Edge-home-orchestration-go: [WIP] Zentralisierte Verwaltung von Edge-Geräten und -Diensten

@suresh-lc @Karthikeyan-Samsung PTAL. Der aktuelle Scoring-Mechanismus ist für mich etwas ineffizient, da die jeweiligen Edge-Kandidaten ihre Kapazität als Score selbst berechnen und diese Ergebnisse einfach an den Master senden. Andererseits kann der Master diese Scores anstelle jedes Kantenkandidaten basierend auf den von ihnen übermittelten Kapazitätsfaktoren berechnen. Dies scheint dem Meister angemessener zu sein. Was denken Sie?

Unser derzeitiger Ansatz ist nicht primär-sekundär. Die Gerätedetails (Speicher/CPU/Bandbreite) werden bei der ersten Erkennung mit anderen Geräten ausgetauscht. Wenn also ein Gerät „A“ einen Dienst auslagern möchte, wird die Bewertung im Gerät „A“ selbst von allen anderen Geräten (die gespeichert wurden) berechnet und das Auslagern erfolgt. Nur um zu verdeutlichen, dass die Bewertung nicht von anderen Geräten abgerufen wird, wenn eine Anforderung für die Dienstauslagerung von einer beliebigen Anwendung an die Edge-Orchestrierung gestellt wird. Daher wäre es ein guter Verbesserungspunkt, diese Bewertung dynamischer (Echtzeit) basierend auf dem aktuellen Speicher/CPU/Bandbreite zu machen.

Wie von @t25kim gezeigt : will einen zentralisierten Ansatz (Master).
Im Folgenden sind einige Überlegungen in einem solchen Fall aufgeführt:

1. Auswählen eines primären Knotens
2. Verwalten eines Szenarios, wenn der primäre Knoten ausfällt, sagen wir ein sekundäres Master-Szenario, wenn wir möchten.
3. Jede Anfrage von Gerät A an B muss zunächst über die Primärseite gehen, um Gerät B zu identifizieren.

@suresh-lc Der Punkt ist nicht die primäre/sekundäre Topologie. Der aktuelle Bewertungsmechanismus ist wie folgt (zumindest auf der Quellcodeebene: alias scoringmgr :

1. Jeder Kandidat berechnet seine Punktzahl und führt alle erforderlichen Verarbeitungen selbst durch.
2. Tatsächlich ist das Offloading erforderlich, wenn der Edge-Orchestrator dies beschließt, sodass die Score-Berechnung in diesem Orchestrator statt im Kandidaten selbst erfolgen sollte.
3. Der Vorschlag hier beginnt mit der Suche nach diesem Szenario.

Wenn Sie die echte disaggregierte Topologie sehen, sollte das Szenario „Primäre Knoten fallen aus“ von einem anderen Delegaten berührt werden, der sich nur um die Status-DB und etwas im Home-Edge-Szenario kümmert. Ich bin mir nicht sicher, ob der aktuelle Bewertungsmechanismus die beste Option ist.

Übrigens, nennen wir master-slave mit alternativen Terminologien. Was ist mit der Grundschule/Sekundarstufe?

Referenz:
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

Mir gefällt die Idee, den Begriff Master/Slave in Primary/Secondary zu ändern.
Außerdem möchte ich den Begriff Sperrliste/Zulassungsliste anstelle von Blacklist/Whitelist vorschlagen.

Übrigens, nennen wir master-slave mit alternativen Terminologien. Was ist mit der Grundschule/Sekundarstufe?

Referenz:
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

In einem der TSC schlug eines der Mitglieder vor, den Begriff „Superior/Inferior“ anstelle von „Master/Slave“ zu verwenden. Ich habe es für unser Verständnis als Master/Slave gehalten.

Mir gefällt die Idee, den Begriff Master/Slave in Primary/Secondary zu ändern.
Außerdem möchte ich den Begriff Sperrliste/Zulassungsliste anstelle von Blacklist/Whitelist vorschlagen.

Für Blacklist: In der TSC-Aufforderung wurde vorgeschlagen, den Begriff "genehmigt" wie in "genehmigte Container" und so weiter zu verwenden.

Übrigens, nennen wir master-slave mit alternativen Terminologien. Was ist mit der Grundschule/Sekundarstufe?
Referenz:
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

In einem der TSC schlug eines der Mitglieder vor, den Begriff „Superior/Inferior“ anstelle von „Master/Slave“ zu verwenden. Ich habe es für unser Verständnis als Master/Slave gehalten.

Mir gefällt die Idee, den Begriff Master/Slave in Primary/Secondary zu ändern.
Außerdem möchte ich den Begriff Sperrliste/Zulassungsliste anstelle von Blacklist/Whitelist vorschlagen.

Für Blacklist: In der TSC-Aufforderung wurde vorgeschlagen, den Begriff "genehmigt" wie in "genehmigte Container" und so weiter zu verwenden.

@suresh-lc Es muss der TSC von LF Edge sein. Irgendeine Richtlinie daraus?

@suresh-lc Der Punkt ist nicht die Master/Slave-Topologie. Der aktuelle Bewertungsmechanismus ist wie folgt (zumindest auf der Quellcodeebene: alias scoringmgr :

1. Jeder Kandidat berechnet seine Punktzahl und führt alle erforderlichen Verarbeitungen selbst durch.
2. Tatsächlich ist das Offloading erforderlich, wenn der Edge-Orchestrator dies beschließt, sodass die Score-Berechnung in diesem Orchestrator statt im Kandidaten selbst erfolgen sollte.
3. Der Vorschlag hier beginnt mit der Suche nach diesem Szenario.

Wenn Sie die wahre disaggregierte Topologie sehen, sollte das Szenario „Master-Knoten fällt aus“ von einem anderen Delegierten berührt werden, der sich nur um die Status-DB und etwas im Home-Edge-Szenario kümmert. Ich bin mir nicht sicher, ob der aktuelle Bewertungsmechanismus die beste Option ist.

Gerät A, B und C sind drei Geräte, die im selben Netzwerk verbunden sind. Alle Geräte-/Dienstdetails werden zwischen allen Geräten zusammen mit ihren Rechen-/Speicherfähigkeiten ausgetauscht.

Gerät A: App X fordert die Auslagerung eines Dienstes an Edge-Orchestrator auf demselben Gerät an.
Gerät A: Edge-Orchestrator in Gerät A, findet, dass sowohl B als auch C den Dienst haben.
Gerät A: A verlangt von B und C eine Punktzahl
Gerät A: Basierend auf der Punktzahl lagert A den Dienst auf Gerät C aus, das eine bessere Punktzahl hatte.
Gerät C: Führt den angeforderten Dienst aus.

Der Grund für die Bewertung auf diese Weise macht die Bewertung in Echtzeit. Wenn wir stattdessen ein Scoring auf dem angeforderten Gerät durchführen, können keine Echtzeitwerte berücksichtigt werden. Während der Erkennung kann der Speicher 1 GB betragen, während er bei der Berechnung des Scorings 512 betragen kann, da andere Prozesse ausgeführt werden. Diese Art der Scoring-Berechnung macht es also nahezu in Echtzeit. Die Scoring-Berechnung bei Kandidaten wird ohnehin von der Edge Orchestration in diesen Geräten berechnet.

Wir sollten daran denken, den Bewertungsmechanismus zu verbessern, indem wir ihn auf mehr Echtzeitparametern basieren lassen und auch eine größere Anzahl von Parametern berücksichtigen. Sogar zeitbasierte Analysen können durchgeführt werden, beispielsweise wenn ein Dienst ausgelagert wird, aber bevor wir wissen, dass das Gerät aufgrund des Benutzermusters ausgelastet ist, können solche Dinge integriert werden.

@suresh-lc Ich stimme Ihrer Idee nicht zu, dass das aktuelle Szenario eher in Echtzeit erfolgt, da die Ressourcen zum Zeitpunkt des Eingangs der Anforderung an jeder Kante nicht unterschiedlich sind.
Angenommen, die Zeit, zu der die Anforderung bei B oder C ankommt, ist T. Im aktuellen Szenario berechnet und sendet jedes Gerät die Punktzahl basierend auf der Ressource zum Zeitpunkt T. Im vorgeschlagenen Szenario sendet jedes Gerät die gleichen Ressourceninformationen zum Zeitpunkt T und primary( master) edge berechnet die Punktzahlen auf der Grundlage der Informationen.

Ihr Anliegen ist wichtig, aber das aktuelle Problem ist meiner Meinung nach, dass Gerät A nicht weiß, welche Vorteile B und C haben.
Wenn C deutlich zu wenig Gedächtnis hat, sollte A B wählen, auch wenn C besser abschneidet als B.

@t25kim : Was auch immer Sie erwähnen, wie das Teilen aller Geräteinformationen anstelle der Punktzahl, macht alle Geräteressourcendetails für andere Geräte freigegeben.

Angenommen, die Zeit, zu der die Anforderung bei B oder C ankommt, ist T. Im aktuellen Szenario berechnet und sendet jedes Gerät die Punktzahl basierend auf der Ressource zum Zeitpunkt T. Im vorgeschlagenen Szenario sendet jedes Gerät die gleichen Ressourceninformationen zum Zeitpunkt T und primary( master) edge berechnet die Punktzahlen auf der Grundlage der Informationen.

Selbst bei diesem Ansatz könnte die Ressource bei T unterschiedlich sein. Aber die Ressource bei T+1, wenn die Score-Berechnung bei Edge stattfindet, könnte anders sein. Dies führt also auch nicht zu einem tatsächlichen Score-Wert. Nachdem das Gerät die Ressourcendetails an Edge gesendet hat, können sich die Ressourcenwerte ändern (für B und C), das meine ich damit.

Wenn C deutlich zu wenig Gedächtnis hat, sollte A B wählen, auch wenn C besser abschneidet als B.

In diesem Fall wäre die berechnete Punktzahl natürlich geringer, da die Punktzahl auch das Gedächtnis berücksichtigt. Daher wählt A natürlich B statt C.

Daher gibt es keinen einzigen narrensicheren Ansatz. Aber um das System zu stärken, können wir uns andere Methoden der Punkteberechnung vorstellen. Wir können uns die Zeit eher empirisch als apriorisch vorstellen

@suresh-lc Ähm .. Es ist interessant, denn wie Sie darauf hingewiesen haben, "empirischer Weg" und nicht "Apriori-Weg", hat es einen Kontext, in dem der Edge-Orchestrierer eine endgültige Entscheidung über die beste primäre Methode treffen sollte, um die angegebenen Dienste basierend auszulagern auf den gesammelten Daten (mit einem historischen Muster und so weiter, und am Ende unter Verwendung von KI/ML). Also für mich ist der aktuelle Mechanismus, mit dem die Nachbargeräte ihre eigene Berechnung vervollständigen, ein bisschen Overhead.

@suresh-lc @t25kim Ich denke, dass @t25kim eine grundlegende Idee hat, um seinen Vorschlag zu präsentieren. Wie wäre es, um die sich wiederholenden Diskussionen zu diesem Thema zu beenden, einen separaten Zweig zu erstellen, um die Machbarkeit dieses Vorschlags zu prüfen? Irgendeine Meinung?

@suresh-lc @t25kim Ich denke, dass @t25kim eine grundlegende Idee hat, um seinen Vorschlag zu präsentieren. Wie wäre es, um die sich wiederholenden Diskussionen zu diesem Thema zu beenden, einen separaten Zweig zu erstellen, um die Machbarkeit dieses Vorschlags zu prüfen? Irgendeine Meinung?

Ja, es ist ein guter Punkt, um eine Machbarkeit zu tun. In Bezug auf die Implementierung sollte dies möglich sein. Aber um den bestehenden und den neuen Ansatz zu vergleichen, müssen wir Metriken berechnen, um zu sehen, welche Methode angemessen ist.

1. Gerät B und C senden Punkte an A und dann fällt eine beliebige Geräteressource aus.
2. Gerät B und C senden Ressourcendetails an A und eine Geräteressource fällt aus.

@suresh-lc @MoonkiHong Das ist ein wichtiges Thema und ich konnte im Moment nicht darüber nachdenken, wie ich das Szenario lösen könnte. Gibt es einen Code auf Home Edge, der das Problem löst, wenn B oder C, die Highscore an A senden, abrupt sinken?

Möglicherweise müssen wir eine Bodenimplementierung / einen Algorithmus herausfinden, um das primäre / sekundäre Gerät in dem angegebenen lokalen Netzwerk neu zu konfigurieren.

Umfassen der Überlegung mit dem bestehenden Bericht von #26