BCDR ل Azure Data Factory وخطوط أنابيب Azure Synapse Analytics

Azure Data Factory
Azure Repos
Azure Synapse Analytics
GitHub

يمكن أن تكون الكوارث هي فشل الأجهزة أو الكوارث الطبيعية أو فشل البرامج. تسمى عملية التحضير للكارثة والتعافي منها التعافي من الكوارث (DR). تتناول هذه المقالة الممارسات الموصى بها لتحقيق استمرارية الأعمال والتعافي من الكوارث (BCDR) ل Azure Data Factory وخطوط أنابيب Azure Synapse Analytics.

تتضمن إستراتيجيات BCDR تكرار منطقة التوفر، والاسترداد التلقائي الذي يوفره استرداد Azure بعد عطل فادح، والاسترداد المدار من قبل المستخدم باستخدام التكامل المستمر والتسليم المستمر (CI/CD).

بناء الأنظمة

رسم تخطيطي يوضح مناطق التوفر والمناطق ل Azure Synapse Analytics وتدفقات Data Factory BCDR.

قم بتنزيل ملف Visio لهذه البنية.

‏‏سير العمل‬

  1. تحقق مسارات Data Factory وAzure Synapse المرونة باستخدام مناطق Azure ومناطق توفر Azure.

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

المكونات

تفاصيل السيناريو

يخزن مصنع البيانات وخطوط أنابيب Azure Synapse البيانات الاصطناعية التي تتضمن البيانات التالية:

بيانات التعريف

  • ‏‫‏‫‏‫المسار‬
  • مجموعات البيانات
  • الخدمات المرتبطة
  • وقت تشغيل التكامل
  • أزرار التشغيل

مراقبة البيانات

  • ‏‫‏‫‏‫المسار‬
  • أزرار التشغيل
  • تشغيل النشاط

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

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

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

الاسترداد التلقائي مع استرداد Azure بعد الكوارث

مع الاسترداد التلقائي المقدم من Azure Backup والتعافي من الكوارث، عندما يكون هناك انقطاع إقليمي كامل لمنطقة Azure التي تحتوي على منطقة مقترنة، تفشل مسارات Data Factory أو Azure Synapse تلقائيا في المنطقة المقترنة عند إعداد الاسترداد التلقائي. الاستثناءات هي مناطق جنوب شرق آسيا والبرازيل، حيث تتطلب متطلبات موقع البيانات البيانات للبقاء في تلك المناطق.

في تجاوز فشل DR، يسترد Data Factory البنية الأساسية لبرنامج ربط العمليات التجارية للإنتاج. إذا كنت بحاجة إلى التحقق من صحة المسارات المستردة، يمكنك إجراء نسخ احتياطي لقوالب Azure Resource Manager لمسارات الإنتاج في التخزين السري، ومقارنة المسارات المستردة بالنسخ الاحتياطية.

يجري فريق Azure Global تدريبات BCDR منتظمة، ويشارك Azure Data Factory وAzure Synapse Analytics في هذه التدريبات. يحاكي تدريب BCDR فشل المنطقة ويفشل عبر خدمات Azure إلى منطقة مقترنة دون أي مشاركة من العملاء. لمزيد من المعلومات حول تدريبات BCDR، راجع اختبار الخدمات.

التكرار المدار من قبل المستخدم مع CI/CD

لتحقيق BCDR في حالة فشل المنطقة بأكملها، تحتاج إلى مصنع بيانات أو مساحة عمل Azure Synapse في المنطقة الثانوية. في حالة حذف مسار Data Factory أو Azure Synapse أو الانقطاعات أو أحداث الصيانة الداخلية العرضية، يمكنك استخدام Git وCI/CD لاسترداد المسارات يدويا.

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

حالات الاستخدام المحتملة

التكرار المدار من قبل المستخدم مفيد في سيناريوهات مثل:

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

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

الاعتبارات

تنفذ هذه الاعتبارات ركائز Azure Well-Architected Framework، وهو عبارة عن مجموعة من المبادئ التوجيهية التي يمكن استخدامها لتحسين جودة حمل العمل. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.

الموثوقيه

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

Data Factory وخطوط أنابيب Azure Synapse هي خدمات Azure الأساسية التي تدعم مناطق التوفر، وهي مصممة لتوفير المستوى الصحيح من المرونة والمرونة جنبا إلى جنب مع زمن انتقال منخفض للغاية.

يسمح لك نهج الاسترداد المدار من قبل المستخدم بمتابعة العمل إذا كانت هناك أي أحداث صيانة أو انقطاعات أو أخطاء بشرية في المنطقة الأساسية. باستخدام CI/CD، يمكن أن يتكامل مصنع البيانات وخطوط أنابيب Azure Synapse في مستودع Git ونشرها في منطقة ثانوية للاسترداد الفوري.

تحسين التكلفة

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

يدمج الاسترداد المدار من قبل المستخدم Data Factory مع Git باستخدام CI/CD، ويستخدم اختياريا منطقة DR ثانوية تحتوي على جميع تكوينات البنية الأساسية الضرورية كنسخة احتياطية. قد يتحمل هذا السيناريو تكاليف إضافية. لتقدير التكاليف، استخدم حاسبة تسعير Azure.

للحصول على أمثلة لتسعير Data Factory وAzure Synapse Analytics، راجع:

التميز التشغيلي

يغطي التميز التشغيلي عمليات التشغيل التي تحافظ على تشغيل التطبيق في الإنتاج. لمزيد من المعلومات، يرجى مراجعةنظرة عامة على ركيزة التميز التشغيلي.

باستخدام نهج استرداد CI/CD المدار من قبل المستخدم، يمكنك التكامل مع Azure Repos أو GitHub. لمزيد من المعلومات حول أفضل ممارسات CI/CD، راجع أفضل الممارسات ل CI/CD.

نشر هذا السيناريو

اتخذ الإجراءات التالية لإعداد DR التلقائي أو المدار من قبل المستخدم لمصنع البيانات وخطوط أنابيب Azure Synapse.

إعداد الاسترداد التلقائي

في Data Factory، يمكنك تعيين منطقة وقت تشغيل تكامل Azure (IR) لتنفيذ نشاطك أو إرساله في إعداد وقت تشغيل التكامل. لتمكين تجاوز الفشل التلقائي في حالة انقطاع إقليمي كامل، قم بتعيين المنطقة إلى حل تلقائي.

لقطة شاشة توضح تحديد Auto Resolve لتمكين تجاوز الفشل التلقائي في إعداد وقت تشغيل التكامل.

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

  • بالنسبة للشبكات الظاهرية المدارة، يقوم Data Factory أيضا بالتبديل تلقائيا إلى وقت تشغيل التكامل المدار.

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

  • لتكوين BCDR لوقت تشغيل تكامل Azure-SSIS، راجع تكوين وقت تشغيل تكامل Azure-SSIS لاستمرارية الأعمال والتعافي من الكوارث (BCDR).

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

إعداد الاسترداد المدار من قبل المستخدم من خلال CI/CD

يمكنك استخدام Git وCI/CD لاسترداد المسارات يدويا في حالة حذف أو انقطاع مسار Data Factory أو Azure Synapse.

عند نشر التكرار المدار من قبل المستخدم باستخدام CI/CD، اتخذ الإجراءات التالية:

تعطيل المشغلات

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

لاستخدام Azure PowerShell لإيقاف تشغيل مشغلات Data Factory أو تشغيلها، راجع نموذج البرنامج النصي قبل النشر وما بعده وتحسينات CI/CD المتعلقة بنشر مشغلات البنية الأساسية لبرنامج ربط العمليات التجارية.

معالجة الكتابات المكررة

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

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

تحقق من الشاهد وتحكم في تدفق البنية الأساسية لبرنامج ربط العمليات التجارية (اختياري)

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

  1. أضف معلمة عمومية في مصنع البيانات للإشارة إلى المنطقة، على سبيل المثال region='EastUS' في مصنع البيانات الأساسي والثانوي region='CentralUS' .

  2. إنشاء شاهد في منطقة ثالثة. يمكن أن يكون الشاهد مكالمة REST أو أي نوع من التخزين. يقوم الشاهد بإرجاع المنطقة الأساسية الحالية، على سبيل المثال 'EastUS'، بشكل افتراضي.

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

  4. أضف نشاطا في البنية الأساسية لبرنامج ربط العمليات التجارية للبحث عن الشاهد ومقارنة القيمة الأساسية الحالية بالمعلمة العمومية.

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

إشعار

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

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكتاب الرئيسيون:

مساهمون آخرون:

  • ماريو زيمرمان | مدير هندسة البرمجيات الرئيسي - فريق Azure Data Factory

  • Wee Hyong Tok | المدير الرئيسي ل PM - فريق Azure Data Factory

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

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