نشر نظام إدارة قواعد البيانات للأجهزة الظاهرية لـ SQL Server Azure لـ SAP NetWeaver
يغطي هذا المستند العديد من المجالات المختلفة التي يجب مراعاتها عند نشر SQL Server لحمل عمل SAP في خدمة تأجير البنية التحتية لـ Azure. كشرط مسبق لهذا المستند، اقرأ المستند اعتبارات نشر Azure Virtual Machines DBMS لحمل عمل SAP وأدلة أخرى في حمل عمل SAP على وثائق Azure.
هام
نطاق هذا المستند هو إصدار Windows على SQL Server. لا يدعم SAP إصدار Linux من SQL Server مع أي من برامج SAP. لا يناقش المستند قاعدة بيانات Microsoft Azure SQL، وهي عبارة عن نظام أساسي كعرض خدمة للنظام الأساسي من Microsoft Azure Platform. تدور المناقشة في هذه الورقة حول تشغيل منتج SQL Server كما هو معروف بعمليات النشر المحلية في الأجهزة الظاهرية من Azure، والاستفادة من خدمة تأجير البنية التحتية في Azure. تختلف قدرات ووظائف قاعدة البيانات بين هذين العرضين ولا ينبغي الخلط بينها وبين بعضهما. لمزيد من المعلومات، راجع Azure SQL Database .
وبوجه عام، يجب أن تفكر في استخدام أحدث إصدارات SQL Server لتشغيل حمل عمل SAP في خدمة تأجير البنية التحتية لـ Azure. توفر أحدث إصدارات SQL Server تكاملاً أفضل مع بعض خدمات Azure ووظائفه. أو لديك تغييرات تعمل على تحسين العمليات في البنية الأساسية لـAzure IaaS.
يمكن العثور على وثائق عامة حول SQL Server الذي يعمل في أجهزة Azure الظاهرية (VM) في هذه المقالات:
- SQL Server على أجهزة Azure الظاهرية (Windows)
- أتمتة الإدارة باستخدام ملحق Windows SQL Server IaaS Agent
- تكوين تكامل Azure Key Vault ل SQL Server على أجهزة Azure الظاهرية (Resource Manager)
- قائمة الاختيار: أفضل الممارسات ل SQL Server على أجهزة Azure الظاهرية
- التخزين: أفضل ممارسات الأداء ل SQL Server على أجهزة Azure الظاهرية
- أفضل ممارسات تكوين HADR (SQL Server على أجهزة Azure الظاهرية)
لا تنطبق جميع المحتويات والعبارات التي تم إجراؤها في وثائق SQL Server العامة في Azure VM على حمل عمل SAP. ولكن الوثائق تعطي انطباعا جيدا حول المبادئ. مثال على الوظائف غير المدعومة لحمل عمل SAP هو استخدام تجميع FCI.
يوجد بعض المعلومات الخاصة بـ SQL Server في خدمة تأجير البنية التحتية يجب أن تعرفها قبل المتابعة:
- دعم إصدار SQL: حتى مع ملاحظة SAP #1928533 تفيد بأن الحد الأدنى من إصدار SQL Server المدعوم هو SQL Server 2008 R2، يتم إملاء نافذة إصدارات SQL Server المدعومة على Azure أيضا مع دورة حياة SQL Server. انتهت الصيانة الممتدة ل SQL Server 2012 منتصف عام 2022. ونتيجة لذلك، يجب أن يكون الحد الأدنى الحالي للإصدار للأنظمة المنشورة حديثا هو SQL Server 2014. كلما كان أحدث، كان ذلك أفضل. توفر أحدث إصدارات SQL Server تكاملاً أفضل مع بعض خدمات Azure ووظائفه. أو لديك تغييرات تعمل على تحسين العمليات في البنية الأساسية لـAzure IaaS.
- استخدام الصور من Azure Marketplace: أسرع طريقة لنشر الجهاز الظاهري من Microsoft Azure الجديد هي استخدام صورة من Azure Marketplace. توجد صور في Azure Marketplace، والتي تحتوي على أحدث إصدارات SQL Server. لا يمكن استخدام الصور المثبت عليها SQL Server بالفعل لتطبيقات SAP NetWeaver. والسبب هو أن ترتيب SQL Server الافتراضي مثبت داخل تلك الصور وليس الترتيب المطلوب لأنظمة SAP NetWeaver. لاستخدام هذه الصور، تحقق من الخطوات الموثقة في الفصل استخدام صورة SQL Server من Microsoft Azure Marketplace.
- دعم المثيل المتعدد لـ SQL Server داخل جهاز ظاهري واحد من Azure: يتم دعم طريقة النشر هذه. ومع ذلك، يجب أن تكون مدركًا لقيود الموارد، خاصة حول النطاق الترددي للشبكة والتخزين لنوع الجهاز الظاهري الذي تستخدمه. تُتاح معلومات مفصلة في المقالة أحجام الأجهزة الظاهرية في Azure. قد تمنعك قيود الحصة النسبية هذه من تنفيذ نفس البنية متعددة المثيلات التي يمكنك تنفيذها محليًا. اعتبارًا من التكوين والتدخل في مشاركة الموارد المتاحة داخل جهاز افتراضي واحد، يجب مراعاة نفس الاعتبارات التي يتم إجراؤها محليًا.
- قواعد بيانات SAP متعددة في مثيل SQL Server واحد في جهاز ظاهري واحد: يتم دعم تكوينات مثل هذه. الاعتبارات الخاصة بقواعد بيانات SAP المتعددة التي تشارك الموارد المشتركة لمثيل SQL Server واحد هي نفسها بالنسبة لعمليات النشر المحلية. ضع حدودا أخرى مثل عدد الأقراص التي يمكن إرفاقها بنوع جهاز ظاهري معين في الاعتبار. أومساحة القرص المتوفرة للشبكة والتخزين لأنواع أجهزة ظاهرية معينة كأحجام تفصيلية للأجهزة الظاهرية في Azure.
الأجهزة الظاهرية الجديدة من سلسلة M وSQL Server
أصدرت Azure بعض العائلات الجديدة من وحدات SKU من سلسلة M ضمن عائلة Mv3. لا يجب استخدام بعض أنواع الأجهزة الظاهرية في هذه العائلة ل SQL Server، بما في ذلك SQL Server 2022 دون تعطيل SMT (Hyperthreading) في نظام التشغيل الضيف ل Windows Server. السبب هو عدد عقد NUMA المقدمة في نظام التشغيل الضيف Windows Server الذي مع أكبر من 64 vCPUs كبير جدا ل SQL Server لاستيعاب. من خلال تعطيل SMT في نظام التشغيل الضيف ل Windows Server، يتم تقليل عدد وحدات vCPUs. لذلك، فإن عدد وحدات vCPUs أقل من 64 في كل عقدة NUMA. يتم وصف طريقة تعطيل SMT هنا. أنواع الأجهزة الظاهرية المحددة هي:
- M176(d)s_3_v3 - تعطيل SMT أو استخدام M176bds_4_v3 أو M176bds_4_v3 كبديل
- M176(d)s_4_v3 - تعطيل SMT أو استخدام M176bds_4_v3 كبديل
- M624(d)s_12_v3 - تعطيل SMT أو استخدام M416ms_v2 كبديل
- M832(d)s_12_v3 - تعطيل SMT أو استخدام M416ms_v2 كبديل
- M832i(d)s_16_v3 - تعطيل SMT أو استخدام M416ms_v2 كبديل
إشعار
مع بعض أنواع M(b)v3 VM الجديدة، يمكن أن يؤدي استخدام تخزين Premium SSD v1 المخزن مؤقتا للقراءة إلى معدلات قراءة وكتابة IOPS ومعدل نقل أقل مما ستحصل عليه إذا كنت لا تستخدم ذاكرة التخزين المؤقت للقراءة.
توصيات بشأن بنية VM/VHD لعمليات نشر SQL Server المتعلقة بـ SAP
وفقًا للوصف العام، ونظام التشغيل، والملفات التنفيذية لـ SQL Server، يجب تحديد موقع ملفات SAP التنفيذية أو تثبيتها على أقراص Azure المنفصلة. عادة، لا يتم استخدام معظم قواعد بيانات نظام SQL Server على مستوى عال مع حمل عمل SAP NetWeaver. ومع ذلك، يجب أن تكون قواعد بيانات نظام SQL Server بالإضافة إلى دلائل SQL Server الأخرى على قرص Azure المنفصل. يجب أن يكون SQL Server tempdb موجودًا على محرك الأقراص D:\ غير المستمر أو على قرص منفصل.
- مع جميع أنواع الأجهزة الظاهرية المعتمدة من SAP (راجع ملاحظة SAP #1928533)، يمكن وضع بيانات tempdb وملفات السجل على محرك الأقراص غير المعرف D:\ .
- مع إصدارات SQL Server، حيث يقوم SQL Server بتثبيت tempdb بملف بيانات واحد فقط، يوصى باستخدام ملفات بيانات tempdb متعددة. كن على علم بأن وحدات تخزين محرك الأقراص D:\ مختلفة من حيث الحجم والقدرات استنادا إلى نوع الجهاز الظاهري. للحصول على الأحجام الدقيقة لمحرك الأقراص D:\ الخاص بالأجهزة الظاهرية المختلفة، راجع المقالة أحجام أجهزة Windows الافتراضية في Azure.
تمكّن هذه التكوينات tempdb من استهلاك مساحة أكبر وعمليات إدخال / إخراج أكثر أهمية في الثانية (IOPS) وعرض نطاق تخزين أكبر مما يستطيع محرك أقراص النظام توفيره. يوفر محرك الأقراص غير الحالي D:\ أيضا زمن انتقال ومعدل نقل أفضل في الإدخال/الإخراج. لتحديد حجم tempdb المناسب، يمكنك التحقق من أحجام tempdb على الأنظمة الموجودة.
إشعار
في حالة وضع ملفات بيانات tempdb وملف السجل في مجلد على محرك الأقراص D:\ الذي أنشأته، فيجب أن تتأكد من وجود المجلد بعد إعادة تشغيل الجهاز الظاهري. نظرا لأنه يمكن تهيئة محرك الأقراص D:\ حديثا بعد أن يتم مسح إعادة تشغيل الجهاز الظاهري لجميع بنيات الملفات والدليل. يتم توثيق إمكانية إعادة إنشاء بنيات الدليل النهائية على محرك الأقراص D:\ قبل بدء خدمة SQL Server في هذه المقالة.
تكوين الجهاز الظاهري، الذي يقوم بتشغيل SQL Server مع قاعدة بيانات SAP وحيث يتم وضع بيانات tempdb و tempdb logfile على محرك الأقراص D:\ وسيبدو تخزين Azure premium v1 أو v2 كما يلي:
يعرض الرسم التخطيطي حالة بسيطة. وكما ذُكر في المقالة الاعتبارات الخاصة بنشر نظام إدارة قواعد البيانات (DBMS) المتعلق بأجهزة Azure الظاهرية لـ SQL Server الخاص بحمل عمل SAP، يعتمد نوع تخزين Azure وعدد الأقراص وحجمها على عوامل مختلفة. ولكن بوجه عام نوصي بما يلي:
- بالنسبة إلى عمليات النشر الأصغر والمتوسطة النطاق، باستخدام وحدة تخزين كبيرة واحدة، والتي تحتوي على ملفات بيانات SQL Server. السبب وراء هذا التكوين هو أنه من الأسهل التعامل مع أحمال عمل الإدخال/الإخراج المختلفة في حالة عدم وجود نفس المساحة الحرة لملفات بيانات SQL Server. في حين أنه في عمليات النشر الكبيرة، خاصة عمليات التوزيع حيث انتقل العميل مع ترحيل قاعدة بيانات غير متجانسة إلى SQL Server في Azure، استخدمنا أقراصا منفصلة ثم وزعنا ملفات البيانات عبر تلك الأقراص. هذه البنية ناجحة فقط عندما يحتوي كل قرص على نفس عدد ملفات البيانات، وتكون جميع ملفات البيانات بنفس الحجم، ولها تقريبا نفس المساحة الحرة.
- استخدم محرك الأقراص D:\ لـ tempdb طالما أن الأداء جيد بدرجة كفاية. إذا كان حمل العمل الإجمالي محدودا في أداء tempdb الموجود على محرك الأقراص D:\ ، فستحتاج إلى نقل tempdb إلى تخزين Azure المتميز v1 أو v2، أو قرص Ultra كما هو موصى به في هذه المقالة.
تقوم آلية التعبئة النسبية لـ SQL Server بتوزيع عمليات القراءة والكتابة على جميع ملفات البيانات بالتساوي بشرط أن تكون جميع ملفات بيانات SQL Server بنفس الحجم ولها نفس سرعة التحرر. يوفر SAP على SQL Server أفضل أداء عند توزيع القراءات والكتابة بالتساوي عبر جميع ملفات البيانات المتوفرة. إذا كانت قاعدة البيانات تحتوي على عدد قليل جدا من ملفات البيانات أو كانت ملفات البيانات الموجودة غير متوازنة للغاية، فإن أفضل طريقة لتصحيحها هي تصدير R3load واستيراده. يتضمن تصدير واستيراد R3load فترة تعطل ويجب أن يحدث ذلك فقط إذا كانت هناك مشكلة واضحة في الأداء تحتاج إلى حل. إذا كانت ملفات البيانات مختلفة بأحجام معتدلة فقط، فقم بزيادة جميع ملفات البيانات إلى نفس الحجم، ويعيد SQL Server التوازن بين البيانات بمرور الوقت. يقوم SQL Server تلقائيا بتنمية ملفات البيانات بالتساوي إذا تم تعيين علامة التتبع 1117 أو إذا تم استخدام SQL Server 2016 أو أعلى دون علامة تتبع.
خاص بالأجهزة الظاهرية من الفئة M
بالنسبة إلى Azure M-Series VM، يمكن تقليل زمن الانتقال للكتابة في سجل المعاملات، مقارنة بأداء تخزين Azure المتميز v1، عند استخدام Azure Write Accelerator. إذا كان زمن الانتقال الذي يوفره التخزين المتميز v1 يحد من قابلية توسع حمل عمل SAP، يمكن تمكين القرص الذي يخزن ملف سجل معاملات SQL Server ل Write Accelerator. يمكن قراءة التفاصيل في المستند مسرع الكتابة. لا يعمل Azure Write Accelerator مع تخزين Azure premium v2 وقرص Ultra. في كلتا الحالتين، يكون زمن الانتقال أفضل مما يقدمه Azure premium storage v1. لا يدعم Write Accelerator الإصدار 2 من Premium SSD.
إشعار
مع بعض أنواع M(b)v3 VM الجديدة، يمكن أن يؤدي استخدام تخزين Premium SSD v1 المخزن مؤقتا للقراءة إلى معدلات قراءة وكتابة IOPS ومعدل نقل أقل مما ستحصل عليه إذا كنت لا تستخدم ذاكرة التخزين المؤقت للقراءة.
تنسيق الأقراص
بالنسبة SQL Server، يجب أن يكون حجم كتلة NTFS للأقراص التي تحتوي على بيانات SQL Server وملفات السجل 64 كيلوبايت. لا تستدعي الحاجة لتهيئة محرك الأقراص D:\. يأتي محرك الأقراص هذا منسقا مسبقا.
لتجنب أن استعادة أو إنشاء قواعد البيانات هو تهيئة ملفات البيانات عن طريق صفر محتوى الملفات، تأكد من أن سياق المستخدم الذي تعمل فيه خدمة SQL Server لديه مهام صيانة وحدة التخزين "أداء المستخدم الصحيح". لمزيد من المعلومات، راجع Database instant file initialization.
SQL Server 2014 وإصدارات SQL Server الأحدث - تخزين ملفات قاعدة البيانات مباشرة على Azure Blob Storage
يفتح SQL Server 2014 والإصدارات الأحدث إمكانية تخزين ملفات قاعدة البيانات مباشرة على Azure Blob Store دون "مجمّع" VHD حولها. كان المقصود من هذه الوظيفة معالجة أوجه القصور في تخزين كتلة Azure قبل سنوات. في هذه الأيام، لا يوصى باستخدام أسلوب النشر هذا وبدلا من ذلك اختر إما تخزين Azure premium v1 أو التخزين المتميز v2 أو قرص Ultra. تعتمد على المتطلبات.
اعتبارات النسخ الاحتياطي / الاسترداد لـ SQL Server
نشر SQL Server في Azure، تحتاج إلى مراجعة بنية النسخ الاحتياطي. حتى إذا لم يكن النظام نظام إنتاج، يجب نسخ قاعدة بيانات SQL Server SAP احتياطيا بشكل دوري. نظرًا لأن Azure Storage يحتفظ بثلاث صور، فإن النسخ الاحتياطي أصبح الآن أقل أهمية فيما يتعلق بتعويض تعطل التخزين. يعد سبب الأولوية للحفاظ على خطة النسخ الاحتياطي والاسترداد المناسبة أمرا مهما لوظيفة استرداد النقطة الزمنية للتعويض عن الأخطاء المنطقية/اليدوية. الهدف هو إما استخدام النسخ الاحتياطية لاستعادة قاعدة البيانات مرة أخرى إلى نقطة زمنية معينة. أو لاستخدام النسخ الاحتياطية في Azure لزرع نظام آخر مع نسخ النسخ الاحتياطي لقاعدة البيانات الموجودة.
هناك عدة طرق لنسخ قواعد بيانات SQL Server احتياطيا واستعادتها في Azure. للحصول على أفضل نظرة عامة وتفاصيل، اقرأ المستند النسخ الاحتياطي والاستعادة ل SQL Server على أجهزة Azure الظاهرية. تتناول المقالة عدة احتمالات مختلفة.
استخدام صورة SQL Server خارج Microsoft Azure Marketplace
تقدم Microsoft أجهزة ظاهرية في Azure Marketplace، والتي تحتوي بالفعل على إصدارات من SQL Server. بالنسبة لعملاء SAP الذين يطلبون تراخيص لـ SQL Server و Windows، قد يكون استخدام هذه الصور فرصة لتغطية الحاجة إلى التراخيص عن طريق تدوير أجهزة ظاهرية مثبتة بالفعل مع SQL Server. من أجل استخدام مثل هذه الصور لـ SAP، يجب مراعاة الاعتبارات التالية:
- تحصل إصدارات SQL Server غير التقييمية على تكاليف أعلى من الأجهزة الظاهرية لـ "Windows فقط" التي تم نشرها من Azure Marketplace. لمقارنة الأسعار، راجع Windows Virtual Machines Pricing و SQL Server Enterprise Virtual Machines Pricing.
- يمكنك فقط استخدام إصدارات SQL Server، والتي يدعمها SAP لبرامجهم.
- لا يعتبر ترتيب مثيل SQL Server، المثبت في الأجهزة الظاهرية المتوفرة في Azure Marketplace، هو الترتيب الذي يتطلبه SAP NetWeaver لتشغيل مثيل SQL Server. يمكنك تغيير الترتيب من خلال التوجيهات في القسم التالي.
تغيير ترتيب SQL Server من Microsoft Windows / SQL Server VM
نظرا لأن صور SQL Server في Azure Marketplace لم يتم إعدادها لاستخدام الترتيب، وهو مطلوب لتطبيقات SAP NetWeaver، يجب تغييرها مباشرة بعد التوزيع. بالنسبة لـ SQL Server، يمكن إجراء هذا التغيير في الترتيب من خلال الخطوات التالية بمجرد نشر الجهاز الظاهري ويكون المسؤول قادرًا على تسجيل الدخول إلى الجهاز الظاهري المنشور:
- افتح نافذة أوامر Windows، كمسؤول.
- تغيير الدليل إلى C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\SQLServer2012.
- تنفيذ الأمر: Setup.exe /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS=
<local_admin_account_name> /SQLCOLLATION=SQL_Latin1_General_Cp850_BIN2<local_admin_account_name> هو الحساب، الذي تم تعريفه على أنه حساب المسؤول عند نشر الجهاز الظاهري لأول مرة من خلال المعرض.
يجب أن تستغرق العملية بضع دقائق فقط. للتأكد مما إذا كانت الخطوة انتهت بالنتيجة الصحيحة، قم بتنفيذ الخطوات التالية:
- فتح SQL Server Management Studio.
- افتح نافذة استعلام.
- قم بتنفيذ الأمر sp_helpsort في قاعدة بيانات SQL Server الرئيسية.
يجب أن تبدو النتيجة المرجوة كما يلي:
Latin1-General, binary code point comparison sort for Unicode Data, SQL Server Sort Order 40 on Code Page 850 for non-Unicode Data
إذا كانت النتيجة مختلفة، فتوقف عن أي نشر وتحقق من سبب عدم عمل أمر الإعداد كما هو متوقع. توزيع تطبيقات SAP NetWeaver على مثيل SQL Server مع صفحات ترميز SQL Server مختلفة عن تلك المذكورة غير مدعومة لنشر NetWeaver.
توافر عالي لـ SQL Server لـ SAP في Azure
باستخدام SQL Server في عمليات نشر Azure IaaS ل SAP، لديك العديد من الاحتمالات المختلفة لإضافتها لنشر طبقة قاعدة البيانات المتوفرة بشكل كبير. يوفر Azure اتفاقيات مستوى خدمة مختلفة لفترة زمنية لجهاز ظاهري واحد باستخدام مخازن كتلة Azure مختلفة، أو زوج من الأجهزة الظاهرية المنشورة في مجموعة توفر Azure، أو زوج من الأجهزة الظاهرية المنشورة عبر مناطق توفر Azure. بالنسبة لأنظمة الإنتاج، نتوقع منك نشر زوج من الأجهزة الظاهرية ضمن مجموعة مقياس الجهاز الظاهري مع تزامن مرن عبر منطقتين للتوفر. راجع مقارنة أنواع النشر المختلفة لحمل عمل SAP لمزيد من المعلومات. يقوم جهاز ظاهري واحد بتشغيل مثيل SQL Server النشط. يقوم الجهاز الظاهري الآخر بتشغيل المثيل السلبي
تجميع SQL Server باستخدام خادم ملفات لتوسيع استخدام Windows أو القرص المشترك في Azure
وباستخدام Windows Server 2016، قدمت Microsoft مساحات التخزين المباشرة. استنادًا إلى مساحات التخزين، النشر المباشر، يتم دعم مجموعات SQL Server FCI بشكل عام. يوفر Azure أيضًا أقراص Azure المشتركة التي يمكن استخدامها لتجميع Windows. بالنسبة لحمل عمل SAP، لا ندعم خيارات قابلية الوصول العالية هذه.
نسخ متواصل لسجل SQL Server
تتمثل إحدى وظائف قابلية الوصول العالية في شحن سجل SQL Server. إذا كانت الأجهزة الظاهرية المشاركة في تكوين قابلية الوصول العالية (HA) تمتلك تحليل اسم صالح، فلا توجد مشكلة. لا يختلف الإعداد في Azure عن أي إعداد يتم في الموقع فيما يتعلق بإعداد شحن السجل والمبادئ المتعلقة بشحن السجل. يمكن العثور على تفاصيل شحن سجل SQL Server في المقالة حول Log Shipping (SQL Server).
نادرًا ما يجري استخدام وظيفة النسخ المتواصل للسجل لـ SQL Server في Azure لتحقيق قابلية وصول عالية داخل منطقة Azure واحدة. ومع ذلك، في السيناريوهات التالية، كان عملاء SAP يستخدمون النسخ المتواصل للسجل بنجاح مع Azure:
- سيناريوهات الإصلاح بعد كارثة من منطقة Azure إلى منطقة Azure أخرى
- تكوين "الإصلاح بعد كارثة" من البيئة المحلية في منطقة Azure
- سيناريوهات القطع من البيئة المحلية إلى Azure. في هذه الحالات، يتم استخدام شحن السجل لمزامنة نشر قاعدة البيانات الجديدة في Azure مع نظام الإنتاج المحلي المستمر. في وقت التقليص، يتم إيقاف التشغيل، ويتم التأكد من نقل النسخ الاحتياطية الأخيرة والأخيرة لسجل المعاملات إلى نشر قاعدة بيانات Azure. ثم يتم فتح نشر قاعدة بيانات Azure للإنتاج.
SQL Server دائماً على
نظرا لأن Always On مدعوم ل SAP المحلي (راجع ملاحظة SAP #1772688)، فإنه مدعوم بالاشتراك مع SAP في Azure. هناك بعض الاعتبارات الخاصة حول نشر وحدة إصغاء مجموعة قابلية وصول عالية التوفر ل SQL Server (لا يجب الخلط بينها وبين مجموعة توفر Azure). لذلك، بعض خطوات التثبيت المختلفة ضرورية.
بعض الاعتبارات التي تستخدم مستمع مجموعة قابلية وصول عالية التوفر على النحو التالي:
- لا يمكن استخدام مستمع مجموعة قابلية وصول عالية التوفر إلا مع Windows Server 2012 أو نظام أعلى كضيف نظام التشغيل الجهاز الظاهري. بالنسبة إلى Windows Server 2012، تأكد من تطبيق update to enable SQL Server Availability Group Listeners on Windows Server 2008 R2 and Windows Server 2012-based Microsoft Azure virtual machines.
- بالنسبة إلى Windows Server 2008 R2، هذا التصحيح غير موجود. في هذه الحالة، يجب استخدام Always On بنفس طريقة النسخ المتطابق لقاعدة البيانات. عن طريق تحديد شريك تجاوز الفشل في سلسلة الاتصالات (تم ذلك من خلال معلمة SAP default.pfl dbs/mss/server - راجع ملاحظة SAP #965908).
- باستخدام مستمع مجموعة قابلية وصول عالية التوفر، تحتاج إلى توصيل أجهزة قاعدة البيانات الظاهرية بموازن تحميل مخصص. يجب تعيين عناوين IP ثابتة إلى واجهات الشبكة لتلك الأجهزة الظاهرية في تكوين Always On (يتم وصف تعريف عنوان IP ثابت في هذه المقالة). تمنع عناوين IP الثابتة مقارنة ب DHCP تعيين عناوين IP جديدة في الحالات التي قد يتم فيها إيقاف كلا الجهازين الظاهريين.
- هناك خطوات خاصة مطلوبة عند إنشاء تكوين مجموعة أجهزة كمبيوتر WSFC حيث تحتاج شبكة نظام المجموعة إلى عنوان IP خاص مُعيّن لأن Azure مع وظائفه الحالية يعيّن اسم شبكة نظام المجموعة نفس عنوان IP باعتبارها عُقدة تم إنشاء شبكة نظام المجموعة عليها. يعني هذا السلوك أنه يجب إجراء خطوة يدوية لتعيين عنوان IP مختلف للكتلة.
- يتم إنشاء مستمع مجموعة قابلية التوفر العالية في Azure مع نقاط النهاية TCP/IP التي تم تعيينها إلى الأجهزة الظاهرية لتشغيل النُسخ المتماثلة الأساسية والثانوية من مجموعة قابلية الوصول العالية.
- قد تكون تدعو الحاجة لتأمين نقاط النهاية هذه باستخدام قوائم ACL.
وثائق مفصلة حول نشر مجموعات قابلية وصول عالية التوفر Always On مع SQL Server في قوائم الأجهزة الظاهرية في Azure مثل:
- تقديم مجموعات توفر SQL Server Always On availability على أجهزة Azure الظاهرية.
- تكوين مجموعات قابلية وصول عالية التوفر Always On على أجهزة Azure الظاهرية في مناطق مختلفة.
- تكوين موازن التحميل لمجموعة توفر Always On في Azure.
- أفضل ممارسات تكوين HADR (SQL Server على أجهزة Azure الظاهرية)
إشعار
قراءة مقدمة حول مجموعات قابلية وصول عالية التوفر Always On لـ SQL Server المتوفرة على أجهزة Azure الظاهرية، ستقرأ عن وحدة استماع اسم الشبكة المباشر (DNN) الخاص بـ SQL Server. تم تقديم هذه الوظيفة الجديدة مع SQL Server 2019 CU8. تجعل هذه الوظيفة الجديدة استخدام موازنة تحميل Azure الذي يتعامل مع عنوان IP الظاهري لمستمع مجموعة قابلية وصول عالية التوفر أمرًا قديمًا.
يعد مجموعات قابلية وصول عالية التوفر Always On لـ SQL Server أكثر الوظائف المستخدمة شيوعًا للإتاحة العالية والتعافي من الكوارث المستخدمة في Azure لعمليات نشر حمل عمل SAP. يستخدم معظم العملاء ميزة مجموعات قابلية وصول عالية التوفر Always On لقابلية الوصول العالية داخل منطقة Azure مفردة. إذا كان التوزيع يقتصر على عُقدتين فقط، فلديك خياران للاتصال:
- استخدام مستمع مجموعة قابلية وصول عالية التوفر. باستخدام مستمع مجموعة قابلية وصول عالية التوفر، يلزمك نشر موازنة تحميل Azure.
- باستخدام إصدارات SQL Server 2016 SP3 أو SQL Server 2017 CU 25 أو SQL Server 2019 CU8 أو أحدث إصدارات SQL Server على Windows Server 2016 أو أحدث، يمكنك استخدام وحدة إصغاء اسم الشبكة المباشرة (DNN) بدلا من موازن تحميل Azure. يلغي DNN مطلب موازنة تحميل Azure.
يجب مراعاة استخدام معلمات الاتصال الخاصة ب SQL Server Database Mirroring فقط لجولة من التحقيق في المشكلات مع الطريقتين الأخريين. في هذه الحالة، تحتاج إلى تكوين اتصال تطبيقات SAP بطريقة يتم فيها تسمية كلا اسمي العقد. يتم توثيق التفاصيل الدقيقة لتكوين جانب SAP في مذكرة SAP #965908. باستخدام هذا الخيار، لن تحتاج إلى تكوين مستمع مجموعة قابلية وصول عالية التوفر. ومع ذلك لا يوجد موازن تحميل Azure ومع ذلك يمكن التحقيق في مشكلات هذه المكونات. لكن تذكر أن هذا الخيار لا يعمل إلا إذا قمت بتقييد مجموعة قابلية وصول عالية التوفر لتشمل مثيلين.
يستخدم معظم العملاء وظيفة SQL Server Always On لوظائف التعافي من الكوارث بين مناطق Azure. العديد من العملاء أيضاً لديهم القدرة على إجراء النسخ الاحتياطي من نسخة احتياطية متماثلة ثانوية.
تشفير البيانات الشفافة لـ SQL Server
يستخدم العديد من العملاء تشفير البيانات الشفافة لـ SQL Server (TDE) عند نشر قواعد بيانات SAP SQL Server في Azure. يتم دعم وظيفة SQL Server TDE بشكل كامل بواسطة SAP (راجع ملاحظة SAP #1380493).
تطبيق SQL Server TDE
في الحالات التي تقوم فيها بإجراء ترحيل غير متجانس من قاعدة بيانات أخرى، تعمل محليا، إلى Windows/SQL Server قيد التشغيل في Azure، يجب إنشاء قاعدة البيانات الهدف الفارغة في SQL Server مسبقا. كخطوة تالية، يمكنك تطبيق وظيفة SQL Server TDE على قاعدة البيانات الفارغة هذه. ويتمثل السبب الذي تريد تنفيذه في هذا التسلسل في أن عملية تشفير قاعدة البيانات الفارغة يمكن أن تستغرق بعض الوقت. ثم تقوم عمليات استيراد SAP باستيراد البيانات إلى قاعدة البيانات المشفرة في أثناء مرحلة التوقف. إن النفقات العامة للاستيراد إلى قاعدة بيانات مشفرة لها تأثير زمني أقل من تشفير قاعدة البيانات بعد مرحلة التصدير في مرحلة وقت التعطل. كانت هناك تجارب سلبية عند محاولة تطبيق تشفير البيانات الشفافة مع حمل العمل SAP الذي يعمل للتحكم بقاعدة البيانات. لذلك، فإن التوصية هي التعامل مع نشر TDE كنشاز يجب القيام به بدون أو حمل عمل SAP منخفض على قاعدة بيانات معينة. من تشغيل SQL Server 2016، يمكنك إيقاف واستئناف فحص TDE الذي يقوم بالتشفير الأولي. يصف المستند تشفير البيانات الشفاف (TDE) الأمر والتفاصيل.
في الحالات التي تقوم فيها بنقل قواعد بيانات SAP SQL Server محليًا إلى Azure، نوصي باختبار البنية الأساسية التي يمكنك تطبيق التشفير فيها أسرع. في هذه الحالة، ضع هذه الحقائق في الاعتبار:
- لا يمكنك تحديد عدد مؤشرات الترابط المستخدمة لتطبيق تشفير البيانات بقاعدة البيانات. عدد مؤشرات الترابط بشكل رئيسي يعتمد على عدد وحدات تخزين القرص التي يتم توزيع بيانات SQL Server وملفات السجل فيها. يعني أنه كلما كانت وحدات التخزين أكثر تميزا (أحرف محرك الأقراص)، زاد عدد مؤشرات الترابط المنخرطة بالتوازي لتنفيذ التشفير. يتعارض هذا التكوين قليلاً مع اقتراح تكوين القرص السابق عند إنشاء مساحة تخزين مفردة أو عدد أصغر لملفات قاعدة بيانات SQL Server في الأجهزة الظاهرية لـ Azure. قد يؤدي التكوين مع وحدات تخزين قليلة إلى تنفيذ عدد قليل من سلاسل العمليات للتشفير. يقوم تشفير مؤشر ترابط مفرد بقراءة نطاقات 64 KB، وتشفيرها ثم كتابة سجل في ملف سجل المعاملات، لإعلامك بأن النطاق تم تشفيره. نتيجة لذلك، يكون الحمل في سجل المعاملات معتدلاً.
- في إصدارات SQL Server القديمة، لم يعد ضغط النسخ الاحتياطي يتمتع بالكفاءة بعد الآن عند تشفير قاعدة بيانات SQL Server. قد يتطور هذا السلوك إلى مشكلة عندما كانت الخطة الخاصة بك تشفير قاعدة بيانات SQL Server محليًا ثم نسخ نسخة احتياطية إلى Azure لاستعادة قاعدة البيانات في Azure. يمكن أن يحقق ضغط النسخ الاحتياطي ل SQL Server نسبة ضغط من العامل 4.
- مع SQL Server 2016، قدم SQL Server وظائف جديدة تسمح بضغط النسخ الاحتياطي لقواعد البيانات المشفرة بطريقة فعالة أيضا. راجع هذه المدونة للحصول على بعض التفاصيل.
استخدام Azure Key Vault
يقدم Azure خدمة Key Vault لتخزين مفاتيح التشفير. يوفر SQL Server على الجانب الآخر موصلاً لاستخدام Azure Key Vault كمخزن لشهادات TDE.
مزيد من التفاصيل لاستخدام Azure Key Vault لقوائم SQL Server TDE مثل:
- تكوين تكامل Azure Key Vault ل SQL Server على أجهزة Azure الظاهرية (Resource Manager).
- المزيد من الأسئلة من العملاء حول تشفير البيانات الشفافة لـ SQL Server - TDE + Azure Key Vault.
هام
باستخدام SQL Server TDE، خاصة مع Azure key Vault، يوصى باستخدام أحدث التصحيحات من SQL Server 2014 وSQL Server 2016 وSQL Server 2017. ويكمن السبب في أنه بناءً على ملاحظات العملاء، تم تطبيق التحسينات والإصلاحات على الكود. على سبيل المثال، تحقق من KBA #4058175.
الحد الأدنى من تكوينات التوزيع
في هذا القسم، نقترح مجموعة من التكوينات الدنيا لأحجام مختلفة من قواعد البيانات ضمن حمل عمل SAP. من الصعب جدا تقييم ما إذا كانت هذه الأحجام تناسب حمل العمل المحدد. في بعض الحالات، قد نكون سخيين في الذاكرة مقارنة بحجم قاعدة البيانات. على الجانب الآخر، قد يكون حجم القرص منخفضا جدا لبعض أحمال العمل. لذلك، يجب التعامل مع هذه التكوينات على أنها ما هي عليه. إنها تكوينات يجب أن تمنحك نقطة للبدء بها. تكوينات لضبط متطلبات حمل العمل وكفاءة التكلفة المحددة.
مثال على تكوين لمثيل SQL Server صغير بحجم قاعدة بيانات يتراوح بين 50 غيغابايت - 250 غيغابايت يمكن أن يبدو مثل
| التكوين | قاعدة البيانات VM | التعليقات |
|---|---|---|
| VM Type | E4s_v3/v4/v5 (4 وحدات معالجة مركزية افتراضية/ذاكرة وصول عشوائي 32 غيغابايت) | |
| تسريع الشبكات | تمكين | |
| إصدار SQL Server | SQL Server 2019 أو أحدث | |
| # من ملفات البيانات | 4 | |
| # من ملفات السجل | 1 | |
| # من ملفات البيانات المؤقتة | 4 أو افتراضي منذ SQL Server 2016 | |
| نظام التشغيل | Windows Server 2019 أو أحدث | |
| تجميع الأقراص | مساحات التخزين إذا رغبت في ذلك | |
| نظام الملفات | NTFS | |
| تنسيق حجم الكتلة | 64 كيلو بايت | |
| عدد ونوع أقراص البيانات | التخزين المتميز v1: 2 x P10 (RAID0) التخزين المتميز v2: 2 x 150 GiB (RAID0) - IOPS الافتراضي ومعدل النقل أو ما يعادله Premium SSD v2 |
ذاكرة التخزين المؤقت = للقراءة فقط للتخزين المتميز v1 |
| عدد ونوع أقراص السجل | التخزين المتميز v1: 1 × P20 Premium storage v2: 1 x 128 GiB - IOPS الافتراضي ومعدل النقل أو ما يعادله Premium SSD v2 |
ذاكرة التخزين المؤقت = لا شيء |
| معلمة الذاكرة القصوى ل SQL Server | 90٪ من ذاكرة الوصول العشوائي الفعلية | بافتراض مثيل واحد |
مثال على تكوين أو مثيل SQL Server صغير بحجم قاعدة بيانات يتراوح بين 250 غيغابايت - 750 غيغابايت، مثل نظام SAP Business Suite أصغر، يمكن أن يبدو مثل
| التكوين | قاعدة البيانات VM | التعليقات |
|---|---|---|
| VM Type | E16s_v3/v4/v5 (16 vCPU/128 GiB RAM) | |
| تسريع الشبكات | تمكين | |
| إصدار SQL Server | SQL Server 2019 أو أحدث | |
| # من ملفات البيانات | 8 | |
| # من ملفات السجل | 1 | |
| # من ملفات البيانات المؤقتة | 8 أو افتراضي منذ SQL Server 2016 | |
| نظام التشغيل | Windows Server 2019 أو أحدث | |
| تجميع الأقراص | مساحات التخزين إذا رغبت في ذلك | |
| نظام الملفات | NTFS | |
| تنسيق حجم الكتلة | 64 كيلو بايت | |
| عدد ونوع أقراص البيانات | التخزين المتميز v1: 4 × P20 (RAID0) التخزين المتميز v2: 4 × 100 جيبي بايت - 200 غيغابايت (RAID0) - IOPS الافتراضي ومعدل نقل إضافي 25 ميغابايت/ ثانية لكل قرص أو ما يعادله من Premium SSD v2 |
ذاكرة التخزين المؤقت = للقراءة فقط للتخزين المتميز v1 |
| عدد ونوع أقراص السجل | التخزين المتميز v1: 1 × P20 التخزين المتميز v2: 1 x 200 GiB - IOPS الافتراضي ومعدل النقل أو ما يعادله Premium SSD v2 |
ذاكرة التخزين المؤقت = لا شيء |
| معلمة الذاكرة القصوى ل SQL Server | 90٪ من ذاكرة الوصول العشوائي الفعلية | بافتراض مثيل واحد |
مثال على تكوين مثيل SQL Server متوسط بحجم قاعدة بيانات يتراوح بين 750 غيغابايت - 2000 غيغابايت، مثل نظام SAP Business Suite متوسط، يمكن أن يبدو مثل
| التكوين | قاعدة البيانات VM | التعليقات |
|---|---|---|
| VM Type | E64s_v3/v4/v5 (64 vCPU/432 GiB RAM) | |
| تسريع الشبكات | تمكين | |
| إصدار SQL Server | SQL Server 2019 أو أحدث | |
| عدد أجهزة البيانات | 16 | |
| عدد أجهزة السجل | 1 | |
| # من ملفات البيانات المؤقتة | 8 أو افتراضي منذ SQL Server 2016 | |
| نظام التشغيل | Windows Server 2019 أو أحدث | |
| تجميع الأقراص | مساحات التخزين إذا رغبت في ذلك | |
| نظام الملفات | NTFS | |
| تنسيق حجم الكتلة | 64 كيلو بايت | |
| عدد ونوع أقراص البيانات | التخزين المتميز v1: 4 × P30 (RAID0) التخزين المتميز v2: 4 × 250 غيغابايت - 500 جيبي بايت - بالإضافة إلى 2000 عملية الإدخال والإخراج في الثانية ومعدل نقل 75 ميغابايت/ ثانية لكل قرص أو ما يعادله من Premium SSD v2 |
ذاكرة التخزين المؤقت = للقراءة فقط للتخزين المتميز v1 |
| عدد ونوع أقراص السجل | التخزين المتميز v1: 1 × P20 Premium storage v2: 1 x 400 GiB - IOPS الافتراضي ومعدل نقل إضافي 75 ميغابايت/ثانية أو ما يعادل Premium SSD v2 |
ذاكرة التخزين المؤقت = لا شيء |
| معلمة الذاكرة القصوى ل SQL Server | 90٪ من ذاكرة الوصول العشوائي الفعلية | بافتراض مثيل واحد |
مثال على تكوين مثيل SQL Server أكبر بحجم قاعدة بيانات يتراوح بين 2000 غيغابايت و4000 غيغابايت، مثل نظام SAP Business Suite أكبر، يمكن أن يبدو مثل
| التكوين | قاعدة البيانات VM | التعليقات |
|---|---|---|
| VM Type | E96(d)s_v5 (96 vCPU/672 GiB RAM) | |
| تسريع الشبكات | تمكين | |
| إصدار SQL Server | SQL Server 2019 أو أحدث | |
| عدد أجهزة البيانات | 24 | |
| عدد أجهزة السجل | 1 | |
| # من ملفات البيانات المؤقتة | 8 أو افتراضي منذ SQL Server 2016 | |
| نظام التشغيل | Windows Server 2019 أو أحدث | |
| تجميع الأقراص | مساحات التخزين إذا رغبت في ذلك | |
| نظام الملفات | NTFS | |
| تنسيق حجم الكتلة | 64 كيلو بايت | |
| عدد ونوع أقراص البيانات | التخزين المتميز v1: 4 × P30 (RAID0) التخزين المتميز v2: 4 × 500 غيغابايت - 800 جيبي بايت - بالإضافة إلى 2500 IOPS ومعدل نقل 100 ميغابايت/ ثانية لكل قرص أو ما يعادله من Premium SSD v2 |
ذاكرة التخزين المؤقت = للقراءة فقط للتخزين المتميز v1 |
| عدد ونوع أقراص السجل | التخزين المتميز v1: 1 × P20 التخزين المتميز v2: 1 × 400 جيبي بايت - بالإضافة إلى 1000 IOPS ومعدل نقل إضافي 75 ميغابايت/ثانية أو ما يعادله من Premium SSD v2 |
ذاكرة التخزين المؤقت = لا شيء |
| معلمة الذاكرة القصوى ل SQL Server | 90٪ من ذاكرة الوصول العشوائي الفعلية | بافتراض مثيل واحد |
مثال على تكوين مثيل SQL Server كبير بحجم قاعدة بيانات 4 تيرابايت+، مثل نظام SAP Business Suite كبير مستخدم عالميا، يمكن أن يبدو مثل
| التكوين | قاعدة البيانات VM | التعليقات |
|---|---|---|
| VM Type | الفئة M (ذاكرة وصول عشوائي من 1.0 إلى 4.0 تيرابايت) | |
| تسريع الشبكات | تمكين | |
| إصدار SQL Server | SQL Server 2019 أو أحدث | |
| عدد أجهزة البيانات | 32 | |
| عدد أجهزة السجل | 1 | |
| # من ملفات البيانات المؤقتة | 8 أو افتراضي منذ SQL Server 2016 | |
| نظام التشغيل | Windows Server 2019 أو أحدث | |
| تجميع الأقراص | مساحات التخزين إذا رغبت في ذلك | |
| نظام الملفات | NTFS | |
| تنسيق حجم الكتلة | 64 كيلو بايت | |
| عدد ونوع أقراص البيانات | التخزين المتميز v1: 4+ x P40 (RAID0) التخزين المتميز v2: 4+ × 1000 غيغابايت - 4000 جيبي بايت - بالإضافة إلى 4500 IOPS ومعدل نقل 125 ميغابايت/ثانية لكل قرص أو ما يعادله من Premium SSD v2 |
ذاكرة التخزين المؤقت = للقراءة فقط للتخزين المتميز v1 |
| عدد ونوع أقراص السجل | التخزين المتميز v1: 1 × P30 التخزين المتميز v2: 1 × 500 غيغابايت - بالإضافة إلى 2000 IOPS ومعدل نقل 125 ميغابايت/ ثانية أو ما يعادله من Premium SSD v2 |
ذاكرة التخزين المؤقت = لا شيء |
| معلمة الذاكرة القصوى ل SQL Server | 95٪ من ذاكرة الوصول العشوائي الفعلية | بافتراض مثيل واحد |
على سبيل المثال، هذا التكوين هو تكوين قاعدة البيانات VM من SAP Business Suite على SQL Server. يستضيف هذا الجهاز الظاهري قاعدة بيانات 30 تيرابايت لمثيل SAP Business Suite العالمي الواحد لشركة عالمية بإيرادات سنوية تزيد عن 200B دولار وأكثر من 200 ألف موظف بدوام كامل. يدير النظام جميع المعالجات المالية والمبيعات ومعالجة التوزيع والعديد من العمليات التجارية من مناطق مختلفة، بما في ذلك كشوف المرتبات في أمريكا الشمالية. يعمل النظام في Azure منذ بداية عام 2018 باستخدام Azure M-series VMs كلأجهزة الظاهرية لقاعدة البيانات. نظرا لقابلية الوصول العالية، يستخدم النظام Always On مع نسخة متماثلة متزامنة واحدة في منطقة توفر أخرى من نفس منطقة Azure. ونسخة متماثلة أخرى غير متزامنة في منطقة Azure أخرى. يتم نشر طبقة تطبيق NetWeaver على أحدث عائلات D(a)/E(a) VM.
| التكوين | قاعدة البيانات VM | التعليقات |
|---|---|---|
| VM Type | M192dms_v2 (192 vCPU/4196 جيبي بايت RAM) | |
| تسريع الشبكات | مُمَكّن | |
| إصدار SQL Server | SQL Server 2019 | |
| # من ملفات البيانات | 32 | |
| # من ملفات السجل | 1 | |
| # من ملفات البيانات المؤقتة | 8 | |
| نظام التشغيل | Windows Server 2019 | |
| تجميع الأقراص | مساحات مخصصة للتخزين | |
| نظام الملفات | NTFS | |
| تنسيق حجم الكتلة | 64 كيلو بايت | |
| عدد ونوع أقراص البيانات | التخزين المتميز v1: 16 x P40 أو ما يعادل Premium SSD v2 | ذاكرة التخزين المؤقت = للقراءة فقط |
| عدد ونوع أقراص السجل | التخزين المتميز v1: 1 x P60 أو ما يعادل Premium SSD v2 | استخدام Write Accelerator |
| # ونوع أقراص tempdb | التخزين المتميز v1: 1 x P30 أو ما يعادل Premium SSD v2 | لا يوجد تخزين مؤقت |
| معلمة الذاكرة القصوى ل SQL Server | 95٪ من ذاكرة الوصول العشوائي الفعلية |
SQL Server العام لـ SAP في ملخص Azure
هناك العديد من التوصيات في هذا الدليل ونوصيك بقراءتها أكثر من مرة قبل التخطيط لنشر Azure. بشكل عام، على الرغم من ذلك، تأكد من اتباع أعلى SQL Server على توصيات Azure الخاصة:
- استخدم أحدث إصدار من SQLServer، مثل SQL Server 2022، الذي يحتوي على معظم المزايا في Azure.
- خطط بعناية لمشهد نظام SAP في Azure لموازنة تخطيط ملف البيانات وقيود Azure:
- ليس لديك عدد كبير من الأقراص، ولكن لديك ما يكفي للتأكد من أنه يمكنك الوصول إلى IOPS المطلوب.
- ضع شريطًا عبر الأقراص فقط إذا كنت بحاجة إلى تحقيق معدل نقل أعلى.
- ليس لديك عدد كبير من الأقراص، ولكن لديك ما يكفي للتأكد من أنه يمكنك الوصول إلى IOPS المطلوب.
- لا تقم بتثبيت البرامج أو وضع أي ملفات تتطلب استمرارية على محرك الأقراص D:\ لأنه غير مستمر. يمكن فقدان أي شيء على محرك الأقراص هذا عند إعادة تشغيل Windows أو إعادة تشغيل الجهاز الظاهري.
- استخدم حل SQL Server Always On لنسخ بيانات قاعدة البيانات نسخا متماثلا.
- استخدم دائما تحليل الاسم، ولا تعتمد على عناوين IP.
- باستخدام SQL Server TDE، قم بتطبيق تصحيحات SQL Server الأحدث.
- كن حذرًا عند استخدام صور SQL Server من Azure Marketplace. إذا كنت تستخدم SQL Server، فيجب عليك تغيير ترتيب المثيل قبل تثبيت أي نظام SAP NetWeaver عليه.
- قم بتثبيت وتكوين مراقبة SAP لـ Azure كما هو موضح في دليل النشر.
الخطوات التالية
قراءة المقال