Diamanti D10 Container Appliance Review

Vi bekantade oss första gången med Diamanti för två år sedan på KubeCon 2017, och vi var imponerade av deras vision: att tillhandahålla en containerplattform av barmetall, specialbyggd för mikrotjänster och molnbaserade miljöer, och optimerad för Kubernetes eller i princip en hyperkonvergerad infrastruktur för Kubernetes. Vi såg detta som en intressant pjäs och förra året på KubeCon 2018 började vi prata med dem om att arbeta med oss ​​för att förstå lagring på Kubernetes och hur Kubernetes-lagring kan testas och kvantifieras på ett metodiskt sätt så att vi kan börja testa och dokumentera Kubernetes lagringsprestanda.

Vi bekantade oss första gången med Diamanti för två år sedan på KubeCon 2017, och vi var imponerade av deras vision: att tillhandahålla en containerplattform av barmetall, specialbyggd för mikrotjänster och molnbaserade miljöer, och optimerad för Kubernetes eller i princip en hyperkonvergerad infrastruktur för Kubernetes. Vi såg detta som en intressant pjäs och förra året på KubeCon 2018 började vi prata med dem om att arbeta med oss ​​för att förstå lagring på Kubernetes och hur Kubernetes-lagring kan testas och kvantifieras på ett metodiskt sätt så att vi kan börja testa och dokumentera Kubernetes lagringsprestanda.

Diamanti har varit bra att arbeta med och har kunnat ge oss den djupa förståelsen av Kubernetes och Kubernetes lagring som vi behövde för att skapa vår testmetod. Diamanti startades av före detta VMware, VERITAS och Cisco Engineers och finansieras av Goldman Sachs och andra välkända VC, vilket är imponerande men vad som är mer imponerande är att Diamanti har varit en stor bidragsgivare till lagrings- och nätverksstandarderna (nämligen FlexVolume/CSI och CNI) som har accepterats i uppströms Kubernetes-kod.

Företagsverksamheten utvecklas med ljusets hastighet, och företag försöker hålla jämna steg med denna utveckling med ny teknik för att påskynda hela sin produktionscykel av applikationer. Containers var tekniken som utformats för att påskynda applikationsutveckling och driftsättning, men att bygga dem på äldre infrastruktur kan vara komplicerat och blir snabbt ett stort hinder för att strukturera en fullt fungerande containerstack. Behållare är inkompatibla med traditionell lagrings- och nätverksinfrastruktur, så en gör-det-själv-metod (DIY) för att bygga en containermiljö är IT-utmanande, kostsam och långsam. Diamanti Enterprise Kubernetes-plattformen är avsedd att ge infrastrukturarkitekter, IT-drift och applikationsägare den hastighet, enkelhet, effektivitet och kontroll som de behöver för att köra stateful containeriserade applikationer i stor skala.

Diamanti Enterprise Kubernetes-plattformen är en barmetall-containerplattform fokuserad på nätverks- och lagringsaspekterna för att komma igång snabbt, särskilt för stora företag. Med öppen källkod Docker och Kubernetes helt integrerade, tillsammans med specialbyggd hårdvara och komplett stöd för hela stacken, är Diamanti Enterprise Kubernetes Platform en komplett containerlösning som kan distribueras på några minuter. Diamanti uppger att ha oöverträffad prestanda och användning på sin Enterprise Kubernetes-plattform; den hemliga såsen för den här föreställningen använder en unik hyperkonvergerad arkitektur designad specifikt för hur Kubernetes-behållare använder nätverks- och lagringsresurser.

Diamanti D10 Specifikationer

Bygg och design

Diamanti-apparaten är den fysiska hårdvaran i Diamantis containerstacklösning. Denna apparat erbjuds i ett minst tre-nodskluster, där varje nod är ett 1U-rack som ger upp till 32 TB datalagringskapacitet och 960 GB för värd OS och Docker-bildlagring.

Framsidan av en nod visar en aluminiumgrill designad för effektivt luftflöde med företagets stock i mitten och uppe till vänster, en låsmekanism. Längst upp till höger på framsidan finns kontrollpanelen som tillhandahåller en strömbrytare, tillsammans med indikatorlampor för systemets hälsa. Om du tar bort aluminiumgrillen avslöjas placeringen av enhetens kortplatser, även en VGA- och två USB-portar.

När vi rör oss på baksidan av apparaten ser vi portarna på enheten. Här markerar vi de två vänstra oberoende strömförsörjningen och ett ventilerat system; och i mitten/höger, de två hanteringsportarna, en 10GbE-port för att ansluta noder med hög prestanda och låg latens, en QSFP+-port (för 4x10G SFP+) och 4 USB-portar för att ansluta ett tangentbord och annan kringutrustning.

Verksamhetsledningen 

Enheten levereras med förintegrerad fullständig mjukvarustack inklusive OS, Docker, Kubernetes och andra containerkonvergenstjänster. Den tillhandahåller instrumentpaneler och rapporteringsfunktioner via en webbläsare, CLI eller REST API och Diamanti OS. Diamanti Enterprise Kubernetes-plattformen är K8s-certifierad; en certifiering designad av CNCF-organisationen.

För hantering ser vi till Diamanti-konsolen. När vi öppnar den går vi rakt in i instrumentpanelen som har grundläggande information som är lätt att snabbt läsa över. Här kan vi se hur många noder som körs, hur många behållare och hur många pods. Användningen av CPU, lagring, minne och nätverk är också lätt att se i procent till vänster. Till höger är bandbredden i Kbps.

Nästa huvudflik är Skapa applikationer. När användarna har skapat de applikationer de vill ha är underfliken Distribuera med en liten Kubernetes-ikon. Härifrån måste användare lägga in information som namn, bild, miljö, port, volymfästen och mängden CPU och minne.

Nästa huvudflik ner är Applications. Under huvudfliken finns underflikarna: Pods, Replikeringskontroller, Replica Sets, Stateful Sets, Daemon Sets, Deployments och Jobs. Pods ger användarna en kort sammanfattning av tillståndet för en vald pod samt tillskriven dator, nätverk och lagring.

Underfliken Stateful Sets gör det möjligt för användare att gå igenom mer i uppsättningarna och exportera dem om det behövs. Här presenteras vi med grundläggande information som namn, namnutrymme, önskat nummer, aktuellt nummer, nummer redo, ålder och alternativ för vilka åtgärder som ska vidtas.

Användare kan också gå ner i Pod-loggar för att se aktivitet och eventuella problem.

Nästa huvudflik är K8S-konfigurationer. Här kan användare hantera Kubernetes-relaterade programkonfigurationer som tjänstekonton, se hemligheter, konfigurera kartor och skapa namnområden.

Från fliken Nodadministration kan användare visa, lägga till eller ta bort noder samt övervaka användningen av nodresurser. Återigen, här kan användare övervaka den övergripande hälsan för en given nod och resurserna: beräkning, nätverk och lagring.

Som namnet på fliken antyder, tillåter lagringsadministration användare att se allt lagring inklusive volymer, ögonblicksbilder, enheter, beständiga volymer, beständiga volymkrav, lagringsklasser och säkerhetskopior. Under underfliken Volymer får vi möjlighet att skapa en ny volym eller se en sammanfattning av en befintlig, inklusive dess hälsa, lagringskapacitet och användning.

Underfliken Drives tillåter användare att se de fysiska enheterna som utnyttjar information som vilken plats disken är i, dess S/N, råkapacitet, användbar kapacitet, allokerad kapacitet, dess firmware och vilket tillstånd den är i. Diskarna kan formateras från denna underflik.

Underfliken Beständiga volymer låter användare skapa eller exportera beständiga volymer samt ge information som dess namn, typkapacitet, åtkomst, återkrav, status, anspråk, lagringstillgänglighet, ålder och en lista över åtgärder inklusive redigering, export och radera.

Persistent Volume Claims gör samma sak som ovan för PVC.

Vår nästa huvudflik är fliken Nätverksadministration. Här kan användare skapa, ta bort, redigera eller exportera nätverk. Här får vi information som namn, grupp, om det är standardnätverket, värdnätverket, dess subnät, gateway, startadress, slutadress och IP-adress.

Användaradministration är ganska enkel. Här kan administratörer skapa användare och grupper och ställa in olika policyer för åtkomstkontroll.

Avancerade inställningar tillåter administratörer att skapa och justera klustret och prestandanivåerna.

Medan vi i allmänhet går igenom olika ledningsfunktioner för att ge läsarna en allmän uppfattning om vad de kan förvänta sig när de går igenom något, gör vi något lite annorlunda den här gången. Vi körde också våra benchmarks så att vi kan se vad GUI gör med en tyngre arbetsbelastning som körs på den. För vart och ett av dessa riktmärken finns vi på fliken Nodadministrationer.

Med våra grundläggande (slumpmässiga och sekventiella) tester kan man enkelt se dragningen på datorn samt prestandamått till höger.

Vårt SQL-test orsakade en ganska låg avgift på datorn och nätverket medan lagringen nådde nästan 1 miljon IOPS.

Slutligen ger vi ett exempel på vad man förväntar sig medan vårt Oracle-test körs.

Prestation

VDBench arbetsbelastningsanalys

När det gäller benchmarking av lagringsmatriser är applikationstestning bäst och syntetisk testning kommer på andra plats. Även om det inte är en perfekt representation av faktiska arbetsbelastningar, hjälper syntetiska tester till baslagringsenheter med en repeterbarhetsfaktor som gör det enkelt att göra jämförelser mellan äpplen och äpplen mellan konkurrerande lösningar. Dessa arbetsbelastningar erbjuder en rad olika testprofiler, allt från "fyra hörn"-tester och vanliga tester av databasöverföringsstorlek, såväl som spårfångst från olika VDI-miljöer. Alla dessa tester utnyttjar den vanliga Vdbench-arbetsbelastningsgeneratorn, med en skriptmotor för att automatisera och fånga resultat över ett stort beräkningstestkluster. Detta gör att vi kan upprepa samma arbetsbelastningar över ett brett utbud av lagringsenheter, inklusive flash-arrayer och individuella lagringsenheter.

profiler:

• 4K slumpmässig läsning: 100 % läsning, 128 trådar, 0-120 % iorat
• 4K Random Write: 100% Write, 64 trådar, 0-120% iorate
• 64K sekventiell läsning: 100 % läsning, 16 trådar, 0-120 % iorat
• 64K sekventiell skrivning: 100 % skrivning, 8 trådar, 0-120 % iorate
• Syntetisk databas: SQL och Oracle

I alla våra VDBench-tester testade vi Diamanti-apparaten baserat på olika installationer som körde 3, 6, 9 eller 12 Vdbench-pods åt gången för att tänja på gränsen för apparaten. Från och med slumpmässig 4K-läsprestanda startade alla Vdbench-pods med en latens på 120μs; och IO-prestanda som sträcker sig mellan de 3 poddarna vid 95,863 12 IOPS och 269,208 pods vid 600 3 IOPS. Om man tittar på toppprestanda, stannade alla konfigurationer under 947,619 μs latens. Med 370 Vdbench-pods såg vi en topp på 6 1,745,344 IOPS vid en latens på 436μs; med 9 baljor, en topp på 2,492019 447 12 IOPS med en latens på 2,753,170 μs; med 554 baljor, en topp på XNUMX IOPS vid en latens på XNUMXμs; och den sista utplaceringen, XNUMX pods, nådde en topp på XNUMX XNUMX XNUMX IOPS med en latens på XNUMX μs.

Om man tittar på 4K-skrivprestanda, startade alla testinstallationer under en latens på 300μs men ökade snabbt mellan 26ms och 28ms när maximal prestanda nåddes. Prestandan toppade med 3 pods på 13,719 6 IOPS; 27,747 baljor vid 9 42,805 IOPS; 12 baljor vid 58,559 XNUMX IOPS; och med XNUMX baljor vid XNUMX XNUMX IOPS. Visar en stadig prestandaökning vid fler tillagda pods.

När vi växlar över till sekventiella arbetsbelastningar tittar vi på 64K läsprestanda för apparaten, och här startade 3 pods-distributionen vid 14,560 910 IOPS eller 297 MB/s med en latens på 18,000μs. Alla andra distributioner startade nära 1.1 227 IOPS eller 3 GB/s med en latens på 143,431μs. När det gäller toppprestanda för utplaceringarna, fortsatte utbyggnaden av 9 pods att nå en topp på 327 179,000 IOPS eller 11.1 GB/s med en latens på 12 μs. Alla andra distributioner nådde en topp med nästan samma prestanda på 1 XNUMX IOPS eller XNUMX GB/s, med XNUMX pods-distribution som den enda som klarade XNUMXms latens.

I 64K sekventiell skrivning startade alla distributioner av Vdbench med en latens nära 350μs. Utplaceringarna nådde sin topp enligt följande: 3 pods, vid 9,693 606 IOPS eller 4.9 MB/s med en latens på 6 ms; de 22,202 poddarna, vid 1.39 4.3 IOPS eller 9 GB/s med en latens på 30,475 ms; de 1.9 poddarna, vid 4.7 12 IOPS eller 32,052 GB/s med en latens på 2.4 ms; och slutligen nådde de 4.9 poddarna en topp på XNUMX XNUMX IOPS eller XNUMX GB/s med en latens på XNUMX ms.

Vår nästa uppsättning tester är våra SQL-arbetsbelastningar: SQL, SQL 90-10 och SQL 80-20. För SQL startade alla distributioner under 180 μs latens. De 3 baljorna började vid 26,291 261,573 IOPS och gick på en topp vid 366 6 IOPS med en latens på 57,061 μs. De 570,642 baljorna stirrade på 336 9 IOPS och nådde en topp på 86,197 885,269 IOPS med en latens på 332 μs. De 12 baljorna började vid 101,753 1,106,860 IOPS och toppade på 346 XNUMX IOPS med en latens på XNUMX μs. Och utplaceringen av XNUMX pods började vid XNUMX XNUMX IOPS och nådde en topp vid XNUMX XNUMX XNUMX IOPS med en latens på XNUMX μs.

För SQL 90-10 startade alla distributioner nära 200μs latens. Utplaceringen av 3 pods startade vid 10,753 105,877 IOPS och nådde en topp vid 904 6 IOPS med en latens på 49,361 μs. De 245,158 baljorna stirrade på 782 9 IOPS och nådde en topp på 80,157 401,444 IOPS med en latens på 716 μs. De 12 baljorna började vid 55,748 554,685 IOPS och toppade på 690 XNUMX IOPS med en latens på XNUMX μs. Och utplaceringen av XNUMX poddar började vid XNUMX XNUMX IOPS och nådde en topp vid XNUMX XNUMX IOPS med en latens på XNUMX μs.

För vårt senaste SQL-test, 80-20, såg vi att Vdbench-distributionerna också startade mycket nära 200μs latens. Utplaceringarna nådde en topp enligt följande: 3 pods-utbyggnaden vid 57,944 1.6 IOPS med en latens på 6 ms; de 132,384 kapslarna nådde en topp på 1.4 9 IOPS med en latens på 217,273 ms; de 1.3 kapslarna 12 305,426 IOPS med en latens på 1.2 ms; och distributionen av XNUMX poddar nådde en topp vid XNUMX XNUMX IOPS med en latens på XNUMX ms.

Nästa upp är våra Oracle-arbetsbelastningar: Oracle, Oracle 90-10 och Oracle 80-20. Med Oracle startade alla distributioner under 210μs. Här ser vi toppprestanda för installationerna. De 3 poddarna nådde en topp på 54,844 2.2 IOPS med en latens på 6 ms. De 125,633 poddarna nådde en topp på 1.9 9 IOPS med en latens på 206,024 ms. De 1.7 poddarna nådde en topp på 12 290,313 IOPS med en latens på 1.6 ms. Och distributionen av XNUMX poddar nådde en topp på XNUMX XNUMX IOPS med en latens på XNUMX ms.

I Oracle 90-10 startade distributionerna under 200μs. Utplaceringen av 3 pods nådde en topp vid 106,182 620 IOPS med en latens på 6 μs. De 243,383 baljorna nådde en topp på 541 9 IOPS med en latens på 393,727μs. De 502 baljorna nådde en topp på 12 544,584 IOPS med en latens på 483μs. Och slutligen, utplaceringen av XNUMX poddar nådde en topp på XNUMX XNUMX IOPS med en latens på XNUMX μs.

För Oracle 80-20 såg vi en gång till alla distributioner som började med en latens på 210μs. Om vi ​​tittar på toppprestanda för implementeringarna ser vi de 3 poddarna som toppar på 58,037 1.1 IOPS med en latens på 6 ms; de 132,911 baljorna toppade på 991 9 IOPS med en latens på 215,817 μs; de 915 baljorna toppade på 12 304,391 IOPS med en latens på 865μs; och slutligen, utplaceringen av XNUMX poddar nådde en topp vid XNUMX XNUMX IOPS med en latens på XNUMX μs.

Slutsats

Kubernetes har sett acceptans av mindre företag och håller nu på att mogna till en teknik som de flesta, om inte alla Fortune 500-företag, tittar på och, några av de mer framåtsträvande, börjar implementera. Kubernetes har bara funnits i 5 år men har passerat innovatörernas del på kurvan för teknikanvändning och befinner sig stabilt i de tidiga användarnas läger. Denna positionering på kurvan för teknikanvändning är viktig eftersom Kubernetes-communityt har listat ut hur man får Kubernetes att köra och fokuserar nu på att få det att fungera bra och vi hoppas att tester som dessa kommer att hjälpa Kubernetes-konsumenter att bestämma vilka leverantörer de ska gå med och hjälpa leverantörerna genom att ge dem en standard att jämföra sig med.

Diamanti har byggt en övertygande Kubernetes-lösning med D10-behållaren, som erbjuder ett informativt och enkelt att använda hanteringsgränssnitt och en mycket snabb backend-lagringsplattform för att vara värd för containrar. Eftersom detta fortfarande är ett framväxande område finns det inte många helt färdiga lösningar på marknaden, men från vad vi har sett kan D10 nå alla betyg för vad vi traditionellt sett på en lagring eller HCI-lösning. Prestandan är generellt sett fantastisk och erbjuder över 2.7 miljoner IOP:er 4K slumpmässig läsning från vårt kluster som testar 3 till 12 pods. Ur ett latensperspektiv började vi på drygt 100 mikrosekunder och toppade vid 600 mikrosekunder. I lagringstermer är det otroligt prestanda, och från en framväxande teknologiplattform som är ganska otrolig. Ur ett skrivperspektiv erbjöd apparaten 50k IOPS 4K slumpmässigt, vilket verkar vara den enda svagheten, men något företaget borde kunna åtgärda via mjukvara eller kanske till och med lagringsmedia. Sekventiell bandbredd som erbjuds läshastigheter på över 11 GB/s, återigen mycket stark och användbar prestanda, med skrivhastigheter på 2.4 GB/s på toppen.

Sammantaget för kunder som använder Kubernetes i sin miljö, erbjuder Diamanti D10-behållaren en fantastisk nyckelfärdig tillvägagångssätt ur ett värd- och lagringsperspektiv för dem som vill ta en seriös titt på marknaden för snabba och lösa containers. För att vara rättvis är detta inte för alla, klustret är ganska specifik i sin inriktning. Men om du passar det målet Diamanti erbjuder exakt vad dessa kunder vill ha, är det specialbyggt för dessa typer av nya containerarbetsbelastningar. Även om det naturligtvis är fullt möjligt att utnyttja PKS för VMware eller alternativa lösningar som är mer företagsfokuserade, erbjuder Diamanti ett system som har låg komplexitet och borde ha kostnadsfördelar jämfört med traditionella företagsstackar. På grund av lösningens fullständighet (den har ett bra GUI för en förändring) och den mycket bra prestandaprofilen, har vi bestämt att D10 är en värdig vinnare av StorageReview Editor's Choice Award.

Diamanti D10

Diskutera denna recension

Anmäl dig till StorageReviews nyhetsbrev