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

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

غالبا ما يكون Azure Databricks جزءا أساسيا من نظام بيئي شامل للبيانات يتضمن العديد من الخدمات، بما في ذلك خدمات استيعاب البيانات الأولية (الدفعة/الدفق)، والتخزين الأصلي السحابي مثل ADLS gen2 (لمساحات العمل التي تم إنشاؤها قبل 6 مارس 2023، وAzure Blob Storage)، وأدوات وخدمات انتقال البيانات من الخادم مثل تطبيقات المعلومات المهنية وأدوات التنسيق. قد تكون بعض حالات الاستخدام حساسة بشكل خاص للانقطاع على مستوى الخدمة الإقليمية.

توضح هذه المقالة المفاهيم وأفضل الممارسات لحل ناجح للتعافي من الكوارث بين المناطق لمنصة Databricks.

ضمانات قابلية وصول عالية داخل المنطقة

بينما يركز باقي هذا الموضوع على تنفيذ التعافي من الكوارث عبر المناطق، من المهم فهم ضمانات التوفر العالية التي توفرها Azure Databricks داخل المنطقة الواحدة. تغطي ضمانات قابلية الوصول العالية داخل المنطقة المكونات التالية:

توفر وحدة التحكم Azure Databricks

• تعمل معظم خدمات وحدة التحكم على مجموعات Kubernetes، وستتعامل مع فقدان الأجهزة الظاهرية في AZ المحدد تلقائيا.
• يتم تخزين بيانات مساحة العمل في قواعد بيانات ذات تخزين متميز، يتم نسخها نسخا متماثلا عبر المنطقة. لا يتم نسخ تخزين قاعدة البيانات (خادم واحد) عبر مناطق أو مناطق مختلفة. إذا كان انقطاع المنطقة يؤثر على تخزين قاعدة البيانات، يتم استرداد قاعدة البيانات عن طريق إحضار مثيل جديد من النسخة الاحتياطية.
• حسابات التخزين المستخدمة لخدمة صور DBR زائدة عن الحاجة أيضا داخل المنطقة، وجميع المناطق لديها حسابات تخزين ثانوية يتم استخدامها عند تعطل الأساسي. راجع مناطق Azure Databricks.
• بشكل عام، يجب استعادة وظيفة وحدة التحكم في غضون حوالي 15 دقيقة بعد استرداد منطقة التوفر.

توفر مستوى الحوسبة

• يعتمد توفر مساحة العمل على توفر مستوى التحكم (كما هو موضح أعلاه).
• لا تتأثر البيانات على جذر DBFS إذا تم تكوين حساب التخزين لجذر DBFS باستخدام ZRS أو GZRS (الافتراضي هو GRS).
• يتم سحب العقد للمجموعات من مناطق التوفر المختلفة عن طريق طلب العقد من موفر حساب Azure (بافتراض السعة الكافية في المناطق المتبقية لتلبية الطلب). إذا فقدت عقدة، يطلب مدير نظام المجموعة عقد استبدال من موفر حساب Azure، والذي يسحبها من AZs المتوفرة. الاستثناء الوحيد هو عند فقدان عقدة برنامج التشغيل. في هذه الحالة، تقوم الوظيفة أو مدير نظام المجموعة بإعادة تشغيلها.

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

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

قبل تنفيذ خطة التعافي من الكوارث، من المهم فهم الفرق بين التعافي من الكوارث (DR) والتوافر العالي (HA).

التوفر العالي هو خاصية مرونة للنظام. يضمن التوفر العالي حدا أدنى من الأداء التشغيلي الذي يتم تعريفه عادة من حيث وقت التشغيل المتسق أو النسبة المئوية لوقت التشغيل. يتم تنفيذ قابلية الوصول العالية في مكانها (في نفس المنطقة مثل نظامك الأساسي) من خلال تصميمه كميزة للنظام الأساسي. على سبيل المثال، تحتوي الخدمات السحابية مثل Azure على خدمات عالية التوفر مثل ADLS gen2 (لمساحات العمل التي تم إنشاؤها قبل 6 مارس 2023، Azure Blob Storage). لا يتطلب التوفر العالي إعدادا صريحا كبيرا من عميل Azure Databricks.

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

المصطلحات

مصطلحات المنطقة

تستخدم هذه المقالة التعريفات التالية للمناطق:

• المنطقة الأساسية: المنطقة الجغرافية التي يقوم فيها المستخدمون بتشغيل أحمال عمل تحليلات البيانات التفاعلية والآلية اليومية النموذجية.

• المنطقة الثانوية: المنطقة الجغرافية التي تنقل فيها فرق تكنولوجيا المعلومات أحمال عمل تحليلات البيانات مؤقتا أثناء انقطاع التيار الكهربائي في المنطقة الأساسية.

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

  هام

  لعمليات التعافي من الكوارث، توصي Databricks بعدم الاعتماد على التخزين المتكرر جغرافيا لتكرار البيانات عبر المناطق مثل ADLS gen2 (لمساحات العمل التي تم إنشاؤها قبل 6 مارس 2023، Azure Blob Storage) التي ينشئها Azure Databricks لكل مساحة عمل في اشتراك Azure الخاص بك. بشكل عام، استخدم Deep Clone لجداول Delta وقم بتحويل البيانات إلى تنسيق Delta لاستخدام Deep Clone إذا كان ذلك ممكنا لتنسيقات البيانات الأخرى.

مصطلحات حالة التوزيع

تستخدم هذه المقالة التعريفات التالية لحالة النشر:

• النشر النشط: يمكن للمستخدمين الاتصال بنشر نشط لمساحة عمل Azure Databricks وتشغيل أحمال العمل. تتم جدولة المهام بشكل دوري باستخدام مجدول Azure Databricks أو آلية أخرى. يمكن تنفيذ تدفقات البيانات في هذا النشر أيضا. قد تشير بعض المستندات إلى عملية نشر نشطة على أنها عملية نشر فعالة.

• التوزيع السلبي: لا يتم تشغيل العمليات على توزيع سلبي. يمكن لفرق تكنولوجيا المعلومات إعداد الإجراءات التلقائية لنشر التعليمات البرمجية والتكوين وعناصر Azure Databricks الأخرى في التوزيع السلبي. يصبح النشر نشطا فقط إذا كان التوزيع النشط الحالي معزولا. قد تشير بعض المستندات إلى التوزيع السلبي على أنه توزيع بارد.

  هام

  يمكن أن يتضمن المشروع اختياريا عمليات نشر سلبية متعددة في مناطق مختلفة لتوفير خيارات إضافية لحل الانقطاعات الإقليمية.

بشكل عام، لدى الفريق نشر نشط واحد فقط في كل مرة، في ما يسمى استراتيجية التعافي من الكوارث النشطة السلبية . هناك استراتيجية أقل شيوعا لحل التعافي من الكوارث تسمى active-active، حيث يوجد اثنان من عمليات النشر النشطة المتزامنة.

مصطلحات صناعة التعافي من الكوارث

هناك مصطلحان مهمان في الصناعة يجب فهمهما وتحديدهما لفريقك:

• هدف نقطة الاسترداد: هدف نقطة الاسترداد (RPO) هو الحد الأقصى للفترة المستهدفة التي قد تفقد فيها البيانات (المعاملات) من خدمة تكنولوجيا المعلومات بسبب حادث رئيسي. لا يقوم توزيع Azure Databricks بتخزين بيانات العميل الرئيسية. يتم تخزين ذلك في أنظمة منفصلة مثل ADLS gen2 (لمساحات العمل التي تم إنشاؤها قبل 6 مارس 2023 أو تخزين Azure Blob) أو مصادر بيانات أخرى تحت سيطرتك. تخزن وحدة التحكم Azure Databricks بعض العناصر جزئيا أو كاملا، مثل الوظائف ودفاتر الملاحظات. بالنسبة إلى Azure Databricks، يتم تعريف RPO على أنه الحد الأقصى للفترة المستهدفة التي يمكن فيها فقدان كائنات مثل تغييرات الوظيفة ودفتر الملاحظات. بالإضافة إلى ذلك، أنت مسؤول عن تحديد RPO لبيانات العميل الخاصة بك في ADLS gen2 (لمساحات العمل التي تم إنشاؤها قبل 6 مارس 2023، تخزين Azure Blob) أو مصادر البيانات الأخرى تحت سيطرتك.

• هدف وقت الاسترداد: هدف وقت الاسترداد (RTO) هو المدة المستهدفة من الوقت ومستوى الخدمة الذي يجب استعادة عملية الأعمال ضمنه بعد وقوع كارثة.

  

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

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

سير عمل الاسترداد النموذجي

عادة ما يتم تشغيل سيناريو التعافي من الكوارث في Azure Databricks بالطريقة التالية:

1. يحدث فشل في خدمة هامة تستخدمها في منطقتك الأساسية. يمكن أن تكون هذه خدمة مصدر بيانات أو شبكة تؤثر على توزيع Azure Databricks.

2. يمكنك التحقيق في الموقف مع موفر السحابة.

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

4. تحقق من أن نفس المشكلة لا تؤثر أيضا على منطقتك الثانوية.

5. تجاوز الفشل إلى منطقة ثانوية.

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

   للحصول على خطوات مفصلة في سياق Azure Databricks، راجع اختبار تجاوز الفشل.

6. في مرحلة ما، يتم تخفيف المشكلة في المنطقة الأساسية وتأكيد هذه الحقيقة.

7. استعادة (إرجاع الموارد) إلى منطقتك الأساسية.

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

   لمزيد من المعلومات حول الاستعادة إلى منطقتك الأساسية، راجع اختبار الاستعادة (إرجاع الموارد).

هام

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

الخطوة 1: فهم احتياجات عملك

خطوتك الأولى هي تحديد احتياجات عملك وفهمها. تحديد خدمات البيانات الهامة وما هو RPO وRTO المتوقع.

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

تعيين جميع نقاط تكامل Azure Databricks التي تؤثر على عملك:

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

حدد الأدوات أو استراتيجيات الاتصال التي يمكن أن تدعم خطة التعافي من الكوارث:

• ما الأدوات التي ستستخدمها لتعديل تكوينات الشبكة بسرعة؟
• هل يمكنك إعداد التكوين الخاص بك وجعله نمطيا لاستيعاب حلول التعافي من الكوارث بطريقة طبيعية وقابلة للصيانة؟
• ما هي أدوات وقنوات الاتصال التي ستخطر الفرق الداخلية والجهات الخارجية (عمليات التكامل ومستهلكي انتقال البيانات من الخادم) بتجاوز فشل التعافي من الكوارث وتغييرات إرجاع الموارد؟ وكيف ستؤكد اعترافهم؟
• ما هي الأدوات أو الدعم الخاص المطلوب؟
• ما هي الخدمات إذا كانت هناك أي خدمات سيتم إيقاف تشغيلها حتى يتم الاسترداد الكامل؟

الخطوة 2: اختيار عملية تلبي احتياجات عملك

يجب أن يقوم الحل الخاص بك بنسخ البيانات الصحيحة في كل من مستوى التحكم ولوحة الحوسبة ومصادر البيانات. يجب تعيين مساحات العمل المكررة للتعافي من الكوارث إلى مستويات تحكم مختلفة في مناطق مختلفة. يجب الاحتفاظ بهذه البيانات متزامنة بشكل دوري باستخدام حل يستند إلى البرنامج النصي، إما أداة مزامنة أو سير عمل CI/CD. ليست هناك حاجة لمزامنة البيانات من داخل شبكة مستوى الحوسبة نفسها، مثل من عمال وقت تشغيل Databricks.

إذا كنت تستخدم ميزة حقن VNet (غير متوفرة مع جميع أنواع الاشتراك والتوزيع)، يمكنك نشر هذه الشبكات باستمرار في كلتا المنطقتين باستخدام الأدوات المستندة إلى القالب مثل Terraform.

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

أفضل الممارسات العامة

تتضمن أفضل الممارسات العامة لخطة ناجحة للتعافي من الكوارث ما يلي:

1. فهم العمليات الهامة للأعمال التجارية والتي يجب تشغيلها في التعافي من الكوارث.

2. تحديد الخدمات المعنية بوضوح، والبيانات التي تتم معالجتها، وما هو تدفق البيانات ومكان تخزينها

3. عزل الخدمات والبيانات قدر الإمكان. على سبيل المثال، إنشاء حاوية تخزين سحابية خاصة للبيانات لاسترداد البيانات بعد الكوارث أو نقل كائنات Azure Databricks المطلوبة أثناء حدوث كارثة إلى مساحة عمل منفصلة.

4. تقع على عاتقك مسؤولية الحفاظ على التكامل بين عمليات النشر الأساسية والثانوية للكائنات الأخرى غير المخزنة في وحدة التحكم Databricks.

   تحذير

   من أفضل الممارسات عدم تخزين البيانات في جذر ADLS gen2 (لمساحات العمل التي تم إنشاؤها قبل 6 مارس 2023، Azure Blob Storage) المستخدمة للوصول الجذر ل DBFS لمساحة العمل. تخزين جذر DBFS هذا غير مدعوم لبيانات عملاء الإنتاج. توصي Databricks أيضا بعدم تخزين المكتبات أو ملفات التكوين أو البرامج النصية للتهيئة في هذا الموقع.

5. بالنسبة لمصادر البيانات، حيثما أمكن، يوصى باستخدام أدوات Azure الأصلية للنسخ المتماثل والتكرار لنسخ البيانات نسخا متماثلا إلى مناطق التعافي من الكوارث.

اختيار استراتيجية حل الاسترداد

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

استراتيجية الحل النشط السلبي

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

هناك نوعان من المتغيرات الرئيسية لهذه الاستراتيجية:

• حل موحد (حكيم من المؤسسة): مجموعة واحدة بالضبط من عمليات النشر النشطة والسلبية التي تدعم المؤسسة بأكملها.
• الحل حسب القسم أو المشروع: يحتفظ كل قسم أو مجال مشروع بحل منفصل للتعافي من الكوارث. ترغب بعض المؤسسات في فصل تفاصيل التعافي من الكوارث بين الأقسام واستخدام مناطق أساسية وثانوية مختلفة لكل فريق بناء على الاحتياجات الفريدة لكل فريق.

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

استراتيجية الحل النشط-النشط

في حل نشط-نشط، يمكنك تشغيل جميع عمليات البيانات في كلتا المنطقتين في جميع الأوقات بالتوازي. يجب على فريق العمليات التأكد من وضع علامة على عملية بيانات مثل مهمة كمكتملة فقط عند انتهاءها بنجاح في كلتا المنطقتين. لا يمكن تغيير الكائنات في الإنتاج ويجب أن تتبع ترقية CI/CD صارمة من التطوير/التقسيم المرحلي إلى الإنتاج.

الحل النشط-النشط هو الاستراتيجية الأكثر تعقيدا، ولأن الوظائف تعمل في كلتا المنطقتين، فهناك تكلفة مالية إضافية.

تماما كما هو الحال مع الاستراتيجية النشطة السلبية، يمكنك تنفيذ هذا كحل تنظيم موحد أو حسب القسم.

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

اختيار الأدوات الخاصة بك

هناك نهجان رئيسيان للأدوات للحفاظ على البيانات مشابهة قدر الإمكان بين مساحات العمل في منطقتك الأساسية والثانوية:

• عميل المزامنة الذي ينسخ من الأساسي إلى الثانوي: يدفع عميل المزامنة بيانات الإنتاج والأصول من المنطقة الأساسية إلى المنطقة الثانوية. عادة ما يتم تشغيل هذا على أساس مجدول.
• أدوات CI/CD للتوزيع المتوازي: بالنسبة لرمز الإنتاج والأصول، استخدم أدوات CI/CD التي تدفع التغييرات إلى أنظمة الإنتاج في وقت واحد إلى كلتا المنطقتين. على سبيل المثال، عند دفع التعليمات البرمجية والأصول من التقسيم المرحلي/التطوير إلى الإنتاج، فإن نظام CI/CD يجعله متاحا في كلتا المنطقتين في نفس الوقت. الفكرة الأساسية هي التعامل مع جميع البيانات الاصطناعية في مساحة عمل Azure Databricks كبنية أساسية كتعليمة برمجية. يمكن نشر معظم البيانات الاصطناعية بشكل مشترك في كل من مساحات العمل الأساسية والثانوية، بينما قد تحتاج بعض البيانات الاصطناعية إلى النشر فقط بعد حدث التعافي من الكوارث. للحصول على الأدوات، راجع البرامج النصية التلقائية والعينات والنماذج الأولية.

يتباين الرسم التخطيطي التالي بين هذين النهجين.

اعتمادا على احتياجاتك، يمكنك الجمع بين الأساليب. على سبيل المثال، استخدم CI/CD للتعليمات البرمجية المصدر لدفتر الملاحظات ولكن استخدم المزامنة للتكوين مثل التجمعات وعناصر التحكم في الوصول.

يصف الجدول التالي كيفية التعامل مع أنواع مختلفة من البيانات مع كل خيار أدوات.

‏‏الوصف	كيفية التعامل مع أدوات CI/CD	كيفية التعامل مع أداة المزامنة
التعليمات البرمجية المصدر: عمليات تصدير مصدر دفتر الملاحظات ورمز المصدر للمكتبات المجمعة	النشر المشترك لكل من الأساسي والثانوي.	مزامنة التعليمات البرمجية المصدر من الأساسي إلى الثانوي.
المستخدمون والمجموعات	إدارة بيانات التعريف كتكوين في Git. بدلا من ذلك، استخدم نفس موفر الهوية (IdP) لكلا مساحات العمل. المشاركة في توزيع بيانات المستخدم والمجموعة إلى عمليات النشر الأساسية والثانوية.	استخدم SCIM أو أتمتة أخرى لكلا المنطقتين. لا ينصح بإنشاء يدوي، ولكن إذا تم استخدامه يجب أن يتم لكليهما في نفس الوقت. إذا كنت تستخدم إعدادا يدويا، فبادر بإنشاء عملية تلقائية مجدولة لمقارنة قائمة المستخدمين والمجموعة بين عمليتي النشر.
تكوينات التجمع	يمكن أن تكون قوالب في Git. النشر المشترك إلى الأساسي والثانوي. ومع ذلك، min_idle_instances في الثانوي يجب أن يكون صفرا حتى حدث التعافي من الكوارث.	تجمعات تم إنشاؤها مع أي min_idle_instances عند مزامنتها إلى مساحة العمل الثانوية باستخدام واجهة برمجة التطبيقات أو CLI.
تكوينات الوظيفة	يمكن أن تكون قوالب في Git. للنشر الأساسي، انشر تعريف المهمة كما هو. للنشر الثانوي، انشر المهمة وقم بتعيين التزامنات إلى الصفر. يؤدي هذا إلى تعطيل المهمة في هذا النشر ويمنع عمليات التشغيل الإضافية. قم بتغيير قيمة التزامنات بعد أن يصبح النشر الثانوي نشطا.	إذا كانت المهام تعمل على مجموعات موجودة <interactive> لسبب ما، فسيحتاج عميل المزامنة إلى التعيين إلى المطابق cluster_id في مساحة العمل الثانوية.
قوائم التحكم بالوصول (ACLs)	يمكن أن تكون قوالب في Git. النشر المشترك في عمليات النشر الأساسية والثانوية لدفاتر الملاحظات والمجلدات والمجموعات. ومع ذلك، الاحتفاظ بالبيانات للمهام حتى حدث التعافي من الكوارث.	يمكن لواجهة برمجة تطبيقات الأذونات تعيين عناصر التحكم في الوصول للمجموعات والوظائف والتجمعات ودفاتر الملاحظات والمجلدات. يحتاج عميل المزامنة إلى تعيين معرفات الكائن المقابلة لكل كائن في مساحة العمل الثانوية. توصي Databricks بإنشاء خريطة لمعرفات الكائنات من مساحة العمل الأساسية إلى مساحة العمل الثانوية أثناء مزامنة هذه الكائنات قبل نسخ عناصر التحكم في الوصول نسخا متماثلا.
المكتبات	تضمين في التعليمات البرمجية المصدر وقوالب نظام المجموعة/الوظيفة.	مزامنة المكتبات المخصصة من المستودعات المركزية أو DBFS أو التخزين السحابي (يمكن تحميلها).
البرامج النصية ل init لنظام المجموعة	تضمين في التعليمات البرمجية المصدر إذا كنت تفضل ذلك.	لمزامنة أبسط، قم بتخزين البرامج النصية init في مساحة العمل الأساسية في مجلد مشترك أو في مجموعة صغيرة من المجلدات إن أمكن.
نقاط تركيب	تضمين في التعليمات البرمجية المصدر إذا تم إنشاؤه فقط من خلال المهام المستندة إلى دفتر الملاحظات أو واجهة برمجة تطبيقات الأوامر.	استخدم المهام، التي يمكن تشغيلها كأنشطة Azure Data Factory (ADF). لاحظ أن نقاط نهاية التخزين قد تتغير، نظرا لأن مساحات العمل ستكون في مناطق مختلفة. يعتمد هذا كثيرا على استراتيجية استرداد البيانات بعد الكوارث أيضا.
بيانات تعريف الجدول	تضمين مع التعليمات البرمجية المصدر إذا تم إنشاؤه فقط من خلال المهام المستندة إلى دفتر الملاحظات أو واجهة برمجة تطبيقات الأوامر. ينطبق هذا على كل من مخزن بيانات Azure Databricks metastore الداخلي أو metastore الخارجي المكون.	قارن تعريفات بيانات التعريف بين مخازن التعريف باستخدام واجهة برمجة تطبيقات كتالوج Spark أو إظهار إنشاء جدول عبر دفتر ملاحظات أو برامج نصية. لاحظ أن جداول التخزين الأساسية يمكن أن تستند إلى المنطقة وستكون مختلفة بين مثيلات metastore.
الأسرار	تضمين في التعليمات البرمجية المصدر إذا تم إنشاؤه فقط من خلال واجهة برمجة تطبيقات الأوامر. لاحظ أن بعض محتويات البيانات السرية قد تحتاج إلى التغيير بين الأساسي والثانوي.	يتم إنشاء الأسرار في كل من مساحات العمل عبر واجهة برمجة التطبيقات. لاحظ أن بعض محتويات البيانات السرية قد تحتاج إلى التغيير بين الأساسي والثانوي.
تكوينات نظام المجموعة	يمكن أن تكون قوالب في Git. النشر المشترك في عمليات النشر الأساسية والثانوية، على الرغم من أنه يجب إنهاء تلك الموجودة في التوزيع الثانوي حتى حدث التعافي من الكوارث.	يتم إنشاء المجموعات بعد مزامنتها إلى مساحة العمل الثانوية باستخدام واجهة برمجة التطبيقات أو CLI. يمكن إنهاء هذه بشكل صريح إذا كنت تريد ذلك، اعتمادا على إعدادات الإنهاء التلقائي.
أذونات دفتر الملاحظات والمهمة والمجلد	يمكن أن تكون قوالب في Git. النشر المشترك في عمليات النشر الأساسية والثانوية.	النسخ المتماثل باستخدام واجهة برمجة تطبيقات الأذونات.

اختيار مناطق ومساحات عمل ثانوية متعددة

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

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

الخطوة 3: إعداد مساحات العمل والقيام بنسخة لمرة واحدة

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

• النسخ المتماثل للبيانات: النسخ المتماثل باستخدام حل النسخ المتماثل السحابي أو عملية Delta Deep Clone.
• إنشاء الرمز المميز: استخدم إنشاء الرمز المميز لأتمتة النسخ المتماثل وأحمال العمل المستقبلية.
• النسخ المتماثل لمساحة العمل: استخدم النسخ المتماثل لمساحة العمل باستخدام الطرق الموضحة في الخطوة 4: إعداد مصادر البيانات.
• التحقق من صحة مساحة العمل: - اختبار للتأكد من إمكانية تنفيذ مساحة العمل والعملية بنجاح وتوفير النتائج المتوقعة.

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

الخطوة 4: إعداد مصادر البيانات

يمكن ل Azure Databricks معالجة مجموعة كبيرة ومتنوعة من مصادر البيانات باستخدام معالجة الدفعات أو تدفقات البيانات.

معالجة الدفعات من مصادر البيانات

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

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

تدفقات البيانات

تعد معالجة دفق البيانات تحديا أكبر. يمكن استيعاب البيانات المتدفقة من مصادر مختلفة ومعالجتها وإرسالها إلى حل دفق:

• قائمة انتظار الرسائل مثل Kafka
• دفق التقاط بيانات تغيير قاعدة البيانات
• المعالجة المستمرة المستندة إلى الملفات
• المعالجة المجدولة المستندة إلى الملفات، والمعروفة أيضا باسم المشغل مرة واحدة

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

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

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

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

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

الخطوة 5: تنفيذ الحل واختباره

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

هام

اختبر بانتظام حل التعافي من الكوارث في ظروف العالم الحقيقي.

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

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

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

تخطيط واختبار التغييرات على أدوات التكوين:

• الاستيعاب: فهم مكان مصادر البيانات وأين تحصل هذه المصادر على بياناتها. حيثما أمكن، حدد معلمات المصدر وتأكد من أن لديك قالب تكوين منفصل للعمل مع عمليات التوزيع الثانوية والمناطق الثانوية. إعداد خطة لتجاوز الفشل واختبار جميع الافتراضات.
• تغييرات التنفيذ: إذا كان لديك مجدول لتشغيل المهام أو إجراءات أخرى، فقد تحتاج إلى تكوين مجدول منفصل يعمل مع النشر الثانوي أو مصادر البيانات الخاصة به. إعداد خطة لتجاوز الفشل واختبار جميع الافتراضات.
• الاتصال التفاعلي: ضع في اعتبارك كيفية تأثر التكوين والمصادقة واتصالات الشبكة بالاضطرابات الإقليمية لأي استخدام لواجهات برمجة تطبيقات REST أو أدوات CLI أو خدمات أخرى مثل JDBC/ODBC. إعداد خطة لتجاوز الفشل واختبار جميع الافتراضات.
• تغييرات الأتمتة: لجميع أدوات الأتمتة، قم بإعداد خطة لتجاوز الفشل واختبار جميع الافتراضات.
• المخرجات: لأي أدوات تنشئ بيانات الإخراج أو السجلات، قم بإعداد خطة لتجاوز الفشل واختبار جميع الافتراضات.

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

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

عند اختبار تجاوز الفشل، اتصل بالنظام وقم بتشغيل عملية إيقاف التشغيل. تأكد من اكتمال جميع المهام وإنهاء المجموعات.

يمكن لعميل المزامنة (أو أدوات CI/CD) نسخ عناصر وموارد Azure Databricks ذات الصلة إلى مساحة العمل الثانوية. لتنشيط مساحة العمل الثانوية، قد تتضمن العملية بعض أو كل ما يلي:

1. قم بإجراء الاختبارات للتأكد من أن النظام الأساسي محدث.
2. قم بتعطيل التجمعات والمجموعات على المنطقة الأساسية بحيث إذا كانت الخدمة الفاشلة ترجع عبر الإنترنت، فلن تبدأ المنطقة الأساسية في معالجة البيانات الجديدة.
3. عملية الاسترداد:
   1. تحقق من تاريخ أحدث البيانات التي تمت مزامنتها. راجع مصطلحات صناعة التعافي من الكوارث. تختلف تفاصيل هذه الخطوة بناء على كيفية مزامنة البيانات واحتياجات عملك الفريدة.
   2. قم بتثبيت مصادر البيانات الخاصة بك وتأكد من توفرها جميعا. قم بتضمين جميع مصادر البيانات الخارجية، مثل Azure Cloud SQL، بالإضافة إلى Delta Lake أو Parquet أو ملفات أخرى.
   3. ابحث عن نقطة استرداد البث. قم بإعداد العملية لإعادة التشغيل من هناك ولديك عملية جاهزة لتحديد التكرارات المحتملة والقضاء عليها (يجعل Delta Lake Lake هذا أسهل).
   4. أكمل عملية تدفق البيانات وأبلغ المستخدمين.
4. بدء التجمعات ذات الصلة (أو زيادة min_idle_instances إلى العدد ذي الصلة).
5. بدء تشغيل المجموعات ذات الصلة (إذا لم يتم إنهاؤها).
6. قم بتغيير التشغيل المتزامن للوظائف وتشغيل المهام ذات الصلة. قد تكون هذه عمليات تشغيل لمرة واحدة أو عمليات تشغيل دورية.
7. بالنسبة لأي أداة خارجية تستخدم عنوان URL أو اسم مجال لمساحة عمل Azure Databricks، قم بتحديث التكوينات لحساب مستوى التحكم الجديد. على سبيل المثال، تحديث عناوين URL لواجهات برمجة تطبيقات REST واتصالات JDBC/ODBC. يتغير عنوان URL المواجه للعميل لتطبيق Azure Databricks على الويب عند تغيير مستوى التحكم، لذا قم بإعلام مستخدمي مؤسستك بعنوان URL الجديد.

اختبار الاستعادة (إرجاع الموارد)

إعادة الفشل أسهل في التحكم ويمكن القيام به في نافذة الصيانة. يمكن أن تتضمن هذه الخطة بعض أو كل ما يلي:

1. احصل على تأكيد لاستعادة المنطقة الأساسية.
2. قم بتعطيل التجمعات والمجموعات في المنطقة الثانوية حتى لا تبدأ في معالجة البيانات الجديدة.
3. قم بمزامنة أي أصول جديدة أو معدلة في مساحة العمل الثانوية مرة أخرى إلى التوزيع الأساسي. اعتمادا على تصميم البرامج النصية لتجاوز الفشل، قد تتمكن من تشغيل نفس البرامج النصية لمزامنة الكائنات من المنطقة الثانوية (التعافي من الكوارث) إلى المنطقة الأساسية (الإنتاج).
4. مزامنة أي تحديثات بيانات جديدة مرة أخرى إلى النشر الأساسي. يمكنك استخدام مسارات التدقيق للسجلات وجداول دلتا لضمان عدم فقدان البيانات.
5. إيقاف تشغيل جميع أحمال العمل في منطقة التعافي من الكوارث.
6. تغيير الوظائف وعنوان URL للمستخدمين إلى المنطقة الأساسية.
7. قم بإجراء الاختبارات للتأكد من أن النظام الأساسي محدث.
8. ابدأ التجمعات ذات الصلة (أو قم بزيادة min_idle_instances إلى رقم ذي صلة) .
9. بدء تشغيل المجموعات ذات الصلة (إذا لم يتم إنهاؤها).
10. قم بتغيير التشغيل المتزامن للوظائف، وتشغيل المهام ذات الصلة. قد تكون هذه عمليات تشغيل لمرة واحدة أو عمليات تشغيل دورية.
11. حسب الحاجة، قم بإعداد منطقتك الثانوية مرة أخرى للتعافي من الكوارث في المستقبل.

البرامج النصية التلقائية والعينات والنماذج الأولية

البرامج النصية التلقائية التي يجب مراعاتها لمشاريع التعافي من الكوارث:

• توصي Databricks باستخدام Databricks Terraform Provider للمساعدة في تطوير عملية المزامنة الخاصة بك.
• راجع أيضا Databricks Workspace Migration Tools للحصول على نماذج ونماذج البرامج النصية. بالإضافة إلى كائنات Azure Databricks، قم بنسخ أي مسارات Azure Data Factory ذات صلة بحيث تشير إلى خدمة مرتبطة تم تعيينها إلى مساحة العمل الثانوية.
• مشروع Databricks Sync (DBSync) هو أداة مزامنة كائن تقوم بعمل نسخة احتياطية من مساحات عمل Databricks واستعادتها ومزامنتها.