مشاركة عبر

تكوينات حمل عمل SAP مع مناطق توافر الخدمات في Azure

  • مقالة

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

اعتباراً من بنية SAP NetWeaver أو S/4HANA النموذجية، تحتاج إلى حماية ثلاث طبقات مختلفة:

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

الاختلافات الرئيسية بين نشر الأجهزة الظاهرية الهامة الخاصة بك من خلال مجموعات توافر الخدمات أو مناطق توافر الخدمات هي:

  • النشر باستخدام مجموعة توفر هو اصطفاف الأجهزة الظاهرية داخل المجموعة في منطقة واحدة أو مركز بيانات واحد (أيًا كان ما ينطبق على المنطقة المحددة). ونتيجة لذلك، لا تتم حماية التوزيع من خلال مجموعة التوفر من خلال مشكلات الطاقة أو التبريد أو الشبكات التي تؤثر على dataceter (قواعد) المنطقة ككل. على الجانب الإيجابي، تتم محاذاة الأجهزة الظاهرية مع مجالات التحديث والخطأ داخل تلك المنطقة أو مركز البيانات. خصيصا لطبقة SAP ASCS أو DBMS حيث نحمي جهازين ظاهريين لكل مجموعة توفر، تمنع المحاذاة مع مجالات الخطأ أن ينتهي الأمر بكلا الجهازين الظاهريين على نفس الجهاز المضيف.
  • عند نشر الأجهزة الظاهرية من خلال مناطق توفر Azure واختيار مناطق مختلفة (ثلاث مناطق ممكنة كحد أقصى)، ستقوم بنشر الأجهزة الظاهرية عبر المواقع المادية المختلفة ومع ذلك يضيف الحماية من مشكلات الطاقة أو التبريد أو الشبكات التي تؤثر على dataceter(s) للمنطقة ككل. ومع ذلك، عند نشر أكثر من جهاز ظاهري واحد من نفس عائلة الجهاز الظاهري في نفس منطقة التوفر، لا توجد حماية من تلك الأجهزة الظاهرية التي ينتهي بها الأمر على نفس المضيف أو نفس مجال الخطأ. ونتيجة لذلك، يعد النشر من خلال مناطق توافر الخدمات مثاليا لطبقة SAP ASCS وDBMS حيث ننظر عادة إلى جهازين ظاهريين لكل منهما. بالنسبة لطبقة تطبيق SAP، والتي يمكن أن تكون أكثر من جهازين ظاهريين بشكل كبير، قد تحتاج إلى العودة إلى نموذج نشر مختلف (انظر لاحقا)

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

كوظيفة توزيع مرونة أخرى، قدم Azure مجموعات مقياس الجهاز الظاهري مع تزامن مرن لحمل عمل SAP. توفر مجموعة مقياس الجهاز الظاهري تجميعا منطقيا للأجهزة الظاهرية المدارة بواسطة النظام الأساسي. يوفر التنسيق المرن لمجموعة مقياس الجهاز الظاهري خيار إنشاء مجموعة المقياس داخل منطقة أو توسيعها عبر مناطق التوفر. عند الإنشاء، سيتم توزيع مجموعة المقياس المرنة داخل منطقة مع platformFaultDomainCount>1 (FD>1)، سيتم توزيع الأجهزة الظاهرية المنشورة في مجموعة المقياس عبر عدد محدد من مجالات الخطأ في نفس المنطقة. من ناحية أخرى، سيؤدي إنشاء مجموعة التحجيم المرنة عبر مناطق التوفر باستخدام platformFaultDomainCount=1 (FD=1) إلى توزيع الأجهزة الظاهرية عبر مناطق مختلفة وستوزع مجموعة التحجيم أيضا الأجهزة الظاهرية عبر مجالات خطأ مختلفة داخل كل منطقة على أساس أفضل جهد. بالنسبة إلى حمل عمل SAP، يتم دعم مجموعة التحجيم المرنة فقط مع FD=1. تتمثل ميزة استخدام مجموعات التحجيم المرنة مع FD=1 للتوزيع عبر المناطق، بدلا من توزيع منطقة التوفر التقليدية في توزيع الأجهزة الظاهرية المنشورة مع مجموعة المقياس عبر مجالات خطأ مختلفة داخل المنطقة بأفضل جهد. لمزيد من المعلومات، راجع دليل توزيع مجموعة المقياس المرنة لحمل عمل SAP.

اعتبارات النشر عبر مناطق توافر الخدمات

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

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

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

المزيج المثالي لمناطق توافر الخدمات

إذا كنت ترغب في نشر نظام SAP NetWeaver أو S/4HANA عبر المناطق، فهناك نمطان للبنية يمكنك توزيعهما:

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

لذلك قبل أن تقرر كيفية استخدام مناطق التوفر، تحتاج إلى تحديد:

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

زمن انتقال الشبكة بين المناطق وداخلها

لتحديد زمن الانتقال بين المناطق المختلفة، تحتاج إلى:

  • توزيع الأجهزة الظاهرية لوحدات حفظ المخزن الذي تريد استخدامه لمثيل نظام إدارة قواعد البيانات في كافة المناطق الثلاث. تأكد من تمكينAzure تسريع الشبكات عند إجراء هذا القياس. الشبكات المتسارعة هي الإعداد الافتراضي منذ بضع سنوات. ومع ذلك، تحقق مما إذا كان ممكنا ويعمل
  • عند العثور على المنطقتين مع زمن انتقال الشبكة الأقل، نشر آخر ثلاثة أجهزة ظاهرية من الأجهزة الظاهرية لوحدات حفظ المخزون التي تريد استخدامها كطبقة برامج الأجهزة الظاهرية عبر مناطق التوفر الثلاثة. قياس زمن انتقال الشبكة مقابل الأجهزة الظاهرية لوحدات حفظ المخزون بعدد اثنين في مناطق حفظ المخزون التي حددتها.
  • استخدام nipingكأداة قياس. هذه الأداة، من SAP، موصوفة في ملاحظات دعم SAP #500235و#1100926. التركيز على الأوامر الموثّقة لقياسات زمن الانتقال. نظرًا لأن ping لا يعمل من خلال مسارات التعليمات البرمجية لـAzure Accelerated Network، فإننا لا نوصي باستخدامه.

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

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

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

عند اتخاذ هذه القرارات، يمكنك أيضًا النظر في توصيات زمن انتقال شبكة SAP، كما هو موثق في SAP note #1100926.

هام

القياسات والقرارات التي تتخذها صالحة للاشتراك Azure الذي استخدمته عند أخذ القياسات. إذا كنت تستخدم اشتراك Azure آخر، فقد يختلف تعيين المناطق تعدادا لاشتراك Azure آخر. ونتيجة لذلك، تحتاج إلى تكرار القياسات أو معرفة تعيين الاشتراك الجديد realitve إلى الاشتراك القديم الأداة Avzone-Mapping script.

هام

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

النشر النشط/الفعال

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

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

مناطق Azure حيث يمكن أن يكون مثل هذا النشر النشط/النشط ممكنا دون اختلافات كبيرة في وقت التشغيل ومعدل النقل داخل طبقة التطبيق المنشورة عبر مناطق توفر مختلفة، قائمة مثل:

  • شرق أستراليا (اثنتان من المناطق الثلاث)
  • جنوب البرازيل (جميع المناطق الثلاث)
  • وسط الهند (جميع المناطق الثلاث)
  • وسط الولايات المتحدة (جميع المناطق الثلاث)
  • شرق آسيا (جميع المناطق الثلاث)
  • شرق الولايات المتحدة (اثنتان من المناطق الثلاث)
  • شرق الولايات المتحدة 2 (جميع المناطق الثلاث)
  • وسط غرب ألمانيا (جميع المناطق الثلاث)
  • وسط إسرائيل (جميع المناطق الثلاث)
  • شمال إيطاليا (اثنتان من المناطق الثلاث)
  • كوريا الوسطى (جميع المناطق الثلاث)
  • بولندا الوسطى (جميع المناطق الثلاث)
  • قطر الوسطى (جميع المناطق الثلاث)
  • شمال أوروبا (المناطق الثلاث)
  • شرق النرويج (اثنتان من المناطق الثلاث)
  • جنوب أفريقيا شمال (اثنان من الثلاثة)
  • جنوب وسط الولايات المتحدة (جميع المناطق الثلاث)
  • جنوب شرق آسيا (جميع المناطق الثلاث)
  • وسط السويد (جميع المناطق الثلاث)
  • شمال سويسرا (جميع المناطق الثلاث)
  • شمال الإمارات العربية المتحدة (جميع المناطق الثلاث)
  • جنوب المملكة المتحدة (اثنتان من المناطق الثلاث)
  • غرب أوروبا (اثنتان من المناطق الثلاث)
  • غرب الولايات المتحدة 2 (جميع المناطق الثلاث)
  • غرب الولايات المتحدة3 (جميع المناطق الثلاث)

لا تريحك قائمة المناطق المقدمة كعميل لاختبار حمل العمل الخاص بك لتحديد ما إذا كان من الممكن إنشاء بنية توزيع نشطة/نشطة.

مناطق Azure حيث قد لا تكون بنية توزيع SAP النشطة/النشطة عبر المناطق ممكنة، قائمة مثل:

  • وسط كندا
  • وسط فرنسا
  • شرق اليابان

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

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

يمكن أن يبدو المخطط المبسط لنشر نشط/نشط عبر منطقتين كما يلي:

توزيع المنطقة النشطة/الفعالة

تنطبق الاعتبارات التالية لهذا التكوين:

  • لا تستخدم Azure Proximity Placement Group، فإنك تتعامل مع مناطق توفر Azure كمجالات خطأ لجميع الأجهزة الظاهرية لأنه لا يمكن نشر مجموعات التوفر في مناطق توفر Azure.
  • إذا كنت ترغب في دمج عمليات النشر المناطقية لطبقة نظام إدارة قواعد البيانات والخدمات المركزية، ولكنك تريد استخدام مجموعات توفر Azure لطبقة التطبيق، فستحتاج إلى استخدام مجموعات القرب Azure كما هو موضح في المقالة Azure Proximity Placement Groups للحصول على زمن انتقال الشبكة الأمثل مع تطبيقات SAP.
  • بالنسبة لموازنات التحميل لمجموعات تجاوز الفشل من SAP Central Services وطبقة نظام إدارة قواعد البيانات، تحتاج إلى استخدام موازنة تحميل وحدة حفظ المخزون الخاصة بـAzure القياسي. لن تعمل موازنة التحميل الأساسي عبر المناطق.
  • شبكة الاتصال الظاهرية لـ Azure التي قمت بنشرها لاستضافة نظام SAP، جنباً إلى جنب مع الشبكات الفرعية الخاصة به، يتم توسيع عبر المناطق. لا تحتاج إلى شبكات ظاهرية وشبكات فرعية منفصلة لكل منطقة.
  • بالنسبة لكافة الأجهزة الظاهرية التي تقوم بنشرها، تحتاج إلى استخدامالأقراص المُدارة لـAzure. الأقراص غير المدارة لا تدعم توزيع المناطق غير المعتمد.
  • لا يدعم تخزين Azure Premium أو تخزين Ultra SSD أو Azure NetApp Files أي نوع من النسخ المتماثل للتخزين عبر المناطق. بالنسبة إلى عمليات نشر DBMS، نعتمد على أساليب قاعدة البيانات لنسخ البيانات عبر المناطق
  • بالنسبة لمشاركات SMB وNFS استنادا إلى Azure Premium Files، يتم تقديم التكرار النطاقي مع النسخ المتماثل المتزامن. تحقق من هذا المستند لمعرفة مدى توفر ZRS ل Azure Premium Files في المنطقة التي تريد النشر فيها. يتم دعم استخدام مشاركات NFS وSMB المنسوخة عبر النطاق بشكل كامل مع عمليات نشر طبقة تطبيق SAP ومجموعات تجاوز الفشل عالية التوفر لخدمات NetWeaver أو S/4HANA المركزية. المستندات التي تغطي هذه الحالات هي:
  • يتم استخدام المنطقة الثالثة لاستضافة جهاز SBD إذا قمت بإنشاءمجموعة SUSE Linux Pacemaker واستخدام أجهزة SBD بدلًا من عامل المبارزة Azure. أو لمزيد من مثيلات التطبيق.
  • لتحقيق تناسق وقت التشغيل لعمليات العمل الهامة، يمكنك محاولة توجيه بعض مهام الدفعة والمستخدمين إلى مثيلات التطبيقات الموجودة في المنطقة مع مثيل DBMS النشط باستخدام مجموعات خادم دفعي SAP أو مجموعات تسجيل دخول SAP أو مجموعات RFC. ومع ذلك، في عملية تجاوز الفشل النطاقي، ستحتاج إلى نقل هذه المجموعات يدويا إلى مثيلات تعمل على الأجهزة الظاهرية الموجودة في المنطقة مع الجهاز الظاهري النشط DB.
  • قد تحتاج إلى نشر مثيلات حوار خاملة في كل منطقة من المناطق.

هام

في هذا السيناريو النشط/النشط، يتم تطبيق رسوم نسبة استخدام الشبكة عبر المناطق. تحقق من تفاصيل تسعير النطاق التردديللمستند. نقل البيانات بين طبقة تطبيق SAP وطبقة SAP DBMS مكثف للغاية. لذلك يمكن أن يساهم السيناريو النشط/النشط في التكاليف.

النشر النشط/ غير الفعال

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

مناطق Azure حيث يمكن أن يكون هذا النوع من بنية التوزيع عبر مناطق مختلفة مفضلة هي:

  • وسط كندا
  • وسط فرنسا
  • شرق اليابان
  • شرق النرويج
  • جنوب أفريقيا

يبدو التخطيط الأساسي للبنية كما يلي:

توزيع المنطقة النشط/غير الفعال

تنطبق الاعتبارات التالية لهذا التكوين:

  • لا يمكن نشر مجموعات التوفر في مناطق توفر Azure. للتخفيف من حدة ذلك، يمكنك استخدام مجموعات موضع تقارب Azure كما هو موثق في المقالة Azure Proximity Placement Groups للحصول على زمن انتقال مثالي للشبكة مع تطبيقات SAP.
  • عند استخدام هذه البنية، تحتاج إلى مراقبة الحالة عن قُرب ومحاولة الاحتفاظ بنظام إدارة قواعد البيانات النشطة وخدمات مثيلات الـ SAP المركزية في نفس المنطقة كطبقة التطبيق المُوزّعة. إذا كان هناك تجاوز فشل ل SAP Central Service أو مثيل DBMS، فأنت تريد التأكد من أنه يمكنك إرجاع الفشل يدويا إلى المنطقة مع نشر طبقة تطبيق SAP في أسرع وقت ممكن.
  • بالنسبة لموازنات التحميل لمجموعات تجاوز الفشل من SAP Central Services وطبقة نظام إدارة قواعد البيانات، تحتاج إلى استخدام موازنة تحميل وحدة حفظ المخزون الخاصة بـAzure القياسي. لن تعمل موازنة التحميل الأساسي عبر المناطق.
  • شبكة الاتصال الظاهرية لـ Azure التي قمت بنشرها لاستضافة نظام SAP، جنباً إلى جنب مع الشبكات الفرعية الخاصة به، يتم توسيع عبر المناطق. لا تحتاج إلى شبكات ظاهرية منفصلة لكل منطقة.
  • بالنسبة لكافة الأجهزة الظاهرية التي تقوم بنشرها، تحتاج إلى استخدامالأقراص المُدارة لـAzure. الأقراص غير المدارة لا تدعم توزيع المناطق غير المعتمد.
  • لا يدعم تخزين Azure Premium أو تخزين Ultra SSD أو Azure NetApp Files أي نوع من النسخ المتماثل للتخزين عبر المناطق. بالنسبة إلى عمليات نشر DBMS، نعتمد على أساليب قاعدة البيانات لنسخ البيانات عبر المناطق
  • بالنسبة لمشاركات SMB وNFS استنادا إلى Azure Premium Files، يتم تقديم التكرار النطاقي مع النسخ المتماثل المتزامن. تحقق من هذا المستند لمعرفة مدى توفر ZRS ل Azure Premium Files في المنطقة التي تريد النشر فيها. يتم دعم استخدام مشاركات NFS وSMB المنسوخة عبر النطاق بشكل كامل مع عمليات نشر طبقة تطبيق SAP ومجموعات تجاوز الفشل عالية التوفر لخدمات NetWeaver أو S/4HANA المركزية. المستندات التي تغطي هذه الحالات هي:
  • يتم استخدام المنطقة الثالثة لاستضافة جهاز SBD إذا قمت بإنشاءمجموعة SUSE Linux Pacemaker واستخدام أجهزة SBD بدلًا من عامل المبارزة Azure. أو لمثيلات التطبيق الإضافية.
  • يجب نشر الأجهزة الظاهرية لـdormant في المنطقة الخاملة (من وجهة نظر نظام إدارة قواعد البيانات) بحيث يمكنك بدء تشغيل موارد التطبيق في حالة فشل منطقة. يمكن أن تكون هناك إمكانية أخرى لاستخدام Azure Site Recovery، والذي يمكنه نسخ الأجهزة الظاهرية النشطة نسخا متماثلا إلى أجهزة ظاهرية غير نشطة بين المناطق.
  • يجب أن تستثمر في التشغيل الآلي الذي يسمح لك لبدء طبقة تطبيق SAP تلقائيًا في المنطقة الثانية إذا حدث انقطاع نطاقي.

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

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

إشعار

نوصي باستخدام تكوين مثل هذا فقط في ظروف معينة. على سبيل المثال، قد تستخدمها عندما لا تتمكن البيانات من مغادرة منطقة Azure لأسباب تتعلق بالأمان أو التوافق.

في ما يلي مثال واحد على كيفية ظهور هذا التكوين:

دمج الإصلاح بعد كارثة عالي التوفر في المناطق

تنطبق الاعتبارات التالية لهذا التكوين:

  • أنت إما تفترض أن هناك مسافة كبيرة بين المرافق التي تستضيف منطقة توفر أو أنك مجبر على البقاء داخل منطقة Azure معينة. لا يمكن نشر مجموعات التوفر في مناطق توفر Azure. للتعويض عن ذلك، يمكنك استخدام مجموعات مواضع القرب من Azure كما هو موثق في المقالة Azure Proximity Placement Groups للحصول على زمن انتقال الشبكة الأمثل مع تطبيقات SAP.
  • عند استخدام هذه البنية، تحتاج إلى مراقبة الحالة عن كثب، ومحاولة الاحتفاظ بمثيلات DBMS وSAP Central Services النشطة في نفس المنطقة مثل طبقة التطبيق المنشورة. إذا كان هناك تجاوز فشل ل SAP Central Service أو مثيل DBMS، فأنت تريد التأكد من أنه يمكنك إرجاع الفشل يدويا إلى المنطقة مع نشر طبقة تطبيق SAP في أسرع وقت ممكن.
  • يجب أن يكون لديك مثيلات تطبيق الإنتاج مثبتة مسبقا في الأجهزة الظاهرية التي تقوم بتشغيل مثيلات تطبيق QA النشطة.
  • في حالة الفشل النطاقي، قم بإيقاف تشغيل مثيلات التطبيق QA وبدء تشغيل مثيلات الإنتاج بدلا من ذلك. تحتاج إلى استخدام أسماء ظاهرية لمثيلات التطبيق لإنجاح هذا الأمر.
  • بالنسبة لموازنات التحميل لمجموعات تجاوز الفشل من SAP Central Services وطبقة نظام إدارة قواعد البيانات، تحتاج إلى استخدام موازنة تحميل وحدة حفظ المخزون الخاصة بـAzure القياسي. لن تعمل موازنة التحميل الأساسي عبر المناطق.
  • شبكة الاتصال الظاهرية لـ Azure التي قمت بنشرها لاستضافة نظام SAP، جنباً إلى جنب مع الشبكات الفرعية الخاصة به، يتم توسيع عبر المناطق. لا تحتاج إلى شبكات ظاهرية منفصلة لكل منطقة.
  • بالنسبة لكافة الأجهزة الظاهرية التي تقوم بنشرها، تحتاج إلى استخدامالأقراص المُدارة لـAzure. الأقراص غير المدارة لا تدعم توزيع المناطق غير المعتمد.
  • لا يدعم تخزين Azure Premium أو تخزين Ultra SSD أو Azure NetApp Files أي نوع من النسخ المتماثل للتخزين عبر المناطق. بالنسبة إلى عمليات نشر DBMS، نعتمد على أساليب قاعدة البيانات لنسخ البيانات عبر المناطق
  • بالنسبة لمشاركات SMB وNFS استنادا إلى Azure Premium Files، يتم تقديم التكرار النطاقي مع النسخ المتماثل المتزامن. تحقق من هذا المستند لمعرفة مدى توفر ZRS ل Azure Premium Files في المنطقة التي تريد النشر فيها. يتم دعم استخدام مشاركات NFS وSMB المنسوخة عبر النطاق بشكل كامل مع عمليات نشر طبقة تطبيق SAP ومجموعات تجاوز الفشل عالية التوفر لخدمات NetWeaver أو S/4HANA المركزية. المستندات التي تغطي هذه الحالات هي:
  • يتم استخدام المنطقة الثالثة لاستضافة جهاز SBD إذا قمت بإنشاءمجموعة SUSE Linux Pacemaker واستخدام أجهزة SBD بدلًا من عامل المبارزة Azure.

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

فيما يلي بعض الخطوات التالية للنشر عبر مناطق توافر الخدمات في Azure: