تصميم للاسترداد
 يجب أن يكون حمل العمل قادرا على توقع معظم حالات الفشل والتعافي منها، من جميع المقدار، مع الحد الأدنى من التعطيل لتجربة المستخدم وأهداف العمل. |
|---|
حتى الأنظمة عالية المرونة تحتاج إلى نهج التأهب للكوارث، في كل من تصميم البنية وعمليات حمل العمل. في طبقة البيانات، يجب أن يكون لديك استراتيجيات يمكنها إصلاح حالة حمل العمل إذا كان هناك تلف.
مثال على السيناريو
تستضيف شركة Contoso حاليا كمية كبيرة من البيانات على قاعدة بيانات SQL Server محلية، وقد قامت مؤخرا بتحديث حل التحليلات للبيانات باستخدام خدمات Azure.
يستخدم حل التحليلات الجديد خدمات تحليل Azure وAzure Data Factory وAzure Synapse Analytics وPower BI وأجهزة Azure الظاهرية. جميع مستخدمي الحل داخليون. بعد النظر في متطلبات توفر الحل، يقرر الفريق تنفيذ الحل في منطقة واحدة.
يتم استيعاب البيانات باستخدام Azure Data Factory ومعالجتها قبل حفظها في تخزين Analysis Services. يتطلب جزء من العملية عملية نوافذ قديمة، يتم نشرها على جهاز ظاهري في السحابة.
الاستعداد للكوارث
خطط استرداد منظمة ومختبرة وموثقة تتماشى مع أهداف الاسترداد المتفاوض عليها. يجب أن تغطي الخطط جميع المكونات بالإضافة إلى النظام ككل.
تؤدي عملية محددة جيدا إلى استرداد سريع يمكن أن يمنع التأثير السلبي على الشؤون المالية وسمعة عملك. يختبر إجراء تدريبات الاسترداد المنتظمة عملية استرداد مكونات النظام والبيانات وخطوات تجاوز الفشل وإرجاع الموارد لتجنب الارتباك عندما يكون الوقت وتكامل البيانات مقاييس رئيسية للنجاح.
تحدي Contoso
- يتم استخدام الحل داخليا فقط ولا يعتبر أمرا بالغ الأهمية. لذلك، يتفق فريق حمل العمل وأصحاب المصلحة في الأعمال على أن إعادة بناء الحل في منطقة ثانوية هو نموذج استرداد كاف في حالة فقدان منطقة Azure حيث يتم نشرها أو عدم توفر الحل بأكمله لسبب آخر.
- يصف فريق حمل العمل كيفية بناء الحل في منطقة أخرى في خطة الإصلاح بعد التعافي من الكوارث، ولكن لم تأتيحت له الفرصة لإجراء تدريب كامل على الإصلاح بعد.
تطبيق النهج والنتائج
- بعد مواجهة انقطاع إقليمي، يمكن لفريق استجابة DR اتباع إرشادات خطة الإصلاح بعد الكوارث لإعادة نشر حل التحليلات في منطقة أخرى.
- يكتشف الفريق الثغرات في خطط الإصلاح بعد الكوارث لبعض العمليات المطلوبة لنشر الحل، ويتم تحديث الخطة لجعل الاسترداد أكثر كفاءة في المستقبل.
- يوافق فريق حمل العمل وأصحاب المصلحة على تسريع اختبار الإصلاح بعد الكوارث المخطط له لضمان أن الخطة المحدثة تتيح استردادا أكثر كفاءة.
معالجة البيانات ذات الحالة
تأكد من أنه يمكنك إصلاح بيانات جميع المكونات ذات الحالة داخل أهداف الاسترداد الخاصة بك.
النسخ الاحتياطية ضرورية لإعادة النظام إلى حالة العمل باستخدام نقطة استرداد موثوق بها، مثل آخر حالة جيدة معروفة.
تضمن النسخ الاحتياطية غير القابلة للتغيير والمتناسقة مع المعاملات عدم إمكانية تغيير البيانات، وأن البيانات المستعادة غير تالفة.
تحدي Contoso
- يقرر فريق حمل العمل نقل قواعد بيانات SQL إلى Azure لتقليل أوقات معالجة التحليلات. يتم استخدام إحدى قواعد البيانات بشكل كبير أثناء عملية التحليلات من قبل الأجهزة الظاهرية، لذلك يحتاج الفريق إلى التأكد من إمكانية استرداد حالة قاعدة البيانات بأقل هدف نقطة استرداد ممكن.
تطبيق النهج والنتائج
- نظرا لأن قواعد البيانات كبيرة في أكثر من 4 ТБ كل منها، فإن الترحيل إلى قاعدة بيانات Azure SQL غير قابل للتحقيق على المدى القصير. لذلك، يرحل الفريق إلى أجهزة Azure الظاهرية التي تشغل SQL Server 2022.
- يقرر الفريق استخدام وظيفة النسخ الاحتياطي التلقائي لجميع قواعد البيانات، بما في ذلك قواعد البيانات الهامة، مثل تلك المستخدمة من قبل الأجهزة الظاهرية.
- بالنسبة لقواعد البيانات الهامة، يخطط الفريق لاستخدام دالة النسخ الاحتياطي التلقائي جنبا إلى جنب مع دالة ارتباط المثيل المدار لنسخ قواعد البيانات نسخا متماثلا بشكل نشط إلى مثيل Azure SQL المدار.
تنفيذ قدرات الإصلاح الذاتي التلقائية في التصميم
قدرات الإصلاح الذاتي هي آليات تسمح لمكونات حمل العمل بحل المشكلات تلقائيا عن طريق استرداد المكونات المتأثرة، وإذا لزم الأمر، ففشلت في البنية الأساسية المكررة. استخدم أنماط التصميم لإضافة مرونة إلى حمل العمل الخاص بك من خلال آليات الإصلاح الذاتي.
تساعد أتمتة الإصلاح الذاتي على تقليل المخاطر الناجمة عن العوامل الخارجية مثل التدخل البشري، وتقصير دورة الإصلاح العاجل.
تحدي Contoso
- تم نشر عملية Windows التي تم استدعاؤها من Azure Data Factory عند استيعاب البيانات في البداية إلى أجهزة ظاهرية متعددة لزيادة التوفر.
- كانت هناك بعض الحالات التي تعطل فيها عملية Windows القديمة، مما يتطلب إعادة تشغيل الجهاز الظاهري. بينما تأثر وقت المعالجة بشكل عام بالحد الأدنى (بسبب مستوى التكرار)، يرغب الفريق في تنفيذ حل يقوم بأتمتة الكشف عن الفشل والانتعاش.
تطبيق النهج والنتائج
- يقرر الفريق تنفيذ حل Azure Virtual Machine Scale Set، الذي تم تكوينه لنشر ملحق صحة التطبيق لمراقبة صحة عملية الجهاز الظاهري باستمرار.
- مع تمكين "إصلاح المثيل التلقائي"، أصبحت مجموعة المقياس قادرة الآن على إصلاح المكون عن طريق إعادة تشغيل الجهاز الظاهري أو إنشاء مثيل جديد استنادا إلى نفس الصورة.