Ehi Habr!
Dopu à e vacanze di l'annu novu, avemu rilanciatu una nuvola a prova di disastru basatu annantu à dui siti. Oghje vi diceremu cumu si travaglia è mostra ciò chì succede à e macchine virtuali di u cliente quandu elementi individuali di u cluster fallenu è u situ sanu sanu (spoiler - tuttu hè bè cun elli).
Sistema di almacenamentu in nuvola resistente à i disastri nantu à u situ OST.
Chì ci hè dentru
Sottu u cappucciu, u cluster hà servitori Cisco UCS cù un hypervisor VMware ESXi, dui sistemi di almacenamento INFINIDAT InfiniBox F2240, l'equipaggiu di rete Cisco Nexus, è ancu i switch Brocade SAN. U cluster hè divisu in dui siti - OST è NORD, vale à dì chì ogni centru di dati hà un equipamentu identicu. In fatti, questu hè ciò chì a rende resistente à i disastri.
In un situ, l'elementi principali sò ancu duplicati (ospiti, switch SAN, networking).
I dui siti sò cunnessi per via di fibra ottica dedicata, ancu riservata.
Uni pochi parolle nantu à i sistemi di almacenamento. Avemu custruitu a prima versione di una nuvola a prova di disastru nantu à NetApp. Quì avemu sceltu INFINIDAT, è eccu perchè:
- Opzione di replicazione attiva-attiva. Permette à a macchina virtuale di stà operativa ancu s'ellu unu di i sistemi di almacenamentu falla cumplettamente. Vi dicu più nantu à a replicazione dopu.
- Trè controller di discu per aumentà a tolleranza à i difetti di u sistema. Di solitu ci sò dui.
- Soluzione pronta. Avemu ricevutu un rack pre-assemblatu chì solu deve esse cunnessu à a reta è cunfiguratu.
- Supportu tecnicu attentu. L'ingegneri INFINIDAT analizanu constantemente i logs è l'avvenimenti di u sistema di almacenamento, installanu novi versioni di firmware è aiutanu cù a cunfigurazione.
Eccu alcune foto da u dispacking:
Cumu travagliu
U nuvulu hè digià tollerante à i difetti in sè stessu. Prutege u cliente da un solu fallimentu hardware è software. A resistenza à i disastri vi aiuterà à prutege contr'à fallimenti massivi in un situ: per esempiu, fallimentu di un sistema di almacenamiento (o un cluster SDS, chì succede abbastanza spessu 🙂), errori massivi in una rete di almacenamento, etc. Ebbè, è u più impurtante: un tali nuvulu salva quandu un situ sanu diventa inaccessibile per via di un focu, blackout, raider takeover, o sbarcu straneru.
In tutti questi casi, e macchine virtuali di u cliente cuntinueghjanu à travaglià, è eccu perchè.
U disignu di u cluster hè pensatu per chì qualsiasi host ESXi cù macchine virtuali clientali ponu accede à qualsiasi di i dui sistemi di almacenamento. Se u sistema d'almacenamiento in u situ OST falla, i machini virtuali cuntinueghjanu à travaglià: l'ospiti nantu à quale sò in esecuzione accede à u sistema di almacenamiento in NORD per i dati.
Questu hè u schema di cunnessione in un cluster.
Questu hè pussibule per u fattu chì un Inter-Switch Link hè cunfiguratu trà i tessuti SAN di i dui siti: u Fabric A OST SAN switch hè cunnessu à u Fabric A NORD SAN switch, è simile per i switch Fabric B SAN.
Ebbè, cusì chì tutte queste intricacies di e fabbriche SAN anu sensu, a replicazione Active-Active hè cunfigurata trà i dui sistemi di almacenamento: l'infurmazione hè scritta quasi simultaneamente à i sistemi di almacenamento lucale è remoti, RPO = 0. Ci hè chì i dati originali sò guardati in un sistema di almacenamiento, è a so replica hè guardata in l'altru. I dati sò replicati à u livellu di volumi di almacenamento, è i dati di VM (i so dischi, u schedariu di cunfigurazione, u schedariu di scambiu, etc.) sò guardati nantu à elli.
L'ospite ESXi vede u voluminu primariu è a so replica cum'è un dispositivu di discu (Dispositivu di almacenamiento). Ci sò 24 percorsi da l'ospite ESXi à ogni dispusitivu di discu:
I percorsi 12 li cunnessu à u sistema di almacenamento lucale (percorsi ottimali), è i 12 restanti à u sistema di almacenamentu remoto (percorsi micca ottimali). In una situazione normale, ESXi accede à e dati nantu à u sistema di almacenamentu locale utilizendu percorsi "ottimali". Quandu stu sistema di almacenamentu falla, ESXi perde percorsi ottimali è cambia à quelli "non ottimali". Questu hè ciò chì pare nantu à u schema.
Schema di un cluster a prova di disastru.
Tutte e rete di clientella sò cunnessi à i dui siti per mezu di una tela di rete cumuna. Ogni situ gestisce un Provider Edge (PE), nantu à quale e rete di u cliente sò terminate. I PE sò uniti in un cluster cumunu. Se un PE falla in un situ, tuttu u trafficu hè ridirettu à u sicondu situ. Grazie à questu, i machini virtuali da u situ lasciatu senza PE restanu accessibili nantu à a reta à u cliente.
Videmu avà ciò chì succede à e macchine virtuali di u cliente durante diversi fallimenti. Cuminciamu cù l'opzioni più ligeri è finisci cù u più seriu - fallimentu di tuttu u situ. In l'esempii, a piattaforma principale serà OST, è a piattaforma di salvezza, cù repliche di dati, serà NORD.
Chì succede à a macchina virtuale di u cliente se ...
Replication Link falla. A replicazione trà i sistemi di almacenamento di i dui siti si ferma.
ESXi funzionerà solu cù i dispositi di discu lucali (via percorsi ottimali).
Macchine virtuale cuntinueghjanu à travaglià.
L'ISL (Inter-Switch Link) si rompe. U casu hè improbabile. A menu chì un escavatore pazzo scavà parechje rotte ottiche à una volta, chì viaghjanu nantu à rotte indipendenti è sò purtate à i siti attraversu diverse inputs. Ma in ogni modu. In questu casu, l'ospiti ESXi perdenu a mità di i camini è ponu accede solu à i so sistemi di almacenamento lucali. E repliche sò cullate, ma l'ospiti ùn puderanu micca accede à elli.
Macchine virtuale sò travagliendu nurmale.
U switch SAN falla in unu di i siti. L'ospiti ESXi perdenu alcuni di i camini à u sistema di almacenamento. In questu casu, l'ospiti in u situ induve u cambiamentu hà fallutu travaglià solu attraversu unu di i so HBA.
E macchine virtuali cuntinueghjanu à operare nurmale.
Tutti i switch SAN nantu à unu di i siti fallenu. Dicemu chì un tali disastru hè accadutu nantu à u situ OST. In questu casu, l'ospiti ESXi nantu à stu situ perderanu tutte e strade à i so dispositi di discu. U mecanismu standard VMware vSphere HA entra in ghjocu: riavvia tutte e macchine virtuali di u situ OST in NORD in un massimu di 140 seconde.
E macchine virtuali chì funzionanu nantu à l'ospiti di u situ NORD funzionanu normalmente.
L'ospite ESXi falla in un situ. Quì u mecanismu vSphere HA funziona di novu: e macchine virtuali da l'ospitu fallutu sò riavviate in altri ospiti - in u stessu situ o remotu. U tempu di riavvia di a macchina virtuale hè finu à 1 minutu.
Se tutti l'ospiti ESXi nantu à u situ OST fallenu, ùn ci sò micca opzioni: i VM sò riavviati nantu à un altru. U tempu di riavvia hè u listessu.
U sistema di almacenamentu falla in un situ. Dicemu chì u sistema di almacenamento falla in u situ OST. Allora l'ospiti ESXi di u situ OST cambianu à travaglià cù repliche di almacenamiento in NORD. Dopu chì u sistema d'almacenamiento fallutu torna à u serviziu, a replicazione furzata accaderà è l'ospiti ESXi OST cumincianu di novu à accede à u sistema di almacenamiento locale.
Macchine virtuali sò stati travagliendu nurmale tuttu stu tempu.
Unu di i siti falla. In questu casu, tutte e macchine virtuali seranu riavviate nantu à u situ di salvezza attraversu u mecanismu vSphere HA. U tempu di riavvia VM hè 140 seconde. In questu casu, tutti i paràmetri di a rete di a macchina virtuale seranu salvati, è ferma accessibile à u cliente nantu à a reta.
Per assicurà chì u riavviu di e macchine in u situ di salvezza si faci senza, ogni situ hè solu a mità piena. A seconda mità hè una riserva in casu chì tutte e macchine virtuali si movenu da u sicondu situ, dannighjatu.
Un nuvulu resistente à i disastri basatu nantu à dui centri di dati pruteghja contru tali fallimenti.
Stu piacè ùn hè micca prezzu, postu chì, in più di i risorsi principali, una riserva hè necessaria in u sicondu situ. Per quessa, i servizii critichi di l'affari sò posti in un tali nuvulu, u downtime à longu andà di quale provoca grandi perdite finanziarie è reputational, o se u sistema d'infurmazione hè sottumessu à esigenze di resilienza di disastru da regulatori o regulamenti internu di a cumpagnia.
Sources:
Source: www.habr.com