مشاركة عبر

اعتبارات لنشرAzure Virtual Machines DBMS لـ SAP workload

  • مقالة

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

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

في هذا المستند، يتم تقديم اعتبارات تشغيل أنظمة DBMS المتعلقة ب SAP في Azure VMs. هناك عدد قليل من المراجع لأنظمة DBMS معينة في هذا المستند. بدلا من ذلك، تتم معالجة أنظمة DBMS المحددة في مستندات أخرى خاصة بنظام قاعدة البيانات.

الموارد

هناك مقالات أخرى متوفرة حول حمل عمل SAP على Azure. ابدأ بحمل عمل SAP على Azure: ابدأ ثم اختر مجال اهتمامك.

ترتبط ملاحظات SAP التالية ب SAP على Azure فيما يتعلق بالمنطقة التي يغطيها هذا المستند.

رقم الملاحظة العنوان
1928533 تطبيقات SAP على Azure: المنتجات المدعومة وأنواع أجهزة Azure الظاهرية
2015553 SAP على Microsoft Azure: دعم المتطلبات الأساسية
1999351 استكشاف أخطاء مراقبة Azure المحسنة لـ SAP وإصلاحها
2178632 مقاييس المراقبة الرئيسية ل SAP على Microsoft Azure
1409604 المحاكاة الافتراضية على Windows: مراقبة محسنة
2191498 SAP على Linux باستخدام Azure: مراقبة محسنة
2039619 تطبيقات SAP على Microsoft Azure باستخدام قاعدة بيانات Oracle: المنتجات والإصدارات المدعومة
2233094 DB6: تطبيقات SAP على Azure باستخدام IBM DB2 لنظام التشغيل Linux UNIX Windows: معلومات إضافية
2243692 Linux على Microsoft Azure (IaaS) VM: مشكلات ترخيص SAP
2578899 SUSE Linux Enterprise Server 15: ملاحظة التثبيت
1984787 خادم المؤسسة 12 لـSUSE LINUX: ملاحظات التثبيت
2772999 Red Hat Enterprise Linux 8.x: Installation and Configuration
2002167 ريد هات المؤسسة لينكس 7.x: التثبيت والترقية
2069760 تثبيت Oracle Linux 7.x SAP وترقيته
1597355 توصية مساحة المبادلة لنظام التشغيل Linux
2799900 ملاحظة تقنية مركزية لقاعدة بيانات Oracle 19c
2171857 قاعدة بيانات أوراكل 12c: دعم نظام الملفات على لينكس
1114181 قاعدة بيانات أوراكل 11g: دعم نظام الملفات على لينكس
2969063 فشل التحقق من صحة الرمز المصغر في HCMT على Azure
3246210 Azure - فشل HCMT أثناء بعض اختبارات أداء القرص

للحصول على معلومات حول جميع ملاحظات SAP لنظام التشغيل Linux، راجع موقع wiki لمجتمع SAP.

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

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

بنية تخزين جهاز ظاهري لعمليات نشر RDBMS

لمتابعة هذا الفصل، اقرأ وفهم المعلومات المقدمة في:

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

في التكوين الأساسي، نوصي عادة ببنية نشر حيث يكون نظام التشغيل و DBMS وثنائيات SAP النهائية منفصلة عن ملفات قاعدة البيانات. نوصي بوجود أقراص Azure منفصلة ل:

  • نظام التشغيل (VHD الأساسي أو OS VHD)
  • الملفات التنفيذية لنظام إدارة قواعد البيانات
  • SAP الملفات التنفيذية مثل /usr/sap
  • ملفات بيانات DBMS
  • إعادة ملفات سجل DBMS

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

يتم تخزين بيانات DBMS وملفات سجل المعاملات/الإعادة في وحدة تخزين الكتلة المدعومة من Azure أو Azure NetApp Files. ملفات Azure أو Azure Premium Files غير مدعومة كمخزن لبيانات DBSM و/أو إعادة ملفات السجل مع حمل عمل SAP. يتم تخزينها في أقراص منفصلة وتوصيلها كأقراص منطقية بالصورة VM الأصلية لنظام التشغيل Azure. بالنسبة إلى عمليات توزيع Linux، يتم توثيق توصيات مختلفة. اقرأ المقالة أنواع تخزين Azure لأحمال عمل SAP للحصول على إمكانات ودعم أنواع التخزين المختلفة للسيناريو الخاص بك. خصيصا ل SAP HANA ابدأ بالمقالة تكوينات تخزين الجهاز الظاهري SAP HANA Azure.

عند تخطيط القرص، ابحث عن أفضل توازن بين هذه العناصر:

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

يفرض Azure حصة IOPS لكل قرص بيانات أو مشاركة NFS. تختلف هذه الحصص بالنسبة للأقراص المستضافة على حلول تخزين كتل Azure أو مشاركاتها المختلفة. يختلف زمن انتقال الإدخال / الإخراج أيضا بين أنواع التخزين المختلفة هذه أيضا.

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

إشعار

بالنسبة إلى عمليات نشر DBMS، نوصي بشدة بتخزين Azure المتميز (v1 وv2) أو قرص Ultra أو مشاركات NFS المستندة إلى ملفات Azure NetApp لأي بيانات أو سجل معاملات أو ملفات إعادة. لا يهم ما إذا كنت ترغب في نشر أنظمة الإنتاج أو غير الإنتاج. زمن انتقال Azure Standard HDD أو SSD غير مقبول لأي نوع من أنواع نظام الإنتاج.

إشعار

لتحقيق أقصى قدر من اتفاقية مستوى الخدمة لجهاز Azure الظاهري الفردي، يجب أن تكون جميع الأقراص المرفقة تخزينا متميزا من Azure (v1 أو v2) أو نوع قرص Azure Ultra، والذي يتضمن VHD الأساسي (تخزين Azure premium).

إشعار

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

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

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

Windows storage striping Windows

نوصي باستخدام Windows مساحات التخزين لإنشاء مجموعات خطوط عبر العديد من محركات أقراص Azure VHD. استخدم Windows على الأقل Server 2012 R2 أو Windows Server 2016.

Linux storage striping ينكس

يتم دعم MDADM وإدارة وحدة التخزين المنطقية (LVM) فقط لإنشاء RAID برنامج على Linux. لمزيد من المعلومات، راجع:

بالنسبة إلى تخزين Azure premium v2 وقرص Ultra، قد لا يكون التخطيط ضروريا نظرا لأنه يمكنك تحديد IOPS ومعدل نقل القرص بشكل مستقل عن حجم القرص.

إشعار

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

الأقراص المدارة أو غير المدارة

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

هام

نظرا لمزايا الأقراص المدارة من Azure، فمن الإلزامي استخدام أقراص Azure المدارة لنشر نظام إدارة قواعد البيانات وتوزيع SAP بشكل عام.

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

التخزين المؤقت للأجهزة الظاهرية وأقراص البيانات

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

تفترض التوصيات التالية خصائص الإدخال/إخراج هذه DBMS القياسية:

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

بالنسبة ل Azure premium storage v1، توجد خيارات التخزين المؤقت التالية:

  • بلا
  • قراءة
  • قراءة/كتابة
  • لا يوجد + مسرع الكتابة، وهو فقط للأجهزة الظاهرية لـ Azure M-Series
  • مسرع الكتابة + القراءة، وهو فقط للأجهزة الظاهرية لـ Azure M-Series

بالنسبة للتخزين المتميز v1، نوصي باستخدام التخزين المؤقت للقراءة لملفات البيانات في قاعدة بيانات SAP واختيار عدم التخزين المؤقت لأقراص ملف (ملفات) السجل.

بالنسبة إلى عمليات توزيع M-Series، نوصي باستخدام Azure Write Accelerator فقط لأقراص ملفات السجل الخاصة بك. للحصول على التفاصيل والقيود ونشر مسرع الكتابة Azure، راجع تمكين مسرع الكتابة.

بالنسبة للتخزين المتميز v2 والقرص Ultra وملفات Azure NetApp، لا يتم تقديم خيارات التخزين المؤقت.

أقراص Azure غير الثابتة

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

لمزيد من المعلومات، راجع فهم محرك الأقراص المؤقت على الأجهزة الظاهرية Windows في Azure.

Windows nonpersisted disk Windows

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

Linuxnonpersisted disk ينكس

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

مرونة تخزين Microsoft Azure

يقوم Microsoft Azure Storage بتخزين VHD الأساسي، مع نظام التشغيل والأقراص أو النقط المرفقة، على ثلاث عقد تخزين منفصلة على الأقل. يسمى هذا النوع من التخزين الزائد محليا (LRS). LRS هو الافتراضي لكافة أنواع التخزين في Azure.

هناك طرق أخرى للتكرار. للحصول على مزيدٍ من المعلومات، راجع النسخ المتماثل لـ Azure Storage.

إشعار

Azure premium storage v1 وv2 و Ultra disk وAzure NetApp Files هي نوع التخزين الموصى به لأجهزة DBMS الظاهرية والأقراص التي تخزن قاعدة البيانات وتسجيل الملفات وإعادة الملفات. باستثناء التخزين المتميز v1، فإن أسلوب التكرار الوحيد المتاح أنواع التخزين هذه هو LRS. ونتيجة لذلك، تحتاج إلى تكوين أساليب قاعدة البيانات لتمكين النسخ المتماثل لبيانات قاعدة البيانات في منطقة Azure أخرى أو منطقة توافر الخدمات. تتضمن طرق قاعدة البيانات SQL Server Always On و Oracle Data Guard و HANA System Replication.

مرونة عقدة VM

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

الحد الأدنى للتوصية لسيناريوهات DBMS للإنتاج مع حمل عمل SAP هو:

  • توزيع جهازين ظاهريين باستخدام نوع النشر المختار في نفس منطقة Azure.
  • قم بتشغيل هذين الجهازين الظاهريين في نفس شبكة Azure الظاهرية وقم بتوصيل NICs من نفس الشبكات الفرعية.
  • استخدم أساليب قاعدة البيانات للحفاظ على وضع الاستعداد السريع مع الجهاز الظاهري الثاني. يمكن SQL Server "التشغيل دائما" أو "Oracle Data Guard" أو "النسخ المتماثل لنظام HANA".

يمكنك أيضا نشر جهاز ظاهري ثالث في منطقة Azure أخرى واستخدام نفس أساليب قاعدة البيانات لتوفير نسخة متماثلة غير متزامنة في منطقة Azure أخرى.

اعتبارات شبكة Azure

في عمليات نشر SAP واسعة النطاق، استخدم مخطط Azure Virtual Datacenter. استخدمه لتكوين الشبكة الظاهرية والأذونات وتعيينات الأدوار لأجزاء مختلفة من مؤسستك.

هذه أفضل الممارسات هي نتيجة لآلاف عمليات نشر العملاء:

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

إشعار

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

التحذير

تكوين الأجهزة الظاهرية للشبكة في مسار الاتصال بين تطبيق SAP وطبقة DBMS لنظام SAP NetWeaver-أو Hybris-أو S/4HANA غير مدعوم. هذا التقييد لأسباب متعلقة بالوظائف والأداء. يجب أن يكون مسار الاتصال بين طبقة تطبيق SAP وطبقة DBMS مسارًا مباشرًا. لا يتضمن التقييد قواعد مجموعة أمان التطبيقات (ASG) وNSG إذا كانت قواعد ASG وNSG تسمح بمسار اتصال مباشر. يتضمن ذلك أيضا حركة المرور إلى مشاركات NFS التي تستضيف بيانات DBMS وإعادة ملفات السجل.

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

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

هام

تصميم آخر غير مدعوم هو فصل بين طبقة تطبيق SAP وطبقة DBMS في شبكات Azure الظاهرية المختلفة التي لا تتشابه مع بعضها البعض. نوصي بفصل طبقة تطبيق SAP وطبقة DBMS باستخدام شبكات فرعية داخل شبكة اتصال ظاهرية Azure بدلا من استخدام شبكات اتصال ظاهرية Azure مختلفة.

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

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

استخدام Azure Load Balancer لإعادة توجيه نسبة استخدام الشبكة

يتطلب استخدام عناوين IP الظاهرية الخاصة المستخدمة في وظائف مثل SQL Server Always On أوHANA System Replication تكوين موازن تحميل Azure. يستخدم موازن التحميل منافذ التحقيق لتحديد عقدة DBMS النشطة وتوجيه حركة المرور بشكل خاص إلى عقدة قاعدة البيانات النشطة تلك.

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

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

يمكن العثور على مثال على كيفية تكوين موازن تحميل داخلي في المقالة البرنامج التعليمي: تكوين مجموعة توفر SQL Server على أجهزة Azure الظاهرية يدويا

إشعار

هناك اختلافات في سلوك SKU الأساسي والقياسي المتعلق بالوصول إلى عناوين IP العامة. يتم وصف طريقة التغلب على قيود SKU القياسية للوصول إلى عناوين IP العامة في المستند اتصال نقطة النهاية العامة للأجهزة الظاهرية باستخدام Azure Standard Load Balancer في سيناريوهات SAP عالية التوفر

نشر مراقبة المضيف

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

لمزيد من المعلومات حول نشر المكونات التي توفر بيانات المضيف إلى SAPOSCOL وSAP Host Agent وإدارة دورة حياة هذه المكونات، ابدأ بالمقالة تنفيذ ملحق Azure VM لحلول SAP.

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

لمزيد من المعلومات حول نظام إدارة قواعد بيانات معين، راجع: