Share via

مجموعة توافر Always On على SQL Server على الأجهزة الظاهرية Azure

  • مقالة

ينطبق على: SQL Server في أجهزة Azure الظاهرية

يعرض هذا المقال مجموعات توافر Always On على (AG) SQL Server على الأجهزة الظاهرية Azure (VMs).

للبدء، راجع البرنامج التعليمي لمجموعة قابلية الوصول عالية التوفر.

نظرة عامة

مجموعات توافر Always On على الأجهزة الظاهرية Azure Virtual Machines تضاهي Always On availability groups on-premises، والاعتماد على مجموعة Windows Server Failover Clusterالأساسية. ومع ذلك، بداية من استضافة الأجهزة الظاهرية في Azure، توجد اعتبارات إضافية قليلة أيضًا، مثل تكرار الأجهزة الظاهرية VM، وتوجيه نسبة استخدام الشبكة على شبكة Azure.

يوضح الرسم التخطيطي التالي مجموعة توفر SQL Server على VMs Azure:

Availability Group

ملاحظة

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

تكرار الأجهزة الظاهرية

لزيادة التكرار والتوافر العالي، ينبغي أن تكون الأجهزة الظاهرية SQL Server VMs إما في نفس مجموعة التوفر،أو مناطق توفر مختلفة.

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

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

عند إنشاء Azure VMs، ينبغي الاختيار بين تكوين مجموعات التوفر في مقابل مناطق التوفر. لا يمكن أن يشارك الجهاز الظاهري VM Azure في كليهما.

في حين أن مناطق التوفر قد تقدم توفرًا أفضل من مجموعات التوفر (99.99٪ مقابل 99.95٪)، ينبغي أن يكون الأداء أيضًا موضع اعتبار. يمكن وضع الأجهزة الظاهرية VMs ضمن مجموعة التوفر في مجموعة موضع القرب التي تضمن قربها من بعضها البعض، ما يقلل من زمن الانتقال في الشبكة بينهما. يكون للأجهزة الظاهرية VMs الموجودة في مناطق توفر مختلفة زمن انتقال أكبر لشبكة الاتصال بينهما، والتي يمكن أن تزيد من الوقت الذي يستغرقه لمزامنة البيانات بين النسخة المتماثلة (النسخ المتماثلة) الأساسية والثانوية. قد يؤدي هذا التأخير على النسخة المتماثلة الأساسية بالإضافة إلى زيادة فرصة فقدان البيانات في حال تجاوز فشل غير مخطط لها. من المهم اختبار الحل المُقترح تحت التحميل والتأكد من أنه يلبي اتفاقات مستوى الخدمات لكلٍ من الأداء والتوافر.

قابلية التوصيل

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

إذا قمت بتوزيع أجهزة Microsoft SQL Server الظاهرية على شبكة فرعية واحدة، يمكنك تكوين اسم شبكة ظاهرية (VNN) وAzure Load Balancer، أو اسم شبكة موزع (DNN) لتوجيه نسبة استخدام الشبكة إلى مستمع مجموعة قابلية الوصول عالية التوفر. راجع الاختلافات بين الاثنتين ثم انشر اسم شبكة موزعة (DNN) أو اسم شبكة ظاهرية (VNN) لمجموعة التوفر.

تعمل معظم ميزات SQL Server بشفافية مع مجموعات التوفر عند استخدام DNN، ولكن توجد بعض الميزات التي قد تتطلب اعتبارات خاصة. راجع AG وDNN بشأن إمكانية التشغيل المتداخل لمعرفة المزيد.

بالإضافة إلى ذلك، توجد بعض اختلافات السلوك بين وظيفة وحدة الإصغاء VNN ووحدة إصغاء DNN التي من المهم ملاحظة:

  • وقت تجاوز الفشل: وقت تجاوز الفشل أسرع عند استخدام وحدة الإصغاء DNN حيث لا توجد حاجة لانتظار موازن تحميل الشبكة للكشف عن حدث الفشل وتغيير التوجيه الخاص به.
  • الاتصالات الموجودة: سيتم إغلاق الاتصالات التي تم إجراؤها إلى قاعدة بيانات معينة ضمن مجموعة توفر الفشل، ولكن الاتصالات الأخرى للنسخة المتماثلة الأساسية ستبقى مفتوحة منذ أن تتصل DNN أثناء عملية تجاوز الفشل. يختلف ذلك عن بيئة VNN التقليدية حيث يتم إغلاق كل الاتصالات إلى النسخة المتماثلة الأساسية عادة عند فشل مجموعة التوفر عبرها، تنتقل وحدة الإصغاء دون اتصال، وانتقالات النسخة المتماثلة الأساسية إلى الدور الثانوي. عند استخدام وحدة إصغاء DNN، قد تحتاج إلى ضبط سلاسل اتصال التطبيق للتأكد من إعادة توجيه الاتصالات إلى النسخة المتماثلة الأساسية الجديدة في حال تجاوز الفشل.
  • فتح الحركات: فتح المعاملات مقابل قاعدة بيانات في مجموعة توفر الفشل سيتم الإغلاق والتراجع، وتحتاج إلى إعادة الاتصال يدويًا. على سبيل المثال، في SQL Server Management Studio، أغلق إطار الاستعلام وافتح إطارًا جديدًا.

يتطلب إعداد وحدة إصغاء VNN في Azure وجود موازن تحميل. يوجد خياران رئيسيان لموازنات التحميل في Azure: خارجي (عام) أو داخلي. يعد موازن التحميل الخارجي (العام) مواجهًا للإنترنت ويرتبط ب IP ظاهري عام يمكن الوصول إليه عبر الإنترنت. يدعم موازن التحميل الداخلي العملاء فقط داخل نفس الشبكة الظاهرية. أمّا نوع موازن التحميل، فينبغي تمكين Direct Server Return.

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

  • توجد نسخة متماثلة أساسية واحدة ونسخة متماثلة ثانوية واحدة.
  • يتم تكوين النسخة المتماثلة الثانوية على أنها غير قابلة للقراءة (قراءة ثانوية تعيين الخيار إلى لا).

فيما يلي مثال لسلسلة اتصال العميل التي تتوافق مع تكوين قاعدة البيانات هذا الذي يعكس النسخ المتطابق باستخدام ADO.NET أو SQL Server Native Client:

Data Source=ReplicaServer1;Failover Partner=ReplicaServer2;Initial Catalog=AvailabilityDatabase;

لمعرفة مزيد من المعلومات حول اتصال العميل، راجع:

آلية التأجير

أما SQL Server، يحدد مورد AG DLL صحة AG استنادًا إلى آلية تأجير AG ودائمًا على الكشف عن الصحة. يعرض DLL مورد AG صحة المورد من خلال عملية IsAlive. رصد الموارد استطلاعات IsAlive في الفاصل الزمني لنبض المجموعة، الذي تم تعيينه بواسطة CrossSubnetDelay وقيم SameSubnetDelay المجموعة على نطاق واسع. على عقدة أساسية، تبدأ خدمة نظام المجموعة تجاوز الفشل كلما كان إرجاع استدعاء IsAlive إلى مورد DLL أن AG غير سليم.

يراقب مورد AG DLL حالة مكونات SQL Server الداخلية. Sp_server_diagnostics يصدر تقرير بصحة هذه المكونات إلى SQL Server على فاصل زمني التي تسيطر عليها HealthCheckTimeout.

وعلى عكس آليات تجاوز الفشل الأخرى، يؤدي المثيل SQL Server دورًا نشطًا في آلية التأجير. تُستخدم آلية التأجير في التحقق من LooksAlive بين مضيف مورد المجموعة وعملية SQL Server. وتُستخدم الآلية لضمان اتصال الجانبين (خدمة الكتلة وخدمة SQL Server) بشكل متكرر، والتحقق من حالة بعضهما البعض ومنع سيناريو انقسام الدماغ في نهاية المطاف.

عند تكوين AG في VMs Azure، توجد غالبًا حاجة لتكوين هذه الحدود بشكل مختلف عن التي سيتم تكوينها في بيئة محلية. لتكوين إعدادات الحدود وفقًا لأفضل الممارسات للأجهزة الظاهرية Azure VMs، راجع أفضل ممارسات المجموعة.

تكوين شبكة الاتصال

نشر VMs SQL Server إلى شبكات فرعية متعددة قدر الإمكان لتجنب التبعية على موازنة تحميل Azure أو اسم الشبكة الموزعة (DNN) لتوجيه حركة المرور الخاصة بك إلى مستمع مجموعة قابلية الوصول عالية التوفر.

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

مجموعة التوفر الأساسية

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

على سبيل المثال، للاتصال بوضوح باستخدام TCP/IP إلى قاعدة بيانات AG AdventureWorks على Replica_A أو Replica_B من AG الأساسية (أو أي AG يحتوي على نسخة متماثلة ثانوية واحدة فقط والوصول للقراءة غير مسموح به في النسخة المتماثلة الثانوية)، يمكن أن يوفر تطبيق عميل سلسلة اتصال النسخ المتطابق لقاعدة البيانات التالية للاتصال بـ AG بنجاح

Server=Replica_A; Failover_Partner=Replica_B; Database=AdventureWorks; Network=dbmssocn

خيارات النشر

توجد خيارات متعددة لنشر مجموعة توفر SQL Server على الأجهزة الظاهرية Azure VMs، بعضها مزود بأتمتة أكثر من غيرها.

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

مدخل Azure، Azure CLI / PowerShell قوالب التشغيل السريع دليل (الشبكة الفرعية الفردية) دليل (الشبكة الفرعية المتعددة)
إصدار SQL Server 2016 + 2016 + 2016 + 2012 + 2012 +
طبعة SQL Server المؤسسة المؤسسة المؤسسة المؤسسة، قياسي المؤسسة، قياسي
إصدار خادم النوافذ 2016 + 2016 + 2016 + الكل الكل
إنشاء نظام مجموعة لك نعم نعم نعم لا لا
إنشاء مجموعة توافر لك نعم لا لا لا لا
إنشاء موزع وحدات إصغاء وموازن التحميل بشكل مستقل لا لا لا نعم غير متوفر
هل من الممكن إنشاء وحدة الإصغاء DNN باستخدام هذا الأسلوب؟ لا لا لا نعم غير متوفر
تكوين حصة WSFC مراقب السحابة مراقب السحابة مراقب السحابة الكل الكل
DR في مناطق متعددة لا لا لا نعم نعم
دعم شبكات فرعية متعددة لا لا لا غير متوفر نعم
دعم AD موجود نعم نعم نعم نعم نعم
DR في أماكن متعددة في نفس المنطقة نعم نعم نعم نعم نعم
AG الموزعة دون AD لا لا لا نعم نعم
AG الموزعة دون مجموعة لا لا لا نعم نعم
يتطلب موازن التحميل أو DNN نعم نعم نعم نعم لا

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

للبدء، راجع أفضل ممارسات HADR، ثم قم بتوزيع مجموعة قابلية الوصول عالية التوفر يدوياً باستخدام البرنامج التعليمي لمجموعة قابلية الوصول عالية التوفر.

لمعرفة المزيد، انتقل إلى: