الفرق بين HA وDRS والترحيل الحي (Live Migration)

تستجيب كل ميزة لحدث مختلف وتتخذ إجراءً مختلفًا. فهم المُحفّز (trigger) الخاص بكل واحدة هو أسرع طريقة للتوقف عن الخلط بينها.

نموذج ذهني مفيد: DRS استباقي ومستمر، والترحيل الحي هو الآلية التي يستخدمها (أو يستخدمها المسؤول) لتنفيذ القرار، أما HA فهو تفاعلي ولا يعمل إلا بعد وقوع خلل فعلي. لا تُعد أي من هذه الميزات ميزة حماية بيانات، ولا يمكن الاستغناء عنها بمجرد أن تنمو مجموعة الخوادم عن حفنة من الأجهزة.

يحمي HA للأجهزة الافتراضية الأحمال من تعطّل خادم مادي. تراقب الخوادم داخل المجموعة (cluster) بعضها بعضًا عبر نبضات (heartbeats) تُرسل عبر شبكة الإدارة، وغالبًا عبر مسار نبض ثانٍ مثل التخزين المشترك، حتى لا يُفسَّر انقطاع شبكي عابر على أنه تعطّل فعلي للخادم. وعندما يتوقف خادم عن الاستجابة على كل المسارات المراقَبة، يتحقق منطق HA من التعطّل — عادةً بعد مهلة قصيرة مصمَّمة لتجنب الإنذارات الكاذبة — ثم يعيد تشغيل الأجهزة الافتراضية التي كانت تعمل عليه على الخوادم السليمة المتبقية، مستخدمًا تخزينًا مشتركًا أو مكررًا يمكن لجميع الخوادم رؤيته مسبقًا.

من المهم أن نكون دقيقين بشأن ما يفعله HA فعلًا. فهو لا يُبقي الجهاز الافتراضي يعمل أثناء تعطّل العتاد؛ بل يتوقف الجهاز فور تعطّل خادمه، ثم يُعاد تشغيله من جديد في مكان آخر، وتعتمد مدة الإقلاع على نظام التشغيل الضيف والتطبيقات التي بداخله. لذلك يقلّص HA زمن التوقف من ساعات — الوقت الذي يستغرقه عامل بشري لملاحظة العطل وتشخيصه وإعادة تشغيل الأحمال يدويًا — إلى دقائق، لكنه لا يضمن توقفًا صفريًا. أما التطبيقات التي لا تحتمل أي انقطاع، مثل بعض أنظمة المعاملات المالية، فهي بحاجة إلى تجميع (clustering) على مستوى التطبيق، أو تكرار لقواعد البيانات، أو نشر نشط-نشط موزّع بالتحميل، إضافة إلى HA على مستوى البنية التحتية.

يعتمد HA أيضًا على التخطيط السليم للسعة. يجب أن تحتفظ المجموعة بموارد احتياطية كافية، وهو ما يُعرف أحيانًا بسياسة التحكم في القبول (admission control) أو احتياطي سعة الفشل، لاستيعاب أجهزة خادم واحد على الأقل يتعطّل، دون إثقال الخوادم الباقية. فمجموعة من ثلاثة خوادم تعمل جميعها عند 90% من طاقة المعالج لا تملك متسعًا واقعيًا لاستيعاب أحمال خادم متعطّل؛ بينما مجموعة من خمسة خوادم تعمل كل منها عند 60% يمكنها عادة استيعاب تعطّل واحد بسلاسة. وكثيرًا ما تُقلّل الفرق من قيمة هذه السعة المحجوزة، فتتعامل مع HA على أنه تأمين مجاني بدلًا من كونه تكلفة موارد يجب إدراجها في الميزانية.

توجد أيضًا حالات فشل لا يعالجها HA جيدًا. فانقسام الشبكة (network partition) الذي يعزل خادمًا عن بقية المجموعة رغم استمراره في العمل فعليًا قد يخلق خطر ما يُعرف بـ split-brain، حيث يعتقد الخادم المعزول وبقية المجموعة معًا أن كلًا منهما يملك الحق في تشغيل الأجهزة نفسها. تحمي المنصات الناضجة من هذا الخطر عبر آليات fencing أو أقفال قائمة على التخزين، لكن الأهم إدراك أن HA استجابة مصممة بعناية لحالة تعطّل محددة، وليست ضمانًا شاملًا ضد كل عطل ممكن في البنية التحتية.

ينقل الترحيل الحي جهازًا افتراضيًا يعمل من خادم إلى آخر دون إعادة تشغيل، ودون انقطاع يُلاحَظ عمليًا لمعظم الأحمال. تنسخ منصة الافتراضية (hypervisor) ذاكرة الجهاز الافتراضي إلى الخادم الهدف على جولات متكررة: تنسخ صورة الذاكرة كاملة أولًا، ثم تنسخ فقط الصفحات التي تغيّرت أثناء النسخ السابق، وتكرر ذلك حتى يصبح الفارق المتبقي صغيرًا بما يكفي لنقله شبه فوري. عند تلك اللحظة، توقف الجهاز لفترة وجيزة — من جزء من الثانية إلى بضع ثوانٍ حسب كثافة استخدام الذاكرة — لنقل آخر التغييرات وحالة المعالج، ثم تستأنف تشغيله على الخادم الجديد.

من أبرز استخدامات الترحيل الحي:

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

DRS — أو Distributed Resource Scheduling — هو المنطق الذي يقرر أين يجب أن تعمل الأجهزة الافتراضية، سواء عند تشغيلها لأول مرة أو باستمرار بعد ذلك. تستخدم منصات مختلفة أسماء مختلفة لهذه الميزة، لكن الفكرة محايدة تجاه المورّد: مراقبة استخدام المعالج والذاكرة عبر المجموعة باستمرار، ووضع الأجهزة الافتراضية أو نقلها بحيث لا يُثقَل خادم بينما تبقى خوادم أخرى شبه خاملة نسبيًا.

يعمل DRS عادة في لحظتين. الأولى هي التوزيع الأولي، عند تشغيل جهاز افتراضي، حيث يختار المجدوِل الخادم الأنسب استنادًا إلى السعة المتاحة حاليًا وأي قواعد توزيع محددة. والثانية هي إعادة التوازن المستمرة، عندما يتغير الحمل بمرور الوقت — كبدء مهمة معالجة دفعية، أو تغيّر نمط استخدام أحد الأحمال، أو إضافة خادم إلى المجموعة أو إخراجه منها — حيث يقيّم المجدوِل ما إذا كان نقل جهاز أو أكثر سيحسّن توازن المجموعة بشكل ملموس.

يمكن لـ DRS أن يعمل في وضع التوصية، حيث يقترح عمليات النقل ويراجعها المسؤول ويوافق عليها، أو في وضع أتمتة كامل ينفذ فيه النقل ضمن حدود مضبوطة دون تدخل يدوي. تبدأ معظم البيئات الإنتاجية بحذر، في وضع التوصية، ثم تنتقل إلى الأتمتة بعد أن يثق الفريق في سلوك النظام. أما قواعد التوزيع مثل التقارب (affinity، أي إبقاء أجهزة معينة معًا، كخادم تطبيق وذاكرته المؤقتة) والتنافر (anti-affinity، أي إبقاء الأجهزة متباعدة، كنُسخ قاعدة بيانات واحدة كي لا يؤدي تعطّل خادم واحد إلى فقدان كل النسخ) فتتيح للفرق ترميز متطلبات على مستوى التطبيق يتجاهلها الحساب الحسابي الصِرف للموارد.

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

لا يخلق DRS سعة جديدة. فإذا كانت المجموعة بأكملها محمَّلة فوق طاقتها — كل خادم يعمل قرب حدوده — فإن إعادة التوازن توزّع الضغط فقط دون أن تنشئ دورات معالج أو ذاكرة إضافية. يعمل DRS بأفضل صورة إلى جانب تحديد حجم منطقي منذ البداية، ومراقبة مستمرة للسعة كي تكون الاتجاهات واضحة قبل أن تتحول إلى حوادث، وسعة احتياطية محجوزة لأغراض HA. أما الفرق التي تتعامل مع DRS كبديل عن التخطيط للسعة فتكتشف الفجوة عادة أثناء ذروة الحمل أو مباشرة بعد تعطّل خادم، وهو أسوأ وقت ممكن لاكتشافها. لمزيد من الخلفية عن كيفية مشاركة الموارد بين الأجهزة الافتراضية أساسًا، راجع ما هي محاكاة الخوادم الافتراضية.

تخيّل مجموعة من ثلاثة خوادم — الخادم أ والخادم ب والخادم ج — تشغّل طبقة ويب وقاعدة بيانات تقارير وعدة تطبيقات داخلية.

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

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

يستحق الأمر أيضًا تقدير تكلفة كل ميزة بصدق: يستهلك HA سعة احتياطية تبقى خاملة معظم الوقت، ويستهلك DRS بعض حركة الشبكة والتخزين كلما نقل جهازًا، ويضيف الترحيل الحي المستخدم لمجرد الراحة — دون سبب تشغيلي واضح — حملًا دون فائدة تُذكر. لا تُغني أي من هذه الميزات عن حماية البيانات. فحذف ملف، أو تلف قاعدة بيانات، أو حادثة فدية خبيثة، ستبقى محفوظة بأمانة بواسطة HA والترحيل الحي، لأن كليهما يحافظ فقط على الحالة الحالية للجهاز الافتراضي وهو يعمل؛ ولا يعيد أي منهما حالة سابقة غير تالفة. لهذا الغرض تحتاج إلى الأساليب الموضحة في النسخة اللحظية مقابل النسخ الاحتياطي مقابل التعافي من الكوارث.

يبدأ تصميم مجموعة تستفيد بأقصى قدر من HA وDRS والترحيل الحي قبل إنشاء أي جهاز افتراضي. بنية التخزين هي الأهم: تفترض الميزات الثلاث جميعها أن أي خادم قد يستقبل جهازًا افتراضيًا يمكنه رؤية التخزين نفسه، سواء عبر تخزين مشترك أو عبر تكرار متزامن بين الخوادم. تصميم الشبكة يأتي في أهمية مقاربة — إذ تتجنب شبكة ترحيل مخصصة وسريعة بما يكفي منافسة حركة الإنتاج أثناء عملية ترحيل حي كبيرة أو حدث إعادة تشغيل جماعي بواسطة HA.

اتساق أجيال المعالجات بين خوادم المجموعة يقلل الاحتكاك. فمزج أجيال معالجات مختلفة كثيرًا لا يزال ممكنًا عبر إخفاء التوافق، لكنه يخفي بعض تعليمات المعالج الأحدث عن كل جهاز افتراضي في المجموعة، مما قد يؤثر في الأداء. لهذا تفضل فرق كثيرة تجميع الخوادم من الجيل نفسه في مجموعات خاصة بها.

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

تدعم فيرشوا ميزات High Availability وDRS والترحيل الحي كجزء من أساس HV، أساسها للمحاكاة الافتراضية القائم على KVM، مع إدارة عمليات المجموعة عبر لجام لإدارة السحابة. تتيح هذه القدرات للفرق إعادة تشغيل الأحمال بعد تعطّل الخوادم، وإجراء صيانة الخوادم دون إيقاف الأجهزة الافتراضية، والحفاظ على توازن المجموعة مع تغيّر الطلب، وكل ذلك من وحدة تحكم واحدة إلى جانب التزويد والشبكات والتخزين.

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