🥇Amministratore senza mani = iperconvergenza?

Questo è un mito piuttosto comune nel campo dell'hardware server. Nella pratica, però, le soluzioni iperconvergenza (quando tutto è in uno) sono necessarie per molte ragioni. Storicamente, le prime architetture furono sviluppate da Amazon e Google per i loro servizi. L'idea era quella di creare una fattoria computazionale composta da nodi identici, ognuno dei quali aveva i propri dischi. Tutto ciò era unito da un software sistemico (hypervisor) e suddiviso in macchine virtuali. L'obiettivo principale era ridurre al minimo gli sforzi per la manutenzione di un nodo e ridurre al minimo i problemi durante la scalabilità: bastava acquistare un altro migliaio di server simili e collegarli. Nella pratica, questi casi sono isolati, e più frequentemente si parla di un numero minore di nodi e di un'architettura leggermente diversa.

Tuttavia, il vantaggio rimane lo stesso: una semplicità straordinaria nella scalabilità e nella gestione. Lo svantaggio è che diversi compiti consumano risorse in modi diversi, e in alcune situazioni ci saranno molti dischi locali, in altre poca RAM, e così via, quindi con diversi tipi di compiti ci sarà una riduzione dell'utilizzo delle risorse.

Risulta che paghi il 10–15% in più per la comodità di configurazione. È così che è nato il mito del titolo. Abbiamo cercato a lungo dove questa tecnologia fosse ottimale e abbiamo trovato la risposta. Il punto è che Cisco non aveva il proprio storage, ma voleva entrare in pieno nel mercato dei server. Così hanno creato Cisco Hyperflex: una soluzione con storage locali sui nodi.

E da questo è emersa, sorprendentemente, una soluzione molto valida per i data center di backup (Disaster Recovery). Perché e come — lo racconterò ora. E mostrerò i test del cluster.

Dove è necessario

L'iperconvergenza è:

Trasferimento dei dischi nei 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à dello storage a livello di virtualizzazione e tutto da un'unica interfaccia di gestione.

Nella nostra azienda, i progetti per la progettazione di data center di backup sono molto richiesti, e spesso si sceglie proprio una soluzione iperconvergente per la moltitudine di opzioni di replica (fino al metrocluster) incluse di default.

In caso di data center di backup, si tratta solitamente di una struttura situata in un'altra parte della città o addirittura in un'altra città. Questo consente il recupero di sistemi critici in caso di guasto parziale o totale del data center principale. I dati vengono continuamente replicati, e questa replicazione può avvenire a livello di applicazione o a livello di dispositivo di archiviazione (SAN).

Quindi, ora parlerò della struttura del sistema e delle prove, e poi di alcuni scenari di utilizzo reale con dati sui risparmi.

Test

Il nostro esemplare è composto da quattro server, ognuno con 10 dischi 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 piuttosto grezza (stando ai feedback), la seconda era ancora un po' acerba, la terza era già abbastanza stabile, e questa può essere considerata la versione finale dopo la beta-test pubblica. Durante il periodo di prova non ho riscontrato problemi, tutto funziona a meraviglia.

Modifiche nella v4Corretti numerosi bug.

Inizialmente, la piattaforma funzionava solo con il hypervisor VMware ESXi e supportava un numero limitato di nodi. Inoltre, il processo di distribuzione non sempre si concludeva con successo; a volte era necessario riavviare alcuni passaggi e c'erano problemi nell'aggiornamento da versioni precedenti. I dati nell'interfaccia grafica non venivano sempre visualizzati correttamente (anche se ora non sono ancora del tutto soddisfatto della visualizzazione dei grafici delle prestazioni) e talvolta si verificavano problemi legati alla virtualizzazione.

Ora tutte le problematiche iniziali sono state risolte, HyperFlex supporta sia ESXi che Hyper-V, e in aggiunta è possibile:

Creare un cluster distribuito.
Creare un cluster per uffici senza utilizzare Fabric Interconnect, da due a quattro nodi (acquistiamo solo server).
Possibilità di lavorare con storage 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 è stata creata una bicicletta. Funziona tutto su piattaforma di virtualizzazione VMware o Hyper-V. A livello hardware, è ospitato su server progettati internamente da Cisco UCS. Ci sono quelli che odiano la piattaforma per la relativa complessità della configurazione iniziale, per la moltitudine di pulsanti, per il sistema di modelli e dipendenze non banale, ma ci sono anche coloro che hanno raggiunto il zen, abbracciato l'idea e non vogliono più lavorare con altri server.

Considereremo specificamente la soluzione per VMware, poiché è stata originariamente sviluppata per essa e offre funzionalità superiori; Hyper-V è stato migliorato nel tempo per non rimanere indietro rispetto ai concorrenti e soddisfare le aspettative di mercato.

C'è un cluster di server dotati di dischi. Ci sono dischi per l'archiviazione dei dati (SSD o HDD, a seconda delle tue preferenze e necessità) e un disco SSD dedicato per la cache. Quando i dati vengono scritti nel datastor, vengono salvati prima nel livello di cache (disco SSD dedicato e RAM della VM di servizio). Contemporaneamente, il blocco di dati viene inviato ai nodi nel cluster (il numero di nodi dipende dal fattore di replica del cluster). Dopo aver ricevuto conferma da tutti i nodi riguardo alla scrittura avvenuta con successo, la conferma viene inviata all'iper-vista e successivamente alla VM. I dati registrati vengono deduplicati, compressi e scritti sui dischi di archiviazione in background. Durante questo processo, i dati vengono sempre scritti in blocchi grandi e in modo sequenziale, il che riduce 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 RAM. Se è configurato un sistema ibrido, anche la lettura viene messa in 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 in modo equivalente tutti i dischi e le interfacce di rete. Ne deriva un chiaro svantaggio: non possiamo ridurre al minimo la latenza di lettura, poiché non c'è alcuna garanzia della presenza locale dei dati. Tuttavia, ritengo che questo sia un sacrificio trascurabile rispetto ai benefici ottenuti. Inoltre, le latenza di rete hanno raggiunto valori tali da avere praticamente un effetto trascurabile sul risultato complessivo.

La logica di funzionamento del sistema di archiviazione è gestita da una VM di servizio speciale, il controller della piattaforma Cisco HyperFlex Data, 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, che non sono pochi. Ricordo che l'host stesso dispone di 28 core fisici e 512 GB di RAM.

La VM di servizio ha accesso diretto ai dischi fisici tramite il pass-through del controllore SAS nella VM. La comunicazione con l'ipervisor avviene tramite un modulo speciale IOVisor, che intercetta le operazioni di input/output, e attraverso un agente che consente di inviare comandi all'API dell'ipervisor. L'agente gestisce il lavoro con gli snapshot e i cloni di HyperFlex.

Nel hypervisor, le risorse disco vengono montate come condivisioni NFS o SMB (a seconda del tipo di hypervisor, indovinate quale sia quale). Ma sotto il cofono si tratta di un file system distribuito, che consente di aggiungere funzionalità di livelli enterprise: assegnazione sottile dei volumi, compressione e deduplicazione, snapshot con tecnologia Redirect-on-Write, replica sincrona/asincrona.

La VM di servizio fornisce accesso all'interfaccia WEB per la gestione del sottosistema HyperFlex. C'è integrazione con vCenter, e gran parte delle attività quotidiane può essere eseguita da lì, ma i data store, ad esempio, sono più facili da gestire tramite una web app separata, se sei già passato all'interfaccia HTML5 rapida, o utilizzare il client Flash completo con integrazione totale. Nella web app di servizio puoi visualizzare le prestazioni e lo stato dettagliato del sistema.

Esiste un altro tipo di nodi nel cluster: i nodi di calcolo. Questi possono essere server rack o blade privi di dischi integrati. Su questi server è possibile eseguire VM i cui dati sono memorizzati su server con dischi. Dal punto di vista dell'accesso ai dati, non ci sono differenze tra i tipi di nodi, poiché l'architettura prevede l'astrazione dalla posizione fisica dei dati. Il rapporto massimo tra nodi di calcolo e nodi di archiviazione è di 2:1.

L'uso dei nodi di calcolo aumenta la flessibilità nella scalabilità delle risorse del cluster: non è necessario acquistare nodi con dischi se abbiamo bisogno solo di CPU/RAM. Inoltre, possiamo aggiungere un blade enclosures e ottenere risparmi sullo spazio dei server nel rack.

In conclusione, 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 un fattore di replicazione di 2 e 3.
Metro-cluster.
Replica asincrona delle VM su un altro cluster HyperFlex.
Orchestrazione della commutazione delle VM in un data center remoto.
Snapshot nativi con tecnologia Redirect-on-Write.
Fino a 1 PB di spazio utile con un fattore di replica di 3 e senza considerare la deduplicazione. Il fattore di replica 2 non è preso in considerazione, poiché non è una scelta per vendite serie.

Un'altra grande vantaggio è la semplicità di gestione e distribuzione. 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, funzionanti 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/rank doppio/x4/1.2v

Network 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 Ethernet 10G

Storage HBA

Controller passante SAS modulare Cisco 12G

Dischi di storage

1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB

Ulteriori opzioni di configurazioneOltre all'hardware selezionato, attualmente sono disponibili le seguenti opzioni:

HXAF240c M5.
Uno o due CPU 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 dati, un disco di cache, un disco di sistema e un disco di avvio.

Unità di capacità

HX-SD960G61X-EV 960GB SSD SATA da 2,5 pollici Enterprise Value 6G (1X endurance) SAS 960 GB.
HX-SD38T61X-EV SSD SATA da 2,5 pollici Enterprise Value 6G 3.8TB (1X endurance) SAS 3.8 TB.
Unità di caching
HX-NVMEXPB-I375 Unità Intel Optane da 2,5 pollici da 375GB, performance estrema e durata.
HX-NVMEHW-H1600* SSD NVMe da 2,5 pollici Ent. Perf. da 1,6TB (3X endurance) NVMe 1,6 TB.
HX-SD400G12TX-EP SSD SAS da 2,5 pollici Ent. Perf. 12G da 400GB (10X endurance) SAS 400 GB.
HX-SD800GBENK9** SSD SED SAS da 2,5 pollici Ent. Perf. 12G da 800GB (10X endurance) SAS 800 GB.
HX-SD16T123X-EP SSD SAS da 2,5 pollici Enterprise performance 12G da 1,6TB (3X endurance).

Unità di sistema / registro

HX-SD240GM1X-EV SSD SATA da 2,5 pollici Enterprise Value 6G da 240GB (richiede aggiornamento).

Unità di avvio

HX-M2-240GB SSD SATA M.2 da 240GB 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. Si tratta di un'utilità gratuita che consente di automatizzare la generazione di carichi di lavoro da più macchine virtuali. Il carico stesso è generato da fio standard.

Il nostro cluster è composto da quattro nodi, fattore di replica 3, tutte le unità Flash.

Per il test ho creato quattro datastore e otto macchine virtuali. Per i test di scrittura si presume uno scenario in cui l'unità di caching non è sovraccarica.

I risultati dei test sono i seguenti:

100 % Lettura 100 % Random

0 % Lettura 100% Random

Blocco / profondità della coda

128

256

512

1024

2048

128

256

512

1024

2048

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

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 soglie oltre le quali non si osserva un aumento delle prestazioni, talvolta anche una evidente degradazione. Ciò è dovuto al fatto che si raggiungono i limiti delle prestazioni della rete/controllori/dischi.

Lettura sequenziale 4432 MB/s.
Scrittura sequenziale 804 MB/s.
In caso di guasto di un controller (guasto della macchina virtuale o dell'host), la caduta delle prestazioni è pari al 50%.
In caso di guasto di un disco di storage, la caduta delle prestazioni è di un terzo. Il rebuilding del disco occupa il 5% delle risorse di ciascun controller.

Nel piccolo blocco ci scontriamo con le prestazioni del controller (macchina virtuale), la sua CPU è al 100% di utilizzo; aumentando il blocco ci troviamo di fronte alla capacità di banda dei porti. 10 Gbit/s non sono sufficienti per sfruttare il potenziale del sistema AllFlash. Purtroppo, le specifiche della demo fornita non consentono di testare il funzionamento a 40 Gbit/s.

Dalla mia impressione nei test e nello studio dell'architettura, grazie all'algoritmo che distribuisce i dati tra tutti gli host, otteniamo prestazioni scalabili e prevedibili; ma questo rappresenta anche un limite nella lettura, poiché dai dischi locali si potrebbe estrarre di più. Qui potrebbe aiutare una rete più performante, ad esempio, disponibili FI a 40 Gbit/s.

Anche un solo disco per caching e deduplicazione può rappresentare un limite; in questo stand, infatti, possiamo scrivere su quattro dischi SSD. Sarebbe fantastico poter aumentare il numero di dischi per il caching e vedere la differenza.

Utilizzo reale

Per organizzare un centro dati secondario, si possono adottare due approcci (non consideriamo il posizionamento del backup in una location remota):

Attivo-Passivo. Tutte le applicazioni sono ospitate nel data center principale. La replica può essere sincrona o asincrona. In caso di malfunzionamento del data center principale, dobbiamo attivare quello di riserva. Questo può essere fatto manualmente / tramite script / applicazioni di orchestrazione. Qui otteniamo un RPO comparabile con la frequenza di replica, e l'RTO dipende dalla reazione e dalle capacità dell'amministratore e dalla qualità della pianificazione / debugging del piano di failover.
Attivo-Attivo. In questo caso è presente solo la replica sincrona, la disponibilità dei data center è determinata da un quorum / arbitro, situato rigorosamente in una terza sede. RPO = 0 e l'RTO può arrivare a 0 (se l'applicazione lo consente) o corrispondere 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 un array di dischi attivo-attivo.

Di solito vediamo clienti con architetture già realizzate basate su storage tradizionali nei loro data center principali, quindi progettiamo un'altra architettura per la replica. Come ho già accennato, Cisco HyperFlex offre replicazione asincrona e la possibilità di creare un cluster di virtualizzazione esteso. In questo modo, non abbiamo bisogno di uno storage dedicato di livello Midrange o superiore con costose funzionalità di replicazione e accesso Active-Active ai dati su due storage.

Scenario 1: Abbiamo un data center principale e uno di riserva, con una piattaforma di virtualizzazione basata su VMware vSphere. Tutti i sistemi produttivi si trovano nel data center principale, mentre la replica delle macchine virtuali avviene a livello di hypervisor, il che significa che non è necessario mantenere le VM accese nel data center di riserva. I database e le applicazioni speciali vengono replicati utilizzando gli strumenti integrati e le VM rimangono accese. In caso di malfunzionamento del data center principale, attiviamo i sistemi nel data center di riserva. Stimiamo che abbiamo circa 100 macchine virtuali. Finché il data center principale è operativo, nel data center di riserva è possibile avviare ambienti di test e altri sistemi che possono essere disattivati in caso di commutazione del data center principale. È inoltre possibile utilizzare la replica bidirezionale. Dal punto di vista hardware, non ci saranno cambiamenti.

In caso di architettura classica, installeremo uno storage ibrido in ogni centro dati con accesso tramite FibreChannel, tiering, deduplicazione e compressione (ma non online), 8 server per ciascun sito, con 2 switch FibreChannel e Ethernet 10G. Per la replica e la gestione dello switch in architettura classica, possiamo utilizzare strumenti VMware (Replication + SRM) o soluzioni di terze parti che saranno un po' più economiche e talvolta più comode.

Nello schema è presentata la configurazione.

Nel caso di utilizzo di Cisco HyperFlex, si ottiene la seguente architettura:

Per HyperFlex ho utilizzato server con risorse elevate di CPU/RAM, poiché parte delle risorse andrà alla VM del controller HyperFlex. Ho addirittura sovradimensionato un po' le risorse nella configurazione di HyperFlex, per non favorire Cisco e garantire risorse per le altre VM. Inoltre, possiamo rinunciare agli switch FibreChannel, e non avremo bisogno di porte Ethernet per ciascun server; il traffico locale viene commutato all'interno del FI.

Alla fine, si ottiene la seguente configurazione per ciascun 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)

Storage ibrido

Storage ibrido con front-end FC (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 VM

VMware Ent Plus

Non ho incluso licenze per software di replica per Hyperflex, poiché è disponibile di default.

Per l'architettura classica ho scelto un fornitore che si è dimostrato un produttore di qualità e a buon prezzo. Ho applicato a entrambi le tariffe standard del settore, ottenendo prezzi reali.

La soluzione su Cisco HyperFlex è risultata il 13% più economica.

Scenario 2: creazione di due data center attivi. In questo scenario progettiamo un cluster esteso su VMware.

L'architettura classica è composta da server di virtualizzazione, SAN (protocollo FC) e due storage che possono leggere e scrivere su quello, esteso tra di loro. Su ciascuno storage prevediamo una capacità utile per la location.

Su HyperFlex creiamo semplicemente un Stretch Cluster con lo stesso numero di nodi su entrambi i siti. In questo caso si utilizza un fattore di replica 2+2.

È stata ottenuta la seguente configurazione:

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)

Storage ibrido

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

Nei miei calcoli non ho considerato l'infrastruttura di rete, i costi del data center, ecc.: saranno gli stessi sia per l'architettura classica che per la soluzione HyperFlex.

In termini di costi, HyperFlex risulta essere il 5% più costoso. È importante notare che per quanto riguarda le risorse CPU/RAM ho riscontrato uno sbilanciamento nella configurazione Cisco, poiché ho riempito i canali dei controller di memoria in modo uniforme. Il costo è leggermente superiore, ma non di molto, 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. Inoltre, questo potrebbe essere interessante per coloro che hanno già server Cisco UCS e l'infrastruttura corrispondente.

I vantaggi includono l'assenza di costi per la gestione di SAN e SDD, la compressione e la deduplica online, un unico punto di accesso per il supporto (virtualizzazione, server, stessi SDD), riduzione dello spazio (ma non in tutti gli scenari) e semplificazione della gestione.

Per quanto riguarda il supporto, lo ricevi da un solo fornitore: Cisco. Basandomi sulla mia esperienza con i server Cisco UCS, mi piace, non ho dovuto nemmeno aprire HyperFlex, tutto funzionava già bene. Gli ingegneri rispondono rapidamente e possono risolvere non solo problemi standard, ma anche casi complessi. A volte li contatto con domande del tipo: «Si può fare così, attaccare questo?» oppure «Ho configurato qualcosa qui e non funziona. Aiutatemi!» — sono pazienti e trovano la guida giusta per indicare le azioni corrette, non risponderanno con: «Ci occupiamo solo dei problemi hardware».