فحص قدرات قابلية الوصول العالية للبنية الأساسية لـ Azure

  • 10 دقائق

تنطبق المبادئ التالية على توفير أقصى قدر من قابلية الوصول العالية من نظامSAP NetWeaver في Azure:

  • يتم نشر النظام الكامل على Azure (مطلوب - مثيل طبقة نظام إدارة قواعد البيانات، (A) SCS وطبقة التطبيق الكامل تحتاج إلى تشغيل في نفس الموقع).
  • يعمل النظام الكامل ضمن اشتراك Azure أحادي (مطلوب).
  • يعمل النظام الكامل ضمن الشبكة الظاهرية الأحادية لـ Azure (مطلوب).
  • يجب أن تستخدم كل طبقة (على سبيل المثال نظام إدارة قواعد البيانات وASCS وخوادم التطبيق) مجموعة قابلية توفّر مخصصة.
  • جميع الأجهزة الظاهرية التي تقوم بتشغيل مثيلات نظام إدارة قواعد البيانات لنظام SAP الأحادي موجودة في مجموعة توافر واحدة. تسمح ميزات التوافر العالية لنظام إدارة قاعدة البيانات الأصلية، مثلSQL Server Always On أو Oracle Data Guard، بتشغيل أكثر من جهاز ظاهري واحد يستضيف نظام إدارة قواعد البيانات لكل نظام.
  • تستخدم كافة الأجهزة الظاهرية الأقراص المدارة.
  • يتم نسخ بيانات نظام إدارة قواعد البيانات وملفات السجل باستخدام وظائف قابلية وصول نظام إدارة قواعد البيانات العالية التي تزامن البيانات.
  • (أ) يتم تخزين ملفات مثيل SCS ومجلد SAP العام إما على مشاركة ملف عالي التوفر أو يتم نسخها بشكل متزامن بين قرصين من الأجهزة الظاهرية لـ Azure اللذين يشكّلان جزءاً من نفس مجموعة التوفّر (على سبيل المثال، باستخدام SIOS DataKeeper).

خيارات قابلية الوصول العالية للأجهزة الظاهرية لـ Azure

يجب مراعاة قابلية الوصول العالية من الأجهزة الظاهرية لـ Azure في السيناريوهات الرئيسية الثلاثة التالية:

  • جهاز Azure الظاهري الأحادي (وقت تشغيل اتفاقية مستوى الخدمة هو 99.9%)
  • جهازان أو أكثر من الأجهزة الظاهرية في نفس مجموعة التوافر (ذات وقت تشغيل يساوي 99.95%)
  • جهازان أو أكثر من الأجهزة الظاهرية في مناطق توفّر مختلفة في نفس منطقة Azure (وقت تشغيل 99.99%)

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

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

يمكن استخدام مجموعات التوفر في السيناريوهات التالية في أنظمة SAP:

  • بنية قابلية الوصول العالية لخوادم تطبيقات SAP
  • بنية عالية التوفر لمثيل SAP ASCS/SCS على Windows وLinux
  • قابلية الوصول العالية لمثيلات نظام إدارة قواعد البيانات

الاعتبارات أثناء إعداد مجموعة التوفر:

  • يتم تعيين مجال تحديث ومجال خطأ لكل جهاز ظاهري في مجموعة توفّر من قِبل النظام الأساسي لـ Azure.
  • يمكن أن تحتوي كل مجموعات توفر على مجالين أو ثلاثة مجالات خطأ؛ تعرف على وقت استخدام كل منها (مطابقة مخطط التطبيق الخاص بك). و 20 مجال تحديث.
  • عند تكوين أكثر من خمسة أجهزة ظاهرية ضمن مجموعة توفر واحدة، يتم وضع الجهاز الظاهري السادس في نفس مجال التحديث مثل الجهاز الظاهري الأول. يتم وضع الجهاز الظاهري السابع في نفس مجال التحديث مثل الجهاز الظاهري الثاني، وهكذا.
  • يتم أيضاً محاذاة الأجهزة الظاهرية مع مجالات أخطاء القرص. تضمن هذه المحاذاة أن كافة الأقراص المدارة المرفقة بالجهاز الظاهري ضمن نفس مجالات الخطأ.
  • تعرف على الفرق في اتفاقية مستوى الخدمة بين شبكة نظام مجموعة التوفر، وشبكة نظام مجموعة عدم التوفّر، ومناطق التوفر.
  • تأكد من فهم التفاعل مع مجموعات تحديد موضع القرب.

سيناريو جهاز ظاهري أحادي

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

  • إعادة تشغيل جهاز Azure الظاهري تلقائيا (يشار إليه أيضا باسم شفاء خدمة Azure)
  • إعادة تشغيل SAP التلقائية

إعادة تشغيل تلقائي للجهاز الظاهري لـ Azure أو معالجة خدمة وظيفة في Azure يعمل على مستويين:

  • يتحقق مضيف الخادم من صحة الأجهزة الظاهرية المضافة الخاصة بك.
  • تراقب جهاز تحكم تصميم Azure صحة وتوافر مضيف الخادم.

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

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

مع مراقبة المضيف والجهاز الظاهري الذي يوفره Azure، تتم إعادة تشغيل الأجهزة الظاهرية لـ Azure التي تواجه مشكلات المضيف تلقائياّ على مضيف Azure سليم.

لن يعيد شفاء خدمة Azure تشغيل أجهزة Linux الظاهرية حيث يكون نظام التشغيل الضيف في حالة ذعر kernel. بدلاً من ذلك، يحتفظ Azure بنظام التشغيل في حالة اضطراب kernel للسماح بإرفاق مصحح الأخطاء kernel للتحليل. الافتراض هو أن مثل هذه التكرارات نادرة. يمكنك الكتابة فوق السلوك الافتراضي لتمكين إعادة تشغيل الجهاز الظاهري. لتغيير السلوك الافتراضي يمكنك تمكين المعلمة 'kernel.panic' في /etc/sysctl.conf. الوقت الذي قمت بتعيينه لهذه المعلمة بالثواني. القيم الشائعة الموصَى بها هي الانتظار لمدة 20-30 ثانية قبل البدء في إعادة التحميل. لمزيد من المعلومات، راجع https://gitlab.com/procps-ng/procps/blob/master/sysctl.conf

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

التشغيل التلقائي لـ SAP

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

بالإضافة إلى ذلك، بينما تقوم المعلمة بتشغيل بدء مثيل SAP ABAP أو Java عند بدء تشغيل خدمة Windows/ Linux ذات الصلة للمثيل، هناك سيناريوهات يجب تجنب إعادة التشغيل التلقائي فيها. على سبيل المثال، إعادة تشغيل خدمات SAP شائعة عند استخدام ميزات إدارة دورة حياة برامج SAP مثل SUM أو أثناء التحديثات والترقيات. في هذه السيناريوهات، يمكن أن تكون إعادة التشغيل معطلة. يجب أيضاً ألا يتم استخدام المعلمة Autostart لمثيلات SAP الموجودة بها.