Gestione dei cluster in Orleans

Orleans fornisce la gestione dei cluster tramite un protocollo di appartenenza predefinito, a volte indicato come appartenenza a cluster . L'obiettivo di questo protocollo è consentire a tutti i silos (server Orleans) di accettare il set di silos attualmente attivi, rilevare i silos in errore e consentire a nuovi silos di unirsi al cluster.

Il protocollo si basa su un servizio esterno per fornire un'astrazione di IMembershipTable. IMembershipTable è una tabella durevole piatta usata per due scopi. In primo luogo, viene usata come punto di incontro per consentire ai silos di trovarsi reciprocamente e ai client Orleans di trovare i silos. In secondo luogo, viene usata per archiviare la visualizzazione delle appartenenze corrente (elenco di silos attivi) e aiuta a coordinare l'accordo su tale visualizzazione.

Attualmente sono disponibili 6 implementazioni di IMembershipTable: basate su Archiviazione tabelle di Azure, Azure Cosmos DB, ADO.NET (PostgreSQL, MySQL/MariaDB, SQL Server, Oracle), Apache ZooKeeper, Consul IO, AWS DynamoDB, MongoDB, Redis, Apache Cassandrae un'implementazione in memoria per lo sviluppo.

Oltre all'interfaccia IMembershipTable, ogni silo partecipa a un protocollo di appartenenza peer-to-peer completamente distribuito che rileva i silos in errore e raggiunge un accordo su un set di silos attivi. Di seguito viene descritta l'implementazione interna del protocollo di appartenenza di Orleans.

Protocollo di appartenenza

1. All'avvio, ogni silo aggiunge una voce per se stesso in una tabella condivisa nota, usando un'implementazione di IMembershipTable. Una combinazione di identità silo (ip:port:epoch) e ID distribuzione del servizio (ID cluster) viene usata come chiavi univoche nella tabella. Per epoch si intende semplicemente il tempo in tick in cui viene avviato il silo ed è pertanto garantito che il valore di ip:port:epoch sia univoco in una determinata distribuzione di Orleans.

2. I silos si monitorano direttamente, tramite sonde dell'applicazione ("sei vivo" heartbeats). Le sonde vengono inviate come messaggi diretti da silo a silo, sugli stessi socket TCP utilizzati per la comunicazione tra i silos. In questo modo, le sonde sono completamente correlate ai problemi di rete effettivi e allo stato di salute del server. Ogni silo controlla un insieme configurabile di altri silo. Un silo seleziona chi eseguire il sondaggio calcolando hash consistenti sull'identità di altri silo, formando un anello virtuale di tutte le identità e selezionando i successivi X silo sull'anello (si tratta di una tecnica distribuita ben nota denominata consistent hashing ed è ampiamente usata in molte tabelle hash distribuite, come Chord DHT).

3. Se un silo S non riceve risposte del probe Y da un server monitorato P, sospetta che venga scritto il sospetto timestamp nella riga di P nel IMembershipTable.

4. Se P ha più di Z sospetti entro K secondi, S scrive che P è morto nella riga di P e invia uno snapshot della tabella dei membri corrente a tutti gli altri silos. I silos aggiornano periodicamente la tabella, quindi lo snapshot è un'ottimizzazione per ridurre il tempo impiegato per tutti i silos per ottenere informazioni sulla nuova vista di appartenenza.

5. Più in dettaglio:

   1. Il sospetto viene scritto in IMembershipTable, in una colonna speciale nella riga corrispondente a P. Quando S sospetta che P non sia attivo, scrive che all'ora TTT S ha sospettato P.

   2. Un solo sospetto non è sufficiente a dichiarare inattivo P. A tale scopo, sono necessari Z sospetti espressi da diversi silos in un intervallo di tempo configurabile T, che corrisponde in genere a tre minuti. Il sospetto viene scritto usando il controllo di concorrenza ottimistica fornito da IMembershipTable.

   3. Il silo S che ha espresso il sospetto legge la riga di P.

   4. Se S è l'ultimo ad avere avuto un sospetto (ne sono già stati espressi Z-1 entro un periodo T, come indicato nella colonna dei sospetti), S decide di dichiarare inattivo P. In questo caso, S si aggiunge all'elenco dei silos che hanno espresso un sospetto e nella colonna relativa allo stato di P scrive che P è inattivo.

   5. Se invece S non è l'ultimo ad avere avuto un sospetto, si aggiunge semplicemente alla colonna dei silos che hanno espresso un sospetto.

   6. In entrambi i casi, il writeback usa il numero di versione o l'ETag che è stato letto e quindi gli aggiornamenti di questa riga vengono serializzati. Nel caso in cui la scrittura non sia riuscita a causa della mancata corrispondenza di versione o ETag, S ripete il tentativo (legge di nuovo e prova a scrivere, a meno che P non sia già stato contrassegnato come inattivo).

   7. A livello generale, questa sequenza di "lettura, modifica locale, writeback" è una transazione. Tuttavia, non si usano necessariamente transazioni di archiviazione per farlo. Il codice della "transazione" viene eseguito in locale su un server e viene usata la concorrenza ottimistica fornita da IMembershipTable per garantire l'isolamento e l'atomicità.

6. Ogni silo legge periodicamente l'intera tabella delle appartenenze per la distribuzione. In questo modo, i silos apprendono che si sono uniti nuovi silos e che altri silos sono stati dichiarati inattivi.

7. Trasmissione dello snapshot: per ridurre la frequenza di letture periodiche della tabella, ogni volta che un silo effettua una scrittura nella tabella (ad esempio in caso di sospetto, nuovo ingresso, ecc.) invia uno snapshot dello stato della tabella corrente a tutti gli altri silo. Poiché la tabella di appartenenza è coerente e a versionamento monotono, ogni aggiornamento genera un'istantanea con versione univoca che può essere condivisa in modo sicuro. Ciò consente la propagazione immediata delle modifiche di appartenenza senza attendere il ciclo di lettura periodico. La lettura periodica viene comunque mantenuta come meccanismo di fallback nel caso in cui la distribuzione degli snapshot non riesca.

8. visualizzazioni di appartenenza ordinate: il protocollo di appartenenza garantisce che tutte le configurazioni di appartenenza siano completamente ordinate a livello internazionale. Questo ordinamento offre due vantaggi principali:

   1. connettività garantita: quando un nuovo silo viene aggiunto al cluster, deve convalidare la connettività bidirezionale a ogni altro silo attivo. Se un silo esistente non risponde (potenzialmente indica un problema di connettività di rete), il nuovo silo non può essere aggiunto. In questo modo si garantisce la connettività completa tra tutti i silo nel cluster in fase di avvio. Consultare la nota seguente su IAmAlive per un'eccezione nel caso di ripristino in caso di emergenza.

   2. aggiornamenti coerenti delle directory: protocolli di livello superiore, ad esempio la directory granulare distribuita, si basano su tutti i silo con una visualizzazione coerente e monotonica dell'appartenenza. Ciò consente una risoluzione più intelligente delle attivazioni duplicate di grano. Per altri dettagli, vedere la documentazione della directory per grano .

   Dettagli dell'implementazione:

   1. Il IMembershipTable richiede aggiornamenti atomici per garantire un ordine totale globale di modifiche:

      • Le implementazioni devono aggiornare le voci della tabella (elenco di silo) e il numero di versione in modo atomico
      • A tale scopo, è possibile utilizzare transazioni di database (come in SQL Server) oppure operazioni atomiche di confronto e scambio tramite ETags (come in Azure Table Storage)
      • Il meccanismo specifico dipende dalle funzionalità del sistema di archiviazione sottostante

   2. Una riga speciale della versione di appartenenza nella tabella tiene traccia delle modifiche:

      • Ogni scrittura nella tabella (sospetti, dichiarazioni di morte, unioni) incrementa questo numero di versione.
      • Tutte le scritture vengono serializzate tramite questa riga usando gli aggiornamenti atomici
      • La versione a aumento monotonico garantisce un ordinamento totale di tutte le modifiche di appartenenza

   3. Quando silo S aggiorna lo stato del silo P:

      • S legge prima lo stato della tabella più recente
      • In un'unica operazione atomica, aggiorna la riga di P e incrementa il numero di versione.
      • Se l'aggiornamento atomico ha esito negativo (ad esempio, a causa di modifiche simultanee), l'operazione viene ritentata utilizzando un meccanismo di attesa esponenziale.

   considerazioni sulla scalabilità:

   La serializzazione di tutte le scritture tramite la riga di versione può influire sulla scalabilità a causa di un aumento della contesa. Il protocollo ha dimostrato di funzionare nell'ambiente di produzione con un massimo di 200 silo, ma può affrontare sfide quando si superano i mille silo. Per distribuzioni molto grandi, altre parti di Orleans (messaggistica, directory granulare, hosting) rimangono scalabili anche se gli aggiornamenti dell'appartenenza diventano un collo di bottiglia.

9. configurazione predefinita: La configurazione predefinita è stata ottimizzata durante l'uso in produzione in Azure. Per impostazione predefinita: ogni silo viene monitorato da tre altri silos, due sospetti sono sufficienti per dichiarare un silo non funzionante, solo sospetti degli ultimi tre minuti (altrimenti sono obsoleti). Le sonde vengono inviate ogni dieci secondi ed è necessario mancarne tre per sospettare un silo.

10. monitoraggio automatico: il rilevatore di errori incorpora idee della ricerca Lifeguard di Hashicorp (paper, talk, blog) per migliorare la stabilità del cluster durante eventi irreversibili in cui una grande parte del cluster riscontra un errore parziale. Il componente LocalSiloHealthMonitor assegna punteggi all'integrità di ogni silo utilizzando diverse euristiche.

    • Stato attivo nella tabella di appartenenza
    • Nessun sospetto da altri silo
    • Risposte recenti riuscite alla sonda
    • Richieste di probe recenti ricevute
    • Velocità di risposta del pool di thread (elementi di lavoro eseguiti entro 1 secondo)
    • Accuratezza del timer (attivazione entro 3 secondi dall'orario programmato)

    Il punteggio di salute di un silo influisce sui timeout della sonda: i silos malsani (punteggio 1-8) hanno timeout aumentati rispetto ai silos sani (punteggio 0). Questo offre due vantaggi:

    • Offre più tempo affinché le sonde abbiano successo quando la rete o il sistema è sotto stress
    • Rende più probabile che i silo non sani saranno considerati morti prima di poter eliminare erroneamente i silo sani.

    Ciò è particolarmente utile durante scenari come la saturazione del pool di thread, in cui i nodi lenti potrebbero sospettare erroneamente nodi integri solo perché non possono elaborare le risposte abbastanza rapidamente.

11. probe indiretto: un'altra funzionalità ispirata al lifeguardche migliora l'accuratezza del rilevamento dei guasti riducendo la probabilità che un silo malfunzionante o partizionato dichiari erroneamente un silo integro morto. Quando un silo di monitoraggio ha due tentativi di sondaggio rimanenti per un silo di destinazione prima di effettuare una votazione per dichiararlo fuori servizio, utilizza il sondaggio indiretto.

    • Il silo di monitoraggio seleziona in modo casuale un altro silo come intermediario e gli chiede di sondare la destinazione.
    • L'intermediario tenta di contattare il silo di destinazione
    • Se la destinazione non risponde entro il periodo di timeout, l'intermediario invia un riconoscimento negativo.
    • Se il silo di monitoraggio riceve un riconoscimento negativo dall'intermediario e l'intermediario si dichiara operativo (tramite auto-monitoraggio, descritto in precedenza), il silo di monitoraggio esprime un voto per dichiarare il bersaglio morto.
    • Con la configurazione predefinita di due voti necessari, un riconoscimento negativo di una sonda indiretta viene conteggiato come entrambi i voti, consentendo una dichiarazione più veloce di silo inattivi se l'errore è confermato da più prospettive

12. L'applicazione del rilevamento perfetto dei guasti: una volta che un silo viene dichiarato morto nella tabella, viene considerato morto da tutti, anche se non lo è (solo temporaneamente partizionato o i messaggi di heartbeat sono stati persi). Tutti smettono di comunicare con tale silo e, non appena quest'ultimo apprende di essere inattivo (leggendo il suo nuovo stato dalla tabella), arresta il processo. Deve pertanto essere presente un'infrastruttura che riavvia il silo come nuovo processo (all'avvio viene generato un nuovo numero di epoch). Quando il silo è ospitato in Azure, questo avviene automaticamente. In caso contrario, è necessaria un'altra infrastruttura, ad esempio un servizio Windows configurato per il riavvio automatico in caso di errore o una distribuzione kubernetes.

13. Cosa accade se la tabella non è accessibile per un certo tempo:

    Quando il servizio di archiviazione è inattivo o non disponibile oppure quando si verificano problemi di comunicazione con tale servizio, il protocollo Orleans NON commette l'errore di dichiarare inattivi i silos. I silos operativi continueranno a funzionare senza problemi. Tuttavia, Orleans non sarà in grado di dichiarare un silo morto (se rileva che alcuni silo sono morti tramite sonde perse, non sarà in grado di scrivere questo fatto nella tabella) e non sarà inoltre in grado di consentire il join di nuovi silo. Quindi la completezza ne risentirà, ma l'accuratezza no — il partizionamento dalla tabella non farà mai sì che Orleans dichiari il silo come morto per errore. Inoltre, nel caso di una partizione di rete parziale (con alcuni silo che possono accedere alla tabella e altri no), potrebbe accadere che Orleans dichiari inattivo un silo effettivamente inattivo, ma ci vorrà del tempo prima che il suo stato risulti noto a tutti gli altri silos. Il rilevamento potrebbe quindi essere ritardato, ma Orleans non commetterà mai l'errore di dichiarare inattivo un silo a causa dell'indisponibilità della tabella.

14. IAmAlive scrive per la diagnostica e il ripristino di emergenza:

    Oltre agli heartbeat inviati tra i silo, ogni silo aggiorna periodicamente un *timestamp I Am Alive* nella sua riga della tabella. Questo serve due scopi:

    1. Per la diagnostica, fornisce agli amministratori di sistema un modo semplice per controllare lo stato del cluster e determinare quando un silo è stato attivo per l'ultima volta. Il timestamp viene in genere aggiornato ogni 5 minuti.
    2. Per il ripristino di emergenza, se un silo non ha aggiornato il timestamp per diversi periodi (configurato tramite NumMissedTableIAmAliveLimit), i nuovi silo lo ignoreranno durante i controlli della connettività di avvio, consentendo al cluster di eseguire il ripristino da scenari in cui silos si arrestino in modo anomalo senza una corretta pulizia.

Tabella delle appartenenze

Come già accennato, l'oggetto IMembershipTable viene usato come punto di incontro per consentire ai silos per trovarsi reciprocamente e ai client Orleans di trovare i silos ed è utile anche a coordinare l'accordo sulla visualizzazione delle appartenenze. Il repository Orleans principale contiene implementazioni per molti sistemi, ad esempio Archiviazione tabelle di Azure, Azure Cosmos DB, PostgreSQL, MySQL/MariaDB, SQL Server, Apache ZooKeeper, Consul IO, Apache Cassandra, MongoDB, Redis, AWS DynamoDB e un'implementazione in memoria per lo sviluppo.

1. Archiviazione tabelle di Azure: in questa implementazione, l'ID distribuzione di Azure viene usato come chiave di partizione e l'identità del silo (ip:port:epoch) viene usata come chiave di riga. Insieme garantiscono una chiave univoca per ogni silo. Per controllare la concorrenza, viene usato il controllo della concorrenza ottimistica basato su ETag di archiviazione tabelle di Azure. Ogni volta che si legge dalla tabella, si archivia l'ETag per ogni riga letta e si usa tale ETag quando si tenta di eseguire il writeback. Gli ETag vengono assegnati automaticamente e controllati da archiviazione tabelle di Azure in ogni scrittura. Per le transazioni su più righe, viene usato il supporto per le transazioni batch fornito da archiviazione tabelle di Azure, che garantisce transazioni serializzabili su righe con la stessa chiave di partizione.

2. SQL Server: in questa implementazione, l'ID distribuzione configurato viene usato per distinguere tra le distribuzioni e i silos appartenenti alle distribuzioni. L'identità dei silos è definita come una combinazione di deploymentID, ip, port, epoch nelle tabelle e nelle colonne appropriate. Il back-end relazionale usa il controllo della concorrenza ottimistica e le transazioni, analogamente alla procedura che prevede l'uso di ETag nell'implementazione di archiviazione tabelle di Azure. L'implementazione relazionale prevede che il motore di database generi l'ETag usato. Nel caso di SQL Server, l'ETag generato in SQL Server 2000 viene acquisito da una chiamata a NEWID(). In SQL Server 2005 e versioni successive viene usato ROWVERSION. Orleans legge e scrive gli ETag relazionali come tag VARBINARY(16) opachi e li archivia in memoria come stringhe codificate in base64. Orleans supporta inserimenti su più righe tramite UNION ALL (per Oracle incluso DUAL), attualmente usato per inserire i dati delle statistiche. L'implementazione esatta e la logica di SQL Server possono essere visualizzate in CreateOrleansTables_SqlServer.sql.

3. Apache ZooKeeper: in questa implementazione, l'ID distribuzione configurato viene usato come nodo radice e l'identità del silo (ip:port@epoch) viene usata come nodo figlio. Insieme garantiscono un percorso univoco per ogni silo. Per controllare la concorrenza, viene usato il controllo della concorrenza ottimistica basato sulla versione del nodo. Ogni volta che si legge dal nodo radice della distribuzione, la versione viene archiviata per ogni nodo di silo figlio letto e quindi usata quando si tenta di eseguire il writeback. Ogni volta che i dati di un nodo cambiano, il numero di versione viene aumento in modo atomico dal servizio ZooKeeper. Per le transazioni a più righe, viene usato il metodo multi, che garantisce transazioni serializzabili su nodi di silo con lo stesso nodo di ID distribuzione padre.

4. Consul IO: per implementare la tabella delle appartenenze è stato usato l'archivio chiave/valore di Consul. Per altri dettagli, vedere Consul-Deployment.

5. AWS DynamoDB: in questa implementazione, l'ID distribuzione del cluster viene usato come chiave di partizione e l'identità del silo (ip-port-generation) viene usata come RangeKey che crea l'unità dei record. La concorrenza ottimistica viene realizzata dall'attributo ETag tramite scritture condizionali in DynamoDB. La logica di implementazione è molto simile a quella di archiviazione tabelle di Azure.

6. Apacha Cassandra: in questa implementazione è utilizzata la combinazione di ID Servizio e ID Cluster come chiave di partizione e l'identità silo (ip:port:epoch) come chiave di riga. Insieme garantiscono una riga univoca per ogni silo. Per il controllo della concorrenza, viene usato il controllo della concorrenza ottimistica basato su una versione di colonna statica usando una transazione leggera. Questa colonna di versione viene condivisa per tutte le righe della partizione o del cluster, pertanto fornisce il numero di versione a incremento coerente per la tabella di appartenenza di ogni cluster. In questa implementazione non sono presenti transazioni a più righe.

7. Emulazione in memoria per la configurazione di sviluppo. Per tale implementazione viene usato un granulare di sistema speciale. Il grano risiede in un silo primario designato, che viene usato solo per una configurazione di sviluppo. In qualsiasi utilizzo reale in produzione, il silo primario non è necessario.

Logica di progettazione

Una domanda naturale che potrebbe essere posta è perché non fare completamente affidamento su Apache ZooKeeper o etcd per l'implementazione dell'appartenenza al cluster, potenzialmente usando il supporto predefinito di ZooKeeper per l'appartenenza a gruppi con nodi effimeri? Perché si è ritenuto opportuno implementare uno specifico protocollo di appartenenza? I motivi sono principalmente tre:

1. Distribuzione/hosting nel cloud:

   Zookeeper non è un servizio ospitato. Ciò significa che nell'ambiente cloud Orleans i clienti avrebbero dovuto distribuire/eseguire/gestire la propria istanza di un cluster ZK. Questo sarebbe stato solo un altro peso inutile, che si voleva evitare ai clienti. Usando archiviazione tabelle di Azure è possibile basarsi su un servizio gestito ospitato, in grado di rendere molto più semplice la vita dei clienti. In pratica, il cloud viene usato come piattaforma, non come infrastruttura. D'altro canto, quando si usa un ambiente locale e si gestiscono direttamente i propri server, un'opzione praticabile è quella di affidarsi a ZK come implementazione di IMembershipTable.

2. Rilevamento diretto degli errori:

   Quando si usa l'appartenenza a gruppi di ZK con nodi temporanei, il rilevamento degli errori viene eseguito tra i server Orleans (client ZK) e i server ZK. Questo potrebbe non essere necessariamente correlato a problemi di rete effettivi tra i server Orleans. L'intenzione era di fare in modo che il rilevamento degli errori riflettesse accuratamente lo stato delle comunicazioni all'interno del cluster. In particolare, in base al criterio di progettazione adottato, se un silo Orleans non può comunicare con IMembershipTable non è considerato inattivo e può continuare a funzionare. Questo non è stato possibile usando l'appartenenza al gruppo ZK con nodi temporanei. In tal caso, infatti, una disconnessione da un server ZK può comportare la dichiarazione di inattività di un silo Orleans (client ZK), quando invece questo potrebbe essere attivo e completamente funzionante.

3. Portabilità e flessibilità:

   Come parte della filosofia di Orleans, non si intende imporre una forte dipendenza da una determinata tecnologia, ma piuttosto offrire una progettazione flessibile in cui i diversi componenti possono essere facilmente scambiati con diverse implementazioni. L'astrazione IMembershipTable serve proprio a questo.

Proprietà del protocollo di appartenenza

1. Può gestire un numero qualsiasi di errori:

   L'algoritmo può gestire un numero qualsiasi di errori, ovvero f<=n, incluso il riavvio completo del cluster. Ciò è in contrasto con le tradizionali soluzioni basate su Paxos, per cui è richiesto un quorum, che corrisponde in genere a una maggioranza. Si è potuto osservare questo comportamento in situazioni di produzione, in cui più della metà dei silos era inattiva. Questo sistema di appartenenza ha continuato a funzionare, mentre quello basato su Paxos è rimasto bloccato.

2. Il traffico verso la tabella è molto leggero:

   Le sonde effettive passano direttamente tra i server e non alla tabella. Il passaggio dalla tabella genererebbe molto traffico e sarebbe meno accurato dal punto di vista del rilevamento degli errori. Se un silo non riuscisse a raggiungere la tabella, perderebbe la scrittura del suo heartbeat di comunicazione dello stato attivo (I am alive) e altri potrebbero dichiararlo inattivo.

3. Accuratezza ottimizzabile e completezza a confronto:

   Anche se non è possibile ottenere un rilevamento degli errori completo e accurato al tempo stesso, in genere si cerca un compromesso tra accuratezza (non si vuole dichiarare inattivo un silo che in realtà non lo è) e completezza (si vuole dichiarare inattivo un silo che è effettivamente tale il prima possibile). I voti configurabili per dichiarare le sonde morte e perse consentono di scambiare queste due opzioni. Per altre informazioni, vedere Yale University: Computer Science Failure Detectors.

4. Scale (Scala):

   Il protocollo può gestire migliaia e probabilmente anche decine di migliaia di server. Ciò è in contrasto con le tradizionali soluzioni basate su Paxos, ad esempio i protocolli di comunicazione di gruppo, che sono noti per non raggiungere una scalabilità superiore alle decine.

5. Diagnostica:

   La tabella offre una soluzione pratica anche per la diagnostica e la risoluzione dei problemi. Gli amministratori di sistema possono trovare istantaneamente nella tabella l'elenco corrente di silos attivi e vedere la cronologia di tutti i silos dichiarati inattivi e sospetti. Ciò è particolarmente utile per la diagnosi dei problemi.

6. Perché è necessaria una risorsa di archiviazione permanente affidabile per l'implementazione di IMembershipTable:

   L'archiviazione permanente viene usata per il IMembershipTable per due scopi. In primo luogo, viene usata come punto di incontro per consentire ai silos di trovarsi reciprocamente e ai client Orleans di trovare i silos. In secondo luogo, viene usata per coordinare l'accordo sulla visualizzazione delle appartenenze. Anche se il rilevamento degli errori viene eseguito direttamente in modalità peer-to-peer tra i silos, la visualizzazione delle appartenenze viene archiviata in una risorsa affidabile e per raggiungere un accordo sullo stato attivo o inattivo dei vari silos viene usato il meccanismo di controllo della concorrenza fornito da tale risorsa di archiviazione. In questo modo, in un certo senso, il protocollo esternalizza il difficile problema del consenso distribuito al cloud. Viene infatti sfruttata completamente la potenza della piattaforma cloud sottostante, usandola realmente come piattaforma distribuita come servizio (PaaS).

7. Scritture dirette di "I am alive" nella tabella solo a scopo di diagnostica:

   Oltre agli heartbeat inviati tra i silos, ogni silo aggiorna periodicamente una colonna "I Am Alive" nella riga della tabella. La colonna "I Am Alive" viene usata solo per la risoluzione dei problemi e la diagnostica manuali e non dal protocollo di appartenenza stesso. In genere le scritture in questa colonna vengono eseguite con una frequenza molto più bassa (ogni cinque minuti) e sono uno strumento molto utile che consente agli amministratori di sistema di controllare lo stato di attività del cluster o di scoprire facilmente quando il silo è stato attivo per l'ultima volta.

Riconoscimenti

Vorremmo riconoscere il contributo di Alex Kogan alla progettazione e all'implementazione della prima versione di questo protocollo. Questo lavoro è stato svolto nell'ambito di uno stage estivo presso la divisione Microsoft Research nell'estate del 2011. L'implementazione del IMembershipTable basato su ZooKeeper è stata eseguita da Shay Hazor, l'implementazione di SQL IMembershipTable è stata eseguita da Veikko Eeva, l'implementazione di AWS DynamoDB IMembershipTable è stata eseguita da Guteenberg Ribeiro e l'implementazione del IMembershipTable basato su Consul è stata eseguita da Paul Northe infine l'implementazione del IMembershipTable Apache Cassandra è stata adattata da OrleansCassandraUtils da Arshia001.