مشاركة عبر

استمرارية الأعمال والإصلاح بعد كارثة لمثيل SQL المدار الذي يدعم Azure Arc

  • مقالة

يوفر مثيل SQL المدار الذي يدعم Azure Arc إمكانات لاستمرارية الأعمال والإصلاح بعد كارثة (BCDR) التي تساعد الشركات على التعافي من الاضطرابات والاستمرار في العمل بأقل وقت تعطل.

توفر هذه المقالة اعتبارات وتوصيات التصميم الرئيسية لتكوين قدرات استمرارية الأعمال وإدارتها مثل الاستعادة في نقطة زمنية، وقابلية وصول عالية، والإصلاح بعد كارثة.

بناء الأنظمة

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

رسم تخطيطي يوضح الحالة التشغيلية لمثيل الأعمال الهام عالي التوفر.

رسم تخطيطي يظهر فشلا في النسخة المتماثلة الأساسية ويروج لنسخة متماثلة ثانوية إلى النسخة الأساسية.

رسم تخطيطي يوضح فشل النسخة المتماثلة الأساسية.

رسم تخطيطي يوضح الحالة التشغيلية المستعادة.

يوضح الرسم التخطيطي للبنية التالية كيف يمكن نشر SQL Managed Instance الممكن بواسطة Arc على نظامي مجموعات Kubernetes منفصلين في موقعين مختلفين للإصلاح بعد كارثة.

رسم تخطيطي يعرض مثيل SQL المدار الذي يدعم Azure Arc والموزع في إعداد الإصلاح بعد كارثة عبر نظامي مجموعة.

يوضح الرسم التخطيطي للبنية التالية كيفية استجابة SQL Managed Instance الممكن بواسطة Arc عند بدء تجاوز فشل الإصلاح بعد كارثة.

رسم تخطيطي يوضح بدء تجاوز فشل الإصلاح بعد كارثة لمثيل SQL المدار الذي يدعم Azure Arc عبر نظامي مجموعة.

اعتبارات التصميم

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

استرداد في نقطة زمنية.

  • حدد أهدافك لهدف نقطة الاسترداد (RPO) وهدف وقت الاسترداد (RTO).

  • حدد المدة التي تريد الاحتفاظ بالنسخ الاحتياطية واستعادتها ضمن حدود الاستبقاء المدعومة.

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

  • ضع في اعتبارك فئة التخزين التي يجب استخدامها لوحدة التخزين الثابتة للنسخ الاحتياطية. للحصول على إرشادات، راجع تخصصات التخزين لمثيل SQL المدار الذي يدعم Azure Arc.

  • ضع في اعتبارك حجم وحدة التخزين الثابتة للنسخ الاحتياطية في سياق حجم البيانات المتوقع وفترة الاستبقاء المكونة.

  • للحصول على أفضل الممارسات للتخزين، راجع تخصصات التخزين لمثيل SQL المدار الذي يدعم Azure Arc.

  • يتم دائما إجراء النسخ الاحتياطية على النسخة المتماثلة الأساسية. ضع في اعتبارك تأثيرات أداء عمليات النسخ الاحتياطي والاستعادة عند تحديد الموارد المخصصة للمثيل الخاص بك.

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

  • ضع في اعتبارك الخطوات الإضافية المطلوبة لاسترداد قاعدة البيانات بالكامل إذا كان تطبيقك متصلا أثناء عملية الاستعادة.

  • ضع في اعتبارك الخطوات الإضافية المطلوبة لاستعادة قاعدة بيانات إلى مثيل متعدد النسخ المتماثلة، كما هو موضح في استعادة قاعدة بيانات على مثيل متعدد النسخ المتماثلة.

  • حدد الأدوات التي يستخدمها مسؤولو قاعدة البيانات لتكوين النسخ الاحتياطية واستعادتها. لمزيد من المعلومات، راجع الاتصال بمثيل SQL المدار الذي يدعم Azure Arc.

⁧قابلية الوصول العالية⁧

  • راجع متطلبات توفر حمل العمل الخاص بك وقرر مستوى الخدمة الأفضل لتوزيع SQL Managed Instance الممكن بواسطة Arc:

    • في مستوى خدمة الأغراض العامة، هناك نسخة متماثلة واحدة متاحة، ويتم تحقيق قابلية الوصول العالية عبر تنسيق Kubernetes.
    • في طبقة خدمة Business Critical، يوفر مثيل SQL المدار الذي يدعم Azure Arc مجموعة توفر مضمنة، بالإضافة إلى ما يتم توفيره في الأصل بواسطة تنسيق Kubernetes.

  • ضع في اعتبارك الآثار التجارية المحتملة لوقت التعطل في مستوى خدمة الأغراض العامة التي يمكن أن تنتج بسبب وجود نسخة متماثلة واحدة فقط.

  • ضع في اعتبارك عدد النسخ المتماثلة - من واحد إلى ثلاثة - للنشر في طبقة خدمة Business Critical.

  • عند نشر مثيل في طبقة خدمة Business Critical مع نسختين متماثلتين أو أكثر، يمكنك تكوين النسخ المتماثلة الثانوية كقابلة للقراءة. حدد عدد النسخ المتماثلة الثانوية التي سيتم نشرها في مستوى خدمة Business Critical. للحصول على معلومات حول تغيير الرقم، راجع تكوين الثانويات القابلة للقراءة.

  • حدد أولويات التناسق على التوفر من خلال عدد النسخ المتماثلة الثانوية المطلوبة لتنفيذ معاملة في طبقة خدمة Business Critical باستخدام المعلمة الاختيارية-sync-secondary-to-commit. إذا كانت هناك مشكلات في الاتصال بين النسخ المتماثلة، فقد لا يقوم الأساسي بتنفيذ أي معاملات:

    • في تكوين النسختين المتماثلتين، يجب الالتزام بمعاملة على كلتا النسختين المتماثلتين حتى تتلقى النسخة الأساسية رسالة نجاح.
    • في تكوين ثلاث نسخ متماثلة، يجب أن تلتزم نسختان متماثلتان على الأقل من النسخ المتماثلة الثلاث بمعاملة لإرجاع رسالة نجاح.

  • حدد ما إذا كنت بحاجة إلى تعيين نسخة متماثلة معينة كنسخة متماثلة أساسية. للحصول على معلومات حول تحديد نسخة متماثلة أساسية، راجع النسخة المتماثلة الأساسية المفضلة.

  • حدد نوع خدمة Kubernetes الذي ستستخدمه، LoadBalancer أو NodePort. إذا كنت تستخدم موازن التحميل، فيمكن للتطبيقات إعادة الاتصال بنفس نقطة النهاية الأساسية، وسيقوم Kubernetes بإعادة توجيه الاتصال إلى الأساسي الجديد. إذا كنت تستخدم منفذ العقدة، فيجب إعادة اتصال التطبيقات بعنوان IP الجديد.

التعافي من الكوارث

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

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

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

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

توصيات التصميم

تسرد الأقسام التالية توصيات التصميم لاستعادة نقطة زمنية، وقابلية وصول عالية، والإصلاح بعد كارثة.

استرداد في نقطة زمنية.

  • عند نشر مثيل جديد من SQL Managed Instance الممكن بواسطة Arc، حدد دائما فئة التخزين للنسخ الاحتياطية لتجنب الإعداد الافتراضي لفئة تخزين البيانات.

  • استخدم فئة تخزين تدعم ReadWriteMany (RWX) لوحدة تخزين النسخ الاحتياطية. للحصول على إرشادات، راجع تخصصات التخزين لمثيل SQL المدار الذي يدعم Azure Arc.

  • قبل بدء عملية استعادة، استخدم المعلمة الاختيارية-- التشغيل الجاف للتحقق أولا من نجاح العملية أم لا. لمزيد من المعلومات، راجع إنشاء قاعدة بيانات من نقطة زمنية باستخدام az CLI.

  • إنشاء عملية لإرسال النسخ الاحتياطية التي تحتاج إلى فترات استبقاء أطول إلى Azure أو التخزين البارد المحلي الآخر.

  • راقب التخزين الذي تستهلكه النسخ الاحتياطية لتحديد ما إذا كان يمكنك استيعاب استبقاء أطول، إذا لزم الأمر.

⁧قابلية الوصول العالية⁧

  • قم بإجراء تدريبات منتظمة للتحقق من التوفر العالي لمثيل SQL المدار الممكن بواسطة Arc. تتضمن أمثلة التدريبات حذف جراب في مثيل General Purpose وفشل نسخة متماثلة في مثيل Business Critical.

  • في الطبقة Business Critical، انشر مثيلا في تكوين من ثلاث نسخ متماثلة بدلا من تكوين نسختين متماثلتين لتحقيق فقدان البيانات شبه الصفري.

  • للحصول على توفر أفضل، استخدم LoadBalancer كنوع الخدمة عند نشر مثيل.

  • راجع قيود قابلية الوصول العالية لمثيل SQL المدار الذي يدعم Azure Arc.

  • راجع أوضاع التوفر المدعومة لتحديد الوضع الذي يجب استخدامه بناء على احتياجاتك عالية التوفر.

  • عند نشر مثيل Business Critical مع نسخ متماثلة متعددة، استخدم إحدى النسخ المتماثلة الثانوية لأحمال عمل القراءة . يجب أن تحدد سلسلة اتصال التطبيق نقطة النهاية الثانوية كمستمع خدمة لإعادة التوجيه إلى النسخ المتماثلة الثانوية. للحصول على معلومات حول نقاط النهاية، راجع الحصول على نقاط النهاية الأساسية والثانوية وحالة AG.

  • لفهم أفضل الممارسات لمراقبة توفر المثيلات الخاصة بك، راجع الإدارة والمراقبة لمثيل SQL المدار الذي يدعم Azure Arc.

التعافي من الكوارث

  • تأكد من أن مثيلات SQL Managed Instance الممكنة بواسطة Arc لها أسماء مختلفة للمواقع الأساسية والثانوية، وأن قيمة الاسم المشترك للمواقع متطابقة.

  • إجراء تدريبات منتظمة للإصلاح بعد كارثة للتحقق من صحة عملية تجاوز الفشل.

  • إنشاء عملية لبدء كل من عمليات تجاوز الفشل اليدوية والإجبارية.

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

  • حدد سجل DNS للاسم المشترك لمجموعة التوفر الموزعة في خوادم DNS لتجنب الحاجة إلى إنشاء سجلات DNS يدويا أثناء تجاوز الفشل.

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

لمزيد من المعلومات حول رحلة السحابة المختلطة ومتعددة السحابات، راجع المقالات التالية: