Idée : maintien de plusieurs adresses par nœud pour faciliter l'établissement et la continuité des connexions entre nœuds #1

New Issue

Open

opened 2021-04-09 11:15:59 +00:00 by adrien · 0 comments

adrien commented

2021-04-09 11:15:59 +00:00

Sur le canal de Garage, on discutait de peer discovery & membership.

Lesterpig et Kaiyou ont notamment soulevé des questions d'UX pour bootstrap un cluster Garage :

Kaiyou :

« On va devoir réfléchir à du déploiement dans k8s nous concernant et le fait d'avoir toutes les IP à l'avance complique la découverte. »
Lesterpig :

« Est ce que tous les membres du cluster doivent "voir" les mêmes IPs (publiques) ? Par exemple si j'ai deux noeuds sur un réseau local et un troisième dans le cloud. »

Ça m'a remis en tête la RFC 5245: Interactive Connectivity Establishment (ICE), qui parle de STUN/TURN, NAT-traversal et autres aspects importants de WebRTC.

Dans le cadre de Garage, on est pas intéressés par la totalité d'ICE, parce qu'on impose la contrainte suivante : « Chaque paire de nœud doit pouvoir communiquer ». Autrement dit, une machine derrière un NAT casse-pieds n'a pas le droit de participer à un cluster Garage.

Néanmoins, ICE a une approche que je trouve pertinente pour gérer la dynamicité des adresses (e.g. IPv4 publiques changeantes) :

Chaque nœud reçoit ses propres adresses via ses pairs, genre « Quand tu me parles, je vois cette adresse locale, pas l'IP publique que tu m'as communiqué ; tu le savais ? ». Il maintient la liste de ses adresses, et les envoie toutes aux nouveaux pairs. Le nouveau pair essaye de ping avec lesdites adresses (de la plus locale à la plus globale), et décide de la meilleure adresse pour discuter ensemble.

Ainsi, dans le cadre de la gestion de membership, chaque nœud apprend et maintient plusieurs adresses permettant de le joindre. Lors du bootstrap d'un nouveau nœud N, ce dernier n'a besoin de connaître qu'une seule adresse valide d'un nœud du cluster, qui lui fournit le registre des membres. Quand il veut démarrer une connexion avec le nœud M, le nouveau nœud N essaye plusieurs adresses, et établira la connexion avec la meilleure adresse (la plus locale).

Dans le cadre du membership, si un nœud change d'adresse (DNS par exemple), il restera sans doute adressable via une autre de ses adresses.

En résumé : « plusieurs adresses par nœud et pas de suppositions sur la plus fiable », plus un mécanisme de sélection quand deux nœuds initient une connexion pour la première fois.

Une façon simple et souple de faciliter le bootstrap, d'éviter les indisponibilités quand le réseau change, et de préférer l'utilisation du réseau local quand deux nœuds sont dans le même.

Sur le canal de Garage, on discutait de peer discovery & membership. Lesterpig et Kaiyou ont notamment soulevé des questions d'UX pour bootstrap un cluster Garage : * Kaiyou : > « On va devoir réfléchir à du déploiement dans k8s nous concernant et le fait d'avoir toutes les IP à l'avance complique la découverte. » * Lesterpig : > « Est ce que tous les membres du cluster doivent "voir" les mêmes IPs (publiques) ? Par exemple si j'ai deux noeuds sur un réseau local et un troisième dans le cloud. » Ça m'a remis en tête la [RFC 5245: Interactive Connectivity Establishment (ICE)](https://tools.ietf.org/html/rfc5245#section-2.1), qui parle de STUN/TURN, NAT-traversal et autres aspects importants de WebRTC. Dans le cadre de Garage, on est pas intéressés par la totalité d'ICE, parce qu'on impose la contrainte suivante : « Chaque paire de nœud doit pouvoir communiquer ». Autrement dit, une machine derrière un NAT casse-pieds n'a pas le droit de participer à un cluster Garage. Néanmoins, ICE a une approche que je trouve pertinente pour gérer la dynamicité des adresses (e.g. IPv4 publiques changeantes) : > Chaque nœud reçoit ses propres adresses via ses pairs, genre « Quand tu me parles, je vois cette adresse locale, pas l'IP publique que tu m'as communiqué ; tu le savais ? ». Il maintient la liste de ses adresses, et les envoie toutes aux nouveaux pairs. Le nouveau pair essaye de ping avec lesdites adresses (de la plus locale à la plus globale), et décide de la meilleure adresse pour discuter ensemble. Ainsi, dans le cadre de la gestion de **membership**, chaque nœud apprend et maintient plusieurs adresses permettant de le joindre. Lors du **bootstrap** d'un nouveau nœud N, ce dernier n'a besoin de connaître qu'une seule adresse *valide* d'un nœud du cluster, qui lui fournit le registre des membres. Quand il veut démarrer une connexion avec le nœud M, le nouveau nœud N essaye plusieurs adresses, et établira la connexion avec la *meilleure* adresse (la plus locale). Dans le cadre du **membership**, si un nœud change d'adresse (DNS par exemple), il restera sans doute adressable via une autre de ses adresses. En résumé : « plusieurs adresses par nœud et pas de suppositions sur la plus fiable », plus un mécanisme de sélection quand deux nœuds initient une connexion pour la première fois. Une façon simple et souple de faciliter le bootstrap, d'éviter les indisponibilités quand le réseau change, et de préférer l'utilisation du réseau local quand deux nœuds sont dans le même.

adrien changed title from ~~Idée : maintient de plusieurs adresses par nœud pour faciliter l'établissement et la continuité des connexions entre nœuds~~ to Idée : maintien de plusieurs adresses par nœud pour faciliter l'établissement et la continuité des connexions entre nœuds

2021-04-09 11:25:31 +00:00

No Label

No Milestone

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: lx/netapp#1

No description provided.