“`html

ميزات التوافر العالي (HA)

وظيفة التوافر العالي هي وظيفة تقوم بـ “إعادة التشغيل” تلقائيًا (تُسمى الفشل الاحتياطي) لآلة افتراضية على مضيف آخر يعمل بشكل طبيعي عند فشل مضيف فعلي. لذلك، من الضروري اتخاذ الترتيبات مسبقًا داخل نظام تشغيل الآلة الافتراضية الضيف بحيث يمكن استعادة النظام تلقائيًا.

ما هي شروط استخدام HA؟

لاستخدام HA مع إصدار HRPC KVM، يجب استيفاء الشروط التالية:

1. مركز بيانات افتراضي يتكون من ثلاثة عقد أو أكثر تم تهيئتها بشكل متطابق.
2. يجب أن يكون من نوع HCI أو نوع ثلاثي الطبقات، حيث يتطلب تخزين مشترك (Ceph، ESF مع ES).
3. يجب أن تكون هناك سعة احتياطية كافية (خاصة الذاكرة) على المعدات. من المهم أن تكون ذاكرة عقدة واحدة على الأقل خالية في المجمل.
   *على سبيل المثال، في حالة مركز بيانات افتراضي يتكون من ثلاث عقد، يجب استخدام ذاكرة عقدتين فقط في المجمل.
4. تأكد من أخذ نسخ احتياطية للآلات الافتراضية.
   نوصي بشدة بتوقيع عقد مع تخزين النسخ الاحتياطية أو ما شابه وإعداد نسخ احتياطية دورية للآلات الافتراضية.

كيفية تفعيل وظيفة HA؟

إذا كنت ترغب في تفعيل وظيفة HA، حدد أولاً مركز البيانات في اللوحة اليسرى، افتح HA في اللوحة الوسطى، وانقر على المجموعة.

انقر على زر الإنشاء في اللوحة اليمنى، قم بإنشاء معرف مجموعة HA، وتحقق من المضيفين المرتبطين بـ HA. عند إنشاء آلات افتراضية على مضيفين مرتبطين بـ HA، يجب تجهيز ذاكرة احتياطية تعادل مضيفًا فعليًا واحدًا على الأقل. إذا كنت تشارك في HA بإجمالي أربعة HRPCs مزودة بذاكرة 768 جيجابايت، ستحتاج الأجهزة الثلاثة المتبقية إلى 768 جيجابايت من الذاكرة الحرة حتى تتمكن الأجهزة الأخرى من الاستمرار في العمل حتى في حالة حدوث عطل فعلي في HRPC واحد. إذا لم تقم بالتحقق من مجموعة HA، سيتم تجاهلها كجهة مستهدفة لـ HA حتى لو كانت في نفس مركز البيانات.

إذا تم إزالة مضيف عمدًا من مجموعة HA، وتم تحديد إعداد مجموعة HA “مقيد”، فلن يمكن بدء الآلات الافتراضية التي تنتمي إلى تلك المجموعة HA على المضيف المزال.

إذا تم تحديد nofailback، فعندما يتم إعادة تشغيل عقدة فعلية فاشلة وتعود، لن يتم استعادة الآلات الافتراضية بل ستستمر في العمل في الوجهة. إذا لم يتم تحديد nofailback، ستُعاد إلى العقدة الأصلية عن طريق الهجرة الحية، مما يسمح بإدارة صارمة لتوزيع مضيفي العقد والآلات الافتراضية. ومع ذلك، إذا أصبحت العقدة الفعلية غير مستقرة وتم إعادة تشغيلها بشكل متكرر، سيتم تفعيل HA مرة أخرى وستتم إعادة تشغيل الآلات الافتراضية بشكل متكرر. لهذا السبب، نوصي بتحديد nofailback.

أيضًا، بينما الهجرة الحية هي ميزة نادرًا ما تفشل، هناك انقطاع داخلي لحظي يمكن أن يسبب مشاكل في البرامج في الوقت الحقيقي.

كيف أقوم بتفعيل HA لآلة افتراضية؟

لن يكون Proxmox HA قابلاً للتطبيق ما لم تكن الآلة الافتراضية تحت إدارة HA.

لوضع آلة افتراضية تحت إدارة HA، حدد الآلة الافتراضية واختر “إدارة HA” من القائمة المنسدلة “المزيد▼” في الجزء العلوي الأيمن. اختر معرف مجموعة HA التي قمت بتهيئتها أعلاه من المجموعة، قم بتعيين الحالة المطلوبة على بدء التشغيل، ثم انقر على زر الإضافة.

هذه الآلة الافتراضية الآن تحت سيطرة HA.

يختلف نطاق عملية HA حسب المحاكي الافتراضي. في VMware، عند تفعيل HA في مركز بيانات افتراضي، يؤثر ذلك على جميع الآلات الافتراضية في مركز البيانات الافتراضي، بينما في XenOrchestra، يؤثر فقط على الآلات الافتراضية في المجموعة التي تم تفعيل HA لها وتم تعيين “إعادة التشغيل” لها.

العلاقة بين إعادة تشغيل صيانة العقد (المضيفين) في مجموعة HA والآلات الافتراضية

عند إعادة تشغيل عقدة جزء من مجموعة HA لأغراض الصيانة (وليس بسبب فشل غير متوقع)، سيكون سلوك الآلات الافتراضية مختلفًا حسب ما إذا كانت تحت إدارة HA أم لا.

الآلات الافتراضية تحت إدارة HA	الهجرة الحية إلى آلة أخرى
الآلات الافتراضية غير المُدارة بواسطة HA	يتم إيقافها تلقائيًا وتظل مغلقة بعد إعادة التشغيل

عمود

قيود وظيفة HA

وظائف HA لها قيود، وهناك مشاكل يمكن أن تحدث عند استخدام HA.

1. إعادة تشغيل غير متوقعة لآلة افتراضية
2. تلف بيانات الآلة الافتراضية

ببساطة، HA هي القدرة على بدء آلة افتراضية من عقدة أخرى عند فشل عقدة، لكن هذا هو طريقة عملها من منظور عين الله، والمنطق البرمجي الفعلي يجب أن يتم تنفيذه بشكل مختلف تمامًا.

أولاً، ليس من الممكن تحديد بدقة ما يشكل “فشلًا” في عقدة معينة من بين جميع العقد الثلاث (أي العقدة A، العقدة B، والعقدة C). يتم تحقيق HA من خلال تنسيق كل عقدة مع الأخرى.

عندما تفقد العقدة A الاتصال بالعقدة B، ليس من الواضح ما إذا كان قد حدث فشل في العقدة B، أو ما إذا تم فقدان الاتصال بين العقدة A والعقدة B فقط. إذا كانت العقدة A قادرة على التواصل مع العقدة C من منظورها، فمن المتصور أن يكون قد حدث فشل في العقدة B.

ومع ذلك، إذا كانت بيانات الآلات الافتراضية المستضافة على العقدة B يتم تحديثها باستمرار على التخزين المشترك، فقد تكون العقدة B معزولة تمامًا.

في المثال أعلاه، إذا كانت العقدتان A وC تتواصلان، فهناك احتمال كبير أن تكون العقدة B قد فشلت. لذلك، ستحاول العقدتان A وC تشغيل الآلات الافتراضية المستضافة على العقدة B بنفسيهما.

ومع ذلك، قد لا تكون العقدة B قد فشلت، بل قد تكون معزولة فقط. إذا قررت عقدة أنها معزولة، ستوقف فورًا الآلات الافتراضية التي تستضيفها استعدادًا لاحتمال بدء العقدتين A وC، وهذا ما يسبب إعادة التشغيل غير المتوقعة المذكورة أعلاه.

فماذا يحدث إذا لم تتوقف العقدة B؟

إذا كانت نفس الآلة الافتراضية تعمل في مكانين، العقدة B وعقدة أخرى، فسيتم تلف القرص الافتراضي للآلة الافتراضية في لحظة، مما سيؤدي إلى تدمير بيانات الآلة الافتراضية المذكورة أعلاه.

لذا خيارك إما إعادة التشغيل أو تدمير بياناتك.

يحتاج HA إلى التنسيق بين كل عقدة لتحديد ما إذا كانت معطلة، أو فقدت الاتصال فقط، أو بطيئة.

إذا كانت الفشلان المذكوران أعلاه متعارضان، فما تريد تجنبه هو تلف البيانات، لذا أغلق فورًا.

يتم اتخاذ هذا القرار على فترات، ويفعل Proxmox ذلك كل دقيقتين. إذا لم يكن هناك استجابة لمدة دقيقتين، يتم تحديد أن “المضيف قد فشل.” لذلك، على الأقل، سيكون وقت التوقف دقيقتين + الوقت الذي يستغرقه لتشغيل الآلة الافتراضية (في الواقع، سيستغرق وقتًا أطول).

ومع ذلك، إذا تباطأت سرعة العقدة، تم تبديل الذاكرة، تسبب استرداد الذاكرة بواسطة برنامج البالون في تباطؤ مؤقت، أو تباطأت كتابة التخزين، يمكن أن تمر الدقيقتان بسرعة وقد لا يكون من الممكن الإغلاق في الوقت المناسب. لأن ما يجب حمايته هو البيانات، يستخدم النظام تلقائيًا مؤقت WatchDog أو ما شابه، وتعمل السحابات الخاصة على أجهزة مزودة بجهاز يمكنه إعادة تشغيل النواة تلقائيًا حتى لو توقفت نواة المضيف عن الاستجابة.

“`