Da due a tre nodi senza ricostruire il cluster: la novità di AOS 7.6

Il cluster a due nodi è da sempre la risposta Nutanix alle sedi remote e alle installazioni dove tre nodi sono sovradimensionati: due host, una Witness VM in un dominio di fault separato, e buona parte della resilienza di un cluster a tre nodi. Il limite principale era la possibilità di espansione. Quando la sede remota diventava qualcosa di più, il percorso praticabile era spostare i workload, distruggere il cluster e ricrearlo a tre nodi.

Con AOS 7.6 e Prism Central 7.6 questo cambia. La feature si chiama Two-Node to Three-Node Cluster Expansion on AHV e consiste esattamente in quello che dice: un cluster AHV a due nodi si porta a tre aggiungendo un nodo, con il normale workflow di Expand Cluster.

Perché non era banale

Vale la pena ricordare come è fatto un cluster a due nodi, perché spiega sia il ritardo di questa funzionalità sia la forma dei prerequisiti.

Un cluster a due nodi mantiene replication factor 2 a livello di nodo per i dati e replication factor 4 per i metadati sugli SSD distribuiti sui due nodi. Le quattro copie dei metadati non sono uno spreco: servono a far transitare rapidamente il nodo sano in single-node mode quando l’altro cade, mantenendo i metadati disk fault tolerant. In quella modalità il replication factor 2 viene mantenuto a livello di disco anziché di nodo, e quando il nodo caduto rientra il sistema torna da solo allo stato precedente.

Questo meccanismo di funzionamento è il motivo per cui il due nodi ha bisogno di un arbitro esterno. La Witness VM assegna il lock di leadership quando i due nodi non si vedono più: un heartbeat ogni due secondi, failover dopo cinque tentativi falliti consecutivi, failback solo dopo quindici minuti di stato healthy. Aggiungere un terzo nodo significa smontare questo assetto mentre il cluster è in produzione, ed è il lavoro che AOS 7.6 ora fa per conto nostro.

Vincoli dichiarati

La documentazione è esplicita su quattro punti, e sono i punti che contano in fase di progetto:

• Solo AHV. “You can expand a two-node cluster to a three-node cluster only on AHV”. Per i cluster ESXi a due nodi l’espansione resta tra le feature non supportate.
• Solo nodi HCI. Il nodo aggiunto non può essere storage-only né compute-only. Nel tab Choose Node Type la scelta è obbligata.
• Un nodo per volta. Il passaggio è da due a tre, non da due a quattro.
• I single-node restano fuori. L’operazione di expand non è disponibile se il cluster ha meno di due nodi.

Prerequisiti operativi

Oltre ai controlli consueti prima di qualsiasi espansione — Health Dashboard pulita, NCC eseguito, nessuna operazione di expand in corso, tutti i nodi nel corretto stato di metadata store — ce n’è uno specifico del due nodi:

nutanix@cvm$ ncli cluster list-witness

Serve una Witness VM sana e il cluster registrato su di essa. Non è una formalità: nel due nodi tutti i workflow di manutenzione (upgrade, procedure LCM, break-fix di nodi e dischi) richiedono la registrazione con la Witness, e l’espansione non fa eccezione.

Secondo punto da verificare in anticipo: la discovery dei nuovi nodi richiede il passaggio di pacchetti multicast IPv6 attraverso lo switch fisico, ma i cluster a due nodi non supportano la configurazione IPv6. Si usa quindi Discover Hosts Manually, inserendo l’indirizzo IP della CVM del nuovo host. Gli indirizzi vanno preparati prima di aprire il wizard.

Cosa fa il processo

Il workflow è lo standard, da Prism Element (Hardware > + Expand Cluster) o da Prism Central. Due cose avvengono in automatico e conviene conoscerle:

Reimaging condizionale. Se AOS o hypervisor del nuovo nodo non coincidono con il cluster, il nodo viene reimmaginato prima di essere aggiunto. Se la versione AOS del nodo è superiore a quella del cluster, l’alternativa è aggiornare prima il cluster; altrimenti il nodo viene allineato al basso. L’imaging richiede tipicamente mezz’ora o più.

Allineamento della memoria CVM. Se la CVM del nuovo nodo ha meno memoria di quelle esistenti, il processo la porta allo stesso valore base, fino a un massimo di 32 GB. A espansione conclusa vale la pena far girare cvm_same_mem_level_check e cvm_memory_check.

Il wizard chiude con Run Checks e poi con Expand Cluster. Due dettagli di chiusura: l’espansione non è completa finché il nodo non è entrato nel metadata ring, e se il cluster ha più di uno storage pool la nuova capacità va assegnata a mano (con un solo pool l’assegnazione è automatica).

Cosa cambia dopo

Con il terzo nodo cadono i limiti architetturali del due nodi. Deduplica, erasure coding, NearSync e Metro Availability, network segmentation: sulla configurazione a due nodi sono tutte feature non supportate. Il dimensionamento cambia natura: nel due nodi la perdita di un nodo significa il 50% delle risorse, con la raccomandazione di non superare il 40% di utilizzo di disco e memoria per evitare lo stato read-only sul nodo superstite.

Il passaggio a tre nodi amplia le funzionalità disponibili e migliora le possibilità di crescita, ma non elimina i vincoli di resilienza propri delle configurazioni a tre nodi. È una condizione specifica dei cluster a tre nodi, che spariscono da quattro nodi in su.

In sintesi

Per ROBO, edge e installazioni di dimensioni contenute il valore è nel dimensionamento iniziale: partire con due nodi non è più una decisione irreversibile. Chi ha in gestione parchi di cluster due nodi su AHV ha ora un percorso di crescita documentato che non passa dalla ricostruzione.