مشاركة عبر

نشر نظام إدارة قواعد البيانات للأجهزة الظاهرية لـ SQL Server Azure لـ SAP NetWeaver

يغطي هذا المستند عدة مجالات مختلفة يجب أخذها في الاعتبار عند نشر SQL Server لحمل عمل SAP في Azure Infrastructure as a Service (IaaS). كشرط مسبق لهذا المستند، انظر اعتبارات نشر نظام قواعد البيانات في Azure Virtual Machines لعبء عمل SAP. انظر أيضا أدلة أخرى في عبء عمل SAP على وثائق Azure.

هام

نطاق هذا المستند هو إصدار Windows على SQL Server. SAP لا يدعم نسخة لينكس من SQL Server مع أي من برامج SAP. الوثيقة لا تناقش قاعدة بيانات Microsoft Azure SQL Database، وهي عرض منصة كخدمة (PaaS) من منصة Microsoft Azure Platform. النقاش في هذا المقال يدور حول تشغيل منتج SQL Server، المعروف بعمليات النشر المحلية في الآلات الافتراضية Azure (VMs)، باستخدام قدرة IaaS الخاصة ب Azure. قدرات ووظائف قاعدة البيانات بين هذين العرضين مختلفة ولا ينبغي الخلط بينها. لمزيد من المعلومات، راجع ⁧⁩Azure SQL Database ⁧⁩.

وبوجه عام، يجب أن تفكر في استخدام أحدث إصدارات SQL Server لتشغيل حمل عمل SAP في خدمة تأجير البنية التحتية لـ Azure. توفر أحدث إصدارات SQL Server تكاملاً أفضل مع بعض خدمات Azure ووظائفه. أو لديك تغييرات تعمل على تحسين العمليات في البنية الأساسية لـAzure IaaS.

يمكن العثور على وثائق عامة حول تشغيل 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 المقدمة في نظام تشغيل ويندوز سيرفر الضيف، مع أكثر من 64 معالج افتراضي، كبير جدا بحيث لا يستطيع SQL Server استيعابه. عن طريق تعطيل SMT في نظام تشغيل ويندوز سيرفر الضيف، يقل عدد المعالجات الافتراضية. لذلك، فإن عدد وحدات vCPUs أقل من 64 في كل عقدة NUMA. طريقة تعطيل SMT هي تعطيل SMT في جهاز افتراضي Azure. أنواع الأجهزة الظاهرية المحددة هي:

  • 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 ومعدل نقل أقل مما ستحصل عليه إذا كنت لا تستخدم ذاكرة التخزين المؤقت للقراءة.

وفقًا للوصف العام، ونظام التشغيل، والملفات التنفيذية لـ SQL Server، يجب تحديد موقع ملفات SAP التنفيذية أو تثبيتها على أقراص Azure المنفصلة. عادة، لا يتم استخدام معظم قواعد بيانات نظام SQL Server على مستوى عال مع حمل عمل SAP NetWeaver. ومع ذلك، يجب أن تكون قواعد بيانات نظام SQL Server بالإضافة إلى دلائل SQL Server الأخرى على قرص Azure المنفصل. يجب أن يكون SQL Server tempdb إما على قرص D:\ غير المثبت أو على قرص منفصل.

  • مع جميع أنواع الأجهزة الافتراضية المعتمدة من SAP (انظر SAP Note #1928533)، tempdb يمكن وضع البيانات وملفات السجل على قرص D:\ غير المستمر.
  • مع إصدارات SQL Server، حيث يتم tempdb تثبيت SQL Server بملف بيانات واحد فقط، التوصية هي استخدام عدة tempdb ملفات بيانات. كن على علم بأن وحدات تخزين محرك الأقراص D:\ مختلفة من حيث الحجم والقدرات استنادا إلى نوع الجهاز الظاهري. للحصول على الأحجام الدقيقة لمحرك الأقراص D:\ الخاص بالأجهزة الظاهرية المختلفة، راجع المقالة أحجام أجهزة Windows الافتراضية في Azure.

تتيح tempdb هذه التكوينات استهلاك مساحة أكبر والأهم من ذلك عمليات إدخال/إخراج في الثانية (IOPS) وعرض نطاق تخزين أكثر مما يمكن لمحرك النظام توفيره. محرك D:\ غير المستمر يوفر أيضا زمن استجابة أفضل للإدخال/الإخراج وسرعة الإنتاجية. لتحديد الحجم المناسب tempdb ، يمكنك التحقق من الأحجام tempdb في الأنظمة الحالية.

إشعار

في حال وضعت tempdb ملفات البيانات وتسجيل الملفات في مجلد على محرك D:\ الذي أنشأته، عليك التأكد من وجود المجلد بعد إعادة تشغيل الجهاز الافتراضي. نظرا لأن محرك D:\ يمكن تهيئته بشكل جديد بعد إعادة تشغيل الجهاز الافتراضي، يمكن مسح جميع الملفات وهياكل الدليل. إمكانية إعادة إنشاء هياكل الدليل النهائية على قرص D:\ قبل بدء خدمة SQL Server موصوفة في استخدام أقراص SSD في أجهزة Azure الافتراضية لتخزين SQL Server TempDB وإضافات Buffer Pool.

تكوين VM الذي يشغل SQL Server مع قاعدة بيانات SAP وحيث tempdb توضع البيانات وملف tempdb السجل على قرص D:\ وAzure Premium Storage v1 أو v2 سيبدو كما يلي:

مخطط لتكوين قرص الآلة الافتراضية البسيط لخادم SQL.

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

  • بالنسبة إلى عمليات النشر الأصغر والمتوسطة النطاق، باستخدام وحدة تخزين كبيرة واحدة، والتي تحتوي على ملفات بيانات SQL Server. السبب وراء هذا التكوين هو أنه من الأسهل التعامل مع أحمال عمل الإدخال/الإخراج المختلفة في حالة عدم وجود نفس المساحة الحرة لملفات بيانات SQL Server. في حين أنه في عمليات التوزيع الكبيرة، خاصة عمليات التوزيع حيث انتقل العميل مع ترحيل قاعدة بيانات غير متجانسة إلى SQL Server في Azure، استخدمنا أقراصا منفصلة ثم وزعنا ملفات البيانات عبر تلك الأقراص. تنجح هذه البنية فقط عندما يحتوي كل قرص على نفس عدد ملفات البيانات، وجميع ملفات البيانات بنفس الحجم، ويكون لها تقريبا نفس المساحة الحرة.
  • استخدم D:\Drive tempdb طالما أن الأداء جيد بما فيه الكفاية. إذا كان عبء العمل العام محدودا في الأداء الموجود tempdb على قرص D:\ ، فعليك الانتقال tempdb إلى Azure Premium Storage v1 أو v2، أو Ultra Disk كما هو موصى به في أفضل ممارسات إرشادات الأداء.

تقوم آلية التعبئة النسبية لـ SQL Server بتوزيع عمليات القراءة والكتابة على جميع ملفات البيانات بالتساوي بشرط أن تكون جميع ملفات بيانات SQL Server بنفس الحجم ولها نفس سرعة التحرر. يوفر SAP على SQL Server أفضل أداء عند توزيع القراءات والكتابة بالتساوي عبر جميع ملفات البيانات المتوفرة. إذا كانت قاعدة البيانات تحتوي على عدد قليل جدا من ملفات البيانات أو كانت ملفات البيانات الموجودة غير متوازنة للغاية، فإن أفضل طريقة لتصحيحها هي تصدير R3load واستيراده. يتضمن تصدير واستيراد R3load فترة تعطل ويجب أن يحدث ذلك فقط إذا كانت هناك مشكلة واضحة في الأداء تحتاج إلى حل. إذا كانت ملفات البيانات مختلفة بأحجام معتدلة فقط، فقم بزيادة جميع ملفات البيانات إلى نفس الحجم، ويعيد SQL Server التوازن بين البيانات بمرور الوقت. يقوم SQL Server تلقائيا بتنمية ملفات البيانات بالتساوي إذا تم تعيين علامة التتبع 1117 أو إذا تم استخدام SQL Server 2016 أو أعلى دون علامة تتبع.

النظر في أجهزة M الافتراضية

بالنسبة لجهاز Azure M-Series الافتراضي، يمكن تقليل التأخير في كتابة سجل المعاملات مقارنة بأداء Azure Premium Storage v1 عند استخدام Azure Write Accelerator. إذا كان زمن الانتقال الذي يوفره التخزين المتميز v1 يحد من قابلية توسع حمل عمل SAP، يمكن تمكين القرص الذي يخزن ملف سجل معاملات SQL Server ل Write Accelerator. يمكن قراءة التفاصيل في المستند مسرع الكتابة. Azure Write Accelerator لا يعمل مع Azure Premium Storage v2 و Ultra Disk. في كلتا الحالتين، التأخير أفضل مما يقدمه Azure Premium Storage v1. Write Accelerator لا يدعم Azure Premium SSD v2.

إشعار

مع بعض أنواع M(b)v3 VM الجديدة، يمكن أن يؤدي استخدام تخزين Premium SSD v1 المخزن مؤقتا للقراءة إلى معدلات قراءة وكتابة IOPS ومعدل نقل أقل مما ستحصل عليه إذا كنت لا تستخدم ذاكرة التخزين المؤقت للقراءة.

تنسيق الأقراص

بالنسبة SQL Server، يجب أن يكون حجم كتلة NTFS للأقراص التي تحتوي على بيانات SQL Server وملفات السجل 64 كيلوبايت. لا تستدعي الحاجة لتهيئة محرك الأقراص D:\. يأتي محرك الأقراص هذا منسقا مسبقا.

لتجنب أن استعادة أو إنشاء قواعد البيانات هو تهيئة ملفات البيانات عن طريق صفر محتوى الملفات، تأكد من أن سياق المستخدم الذي تعمل فيه خدمة SQL Server لديه مهام صيانة وحدة التخزين "أداء المستخدم الصحيح". لمزيد من المعلومات، راجع Database instant file initialization.

تخزين ملفات قواعد البيانات مباشرة على Azure Blob Storage

يفتح SQL Server 2014 والإصدارات الأحدث إمكانية تخزين ملفات قاعدة البيانات مباشرة على Azure Blob Store دون "مجمّع" VHD حولها. كان المقصود من هذه الوظيفة معالجة أوجه القصور في تخزين كتلة Azure قبل سنوات. في هذه الأيام، لا ينصح باستخدام هذه الطريقة للنشر، بل اختر إما Azure Premium Storage v1 أو v2، أو Ultra Disk حسب المتطلبات.

اعتبارات النسخ الاحتياطي والاسترداد لخادم SQL

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

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

باستخدام صورة SQL Server من Microsoft Azure Marketplace

تقدم مايكروسوفت أجهزة افتراضية في 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

نظرا لأن صور 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 Note #1772688) ويدعم بالاشتراك مع SAP في Azure. هناك بعض الاعتبارات الخاصة حول نشر وحدة إصغاء مجموعة قابلية وصول عالية التوفر ل SQL Server (لا يجب الخلط بينها وبين مجموعة توفر Azure). لذلك، هناك حاجة لخطوات تركيب مختلفة.

بعض الاعتبارات التي تستخدم مستمع مجموعة قابلية وصول عالية التوفر على النحو التالي:

  • استخدام مستمع مجموعة التوافر ممكن فقط مع ويندوز سيرفر 2012 وما بعده كنظام تشغيل ضيف للجهاز الافتراضي. بالنسبة لويندوز سيرفر 2012، تأكد من تطبيق مجموعة مستمعي توفر SQL Server على ويندوز سيرفر 2008 R2 وويندوز سيرفر 2012 الافتراضية المبنية على ويندوز سيرفر 2012 .
  • بالنسبة إلى Windows Server 2008 R2، هذا التصحيح غير موجود. في هذه الحالة، يجب استخدام Always On بنفس طريقة النسخ المتطابق لقاعدة البيانات. عن طريق تحديد شريك تجاوز الفشل في سلسلة الاتصالات كما يتم من خلال معلمة SAP default.pfl dbs/mss/server. انظر ملاحظة SAP #965908.
  • باستخدام مستمع مجموعة قابلية وصول عالية التوفر، تحتاج إلى توصيل أجهزة قاعدة البيانات الظاهرية بموازن تحميل مخصص. يجب عليك تعيين عناوين IP ثابتة لواجهات الشبكة في تلك الأجهزة الافتراضية في إعدادات Always In. تعريف عنوان IP ثابت موصوف في إنشاء آلة افتراضية بعنوان IP خاص ثابت. تمنع عناوين IP الثابتة مقارنة ب DHCP تعيين عناوين IP جديدة في الحالات التي قد يتم فيها إيقاف كلا الجهازين الظاهريين.
  • هناك خطوات خاصة مطلوبة عند بناء تكوين عنقود WSFC حيث يحتاج العنقود إلى تعيين عنوان IP خاص. أزور، بوظيفته الحالية، سيمنح اسم العنقود نفس عنوان IP للعقدة التي تم إنشاء العنقود عليها. يعني هذا السلوك أنه يجب إجراء خطوة يدوية لتعيين عنوان IP مختلف للكتلة.
  • يتم إنشاء مستمع مجموعة قابلية التوفر العالية في Azure مع نقاط النهاية TCP/IP التي تم تعيينها إلى الأجهزة الظاهرية لتشغيل النُسخ المتماثلة الأساسية والثانوية من مجموعة قابلية الوصول العالية.
  • قد تكون تدعو الحاجة لتأمين نقاط النهاية هذه باستخدام قوائم ACL.

وثائق مفصلة حول نشر مجموعات قابلية وصول عالية التوفر Always On مع SQL Server في قوائم الأجهزة الظاهرية في Azure مثل:

إشعار

قراءة مقدمة حول مجموعات قابلية وصول عالية التوفر Always On لـ SQL Server المتوفرة على أجهزة Azure الظاهرية، ستقرأ عن وحدة استماع اسم الشبكة المباشر (DNN) الخاص بـ SQL Server. تم تقديم وظيفة DNN مع SQL Server 2019 CU8. تجعل هذه الوظيفة الجديدة استخدام موازنة تحميل Azure الذي يتعامل مع عنوان IP الظاهري لمستمع مجموعة قابلية وصول عالية التوفر أمرًا قديمًا.

يعد مجموعات قابلية وصول عالية التوفر Always On لـ SQL Server أكثر الوظائف المستخدمة شيوعًا للإتاحة العالية والتعافي من الكوارث المستخدمة في Azure لعمليات نشر حمل عمل SAP. يستخدم معظم العملاء ميزة مجموعات قابلية وصول عالية التوفر Always On لقابلية الوصول العالية داخل منطقة Azure مفردة. إذا كان التوزيع يقتصر على عُقدتين فقط، فلديك خياران للاتصال:

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

  • يمكن استخدام مستمع اسم الشبكة المباشر (DNN) بدلا من موزع تحميل Azure. DNN يلغي الحاجة لاستخدام موازن تحميل Azure، والذي ينطبق أيضا على:

    • SQL Server 2016 SP3

      • إصدارات SQL Server الأحدث على ويندوز سيرفر 2016

    • SQL Server 2017 CU 25

    • SQL Server 2019 CU8

يجب مراعاة استخدام معلمات الاتصال الخاصة ب SQL Server Database Mirroring فقط لجولة من التحقيق في المشكلات مع الطريقتين الأخريين. في هذه الحالة، تحتاج إلى تكوين اتصال تطبيقات SAP بطريقة يتم فيها تسمية كلا اسمي العقد. يتم توثيق التفاصيل الدقيقة لتكوين جانب SAP في مذكرة SAP #965908. باستخدام هذا الخيار، لن تحتاج إلى تكوين مستمع مجموعة قابلية وصول عالية التوفر. ومع ذلك لا يوجد موازن تحميل Azure ومع ذلك يمكن التحقيق في مشكلات هذه المكونات. لكن تذكر أن هذا الخيار لا يعمل إلا إذا قمت بتقييد مجموعة قابلية وصول عالية التوفر لتشمل مثيلين.

يستخدم معظم العملاء وظيفة SQL Server Always On لوظائف التعافي من الكوارث بين مناطق Azure. العديد من العملاء أيضاً لديهم القدرة على إجراء النسخ الاحتياطي من نسخة احتياطية متماثلة ثانوية.

تشفير البيانات الشفافة لـ SQL Server

يستخدم العديد من العملاء تشفير البيانات الشفافة لـ SQL Server (TDE) عند نشر قواعد بيانات SAP SQL Server في Azure. يدعم SAP بالكامل وظيفة SQL Server TDE. انظر ملاحظة SAP #1380493.

تطبيق SQL Server TDE

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

في الحالات التي تقوم فيها بنقل قواعد بيانات SAP SQL Server محليًا إلى Azure، نوصي باختبار البنية الأساسية التي يمكنك تطبيق التشفير فيها أسرع. في هذه الحالة، ضع هذه الحقائق في الاعتبار:

  • لا يمكنك تحديد عدد مؤشرات الترابط المستخدمة لتطبيق تشفير البيانات بقاعدة البيانات. عدد مؤشرات الترابط بشكل رئيسي يعتمد على عدد وحدات تخزين القرص التي يتم توزيع بيانات SQL Server وملفات السجل فيها. يعني أنه كلما كانت وحدات التخزين أكثر تميزا (أحرف محرك الأقراص)، زاد عدد مؤشرات الترابط المنخرطة بالتوازي لتنفيذ التشفير. يتعارض هذا التكوين مع اقتراحات تكوين القرص السابقة لبناء واحد، أو تقليل عدد مساحات التخزين لملفات قاعدة بيانات SQL Server في أجهزة Azure الافتراضية. قد يؤدي التكوين مع وحدات تخزين قليلة إلى تنفيذ عدد قليل من سلاسل العمليات للتشفير. تشفير خيط واحد يقرأ امتدادات 64 كيلوبايت، ثم يشفرها ثم يكتب سجلا في ملف سجل المعاملات، مما يخبر أن المدى تم تشفيره. نتيجة لذلك، يكون الحمل في سجل المعاملات معتدلاً.
  • في إصدارات 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 مثل:

هام

عند استخدام SQL Server TDE، خاصة مع Azure Key Vault، التوصية هي استخدام أحدث تحديثات SQL Server 2014، SQL Server 2016، وSQL Server 2017. ويكمن السبب في أنه بناءً على ملاحظات العملاء، تم تطبيق التحسينات والإصلاحات على الكود. على سبيل المثال، تحقق من KBA #4058175.

الحد الأدنى من تكوينات التوزيع

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

مثال على تكوين لنسخة SQL Server صغيرة بحجم قاعدة بيانات يتراوح بين 50 جيجابايت و250 جيجابايت قد يظهر:

التكوين قاعدة البيانات VM التعليقات
نوع الجهاز الظاهري 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٪ من ذاكرة الوصول العشوائي الفعلية بافتراض مثيل واحد

على سبيل المثال، هذا التكوين هو تكوين قاعدة البيانات VM من SAP Business Suite على SQL Server. تستضيف هذه الآلة الافتراضية قاعدة بيانات بسعة 30 تيرابايت لنسخة SAP Business Suite العالمية الوحيدة لشركة عالمية ذات إيرادات سنوية تزيد عن 200 مليار دولار وأكثر من 200 ألف موظف بدوام كامل. يدير النظام جميع المعالجات المالية والمبيعات ومعالجة التوزيع والعديد من العمليات التجارية من مناطق مختلفة، بما في ذلك كشوف المرتبات في أمريكا الشمالية. يعمل النظام في Azure منذ بداية عام 2018 باستخدام Azure M-series VMs كلأجهزة الظاهرية لقاعدة البيانات. نظرا لقابلية الوصول العالية، يستخدم النظام Always On مع نسخة متماثلة متزامنة واحدة في منطقة توفر أخرى من نفس منطقة Azure. ونسخة متماثلة أخرى غير متزامنة في منطقة Azure أخرى. يتم نشر طبقة تطبيق NetWeaver على أحدث عائلات D(a)/E(a) VM.

التكوين قاعدة البيانات VM التعليقات
نوع الجهاز الظاهري M192dms_v2 (192 vCPU/4196 جيبي بايت RAM)
تسريع الشبكات مُمَكّن
إصدار SQL Server SQL Server 2019
# من ملفات البيانات 32
# من ملفات السجل 1
# من ملفات البيانات المؤقتة 8
نظام التشغيل ويندوز سيرفر 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.
  • لتحقيق التوازن بين تصميم ملفات البيانات وقيود Azure، خطط بعناية لنظام SAP الخاص بك في Azure:
    • ليس لديك عدد كبير من الأقراص، ولكن لديك ما يكفي للتأكد من أنه يمكنك الوصول إلى IOPS المطلوب.
      • ضع شريطًا عبر الأقراص فقط إذا كنت بحاجة إلى تحقيق معدل نقل أعلى.
  • لا تقم بتثبيت البرامج أو وضع أي ملفات تتطلب استمرارية على محرك الأقراص D:\ لأنه غير مستمر. يمكن فقدان أي شيء على محرك الأقراص هذا عند إعادة تشغيل Windows أو إعادة تشغيل الجهاز الظاهري.
  • لتكرار بيانات قاعدة البيانات، استخدم حل SQL Server Always On الخاص بك.
  • استخدم دائما تحليل الاسم، ولا تعتمد على عناوين IP.
  • باستخدام SQL Server TDE، قم بتطبيق تصحيحات SQL Server الأحدث.
  • كن حذرا عند استخدام صور SQL Server من Azure Marketplace. إذا كنت تستخدم SQL Server، فيجب عليك تغيير ترتيب المثيل قبل تثبيت أي نظام SAP NetWeaver عليه.
  • قم بتثبيت وتكوين مراقبة SAP لـ Azure كما هو موضح في دليل النشر.
  • Last updated on