Implementazione della directory granulare

Panoramica e architettura

La directory granulare in Orleans è un archivio chiave-valore in cui la chiave è un identificatore di granularità e il valore è una voce di registrazione che punta a un silo attivo che (potenzialmente) ospita la granularità.

Mentre Orleans fornisce un'implementazione predefinita della directory distribuita in memoria (descritta in questo articolo), il sistema di directory granulare è progettato per essere collegabile. È possibile implementare la propria directory implementando l'interfaccia IGrainDirectory e registrandola con la raccolta di servizi del silo. Ciò consente implementazioni di directory personalizzate che potrebbero usare diversi back-end di archiviazione o modelli di coerenza per soddisfare meglio requisiti specifici dell'applicazione. Dall'introduzione della nuova directory di coerenza assoluta, c'è meno bisogno di implementazioni di directory esterne, ma l'API rimane ancora disponibile per compatibilità con le versioni precedenti e flessibilità. È possibile configurare la directory di grano su base per tipo di grano.

Per ottimizzare le prestazioni, Orleans memorizza nella cache le ricerche di directory in locale all'interno di ogni silo. Ciò significa che le letture di directory potenzialmente remote sono necessarie solo quando la voce della cache locale è mancante o non valida. Questo meccanismo di memorizzazione nella cache riduce il sovraccarico di rete e la latenza associati alle ricerche di percorsi granulari.

Originariamente, Orleans ha implementato una directory strutturata come una tabella hash distribuita ed eventualmente coerente. Questa operazione è stata sostituita da una directory fortemente coerente nella Orleans versione 9.0, in base alla metodologia virtualmente sincrona in due fasi. È anche strutturato come tabella hash distribuita, ma offre un bilanciamento del carico migliorato tramite nodi virtuali. Questo articolo descrive l'implementazione di quest'ultima directory granulare più recente.

Directory granulare distribuita

La directory granulare distribuita in Orleans offre coerenza assoluta, anche bilanciamento del carico, prestazioni elevate e tolleranza di errore. L'implementazione segue una progettazione in due fasi basata sulla metodologia di sincronizzazione virtuale con analogie con Vertical Paxos.

Le partizioni di directory hanno due modalità di funzionamento:

1. Operazione normale: le partizioni elaborano le richieste in locale senza coordinamento con altri host.
2. Modifica visualizzazione: gli host si coordinano tra loro per trasferire la proprietà degli intervalli di directory.

La directory sfrutta Orleanssistema di appartenenza al cluster di coerenza assoluta, in cui le configurazioni denominate "visualizzazioni" hanno numeri di versione che aumentano in modo monotonico. Man mano che i silos si uniscono e lasciano il cluster, vengono create visualizzazioni successive, con conseguente modifica della proprietà del range.

Tutte le operazioni di directory includono il coordinamento delle visualizzazioni:

• Le richieste contengono il numero di visualizzazione del chiamante.
• Le risposte includono il numero di visualizzazione della partizione.
• Le discrepanze nei numeri attivano la sincronizzazione.
• Le richieste vengono ripetute automaticamente al cambiamento della visualizzazione.

In questo modo il proprietario corretto della partizione di directory elabora tutte le richieste.

Strategia di partizionamento

La directory viene partizionata usando un anello hash coerente, con intervalli assegnati ai silo attivi nel cluster. Gli identificatori di nodo vengono sottoposti a hashing per trovare il silo proprietario della sezione dell'anello corrispondente al proprio hash.

Ogni silo attivo possiede un numero preconfigurato di intervalli, generalmente pari a 30 intervalli per silo. Questo è simile allo schema usato da Amazon Dynamo e Apache Cassandra, in cui vengono creati più "nodi virtuali" (intervalli) per ogni nodo fisico (host).

La dimensione di una partizione è determinata dalla distanza tra il relativo hash e l'hash della partizione successiva. È possibile suddividere un intervallo tra più silo durante una modifica della visualizzazione. Ciò aggiunge complessità alla routine di modifica della vista, perché ogni partizione deve potenzialmente coordinarsi con più altre partizioni.

Visualizzare la procedura di modifica

Le partizioni di directory (implementate in GrainDirectoryPartition) utilizzano blocchi di intervallo versionati per impedire l'accesso non valido agli intervalli durante le modifiche della vista. I blocchi di intervallo vengono creati durante una modifica della visualizzazione e rilasciati al termine della modifica della visualizzazione. Questi blocchi sono analoghi ai "cunei" usati nella metodologia di sincronizzazione virtuale.

Quando si verifica una modifica di visualizzazione, una partizione può aumentare o ridurre:

• Se un nuovo silo si unisce al cluster, le partizioni esistenti potrebbero ridursi per fare spazio.
• Se un silo lascia il cluster, le partizioni rimanenti potrebbero espandersi per coprire gli intervalli orfani.

Le registrazioni della directory devono essere trasferite dal vecchio proprietario al nuovo proprietario prima che le richieste possano essere gestite. Il processo di trasferimento segue questa procedura:

1. Il proprietario precedente sigilla l'intervallo e crea uno snapshot delle relative voci di directory.
2. Il nuovo proprietario richiede e applica lo snapshot.
3. Il nuovo proprietario inizia a gestire le richieste per la gamma.
4. Il proprietario precedente riceve una notifica ed elimina lo snapshot.

Processo di ripristino

Quando un host si arresta in modo anomalo senza distribuire correttamente le partizioni di directory, i proprietari di partizioni successivi devono eseguire il ripristino. Ciò comporta:

1. Esecuzione di query su tutti i silo attivi nel cluster per individuare le registrazioni granulari.
2. Ricostruire lo stato della directory per gli intervalli interessati.
3. Garantire che non si verifichino attivazioni granulari duplicate.

Il ripristino è necessario anche quando l'appartenenza al cluster cambia rapidamente. Anche se l'appartenenza al cluster garantisce la monotonicità, i silo possono perdere le visualizzazioni di appartenenza intermedie. In questi casi:

• I trasferimenti di snapshot vengono abbandonati.
• Il ripristino viene eseguito anziché il normale trasferimento da partizione a partizione.
• Il sistema mantiene la coerenza nonostante gli stati intermedi mancanti.

Un miglioramento futuro dell'appartenenza al cluster potrebbe ridurre o eliminare questi scenari assicurandosi che tutti i silo visualizzino tutte le visualizzazioni.