Questo è un mito piuttosto diffuso nel campo dell'hardware server. Nella pratica, tuttavia, le soluzioni iperconvergenti (dove tutto è in uno) sono necessarie per molti motivi. Storicamente, le prime architetture furono sviluppate da Amazon e Google per i loro servizi. All'epoca l'idea era di creare una fattoria di calcolo composta da nodi identici, ognuno dei quali dispone di dischi propri. Tutto questo veniva unito tramite un certo software di sistema (iper-vvisor) e suddiviso in macchine virtuali. L'obiettivo principale era ridurre al minimo gli sforzi per la gestione di un nodo e minimizzare i problemi durante la scalabilità: bastava acquistare un migliaio di server simili e collegarli accanto. Nella pratica, questi sono casi isolati, e più spesso si parla di un numero inferiore di nodi e un'architettura leggermente diversa.
Ma il vantaggio rimane lo stesso: un'incredibile semplicità di scalabilità e gestione. Lo svantaggio è che diversi compiti consumano risorse in modi diversi, e in alcuni casi ci saranno molti dischi locali, in altri poca memoria e così via, quindi con compiti diversi si verificherà una diminuzione dell'utilizzazione delle risorse.
Si scopre che si paga il 10-15% in più per la comodità della configurazione. Questo ha generato il mito del titolo. Abbiamo cercato a lungo dove la tecnologia sarebbe stata utilizzata in modo ottimale, e l'abbiamo trovata. Il fatto è che Cisco non aveva i propri sistemi di archiviazione, ma voleva coprire l'intero mercato dei server. Così hanno realizzato Cisco Hyperflex: una soluzione con archiviazione locale sui nodi.
Da ciò è emerso improvvisamente un'ottima soluzione per i data center di backup (Disaster Recovery). Perché e come — ora lo racconterò. E mostrerò i test del cluster.
Dove serve
L'iperconvergenza è:
- Trasferimento dei dischi nei nodi di calcolo.
- Integrazione completa del sottosistema di archiviazione con il sottosistema di virtualizzazione.
- Trasferimento/integrazione con il sottosistema di rete.
Questa combinazione consente di realizzare molte funzionalità degli storage a livello di virtualizzazione e tutto da un'unica interfaccia di gestione.
Nella nostra azienda sono molto richiesti progetti di progettazione di data center di backup, e spesso viene scelta proprio la soluzione iperconvergente per la moltitudine di opzioni di replica (fino al metrocluster) disponibili out of the box.
Nel caso dei data center di riserva, si parla solitamente di un sito remoto situato all'altro capo della città o addirittura in un'altra città. Questo consente di ripristinare sistemi critici in caso di guasti parziali o totali del data center principale. I dati vengono continuamente replicati dal server di produzione e questa replicazione può avvenire a livello applicativo o a livello di dispositivo di memorizzazione (storage condiviso).
Pertanto, ora parlerò della configurazione del sistema e dei test, e poi di alcuni scenari di applicazione reale con dati sui risparmi.
Test
Il nostro esempio è composto da quattro server, ognuno dei quali ha 10 SSD da 960 GB. C'è un disco dedicato per la cache delle operazioni di scrittura e per la memorizzazione della macchina virtuale di servizio. La soluzione stessa è la quarta versione. La prima era chiaramente acerba (secondo le recensioni), la seconda era ancora un po' incongruente, la terza è già abbastanza stabile, mentre questa può essere considerata un rilascio dopo la fine dei test beta per il grande pubblico. Durante il periodo di prova non ho riscontrato problemi, tutto funziona come un orologio.
Cambiamenti in v4Correzione di numerosi bug.
Inizialmente, la piattaforma poteva funzionare solo con il hypervisor VMware ESXi e supportava un numero limitato di nodi. Inoltre, il processo di implementazione spesso non si concludeva con successo, era necessario riavviare alcuni passaggi, c'erano problemi con l'aggiornamento dalle versioni precedenti, i dati nell'interfaccia grafica non venivano sempre visualizzati correttamente (anche se ora non sono entusiasta della visualizzazione dei grafici delle prestazioni), a volte si presentavano problemi legati alla virtualizzazione.
Ora tutte le malattie infantili sono state corrette, HyperFlex supporta sia ESXi che Hyper-V, in aggiunta a questo è possibile:
- Creare un cluster distribuito.
- Creare un cluster per uffici senza utilizzare Fabric Interconnect, da due a quattro nodi (acquistiamo solo i server).
- Possibilità di lavorare con storage condiviso esterni.
- Supporto per contenitori e Kubernetes.
- Creazione di zone di disponibilità.
- Integrazione con VMware SRM, se le funzionalità integrate non sono soddisfacenti.
L'architettura non si discosta molto dalle soluzioni dei principali concorrenti, non abbiamo reinventato la ruota. Tutto ciò funziona su una piattaforma di virtualizzazione VMware o Hyper-V. A livello hardware viene installato su server sviluppati internamente da Cisco UCS. Ci sono quelli che odiano la piattaforma per la relativa complessità della configurazione iniziale, il gran numero di pulsanti, un sistema di modelli e dipendenze non triviale, ma ci sono anche quelli che hanno raggiunto il zen, si sono appassionati all'idea e non vogliono più lavorare con altri server.
Esamineremo specificamente la soluzione per VMware, poiché è stata originariamente creata per essa e ha un funzionalità maggiore; Hyper-V è stato migliorato nel tempo per non rimanere indietro rispetto ai concorrenti e per soddisfare le aspettative del mercato.
C'è un cluster di server, dotato di dischi. Ci sono dischi per l'archiviazione dei dati (SSD o HDD, a seconda delle tue preferenze e necessità), e un disco SSD per la cache. Quando i dati vengono scritti nel datastore, vengono salvati nella layer di caching (un SSD dedicato e RAM della VM di service). Parallelamente, il blocco di dati viene inviato ai nodi nel cluster (il numero di nodi dipende dal fattore di replicazione del cluster). Dopo la conferma di scrittura da tutti i nodi, la conferma della scrittura viene inviata all'hypervisor e poi alla VM. I dati scritti vengono deduplicati, compressi e registrati su dischi di archiviazione in background. In questo modo, su dischi di archiviazione viene sempre scritto un grande blocco in modo sequenziale, riducendo il carico sui dischi di archiviazione.
La deduplicazione e la compressione sono sempre attive e non possono essere disattivate. La lettura dei dati avviene direttamente dai dischi di archiviazione o dalla cache della RAM. Se è configurata una configurazione ibrida, anche la lettura viene memorizzata nella cache su disco SSD.
I dati non sono legati alla posizione attuale della macchina virtuale e vengono distribuiti uniformemente tra i nodi. Questo approccio consente di caricare uniformemente tutti i dischi e le interfacce di rete. C'è un evidente svantaggio: non possiamo ridurre al minimo la latenza della lettura, poiché non c'è garanzia che i dati siano locali. Ma ritengo che sia un sacrificio trascurabile rispetto ai benefici ottenuti. Inoltre, le latenze di rete hanno raggiunto valori tali da non influenzare praticamente il risultato complessivo.
Per tutta la logica di funzionamento del sottosistema di archiviazione risponde una speciale VM di servizio Cisco HyperFlex Data Platform controller, che viene creata su ogni nodo di archiviazione. Nella nostra configurazione, alla VM di servizio sono stati assegnati otto vCPU e 72 GB di RAM, il che non è affatto poco. Ricordo che l'host stesso dispone di 28 core fisici e 512 GB di RAM.
La VM di servizio ha accesso ai dischi fisici direttamente tramite il passaggio del controller SAS nella VM. La comunicazione con l'iper-V avviene attraverso un modulo speciale IOVisor, che intercetta le operazioni di input-output, e tramite un agente che consente di inviare comandi all'API dell'iper-V. L'agente si occupa della gestione degli snapshot HyperFlex e dei cloni.
Nel hypervisor, le risorse discali sono montate come NFS o SMB share (a seconda del tipo di hypervisor, indovinate quale dove). Sotto il cofano c'è un file system distribuito, che consente di aggiungere funzionalità da veri sistemi di archiviazione: allocazione sottile dei volumi, compressione e deduplicazione, snapshot con tecnologia Redirect-on-Write, replica sincrona/asincrona.
La VM di servizio fornisce accesso all'interfaccia WEB di gestione del sottosistema HyperFlex. C'è integrazione con vCenter e gran parte delle attività quotidiane può essere eseguita da lì, ma i datastore, ad esempio, è più comodo crearli da una web separata, se avete già passato all'interfaccia veloce HTML5, oppure utilizzare un client Flash completo con piena integrazione. Nella web di servizio è possibile consultare le prestazioni e lo stato dettagliato del sistema.
Esiste anche un altro tipo di nodi nel cluster: i nodi di calcolo. Questi possono essere server rack o blade senza dischi integrati. Su questi server è possibile eseguire VM i cui dati sono archiviati su server con dischi. Da un punto di vista dell'accesso ai dati, non c'è differenza tra i tipi di nodi, poiché l'architettura prevede un'astrazione dalla posizione fisica dei dati. Il massimo rapporto tra nodi di calcolo e nodi di archiviazione è 2:1.
L'uso di nodi di calcolo aumenta la flessibilità nella scalabilità delle risorse del cluster: non è necessario acquistare nodi con dischi se abbiamo solo bisogno di CPU/RAM. Inoltre, possiamo aggiungere un blade basket e ottenere risparmi sulla collocazione dei server nel rack.
Di conseguenza, abbiamo una piattaforma iperconvergente con le seguenti funzionalità:
- Fino a 64 nodi nel cluster (fino a 32 nodi di archiviazione).
- Il numero minimo di nodi nel cluster è tre (due per il cluster Edge).
- Meccanismo di ridondanza dei dati: mirroring con fattore di replicazione 2 e 3.
- Metro-cluster.
- Replicazione asincrona delle VM su un altro cluster HyperFlex.
- Orchestrazione del failover delle VM verso un data center remoto.
- Snapshot nativi con tecnologia Redirect-on-Write.
- Fino a 1 PB di spazio utile con fattore di replicazione 3 e senza considerare la deduplicazione. Il fattore di replicazione 2 non è considerato, poiché non è una soluzione per un ambiente di produzione serio.
Un altro enorme vantaggio è la semplicità nella gestione e nel deployment. Tutte le complessità della configurazione dei server UCS sono gestite da una VM specializzata, preparata dagli ingegneri Cisco.
Configurazione del banco di prova:
- 2 x Cisco UCS Fabric Interconnect 6248UP come cluster di gestione e componenti di rete (48 porte in modalità Ethernet 10G/FC 16G).
- Quattro server Cisco UCS HXAF240 M4.
Caratteristiche dei server:
CPU
2 x Intel ® Xeon ® E5-2690 v4
RAM
16 x 32GB DDR4-2400-MHz RDIMM/PC4-19200/dual rank/x4/1.2v
Network global log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats timeout 30s user haproxy group haproxy daemondefaults log global mode http option httplog option dontlognull timeout connect 5000 timeout client 50000 timeout server 50000frontend http_front bind *:80 stats uri /haproxy?stats default_backend http_backbackend http_back balance roundrobin server server_name1 private_ip1:80 check server server_name2 private_ip2:80 check
UCSC-MLOM-CSC-02 (VIC 1227). 2 porte 10G Ethernet
Storage HBA
Cisco 12G Modular SAS Pass through Controller
Storage Disks
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Maggiore varietà di configurazioniOltre all'hardware selezionato, attualmente sono disponibili le seguenti opzioni:
- HXAF240c M5.
- Uno o due CPU a partire da Intel Silver 4110 a Intel Platinum I8260Y. Disponibile la seconda generazione.
- 24 slot di memoria, moduli da 16 GB RDIMM 2600 a 128 GB LRDIMM 2933.
- Da 6 a 23 dischi per i dati, un disco di caching, un disco di sistema e un disco di avvio.
Capacity Drives
- HX-SD960G61X-EV 960GB 2,5 pollici Enterprise Value 6G SATA SSD (1X endurance) SAS 960 GB.
- HX-SD38T61X-EV 3,8TB 2,5 pollici Enterprise Value 6G SATA SSD (1X endurance) SAS 3,8 TB.
- Caching Drives
- HX-NVMEXPB-I375 375GB 2,5 pollici Intel Optane Drive, Extreme Perf & Endurance.
- HX-NVMEHW-H1600* 1,6TB 2,5 pollici Ent. Perf. NVMe SSD (3X endurance) NVMe 1,6 TB.
- HX-SD400G12TX-EP 400GB 2,5 pollici Ent. Perf. 12G SAS SSD (10X endurance) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2,5 pollici Ent. Perf. 12G SAS SED SSD (10X endurance) SAS 800 GB.
- HX-SD16T123X-EP 1,6TB 2,5 pollici Enterprise performance 12G SAS SSD (3X endurance).
System / Log Drives
- HX-SD240GM1X-EV 240GB 2,5 pollici Enterprise Value 6G SATA SSD (Richiede aggiornamento).
Boot Drives
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.
Connessione di rete tramite porte Ethernet 40G, 25G o 10G.
Come FI possono essere utilizzati HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Il test stesso
Per testare il sottosistema di archiviazione ho utilizzato HCIBench 2.2.1. È un'utility gratuita che consente di automatizzare la creazione di un carico di lavoro tramite diverse macchine virtuali. Il carico stesso è generato da fio normale.
Il nostro cluster è composto da quattro nodi, fattore di replicazione 3, tutti i dischi Flash.
Per il test ho creato quattro datastore e otto macchine virtuali. Per i test di scrittura, si presume che il disco di cache non sia sovraccarico.
I risultati dei test sono i seguenti:
100 % Lettura 100 % Casual
0 % Lettura 100 % Casual
Blocco / profondità della 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 IOPS
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 376484 IOPS
5,47 ms 373176 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
I valori in grassetto indicano i punti dopo i quali non c'è aumento delle prestazioni, talvolta si osserva anche una degradazione. Questo è dovuto al fatto che ci scontriamo con la capacità di rete / controllori / dischi.
- Lettura sequenziale 4432 MB/s.
- Scrittura sequenziale 804 MB/s.
- In caso di guasto di un controller (guasto di una macchina virtuale o di un host), la perdita di prestazioni è di circa la metà.
- In caso di guasto di un disco di storage, la perdita è di 1/3. Il rebuild del disco richiede il 5% delle risorse di ogni controller.
Con blocchi piccoli ci scontriamo con la performance del controller (macchina virtuale), il suo CPU è carico al 100%, mentre aumentando il blocco ci scontriamo con la larghezza di banda delle porte. 10 Gbit/s non è sufficiente per sfruttare il potenziale del sistema AllFlash. Purtroppo, non è possibile testare il funzionamento su 40 Gbit/s a causa delle specifiche del demo fornito.
Secondo le mie impressioni dai test e dallo studio dell'architettura, grazie all'algoritmo che distribuisce i dati tra tutti gli host, otteniamo prestazioni scalabili e prevedibili, ma questo rappresenta anche un vincolo durante la lettura, poiché dai dischi locali sarebbe possibile ottenere di più; qui potrebbe aiutare una rete più performante, ad esempio, ci sono FI disponibili a 40 Gbit/s.
Un singolo disco per la cache e la deduplicazione può fungere da vincolo; in effetti, in questa configurazione possiamo scrivere su quattro dischi SSD. Sarebbe fantastico avere la possibilità di aumentare il numero di dischi di cache e vedere la differenza.
Utilizzo reale
Per organizzare un centro dati di backup si possono utilizzare due approcci (l'assegnazione del backup a una sede remota non è considerata):
- Active-Passive. Tutti le applicazioni sono collocate principalmente nel Data Center principale. La replica è sincrona o asincrona. In caso di guasto del Data Center principale, dobbiamo attivare quello secondario. Questo può essere fatto manualmente/script o tramite applicazioni di orchestrazione. Qui otteniamo un RPO comparabile alla frequenza di replica, e l'RTO dipende dalla reazione e dalle capacità dell'amministratore e dalla qualità della preparazione/debugging del piano di failover.
- Active-Active. In questo caso è presente solo replica sincrona, la disponibilità dei Data Center è determinata da un quorum/arbiter, situato rigorosamente in una terza posizione. RPO = 0, mentre l'RTO può raggiungere 0 (se l'applicazione lo consente) o è pari al tempo necessario per gestire il guasto di un nodo nel cluster di virtualizzazione. A livello di virtualizzazione viene creato un cluster esteso (Metro), che richiede una SAN Active-Active.
Di solito vediamo i clienti con un'architettura già realizzata con una SAN tradizionale nel Data Center principale, quindi progettiamo un'altra per la replica. Come ho già accennato, Cisco HyperFlex offre replica asincrona e la creazione di un cluster di virtualizzazione esteso. Non abbiamo bisogno di una SAN di livello Midrange e superiore con costose funzioni di replica e accesso Active-Active ai dati su due SAN.
Scenario 1: Abbiamo un Data Center principale e uno secondario, una piattaforma di virtualizzazione su VMware vSphere. Tutti i sistemi produttivi si trovano nel Data Center principale, e la replica delle macchine virtuali avviene a livello di hypervisor, il che permette di non mantenere le VM accese nel Data Center secondario. I database e le applicazioni speciali vengono replicati con strumenti integrati e manteniamo le VM accese. In caso di guasto del Data Center principale, avviamo i sistemi nel Data Center secondario. Stimeamo di avere circa 100 macchine virtuali. Finché il Data Center principale è attivo, nel Data Center secondario possono essere avviati ambienti di test e altri sistemi che possono essere spenti in caso di failover del Data Center principale. È anche possibile una configurazione in cui utilizziamo replica bidirezionale. Dal punto di vista hardware, nulla cambierà.
Nel caso di architettura classica, installeremo ogni centro dati con uno storage ibrido con accesso Fibre Channel, tiering, deduplicazione e compressione (ma non online), 8 server per ogni sito, 2 switch Fibre Channel e Ethernet 10G. Per la replica e la gestione dello switch nell'architettura classica, possiamo utilizzare gli strumenti VMware (Replication + SRM) o strumenti di terze parti, che saranno un po' più economici e a volte più convenienti.
Nella figura è mostrato lo schema.
Nel caso dell'uso di Cisco HyperFlex, si ottiene la seguente architettura:
Per HyperFlex ho utilizzato server con elevate risorse CPU/RAM, poiché parte delle risorse andrà alle VM del controller HyperFlex; per CPU e memoria ho anche leggermente sovradimensionato nella configurazione di HyperFlex, per non dare vantaggi a Cisco e garantire risorse per le altre VM. Così possiamo rinunciare agli switch Fibre Channel e non avremo bisogno di porte Ethernet per ogni server, il traffico locale è commutato all'interno di FI.
In conclusione, la seguente configurazione è stata ottenuta per ogni centro dati:
Server
8 x Server 1U (384 GB RAM, 2 x Intel Gold 6132, FC HBA)
8 x HX240C-M5L (512 GB RAM, 2 x Intel Gold 6150, 3,2 GB SSD, 10 x 6 TB NL-SAS)
Sistemi di archiviazione
Storage ibrido con FC Front-End (20TB SSD, 130 TB NL-SAS)
—
LAN
2 x switch Ethernet 10G 12 porte
—
SAN
2 x switch FC 32/16Gb 24 porte
2 x Cisco UCS FI 6332
Licenze
VMware Ent Plus
Replica e/o orchestrazione del passaggio delle VM
VMware Ent Plus
Per Hyperflex non ho previsto licenze per il software di replica, poiché è disponibile out-of-the-box.
Per l'architettura classica ho scelto un fornitore che si è affermato come un produttore di qualità e a buon mercato. Per entrambe le opzioni ho applicato sconti standard per la specifica soluzione, e ho ottenuto prezzi reali.
La soluzione su Cisco HyperFlex è risultata essere più economica del 13%.
Scenario 2: creazione di due centri dati attivi. In questo scenario stiamo progettando un cluster distribuito su VMware.
L'architettura classica è composta da server di virtualizzazione, SAN (protocollo FC) e due storage, che sono in grado di leggere e scrivere sui dati distribuiti tra di loro. Su ogni storage prevede una capacità utile per il locale.
Con HyperFlex creiamo semplicemente un Stretch Cluster con lo stesso numero di nodi in entrambe le sedi. In questo caso si utilizza un fattore di replica 2+2.
La seguente configurazione è stata ottenuta:
Architettura classica
HyperFlex
Server
16 x Server 1U (384 GB RAM, 2 x Intel Gold 6132, FC HBA, 2 x 10G NIC)
16 x HX240C-M5L (512 GB RAM, 2 x Intel Gold 6132, 1,6 TB NVMe, 12 x 3,8 TB SSD, VIC 1387)
Sistemi di archiviazione
2 x Storage AllFlash (150 TB SSD)
—
LAN
4 x switch Ethernet 10G 24 porte
—
SAN
4 x switch FC 32/16Gb 24 porte
4 x Cisco UCS FI 6332
Licenze
VMware Ent Plus
VMware Ent Plus
In tutti i calcoli non ho considerato l'infrastruttura di rete, i costi del centro dati, ecc.: saranno gli stessi per l'architettura tradizionale e per la soluzione su HyperFlex.
Sul costo, HyperFlex è risultato essere più costoso del 5%. Qui vale la pena notare che per le risorse CPU/RAM ho riscontrato uno sbilanciamento a favore di Cisco, poiché nella configurazione ho uniformato i canali dei controller di memoria. Il costo è leggermente superiore, ma non di molto, il che indica chiaramente che l'iperconvergenza non è necessariamente "un giocattolo per i ricchi", ma può competere con l'approccio standard alla costruzione di centri dati. Questo potrebbe interessare anche coloro che possiedono già server Cisco UCS e un'infrastruttura adeguata.
Tra i vantaggi, avremo l'assenza di costi per l'amministrazione di SAN e storage, compressione e deduplicazione online, un unico punto di accesso per il supporto (virtualizzazione, server, ossia - storage), risparmio di spazio (sebbene non in tutti gli scenari), semplificazione dell'operatività.
Per quanto riguarda il supporto, qui lo ricevete da un unico fornitore - Cisco. Se giudico in base all'esperienza con i server Cisco UCS, mi piace, su HyperFlex non ho mai dovuto intervenire, tutto funzionava. Gli ingegneri rispondono rapidamente e possono affrontare non solo problemi comuni, ma anche casi critici complessi. A volte li contatto con domande: "È possibile fare così, collegare questo?" o "Ho configurato qualcosa ed esso non funziona. Aiutatemi!" - lì pazientemente trovano la guida necessaria e indicano le azioni corrette, non diranno: "Ci occupiamo solo di problemi hardware".
Link
- La mia email è StGeneralov@croc.ru
Fonte: habr.com
