مشاركة عبر

توفر SAP Hana عبر مناطق Azure

  • مقالة

توضح هذه المقالة السيناريوهات المتعلقة بتوفر SAP Hana عبر مناطق Azure المختلفة. نظرا للمسافة بين مناطق Azure، فإن إعداد توفر SAP Hana في مناطق Azure متعددة ينطوي على اعتبارات خاصة.

لما التوزيع إلى مناطق Azure متعددة

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

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

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

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

توفر بسيط بين منطقتين لـ Azure

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

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

  • هناك نوعان من أوضاع التشغيل مع delta_datashipping و logreplay، وهما متاحان لمثل هذا السيناريو
  • كل من أوضاع العملية له متطلبات ذاكرة مختلفة دون تحميل البيانات مسبقاً
  • قد تتطلب Delta_datashipping ذاكرة أقل بشكل كبير دون خيار التحميل في الخلفية مقارنة بما قد يتطلبه logreplay. راجع الفصل 4.3 من مستند SAP كيفية إجراء النسخ المتماثل للنظام لـ SAP Hana
  • متطلبات الذاكرة لوضع عملية logreplay بدون تحميل مسبق ليست حتمية وتعتمد على بنيات تخزين الأعمدة التي تم تحميلها. في الحالات القصوى، قد تحتاج إلى 50٪ من ذاكرة المثيل الأساسي. الذاكرة الخاصة بوضع التشغيل logreplay مستقلة عما إذا كنت قد اخترت أن يكون لديك مجموعة البيانات المحملة مسبقاً أم لا.

Diagram of two VMs over two regions.

إشعار

في هذا التكوين، لا يمكنك توفير RPO=0 لأن وضع النسخ المتماثل لنظام HANA غير متزامن. إذا كنت بحاجة إلى توفير RPO=0، فإن هذا التكوين ليس التكوين المفضل.

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

اجمع بين التوفر داخل منطقة واحدة وعبر المناطق

قد يكون مزيج من التوافر داخل المناطق وعبرها مدفوعاً بهذه العوامل:

  • مطلوب RPO=0 داخل منطقة Azure.
  • المنظمة ليست مستعدة أو قادرة على أن تتأثر العمليات العالمية بكارثة طبيعية كبرى تؤثر على منطقة أكبر. وكان هذا هو الحال بالنسبة لبعض الأعاصير التي ضربت منطقة البحر الكاريبي خلال السنوات القليلة الماضية.
  • اللوائح التي تتطلب مسافات بين المواقع الأولية والثانوية التي تتجاوز بوضوح ما يمكن أن توفره مناطق توفر Azure.

في هذه الحالات، يمكنك إعداد ما يسميه SAP تكوين النسخ المتماثل لنظام SAP HANA متعدد المستويات باستخدام النسخ المتماثل لنظام HANA. سيبدو الهيكل كما يلي:

Diagram of three VMs over two regions.

أدخلت SAP النسخ المتماثل متعدد الأهداف مع HANA 2.0 SPS3. النسخ المتماثل متعدد الأهداف للنظام يجلب بعض المزايا في سيناريوهات التحديث. على سبيل المثال، لا يؤثر موقع التعافي من الكوارث (المنطقة 2) عندما يكون موقع قابلية الوصول العالية الثانوي معزولا للصيانة أو التحديثات. يمكنك معرفة المزيد حول النسخ المتماثل لنظام HANA متعدد الأهداف في بوابة مساعدة SAP. ستبدو البنية الممكنة مع النسخ المتماثل متعدد الأهداف كما يلي:

Diagram of three VMs over two regions multi-target.

إذا كان لدى المؤسسة متطلبات الاستعداد التوفر العالي في منطقة (DR) Azure الثانية، فستبدو البنية الأساسية مثل:

Diagram that shows an organization that has requirements for high availability readiness in the second (DR) Azure region.

باستخدام logreplay كوضع تشغيل، يوفر هذا التكوينRPO=0، مع RTO منخفضة، داخل المنطقة الأساسية. يوفر التكوين أيضاً RPO لائقاً إذا كان هناك نقل إلى المنطقة الثانية. تعتمد أوقات RTO في المنطقة الثانية على ما إذا كان تم تحميل البيانات مسبقاً. يستخدم العديد من العملاء الجهاز الظاهري في المنطقة الثانوية لتشغيل نظام اختبار. في حالة الاستخدام هذه، لا يمكن تحميل البيانات مسبقاً.

هام

يجب أن تكون أوضاع التشغيل بين المستويات المختلفة متجانسة. لا يمكنك استخدام logreplay كوضع تشغيل بين المستوى 1 والمستوى 2 delta_datashipping لتوفير المستوى 3. يمكنك فقط اختيار وضع التشغيل أو وضع التشغيل الآخر الذي يجب أن يكون متناسقاً مع جميع المستويات. نظراً لأن delta_datashipping غير مناسب لمنحك RPO=0، فإن وضع التشغيل المعقول الوحيد لمثل هذا التكوين متعدد المستويات يظل logreplay. للحصول على تفاصيل حول أوضاع التشغيل وبعض القيود، راجع مقالة SAP أوضاع التشغيل SAP Hana النسخ المتماثل للنظام.

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

للحصول على إرشادات خطوة بخطوة حول إعداد هذه التكوينات في Azure، راجع: