المجموعات الموجودة على الحافة

تتطلّب التطبيقات كثيفة الحوسبة قدرة عالية على المعالجة والتخزين، وهي قدرات لا تستطيع أجهزة إنترنت الأشياء توفيرها نظرًا إلى كونها غالبًا محدودة الموارد. لذا، يمكن للشركات استخدام المجموعات على الحافة كبيئات ديناميكية وقوية تُمكّن فرق العمليات من تلبية متطلبات التخزين والحوسبة وزمن الانتقال والأداء العالي وعرض النطاق الترددي العالي. وقد تتطلب بعض الخدمات المشتركة المحلية المتوفرة بشكل كبير قابلية التوسع التي صُمِّمت مجموعات Kubernetes لتوفيرها، مثل عمليات نشر السحابة على الحافة.

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

توفر المجموعات على الحافة المزايا الرئيسية التالية:

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

دعونا نأخذ مثالاً في صناعة البيع بالتجزئة. يرغب بائع تجزئة في سحب منتج معين من رفوف المتجر أو جعله غير متاح للشراء بسبب استدعاء أمني. وسيتعين عليه تحديث نظام المخزون المركزي الخاص به ونشر هذا التحديث ليصبح ساري المفعول في العديد من المتاجر.

تُعد مجموعة الحافة في المتجر، إلى جانب أجهزة إنترنت الأشياء والكاميرات وأجهزة الاستشعار، مناسبة تمامًا لدعم هذا السيناريو. بينما يضع نظام مخزون المتجر علامة على وحدة حفظ المخزون (SKU) المعينة على أنها مسحوبة، ويُخطر مدير المتجر أيضًا بسحب المنتج (المنتجات) الفعلي من الرفوف. في الوقت نفسه، يتم تحديث نظام نقاط البيع (POS) لإبطال صلاحية الرمز الشريطي الخاص بهذا المنتج. سيتيح حل مجموعة الحافة المُصمّم بعناية اتخاذ مثل هذه الإجراءات السريعة على نطاق واسع من دون تأخيرات مُكلفة أو أخطاء بشرية.

يوضح الشكل 1 مجموعة الحافة المنشورة في متجر ذي تصميم شبكي نموذجي مزوّد بكاميرات أمنية وكاميرات مراقبة المخزون، وأنظمة نقاط البيع (POS)، ومستشعر دخول، ومستشعرات درجة الحرارة في المجمدات:

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

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

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

كمثال تمثيلي لتثبيت مجموعة Kubernetes متواضعة للسيناريوهات المذكورة أعلاه، يرد أدناه بعض التفاصيل حول كيفية التنفيذ باستخدام K3s. ضع في حسبانك أنه يمكنك أيضًا استخدام توزيعات Kubernetes مشابهة مثل minikube أو microk8s. توضح القائمة أدناه عقدة K3s أساسية ذات وحدة تحكم واحدة وعقدتين عاملتين (https://k3s.io/) إعداد المجموعة. نعرض الحد الأدنى من مجموعة الأوامر التي ينبغي تشغيلها على كل عنصر. يظهر الجدول أدناه طوبولوجيا ثلاثية العقد:

K3S_URL هو عنوان IP للعقدة الرئيسية إلى جانب المنفذ، حيث 6443 هو منفذ الاستماع لـ HTTPS. لاحظ أن K3s يستخدم حاويات containerd وليس Docker بشكل افتراضي

رئيسية

$export K3S_URL="https://192.168.0.248:6443" $curl -sfL https://get.k3s.io | sh - $sudo cat /var/lib/rancher/k3s/server/node-token K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d5858a6d45b5adccd

العامل 1

$export K3S_KUBECONFIG_MODE="644" $export K3S_URL="https://192.168.0.248:6443" $export K3S_TOKEN="K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d5858a6d45b5adccd"

العامل 2

$export K3S_KUBECONFIG_MODE="644" $export K3S_URL="https://192.168.0.248:6443" $export K3S_TOKEN="K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d585

من منظور IBM Edge Application Manager، تشبه مجموعة الحافة جهاز الحافة لأن كليهما يحتوي على وكيل حافة مثبت عليهما. يوضح الشكل 2 العناصر عالية المستوى لمجموعة الحافة:

تُعد مجموعات الحافة أساسًا بمثابة عُقد حافة، وهي عبارة عن مجموعات قائمة على Kubernetes. إذن، ما السبب المنطقي لإنشاء مجموعة صغيرة كعقدة حافة؟ تُسجِّل كل عقدة حافة — في هذه الحالة، مجموعة الحافة — في البورصة ضمن مؤسسة مالك مجموعة الحافة. ويتكون التسجيل من معرف ورمز أمان ينطبق فقط على مجموعة الحافة هذه. تعمل عملية وكيل مستقل على مجموعة الحافة تلك وتفرض السياسات التي يحددها مالك مجموعة الحافة. وفي الوقت نفسه، تُكلَّف روبوتات الاتفاقيات المستقلة (أو agbots) بسياسات النشر لنشر الخدمات على مجموعات الحافة هذه.

يصف ما سبق الخطوات الموجودة في منتج IBM Edge Application Manager، والذي يسمح بنشر خدمات الحافة على مجموعة الحافة، عبر مشغل Kubernetes، ومن ثَمَّ تمكين آليات النشر المستقلة نفسها المستخدمة مع أجهزة الحافة. وذلك يعني أن القوة الكاملة لـ Kubernetes كمنصة لإدارة الحاويات متاحة لخدمات الحافة.

يوضح هذا الرابط في مركز معرفة المنتج الخطوات اللازمة لتثبيت وكيل حافة على مجموعة الحافة. بعد ذلك، يمكن تثبيت التطبيقات ذات الصلة على مجموعة الحافة هذه. بحسب تخمينك، يدعم IEAM كلاً من Kubernetes وK3s وMiniKube وMicrok8s وRed Hat OpenShift.

وصفت هذه المدونة قيمة الأعمال الفريدة التي يوفرها نشر المجموعات في الحافة — وليس بالضرورة الحافة البعيدة، ولكن مع ذلك عُقد الحافة في المواقع المحلية البعيدة. للتذكير، تساعدك قدرات مجموعة عقدة الحافة على إدارة أحمال التشغيل ونشرها من مجموعة مركز الإدارة إلى حالات OCP البعيدة أو مجموعات أخرى قائمة على Kubernetes.

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

ثمة أداة جديدة مفتوحة المصدر لإدارة الحاويات لتطوير حاويات مبادرة الحاويات المفتوحة (OCI) وإدارتها وتشغيلها. ويُطلق عليها اسم Podman ( اختصارًا لـ Pod Manager)، حيث تُعد خيارًا مناسبًا تمامًا لمجموعات الحافة. يتم توفير Podman كجزء من مكتبة libpod ويمكن استخدامها لإنشاء الحاويات وصيانتها. وعلى الرغم من أنه بإمكانها تشغيل حاويات Docker، فإنها تعمل حاليًا على أنظمة التشغيل المستندة إلى Linux فقط. يمكنك معرفة المزيد عن Podman هنا.

يقدم مركز بنية IBM Cloud العديد من البنى المرجعية الهجينة ومتعددة السحابة. 

يمكنك أيضًا عرض  البنية المرجعية للسيارات المتعلقة بالحافة المنشورة حديثًا.

شكر خاص لكل من Joe Pearson وDavid Booz لتقييم المقال.

يُرجى التأكد من الاطلاع على الأجزاء الأخرى من سلسلة منشورات المدونة هذه حول حوسبة الحافة:

• الجزء 3: "تصميم البنية على الحافة "
• الجزء 4: "عمليات التطوير على الحافة "
• الجزء 7: "الأمن على الحافة "
• الجزء 8: "التحليلات على الحافة "
• الجزء 9: "5G على الحافة "
• الجزء 10: "المجموعات على الحافة "
• الجزء 11: "الأتمتة على الحافة "
• الجزء 12: "تقطيع الشبكة على الحافة "
• الجزء 13: "البيانات على الحافة "
• الجزء 14: "القرارات المتعلقة بالبنية على الحافة "
• الجزء 15: "GitOps على الحافة "
• الجزء 17: "خدمات التخزين على الحافة "
• الجزء 18: "خدمات السحابة على الحافة "
• الجزء 20: "سيادة البيانات على الحافة "
• الجزء 22: "المنتجات المتصلة على الحافة "
• الجزء 23: "النماذج الأساسية على الحافة "

• ™IBM Garage
  
• IBM Edge Application Manager
  

• تثبيت K3s
• وثائق K3s
• تثبيت وكيل IEAM على المجموعة
• ما حاوية التبريد؟
• الانتقال من Docker إلى Podman
• مبادرة الحاوية المفتوحة من مؤسسة Linux