استخدام إعادة تشغيل الجهاز الظاهري لبنية Azure الأساسية لتحقيق "توفر أعلى" لنظام SAP
ينطبق هذا القسم على:
Windows وLinux
إذا قررت عدم استخدام وظائف مثل تجميع تجاوز فشل خادم Windows (WSFC) أو Pacemaker على Linux (مدعوم حاليًا فقط لـSUSE Linux Enterprise Server [SLES] 12 والإصدارات الأحدث)، استخدام إعادة تشغيل جهاز Azure الظاهري. فهو يحمي أنظمة SAP من وقت التوقف المخطط وغير المخطط له للبنية التحتية لخادم Azure الفعلي والنظام الأساسي المصدر لـAzure بشكل عام.
إشعار
تحمي إعادة تشغيل أجهزة Azure الظاهرية الأجهزة الظاهرية بشكل أساسي وليس التطبيقات. على الرغم من أن إعادة تشغيل الأجهزة الظاهرية لا توفر توافرًا عاليًا لتطبيقات SAP، إلا أنها توفر مستوى معينًا من توفر البنية التحتية. كما أنه يوفر بشكل غير مباشر "توافرًا أعلى" لأنظمة SAP. لا توجد أيضاً اتفاقية مستوى الخدمة للوقت الذي يستغرقه إعادة تشغيل جهاز ظاهري بعد انقطاع المضيف المخطط له أو غير المخطط له، مما يجعل طريقة التوافر العالي هذه غير مناسبة للمكونات المهمة لنظام SAP. قد تكون أمثلة المكونات الهامة مثيل ASCS/SCS أو نظام إدارة قاعدة بيانات (DBMS).
عنصر آخر مهم في البنية التحتية للتوافر العالي هو التخزين. على سبيل المثال، تتوفر اتفاقية مستوى الخدمة لتخزين Azure بنسبة 99.9٪. إذا قمت بنشر كافة الأجهزة الظاهرية وأقراصها في حساب تخزين Azure واحد، فإن عدم توفر Azure Storage المحتمل سيؤدي إلى عدم توفر كافة الأجهزة الظاهرية التي يتم وضعها في حساب التخزين هذا وجميع مكونات SAP التي تعمل داخل الأجهزة الظاهرية.
بدلاً من وضع جميع الأجهزة الظاهرية في حساب تخزين Azure واحد، يمكنك استخدام حسابات تخزين مخصصة لكل جهاز ظاهري. باستخدام حسابات تخزين Azure مستقلة متعددة، يمكنك زيادة إجمالي توفر تطبيقات الأجهزة الظاهرية وSAP.
يتم وضع الأقراص المدارة بواسطة Azure تلقائيا في مجال الخطأ الخاص بالجهاز الظاهري المرفق بها. إذا وضعت جهازين ظاهريين في مجموعة توفر واستخدمت الأقراص المدارة، فإن النظام الأساسي يعتني بتوزيع الأقراص المدارة في مجالات خطأ مختلفة أيضاً. إذا كنت تخطط لاستخدام حساب تخزين متميز، فإننا نوصي بشدة باستخدام الأقراص المدارة.
قد تبدو بنية نموذجية لنظام SAP NetWeaver يستخدم حسابات التوفر والتخزين العالية للبنية الأساسية لـAzure كما يلي:
قد تبدو بنية نموذجية لنظام SAP NetWeaver يستخدم حسابات التوفر العالي والأقراص المدارة للبنية الأساسية لـAzure كما يلي:
بالنسبة لمكونات SAP المهمة، فقد حققت ما يلي حتى الآن:
قابلية التوافر العالية لخوادم تطبيق SAP.
مثيلات خادم تطبيقات SAP هي مكونات زائدة عن الحاجة. يتم نشر كل مثيل خادم تطبيق SAP على الجهاز الظاهري الخاص به، والذي يعمل في مجال خطأ وترقية Azure مختلفين. لمزيد من المعلومات، راجع قسمي مجالات الخطأ وتحديث المجالات .
يمكنك التأكد من هذا التكوين باستخدام مجموعات توفر Azure. لمزيد من المعلومات، راجع قسم مجموعات توفر Azure.
سيؤدي عدم التوفر المحتمل المخطط له أو غير المخطط له لخطأ Azure أو مجال الترقية إلى عدم توفر عدد محدود من الأجهزة الظاهرية مع مثيلات خادم تطبيق SAP الخاصة بهم.
يتم وضع كل مثيل خادم تطبيق SAP في حساب تخزين Azure الخاص به. سيؤدي عدم توفر حساب تخزين Azure واحد المحتمل إلى عدم توفر جهاز ظاهري واحد فقط مع مثيل خادم تطبيق SAP الخاص به. ومع ذلك، يجب أن تدرك أن هناك حدًا لعدد حسابات تخزين Azure ضمن اشتراك Azure واحد. لضمان البدء التلقائي لمثيل ASCS/SCS بعد إعادة تشغيل الجهاز الظاهري، قم بتعيين معلمة التشغيل التلقائي في ملف تعريف بدء مثيل ASCS/SCS.
لمزيد من المعلومات، راجع التوفر العالي لخوادم تطبيقات SAP.
حتى إذا كنت تستخدم الأقراص المدارة، يتم تخزين الأقراص في حساب تخزين Azure وقد تكون غير متوفرة في حالة انقطاع التخزين.
توفر أعلى لمثيلات SAP ASCS/SCS
في هذا السيناريو، استخدم إعادة تشغيل أجهزة Azure الظاهرية لحماية الجهاز الظاهري باستخدام مثيل SAP ASCS/SCS المثبت. في حالة التوقف المخطط له أو غير المخطط له لخوادم Azure، تتم إعادة تشغيل الأجهزة الظاهرية على خادم آخر متوفر. كما ذكرنا سابقًا، فإن إعادة تشغيل أجهزة Azure الظاهرية تحمي في المقام الأول الأجهزة الظاهرية وليس التطبيقات، وفي هذه الحالة مثيل ASCS/SCS. من خلال إعادة تشغيل الجهاز الظاهري، يمكنك الوصول بشكل غير مباشر إلى "توفر أعلى" لمثيل SAP ASCS/SCS.
لضمان البدء التلقائي لمثيل ASCS/SCS بعد إعادة تشغيل الجهاز الظاهري، قم بتعيين معلمة التشغيل التلقائي في ملف تعريف بدء مثيل ASCS/SCS. يعني هذا الإعداد أن مثيل ASCS/SCS كنقطة فشل واحدة (SPOF) قيد التشغيل في جهاز ظاهري واحد سيحدد مدى توفر مشهد SAP بأكمله.
توفر أعلى لخادم DBMS
كما هو الحال في حالة استخدام مثيل SAP ASCS/SCS السابقة، يمكنك استخدام إعادة تشغيل أجهزة Azure الظاهرية لحماية الجهاز الظاهري باستخدام برنامج DBMS المثبت، وتحقيق "توفر أعلى" لبرنامج DBMS من خلال إعادة تشغيل الجهاز الظاهري.
نظام إدارة قواعد البيانات الذي يعمل في جهاز ظاهري واحد هو أيضاً SPOF، وهو العامل الحاسم لتوفر مشهد SAP بأكمله.
استخدام التشغيل التلقائي لمثيلات SAP
يوفر SAP إعداداً يتيح لك بدء تشغيل مثيلات SAP مباشرة بعد بدء تشغيل نظام التشغيل داخل الجهاز الظاهري. يتم توثيق الإرشادات في مقالة قاعدة معارف SAP 1909114. ومع ذلك، لم يعد SAP يوصي باستخدام الإعداد، لأنه لا يسمح بالتحكم في ترتيب إعادة تشغيل المثيل في حالة تأثر أكثر من جهاز ظاهري واحد أو في حالة تشغيل مثيلات متعددة لكل جهاز ظاهري.
بافتراض سيناريو Azure نموذجي لمثيل خادم تطبيق SAP واحد في جهاز ظاهري وجهاز ظاهري واحد يتم إعادة تشغيله في النهاية، فإن التشغيل التلقائي ليس حرجاً. ولكن يمكنك تمكينه عن طريق إضافة المعلمة التالية إلى ملف تعريف البدء الخاص ببرمجة تطبيقات الأعمال المتقدمة SAP (ABAP) أو مثيل Java:
Autostart = 1
إشعار
تحتوي معلمة التشغيل التلقائي على بعض أوجه القصور أيضاً. وبوجه خاص، المعلمة بتشغيل بدء مثيل ABAP أو Java SAP عند بدء تشغيل Windows أو خدمة Linux ذات الصلة من المثيل. يحدث هذا التسلسل عند تشغيل نظام التشغيل. ومع ذلك، تعد عمليات إعادة تشغيل خدمات SAP أيضاً أمراً شائعاً لوظيفة إدارة دورة حياة برامج SAP مثل مدير تحديث البرامج (SUM) أو التحديثات أو الترقيات الأخرى. لا تتوقع هذه الوظائف إعادة تشغيل مثيل تلقائياً. لذلك، يجب تعطيل معلمة "التشغيل التلقائي" قبل تشغيل هذه المهام. يجب أيضاً ألا يتم استخدام المعلمة Autostart لمثيلات SAP الموجودة بها، مثل ASCS/SCS/CI.
لمزيد من المعلومات حول التشغيل التلقائي لمثيلات SAP، راجع المقالات التالية:
الخطوات التالية
للحصول على معلومات حول التوافر العالي الكامل لتطبيق SAP NetWeaver، راجع التوفر العالي لتطبيق SAP على Azure IaaS.