إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
أثناء دورة حياة حل IoT، من الشائع نقل الأجهزة بين محاور IoT. قد تتضمن أسباب هذه الخطوة السيناريوهات التالية:
الموقع الجغرافي / GeoLatency: مع انتقال الجهاز بين المواقع، يتم تحسين زمن انتقال الشبكة عن طريق ترحيل الجهاز إلى مركز IoT أقرب.
الإيجار المتعدد: يمكن استخدام جهاز داخل نفس حل إنترنت الأشياء وإعادة تعيينه لعميل جديد أو موقع عميل. قد تتم خدمة هذا العميل الجديد باستخدام مركز IoT مختلف.
تغيير الحل: يمكن نقل الجهاز إلى حل IoT جديد أو محدث. قد تتطلب إعادة التعيين هذه من الجهاز الاتصال بمركز IoT جديد متصل بمكونات خلفية أخرى.
العزل: مشابه لتغيير الحل. يمكن إعادة تعيين الجهاز المعطل أو المخترق أو القديم إلى مركز IoT الذي يمكنه فقط التحديث والعودة إلى الامتثال. بمجرد أن يعمل الجهاز بشكل صحيح، يتم ترحيله مرة أخرى إلى مركزه الرئيسي.
إعادة تزويد الدعم داخل خدمة تزويد الأجهزة يعالج هذه الاحتياجات. يمكن إعادة تعيين الأجهزة تلقائيا إلى مراكز IoT الجديدة استنادا إلى نهج إعادة التوفير الذي تم تكوينه في إدخال تسجيل الجهاز.
بَيانات حالة الجهاز
تتكون بيانات حالة الجهاز من قدرات الجهاز المزدوج والجهاز. يتم تخزين هذه البيانات في مثيل خدمة تزويد الأجهزة ومركز IoT الذي تم تعيين جهاز إليه.
عند تزويد جهاز في البداية مع مثيل خدمة تزويد الأجهزة، يتم تنفيذ الخطوات التالية:
يرسل الجهاز طلب تزويد إلى مثيل خدمة تزويد الأجهزة. يصادق مثيل الخدمة على هوية الجهاز استنادا إلى إدخال تسجيل وإنشاء التكوين الأولي لبيانات حالة الجهاز. يعين مثيل الخدمة الجهاز إلى مركز IoT استنادا إلى تكوين التسجيل ويقوم بإرجاع تعيين مركز IoT إلى الجهاز.
يقدم مثيل خدمة التزويد نسخة من أي بيانات حالة الجهاز الأولية إلى مركز IoT المعين. يتصل الجهاز بمركز IoT المعين ويبدأ العمليات.
بمرور الوقت، يمكن لعمليات الجهازوالعمليات الخلفية تحديث بيانات حالة الجهاز على مركز إنترنت الأشياء. تظل معلومات حالة الجهاز الأولية المخزنة في مثيل خدمة تزويد الأجهزة دون أي تغيير. تُشكل بيانات حالة الجهاز التي لم يتم المساس بها التكوين الأولي.
اعتمادا على السيناريو، أثناء انتقال الجهاز بين مراكز IoT، قد يكون من الضروري أيضا ترحيل حالة الجهاز المحدثة على مركز IoT السابق إلى مركز IoT الجديد. يمكن أن تدعم سياسات إعادة إدارة الحسابات في خدمة إدارة حسابات الأجهزة هذا الترحيل.
نهج إعادة التزويد
اعتمادا على السيناريو، يمكن للجهاز إرسال طلب إلى مثيل خدمة توفير عند إعادة التشغيل. كما أنه يدعم طريقة لتشغيل التزويد يدويا عند الطلب. يحدد نهج إعادة التزويد بشأن إدخال التسجيل كيفية معالجة مثيل خدمة تزويد الأجهزة لطلبات التزويد هذه. يحدد النهج أيضا ما إذا كان يجب ترحيل بيانات حالة الجهاز أثناء إعادة التزويد. تتوفر نفس النُهج للتسجيل الفردي وتسجيل المجموعة:
إعادة توفير البيانات وترحيلها: هذا النهج هو النهج الافتراضي لإدخالات التسجيل الجديدة. يتخذ هذا النهج إجراء عندما ترسل الأجهزة المرتبطة بإدخال التسجيل طلبا جديدا (1). اعتمادا على تكوين إدخال التسجيل، قد تتم إعادة تعيين الجهاز إلى مركز IoT آخر. إذا كان الجهاز يقوم بتغيير مراكز IoT، تتم إزالة تسجيل الجهاز مع مركز IoT الأولي. يتم ترحيل معلومات حالة الجهاز المحدثة من مركز IoT الأولي هذا إلى مركز IoT الجديد (2). أثناء الترحيل، يتم الإبلاغ عن حالة الجهاز على أنها تعيين.
إعادة التوفير وإعادة التعيين إلى التكوين الأولي: يتخذ هذا النهج إجراء عندما ترسل الأجهزة المقترنة بإدخال التسجيل طلب توفير جديد (1). اعتمادا على تكوين إدخال التسجيل، قد تتم إعادة تعيين الجهاز إلى مركز IoT آخر. إذا كان الجهاز يقوم بتغيير مراكز IoT، تتم إزالة تسجيل الجهاز مع مركز IoT الأولي. يتم تزويد بيانات التكوين الأولية التي يتلقاها مثيل خدمة التزويد عند تزويد الأجهزة إلى مركز IoT الجديد (2). أثناء الترحيل، يتم الإبلاغ عن حالة الجهاز على أنها تعيين.
غالبا ما يتم استخدام هذا النهج لإعادة تعيين مصنع دون تغيير مراكز IoT.
عدم إعادة التوفير أبدا: لا يتم إعادة تعيين الجهاز أبدا إلى مركز مختلف. يتم تزويد هذا النهج لإدارة توافق الإصدارات السابقة.
إشعار
يستدعي DPS دائما خطاف الويب للتخصيص المخصص بغض النظر عن سياسة إعادة التوفير في حالة وجود ReturnData جديد للجهاز. إذا تم تعيين نهج إعادة التوفير على عدم إعادة التوفير مطلقا، يتم استدعاء الإخطار على الويب ولكن الجهاز لا يغير المركز المخصص له.
أثناء تصميم الحل الخاص بك وتحديد منطق إعادة التوفير، هناك بعض الأشياء التي يجب مراعاتها. على سبيل المثال:
- عدد المرات التي تتوقع فيها إعادة تشغيل أجهزتك
- الحصص النسبية وحدود DPS
- وقت النشر المتوقع لأسطولك (الإطلاق المرحلي مقابل الكل في وقت واحد)
- إمكانية إعادة المحاولة المطبقة على التعليمات البرمجية للعميل، كما هو موضح في التوجيه العام لإعادة المحاولة في Azure Architecture Center
تلميح
نوصي بعدم التوفير في كل عملية إعادة تشغيل للجهاز، لأن هذا الإجراء قد يتسبب في بعض المشكلات عند إعادة توفير عدة آلاف أو ملايين الأجهزة في وقت واحد. بدلا من ذلك، يجب محاولة استخدام واجهة برمجة تطبيقات البحث عن حالة تسجيل الجهاز ومحاولة الاتصال بهذه المعلومات ب IoT Hub. إذا فشل ذلك، فحاول إعادة التوفير حيث قد تتغير معلومات IoT Hub. ضع في اعتبارك أن الاستعلام عن حالة التسجيل يعتبر تسجيلا جديدا للجهاز، لذلك يجب مراعاة حد تسجيل الجهاز. ضع في اعتبارك أيضا تنفيذ منطق إعادة المحاولة المناسب، مثل التراجع الأسي مع التوزيع العشوائي، كما هو موضح في الإرشادات العامة لإعادة المحاولة. في بعض الحالات، اعتمادا على إمكانيات الجهاز، من الممكن حفظ معلومات IoT Hub مباشرة على الجهاز، للاتصال مباشرة ب IoT Hub بعد حدوث التوفير لأول مرة باستخدام DPS. إذا اخترت الحفظ مباشرة على الجهاز، فتأكد من تنفيذ آلية احتياطية في حالة حدوث أخطاء محددة من IoT Hub . على سبيل المثال ، ضع في اعتبارك السيناريوهات التالية:
- أعد محاولة عملية IoT Hub إذا كانت التعليمات البرمجية للنتيجة هي 429 (طلبات كثيرة جدا) أو خطأ في نطاق 5xx. لا تعيد المحاولة بحثا عن أي أخطاء أخرى.
- بالنسبة لأخطاء 429، أعد المحاولة فقط بعد الوقت المحدد في العنوان إعادة المحاولة بعد.
- بالنسبة لأخطاء 5xx، استخدم التراجع الأسي، مع إعادة المحاولة الأولى بعد 5 ثوانٍ على الأقل من الاستجابة.
- عند حدوث أخطاء أخرى غير 429 و5xx، أعد التسجيل من خلال DPS
- من الناحية المثالية، يجب عليك أيضا دعم طريقة مباشرة لتشغيل التوفير يدويا عند الطلب.
نوصي أيضا بمراعاة حدود الخدمة عند التخطيط لأنشطة مثل دفع التحديثات إلى أسطولك. على سبيل المثال، يمكن أن يؤدي تحديث الأسطول مرة واحدة إلى إعادة تسجيل جميع الأجهزة من خلال DPS (والتي يمكن أن تتجاوز بسهولة حد الحصة النسبية للتسجيل) - لمثل هذه السيناريوهات، ضع في اعتبارك التخطيط لتحديثات الأجهزة على مراحل بدلا من تحديث الأسطول بأكمله في نفس الوقت.
إدارة توافق الإصدارات السابقة
قبل سبتمبر 2018، كان لتعيينات الأجهزة إلى مراكز IoT إجراء صعب. عندما يعود جهاز خلال عملية التزويد، سيتم تعيينه فقط مرة أخرى إلى نفس مركز IoT.
بالنسبة للحلول التي تعتمد على هذا السلوك، تتضمن خدمة التوفير التوافق مع الإصدارات السابقة. يتم الاحتفاظ بهذا الإجراء حاليا للأجهزة وفقا للمعايير الآتية:
تتصل الأجهزة بإصدار API قبل توفر دعم إعادة النسخ الأصلي في خدمة تزويد الأجهزة. ارجع إلى جدول واجهة برمجة التطبيقات التالي.
لا يحتوي إدخال التسجيل للأجهزة على نهج إعادة تزويد معينة له.
يضمن هذا التوافق أن الأجهزة التي تم توزيعها مسبقًا تواجه نفس الإجراء الموجود أثناء الاختبار الأولي. للمحافظة على الإجراء السابق، لا تقم بحفظ نهج إعادة تزويد لهذه التسجيلات. إذا تم تعيين نهج إعادة تزويد، يأخذ نهج إعادة التزويد الأسبقية على الإجراء. من خلال السماح لنهج إعادة التزويد بأخذ الأسبقية، يمكن للعملاء تحديث إجراء الجهاز دون الحاجة إلى إعادة تصوير الجهاز.
يساعد المخطط الانسيابي التالي على إظهار وقت وجود الإجراء:
يعرض الجدول التالي إصدارات واجهة برمجة التطبيقات قبل توفر دعم إعادة التزويد الأصلي في خدمة تزويد الأجهزة:
| واجهة برمجة تطبيقات REST | C SDK | Python SDK | عقدة SDK | Java SDK | .NET SDK |
|---|---|---|---|---|---|
| 2018-04-01 والإصدارات السابقة | 1.2.8 والإصدارات السابقة | 1.4.2 والإصدارات السابقة | 1.7.3 أو إصدار سابق | 1.13.0 أو إصدار سابق | 1.1.0 أو إصدار سابق |
إشعار
من المحتمل أن تتغير هذه القيم والارتباطات. يتم إصدار Azure IoT SDKs وواجهات برمجة التطبيقات لضمان استمرار التطبيقات والخدمات في العمل مع تطور المنتجات وواجهات برمجة التطبيقات. نوصي بالتحقق من أحدث إصدارات Azure IoT SDKs وواجهات برمجة التطبيقات في الوثائق المرجعية لحزم SDK وواجهات برمجة التطبيقات هذه. على سبيل المثال، أحدث إصدار من واجهة برمجة تطبيقات REST لخدمة توفير الأجهزة Azure IoT Hub هو 2021-10-01.