تحرير

سيناريوهات قابلية الوصول العالية والإصلاح بعد الكوارث في تطبيقات IaaS

Azure Site Recovery
Azure Virtual Machines
Azure Disk Storage

تعرض هذه المقالة شجرة قرارات وأمثلة على خيارات قابلية الوصول العالية (HA) والإصلاح بعد كارثة (DR) عند نشر تطبيقات البنية الأساسية كخدمة (IaaS) مُتعددة التلميحات إلى Azure.

بناء الأنظمة

يوضح هذا الرسم التخطيطي شجرة قرارات قابلية الوصول العالية.

‏‏سير العمل‬

تُوفر مجموعات التوفر (ASs) تكرار الجهاز الظاهري وتوافره داخل مركز البيانات عن طريق توزيع الأجهزة الظاهرية عبر عقد أجهزة معزولة متعددة. وتستمر مجموعة فرعية من الأجهزة الظاهرية في العمل أثناء وقت التعطل المُخطط له أو غير المُخطط له، لذلك يظل التطبيق بأكمله متوفرًا وعاملًا.

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

يعكس المُخطط الانسيابي للقرار مبدأ أن تطبيقات قابلية الوصول العالية يجب أن تستخدم مناطق التوفر إذا كان ذلك ممكنًا. عبر المناطق، وبالتالي عبر مراكز البيانات، توفر قابلية الوصول العالية > 99.99٪ من اتفاقية مستوى الخدمة بسبب المرونة في فشل مركز البيانات.

لا يُضمن وجود مجموعات التوفر ومناطق التوفر لمستويات التطبيقات المختلفة داخل مراكز البيانات نفسها. في حال كان زمن انتقال التطبيق مصدر قلق أساسي، فيجب عليك تجميع الخدمات في مركز بيانات واحد باستخدام مجموعات وضع التقارب (PPGs) مع مناطق التوفر ومجموعات التوفر.

المكونات

البدائل

  • كبديل للإصلاح بعد الكارثة الإقليمية باستخدام Azure Site Recovery، إذا كان التطبيق يمكنه نسخ البيانات نسخًا متماثلًا محليًا، يمكنك تنفيذ الإصلاح بعد كارثة متعدد المناطق باستخدام خوادم الاستعداد الساخنة/الباردة، مثل نظام مجموعة ممتدة لإصلاح بعد كارثة فقط. هذا البديل غير مُفصل على وجه التحديد في الأمثلة، ولكن يمكن إضافته إلى أي من الحلول. لاحظ أن النسخ المتماثل بين المناطق غير مُتزامن، ومن المتوقع فقدان بعض البيانات.

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

  • قابلية الوصول العالية مُتعددة المناطق مُمكنة، ولكنها تتطلب موازن تحميل عمومي مثل Front Door أو Traffic Manager. لمزيد من المعلومات، راجع تشغيل تطبيق من المستوى N في مناطق Azure مُتعددة لتوفير قابلية وصول عالية.

تفاصيل السيناريو

تُعد البنيات مُتعددة المستويات أو ذات مستوي N شائعة في التطبيقات المحلية التقليدية، لذلك فهي خيار طبيعي لترحيل التطبيقات المحلية إلى السحابة، أو عند تطوير تطبيقات لكل من التطبيقات المحلية والسحابة. عادةً ما يتم تنفيذ بنيات الطبقة N كتطبيقات IaaS مُقسمة إلى طبقات منطقية وطبقات فعلية، مع أعلى مستوى ويب أو عرض تقديمي، وطبقة أعمال متوسطة، وطبقة بيانات.

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

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

إذا كانت الاتفاقية علي مستوى الخدمة (SLA) لتطبيق IaaS تتطلب > توفرًا بنسبة 99٪، يمكنك وضع الأجهزة الظاهرية في مجموعات التوفر و مناطق التوفر و مجموعات موضع التقارب لتكوين قابلية وصول عالية للتطبيق. تعتمد حلول قابلية الوصول العالية والإصلاح بعد كارثة التي تختارها على اتفاقية على مستوى الخدمة المطلوبة واعتبارات زمن الانتقال ومتطلبات الإصلاح بعد كارثة الإقليمية.

حالات الاستخدام المحتملة

  • ترحيل تطبيق من المستوى N من الموقع المحلي إلى السحابة.
  • انشر تطبيقًا من مستوي N محليا وإلى السحابة.
  • تكوين قابلية الوصول العالية والإصلاح بعد كارثة لتطبيق IaaS.

يمكن استخدام هذا الحل لأي صناعة، بما في ذلك السيناريوهات التالية:

  • تطبيقات القطاع العام
  • الخدمات المصرفية (صناعة التمويل)
  • الرعاية الصحية

الاعتبارات

  • لا تتوفر مناطق التوفر في جميع مناطق Azure.

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

  • تأكد من أنه يمكنك تعيين التطبيق الخاص بك مُقابل الحل المحدد. تقع العديد من أنماط ومرونة طبقة التطبيق والتصميمات خارجَ نطاق شجرة القرار هذه.

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

أجهزة ظاهرية مفردة

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

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

التوافر العالي

في حال كان التطبيق يتطلب اتفاقية مستوى الخدمة بنسبة > 99.9٪، فصمم التطبيق لقابلية الوصول العالية. استخدم مناطق التوفر إذا كان ذلك ممكنًا، لأنها توفر التسامح مع خطأ مركز البيانات. يمكنك استخدام مجموعات التوفر بدلًا من مناطق التوفر، ولكن استخدام مجموعات التوفر يقلل من التوفر من 99.99٪ إلى 99.95٪، لأن مجموعات التوفر لا يمكن أن تتسامح مع فشل مركز البيانات.

تعد مناطق التوفر مناسبة للعديد من سيناريوهات التطبيقات المُجمعة، بما في ذلك مجموعات AlwaysOn SQL، باستخدام active-active أو active-passive أو مزيج من كلا مستويي قابلية الوصول العالية في كل طبقة مع تجاوز الفشل السريع. النسخ المُتماثل المتزامن ممكن بين أي عُقد لنظام إدارة قواعد البيانات (DBMS)، بسبب زمن الانتقال المنخفض للشبكة عبر المناطق. بإمكانك أيضًا تشغيل تكوين نظام مجموعة مُمتد عبر المناطق، والذي يحتوي على زمن انتقال أعلى ويدعم النسخ المتماثل غير المتزامن.

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

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

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

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

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

اعتبارات زمن الانتِقال

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

بإمكانك استخدام الأدوات التالية للحصول على رؤية أفضل لظروف زمن الانتقال لمجموعة متنوعة من السيناريوهات:

  • لاختبار زمن الانتقال بين الأجهزة الظاهرية، راجع اختبار زمن انتقال شبكة الجِهاز الظاهري.
  • لاختبار زمن الانتقال بين المناطق، قم باستخدام AvZone-Latency-Test. يُمكن أن يساعدك هذا الاختبار في تحديد المناطق المنطقية التي لديها أقل زمن انتقال لاشتراكك.
  • لاختبار زمن الانِتقال بين مناطق Azure، استخدم http://www.azurespeed.com/. يُمكن أن تكون هذه الأداة المحدثة بانتظام مفيدة عند النظر في النسخ المُتماثل غير المتزامن بين المناطق.

التعافي من الكوارث

تتضمن اعتبارات الإصلاح بعد كارثة التوفر، وقدرة التطبيق على الاستمرار في العمل في حالة صحية، وقدرة البيانات على الصمود، والحفاظ على البيانات في حالة حدوث كارثة.

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

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

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

في حال كان تطبيقك يدعم Azure Site Recovery، يمكنك توفير حل إقليمي للإصلاح بعد كارثة لزيادة الحماية، إذا كانت أهمية التطبيق تتطلب ذلك. ومع ذلك، قد تكون قابلية الوصول العالية عبر المناطق عبر مراكز البيانات وحدها حماية كافية، لأنه إذا كان التطبيق مرنا تماما لفشل مركز البيانات، فلا ينبغي أن يكون هناك وقت تعطل أو فقدان للبيانات.

تحسين التكلفة

لا توجد تكلفة إضافية للأجهزة الظاهرية المنشورة في مناطق التوفر. قد تكون هناك رسوم إضافية لنقل البيانات بين AZ VM-to-VM. لمزيد من المعلومات، راجع تفاصيل أسعار النطاق الترددي.

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكاتب الرئيسي:

الخطوات التالية