Se prevede di utilizzare Amazon FSx for OpenZFS, è bene conoscere i Deployment Type e capire come funzionano dietro le quinte. Al momento sono supportati 3 tipi di deployment: Single-AZ (non-HA), Single-AZ (HA) e Multi-AZ (HA).
Quando configurerà un nuovo file system, si troverà davanti a due metodi di creazione: Quick Create e Standard Create. Il primo offre una procedura di setup semplificata, mentre Standard Create mette a disposizione opzioni di configurazione molto più complete.
In realtà Standard Create non è solo consigliato: è obbligatorio per due dei tre tipi di deployment. È quindi la scelta da preferire nella maggior parte delle implementazioni, perché garantisce un controllo decisamente più ampio sulla configurazione del file system fin dall'inizio.
Deployment Single-AZ (non-HA)
Per utilizzare Single-AZ (non-HA) deve seguire la procedura Standard Create, dato che questo tipo di deployment non è disponibile con Quick Create (vedi figura 1). Si ottiene un singolo file system e, in caso di guasto, dovrebbe ripristinarsi automaticamente sostituendo il componente infrastrutturale danneggiato; durante l'evento di failure, però, si verificherà un downtime con conseguente perdita di dati. In rari casi il file system potrebbe risultare irrecuperabile e tutti i dati non sottoposti a backup andranno persi.
Si ricordi di associare il security group corretto e di creare la regola appropriata per consentire il traffico (con Quick Create viene associato per impostazione predefinita il security group di default della VPC); questo vale per tutti i tipi di deployment.
Figura 1 — interfaccia di creazione FSx con Quick Create.
Deployment Single-AZ (HA)
Con Single-AZ (HA) può scegliere sia Quick Create sia Standard Create, ma è preferibile optare per quest'ultima perché consente di selezionare la subnet e il security group desiderati.
Questo tipo di deployment crea 2 file system all'interno della stessa subnet e genera anche un Endpoint IP address (lo approfondiremo più avanti, parlando del setup Multi-AZ). FSx utilizza l'Endpoint IP address per gestire gli eventi di failover in questa modalità. Il file system FSx ha un nome DNS che punta all'Endpoint IP address, il quale è collegato come indirizzo IP secondario all'ENI del file system attualmente attivo. Quando si verifica un failover, l'Endpoint IP address viene scollegato dall'ENI del file system attivo e collegato all'ENI del file system in standby. A questo punto il DNS continua a puntare allo stesso IP, che però è ora associato all'ENI di standby, fino al completo ripristino del file system principale.
Entrambi i deployment descritti consentono di montare il file system sulle istanze EC2 con una configurazione minima; con il Multi-AZ, invece, è richiesto un passaggio aggiuntivo.
Deployment Multi-AZ
Con il deployment Multi-AZ è fondamentale scegliere sempre Standard Create al posto di Quick Create, perché quest'ultimo non consente di selezionare le subnet né di associare le route table. L'associazione delle route table al file system FSx è infatti disponibile solo per il setup Multi-AZ.
Un setup Multi-AZ creato con Quick Create utilizzerà solo la route table di default per l'associazione, mentre le subnet quasi certamente ne usano di proprie. Perché è un punto cruciale? Perché impostando la configurazione in questo modo non avrà connettività di rete out of the box e la connessione andrà in timeout. È esattamente quanto è capitato a un mio cliente che aveva tentato di usare Quick Create, ed è proprio da lì che siamo partiti per approfondire e capire come funziona davvero.
Verrebbe da pensare che le risorse all'interno della stessa VPC si colleghino automaticamente al file system FSx attraverso la route 'local' — in fondo è così che si raggiungono altri servizi AWS come RDS, ElastiCache e le istanze EC2 nella propria VPC, e anche i file system FSx single-AZ sono accessibili in questo modo. C'è però un colpo di scena inatteso: in questo caso quell'assunto non regge. La sola route 'local' non basta a stabilire la connettività con il file system FSx in queste condizioni.
Come si abilita allora la connettività in questo scenario? La risposta breve è: deve associare al file system FSx le route table delle subnet in cui risiedono le sue istanze EC2. Per farlo, faccia clic su "manage" accanto a "route tables" e associ o dissoci le route table desiderate (vedi figura 2).
Figura 2 — modifica dell'associazione delle route table di FSx.
Una volta abilitata la connettività, noterà una voce relativa a un ENI nella route table (vedi figura 3). È proprio quella route ENI a permettere all'istanza di raggiungere il file system FSx. La voce è composta da un Endpoint IP address e dall'ENI del file system attualmente attivo.
Figura 3 — voce ENI all'interno delle route table associate.
Questa configurazione serve ad abilitare la procedura di failover. Come per Single-AZ (HA), si utilizza un Endpoint IP address; tuttavia quell'indirizzo IP non può essere spostato tra ENI che si trovano in AZ diverse. Inoltre, nel caso Single-AZ (HA) l'Endpoint IP Address viene creato all'interno di una subnet esistente, mentre nel deployment Multi-AZ ciò non avviene.
Setup Multi-AZ
Quando configura FSx in modalità Multi-AZ, vengono creati due file system separati in due subnet collocate in AZ diverse, così da garantire la ridondanza. Ogni file system dispone di una propria Elastic Network Interface (ENI). Durante il setup, FSx ha bisogno di uno speciale indirizzo IP (un IP "floating") da utilizzare in caso di failover. Si tratta di un singolo indirizzo (/32).
Può specificare lei stesso il range di IP tramite il parametro 'EndpointIpAddressRange', oppure lasciare che FSx scelga automaticamente un range CIDR /28 inutilizzato all'interno della VPC.
Un dettaglio importante su questo IP floating: pur rientrando nel range IP della VPC, viene volutamente collocato al di fuori dei range di qualsiasi subnet esistente. Ciò significa che, dal punto di vista del networking di Amazon EC2, questo indirizzo non è legato ad alcuna risorsa o subnet specifica.
I file system e le relative ENI restano comunque all'interno delle subnet, ma l'Endpoint IP address — l'IP floating — non rientra in nessun CIDR di subnet della VPC. La voce nella route table è quindi necessaria per instradare il traffico destinato all'IP floating verso l'ENI corretta del file system attualmente attivo. Senza quella route il traffico viene scartato, perché l'IP floating non fa parte di alcuna subnet (vedi figura 4).
Il motivo di questa configurazione è che FSx non esegue il failover basato su DNS, a causa dei limiti del client NFS in fase di failover. Le risoluzioni DNS avvengono una sola volta, al momento del mount. Per questo FSx deve adottare un meccanismo di failover diverso da quello solitamente utilizzato in altri servizi AWS Multi-AZ come, ad esempio, RDS; in caso contrario i client NFS dovrebbero rimontare il file system dopo ogni failover.
In sostanza, per ottenere un failover senza interruzioni tra il file system primario e quello in standby in modalità Multi-AZ, è necessaria la voce ENI nelle route table delle subnet in cui sono distribuiti i client. Durante un evento di failover, FSx aggiornerà tutte le Route Table del cliente associate, così che l'IP floating (Destination) rimanga invariato e il target diventi quello del file system in standby per tutta la durata del failover.
Figura 4 — Setup di FSx.
In sintesi
In questo articolo abbiamo analizzato l'implementazione di Amazon FSx for OpenZFS, le opzioni di creazione, il funzionamento del networking e i motivi per cui le implementazioni differiscono tra i vari deployment.
Domande su come far funzionare FSx for OpenZFS nella sua organizzazione?
Se si sta ancora chiedendo come applicare con successo il setup OpenZFS Multi-AZ — o qualsiasi altra soluzione infrastrutturale GCP o AWS — nella sua organizzazione, siamo qui per aiutarla.
In DoiT International il nostro team è composto esclusivamente da Engineers senior. Siamo specializzati in consulenza cloud avanzata, progettazione architetturale e servizi di debugging. Che stia pianificando i primi passi con i database distribuiti, ottimizzando un sistema esistente o affrontando problemi complessi, le offriamo una consulenza esperta e su misura.
Ci contatti oggi stesso: la aiuteremo a liberare tutto il potenziale della sua infrastruttura cloud.