نمط تكوين حافة حمل العمل
يمكن للتنوع الكبير للأنظمة والأجهزة الموجودة في أرضية المتجر أن يجعل تكوين حمل العمل مشكلةً صعبةً. توفر هذه المقالة أساليب لحلها.
السياق والمشكلة
تركز شركات التصنيع، باعتبارها جزءاً من رحلة التحول الرقمي خاصتها، على نحوٍ متزايدٍ على بناء حلول برمجية يمكن إعادة استخدامها باعتبارها إمكانات مشتركة. نظراً لتنوع الأجهزة والأنظمة الموجودة في أرضية المتجر، يتم تكوين أحمال العمل المعيارية لدعم البروتوكولات وبرامج التشغيل وتنسيقات البيانات المختلفة. في بعض الأحيان يتم تشغيل مثيلات متعددة من حمل العمل بتكوينات مختلفة في نفس موقع الحافة. بالنسبة لبعض أحمال العمل، تُحدَّث التكوينات أكثر من مرة في اليوم. لذلك، فإن إدارة التكوين مهمة بصفةٍ متزايدةٍ لتوسيع نطاق حلول الحافة.
حل
هناك بعض الخصائص الشائعة لإدارة التكوين لأحمال عمل الحافة:
- هناك العديد من نقاط التكوين التي يمكن تجميعها في طبقات مميزة، مثل مصدر البرامج، ومسار CI/CD، ومستأجر السحابة، وموقع الحافة:
- يمكن تحديث الطبقات المختلفة بواسطة أشخاص مختلفين.
- بغض النظر عن كيفية تحديث التكوينات، يجب تعقبها وتدقيقها بعنايةٍ.
- لاستمرارية الأعمال، يلزم الوصول إلى التكوينات دون اتصال على الحافة.
- من المطلوب أيضاً أن تكون هناك طريقة عرض عمومية للتكوينات المتوفرة على السحابة.
المسائل والاعتبارات
راع النقاط التالية عند تحديد كيفية تنفيذ هذا النمط:
- يؤدي السماح بإجراء عمليات التحرير عندما لا تكون الحافة متصلة بالسحابة إلى زيادة تعقيد إدارة التكوين بدرجةٍ كبيرةٍ. من الممكن نسخ التغييرات إلى السحابة، ولكن هناك تحديات مع:
- مصادقة المستخدم، لأنها تعتمد على خدمة سحابية مثل معرف Microsoft Entra.
- حل التعارض بعد إعادة الاتصال، إذا تلقت أحمال العمل تكوينات غير متوقعة تتطلب تدخلاً يدوياً.
- يمكن أن يكون لبيئة الحافة قيود متعلقة بالشبكة إذا كان المخطط متوافقاً مع متطلبات ISA-95. يمكنك التغلب على هذه القيود عن طريق تحديد تقنية توفر الاتصال عبر الطبقات، مثل التسلسلات الهرمية للجهاز في Azure IoT Edge.
- إذا كان تكوين وقت التشغيل منفصلاً عن إصدارات البرامج، فيجب معالجة تغييرات التكوين بصفةٍ منفصلةٍ. لتقديم ميزات المحفوظات والعودة إلى الحالة السابقة، تحتاج إلى تخزين التكوينات السابقة في مخزن بيانات في السحابة.
- يمكن أن يؤدي الخطأ في التكوين، مثل مكون اتصال تم تكوينه إلى نقطة نهاية غير موجودة، إلى مقاطعة حمل العمل. لذلك، من المهم التعامل مع تغييرات التكوين أثناء تعاملك مع أحداث دورة حياة التوزيع الأخرى في حل إمكانية الملاحظة، بحيث يمكن أن تساعد لوحات معلومات إمكانية الملاحظة في ربط أخطاء النظام بتغييرات التكوين. لمزيد من المعلومات عن إمكانية الملاحظة، راجع دليل مراقبة السحابة: إمكانية الملاحظة.
- فهم الأدوار التي تلعبها مخازن بيانات السحابة والحافة في استمرارية الأعمال. إذا كان مخزن البيانات السحابي هو المصدر الوحيد للحقيقة، فيجب أن تكون أحمال عمل الحافة قادرةً على استعادة الحالات المقصودة باستخدام العمليات التلقائية.
- من أجل المرونة، يجب أن يعمل مخزن بيانات الحافة كذاكرة تخزين مؤقت غير متصلة بالإنترنت. هذا له الأسبقية على اعتبارات زمن الانتقال.
موعد استخدام النمط
استخدم هذا النمط عندما:
- هناك متطلب لتكوين أحمال العمل خارج دورة إصدار البرنامج.
- يحتاج أشخاص مختلفون إلى أن يكونوا قادرين على قراءة التكوينات وتحديثها.
- يجب أن تكون التكوينات متاحةً حتى إذا لم يكن هناك اتصال بالسحابة.
أمثلة من أحمال العمل:
- الحلول التي تتصل بالأصول في أرضية المتجر لاستيعاب البيانات - OPC Publisher، على سبيل المثال، والأمر والتحكم
- أحمال عمل التعلّم الآلي للصيانة التنبؤية
- أحمال عمل التعلّم الآلي التي تفحص في الوقت الحقيقي للحصول على جودة على خط التصنيع
الأمثلة
يمكن أن يعتمد حل تكوين أحمال عمل الحافة أثناء وقت التشغيل على وحدة تحكم تكوين خارجية أو موفر تكوين داخلي.
تباين وحدة التحكم الخارجية بالتكوين
يحتوي هذا التباين على وحدة تحكم تكوين خارج حمل العمل. دور مكون وحدة التحكم بتكوين السحابة هو دفع عمليات التحرير من مخزن البيانات السحابي إلى حمل العمل من خلال وحدة التحكم بتكوين الحافة. تحتوي الحافة أيضاً على مخزن بيانات بحيث تعمل وظائف النظام حتى عند فصله عن السحابة.
باستخدام IoT Edge، يمكن تنفيذ وحدة التحكم بتكوين الحافة كوحدة، ويمكن تطبيق التكوينات مع الوحدات المزدوجة. الوحدة المزدوجة لها حد للحجم؛ إذا تجاوز التكوين الحد، يمكن توسيع نطاق الحل باستخدام Azure Blob Storage أو عن طريق تقسيم حمولات أكبر عبر الأساليب المباشرة.
ميزات هذا الاختلاف هي:
- لا يجب أن يكون حمل العمل نفسه على دراية بنظام التكوين. تُعد هذه الإمكانية شرطاً إذا كانت التعليمات البرمجية المصدر لحمل العمل غير قابلة للتحرير - على سبيل المثال، عند استخدام وحدة من Azure IoT Edge Marketplace.
- من الممكن تغيير تكوين أحمال عمل متعددة في نفس الوقت من خلال تنسيق التغييرات عبر وحدة التحكم بتكوين السحابة.
- يمكن تنفيذ التحقق الإضافي كجزء من مسار الدفع - على سبيل المثال، للتحقق من وجود نقاط نهاية على الحافة قبل دفع التكوين إلى حمل العمل.
تباين موفر التكوين الداخلي
في تباين موفر التكوين الداخلي، يسحب حمل العمل التكوينات من موفر التكوين. للحصول على مثال على التنفيذ، راجع تنفيذ موفر تكوين مخصص في .NET. يستخدم هذا المثال C#، ولكن يمكن استخدام لغات أخرى.
في هذا التباين، تحتوي أحمال العمل على معرّفات فريدة بحيث يمكن أن يكون هناك تكوينات مختلفة لنفس التعليمات البرمجية المصدر التي تعمل في بيئات مختلفة. تتمثل إحدى الطرق لإنشاء معرّف في تسلسل العلاقة الهرمية لحمل العمل بتجميع على مستوى أعلى مثل المستأجر. بالنسبة إلى IoT Edge، قد يكون مزيجاً من مجموعة موارد Azure واسم مركز IoT واسم جهاز IoT Edge ومعرّف الوحدة. تشكل هذه القيم معاً معرّفاً فريداً يعمل كمفتاح في مخازن البيانات.
على الرغم من أنه يمكن إضافة إصدار الوحدة إلى المعرّف الفريد، فمن المتطلبات الشائعة استمرار التكوينات عبر تحديثات البرامج. إذا كان الإصدار جزءاً من المعرّف، يجب ترحيل الإصدار القديم من التكوين إلى الأمام مع تنفيذ إضافي.
ميزات هذا الاختلاف هي:
- بخلاف مخازن البيانات، لا يتطلب الحل مكونات، مما يقلل من التعقيد.
- يمكن معالجة منطق الترحيل من الإصدارات القديمة غير المتوافقة ضمن تنفيذ حمل العمل.
الحلول المستندة إلى IoT Edge
يتكون المكون السحابي لتنفيذ مرجع IoT Edge من مركز IoT الذي يعمل كوحدة تحكم بتكوين السحابة. تنشر وظيفة الوحدة المزدوجة Azure IoT Hub تغييرات التكوين ومعلومات عن التكوين المُطبَّق حالياً باستخدام الخصائص المطلوبة والمذكورة للوحدة المزدوجة. تعمل خدمة إدارة التكوين كمصدر للتكوينات. يمكن أن تكون أيضاً واجهة مستخدم لإدارة التكوينات ونظام البناء والأدوات الأخرى المُستخدَّمة لتأليف تكوينات حمل العمل.
تخزن قاعدة بيانات Azure Cosmos DB جميع التكوينات. يمكنها التفاعل مع مراكز IoT متعددة، وتوفر محفوظات التكوين.
بعد أن يشير جهاز الحافة عبر الخصائص المبلغ عنها إلى تطبيق تكوين، تلاحظ خدمة حالة التكوين الحدث في مثيل قاعدة البيانات.
عند إنشاء تكوين جديد في خدمة إدارة التكوين، يتم تخزينه في Azure Cosmos DB ويتم تغيير الخصائص المطلوبة لوحدة الحافة في مركز IoT حيث يوجد الجهاز. ثم يتم إرسال التكوين بواسطة IoT Hub إلى جهاز الحافة. من المتوقع أن تطبق وحدة الحافة التكوين والتقرير عبر الوحدة المزدوجة لحالة التكوين. ثم تستمع خدمة حالة التكوين إلى أحداث التغيير المزدوج، وعند اكتشاف أن الوحدة تبلغ عن تغيير حالة التكوين، تسجل التغيير المقابل في قاعدة بيانات Azure Cosmos DB.
يمكن لمكون الحافة استخدام وحدة التحكم الخارجي بالتكوين أو موفر التكوين الداخلي. في أيٍ من عمليتي التنفيذ، يتم إرسال التكوين إما في الخصائص المطلوبة للوحدة المزدوجة، أو في حالة الحاجة إلى إرسال تكوينات كبيرة، تحتوي الخصائص المطلوبة للوحدة المزدوجة على عنوان URL إلى Azure Blob Storage أو إلى خدمة أخرى يمكن استخدامها لاسترداد التكوين. تشير الوحدة بعد ذلك في الوحدة المزدوجة إلى الخصائص التي تشير إلى ما إذا كان التكوين الجديد قد تم تطبيقه بنجاحٍ وما هو التكوين المُطبَّق حالياً.
المساهمون
تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.
الكاتب الرئيسي:
- هيذر كام | مدير أول للبرنامج
لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.
الخطوات التالية
- Azure IoT Edge
- ما هو Azure IoT Edge؟
- Azure IoT Hub
- مفاهيم IoT وAzure IoT Hub
- Azure Cosmos DB
- مرحبًا بكم في قاعدة بيانات Azure Cosmos DB
- مخزن البيانات الثنائية كبيرة الحجم لـ Azure
- مقدمة حول تخزين Azure Blob