مشاركة عبر

أحمال عمل SAP في سيناريوهات جهاز Azure الظاهري المدعومة

  • مقالة

يفتح تصميم بنية أنظمة SAP NetWeaver أو Business One Hybris أو S/4HANA في Azure العديد من الفرص المختلفة للعديد من البُنى والأدوات لاستخدامها للوصول إلى نشر قابل للتطوير وفعال ومتوفر بكثرة. على الرغم من اعتمادها على نظام التشغيل أو نظام إدارة قواعد البيانات (DBMS) المستخدم، إلا أن هناك قيودًا. وعلاوة على ذلك، لا يتم دعم كافة السيناريوهات المعتمدة محليًا بنفس الطريقة في Azure. سترشدك هذه الوثيقة من خلال التكوينات المدعومة التي تتيح الوصول بدرجة منخفضة والتكوينات والبُنى التي تتيح الوصول بدرجة عالية باستخدام أجهزة Azure الظاهرية حصريًا.

إشعار

خدمة HANA Large Instance في وضع الغروب ولا تقبل العملاء الجدد بعد الآن. لا يزال من الممكن توفير وحدات لعملاء HANA Large Instance الحاليين. للحصول على بدائل، تحقق من عروض أجهزة Azure الظاهرية المعتمدة من HANA في دليل أجهزة HANA. بالنسبة للسيناريوهات التي كانت ولا تزال مدعومة لعملاء HANA Large Instance الحاليين مع مثيلات HANA الكبيرة، تحقق من المقالة السيناريوهات المدعومة لمثيلات HANA الكبيرة.

قيود النظام الأساسي العامة

لدى Azure منصات مختلفة إلى جانب ما يسمى أجهزة Azure الظاهرية الأصلية التي يتم تقديمها كخدمة الطرف الأول. HANA Large Instances، والتي هي في وضع غروب الشمس هي واحدة من تلك الأنظمة الأساسية. Azure VMware Services هي خدمة أخرى من خدمات الطرف الأول هذه. خدمات Azure VMware بشكل عام غير مدعومة من قبل SAP لاستضافة حمل عمل SAP. راجع ملاحظة دعم SAP #2138865 - تطبيقات SAP على VMware Cloud: المنتجات المدعومة وتكوينات الجهاز الظاهري لمزيد من التفاصيل حول دعم VMware على الأنظمة الأساسية المختلفة.

بالإضافة إلى Active Directory محلي، يقدم Azure خدمة Active Directory SaaS مدارة مع Microsoft Entra Domain Services (AD التقليدية التي تديرها Microsoft)، ومعرف Microsoft Entra. غالبا ما تعتمد مكونات SAP المستضافة على نظام التشغيل Windows على استخدام Windows Active Directory. في هذه الحالة Active Directory التقليدي حيث تتم استضافته محليا من قبلك، أو Microsoft Entra Domain Services (لا يزال قيد الاختبار). ولكن لا يمكن لمكونات SAP هذه العمل مع معرف Microsoft Entra الأصلي. السبب هو أنه لا تزال هناك فجوات أكبر في الوظائف بين Active Directory في نموذجه المحلي أو نموذج SaaS الخاص به (Microsoft Entra Domain Services) ومعرف Microsoft Entra الأصلي. هذه التبعية هي السبب في عدم دعم حسابات Microsoft Entra للتطبيقات استنادا إلى SAP NetWeaver وS/4 HANA على نظام التشغيل Windows. يجب استخدام حسابات Active Directory التقليدية في مثل هذه السيناريوهات.

خدمة AD التطبيقات المدعومة استنادا إلى SAP NetWeaver وS/4 HANA على نظام التشغيل Windows
Windows Active Directory المحلي مدعوم
Microsoft Entra Domain Services مدعوم
Microsoft Entra ID غير مدعوم

لا يؤثر ما سبق على استخدام حسابات Microsoft Entra لسيناريوهات تسجيل الدخول الأحادي (SSO) مع تطبيقات SAP.

تكوين من طبقتين

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

يمكن أن يبدو التمثيل الرسومي لمثل هذا التكوين كما يلي:

Simple 2-Tier configuration

مثل هذه التكوينات مدعومة مع Windows و Red Hat و SUSE و Oracle Linux لأنظمة DBMS الخاصة بـ SQL Server و Oracle و Db2 و maxDB و SAP ASE للحالات الإنتاجية وغير الإنتاجية. بالنسبة إلى SAP HANA ك DBMS، يدعم SAP مثل هذا السيناريو كما هو مذكور في ملاحظة SAP #1953429. حتى الآن، لم تقدم أي من توزيعات Linux وثائق قابلية وصول عالية كافية لإعداد وتشغيل مجموعة Pacemaker في مثل هذا التكوين. ونتيجة لذلك، يتم دعم هذا النوع من التكوينات على Azure فقط للحالات غير الإنتاجية التي لا تتطلب مجموعة تجاوز فشل عالية التوفر.

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

إشعار

بالنسبة لأنظمة SAP الإنتاجية، نوصي بقابلية وصول عالية إضافية وتكوينات الإصلاح بعد كارثة النهائية كما هو موضح لاحقًا في هذا المستند

تكوين من 3 طبقات

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

يبدو التمثيل الرسومي كما يلي:

Diagram that shows a simple 3-Tier configuration.

يتم دعم هذا النوع من التكوين على Windows و Red Hat و SUSE و Oracle Linux لأنظمة DBMS الخاصة بـ SQL Server و Oracle و Db2 و SAP Hana و maxDB و SAP ASE للحالات الإنتاجية وغير الإنتاجية. للتبسيط، لم نميز بين مثيلات حوار SAP Central Services وSAP في طبقة تطبيق SAP. في هذا التكوين البسيط المكون من 3 طبقات، لن تكون هناك حماية لقابلية الوصول العالية لخدمات SAP المركزية.

إشعار

بالنسبة لأنظمة SAP الإنتاجية، نوصي بقابلية وصول عالية إضافية وتكوينات الإصلاح بعد كارثة النهائية كما هو موضح لاحقًا في هذا المستند

مثيلات DBMS متعددة لكل جهاز ظاهري

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

يمكن أن يبدو تكوين مثل هذا:

Multiple DBMS instances in one unit

يتم دعم هذا النوع من نشر DBMS من أجل:

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

إشعار

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

مثيلات حوار SAP متعددة في جهاز ظاهري واحد

في كثير من الحالات، تم نشر مثيلات حوار متعددة على خوادم كمبيوتر بلا نظام تشغيل أو حتى في الأجهزة الظاهرية التي تعمل في السحب الخاصة. كان سبب هذه التكوينات هو تخصيص مثيلات حوار SAP معينة لحمل عمل معين أو مهام الأعمال أو أنواع حمل العمل. وكان السبب في عدم عزل هذه المثيلات في أجهزة ظاهرية منفصلة هو الجهد المبذول في صيانة وتشغيل نظام التشغيل. أو في كثير من الحالات التكاليف في حالة طلب مضيف أو مشغل الجهاز الظاهري رسومًا شهرية لكل جهاز ظاهري يتم تشغيله وإدارته. في Azure، سيناريو استضافة مثيلات حوار SAP متعددة داخل جهاز ظاهري واحد مدعوم للأغراض الإنتاجية وغير الإنتاجية على أنظمة تشغيل Windows وRed Hat وSUSE وOracle Linux. يجب تعيين معلمة SAP kernel PHYS_MEMSIZE، المتوفرة على Windows ونواة Linux الحديثة، إذا كانت مثيلات SAP Application Server المتعددة تعمل على جهاز ظاهري واحد. ينصح أيضا بالحد من توسيع SAP Extended Memory على أنظمة التشغيل، مثل Windows حيث يتم تنفيذ النمو التلقائي للذاكرة الموسعة SAP. يمكن القيام بذلك باستخدام معلمة ملف تعريف SAP em/max_size_MB.

في التكوين من 3 طبقات حيث يتم تشغيل مثيلات حوار SAP متعددة داخل أجهزة Azure الظاهرية يمكن أن تبدو كما يلي:

Diagram that shows a 3-Tier configuration where multiple SAP dialog instances are run within Azure VMs.

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

حماية قابلية الوصول العالية لطبقة SAP DBMS

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

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

بشكل عام، تدعم Microsoft مجموعة محدودة من تكوينات قابلية الوصول العالية على أجهزة Azure الظاهرية أو وحدات مثيلات HANA الكبيرة.

بالنسبة إلى أجهزة Azure الظاهرية، يتم دعم تكوينات قابلية الوصول العالية التالية على مستوى نظام إدارة قواعد البيانات:

هام

بالنسبة لأي من السيناريوهات الغير موضحة أعلاه، فإننا ندعم تكوينات مثيلات DBMS متعددة في جهاز ظاهري واحد. يعني أنه في كل حالة من الحالات، لا يمكن نشر إلا مثيل قاعدة بيانات واحد فقط لكل جهاز ظاهري وحمايته باستخدام طرق قابلية الوصول العالية الموصوفة. حماية مثيلات DBMS متعددة ضمن نفس Windows أو مجموعة تجاوز فشل Pacemaker غير مدعومة حاليا. كما يتم دعم Oracle Data Guard لمثيل واحد لكل حالات نشر جهاز ظاهري فقط.

تسمح أنظمة قواعد البيانات المختلفة باستضافة قواعد بيانات متعددة تحت مثيل DBMS واحد. كما هو الحال مع SAP HANA، يمكن استضافة قواعد بيانات متعددة في حاويات قاعدة بيانات متعددة (MDC). يتم دعم هذه التكوينات، بالنسبة للحالات التي تعمل فيها تكوينات قواعد البيانات المتعددة هذه ضمن مورد نظام مجموعة تجاوز فشل واحد. التكوينات غير المدعومة هي الحالات التي تكون فيها موارد نظام المجموعة المتعددة مطلوبة. أما بالنسبة للتكوينات التي يمكنك فيها تحديد مجموعة قابلية وصول عالية التوفر لـ SQL Server المتعددة، تحت مثيل SQL Server واحد.

DBMS HA configuration

اعتمادا على DBMS أو أنظمة التشغيل أو كليهما، قد تكون مكونات مثل موازن تحميل Azure مطلوبة أو غير مطلوبة كجزء من بنية الحل.

على وجه التحديد بالنسبة لـ maxDB، يجب أن يكون تكوين التخزين مختلفًا. باستخدام maxDB، يجب أن تكون البيانات وملفات السجل موجودة على التخزين المشترك لتكوينات قابلية الوصول العالية. بالنسبة إلى maxDB فقط، يتم دعم التخزين المشترك لقابلية الوصول العالية. بالنسبة لجميع DBMS الأخرى، تعد مكدسات التخزين المنفصلة لكل عقدة هي تكوينات القرص المدعومة الوحيدة.

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

  • تطوير بنية النشر
  • نشر البنية
  • دعم البنية

هام

تقدم Microsoft Azure Marketplace مجموعة متنوعة من الأجهزة المرنة التي توفر حلول تخزين بالإضافة إلى تخزين Azure الأصلي. يمكن استخدام هذه الأجهزة المرنة لإنشاء مشاركات NFS كما يمكن استخدامها نظريًا في عمليات النشر SAP Hana الموسعة حيث تكون هناك حاجة إلى عقدة احتياطية. لأسباب مختلفة، لا يتم دعم أي من هذه الأجهزة اللينة للتخزين لأي من عمليات نشر DBMS بواسطة Microsoft وSAP على Azure. لا يتم دعم عمليات نشر DBMS على مشاركات SMB على الإطلاق في هذه المرحلة من الوقت. تقتصر عمليات نشر DBMS في مشاركات NFS على مشاركات NFS 4.1 على ملفات Azure NetApp.

قابلية وصول عالية لخدمة SAP المركزية

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

من بين الحلول المدرجة، تحتاج إلى علاقة دعم مع SIOS لدعم Datakeeper المنتج والتفاعل مع SIOS مباشرة في حالة مواجهة مشكلات. اعتمادًا على الطريقة التي قمت بها بترخيص Windows وRed Hat وSUSE OS أو إحداها، قد يطلب منك أيضا الحصول على عقد دعم مع موفر نظام التشغيل الخاص بك للحصول على الدعم الكامل لتكوينات قابلية الوصول العالية المدرجة.

كما يمكن أيضا عرض التكوين مثل:

DBMS and ASCS HA configuration

على الجانب الأيمن من الرسومات، يتم عرض خدمات SAP المركزية المتوفرة بشكل كبير. بالإضافة إلى حماية خدمات SAP Central بإطار عمل مجموعة تجاوز الفشل الذي يمكن أن يفشل في سيناريوهات الفشل. هناك ضرورة لمشاركة NFS أو SMB متوفرة بشكل كبير، أو قرص مشترك ل Windows للتأكد من توفر دليل النقل العمومي وال sapmnt بشكل مستقل عن وجود جهاز ظاهري واحد. ستتطلب بعض الحلول الإضافية، مثل Windows Failover Cluster Server و Pacemaker موازن تحميل Azure لتوجيه حركة المرور أو إعادة توجيهها إلى عقدة سليمة.

في القائمة المعروضة، لا يوجد ذكر لنظام تشغيل Oracle Linux. لا يدعم Oracle Linux Pacemaker كإطار عمل لنظام المجموعة. إذا كنت ترغب في نشر نظام SAP الخاص بك على Oracle Linux وتحتاج إلى إطار ذو قابلية وصول عالية لـ Oracle Linux، فأنت بحاجة إلى العمل مع موردي الجهات الخارجية. أحد الموردين هو SIOS مع مجموعة الحماية الخاصة بهم لنظام التشغيل Linux والتي تدعمها SAP على Azure. لمزيد من المعلومات، اقرأ ملاحظة SAP # 1662610 - تفاصيل الدعم لمجموعة الحماية SIOS لنظام التشغيل Linux لمزيد من التفاصيل.

التخزين المدعوم مع سيناريوهات خدمات SAP المركزية المذكورة أعلاه

نظرا لأن مجموعة فرعية فقط من أنواع التخزين Azure توفر مشاركات NFS أو SMB المتوفرة بشكل كبير بجودة مقبولة للاستخدام في سيناريوهات نظام مجموعة خدمات SAP، فإن ما يلي هو قائمة بأنواع التخزين المدعومة

  • يمكن نشر خادم نظام المجموعة لتجاوز الفشل لـ Windows مع خادم الملفات الموسع لـ Windows على كافة أنواع وحدات تخزين Azure الأصلية، باستثناء ملفات Azure NetApp. ومع ذلك، يوصى باستخدام Premium Storage بسبب اتفاقيات مستوى الخدمة الفائقة في معدل النقل وعمليات IOPS.
  • خادم نظام المجموعة تجاوز الفشل لـ Windows مع SMB على ملفات Azure NetApp على ملفات Azure NetApp. يتم دعم مشاركات SMB المستضافة على خدمات Azure Premium File لهذا السيناريو أيضا. ملفات Azure القياسية غير مدعومة
  • يمكن نشر خادم نظام مجموعة تجاوز الفشل لـ Windows مع قرص مشترك يعمل بنظام التشغيل Windows استنادا إلى SIOS Datakeeper على جميع أنواع وحدات تخزين Azure الأصلية، باستثناء ملفات Azure NetApp. ومع ذلك، يوصى باستخدام Premium Storage بسبب اتفاقيات مستوى الخدمة الفائقة في معدل النقل وعمليات IOPS.
  • يتم دعم SUSE أو Red Hat Pacemaker باستخدام مشاركات NFS على Azure NetApp Files.
  • SUSE أو Red Hat Pacemaker باستخدام مشاركات NFS على Azure Premium Files باستخدام LRS أو ZRS المدعومة. ملفات Azure القياسية غير مدعومة
  • يتم دعم SUSE Pacemaker مستخدم تكوين drdbبين جهازين ظاهريين باستخدام أنواع تخزين Azure الأصلية، باستثناء ملفات Azure NetApp. ومع ذلك، نوصي باستخدام إحدى خدمات الطرف الأول مع Azure Premium Files أو Azure NetApp Files.
  • يتم دعم Red Hat Pacemake مستخدم glusterfs لتوفير مشاركة NFS باستخدام أنواع تخزين Azure الأصلية، باستثناء ملفات Azure NetApp. ومع ذلك، نوصي باستخدام إحدى خدمات الطرف الأول مع Azure Premium Files أو Azure NetApp Files.

هام

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

مجموعات تجاوز الفشل لخدمات SAP المركزية متعدد SID

لتقليل عدد الأجهزة الظاهرية المطلوبة في مشاهد SAP الكبيرة، تسمح SAP بتشغيل مثيلات خدمات SAP المركزية للعديد من أنظمة SAP المختلفة في تكوين مجموعة تجاوز الفشل. تخيل الحالات التي يكون لديك فيها 30 أو أكثر من أنظمة إنتاج NetWeaver أو S/4HANA. بدون نظام مجموعة متعدد SID، ستتطلب هذه التكوينات 60 جهازًا ظاهريًا أو أكثر في 30 نظام Windows أو أكثر أو تكوينات نظام مجموعة تجاوز فشل Pacemaker. يمكن أن يؤدي نشر خدمات SAP مركزية متعددة عبر عقدتين في تكوين مجموعة تجاوز الفشل إلى تقليل عدد الأجهزة الظاهرية بشكل كبير. ومع ذلك، فإن نشر مثيلات خدمات SAP المركزية المتعددة على تكوين أحادي لمجموعة عقدتين له أيضا بعض العيوب. تنطبق المشكلات المتعلقة بجهاز ظاهري واحد في تكوين نظام المجموعة على أنظمة SAP متعددة. تتطلب الصيانة على نظام التشغيل الضيف الذي يعمل في تكوين المجموعة مزيدًا من التنسيق نظرًا لتأثر أنظمة SAP الإنتاجية المتعددة. لا تدعم أدوات مثل SAP LaMa التجميع متعدد SID في عملية استنساخ النظام.

على Azure، يتم دعم تكوين نظام مجموعة متعدد SID لنظام تشغيل Windows مع ENSA1 و ENSA2. التوصية ليست الجمع بين بنية خدمة النسخ المتماثل Enqueue القديمة (ENSA1) مع البنية الجديدة (ENSA2) على مجموعة واحدة متعددة SID. تفاصيل حول مثل هذه البنية موثقة في المقالات

بالنسبة لـ SUSE، يتم دعم مجموعة متعدد SID تعتمد على Pacemaker أيضا. التكوين مدعوم حتى الآن من أجل:

  • ما يصل إلى خمس مثيلات SAP ASCS/SCS كحد أقصى
  • بنية خدمة النسخ المتماثل القديمة في قائمة الانتظار (ENSA1)
  • تكوينات نظام مجموعة Pacemaker ثنائي العقدة

يتم توثيق التكوين في قابلية وصول عالية لـ SAP NetWeaver على أجهزة Azure ظاهرية على SUSE Linux Enterprise Server لدليل بمعرفات أمان متعددة لتطبيقات SAP⁧⁩⁧⁩⁧⁩

تبدو مجموعة متعدد SID مع خادم النسخ المتماثل في قائمة الانتظار تخطيطيًا كما يلي:

Diagram that shows a multi-SID cluster with Enqueue Replication server.

سيناريوهات توسيع نطاق SAP HANA

يتم دعم سيناريوهات توسيع نطاق SAP Hana لمجموعة فرعية من أجهزة Azure الظاهرية المعتمدة من HANA كما هو مدرج في دليل أجهزة SAP Hana. يمكن استخدام جميع الأجهزة الظاهرية التي تحمل علامة "نعم" في العمود "تكوين أنظمة المجموعات" إما لتوسيع نطاق OLAP أو S/4HANA. يتم دعم التكوينات بدون وضع الاستعداد مع أنواع تخزين Azure التالية:

  • Azure Premium Storage v1، بما في ذلك مسرع الكتابة Azure لوحدة تخزين /hana/log
  • Azure Premium Storage v2
  • قرص Ultra
  • Azure NetApp Files

يتم دعم تكوينات توسع SAP Hana لـ OLAP أو S/4HANA ذو عقدة (عقد) الاستعداد حصريًا مع NFS المشتركة المستضافة على ملفات Azure NetApp.

لمزيد من المعلومات حول تكوينات التخزين الدقيق بعقدة الاستعداد أو بدونها، راجع المقالات:

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

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

طبقة DBMS

بالنسبة لطبقة DBMS، يتم دعم التكوينات المستخدمة لآليات النسخ المتماثل الأصلية لنظام إدارة قواعد البيانات (DBMS)، مثل Always On أو Oracle Data Guard أو Db2 HDR أو SAP ASE Always-On أو النسخ المتماثل لنظام HANA. من الإلزامي أن يكون تدفق النسخ المتماثل في مثل هذه الحالات غير متزامن، بدلا من متزامن كما هو الحال في سيناريوهات التوفر العالي النموذجية التي يتم نشرها داخل منطقة Azure واحدة. يتم وصف مثال نموذجي لتكوين الإصلاح بعد كارثة لـ DBMS المدعوم في المقالة توفر SAP Hana عبر مناطق Azure. يصف الرسم الثاني في هذا القسم سيناريو مع HANA كمثال. يمكن نشر جميع قواعد البيانات الرئيسية المدعومة لتطبيقات SAP في مثل هذا السيناريو.

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

  • لا تسمح أنواع الأجهزة الظاهرية الأصغر بأن العديد من الأقراص المرفقة من الأجهزة الظاهرية الأصغر
  • تتمتع الأجهزة الظاهرية الأصغر حجمًا بإنتاجية أقل للشبكة والتخزين
  • يمكن أن يكون تغيير الحجم عبر عائلات الأجهزة الظاهرية مشكلة عند جمع الأجهزة الظاهرية المختلفة في مجموعة توفر Azure واحدة أو عندما يجب أن يحدث تغيير الحجم بين عائلة M-Series وعائلة Mv2 من الأجهزة الظاهرية
  • استهلاك وحدة المعالجة المركزية والذاكرة لمثيل قاعدة البيانات له القدرة على تلقي دفق التغييرات بأقل تأخير وموارد كافية لوحدة المعالجة المركزية والذاكرة لتطبيق هذه التغييرات بأقل تأخير على البيانات

يمكن العثور على مزيد من التفاصيل حول قيود أحجام الأجهزة الظاهرية المختلفة على صفحة أحجام الأجهزة الظاهرية

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

إشعار

لم يتم اختبار استخدام Azure Site Recovery لعمليات نشر نظام إدارة قواعد البيانات (DBMS) تحت حمل عمل SAP. ونتيجة لذلك فهي غير مدعومة لطبقة DBMS لأنظمة SAP في هذه المرحلة من الوقت. لا يتم دعم الأساليب الأخرى للنسخ المتماثلة بواسطة Microsoft وSAP غير المدرجة. يجب أن يكون استخدام برنامج تابع لجهة خارجية لنسخ طبقة DBMS من أنظمة SAP بين مناطق Azure المختلفة مدعومًا من مورد البرنامج ولن يتم دعمه من خلال قنوات دعم Microsoft وSAP.

طبقة ليس بها نظام إدارة قواعد البيانات (DBMS)

بالنسبة لطبقة تطبيق SAP والمشاركات النهائية أو مواقع التخزين المطلوبة، يتم استخدام السيناريوهين الرئيسيين من قبل العملاء:

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

نظام مجموعة خدمات SAP المركزية

في نسخ مجموعات خدمات SAP المركزية التي تستخدم الأقراص المشتركة (Windows) أو مشاركات SMB (Windows) أو مشاركات NFS بعض الصعوبة عن غيرها. على الجانب Windows، يعد Windows Storage Replication حلًا ممكنًا. على Linux، يعد rsync حلا قابلا للتطبيق. أيضا النسخ المتماثل عبر المناطق من Azure NetApp Files هو حل قابل للتطبيق.

سيناريو غير مدعوم

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

  • الأجهزة الناعمة للتخزين: هناك العديد من الأجهزة الناعمة للتخزين في السوق. يقدم بعض الموردين وثائق خاصة حول كيفية استخدام الأجهزة الناعمة للتخزين على Azure المتعلقة ببرامج SAP. يجب توفير دعم التكوينات أو عمليات النشر التي تتضمن مثل هذه الأجهزة الناعمة للتخزين من قبل بائع الجهاز الناعم للتخزين. تتجلى هذه الحقيقة أيضا في ملاحظة دعم SAP #2015553
  • أطر عمل قابلية وصول عالية: ليس هناك أطر عمل قابلية وصول عالية مدعومة لحمل عمل SAP على Azure إلا مجموعة تجاوز فشل خادم Windows و Pacemaker فقط. كما ذكرنا سابقا، يتم وصف حل Datakeeper SIOS وتوثيقه من قبل Microsoft. ومع ذلك، يلزم دعم مكونات Datakeeper SIOS من خلال SIOS بوصفها البائع الذي يوفر تلك المكونات. أدرجت SAP أيضا أطر عمل أخرى معتمدة ذات قابلية وصول عالية في ملاحظات SAP المختلفة. تم اعتماد بعضها من قبل بائع الجهة الخارجية لـ Azure أيضا. ومع ذلك، يجب توفير الدعم للتكوينات التي تستخدم هذه المنتجات من قبل بائع المنتج. يتمتع البائعون المختلفون بتكامل مختلف في عمليات دعم SAP. يجب توضيح عملية الدعم التي تعمل بشكل أفضل للمورد المعين قبل أن تقرر استخدام المنتج مع تكوينات SAP المنشورة على Azure.
  • مجموعات الأقراص المشتركة حيث توجد ملفات قاعدة البيانات على الأقراص المشتركة غير مدعومة، باستثناء maxDB. بالنسبة لكافة قواعد البيانات الأخرى، يتمثل الحل المدعوم في الحصول على مواقع تخزين منفصلة بدلًا من مشاركة SMB أو NFS أو قرص مشترك لتكوين سيناريوهات لقابلية وصول عالية

السيناريوهات الأخرى، غير المدعومة هي سيناريوهات مثل:

  • سيناريوهات التوزيع التي تقدم زمن انتقال أكبر للشبكة بين طبقة تطبيق SAP وطبقة SAP DBMS كما هو الحال في NetWeaver وS/4HANA وعلى سبيل المثال Hybris. ويشمل ذلك ما يلي:
    • توزيع إحدى الطبقات محلياً بينما تُوزَّع الطبقة الأخرى في Azure
    • نشر طبقة تطبيق SAP لنظام في منطقة Azure مختلفة عن طبقة DBMS
    • نشر طبقة واحدة في مراكز البيانات التي تقع في موقع واحد في Azure والطبقة الأخرى في Azure، باستثناء الحالات التي يتم فيها توفير نمط بنية من هذا القبيل بواسطة خدمة Azure الأصلية
    • نشر الأجهزة الظاهرية للشبكة بين طبقة تطبيق SAP وطبقة DBMS
    • استخدام التخزين المستضاف في مراكز البيانات الموجودة في مركز بيانات Azure لطبقة SAP DBMS أو دليل النقل العمومي SAP
    • نشر الطبقتين مع موردين مختلفين للسحابة. على سبيل المثال، نشر طبقة DBMS في البنية الأساسية السحابية لـ Oracle وطبقة التطبيقات في Azure
  • تكوينات نظام مجموعة HANA Pacemaker متعددة المثيلات
  • تكوينات نظام مجموعة Windows مع الأقراص المشتركة من خلال SOFS أو SMB على ANF لقواعد بيانات SAP المدعومة على Windows. بدلا من ذلك، نوصي باستخدام النسخ المتماثل الأصلي من مجموعة قابلية وصول عالية التوفر لقواعد البيانات المعينة واستخدام مكدسات تخزين منفصلة
  • نشر قواعد بيانات SAP المدعومة على Linux مع ملفات قاعدة البيانات الموجودة في مشاركات NFS أعلى ANF باستثناء SAP HANA وOracle على Oracle Linux وDb2 على Suse وRed Hat
  • نشر Oracle DBMS على أي نظام تشغيل ضيف آخر غير Windows و Oracle Linux. راجع أيضا ملاحظة دعم SAP رقم 2039619

السيناريو (السيناريوهات) التي لم نختبرها وبالتالي ليس لدينا خبرة في القائمة مثل:

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

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

اقرأ الخطوات التالية في تخطيط أجهزة Azure الظاهرية وتنفيذها من أجل SAP NetWeaver