إنشاء بنية عالية التوفر

مكتمل

يضمن قابلية الوصول العالية (HA) أن البنية لديك يمكنها التعامل مع حالات الفشل. تخيل أنك تتحمل مسؤولية نظام يجب أن يعمل بكامل طاقته على الدوام. يمكن أن تحدث الأعطال، لذا، كيف تضمن بقاء نظامك متصلاً بالإنترنت عندما يحدث خطأ ما؟ كيف تقوم بالصيانة دون انقطاع الخدمة؟

ومن هنا ستتعرف على الحاجة إلى قابلية الوصول العالية، وتقييم متطلبات التوفر العالي للتطبيق، ومعرفة كيف يساعدك النظام الأساسي لـ Azure على تحقيق أهداف قابلية الوصول لديك.

ما المقصود بقابلية الوصول العالية؟

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

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

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

تقييم قابلية الوصول العالية للبنية لديك

هناك ثلاث خطوات لتقييم تطبيق قابلية الوصول العالية:

  1. تحدد اتفاقية مستوى الخدمة لتطبيقك
  2. تقييم قدرات قابلية الوصول العالية للتطبيق
  3. تقييم إمكانيات قابلية الوصول العالية للتطبيقات التابعة

لنستكشف هذه الخطوات بالتفصيل.

تحدد اتفاقية مستوى الخدمة لتطبيقك

الاتفاقية على مستوى الخدمة (SLA) هي عبارة عن اتفاقية بين مقدم الخدمة ومستهلك الخدمة حيث يلتزم مزود الخدمة بمعيار الخدمة بناءً على مقاييس ومعايير قابلة للقياس ومسؤوليات محددة. يمكن أن تكون الاتفاقيات على مستوى الخدمة صارمة أو ملزمة قانونًا أو اتفاقيات تعاقدية أو توقعات مفترضة لقابلية الوصول من خلال العملاء. عادةً ما تركز مقاييس الخدمة على معدل نقل الخدمة والسعة وقابلية الوصول، ويمكن قياسها جميعًا بطرق مختلفة. وبغض النظر عن المقاييس المحددة التي تشكّل الاتفاقية على مستوى الخدمة، يمكن أن يسفر الفشل في تلبية اتفاقية مستوى الخدمة عن عواقب مالية خطيرة على مزود الخدمة. ويتمثل أحد عناصر المكونات المشتركة لاتفاقيات الخدمة في ضمان تسديد النفقات المالية للاتفاقيات على مستوى الخدمة المفقودة.

أهداف مستوى الخدمة (SLO) هي عبارة عن قيم المقاييس المستهدفة التي تُستخدم لقياس الأداء أو الموثوقية أو قابلية الوصول. قد تكون هذه المقاييس التي تحدد أداء معالجة الطلب بالمللي ثانية، أو مدى قابلية الوصول للخدمات في دقائق في الشهر، أو عدد الطلبات التي يجري معالجتها في الساعة. ومن خلال تقييم المقاييس التي يعرضها تطبيقك وفهم ما يستخدمه العملاء باعتباره مقياسًا للجودة، يمكنك عندئِذٍ تحديد النطاقات المقبولة وغير المقبولة لأهداف مستوى الخدمة هذه. ومن خلال تحديد هذه الأهداف، فإنك تحدد بوضوح الأهداف والتوقعات مع كل من الفِرق التي تدعم الخدمات والعملاء الذين يستهلكون هذه الخدمات. تُستخدم أهداف مستوى الخدمة هذه لتحديد ما إذا كان يتم الوفاء بالاتفاقية على مستوى الخدمة بشكل عام أم لا.

يوضح الجدول التالي فترات التعطل التراكمية المحتملة لمستويات اتفاقية مستوى الخدمة المختلفة.

اتفاقية على مستوى الخدمة «SLA» وقت التعطل في الأسبوع وقت التعطل في الشهر وقت التعطل في السنة
99% 1.68 ساعة 7.2 ساعات 3.65 أيام
99.9% 10.1 دقائق 43.2 دقيقة 8.76 ساعات
99.95% 5 دقائق 21.6 دقيقة 4.38 ساعات
99.99% 1.01 دقيقة 4.32 دقائق 52.56 دقيقة
99.999% 6 ثوانٍ 25.9 ثانية 5.26 دقائق

تعد قابلية الوصول العالية الأفضل والأنسب، وكل شيء آخر يبدو متساويًا. ولكن عندما تسعى جاهدًا للحصول على أكثر من 9، تزداد التكلفة والتعقيد لتحقيق هذا المستوى من قابلية الوصول. ويُترجم وقت التشغيل بنسبة 99.99% إلى حوالي 5 دقائق من إجمالي وقت التعطل شهريًا. هل يستحق الأمر التعقيد الإضافي والتكلفة للوصول إلى خمس أعداد من العدد 9 (99.999%)؟ الجواب يعتمد على متطلبات الأعمال.

فيما يلي بعض الاعتبارات الأخرى عند تحديد اتفاقية على مستوى الخدمة:

  • وحتى يتسنى تحقيق أربعة أعداد من العدد 9 (99.99%)، ربما لا يمكنك الاعتماد على التدخل اليدوي للتعافي من حالات الفشل. يجب أن يتسم التطبيق بالتشخيص الذاتي والإصلاح الذاتي.
  • بعد تحقيق أربعة أعداد من العدد 9 (99.99%)، من الصعب اكتشاف حالات انقطاع الاتصال بسرعة كافية للوفاء باتفاقية مستوى الخدمة.
  • فكّر في الإطار الزمني الذي يتم قياس اتفاقية مستوى الخدمة مقارنة به. كلما كانت النافذة أصغر، كان التحميل أشد. قد لا يكون من المنطقي تحديد اتفاقية مستوى الخدمة من حيث وقت التشغيل كل ساعة أو يوميًا.

يعد تحديد اتفاقيات مستوى الخدمة خطوة أولى مهمة عند تحديد إمكانات قابلية الوصول العالية التي تتطلبها البنية لديك. سيساعد هذا الأمر في تشكيل الطرق التي ستستخدمها لجعل تطبيقك يتمتع بقابلية الوصول العالية.

تقييم قدرات قابلية الوصول العالية للتطبيق

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

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

تقييم إمكانيات قابلية الوصول العالية للتطبيقات التابعة

ولن يقتصر الأمر على فهم متطلبات اتفاقية مستوى الخدمة (SLA) الخاصة بتطبيقك إلى المستهلك فحسب، ولكن أيضًا فهم اتفاقيات مستوى الخدمة المقدمة لأي مورد قد يعتمد عليه تطبيقك. إذا كنت تلتزم بوقت تشغيل لعملائك بنسبة 99.9%، ولكن الخدمة التي يعتمد عليها تطبيقك تلتزم بوقت تشغيل بنسبة 99% فقط، فقد يعرضك هذا الأمر لخطر عدم تلبية اتفاقية مستوى الخدمة لعملائك. إذا كانت الخدمة التابعة غير قادرة على توفير اتفاقية على مستوى خدمة بقدر كافٍ، فقد تحتاج إلى تعديل اتفاقية مستوى الخدمة لديك، أو استبدال التبعية ببديل، أو إيجاد طرق للوفاء باتفاقية مستوى الخدمة عندما تكون التبعية غير متاحة. واعتمادًا على السيناريو وطبيعة التبعية، يمكن التعامل مع التبعيات الفاشلة مؤقتًا باستخدام حلول مثل ذاكرات التخزين المؤقت وقوائم انتظار العمل.

منصة قابلية الوصول العالية الخاصة بـ Azure

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

  • مجموعات التوفر
  • مناطق التوفر
  • موازنة التحميل
  • قابلية الوصول العالية إلى النظام الأساسي كخدمة (PaaS)

مجموعات التوفر

تعد مجموعات التوفر طريقة لإعلام Azure بأنه يجب توزيع الأجهزة الظاهرية التي تنتمي إلى نفس حمل عمل التطبيق لمنع التأثير المتزامن من فشل الأجهزة والصيانة المجدولة. تتكون مجموعات التوفر من مجالات التحديث و مجالات الخطأ.

رسم توضيحي يوضح ثلاث مجموعات توفر. تحتوي المجموعة الأولى على مجال تحديث واحد، والثانية بها مجالان للتحديث، والثالثة لا تحتوي على أي مجال تحديث.

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

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

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

مناطق التوفر

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

رسم توضيحي يوضح ثلاث مناطق توفر داخل منطقة Azure. تحتوي كل منطقة توافر مجموعة على موارد خاصة بها وتتصل ببعضها لإجراء نسخ متماثل لخدمات المنطقة المتكررة.

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

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

موازنة التحميل

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

تمتلك Azure ثلاث خدمات تقنية لموازنة التحميل تتميز بقدراتها على توجيه حركة نقل البيانات عبر الشبكة:

  • تتيح خدمة Azure Traffic Manager موازنة عالمية لتحميل DNS. قد تفكر في استخدام Traffic Manager لتوفير موازنة التحميل لنقاط نهاية DNS داخل مناطق Azure أو عبرها. سيقوم Traffic Manager بتوزيع الطلبات على نقاط النهاية المتاحة، واستخدام مراقبة نقطة النهاية لاكتشاف وإزالة نقاط النهاية الفاشلة من التحميل.
  • توفر خدمة Azure Application Gateway إمكانات موازنة تحميل الطبقة 7، مثل التوزيع الدائري لنسبة استخدام الشبكة الواردة، وترابط الجلسة المستندة إلى ملفات تعريف الارتباط، والتوجيه المستند إلى مسار URL، والقدرة على استضافة مواقع ويب متعددة خلف بوابة تطبيق واحدة. تراقب Application Gateway بشكل افتراضي سلامة جميع الموارد الموجودة في تجمعها الخلفي وتزيل تلقائيًا أي مورد يعتبر غير سليم من التجمع. تواصل Application Gateway مراقبة الحالات غير السليمة وإضافتها مرة أخرى إلى المجموعة الخلفية السليمة بمجرد توفرها والاستجابة للتحقيقات السليمة.
  • Azure Load Balancer هي عبارة عن موازنة تحميل من الطبقة 4. يمكنك تكوين نقاط نهاية التحميل العامة والداخلية المتوازنة وتحديد القواعد لتعيين الاتصالات الواردة إلى وجهات التجمع الخلفي باستخدام خيارات فحص سلامة TCP وHTTP لإدارة توفر الخدمة.

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

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

إمكانات قابلية الوصول العالية للنظام الأساسي كخدمة PaaS

تأتي خدمات النظام الأساسي كخدمة PaaS مع قابلية الوصول العالية المضمنة. تتضمن الخدمات مثل قاعدة بيانات Azure SQL وAzure App Service وAzure Service Bus ميزات قابلية الوصول العالية وتضمن أن فشل أحد المكونات الفردية للخدمة سيكون سلسًا للتطبيق لديك. يعد استخدام خدمات النظام الأساسي كخدمة PaaS إحدى أفضل الطرق لضمان توفر البنية بدرجة كبيرة.

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

اختبر معلوماتك

1.

تمثل اتفاقية على مستوى الخدمة «SLA» أهمية بالغة القدر لتحديد خدمتك للأسباب التالية:

2.

أي مما يلي لا يُستخدم في بنية عالية التوفر؟