مع ازدياد الحاجة للبُنى ذات الأداء المرتفع والمصمّمة لخدمة الأنظمة الحساسة، ازدادت أهمّية مصطلحات مثل قابلية التوسعة scalability والوفرة العالية availability. وبينما يُعد تحمّل الاستهلاك المتزايد لموارد النظام أمرًا مهمًّا، فإنّ من المهم أيضًا تخفيض زمن توقف الخدمة downtime والقضاء على نقاط التوقّف الحرجة single points of failure، وتمثّل الوفرة العالية جودة تصميم البُنية على مستوى قادر على معالجة هذه الاعتبارات الحساسة.
سنناقش في المقال ما تعنيه الوفرة العالية بالضبط وكيف بإمكانها تحسّين جودة البنية الخاصة بك.
ما هي الوفرة العالية
يستخدم مصطلح الوفرة لوصف الفترة الزمنية التي تتوفر خلالها الخدمة، بالإضافة للوقت المطلوب من قبل النظام للاستجابة لطلبٍ مُرسَل من قبل مستخدم ما. إنّ الوفرة العالية هي جودة النظام أو العنصر الذي يضمن مستوىً عالٍ من الأداء التشغيلي لفترة من الزمن.
قياس الوفرة
يعبرّ عن الوفرة عادة كنسبة تُمثّل الزمن الذي تكون خلاله خدمة أو نظام ما قيد التشغيل، فتعبّر النسبة 100% مثلًا عن نظام يعمل طوال الوقت دون توقّف أبدًا، بينما تشير النسبة 99% من الوفرة خلال عام واحد إلى أنّ النظام سيعمل طوال العام مع احتمالية انقطاع في الخدمة (إجمالًا) بنسبة 1% أي ما يماثل 3.65 يوم (3 يوم و15 ساعة و36 دقيقة).
يتم وضع هذه النسب بالاعتماد على عدة عوامل، بما في ذلك فترات الصيانة المجدّولة والطارئة، بالإضافة إلى الوقت اللازم لاستعادة النظام لوضعه الطبيعي في حال حدوث خطأ.
كيف تعمل الوفرة العالية
تعمل الوفرة العالية كآلية استجابة عند وقوع مشكلة ما في البنية، وبالرغم من أن مفهومها سهل نظريًا إلا أنّ تنفيذها عمليًّا يتطلب بعض البرمجيات والإعدادات المختصّة.
متى تكون الوفرة العالية مهمة
تكون الوفرة العالية High Availability مهمّة عند إعداد وتثبيت أنظمة متينة robust، حيث يصبح تخفيض زمن انقطاع الخدمة مسألة بالغة الأهمّية. وبغض النظر عن مدى جودة الأنظمة أو البرمجيات لديك، فقد تقع الأخطاء التي قد تؤدي لتوقف برمجياتك أو خواديمك عن العمل.
إنّ تطبيق الوفرة العالية في البنية لديك هو استراتيجية مفيدة لتخفيض الضرر الناتج عن مثل هذه الحوادث، حيث يمكن لأنظمة الوفرة العالية أن تعيد البنية للعمل بصورة طبيعية بشكل أوتوماتيكي.
كيف يتم تحقيق الوفرة العالية
إنّ إحدى أهداف الوفرة العالية هو القضاء على نقاط التوقّف الحرجة في البنية التحتية infrastructure. إنّ نقطة التوقّف الحرجة A single point of failure هي إحدى العناصر في التكنولوجيا التي تستخدمها والتي تؤدي إلى توقّف الخدمة بشكل كامل في حال خروجها فحسب عن الخدمة. وكمثال على هذا، إنّ أي عنصر يعدّ مُهمًّا لعمل برمجياتك ولا يملك أي بديل عنه يمكن أن يُعتبر نقطة توقّف حرجة.
وللقضاء على نقاط التوقّف الحرجة يجب أن يتم تجهيز بديل عن كل طبقة من طبقات النظام. على سبيل المثال، تخيل امتلاكك لبنية تتكون من خادومي ويب متطابقين تمامًا يستخدمان خلف موازن أحمال load balancer. إنّ حركة البيانات التي تصل من المستخدمين سيتم توزيعها بشكل متساوٍ بين الخادومين، ولكن إن توقّف أحدهما عن العمل فسيقوم موازن الأحمال بتحويل جميع البيانات إلى الخادوم الثاني الذي يعمل.
إنّ خادوم الويب في هذه الحالة لا يعتبر نقطة توقّف حرجة لأنّ:
- هناك عنصرًا بديلًا عنه في نفس المستوى،
- موازن الأحمال قادر على اكتشاف المشكلة في العناصر التي تليه ويقوم بتفادي المشكلة في زمن قصير.
ولكن ما الذي قد يحصل في حال توقّف موازن الأحمال عن العمل؟
وفقًا للوصف المقدّم سابقًا الشائع الاستخدام في الحياة العملية، يُعدّ موازن الأحمال نقطة توقف حرجة، والقضاء على نقطة التوقف الحرجة في هذه الحالة هو تحدٍّ صعب على الرغم من أنّ إضافة موازن أحمال ثانٍ أمرٌ ممكن إلا أنّه من غير الواضح أين يُمكن تنفيذ آلية لاكتشاف الخلل الذي قد يطرأ على موازن الأحمال لتفادي المشكلة.
إنّ زيادة عدد العناصر المكرّرة البديلة redundant لا يضمن الوفرة العالية، حيث يتوجب تطبيق آلية لاكتشاف الأخطاء واتخاذ الإجراء المناسب عند توقّف أحد العناصر عن العمل.
إنّ من الممكن تنفيذ آلية اكتشاف الأخطاء والاستعادة من حالة الفشل وفق منهج عمل يبدأ من الأعلى إلى الأسفل، حيث تكون الطبقة العلوية مسؤولة عن مراقبة الطبقة التي تليها مباشرة بحثًا عن وقوع أخطاء. وفي السيناريو السابق، يُعدّ موازن الأحمال هو الطبقة العلوية وعند توقّف أحد خواديم الويب في الطبقة الدُنيا (التالية)، سيقوم موازن الأحمال بإيقاف حركة البيانات باتجاه الخادوم الخارج عن الخدمة.
إنّ هذه الطريقة غير مناسبة على الرغم من بساطتها، حيث لن يكون من الممكن في بعض الحالات تحديد الطبقة العلوية المسؤولة عن مراقبة بعض نقاط التوقّف الحرجة التي تقع في الطبقة التي تليها، كحالة موازن الأحمال في المثال المذكور، وتصبح الآلية -التي يتم إنشاؤها بغرض مراقبة النقاط الحرجة- نقطة حرجة بحد ذاتها.
في هذه المرحلة، يصبح من الضروري اتباع منهج موزّع، حيث يتوجب ربط العقد المكرّرة البديلة عن بعضها البعض مع بعضها البعض كعنقود cluster وينبغي أن تكون كل عقدة منها قادرة على اكتشاف الخطأ وتفاديه في العقد المتصلة معها ضمن العنقود.
وفي حالة موازن الأحمال، فالأمر أعقد بقليل من ذلك، نظرًا للآلية التي تعمل بها خواديم الأسماء nameservers في DNS، حيث يتطلب الاستعادة من خطأ يحصل في موازن أحمال مكرّر redundant أن يتم إجراء تعديل على سجلّات DNS كي يتم توجيه اسم النطاق domain name إلى عنوان IP لموازن الأحمال الثانوي. إنّ مثل هذا التغيير يحتاج وقتًا ليس بقصير حتى يصبح ساري المفعول على شبكة الإنترنت، مما سيؤدي إلى حصول انقطاع طويل في الخدمة.
أحد الحلول لمثل هذه المشكلة هو استخدام موازن أحمال DNS يستخدم خوارزمية Round-Robin، ولكن هذا النهج غير عملي لأنّه يترك احتمالية وقوع خطأ في البرنامج من جهة العميل.
إن الحل الأكثر عملية ومتانة هو استخدام أنظمة تسمح بعنونة مرنة للعناوين الرقمية IP، كالعناوين الرقمية العائمة floating IPs. إنّ التبديل بين العناوين الرقمية عند الطلب يُلغي الحاجة للانتظار حتى يتم نشر العنوان الجديد لاسم النطاق عند تغييره على الشبكة، وذلك عبر توفير عناوين رقمية ثابتة يمكن نقلها من عنصر لآخر عند الطلب، حيث يبقى اسم النطاق مرتبطًا بالعنوان الرقمي نفسه، بينما يتم نقل العنوان الرقمي بين الخواديم.
يتم تطبيق البنى ذات الوفرة العالية باستخدام العناوين الرقمية العائمة على الشكل التالي:
ما العناصر اللازمة لتنفيذ الوفرة العالية
هناك عدة عناصر يجب أخذها بعين الاعتبار لتنفيذ الوفرة العالية على أرض الواقع، حيث تعتمد الوفرة العالية على عدة عوامل لا تتوقف عند التطبيق البرمجي فحسب، كـ:
- البيئة: إن كانت جميع الخواديم موجودة في ذات المنطقة الجغرافية، فيمكن لكارثة طبيعية كالهزات الأرضية أو الفيضانات أن تقضي على النظام كاملًا، وبالتالي يكون من المهم توزيع الأنظمة المكرّرة البديلة على مراكز بيانات مختلفة ضمن مناطق جغرافية متباعدة أمرًا مهمًا لرفع نسبة الوفرة.
- العتاد الصلب: يجب أن تكون خواديم الوفرة العالية حصينة من الانقطاعات الكهربائية ومشاكل العتاد الصلب كأقراص التخزين وبطاقات الشبكة.
- العتاد البرمجي: يجب أن تكون البرمجيات وأنظمة التشغيل معدّة لمعالجة الأخطاء الطارئة التي قد تتطلب إعادة التشغيل على سبيل المثال.
- البيانات: يجب أن تأخذ أنظمة الوفرة العالية احتمالية فقدان البيانات نتيجة مشكلة ما بعين الاعتبار، ففقدان البيانات وأخطائها قد يحدث نتيجة عوامل مختلفة لا تتعلق بمشاكل الأقراص الصلبة فقط.
- الشبكة: الانقطاعات الطارئة غير المتوقّعة في اتصالات الشبكة تمثّل نقطة توقّف حرجة أخرى في أنظمة الوفرة العالية، ومن المهم تصميم الشبكة التي تخدم أنظمة الوفرة العالية بطريقة تضمن عدم خروجها عن الخدمة في حال حدوث مشكلة في إحدى نقاط التوقّف الحرجة.
ما البرمجيات التي من الممكن استخدامها لإعداد أنظمة الوفرة العالية
إن كلّ طبقة من طبقات أنظمة الوفرة العالية تحتاج متطلّبات مختلفة في البرمجيات والإعدادات. ولكنّ موازنات الأحمال تعدّ جزءًا ضروريًا على مستوى التطبيقات لإنشاء أي نظام وفرة عالية.
يُعدّ برنامج (HAProxy (High Availability Proxy أحد الخيارات الشائعة لتوزيع الأحمال، حيث بإمكانه إدارة توزيع الأحمال على عدّة طبقات، ولمختلف أنواع الخواديم، بما في ذلك خواديم مراكز البيانات.
وبالانتقال إلى الأعلى في طبقات النظام، فإنّ من المهم تنفيذ حل معتمد انطلاقًا من المدخل، وهو موازن الأحمال عادة. ولإلغاء نقطة توقّف حرجة كما ذكرنا سابقًا، نحتاج لتنفيذ عنقود مشكّل من موازنات الأحمال التي تستخدم العناوين الرقمية العائمة. يُعدّ كلّ من Corosync و Pacemaker خيارين شائعين لتنفيذ هذا الغرض، ويتوفّران على خواديم Ubuntu و CentOS.
الخلاصة
إن الوفرة العالية أمرٌ هام، تركّز على ضمان امتلاك النظام أو أحد العناصر لقدرة تشغيل عالية في فترة من الزمن. وقد يبدو تنفيذها للوهلة الأولى أمرًا معقّدًا، ولكنّها تؤمن فوائد كبيرة للأنظمة التي تتطلب اعتمادية متزايدة.
ترجمة -وبتصرّف- للمقال What is High Availability لصاحبته Erika Heidi.
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.