Bewertung der Diamanti D10 Container Appliance

Wir haben Diamanti zum ersten Mal vor zwei Jahren auf der KubeCon 2017 kennengelernt und waren von ihrer Vision beeindruckt: eine Bare-Metal-Containerplattform bereitzustellen, die speziell für Microservices und Cloud-native Umgebungen entwickelt und für Kubernetes oder, im Grunde genommen, hyperkonvergent optimiert wurde Infrastruktur-Appliance für Kubernetes. Wir hielten dies für ein interessantes Spiel und haben letztes Jahr auf der KubeCon 2018 begonnen, mit ihnen über die Zusammenarbeit mit uns zu sprechen, um Speicher auf Kubernetes zu verstehen und wie Kubernetes-Speicher auf methodische Weise getestet und quantifiziert werden kann, damit wir mit dem Testen und Dokumentieren beginnen können Kubernetes-Speicherleistung.

Wir haben Diamanti zum ersten Mal vor zwei Jahren auf der KubeCon 2017 kennengelernt und waren von ihrer Vision beeindruckt: eine Bare-Metal-Containerplattform bereitzustellen, die speziell für Microservices und Cloud-native Umgebungen entwickelt und für Kubernetes oder im Grunde eine Hyperkonvergenz optimiert wurde Infrastruktur-Appliance für Kubernetes. Wir hielten dies für ein interessantes Spiel und haben letztes Jahr auf der KubeCon 2018 begonnen, mit ihnen über die Zusammenarbeit mit uns zu sprechen, um Speicher auf Kubernetes zu verstehen und wie Kubernetes-Speicher auf methodische Weise getestet und quantifiziert werden kann, damit wir mit dem Testen und Dokumentieren beginnen können Kubernetes-Speicherleistung.

Die Zusammenarbeit mit Diamanti war großartig und sie konnten uns das tiefe Verständnis von Kubernetes und Kubernetes-Speicher vermitteln, das wir für die Entwicklung unserer Testmethodik benötigten. Diamanti wurde von ehemaligen VMware-, VERITAS- und Cisco-Ingenieuren gegründet und wird von Goldman Sachs und anderen bekannten VCs finanziert. Das ist beeindruckend, aber was noch beeindruckender ist, ist, dass Diamanti einen wichtigen Beitrag zu den Speicher- und Netzwerkstandards (nämlich FlexVolume/CSI) geleistet hat und CNI), die in den Upstream-Kubernetes-Code akzeptiert wurden.

Das Unternehmensgeschäft entwickelt sich mit Lichtgeschwindigkeit weiter, und Unternehmen versuchen, mit dieser Entwicklung mit neuen Technologien Schritt zu halten, um ihren gesamten Produktionszyklus von Anwendungen zu beschleunigen. Container waren die Technologie, die entwickelt wurde, um die Anwendungsentwicklung und -bereitstellung zu beschleunigen. Der Aufbau auf einer veralteten Infrastruktur kann jedoch kompliziert sein und schnell zu einem erheblichen Hindernis für die Strukturierung eines voll funktionsfähigen Containerstapels werden. Container sind mit der herkömmlichen Speicher- und Netzwerkinfrastruktur nicht kompatibel, daher ist der Do-it-yourself-Ansatz (DIY) zum Aufbau einer Containerumgebung eine IT-Herausforderung, kostspielig und langsam. Die Diamanti Enterprise Kubernetes-Plattform soll Infrastrukturarchitekten, IT-Betriebsleitern und Anwendungseigentümern die Geschwindigkeit, Einfachheit, Effizienz und Kontrolle bieten, die sie benötigen, um zustandsbehaftete Containeranwendungen in großem Maßstab auszuführen.

Die Diamanti Enterprise Kubernetes-Plattform ist eine Bare-Metal-Containerplattform, die sich auf die Netzwerk- und Speicheraspekte konzentriert, um eine schnelle Inbetriebnahme zu ermöglichen, insbesondere für große Unternehmen. Mit der vollständigen Integration von Open-Source-Docker und Kubernetes sowie speziell entwickelter Hardware und vollständiger Unterstützung für den gesamten Stack ist die Diamanti Enterprise Kubernetes-Plattform eine vollständige Containerlösung, die in wenigen Minuten bereitgestellt werden kann. Diamanti gibt an, auf seiner Enterprise Kubernetes-Plattform eine unübertroffene Leistung und Auslastung zu haben; Das Geheimnis dieser Leistung liegt in der Verwendung einer einzigartigen hyperkonvergenten Architektur, die speziell für die Art und Weise entwickelt wurde, wie Kubernetes-Container Netzwerk- und Speicherressourcen nutzen.

Diamanti D10 Spezifikationen

Network	4×10 GbE über eine einzelne QSFP+-Verbindung (pro Knoten)
Lagerung
Datenspeicher	4-TB-Konfiguration (4x 1000-GB-NVMe-SSD pro Knoten) 8-TB-Konfiguration (4x 2000-GB-NVMe-SSD pro Knoten) 32-TB-Konfiguration (4x 8000-GB-NVMe-SSD pro Knoten)
Host-Betriebssystem und Docker-Image-Speicher	960 GB (2x 480 GB SATA SSD pro Knoten)
Berechnen
CPU	2x Intel Xeon Prozessoren mit 20 / 32 / 44 Kernen (pro Knoten)
RAM	192 GB / 384 GB / 768 GB (pro Knoten
Physik
Formfaktor	1U
Abmessungen und Gewicht (pro Knoten)	17.25″B x 28″T x 1.72″H / 52 Pfund. 43.8 cm x 71.1 cm x 4.4 cm / 24 kg
Power	Zwei redundante 110/220-V-Netzteile
Umwelt	Betriebstemperatur: 50 ° F bis 95 ° F (10 ° C bis 35 ° C)

Aufbau und Design

Die Diamanti-Appliance ist die physische Hardware der Container-Stack-Lösung von Diamanti. Diese Appliance wird in einem Cluster mit mindestens drei Knoten angeboten, wobei jeder Knoten ein 1U-Rack ist, das bis zu 32 TB Datenspeicherkapazität und 960 GB für Host-Betriebssystem und Docker-Image-Speicher bietet.

Die Vorderseite eines Knotens zeigt ein Aluminiumgitter, das für eine effiziente Luftzirkulation ausgelegt ist, mit dem Firmenlogo in der Mitte und oben links einen Verriegelungsmechanismus. Oben rechts auf der Vorderseite befindet sich das Bedienfeld mit einem Netzschalter und Anzeige-LEDs für den Systemzustand. Durch Entfernen des Aluminiumgitters werden die Laufwerkssteckplätze sowie ein VGA- und zwei USB-Anschlüsse sichtbar.

Wenn wir uns zur Rückseite des Geräts bewegen, sehen wir die Anschlüsse des Geräts. Hier heben wir die linken zwei unabhängigen Stromversorgungen und ein belüftetes System hervor; und in der Mitte/rechts die beiden Management-Ports, ein 10GbE-Port zum Anschluss von Knoten mit hoher Leistung und geringer Latenz, ein QSFP+-Port (für 4x10G SFP+) und 4 USB-Ports zum Anschluss einer Tastatur und anderer Peripheriegeräte.

Management

Die Appliance wird mit einem vorintegrierten vollständigen Software-Stack geliefert, einschließlich Betriebssystem, Docker, Kubernetes und anderen Container-Konvergenzdiensten. Es bietet Dashboards und Berichtsfunktionen über einen Browser, CLI oder REST API und Diamanti OS. Die Diamanti Enterprise Kubernetes-Plattform ist K8s-zertifiziert; eine Zertifizierung, die von der CNCF-Organisation entwickelt wurde.

Zur Verwaltung greifen wir auf die Diamanti-Konsole zurück. Wenn wir es öffnen, gelangen wir direkt zum Dashboard, das grundlegende Informationen enthält, die leicht und schnell zu lesen sind. Hier können wir sehen, wie viele Knoten ausgeführt werden, wie viele Container und wie viele Pods. Die Auslastung von CPU, Speicher, Arbeitsspeicher und Netzwerk ist auf der linken Seite ebenfalls leicht in Prozent dargestellt. Auf der rechten Seite ist die Bandbreite in Kbit/s angegeben.

Die nächste Hauptregisterkarte unten ist „Anwendungen erstellen“. Sobald Benutzer die gewünschten Anwendungen erstellt haben, lautet die Unterregisterkarte „Bereitstellen“ mit einem kleinen Kubernetes-Symbol. Von hier aus müssen Benutzer Informationen wie Name, Image, Umgebung, Port, Volume-Mounts sowie die Menge an CPU und Speicher eingeben.

Die nächste Hauptregisterkarte unten ist „Anwendungen“. Unterhalb der Hauptregisterkarte befinden sich die Unterregisterkarten: Pods, Replikationscontroller, Replikatsätze, Zustandsbehaftete Sätze, Daemon-Sets, Bereitstellungen und Jobs. Pods bietet Benutzern eine kurze Zusammenfassung des Zustands eines ausgewählten Pods sowie der zugeordneten Rechenleistung, des Netzwerks und des Speichers.

Auf der Unterregisterkarte „Stateful Sets“ können Benutzer einen tieferen Einblick in die Sets erhalten und diese bei Bedarf exportieren. Hier werden uns grundlegende Informationen wie Name, Namespace, gewünschte Nummer, aktuelle Nummer, Nummer bereit, Alter und Optionen für die zu ergreifenden Maßnahmen angezeigt.

Benutzer können auch einen Drilldown in Pod-Protokolle durchführen, um Aktivitäten und mögliche Probleme anzuzeigen.

Die nächste Hauptregisterkarte unten ist „K8S-Konfigurationen“. Hier können Benutzer Kubernetes-bezogene Anwendungskonfigurationen wie Dienstkonten verwalten, Secrets und Konfigurationszuordnungen anzeigen und Namespaces erstellen.

Auf der Registerkarte „Knotenverwaltung“ können Benutzer Knoten anzeigen, hinzufügen oder löschen sowie die Nutzung der Knotenressourcen überwachen. Auch hier können Benutzer den Gesamtzustand eines bestimmten Knotens und der Ressourcen überwachen: Rechenleistung, Netzwerk und Speicher.

Wie der Name der Registerkarte schon sagt, können Benutzer mit der Speicherverwaltung alles rund um den Speicher sehen, einschließlich Volumes, Snapshots, Laufwerke, persistente Volumes, persistente Volume-Ansprüche, Speicherklassen und Backups. Auf der Unterregisterkarte „Volumes“ haben wir die Möglichkeit, ein neues Volume zu erstellen oder eine Zusammenfassung eines vorhandenen Volumes anzuzeigen, einschließlich dessen Zustand, Speicherdurchsatz und Nutzung.

Auf der Unterregisterkarte „Laufwerke“ können Benutzer die Nutzung der physischen Laufwerke mit Informationen wie dem Steckplatz des Laufwerks, seiner Seriennummer, der Rohkapazität, der nutzbaren Kapazität, der zugewiesenen Kapazität, seiner Firmware und seinem Status anzeigen. Die Laufwerke kann über diese Unterregisterkarte formatiert werden.

Auf der Unterregisterkarte „Persistente Volumes“ können Benutzer persistente Volumes erstellen oder exportieren und Informationen wie Name, Typkapazität, Zugriff, Rückforderung, Status, Anspruch, Speicherverfügbarkeit, Alter und eine Liste von Aktionen, einschließlich Bearbeiten, Exportieren usw., angeben löschen.

Persistent Volume Claims bewirkt dasselbe wie oben für PVCs.

Unsere nächste Hauptregisterkarte ist die Registerkarte Netzwerkverwaltung. Hier können Benutzer Netzwerke erstellen, löschen, bearbeiten oder exportieren. Hier erhalten wir Informationen wie Name, Gruppe, ob es sich um das Standardnetzwerk handelt, Hostnetzwerk, sein Subnetz, Gateway, Startadresse, Endadresse und IP-Adresse.

Die Benutzerverwaltung ist ziemlich einfach. Hier können Administratoren Benutzer und Gruppen erstellen und verschiedene Richtlinien zur Zugriffskontrolle einrichten.

Mit den erweiterten Einstellungen können Administratoren die Cluster- und Leistungsstufen erstellen und anpassen.

Während wir im Allgemeinen verschiedene Verwaltungsfunktionen durchlaufen, um den Lesern eine allgemeine Vorstellung davon zu geben, was sie erwartet, wenn sie etwas durchlaufen, machen wir dieses Mal etwas anderes. Wir haben auch unsere Benchmarks durchgeführt, um zu sehen, was die GUI macht, wenn eine höhere Arbeitslast darauf ausgeführt wird. Für jeden dieser Benchmarks befinden wir uns auf der Registerkarte „Knotenverwaltungen“.

Mit unseren Basistests (zufällig und sequentiell) können Sie rechts leicht die Auswirkung auf die Rechen- und Leistungsmetriken erkennen.

Unser SQL-Test verursachte eine relativ geringe Belastung der Rechenleistung und des Netzwerks, während der Speicher fast 1 Million IOPS erreichte.

Abschließend geben wir ein Beispiel dafür, was man erwartet, während unser Oracle-Test läuft.

Kennzahlen

VDBench-Workload-Analyse

Wenn es um das Benchmarking von Speicher-Arrays geht, sind Anwendungstests am besten und synthetische Tests stehen an zweiter Stelle. Obwohl sie keine perfekte Darstellung der tatsächlichen Arbeitslasten darstellen, helfen synthetische Tests dabei, Speichergeräte mit einem Wiederholbarkeitsfaktor zu vergleichen, der es einfach macht, Konkurrenzlösungen direkt miteinander zu vergleichen. Diese Workloads bieten eine Reihe unterschiedlicher Testprofile, die von „Vier-Ecken“-Tests und allgemeinen Datenbankübertragungsgrößentests bis hin zu Trace-Erfassungen aus verschiedenen VDI-Umgebungen reichen. Alle diese Tests nutzen den gemeinsamen Vdbench-Workload-Generator mit einer Skript-Engine, um Ergebnisse über einen großen Computing-Testcluster zu automatisieren und zu erfassen. Dadurch können wir dieselben Arbeitslasten auf einer Vielzahl von Speichergeräten wiederholen, einschließlich Flash-Arrays und einzelnen Speichergeräten.

Profile:

4K Random Read: 100 % Read, 128 Threads, 0-120 % Iorate
4K Random Write: 100 % Schreiben, 64 Threads, 0-120 % Iorate
64K sequentielles Lesen: 100 % Lesen, 16 Threads, 0-120 % Leserate
64K Sequentielles Schreiben: 100 % Schreiben, 8 Threads, 0-120 % Iorate
Synthetische Datenbank: SQL und Oracle

In allen unseren VDBench-Tests haben wir die Diamanti-Appliance anhand verschiedener Bereitstellungen mit 3, 6, 9 oder 12 Vdbench-Pods gleichzeitig getestet, um die Grenzen der Appliance zu erweitern. Beginnend mit der zufälligen 4K-Leseleistung starteten alle Vdbench-Pods mit einer Latenz von 120 μs; und die E/A-Leistung liegt zwischen den 3 Pods bei 95,863 IOPS und den 12 Pods bei 269,208 IOPS. Betrachtet man die Spitzenleistung, blieben alle Konfigurationen unter der Latenz von 600 μs. Mit 3 Vdbench-Pods sahen wir einen Spitzenwert von 947,619 IOPS bei einer Latenz von 370 μs; mit 6 Pods ein Spitzenwert von 1,745,344 IOPS mit einer Latenz von 436 μs; mit 9 Pods ein Spitzenwert von 2,492019 IOPS bei einer Latenz von 447μs; und die letzte Bereitstellung, 12 Pods, erreichte einen Spitzenwert von 2,753,170 IOPS mit einer Latenz von 554 μs.

Betrachtet man die 4K-Schreibleistung, so begannen alle Testbereitstellungen mit einer Latenz von 300 μs, stiegen aber bei Erreichen der maximalen Leistung schnell zwischen 26 ms und 28 ms an. Die Leistung erreichte mit 3 Pods ihren Höhepunkt bei 13,719 IOPS; 6 Pods mit 27,747 IOPS; 9 Pods mit 42,805 IOPS; und mit 12 Pods bei 58,559 IOPS. Zeigt eine stetige Leistungssteigerung bei mehr hinzugefügten Pods.

Bei der Umstellung auf sequentielle Workloads betrachten wir die 64K-Leseleistung der Appliance. Hier begann die 3-Pods-Bereitstellung bei 14,560 IOPS oder 910 MB/s mit einer Latenz von 297 μs. Alle anderen Bereitstellungen begannen in der Nähe von 18,000 IOPS oder 1.1 GB/s mit einer Latenz von 227 μs. Was die Spitzenleistung der Bereitstellungen betrifft, erreichte die Bereitstellung mit 3 Pods einen Spitzenwert von 143,431 IOPS oder 9 GB/s bei einer Latenz von 327 μs. Alle anderen Bereitstellungen erreichten ihren Höhepunkt mit nahezu der gleichen Leistung von 179,000 IOPS oder 11.1 GB/s, wobei die Bereitstellung mit 12 Pods die einzige war, die die Marke von 1 ms Latenz überschritt.

Beim sequentiellen 64-KByte-Schreiben starteten alle Bereitstellungen des Vdbench mit einer Latenz von nahezu 350 μs. Die Bereitstellungen erreichten folgende Spitzenwerte: 3 Pods mit 9,693 IOPS oder 606 MB/s und einer Latenz von 4.9 ms; die 6 Pods mit 22,202 IOPS oder 1.39 GB/s und einer Latenz von 4.3 ms; die 9 Pods mit 30,475 IOPS oder 1.9 GB/s und einer Latenz von 4.7 ms; und schließlich erreichten die 12 Pods einen Spitzenwert von 32,052 IOPS oder 2.4 GB/s mit einer Latenz von 4.9 ms.

Unsere nächste Testreihe sind unsere SQL-Workloads: SQL, SQL 90-10 und SQL 80-20. Bei SQL begannen alle Bereitstellungen mit einer Latenz von 180 μs. Die 3 Pods starteten mit 26,291 IOPS und erreichten einen Spitzenwert von 261,573 IOPS mit einer Latenz von 366 μs. Die 6 Pods erreichten zunächst 57,061 IOPS und erreichten einen Spitzenwert von 570,642 IOPS mit einer Latenz von 336 μs. Die 9 Pods starteten mit 86,197 IOPS und erreichten einen Spitzenwert von 885,269 IOPS mit einer Latenz von 332 μs. Und die Bereitstellung der 12 Pods begann bei 101,753 IOPS und erreichte einen Spitzenwert von 1,106,860 IOPS mit einer Latenz von 346 μs.

Bei SQL 90-10 begannen alle Bereitstellungen nahe der Latenzzeit von 200 μs. Die Bereitstellung der 3 Pods begann mit 10,753 IOPS und erreichte einen Spitzenwert von 105,877 IOPS mit einer Latenz von 904 μs. Die 6 Pods erreichten zunächst 49,361 IOPS und erreichten einen Spitzenwert von 245,158 IOPS mit einer Latenz von 782 μs. Die 9 Pods starteten mit 80,157 IOPS und erreichten einen Spitzenwert von 401,444 IOPS mit einer Latenz von 716 μs. Und die Bereitstellung der 12 Pods begann bei 55,748 IOPS und erreichte einen Spitzenwert von 554,685 IOPS mit einer Latenz von 690 μs.

Bei unserem letzten SQL-Test, dem 80-20, sahen wir, dass die Vdbench-Bereitstellungen ebenfalls sehr nahe bei der Latenz von 200 μs begannen. Die Bereitstellungen erreichten wie folgt ihren Höhepunkt: die 3-Pods-Bereitstellung mit 57,944 IOPS mit einer Latenz von 1.6 ms; die 6 Pods erreichten einen Spitzenwert von 132,384 IOPS mit einer Latenz von 1.4 ms; die 9 Pods 217,273 IOPS mit einer Latenz von 1.3 ms; und die Bereitstellung mit 12 Pods erreichte einen Spitzenwert von 305,426 IOPS mit einer Latenz von 1.2 ms.

Als nächstes folgen unsere Oracle-Workloads: Oracle, Oracle 90-10 und Oracle 80-20. Bei Oracle starteten alle Bereitstellungen unter 210 μs. Hier sehen wir die Spitzenleistung der Bereitstellungen. Die drei Pods erreichten einen Spitzenwert von 3 IOPS mit einer Latenz von 54,844 ms. Die 2.2 Pods erreichten einen Spitzenwert von 6 IOPS mit einer Latenz von 125,633 ms. Die 1.9 Pods erreichten einen Spitzenwert von 9 IOPS mit einer Latenz von 206,024 ms. Und die Bereitstellung von 1.7 Pods erreichte einen Spitzenwert von 12 IOPS mit einer Latenz von 290,313 ms.

In Oracle 90-10 starteten die Bereitstellungen unter 200 μs. Der Einsatz der drei Pods erreichte einen Spitzenwert von 3 IOPS mit einer Latenz von 106,182 μs. Die 620 Pods erreichten einen Spitzenwert von 6 IOPS mit einer Latenz von 243,383 μs. Die 541 Pods erreichten einen Spitzenwert von 9 IOPS mit einer Latenz von 393,727 μs. Und schließlich erreichte die Bereitstellung von 502 Pods einen Spitzenwert von 12 IOPS mit einer Latenz von 544,584 μs.

Für Oracle 80-20 sahen wir noch einmal, dass alle Bereitstellungen mit einer Latenz von 210 μs begannen. Wenn wir uns die Spitzenleistung der Bereitstellungen ansehen, sehen wir, dass die drei Pods einen Spitzenwert von 3 IOPS mit einer Latenz von 58,037 ms erreichen; die 1.1 Pods erreichen einen Spitzenwert von 6 IOPS mit einer Latenz von 132,911 μs; die 991 Pods erreichen einen Spitzenwert von 9 IOPS mit einer Latenz von 215,817 μs; und schließlich erreichte die Bereitstellung von 915 Pods einen Spitzenwert von 12 IOPS mit einer Latenz von 304,391 μs.

Fazit

Kubernetes wurde von kleineren Unternehmen akzeptiert und entwickelt sich nun zu einer Technologie, die die meisten, wenn nicht alle Fortune-500-Unternehmen, in Betracht ziehen und einige der zukunftsorientierteren Unternehmen mit deren Implementierung beginnen. Kubernetes gibt es erst seit fünf Jahren, hat aber die Innovatoren-Tranche auf der Technologieeinführungskurve bestanden und gehört fest zum Lager der Early Adopters. Diese Positionierung auf der Technologieakzeptanzkurve ist wichtig, da die Kubernetes-Community herausgefunden hat, wie man Kubernetes zum Laufen bringt, und sich nun darauf konzentriert, es gut zum Laufen zu bringen. Wir hoffen, dass Tests wie diese Kubernetes-Konsumenten bei der Entscheidung für die Anbieter helfen werden und helfen Sie den Anbietern, indem Sie ihnen einen Standard geben, mit dem sie sich vergleichen können.

Diamanti hat mit der D10-Container-Appliance eine überzeugende Kubernetes-Lösung entwickelt, die eine informative und einfach zu bedienende Verwaltungsoberfläche und eine sehr schnelle Backend-Speicherplattform für das Hosting von Containern bietet. Da dies noch ein aufstrebendes Feld ist, gibt es nicht viele vollständig ausgereifte Lösungen auf dem Markt, aber nach dem, was wir gesehen haben, ist der D10 in der Lage, alle Erwartungen zu erfüllen, die wir traditionell von einem erwarten würden Speicher- oder HCI-Lösung. Die Leistung ist im Allgemeinen fantastisch und bietet weit über 2.7 Millionen IOPs 4K-Zufallslesevorgänge aus unserem Cluster, der 3 bis 12 Pods testet. Aus Sicht der Latenz begannen wir bei knapp über 100 Mikrosekunden und erreichten die Spitze bei 600 Mikrosekunden. Was den Speicher betrifft, ist das eine unglaubliche Leistung, und von einer aufstrebenden Technologieplattform aus ist das ziemlich unglaublich. Aus Schreibsicht bot die Appliance 50 IOPS 4K Random, was die einzige Schwäche zu sein scheint, die das Unternehmen jedoch über Software oder vielleicht sogar Speichermedien beheben kann. Die sequentielle Bandbreite bot Lesegeschwindigkeiten von über 11 GB/s, wiederum eine sehr starke und nutzbare Leistung, wobei die Schreibgeschwindigkeiten in der Spitze bei 2.4 GB/s lagen.

Insgesamt bietet die Diamanti D10-Container-Appliance für Kunden, die Kubernetes in ihrer Umgebung einsetzen, einen großartigen schlüsselfertigen Ansatz aus der Hosting- und Speicherperspektive für diejenigen, die sich ernsthaft mit dem Markt für schnelle und lose Container befassen möchten. Fairerweise muss man sagen, dass dies nicht jedermanns Sache ist, da der Cluster in seiner Ausrichtung ziemlich spezifisch ist. Aber wenn Sie diesem Ziel entsprechen, bietet Diamanti genau das, was diese Kunden wollen: Es ist speziell für diese Art neuer Container-Workloads entwickelt. Während es natürlich durchaus möglich ist, PKS für VMware oder alternative Lösungen zu nutzen, die stärker auf Unternehmen ausgerichtet sind, bietet Diamanti ein System mit geringer Komplexität und sollte einen Kostenvorteil gegenüber herkömmlichen Enterprise-Stacks haben. Aufgrund der Vollständigkeit der Lösung (sie verfügt zur Abwechslung über eine gute GUI) und des sehr guten Leistungsprofils haben wir den D10 zu einem würdigen Gewinner des StorageReview Editor's Choice Award gekürt.