الموثوقية في Azure Event Grid ومساحة اسم Event Grid

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

للحصول على نظرة عامة معمارية على الموثوقية في Azure، راجع موثوقية Azure.

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

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

لمزيد من المعلومات حول مناطق التوفر في Azure، راجع ما هي مناطق التوفر؟

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

تحقق مساحة اسم Azure Event Grid أيضا توفرا عاليا داخل المنطقة باستخدام مناطق التوفر.

المتطلبات الأساسية

لدعم منطقة التوفر، يجب أن تكون موارد Event Grid في منطقة تدعم مناطق التوفر. لمراجعة المناطق التي تدعم مناطق التوفر، راجع قائمة المناطق المدعومة.

التسعير

نظرا لأن Event Grid تدعم مناطق التوفر تلقائيا في المناطق التي تدعم مناطق التوفر، فلا توجد تغييرات في السعر.

إنشاء مورد مع تمكين مناطق التوفر

نظرا لأن Event Grid تدعم مناطق التوفر تلقائيا في المناطق التي تدعم مناطق التوفر، فلا يوجد تكوين إعداد مطلوب.

الترحيل إلى دعم منطقة التوفر

إذا قمت بنقل موارد Event Grid إلى منطقة تدعم مناطق التوفر، فستتلقى دعم منطقة التوفر تلقائيا. لمعرفة كيفية نقل مواردك إلى منطقة أخرى تدعم مناطق التوفر، راجع ما يلي:

• نقل موضوعات نظام Azure Event Grid إلى منطقة أخرى
• نقل مواضيع Azure Event Grid المخصصة إلى منطقة أخرى
• نقل مجالات Azure Event Grid إلى منطقة أخرى

التعافي من الكوارث عبر المناطق واستمرارية الأعمال

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

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

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

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

تدعم Event Grid كلا من التعافي من الكوارث الجغرافية اليدوية والتلقائية (GeoDR) على جانب الخادم. لا يزال بإمكانك تطبيق منطق التعافي من الكوارث من جانب العميل إذا كنت تريد تحكمًا أكبر في عملية تجاوز الفشل. للحصول على تفاصيل حول GeoDR التلقائي، راجع Server-side geo disaster recovery in Azure Event Grid. للحصول على تفاصيل حول كيفية تنفيذ التعافي من الكوارث من جانب العميل، راجع تنفيذ تجاوز الفشل من جانب العميل في Azure Event Grid.

يوضح الجدول التالي تجاوز الفشل من جانب العميل ودعم التعافي من الكوارث الجغرافية في Event Grid.

مساحة اسم شبكة الأحداث

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

مع تنفيذ تجاوز الفشل من جانب العميل، يمكنك:

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

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

• تحقيق حل Active-Active DR عن طريق نسخ بيانات التعريف وموازنة التحميل عبر مساحات الأسماء. يمكن تحقيق حل Active-Passive DR عن طريق نسخ بيانات التعريف نسخا متماثلا للحفاظ على مساحة الاسم الثانوية جاهزة بحيث عندما تكون مساحة الاسم الأساسية غير متوفرة، يمكن توجيه نسبة استخدام الشبكة إلى مساحة الاسم الثانوية.

إعداد عملية الإصلاح بعد الكارثة

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

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

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

  قم بتمكين هذه الوظيفة عن طريق تحديث التكوين لموضوعك أو مجالك. حدد Cross-Geo (افتراضي) لتمكين تجاوز الفشل الذي بدأته Microsoft.

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

  هناك بعض الأسباب التي قد تدفعك إلى تعطيل ميزة تجاوز الفشل التي بدأتها Microsoft:

  • يتم تجاوز الفشل الذي بدأته Microsoft على أساس أفضل جهد.
  • لا تفي بعض الأزواج الجغرافية بمتطلبات موقع بيانات مؤسستك.

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

  

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

تجربة تجاوز الفشل للتعافي من الكوارث

يتم قياس التعافي من الكوارث بقياسين، هدف نقطة الاسترداد (RPO) وهدف وقت الاسترداد (RTO). لمزيد من المعلومات، راجع ما هي استمرارية الأعمال، وقابلية الوصول العالية، والتعافي من الكوارث؟.

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

هدف نقطة الاسترداد (RPO)

• Metadata RPO: صفر دقيقة. بالنسبة للموارد القابلة للتطبيق، عند إنشاء/تحديث/حذف مورد، يتم نسخ تعريف المورد بشكل متزامن إلى الزوج الجغرافي. عند حدوث تجاوز الفشل، لا يتم فقد أي بيانات تعريف.

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

هدف وقت الاسترداد (RTO)

• بيانات التعريف RTO: يعتمد اتخاذ قرار تجاوز الفشل على عوامل مثل السعة المتاحة في منطقة مقترنة ويمكن أن تستمر في نطاق 60 دقيقة أو أكثر. بمجرد بدء تجاوز الفشل، في غضون 5 دقائق، تبدأ Event Grid في قبول استدعاءات الإنشاء/التحديث/الحذف للموضوعات والاشتراكات.

• Data RTO: نفس المعلومات المذكورة أعلاه.

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

• إنشاء الاسترداد بعد الكوارث من جانب العميل لمواضيع Azure Event Grid.

• الموثوقية في Azure