Edge-home-orchestration-go: [WIP] Gestion centralisée des appareils et services périphériques

@suresh-lc @Karthikeyan-Samsung PTAL. Le mécanisme de notation actuel est un peu inefficace pour moi, car les candidats avancés calculent eux-mêmes leur capacité en tant que score et envoient simplement les résultats au maître. D'un autre côté, le maître peut calculer ces scores au lieu de chaque candidat d'arête sur la base des facteurs de capacité transmis par eux. Cela semble plus adapté au maître. Qu'est-ce que tu penses?

Notre approche actuelle n'est pas de type primaire-secondaire. Les détails de l'appareil (mémoire/processeur/bande passante) sont échangés avec d'autres appareils lors de la découverte initiale. Par conséquent, lorsqu'un appareil « A » veut décharger un service, le score est calculé dans l'appareil « A » lui-même de tous les autres appareils (qui ont été stockés) et le déchargement se produit. Donc, juste pour clarifier, la notation n'est pas obtenue à partir d'autres appareils lorsque la demande de déchargement de service est faite à l'orchestration de bord par n'importe quelle application. Par conséquent, rendre cette notation plus dynamique (en temps réel) basée sur la mémoire / le processeur / la bande passante actuels serait un bon point d'amélioration.

Comme l'a souligné @t25kim : veut une approche centralisée (Maître).
Voici quelques-unes des considérations dans un tel cas :

1. Sélection d'un nœud principal
2. Gérer un scénario lorsque le nœud principal tombe en panne, disons un scénario de type maître secondaire si nous le souhaitons.
3. Toute demande de l'appareil A à B doit d'abord passer par le primaire pour identifier l'appareil B.

@suresh-lc Le point n'est pas la topologie primaire/secondaire, Le mécanisme de notation actuel est le suivant (au moins au niveau du code source : alias scoringmgr :

1. Chaque candidat calcule son score et effectue tout le traitement requis par lui-même.
2. En fait, le déchargement est requis lorsque l'orchestrateur de bord décide de le faire, donc le calcul du score doit être effectué dans cet orchestrateur au lieu du candidat lui-même.
3. La suggestion ici commence à regarder ce scénario.

Si vous voyez la véritable topologie désagrégée, le scénario tel que "les nœuds principaux tombent en panne" doit être touché par un autre délégué, qui ne s'occupe que de l'état de la base de données et de quelque chose dans le scénario Home Edge. Je ne sais pas si le mécanisme de notation actuel est la meilleure option.

BTW, appelons master-slave par des terminologies alternatives. Qu'en est-il du primaire/secondaire ?

Référence:
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

J'aime l'idée de changer le terme maître/esclave en primaire/secondaire.
De plus, j'aimerais suggérer le terme liste de blocage/liste autorisée au lieu de liste noire/liste blanche.

BTW, appelons master-slave par des terminologies alternatives. Qu'en est-il du primaire/secondaire ?

Référence:
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

Dans l'un des TSC, l'un des membres a suggéré d'utiliser le terme Supérieur/Inférieur au lieu de Maître/Esclave. Je l'ai gardé en maître/esclave pour notre compréhension.

J'aime l'idée de changer le terme maître/esclave en primaire/secondaire.
De plus, j'aimerais suggérer le terme liste de blocage/liste autorisée au lieu de liste noire/liste blanche.

Pour la liste noire : dans l'appel TSC, il a été suggéré d'utiliser le terme "approuvé" comme dans "Conteneurs approuvés" et ainsi de suite.

BTW, appelons master-slave par des terminologies alternatives. Qu'en est-il du primaire/secondaire ?
Référence:
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

Dans l'un des TSC, l'un des membres a suggéré d'utiliser le terme Supérieur/Inférieur au lieu de Maître/Esclave. Je l'ai gardé en maître/esclave pour notre compréhension.

J'aime l'idée de changer le terme maître/esclave en primaire/secondaire.
De plus, j'aimerais suggérer le terme liste de blocage/liste autorisée au lieu de liste noire/liste blanche.

Pour la liste noire : dans l'appel TSC, il a été suggéré d'utiliser le terme "approuvé" comme dans "Conteneurs approuvés" et ainsi de suite.

@suresh-lc Ce doit être le TSC de LF Edge. Une ligne directrice à partir de cela?

@suresh-lc Le point n'est pas la topologie maître/esclave, Le mécanisme de notation actuel est le suivant (au moins au niveau du code source : alias scoringmgr :

1. Chaque candidat calcule son score et effectue tout le traitement requis par lui-même.
2. En fait, le déchargement est requis lorsque l'orchestrateur de bord décide de le faire, donc le calcul du score doit être effectué dans cet orchestrateur au lieu du candidat lui-même.
3. La suggestion ici commence à regarder ce scénario.

Si vous voyez la véritable topologie désagrégée, le scénario tel que "les nœuds maîtres tombent en panne" doit être touché par un autre délégué, qui ne s'occupe que de l'état de la base de données et de quelque chose dans le scénario Home Edge. Je ne sais pas si le mécanisme de notation actuel est la meilleure option.

Les appareils A, B et C sont trois appareils connectés dans le même réseau. Tous les détails de l'appareil/service sont échangés entre tous les appareils ainsi que leurs capacités de calcul/mémoire.

Appareil A : App X demande de décharger un service vers Edge-Orchestrator dans le même appareil.
Appareil A : Edge-Orchestrator dans l'appareil A, trouve que B et C ont le service.
Appareil A : A demande le score à B et C
Appareil A : en fonction du score , A décharge le service sur l'appareil C, qui a obtenu un meilleur score.
Dispositif C : Exécute le service demandé.

La raison de faire la notation de cette façon rend la notation plus en temps réel. Au lieu de cela, si nous effectuons une notation sur l'appareil qui a demandé, les valeurs en temps réel ne peuvent pas être prises en compte. Lors de la découverte, la mémoire peut être de 1 Go, alors que lors du calcul de la notation, elle peut être de 512, car d'autres processus sont en cours d'exécution. Ainsi, ce type de calcul de score le rend quasiment en temps réel. Le calcul de la notation chez les candidats est de toute façon calculé par Edge Orchestration dans ces appareils.

Nous devrions penser à améliorer le mécanisme de notation en le basant sur davantage de paramètres en temps réel et en considérant également un plus grand nombre de paramètres. Même une analyse basée sur le temps peut être effectuée, par exemple si un service est déchargé, mais avant que nous sachions que l'appareil deviendrait occupé en raison du modèle d'utilisateur, de telles choses peuvent être incorporées.

@suresh-lc Je ne suis pas d'accord avec votre idée selon laquelle le scénario actuel est plus en temps réel car les ressources ne sont pas différentes au moment de la réception de la demande à chaque bord.
Supposons que l'heure à laquelle la demande arrive à B ou C est T. Dans le scénario actuel, chaque appareil calcule et envoie le score en fonction de la ressource à l'heure T. Dans le scénario proposé, chaque appareil envoie les mêmes informations de ressource à l'heure T et primaire( master) edge calcule les scores en fonction des informations.

Votre préoccupation est importante, mais le problème actuel, je pense, est que l'appareil A ne sait pas quels avantages B et C ont.
Si C manque de mémoire de manière significative, alors A devrait choisir B même si C obtient un meilleur score que B.

@t25kim : Tout ce que vous mentionnez, comme le partage de toutes les informations sur l'appareil au lieu du score, rend tous les détails des ressources de l'appareil partagés avec un autre appareil.

Supposons que l'heure à laquelle la demande arrive à B ou C est T. Dans le scénario actuel, chaque appareil calcule et envoie le score en fonction de la ressource à l'heure T. Dans le scénario proposé, chaque appareil envoie les mêmes informations de ressource à l'heure T et primaire( master) edge calcule les scores en fonction des informations.

Même dans cette approche, la ressource à T pourrait être différente. Mais la ressource à T + 1, lorsque le calcul du score se produit à Edge, pourrait être différente. Donc, cela ne conduira pas non plus à la valeur réelle du score. Une fois que l'appareil a envoyé les détails des ressources à Edge, les valeurs des ressources peuvent changer (pour B et C), c'est ce que je veux dire.

Si C manque de mémoire de manière significative, alors A devrait choisir B même si C obtient un meilleur score que B.

Dans ce cas, naturellement, le score calculé serait inférieur car le score prend également en compte la mémoire. Donc naturellement A choisit B au lieu de C.

Il n'y a donc pas d'approche infaillible unique. Mais pour renforcer le système on peut penser à d'autres méthodes de calcul de score. Nous pouvons penser au temps de manière empirique au lieu de la manière Apriori

@suresh-lc Um .. C'est intéressant, car comme vous l'avez souligné "voie empirique" plutôt que "voie a priori", il y a un contexte dans lequel l'orchestrateur de périphérie devrait prendre une décision finale du meilleur primaire pour décharger les services donnés en fonction sur les données collectées (avec des modèles historiques, etc., et finalement en utilisant l'IA/ML). Donc, pour moi, le mécanisme actuel, dans lequel les appareils voisins effectuent leur propre calcul, est un peu encombrant.

@suresh-lc @t25kim Je pense que @t25kim a une idée de base pour présenter sa proposition. Afin de mettre fin aux discussions itératives sur cette question, que diriez-vous de créer une branche distincte pour vérifier la faisabilité de cette proposition ? Un avis ?

@suresh-lc @t25kim Je pense que @t25kim a une idée de base pour présenter sa proposition. Afin de mettre fin aux discussions itératives sur cette question, que diriez-vous de créer une branche distincte pour vérifier la faisabilité de cette proposition ? Un avis ?

Ya son bon point de faire une faisabilité. Mise en œuvre sage, devrait être en mesure de le faire. Mais pour comparer l'approche existante et la nouvelle approche, nous devons calculer des métriques pour voir quelle méthode convient le mieux.

1. Les appareils B et C envoient le score à A, puis n'importe quelle ressource d'appareil tombe en panne.
2. Les périphériques B et C envoient les détails des ressources à A et une ressource de périphérique tombe en panne.

@suresh-lc @MoonkiHong C'est un problème important et je ne pouvais pas penser à la façon de résoudre le scénario pour le moment. Existe-t-il un code sur le bord d'origine résolvant le problème lorsque B ou C envoie un score élevé à A tombe brusquement?

Nous pourrions avoir besoin de trouver une implémentation / un algorithme au sol pour reconfigurer le périphérique principal / secondaire dans le réseau local donné.

Adopter la considération avec le rapport existant par #26