Questo è un mito abbastanza comune nel campo dell'hardware dei server. In pratica, le soluzioni iperconvergenti (quando tutto è in uno) servono per molte cose. Storicamente, le prime architetture sono state sviluppate da Amazon e Google per i loro servizi. Quindi l'idea era quella di creare una fattoria informatica da nodi identici, ognuno dei quali avesse i propri dischi. Tutto questo era unito da alcuni software di formazione del sistema (hypervisor) ed era diviso in macchine virtuali. L'obiettivo principale è il minimo sforzo per la manutenzione di un nodo e il minimo di problemi durante il ridimensionamento: basta acquistare altri mille o due server uguali e collegarli nelle vicinanze. In pratica si tratta di casi isolati, e molto più spesso si parla di un numero minore di nodi e di un'architettura leggermente diversa.
Ma il vantaggio rimane lo stesso: incredibile facilità di scalabilità e gestione. Lo svantaggio è che attività diverse consumano risorse in modo diverso e in alcuni luoghi ci saranno molti dischi locali, in altri ci sarà poca RAM e così via, ovvero per diversi tipi di attività l'utilizzo delle risorse diminuirà.
Si scopre che paghi il 10-15% in più per una facilità di configurazione. Questo è ciò che ha acceso il mito nel titolo. Abbiamo cercato a lungo dove la tecnologia potesse essere applicata in modo ottimale e l'abbiamo trovato. Il fatto è che Cisco non disponeva di propri sistemi di storage, ma voleva un mercato di server completo. E hanno realizzato Cisco Hyperflex, una soluzione con archiviazione locale sui nodi.
E questa si è rivelata improvvisamente un'ottima soluzione per il backup dei data center (Disaster Recovery). Ti dirò perché e come adesso. E ti mostrerò i test sui cluster.
Dove necessario
L'iperconvergenza è:
- Trasferimento dei dischi ai nodi di calcolo.
- Integrazione completa del sottosistema di storage con il sottosistema di virtualizzazione.
- Trasferimento/integrazione con il sottosistema di rete.
Questa combinazione consente di implementare molte funzionalità del sistema di storage a livello di virtualizzazione e tutto da un'unica finestra di controllo.
Nella nostra azienda, i progetti per la progettazione di data center ridondanti sono molto richiesti e spesso viene scelta una soluzione iperconvergente a causa di una serie di opzioni di replica (fino a un metrocluster) pronte all'uso.
Nel caso dei data center di backup, di solito parliamo di una struttura remota in un sito dall'altra parte della città o in un'altra città. Consente di ripristinare i sistemi critici in caso di guasto parziale o totale del data center principale. I dati di vendita vengono costantemente replicati lì e questa replica può avvenire a livello di applicazione o a livello di dispositivo a blocchi (archiviazione).
Pertanto, ora parlerò della progettazione e dei test del sistema, quindi di un paio di scenari applicativi reali con dati di risparmio.
Test
La nostra istanza è composta da quattro server, ciascuno dei quali dispone di 10 unità SSD da 960 GB. È disponibile un disco dedicato per la memorizzazione nella cache delle operazioni di scrittura e l'archiviazione della macchina virtuale del servizio. La soluzione stessa è la quarta versione. Il primo è francamente rozzo (a giudicare dalle recensioni), il secondo è umido, il terzo è già abbastanza stabile, e questo può essere definito un rilascio dopo la fine del beta testing per il grande pubblico. Durante i test non ho riscontrato alcun problema, tutto funziona come un orologio.
Modifiche nella v4Sono stati risolti un sacco di bug.
Inizialmente, la piattaforma poteva funzionare solo con l'hypervisor VMware ESXi e supportava un numero limitato di nodi. Inoltre, il processo di distribuzione non sempre si concludeva con successo, alcuni passaggi dovevano essere riavviati, si verificavano problemi con l'aggiornamento da versioni precedenti, i dati nella GUI non venivano sempre visualizzati correttamente (anche se non sono ancora soddisfatto della visualizzazione dei grafici delle prestazioni ), a volte sono sorti problemi nell'interfaccia con la virtualizzazione.
Ora che tutti i problemi infantili sono stati risolti, HyperFlex può gestire sia ESXi che Hyper-V, inoltre è possibile:
- Creazione di un cluster allungato.
- Creazione di un cluster per uffici senza utilizzo di Fabric Interconnect, da due a quattro nodi (acquistiamo solo server).
- Capacità di lavorare con sistemi di storage esterni.
- Supporto per contenitori e Kubernetes.
- Creazione di zone di disponibilità.
- Integrazione con VMware SRM se la funzionalità integrata non è soddisfacente.
L'architettura non è molto diversa dalle soluzioni dei suoi principali concorrenti, non hanno creato una bicicletta. Tutto funziona sulla piattaforma di virtualizzazione VMware o Hyper-V. L'hardware è ospitato su server proprietari Cisco UCS. C'è chi odia la piattaforma per la relativa complessità del setup iniziale, tanti pulsanti, un sistema di template e dipendenze non banale, ma c'è anche chi ha imparato lo Zen, si ispira all'idea e non vuole più per lavorare con altri server.
Considereremo la soluzione per VMware, poiché la soluzione è stata originariamente creata per questo e ha più funzionalità; Hyper-V è stato aggiunto lungo il percorso per stare al passo con la concorrenza e soddisfare le aspettative del mercato.
C'è un cluster di server pieno di dischi. Sono presenti dischi per l'archiviazione dei dati (SSD o HDD - in base ai tuoi gusti e alle tue esigenze), c'è un disco SSD per la memorizzazione nella cache. Durante la scrittura dei dati nel datastore, i dati vengono salvati sul livello di caching (disco SSD dedicato e RAM della VM del servizio). Parallelamente, un blocco di dati viene inviato ai nodi del cluster (il numero di nodi dipende dal fattore di replica del cluster). Dopo la conferma da parte di tutti i nodi dell'avvenuta registrazione, la conferma della registrazione viene inviata all'hypervisor e quindi alla VM. I dati registrati vengono deduplicati, compressi e scritti su dischi di archiviazione in background. Allo stesso tempo, un blocco di grandi dimensioni viene sempre scritto sui dischi di archiviazione e in sequenza, il che riduce il carico sui dischi di archiviazione.
La deduplicazione e la compressione sono sempre abilitate e non possono essere disabilitate. I dati vengono letti direttamente dai dischi di archiviazione o dalla cache RAM. Se viene utilizzata una configurazione ibrida, le letture vengono memorizzate anche nella cache dell'SSD.
I dati non sono legati alla posizione corrente della macchina virtuale e sono distribuiti uniformemente tra i nodi. Questo approccio consente di caricare equamente tutti i dischi e le interfacce di rete. C'è uno svantaggio evidente: non possiamo ridurre il più possibile la latenza di lettura, poiché non esiste alcuna garanzia della disponibilità dei dati localmente. Ma credo che questo sia un piccolo sacrificio rispetto ai benefici ricevuti. Inoltre, i ritardi di rete hanno raggiunto valori tali da non incidere praticamente sul risultato complessivo.
Uno speciale controller di servizio VM Cisco HyperFlex Data Platform, creato su ciascun nodo di archiviazione, è responsabile dell'intera logica operativa del sottosistema del disco. Nella configurazione della nostra VM di servizio sono state allocate otto vCPU e 72 GB di RAM, il che non è poi così poco. Lascia che ti ricordi che l'host stesso ha 28 core fisici e 512 GB di RAM.
La VM del servizio ha accesso ai dischi fisici direttamente inoltrando il controller SAS alla VM. La comunicazione con l'hypervisor avviene tramite un apposito modulo IOVisor, che intercetta le operazioni di I/O, e utilizzando un agente che consente di inviare comandi alle API dell'hypervisor. L'agente è responsabile dell'utilizzo degli snapshot e dei cloni HyperFlex.
Le risorse disco sono montate nell'hypervisor come condivisioni NFS o SMB (a seconda del tipo di hypervisor, indovina quale è dove). E sotto il cofano, si tratta di un file system distribuito che consente di aggiungere funzionalità di sistemi di archiviazione completi per adulti: allocazione di volumi sottili, compressione e deduplicazione, istantanee che utilizzano la tecnologia Redirect-on-Write, replica sincrona/asincrona.
Il servizio VM fornisce l'accesso all'interfaccia di gestione WEB del sottosistema HyperFlex. C'è integrazione con vCenter e la maggior parte delle attività quotidiane può essere eseguita da esso, ma i datastore, ad esempio, sono più convenienti da tagliare da una webcam separata se sei già passato a un'interfaccia HTML5 veloce o utilizzi un client Flash completo con piena integrazione. Nella webcam del servizio è possibile visualizzare l'andamento e lo stato dettagliato dell'impianto.
Esiste un altro tipo di nodo in un cluster: i nodi di calcolo. Possono essere server rack o blade senza dischi integrati. Questi server possono eseguire macchine virtuali i cui dati sono archiviati su server con dischi. Dal punto di vista dell'accesso ai dati non c'è differenza tra le tipologie di nodi, perché l'architettura prevede l'astrazione dalla posizione fisica dei dati. Il rapporto massimo tra nodi di elaborazione e nodi di archiviazione è 2:1.
L'uso dei nodi di calcolo aumenta la flessibilità durante il ridimensionamento delle risorse del cluster: non dobbiamo acquistare nodi aggiuntivi con dischi se abbiamo bisogno solo di CPU/RAM. Inoltre, possiamo aggiungere una gabbia per blade e risparmiare sul posizionamento dei server nei rack.
Di conseguenza, disponiamo di una piattaforma iperconvergente con le seguenti funzionalità:
- Fino a 64 nodi in un cluster (fino a 32 nodi di archiviazione).
- Il numero minimo di nodi in un cluster è tre (due per un cluster Edge).
- Meccanismo di ridondanza dei dati: mirroring con fattore di replica 2 e 3.
- Gruppo metropolitano.
- Replica asincrona della VM su un altro cluster HyperFlex.
- Orchestrazione del passaggio di VM a un data center remoto.
- Istantanee native che utilizzano la tecnologia Redirect-on-Write.
- Fino a 1 PB di spazio utilizzabile con fattore di replica 3 e senza deduplica. Non prendiamo in considerazione il fattore di replica 2, perché questa non è un'opzione per vendite serie.
Un altro enorme vantaggio è la facilità di gestione e implementazione. Tutte le complessità della configurazione dei server UCS sono gestite da una VM specializzata preparata dagli ingegneri Cisco.
Configurazione banco prova:
- 2 x Cisco UCS Fabric Interconnect 6248UP come cluster di gestione e componenti di rete (48 porte funzionanti in modalità Ethernet 10G/FC 16G).
- Quattro server Cisco UCS HXAF240 M4.
Caratteristiche del server:
CPU
2 Intel® Xeon® E5-2690 v4
RAM
16 RDIMM DDR32-4 MHz da 2400 GB/PC4-19200/dual ranking/x4/1.2 V
Network NetPoulSafe
UCSC-MLOM-CSC-02 (VIC 1227). 2 porte Ethernet 10G
HBA di archiviazione
Controller pass-through SAS modulare Cisco 12G
Dischi di archiviazione
1 SSD Intel S3520 da 120 GB, 1 SSD Samsung MZ-IES800D, 10 SSD Samsung PM863a da 960 GB
Ulteriori opzioni di configurazioneOltre all'hardware selezionato, sono attualmente disponibili le seguenti opzioni:
- HXAF240c M5.
- Una o due CPU che vanno da Intel Silver 4110 a Intel Platinum I8260Y. Disponibile la seconda generazione.
- 24 slot di memoria, strisce da 16 GB RDIMM 2600 a 128 GB LRDIMM 2933.
- Da 6 a 23 dischi dati, un disco di cache, un disco di sistema e un disco di avvio.
Unità di capacità
- HX-SD960G61X-EV SSD SATA Enterprise Value 960G da 2.5 pollici da 6 GB (durata 1X) SAS 960 GB.
- SSD SATA Enterprise Value 38G HX-SD61T3.8X-EV da 2.5 TB e 6 pollici (durata 1X) SAS da 3.8 TB.
- Unità di memorizzazione nella cache
- HX-NVMEXPB-I375 Unità Intel Optane da 375 GB e 2.5 pollici, prestazioni e resistenza estreme.
- HX-NVMEHW-H1600* 1.6 TB 2.5 pollici ent. Perf. SSD NVMe (resistenza 3X) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400 GB 2.5 pollici ent. Perf. SSD SAS 12G (resistenza 10X) SAS 400 GB.
- HX-SD800GBENK9** 800 GB 2.5 pollici ent. Perf. SSD SAS SED da 12G (resistenza 10X) SAS da 800 GB.
- SSD SAS 16G HX-SD123T1.6X-EP da 2.5 TB e 12 pollici per prestazioni aziendali (resistenza 3X).
Unità di sistema/registro
- SSD SATA Enterprise Value 240G HX-SD1GM240X-EV da 2.5 GB e 6 pollici (richiede l'aggiornamento).
Unità di avvio
- HX-M2-240GB SSD SATA M.240 da 2 GB SATA 240 GB.
Connettiti alla rete tramite porte Ethernet 40G, 25G o 10G.
L'FI può essere HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
La prova stessa
Per testare il sottosistema del disco, ho utilizzato HCIBench 2.2.1. Si tratta di un'utilità gratuita che consente di automatizzare la creazione di un carico da più macchine virtuali. Il carico stesso è generato dal solito fio.
Il nostro cluster è composto da quattro nodi, fattore di replica 3, tutti i dischi sono Flash.
Per i test, ho creato quattro archivi dati e otto macchine virtuali. Per i test di scrittura si presuppone che il disco di memorizzazione nella cache non sia pieno.
I risultati del test sono i seguenti:
100% letto 100% casuale
0% letto 100% casuale
Profondità blocco/coda
128
256
512
1024
2048
128
256
512
1024
2048
4K
0,59 ms 213804 IOPS
0,84 ms 303540 IOPS
1,36 ms 374348 IOPS
2.47 ms 414116 IOPS
4,86 ms 420180 IOPS
2,22 ms 57408 IOPS
3,09 ms 82744 IOPS
5,02 ms 101824 IPOS
8,75 ms 116912 IOPS
17,2 ms 118592 IOPS
8K
0,67 ms 188416 IOPS
0,93 ms 273280 IOPS
1,7 ms 299932 IOPS
2,72 ms 376,484 IOPS
5,47 ms 373,176 IOPS
3,1 ms 41148 IOPS
4,7 ms 54396 IOPS
7,09 ms 72192 IOPS
12,77 ms 80132 IOPS
16K
0,77 ms 164116 IOPS
1,12 ms 228328 IOPS
1,9 ms 268140 IOPS
3,96 ms 258480 IOPS
3,8 ms 33640 IOPS
6,97 ms 36696 IOPS
11,35 ms 45060 IOPS
32K
1,07 ms 119292 IOPS
1,79 ms 142888 IOPS
3,56 ms 143760 IOPS
7,17 ms 17810 IOPS
11,96 ms 21396 IOPS
64K
1,84 ms 69440 IOPS
3,6 ms 71008 IOPS
7,26 ms 70404 IOPS
11,37 ms 11248 IOPS
Il grassetto indica valori oltre i quali non si registra alcun aumento della produttività, a volte è visibile anche un degrado. Ciò è dovuto al fatto che siamo limitati dalle prestazioni della rete/controller/dischi.
- Lettura sequenziale 4432 MB/s.
- Scrittura sequenziale 804 MB/s.
- Se un controller si guasta (guasto di una macchina virtuale o di un host), il calo delle prestazioni è duplice.
- Se il disco di archiviazione si guasta, il prelievo è di 1/3. La ricostruzione del disco richiede il 5% delle risorse di ciascun controller.
Su un blocco piccolo siamo limitati dalle prestazioni del controller (macchina virtuale), la sua CPU è caricata al 100% e quando il blocco aumenta, siamo limitati dalla larghezza di banda della porta. 10 Gbps non sono sufficienti per sfruttare il potenziale del sistema AllFlash. Sfortunatamente, i parametri del supporto demo fornito non ci permettono di testare il funzionamento a 40 Gbit/s.
Secondo la mia impressione dai test e dallo studio dell'architettura, grazie all'algoritmo che colloca i dati tra tutti gli host, otteniamo prestazioni scalabili e prevedibili, ma questa è anche una limitazione durante la lettura, perché sarebbe possibile spremere di più dai dischi locali, qui può risparmiare una rete più produttiva, ad esempio è disponibile FI a 40 Gbit/s.
Inoltre, un disco per la cache e la deduplicazione potrebbe rappresentare una limitazione; infatti, in questo test possiamo scrivere su quattro dischi SSD. Sarebbe fantastico poter aumentare il numero di unità di memorizzazione nella cache e vedere la differenza.
Utilizzo reale
Per organizzare un data center di backup è possibile utilizzare due approcci (non consideriamo il posizionamento di un backup su un sito remoto):
- Attivo passivo. Tutte le applicazioni sono ospitate nel data center principale. La replica è sincrona o asincrona. Se il data center principale fallisce, dobbiamo attivare quello di backup. Questa operazione può essere eseguita manualmente/script/applicazioni di orchestrazione. Qui otterremo un RPO commisurato alla frequenza di replica, e l'RTO dipende dalla reazione e dalle competenze dell'amministratore e dalla qualità di sviluppo/debug del piano di switching.
- Attivo-Attivo. In questo caso esiste solo la replica sincrona; la disponibilità dei data center è determinata da un quorum/arbitro situato rigorosamente sul terzo sito. RPO = 0 e RTO può raggiungere 0 (se l'applicazione lo consente) o uguale al tempo di failover di un nodo in un cluster di virtualizzazione. A livello di virtualizzazione viene creato un cluster allungato (Metro) che richiede storage Active-Active.
Di solito vediamo che i clienti hanno già implementato un'architettura con un sistema di storage classico nel data center principale, quindi ne progettiamo un'altra per la replica. Come ho già detto, Cisco HyperFlex offre la replica asincrona e la creazione di cluster di virtualizzazione estesa. Allo stesso tempo non abbiamo bisogno di un sistema di storage dedicato di livello Midrange e superiore con costose funzioni di replica e accesso ai dati attivo-attivo su due sistemi di storage.
Script 1: Disponiamo di un data center primario e di backup, una piattaforma di virtualizzazione su VMware vSphere. Tutti i sistemi produttivi si trovano nel data center principale e la replica delle macchine virtuali viene eseguita a livello di hypervisor, questo eviterà di mantenere le VM accese nel data center di backup. Replichiamo database e applicazioni speciali utilizzando strumenti integrati e manteniamo accese le VM. Se il data center principale fallisce, lanciamo i sistemi nel data center di backup. Crediamo di avere circa 100 macchine virtuali. Mentre il data center primario è operativo, il data center in standby può eseguire ambienti di test e altri sistemi che possono essere spenti se il data center primario cambia. È anche possibile utilizzare la replica bidirezionale. Dal punto di vista hardware non cambierà nulla.
Nel caso dell'architettura classica, installeremo in ogni data center un sistema di storage ibrido con accesso via FibreChannel, tiering, deduplicazione e compressione (ma non online), 8 server per ogni sito, 2 switch FibreChannel e Ethernet 10G. Per la gestione della replica e dello switching in un'architettura classica, possiamo utilizzare strumenti VMware (Replica + SRM) o strumenti di terze parti, che saranno un po' più economici e talvolta più convenienti.
La figura mostra il diagramma.
Utilizzando Cisco HyperFlex si ottiene la seguente architettura:
Per HyperFlex ho utilizzato server con grandi risorse CPU/RAM, perché... Alcune risorse andranno alla VM del controller HyperFlex; in termini di CPU e memoria ho anche riconfigurato un po' la configurazione HyperFlex per non giocare con Cisco e garantire risorse per le restanti VM. Ma possiamo abbandonare gli switch FibreChannel e non avremo bisogno di porte Ethernet per ciascun server; il traffico locale viene commutato all'interno di FI.
Il risultato è stata la seguente configurazione per ciascun data center:
Server
8 server 1U (384 GB di RAM, 2 Intel Gold 6132, FC HBA)
8 HX240C-M5L (512 GB RAM, 2 Intel Gold 6150, SSD da 3,2 GB, 10 NL-SAS da 6 TB)
Magazzinaggio
Sistema di storage ibrido con front-end FC (SSD da 20 TB, NL-SAS da 130 TB)
-
LAN
2 switch Ethernet 10G 12 porte
-
SAN
2 switch FC 32/16Gb 24 porte
2 Cisco UCS FI 6332
della licenza
VMware EntPlus
Replica e/o orchestrazione dello switching delle VM
VMware EntPlus
Non ho fornito licenze software di replica per Hyperflex, poiché per noi sono già disponibili.
Per l'architettura classica ho scelto un fornitore che si è affermato come produttore di alta qualità ed economico. Per entrambe le opzioni ho applicato lo sconto standard per una soluzione specifica e di conseguenza ho ricevuto prezzi reali.
La soluzione Cisco HyperFlex si è rivelata più economica del 13%.
Script 2: creazione di due data center attivi. In questo scenario, stiamo progettando un cluster esteso su VMware.
L'architettura classica è composta da server di virtualizzazione, una SAN (protocollo FC) e due sistemi di storage in grado di leggere e scrivere sul volume esteso tra di loro. Su ogni sistema di storage mettiamo una capacità utile per lo storage.
In HyperFlex creiamo semplicemente uno Stretch Cluster con lo stesso numero di nodi su entrambi i siti. In questo caso viene utilizzato un fattore di replica pari a 2+2.
Il risultato è la seguente configurazione:
architettura classica
Iperflessibile
Server
16 server 1U (384 GB di RAM, 2 Intel Gold 6132, HBA FC, 2 NIC 10G)
16 HX240C-M5L (512 GB RAM, 2 Intel Gold 6132, 1,6 TB NVMe, 12 SSD da 3,8 TB, VIC 1387)
Magazzinaggio
2 sistemi di archiviazione AllFlash (SSD da 150 TB)
-
LAN
4 switch Ethernet 10G 24 porte
-
SAN
4 switch FC 32/16Gb 24 porte
4 Cisco UCS FI 6332
della licenza
VMware EntPlus
VMware EntPlus
In tutti i calcoli non ho tenuto conto dell'infrastruttura di rete, dei costi del data center, ecc.: saranno gli stessi per l'architettura classica e per la soluzione HyperFlex.
In termini di costi, HyperFlex si è rivelato più costoso del 5%. Vale la pena notare che in termini di risorse CPU/RAM ho avuto una distorsione per Cisco, perché nella configurazione ho riempito i canali del controller di memoria in modo uniforme. Il costo è leggermente più alto, ma non di un ordine di grandezza, il che indica chiaramente che l’iperconvergenza non è necessariamente un “giocattolo per ricchi”, ma può competere con l’approccio standard alla costruzione di un data center. Ciò potrebbe interessare anche a coloro che dispongono già di server Cisco UCS e della relativa infrastruttura.
Tra i vantaggi otteniamo l'assenza di costi per l'amministrazione di SAN e sistemi di storage, compressione e deduplicazione online, un unico punto di accesso per il supporto (virtualizzazione, server, sono anche sistemi di storage), risparmio di spazio (ma non in tutti gli scenari), semplificando il funzionamento.
Per quanto riguarda il supporto, qui lo ottieni da un fornitore: Cisco. A giudicare dalla mia esperienza con i server Cisco UCS, mi piace; non ho dovuto aprirlo su HyperFlex, tutto ha funzionato allo stesso modo. Gli ingegneri rispondono prontamente e possono risolvere non solo problemi tipici, ma anche casi limite complessi. A volte mi rivolgo a loro con domande: "È possibile farlo, fanculo?" oppure "Ho configurato qualcosa qui e non vuole funzionare. Aiuto!" - lì troveranno pazientemente la guida necessaria e indicheranno le azioni corrette; non risponderanno: "Risolviamo solo problemi hardware".
riferimenti
- La mia posta - [email protected]
Fonte: habr.com