Perché un cluster a due nodi è la scelta peggiore: la questione della maggioranza

Hai comprato il secondo server e montato un cluster. Ti senti più tranquillo: adesso ci sono due macchine, e se una cade l’altra continua.

Non continua. Un cluster a due nodi è più fragile di un nodo singolo, e il giorno in cui lo scopri di solito è una brutta giornata.

Perché

Le decisioni di un cluster si prendono a maggioranza. Se due nodi su tre sono in piedi c’è la maggioranza e il cluster continua a funzionare. Se cade uno dei due nodi, l’unico nodo rimasto non è una maggioranza, quindi il cluster si blocca da solo: le macchine continuano a girare, ma la configurazione non si può cambiare, non si avvia nessuna macchina nuova e gran parte del lavoro di amministrazione si ferma.

Non è un difetto, è una scelta voluta. L’alternativa è molto peggiore: quando due nodi non si vedono più, entrambi dicono "io sono in piedi, l’altro è caduto" e avviano la stessa macchina virtuale in due posti. Sullo stesso disco si scrive da due lati e i dati si rovinano senza ritorno.

Il cluster quindi ti protegge bloccandoti. Ma con due nodi questa protezione scatta in metà dei guasti.

Il numero giusto è tre

In un cluster a tre nodi, se uno cade ne restano due, la maggioranza regge e la vita continua. Per questo il numero tre compare ovunque nella documentazione dei cluster.

La terza macchina non deve essere potente. Vota soltanto, non deve eseguire lavoro. Una macchina piccola, perfino un vecchio computer, fa il suo dovere.

Se davvero non vuoi una terza macchina, si può montare al suo posto un piccolo nodo testimone che esiste solo per votare. Non è un nodo completo e non ci puoi far girare macchine, ma completa il conto della maggioranza a tre. Se resti a due nodi, monta almeno questo.

Se resti a due nodi, sappi che

Quando un nodo viene messo in manutenzione, anche il nodo rimasto diventa ingestibile. Quindi persino un aggiornamento pianificato ti lascia bloccato.

È possibile dire a mano "decida pure anche un nodo solo", ma questo riapre esattamente il rischio del doppio avvio descritto sopra. Si fa in modo temporaneo, consapevole e breve; non è una soluzione permanente.

Montare un cluster non è fare backup

Sono le due cose che si confondono più spesso. Un cluster serve alla disponibilità: perché il lavoro continui quando una macchina cade. Un backup serve al recupero: per tornare indietro dopo che i dati si sono corrotti o sono stati cancellati per sbaglio.

Un cluster non riporta indietro una macchina virtuale cancellata per errore. La cancellazione si propaga subito a tutti i nodi, perché un cluster esiste proprio perché vedano la stessa cosa. Anche con un cluster, i backup ti serviranno.

Che cosa fa Atlas

Atlas tratta il cluster non come un concetto ma come uno stato: quanti nodi ci sono, quanti votano, se la maggioranza regge in questo momento.

Dove aiuta di più è l’aggiornamento. Prima che un nodo venga aggiornato, Atlas guarda quante delle macchine su di esso possono spostarsi su un altro nodo e ti propone un ordine. La proposta resta una proposta: il comando di spostamento non parte da solo, il pulsante lo premi tu.

Un dettaglio conta in modo particolare qui, e tocca direttamente il tema di questo articolo. Il comando che chiede lo stato del cluster fallisce allo stesso modo in due situazioni diverse: essere davvero una macchina isolata, ed essere membro di un cluster il cui strato di cluster è crollato. Se le due cose non si distinguono, il prodotto dice "nessun cluster, maggioranza a posto" proprio nel momento in cui il cluster è crollato. Cioè costruisce la frase più rassicurante nell’istante più pericoloso.

Atlas le distingue guardando se il file di configurazione esiste: quel file viene scritto insieme all’adesione e resta al suo posto anche quando lo strato di cluster crolla. La distinzione sta in un solo punto, perché prima era scritta separatamente in tre punti diversi e tutti e tre avevano lo stesso errore.