Edge-home-orchestration-go: [WIP] الإدارة المركزية للأجهزة والخدمات المتطورة

@ suresh-lc @ Karthikeyan-Samsung PTAL. آلية تسجيل النتائج الحالية غير فعالة بعض الشيء بالنسبة لي ، لأن المرشحين المتقدمين فيما يتعلق يحسبون قدرتهم على أنها درجة بأنفسهم ويرسلون تلك النتائج إلى المعلم. من ناحية أخرى ، يمكن للسيد حساب تلك الدرجات بدلاً من كل مرشح حافة بناءً على عوامل السعة المرسلة من قبلهم. هذا يبدو أكثر ملاءمة للسيد. ما رأيك؟

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

كما أشار @ t25kim : يريد مقاربة مركزية (ماجستير).
فيما يلي بعض الاعتبارات في مثل هذه الحالة:

1. اختيار عقدة أساسية
2. إدارة سيناريو عندما تتعطل العقدة الأساسية ، قل نوعًا رئيسيًا ثانويًا من السيناريو إذا أردنا ذلك.
3. أي طلب من الجهاز A إلى B ، يجب أن يمر مبدئيًا عبر الأساسي لتحديد الجهاز B.

@ suresh-lc النقطة ليست الهيكل الأساسي / الثانوي ، آلية التسجيل الحالية هي كما يلي (على الأقل من مستوى كود المصدر: الملقب scoringmgr :

1. يحسب كل مرشح درجاته ويقوم بكل المعالجات المطلوبة بنفسه.
2. في الواقع ، يكون التفريغ مطلوبًا عندما يقرر منسق الحافة القيام بذلك ، لذلك يجب إجراء حساب النتيجة في هذا المنسق بدلاً من المرشح نفسه.
3. الاقتراح هنا يبدأ في البحث عن هذا السيناريو.

إذا رأيت الهيكل المفصل الحقيقي ، فيجب أن يتأثر سيناريو مثل "العقد الأساسية تنخفض" بمندوب آخر ، والذي يهتم فقط بالحالة DB وشيء ما في سيناريو Home Edge. لست متأكدًا مما إذا كانت آلية التسجيل الحالية هي الخيار الأفضل.

راجع للشغل ، دعنا نسمي master-slave بالمصطلحات البديلة. ماذا عن الابتدائية / الثانوية؟

مرجع:
https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms-like-blacklist-and-slave/
https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now
https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1.1

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

راجع للشغل ، دعنا نسمي master-slave بالمصطلحات البديلة. ماذا عن الابتدائية / الثانوية؟

مرجع:
https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms-like-blacklist-and-slave/
https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now
https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1.1

في أحد TSC ، اقترح أحد الأعضاء استخدام المصطلح الأعلى / الأدنى بدلاً من المصطلح الرئيسي / التابع. احتفظت به كسيد / عبد لفهمنا.

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

بالنسبة للقائمة السوداء: في استدعاء TSC ، تم اقتراح استخدام المصطلح "موافق عليه" مثل "الحاويات المعتمدة" وهكذا.

راجع للشغل ، دعنا نسمي master-slave بالمصطلحات البديلة. ماذا عن الابتدائية / الثانوية؟
مرجع:
https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms-like-blacklist-and-slave/
https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now
https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1.1

في أحد TSC ، اقترح أحد الأعضاء استخدام المصطلح الأعلى / الأدنى بدلاً من المصطلح الرئيسي / التابع. احتفظت به كسيد / عبد لفهمنا.

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

بالنسبة للقائمة السوداء: في استدعاء TSC ، تم اقتراح استخدام المصطلح "موافق عليه" مثل "الحاويات المعتمدة" وهكذا.

@ suresh-lc يجب أن يكون TSC من LF Edge. أي دليل من ذلك؟

@ suresh-lc النقطة ليست طوبولوجيا السيد / العبد ، آلية التسجيل الحالية هي كما يلي (على الأقل من مستوى كود المصدر: الملقب scoringmgr :

1. يحسب كل مرشح درجاته ويقوم بكل المعالجات المطلوبة بنفسه.
2. في الواقع ، يكون التفريغ مطلوبًا عندما يقرر منسق الحافة القيام بذلك ، لذلك يجب إجراء حساب النتيجة في هذا المنسق بدلاً من المرشح نفسه.
3. الاقتراح هنا يبدأ في البحث عن هذا السيناريو.

إذا رأيت الهيكل المفصل الحقيقي ، فيجب أن يتأثر سيناريو مثل "العقد الرئيسية تنخفض" بمندوب آخر ، والذي يهتم فقط بالحالة DB وشيء ما في سيناريو Home Edge. لست متأكدًا مما إذا كانت آلية التسجيل الحالية هي الخيار الأفضل.

الجهاز A و B و C عبارة عن ثلاثة أجهزة متصلة في نفس الشبكة. يتم تبادل جميع تفاصيل الجهاز / الخدمة بين جميع الأجهزة مع قدرات الحوسبة / الذاكرة.

الجهاز أ: يطلب التطبيق X إلغاء تحميل خدمة إلى Edge-Orchestrator في نفس الجهاز.
الجهاز أ: Edge-Orchestrator في الجهاز A ، يجد كل من B و C يحتويان على الخدمة.
الجهاز A: يطلب A B و C للحصول على الدرجة
الجهاز "أ": بناءً على النتيجة ، يقوم "أ" بإلغاء تحميل الخدمة على الجهاز "ج" ، الذي حصل على درجة أفضل.
الجهاز ج: يؤدي الخدمة المطلوبة.

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

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

@ suresh-lc لا أتفق مع فكرتك بأن السيناريو الحالي هو أكثر واقعية لأن الموارد لا تختلف في وقت تلقي الطلب عند كل حافة.
افترض أن وقت وصول الطلب إلى B أو C هو T. في السيناريو الحالي ، يحسب كل جهاز ويرسل النتيجة بناءً على المورد في الوقت T. في السيناريو المقترح ، يرسل كل جهاز معلومات المورد نفسها في الوقت T والأساسي ( master) edge بحساب الدرجات بناءً على المعلومات.

قلقك مهم ولكن المشكلة الحالية على ما أعتقد هي أن الجهاز "أ" لا يعرف مزايا "ب" و "ج".
إذا نفدت ذاكرة C بشكل ملحوظ ، فيجب على A اختيار B حتى لو كانت C درجات أفضل من B.

@ t25kim : كل ما ذكرته مثل مشاركة جميع معلومات الجهاز بدلاً من النقاط يجعل جميع تفاصيل موارد الجهاز مشتركة مع جهاز آخر.

افترض أن وقت وصول الطلب إلى B أو C هو T. في السيناريو الحالي ، يحسب كل جهاز ويرسل النتيجة بناءً على المورد في الوقت T. في السيناريو المقترح ، يرسل كل جهاز معلومات المورد نفسها في الوقت T والأساسي ( master) edge بحساب الدرجات بناءً على المعلومات.

حتى في هذا النهج ، قد يكون المورد في T مختلفًا. لكن المورد عند T + 1 ، عندما يحدث حساب النتيجة في Edge قد يكون مختلفًا. لذلك لن يؤدي هذا أيضًا إلى قيمة النتيجة الفعلية. بعد أن يرسل الجهاز تفاصيل المورد إلى Edge ، يمكن أن تتغير قيم المورد (لـ B و C) ، وهذا ما أقصد قوله.

إذا نفدت ذاكرة C بشكل ملحوظ ، فيجب على A اختيار B حتى لو كانت C درجات أفضل من B.

في هذه الحالة ، من الطبيعي أن تكون النتيجة المحسوبة أقل لأن الدرجة تأخذ الذاكرة أيضًا في الاعتبار. ومن ثم ، من الطبيعي أن يختار "أ" "ب" بدلاً من "ج".

ومن ثم لا يوجد نهج واحد خداع. ولكن لتقوية النظام يمكننا التفكير في طرق أخرى لحساب الدرجات. يمكننا التفكير في الوقت بطريقة تجريبية بدلاً من طريقة Apriori

@ suresh-lc Um .. إنه أمر مثير للاهتمام ، لأنه كما أشرت إلى "الطريقة التجريبية" بدلاً من "طريقة apriori" ، فإنه يحتوي على سياق يجب على منسق الحافة اتخاذ قرار نهائي بشأن أفضل الطرق الأولية لإلغاء تحميل الخدمات المعينة القائمة على البيانات التي تم جمعها (مع الأنماط التاريخية وما إلى ذلك ، وفي النهاية باستخدام الذكاء الاصطناعي / تعلم الآلة). بالنسبة لي ، فإن الآلية الحالية ، التي تكمل الأجهزة المجاورة حسابها الخاص بها ، هي عبارة عن مقدار ضئيل من النفقات.

@ suresh-lc @ t25kim أعتقد أن @ t25kim لديه بعض الأفكار الأساسية لتقديم اقتراحه. من أجل إنهاء المناقشات المتكررة لهذه المسألة ، ماذا عن إنشاء فرع منفصل للتحقق من جدوى هذا الاقتراح؟ اي رأي؟

@ suresh-lc @ t25kim أعتقد أن @ t25kim لديه بعض الأفكار الأساسية لتقديم اقتراحه. من أجل إنهاء المناقشات المتكررة لهذه المسألة ، ماذا عن إنشاء فرع منفصل للتحقق من جدوى هذا الاقتراح؟ اي رأي؟

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

1. يرسل الجهازان "ب" و "ج" النتيجة إلى "أ" ثم ينخفض ​​أي مورد جهاز واحد.
2. يرسل الجهازان "ب" و "ج" تفاصيل المورد إلى "أ" وينخفض ​​مورد جهاز واحد.

@ suresh- lcMoonkiHong هذه مشكلة مهمة ولا يمكنني التفكير في كيفية حل السيناريو في الوقت الحالي. هل هناك أي كود على حافة المنزل يحل المشكلة عندما ينخفض ​​B أو C الذي يرسل درجة عالية إلى A بشكل مفاجئ؟

قد نحتاج إلى معرفة أي تطبيق / خوارزمية أرضية لإعادة تكوين الجهاز الأساسي / الثانوي في الشبكة المحلية المحددة.

احتضان الاعتبار مع التقرير الحالي بحلول # 26