Share via

إعداد التعافي من الكوارث لـSQL Server

  • مقالة

توضح هذه المقالة طريقة المساعدة في حماية SQL Server الخلفية لأحد التطبيقات. بمقدورك القيام بذلك باستخدام مزيج من تقنيات SQL Server استمرارية الأعمال والإصلاح بعد الكارثة (BCDR) Microsoft Azure Site Recovery.

قبل الشروع في العمل، تأكد من فهمك لكافة القدرات المتعلقة بالإصلاح بعد الكارثة SQL Server. تشمل هذه الإمكانات:

  • تجاوز الفشل للمجموعات
  • مجموعات قابلية وصول عالية التوافر Always On
  • النسخ المتطابق لقاعدة البيانات
  • Log shipping
  • النسخ الجغرافي النشط
  • مجموعات تجاوز الفشل التلقائي

التمكن من الجمع بين تقنيات غرفة البحرين لتسوية المنازعات واستعادة الموقع

يجب أن يستند اختيارك لتقنية غرفة البحرين لتسوية المنازعات لاسترداد SQL Server الحالات إلى هدف وقت الاسترداد (RTO) واحتياجات هدف نقطة الاسترداد (RPO) على النحو المبين في الجدول التالي. القدرة على الجمع بين استرداد الموقع وتشغيل تجاوز الفشل للتكنولوجيا التي اخترتها لتنسيق استرداد التطبيق بأكمله.

نوع التوزيع تكنولوجيا بيانات تكوين التمهيد RTO المتوقع لـSQL Server RPO المتوقع لـSQL Server
SQL Server على بنية أساسية لـAzure باعتباره جهازًا ظاهريًا (VM) لخدمة (IaaS) أو محليًا. مجموعة قابلية وصول عالية التوفر AlwaysOn الوقت المستغرق لدفع النسخة المتماثلة الثانوية لتصبح أساسية. نظرًا لأن النسخ المتماثل إلى النسخة المتماثلة الثانوية غير متزامن، فسيحدث فقد لبعض البيانات.
SQL Server الموجود على جهاز ظاهري Azure IaaS أو في مكان العمل. تجاوز الفشل للمجموعات (Always On FCI) الوقت المستغرق لتجاوز الفشل بين العقد. نظرًا لأن Always On FCI يستخدم التخزين المشترك، فإن نفس طريقة عرض مثيل التخزين متاحة عند تجاوز الفشل.
SQL Server الموجود على جهاز ظاهري Azure IaaS أو في مكان العمل. النسخ المتطابق لقاعدة البيانات (وضع الأداء العالي) الوقت المستغرق لفرض الخدمة، والتي تستخدم خادم المرآة كخادم استعداد دافئ. النسخ المتماثل غير متزامن. قد تتخلف قاعدة البيانات النسخة المماثلة إلى حد ما عن قاعدة البيانات الرئيسية. عادة ما يكون معدل التأخير قليلًا. ويمكن أن تصبح كبيرة إذا كان نظام الخادم الرئيسي أو المرآة تحت الضغط الكبير.

يمكن أن يكون شحن السجل مكملًا لانعكاس قاعدة البيانات. يعتبر بديلًا مواتيًا لعكس قاعدة البيانات غير المتزامنة.
SQL باعتباره أساسيًا كخدمة (PaaS) على Azure.

يحتوي نوع النشر هذا قواعد بيانات مفردة وتجمعات مرنة.		 النسخ الجغرافي النشط 30 ثانية بعد التمكن من تشغيل تجاوز الفشل.

عند البدء في تنشيط تجاوز الفشل لإحدى قواعد البيانات الثانوية، يتم ربط جميع الثانويات الأخرى تلقائيًا بالنظام الأساسي الجديد.		 RPO لمدة تستغرق خمس ثوان.

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

البيانات الثانوية مضمونة لعدم وجود معاملات جزئية أبدًا.
SQL مثل PaaS تم تكوينه مع النسخ المتماثل الجغرافي النشط على Azure.

يتضمن نوع النشر هذا طبعات مُدارة ومخازن مرنة وقواعد بيانات مفردة.		 مجموعات تجاوز الفشل التلقائي RTO لمدة زمنية قدرها ساعة واحدة. RPO لمدة تستغرق خمس ثوان.

توفر مجموعات تجاوز الفشل التلقائي دلالات المجموعة فوق النسخ المتماثل الجغرافي النشط. لكن يتم استخدام نفس آلية النسخ المتماثل غير المتزامن.
SQL Server الموجود على جهاز ظاهري Azure IaaS أو في مكان العمل. النسخ المتماثل باستخدام خدمة Azure Site Recovery RTO عادةً ما يكون أقل من 15 دقيقة. لمعرفة المزيد، يرجى قراءة RTO SLA المقدم من Site Recovery . ساعة واحدة لاتساق التطبيق وخمس دقائق لاتساق التعطل. إذا كنت تبحث عن RPO أقل، فاستخدم تقنيات BCDR الأخرى.

إشعار

بعض الاعتبارات المهمة عندما تساعد في حماية أعباء عمل SQL باستخدام Site Recovery:

  • يعد Site Recovery حياديًا للتطبيق. يمكن أن يساعد Site Recovery في حماية أي إصدار من SQL Server يتم نشره على نظام تشغيل مدعوم. لمعرفة المزيد، راجع مصفوفة الدعم لاستعادة الأجهزة المنسوخة.
  • يمكنك اختيار استخدام "Site Recovery" لأي عملية نشر في Azure أو Hyper-V أو VMware أو البنية التحتية المادية. الرجاء اتباع الإرشادات الواردة في نهاية هذه المقالة حول كيفية المساعدة في حماية مجموعة SQL Server باستخدام "Site Recovery".
  • تأكد من أن معدل تغيير البيانات الذي تمت ملاحظته على الجهاز ضمن حدود Site Recovery. يتم قياس معدل التغيير بنقل معلومات البايت في الثانية. بالنسبة للأجهزة التي تعمل بنظام Windows، يمكنك عرض معدل التغيير هذا عن طريق تحديد علامة التبويب الأداء في إدارة المهام. راقب سرعة نقل بيانات لكل قرص.
  • يدعم Site Recovery النسخ المتماثل لمثيلات نظام مجموعة تجاوز الفشل على مساحات التخزين المباشرة. لمعرفة المزيد، راجع كيفية تمكين النسخ المتماثل المباشر لمساحات التخزين.

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

إصلاح الكوارث بعد الكارثة في التطبيق

ينسق Site Recovery تجاوز فشل الاختبار وتجاوز فشل التطبيق بأكمله بمساعدة خطط الاسترداد.

تتوافر بعض المتطلبات الأساسية لضمان تخصيص خطة الاسترداد الخاصة بك بالكامل وفقًا لاحتياجاتك. يحتاج أي نشر لـSQL Server عادةً إلى نشر Active Directory. يحتاج أيضًا إلى اتصالية بمستوى التطبيق الخاص بك.

خطوة 1: إعداد Active Directory

قم بإعداد Active Directory في موقع الاسترداد الثانوي لـ SQL Server ليعمل بطريقة صحيحة.

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

تفترض الإرشادات الواردة في هذه المقالة أن وحدة تحكم المجال متوفرة في الموقع الثانوي. لمعرفة المزيد، راجع إجراءات المساعدة في حماية Active Directory باستخدام Site Recovery.

خطوة 2: تأكد من الاتصال بطبقات أخرى

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

لفهم طريقة تصميم التطبيقات لاعتبارات الاتصال، راجع هذه الأمثلة:

خطوة 3: التعامل مع مجموعات Always On والنسخ الجغرافي النشط وتجاوز الفشل التلقائي

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

إشعار

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

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

  1. قم باستيراد البرامج النصية التي تفشل في تجاوز مجموعة إتاحة SQL في كل من الجهاز الظاهري Azure Resource Manager و الجهاز الظاهري الكلاسيكي . استيراد البرامج النصية إلى حساب Azure Automation.

    Button to deploy the Resource Manager template to Azure.

  2. إضافة البرنامج النصي ASR-SQL-FailoverAG كعمل مسبق للمجموعة الأولى من خطة الاسترداد.

  3. اتبع التعليمات المتوفرة في البرنامج النصي لإنشاء متغير أتمتة. يقدم هذا المتغير اسم مجموعات التوافر.

خطوة 4: قم بإجراء اختبار تجاوز الفشل

لا تدعم بعض تقنيات BCDR مثل مجموعات قابلية وصول عالية التوفر AlwaysOn في الأصل اختبار تجاوز الفشل. لا نوصي إلّا بالطريقة التالية عند استخدام هذه التقنيات .

  1. قم بإعداد Azure Backup على الجهاز الظاهري الذي يستضيف نسخة مجموعة الإتاحة المتماثلة في Azure.

  2. قبل بدء اختبار تجاوز الفشل لخطة الاسترداد، قم باستعادة الجهاز الظاهري من النسخة الاحتياطية التي تم التقاطها في الخطوة السابقة.

    Screenshot showing window for restoring a configuration from Azure Backup

  3. فرض النصاب القانوني في الجهاز الظاهري الذي تمت استعادته من النسخة الاحتياطية.

  4. حدّث عنوان IP الخاص بالمستمع ليكون عنوانًا متاحًا في شبكة اختبار تجاوز الفشل.

    Screenshot of rules window and IP address properties dialog

  5. أحضر المستمع عبر الإنترنت.

    Screenshot of window labeled Content_AG showing server names and statuses

  6. تأكد أن موازن التحميل في شبكة تجاوز الفشل يحتوي على عنوان IP واحد، من تجمع عناوين IP الأمامي الذي يتوافق مع كل مستمع لمجموعة التوفر، ومع SQL Server VM في التجمع الخلفي.

    Screenshot of window titled

    Screenshot of window titled

  7. في مجموعات الاسترداد اللاحقة، أضف تجاوز فشل طبقة التطبيق متبوعًا بطبقة الويب لخطة الاسترداد هذه.

  8. نفّذ اختبار تجاوز الفشل لخطة الاسترداد لاختبار تجاوز الفشل الشامل للتطبيق الخاص بك.

خطوات إجراء تجاوز الفشل

بعد إضافة البرنامج النصي في الخطوة 3 والتحقق من صحته في الخطوة 4، يمكنك إجراء تجاوز الفشل لخطة الاسترداد التي تم إنشاؤها في الخطوة 3.

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

طريقة المساعدة في حماية مجموعة SQL Server

بالنسبة لمجموعة أجهزة الكمبيوتر التي تعمل بإصدار SQL Server Standard أو SQL Server 2008 R2، نوصي باستخدام النسخ المتماثل لاسترداد الموقع للمساعدة في حماية SQL Server.

Azure إلى Azure ومن المحلي إلى Azure

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

  1. تكوين مثيل SQL Server مستقل آخر على منطقة Azure الأساسية أو في الموقع المحلي.

  2. كوّن المثيل ليكون بمثابة مرآة لقواعد البيانات التي تريد المساعدة في حمايتها. كوّن النسخ المتطابق لقاعدة البيانات في وضع الأمان العالي.

  3. كوّن Site Recovery على الموقع الأساسي للأجهزة الظاهرية Azure أو Hyper-V أو VMware والخوادم الفعلية.

  4. استخدم النسخ المتماثل Site Recovery لنسخ مثيل SQL Server الجديد إلى الموقع الثانوي. نظرا لأنها نسخة معكوسة عالية الأمان، تتم مزامنتها مع نظام المجموعة الأساسي ولكن يتم نسخها نسخا متماثلا باستخدام النسخ المتماثل ل Site Recovery.

    Image of a standard cluster that shows the relationship and flow among a primary site, Site Recovery, and Azure

اعتبارات تجاوز الفشل

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

الأسئلة الشائعة

كيف يتم ترخيص SQL Server عند استخدامه مع Site Recovery؟

تتم تغطية النسخ المتماثل لاسترداد الموقع لـSQL Server ضمن ميزة الإصلاح بعد الكارثة في Software Assurance. تنطبق هذه التغطية على جميع سيناريوهات Site Recovery: بدءًا من الإصلاح بعد الكارثة الداخلي إلى Azure والإصلاح بعد الكارثة في Azure IaaS في شتى المناطق. راجع أسعار Azure Site Recovery لمزيد من المعلومات.

هل سيدعم Site Recovery إصدار SQL Server الخاص بي؟

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

هل يعمل ASR مع النسخ المتماثل لمعاملات SQL؟

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

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