مشاركة عبر

توفر SAP Hana داخل منطقة Azure واحدة

  • مقالة

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

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

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

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

سيناريو جهاز ظاهري أحادي

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

  • إعادة تشغيل جهاز Azure الظاهري تلقائيا (يشار إليه أيضا باسم شفاء خدمة Azure)
  • إعادة تشغيل SAP HANA تلقائيا

إعادة تشغيل تلقائي للجهاز الظاهري لـ Azure أو معالجة خدمة وظيفة في Azure يعمل على مستويين:

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

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

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

مع مراقبة المضيف والجهاز الظاهري الذي يوفره Azure، تتم إعادة تشغيل الأجهزة الظاهرية لـ Azure التي تواجه مشكلات المضيف تلقائياّ على مضيف Azure سليم.

هام

لن يقوم برنامج Azure لمعالجة الخدمة بإعادة تشغيل الأجهزة الظاهرية لـ Linux حيث يكون نظام التشغيل الضيف في حالة اضطراب kernel. الإعدادات الافتراضية لإصدارات Linux شائعة الاستخدام، لا تقوم تلقائيًا بإعادة تشغيل الأجهزة الظاهرية أو الخادم حيث تكون نواة Linux في حالة ذعر. بدلاً من ذلك، يتوقع الافتراضي إبقاء نظام التشغيل في حالة ذعر النواة ليتمكن من إرفاق مصحح أخطاء النواة لتحليله. تحترم Azure هذا السلوك من خلال عدم إعادة تشغيل جهاز ظاهري تلقائيا مع نظام التشغيل الضيف في مثل هذه الحالة. الافتراض هو أن مثل هذه الأحداث نادرة للغاية. يمكنك الكتابة فوق السلوك الافتراضي لتمكين إعادة تشغيل الجهاز الظاهري. لتغيير السلوك الافتراضي يمكنك تمكين المعلمة 'kernel.panic' في /etc/sysctl.conf. الوقت الذي قمت بتعيينه لهذه المعلمة بالثواني. القيم الشائعة الموصَى بها هي الانتظار لمدة 20-30 ثانية قبل البدء في إعادة التحميل عبر هذه المعلمة. لمزيد من المعلومات، راجع sysctl.conf.

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

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

حالة خاصة من SAP Hana تكوينات قابلة للتوسيع في Azure

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

سيناريوهات التوفر لجهازين ظاهريين مختلفين

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

رسم تخطيطي لجهازين ظاهريين مع جميع الطبقات.

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

نسخ النُسخ الاحتياطية إلى جهاز ظاهري آخر

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

الهندسة المعمارية تبدو كما يلي:

رسم تخطيطي يوضح بنية جهازين ظاهريين مع النسخ المتماثل للتخزين.

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

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

النسخ المتماثل لنظام SAP HANA دون تجاوز الفشل التلقائي

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

النَسخ المتماثل لنظام SAP HANA دون تجاوز تلقائي للفشل ودون تحميل مسبق للبيانات

في هذا السيناريو، يمكنك استخدام النسخ المتماثل للنظام SAP Hana لنقل البيانات بطريقة متزامنة لتحقيق RPO من 0. من ناحية أخرى، لديك أوقات استرداد طويلة بما فيه الكفاية التي لا تحتاج إلى تجاوز الفشل أو تحميل البيانات مسبقاً في ذاكرة التخزين المؤقت لمثيل HANA. في هذه الحالة، من الممكن تحقيق المزيد من الاقتصاد في التكوين الخاص بك عن طريق اتخاذ الإجراءات التالية:

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

يبدو السيناريو كما يلي:

رسم تخطيطي لجهازين ظاهريين مع النسخ المتماثل للتخزين.

إشعار

حتى إذا لم تستخدم التحميل المسبق للبيانات في هدف النَسخ المتماثل لنظام HANA، فأنت بحاجة إلى ذاكرة 64 غيغا بايت على الأقل. تحتاج أيضاً ذاكرة كافية بالإضافة إلى 64 غيغا بايت للاحتفاظ بيانات rowstore في ذاكرة المثيل الهدف.

النَسخ المتماثل لنظام SAP HANA دون تجاوز تلقائي للفشل ودون تحميل مُسبق للبيانات

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

النَسخ المتماثل لنظام SAP HANA دون تجاوز الفشل التلقائي

في تكوين التوفر القياسي والأكثر شيوعا داخل منطقة Azure واحدة، يحتوي جهازا Azure VMs يعملان بنظام Linux مع حزم قابلية الوصول العالية على مجموعة تجاوز الفشل المعرفة. يستند نظام مجموعة HA Linux إلى Pacemaker إطار العمل باستخدام SLES أو RHEL مع fencing device SLES أو RHEL كمثال.

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

ويبدو ضبط الإعدادات العام كالتالي:

رسم تخطيطي لجهازين ظاهريين مع النسخ المتماثل للتخزين وتجاوز الفشل.

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

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

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

لمزيد من المعلومات حول توفر SAP Hana عبر مناطق Azure، راجع: