Abbiamo conosciuto Diamanti per la prima volta due anni fa al KubeCon 2017 e siamo rimasti colpiti dalla loro visione: fornire una piattaforma container bare metal creata appositamente per microservizi e ambienti cloud-native e ottimizzata per Kubernetes o, fondamentalmente, una piattaforma iperconvergente. Appliance dell'infrastruttura per Kubernetes. Abbiamo visto questo come un'iniziativa interessante e l'anno scorso al KubeCon 2018 abbiamo iniziato a parlare con loro della collaborazione con noi per comprendere lo storage su Kubernetes e come lo storage Kubernetes possa essere testato e quantificato in modo metodico in modo da poter iniziare a testare e documentare Prestazioni di archiviazione Kubernetes.
Abbiamo conosciuto Diamanti per la prima volta due anni fa al KubeCon 2017 e siamo rimasti colpiti dalla loro visione: fornire una piattaforma container bare metal creata appositamente per microservizi e ambienti cloud-native e ottimizzata per Kubernetes o, fondamentalmente, una soluzione iperconvergente Appliance dell'infrastruttura per Kubernetes. Abbiamo considerato questo come un'iniziativa interessante e l'anno scorso al KubeCon 2018 abbiamo iniziato a parlare con loro della collaborazione per comprendere lo spazio di archiviazione su Kubernetes e come lo spazio di archiviazione Kubernetes può essere testato e quantificato in modo metodico in modo da poter iniziare a testare e documentare Prestazioni di archiviazione Kubernetes.
È stato fantastico lavorare con Diamanti e siamo stati in grado di fornirci la profonda conoscenza di Kubernetes e dello storage Kubernetes di cui avevamo bisogno per creare la nostra metodologia di test. Diamanti è stata fondata da ex ingegneri VMware, VERITAS e Cisco ed è finanziata da Goldman Sachs e altri noti VC, il che è impressionante, ma ciò che è ancora più impressionante è che Diamanti ha contribuito in modo determinante agli standard di archiviazione e rete (vale a dire FlexVolume/CSI e CNI) che sono stati accettati nel codice Kubernetes a monte.
Il business aziendale si sta evolvendo alla velocità della luce e le aziende stanno cercando di tenere il passo con questa evoluzione con nuove tecnologie per accelerare l’intero ciclo di produzione delle applicazioni. I container erano la tecnologia progettata per accelerare lo sviluppo e la distribuzione delle applicazioni, ma costruirli su un'infrastruttura legacy può essere complicato e diventa rapidamente un ostacolo considerevole per strutturare uno stack di container completamente funzionale. I container sono incompatibili con lo storage tradizionale e l’infrastruttura di rete, quindi un approccio fai-da-te alla creazione di un ambiente container è impegnativo per il IT, costoso e lento. La piattaforma Diamanti Enterprise Kubernetes è pensata per offrire agli architetti dell'infrastruttura, alle operazioni IT e ai proprietari di applicazioni la velocità, la semplicità, l'efficienza e il controllo di cui hanno bisogno per eseguire applicazioni containerizzate con stato su larga scala.
La Diamanti Enterprise Kubernetes Platform è una piattaforma container bare metal focalizzata sugli aspetti di rete e storage necessari per essere operativi velocemente, soprattutto per le grandi aziende. Con Docker open source e Kubernetes completamente integrati, insieme a hardware appositamente creato e supporto completo per l'intero stack, la piattaforma Diamanti Enterprise Kubernetes è una soluzione container completa che può essere implementata in pochi minuti. Diamanti afferma di avere prestazioni e utilizzo senza pari sulla sua piattaforma Enterprise Kubernetes; la salsa segreta per queste prestazioni è l'utilizzo di un'architettura iperconvergente unica progettata specificamente per il modo in cui i contenitori Kubernetes utilizzano le risorse di rete e di archiviazione.
Specifiche Diamanti D10
| Network NetPoulSafe | 4×10 GbE tramite una singola connessione QSFP+ (per nodo) |
| Archiviazione | |
| Archiviazione dei dati | Configurazione da 4 TB (4 SSD NVMe da 1000 GB per nodo) Configurazione da 8 TB (4 SSD NVMe da 2000 GB per nodo) Configurazione da 32 TB (4 SSD NVMe da 8000 GB per nodo) |
| Sistema operativo host e archiviazione di immagini Docker | 960 GB (2x SSD SATA da 480 GB per nodo) |
| Calcolare | |
| CPU | 2 processori Intel Xeon con 20/32/44 core (per nodo) |
| RAM | 192 GB / 384 GB / 768 GB (per nodo |
| Fisico | |
| Fattore di forma | 1U |
| Dimensioni e peso (per nodo) | 17.25 "L x 28" P x 1.72 "A / 52 libbre. 43.8 cm x 71.1 cm x 4.4 cm / 24 kg |
| Potenza | Doppi alimentatori ridondanti 110/220V |
| Ambientali | Temperatura di esercizio: da 50°F a 95°F (da 10°C a 35°C) |
Costruire e disegnare
L’appliance Diamanti è l’hardware fisico della soluzione container stack di Diamanti. Questo dispositivo viene offerto in un cluster minimo di tre nodi, in cui ciascun nodo è un rack 1U che fornisce fino a 32 TB di capacità di archiviazione dati e 960 GB per il sistema operativo host e l'archiviazione di immagini Docker.
La parte anteriore di un nodo mostra una griglia in alluminio progettata per un flusso d'aria efficiente con il registro dell'azienda al centro e in alto a sinistra, un meccanismo di bloccaggio. In alto a destra nella parte anteriore è presente il pannello di controllo che fornisce un interruttore di alimentazione, insieme a LED indicatori per lo stato del sistema. La rimozione della griglia in alluminio rivelerà le posizioni degli slot dell'unità, nonché una porta VGA e due porte USB.
Spostandoci nella parte posteriore dell'apparecchio, vediamo le porte del dispositivo. Qui evidenziamo a sinistra due alimentatori indipendenti ed un sistema ventilato; e al centro/a destra, le due porte di gestione, una porta 10GbE per connettere nodi ad alte prestazioni e bassa latenza, una porta QSFP+ (per 4x10G SFP+) e 4 porte USB per collegare una tastiera e altre periferiche.
Management
L'appliance viene fornita con uno stack software completo preintegrato che include sistema operativo, Docker, Kubernetes e altri servizi di convergenza dei container. Fornisce dashboard e funzioni di reporting tramite browser, CLI o API REST e sistema operativo Diamanti. La piattaforma Diamanti Enterprise Kubernetes è certificata K8s; una certificazione progettata dall'organizzazione CNCF.
Per la gestione guardiamo alla console Diamanti. Aprendolo entriamo direttamente nella dashboard che contiene informazioni di base facili da leggere rapidamente. Qui possiamo vedere quanti nodi sono in esecuzione, quanti contenitori e quanti pod. Anche l'utilizzo di CPU, spazio di archiviazione, memoria e rete è facilmente visibile in percentuale sulla sinistra. Sulla destra c'è la larghezza di banda in Kbps.
La scheda principale successiva è Crea applicazioni. Una volta che gli utenti hanno creato le applicazioni che desiderano, la sottoscheda è Distribuisci con una piccola icona Kubernetes. Da qui gli utenti devono inserire informazioni come nome, immagine, ambiente, porta, montaggi del volume e quantità di CPU e memoria.
La scheda principale successiva è Applicazioni. Sotto la scheda principale sono presenti le sottoschede: Pod, Controller di replica, Set di repliche, Set con stato, Set di daemon, Distribuzioni e Lavori. Pods offre agli utenti un breve riepilogo dello stato di un pod selezionato nonché del calcolo, della rete e dello spazio di archiviazione attribuiti.
La sottoscheda Stateful Sets consente agli utenti di approfondire ulteriormente i set ed esportarli se necessario. Qui ci vengono presentate informazioni di base come nome, spazio dei nomi, numero desiderato, numero attuale, numero pronto, età e opzioni su quali azioni intraprendere.
Gli utenti possono anche approfondire i log dei pod per visualizzare l'attività ed eventuali problemi.
La scheda principale successiva è Configurazioni K8S. Qui gli utenti possono gestire le configurazioni delle applicazioni correlate a Kubernetes come gli account di servizio, vedere i segreti, le mappe di configurazione e creare spazi dei nomi.
Dalla scheda Amministrazione nodo gli utenti possono visualizzare, aggiungere o eliminare nodi nonché monitorare l'utilizzo delle risorse del nodo. Anche in questo caso, gli utenti possono monitorare lo stato generale di un determinato nodo e delle risorse: calcolo, rete e spazio di archiviazione.
Come suggerisce il nome della scheda, Amministrazione archiviazione consente agli utenti di vedere tutto ciò che riguarda l'archiviazione, inclusi volumi, istantanee, unità, volumi persistenti, richieste di volume persistenti, classi di archiviazione e backup. Nella sottoscheda Volumi, ci viene data la possibilità di creare un nuovo volume o visualizzare un riepilogo di uno esistente, incluso il suo stato, la velocità effettiva di archiviazione e l'utilizzo.
La sottoscheda Unità consente agli utenti di visualizzare gli utilizzi delle unità fisiche con informazioni quali lo slot in cui si trova l'unità, il suo S/N, la capacità grezza, la capacità utilizzabile, la capacità allocata, il firmware e lo stato in cui si trova. può essere formattato da questa sottoscheda.
La sottoscheda Volumi persistenti consente agli utenti di creare o esportare volumi persistenti oltre a fornire informazioni quali nome, tipo, capacità, accesso, recupero, stato, richiesta, disponibilità di archiviazione, età e un elenco di azioni tra cui modifica, esportazione e eliminare.
Le richieste di volume persistenti fanno la stessa cosa di cui sopra per i PVC.
La nostra prossima scheda principale è la scheda Amministrazione di rete. Qui gli utenti possono creare, eliminare, modificare o esportare reti. Qui ci vengono fornite informazioni come nome, gruppo, se si tratta della rete predefinita, della rete host, della sua sottorete, gateway, indirizzo iniziale, indirizzo finale e indirizzo IP.
L'amministrazione degli utenti è abbastanza semplice. Qui gli amministratori possono creare utenti e gruppi e impostare varie policy per il controllo degli accessi.
Le Impostazioni avanzate consentono agli amministratori di creare e modificare i livelli di cluster e prestazioni.
Sebbene in genere passiamo attraverso varie funzioni di gestione per dare ai lettori un'idea generale di cosa aspettarsi mentre attraversano qualcosa, in questo caso stiamo facendo qualcosa di un po' diverso. Abbiamo anche eseguito i nostri benchmark in modo da poter vedere cosa fa la GUI con un carico di lavoro più pesante in esecuzione su di essa. Per ciascuno di questi benchmark ci troveremo nella scheda Amministrazioni dei nodi.
Con i nostri test di base (casuali e sequenziali) è possibile vedere facilmente l'assorbimento del calcolo e le metriche delle prestazioni sulla destra.
Il nostro test SQL ha causato un impatto piuttosto leggero sul calcolo e sulla rete, mentre lo storage ha raggiunto quasi 1 milione di IOPS.
Infine, diamo un esempio di ciò che ci si aspetta durante l'esecuzione del nostro test Oracle.
Performance
Analisi del carico di lavoro VDBench
Quando si tratta di confrontare gli array di storage, il test delle applicazioni è il migliore e il test sintetico viene al secondo posto. Pur non essendo una rappresentazione perfetta dei carichi di lavoro effettivi, i test sintetici aiutano a definire i dispositivi di storage con un fattore di ripetibilità che semplifica il confronto tra soluzioni concorrenti. Questi carichi di lavoro offrono una gamma di profili di test diversi che vanno dai test "quattro angoli" e test comuni sulle dimensioni di trasferimento del database, nonché acquisizioni di tracce da diversi ambienti VDI. Tutti questi test sfruttano il comune generatore di carico di lavoro Vdbench, con un motore di scripting per automatizzare e acquisire risultati su un ampio cluster di test di calcolo. Ciò ci consente di ripetere gli stessi carichi di lavoro su un'ampia gamma di dispositivi di storage, inclusi array flash e singoli dispositivi di storage.
Profili:
- Lettura casuale 4K: 100% di lettura, 128 thread, 0-120% irate
- Scrittura casuale 4K: scrittura al 100%, 64 thread, 0-120% irate
- Lettura sequenziale 64K: lettura al 100%, 16 thread, 0-120% irate
- Scrittura sequenziale 64K: scrittura al 100%, 8 thread, 0-120% irate
- Database sintetici: SQL e Oracle
In tutti i nostri test VDBench, abbiamo testato l'appliance Diamanti sulla base di diverse implementazioni che eseguono 3, 6, 9 o 12 pod Vdbench alla volta per superare il limite dell'appliance. Partendo da prestazioni di lettura 4K casuali, tutti i pod Vdbench hanno iniziato con una latenza di 120 μs; e prestazioni IO comprese tra 3 pod a 95,863 IOPS e 12 pod a 269,208 IOPS. Guardando alle prestazioni di picco, tutte le configurazioni sono rimaste sotto la latenza di 600μs. Con 3 pod Vdbench abbiamo registrato un picco di 947,619 IOPS con una latenza di 370 μs; con 6 pod, un picco di 1,745,344 IOPS con una latenza di 436μs; con 9 pod, un picco di 2,492019 IOPS con una latenza di 447μs; e l'ultima implementazione, 12 pod, ha raggiunto il picco di 2,753,170 IOPS con una latenza di 554μs.
Osservando le prestazioni di scrittura 4K, tutte le distribuzioni di test sono iniziate con una latenza di 300 μs ma sono aumentate rapidamente tra 26 ms e 28 ms quando hanno raggiunto le prestazioni massime. Le prestazioni hanno raggiunto il picco con 3 pod a 13,719 IOPS; 6 pod a 27,747 IOPS; 9 pod a 42,805 IOPS; e con 12 pod a 58,559 IOPS. Mostra un aumento costante delle prestazioni con più pod aggiunti.
Passando ai carichi di lavoro sequenziali, osserviamo le prestazioni di lettura dell'appliance a 64 KB, e qui la distribuzione dei 3 pod è iniziata a 14,560 IOPS o 910 MB/s con una latenza di 297μs. Tutte le altre implementazioni sono iniziate intorno ai 18,000 IOPS o 1.1 GB/s con una latenza di 227 μs. Per quanto riguarda le prestazioni di picco delle distribuzioni, la distribuzione a 3 pod ha raggiunto il picco di 143,431 IOPS o 9 GB/s con una latenza di 327 μs. Tutte le altre distribuzioni hanno raggiunto quasi le stesse prestazioni di 179,000 IOPS o 11.1 GB/s, con la distribuzione a 12 pod che è stata l'unica a superare la latenza di 1 ms.
Nella scrittura sequenziale a 64K, tutte le implementazioni di Vdbench sono iniziate con una latenza vicina a 350μs. Le distribuzioni hanno raggiunto il picco come segue: 3 pod, a 9,693 IOPS o 606 MB/s con una latenza di 4.9 ms; i 6 pod, a 22,202 IOPS o 1.39GB/s con una latenza di 4.3ms; i 9 pod, a 30,475 IOPS o 1.9GB/s con una latenza di 4.7ms; e infine i 12 pod hanno raggiunto un picco di 32,052 IOPS o 2.4 GB/s con una latenza di 4.9 ms.
La prossima serie di test riguarda i carichi di lavoro SQL: SQL, SQL 90-10 e SQL 80-20. Per SQL, tutte le distribuzioni sono iniziate con una latenza di 180μs. I 3 pod sono partiti da 26,291 IOPS e hanno raggiunto un picco a 261,573 IOPS con una latenza di 366μs. I 6 pod hanno raggiunto 57,061 IOPS e hanno raggiunto il picco a 570,642 IOPS con una latenza di 336μs. I 9 pod sono partiti da 86,197 IOPS e hanno raggiunto il picco a 885,269 IOPS con una latenza di 332μs. Inoltre, l'implementazione dei 12 pod è iniziata a 101,753 IOPS e ha raggiunto un picco a 1,106,860 IOPS con una latenza di 346μs.
Per SQL 90-10, tutte le distribuzioni sono iniziate con una latenza prossima ai 200μs. La distribuzione dei 3 pod è iniziata a 10,753 IOPS e ha raggiunto un picco a 105,877 IOPS con una latenza di 904μs. I 6 pod hanno raggiunto 49,361 IOPS e hanno raggiunto il picco di 245,158 IOPS con una latenza di 782μs. I 9 pod sono partiti da 80,157 IOPS e hanno raggiunto il picco a 401,444 IOPS con una latenza di 716μs. Inoltre, la distribuzione dei 12 pod è iniziata a 55,748 IOPS e ha raggiunto il picco a 554,685 IOPS con una latenza di 690 μs.
Per il nostro ultimo test SQL, l'80-20, abbiamo visto che anche le implementazioni Vdbench sono iniziate molto vicino alla latenza di 200μs. Le distribuzioni hanno raggiunto il picco come segue: distribuzione dei 3 pod a 57,944 IOPS con una latenza di 1.6 ms; i 6 pod hanno raggiunto il picco di 132,384 IOPS con una latenza di 1.4 ms; i 9 pod 217,273 IOPS con una latenza di 1.3ms; e l'implementazione dei 12 pod ha raggiunto un picco di 305,426 IOPS con una latenza di 1.2 ms.
Successivamente ci sono i nostri carichi di lavoro Oracle: Oracle, Oracle 90-10 e Oracle 80-20. Con Oracle, tutte le implementazioni sono iniziate con tempi inferiori a 210μs. Qui vediamo le prestazioni di picco delle distribuzioni. I 3 pod hanno raggiunto un picco di 54,844 IOPS con una latenza di 2.2 ms. I 6 pod hanno raggiunto il picco di 125,633 IOPS con una latenza di 1.9 ms. I 9 pod hanno raggiunto il picco di 206,024 IOPS con una latenza di 1.7 ms. Inoltre, l'implementazione dei 12 pod ha raggiunto un picco di 290,313 IOPS con una latenza di 1.6 ms.
In Oracle 90-10, le implementazioni iniziavano con meno di 200μs. L'implementazione dei 3 pod ha raggiunto un picco di 106,182 IOPS con una latenza di 620μs. I 6 pod hanno raggiunto il picco di 243,383 IOPS con una latenza di 541μs. I 9 pod hanno raggiunto il picco di 393,727 IOPS con una latenza di 502μs. Infine, l'implementazione dei 12 pod ha raggiunto un picco di 544,584 IOPS con una latenza di 483μs.
Per Oracle 80-20, abbiamo visto ancora una volta tutte le distribuzioni iniziare con una latenza di 210μs. Osservando le prestazioni di picco delle distribuzioni, vediamo che i 3 pod hanno raggiunto un picco di 58,037 IOPS con una latenza di 1.1 ms; i 6 pod hanno raggiunto un picco di 132,911 IOPS con una latenza di 991μs; i 9 pod hanno raggiunto un picco di 215,817 IOPS con una latenza di 915μs; infine, l'implementazione dei 12 pod ha raggiunto un picco di 304,391 IOPS con una latenza di 865μs.
Conclusione
Kubernetes ha visto l'accettazione da parte delle aziende più piccole e ora sta maturando in una tecnologia che la maggior parte, se non tutte le aziende Fortune 500, stanno esaminando e, alcune di quelle più lungimiranti, stanno iniziando a implementare. Kubernetes è in circolazione solo da 5 anni, ma ha superato la tranche degli innovatori sulla curva di adozione della tecnologia e si colloca saldamente nel campo dei primi utilizzatori. Questo posizionamento sulla curva di adozione della tecnologia è importante poiché la comunità Kubernetes ha capito come far funzionare Kubernetes e ora si sta concentrando su come farlo funzionare bene e speriamo che test come questi aiutino i consumatori Kubernetes a decidere con quali fornitori rivolgersi e aiutare i venditori fornendo loro uno standard con cui confrontarsi.
Diamanti ha creato un'avvincente soluzione Kubernetes con l'appliance container D10, offrendo un'interfaccia di gestione informativa e semplice da usare e una piattaforma di storage backend molto veloce per l'hosting dei container. Dato che si tratta ancora di un campo emergente, non ci sono molte soluzioni complete sul mercato, ma da quello che abbiamo visto il D10 è in grado di raggiungere tutti i livelli per ciò che tradizionalmente guarderemmo da un punto di vista storage o soluzione HCI. Le prestazioni sono generalmente fantastiche e offrono oltre 2.7 milioni di IOP in lettura casuale 4K dal nostro cluster che ha testato da 3 a 12 pod. Dal punto di vista della latenza abbiamo iniziato a poco più di 100 microsecondi e abbiamo raggiunto il massimo a 600 microsecondi. In termini di archiviazione è incredibilmente performante e da una piattaforma tecnologica emergente è davvero incredibile. Dal punto di vista della scrittura, l'appliance offriva 50 IOPS 4K casuali, che sembra essere l'unico punto debole, ma qualcosa che l'azienda dovrebbe essere in grado di risolvere tramite software o forse anche tramite supporti di memorizzazione. La larghezza di banda sequenziale offerta legge velocità superiori a 11 GB/s, ancora una volta prestazioni molto potenti e utilizzabili, con velocità di scrittura che arrivano a 2.4 GB/s al massimo.
Nel complesso, per i clienti che implementano Kubernetes nel proprio ambiente, l'appliance container Diamanti D10 offre un ottimo approccio chiavi in mano dal punto di vista dell'hosting e dello storage per coloro che desiderano dare uno sguardo serio al mercato dei container veloce e flessibile. Ad essere onesti, questo non è per tutti, il cluster è piuttosto specifico nel suo targeting. Ma se rientri in questo obiettivo, Diamanti offre esattamente ciò che desiderano i clienti, è creato appositamente per questi tipi di carichi di lavoro emergenti in contenitori. Sebbene sia ovviamente del tutto possibile sfruttare PKS per VMware o soluzioni alternative più focalizzate sull'azienda, Diamanti offre un sistema a bassa complessità e dovrebbe avere un vantaggio in termini di costi rispetto agli stack aziendali tradizionali. Grazie alla completezza della soluzione (ha una buona GUI tanto per cambiare) e all'ottimo profilo prestazionale, abbiamo stabilito che il D10 è un degno vincitore del StorageReview Editor's Choice Award.
Iscriviti alla newsletter di StorageReview
