Il ne fait aucun doute qu'Amazon est le leader en ce qui concerne une variété de services cloud proposés via son service Web EC2 (Elastic Compute Cloud). Avec un processus de provisionnement relativement simple et la possibilité d'augmenter ou de réduire facilement les instances et les besoins de stockage, EC2 vise à offrir toutes les promesses du cloud à des prix abordables. Pour certains, cependant, le cloud n'est pas qu'une question de flexibilité et de facilité de déploiement ; c'est une question de performances. Les avantages commerciaux de pouvoir faire tourner des environnements puissants vers le haut ou vers le bas pour des applications critiques comme l'analytique peuvent souvent largement dépasser les dépenses de le faire via OPEX au lieu de l'investissement à long terme de CAPEX. À cette fin, en mai, Amazon a mis en disponibilité la famille d'instances bare metal i3 qui fournit un accès direct aux ressources CPU et mémoire du serveur sous-jacent.
Il ne fait aucun doute qu'Amazon est le leader en ce qui concerne une variété de services cloud proposés via son service Web EC2 (Elastic Compute Cloud). Avec un processus de provisionnement relativement simple et la possibilité d'augmenter ou de réduire facilement les instances et les besoins de stockage, EC2 vise à offrir toutes les promesses du cloud à des prix abordables. Pour certains, cependant, le cloud n'est pas qu'une question de flexibilité et de facilité de déploiement ; c'est une question de performances. Les avantages commerciaux de pouvoir faire tourner des environnements puissants vers le haut ou vers le bas pour des applications critiques comme l'analytique peuvent souvent largement dépasser les dépenses de le faire via OPEX au lieu de l'investissement à long terme de CAPEX. À cette fin, en mai, Amazon a mis en disponibilité la famille d'instances bare metal i3 qui fournit un accès direct aux ressources CPU et mémoire du serveur sous-jacent.
Les instances i3.metal sont construites sur le système Nitro, qui est une collection de composants de déchargement matériel et de protection de serveur conçus par AWS qui « fournissent en toute sécurité des ressources de mise en réseau et de stockage hautes performances aux instances EC2 ». Les instances i3.metal tirent également parti de tous les autres services proposés par AWS Cloud, comme Elastic Block Store (EBS), que nous avons exploité dans le cadre de cet examen. Les instances comportent également jusqu'à 15.2 To de stockage d'instance sur SSD NVMe, ainsi que des processeurs Intel Xeon à 2.3 GHz offrant 36 cœurs hyper-threadés (72 processeurs logiques) et 512 Gio de mémoire. Du côté de la structure, les instances i3.metal fournissent jusqu'à 25 Gbit/s de bande passante réseau agrégée, générant un débit réseau élevé et une latence plus faible via la mise en réseau améliorée basée sur l'adaptateur réseau élastique (ENA).
Dans EC2, il existe un certain nombre de types d'instances. Les instances i3 entrent dans la catégorie "Storage Optimized", les instances i3.metal étant les plus performantes de ce groupe. Le tableau ci-dessous met en évidence la famille et la configuration des types d'instance.
| Modèle | Processeur virtuel | Mémoire (Gio) | Performances de mise en réseau | Stockage (To) |
| i3.grand | 2 | 15.25 | Jusqu'à 10 Gigabits | 1 SSD NVMe 0.475 |
| i3.xlarge | 4 | 30.5 | Jusqu'à 10 Gigabits | 1 SSD NVMe 0.95 |
| i3.2xlarge | 8 | 61 | Jusqu'à 10 Gigabits | 1 SSD NVMe 1.9 |
| i3.4xlarge | 16 | 122 | Jusqu'à 10 Gigabits | 2 SSD NVMe 1.9 |
| i3.8xlarge | 32 | 244 | 10 Gigabit | 4 SSD NVMe 1.9 |
| i3.16xlarge | 64 | 488 | 25 Gigabit | 8 SSD NVMe 1.9 |
| i3.métal | 72 | 512 | 25 Gigabit | 8 SSD NVMe 1.9 |
Les instances i3.metal sont disponibles dans les régions AWS USA Est (Virginie du Nord), USA Est (Ohio), USA Ouest (Oregon), Europe (Francfort) et Europe (Irlande) et peuvent être achetées en tant qu'instances à la demande, Instances réservées (3 ans, 1 an et convertibles) ou en tant qu'instances Spot. Aux fins de cet examen, nous avons effectué des tests dans la région de Virginie du Nord. Nous avons testé à la fois le stockage NVMe et les volumes de blocs EBS.
Performance
Analyse de la charge de travail VDBench
Pour évaluer les performances de l'instance EC2 i3.metal, nous avons utilisé VDBench installé localement pour tester à la fois le stockage EBS (30 x 1 To) et NVMe (8 x 1.7 To). Avec les deux types de stockage, nous avons alloué 12 % de chaque périphérique et les avons regroupés pour examiner les performances maximales du système avec une quantité modérée de localité de données.
Ces charges de travail offrent une gamme de profils de test différents allant des tests « aux quatre coins », 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
- Traces de clone lié VDI
Nous examinons à la fois EBS et NVMe dans cette revue. Puisqu'il existe une différence de performances considérable, nous avons séparé les résultats en deux graphiques (la latence serait si éloignée que les graphiques seraient très difficiles à lire).
Notre premier test porte sur la lecture aléatoire 4K. Ici, l'instance EBS avait des performances de latence inférieures à la milliseconde jusqu'à la fin. Juste à environ 64 59.46 IOPS, la latence a augmenté à 64,047 ms avec des performances de XNUMX XNUMX IOPS.
En regardant la lecture aléatoire de pointe NVMe 4K, nous voyons que l'instance fonctionne bien mieux. L'instance a culminé à 2,802,904 348 XNUMX IOPS avec une latence de XNUMX μs.
L'écriture aléatoire 4K avec EBS a vu presque la même chose que les lectures 4K avec EBS. L'instance a cassé 1 ms un peu plus tôt, environ 60 64,003 IOPS, et a culminé à 29.97 XNUMX IOPS avec une latence de XNUMX ms.
Pour la version NVMe de l'instance, il y avait un léger pic de latence, mais toujours inférieur à 1 ms. L'instance a culminé à 920,975 545 IOPS avec une latence de XNUMX μs.
En passant aux tests séquentiels, pour les performances de lecture de pointe EBS 64K, l'instance avait une latence inférieure à la milliseconde jusqu'à environ 70K IOPS ou environ 450 Mo/s et culminait à 17,360 1.08 IOPS ou 27.65 Go/s avec une latence de XNUMX ms.
La lecture séquentielle 64K avec le NVMe nous a donné des performances maximales de 244,037 15.25 IOPS ou 514 Go/s avec une latence de XNUMX μs.
Avec 64K d'écriture avec EBS, l'instance a démarré au-dessus de 1 ms et a culminé à 17,359 1.08 IOPS ou 13.8 Go/s avec une latence de XNUMX ms.
L'écriture séquentielle 64K est la première fois que nous voyons l'instance NVMe dépasser 1 ms. L'instance a culminé à 58,572 3.66 IOPS ou 1.08 Go/s avec une latence de XNUMX ms.
En passant à nos charges de travail SQL, l'instance EBS avait des performances de latence inférieures à la milliseconde jusqu'à environ 55 64,036 IOPS et culminait à 14.93 XNUMX IOPS avec une latence de XNUMX ms.
Pour la version NVMe de l'instance, nous avons constaté des performances de pointe de 834,231 302 IOPS avec une latence de XNUMX μs pour le test SQL.
Pour le SQL 90-10 avec EBS, l'instance a de nouveau dépassé la latence de 1 ms autour de 55 64,036 IOPS et a atteint un pic à 14.99 XNUMX IOPS avec une latence de XNUMX ms.
La version NVMe de l'instance dans SQL 90-10 avait une performance maximale de 605,150 415 IOPS et une latence de XNUMX μs.
Le SQL 80-20 avec EBS a de nouveau donné à peu près les mêmes chiffres avec une latence inférieure à la milliseconde se terminant autour de 55 64,036 IOPS et un pic de 14.93 XNUMX IOPS avec une latence de XNUMX ms.
Le SQL 80-20 avec NVMe avait des nombres d'instances de 511,840 493 IOPS et une latence de XNUMX μs.
Les tests Oracle pour EBS ont montré les mêmes performances de pointe impaires avec presque les mêmes nombres. Pour Oracle, l'instance a atteint 64,036 13.6 IOPS avec une latence de 55 ms. L'instance avait des performances de latence inférieures à la milliseconde jusqu'à environ XNUMX XNUMX IOPS.
Avec NVMe, l'instance a atteint 457,372 613 IOPS avec une latence de XNUMX μs dans le test Oracle.
Oracle 90-10 avait le pic d'instance EBS à 64,035 10.3 IOPS avec une latence de 1 ms. L'instance a cassé 55 ms à environ XNUMX XNUMX IOPS.
La version NVMe de l'instance dans Oracle 90-10 a pu atteindre 520,448 333 IOPS avec une latence de XNUMX μs.
Oracle 80-20 a eu une pause EBS de 1 ms autour de 55 64,036 IOPS et un pic à 10.3 XNUMX IOPS avec une latence de XNUMX ms.
L'instance avec NVMe avait des performances maximales de 435,265 400 IOPS avec une latence de XNUMX μs.
Ensuite, nous examinons nos tests VDI Linked Clone (LC). À partir de Boot, la version EBS de l'instance avait une latence inférieure à la milliseconde jusqu'à environ 35 42,893 IOPS et a culminé à 11.2 XNUMX IOPS avec une latence de XNUMX ms.
La version NVMe de l'instance a pu culminer à 349,799 363 IOPS et une latence de XNUMX μs dans notre test de démarrage VDI LC.
Pour la connexion initiale VDI LC, l'instance EBS a chevauché la ligne de 1 ms pendant un certain temps avant de tomber sur environ 31 34,486 IOPS. L'instance a culminé à 6.95 XNUMX IOPS et une latence de XNUMX ms.
Avec VDI LC Initial Login, l'instance NVMe a culminé à 93,405 677 IOPS avec une latence de XNUMX μs.
Avec le VDI LC Monday Login, une fois de plus, l'instance EBS a flirté avec 1 ms pendant un certain temps avant de plonger autour de 25 34,643 IOPS et de culminer à 13.85 XNUMX IOPS avec une latence de XNUMX ms.
Et enfin, notre VDI LC Monday Login avec NVMe a eu le pic d'instance à 119,615 1.1 IOPS avec une latence de XNUMX ms.
Conclusion
Les services cloud d'Amazon sont généralement considérés comme les plus polyvalents. Bien que le calcul et le stockage soient certainement variés, Amazon propose également des options de performances. Amazon propose une pléthore d'options de performances sur son service Web EC2, y compris son instance bare metal i3. Ces instances exploitent le système AWS Nitro de matériel et de logiciels spécialement conçus. Les instances i3.metal offrent de meilleures performances grâce à un accès direct aux processeurs et à la mémoire tout en offrant aux utilisateurs la possibilité de tirer parti d'autres fonctionnalités telles que le stockage attaché AWS EBS et le stockage NVMe local.
Pour les performances, nous avons testé à la fois le stockage par blocs (EBS) et NVMe. Cela a pour but de donner aux lecteurs une idée de ce à quoi s'attendre en termes d'options, et moins l'une étant meilleure que l'autre (généralement, le stockage NVMe fonctionne mieux et a une latence beaucoup plus faible, c'est pourquoi il existe deux ensembles de graphiques). En regardant l'EBS, nous avons vu un modèle où l'instance est passée au-dessus de 1 ms, puis peu de temps après, la latence et la finition ont augmenté. Tout au long de nos tests, l'EBS a culminé à environ 64 4 IOPS, ce qui est le maximum autorisé pour l'EBS. Cela comprenait les tests 64K et les trois tests SQL et Oracle. L'instance a un peu ralenti pour nos tests VDI. Amazon indique qu'il est possible de modifier les paramètres pour atteindre plus que les XNUMX XNUMX IOPS prescrits, mais les processus pour y parvenir ne correspondent pas à ce que la plupart des clients connaîtraient, nous n'avons donc pas suivi cette voie.
Pour nos tests NVMe, nous avons vu des résultats plus conformes à nos références normales. Les points forts ici comprenaient une performance de lecture 4K aléatoire de 2.8 millions d'IOPS, une écriture 4K de 920K IOPS, une lecture 64K de 15.25 Go/s et des performances SQL supérieures à 500K IOPS dans les trois tests (le test SQL étant d'environ 834K IOPS). Les tests Oracle ont également eu de bons résultats avec le NVMe, avec des résultats entre 435K IOPS et 520K IOPS. Notre clone lié VDI a montré de bonnes performances de démarrage avec environ 350 3 IOPS. La seule déception ici est que les clients ne peuvent pas opter pour plus de NVMe local dans les instances iXNUMX.metal.
Dans l'ensemble, l'instance i3.metal nous a donné exactement ce qu'Amazon avait promis. C'est rassurant pour les clients qui veulent savoir qu'ils vont recevoir le niveau de service promis. Ce n'est bien sûr pas sans coût, comme pour tout déploiement cloud, la préoccupation va porter sur la facilité d'utilisation et les résultats dans le cloud par rapport aux autres fournisseurs de cloud par rapport à sur site. Cela dit, les clients dont les charges de travail peuvent se contenter d'un niveau d'IOPS inférieur peuvent économiser beaucoup d'argent. Cependant, cela se résume vraiment à ce que sont les exigences ultimes pour l'instance particulière. À cette fin, les instances i3.metal sont idéales pour les applications grand public qui ne vont pas ou ne sont pas capables de dépasser les limites de performances offertes par i3.metal et n'ont pas besoin des IOPS qu'une baie XNUMX % flash sur site fournirait pour exemple. De plus, si vous faites déjà partie de la famille Amazon, le passage au métal nu est familier et il y a probablement un avantage en termes de coûts tout en consommant plusieurs programmes AWS en masse.
Inscrivez-vous à la newsletter StorageReview
