Ehi Habr!
Dopo le vacanze di Capodanno abbiamo rilanciato un cloud a prova di disastro basato su due siti. Oggi vi diremo come funziona e vi mostreremo cosa succede alle macchine virtuali client quando i singoli elementi del cluster falliscono e l'intero sito si blocca (spoiler: con loro va tutto bene).
Sistema di archiviazione cloud resistente ai disastri sul sito OST.
Cosa c'è dentro
Sotto il cofano, il cluster dispone di server Cisco UCS con un hypervisor VMware ESXi, due sistemi di storage INFINIDAT InfiniBox F2240, apparecchiature di rete Cisco Nexus e switch Brocade SAN. Il cluster è diviso in due siti: OST e NORD, ovvero ogni data center ha un set identico di apparecchiature. In realtà, questo è ciò che lo rende a prova di disastro.
All'interno di un sito vengono duplicati anche gli elementi principali (host, switch SAN, rete).
Le due sedi sono collegate da percorsi in fibra ottica dedicati, anch'essi riservati.
Qualche parola sui sistemi di storage. Abbiamo creato la prima versione di un cloud a prova di disastro su NetApp. Qui abbiamo scelto INFINIDAT, ed ecco perché:
- Opzione di replica attivo-attivo. Consente alla macchina virtuale di rimanere operativa anche se uno dei sistemi di storage si guasta completamente. Ti dirò di più sulla replica più tardi.
- Tre controller del disco per aumentare la tolleranza agli errori del sistema. Di solito ce ne sono due.
- Soluzione pronta. Abbiamo ricevuto un rack preassemblato che deve solo essere collegato alla rete e configurato.
- Supporto tecnico attento. Gli ingegneri INFINIDAT analizzano costantemente i registri e gli eventi del sistema di archiviazione, installano nuove versioni del firmware e aiutano nella configurazione.
Ecco alcune foto del disimballaggio:
Come funziona
Il cloud è già tollerante ai guasti al suo interno. Protegge il client da singoli guasti hardware e software. La resistenza ai disastri aiuterà a proteggersi da guasti massicci all'interno di un sito: ad esempio, guasto di un sistema di archiviazione (o di un cluster SDS, che accade abbastanza spesso 🙂), errori massicci in una rete di archiviazione, ecc. Bene, e la cosa più importante: un cloud di questo tipo salva quando un intero sito diventa inaccessibile a causa di un incendio, blackout, presa del controllo di un predone o atterraggio alieno.
In tutti questi casi, le macchine virtuali client continuano a funzionare ed ecco perché.
Il design del cluster è progettato in modo che qualsiasi host ESXi con macchine virtuali client possa accedere a uno qualsiasi dei due sistemi di storage. Se il sistema di storage sul sito OST fallisce, le macchine virtuali continueranno a funzionare: gli host su cui sono in esecuzione accederanno al sistema di storage su NORD per i dati.
Ecco come appare lo schema di connessione in un cluster.
Ciò è possibile grazie al fatto che tra i fabric SAN dei due siti è configurato un Inter-Switch Link: lo switch SAN OST del Fabric A è connesso allo switch SAN NORD del Fabric A, e analogamente per gli switch SAN del Fabric B.
Bene, affinché tutte queste complessità delle fabbriche SAN abbiano un senso, viene configurata la replica Active-Active tra i due sistemi di storage: le informazioni vengono scritte quasi contemporaneamente sui sistemi di storage locale e remoto, RPO = 0. Si scopre che i dati originali sono archiviati su un sistema di archiviazione e la relativa replica è archiviata sull'altro. I dati vengono replicati a livello di volumi di archiviazione e i dati della VM (i suoi dischi, file di configurazione, file di scambio, ecc.) vengono archiviati su di essi.
L'host ESXi vede il volume primario e la sua replica come un unico dispositivo disco (dispositivo di storage). Esistono 24 percorsi dall'host ESXi a ciascun dispositivo disco:
12 percorsi lo collegano al sistema di storage locale (percorsi ottimali), ed i restanti 12 al sistema di storage remoto (percorsi non ottimali). In una situazione normale, ESXi accede ai dati sul sistema di storage locale utilizzando percorsi “ottimali”. Quando questo sistema di storage fallisce, ESXi perde i percorsi ottimali e passa a quelli “non ottimali”. Questo è quello che appare sul diagramma.
Schema di un cluster a prova di disastro.
Tutte le reti client sono connesse a entrambi i siti tramite una struttura di rete comune. Ogni sito esegue un Provider Edge (PE), sul quale vengono terminate le reti del cliente. I PE sono uniti in un cluster comune. Se un PE fallisce in un sito, tutto il traffico viene reindirizzato al secondo sito. Grazie a ciò le macchine virtuali della sede rimasta senza PE rimangono accessibili al client in rete.
Vediamo ora cosa accadrà alle macchine virtuali client durante i vari guasti. Iniziamo con le opzioni più leggere e terminiamo con la più grave: il fallimento dell'intero sito. Negli esempi, la piattaforma principale sarà OST e la piattaforma di backup, con le repliche dei dati, sarà NORD.
Cosa succede alla macchina virtuale client se...
Il collegamento di replica non riesce. La replica tra i sistemi di storage dei due siti si interrompe.
ESXi funzionerà solo con dispositivi disco locali (tramite percorsi ottimali).
Le macchine virtuali continuano a funzionare.
L'ISL (Inter-Switch Link) si rompe. Il caso è improbabile. A meno che qualche escavatore pazzo non scavi più percorsi ottici contemporaneamente, che corrono su percorsi indipendenti e vengono portati ai siti attraverso ingressi diversi. Ma in ogni caso. In questo caso, gli host ESXi perdono metà dei percorsi e possono accedere solo ai propri sistemi di storage locali. Vengono raccolte le repliche, ma gli host non saranno in grado di accedervi.
Le macchine virtuali funzionano normalmente.
Lo switch SAN non funziona su uno dei siti. Gli host ESXi perdono alcuni percorsi verso il sistema di storage. In questo caso, gli host del sito in cui lo switch non è riuscito funzioneranno solo tramite uno dei rispettivi HBA.
Le macchine virtuali continuano a funzionare normalmente.
Tutti gli switch SAN su uno dei siti falliscono. Diciamo che un simile disastro è accaduto sul sito OST. In questo caso, gli host ESXi su questo sito perderanno tutti i percorsi verso i propri dispositivi disco. Entra in gioco il meccanismo standard VMware vSphere HA: riavvierà tutte le macchine virtuali del sito OST in NORD in un massimo di 140 secondi.
Le macchine virtuali in esecuzione sugli host dei siti NORD funzionano normalmente.
L'host ESXi si guasta su un sito. Qui il meccanismo vSphere HA funziona di nuovo: le macchine virtuali dell'host guasto vengono riavviate su altri host, sullo stesso sito o su quello remoto. Il tempo di riavvio della macchina virtuale è massimo di 1 minuto.
Se tutti gli host ESXi sul sito OST falliscono, non ci sono opzioni: le VM vengono riavviate su un altro. L'ora di riavvio è la stessa.
Il sistema di storage si guasta in un sito. Supponiamo che il sistema di archiviazione fallisca nel sito OST. Quindi gli host ESXi del sito OST passano a lavorare con le repliche di storage in NORD. Una volta che il sistema di storage guasto tornerà in servizio, verrà eseguita la replica forzata e gli host ESXi OST inizieranno nuovamente ad accedere al sistema di storage locale.
Le macchine virtuali hanno funzionato normalmente per tutto questo tempo.
Uno dei siti fallisce. In questo caso, tutte le macchine virtuali verranno riavviate sul sito di backup tramite il meccanismo vSphere HA. Il tempo di riavvio della VM è di 140 secondi. In questo caso, tutte le impostazioni di rete della macchina virtuale verranno salvate e rimarrà accessibile al client tramite la rete.
Per garantire che il riavvio delle macchine nel sito di backup avvenga senza intoppi, ciascun sito è pieno solo per metà. La seconda metà è una riserva nel caso in cui tutte le macchine virtuali si spostino dal secondo sito danneggiato.
Un cloud resistente ai disastri basato su due data center protegge da tali guasti.
Questo piacere non è economico, poiché, oltre alle risorse principali, è necessaria una riserva nel secondo sito. Pertanto, i servizi business-critical vengono collocati in un cloud di questo tipo, i cui tempi di inattività a lungo termine causano ingenti perdite finanziarie e di reputazione, o se il sistema informativo è soggetto a requisiti di resilienza ai disastri da parte delle autorità di regolamentazione o delle normative interne dell'azienda.
Fonti:
Fonte: habr.com