Ciao, Habr!
Dopo le festività di Capodanno, abbiamo riavviato il cloud resistente ai disastri su due sedi. Oggi vi racconteremo come è strutturato e vi mostreremo cosa succede alle macchine virtuali dei clienti in caso di guasto di singoli elementi del cluster e di un'intera sede (spoiler: stanno tutti bene).
Sistemi di archiviazione del cloud resistente ai disastri presso la sede OST.
Cosa c'è dentro
Sotto il cofano del cluster ci sono server Cisco UCS con hypervisor VMware ESXi, due sistemi di archiviazione INFINIDAT InfiniBox F2240, apparecchiature di rete Cisco Nexus, oltre a switch SAN Brocade. Il cluster è distribuito su due sedi: OST e NORD, ovvero, in ogni data center c'è lo stesso set di hardware. Questo è ciò che lo rende resistente ai disastri.
All'interno di una sede, anche gli elementi principali sono duplicati (host, switch SAN, rete).
Le due sedi sono collegate tramite linee in fibra ottica dedicate, anch'esse riservate.
Due parole sui sistemi di archiviazione. La prima versione del cloud resistente ai disastri l'abbiamo costruita su NetApp. Qui abbiamo scelto INFINIDAT, ecco perché:
- Opzione di replica Active-Active. Consente alla macchina virtuale di rimanere operativa anche in caso di guasto totale di uno dei sistemi di archiviazione. Parlerò più dettagliatamente della replica in seguito.
- Tre controller disco per aumentare l'affidabilità del sistema. Di solito ce ne sono due.
- Soluzione pronta. Ci è arrivato un rack già assemblato, che deve semplicemente essere connesso alla rete e configurato.
- Supporto tecnico attento. Gli ingegneri di INFINIDAT analizzano costantemente i log e gli eventi dei sistemi di archiviazione, installano nuove versioni del firmware e aiutano nella configurazione.
Ecco alcune foto dello unpacking:
Come funziona
Il cloud è già resiliente al suo interno. Protegge il cliente da guasti hardware e software isolati. La resilienza ai disastri, invece, aiuta a proteggersi da guasti di massa all'interno di una singola sede: ad esempio, guasto del sistema di archiviazione (o del cluster SDS, che avviene abbastanza frequentemente 🙂), errori di massa nella rete di archiviazione e altro ancora. E la cosa più importante: un tale cloud salva quando un'intera sede diventa inaccessibile a causa di un incendio, blackout, attacco di pirati o invasione aliena.
In tutti questi casi, le macchine virtuali dei clienti continuano a funzionare, ecco perché.
Lo schema del cluster è strutturato in modo che qualsiasi host ESXi con macchine virtuali client possa accedere a uno qualsiasi dei due storage SAN. Se lo storage SAN nel sito OST si guasta, le macchine virtuali continueranno a funzionare: gli host su cui operano si collegheranno allo storage SAN su NORD per i dati.
Ecco come appare lo schema di connessione nel cluster.
Questo è possibile grazie al fatto che tra le SAN fabric dei due siti è stato configurato l'Inter-Switch Link: lo switch SAN Fabric A OST è collegato allo switch SAN Fabric A NORD, lo stesso vale per gli switch SAN Fabric B.
E affinché tutte queste complessità delle SAN fabric abbiano senso, tra i due storage SAN è stata configurata una replica Active-Active: le informazioni vengono registrate praticamente simultaneamente nello storage locale e in quello remoto, RPO=0. Dunque, su uno storage SAN si trova l'originale dei dati, mentre sull'altro si trova la loro replica. I dati vengono replicati a livello di volumi dello storage SAN, e su questi volumi sono memorizzati i dati delle VM (i suoi dischi, il file di configurazione, il file swap, ecc.).
L'host ESXi vede il volume principale e la sua replica come un'unica unità di storage (Storage Device). Ci sono 24 percorsi dall'host ESXi a ciascuna unità di storage:
12 percorsi collegano l'host allo storage SAN locale (percorsi ottimali), mentre gli altri 12 collegano a quello remoto (percorsi non ottimali). In condizioni normali, l'ESXi accede ai dati sullo storage SAN locale, utilizzando i percorsi "ottimali". In caso di guasto di questo storage, l'ESXi perde i percorsi ottimali e passa ai "percorsi non ottimali". Ecco come appare nello schema.
Schema del cluster a prova di disastro.
Tutte le reti client sono collegate a entrambi i siti attraverso un'unica fabric di rete. In ogni sito è attivo 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 un sito, tutto il traffico viene reindirizzato al secondo sito. Grazie a ciò, le macchine virtuali nel sito privo di PE rimangono accessibili in rete per il cliente.
Ora vediamo cosa accade alle macchine virtuali del cliente in caso di vari guasti. Iniziamo con le situazioni più leggere e concludiamo con la più seria: il guasto di tutto il sito. Negli esempi, il sito principale sarà OST e quello di riserva, 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 SAN dei due siti si interrompe.
ESXi funzionerà solo con dispositivi di archiviazione locali (attraverso percorsi ottimali).
Le macchine virtuali continuano a funzionare.
Si è verificata un'interruzione dell'ISL (Inter-Switch Link). Un evento raro. A meno che un escavatore impazzito non scavi in diversi percorsi ottici, che seguono rotte indipendenti e sono collegati alle piattaforme tramite ingressi diversi. Tuttavia, in questo caso, gli host ESXi perderanno metà dei percorsi e potranno accedere solo ai propri SAN locali. Le repliche vengono raccolte, ma gli host non potranno accedervi.
Le macchine virtuali funzionano correttamente.
Il commutatore SAN ha subito un guasto su una delle piattaforme. Gli host ESXi perdono parte dei percorsi verso il SAN. In questo caso, gli host sulla piattaforma dove si è verificato il guasto del commutatore funzioneranno solo tramite un proprio HBA.
Le macchine virtuali continuano a funzionare correttamente.
Tutti i commutatori SAN hanno subito un guasto su una delle piattaforme. Supponiamo che questo problema si sia verificato sulla piattaforma OST. In questo caso, gli host ESXi su questa piattaforma perderanno tutti i percorsi verso i propri dispositivi di archiviazione. Interviene il meccanismo standard di VMware vSphere HA: riavvierà tutte le macchine virtuali sulla piattaforma OST nel NORD entro un massimo di 140 secondi.
Le macchine virtuali funzionanti sugli host della piattaforma NORD funzionano correttamente.
Un host ESXi ha subito un guasto su una piattaforma. Qui entra nuovamente in gioco il meccanismo vSphere HA: le macchine virtuali dell'host guasto vengono riavviate su altri host – sulla stessa o su una piattaforma remota. Il tempo di riavvio della macchina virtuale è fino a 1 minuto.
Se tutti gli host ESXi della piattaforma OST subiscono un guasto, non ci sono alternative: le VM vengono riavviate su un'altra piattaforma. Il tempo di riavvio è lo stesso.
Un SAN ha subito un guasto su una piattaforma. Supponiamo che il SAN sulla piattaforma OST abbia subito un guasto. In tal caso, gli host ESXi della piattaforma OST passeranno a lavorare con le repliche del SAN nel NORD. Dopo il ripristino del SAN guasto, avverrà una replica forzata e gli host ESXi OST riprenderanno a contattare il SAN locale.
Le macchine virtuali funzionano correttamente durante tutto questo tempo.
Una delle piattaforme ha subito un guasto. In questo caso, tutte le macchine virtuali verranno riavviate sulla piattaforma di riserva tramite il meccanismo vSphere HA. Il tempo di riavvio della VM è di 140 secondi. Nel frattempo, tutte le impostazioni di rete della macchina virtuale verranno salvate e rimarrà accessibile per il cliente attraverso la rete.
Affinché il riavvio delle macchine nel sito di emergenza avvenga senza problemi, ogni sito è riempito solo a metà. La seconda metà è una riserva nel caso di trasferimento di tutte le macchine virtuali dal secondo sito, quello danneggiato.
È questa la protezione contro tali guasti che offre un cloud altamente resiliente basato su due data center.
Questo piacere non è economico, poiché oltre alle risorse principali, è necessaria una riserva nel secondo sito. Pertanto, vengono ospitati in questo tipo di cloud i servizi critici per il business, il cui lungo fermo comporterebbe ingenti perdite finanziarie e di reputazione, o se il sistema informativo è soggetto a requisiti di resilienza da parte dei regolatori o delle normative interne dell’azienda.
Fonti:
Fonte: habr.com
