مشاركة عبر

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

  • مقالة

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

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

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

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

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

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

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

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

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

  • يتم تقديم مزيد من المعلومات حول مناطق توفر Azure في مناطق المستند ومناطق التوفر.
  • لا يشير زمن الانتقال ذهابا وإيابا للشبكة من ذوي الخبرة بالضرورة إلى المسافة الجغرافية الحقيقية لمراكز البيانات التي تشكل المناطق المختلفة. يتأثر زمن الانتقال ذهابا وإيابا للشبكة أيضا باتصالات الكبل وتوجيه الكبلات بين مراكز البيانات المختلفة هذه.
  • إذا كنت تستخدم مناطق التوفر كحل للتعافي من الكوارث على مسافة صغيرة، فضع في اعتبارك أننا واجهنا كوارث طبيعية تسبب أضرارا واسعة النطاق في مناطق مختلفة من العالم، بما في ذلك الأضرار الثقيلة والواسعة النطاق التي لحقت بالبنى التحتية للطاقة. وقد لا تكون المسافات بين مختلف المناطق كبيرة بما يكفي للتعويض عن هذه الكوارث الطبيعية الأكبر حجما.
  • زمن انتقال الشبكة عبر مناطق التوفر ليس هو نفسه في جميع مناطق Azure. حتى داخل منطقة Azure، قد تختلف زمن انتقال الشبكة بين المناطق المختلفة. على الرغم من أنه حتى في أسوأ الحالات، فإن النسخ المتماثل المتزامن على مستوى قاعدة البيانات استنادا إلى HANA System Replication أو SQL Server Always On سيعمل دون التأثير على قابلية توسع حمل العمل.
  • عند تحديد مكان استخدام مناطق التوفر، قم بتأسيس قرارك على زمن انتقال الشبكة بين المناطق. يلعب زمن انتقال الشبكة دورا مهما في مجالين:
    • زمن الانتقال بين مثيلي قاعدة البيانات اللذين يحتاجان إلى نسخ متماثل متزامن. استنادا إلى العمليات الناجحة جدا لأكبر أنظمة NetWeaver وS/4HANA بين المناطق ذات زمن انتقال أعلى للشبكة (أقل من 1.5 مللي ثانية)، يمكن إهمال هذا الاعتبار
    • الفرق في زمن انتقال الشبكة بين جهاز ظاهري يقوم بتشغيل مثيل حوار SAP في المنطقة مع مثيل قاعدة البيانات النشط و VM مشابه في منطقة أخرى. مع زيادة هذا الاختلاف، يزداد التأثير على وقت تشغيل العمليات التجارية ووظائف الدفعات أيضا، اعتمادا على ما إذا كانت تعمل داخل المنطقة مع قاعدة البيانات أو في منطقة مختلفة (راجع لاحقا في هذه المقالة).
  • زمن انتقال الشبكة مع مناطق توفر Azure، حتى في أكبر المناطق، منخفض بما يكفي لتشغيل عمليات أعمال SAP. حتى الآن، رأينا فقط عددا قليلا من الحالات الاستثنائية التي يحتاج فيها العملاء إلى تجميع طبقة تطبيق SAP وطبقة قاعدة البيانات تحت عمود شبكة مركز بيانات واحد.

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

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

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

ما لم تقم بتكوين تعيين عملية العمل باستخدام وظائف SAP مثل مجموعات تسجيل الدخول ومجموعات خادم RFC ومجموعات خادم الدفعات وما شابه ذلك، يمكن تنفيذ العمليات التجارية في مثيلات التطبيق المختلفة عبر طبقة تطبيق SAP. يتمثل التأثير الجانبي لهذه الحقيقة في أنه قد يتم تنفيذ مهام الدفعات بواسطة أي مثيلات تطبيق SAP مستقلة عما إذا كانت تعمل في نفس المنطقة مع مثيل قاعدة البيانات النشط أم لا. إذا كان الفرق في زمن انتقال الشبكة بين مناطق الفرق صغيرًا مقارنة بزمن انتقال الشبكة داخل منطقة ما، فقد لا يكون الفرق في أوقات تشغيل المهام الدفعية كبيرًا. ومع ذلك، كلما زاد الفرق في زمن انتقال الشبكة داخل منطقة، مقارنة بحركة مرور الشبكة عبر المنطقة، يمكن أن يؤثر وقت تشغيل مهام الدفعات بشكل أكبر إذا تم تنفيذ المهمة في منطقة لا يكون فيها مثيل قاعدة البيانات نشطا. عليك كعميل أن تقرر ما هي الاختلافات المقبولة في وقت التشغيل. ومع ذلك، فإن زمن انتقال الشبكة المسموح به لنسبة استخدام الشبكة عبر المناطق هو لحمل العمل الخاص بك. من وجهة نظر تقنية فقط، تعمل زمن انتقال الشبكة بين مناطق توفر Azure داخل منطقة Azure لبنية NetWeaver أو S/4HANA أو تطبيقات SAP الأخرى. كما أنه عليك كعميل من المحتمل أن يخفف من هذه الاختلافات باستخدام مفاهيم SAP لمجموعات تسجيل الدخول ومجموعات خادم RFC ومجموعات Batch Server وما شابه ذلك عندما تقرر أحد مفاهيم النشر التي نقدمها في هذه المقالة.

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

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

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

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

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

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

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

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

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

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

هام

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

هام

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

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

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

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

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

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

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

هام

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

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

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

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

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

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

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

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

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

إشعار

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

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

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

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

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

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

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