استكشف قابلية الوصول العالية لـSQL Server لـ SAP في Azure

  • 8 دقائق

عند استخدام SQL Server في عمليات النشر المستندة إلى الجهاز الظاهري لـ Azure لـ SAP، يكون لديك العديد من الخيارات المختلفة لنشر طبقة DBMS عالية التوفر. يوفر Azure اتفاقيات مستوى خدمة مختلفة لجهاز ظاهري واحد وزوج من أجهزة النشر الظاهرية في Azure Availability Sets. افتراض أنك تتجه نحو اتفاقية مستوى الخدمة وقت التشغيل لعمليات نشر الإنتاج التي تتطلب النشر في Azure Availability Sets. في مثل هذه الحالة، تحتاج إلى نشر حد أدنى من الأجهزة الظاهرية بعدد اثنين في مثل Availability Set هذه. يقوم جهاز ظاهري واحد بتشغيل مثيل SQL Server النشط. يقوم الجهاز الظاهري الآخر بتشغيل المثيل السلبي

يقوم خادم نظام مجموعة أجهزة كمبيوتر الخادم SQL باستخدام Windows Scale-out File Server

وباستخدام Windows Server 2016، قدمت Microsoft مساحات التخزين المباشرة. استناداً إلى "النشر المباشر لمساحات التخزين"، يتم اعتماد SQL Server نظام المجموعات مثيلات تجاوز الفشل. يتطلب الحل موازنة تحميل Azure كذلك للتعامل مع عنوان IP الظاهري لموارد نظام المجموعة. يتم تخزين ملفات قاعدة البيانات SQL Server في "مساحات التخزين". ومن ثم، فمن المعطى أن عليك نشر مساحات تخزين Windows استنادا إلى Azure Premium Storage. منذ أن تم دعم هذا الحل لفترة ليست طويلة جداً حتى الآن، لا يوجد عملاء SAP معروفين يستخدمون هذا الحل في سيناريوهات الإنتاج لـ SAP.

نسخ متواصل لسجل SQL Server

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

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

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

النسخ المتطابق لقاعدة البيانات

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

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

إذا لم يكن التكوين المستند إلى المجال خيارا، فمن الممكن استخدام شهادات لنقاط نهاية النسخ المتطابق لقاعدة البيانات كما هو موضح في استخدام الشهادات لنقطة نهاية النسخ المتطابق لقاعدة البيانات (Transact-SQL)

SQL Server دائماً على

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

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

  • لا يمكن استخدام مستمع مجموعة قابلية وصول عالية التوفر إلا مع Windows Server 2012 أو نظام أعلى كضيف نظام التشغيل الجهاز الظاهري. بالنسبة لنظام التشغيل Windows Server 2012، تحتاج إلى التأكد من تطبيق التصحيح المتاح على: KB 2854082: التحديث يمكّن مُستمع مجموعة قابلية الوصول العالية التوفّر الخاصة بـ SQL Server على Windows Server 2008 R2 والأجهزة الظاهرية لـ Microsoft Azure استناداً إلى Windows Server 2012 .
  • بالنسبة لنظام التشغيل Windows Server 2008 R2، يجب استخدام مجموعات قابلية وصول عالية التوفر AlwaysOn بنفس طريقة استخدام "النسخ المتطابق لقاعدة البيانات" من خلال تحديد شريك تجاوز الفشل في سلسلة الاتصالات (يتم ذلك من خلال معلمة SAP default.pfl وهي dbs/mss/server - راجع ملاحظة SAP رقم 965908).
  • عند استخدام مستمع مجموعة قابلية وصول عالية التوفر، قاعدة بيانات الأجهزة الظاهرية تحتاج إلى أن تكون متصلاً بموازنة تحميل مخصصة. لتجنب السيناريو الذي يقوم فيه Azure بتعيين عناوين IP جديدة في الحالات التي يتم فيها إيقاف تشغيل كلا الجهازين الظاهريين عن طريق الخطأ، يجب تعيين عناوين IP ثابتة لواجهات الشبكة لتلك الأجهزة الظاهرية في تكوين Always On.
  • هناك خطوات خاصة مطلوبة عند إنشاء تكوين نظام مجموعة WSFC حيث يحتاج نظام المجموعة إلى عنوان IP خاص معين. يعين Azure اسم نظام المجموعة نفس عنوان IP مثل العقدة التي تم إنشاء نظام المجموعة عليها. وهذا يعني أنه يجب تنفيذ خطوة يدوية لتعيين عنوان IP مختلف إلى شبكة نظام المجموعة.
  • يتم إنشاء مستمع مجموعة قابلية التوفر العالية في Azure مع نقاط النهاية TCP/IP التي تم تعيينها إلى الأجهزة الظاهرية لتشغيل النُسخ المتماثلة الأساسية والثانوية من مجموعة قابلية الوصول العالية.

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

إشعار

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

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

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

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