مشاركة عبر

استمرارية الأعمال والإصلاح بعد كارثة لترحيل SAP

  • مقالة

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

السيناريو والنطاق

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

  • توفر الخدمة وعملية الأعمال.
  • أهداف وقت الاسترداد (RTOs) لسيناريوهات الفشل أو الكوارث.
  • أهداف نقطة الاسترداد (RPOs) لسيناريوهات الفشل.
  • مهام إدارة العمليات ودورة الحياة والتكنولوجيا التي تملأ أثناء سيناريوهات الفشل. تتضمن مهام الإدارة هذه تصحيح أنظمة تشغيل الضيف وأنظمة إدارة قواعد البيانات والاستنساخ وتحديث أنظمة SAP.

تلميح

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

قم بتكوين HADR على Azure في وقت مبكر، في مشهد واحد على الأقل، واحتفظ به قيد التشغيل هناك. يتيح القيام بذلك لفرقك الفرصة للحصول على خبرة في التقنيات المعنية، والتي قد تكون مختلفة عن التقنيات الحالية. يمكن أن يساعدك تكوين HADR مبكرا أيضا في تطوير وتطوير إجراءات التشغيل القياسية (SOP).

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

تتناول هذه المقالة الجوانب التالية من BCDR لسيناريو SAP على نطاق المؤسسة:

  • قابلية وصول عالية داخل منطقة Azure.
  • اعتبارات النسخ الاحتياطي والاستعادة.
  • معايير اتخاذ قرار بين التعافي من الكوارث عبر المناطق والإقليمية.

قابلية وصول عالية داخل منطقة Azure

توفر الأقسام التالية اعتبارات التصميم والتوصيات لقابلية الوصول العالية داخل منطقة Azure لسيناريو مؤسسة SAP.

اعتبارات التصميم لقابلية الوصول العالية

للحصول على قابلية وصول عالية، ينصب التركيز على توفير التوفر لنقطة الفشل الفردية لبرنامج SAP، مثل:

  • أنظمة إدارة قواعد البيانات.
  • نقاط فشل واحدة في التطبيق، مثل SAP ABAP وASCS + SCS. تتضمن الأمثلة SAP NetWeaver وبنية SAP S/4HANA.
  • أدوات أخرى، مثل SAP Web Dispatcher.

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

تدعم قواعد بيانات SAP وSAP مجموعات تجاوز الفشل التلقائي. في Windows، يدعم تجاوز الفشل للمجموعات في Windows Server تجاوز الفشل. في Linux أو Linux Pacemaker أو أدوات الجهات الخارجية مثل SIOS Protection Suite وVeritas InfoScale تدعم تجاوز الفشل. باستخدام Azure، يمكنك نشر تكوين مجموعة فرعية عالية التوفر فقط في مركز البيانات الخاص بك.

لمعرفة المزيد حول كيفية دعم Azure ل SAP، راجع السيناريوهات المدعومة لأحمال عمل SAP على أجهزة Azure الظاهريةوالسيناريوهات المدعومة لمثيلات SAP HANA الكبيرة.

بالنسبة لطبقة DBMS، يتمثل نمط البنية الشائع في نسخ قواعد البيانات نسخا متماثلا في نفس الوقت ومع مكدسات تخزين مختلفة عن تلك التي تستخدمها الأجهزة الظاهرية الأساسية والثانوية. لا يدعم Azure البنيات التي تشترك فيها الأجهزة الظاهرية الأساسية والثانوية في التخزين لبيانات DBMS. كما أن Azure لا يدعم المعاملات أو سجلات الإعادة. المبدأ التوجيهي هو استخدام مكدسي تخزين مستقلين، حتى إذا كانا يستندان إلى مشاركات نظام ملفات الشبكة (NFS). هذا الأسلوب هو القيد الرئيسي عند مقارنة ما هو ممكن محليا مع ما هو ممكن على Azure.

يوفر Azure خيارات أخرى، لأنه يدعم إما مشاركة NFS أو Server Message Block. يمكنك استخدام أقراص Azure المشتركة في Windows لمكونات ASCS + SCS وسيناريوهات محددة عالية التوفر. قم بإعداد مجموعات تجاوز الفشل بشكل منفصل لمكونات طبقة تطبيق SAP وطبقة DBMS. لا يدعم Azure حاليا البنيات عالية التوفر التي تجمع بين مكونات طبقة تطبيق SAP وطبقة DBMS في مجموعة تجاوز فشل واحدة.

تتطلب معظم مجموعات تجاوز الفشل لمكونات طبقة تطبيق SAP وطبقة DBMS عنوان IP ظاهريا لمجموعة تجاوز الفشل. الاستثناء الشائع هو عند استخدام Oracle Data Guard. لا يتطلب عنوان IP ظاهريا. يجب أن يتعامل Azure Load Balancer مع عنوان IP الظاهري لجميع الحالات الأخرى. أحد مبادئ التصميم هو استخدام موازن تحميل واحد لكل تكوين نظام مجموعة. نوصي باستخدام الإصدار القياسي من موازن التحميل. لمزيد من المعلومات، راجع اتصال نقطة النهاية العامة للأجهزة الظاهرية باستخدام Azure Standard Load Balancer في سيناريوهات SAP عالية التوفر.

لمزيد من المعلومات والخيارات، راجع بنية وسيناريوهات قابلية الوصول العالية ل SAP NetWeaver.

فيما يلي اتفاقيات مستوى الخدمة على مستوى النظام الأساسي لخيارات النشر المختلفة عالية التوفر. يوفر الشركاء الذين يقدمون الخدمات المدارة اتفاقية مستوى الخدمة على مستوى التطبيق.

المستوى سيناريو قابلية الوصول العالية اتفاقية مستوى الخدمة للنظام الأساسي
الفئة 1 مناطق التوافر 99.99%
المستوى 2 مجموعة التوفّر 99.95%
المستوى 3 جهاز ظاهري واحد (الشفاء الذاتي) 99.9%

لمزيد من المعلومات، راجع القسم التالي.

مجموعات توفر Azure مقابل مناطق التوفر

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

  • لا تنتشر الأجهزة الظاهرية عبر مناطق توفر مختلفة.
  • يتم تقييد نوع الأجهزة الظاهرية التي يمكنك نشرها من خلال مجموعة توفر واحدة لأن المضيف يتم تعريفه بواسطة الجهاز الظاهري الأول الذي تم نشره في المجموعة. أحد الأمثلة على ذلك هو أنك لن تتمكن من دمج أجهزة M-series وE-series الظاهرية في مجموعة توفر واحدة.

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

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

إذا كنت تستخدم توزيع نطاقي نشط/سلبي لطبقة خادم التطبيق (يجب أن تتصل خوادم التطبيقات بقاعدة البيانات في نفس منطقة التوفر)، فقم بإنشاء أتمتة وSOP لتمكين الاسترداد السريع والآلي إذا كان هناك تجاوز فشل في قاعدة البيانات.

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

توصيات التصميم لقابلية الوصول العالية

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

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

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

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

  • في توزيع مجموعة التوفر، يجب أن يكون كل مكون من مكونات نظام SAP في مجموعة التوفر الخاصة به. يجب أن تكون خدمات SAP المركزية وقاعدة البيانات والأجهزة الظاهرية للتطبيق في مجموعات التوفر الخاصة بها.

  • عند استخدام مجموعات مواضع تقارب Azure في توزيع مجموعة التوفر، يجب أن تكون جميع مكونات SAP الثلاثة (الخدمات المركزية وخادم التطبيق وقاعدة البيانات) في نفس مجموعة موضع التقارب.

  • إذا كنت تستخدم مجموعات مواضع التقارب، فاستخدم واحدة لكل SAP SID. لا تمتد المجموعات عبر مناطق التوفر أو مناطق Azure.

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

  • لا يدعم Azure حاليا الجمع بين ASCS والتوافر العالي لقاعدة البيانات في مجموعة Linux Pacemaker واحدة. افصلها إلى مجموعات فردية. يمكنك دمج ما يصل إلى خمس مجموعات خدمات مركزية متعددة في زوج من الأجهزة الظاهرية.

  • استخدم وحدة SKU لموازن التحميل القياسي أمام مجموعات ASCS وقاعدة البيانات.

  • قم بتشغيل جميع أنظمة الإنتاج على محركات الأقراص ذات الحالة الصلبة المدارة المتميزة واستخدم Azure NetApp Files أو Ultra Disk Storage. يجب أن يكون قرص نظام التشغيل على الأقل على مستوى Premium حتى تتمكن من تحقيق أداء أفضل وأفضل اتفاقية مستوى خدمة.

  • انشر كلا الجهازين الظاهريين في زوج قابلية الوصول العالية في مجموعة توفر أو في مناطق التوفر. يجب أن تكون هذه الأجهزة الظاهرية بنفس الحجم وأن يكون لها نفس تكوين التخزين.

  • استخدم تقنية النسخ المتماثل لقاعدة البيانات الأصلية لمزامنة قاعدة البيانات في زوج قابلية وصول عالية.

  • استخدم إحدى الخدمات التالية لتشغيل مجموعات خدمات SAP المركزية، اعتمادا على نظام التشغيل:

  • قم بإعداد معلمات مهلة نظام المجموعة كما هو مستحسن في وثائق الخدمات المركزية ومجموعات قواعد البيانات.

التخزين لأحمال عمل SAP

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

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

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

    نوع التخزين دعم التكوين عالي التوفر
    أقراص Azure المشتركة (LRS أو ZRS) نظام مجموعة تجاوز الفشل ل Windows Server. للحصول على تفاصيل التكوين، راجع تصميم SAP HA مع نظام مجموعة تجاوز الفشل ل Windows Server .
    NFS على ملفات Azure (LRS أو ZRS) نظام المجموعة المستند إلى Pacemaker على بيئات Linux. تأكد من التحقق من توفر NFS في مناطق مختلفة.
    NFS على Azure NetApp Files نظام المجموعة المستند إلى Pacemaker على بيئات Linux. لمزيد من المعلومات، راجع Azure NetApp Files لأجهزة SAP الظاهرية.
    SMB على ملفات Azure (LRS أو ZRS) نظام مجموعة تجاوز الفشل ل Windows Server. للحصول على تفاصيل التكوين، راجع قابلية الوصول العالية ل SAP NetWeaver على أجهزة Azure الظاهرية على Windows مع Azure Files Premium SMB لتطبيقات SAP.
    SMB على Azure NetApp Files نظام مجموعة تجاوز الفشل ل Windows Server. للحصول على تفاصيل التكوين، راجع قابلية الوصول العالية ل SAP NetWeaver على أجهزة Azure الظاهرية على Windows باستخدام Azure NetApp Files (SMB) لتطبيقات SAP.

  • بدلا من خدمات التخزين المشتركة الأصلية في Azure، يمكنك استخدام مجموعات NFS التقليدية (استنادا إلى النسخ المتماثل DRBD) أو GlusterFS أو وحدة التخزين المشتركة للمجموعة مع Storage Spaces Direct كحل تخزين مشترك بديل لتشغيل أحمال عمل SAP على Azure. تكون هذه الخيارات مفيدة بشكل خاص عندما تكون خدمات التخزين المشتركة الأصلية من Azure إما غير متوفرة في منطقة Azure المستهدفة أو لا تدعم البنية الهدف. للحصول على معلومات حول توفر خدمة التخزين، راجع منتجات Azure حسب المنطقة.

  • للتعرف على خيارات التخزين المتوفرة لأحمال عمل SAP على Azure، راجع توصيات التخزين وإرشادات إعداد الإصلاح بعد كارثة.

النسخ الاحتياطي والاستعادة

تصف الأقسام التالية اعتبارات التصميم والتوصيات للنسخ الاحتياطي والاستعادة في سيناريو SAP.

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

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

  • احتفظ بمخزن للاحتفاظ بالنسخ الاحتياطية طويلة الأجل من أجل تلبية لوائح التوافق.

  • استخدم النسخ الاحتياطية لقاعدة البيانات لاستنساخ نظام SAP واستعادة النسخ الاحتياطية مقابل خادم أو جهاز ظاهري آخر.

  • استخدم بيانات قاعدة بيانات الإنتاج من النسخ الاحتياطية لقاعدة البيانات لتحديث الأنظمة غير الإنتاجية.

  • النسخ الاحتياطي لخوادم تطبيقات SAP والأجهزة الظاهرية أو الأقراص أو لقطات الجهاز الظاهري.

عند إجراء النسخ الاحتياطي والاستعادة محليا، تحتاج إلى إحضار هذه الإمكانات إلى أنظمة SAP في Azure.

إذا كنت راضيا عن الحل الحالي، فتحقق مما إذا كان مورد النسخ الاحتياطي يدعم عمليات توزيع Azure أو ما إذا كان لديه حل خدمة تأجير البرامج (SaaS) ل Azure.

يوفر Azure خدمة SaaS احتياطية، Azure Backup، والتي تأخذ لقطات الجهاز الظاهري وتدير دفق SQL Server ونسخ SAP HANA الاحتياطية. إذا كنت تستخدم Azure NetApp Files لتخزين قواعد بيانات SAP HANA الخاصة بك، يمكنك تشغيل النسخ الاحتياطية استنادا إلى لقطات التخزين المتوافقة مع HANA.

توصيات التصميم للنسخ الاحتياطي والاستعادة

  • يمكنك استخدام Azure Backup لنسخ خادم تطبيق SAP والأجهزة الظاهرية للخدمات المركزية احتياطيا.

  • يمكنك استخدام نسخة احتياطية من SAP HANA لعمليات توزيع HANA تصل إلى 8 تيرابايت. لمزيد من المعلومات، راجع مصفوفة الدعم لنسخ قواعد بيانات SAP HANA احتياطيا على أجهزة Azure الظاهرية.

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

  • اختبر أوقات النسخ الاحتياطي والاسترداد للتحقق من أنها تفي بمتطلبات RTO لاستعادة جميع الأنظمة في وقت واحد بعد وقوع كارثة.

  • من الناحية المثالية، تجنب سحب النسخ الاحتياطية من Azure إلى البنية الأساسية للنسخ الاحتياطي المحلي، خاصة لقواعد البيانات الكبيرة. يؤثر القيام بذلك على مقدار النطاق الترددي الذي تستخدمه دوائر ExpressRoute.

  • اختبار تحميل أدوات النسخ الاحتياطي والاسترداد كجزء من خطة اختبار الأداء.

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

تصف الأقسام التالية اعتبارات التصميم والتوصيات للإصلاح بعد كارثة في سيناريو SAP.

اعتبارات التصميم للإصلاح بعد كارثة

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

التحديات الرئيسية لإقران مناطق Azure لأحمال عمل SAP هي:

  • لا تتوافق الأزواج دائما مع خدمات الأجهزة الظاهرية من سلسلة M أو Mv2. لا تستخدم العديد من المؤسسات التي تنشر أنظمة SAP الخاصة بها مناطق Azure المقترنة. بدلا من ذلك، يختارون المناطق استنادا إلى توفر أنواع الأجهزة الظاهرية المطلوبة.

  • يمكنك نسخ التخزين القياسي بين المناطق المقترنة، ولكن لا يمكنك استخدام التخزين القياسي لتخزين قواعد البيانات أو الأقراص الثابتة الظاهرية. يمكنك نسخ النسخ الاحتياطية فقط بين المناطق المقترنة التي تستخدمها. بالنسبة لجميع بياناتك الأخرى، قم بتشغيل النسخ المتماثل باستخدام ميزات DBMS الأصلية مثل SQL Server Always On أو SAP HANA System Replication. استخدم مزيجا من Site Recovery، rsync أو robocopy، وبرامج أخرى تابعة لجهة خارجية لطبقة تطبيق SAP.

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

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

بعد تحديد مناطق Azure الخاصة بك، تحتاج إلى اختيار نمط توزيع:

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

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

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

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

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

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

توصيات التصميم للإصلاح بعد كارثة

  • تأكد من أن التوجيه بين المجالات (CIDR) دون فئة للشبكة الظاهرية الأساسية لا يتعارض أو يتداخل مع CIDR للشبكة الظاهرية لموقع الإصلاح بعد كارثة.
  • قم بإعداد اتصالات ExpressRoute من أماكن العمل إلى مناطق الإصلاح بعد كارثة الأساسية والثانوية في Azure.
  • كبديل لاستخدام ExpressRoute، ضع في اعتبارك إعداد اتصالات VPN من أماكن العمل إلى مناطق الإصلاح بعد كارثة الأساسية والثانوية في Azure.
  • استخدم Site Recovery لنسخ خادم تطبيق نسخا متماثلا إلى موقع الإصلاح بعد كارثة. يمكن أن يساعدك استرداد الموقع أيضا في نسخ الأجهزة الظاهرية لنظام مجموعة الخدمات المركزية إلى موقع الإصلاح بعد كارثة. عند استدعاء الإصلاح بعد كارثة، تحتاج إلى إعادة تكوين نظام مجموعة Linux Pacemaker على موقع الإصلاح بعد كارثة. على سبيل المثال، تحتاج إلى استبدال VIP أو SBD، وتشغيل corosync.conf، وما إلى ذلك.
  • نسخ محتويات مخزن المفاتيح مثل الشهادات أو الأسرار أو المفاتيح عبر المناطق حتى تتمكن من فك تشفير البيانات في منطقة الإصلاح بعد كارثة.
  • استخدم النسخ المتماثل عبر المناطق في Azure NetApp Files (حاليا في المعاينة العامة) لمزامنة وحدات تخزين الملفات بين المنطقة الأساسية ومنطقة الإصلاح بعد كارثة.
  • استخدم النسخ المتماثل لقاعدة البيانات الأصلية، بدلا من استرداد الموقع، لمزامنة البيانات إلى موقع الإصلاح بعد كارثة.
  • نظير الشبكات الظاهرية الأساسية والإصلاح بعد كارثة. على سبيل المثال، بالنسبة إلى النسخ المتماثل لنظام HANA، يجب تناظر شبكة SAP HANA DB الظاهرية بشبكة SAP HANA DB الظاهرية لموقع الإصلاح بعد كارثة.
  • إذا كنت تستخدم تخزين Azure NetApp Files لعمليات توزيع SAP الخاصة بك، على الأقل، فقم بإنشاء حسابين من حسابات Azure NetApp Files في المستوى Premium، في منطقتين.
  • ضع في اعتبارك تجميع الأنظمة استنادا إلى أهمية أعمالها وتبعية التقارب استنادا إلى أداء التطبيق. انشر كل مجموعة في منطقة منفصلة في بنية منطقة مقترنة لتقليل تأثير الأعمال على الانقطاع الإقليمي. على سبيل المثال، يمكن نشر نظامين مهمين ل ECC يخدمان وحدتي أعمال مختلفتين في جنوب المملكة المتحدة وغرب المملكة المتحدة لتقليل تأثير الانقطاع الإقليمي.

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

خيارات التوزيع ل SAP في Azure