إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
مركز أزور إنترنت الأشياء هو خدمة مدارة مستضافة في السحابة وتعمل كمركز رسائل مركزي للتواصل بين تطبيق إنترنت الأشياء وأجهزته الملحقة.
عند استخدام Azure، تعد الموثوقية مسؤولية مشتركة. توفر Microsoft مجموعة من الإمكانات لدعم المرونة والاسترداد. أنت مسؤول عن فهم كيفية عمل هذه الإمكانات في جميع الخدمات التي تستخدمها، وتحديد الإمكانات التي تحتاجها لتحقيق أهداف عملك وأهداف وقت التشغيل.
تصف هذه المقالة كيفية جعل مركز إنترنت الأشياء مقاوما لمجموعة متنوعة من الانقطاعات والمشاكل المحتملة، بما في ذلك الأعطال المؤقتة، وانقطاعات مناطق التوفر، وانقطاعات المناطق. كما يشرح كيف يمكنك استخدام النسخ الاحتياطية للتعافي من أنواع أخرى من المشاكل، ويبرز بعض المعلومات الأساسية حول اتفاقية مستوى خدمة مركز إنترنت الأشياء (SLA).
المرونة في مواجهة الأعطال العابرة
الأخطاء العابرة هي حالات فشل قصيرة متقطعة في المكونات. تحدث بشكل متكرر في بيئة موزعة مثل السحابة، وهي جزء طبيعي من العمليات. الأخطاء العابرة تصحح نفسها بعد فترة زمنية قصيرة. من المهم أن تتمكن تطبيقاتك من معالجة الأخطاء العابرة، عادة عن طريق إعادة محاولة الطلبات المتأثرة.
يجب أن تتبع جميع التطبيقات المستضافة على السحابة إرشادات معالجة الأخطاء العابرة ل Azure عند الاتصال بأي واجهات برمجة تطبيقات وقواعد بيانات ومكونات أخرى مستضافة على السحابة. لمزيد من المعلومات، راجع توصيات للتعامل مع الأخطاء العابرة.
يوفر IoT Hub ضمان وقت تشغيل مرتفع بشكل معقول، ولكن يمكن أن تحدث حالات فشل عابرة في أي نظام أساسي للحوسبة الموزعة. لمعالجة حالات الفشل العابرة، أنشئ أنماط إعادة المحاولة المناسبة في المكونات التي تتفاعل مع التطبيقات السحابية.
المرونة في مواجهة حالات فشل منطقة التوفر
مناطق التوفر هي مجموعات منفصلة فعليا من مراكز البيانات داخل منطقة Azure. عند فشل منطقة واحدة، يمكن أن تفشل الخدمات إلى إحدى المناطق المتبقية.
يدعم IoT Hub نوعين متميزين من دعم منطقة التوفر:
تكرار المنطقة للبيانات، والذي يقوم تلقائيا بنسخ البيانات بين مناطق توفر متعددة لمكونات التخزين الأساسية التي تخزن سجل هوية الجهاز والرسائل من جهاز إلى سحابة.
تكرار المنطقة للحساب، والذي يوفر المرونة في المكونات المسؤولة عن إدارة الأجهزة وتوجيه الرسائل.
دعم المنطقة
يعتمد نوع دعم منطقة التوفر لمركز IoT الخاص بك على المنطقة التي تم نشرها فيها.
| المنطقة | تكرار المنطقة للبيانات | تكرار المنطقة للحساب |
|---|---|---|
| شرق أستراليا |
|
|
| جنوب البرازيل |
|
|
| وسط كندا |
|
|
| وسط الهند |
|
|
| وسط الولايات المتحدة |
|
|
| شرق الولايات المتحدة |
|
|
| وسط فرنسا |
|
|
| وسط غرب ألمانيا |
|
|
| شرق اليابان |
|
|
| وسط كوريا |
|
|
| أوروبا الشمالية |
|
|
| شرق النرويج |
|
|
| قطر الوسطى |
|
|
| جنوب وسط الولايات المتحدة |
|
|
| جنوب شرق آسيا |
|
|
| جنوب المملكة المتحدة |
|
|
| أوروبا الغربية |
|
|
| غرب الولايات المتحدة 2 |
|
|
| غرب الولايات المتحدة الأمريكية 3 |
|
|
مراكز IoT التي تقوم بإنشائها في المناطق غير الموجودة في هذه القائمة غير مرنة في مواجهة انقطاعات المنطقة.
التكلفة
لا توجد تكلفة إضافية لتكرار المنطقة مع IoT Hub.
تكوين دعم منطقة التوفر
تدعم موارد IoT Hub تلقائيا تكرار المنطقة عند نشرها في المناطق المدعومة. لا يلزم تكوين إضافي.
السلوك عندما تكون جميع المناطق صحية
يصف هذا القسم ما يمكن توقعه عند تكوين موارد IoT Hub لتكرار المنطقة وجميع مناطق التوفر قيد التشغيل.
النسخ المتماثل للبيانات بين المناطق: عند نشر مركز IoT في منطقة تدعم تكرار المنطقة للبيانات، يتم نسخ التغييرات في البيانات بين مناطق التوفر تلقائيا. يحدث النسخ المتماثل بشكل متزامن.
توجيه نسبة استخدام الشبكة بين المناطق: عند نشر مركز IoT في منطقة تدعم تكرار المنطقة لمكونات الحوسبة، يتم توجيه الطلبات إلى مثيل أساسي للخدمة في إحدى مناطق التوفر. يحدد Azure المثيل النشط والمنطقة تلقائيا.
السلوك أثناء فشل المنطقة
يصف هذا القسم ما يمكن توقعه عند تكوين موارد IoT Hub لتكرار المنطقة وهناك انقطاع في منطقة التوفر.
- الكشف والاستجابة: خدمة IoT Hub مسؤولة عن الكشف عن فشل في منطقة توفر. لا تحتاج إلى القيام بأي شيء لبدء تجاوز فشل المنطقة.
- الإعلام: لا تقوم Microsoft بإعلامك تلقائيا عندما تكون المنطقة معطلة. ومع ذلك، يمكنك استخدام Azure Resource Health لمراقبة صحة كل مورد على حدة، ويمكنك إعداد تنبيهات Resource Health لإبلاغك بالمشاكل. يمكنك أيضا استخدام Azure Service Health لفهم الصحة العامة للخدمة، بما في ذلك أي أعطال في المناطق، ويمكنك إعداد تنبيهات صحة الخدمة لإبلاغك بالمشاكل.
الطلبات النشطة: أثناء فشل المنطقة، قد يتم إسقاط الطلبات النشطة. يجب أن يكون لدى عملائك وأجهزتك منطق إعادة محاولة كاف مطبق لمعالجة الأخطاء العابرة.
فقدان البيانات المتوقع: عند نشر مركز IoT في منطقة تدعم تكرار المنطقة للبيانات، يجب ألا يتسبب فشل المنطقة في أي فقدان للبيانات.
وقت التعطل المتوقع: عند نشر مركز IoT في منطقة تدعم تكرار المنطقة لكل من مكونات الحوسبة والبيانات، يجب ألا يتسبب فشل المنطقة في توقف موارد IoT Hub.
إعادة توجيه حركة المرور: عند نشر مركز IoT في منطقة تدعم تكرار المنطقة لمكونات الحساب، يكتشف IoT Hub فقدان المنطقة. بعد ذلك، تتم إعادة توجيه أي طلبات جديدة تلقائيا إلى مثيل أساسي جديد للخدمة في إحدى مناطق التوفر السليمة.
استعادة المنطقة
عند استرداد منطقة التوفر، يقوم IoT Hub تلقائيا باستعادة المثيلات في منطقة التوفر وإعادة توجيه نسبة استخدام الشبكة بين مثيلاتك كالمعتاد.
اختبار فشل المنطقة
نظرا لأن IoT Hub يدير توجيه نسبة استخدام الشبكة وتجاوز الفشل وإرجاع الموارد بشكل كامل لحالات فشل المنطقة، فلن تحتاج إلى التحقق من صحة عمليات فشل منطقة التوفر أو توفير أي إدخال إضافي.
القدرة على الصمود في وجه الإخفاقات على مستوى المنطقة
IoT Hub هي خدمة من منطقة واحدة. إذا أصبحت المنطقة غير متوفرة، فإن موارد IoT Hub غير متوفرة أيضا.
ومع ذلك، إذا كانت مواردك في منطقة مقترنة، يتم نسخ بيانات مركز IoT إلى المنطقة المقترنة.
قد يفشل مركز IoT الخاص بك إلى المنطقة المقترنة في السيناريوهات التالية:
تجاوز الفشل الذي بدأه العميل: يمكنك تشغيل تجاوز الفشل اليدوي إلى المنطقة المقترنة بنفسك، سواء كانت المنطقة تواجه وقت تعطل أم لا. يمكنك استخدام هذا الأسلوب لإجراء عمليات تجاوز الفشل والتنقلات المخطط لها.
تجاوز الفشل الذي بدأته Microsoft: إذا فقدت منطقة، يمكن ل Microsoft بدء تجاوز فشل مراكز IoT إلى المنطقة المقترنة. ومع ذلك، من غير المحتمل أن تبدأ Microsoft تجاوز الفشل إلا بعد تأخير كبير وعلى أساس أفضل جهد. قد يحدث تجاوز الفشل لموارد IoT Hub في وقت مختلف عن تجاوز الفشل لخدمات Azure الأخرى. هذه العملية هي خيار افتراضي ولا تتطلب أي تدخل منك.
إذا كانت الموارد في منطقة غير مدفوعة، فلن تقوم Microsoft بنسخ التكوين والبيانات عبر المناطق، ولا يوجد تجاوز فشل مضمن عبر المناطق. ومع ذلك، يمكنك نشر موارد منفصلة في مناطق متعددة. في هذا السيناريو، تقع على عاتقك مسؤولية إدارة النسخ المتماثل وتوزيع نسبة استخدام الشبكة وتجاوز الفشل.
إذا كان مركز إنترنت الأشياء الخاص بك في منطقة غير مرتبطة، أو إذا لم يلبي سلوك النسخ الافتراضي وتجاوز الفشل احتياجاتك، يمكنك استخدام حلول متعددة المناطق مخصصة للمرونة للتخطيط وبدء عمليات التجاوز (Failovers).
دعم المنطقة
النسخ المتماثل الافتراضي وتجاوز الفشل مدعومان فقط في المناطق المقترنة.
المتطلبات
تتوفر خيارات النسخ المتماثل للمنطقة المقترنة وتجاوز الفشل لجميع مستويات IoT Hub.
الاعتبارات
لا تستخدم تجاوز الفشل الذي بدأه العميل لترحيل المركز الخاص بك بشكل دائم بين المناطق المقترنة ب Azure. بشكل عام، توجد الأجهزة بالقرب من المنطقة الأساسية للمركز. إذا قمت بنقل المركز إلى المنطقة الثانوية، يزداد زمن الانتقال للعمليات بين الأجهزة ومركز IoT في الموقع الثانوي.
التكلفة
بالنسبة إلى المراكز في المناطق المقترنة، لا توجد تكلفة إضافية للنسخ المتماثل للبيانات عبر المناطق أو تجاوز الفشل.
إذا كان مركز إنترنت الأشياء الخاص بك في منطقة غير مرتبطة، راجع حلول مخصصة متعددة المناطق للمرونة للحصول على معلومات محتملة عن التكاليف.
تكوين النسخ المتماثل والاستعداد لتجاوز الفشل
بشكل افتراضي، يتم تكوين النسخ المتماثل للبيانات عبر المناطق تلقائيا عند إنشاء مركز IoT في منطقة مقترنة. هذه العملية هي خيار افتراضي ولا تتطلب أي تدخل منك. في المناطق باستثناء جنوب البرازيل وجنوب شرق آسيا (سنغافورة)، لا يتم تخزين بيانات العملاء أو معالجتها خارج المنطقة الجغرافية حيث تقوم بنشر مثيل الخدمة.
إذا كان مركز IoT الخاص بك في مناطق جنوب البرازيل أو جنوب شرق آسيا (سنغافورة)، يمكنك تعطيل النسخ المتماثل للبيانات وإلغاء تجاوز الفشل. لمزيد من المعلومات، راجع تعطيل التعافي من الكوارث (DR).
إذا كان مركز IoT الخاص بك في منطقة غير مدفوعة، فأنت بحاجة إلى تخطيط نهج النسخ المتماثل وتجاوز الفشل الخاص بك عبر المناطق. لمزيد من المعلومات، راجع الحلول المخصصة متعددة المناطق للمرونة.
السلوك عندما تكون جميع المناطق صحية
يصف هذا القسم ما يمكن توقعه عند تكوين مركز IoT للنسخ المتماثل عبر المناطق وتجاوز الفشل، وتكون المنطقة الأساسية قيد التشغيل.
النسخ المتماثل للبيانات بين المناطق: يتم نسخ البيانات تلقائيا إلى المنطقة المقترنة. يحدث النسخ المتماثل بشكل غير متزامن، ما يعني أنه من المتوقع فقدان بعض البيانات في حالة حدوث تجاوز الفشل. لا يوجد نسخ متماثل للبيانات بين المناطق لمراكز IoT في المناطق غير المدفوعة.
توجيه نسبة استخدام الشبكة بين المناطق: في العمليات العادية، تتدفق نسبة استخدام الشبكة فقط إلى المنطقة الأساسية.
السلوك أثناء فشل المنطقة
يصف هذا القسم ما يمكن توقعه عند تكوين مركز IoT للنسخ المتماثل عبر المناطق وتجاوز الفشل وهناك انقطاع في المنطقة الأساسية.
الكشف والاستجابة: يمكن أن تختلف مسؤولية الكشف عن انقطاع التيار الكهربائي والاستجابة له في المنطقة الأساسية.
تجاوز الفشل الذي بدأه العميل: أنت مسؤول عن الكشف عن فقدان منطقة وتحديد وقت تجاوز الفشل. لمزيد من المعلومات حول كيفية تنفيذ تجاوز الفشل الذي بدأه العميل بين المناطق المقترنة، راجع تنفيذ تجاوز الفشل اليدوي لمركز IoT.
هناك حدود لمدى تكرار تنفيذ تجاوز الفشل أو إرجاع الموارد الذي بدأه العميل:
يسمح للمستخدمين بتنفيذ عمليتين ناجحتين لتجاوز الفشل عمليتين ناجحتين لإرجاع الموارد يوميا.
لا يسمح بعمليات تجاوز الفشل أو إرجاع الموارد مرة أخرى. يجب الانتظار لمدة ساعة واحدة بين هذه العمليات.
تجاوز الفشل الذي بدأته Microsoft: يمكن أن تقرر Microsoft إجراء تجاوز فشل إذا فقدت المنطقة الأساسية. قد تستغرق هذه العملية عدة ساعات بعد فقدان المنطقة الأساسية، أو حتى لفترة أطول في بعض السيناريوهات. قد لا يحدث تجاوز الفشل لموارد IoT Hub في نفس الوقت مثل خدمات Azure الأخرى.
الطلبات النشطة: من المحتمل أن تفقد أي طلبات تعالجها المنطقة الأساسية أثناء تجاوز الفشل. يجب على العملاء إعادة محاولة الطلبات بعد اكتمال تجاوز الفشل.
فقدان البيانات المتوقع: بالنسبة للمناطق المقترنة، يتم نسخ البيانات بشكل غير متزامن إلى المنطقة المقترنة. ونتيجة لذلك، من المتوقع فقدان بعض البيانات بعد تجاوز الفشل. تنطبق هذه العملية على كل من عمليات تجاوز الفشل المدارة من قبل Microsoft والمدارة من قبل العميل. يوضح الجدول التالي هدف نقطة الاسترداد (RPO)، أو فقدان البيانات المتوقع، لكل نوع من البيانات التي تخزنها مراكز IoT.
نوع البيانات هدف نقطة الاسترداد (RPO) تسجيل الهوية فقدان البيانات من 0 إلى 5 دقائق بيانات الجهاز المزدوج فقدان البيانات من 0 إلى 5 دقائق الرسائل من السحابة إلى الجهاز 1 فقدان البيانات من 0 إلى 5 دقائق مهام الأصل 1 والجهاز فقدان البيانات من 0 إلى 5 دقائق رسائل من جهاز إلى سحابة يتم فقدان جميع الرسائل غير المقروءة رسائل الملاحظات من السحابة إلى الجهاز يتم فقدان جميع الرسائل غير المقروءة 1 لا يتم استرداد الرسائل من السحابة إلى الجهاز والمهام الأصلية كجزء من تجاوز الفشل الذي بدأه العميل.
وقت التعطل المتوقع: يعتمد وقت التعطل المتوقع أثناء تجاوز فشل المنطقة على نوع تجاوز الفشل.
تجاوز الفشل الذي بدأه العميل: توقع ما يقرب من 10 دقائق إلى ساعتين من وقت التوقف عن العمل من وقت فقدان المنطقة إلى عند تشغيل المورد في المنطقة المقترنة. يؤثر عدد الأجهزة المسجلة مقابل مثيل مركز IoT الذي يتم فشله على وقت الاسترداد. يمكنك توقع أن يكون وقت الاسترداد لمركز يستضيف حوالي 100,000 جهاز حوالي 15 دقيقة.
تجاوز الفشل الذي بدأته Microsoft: توقع ما يقرب من 2 إلى 26 ساعة من وقت التوقف عن العمل من وقت فقدان المنطقة إلى عند توفر المورد في المنطقة المقترنة.
يرجع مقدار وقت الاسترداد المرتفع إلى أنه يجب على Microsoft تنفيذ عملية تجاوز الفشل نيابة عن جميع العملاء المتأثرين في تلك المنطقة. بالنسبة للأنظمة الهامة، يجب استخدام تجاوز الفشل الذي بدأه العميل لتحقيق وقت تعطل أقل. ومع ذلك، إذا قمت بتشغيل حل IoT أقل أهمية يمكنه الحفاظ على وقت تعطل لمدة يوم واحد تقريبا، فقد يكون من الممكن الاعتماد على الخيار الذي بدأته Microsoft لتلبية أهداف الإصلاح بعد الكوارث الشاملة لحل IoT الخاص بك.
لكلا نوعي تجاوز الفشل، يظل اسم المجال المؤهل بالكامل لمثيل مركز IoT كما هو بعد تجاوز الفشل، مما يعني أن سلسلة الاتصال تظل هي نفسها أيضا. ومع ذلك، نظرا لتغيير عنوان IP الأساسي، يجب على العملاء الانتظار حتى يتم تحديث سجلات نظام أسماء المجالات (DNS) قبل الوصول إلى مركز IoT بعد تجاوز الفشل.
هام
لا تقوم IoT Hub SDKs بالتخزين المؤقت لعنوان IP لمركز IoT. يجب ألا يخزن رمز المستخدم المتداخل مع SDKs أيضا عنوان IP لمركز IoT مؤقتا.
وبسبب هذه العوامل، يمكن التعبير عن وقت عمليات وقت التشغيل التي يتم إجراؤها مقابل مثيل مركز IoT الخاص بك لتصبح تعمل بشكل كامل بعد عملية تجاوز الفشل باستخدام الدالة التالية:
وقت الاسترداد = RTO [من 10 دقائق إلى ساعتين لتجاوز الفشل الذي بدأه العميل أو من ساعتين إلى 26 ساعة لتجاوز الفشل الذي بدأته Microsoft] + تأخير نشر DNS + الوقت الذي يستغرقه تطبيق العميل لتحديث أي عنوان IP لمركز IoT مخزن مؤقتا
إعادة توجيه حركة المرور: أثناء عملية تجاوز الفشل، يقوم IoT Hub بتحديث سجلات DNS للإشارة إلى المنطقة المقترنة. يتم إرسال جميع الطلبات اللاحقة إلى المنطقة المقترنة.
بعد اكتمال عملية تجاوز الفشل لمركز IoT، من المتوقع أن تستمر جميع العمليات من الجهاز والتطبيقات الخلفية في العمل دون الحاجة إلى تدخل يدوي. تضمن هذه الاستمرارية استمرار عمل الرسائل من جهاز إلى سحابة، وأن سجل الجهاز بأكمله سليم. إذا قمت ببعث أحداث من خلال Azure Event Grid، يمكن استهلاكها عبر نفس الاشتراكات التي قمت بتكوينها سابقا طالما أن اشتراكات Event Grid هذه لا تزال متوفرة. لا يلزم إجراء أي معالجة أخرى لنقاط النهاية المخصصة.
مطلوب تكوين ما بعد تجاوز الفشل
اعتمادا على المكان الذي توجه فيه رسائل مركز IoT، قد تحتاج إلى تنفيذ خطوات إضافية بعد اكتمال تجاوز الفشل.
مراكز أحداث Azure: يتغير الاسم المتوافق مع مراكز الأحداث ونقطة النهاية لنقطة نهاية الأحداث المضمنة في مركز IoT بعد تجاوز الفشل. يحدث هذا التغيير لأن عميل Event Hubs ليس لديه رؤية في أحداث IoT Hub.
عند تلقي رسائل بيانات تتبع الاستخدام من نقطة النهاية المضمنة باستخدام عميل مراكز الأحداث أو مضيف معالج الأحداث، استخدم سلسلة اتصال مركز IoT لإنشاء الاتصال. يضمن هذا النهج استمرار تطبيقاتك الخلفية في العمل دون الحاجة إلى تدخل يدوي بعد تجاوز الفشل.
إذا كنت تستخدم الاسم المتوافق مع مراكز الأحداث ونقطة النهاية في تطبيقك مباشرة، فستحتاج إلى إحضار نقطة النهاية الجديدة المتوافقة مع مراكز الأحداث بعد تجاوز الفشل لمتابعة العمليات. لاسترداد نقطة النهاية والاسم، يمكنك استخدام مدخل Microsoft Azure أو .NET SDK:
مدخل Azure: لمزيد من المعلومات حول كيفية استخدام المدخل لاسترداد نقطة النهاية المتوافقة مع مراكز الأحداث والاسم المتوافق مع مراكز الأحداث، راجع الاتصال بنقطة النهاية المضمنة.
.NET SDK: لاستخدام سلسلة اتصال مركز IoT لاستعادة نقطة النهاية المتوافقة مع مراكز الأحداث، استخدم نموذج التعليمات البرمجية. يستخدم مثال التعليمات البرمجية هذا سلسلة الاتصال للحصول على نقطة نهاية مراكز الأحداث الجديدة وإعادة إنشاء الاتصال. يجب أن يكون لديك Visual Studio تثبيت.
Azure Functions وAzure Stream Analytics: إذا كنت تستخدم Azure Functions أو Stream Analytics للاتصال بنقطة نهاية الأحداث المضمنة، يجب تحديث نقطة نهاية مراكز الأحداث التي تتصل بها الوظيفة أو الوظيفة، باتباع نفس العملية الموضحة في نقطة التعداد النقطي السابقة. ثم قم بتنفيذ إجراء إعادة التشغيل لأن أي إزاحات دفق حدث تصبح غير صالحة بعد تجاوز الفشل.
تخزين Azure: عند التوجيه إلى Azure Storage، قم بإدراج الكائنات الثنائية كبيرة الحجم أو الملفات أولا. ثم قم بالتكرار فوقها للتأكد من قراءة جميع الكائنات الثنائية كبيرة الحجم أو الملفات دون افتراض التقسيم. يمكن أن يتغير نطاق القسم أثناء تجاوز الفشل الذي بدأته Microsoft أو تجاوز الفشل الذي بدأه العميل. يمكنك استخدام List Blobs API لتعداد قائمة الكائنات الثنائية كبيرة الحجم أو واجهة برمجة تطبيقات List Azure Data Lake Storage لقائمة الملفات. لمزيد من المعلومات، راجع Azure Storage كنقطة نهاية توجيه.
انتعاش المنطقة
للعودة إلى المنطقة الأساسية، يمكنك تشغيل إجراء تجاوز الفشل يدويا مرة ثانية. من المهم تذكر القيود المفروضة على عدد مرات تجاوز الفشل.
إذا تم تنفيذ عملية تجاوز الفشل الأصلية للاسترداد من انقطاع موسع في المنطقة الأساسية الأصلية، فنفذ إعادة الفشل إلى المنطقة الأساسية بعد استرداد المنطقة الأساسية من الانقطاع.
اختبار حالات فشل المنطقة
لمحاكاة فشل أثناء انقطاع المنطقة، يمكنك تشغيل تجاوز فشل يدوي لمركز IoT الخاص بك. ومع ذلك، نظرا لأن تجاوز الفشل الإقليمي يتسبب في كل من وقت التعطل وفقدان البيانات، يجب إجراء عمليات تجاوز فشل الاختبار فقط في البيئات غير المنتجة. لمزيد من المعلومات، راجع السلوك أثناء فشل المنطقة. ضع في اعتبارك إعداد مثيل IoT Hub تجريبي لبدء خيار تجاوز الفشل المخطط له بشكل دوري. يمكن أن يساعدك الاختبار الدوري على بناء الثقة في قدرتك على استعادة الحلول الشاملة وتشغيلها بفعالية عند حدوث كارثة حقيقية.
حلول مخصصة متعددة المناطق للمرونة
قدرات تجاوز الفشل عبر المناطق ل IoT Hub غير مناسبة للسيناريوهات التالية:
مركز IoT الخاص بك في منطقة غير مدفوعة.
لا تفي أهداف وقت تشغيل عملك بوقت الاسترداد أو فقدان البيانات الذي يوفره خيار تجاوز الفشل المضمن.
تحتاج إلى تجاوز الفشل في منطقة ليست زوج منطقتك الأساسية.
يمكنك تصميم حل تجاوز الفشل عبر المناطق مصمم خصيصا لكل جهاز على حدة. إن المعالجة الكاملة لطوبولوجيا التوزيع في حلول IoT خارج نطاق هذه المقالة، ولكن يمكنك التفكير في نموذج نشر متعدد المناطق. في هذا النموذج، يتم تشغيل مركز IoT الأساسي والواجهة الخلفية للحل بشكل أساسي في منطقة Azure واحدة. يتم نشر مركز IoT ثانوي وواجهة خلفية في منطقة Azure أخرى. إذا واجه مركز IoT في المنطقة الأساسية انقطاعا أو تمت مقاطعة اتصال الشبكة من الجهاز إلى المنطقة الأساسية، تستخدم الأجهزة نقطة نهاية خدمة ثانوية.
وقت التعطل المتوقع: يحتوي هذا النهج على أقل من دقيقة واحدة من وقت التعطل ولكن يمكن أن يكون تنفيذه معقدا.
فقدان البيانات المتوقع: يعتمد مقدار فقدان البيانات على مخازن البيانات المحددة التي تستخدمها والطريقة التي تقوم بها بتكوين النسخ المتماثل الجغرافي بينها.
كلف: يتطلب منك هذا النهج توفير مركز IoT إضافي واحد على الأقل، ما يزيد من التكلفة الإجمالية.
على مستوى عال، لتنفيذ نموذج تجاوز الفشل الإقليمي باستخدام IoT Hub، تحتاج إلى اتخاذ التدابير التالية:
مركز IoT ثانوي ومنطق توجيه الجهاز: إذا تعطلت الخدمة في منطقتك الأساسية، يجب أن تبدأ الأجهزة في الاتصال بمنطقتك الثانوية. نظرا للطبيعة المدركة للحالة لمعظم الخدمات المعنية، يقوم مسؤولو الحلول عادة بتشغيل عملية تجاوز الفشل بين المناطق يدويا. أفضل طريقة لتوصيل نقطة النهاية الجديدة بالأجهزة مع الحفاظ على التحكم في العملية هي جعلها تتحقق بانتظام من خدمة concierge لنقطة النهاية النشطة الحالية. يمكن أن تكون خدمة concierge تطبيق ويب يتم نسخه نسخا متماثلا ويبقى قابلا للوصول باستخدام تقنيات إعادة توجيه DNS، مثل Azure Traffic Manager.
إشعار
لا يحتوي Traffic Manager على دعم مضمن ل IoT Hub. يمكنك تكوين نقاط نهاية Traffic Manager مخصصة لكل مركز IoT. قم بتكوين التحقيق الصحي لنقطة نهاية Traffic Manager لاستخدام نقطة نهاية مركز IoT.
النسخ المتماثل لسجل الهوية: لكي يكون قابلا للاستخدام، يجب أن يحتوي مركز IoT الثانوي على جميع هويات الجهاز التي يمكنها الاتصال بالحل. يجب أن يحتفظ الحل بالنسخ الاحتياطية المنسوخة جغرافيا لهويات الجهاز وتحميلها إلى مركز IoT الثانوي قبل تبديل نقطة النهاية النشطة للأجهزة. وظيفة تصدير هوية الجهاز لـ IoT Hub مفيدة في هذا السياق. للمزيد من المعلومات، راجع فهم تسجيل الهوية في مركز IoT في دليل مطور IoT Hub.
منطق الدمج: عندما تصبح المنطقة الأساسية متاحة مرة أخرى، يجب ترحيل جميع الحالة والبيانات التي تم إنشاؤها في المنطقة الثانوية مرة أخرى إلى المنطقة الأساسية. تتعلق هذه الحالة والبيانات في الغالب بهويات الجهاز وبيانات تعريف التطبيق، والتي يجب دمجها مع مركز IoT الأساسي وأي مخازن أخرى خاصة بالتطبيق في المنطقة الأساسية.
لتبسيط هذه الخطوة، استخدم عمليات متكررة . تقلل العمليات المتكررة من الآثار الجانبية من التوزيع المتسق النهائي للأحداث ومن التكرارات أو تسليم الأحداث خارج الترتيب. أيضا، يجب تصميم منطق التطبيق للتسامح مع حالات عدم التناسق المحتملة أو الحالة قديمة قليلا. يمكن أن يحدث هذا السيناريو بسبب الوقت الإضافي الذي يستغرقه النظام للشفاء استنادا إلى RPOs.
النسخ الاحتياطي والاستعادة
تتيح خدمة IoT Hub عمليات التصدير المجمع، والتي تسمح لك بتصدير سجل الهوية بأكمله لمركز IoT. يتم نقل هذه البيانات إلى حاوية كائن ثنائي كبير الحجم ل Azure Storage باستخدام توقيع وصول مشترك. تمكنك هذه الطريقة من إنشاء نسخ احتياطية موثوقة لمعلومات جهازك في حاوية البيانات الثنائية الكبيرة التي تتحكم فيها. لمزيد من المعلومات، راجع استيراد هويات جهاز IoT Hub وتصديرها بشكل مجمع.
يمكنك أيضا تصدير قالب Azure Resource Manager (قالب ARM) لمركز IoT موجود لإنشاء نسخة احتياطية من تكوين مركز IoT. لمزيد من المعلومات، راجع ترحيل مركز IoT يدويا باستخدام قالب ARM.
بالنسبة لمعظم الحلول، يجب ألا تعتمد حصريا على النسخ الاحتياطية. بدلا من ذلك، استخدم الإمكانات الأخرى الموضحة في هذا الدليل لدعم متطلبات المرونة الخاصة بك. ومع ذلك، تحمي النسخ الاحتياطية من بعض المخاطر التي لا تحميها الأساليب الأخرى. لمزيد من المعلومات، راجع ما المقصود بالتكرار والنسخ المتماثل والنسخ الاحتياطي؟.
اتفاقية مستوى الخدمة
تصف اتفاقية مستوى الخدمة (SLA) لخدمات Azure التوفر المتوقع لكل خدمة والشروط التي يجب أن يفي بها الحل الخاص بك لتحقيق توقع التوفر هذا. لمزيد من المعلومات، راجع اتفاقيات مستوى الخدمة للخدمات عبر الإنترنت.