Ciao, Habr!
Dopo le festività di Capodanno abbiamo riavviato il cloud ad alta disponibilità basato su due sedi. Oggi vi spiegheremo come è strutturato e mostreremo cosa succede alle macchine virtuali dei clienti in caso di guasti di singoli componenti del cluster e caduta di un'intera sede (spoiler: stanno bene).
Storage del cloud ad alta disponibilità presso la sede OST.
Cosa c'è dentro
Sotto il cofano del cluster troviamo server Cisco UCS con hypervisor VMware ESXi, due storage INFINIDAT InfiniBox F2240, apparecchiature di rete Cisco Nexus, e switch SAN Brocade. Il cluster è suddiviso in due sedi – OST e NORD, ovvero in ogni data center c'è una configurazione identica. Questo è ciò che lo rende ad alta disponibilità.
All'interno di una sede, anche i componenti principali sono duplicati (host, switch SAN, rete).
Le due sedi sono collegate tramite linee in fibra ottica dedicate, anch'esse ridondanti.
Qualche parola sullo storage. La prima versione del cloud ad alta disponibilità era costruita su NetApp. Qui abbiamo scelto INFINIDAT, ecco perché:
- L'opzione di replica Active-Active. Consente alla macchina virtuale di rimanere operativa anche in caso di guasto totale di uno degli storage. Vi parlerò più dettagliatamente della replica più avanti.
- Tre controller di disco per aumentare l'affidabilità del sistema. Di solito ce ne sono due.
- Soluzione pronta all'uso. Ci è arrivato un rack già assemblato, da collegare semplicemente alla rete e configurare.
- Assistenza tecnica attenta. Gli ingegneri di INFINIDAT analizzano costantemente i log e gli eventi degli storage, installano nuove versioni del firmware e aiutano nella configurazione.
Ecco alcune foto dello unpacking:
Come funziona
Il cloud è già altamente disponibile internamente. Protegge il cliente da guasti hardware e software singoli. L'alta disponibilità, d'altra parte, aiuta a difendersi da guasti massivi all'interno di una singola sede: ad esempio, il guasto di uno storage (o di un cluster SDS, cosa che accade spesso 🙂), errori massivi nella rete di storage, e altro. E la cosa più importante: questo tipo di cloud è salvavita quando un'intera sede diventa inaccessibile a causa di incendi, blackout, attacchi raiders o invasioni aliene.
In tutti questi casi, le macchine virtuali dei clienti continuano a lavorare, ecco perché.
Lo schema del cluster è progettato in modo tale che qualsiasi host ESXi con macchine virtuali dei clienti possa accedere a uno qualsiasi dei due storage. Se lo storage nella sede OST si guasta, le macchine virtuali continueranno a funzionare: gli host su cui operano chiederanno dati allo storage nella sede NORD.
Ecco come appare lo schema di connessione nel cluster.
Questo è possibile grazie al fatto che tra le fabric SAN delle due sedi è configurato l'Inter-Switch Link: lo switch SAN Fabric A OST è collegato allo switch SAN Fabric A NORD, e lo stesso per gli switch SAN Fabric B.
E per rendere sensate tutte queste complesse interconnessioni delle fabric SAN, tra i due storage è configurata la replica Active-Active: l'informazione viene scritta quasi simultaneamente sullo storage locale e su quello remoto, RPO=0. Questo significa che su uno storage è conservata l'originale dei dati, sull'altro la sua replica. I dati vengono replicati a livello di volumi dello storage, e su di essi sono memorizzati i dati delle VM (i loro dischi, il file di configurazione, il file di swap, ecc.).
L'host ESXi vede il volume principale e la sua replica come un'unica unità di memorizzazione (Storage Device). Da ciascun host ESXi partono 24 percorsi verso ciascuna unità di memorizzazione:
12 percorsi collegano l'unità allo storage locale (percorsi ottimali), mentre i restanti 12 allo storage remoto (percorsi non ottimali). In condizioni normali, ESXi accede ai dati sullo storage locale utilizzando i “percorsi ottimali”. In caso di guasto di questo storage, ESXi perde i percorsi ottimali e commuta sui “percorsi non ottimali”. Ecco come appare nello schema.
Schema del cluster ad alta disponibilità.
Tutte le reti dei clienti sono collegate a entrambe le sedi tramite una fabric di rete comune. In ogni sede è presente un Provider Edge (PE), dove terminano le reti dei clienti. I PE sono uniti in un cluster comune. In caso di guasto di un PE in una sede, tutto il traffico viene instradato verso la seconda sede. Grazie a ciò, le macchine virtuali della sede rimasta senza PE rimangono accessibili in rete per il cliente.
Ora vediamo cosa succede alle macchine virtuali dei clienti in caso di vari guasti. Iniziamo con le opzioni più leggere e finiamo con la più seria: il guasto dell'intera sede. Nei seguenti esempi, la sede principale sarà OST e quella secondaria, con le repliche dei dati, sarà NORD.
Cosa succede alla macchina virtuale del cliente se…
Si guasta il Replication Link. La replica tra gli storage delle due sedi viene interrotta.
ESXi lavorerà solo con le unità locali (attraverso i percorsi ottimali).
Le macchine virtuali continuano a funzionare.
Si verifica un'interruzione dell'ISL (Inter-Switch Link). Un caso poco probabile. A meno che un qualche escavatore pazzo non scavi contemporaneamente diverse linee ottiche che passano su percorsi indipendenti e portano agli impianti tramite ingressi diversi. Ma comunque. In questo caso, gli host ESXi perderanno metà dei percorsi e potranno accedere solo ai propri storage locali. Le repliche vengono create, ma gli host non possono accedervi.
Le macchine virtuali funzionano normalmente.
Guasto dello switch SAN in uno degli impianti. Gli host ESXi perdono parte dei percorsi verso lo storage. In questo caso, gli host nell'impianto dove è guasto lo switch funzioneranno solo tramite il proprio HBA.
Le macchine virtuali continuano a funzionare normalmente.
Guasto di tutti gli switch SAN in uno degli impianti. Supponiamo che un evento del genere si verifichi nell'impianto OST. In questo caso, gli host ESXi in questo impianto perderanno tutti i percorsi verso i propri dispositivi di archiviazione. Interviene il meccanismo standard di VMware vSphere HA: riavvierà tutte le macchine virtuali dell'impianto OST nel NORD al massimo entro 140 secondi.
Le macchine virtuali che funzionano sugli host dell'impianto NORD funzionano normalmente.
Guasto dell'host ESXi in uno degli impianti. Qui entra di nuovo in gioco il meccanismo vSphere HA: le macchine virtuali dall'host guasto vengono riavviate su altri host - nello stesso impianto o in un impianto remoto. Il tempo di riavvio della macchina virtuale è fino a 1 minuto.
Se tutti gli host ESXi dell'impianto OST sono guasti, non ci sono alternative: le VM vengono riavviate in un altro. Il tempo di riavvio rimane invariato.
Guasto dello storage in uno degli impianti. Supponiamo che lo storage abbia guastato nell'impianto OST. Gli host ESXi dell'impianto OST quindi si switchano per lavorare con le repliche dello storage nel NORD. Dopo che lo storage guasto è tornato in funzione, verrà forzata una replica, e gli host OST inizieranno di nuovo ad accedere allo storage locale.
Le macchine virtuali funzionano normalmente durante tutto questo.
Guasto di uno degli impianti. In questo caso, tutte le macchine virtuali verranno riavviate nel sito di riserva tramite il meccanismo vSphere HA. Il tempo di riavvio delle VM è di 140 secondi. Inoltre, tutte le impostazioni di rete della macchina virtuale verranno conservate, e rimarrà accessibile al cliente attraverso la rete.
Per garantire un riavvio senza problemi delle macchine nel sito di riserva, ciascun impianto è riempito solo a metà. La seconda metà è una riserva nel caso in cui tutte le macchine virtuali vengano spostate dall'altro, impianto colpito.
Questo è ciò da cui protegge il cloud a prova di disastro basato su due data center.
Questo piacere non è economico, poiché, oltre alle risorse principali, è necessaria una riserva nel secondo impianto. Pertanto, vengono ospitati in questo cloud servizi critici per il business, il cui lungo inattività comporta grandi perdite finanziarie e reputazionali, oppure se il sistema informativo è soggetto a requisiti di resilienza ai disastri da parte dei regolatori o dei regolamenti interni dell'azienda.
Fonti:
Fonte: habr.com
