Gestion de cluster dans Orleans

Article
01/10/2025

Orleans fournit la gestion des clusters via un protocole d’adhésion intégré, que nous désignons parfois par adhésion au cluster. L’objectif de ce protocole est que tous les silos (serveurs Orleans) s’accordent sur l’ensemble des silos actuellement actifs, détectent les silos ayant échoué et permettent à de nouveaux silos de rejoindre le cluster.

Le protocole s’appuie sur un service externe pour fournir une abstraction de IMembershipTable. IMembershipTable est une table durable plate que nous utilisons à deux fins. Tout d’abord, il est utilisé comme point de rendez-vous pour que les silos puissent se trouver les uns les autres et que les clients Orleans puissent trouver les silos. Deuxièmement, elle permet de stocker la vue des appartenances actuelles (liste des silos actifs) et aide à coordonner l’accord sur la vue des appartenances.

Nous avons actuellement 6 implémentations de la IMembershipTable: basées sur Stockage Table Azure, azure Cosmos DB, ADO.NET (PostgreSQL, MySQL/MariaDB, SQL Server, Oracle), Apache ZooKeeper, Consul IO, AWS DynamoDB, MongoDB, Redis, Apache Cassandraet une implémentation en mémoire pour le développement.

Outre IMembershipTable, chaque silo participe à un protocole d’appartenance d’égal à égal entièrement distribué qui détecte les silos ayant échoué et atteint un accord sur un ensemble de silos actifs. Nous décrivons l’implémentation interne du protocole d’appartenance de Orleansci-dessous.

Protocole d’appartenance

Au démarrage, chaque silo ajoute une entrée pour elle-même dans une table partagée bien connue, à l’aide d’une implémentation de IMembershipTable. Une combinaison d’identité de silo (ip:port:epoch) et d’ID de déploiement de service (ID de cluster) est utilisée comme clés uniques dans la table. L’époque correspond juste au temps exprimé en graduations quand ce silo a commencé et, en tant que telle, ip:port:epoch est garantie comme étant unique dans un déploiement Orleans donné.
Les silos surveillent les uns les autres directement, via des sondes d’application (« êtes-vous vivants » heartbeats). les sondes sont envoyées en tant que messages directs de silo à silo, utilisant les mêmes sockets TCP pour la communication entre les silos. De cette façon, les sondes sont entièrement corrélées avec les problèmes de mise en réseau réels et l’intégrité du serveur. Chaque silo sonde un ensemble configurable d’autres silos. Un silo choisit quelles cibles sonder en calculant des hachages cohérents sur l'identité d'autres silos, en formant un anneau virtuel de toutes les identités et en choisissant les X silos successeurs sur l'anneau (c'est une technique de distribution bien connue appelée hachage cohérent et elle est largement utilisée dans de nombreuses tables de hachage distribuées, comme Chord DHT).
Si un silo S ne reçoit pas Y réponses de sondes d’un serveur surveillé P, il le soupçonne en écrivant sa suspicion horodatée dans la ligne de P dans le IMembershipTable.
Si P a plus de Z soupçons en K secondes, alors S écrit que P est mort dans la ligne de P et envoie un snapshot de la table d’adhésion actuelle à tous les autres silos. Les silos actualisent la table périodiquement, donc le snapshot est une optimisation pour réduire le temps nécessaire à tous les silos pour connaître la nouvelle vue d’adhésion.
Plus en détail :
1. Le soupçon est écrit dans IMembershipTable, dans une colonne spéciale, dans la ligne correspondant à P. Quand S soupçonne P, il écrit : « à l’instant TTT, S soupçonnait P ».
2. Un soupçon n’est pas suffisant pour déclarer que P est mort. Vous avez besoin de Z soupçons provenant de différents silos dans une fenêtre de temps configurable T, généralement 3 minutes, pour déclarer que P est mort. Le soupçon est écrit à l’aide du contrôle d’accès concurrentiel optimiste fourni par IMembershipTable.
3. Le silo S suspicieux lit la ligne de P.
4. Si S est le dernier silo suspicieux (il y a déjà eu Z-1 silos suspicieux dans une période T, comme écrit dans la colonne des soupçons), S décide de déclarer que P est mort. Dans ce cas, S s’ajoute à la liste des silos suspicieux et écrit également dans la colonne d’état de P que P est mort.
5. Sinon, si S n’est pas le dernier silo suspicieux, S s’ajoute simplement à la colonne des silos suspicieux.
6. Dans les deux cas, l’écriture différée utilise le numéro de version ou l’ETag qui a été lu, de sorte que les mises à jour de cette ligne sont sérialisées. Si l’écriture a échoué en raison d’une non-correspondance entre la version et l’ETag, S réessaie (relecture et tentative d’écriture, sauf si P a déjà été marqué comme mort).
7. À un niveau élevé, cette séquence de « lecture, modification locale, écriture différée » est une transaction. Toutefois, nous n’utilisons pas nécessairement les transactions de stockage pour ce faire. Le code de « transaction » s’exécute localement sur un serveur et nous utilisons l’accès concurrentiel optimiste fourni par IMembershipTable pour garantir l’isolement et l’atomicité.
Chaque silo lit régulièrement la table des appartenances entière pour son déploiement. De cette façon, les silos découvrent les nouveaux silos qui les rejoignent et les autres silos qui sont déclarés morts.
Diffusion de snapshots: Pour réduire la fréquence des lectures périodiques de la table, chaque fois qu’un silo écrit dans la table (suspicion, nouvelle adhésion, etc.), il envoie un snapshot de l’état actuel de la table à tous les autres silos. Étant donné que la table d’appartenances est cohérente et monotoniquement versionnée, chaque mise à jour produit un instantané à version unique qui peut être partagé en toute sécurité. Cela permet la propagation immédiate des modifications d’appartenance sans attendre le cycle de lecture périodique. La lecture périodique est toujours maintenue comme mécanisme de secours au cas où la distribution du snapshot échouerait.
Vues d’adhésion ordonnées: Le protocole d’adhésion garantit que toutes les configurations d’adhésion sont totalement ordonnées globalement. Cet ordre offre deux avantages clés :
1. Connectivité garantie: Lorsqu’un nouveau silo rejoint le cluster, il doit valider la connectivité bidirectionnelle avec chaque autre silo actif. Si un silo existant ne répond pas (potentiellement indiquant un problème de connectivité réseau), le nouveau silo n’est pas autorisé à se joindre. Cela garantit une connectivité complète entre tous les silos du cluster au moment du démarrage. Consultez la note sur IAmAlive ci-dessous pour obtenir une exception en cas de récupération d’urgence.
2. Mises à jour cohérentes du répertoire: Les protocoles de niveau supérieur, tels que le répertoire de grains distribué, dépendent du fait que tous les silos aient une vue d’adhésion cohérente et monotone. Cela permet une résolution plus intelligente des activations de grains en doublon. Pour plus de détails, veuillez consulter la documentation du répertoire de grains.
Détails de l’implémentation:
1. Le IMembershipTable nécessite des mises à jour atomiques pour garantir un ordre total global des modifications :
  - Les implémentations doivent mettre à jour les entrées de table (liste de silos) et le numéro de version de manière atomique.
  - Cela peut être réalisé à l’aide de transactions de base de données (comme dans SQL Server) ou d’opérations de comparaison et d’échange atomiques à l’aide d’ETags (comme dans Stockage Table Azure)
  - Le mécanisme spécifique dépend des fonctionnalités du système de stockage sous-jacent
2. Une ligne spéciale de version d’adhésion dans la table suit les changements :
  - Chaque écriture dans la table (soupçons, déclarations de mort, adhésions) incrémente ce numéro de version
  - Toutes les écritures sont sérialisées via cette ligne en utilisant des mises à jour atomiques
  - La version monotoniquement croissante garantit un classement total de toutes les modifications d’appartenance
3. Lorsque silo S met à jour l’état du silo P :
  - S lit d’abord l’état actuel de la table
  - Dans une seule opération atomique, il met à jour à la fois la ligne de P et incrémente le numéro de version
  - Si la mise à jour atomique échoue (par exemple, en raison de modifications concurrentes), l’opération est réessayée avec un retour exponentiel
considérations relatives à l’extensibilité :

La sérialisation de toutes les opérations d'écriture via la ligne de version peut avoir un impact sur l'extensibilité en raison d'une contention accrue. Le protocole a été prouvé en production avec jusqu’à 200 silos, mais peut faire face à des défis au-delà de mille silos. Pour les déploiements très volumineux, d’autres parties de Orleans (messagerie, répertoire grain, hébergement) restent évolutives même si les mises à jour d’appartenance deviennent un goulot d’étranglement.
configuration par défaut: la configuration par défaut a été paramétrée manuellement pendant l’utilisation de la production dans Azure. Par défaut : chaque silo est surveillé par trois autres silos, deux soupçons sont suffisants pour déclarer un silo mort, les suspicions seulement des trois dernières minutes (sinon elles sont obsolètes). les sondes sont envoyées toutes les dix secondes et vous devrez manquer trois sondes pour suspecter un silo.
Auto-surveillance: Le détecteur de fautes intègre des idées de la recherche Lifeguard de Hashicorp (document, conférence, blog) pour améliorer la stabilité du cluster lors d’événements catastrophiques où une grande partie du cluster subit une défaillance partielle. Le composant LocalSiloHealthMonitor évalue l’intégrité de chaque silo en utilisant plusieurs heuristiques :
- Statut actif dans la table d’adhésion
- Aucun soupçon provenant des autres silos
- Réponses de sonde réussies récentes
- Requêtes de sondes récentes reçues
- Réactivité du pool de threads (éléments de travail s’exécutant dans un délai de 1 seconde)
- Précision du minuteur (déclenchement dans les 3 secondes de la planification)
Le score d’intégrité d’un silo affecte ses délais d’attente de sondes : les silos non sains (score 1-8) ont des délais d’attente augmentés par rapport aux silos sains (score 0). Cela présente deux avantages :
- Donne plus de temps pour que les sondes réussissent lorsque le réseau ou le système est soumis à un stress
- Cela augmente la probabilité que les silos non sains soient déclarés morts avant qu’ils ne puissent à tort éliminer des silos sains
Cela est particulièrement intéressant dans des scénarios comme la famine de pool de threads, où des nœuds lents pourraient autrement suspecter à tort des nœuds sains simplement parce qu’ils ne peuvent pas traiter les réponses assez rapidement.
Sonde indirecte: Une autre fonctionnalité inspirée de Lifeguard qui améliore la précision de la détection des défaillances en réduisant la probabilité qu’un silo non sain ou partitionné déclare à tort un silo sain mort. Lorsqu’un silo de surveillance dispose de deux tentatives de sondes restantes pour un silo cible avant de voter pour le déclarer mort, il utilise la sonde indirecte :
- Le silo de surveillance sélectionne aléatoirement un autre silo en tant qu’intermédiaire et lui demande de sonder la cible
- L’intermédiaire tente de contacter le silo cible
- Si la cible ne répond pas dans le délai d’expiration, l’intermédiaire envoie un accusé de réception négatif
- Si le silo de surveillance a reçu un accusé de réception négatif de l’intermédiaire et que l’intermédiaire se déclare sain (par le biais de l’auto-surveillance, décrit ci-dessus), le silo de surveillance a émis un vote pour déclarer la cible morte
- Avec la configuration par défaut de deux votes requis, un accusé de réception négatif d’une sonde indirecte compte comme les deux votes, ce qui permet une déclaration plus rapide des silos morts lorsque l’échec est confirmé par plusieurs perspectives
Application d’une détection parfaite des défaillances: Une fois qu’un silo est déclaré mort dans la table, il est considéré comme mort par tous, même s’il ne l’est pas (juste partitionné temporairement ou si des messages de heartbeat ont été perdus). Tout le monde cesse de communiquer avec lui et une fois qu’il apprend qu’il est mort (en lisant son nouvel état dans la table), il se suicide et arrête son processus. Par conséquent, une infrastructure doit être en place pour redémarrer le silo en tant que nouveau processus (un nouveau nombre d’époque est généré au démarrage). Lorsqu’elle est hébergée dans Azure, cela se produit automatiquement. Quand ce n’est pas le cas, une autre infrastructure est requise, telle qu’un service Windows configuré pour redémarrer automatiquement en cas d’échec ou un déploiement Kubernetes.
Que se passe-t-il si la table n’est pas accessible pendant un certain temps :

En cas de panne, d’indisponibilité ou de problème de communication du service de stockage, le protocole Orleans NE déclare PAS les silos comme morts par erreur. Les silos opérationnels continueront de fonctionner sans aucun problème. Toutefois, Orleans ne pourra pas déclarer un silo mort (s’il détecte que certains silos sont morts via des requêtes sondes manquantes, il ne pourra pas écrire ce fait dans la table), pas plus qu’il ne pourra autoriser la jonction de nouveaux silos. Ainsi, l’exhaustivité sera mise à mal, mais pas la précision : le partitionnement de la table ne poussera jamais Orleans à déclarer le silo comme mort par erreur. De plus, en cas de partition partielle du réseau (si certains silos peuvent accéder à la table et d’autres non), il peut arriver que Orleans déclare un silo mort comme mort. Cependant, la communication de cette information à tous les autres silos peut prendra un certain temps. Ainsi, la détection pourrait être retardée, mais Orleans ne supprimera jamais un silo par erreur en raison de l’indisponibilité de la table.
IAmAlive écrit pour les diagnostics et la récupération après sinistre:

Outre les pulsations envoyées entre les silos, chaque silo met régulièrement à jour un timestamp « I Am Alive » (Je suis actif) dans sa ligne, dans la table. Cela sert à deux fins :
1. Pour les diagnostics, il fournit aux administrateurs système un moyen simple de vérifier la durée de vie du cluster et de déterminer quand un silo a été actif pour la dernière fois. L’horodatage est généralement mis à jour toutes les 5 minutes.
2. Pour la récupération d’urgence, si un silo n’a pas mis à jour son horodatage pendant plusieurs périodes (configuré via NumMissedTableIAmAliveLimit), les nouveaux silos l’ignorent lors des vérifications de connectivité de démarrage, ce qui permet au cluster de récupérer à partir de scénarios où les silos se sont bloqués sans nettoyage approprié.

Table des appartenances

Comme cela a déjà été mentionné, la table IMembershipTable est utilisée comme point de rendez-vous pour que les silos puissent se retrouver les uns les autres et que les clients Orleans puissent trouver les silos, et elle aide également à coordonner l’accord sur la vue des appartenances. Le référentiel principal Orleans contient des implémentations pour de nombreux systèmes, tels que Stockage Table Azure, Azure Cosmos DB, PostgreSQL, MySQL/MariaDB, SQL server, Apache ZooKeeper, Consul IO, Apache Cassandra, MongoDB, Redis, AWS DynamoDB et une implémentation en mémoire pour le développement.

Stockage Table Azure: dans cette implémentation, nous utilisons l’ID de déploiement Azure comme clé de partition et l’identité de silo (ip:port:epoch) comme clé de ligne. Ensemble, ils garantissent une clé unique par silo. Pour le contrôle d’accès concurrentiel, nous utilisons le contrôle d’accès concurrentiel optimiste basé sur les ETags de table Azure. Chaque fois que nous lisons à partir de la table, nous stockons l’ETag pour chaque ligne de lecture et utilisons cet ETag lorsque nous essayons d’écrire en différé. Les ETags sont automatiquement attribués et vérifiés par le service Table Azure à chaque écriture. Pour les transactions à plusieurs lignes, nous utilisons la prise en charge des transactions par lots fournies par la table Azure, qui garantit des transactions sérialisables sur des lignes avec la même clé de partition.
SQL Server : dans cette implémentation, l’ID de déploiement configuré est utilisé pour établir la distinction entre les déploiements et les silos qui appartiennent aux déploiements. L’identité de silo est définie comme une combinaison de deploymentID, ip, port, epoch dans les tables et les colonnes appropriées. Le back-end relationnel utilise le contrôle d’accès concurrentiel optimiste et les transactions, comme dans la procédure d’utilisation des ETags dans l’implémentation de la table Azure. L’implémentation relationnelle s’attend à ce que le moteur de base de données génère l’ETag utilisé. Dans le cas de SQL Server, dans SQL Server 2000, l’ETag généré est un élément acquis à partir d’un appel à NEWID(). Dans SQL Server 2005 et versions ultérieures, ROWVERSION est utilisé. Orleans lit et écrit des ETags relationnels sous forme d’étiquettes VARBINARY(16) opaques et les stocke en mémoire sous forme de chaînes codées en base64. Orleans prend en charge les insertions à plusieurs lignes à l’aide de UNION ALL (pour Oracle, y compris DUAL), ce qui est actuellement utilisé pour insérer des données statistiques. L’implémentation et la logique exactes de SQL Server sont visibles dans CreateOrleansTables_SqlServer.sql.
Apache ZooKeeper : dans cette implémentation, nous utilisons l’ID de déploiement configuré comme nœud racine et l’identité de silo (ip:port@epoch) comme son nœud enfant. Ensemble, ils garantissent un chemin unique par silo. Pour le contrôle d’accès concurrentiel, nous utilisons le contrôle d’accès concurrentiel optimiste basé sur la version du nœud. Chaque fois que nous lisons à partir du nœud racine de déploiement, nous stockons la version pour chaque nœud de silo enfant lu et utilisons cette version lorsque nous essayons d’écrire en différé. Chaque fois que les données d’un nœud changent, le numéro de version augmente atomiquement via le service ZooKeeper. Pour les transactions à plusieurs lignes, nous utilisons la méthode multifacteur, qui garantit des transactions sérialisables sur les nœuds de silo avec le même nœud d’ID de déploiement parent.
Consul IO : nous avons utilisé le magasin de clés/valeurs de Consul pour implémenter la table des appartenances. Pour plus d’informations, consultez Déploiement de Consul.
AWS DynamoDB : dans cette implémentation, nous utilisons l’ID de déploiement du cluster comme clé de partition et l’identité de silo (ip-port-generation) comme RangeKey qui fait l’unité de l’enregistrement. L’accès concurrentiel optimiste est réalisé par l’attribut ETag en effectuant des écritures conditionnelles sur DynamoDB. La logique d’implémentation est assez similaire au Stockage Table Azure.
Apacha Cassandra : dans cette implémentation, nous utilisons le composite d’ID de service et d’ID de cluster comme clé de partition et l’identité de silo (ip:port:epoch) comme clé de ligne. Ensemble, ils garantissent une ligne unique par silo. Pour le contrôle de concurrence, nous utilisons un contrôle de concurrence optimiste basé sur une version de colonne statique en utilisant une Transaction Légère. Cette colonne de version est partagée pour toutes les lignes de la partition/cluster. Elle fournit donc le numéro de version incrémenté cohérent pour la table d’appartenance de chaque cluster. Il n’existe aucune transaction à plusieurs lignes dans cette implémentation.
Émulation en mémoire pour la configuration du développement. Nous utilisons un grain de système spécial pour cette implémentation. Ce grain réside sur un silo principal désigné, qui est utilisé uniquement pour une configuration de développement. Dans toute utilisation réelle en production le silo principal n’est pas obligatoire.

Logique de conception

On peut naturellement se poser la question suivante : pourquoi ne pas s’appuyer complètement sur Apache ZooKeeper ou etcd pour l’implémentation de l’appartenance au cluster, en utilisant potentiellement la prise en charge prête à l’emploi de ZooKeeper pour l’appartenance aux groupes avec des nœuds éphémères ? Pourquoi avons-nous pris la peine d’implémenter notre protocole d’appartenance ? Il y avait principalement trois raisons :

Déploiement/hébergement dans le cloud :

Zookeeper n’est pas un service hébergé. Cela signifie que dans l’environnement cloud, les clients Orleans doivent déployer/exécuter/gérer leur instance d’un cluster ZK. Ce n’est là qu’un autre fardeau inutile, que nous ne voulions pas imposer à nos clients. En utilisant la table Azure, nous nous appuyons sur un service géré hébergé qui simplifie considérablement la vie de notre client. En fait, dans le cloud, utilisez le cloud en tant que plateforme, et non pas en tant qu’infrastructure. D’un autre côté, lors de l’exécution locale et de la gestion de vos serveurs, s’appuyer sur ZK comme implémentation de l’élément IMembershipTable est une option viable.
Détection directe des défaillances :

Lorsque vous utilisez l’appartenance aux groupes de ZK avec des nœuds éphémères, la détection des défaillances s’effectue entre les serveurs Orleans (clients ZK) et les serveurs ZK. Cela peut ne pas nécessairement correspondre aux problèmes réseau réels entre des serveurs Orleans. Notre désir était que la détection des défaillances reflète avec précision l’état de la communication à l’intérieur du cluster. Plus précisément, dans notre conception, si un silo Orleans ne peut pas communiquer avec IMembershipTable, il n’est pas considéré comme mort et peut continuer à fonctionner. Par contre, si nous utilisons l’appartenance aux groupes de ZK avec des nœuds éphémères, une déconnexion d’un serveur ZK peut entraîner la déclaration d’un silo Orleans (client ZK) comme mort, alors qu’il peut être actif et pleinement fonctionnel.
Portabilité et flexibilité :

Dans le cadre de la philosophie d’Orleans, nous ne voulons pas imposer une forte dépendance à toute technologie particulière, mais plutôt disposer d’une conception flexible où différents composants peuvent facilement basculer entre différentes implémentations. L’abstraction IMembershipTable sert exactement cet objectif.

Propriétés du protocole d’appartenance

Peut gérer n’importe quel nombre d’échecs :

Notre algorithme peut gérer n’importe quel nombre d’échecs (c’est-à-dire f<=n), y compris un redémarrage complet du cluster. Cela contraste avec les solutions « traditionnelles » basées sur Paxos, qui nécessitent un quorum, qui est généralement une majorité. Nous avons vu cela dans des situations de production, quand plus de la moitié des silos étaient en panne. Notre système est resté fonctionnel, tandis que l’appartenance basée sur Paxos n’aurait pas été en mesure de faire des progrès.
Le trafic vers la table est très léger :

Les sondes réelles vont directement entre les serveurs et non vers la table. Cela générerait beaucoup de trafic et serait moins précis du point de vue de la détection des échecs. Si un silo ne pouvait pas atteindre la table, il n’écrirait pas sa pulsation Je suis actif, et les autres le supprimeraient.
Précision ajustable ou exhaustivité :

Une détection des échecs parfaite et précise est impossible, mais il est généralement souhaitable de pouvoir compenser la précision (vous ne souhaitez pas déclarer un silo actif comme mort) par l’exhaustivité (vous voulez déclarer comme mort un silo qui est effectivement mort dès que possible). Les votes configurables pour déclarer mort et les sondes manquées permettent de faire un compromis entre les deux. Pour plus d’informations, consultez Université de Yale : Détecteurs d’échec en informatique.
Échelle :

Le protocole peut gérer des milliers et probablement des dizaines de milliers de serveurs. Cela contraste avec les solutions traditionnelles basées sur Paxos, telles que les protocoles de communication de groupe, qui sont connues pour ne pas permettre une mise à l’échelle au-delà de quelques dizaines.
Diagnostics :

La table est également très pratique pour les diagnostics et la résolution des problèmes. Les administrateurs système peuvent rechercher instantanément dans la table la liste actuelle des silos actifs, ainsi que consulter l’historique de tous les silos supprimés et des soupçons. Cela est particulièrement utile lors du diagnostic des problèmes.
Pourquoi avons-nous besoin d’un stockage persistant fiable pour l’implémentation de IMembershipTable :

Nous utilisons le stockage persistant pour les IMembershipTable à deux fins. Tout d’abord, il est utilisé comme point de rendez-vous pour que les silos puissent se trouver les uns les autres et que les clients Orleans puissent trouver les silos. Deuxièmement, nous utilisons un stockage fiable pour mieux coordonner l’accord sur la vue des appartenances. Nous effectuons la détection des défaillances directement dans un mode d’égal à égal entre les silos, nous stockons la vue des appartenances dans un stockage fiable et nous utilisons le mécanisme de contrôle d’accès concurrentiel fourni par ce stockage pour atteindre un accord concernant qui est actif et qui est mort. De cette façon, dans un sens, notre protocole externalise le problème difficile du consensus distribué dans le cloud. En cela, nous utilisons pleinement la puissance de la plateforme cloud sous-jacente, en l’utilisant réellement comme une plateforme en tant que service (PaaS).
Écriture directe de IAmAlive dans la table pour les diagnostics uniquement :

Outre les pulsations envoyées entre les silos, chaque silo met régulièrement à jour une colonne « I Am Alive » (Je suis actif) dans sa ligne, dans la table. Cette colonne « Je suis actif » est utilisée uniquement pour les diagnostics et la résolution manuelle des problèmes, et elle n’est pas utilisée par le protocole d’appartenance lui-même. Elle est généralement écrite à une fréquence beaucoup plus faible (une fois toutes les 5 minutes) et sert d’outil très utile pour les administrateurs système afin de vérifier l’activité du cluster et de découvrir facilement quand le silo était actif pour la dernière fois.

Remerciements

Nous aimerions reconnaître la contribution d’Alex Kogan à la conception et à l’implémentation de la première version de ce protocole. Ce travail a été effectué dans le cadre d’un stage d’été dans Microsoft Research à l’été 2011. L’implémentation de IMembershipTable basé sur ZooKeeper a été effectuée par Shay Hazor, l’implémentation de SQL IMembershipTable a été effectuée par Veikko Eeva, l’implémentation d'AWS DynamoDB IMembershipTable a été réalisée par Gutemberg Ribeiro et l’implémentation de Consul basé IMembershipTable a été effectuée par Paul North, et enfin, l'implémentation d'Apache Cassandra IMembershipTable a été adaptée de OrleansCassandraUtils par Arshia001.

Partage via