مشاركة عبر

قائمة الاختيار: أفضل الممارسات لـ SQL Server على Azure VMs

  • مقالة

ينطبق على: Microsoft SQL Server على Azure VM

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

للحصول على تفاصيل شاملة، راجع المقالات الأخرى في هذه السلسلة: حجم VM، Storage، Security، تكوين HADR، تجميع خط الأساس.

قم بتمكين SQL Assessment لـSQL Server على Azure VMs وسيتم تقييم SQL Server الخاص بك مقابل أفضل الممارسات المعروفة مع النتائج على صفحة SQL VM management من مدخل Microsoft Azure.

لمقاطع الفيديو عن أحدث الميزات لتحسين أداء SQL Server VM والتشغيل الآلي للإدارة، راجع مقاطع الفيديو التالية للبيانات المكشوفة:

نظرة عامة

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

هناك عادةً مفاضلة بين تحسين التكاليف وتحسين الأداء. تركز سلسلة أفضل الممارسات على الحصول على ⁧⁩أفضل⁧⁩ أداء لـ Microsoft SQL Server على VM Azure. إذا كان حمل عملك أقل تطلبًا، فقد لا تحتاج إلى كل تحسين موصى به. خذ بعين الاعتبار احتياجات الأداء والتكاليف وأنماط حمل العمل أثناء تقييم هذه التوصيات.

حجم الجهاز الظاهري

فيما يلي قائمة اختيار سريعة لأفضل الممارسات لحجم VM لتشغيل SQL Server على Azure VM:

  • توفر سلسلة Ebdsv5 أعلى معدل نقل إدخال/إخراج إلى vCore في Azure مع نسبة ذاكرة إلى vCore تبلغ 8. تقدم هذه السلسلة أفضل سعر وأداء لأحمال عمل SQL Server على Azure VMs. ضع في اعتبارك هذه السلسلة أولاً لمعظم أحمال عمل Microsoft SQL Server.
  • استخدم أحجام الجهاز الظاهري مع 4 أو أكثر من وحدات المعالجة المركزية الظاهرية مثل E4ds_v5 أو أعلى.
  • استخدم أحجام الجهاز الظاهري المحسنة للذاكرة للحصول على أفضل أداء لأحمال عمل SQL Server.
  • تقدم سلسلة Edsv5 و-M و-Mv2 النسبة المثلى للذاكرة إلى vCore المطلوبة لأحمال عمل OLTP.
  • توفر الأجهزة الظاهرية من السلسلة M أعلى نسبة ذاكرة إلى vCore في Azure. ضع في اعتبارك هذه الأجهزة الظاهرية لأحمال العمل الحرجة للمهمة ولأحمال عمل مستودع البيانات.
  • استفد من صور Azure Marketplace لتوزيع الأجهزة الظاهرية لـ Microsoft SQL Server حيث تم تكوين إعدادات Microsoft SQL Server وخيارات التخزين لتحقيق الأداء الأمثل.
  • اجمع خصائص الأداء لأحمال العمل المستهدفة واستخدمها لتحديد حجم VM المناسب لعملك.
  • استخدم أداة مساعد ترحيل البيانات والتوصية بوحدة حفظ المخزون المسماة Data Migration AssistantSKU recommendation للعثور على حجم الجهاز الظاهري المناسب لحمل عمل Microsoft SQL Server الحالي لديك.

لمعرفة المزيد، راجع أفضل الممارسات الشاملة لحجم VM.

التخزين

فيما يلي قائمة اختيار سريعة لأفضل ممارسات تكوين التخزين لتشغيل SQL Server على Azure VM:

  • مراقبة التطبيق وتحديد متطلبات النطاق الترددي وزمن الانتقال للتخزين لبيانات SQL Server، والسجل وملفات tempdb قبل اختيار نوع القرص.
  • لتحسين أداء التخزين، خطط لأعلى IOPS غير مقيدة ومتاحة واستخدم التخزين المؤقت للبيانات كميزة أداء لقراءة البيانات مع تجنب التحكم بالنطاق الترددي/التقييد للجهاز الظاهري والأقراص.
  • وضع البيانات والسجل وملفات tempdb على محركات أقراص منفصلة.
    • بالنسبة لمحرك البيانات، استخدم أقراص P30 وP40 المتميزة أو أقراص أصغر لضمان توفر دعم ذاكرة التخزين المؤقت
    • لخطة محرك السجل للقدرة واختبار الأداء مقابل التكلفة أثناء تقييم أقراص P30 - P80 المتميزة.
      • إذا كان زمن انتقال التخزين من submillisecond مطلوباً، فاستخدم أقراص Azure فائقة لسجل المعاملات.
      • بالنسبة إلى عمليات نشر الجهاز الظاهري من سلسلة M، ضع في اعتبارك Write Accelerator باستخدام أقراص Azure الفائقة.
    • ضع tempdb على محرك أقراص ذي حالة صلبة SSD سريع الزوال (افتراضي D:\) لمعظم أحمال عمل SQL Server التي ليست جزءاً من Failover Cluster Instance (FCI) بعد اختيار الحجم الأمثل للجهاز الظاهري.
    • لـ FCI، ضع tempdb على التخزين المتشارك.
      • إذا كان حمل عمل FCI يعتمد بشكل كبير على أداء قرص tempdb، فحينئذٍ، كإعداد متقدم، ضع tempdb على محرك أقراص ذي حالة صلبة (SSD) سريع الزوال (افتراضي D:\) والذي لا يعد جزءاً من تخزين FCI. سيحتاج هذا التكوين إلى مراقبة وإجراءات مخصصة لضمان توفر محرك SSD المؤقت (الافتراضي D:\) طوال الوقت لأن أي فشل في محرك الأقراص هذا لن يؤدي إلى تشغيل إجراء من FCI.
  • قم بتخطيط أقراص بيانات Azure المتعددة باستخدام مساحات التخزين لزيادة النطاق الترددي I/O حتى حدود IOPS ومعدل النقل للجهاز الظاهري المستهدف.
  • تعيين التخزين المؤقت للمضيف للقراءة فقط لأقراص ملفات البيانات.
  • تعيين التخزين المؤقت المضيف إلى لا شيء لأقراص ملفات السجل.
    • لا تُمكِّن التخزين المؤقت للقراءة/الكتابة على الأقراص التي تحتوي على بيانات Microsoft SQL Server أو ملفات السجل.
    • قم بإيقاف خدمة SQL Server دوماً قبل تغيير إعدادات ذاكرة التخزين المؤقت للقرص.
  • لأحمال عمل التطوير والاختبار، ضع في الاعتبار استخدام التخزين القياسي. لا ينصح باستخدام محركات الأقراص الصلبة HDD/SDD القياسية لأحمال العمل الإنتاجية.
  • يجب أن يتم النظر فقط في اندفاع القرص المستند إلى الرصيد (P1-P20) لأحمال العمل الصغيرة dev/test وأنظمة الإدارات.
  • توفير حساب التخزين في نفس المنطقة كالجهاز الظاهري SQL Server.
  • تعطيل تخزين Azure الموقع الجغرافي المُكرر (النسخ المتماثل الجغرافي) واستخدام LRS (التخزين المُكرر المحلي) على حساب التخزين.
  • تنسيق قرص البيانات لاستخدام حجم وحدة تخصيص 64 كيلوبايت لجميع ملفات البيانات الموضوعة على محرك أقراص آخر غير محرك الأقراص المؤقت D:\ (الذي يحتوي على سعة افتراضية 4 كيلوبايت). تأتي الأجهزة الظاهرية SQL Server المنشورة عبر Azure Marketplace مع أقراص بيانات منسقة بحجم وحدة التخصيص وتداخل مجموعة التخزين التي تم تعيينها إلى 64 كيلوبايت.

لمعرفة المزيد، راجع أفضل ممارسات التخزين الشاملة.

ميزات SQL Server

فيما يلي قائمة اختيار سريعة لأفضل الممارسات لإعدادات تكوين SQL Server عند تشغيل مثيلات SQL Server في جهاز ظاهري Azure في الإنتاج:

ميزات Azure

فيما يلي قائمة اختيار سريعة بأفضل الممارسات للإرشادات الخاصة بـ Azure عند تشغيل SQL Server على Azure VM:

تكوين HADR

تعتمد ميزات قابلية الوصول العالية ومواجهة الكوارث (HADR) مثل مجموعة التوفر قيد التشغيل دوماً ومثيل نظام مجموعة تجاوز الفشل على تقنية نظام مجموعة تجاوز الفشل لـ Windows Server. راجع أفضل الممارسات لتعديل إعدادات 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.
    • مهلة الفحص السليم: يمكنك تعيين هذه القيمة إلى 60000 في البداية، والضبط حسب الضرورة.
  • عند استخدام اسم الشبكة الظاهرية (VNN) وAzure Load Balancer للاتصال بحل 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

لمعرفة المزيد، راجع أفضل الممارسات الشاملة لحجم الجهاز الظاهري.

الأمان

تغطي قائمة التحقق في هذا القسم أفضل ممارسات الأمان لـSQL Server على Azure VMs.

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

  • استخدم Azure Security Center لتقييم الوضع الأمني لبيئة البيانات لديك واتخاذ إجراء بشأنه. يمكن الاستفادة من إمكانات مثل Azure Advanced Threat Protection (ATP) عبر أحمال العمل المختلطة لتحسين تقييم الأمان ومنح القدرة على الاستجابة للمخاطر. يؤدي تسجيل SQL Server VM باستخدام ملحق SQL IaaS Agent إلى ظهور تقييمات Azure Security Center داخل مورد الجهاز الظاهري لـSQL لمدخل Microsoft Azure.
  • استفد من Microsoft Defender for SQL لاكتشاف الثغرات الأمنية المحتملة في قاعدة البيانات والتخفيف من حدتها، بالإضافة إلى اكتشاف الأنشطة غير الطبيعية التي قد تشير إلى وجود تهديد لمثيل SQL Server وطبقة قاعدة البيانات.
  • يعد Vulnerability Assessment جزءاً من Microsoft Defender for SQL الذي يمكنه اكتشاف المخاطر المحتملة على بيئة SQL Server الخاصة بك والمساعدة في معالجتها. ويوفر رؤية لحالة الأمان الخاصة بك، ويتضمن خطوات قابلة للتنفيذ لحل مشكلات الأمان.
  • يحلل Microsoft Azure Active Directoryvisor تكوين الموارد وقياس الاستخدام عن بُعد ثم يوصي بالحلول التي يمكن أن تساعدك على تحسين فعالية التكلفة والأداء، وقابلية وصول عالية والأمان لموارد Azure. استفد من Azure Advisor على مستوى الجهاز الظاهري أو مجموعة الموارد أو مستوى الاشتراك للمساعدة في تحديد أفضل الممارسات وتطبيقها لتحسين عمليات توزيع Azure الخاصة بك.
  • استخدم Azure Disk Encryption عندما تتطلب منك متطلبات التوافق والأمان تشفير البيانات من طرف إلى طرف باستخدام مفاتيح التشفير، بما في ذلك تشفير القرص المؤقت (المرفق محلياً المؤقت).
  • يتم تشفير Managed Disks في حالة الثبات بشكل افتراضي باستخدام Azure Storage Service Encryption، حيث تكون مفاتيح التشفير هي مفاتيح مدارة من Microsoft مخزنة في Azure.
  • للمقارنة بين خيارات تشفير القرص المُدار، راجع مخطط بياني لمقارنة تشفير القرص المُدار
  • يجب إغلاق منافذ الإدارة على أجهزتك الظاهرية - يؤدي فتح منافذ الإدارة عن بعد إلى تعريض الجهاز الظاهري لمستوى عالٍ من المخاطر من الهجمات المستندة إلى الإنترنت. وتحاول هذه الهجمات استخدام القوة الغاشمة للإضرار ببيانات الاعتماد للوصول كمسؤول إلى الجهاز.
  • قم بتشغيل Just-in-time (JIT) access لأجهزة Azure الظاهرية
  • استخدم Azure Bastion عبر Remote Desktop Protocol (RDP).
  • قم بتأمين المنافذ والسماح فقط بنسبة استخدام شبكة التطبيق الضرورية باستخدام Azure Firewall وهو جدار حماية مُدار كخدمة (FaaS) يمنح/يرفض الوصول إلى الخادم بناءً على عنوان IP الأصلي.
  • استخدم Network Security Groups (NSGs) لتصفية نسبة استخدام الشبكة من وإلى موارد Azure على Azure Virtual Networks
  • استفد من Application Security Groups لتجميع الخوادم مع متطلبات تصفية المنافذ المماثلة، مع وظائف مماثلة، مثل خوادم الويب وخوادم قواعد البيانات.
  • بالنسبة لخوادم الويب والتطبيقات، استفد من حماية Azure Distributed Denial لـService (DDoS). تم تصميم هجوم موزع لحجب الخدمة لإرباك موارد الشبكة واستنفادها، ما يجعل التطبيقات بطيئة أو لا تستجيبِ. من الشائع أن يستهدف هجوم موزع لحجب الخدمة DDos واجهات المستخدم. تعمل حماية Azure DDoS على تنقية نسبة استخدام الشبكة غير المرغوب فيها، قبل أن تؤثر على توفر الخدمة
  • استفد من ملحقات الأجهزة الظاهرية للمساعدة في معالجة برامج مكافحة البرامج الضارة والحالة المرغوبة واكتشاف التهديدات والوقاية منها ومعالجتها لمواجهة التهديدات على مستوى نظام التشغيل والجهاز والشبكة:
  • استفد من Azure Policy لإنشاء قواعد عمل يمكن تطبيقها على بيئتك. تقوم Azure Policies بتقييم موارد Azure من خلال مقارنة خصائص هذه الموارد بالقواعد المحددة بتنسيق JSON.
  • تُمكِّن Azure Blueprints مهندسي السحابة ومجموعات تكنولوجيا المعلومات المركزية من تحديد مجموعة قابلة للتكرار من موارد Azure التي تنفذ معايير المؤسسة، وأنماطها، ومتطلباتها، وتتقيد بها. تختلف Azure Blueprints عن Azure Policies.

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

لمعرفة المزيد، راجع المقالات الأخرى في سلسلة أفضل الممارسات هذه:

ضع في اعتبارك تمكين SQL Assessment لـSQL Server على Azure VMs.

راجع مقالات Microsoft SQL ServerVirtual Machine الأخرى في ⁧⁩ نظرة عامة على Microsoft SQL Server على Azure Virtual Machines ⁧⁩. إذا كانت لديك أسئلة حول أجهزة SQL Server الظاهرية، فراجع ⁧⁩الأسئلة المتداولة⁧⁩.