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. Gli sviluppatori possono 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. Poiché con l'introduzione della nuova directory di coerenza assoluta, non sono quasi più necessarie le implementazioni di directory esterne, l'API rimane per garantire compatibilità e flessibilità con le versioni precedenti. La directory dei grani può essere configurata in base al tipo di grano.

Per ottimizzare le prestazioni, le ricerche di directory vengono memorizzate nella cache localmente 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. Questo è stato sostituito da una directory fortemente coerente in Orleans v9.0, basata sulla metodologia a due fasi Virtually Synchronous e strutturata come una tabella hash distribuita, ma con un bilanciamento del carico migliorato grazie all'uso di 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. Visualizza modifica: gli host si coordinano tra loro per trasferire la proprietà dei range 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 ritentate automaticamente in caso di modifiche alla visualizzazione.

In questo modo si garantisce che tutte le richieste vengano elaborate dal proprietario corretto della partizione di directory.

Strategia di partizionamento

La directory viene suddivisa usando un anello hash uniforme, con intervalli assegnati ai silos attivi nel cluster. Gli identificatori dei granelli vengono sottoposti a hashing per trovare il silo che possiede la sezione dell'anello corrispondente al suo 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 (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, che aggiunge complessità alla routine di modifica della visualizzazione, 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 la modifica della visualizzazione e vengono 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 è stato aggiunto al cluster, le partizioni esistenti potrebbero ridursi per fare spazio.
• Se un silo ha lasciato il cluster, le partizioni rimanenti potrebbero espandersi per prendere il controllo degli 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 invece del normale passaggio da partizione a partizione.
• Il sistema mantiene la coerenza nonostante gli stati intermedi mancanti.

Un miglioramento futuro dell'appartenenza al cluster può ridurre o eliminare questi scenari garantendo che tutti i silos possano visualizzare tutte le prospettive.