Edge-home-orchestration-go: [WIP] एज उपकरणों और सेवाओं का केंद्रीकृत प्रबंधन

@ सुरेश-एलसी @ कार्तिकेयन-सैमसंग PTAL। वर्तमान स्कोरिंग तंत्र मेरे लिए थोड़ा अक्षम है, क्योंकि संबंधित उम्मीदवार अपनी क्षमता की गणना स्वयं स्कोर के रूप में करते हैं और केवल उस परिणाम को मास्टर को भेजते हैं। दूसरी ओर, मास्टर उनके द्वारा प्रेषित क्षमता कारकों के आधार पर प्रत्येक किनारे के उम्मीदवार के बजाय उन अंकों की गणना कर सकता है। यह गुरु को अधिक उपयुक्त लगता है। तुम क्या सोचते हो?

हमारा वर्तमान दृष्टिकोण प्राथमिक-माध्यमिक प्रकार का नहीं है। प्रारंभिक खोज के दौरान अन्य उपकरणों के साथ डिवाइस विवरण (मेमोरी/सीपीयू/बैंडविड्थ) का आदान-प्रदान किया जाता है। इसलिए जब कोई डिवाइस 'ए' किसी सेवा को ऑफलोड करना चाहता है, तो स्कोरिंग की गणना डिवाइस 'ए' में ही अन्य सभी डिवाइसों (जो संग्रहीत किए गए हैं) में की जाती है और ऑफलोडिंग होती है। तो बस यह स्पष्ट करने के लिए कि स्कोरिंग अन्य उपकरणों से नहीं मिलती है जब किसी भी एप्लिकेशन द्वारा ऑर्केस्ट्रेशन को किनारे करने के लिए सेवा ऑफलोडिंग के लिए अनुरोध किया जाता है। इसलिए वर्तमान मेमोरी/सीपीयू/बैंडविड्थ के आधार पर इस स्कोरिंग को अधिक गतिशील (वास्तविक समय) बनाना सुधार का अच्छा बिंदु होगा।

जैसा कि @t25kim द्वारा बताया गया है: एक केंद्रीकृत दृष्टिकोण (मास्टर) चाहता है।
ऐसे मामले में कुछ विचार निम्नलिखित हैं:

1. प्राथमिक नोड का चयन
2. एक परिदृश्य का प्रबंधन जब प्राथमिक नोड नीचे चला जाता है, यदि हम चाहें तो एक माध्यमिक मास्टर प्रकार का परिदृश्य कहें।
3. डिवाइस ए से बी के किसी भी अनुरोध को डिवाइस बी की पहचान करने के लिए शुरू में प्राथमिक से गुजरना होगा।

@ सुरेश-एलसी बिंदु प्राथमिक/माध्यमिक टोपोलॉजी नहीं है, वर्तमान स्कोरिंग तंत्र इस प्रकार है (कम से कम स्रोत कोड स्तर से: उर्फ scoringmgr :

1. प्रत्येक उम्मीदवार अपने स्कोर की गणना करता है और सभी आवश्यक प्रसंस्करण स्वयं करता है।
2. दरअसल, ऑफलोडिंग की आवश्यकता तब होती है जब एज-ऑर्केस्ट्रेटर ऐसा करने का फैसला करता है, इसलिए स्कोर की गणना उम्मीदवार के बजाय उस ऑर्केस्ट्रेटर में ही की जानी चाहिए।
3. यहां सुझाव उस परिदृश्य को देखना शुरू कर देता है।

यदि आप सही अलग-अलग टोपोलॉजी देखते हैं, तो "प्राथमिक नोड्स नीचे चला जाता है" जैसे परिदृश्य को किसी अन्य प्रतिनिधि द्वारा छुआ जाना चाहिए, जो केवल स्थिति डीबी और होम एज परिदृश्य में कुछ का ख्याल रखता है। मुझे यकीन नहीं है कि मौजूदा स्कोरिंग तंत्र सबसे अच्छा विकल्प है।

BTW, आइए हम वैकल्पिक शब्दावली से 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

मुझे मास्टर/दास शब्द को प्राथमिक/माध्यमिक में बदलने का विचार पसंद है।
इसके अतिरिक्त, मैं ब्लैकलिस्ट/श्वेतसूची के बजाय ब्लॉकलिस्ट/अनुमति सूची शब्द का सुझाव देना चाहूंगा।

BTW, आइए हम वैकल्पिक शब्दावली से 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

टीएससी में से एक में, सदस्य में से एक ने मास्टर/दास के बजाय सुपीरियर/अवर शब्द का उपयोग करने का सुझाव दिया। मैंने इसे अपनी समझ के लिए स्वामी/दास के रूप में रखा।

मुझे मास्टर/दास शब्द को प्राथमिक/माध्यमिक में बदलने का विचार पसंद है।
इसके अतिरिक्त, मैं ब्लैकलिस्ट/श्वेतसूची के बजाय ब्लॉकलिस्ट/अनुमति सूची शब्द का सुझाव देना चाहूंगा।

ब्लैकलिस्ट के लिए: टीएससी कॉल में "स्वीकृत" शब्द का उपयोग करने का सुझाव दिया गया था जैसे "स्वीकृत कंटेनर" और इसी तरह।

BTW, आइए हम वैकल्पिक शब्दावली से 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

टीएससी में से एक में, सदस्य में से एक ने मास्टर/दास के बजाय सुपीरियर/अवर शब्द का उपयोग करने का सुझाव दिया। मैंने इसे अपनी समझ के लिए स्वामी/दास के रूप में रखा।

मुझे मास्टर/दास शब्द को प्राथमिक/माध्यमिक में बदलने का विचार पसंद है।
इसके अतिरिक्त, मैं ब्लैकलिस्ट/श्वेतसूची के बजाय ब्लॉकलिस्ट/अनुमति सूची शब्द का सुझाव देना चाहूंगा।

ब्लैकलिस्ट के लिए: टीएससी कॉल में "स्वीकृत" शब्द का उपयोग करने का सुझाव दिया गया था जैसे "स्वीकृत कंटेनर" और इसी तरह।

@ सुरेश-एलसी यह एलएफ एज से टीएससी होना चाहिए। उससे कोई दिशानिर्देश?

@ सुरेश-एलसी बिंदु मास्टर/स्लेव टोपोलॉजी नहीं है, वर्तमान स्कोरिंग तंत्र इस प्रकार है (कम से कम स्रोत कोड स्तर से: उर्फ scoringmgr :

1. प्रत्येक उम्मीदवार अपने स्कोर की गणना करता है और सभी आवश्यक प्रसंस्करण स्वयं करता है।
2. दरअसल, ऑफलोडिंग की आवश्यकता तब होती है जब एज-ऑर्केस्ट्रेटर ऐसा करने का फैसला करता है, इसलिए स्कोर की गणना उम्मीदवार के बजाय उस ऑर्केस्ट्रेटर में ही की जानी चाहिए।
3. यहां सुझाव उस परिदृश्य को देखना शुरू कर देता है।

यदि आप वास्तविक असंबद्ध टोपोलॉजी देखते हैं, तो "मास्टर नोड्स नीचे चला जाता है" जैसे परिदृश्य को किसी अन्य प्रतिनिधि द्वारा छुआ जाना चाहिए, जो केवल स्थिति डीबी और होम एज परिदृश्य में कुछ का ख्याल रखता है। मुझे यकीन नहीं है कि मौजूदा स्कोरिंग तंत्र सबसे अच्छा विकल्प है।

डिवाइस ए, बी और सी एक ही नेटवर्क से जुड़े तीन डिवाइस हैं। सभी डिवाइस/सेवा विवरणों को उनकी गणना/स्मृति क्षमताओं के साथ सभी उपकरणों के बीच आदान-प्रदान किया जाता है।

डिवाइस ए: ऐप एक्स उसी डिवाइस में एज-ऑर्केस्ट्रेटर को एक सेवा को ऑफलोड करने का अनुरोध करता है।
डिवाइस ए: डिवाइस ए में एज-ऑर्केस्ट्रेटर, बी और सी दोनों की सेवा पाता है।
डिवाइस ए: ए स्कोर के लिए बी और सी का अनुरोध करता है
डिवाइस ए: स्कोर के आधार पर, ए डिवाइस सी पर सेवा को ऑफलोड करता है, जिसका स्कोर बेहतर था।
डिवाइस सी: अनुरोधित सेवा करता है।

इस तरह से स्कोरिंग करने का कारण स्कोरिंग को अधिक वास्तविक समय बनाता है। इसके बजाय यदि हम अनुरोधित डिवाइस पर स्कोरिंग करते हैं, तो वास्तविक समय मूल्यों को ध्यान में नहीं रखा जा सकता है। खोज के दौरान, मेमोरी 1Gb हो सकती है, जबकि स्कोरिंग की गणना करते समय यह 512 हो सकती है, क्योंकि अन्य प्रक्रिया चल रही है। तो इस प्रकार की स्कोरिंग गणना इसे वास्तविक समय के करीब बनाती है। उम्मीदवारों पर स्कोरिंग गणना वैसे भी उन उपकरणों में एज ऑर्केस्ट्रेशन द्वारा गणना की जाती है।

हमें अधिक वास्तविक समय मापदंडों के आधार पर स्कोरिंग तंत्र को बढ़ाने और अधिक संख्या में मापदंडों पर विचार करने के बारे में सोचना चाहिए। यहां तक ​​​​कि समय आधारित विश्लेषण भी किया जा सकता है, जैसे कि अगर कोई सेवा ऑफलोड हो जाती है, लेकिन इससे पहले कि हम जानते हैं कि डिवाइस उपयोगकर्ता पैटर्न के कारण व्यस्त हो जाएगा, ऐसी चीजों को शामिल किया जा सकता है।

@ सुरेश-एलसी मैं आपके विचार से असहमत हूं कि वर्तमान परिदृश्य अधिक वास्तविक समय है क्योंकि प्रत्येक किनारे पर अनुरोध प्राप्त करने के समय संसाधन भिन्न नहीं होते हैं।
मान लें कि अनुरोध बी या सी के पास आने का समय टी है। वर्तमान परिदृश्य में प्रत्येक डिवाइस समय टी पर संसाधन के आधार पर स्कोर की गणना करता है और भेजता है। प्रस्तावित परिदृश्य में प्रत्येक डिवाइस समय टी और प्राथमिक पर समान संसाधन जानकारी भेजता है ( मास्टर) एज जानकारी के आधार पर स्कोर की गणना करता है।

आपकी चिंता महत्वपूर्ण है लेकिन मुझे लगता है कि वर्तमान समस्या यह है कि डिवाइस ए नहीं जानता कि बी और सी के क्या फायदे हैं।
यदि C की मेमोरी काफी कम है, तो A को B को चुनना चाहिए, भले ही C, B से बेहतर स्कोर करता हो।

@ t25kim : आप जो कुछ भी उल्लेख करते हैं जैसे स्कोर के बजाय सभी डिवाइस जानकारी साझा करना, अन्य डिवाइस पर साझा किए गए सभी डिवाइस संसाधन विवरण बनाता है।

मान लें कि अनुरोध बी या सी के पास आने का समय टी है। वर्तमान परिदृश्य में प्रत्येक डिवाइस समय टी पर संसाधन के आधार पर स्कोर की गणना करता है और भेजता है। प्रस्तावित परिदृश्य में प्रत्येक डिवाइस समय टी और प्राथमिक पर समान संसाधन जानकारी भेजता है ( मास्टर) एज जानकारी के आधार पर स्कोर की गणना करता है।

इस दृष्टिकोण में भी, T पर संसाधन भिन्न हो सकते हैं। लेकिन T+1 पर संसाधन, जब एज पर स्कोर की गणना होती है, भिन्न हो सकता है। तो यह वास्तविक स्कोर मूल्य की ओर भी नहीं ले जाएगा। डिवाइस द्वारा एज को संसाधन विवरण भेजने के बाद, संसाधन मान बदल सकते हैं (बी और सी के लिए), यही मेरे कहने का मतलब है।

यदि C की मेमोरी काफी कम है, तो A को B को चुनना चाहिए, भले ही C, B से बेहतर स्कोर करता हो।

इस मामले में, स्वाभाविक रूप से परिकलित स्कोर कम होगा क्योंकि स्कोर मेमोरी को भी ध्यान में रखता है। इसलिए स्वाभाविक रूप से A, C के बजाय B को चुनता है।

इसलिए कोई भी मूर्ख सबूत दृष्टिकोण नहीं है। लेकिन प्रणाली को मजबूत करने के लिए हम स्कोर गणना के अन्य तरीकों के बारे में सोच सकते हैं। हम एप्रीओरी तरीके के बजाय समय के अनुभवजन्य तरीके के बारे में सोच सकते हैं

@ सुरेश-एलसी उम .. यह दिलचस्प है, क्योंकि जैसा कि आपने "एप्रियोरी वे" के बजाय "अनुभवजन्य तरीके" की ओर इशारा किया है, इसका एक संदर्भ है कि एज ऑर्केस्ट्रेटर को दी गई सेवाओं को ऑफलोड करने के लिए सर्वश्रेष्ठ प्राथमिक का अंतिम निर्णय लेना चाहिए। एकत्रित डेटा पर (ऐतिहासिक पैटर्न आदि के साथ, और अंत में एआई/एमएल को नियोजित करना)। तो मेरे लिए, वर्तमान तंत्र, जिसे पड़ोसी उपकरण अपनी गणना पूरी करते हैं, थोड़ा ऊपर की ओर है।

@ सुरेश-एलसी @ t25kim मुझे लगता है कि @ t25kim के पास अपना प्रस्ताव पेश करने के लिए कुछ बुनियादी विचार है। इस मामले के लिए बार-बार होने वाली चर्चाओं को समाप्त करने के लिए, इस प्रस्ताव की व्यवहार्यता की जांच के लिए एक अलग शाखा बनाने के बारे में क्या? कोई राय?

@ सुरेश-एलसी @ t25kim मुझे लगता है कि @ t25kim के पास अपना प्रस्ताव पेश करने के लिए कुछ बुनियादी विचार है। इस मामले के लिए बार-बार होने वाली चर्चाओं को समाप्त करने के लिए, इस प्रस्ताव की व्यवहार्यता की जांच के लिए एक अलग शाखा बनाने के बारे में क्या? कोई राय?

हां व्यवहार्यता करने के लिए इसकी अच्छी बात है। कार्यान्वयन के अनुसार, करने में सक्षम होना चाहिए। लेकिन मौजूदा और नए दृष्टिकोण की तुलना करने के लिए, हमें यह देखने के लिए मेट्रिक्स की गणना करने की आवश्यकता है कि कौन सी विधि उचित है।

1. डिवाइस बी और सी ए को स्कोर भेजते हैं और फिर कोई एक डिवाइस संसाधन नीचे चला जाता है।
2. डिवाइस बी और सी ए को संसाधन विवरण भेजते हैं और एक डिवाइस संसाधन नीचे चला जाता है।

@ सुरेश-एलसी @MoonkiHong यह एक महत्वपूर्ण मुद्दा है और मैं इस समय परिदृश्य को हल करने के बारे में नहीं सोच सकता। जब बी या सी ए को उच्च स्कोर भेजते हैं तो क्या समस्या को हल करने के लिए होम एज पर कोई कोड होता है?

हमें दिए गए स्थानीय नेटवर्क में प्राथमिक/द्वितीयक उपकरण को पुन: कॉन्फ़िगर करने के लिए किसी भी जमीनी कार्यान्वयन/एल्गोरिदम का पता लगाने की आवश्यकता हो सकती है।

#26 . द्वारा मौजूदा रिपोर्ट के साथ विचार को गले लगाते हुए