في عالم الحوسبة السحابية الديناميكي، يعد ضمان مرونة التطبيقات المهمة وتوافرها أمرًا بالغ الأهمية. التعافي من الكوارث (DR) هي العملية التي من خلالها تتوقع المنظمة الكوارث المتعلقة بالتكنولوجيا وتعالجها. بالنسبة للمؤسسات التي تنفذ تنسيق عبء العمل الحاسم باستخدام تدفقات عمل أمازون المدارة لتدفق أباتشي (Amazon MWAA)، من الضروري وجود خطة DR لضمان استمرارية العمل.
في هذه السلسلة، نستكشف الحاجة إلى التعافي من الكوارث في Amazon MWAA ونصف الحلول التي ستدعم بيئات Amazon MWAA ضد الاضطرابات غير المقصودة. ويتيح لك ذلك تحديد مخاطر الانقطاع وتجنبها والتعامل معها كجزء من خطة استمرارية عملك. يركز هذا المنشور على تصميم بنية DR الشاملة. ستركز إحدى المشاركات المستقبلية في هذه السلسلة على تنفيذ المكونات الفردية باستخدام خدمات AWS.
الحاجة إلى التعافي من الكوارث في Amazon MWAA
Amazon MWAA، خدمة مُدارة بالكامل لـ أباتشي تدفق الهواء، يجلب قيمة هائلة للمؤسسات من خلال أتمتة تنسيق سير العمل لأحمال عمل الاستخراج والتحويل والتحميل (ETL) وDevOps والتعلم الآلي (ML). أمازون MWAA لديه العمارة الموزعة مع مكونات متعددة مثل المجدول والعامل وخادم الويب وقائمة الانتظار وقاعدة البيانات. وهذا يجعل من الصعب تنفيذ استراتيجية شاملة للحد من الكوارث.
تعمل بيئة Amazon MWAA النشطة على تحليل تدفق الهواء بشكل مستمر الرسوم البيانية غير الدورية الموجهة (DAGs)، وقراءتها من تكوينها خدمة تخزين أمازون البسيطة دلو (أمازون S3). يؤدي عدم توفر مصدر DAG بسبب عدم إمكانية الوصول إلى الشبكة أو الفساد غير المقصود أو عمليات الحذف إلى فترة توقف طويلة وانقطاع الخدمة.
ضمن Airflow، تعد قاعدة بيانات البيانات التعريفية مكونًا أساسيًا يقوم بتخزين متغيرات التكوين والأدوار والأذونات وتاريخ تشغيل DAG. لذلك، تعد قاعدة بيانات التعريف الصحية أمرًا بالغ الأهمية لبيئة Airflow لديك. كما هو الحال مع أي مكون أساسي لـ Airflow، يعد وجود خطة احتياطية والتعافي من الكوارث لقاعدة بيانات البيانات التعريفية أمرًا ضروريًا.
تقوم Amazon MWAA بنشر مكونات Airflow إلى عدة مناطق التوفر داخل VPC الخاص بك في المفضل لديك منطقة AWS. وهذا يوفر التسامح مع الأخطاء والاسترداد التلقائي ضد فشل منطقة توافر الخدمات الفردية. بالنسبة لأحمال العمل ذات المهام الحرجة، فإن القدرة على الصمود في مواجهة الإعاقات في المنطقة الموحدة من خلال عمليات النشر متعددة المناطق يعد أمرًا مهمًا أيضًا لضمان التوافر العالي واستمرارية الأعمال.
يعد الموازنة بين تكاليف صيانة البنى التحتية المتكررة والتعقيد ووقت الاسترداد أمرًا ضروريًا لبيئات Amazon MWAA. تهدف المنظمات إلى إيجاد حلول فعالة من حيث التكلفة تقلل من تكاليفها وقت الانتعاش الهدف (RTO) و هدف نقطة الانتعاش (RPO) للوفاء باتفاقيات مستوى الخدمة الخاصة بهم، وتكون قابلة للتطبيق اقتصاديًا، وتلبية متطلبات عملائهم.
الكشف عن الكوارث في البيئة الأولية: المراقبة الاستباقية من خلال المقاييس والإنذارات
يعد الكشف الفوري عن الكوارث في البيئة الأولية أمرًا بالغ الأهمية للتعافي من الكوارث في الوقت المناسب. مراقبة الأمازون CloudWatch مقياس نبضات القلب المجدول يوفر رؤى حول صحة تدفق الهواء لبيئة Amazon MWAA النشطة. يمكنك إضافة مقاييس فحص السلامة الأخرى إلى معايير التقييم، مثل التحقق من توفر الأنظمة الأولية أو النهائية وإمكانية الوصول إلى الشبكة. مدموج مع إنذارات CloudWatch، يمكنك إرسال إشعارات عند عدم استيفاء هذه الحدود لعدد من الفترات الزمنية. يمكنك إضافة تنبيهات إلى لوحات المعلومات لمراقبة واستقبال التنبيهات حول موارد وتطبيقات AWS الخاصة بك عبر مناطق متعددة.
تنشر AWS أحدث المعلومات لدينا حول توفر الخدمة على لوحة معلومات صحة الخدمة. يمكنك التحقق في أي وقت للحصول على معلومات الحالة الحالية، أو الاشتراك في موجز RSS ليتم إعلامك بالانقطاعات لكل خدمة فردية في منطقة التشغيل الخاصة بك. ال لوحة معلومات الصحة في AWS يوفر معلومات حول أحداث AWS Health التي يمكن أن تؤثر على حسابك.
من خلال الجمع بين مراقبة المقاييس ولوحات المعلومات المتاحة والإنذار التلقائي، يمكنك اكتشاف عدم توفر بيئتك الأساسية على الفور، مما يتيح اتخاذ تدابير استباقية للانتقال إلى خطة DR الخاصة بك. من الضروري مراعاة اكتشاف الحوادث والإخطار والتصعيد والاكتشاف والإعلان في تخطيط وتنفيذ حالات الكوارث الخاصة بك لتوفير أهداف واقعية وقابلة للتحقيق توفر قيمة للأعمال.
في الأقسام التالية، نناقش حلين لاستراتيجية Amazon MWAA DR وبنيتهما.
حل استراتيجية DR 1: النسخ الاحتياطي والاستعادة
تتضمن إستراتيجية النسخ الاحتياطي والاستعادة إنشاء نسخ احتياطية لمكونات Airflow في نفس المنطقة أو منطقة مختلفة مثل بيئة Amazon MWAA الأساسية لديك. ولضمان الاستمرارية، يمكنك نسخها بشكل غير متزامن إلى منطقة DR الخاصة بك، مع الحد الأدنى من التأثير على الأداء على بيئة Amazon MWAA الأساسية لديك. في حالة حدوث خلل إقليمي أساسي نادر أو انقطاع الخدمة، ستعمل هذه الإستراتيجية على إنشاء بيئة Amazon MWAA جديدة واستعادة البيانات التاريخية إليها من النسخ الاحتياطية الموجودة. ومع ذلك، من المهم ملاحظة أنه أثناء عملية الاسترداد، ستكون هناك فترة لا تكون فيها بيئات تدفق الهواء جاهزة للعمل لمعالجة سير العمل حتى يتم توفير البيئة الجديدة بالكامل ووضع علامة عليها كمتاحة.
توفر هذه الإستراتيجية حلاً منخفض التكلفة ومنخفض التعقيد ومناسبًا أيضًا للتخفيف من فقدان البيانات أو الفساد داخل منطقتك الأساسية. تؤثر كمية البيانات التي يتم نسخها احتياطيًا والوقت اللازم لإنشاء بيئة Amazon MWAA جديدة (عادةً 20-30 دقيقة) على مدى سرعة حدوث الاستعادة. لتمكين إعادة نشر البنية الأساسية بسرعة دون أخطاء، قم بالنشر باستخدام البنية التحتية كرمز (إياك). بدون IaC، قد يكون من الصعب استعادة بيئة DR مماثلة، مما سيؤدي إلى زيادة أوقات الاسترداد وربما تجاوز RTO الخاص بك.
دعنا نستكشف الإعداد المطلوب عندما تكون بيئة Amazon MWAA الأساسية قيد التشغيل بشكل نشط، كما هو موضح في الشكل التالي.
ويتكون الحل من ثلاثة مكونات رئيسية. المكون الأول هو البيئة الأساسية، حيث يتم في البداية نشر مسارات عمل Airflow وتشغيلها بشكل نشط. المكون الثاني هو مكون مراقبة الكوارث، الذي يتكون من CloudWatch ومجموعة من وظائف خطوة AWS آلة الدولة و AWS لامدا وظيفة. المكون الثالث مخصص لإنشاء وتخزين النسخ الاحتياطية لجميع التكوينات وبيانات التعريف المطلوبة لاستعادتها. يمكن أن يكون هذا في نفس المنطقة الأساسية أو منسوخًا إلى منطقة DR الخاصة بك باستخدام S3 النسخ المتماثل عبر المنطقة (كر). بالنسبة إلى CRR، فإنك تدفع أيضًا مقابل نقل البيانات بين المناطق من Amazon S3 إلى كل منطقة وجهة.
الخطوات الثلاث الأولى في سير العمل هي كما يلي:
- كجزء من عملية إنشاء النسخة الاحتياطية، يتم نسخ بيانات تعريف Airflow إلى حاوية S3 باستخدام تصدير داج الأداة المساعدة، يتم تشغيلها بشكل دوري بناءً على الفاصل الزمني لـ RPO الخاص بك.
- تقوم بيئة Amazon MWAA الأساسية الحالية لديك تلقائيًا بإصدار حالة صحة برنامج الجدولة الخاص بها إلى CloudWatch جدولةنبضات القلب قياس.
- وظائف خطوة متعددة آلة الدولة يتم تشغيله من دورية أمازون إيفينت بريدج جدول لمراقبة الحالة الصحية للمجدول. كخطوة أساسية في جهاز الحالة، تقوم دالة Lambda بتقييم حالة جدولةنبضات القلب قياس. إذا تم اعتبار المقياس سليمًا، فلن يتم اتخاذ أي إجراء.
يوضح الشكل التالي الخطوات الإضافية في سير عمل الحل.
- عندما ينحرف عدد نبضات القلب عن العدد الطبيعي لفترة من الوقت، يتم بدء سلسلة من الإجراءات للتعافي إلى بيئة Amazon MWAA الجديدة في منطقة DR. تتضمن هذه الإجراءات البدء في إنشاء بيئة Amazon MWAA جديدة، وتكرار تكوينات البيئة الأساسية، ثم انتظار توفر البيئة الجديدة.
- عندما تكون البيئة متاحة، أ استيراد داج يتم تشغيل الأداة المساعدة لاستعادة محتويات البيانات التعريفية من النسخ الاحتياطية. يجب إعادة تشغيل أي عمليات تشغيل DAG تمت مقاطعتها أثناء تعطل البيئة الأساسية يدويًا للحفاظ على اتفاقيات مستوى الخدمة. يتم وضع عمليات تشغيل DAG المستقبلية في قائمة الانتظار للتشغيل وفقًا للجدول الزمني التالي الذي تم تكوينه.
حل استراتيجية DR 2: البيئات النشطة والسلبية مع مزامنة دورية للبيانات
تركز البيئات النشطة والسلبية ذات إستراتيجية مزامنة البيانات الدورية على الحفاظ على مزامنة البيانات المتكررة بين بيئة Amazon MWAA DR الأساسية النشطة والسلبية. من خلال التحديث والمزامنة الدورية لمخازن DAG وقواعد بيانات التعريف، تضمن هذه الإستراتيجية بقاء بيئة DR محدثة أو قريبة من البيئة الأساسية. يمكن أن تكون منطقة DR هي نفس المنطقة أو منطقة مختلفة عن بيئة Amazon MWAA الأساسية لديك. في حالة وقوع كارثة، تتوفر النسخ الاحتياطية للعودة إلى حالة جيدة معروفة سابقة لتقليل فقدان البيانات أو تلفها.
توفر هذه الإستراتيجية معدل RTO وRPO منخفضًا مع مزامنة متكررة، مما يسمح بالاسترداد السريع مع الحد الأدنى من فقدان البيانات. تتضاعف تكاليف البنية التحتية وعمليات نشر التعليمات البرمجية للحفاظ على كل من بيئات DR Amazon MWAA الأساسية. بيئة DR الخاصة بك متاحة على الفور لتشغيل DAGs.
يوضح الشكل التالي الإعداد المطلوب عندما تكون بيئة Amazon MWAA الأساسية قيد التشغيل بشكل نشط.
ويتكون الحل من أربعة مكونات رئيسية. كما هو الحال مع حل النسخ الاحتياطي والاستعادة، فإن المكون الأول هو البيئة الأساسية، حيث يتم نشر سير العمل في البداية وتشغيله بشكل نشط. المكون الثاني هو مكون مراقبة الكوارث، الذي يتكون من CloudWatch ومجموعة من جهاز الحالة Step Functions ووظيفة Lambda. يقوم المكون الثالث بإنشاء وتخزين النسخ الاحتياطية لجميع التكوينات وبيانات التعريف المطلوبة لمزامنة قاعدة البيانات. يمكن أن يكون هذا في نفس المنطقة الأساسية الخاصة بك أو منسوخًا إلى منطقة DR الخاصة بك باستخدام Amazon S3 Cross-Region Replication. كما ذكرنا سابقًا، بالنسبة لـ CRR، فإنك تدفع أيضًا مقابل نقل البيانات بين المناطق من Amazon S3 إلى كل منطقة وجهة. المكون الأخير هو بيئة Amazon MWAA السلبية التي تحتوي على نفس كود Airflow وتكوينات البيئة مثل المكون الأساسي. يتم نشر DAGs في بيئة DR باستخدام نفس خط أنابيب التكامل المستمر والتسليم المستمر (CI/CD) باعتباره المسار الأساسي. على عكس الأساسي، يتم الاحتفاظ بـ DAGs في حالة الإيقاف المؤقت حتى لا تتسبب في عمليات تشغيل مكررة.
تشبه الخطوات الأولى لسير العمل استراتيجية النسخ الاحتياطي والاستعادة:
- كجزء من عملية إنشاء النسخ الاحتياطي، يتم نسخ بيانات تعريف Airflow إلى حاوية S3 باستخدام أداة تصدير DAG المساعدة، ويتم تشغيلها بشكل دوري بناءً على الفاصل الزمني لـ RPO الخاص بك.
- تقوم بيئة Amazon MWAA الأساسية الحالية لديك تلقائيًا بإرسال حالة صحة المجدول الخاص بها إلى CloudWatch جدولةنبضات القلب قياس.
- يتم تشغيل آلة حالة Step Functions متعددة الخطوات من جدول Amazon EventBridge الدوري لمراقبة الحالة الصحية للمجدول. كخطوة أساسية في جهاز الحالة، تقوم دالة Lambda بتقييم حالة جدولةنبضات القلب قياس. إذا تم اعتبار المقياس سليمًا، فلن يتم اتخاذ أي إجراء.
ويوضح الشكل التالي الخطوات النهائية لسير العمل.
- عندما ينحرف عدد نبضات القلب عن العدد الطبيعي لفترة من الوقت، يتم بدء إجراءات DR.
- كخطوة أولى، تقوم وظيفة Lambda بتشغيل أداة مساعدة DAG للاستيراد لاستعادة محتويات بيانات التعريف من النسخ الاحتياطية إلى بيئة Amazon MWAA DR السلبية. عند اكتمال عمليات الاستيراد، يمكن لـ DAG نفسه إلغاء الإيقاف المؤقت لـ Airflow DAGs الأخرى، مما يجعلها نشطة لعمليات التشغيل المستقبلية. يجب إعادة تشغيل أي عمليات تشغيل DAG تمت مقاطعتها أثناء تعطل البيئة الأساسية يدويًا للحفاظ على اتفاقيات مستوى الخدمة. يتم وضع عمليات تشغيل DAG المستقبلية في قائمة الانتظار للتشغيل وفقًا للجدول الزمني التالي الذي تم تكوينه.
أفضل الممارسات لتحسين مرونة Amazon MWAA
لتعزيز مرونة بيئة Amazon MWAA الخاصة بك وضمان التعافي السلس من الكوارث، فكر في تنفيذ أفضل الممارسات التالية:
- آليات النسخ الاحتياطي والاستعادة القوية – يعد تنفيذ آليات النسخ الاحتياطي والاستعادة الشاملة لبيانات Amazon MWAA أمرًا ضروريًا. يؤدي حذف بيانات التعريف الموجودة بشكل منتظم بناءً على سياسات الاحتفاظ بمؤسستك إلى تقليل أوقات النسخ الاحتياطي ويجعل بيئة Amazon MWAA الخاصة بك أكثر أداءً.
- الأتمتة باستخدام IaC – استخدام أدوات الأتمتة والتنسيق مثل تكوين سحابة AWSأطلقت حملة مجموعة تطوير سحابة AWS (AWS CDK)، أو Terraform يمكنه تبسيط إدارة النشر والتكوين لبيئات Amazon MWAA. ويضمن ذلك الاتساق وقابلية التكرار والاسترداد الأسرع أثناء سيناريوهات DR.
- DAGs والمهام العاجزة - في Airflow، يعتبر DAG خاملاً إذا كان لإعادة تشغيل نفس DAG بنفس المدخلات عدة مرات نفس تأثير تشغيله مرة واحدة فقط. يؤدي تصميم DAGs غير القادرة والحفاظ على المهام الذرية إلى تقليل وقت الاسترداد من حالات الفشل عندما يتعين عليك إعادة تشغيل DAG المتقطع يدويًا في البيئة المستردة.
- الاختبار المنتظم والتحقق من الصحة - يجب أن تتضمن استراتيجية Amazon MWAA DR القوية اختبارات منتظمة وتمارين التحقق من الصحة. من خلال محاكاة سيناريوهات الكوارث، يمكنك تحديد أي ثغرات في خطط DR الخاصة بك، وضبط العمليات، والتأكد من أن بيئات Amazon MWAA الخاصة بك قابلة للاسترداد بالكامل.
وفي الختام
في هذا المنشور، استكشفنا التحديات التي تواجه التعافي من الكوارث في Amazon MWAA وناقشنا أفضل الممارسات لتحسين المرونة. قمنا بفحص حلين لاستراتيجية DR: النسخ الاحتياطي والاستعادة والبيئات النشطة والسلبية مع مزامنة دورية للبيانات. من خلال تنفيذ هذه الحلول واتباع أفضل الممارسات، يمكنك حماية بيئات Amazon MWAA الخاصة بك، وتقليل وقت التوقف عن العمل، وتخفيف تأثير الكوارث. يعد الاختبار المنتظم والتحقق من الصحة والتكيف مع المتطلبات المتطورة أمرًا بالغ الأهمية لاستراتيجية Amazon MWAA DR الفعالة. من خلال التقييم المستمر لخطط التعافي من الكوارث وتحسينها، يمكنك ضمان المرونة والتشغيل المتواصل لبيئات Amazon MWAA الخاصة بك، حتى في مواجهة الأحداث غير المتوقعة.
للحصول على تفاصيل إضافية وأمثلة التعليمات البرمجية على Amazon MWAA، راجع دليل مستخدم Amazon MWAA و أمثلة Amazon MWAA GitHub repo.
حول المؤلف
بارناب باشاك هو أحد كبار مهندسي الحلول ومتخصص بدون خادم في AWS. وهو متخصص في إنشاء حلول جديدة سحابية أصلية باستخدام ممارسات تطوير البرامج الحديثة مثل بدون خادم، وDevOps، والتحليلات. يعمل Parnab بشكل وثيق في مجال خدمات التحليلات والتكامل لمساعدة العملاء على اعتماد خدمات AWS لتلبية احتياجات تنسيق سير العمل الخاصة بهم.
تشاندان روباخيتي هو مهندس حلول ومتخصص بدون خادم في AWS. إنه قائد تقني شغوف وباحث ومرشد يتمتع بموهبة بناء حلول مبتكرة في السحابة وجمع أصحاب المصلحة معًا في رحلتهم السحابية. وخارج حياته المهنية، يحب قضاء الوقت مع عائلته وأصدقائه إلى جانب الاستماع إلى الموسيقى وتشغيلها.
فينود جاييندرا هو قائد دعم المؤسسات في حسابات ISV في Amazon Web Services، حيث يساعد العملاء في حل تحدياتهم المعمارية والتشغيلية وتحسين التكلفة. ومع التركيز بشكل خاص على التقنيات بدون خوادم، فإنه يستفيد من خلفيته الواسعة في تطوير التطبيقات لتقديم حلول عالية المستوى. بعيدًا عن العمل، يجد المتعة في قضاء وقت ممتع مع العائلة، والشروع في مغامرات ركوب الدراجات، وتدريب فريق رياضي للشباب.
روبيش تيواري هو مهندس حلول أول في AWS في مدينة نيويورك، مع التركيز على الخدمات المالية. يتمتع بخبرة تزيد عن 18 عامًا في مجال تكنولوجيا المعلومات في مجالات التمويل والتأمين والتعليم، وهو متخصص في تصميم التطبيقات واسعة النطاق وأحمال عمل البيانات الضخمة السحابية الأصلية. في أوقات فراغه، يستمتع روبيش بغناء الكاريوكي ومشاهدة المسلسلات التلفزيونية الكوميدية وخلق لحظات بهيجة مع عائلته.
- محتوى مدعوم من تحسين محركات البحث وتوزيع العلاقات العامة. تضخيم اليوم.
- PlatoData.Network Vertical Generative Ai. تمكين نفسك. الوصول هنا.
- أفلاطونايستريم. ذكاء Web3. تضخيم المعرفة. الوصول هنا.
- أفلاطون كربون، كلينتك ، الطاقة، بيئة، شمسي، إدارة المخلفات. الوصول هنا.
- أفلاطون هيلث. التكنولوجيا الحيوية وذكاء التجارب السريرية. الوصول هنا.
- المصدر https://aws.amazon.com/blogs/big-data/disaster-recovery-strategies-for-amazon-mwaa-part-1/
