دراسة حالة بنية الحل عالية التوفر لـ Azure HDInsight
يمكن دمج آليات النسخ المتماثل لـ Azure HDInsight داخل هيكل الحل عالي التوفر. في هذه المقالة، يتم استخدام دراسة حالة وهمية لـ Contoso Retail لتوضيح نُهج الإصلاح بعد الكارثة عالية التوفر والممكنة، واعتبارات التكلفة، والتصاميم المقابلة لها.
يمكن أن تحتوي توصيات الإصلاح بعد الكارثة عالية التوفر على العديد من التباديل والمجموعات. ينبغي التوصل إلى هذه الحلول بعد دراسة إيجابيات وسلبيات كل خيار. تتناول هذه المقالة حل واحد ممكن فقط.
هيكل العملاء
توضح الصورة التالية هيكل Contoso Retail الأساسي. يتكون الهيكل من حمل عمل الدفق، وحمل عمل الدفعة، وطبقة الخدمة، وطبقة الاستهلاك، وطبقة العرض، والتحكم بالإصدار.
حمل عمل الدفق
تنتج الأجهزة وأدوات الاستشعار بيانات إلى HDInsight Kafka، والتي تُشكل إطار عمل المراسلة. يقرأ مستهلك HDInsight Spark من مواضيع Kafka. يحول Spark الرسائل الواردة ويكتبها إلى نظام مجموعة HDInsight HBase على طبقة العرض.
حمل عمل الدفعة
يقوم نظام مجموعة HDInsight Hadoop الذي يعمل على Apache Hive وMapReduce باستيعاب البيانات من أنظمة المعاملات الداخلية. يتم تخزين البيانات الأولية التي تم تحويلها بواسطة Apache Hive وMapReduce في جداول Apache Hive على قسم منطقي من مستودع البيانات المدعومة من قِبل Azure Data Lake Storage Gen2. كما يتم توفير البيانات المخزنة في جداول Apache Hive إلى Spark SQL، والتي تقوم بتحويل الدُفعة قبل تخزين البيانات المجمعة في HBase لعرضها.
طبقة العرض
يتم استخدام مجموعة HDInsight HBase مع Apache Phoenix لعرض البيانات على تطبيقات الويب ولوحات المعلومات المرئية. يتم استخدام مجموعة HDInsight LLAP للوفاء بمتطلبات التقارير الداخلية.
طبقة الاستهلاك
تدعم طبقة APIM وتطبيقات واجهة برمجة التطبيقات في Azure صفحة ويب موجهة بشكل عام. يتم استيفاء متطلبات التقارير الداخلية من قِبل Power BI.
طبقة التخزين
يتم استخدام Azure Data Lake Storage Gen2 المقسم بشكل منطقي كمستودع بيانات المؤسسات. يتم دعم مخزن بيانات HDInsight من قِبل Azure SQL DB.
نظام التحكم في الإصدار
نظام التحكم بالإصدار المدمج في البنية الأساسية لبرنامج ربط العمليات التجارية لـ Azure ومستضاف خارج Azure.
متطلبات استمرارية عمل العملاء
من المهم تحديد الحد الأدنى من وظائف الأعمال التي ستحتاجها إذا كانت هناك كارثة.
متطلبات استمرارية أعمال Contoso Retail
- يجب حمايتنا من حدوث أي فشل إقليمي أو مشكلة تتعلق بحالة الخدمة الإقليمية.
- يجب ألا يرى عملائي خطأ 404 أبداً. يجب دائما عرض المحتوى العام. (RTO = 0)
- في معظم أوقات السنة، يمكننا عرض محتوى عام تمت إزالته من 5 ساعات. (RPO = 5 ساعات)
- خلال موسم العطلات، يجب أن يكون المحتوى الذي يواجهه الجمهور دائماً محدثاً. (RPO = 0)
- لا تعتبر متطلبات إعداد التقارير الداخلية ضرورية لاستمرارية العمل.
- تحسين تكاليف استمرارية العمل.
الحل المقترح
تعرض الصورة التالية هيكل الإصلاح بعد الكوارث ذو قابلية وصول عالية في Contoso Retail.
Kafka يستخدم النسخة المتماثلة نشط – سلبي لمطابقة موضوعات Kafka من المنطقة الأساسية إلى المنطقة الثانوية. ويمكن أن يكون البديل لتكرار كافكا هو الإنتاج إلى كافكا في كلتا المنطقتين.
Apache Hive وSpark يستخدمان نماذج النسخ المتماثل أساسي نشط – ثانوي عند الطلب خلال الأوقات العادية. تعمل عملية النسخ المتماثل لـ Apache Hive بشكل دوري وتتضمن مخزن بيانات Hive Azure SQL والنسخ المتماثل لحساب تخزين Apache Hive. يتم النسخ المتماثل لحساب تخزين Spark بشكل دوري باستخدام ADF DistCP. وتساعد الحالة المؤقت التي تتمتع بها أنظمة المجموعات هذه على تحسين التكاليف. تتم جدولة النسخ المتماثل كل 4 ساعات للوصول إلى RPO بشكل جيد ضمن متطلبات الخمس ساعات.
تستخدم النسخة المتماثلة لـ HBase النموذج رئيسي – تابع خلال الأوقات العادية لضمان عرض البيانات دائماً بغض النظر عن المنطقة وانخفاض RPO الشديد.
إذا كان هناك فشل إقليمي في المنطقة الأساسية، يتم عرض صفحة الويب ومحتوى الخلفية من المنطقة الثانوية لمدة 5 ساعات مع درجة ما من التباعد. إذا لم تشر لوحة معلومات حالة خدمة Azure إلى الوقت الوصول المقدر للإصلاح خلال فترة مدتها خمس ساعات، فسيقوم Contoso Retail بإنشاء طبقة تحويل Apache Hive وSpark في المنطقة الثانوية، ثم الإشارة إلى جميع مصادر البيانات المصدر إلى منطقة ثانوية. قد يؤدي جعل المنطقة الثانوية قابلة للكتابة إلى إجراء عملية إرجاع الموارد التي تتضمن النسخ المتماثل مرة أخرى إلى الأساسي.
خلال ذروة موسم التسوق، تكون البنية الأساسية لبرنامج ربط العمليات التجارية الثانوية بأكملها نشطة ودائماً قيد التشغيل. ينتج منتجو Kafka إلى المنطقتين وسيتم تغيير النسخ المتماثل لـ HBase من "رئيسي-تابع" إلى "رئيسي-رئيسي" لضمان تحديث المحتوى الموجه بشكل عام دائماً.
لا يحتاج أي حل لعملية تجاوز الفشل إلى التخصيص لإجراء التقارير الداخلية لأنه ليس أمراً ضرورياً لاستمرارية العمل.
الخطوات التالية
لمعرفة المزيد عن العناصر التي تم تناولها في هذه المقالة، راجع: