يقوم التوسع التلقائي بزيادة وتقليل عدد الحالات التي تُشغّل تطبيق Node.js الخاص بك مع تغيّر حمل CPU، بحيث تحصل فترات الذروة على سعة أكبر وتكلّف فترات الهدوء أقل. يغطي هذا الدليل تبويب KPanel، وكل إعداد، وما الذي يُحتسب عليه الفاتورة، وكيفية جعل التطبيق آمنًا للتوسع.
أين يوجد التوسع في KPanel
- سجّل الدخول إلى KPanel.
- اضغط على المواقع في الشريط الجانبي الأيسر، ثم اضغط على الموقع.
- في القائمة اليسرى للموقع، افتح الأداء، ثم التوسع.
العنوان المباشر هو /websites/<site-id>/autoscale. العنوان الأقدم /websites/<site-id>/scaling لا يزال يعمل ويحوّلك إلى الصفحة نفسها.
يظهر هذا التبويب فقط في مواقع Node.js. لن يظهر في القائمة لمواقع WordPress أو WooCommerce أو المواقع الثابتة أو PHP أو Python أو Ruby، لأن الآلية تُوسّع مجموعة عمليات Node.js.
تبويب واحد، إعداد واحد
كان KPanel يحتوي سابقًا على تبويبين هنا، التوسع والتوسع التلقائي، لمجموعة إعدادات واحدة. كانا عرضين لنفس الإعدادات، ولم يكونا سوى سبب للتشوّش، لذا أصبحا الآن تبويبًا واحدًا هو التوسع: الحالة المباشرة، والإعدادات، وأحداث التوسع الأخيرة، ولوحة الاستخدام والتكلفة لفترة الفوترة الحالية، كل ذلك في مكان واحد.
كيف يعمل
يعمل تطبيقك كمجموعة من العمليات. يراقب التوسع التلقائي متوسط CPU عبر الحالات العاملة ويضيف أو يزيل حالات بناءً على الحدود التي تضبطها.
وضع العنقدة (cluster mode) مطلوب. إذا لم يكن تطبيقك يعمل بالفعل في وضع العنقدة، فإن تفعيل التوسع التلقائي يُحوّله لك، وهو ما يتضمن إعادة تشغيل قصيرة. تُعلمك الصفحة عند حدوث ذلك.
قراءة الحالة المباشرة
تعرض بطاقة الحالة ثلاثة أمور:
- Instances: عدد الحالات العاملة حاليًا.
- متوسط CPU: متوسط CPU عبر تلك الحالات.
- Cluster: ما إذا كان التطبيق في وضع العنقدة. إذا كانت الإجابة لا، فإن تفعيل التوسع التلقائي سيُحوّله.
إذا لم يكن التطبيق يعمل على الإطلاق، تُظهر البطاقة ذلك بدلًا من عرض أصفار.
يعرض التبويب أيضًا آخر توسع، وهو وقت آخر حدث توسع، أو never إن لم يحدث شيء.
الإعدادات
| الإعداد | النطاق | ماذا يفعل |
|---|---|---|
| الحد الأدنى من الحالات | 1 إلى 16 | الحد الأدنى. لا يتوسع أبدًا تحت هذا الرقم |
| الحد الأقصى من الحالات | 1 إلى 16 | الحد الأقصى. لا يتوسع أبدًا فوق هذا الرقم |
| التوسع عند CPU % | 5 إلى 99 | متوسط CPU فوق هذا الحد يضيف حالة |
| التقليل عند CPU % | 1 إلى 95 | متوسط CPU تحت هذا الحد يزيل حالة |
| فترة الانتظار (ثانية) | 30 إلى 3600 | الحد الأدنى من الانتظار بين إجراءات التوسع |
المفتاح الرئيسي هو الزر في رأس بطاقة الإعدادات. عندما يكون التوسع التلقائي متوقفًا، تصبح الإعدادات باهتة ويبقى تطبيقك على عدد الحالات الحالي.
قيم بداية منطقية:
- الحد الأدنى من الحالات 1 أو 2. اثنان إذا كنت لا تستطيع تحمّل أن تؤدي إعادة تشغيل حالة واحدة إلى تعطيل التطبيق.
- الحد الأقصى من الحالات عند ما أنت مستعد لدفعه في أوقات الذروة، وليس عند السقف الفعلي.
- التوسع عند نحو 70 بالمئة. مرتفع بما يكفي بحيث لا تدفع ثمن سعة احتياطية لا تستخدمها أبدًا، ومنخفض بما يكفي ليكون هناك وقت لإضافة سعة قبل أن تبدأ الطلبات بالتراكم.
- التقليل عند نحو 30 بالمئة. اترك فجوة واسعة بين الحدّين.
- فترة انتظار من بضع دقائق. هذا هو الإعداد الأقل تقديرًا من الجميع.
ضبط حدّي CPU قريبين جدًا من بعضهما يسبب تذبذبًا: تتوسع المجموعة، ثم تنخفض فورًا تحت حد التقليل لأن الحمل أصبح الآن موزعًا على نطاق أوسع، فتتقلص، ثم ترتفع مجددًا، وهكذا تتكرر الدورة. حافظ على فجوة واسعة، واستخدم فترة انتظار سخية. التذبذب يكلّف مالًا ويزعزع استقرار التطبيق.
أحداث التوسع
يسرد التبويب أحداث التوسع الأخيرة، من الأحدث إلى الأقدم، موضحًا لكل منها الاتجاه، وعدد الحالات قبل وبعد، وقراءة CPU التي أثارت الحدث، والوقت.
هذا هو السجل الذي تقرأه عندما يُساء تصرف التطبيق. سلسلة من أحداث الزيادة والنقصان خلال دقائق قليلة تعني أن حدودك قريبة جدًا من بعضها أو أن فترة الانتظار قصيرة جدًا. توسّع واحد لم يعد للانخفاض أبدًا يعني أن الحمل بقي مرتفعًا، وهذه مسألة سعة وليست مسألة إعداد. عدم وجود أي أحداث على الإطلاق بينما كنت تتوقع بعضها يعني إما أن CPU لم يتجاوز أي حد، أو أن التوسع التلقائي متوقف.
تكلفة التوسع التلقائي
تُقاس الحالات التي تتجاوز التخصيص الأساسي لخطتك وتُحتسب فاتورتها بالثانية. يعرض التبويب، للفترة الحالية:
- وقت الحالة المستخدم، بالساعات والدقائق، مع عدد ثواني الحالة الخام تحتها.
- المُنفق حتى الآن في هذه الفترة.
- التوقع عند نهاية الشهر، المُستنتج من الاستخدام حتى الآن.
- Tracking، عدد نوافذ الاستخدام التي تم احتسابها من إجمالي ما تم تسجيله.
- تقدم الفترة، عدد الأيام المنقضية من إجمالي أيام الشهر.
يظهر السعر لكل ثانية أعلى اللوحة نفسها، بحيث يكون الرقم الذي تُحاسَب عليه مرئيًا دائمًا بجانب الاستخدام الذي ينطبق عليه.
التوقع هو الرقم الذي يجب مراقبته. فهو يُستنتج مما استخدمته حتى الآن، لذا فإن أسبوعًا مزدحمًا بشكل غير معتاد في بداية الشهر سيُضخّمه. تحقق منه بعد بضعة أيام، ثم مرة أخرى في منتصف الشهر، قبل استخلاص أي استنتاجات. إذا كان أعلى مما تريد، فخفّض الحد الأقصى لعدد الحالات بدلًا من رفع حد التوسع: فالسقف حد صارم، بينما الحد ليس سوى إشارة استرشادية.
التقليص إلى الحد الأدنى يوقف الاحتساب. إذا أوقفت التوسع التلقائي بالكامل، يبقى التطبيق على عدد الحالات الذي لديه حاليًا، لذا أعده إلى الحد الأدنى أولًا إذا كانت التكلفة هي سبب إيقافك له.
جعل التطبيق آمنًا للتوسع
تحمل الصفحة تحذيرًا، وهو أهم ما فيها: يجب أن يكون تطبيق Node.js الخاص بك آمنًا للعنقدة حتى يتوسع بسلاسة عبر الحالات.
عمليًا، هذا يعني:
لا حالة جلسة في الذاكرة. إذا كانت جلسة مستخدم مسجّل الدخول تعيش في ذاكرة حالة واحدة، فسيتم تسجيل خروجه كلما وصل طلب إلى حالة مختلفة. انقل الجلسات إلى مخزن مشترك.
لا ذاكرة تخزين مؤقت في الذاكرة تعتمد عليها للصحة. لكل حالة ذاكرتها الخاصة. أي ذاكرة تخزين مؤقت يجب أن تكون متسقة ينبغي أن تكون مشتركة.
لا كتابة محلية على نظام الملفات تتوقع قراءتها لاحقًا. الملفات المرفوعة التي تُكتب على القرص المحلي من قبل حالة واحدة غير مرئية للحالات الأخرى. اكتب إلى تخزين مشترك.
لا عمل مجدول غير محمي. إذا كان مؤقّت يعمل داخل التطبيق، فإن كل حالة تُشغّله، بحيث تعمل مهمة ليلية على أربع حالات أربع مرات. انقل العمل المجدول إلى مهمة cron، أو احمِه بقفل. راجع مهام Cron.
لا افتراض بأن عدد الحالات ثابت. أي شيء يقسّم العمل بحسب فهرس الحالة ينكسر بمجرد تغيّر العدد.
إذا كان أي من هذا ينطبق على تطبيقك، فأصلحه قبل تفعيل التوسع التلقائي. التطبيق غير الآمن للعنقدة يفشل بطرق متقطعة ويصعب إعادة إنتاجها، لأنها تعتمد على أي حالة خدمت أي طلب.
استكشاف الأخطاء وإصلاحها
المفتاح لا يُفعَّل. يتطلب التفعيل صلاحية الكتابة على الموقع. مع دور للقراءة فقط تكون عناصر التحكم معطلة.
أعيد تشغيل التطبيق عند تفعيل التوسع التلقائي. هذا متوقع. التحوّل إلى وضع العنقدة يتطلب إعادة تشغيل، ويحدث ذلك مرة واحدة.
يتم تسجيل خروج المستخدمين عشوائيًا. عرض كلاسيكي لعدم الأمان مع العنقدة. الجلسات في الذاكرة والطلبات تصل إلى حالات مختلفة.
توسعت الحالات ولم تعد للانخفاض أبدًا. إما أن الحمل بقي فوق حد التقليل، أو أن شيئًا ما يُبقي CPU مرتفعًا بغض النظر عن حركة المرور. تحقق من قائمة الأحداث وانظر فيما يفعله التطبيق فعليًا.
عملت مهمة مجدولة عدة مرات. كل حالة شغّلتها. انقلها إلى مهمة cron أو أضف قفلًا.
لا شيء يتوسع. تأكد من أن المفتاح مُفعّل، وأن التطبيق يعمل، وأن وضع العنقدة مُفعّل. ثم تحقق مما إذا كان CPU قد تجاوز فعليًا حد التوسع في قائمة الأحداث.
التكلفة أعلى من المتوقع. انظر في قائمة الأحداث بحثًا عن التذبذب، ثم خفّض الحد الأقصى لعدد الحالات.
صفحات ذات صلة
- أداء الموقع ومراقبة الأداء (APM) لمعرفة ما إذا كان CPU هو عنق الزجاجة فعلًا.
- مراقبة جاهزية الموقع للتأكد من أن التوسع يُحسّن التوافر فعلًا.
- مهام Cron للأعمال المجدولة التي يجب أن تعمل مرة واحدة بالضبط.
- تغيير حجم خادم سحابي إذا كنت بحاجة إلى جهاز أكبر بدلًا من حالات إضافية.