Transizione tra il servizio stateful e la persistenza esterna in Azure Service Fabric

Question

Il Fabric Service di Azure sembra focalizzato su scenari in cui tutti i dati possono essere contenuti nella RAM e la persistenza viene utilizzata come backing store. I servizi affidabili sono progettati per archiviare le informazioni in Raccolte affidabili, che utilizzano uno log-checkpoint system in cui le informazioni registrate vengono scritte nella RAM. Nel frattempo, per Reliable Actors, lo default actor state provider è "l'archivio di valori-chiave distribuiti fornito dalla piattaforma di Service Fabric". Ciò sembra indicare che si applicherebbero le stesse limitazioni.

Potrebbero tuttavia esserci situazioni in cui si vorrebbe utilizzare il Service Fabric per "hot data" ma scrivere "cold data" su una qualche forma di memorizzazione permanente. Quali sono le migliori pratiche per gestire questa transizione?

In Orleans, questo sembra essere gestito automaticamente, utilizzando un archivio di persistenza come le tabelle di Azure. Ma sembra che uno degli scopi principali del design del Service Fabric e delle Affidabili Collezioni sia quello di evitare di richiedere servizi esterni, migliorando così la localizzazione dei dati. L'attuale documentazione anticipa la possibilità che uno vorrebbe spostare i dati in qualche archivio permanente per disaster recovery and analytics, ma non discute la possibilità di spostare i dati avanti e indietro tra gli attori in memoria persistenti e più forme di archiviazione permanenti.

Una possibile risposta è che Service Fabric lo faccia già. Forse un dizionario affidabile ha un meccanismo integrato per il passaggio tra archiviazione in memoria persistente e memoria permanente.

Oppure, forse la risposta è che si deve gestire questo. Un approccio potrebbe essere per un attore tenere traccia di quanto è "caldo" e cambiare il suo archivio di persistenza se necessario. Ma questo sacrifica uno dei vantaggi del modello di attore, l'assegnazione automatica e la deallocazione degli attori. Allo stesso modo, potremmo rimuovere periodicamente gli elementi dal Dizionario affidabile e aggiungerli a un altro archivio di persistenza, quindi aggiungerli nuovamente. Di nuovo, tuttavia, ciò richiede la conoscenza di quando ha senso effettuare la transizione.

Un paio di esempi possono aiutare a cristallizzare questo: "camere"

(1) Supponiamo che stiamo attuando un gioco multiplayer con molte differenti Non abbiamo bisogno di tutte le stanze nella memoria in una volta, ma dobbiamo spostarle in memoria e usare la persistenza locale come backup una volta che i giocatori si uniscono a loro.

(2) Supponiamo che stiamo implementando un B-Tree append-only come parte di un database. La tentazione sarebbe quella di fare in modo che ogni nodo B-Tree sia un attore di stato. Vorremmo che gli hot b fossero conservati in memoria, ma ovviamente l'intero indice non può essere in memoria. Sembra che questo sia uno scenario principale che è già implementato per cose come DocumentDB, ma non mi è chiaro dalla documentazione come si farebbe questo.

Una domanda correlata che ho trovato è here. Ma quella domanda si concentra su quando utilizzare Azure Service Fabric rispetto ai servizi esterni. La mia domanda è se c'è bisogno di transitare tra di loro o se Azure Service Fabric ha già tutte le capacità necessarie qui.

Answer 1

Il provider dello stato del negozio di valori-chiave fa non richiede che tutto sia tenuto in memoria. Questo provider memorizza effettivamente lo stato di tutti gli attori sul disco locale e lo stato viene anche replicato sul disco locale su altri nodi. Quindi lo store KVS è considerato un negozio persistente e affidabile.

In aggiunta a ciò, lo stato di attivo attori viene anche memorizzato. Quando un attore non è stato utilizzato per un po ', viene disattivato e eliminato. Quando ciò accade, la copia in memoria viene liberata e rimane solo la copia sul disco. Quando l'attore viene nuovamente attivato, lo stato viene recuperato dal disco e rimane in memoria finché l'attore è attivo.

Inoltre, KVS non è l'unico provider di stato integrato. Abbiamo anche VolatileActorStateProvider (http://azure.microsoft.com/en-gb/documentation/articles/service-fabric-reliable-actors-platform/#actor-state-provider-choices). Questo è il fornitore dello stato che tiene tutto in memoria.

Answer 2

Il KvsActorStateProvider memorizza effettivamente lo stato degli attori in un KeyValueStore che è una struttura simile a ReliableDictionary.

La prima domanda che vorrei porre è se sia necessario relegare lo stato dei vecchi attori in un ambiente freddo? La limitazione di tenere tutto in memoria non ti limita a un numero totale di attori, ma a un numero totale per replica. Quindi, per prima cosa devi considerare la strategia di partizionamento in modo che i tuoi attori siano distribuiti su un numero di repliche differenti.A mano a mano che le tue richieste crescono, puoi aggiungere più macchine al cluster e ServiceFabric orchestrerà i movimenti delle repliche alle nuove macchine. Per ulteriori informazioni sul partizionamento del servizio Actor, vedere http://azure.microsoft.com/en-gb/documentation/articles/service-fabric-reliable-actors-platform/

Se si desidera utilizzare la conservazione a freddo dopo un po 'di tempo, allora si hanno un paio di opzioni. In primo luogo, puoi decorare i tuoi attori con un numero personalizzato ActorStateProviderAttribute che restituisce la tua implementazione di un IActorStateProvider che può gestire la persistenza come tu decidi.

In alternativa, è possibile gestirlo interamente all'interno dell'implementazione dell'attore. Collegarsi a Actor Lifecycle e in OnDeactivateAsync in modo tale che quando l'istanza viene raccolta inutilmente o utilizzare uno Actor Reminder per un certo periodo di tempo specificato, per serializzare lo stato e archiviarlo in una cella frigorifera come blob o storage di tabella e annullare la proprietà State. L'override di ActivateAsync può quindi essere utilizzato per recuperare questo stato dall'archiviazione offline e dalla deserializzazione.