مشاركة عبر

أفضل ممارسات تكوين HADR (SQL Server على Azure VMs)

  • مقالة

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

يتم استخدام نظام مجموعة تجاوز الفشل لخادم Windows للتوفر العالي والتعافي من الكوارث (HADR) مع SQL Server على الأجهزة الظاهرية Azure (VMs).

توفر هذه المقالة أفضل الممارسات لتكوين نظام المجموعة لكلا مثيلات نظام مجموعة تجاوز الفشل (FCIs) وومجموعات التوفر عند استخدامها مع SQL Server على VMs Azure.

لمعرفة المزيد، راجع المقالات الأخرى في هذه السلسلة: قائمة التحقق، حجم الجهاز الظاهري، التخزين، الأمان، تكوين HADR، جمع الأساس.

قائمة الاختيار

راجع قائمة التدقيق التالية للحصول على نظرة عامة موجزة عن أفضل ممارسات HADR التي تغطيها بقية المقالة بمزيد من التفصيل.

بالنسبة إلى نظام مجموعة Windows، خذ بعين الاعتبار أفضل الممارسات التالية:

  • نشر VMs SQL Server إلى شبكات فرعية متعددة كلما أمكن لتجنب التبعية على موازنة تحميل Azure أو اسم الشبكة الموزعة (DNN) لتوجيه حركة المرور الخاصة بك إلى حل HADR.
  • تغيير نظام المجموعة إلى معلمات أقل عدوانية لتجنب الانقطاع غير المتوقع من علميات فشل الشبكة العابرة أو صيانة النظام الأساسي Azure. لمعرفة المزيد، راجع إعدادات كشف أخطاء الاتصال والحد. للحصول على إصدار Windows Server 2012 والإصدارات الأحدث، استخدم القيم التالية الموصى بها:
    • SameSubnetDelay: لمدة 1 ثانية
    • SameSubnetThreshold: عدد 40 رسالة كشف أخطاء الاتصال
    • CrossSubnetDelay: لمدة 1 ثانية
    • CrossSubnetThreshold: عدد 40 رسالة كشف أخطاء الاتصال
  • ضع VMs في مجموعة توفر أو مناطق توفر مختلفة. لمعرفة المزيد، راجع إعدادات توفر الجهاز الظاهري.
  • استخدم NIC واحداً لكل عقدة نظام المجموعة.
  • قم بتكوين تصويت الحصة نظام المجموعة لاستخدام عدد فردي لعدد 3 أو أكثر من الأصوات. لا تقم بتعيين الأصوات إلى مناطق DR.
  • قم بمراقبة حدود الموارد بعناية لتجنب عمليات إعادة التشغيل غير المتوقعة أو تجاوز الفشل بسبب قيود الموارد.
    • تأكد من أن برامج التشغيل ونظام التشغيل الخاص بك و SQL Server في أحدث إصدار لها.
    • قم بتحسين أداء SQL Server على أجهزة Azure VMs. راجع الأقسام الأخرى في هذه المقالة لمعرفة المزيد.
    • قم بتقليل أو توزيع حمل العمل لتجنب حدود الموارد.
    • انتقل إلى VM أو القرص الذي يمتلك حدوداً عالية لتجنب القيود.

بالنسبة لمجموعة توفر SQL Server أو مثيل نظام مجموعة تجاوز الفشل، خذ بعين الاعتبار أفضل الممارسات التالية:

  • إذا كنت تواجه حالات فشل متكررة غير متوقعة، فاتبع أفضل ممارسات الأداء الموضحة في بقية هذه المقالة.
  • إذا لم يعمل تحسين أداء VM SQL Server على حل تجاوز الفشل غير المتوقع، فقم بـ تخفيف المراقبة الخاصة بمجموعة التوفر أو مثيل نظام مجموعة تجاوز الفشل. ومع ذلك، قد لا يعالج ذلك المصدر الأساسي لهذه المشكلة ويمكن أن يخفي الأعراض عن طريق تقليل احتمال الفشل. قد تحتاج إلى الاستقصاء عن السبب الجذري الأساسي ومعالجته. للحصول على إصدار Windows Server 2012 أو إصدار أحدث، استخدم القيم التالية الموصى بها:
    • مهلة التأجير: استخدم هذه المعادلة لحساب الحد الأقصى لوقت الإيجار:
      Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
      ابدأ بـ 40 ثانية. إذا كنت تستخدم القيم المريحة SameSubnetThreshold وSameSubnetDelayالموصى بهما سابقًا، فلا تتجاوز 80 ثانية لقيمة مهلة الإيجار.
    • الحد الأقصى للفشل في فترة محددة: تعيين هذه القيمة إلى 6.
  • عند استخدام اسم الشبكة الظاهرية (VNN) وموازن التحميل في Azure للاتصال بحل HADR الخاص بك، حدد MultiSubnetFailover = true في سلسلة الاتصال، حتى إذا كان نظام المجموعة يمتد لشبكة فرعية واحدة فقط.
    • إذا كان العميل لا يدعم MultiSubnetFailover = True فقد تحتاج إلى تعيينRegisterAllProvidersIP = 0 وHostRecordTTL = 300لتخزين بيانات اعتماد العميل لفترات أقصر. ومع ذلك، قد يؤدي القيام بذلك إلى استعلامات إضافية إلى خادم DNS.
  • للاتصال بحل HADR باستخدام اسم الشبكة الموزع (DNN)، خذ في الاعتبار ما يلي:
    • يجب استخدام برنامج تشغيل عميل يدعم MultiSubnetFailover = True، ويجب أن تكون هذه المعلمة في سلسلة الاتصال.
    • استخدم منفذ DNN فريد في سلسلة الاتصال عند الاتصال بوحدة الإصغاء DNN لمجموعة توفر.
  • استخدم قاعدة بيانات تعكس سلسلة الاتصال لمجموعة توفر أساسية لتجاوز الحاجة إلى موازنة تحميل أو DNN.
  • التحقق من حجم قطاع VHDs الخاص بك قبل نشر حل التوفر العالي لتجنب وجود اختلال I/Os. راجع KB3009974 لمعرفة المزيد.
  • إذا تم تكوين محرك قاعدة بيانات SQL Server أو مستمع مجموعات قابلية وصول عالية التوفر AlwaysOn أو مسبار صحة مثيل نظام مجموعة تجاوز الفشل لاستخدام منفذ بين 49152 و65536 ( نطاق المنفذ الديناميكي الافتراضي لـTCP/IP)، أضف استثناء لكل منفذ. سيؤدي القيام بذلك إلى منع الأنظمة الأخرى من تعيين نفس المنفذ ديناميكياً. ينشئ المثال التالي استثناءً للمنفذ 59999:
    netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

إعدادات توفر الجهاز الظاهري

لتقليل تأثير وقت التعطل، خذ بعين الاعتبار أفضل إعدادات توفر الجهاز الظاهري التالية:

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

الحصة

على الرغم من أن نظام مجموعة عقدتين ستعمل دون مورد الحصة، يتطلب من العملاء بشكل صارم استخدام مورد الحصة للحصول على دعم الإنتاج. لن يمر التحقق من صحة نظام مجموعة أي نظام مجموعة دون مورد الحصة.

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

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

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

مراقب سحابي مراقب القرص مراقب مشاركة الملف
نظام التشغيل المعتمد Windows Server 2016+ الكل الكل
  • يعتبر المراقب السحابي مثاليًا للنشر في عدة مواقع ومجالات ومناطق. استخدم المراقب السحابي كلما أمكن، إلا إذا كنت تستخدم حل نظام مجموعة التخزين المشترك.
  • مراقب القرص هو خيار الحصة الأكثر مرونة ويفضل لأي نظام مجموعة يستخدم الأقراص المشتركة من Azure (أو أي حل قرص مشترك مثل SCSI، iSCSI، أو قناة الألياف SAN المشتركة). لا يمكن استخدام وحدة التخزين المشتركة متفاوتة المسافات كمراقب قرص.
  • يُعد مراقب مشاركة الملفات مناسبًا عندما تكون خيارات مراقب القرص والمراقب السحابي غير متوفرة.

للبدء، راجع تكوين الحصة لنظام المجموعة.

التصويت على الحصة

من الممكن تغيير التصويت على الحصة لعقدة المشاركة في نظام مجموعة تجاوز الفشل لـ Windows Server.

عند تعديل إعدادات التصويت على العقدة، اتبع هذه الإرشادات:

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

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

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

لتبسيط حل HADR الخاص بك، قم بنشر SQL Server VMs الخاص بك على شبكات فرعية متعددة كلما أمكن ذلك. لمعرفة المزيد، راجع متعدد الشبكات الفرعية AG و متعدد الشبكات الفرعية FCI.

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

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

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

خذ بعين الاعتبار القيود التالية:

لمعرفة المزيد، راجع نظرة عامة حول نظام مجموعة تجاوز الفشل لـ Windows Server.

لتكوين الاتصال، راجع المقالات التالية:

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

تلميح

قم بتعيين المعلمة MultiSubnetFailover = true في سلسلة الاتصال حتى بالنسبة لحلول HADR التي تمتد على شبكة فرعية واحدة لدعم الامتداد المستقبلي للشبكات الفرعية دون الحاجة إلى تحديث سلاسل الاتصال.

كشف أخطاء الاتصال والحد

تغيير إعدادات كشف أخطاء الاتصال والحد لنظام المجموعة إلى إعدادات مريحة. تم تصميم إعدادات نظام المجموعة الافتراضية لكشف أخطاء الاتصال والحد للشبكات المحلية التي تم ضبطها بشكل كبير ولا تأخذ في الاعتبار إمكانية زيادة زمن الوصول في بيئة سحابية. يتم الاحتفاظ بشبكة كشف أخطاء الاتصال مع UDP 3343، وهو تقليديًا أقل موثوقية بكثير من TCP وأكثر عرضة للمحادثات غير المكتملة.

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

يكون لإعدادات التأخير والحد تأثير تراكمي على الكشف الصحي الكلي. على سبيل المثال، تعيين CrossSubnetDelay لإرسال رسالة كشف أخطاء الاتصال كل ثانيتين وإعداد CrossSubnetThreshold إلى 10 رسائل كشف أخطاء الاتصال فائتة قبل الاسترداد ما يعني أنه يمكن أن يكون لنظام مجموعة الشبكة سماح بإجمالي 20 ثانية قبل اتخاذ إجراء التعافي. بشكل عام، يفضل الاستمرار في إرسال رسالة كشف أخطاء الاتصال المتكررة ولكن مع وجود حدود أكبر.

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

الإعداد خادم Windows Server 2012 أو الأحدث نظام التشغيل Windows Server 2008R2
SameSubnetDelay 1 ثانية 2 ثانية
SameSubnetThreshold 40 رسالة كشف أخطاء الاتصال 10 رسائل كشف أخطاء الاتصال (كحد أقصى)
CrossSubnetDelay 1 ثانية 2 ثانية
CrossSubnetThreshold 40 رسالة كشف أخطاء الاتصال 20 رسائل كشف أخطاء الاتصال (كحد أقصى)

استخدم PowerShell لتغيير معلمات نظام المجموعة:

(get-cluster).SameSubnetThreshold = 40
(get-cluster).CrossSubnetThreshold = 40

استخدم PowerShell للتحقق من التغييرات:

get-cluster | fl *subnet*

خذ بعين الاعتبار ما يلي:

  • هذا التغيير فوري، لا يتطلب إعادة تشغيل نظام مجموعة أو أي موارد .
  • يجب ألا تكون قيم الشبكة الفرعية نفسها أكبر من قيم الشبكة الفرعية.
  • SameSubnetThreshold <= CrossSubnetThreshold
  • SameSubnetDelay <= CrossSubnetDelay

اختر القيم المريحة استنادًا إلى مقدار وقت السماح والمدة التي يجب أن تستغرقها قبل اتخاذ إجراء تصحيحي استنادًا إلى التطبيق واحتياجات العمل والبيئة الخاصة بك. إذا لم تكن قادرًا على تجاوز القيم الافتراضية لـ Windows Server 2019، فحاول على الأقل مطابقتها، إذا أمكن:

للرجوع إليها، يفصل الجدول التالي القيم الافتراضية:

الإعداد Windows Server 2019 Windows Server 2016 Windows Server 2008 - 2012 R2
SameSubnetDelay 1 ثانية 1 ثانية 1 ثانية
SameSubnetThreshold 20 رسالة كشف أخطاء الاتصال 10 رسالة كشف أخطاء الاتصال 5 رسالة كشف أخطاء الاتصال
CrossSubnetDelay 1 ثانية 1 ثانية 1 ثانية
CrossSubnetThreshold 20 رسالة كشف أخطاء الاتصال 10 رسالة كشف أخطاء الاتصال 5 رسالة كشف أخطاء الاتصال

لمعرفة المزيد، راجع ضبط حدود شبكة نظام مجموعة تجاوز الفشل.

تخفيف الرقابة

إذا كان ضبط رسالة كشف أخطاء الاتصال لنظام المجموعة وإعدادات الحد كما هو موصى به بسماح غير كافٍ وكنت لا تزال ترى الفشل بسبب مشاكل عابرة وليس انقطاعاً صحيحاً، يمكنك تكوين مراقبة AG أو FCI لتكون أكثر تخفيفًا. في بعض السيناريوهات، قد يكون من المفيد تخفيف المراقبة مؤقتًا لفترة من الوقت نظرًا لمستوى النشاط. على سبيل المثال، قد تحتاج إلى تخفيف الرقابة عند القيام بأحمال العمل IO المكثفة مثل النسخ الاحتياطي لقاعدة البيانات، صيانة الفهرس، DBCC CHECKDB، إلخ. بمجرد اكتمال النشاط، قم بتعيين المراقبة إلى قيم أقل تخفيفًا.

تحذير

تغيير هذه الإعدادات قد يُخفي مشكلة أساسية، ويجب استخدامه كحل مؤقت لتقليل احتمال الفشل بدلاً من القضاء عليه. ولا يزال ينبغي التحقيق في المشاكل الأساسية ومعالجتها.

ابدأ بزيادة المعلمات التالية من قيمها الافتراضية لتخفيف الرقابة والضبط حسب الضرورة:

المعلمة القيمة الافتراضية تخفيف القيمة الوصف
مهلة Healthcheck 30000 60000 تحديد صحة النسخة المتماثلة أو العقدة الأساسية. يقوم مورد نظام المجموعة DLL sp_server_diagnostics بإرجاع النتائج في فاصل زمني يساوي 1/3 من حد المهلة للتحقق من الصحة. إذا كان sp_server_diagnostics بطيئًا أو لا يقوم بإرجاع المعلومات، فسينتظر المورد DLL الفاصل الزمني الكامل لحد مهلة التحقق من الصحة قبل تحديد أن المورد غير مستجيب، وبدء تجاوز الفشل التلقائي، إذا تم تكوينه للقيام بذلك.
مستوى حالة الفشل 3 2 الشروط التي تؤدي إلى تجاوز الفشل التلقائي. هناك خمسة مستويات لحالة الفشل، والتي تتراوح من الأقل تقييدًا (المستوى الأول) إلى الأكثر تقييدًا (المستوى الخامس)

استخدم Transact-SQL (T-SQL)لتعديل ظروف الفحص الصحي والفشل لكلٍ من AGs وFCIs.

بالنسبة لمجموعات التوفر:

ALTER AVAILABILITY GROUP AG1 SET (HEALTH_CHECK_TIMEOUT =60000);
ALTER AVAILABILITY GROUP AG1 SET (FAILURE_CONDITION_LEVEL = 2);

بالنسبة لمثيلات نظام مجموعة تجاوز الفشل:

ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY HealthCheckTimeout = 60000;
ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY FailureConditionLevel = 2;

لتحديد مجموعات التوفر، ابدأ بالمعلمات الموصى بها التالية، واضبط حسب الضرورة:

المعلمة القيمة الافتراضية تخفيف القيمة الوصف
مهلة التأجير 20000 40000 يمنع انقسام العقل.
مهلة الجلسة 10000 20000 يتحقق من مشكلات الاتصال بين النسخ المتماثلة. فترة مهلة جلسة العمل هي خاصية النسخة المتماثلة التي تتحكم في المدة (بالثواني) التي تنتظر نسخة متماثلة توفر لاستجابة ping من نسخة متماثلة متصلة قبل النظر في فشل الاتصال. بشكل افتراضي، تنتظر النسخة متماثلة 10 ثوان لاستجابة ping. تنطبق خاصية النسخة المتماثلة هذه على الاتصال بين نسخة متماثلة ثانوية معينة والنسخة المتماثلة الأساسية لمجموعة التوفر فقط.
الحد الأقصى للفشل في الفترة المحددة 2 6 يستخدم لتجنب حركة غير محددة لمورد متفاوت المسافات ضمن فشل العقدة المتعدد. يمكن أن تؤدي القيمة المنخفضة جدًا إلى مجموعة توفر في حالة فشل. قم بزيادة القيمة لمنع حدوث اضطرابات قصيرة من مشكلات الأداء حيث يمكن أن تؤدي القيمة المنخفضة جدًا إلى أن يكون AG في حالة فشل.

قبل إجراء أي تغييرات، خذ بعين الاعتبار ما يلي:

  • لا تخفض أي قيم للمهلة أقل من قيمها الافتراضية.
  • استخدم هذه المعادلة لحساب الحد الأقصى لقيمة مهلة التأجير:
    Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
    ابدأ بـ 40 ثانية. إذا كنت تستخدم القيم المريحة SameSubnetThreshold وSameSubnetDelayالموصى بهما سابقًا، فلا تتجاوز 80 ثانية لقيمة مهلة الإيجار.
  • بالنسبة للنسخ المتماثلة المتزامنة الالتزام، فإن تغيير مهلة جلسة العمل إلى قيمة عالية يمكن أن يزيد من مدة انتظار HADR_sync_commit.

مهلة التأجير

استخدم إدارة نظام مجموعة تجاوز الفشل لتعديل إعدادات مهلة التأجير لمجموعة التوفر الخاصة بك. راجع وثائق التحقق من صحة تأجير مجموعة التوفر لـ SQL Server للحصول على خطوات مفصلة.

مهلة الجلسة

استخدم Transact-SQL (T-SQL) لتعديل مهلة جلسة العمل لمجموعة توفر:

ALTER AVAILABILITY GROUP AG1
MODIFY REPLICA ON 'INSTANCE01' WITH (SESSION_TIMEOUT = 15);

الحد الأقصى للفشل في الفترة المحددة

استخدام إدارة نظام مجموعة تجاوز الفشل لتعديل الحد الأقصى للفشل في الفترة المحددة للقيمة:

  1. حدد الأدوار في جزء التنقل.
  2. ضمن الأدوار، انقر بزر الماوس الأيمن فوق المورد متفاوت المسافات واختر خصائص.
  3. حدد علامة التبويب تجاوز الفشل، ثم قم بزيادة الحد الأقصى للفشل في الفترة المحددة للقيمة كما هو مطلوب.

حدود الموارد

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

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

الشبكات

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

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

مشاركة حدود عرض النطاق الترددي لـ VM معين عبر NICs وإضافة NIC إضافية لا يُحسن من أداء مجموعة التوفر لـ SQL Server على Azure VMs. على هذا النحو، ليست هناك حاجة لإضافة NIC ثانٍ.

يمكن أن تتسبب خدمة DHCP غير المتوافقة مع RFC في Azure في فشل إنشاء تكوينات نظام مجموعة تجاوز الفشل المعينة. يحدث هذا الفشل لأنه تم تعيين اسم شبكة نظام المجموعة لعنوان IP مكرر مثل نفس عنوان IP كإحدى عقد نظام المجموعة. هذه مشكلة عند استخدام مجموعات التوفر التي تعتمد على ميزة نظام مجموعة تجاوز الفشل لـ Windows.

خذ بعين الاعتبار السيناريو عند إنشاء نظام مجموعة ذي عقدتين ثم جلبه عبر الإنترنت:

  1. يكون نظام المجموعة عبر الإنترنت، ثم يتطلب NODE1 عنوان IP المعين بشكل حيوي لاسم شبكة نظام المجموعة.
  2. لا تمنح خدمة DHCP أي عنوان IP غير عنوان IP NODE1 الخاص، لأن خدمة DHCP تتعرف على أن الطلب يأتي من NODE1 نفسه.
  3. يكتشف Windows أن العنوان المكرر يتم تعيينه إلى NODE1 وإلى اسم شبكة نظام مجموعة تجاوز الفشل، وفشل مجموعة نظام المجموعة الافتراضية في الاتصال.
  4. تنتقل مجموعة نظام المجموعة الافتراضية إلى NODE2. يتعامل NODE2 مع عنوان IP NODE1 كعنوان IP لنظام المجموعة ويجلب مجموعة نظام المجموعة الافتراضية عبر الإنترنت.
  5. عندما يحاول NODE2 تأسيس الاتصال مع NODE1، الحزم الموجهة إلى NODE1 لا تترك NODE2 لأنه يحل عنوان IP NODE1 إلى نفسه. لا يمكن لـ NODE2 تأسيس الاتصال مع NODE1، ومن ثم تُفقد الحصة ويتم إيقاف تشغيل نظام المجموعة.
  6. يمكن أن ترسل NODE1 الحزم إلى NODE2، ولكن لا يمكن لـ NODE2 الرد. تفقد NODE1 الحصة وتقوم بإيقاف تشغيل نظام المجموعة.

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

المشكلات المعروفة

مراجعة الحلول لبعض المشاكل والأخطاء المعروفة والشائعة:

تمت إزالة عقدة نظام المجموعة من العضوية

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

Error 1135
Cluster node 'Node1' was removed from the active failover cluster membership. 
The Cluster service on this node may have stopped. This could also be due to the node having 
lost communication with other active nodes in the failover cluster. Run the Validate a 
Configuration Wizard to check your network configuration. If the condition persists, check 
for hardware or software errors related to the network adapters on this node. Also check for 
failures in any other network components to which the node is connected such as hubs, switches, or bridges.

لمزيد من المعلومات، راجع استكشاف أخطاء مشكلة نظام المجموعة مع معرف الحدث 1135.

انتهت مدة التأجير / التأجير لم يعد صالحًا

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

Error 19407: The lease between availability group 'PRODAG' and the Windows Server Failover Cluster has expired. 
A connectivity issue occurred between the instance of SQL Server and the Windows Server Failover Cluster. 
To determine whether the availability group is failing over correctly, check the corresponding availability group 
resource in the Windows Server Failover Cluster

Error 19419: The renewal of the lease between availability group '%.*ls' and the Windows Server Failover Cluster 
failed because the existing lease is no longer valid.

مهلة الاتصال

إذا كانت مهلة جلسة العمل دقيقة جدًا لبيئة مجموعة التوفر الخاص بك، فقد تشاهد الرسائل التالية بشكل متكرر:

Error 35201: A connection timeout has occurred while attempting to establish a connection to availability 
replica 'replicaname' with ID [availability_group_id]. Either a networking or firewall issue exists, 
or the endpoint address provided for the replica is not the database mirroring endpoint of the host server instance.

Error 35206
A connection timeout has occurred on a previously established connection to availability 
replica 'replicaname' with ID [availability_group_id]. Either a networking or a firewall issue 
exists, or the availability replica has transitioned to the resolving role.

عدم الفشل في المجموعة

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

Not failing over group <Resource name>, failoverCount 3, failoverThresholdSetting <Number>, computedFailoverThreshold 2.

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

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