Uno switch può morire e il vostro storage continua a servire
Il disco della vostra VM vive su un array dedicato, raggiunto da due reti storage che non condividono nulla. Entrambe sono attive in ogni momento, quindi uno switch morto, un cavo staccato o un'intera rete messa fuori servizio per manutenzione non è un evento per il carico di lavoro.
In questo articolo 4 sezioni
- Ogni host sul nostro SAN raggiunge il proprio storage attraverso due fabric Fibre Channel completamente indipendenti, con switch separati, in modalità active/active.
- Uno switch, un cavo o una porta possono guastarsi e la vostra LUN continua a servire sull'altro percorso. Entrambi i percorsi portano I/O di produzione in ogni momento, quindi non c'è uno standby da svegliare né un cutover da superare.
- Il RAID dentro un singolo server copre un solo guasto, un disco morto. Tutto il resto in quella macchina si porta giù il vostro storage con sé.
- Il design permette di mettere fuori servizio un intero fabric con ogni macchina virtuale ancora in esecuzione sull'altro.
Il disco su cui scrive il vostro carico di lavoro non vive dentro il server che lo esegue. Vive su un array storage a una rete di distanza, e quella rete può guastarsi come qualsiasi altra cosa: gli switch muoiono, i cavi vengono staccati, le porte cominciano a fare flapping. Ciò che decide se il vostro carico se ne accorgerà mai è se esiste una seconda strada verso il disco, e se quella seconda strada è davvero separata dalla prima.
Il multipath dà a ogni host due strade attive verso la sua LUN
Una LUN è il dispositivo a blocchi che la vostra macchina virtuale vede come il proprio disco. Su un SAN, quel disco vive fuori dal server che esegue il vostro carico, su un array all-flash dedicato a doppio controller, e il server lo raggiunge attraverso una rete storage. Multipath significa che il server tiene più di un percorso fisico verso la stessa LUN nello stesso momento, attraverso porte diverse, cavi diversi e switch diversi.
Active/active significa che entrambi i percorsi portano traffico ogni secondo della giornata. Un percorso di standby che si sveglia solo durante un guasto è un percorso che non avete mai davvero testato, e il guasto è il momento peggiore possibile per fargli il primo test. Quando entrambi i percorsi portano I/O live di continuo, perderne uno lascia semplicemente l'altro a fare tutto il lavoro di cui già faceva metà. Il carico non vede nulla, perché da dove sta, non è successo nulla.
Due porte HBA sull'host
Due cavi, su due percorsi separati
Due switch, uno per fabric
Due fabric Fibre Channel, entrambi active/active
I due fabric non condividono alcuno switch, quindi un guasto non può passare dall'uno all'altro
Due percorsi attraverso lo stesso switch sono un percorso con due etichette. Qualunque cosa uccida lo switch li uccide entrambi. Vera indipendenza significa che i due fabric sono costruiti come due reti separate con switch separati, e nulla nel percorso dati tra host e array compare in entrambi. Un guasto in un fabric, che sia uno switch morto, una porta in flapping o un link congestionato, non ha dove propagarsi. Il secondo fabric non ne viene a sapere.
Un fabric Fibre Channel è la rete switched tra server e array storage, l'equivalente storage della vostra LAN. Farne girare due, completamente separati, significa che il vostro traffico storage ha sempre una seconda rete su cui vivere. I guasti costosi nel networking storage raramente sono morti pulite; sono link che restano up ma si bloccano, e l'indipendenza è ciò che tiene quel tipo di malattia confinato a un lato.
Il RAID dentro un server muore con il server
Il RAID su una scheda controller dentro il vostro server vi protegge da esattamente una cosa, un disco morto, ed è bravo in questo. Ma i dischi, la scheda RAID, il backplane, gli alimentatori e la scheda madre vivono tutti nella stessa macchina, e la macchina è il dominio di guasto. Quando qualsiasi altra cosa al suo interno muore, il vostro storage se ne va con lei, e torna quando torna il server. Se è la scheda RAID stessa a guastarsi, i dischi più sani del mondo sono irraggiungibili.
Un SAN sposta il disco fuori dal dominio di guasto della macchina che lo usa. Il vostro server può morire e la LUN su cui stava scrivendo un secondo prima è ancora lì, intatta e in servizio, pronta perché il carico riparta su un altro host. Il design a doppio fabric estende la stessa idea alla strada tra i due: anche al percorso verso il vostro storage è permesso guastarsi, per questo ne abbiamo costruiti due.
| Cosa si guasta | Cosa vedono i vostri carichi |
|---|---|
| Un cavo o una porta | La LUN continua a servire sull'altro percorso. Nessun cutover, nessun riavvio. |
| Un intero switch | Il secondo fabric porta tutto. Nulla si sveglia né commuta. |
| Un intero fabric, messo fuori servizio per manutenzione | Ogni host mantiene un percorso buono sul fabric sano mentre il lavoro avviene. |
| Un nodo controller dello storage | Il secondo controller continua a servire mentre l'hardware viene sostituito. |
| Il server stesso | La LUN gli sopravvive. Il carico riparte su un altro host e trova il suo disco dove l'aveva lasciato. |
Mettere fuori servizio un intero fabric con carichi live
Quando un fabric ha bisogno di manutenzione, la procedura è priva di glamour: confermiamo che ogni host mantenga un percorso buono sull'altro fabric, mettiamo il fabric fuori servizio, facciamo il lavoro, poi lo reintroduciamo deliberatamente. Le macchine virtuali girano su un fabric mentre il lavoro avviene e non vedono nulla. È la giusta quantità di dramma per la manutenzione dello storage.
La stessa postura vale sul lato array. Gli array sono a doppio controller: un controller può essere manutenuto mentre l'altro continua a servire. Sul nostro SAN l'hardware viene manutenuto come dovrebbe esserlo ovunque: mentre la cosa a cui appartiene continua a fare il suo lavoro.
Risposte dirette
Active/active è solo una parola più carina per failover?+
No. Un design failover tiene un secondo percorso inattivo finché il primo non muore, poi tenta un cutover nelle peggiori condizioni della giornata. Active/active significa che entrambi i fabric portano I/O di produzione in ogni momento, quindi un guasto rimuove un percorso funzionante mentre l'altro percorso funzionante continua. Non c'è alcun evento di cutover da superare né uno standby che riceve il suo primo test durante il vostro incidente.
Il mio server ha RAID-10. È la stessa protezione?+
Il RAID dentro il server protegge i vostri dati da un disco morto, e solo da quello. La scheda RAID, il backplane, gli alimentatori e il server stesso restano singoli punti di guasto, e il vostro storage condivide la loro sorte. Su un SAN lo storage sopravvive alla morte del server che lo usa, e con i doppi fabric sopravvive anche alla morte della strada in mezzo.
E se si guasta l'intero array, o l'intero sito?+
Classe di guasto diversa, strumenti diversi. Questo articolo copre i percorsi tra un host sano e un array sano, che è dove vivono i guasti di tutti i giorni. Sopravvivere alla perdita di un array o di un sito è una conversazione sul ripristino, e l'abbiamo scritta a parte: quanta perdita di dati e quanto downtime la vostra azienda può tollerare onestamente.
Come faccio a sapere che entrambi i percorsi funzionano davvero prima che uno si guasti?+
Poiché entrambi i fabric portano I/O live di continuo, un percorso morto non è una condizione silenziosa: nel momento in cui un lato smette di far passare traffico, emerge nel monitoraggio. E ogni manutenzione inizia allo stesso modo, confermando che ogni host mantenga un percorso buono sul fabric che resta, prima che qualsiasi cosa venga messa fuori servizio.
Chiedete a un ingegnere su cosa poggia davvero il vostro storage
Le persone che progettano e gestiscono i fabric sono le stesse che rispondono. Portateci la vostra configurazione attuale e vi diremo chiaramente cosa sopravvive a cosa.
Parla con un ingegnereSwitch morti, cavi staccati e manutenzione dei controller sono i guasti che questo design manda in pensione. Perdere un intero array o un intero sito è una classe di guasto diversa, e quella parte dalla conversazione sul ripristino. Se state valutando dei provider, le domande sullo storage che vale la pena fare a chiunque, noi compresi, sono in il segreto sporco del vostro provider è il suo storage.
Siete arrivati alla fine.
Mettete la lettura al lavoro
Cosa fate girare?
Raccontateci il carico di lavoro, il traffico e i requisiti di ripristino. Partite dal configuratore di server, oppure discutete i dettagli con un ingegnere.
Scritto dagli ingegneri che costruiscono e gestiscono l'infrastruttura che descrive.Parla con un ingegnere