Examen de l'appareil de conteneur Diamanti D10

Nous avons fait la connaissance de Diamanti pour la première fois il y a deux ans lors de la KubeCon 2017, et nous avons été impressionnés par leur vision : fournir une plate-forme de conteneurs bare-metal spécialement conçue pour les microservices et les environnements natifs du cloud, et optimisée pour Kubernetes ou, en gros, une plate-forme hyperconvergée. Appliance d'infrastructure pour Kubernetes. Nous avons vu cela comme un jeu intéressant et l'année dernière à KubeCon 2018, nous avons commencé à leur parler de travailler avec nous pour comprendre le stockage sur Kubernetes et comment le stockage Kubernetes peut être testé et quantifié de manière méthodique afin que nous puissions commencer à tester et documenter Performances de stockage Kubernetes.

Diamanti a été formidable de travailler avec et a été en mesure de nous fournir la compréhension approfondie de Kubernetes et du stockage Kubernetes dont nous avions besoin pour créer notre méthodologie de test. Diamanti a été lancé par d'anciens ingénieurs VMware, VERITAS et Cisco et est financé par Goldman Sachs et d'autres VC bien connus, ce qui est impressionnant, mais ce qui est plus impressionnant, c'est que Diamanti a été un contributeur majeur aux normes de stockage et de mise en réseau (à savoir FlexVolume/CSI et CNI) qui ont été acceptés dans le code Kubernetes en amont.

Les entreprises évoluent à la vitesse de la lumière et les entreprises tentent de suivre cette évolution avec de nouvelles technologies pour accélérer l'ensemble de leur cycle de production d'applications. Les conteneurs étaient la technologie conçue pour accélérer le développement et le déploiement d'applications, mais les construire sur une infrastructure héritée peut être compliqué et devient rapidement un obstacle considérable pour structurer une pile de conteneurs entièrement fonctionnelle. Les conteneurs sont incompatibles avec l'infrastructure de stockage et de réseau traditionnelle, de sorte qu'une approche de bricolage (bricolage) pour créer un environnement de conteneurs est difficile sur le plan informatique, coûteuse et lente. La plate-forme Diamanti Enterprise Kubernetes est destinée à donner aux architectes d'infrastructure, aux opérations informatiques et aux propriétaires d'applications la vitesse, la simplicité, l'efficacité et le contrôle dont ils ont besoin pour exécuter des applications conteneurisées avec état à grande échelle.

La plate-forme Diamanti Enterprise Kubernetes est une plate-forme de conteneurs bare-metal axée sur les aspects de mise en réseau et de stockage pour une mise en place et un fonctionnement rapides, en particulier pour les grandes entreprises. Avec Docker et Kubernetes open source entièrement intégrés, ainsi qu'un matériel spécialement conçu et une prise en charge complète de l'ensemble de la pile, la plateforme Diamanti Enterprise Kubernetes est une solution de conteneur complète qui peut être déployée en quelques minutes. Diamanti déclare avoir des performances et une utilisation inégalées sur sa plate-forme Enterprise Kubernetes ; le secret de cette performance est l'utilisation d'une architecture hyperconvergée unique conçue spécifiquement pour la façon dont les conteneurs Kubernetes utilisent les ressources réseau et de stockage.

Spécifications du Diamanti D10

Réseau	4×10 GbE via une seule connexion QSFP+ (par nœud)
Rangements
Stockage de données	Configuration de 4 To (4 disques SSD NVMe de 1000 XNUMX Go par nœud) Configuration de 8 To (4 disques SSD NVMe de 2000 XNUMX Go par nœud) Configuration de 32 To (4 disques SSD NVMe de 8000 XNUMX Go par nœud)
Système d'exploitation hôte et stockage d'images Docker	960 Go (2x SSD SATA 480 Go par nœud)
calcul
Processeur	2x processeurs Intel Xeon avec 20 / 32 / 44 cœurs (par nœud)
RAM	192 Go / 384 Go / 768 Go (par nœud
Physique
Facteur de forme	1U
Dimensions et poids (par nœud)	17.25″L x 28″P x 1.72″H / 52 livres. 43.8 cm x 71.1 cm x 4.4 cm / 24 kg
Puissance	Deux alimentations 110/220V redondantes
Environnemental	Température de fonctionnement : 50 °C à 95 °C (10 °F à 35 °F)

Construire et concevoir

L'appliance Diamanti est le matériel physique de la solution d'empilement de conteneurs de Diamanti. Cette appliance est proposée dans un cluster de trois nœuds minimum, où chaque nœud est un rack 1U offrant jusqu'à 32 To de capacité de stockage de données et 960 Go pour le système d'exploitation hôte et le stockage d'images Docker.

L'avant d'un nœud montre une grille en aluminium conçue pour une circulation d'air efficace avec le journal de l'entreprise au milieu et en haut à gauche, un mécanisme de verrouillage. En haut à droite de l'avant, se trouve le panneau de commande qui fournit un interrupteur d'alimentation, ainsi que des voyants indicateurs pour l'état du système. Le retrait de la grille en aluminium révélera les emplacements des emplacements de lecteur, ainsi qu'un port VGA et deux ports USB.

En se déplaçant vers l'arrière de l'appareil, nous voyons les ports de l'appareil. Ici, nous mettons en évidence les deux alimentations indépendantes de gauche et un système ventilé; et au milieu/droite, les deux ports de gestion, un port 10GbE pour connecter des nœuds à hautes performances et à faible latence, un port QSFP+ (pour 4x10G SFP+), et 4 ports USB pour connecter un clavier et d'autres périphériques.

Direction

L'appliance est livrée avec une pile logicielle complète pré-intégrée comprenant le système d'exploitation, Docker, Kubernetes et d'autres services de convergence de conteneurs. Il fournit des tableaux de bord et des fonctions de reporting via un navigateur, une API CLI ou REST et Diamanti OS. La plate-forme Diamanti Enterprise Kubernetes est certifiée K8s ; une certification conçue par l'organisme CNCF.

Pour la gestion, nous nous tournons vers la console Diamanti. En l'ouvrant, nous allons directement dans le tableau de bord qui contient des informations de base faciles à lire rapidement. Ici, nous pouvons voir combien de nœuds sont en cours d'exécution, combien de conteneurs et combien de pods. L'utilisation du processeur, du stockage, de la mémoire et du réseau est également facilement visible en pourcentage sur la gauche. À droite, la bande passante en Kbps.

L'onglet principal suivant est Créer des applications. Une fois que les utilisateurs ont créé les applications qu'ils souhaitent, le sous-onglet est Déployer avec une petite icône Kubernetes. À partir de là, les utilisateurs doivent entrer des informations telles que le nom, l'image, l'environnement, le port, les montages de volume et la quantité de CPU et de mémoire.

L'onglet principal suivant est Applications. Sous l'onglet principal se trouvent les sous-onglets : Pods, Replications Controllers, Replica Sets, Stateful Sets, Daemon Sets, Deployments et Jobs. Les pods donnent aux utilisateurs un bref résumé de la santé d'un pod sélectionné ainsi que le calcul, le réseau et le stockage attribués.

Le sous-onglet Ensembles avec état permet aux utilisateurs d'explorer davantage les ensembles et de les exporter si nécessaire. Ici, on nous présente des informations de base telles que le nom, l'espace de noms, le numéro souhaité, le numéro actuel, le numéro prêt, l'âge et les options sur les actions à entreprendre.

Les utilisateurs peuvent également explorer les journaux du pod pour voir l'activité et tout problème potentiel.

L'onglet principal suivant est Configurations K8S. Ici, les utilisateurs peuvent gérer les configurations d'application liées à Kubernetes telles que les comptes de service, voir les secrets, les cartes de configuration et créer des espaces de noms.

À partir de l'onglet Administration des nœuds, les utilisateurs peuvent afficher, ajouter ou supprimer des nœuds ainsi que surveiller l'utilisation des ressources de nœud. Là encore, les utilisateurs peuvent surveiller la santé globale d'un nœud donné et des ressources : calcul, réseau et stockage.

Comme le nom de l'onglet l'indique, l'administration du stockage permet aux utilisateurs de voir tout ce qui concerne le stockage, y compris les volumes, les instantanés, les lecteurs, les volumes persistants, les demandes de volume persistant, les classes de stockage et les sauvegardes. Sous le sous-onglet Volumes, nous avons la possibilité de créer un nouveau volume ou de voir un résumé d'un volume existant, y compris son état de santé, son débit de stockage et son utilisation.

Le sous-onglet Disques permet aux utilisateurs de voir les disques physiques exploités avec des informations telles que l'emplacement dans lequel se trouve le disque, son S/N, sa capacité brute, sa capacité utilisable, sa capacité allouée, son micrologiciel et son état. Les disques peut être formaté à partir de ce sous-onglet.

Le sous-onglet Volumes persistants permet aux utilisateurs de créer ou d'exporter des volumes persistants et de fournir des informations telles que son nom, sa capacité de type, son accès, sa récupération, son statut, sa réclamation, la disponibilité du stockage, son âge et une liste d'actions telles que la modification, l'exportation et supprimer.

Persistent Volume Claims fait la même chose que ci-dessus pour les PVC.

Notre prochain onglet principal est l'onglet Administration du réseau. Ici, les utilisateurs peuvent créer, supprimer, modifier ou exporter des réseaux. Ici, nous recevons des informations telles que le nom, le groupe, s'il s'agit du réseau par défaut, du réseau hôte, de son sous-réseau, de la passerelle, de l'adresse de début, de l'adresse de fin et de l'adresse IP.

L'administration des utilisateurs est assez simple. Ici, les administrateurs peuvent créer des utilisateurs et des groupes et configurer diverses politiques de contrôle d'accès.

Les paramètres avancés permettent aux administrateurs de créer et d'ajuster le cluster et les niveaux de performance.

Bien que nous parcourions généralement diverses fonctions de gestion pour donner aux lecteurs une idée générale de ce à quoi s'attendre lorsqu'ils parcourent quelque chose, nous faisons quelque chose d'un peu différent cette fois-ci. Nous avons également exécuté nos tests de performance afin de voir ce que fait l'interface graphique avec une charge de travail plus lourde exécutée dessus. Pour chacun de ces benchmarks nous serons dans l'onglet Node Administrations.

Avec nos tests de base (aléatoires et séquentiels), on peut facilement voir le tirage sur le calcul ainsi que les mesures de performance à droite.

Notre test SQL a causé un péage assez léger sur le calcul et le réseau tandis que le stockage a atteint près d'un million d'IOPS.

Enfin, nous donnons un exemple de ce à quoi on s'attend pendant l'exécution de notre test Oracle.

Performances

Analyse de la charge de travail VDBench

Lorsqu'il s'agit de comparer les baies de stockage, les tests d'application sont les meilleurs et les tests synthétiques viennent en deuxième position. Bien qu'ils ne soient pas une représentation parfaite des charges de travail réelles, les tests synthétiques aident à référencer les périphériques de stockage avec un facteur de répétabilité qui facilite la comparaison de pommes à pommes entre des solutions concurrentes. Ces charges de travail offrent une gamme de profils de test différents allant des tests « aux quatre coins » et des tests de taille de transfert de base de données communs, ainsi que des captures de traces à partir de différents environnements VDI. Tous ces tests exploitent le générateur de charge de travail Vdbench commun, avec un moteur de script pour automatiser et capturer les résultats sur un grand cluster de test de calcul. Cela nous permet de répéter les mêmes charges de travail sur une large gamme de périphériques de stockage, y compris les baies flash et les périphériques de stockage individuels.

Profils:

Lecture aléatoire 4K : 100 % de lecture, 128 threads, 0-120 % d'iorate
Écriture aléatoire 4K : 100 % d'écriture, 64 threads, 0-120 % de vitesse
Lecture séquentielle 64K : 100 % de lecture, 16 threads, 0-120 % d'iorate
Écriture séquentielle 64K : 100 % d'écriture, 8 threads, 0-120 % d'iorate
Base de données synthétique : SQL et Oracle

Dans tous nos tests VDBench, nous avons testé l'appliance Diamanti sur la base de différents déploiements exécutant 3, 6, 9 ou 12 pods Vdbench à la fois pour repousser les limites de l'appliance. En commençant par des performances de lecture 4K aléatoires, tous les pods Vdbench ont démarré avec une latence de 120 μs ; et des performances d'E/S comprises entre les 3 pods à 95,863 12 IOPS et 269,208 pods à 600 3 IOPS. En ce qui concerne les performances de pointe, toutes les configurations sont restées sous la latence de 947,619 μs. Avec 370 pods Vdbench, nous avons enregistré un pic de 6 1,745,344 IOPS avec une latence de 436 μs ; avec 9 pods, un pic de 2,492019 447 12 IOPS avec une latence de 2,753,170 μs ; avec 554 pods, un pic de XNUMX IOPS à une latence de XNUMXμs ; et le dernier déploiement, XNUMX pods, a culminé à XNUMX XNUMX XNUMX IOPS avec une latence de XNUMX μs.

En ce qui concerne les performances d'écriture 4K, tous les déploiements de test ont commencé avec une latence de 300 μs, mais ont rapidement augmenté entre 26 ms et 28 ms lorsqu'ils ont atteint les performances maximales. Les performances ont culminé avec 3 pods à 13,719 6 IOPS ; 27,747 pods à 9 42,805 IOPS ; 12 pods à 58,559 XNUMX IOPS ; et avec XNUMX pods à XNUMX XNUMX IOPS. Affichage d'une augmentation constante des performances sur davantage de pods ajoutés.

En passant aux charges de travail séquentielles, nous examinons les performances de lecture de 64K de l'appliance, et ici le déploiement des 3 pods a commencé à 14,560 910 IOPS ou 297 Mo/s avec une latence de 18,000 μs. Tous les autres déploiements ont commencé près des 1.1 227 IOPS ou 3 Go/s avec une latence de 143,431 μs. En ce qui concerne les performances de pointe des déploiements, le déploiement de 9 pods a culminé à 327 179,000 IOPS ou 11.1 Go/s avec une latence de 12 μs. Tous les autres déploiements ont culminé à presque les mêmes performances de 1 XNUMX IOPS ou XNUMX Go/s, le déploiement de XNUMX pods étant le seul à dépasser la latence de XNUMX ms.

En écriture séquentielle 64K, tous les déploiements du Vdbench ont démarré avec une latence proche de 350μs. Les déploiements ont culminé comme suit : 3 pods, à 9,693 606 IOPS ou 4.9 Mo/s avec une latence de 6 ms ; les 22,202 pods, à 1.39 4.3 IOPS ou 9 Go/s avec une latence de 30,475 ms ; les 1.9 pods, à 4.7 12 IOPS ou 32,052 Go/s avec une latence de 2.4 ms ; et enfin les 4.9 pods ont atteint un pic à XNUMX XNUMX IOPS ou XNUMX Go/s avec une latence de XNUMX ms.

Notre prochaine série de tests concerne nos charges de travail SQL : SQL, SQL 90-10 et SQL 80-20. Pour SQL, tous les déploiements ont démarré sous la latence de 180 μs. Les 3 pods ont démarré à 26,291 261,573 IOPS et ont culminé à 366 6 IOPS avec une latence de 57,061 μs. Les 570,642 pods ont commencé à 336 9 IOPS et ont culminé à 86,197 885,269 IOPS avec une latence de 332 μs. Les 12 pods ont commencé à 101,753 1,106,860 IOPS et ont culminé à 346 XNUMX IOPS avec une latence de XNUMX μs. Et le déploiement de XNUMX pods a commencé à XNUMX XNUMX IOPS et a atteint un pic à XNUMX XNUMX XNUMX IOPS avec une latence de XNUMX μs.

Pour SQL 90-10, tous les déploiements ont commencé près de la latence de 200μs. Le déploiement des 3 pods a commencé à 10,753 105,877 IOPS et a culminé à 904 6 IOPS avec une latence de 49,361 μs. Les 245,158 pods ont commencé à 782 9 IOPS et ont culminé à 80,157 401,444 IOPS avec une latence de 716 μs. Les 12 pods ont commencé à 55,748 554,685 IOPS et ont culminé à 690 XNUMX IOPS avec une latence de XNUMX μs. Et le déploiement de XNUMX pods a commencé à XNUMX XNUMX IOPS et a atteint un pic à XNUMX XNUMX IOPS avec une latence de XNUMX μs.

Pour notre dernier test SQL, le 80-20, nous avons vu les déploiements Vdbench démarrer également très près de la latence de 200μs. Les déploiements ont connu un pic comme suit : le déploiement de 3 pods à 57,944 1.6 IOPS avec une latence de 6 ms ; les 132,384 pods ont culminé à 1.4 9 IOPS avec une latence de 217,273 ms ; les 1.3 pods 12 305,426 IOPS avec une latence de 1.2 ms ; et le déploiement de XNUMX pods a culminé à XNUMX XNUMX IOPS avec une latence de XNUMX ms.

Viennent ensuite nos charges de travail Oracle : Oracle, Oracle 90-10 et Oracle 80-20. Avec Oracle, tous les déploiements ont commencé sous 210μs. Ici, nous voyons les performances de pointe des déploiements. Les 3 pods ont culminé à 54,844 2.2 IOPS avec une latence de 6 ms. Les 125,633 pods ont culminé à 1.9 9 IOPS avec une latence de 206,024 ms. Les 1.7 pods ont culminé à 12 290,313 IOPS avec une latence de 1.6 ms. Et le déploiement de XNUMX pods a culminé à XNUMX XNUMX IOPS avec une latence de XNUMX ms.

Dans Oracle 90-10, les déploiements ont commencé sous 200μs. Le déploiement des 3 pods a atteint un pic à 106,182 620 IOPS avec une latence de 6 μs. Les 243,383 pods ont culminé à 541 9 IOPS avec une latence de 393,727 μs. Les 502 pods ont culminé à 12 544,584 IOPS avec une latence de 483 μs. Et enfin, le déploiement de XNUMX pods a culminé à XNUMX XNUMX IOPS avec une latence de XNUMX μs.

Pour Oracle 80-20, nous avons vu une fois de plus tous les déploiements démarrer à une latence de 210μs. En regardant les performances de pointe des déploiements, nous voyons les 3 pods culminer à 58,037 1.1 IOPS avec une latence de 6 ms ; les 132,911 pods culminant à 991 9 IOPS avec une latence de 215,817 μs ; les 915 pods culminant à 12 304,391 IOPS avec une latence de 865 μs ; et enfin, le déploiement de XNUMX pods a culminé à XNUMX XNUMX IOPS avec une latence de XNUMX μs.

Conclusion

Kubernetes a été accepté par les petites entreprises et est en train de devenir une technologie que la plupart, sinon toutes les entreprises du Fortune 500, envisagent et, certaines des plus avant-gardistes, commencent à mettre en œuvre. Kubernetes n'existe que depuis 5 ans, mais a dépassé la tranche des innovateurs sur la courbe d'adoption de la technologie et est solidement dans le camp des premiers utilisateurs. Ce positionnement sur la courbe d'adoption de la technologie est important car la communauté Kubernetes a compris comment faire fonctionner Kubernetes et se concentre maintenant sur son bon fonctionnement et nous espérons que des tests tels que ceux-ci aideront les consommateurs de Kubernetes à décider avec quels fournisseurs aller. et aidez les fournisseurs en leur donnant une norme à laquelle se comparer.

Diamanti a construit une solution Kubernetes convaincante avec l'appliance de conteneur D10, offrant une interface de gestion informative et simple à utiliser et une plate-forme de stockage backend très rapide pour l'hébergement de conteneurs. Comme il s'agit encore d'un domaine émergent, il n'y a pas beaucoup de solutions entièrement étoffées sur le marché, mais d'après ce que nous avons vu, le D10 est capable de frapper toutes les marques pour ce que nous regardons traditionnellement d'un stockage ou solution HCI. Les performances sont généralement fantastiques, offrant bien plus de 2.7 millions d'IOP en lecture aléatoire 4K à partir de notre cluster testant 3 à 12 pods. Du point de vue de la latence, nous avons commencé à un peu plus de 100 microsecondes et avons atteint 600 microsecondes. En termes de stockage, c'est incroyablement performant, et à partir d'une plate-forme technologique émergente, c'est assez incroyable. Du point de vue de l'écriture, l'appliance offrait 50 4 IOPS 11K aléatoires, ce qui semble être la seule faiblesse, mais quelque chose que l'entreprise devrait pouvoir résoudre via un logiciel ou peut-être même un support de stockage. La bande passante séquentielle offerte lit des vitesses supérieures à 2.4 Go/s, encore une fois des performances très solides et utilisables, avec des vitesses d'écriture atteignant XNUMX Go/s au maximum.

Dans l'ensemble, pour les clients déployant Kubernetes dans leur environnement, l'appliance de conteneur Diamanti D10 offre une excellente approche clé en main du point de vue de l'hébergement et du stockage pour ceux qui cherchent à se pencher sérieusement sur le marché des conteneurs rapides et mobiles. Pour être juste, ce n'est pas pour tout le monde, le cluster est assez spécifique dans son ciblage. Mais si vous correspondez à cet objectif, Diamanti offre exactement ce que ces clients veulent, il est spécialement conçu pour ces types de charges de travail de conteneurs émergentes. Bien qu'il soit tout à fait possible de tirer parti de PKS pour VMware ou d'autres solutions plus axées sur l'entreprise, Diamanti propose un système peu complexe et qui devrait présenter un avantage en termes de coûts par rapport aux piles d'entreprise traditionnelles. En raison de l'exhaustivité de la solution (elle a une bonne interface graphique pour changer) et du très bon profil de performances, nous avons déterminé que le D10 était un digne gagnant du StorageReview Editor's Choice Award.