Azure Availability Zones

  • 7 دقائق

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

تمكنك Azure Availability Zone من تحديد مواقع فعلية فريدة داخل منطقة ما. تتكون كل منطقة من مركز بيانات واحد أو أكثر مزود بمصدر طاقة وتبريد وشبكات مستقلة. اعتباراً من بنية SAP NetWeaver أو S/4HANA النموذجية، تحتاج إلى حماية ثلاث طبقات مختلفة:

  • طبقة تطبيق SAP، والتي يمكن أن تكون واحدة إلى بضع عشرات من الأجهزة الظاهرية. تريد تقليل فرصة الحصول على توزيع الأجهزة الظاهرية على نفس الخادم المضيف. كما تريد أن تحتفظ هذه الأجهزة ضمن القرب المقبول من طبقة نظام إدارة قواعد البيانات بفترة زمن انتقال الشبكة في إطار مقبول.
  • طبقة SAP ASCS/SCS التي تمثل نقطة فشل واحدة في بنية SAP NetWeaver وS/4HANA. عادة ما تنظر إلى اثنين من الأجهزة الظاهرية التي تريد تغطيتها بإطار تجاوز الفشل. لذلك، يجب تخصيص هذه الأجهزة الظاهرية في مجالات مختلفة لأعطال البنية الأساسية وتحديثها.
  • طبقة SAP DBMS، والتي تمثل نقطة فشل واحدة أيضاً. في الحالات المعتادة، يتكون من اثنين من الأجهزة الظاهرية التي يغطيها إطار تجاوز الفشل. لذلك، يجب تخصيص هذه الأجهزة الظاهرية في مجالات مختلفة لأعطال البنية الأساسية وتحديثها. الاستثناءات هي عمليات نشر مقياسHANA SAP حيث يمكن استخدام أكثر من جهازين ظاهريين.

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

  • ما هي متطلبات التوفر؟
  • ما هو مقدار وقت التعطّل المقبول؟
  • كم سيكلف وقت التعطّل المحتمل لـ نشاطك التجاري؟
  • كم المبلغ اللازم استثماره لجعل التطبيق ذات قابلية توفر عالية؟
  • ما هي متطلبات النسخ الاحتياطي للبيانات؟
  • ما هي متطلبات نسخ البيانات؟
  • ما هي متطلبات المراقبة؟
  • هل يحتوي تطبيقك على متطلبات زمن انتقال محددة؟

اعتبارات اتخاذ قرار باستخدام مناطق التوفر:

  • لا توجد ضمانات فيما يتعلق بالمسافات بين مناطق التوفر المختلفة داخل منطقة Azure.

  • مناطق التوفر ليست حلا مثاليا للتعافي من الكوارث. ويمكن أن تتسبب الكوارث الطبيعية في أضرار واسعة النطاق في مناطق العالم، بما في ذلك إلحاق أضرار جسيمة بالبنية الأساسية للطاقة. قد لا تكون المسافات بين مناطق مختلفة كبيرة بما يكفي لتشكل حلاً مناسباً لـ DR.

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

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

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

عند نشر الأجهزة الظاهرية لـ Azure عبر مناطق التوفر وإنشاء حلول تجاوز الفشل ضمن نفس المنطقة Azure، يتم تطبيق بعض القيود:

  • يجب استخدام الأقراص المدارة لـ Azure عند التوزيع إلى مناطق توفر Azure.
  • يتم إصلاح تعيين قائمة تعدادات المنطقة إلى المناطق الفعلية على أساس اشتراك Azure. إذا كنت تستخدم اشتراكات مختلفة لنشر أنظمة SAP، فستحتاج إلى تحديد المناطق المثالية لكل اشتراك.
  • لا يمكنك نشر مجموعات توفر Azure ضمن منطقة توفر Azure. اختر هذا أو ذاك باعتباره إطار عمل نشر للأجهزة الظاهرية.
  • لا يمكنك استخدام موازنة تحميل Azure Basic لإنشاء حلول شبكة نظام مجموعة تجاوز الفشل استناداً إلى Windows Server Failover Clustering أو Linux Pacemaker. بدلاً من ذلك، تحتاج إلى استخدام موازنة التحميل القياسي لوحدة حفظ المخزون في Azure.