Twee jaar geleden maakten we voor het eerst kennis met Diamanti op KubeCon 2017, en we waren onder de indruk van hun visie: een bare-metal containerplatform bieden dat speciaal is gebouwd voor microservices en cloud-native omgevingen, en geoptimaliseerd voor Kubernetes of eigenlijk een hyperconverged infrastructuurapparaat voor Kubernetes. We zagen dit als een interessant spel en vorig jaar op KubeCon 2018 begonnen we met hen te praten over samenwerking met ons om opslag op Kubernetes te begrijpen en hoe Kubernetes-opslag kan worden getest en op een methodische manier gekwantificeerd, zodat we kunnen beginnen met testen en documenteren Kubernetes-opslagprestaties.
Twee jaar geleden maakten we voor het eerst kennis met Diamanti op KubeCon 2017, en we waren onder de indruk van hun visie: een bare-metal containerplatform bieden dat speciaal is gebouwd voor microservices en cloud-native omgevingen, en geoptimaliseerd voor Kubernetes of eigenlijk een hyperconverged infrastructuurapparaat voor Kubernetes. We zagen dit als een interessant spel en vorig jaar op KubeCon 2018 begonnen we met hen te praten over samenwerking met ons om opslag op Kubernetes te begrijpen en hoe Kubernetes-opslag kan worden getest en op een methodische manier gekwantificeerd, zodat we kunnen beginnen met testen en documenteren Kubernetes-opslagprestaties.
Diamanti was geweldig om mee samen te werken en heeft ons het diepgaande begrip van Kubernetes en Kubernetes-opslag gegeven dat we nodig hadden om onze testmethodologie te ontwikkelen. Diamanti is gestart door voormalige VMware-, VERITAS- en Cisco-ingenieurs en wordt gefinancierd door Goldman Sachs en andere bekende VC's, wat indrukwekkend is, maar wat nog indrukwekkender is, is dat Diamanti een belangrijke bijdrage heeft geleverd aan de opslag- en netwerkstandaarden (namelijk FlexVolume/CSI en CNI) die zijn geaccepteerd in upstream Kubernetes-code.
Enterprise-business evolueert met de snelheid van het licht en bedrijven proberen gelijke tred te houden met deze evolutie met nieuwe technologieën om hun volledige productiecyclus van applicaties te versnellen. Containers was de technologie die is ontworpen om de ontwikkeling en implementatie van applicaties te versnellen, maar het bouwen ervan op een verouderde infrastructuur kan ingewikkeld zijn en wordt al snel een aanzienlijk obstakel bij het structureren van een volledig functionele containerstack. Containers zijn niet compatibel met traditionele opslag- en netwerkinfrastructuur, dus een doe-het-zelfbenadering voor het bouwen van een containeromgeving is IT-uitdagend, kostbaar en traag. Het Diamanti Enterprise Kubernetes-platform is bedoeld om infrastructuurarchitecten, IT-operaties en applicatie-eigenaren de snelheid, eenvoud, efficiëntie en controle te geven die ze nodig hebben om stateful container-applicaties op schaal uit te voeren.
Het Diamanti Enterprise Kubernetes Platform is een bare-metal containerplatform dat zich richt op de netwerk- en opslagaspecten om snel aan de slag te kunnen, met name voor grote ondernemingen. Met open-source Docker en Kubernetes volledig geïntegreerd, samen met speciaal gebouwde hardware en volledige ondersteuning voor de gehele stack, is het Diamanti Enterprise Kubernetes Platform een volledige containeroplossing die binnen enkele minuten kan worden geïmplementeerd. Diamanti beweert ongeëvenaarde prestaties en gebruik te hebben op zijn Enterprise Kubernetes-platform; de geheime saus voor deze prestatie is het gebruik van een unieke hypergeconvergeerde architectuur die speciaal is ontworpen voor de manier waarop Kubernetes-containers netwerk- en opslagbronnen gebruiken.
Diamanti D10-specificaties
| Netwerk | 4×10 GbE via een enkele QSFP+ verbinding (per node) |
| Opbergen | |
| Data opslag | 4 TB configuratie (4x 1000 GB NVMe SSD per node) 8 TB configuratie (4x 2000 GB NVMe SSD per node) 32 TB configuratie (4x 8000 GB NVMe SSD per node) |
| Host OS en Docker Image Storage | 960 GB (2x 480 GB SATA SSD per node) |
| Berekenen | |
| CPU | 2x Intel Xeon-processors met 20 / 32 / 44 cores (per knooppunt) |
| RAM | 192 GB / 384 GB / 768 GB (per knooppunt |
| fysiek | |
| Form Factor | 1U |
| Afmetingen en gewicht (per knoop) | 17.25″B x 28″D x 1.72″H / 52 lbs. 43.8 cm x 71.1 cm x 4.4 cm / 24 kg |
| Power | Dubbele redundante 110/220V voedingen |
| Mileu | Bedrijfstemperatuur: 50 ° F tot 95 ° F (10 ° C tot 35 ° C) |
Bouw en Ontwerp
Het Diamanti-apparaat is de fysieke hardware van Diamanti's containerstapeloplossing. Dit apparaat wordt aangeboden in een cluster met minimaal drie knooppunten, waarbij elk knooppunt een 1U-rack is dat tot 32 TB aan gegevensopslagcapaciteit biedt en 960 GB voor host-besturingssysteem en Docker-beeldopslag.
De voorkant van een knooppunt toont een aluminium rooster dat is ontworpen voor een efficiënte luchtstroom met het bedrijfslogboek in het midden en linksboven een vergrendelingsmechanisme. Rechtsboven op de voorkant bevindt zich het bedieningspaneel met een aan/uit-schakelaar en indicatie-LED's voor de systeemstatus. Als u de aluminium grill verwijdert, worden de locaties van de schijfsleuven zichtbaar, evenals een VGA- en twee USB-poorten.
Als we naar de achterkant van het apparaat gaan, zien we de poorten van het apparaat. Hier belichten we de linker twee onafhankelijke voedingen en een geventileerd systeem; en in het midden/rechts de twee beheerpoorten, een 10GbE-poort om knooppunten met hoge prestaties en lage latentie aan te sluiten, een QSFP+-poort (voor 4x10G SFP+) en 4 USB-poorten om een toetsenbord en andere randapparatuur aan te sluiten.
beheer
De appliance wordt geleverd met een voorgeïntegreerde volledige softwarestack, inclusief OS, Docker, Kubernetes en andere containerconvergentieservices. Het biedt dashboards en rapportagefuncties via een browser, CLI of REST API en Diamanti OS. Het Diamanti Enterprise Kubernetes Platform is K8s-gecertificeerd; een certificering ontworpen door de CNCF-organisatie.
Voor het beheer kijken we naar de Diamanti-console. Als we het openen, gaan we rechtstreeks naar het dashboard met basisinformatie die gemakkelijk snel kan worden gelezen. Hier kunnen we zien hoeveel knooppunten actief zijn, hoeveel containers en hoeveel pods. Het gebruik van CPU, opslag, geheugen en netwerk zijn ook gemakkelijk te zien in percentages aan de linkerkant. Rechts staat de bandbreedte in Kbps.
Het volgende hoofdtabblad is Create Applications. Zodra gebruikers de gewenste applicaties hebben gemaakt, is het subtabblad Implementeren met een klein Kubernetes-pictogram. Vanaf hier moeten gebruikers informatie invoeren zoals naam, afbeelding, omgeving, poort, volumekoppelingen en de hoeveelheid CPU en geheugen.
Het volgende hoofdtabblad is Toepassingen. Onder het hoofdtabblad bevinden zich de subtabbladen: pods, replicacontrollers, replicasets, stateful sets, daemonsets, implementaties en taken. Pods geeft gebruikers een korte samenvatting van de status van een geselecteerde pod, evenals de toegewezen rekenkracht, het netwerk en de opslag.
Op het subtabblad Stateful Sets kunnen gebruikers dieper inzoomen op de sets en deze indien nodig exporteren. Hier krijgen we basisinformatie te zien, zoals de naam, naamruimte, gewenst nummer, huidig nummer, nummer gereed, leeftijd en opties voor de te ondernemen acties.
Gebruikers kunnen ook in Pod-logboeken inzoomen om activiteit en mogelijke problemen te zien.
Het volgende hoofdtabblad is K8S-configuraties. Hier kunnen gebruikers Kubernetes-gerelateerde applicatieconfiguraties zoals serviceaccounts beheren, geheimen en configuratietoewijzingen bekijken en naamruimten maken.
Vanaf het tabblad Knooppuntbeheer kunnen gebruikers knooppunten bekijken, toevoegen of verwijderen, en het gebruik van knooppuntbronnen controleren. Nogmaals, hier kunnen gebruikers de algehele gezondheid van een bepaald knooppunt en de bronnen bewaken: rekenkracht, netwerk en opslag.
Zoals de naam van het tabblad al aangeeft, stelt Opslagbeheer gebruikers in staat om alles over opslag te zien, inclusief volumes, snapshots, schijven, persistente volumes, persistente volumeclaims, opslagklassen en back-ups. Onder het subtabblad Volumes krijgen we de mogelijkheid om een nieuw volume te maken of een samenvatting van een bestaand volume te bekijken, inclusief de status, opslagdoorvoer en gebruik.
Op het subtabblad Schijven kunnen gebruikers de hefbomen van de fysieke schijven zien met informatie zoals in welk slot de schijf zich bevindt, de S/N, onbewerkte capaciteit, bruikbare capaciteit, toegewezen capaciteit, de firmware en de status waarin deze zich bevindt. kan worden opgemaakt vanuit dit subtabblad.
Op het subtabblad Persistent Volumes kunnen gebruikers persistente volumes maken of exporteren en informatie geven zoals de naam, typecapaciteit, toegang, terugvordering, status, claim, opslagbeschikbaarheid, leeftijd en een lijst met acties, waaronder bewerken, exporteren en verwijderen.
Persistent Volume Claims doet hetzelfde als hierboven voor PVC's.
Ons volgende hoofdtabblad is het tabblad Netwerkbeheer. Hier kunnen gebruikers netwerken maken, verwijderen, bewerken of exporteren. Hier krijgen we informatie zoals naam, groep, of dit het standaardnetwerk, hostnetwerk, het subnet, gateway, startadres, eindadres en IP-adres is.
Gebruikersbeheer is vrij eenvoudig. Hier kunnen beheerders gebruikers en groepen aanmaken en verschillende beleidsregels voor toegangscontrole instellen.
Met geavanceerde instellingen kunnen beheerders de cluster- en prestatielagen maken en aanpassen.
Hoewel we over het algemeen verschillende managementfuncties doorlopen om lezers een algemeen idee te geven van wat ze kunnen verwachten als ze iets doorlopen, doen we deze ronde iets anders. We hebben ook onze benchmarks uitgevoerd, zodat we kunnen zien wat de GUI doet met een zwaardere werklast. Voor elk van deze benchmarks bevinden we ons op het tabblad Node Administrations.
Met onze eenvoudige (willekeurige en sequentiële) tests kan men eenvoudig de trekking op de computer zien, evenals prestatiestatistieken aan de rechterkant.
Onze SQL-test veroorzaakte een vrij lichte tol van de rekenkracht en het netwerk, terwijl de opslag bijna 1 miljoen IOPS bereikte.
Tot slot geven we een voorbeeld van wat men verwacht terwijl onze Oracle-test loopt.
Prestatie
VDBench-werkbelastinganalyse
Als het gaat om het benchmarken van opslagarrays, is het testen van toepassingen het beste en komt het synthetische testen op de tweede plaats. Hoewel ze geen perfecte weergave zijn van de werkelijke werkbelasting, helpen synthetische tests wel om opslagapparaten te baseren met een herhaalbaarheidsfactor die het gemakkelijk maakt om appels met appels te vergelijken tussen concurrerende oplossingen. Deze workloads bieden een scala aan verschillende testprofielen, variërend van "four corners"-tests en algemene tests voor de grootte van databaseoverdrachten, evenals het vastleggen van sporen uit verschillende VDI-omgevingen. Al deze tests maken gebruik van de gemeenschappelijke Vdbench-workloadgenerator, met een scripting-engine om resultaten te automatiseren en vast te leggen over een groot rekentestcluster. Hierdoor kunnen we dezelfde workloads herhalen op een breed scala aan opslagapparaten, waaronder flash-arrays en individuele opslagapparaten.
profielen:
- 4K willekeurig lezen: 100% lezen, 128 threads, 0-120% joate
- 4K willekeurig schrijven: 100% schrijven, 64 threads, 0-120% snelheid
- 64K sequentieel lezen: 100% lezen, 16 threads, 0-120% jorate
- 64K sequentieel schrijven: 100% schrijven, 8 threads, 0-120% snelheid
- Synthetische database: SQL en Oracle
In al onze VDBench-tests hebben we het Diamanti-apparaat getest op basis van verschillende implementaties met 3, 6, 9 of 12 Vdbench-pods tegelijk om de limiet van het apparaat te verleggen. Beginnend met willekeurige 4K-leesprestaties, begonnen alle Vdbench-pods met een latentie van 120 μs; en IO-prestaties variërend tussen de 3 pods bij 95,863 IOPS en 12 pods bij 269,208 IOPS. Kijkend naar de topprestaties, bleven alle configuraties onder de latentie van 600 μs. Met 3 Vdbench-pods zagen we een piek van 947,619 IOPS bij een latentie van 370μs; met 6 pods, een piek van 1,745,344 IOPS met een latentie van 436μs; met 9 pods, een piek van 2,492019 IOPS bij een latentie van 447μs; en de laatste implementatie, 12 pods, piekte op 2,753,170 IOPS met een latentie van 554μs.
Kijkend naar 4K-schrijfprestaties, begonnen alle testimplementaties met een latentie van 300μs, maar namen snel toe tussen 26ms en 28ms bij het bereiken van de maximale prestaties. De prestatie piekte met 3 pods op 13,719 IOPS; 6 capsules bij 27,747 IOPS; 9 pods bij 42,805 IOPS; en met 12 pods bij 58,559 IOPS. Toont een gestage prestatieverbetering bij meer toegevoegde pods.
Als we overschakelen naar sequentiële workloads, kijken we naar 64K leesprestaties van het apparaat, en hier begon de implementatie van 3 pods met 14,560 IOPS of 910 MB/s met een latentie van 297 μs. Alle andere implementaties begonnen in de buurt van de 18,000 IOPS of 1.1 GB/s met een latentie van 227 μs. Wat betreft de topprestaties van de implementaties, bereikte de implementatie met 3 pods een piek van 143,431 IOPS of 9GB/s bij een latentie van 327μs. Alle andere implementaties bereikten bijna dezelfde prestaties van 179,000 IOPS of 11.1 GB/s, waarbij de implementatie met 12 pods de enige was die de latentie van 1 ms overschreed.
Bij 64K sequentiële schrijfbewerkingen begonnen alle implementaties van de Vdbench met een latentie van bijna 350 μs. De implementaties piekten als volgt: 3 pods, met 9,693 IOPS of 606 MB/s met een latentie van 4.9 ms; de 6 pods, met 22,202 IOPS of 1.39 GB/s met een latentie van 4.3 ms; de 9 pods, met 30,475 IOPS of 1.9 GB/s met een latentie van 4.7 ms; en uiteindelijk bereikten de 12 pods een piek van 32,052 IOPS of 2.4 GB/s met een latentie van 4.9 ms.
Onze volgende reeks tests zijn onze SQL-workloads: SQL, SQL 90-10 en SQL 80-20. Voor SQL zijn alle implementaties gestart onder de latentie van 180 μs. De 3 pods begonnen bij 26,291 IOPS en bereikten een piek bij 261,573 IOPS met een latentie van 366μs. De 6 pods staarden naar 57,061 IOPS en piekten op 570,642 IOPS met een latentie van 336μs. De 9 pods begonnen bij 86,197 IOPS en piekten bij 885,269 IOPS met een latentie van 332μs. En de implementatie van 12 pods begon bij 101,753 IOPS en bereikte een piek bij 1,106,860 IOPS met een latentie van 346μs.
Voor SQL 90-10 begonnen alle implementaties dicht bij de latentie van 200 μs. De implementatie van 3 pods begon bij 10,753 IOPS en bereikte een piek van 105,877 IOPS met een latentie van 904μs. De 6 pods staarden naar 49,361 IOPS en piekten op 245,158 IOPS met een latentie van 782μs. De 9 pods begonnen bij 80,157 IOPS en piekten bij 401,444 IOPS met een latentie van 716μs. En de implementatie van 12 pods begon bij 55,748 IOPS en bereikte een piek bij 554,685 IOPS met een latentie van 690μs.
Voor onze laatste SQL-test, de 80-20, zagen we dat de Vdbench-implementaties ook heel dicht bij de latentie van 200 μs begonnen. De implementaties bereikten als volgt een hoogtepunt: de implementatie van 3 pods met 57,944 IOPS met een latentie van 1.6 ms; de 6 pods piekten op 132,384 IOPS met een latentie van 1.4 ms; de 9 pods 217,273 IOPS met een latentie van 1.3 ms; en de inzet van 12 pods bereikte een hoogtepunt met 305,426 IOPS met een latentie van 1.2 ms.
De volgende stap zijn onze Oracle-workloads: Oracle, Oracle 90-10 en Oracle 80-20. Met Oracle begonnen alle implementaties onder 210μs. Hier zien we de topprestaties van de implementaties. De 3 pods bereikten een piek van 54,844 IOPS met een latentie van 2.2 ms. De 6 pods piekten op 125,633 IOPS met een latentie van 1.9 ms. De 9 pods piekten op 206,024 IOPS met een latentie van 1.7 ms. En de implementatie van 12 pods bereikte een hoogtepunt met 290,313 IOPS met een latentie van 1.6 ms.
In Oracle 90-10 begonnen de implementaties onder de 200μs. De inzet van 3 pods bereikte een piek van 106,182 IOPS met een latentie van 620μs. De 6 pods piekten op 243,383 IOPS met een latentie van 541μs. De 9 pods piekten op 393,727 IOPS met een latentie van 502μs. En tot slot bereikte de inzet van 12 pods een piek van 544,584 IOPS met een latentie van 483μs.
Voor Oracle 80-20 zagen we nog een keer dat alle implementaties begonnen met een latentie van 210 μs. Als we kijken naar de topprestaties van de implementaties, zien we dat de 3 pods pieken op 58,037 IOPS met een latentie van 1.1 ms; de 6 pods met een piek van 132,911 IOPS met een latentie van 991μs; de 9 pods met een piek van 215,817 IOPS met een latentie van 915μs; en ten slotte bereikte de inzet van 12 pods een piek van 304,391 IOPS met een latentie van 865 μs.
Conclusie
Kubernetes wordt geaccepteerd door kleinere bedrijven en ontwikkelt zich nu tot een technologie waar de meeste, zo niet alle Fortune 500-bedrijven naar kijken en sommige van de meer vooruitstrevende beginnen te implementeren. Kubernetes bestaat pas 5 jaar, maar heeft de innovators-tranche op de technologie-adoptiecurve gepasseerd en bevindt zich stevig in het kamp van de early adopters. Deze positionering op de acceptatiecurve van technologie is van belang, aangezien de Kubernetes-gemeenschap heeft uitgezocht hoe Kubernetes aan het werk kan worden gezet en zich er nu op richt om het goed te laten werken. en help de verkopers door ze een standaard te geven waarmee ze zichzelf kunnen vergelijken.
Diamanti heeft een overtuigende Kubernetes-oplossing gebouwd met de D10-containerappliance, die een informatieve en eenvoudig te gebruiken beheerinterface biedt en een zeer snel backend-opslagplatform voor het hosten van containers. Aangezien dit nog steeds een opkomend gebied is, zijn er niet veel volledig uitgewerkte oplossingen op de markt, maar van wat we hebben gezien, kan de D10 alle punten halen voor waar we traditioneel naar kijken vanuit een opslag of HCI-oplossing. De prestaties zijn over het algemeen fantastisch en bieden meer dan 2.7 miljoen IOP's 4K willekeurig gelezen uit onze cluster die 3 tot 12 pods test. Vanuit een latentieperspectief zijn we begonnen met iets meer dan 100 microseconden en bereikten we een hoogtepunt van 600 microseconden. In termen van opslag is dat ongelooflijk krachtig, en vanuit een opkomend technologieplatform is dat behoorlijk ongelooflijk. Vanuit schrijfperspectief bood het apparaat 50 IOPS 4K random, wat de enige zwakte lijkt te zijn, maar iets dat het bedrijf zou moeten kunnen oplossen via software of misschien zelfs opslagmedia. Sequentiële bandbreedte bood leessnelheden van meer dan 11 GB/s, opnieuw zeer sterke en bruikbare prestaties, met schrijfsnelheden van 2.4 GB/s op het hoogtepunt.
Over het algemeen biedt het Diamanti D10-containerapparaat voor klanten die Kubernetes in hun omgeving implementeren, een geweldige kant-en-klare benadering vanuit het oogpunt van hosting en opslag voor diegenen die serieus naar de snelle en losse containermarkt willen kijken. Om eerlijk te zijn, dit is niet voor iedereen weggelegd, het cluster is vrij specifiek in zijn targeting. Maar als u aan dat doel voldoet, biedt Diamanti precies wat die klanten willen, het is speciaal gebouwd voor dit soort opkomende containerworkloads. Hoewel het natuurlijk heel goed mogelijk is om PKS te gebruiken voor VMware of alternatieve oplossingen die meer gericht zijn op ondernemingen, biedt Diamanti een systeem dat weinig complex is en een kostenvoordeel zou moeten hebben ten opzichte van traditionele enterprise-stacks. Vanwege de volledigheid van de oplossing (hij heeft voor de verandering een goede GUI) en het zeer goede prestatieprofiel, hebben we vastgesteld dat de D10 een waardige winnaar is van de StorageReview Editor's Choice Award.
Meld u aan voor de StorageReview-nieuwsbrief
