مشاركة عبر

نظرة عامة على التعافي من الكوارث وإرشادات البنية الأساسية لحمل عمل SAP

  • مقالة

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

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

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

اعتبارات خطة التعافي من الكوارث العامة

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

بالنسبة إلى DR على Azure، يجب على المؤسسات التفكير في سيناريوهات مختلفة قد تؤدي إلى تجاوز الفشل.

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

لتحقيق هدف الاسترداد لسيناريوهات مختلفة، يجب على المؤسسة تحديد هدف وقت الاسترداد (RTO) وهدف نقطة الاسترداد (RPO) لحمل العمل استنادا إلى متطلبات العمل. يصف RTO مقدار الوقت الذي يمكن أن يكون فيه التطبيق معزولا، ويتم قياسه عادة بالساعات أو الدقائق أو الثوان. في حين يصف RPO مقدار بيانات المعاملات المقبولة من قبل الأعمال لتفقد من أجل استئناف العمليات العادية. يعد تحديد RTO وRPO لأعمالك أمرا بالغ الأهمية، لأنه سيساعدك على تصميم استراتيجية الاسترداد بعد الكوارث على النحو الأمثل. يتم نسخ المكونات (الحوسبة والتخزين وقاعدة البيانات وما إلى ذلك) المتضمنة في حمل عمل SAP إلى منطقة التعافي من الكوارث باستخدام تقنيات مختلفة (خدمات Azure الأصلية، تقنية النسخ المتماثل الأصلي لقاعدة البيانات، البرامج النصية المخصصة). توفر كل تقنية RPO مختلفة، والتي يجب حسابها عند تصميم استراتيجية الاسترداد بعد الكوارث. على Azure، يمكنك استخدام بعض خدمات Azure الأصلية مثل Azure Site Recovery وAzure Backup التي يمكن أن تساعدك على تلبية RTO وRPO لأحمال عمل SAP الخاصة بك. راجع اتفاقية مستوى الخدمة ل Azure Site Recovery وAzure Backup للمحاذاة على النحو الأمثل مع RTO وRPO.

اعتبارات التصميم للتعافي من الكوارث على Azure

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

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

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

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

    • لا تقدم جميع خدمات Azure نسخا متماثلا عبر المناطق في منطقة مقترنة.

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

    • يتوفر خيار GRS لحساب التخزين مع نوع التخزين القياسي الذي ينسخ البيانات إلى منطقة مقترنة. ولكن التخزين القياسي غير مناسب ل SAP DBMS أو أقراص البيانات الظاهرية.

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

نشر حمل عمل SAP المرجعي

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

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

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

يجب على المؤسسات تخطيط استراتيجية الإصلاح بعد الكارثة وتصميمها لمشهد تكنولوجيا المعلومات بأكمله. عادة ما يتم دمج أنظمة SAP التي تعمل في بيئة الإنتاج مع خدمات وواجهات مختلفة مثل Active Directory وDNS وتطبيق الجهات الخارجية وما إلى ذلك. لذلك يجب عليك تضمين الأنظمة غير SAP والخدمات الأخرى في تخطيط التعافي من الكوارث أيضا. يركز هذا المستند على تخطيط الاسترداد لتطبيقات SAP. ولكن يمكنك توسيع حجم ونطاق تخطيط DR للمكونات التابعة لتناسب متطلباتك.

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

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

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

  • الشبكة
  • Compute
  • التخزين

الشبكة

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

    إشعار

    ضع في اعتبارك إعداد VPN من موقع إلى موقع (S2S) كنسخة احتياطية من Azure ExpressRoute. لمزيد من المعلومات، راجع استخدام S2S VPN كنسخة احتياطية ل Azure ExpressRoute Private Peering.

  • تمتد الشبكة الظاهرية والشبكات الفرعية إلى جميع مناطق التوفر في منطقة ما. بالنسبة إلى DR عبر منطقتين، تحتاج إلى تكوين شبكات ظاهرية منفصلة وشبكات فرعية على منطقة التعافي من الكوارث. راجع حول الشبكات في التعافي من الكوارث في Azure VM لمعرفة المزيد حول إعداد الشبكات في منطقة الاسترداد بعد الكوارث.

  • يوفر Azure Standard Load Balancer عناصر شبكة الاتصال لتصميم قابلية وصول عالية لأنظمة SAP الخاصة بك. بالنسبة للأنظمة المجمعة، يوفر موازن التحميل القياسي عنوان IP الظاهري لخدمة نظام المجموعة، مثل مثيلات ASCS/SCS وقواعد البيانات التي تعمل على الأجهزة الظاهرية. لتشغيل نظام SAP عالي التوفر على موقع التعافي من الكوارث، يجب إنشاء موازن تحميل منفصل ويجب تعديل تكوين نظام المجموعة وفقا لذلك.

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

  • نظرا لأن مكونات الشبكات (مثل الشبكة الظاهرية وجدار الحماية وما إلى ذلك) يتم إنشاؤها بشكل منفصل في منطقة التعافي من الكوارث، فأنت بحاجة إلى التأكد من تكييف حمل عمل SAP على منطقة DR مع تغييرات الشبكة مثل تحديث DNS وجدار الحماية وما إلى ذلك.

  • الشبكات الظاهرية في كلتا المنطقتين مستقلة وإنشاء اتصال بين الاثنين، تحتاج إلى تمكين تناظر الشبكة الظاهرية بين المنطقتين.

الأجهزة الظاهرية

  • على Azure، يتم تشغيل مكونات مختلفة من نظام SAP واحد على الأجهزة الظاهرية مع أنواع SKU مختلفة. بالنسبة إلى DR، يمكن تمكين حماية تطبيق (SAP NetWeaver وغير SAP) يعمل على أجهزة Azure الظاهرية عن طريق النسخ المتماثل للمكونات باستخدام Azure Site Recovery إلى منطقة أو منطقة Azure أخرى. باستخدام Azure Site Recovery، يتم نسخ أجهزة Azure الظاهرية بشكل مستمر من موقع التعافي من الكوارث الأساسي إلى موقع التعافي من الكوارث. اعتمادا على منطقة Azure DR المحددة، قد لا يتوفر نوع وحدة SKU للجهاز الظاهري على موقع DR. تحتاج إلى التأكد من أن أنواع VM SKU المطلوبة متوفرة في Azure DRregion أيضا. تحقق من منتجات Azure حسب المنطقة لمعرفة ما إذا كان نوع SKU لعائلة الجهاز الظاهري المطلوب متوفرا أم لا.

    هام

    إذا تم تكوين نظام SAP مع مجموعة مقياس مرنة مع FD=1، فأنت بحاجة إلى استخدام PowerShell لإعداد Azure Site Recovery للتعافي من الكوارث. حاليا، إنها الطريقة الوحيدة المتاحة لتكوين التعافي من الكوارث للأجهزة الظاهرية المنشورة في مجموعة التحجيم.

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

    إشعار

    لا ينصح باستخدام Azure Site Recovery لقواعد البيانات، لأنه لا يضمن تناسق قاعدة البيانات ولديه قيود على خسارة البيانات.

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

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

التخزين

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

  • بالنسبة لنظام SAP الذي يعمل على Windows مع قرص Azure المشترك، يمكنك استخدام Azure Site Recovery مع Azure Shared Disk (معاينة). نظرا لأن الميزة في المعاينة العامة، لا نوصي بتنفيذ السيناريو لمعظم أحمال عمل إنتاج SAP الحرجة. لمزيد من المعلومات حول السيناريوهات المدعومة لقرص Azure المشترك، راجع مصفوفة الدعم للأقراص المشتركة في التعافي من الكوارث لجهاز Azure الظاهري (معاينة)

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

    نوع التخزين توصية استراتيجية الإصلاح بعد الكوارث
    القرص المُدار استرداد موقع Azure
    NFS على ملفات Azure (LRS أو ZRS) برنامج نصي مخصص لنسخ البيانات بين موقعين (على سبيل المثال، rsync)
    NFS على Azure NetApp Files استخدام النسخ المتماثل عبر المناطق لوحدات تخزين Azure NetApp Files
    Azure Shared Disk (LRS أو ZRS) Azure Site Recovery مع Azure Shared Disk (في المعاينة)
    SMB على ملفات Azure (LRS أو ZRS) استخدام RoboCopy لنسخ الملفات بين موقعين
    SMB على Azure NetApp Files استخدام النسخ المتماثل عبر المناطق لوحدات تخزين Azure NetApp Files

  • بالنسبة لحلول التخزين المخصصة المضمنة مثل مجموعة NFS، تحتاج إلى التأكد من وجود استراتيجية الاسترداد بعد الكوارث المناسبة.

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

  • إذا كنت تستخدم تخزين تكرار المنطقة (ZRS) لملفات Azure، والقرص المشترك ل Azure في منطقتك الأساسية، وتريد الاحتفاظ بنفس خيار تكرار ZRS في منطقة الاسترداد بعد الكوارث أيضا، فراجع [دعم ZRS لمشاركات الملفات المتميزة](دعم التخزين المتكرر في منطقة Azure Files (ZRS) لمشاركات الملفات المتميزة | مستند Microsoft Learn) وZRS للأقراص المدارة لدعم ZRS في مناطق Azure.

  • إذا كنت تستخدم مناطق التوفر للتعافي من الكوارث، فضع في اعتبارك النقاط التالية:

    • ميزة ملفات Azure NetApp ليست على علم بالمنطقة حتى الآن. حالياً ميزة Azure NetApp Files غير منشورة في جميع مناطق التوفر في منطقة Azure. لذلك قد يحدث أن خدمة Azure NetApp Files غير متوفرة في منطقة التوفر المختارة لاستراتيجية الاسترداد بعد الكوارث.
    • يتوفر النسخ المتماثل عبر المناطق لوحدات تخزين Azure NetApp File فقط في أزواج المنطقة الثابتة، وليس عبر المناطق.

  • إذا قمت بتكوين التخزين الخاص بك مع تكامل Active Directory، يجب إجراء إعداد مماثل على حساب تخزين موقع DR أيضا.

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