Examen des instances Oracle Cloud Infrastructure Compute Bare Metal

L'infrastructure Oracle Cloud comprend une grande variété d'offres de services, notamment le calcul, le stockage, la mise en réseau, la base de données et l'équilibrage de charge - en fait, toute l'infrastructure nécessaire pour construire un centre de données basé sur le cloud. Dans le cadre de cet examen, nous nous intéressons à la catégorie Oracle Cloud Infrastructure Compute, avec un accent très particulier sur leurs instances bare metal. Comme la plupart des fournisseurs de cloud, Oracle propose des instances de calcul virtualisées, mais contrairement à la plupart des autres offres virtuelles, Oracle peut les sauvegarder avec des formes contenant jusqu'à ~25 To de stockage NVMe pour les applications nécessitant une faible latence. Aussi formidables soient-elles, Oracle a encore relevé la barre des performances de calcul dans le cloud en proposant les premières instances bare metal hautes performances du secteur, idéales pour les applications critiques où la latence est primordiale. Les instances sont livrées avec jusqu'à 52 OCPU, 768 Go de RAM, deux cartes réseau 25 GbE et jusqu'à 51 To de stockage NVMe connecté localement. Pour ceux qui en veulent plus, jusqu'à 512 To de stockage de blocs NVMe en réseau sont disponibles ainsi que des options GPU. Toutes les différentes offres de calcul Oracle s'exécutent sur un réseau défini par logiciel hautement optimisé, réglé pour minimiser les conflits et optimiser les performances.

L'infrastructure Oracle Cloud comprend une grande variété d'offres de services, notamment le calcul, le stockage, la mise en réseau, la base de données et l'équilibrage de charge - en fait, toute l'infrastructure nécessaire pour construire un centre de données basé sur le cloud. Dans le cadre de cet examen, nous nous intéressons à la catégorie Oracle Cloud Infrastructure Compute, avec un accent très particulier sur leurs instances bare metal. Comme la plupart des fournisseurs de cloud, Oracle propose des instances de calcul virtualisées, mais contrairement à la plupart des autres offres virtuelles, Oracle peut les sauvegarder avec des formes contenant jusqu'à ~25 To de stockage NVMe pour les applications nécessitant une faible latence. Aussi formidables soient-elles, Oracle a encore relevé la barre des performances de calcul dans le cloud en proposant les premières instances bare metal hautes performances du secteur, idéales pour les applications critiques où la latence est primordiale. Les instances sont livrées avec jusqu'à 52 OCPU, 768 Go de RAM, deux cartes réseau 25 GbE et jusqu'à 51 To de stockage NVMe connecté localement. Pour ceux qui en veulent plus, jusqu'à 512 To de stockage en bloc NVMe connecté au réseau sont disponibles ainsi que des options GPU. Toutes les différentes offres de calcul Oracle s'exécutent sur un réseau défini par logiciel hautement optimisé, réglé pour minimiser les conflits et optimiser les performances.

Il existe une grande variété d'offres cloud à ce stade et même plusieurs grandes offres cloud avec AWS, Google Cloud Platform et Microsoft Azure en tête de liste. Bien que ces fournisseurs de services cloud proposent de nombreux produits et services de qualité, une chose qu'ils n'ont généralement pas est la performance. Lorsque l'on compare le cloud au local, le local bat toujours le cloud haut la main. Oracle cherche à changer cette vision avec ses offres d'infrastructure cloud.

Les offres de calcul d'Oracle s'accompagnent de promesses que l'on pourrait attendre d'un stockage ou de serveurs sur site, notamment en termes de performances, de disponibilité, de polyvalence et de gouvernance. Le côté performances prend en charge des performances optimales et constantes pour les applications critiques et est soutenu par le SLA d'infrastructure cloud de bout en bout récemment annoncé, qui, au moment d'écrire ces lignes, est le seul de ce type dans l'industrie. L'offre prend en charge la disponibilité sur plusieurs couches, notamment le DNS, l'équilibrage de charge, la réplication, la sauvegarde, les instantanés de stockage et le clustering. Les offres de calcul vont d'une machine virtuelle à cœur unique à un métal nu à locataire unique à 52 cœurs, offrant la polyvalence nécessaire pour tout exécuter, des charges de travail courantes aux clusters HPC. Et avec les instances bare metal d'Oracle, les clients obtiennent l'isolation et le contrôle d'un serveur sur site, car ils ne contiennent aucun autre locataire et aucun logiciel de fournisseur Oracle.

Les offres de calcul d'Oracle Cloud se présentent sous plusieurs « formes », y compris les instances bare metal, les instances GPU bare metal et les instances de machine virtuelle. Pour cet examen, nous examinerons les instances bare metal qui, selon Oracle, peuvent fournir jusqu'à 5.1 millions d'IOPS et sont destinées à des cas d'utilisation tels que les applications de base de données critiques, les charges de travail HPC et les applications Web intensives en E/S. À titre de comparaison, nous montrerons également les formes de machine virtuelle d'Oracle, avec le stockage NVMe local (DenseIO) et avec le stockage de bloc réseau (Standard).

Direction

L'interface graphique de gestion d'Oracle Cloud Infrastructure est assez simple à comprendre. La page principale contient des procédures pas à pas et une assistance, si nécessaire. En haut se trouvent la location ou le compte, la région que l'on utilise (us-ashburn-1, dans notre cas), ainsi que des onglets pour Accueil (qui est la page principale), Identité, Calcul, Base de données, Réseau, Stockage, Audit , et E-mail. Pour nos tests, DenseIO2 et Standard2 sont affichés.

Étant donné que cet examen se concentre sur le côté calcul, en regardant sous cet onglet, nous pouvons voir les instances que nous utiliserons pour nos tests de performances. Chaque instance a son nom, sa forme, sa région, son domaine de disponibilité et sa date de création. Sur le côté gauche, les utilisateurs peuvent modifier la liste en sélectionnant l'état, par exemple, "en cours d'exécution".

Cliquer sur les points de suspension sur le côté droit permet d'approfondir un peu plus une instance. En regardant le BM.DenseIO2.52, on peut facilement voir si l'instance est en cours d'exécution et obtenir des informations plus détaillées à son sujet. Des balises peuvent également lui être associées ici. En haut de l'information se trouve la possibilité de créer une image personnalisée, de démarrer, d'arrêter ou de redémarrer l'instance, de la terminer ou d'appliquer des balises. Le défilement vers le bas donne également la possibilité d'attacher des volumes de blocs.

Sous l'onglet Networking, on peut voir le Virtual Cloud Network utilisé ou en créer un. Pour le VCN, il existe des informations telles que la région, la table de routage par défaut, le domaine DNS et la date de sa création. Encore une fois, les points de suspension à droite permettent d'explorer, d'appliquer des balises et de créer un sous-réseau.

Sous l'onglet Stockage, les utilisateurs peuvent voir les volumes de blocs dans leur compartiment et en créer d'autres. Les volumes de bloc sont répertoriés par date de création et les utilisateurs peuvent rechercher plus d'informations, créer des sauvegardes manuelles, détacher le volume de bloc de l'instance, supprimer le volume ou appliquer des balises.

Et comme Audit l'implique, on peut rapidement consulter les événements passés en sélectionnant la date et la plage horaire. Cela permet aux entreprises de répondre aux besoins de conformité de gestion où l'utilisateur et l'action pour chaque événement ou modification de l'environnement sont capturés.

Performances

Analyse de la charge de travail VDBench

Pour évaluer les performances de ces instances Oracle Cloud, nous avons utilisé vdbench installé localement sur chaque plateforme. Nos tests ont été répartis sur tous les stockages locaux en même temps, donc si les deux stockages BV (Block Volume) et NVMe étaient présents, nous avons testé un groupe à la fois. 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 complet et de clone lié VDI

Nous examinons à la fois les périphériques de bloc distants (BV) et NVMe. Puisqu'il y a une telle différence de performances, nous avons séparé les résultats en deux graphiques (la latence serait si éloignée que les graphiques seraient très difficiles à lire). Pour cet examen, nous examinons à la fois les configurations Bare Metal (BM) et VM avec des exécutions d'E/S standard et denses sur BV et uniquement des exécutions d'E/S denses pour le NVMe.

En regardant le pic de lecture 4K pour BV, les quatre exécutions ont commencé avec une forte latence inférieure à la milliseconde. Le premier à se détacher a été le VM.Standard, ce qui en fait un peu moins de 53 60,591 IOPS, puis culmine à 15 1 IOPS avec une latence de 72,626 ms. Le prochain à briser la latence inférieure à la milliseconde était le VM.DenseIO, dépassant 7.5 ms à peu près au même endroit que la norme, mais culminant à 235 252,275 IOPS avec une latence de 4.1 ms. Les deux exécutions en métal nu ont fait beaucoup mieux avec les performances de latence inférieure à la milliseconde DenseIO jusqu'à environ 250 1 IOPS, culminant à 258,329 4.05 IOPS avec une latence de XNUMX ms. Le BM.Standard a atteint environ XNUMX XNUMX IOPS avant de dépasser XNUMX ms et a culminé à XNUMX XNUMX IOPS avec une latence de XNUMX ms.

En regardant les performances de lecture 4K maximales pour NVMe, les deux exécutions avaient une latence inférieure à la milliseconde tout au long. Le VM.DenseIO a culminé à 569,534 214 IOPS avec une latence de 4,419,490 μs. Le BM.DenseIO a culminé à 174.6 XNUMX XNUMX IOPS avec une latence de seulement XNUMX μs.

En passant aux performances maximales d'écriture 4K aléatoires pour BV, nous constatons un placement similaire à celui d'avant, les machines virtuelles culminant beaucoup plus tôt que les BM. Le VM.Standard a atteint environ 63 77,229 IOPS avant de briser la latence inférieure à la milliseconde et a culminé à 5.3 69 IOPS à une latence de 1 ms. Le VM.DenseIO a un peu mieux performé, atteignant environ 84,274 3.9 IOPS avant de dépasser 263 ms et culminant à 1 280,158 IOPS avec une latence de 2.02 ms. Le BM.DenseIO a pu atteindre le nord de 278 280,844 IOPS avant de dépasser 1.84 ms de latence et a culminé à XNUMX XNUMX IOPS avec une latence de XNUMX ms. Et BM.Standard était la configuration la plus performante atteignant environ XNUMX XNUMX IOPS avant de dépasser une latence inférieure à la milliseconde et culminant à XNUMX XNUMX IOPS avec une latence de XNUMX ms.

Avec le NVMe sur écriture 4K, encore une fois, le BM a surpassé la VM avec des performances de latence inférieures à la milliseconde tout au long. Le VM.DenseIO a culminé à 412,207 141 IOPS avec une latence de 3,232,215 μs. Le BM.DenseIO a culminé à 125 XNUMX XNUMX IOPS avec une latence de XNUMX μs.

Passant au travail séquentiel, nous examinons d'abord 64K lu pour BV. Le VM.Standard et le VM.DenseIO ont tous deux cassé une latence de 1 ms à environ 15.5 K IOPS ou 968 Mo/s. Et les deux ont plus ou moins maintenu les mêmes performances puisque la latence a grimpé à 8.2 ms. Encore une fois, nous avons vu quelque chose de similaire avec BM.Standard et BM.DenseIO cassant tous les deux 1 ms à environ 37.5 K IOPS ou 2.35 Go/s. Les deux configurations ont culminé juste au nord de 47 2.95 IOPS ou 8.4 Go/s avec une latence de XNUMX ms.

La lecture séquentielle 64K NVMe a permis aux deux configurations de rester en dessous de la latence inférieure à la milliseconde tout au long. Le VM.DenseIO a culminé à 39,512 2.5 IOPS ou 403 Go/s avec une latence de 323,879 μs, tandis que le BM.DenseIO a culminé à 20.2 361 IOPS ou XNUMX Go/s avec une latence de XNUMX μs.

Avec des écritures séquentielles de 64K pour BV, nous constatons à nouveau un phénomène similaire avec VM.Standard et VM.DenseIO, tous deux cassant une latence de 1 ms à une performance de 12K IOPS ou 770 Mo/s. Les deux ont culminé à environ 15.1 943 IOPS ou 3.1 Mo/s avec une latence de 1 ms. Avec le BM.Standard et le BM.DenseIO, les deux cassaient une latence de 42 ms à environ 2.6 46,768 IOPS ou 2.92 Go/s avec le BM.DenseIO culminant à 2.6 46,787 IOPS ou 2.92 Go/s avec une latence de 3.4 ms. Le BM.Standard a culminé à XNUMX XNUMX IOPS ou XNUMX Go/s avec une latence de XNUMX ms.

Pour les écritures séquentielles 64K pour NVMe, VM.DenseIO et BM.DenseIO avaient à nouveau des performances de latence inférieures à la milliseconde, mais les deux ont également subi un pic de latence (associé à une réduction finale des performances pour le BM.DenseIO). Le VM.DenseIO a culminé à 25 1.56 IOPS ou 311 Go/s avec une latence de 754 μs après un pic jusqu'à 160,895 μs. Le BM.DenseIO avait de bien meilleures performances de pointe (10.1 170 IOPS ou 132,192 Go/s avec une latence de 8.8 μs), mais il en a chuté à la fin avec une légère augmentation de la latence également, terminant à 310 XNUMX IOPS ou XNUMX Go/s. avec une latence de XNUMXμs.

Dans notre charge de travail SQL pour BV, le VM.Standard a été le premier à dépasser 1 ms à environ 50 73,259 IOPS, il a culminé à 3.4 1 IOPS avec une latence de 58 ms. VM.DenseIO a dépassé la latence de 78,624 ms à environ 3.1 1 IOPS et a culminé à 275 305,368 IOPS avec une latence de 1.7 ms. Avec les BM, les deux sont restés sous 307,979 ms de latence jusqu'à environ 1.35K (avec le BM.DenseIO fonctionnant un peu plus longtemps). Le BM.Standard a culminé à XNUMX XNUMX IOPS avec une latence de XNUMX ms tandis que le BM.DenseIO a culminé à XNUMX XNUMX IOPS avec une latence de XNUMX ms.

SQL pour NVMe a de nouveau eu une latence inférieure à la milliseconde avec le VM.DenseIO culminant à 188,786 167 IOPS avec 1,684,869 μs. Le BM.DenseIO a culminé à 142 XNUMX XNUMX IOPS avec une latence de XNUMX μs.

Dans le benchmark SQL 90-10 pour BV, les deux machines virtuelles ont dépassé les performances de latence inférieures à la milliseconde à environ 58 71,691 IOPS. Le VM.Standard a culminé à 3.5 79,033 IOPS avec une latence de 3.05 ms. Le VM.DenseIO a culminé à 1 270 IOPS avec une latence de 303,904 ms. Le BM.Standard a dépassé la latence de 1.7 ms avec une performance d'environ 290 307,472 IOPS et a culminé à 1.34 XNUMX IOPS avec une latence de XNUMX ms. Le BM.DenseIO avait une latence inférieure à la milliseconde jusqu'à environ XNUMX XNUMX IOPS et a culminé à XNUMX XNUMX IOPS avec une latence de XNUMX ms.

Pour NVMe SQL 90-10, le VM.DenseIO a culminé à 172,693 182 IOPS avec une latence de 1,328,437 μs. Le BM.DenseIO a culminé à 165 XNUMX XNUMX IOPS avec XNUMX μs.

Dans le benchmark SQL 80-20 pour BV, le VM.Standard a atteint environ 54 1 IOPS avant de dépasser 72,204 ms et a culminé à 3.4 59 IOPS avec une latence de 78,787 ms. Le VM.DenseIO avait une latence inférieure à la milliseconde jusqu'à environ 2.99 280 IOPS et a culminé à 1 300,014 IOPS avec une latence de 1.6 ms. Le BM.Standard a atteint environ 1 285 IOPS avec une latence inférieure à 299,730 ms et a culminé à 1.3 XNUMX IOPS avec une latence de XNUMX ms. Le BM.DenseIO a cassé la latence de XNUMX ms à environ XNUMX XNUMX IOPS et a culminé à XNUMX XNUMX IOPS avec une latence de XNUMX ms avant de baisser ses performances.

Dans le benchmark SQL 80-20 pour NVMe, le VM.DenseIO a culminé à 144,010 218 IOPS avec une latence de 1,114,056 μs. Le BM.DenseIO a culminé à 182 XNUMX XNUMX IOPS avec une latence de XNUMX μs avant d'avoir une légère baisse de performances.

Dans notre charge de travail Oracle avec BV, le VM.Standard avait des performances de latence inférieures à la milliseconde jusqu'à ce qu'il atteigne environ 52 70,096 IOPS et culmine à 3.4 1 IOPS avec une latence de 58 ms. Le VM.DenseIO a cassé la latence de 75,000 ms à environ 3.1 1 IOPS et a culminé à 255 280,599 IOPS avec une latence de 1.41 ms. BM.Standard a dépassé la latence de 260 ms autour de 267,632K avec une performance maximale de 1.3 XNUMX IOPS avec une latence de XNUMX ms. BM.DenseIO avait une latence inférieure à la milliseconde jusqu'à environ XNUMX XNUMX IOPS et a culminé à XNUMX XNUMX IOPS avec une latence de XNUMX ms.

Notre charge de travail Oracle avec NVMe a montré une performance maximale pour le VM.DenseIO de 132,553 257 IOPS avec une latence de 1,043,104 μs. Avec BM.DenseIO, les performances maximales étaient de 199 XNUMX XNUMX IOPS et une latence de XNUMX μs.

Dans Oracle 90-10 pour BV, le VM.Standard avait une latence inférieure à la milliseconde jusqu'à un peu plus de 54 72,533 IOPS et culminait à 2.2 1 IOPS avec une latence de 61 ms. Le VM.DenseIO a cassé la latence de 76,908 ms à environ 1.86 297 IOPS et a culminé à 1 305,771 IOPS avec une latence de 1.17 ms. Les deux BM ont atteint 297,509 1.03 IOPS avant de briser la latence de XNUMX ms. Le BM.Standard a culminé à XNUMX XNUMX IOPS avec une latence de XNUMX ms. Le BM.DenseIO avait une performance maximale de XNUMX XNUMX IOPS avec une latence de XNUMX ms.

Dans Oracle 90-10 pour NVMe, le VM.DenseIO avait une performance maximale de 133,330 163 IOPS et une latence de 1,088,454 μs. Le BM.DenseIO avait une performance maximale de 142 XNUMX XNUMX IOPS et une latence de XNUMX μs.

Dans l'Oracle 80-20 avec BV, le VM.Standard a atteint environ 55K en moins de 1 ms et a culminé à 74,032 2.14 IOPS avec une latence de 51 ms. Le VM.DenseIO avait une latence inférieure à la milliseconde jusqu'à environ 75,666K et a culminé à 2 295 IOPS avec une latence de 1 ms. Les deux BM ont atteint environ 306,955 1.14 IOPS avant de casser 295 ms. Le BM.Standard a culminé à 893 XNUMX IOPS avec une latence de XNUMX ms. Le BM.DenseIO a culminé à environ XNUMX XNUMX IOPS avec une latence de XNUMX μs.

Dans l'Oracle 80-20 avec NVMe, le VM.DenseIO a culminé à 108,483 195 IOPS avec une latence de 956,326 μs. Le BM.DenseIO a culminé à 158 XNUMX IOPS avec une latence de XNUMX μs.

Ensuite, nous avons examiné VDI Full Clone. Pour le démarrage avec BV, VM.Standard a dépassé 1 ms juste en dessous de 40 56,057 IOPS et a culminé à 4.2 43 IOPS avec une latence de 61,570 ms. VM.DenseIO l'a fait avec une latence inférieure à la milliseconde jusqu'à environ 3.6 200 IOPS et a culminé à 220 2.1 IOPS avec une latence de XNUMX ms. Les deux BM avaient une latence inférieure à la milliseconde jusqu'à un peu plus du seuil de XNUMX XNUMX IOPS. Les deux ont culminé à environ XNUMX XNUMX IOPS avec une latence de XNUMX avant de chuter en performances.

Pour le démarrage Full Clone avec NVMe, le VM.DenseIO a culminé à environ 136 235 IOPS avec une latence de 1,032,322 μs. Le BM.DenseIO a culminé à 213 XNUMX XNUMX IOPS avec une latence de XNUMX μs.

Avec VDI Full Clone Initial Log In with BV, les deux machines virtuelles ont atteint environ 41 55,522 IOPS avec une latence inférieure à la milliseconde, la VM.Standard culminant à 3.7 59,560 IOPS avec une latence de 3.6 ms et la VMDenseIO culminant à 203 225 IOPS avec une latence de 2.04 ms. . Les deux BM ont dépassé la latence inférieure à la milliseconde juste autour de 224,385 1.8 IOPS (la norme passant avant dense). BM.Standard a culminé à environ XNUMX XNUMX IOPS avec une latence de XNUMX ms et BM.DenseIO a culminé à XNUMX XNUMX IOPS avec une latence de XNUMX ms.

Pour la connexion initiale VDI Full Clone avec NVMe, le VM.Standard a culminé à 59,883 506 IOPS avec une latence de 467,761 μs. Et le BM.DenseIO a culminé à 262 XNUMX IOPS avec une latence de XNUMX μs.

VDI Full Clone Monday Login avec BV avait le VM.Standard avec une latence inférieure à la milliseconde jusqu'à un peu moins de 36 50,685 IOPS avec un pic de 2.3 1 IOPS et une latence de 38 ms. VM.DenseIO a fonctionné en moins de 53,304 ms jusqu'au nord de 2.2 1 IOPS et a culminé à 205 224,764 IOPS avec une latence de 1.5 ms. BM.Standard a dépassé la latence de 1 ms à environ 210 220 IOPS et a culminé à 1.2 XNUMX IOPS avec une latence de XNUMX ms. BM.DenseIO est passé au-dessus de XNUMX ms autour de XNUMXK avec un pic d'un peu plus de XNUMXK IOPS et une latence de XNUMX ms.

VDI Full Clone Monday Login avec NVMe a montré une performance maximale de VM.DenseIO de 44,384 356 IOPS avec une latence de 356,691 μs. BM.DenseIO a culminé à 252 XNUMX IOPS avec une latence de XNUMX μs.

Notre sélection finale de tests porte sur VDI Linked Clone. En recommençant avec le test de démarrage avec BV, le VM.Standard avait une latence inférieure à la milliseconde jusqu'à environ 29 38 IOPS, culminant à environ 2.4 32 IOPS avec une latence de 1 ms. VM.DenseIO a atteint environ 38 2.16 IOPS avant de casser 100 ms et a culminé à environ 1 114 IOPS également avec une latence de 3 ms. Les deux BM ont atteint environ XNUMX XNUMX IOPS avant de dépasser la latence de XNUMX ms. Les deux avaient des performances de pointe d'environ XNUMX XNUMX IOPS avec une latence de XNUMX ms.

Avec VDI Linked Clone Boot pour NVMe, nous avons vu le pic VM.DenseIO à 65,384 238 IOPS avec une latence de 555,004 μs. Le BM.DenseIO a culminé à 217 XNUMX IOPS avec une latence de XNUMX μs.

Avec la connexion initiale avec BV, les deux machines virtuelles ont dépassé la latence de 1 ms à environ 28 36,682 IOPS, avec le VM.Standard culminant à 1.6 38,525 IOPS avec une latence de 1.6 ms et le VM.DenseIO culminant à 1 132 IOPS avec une latence de 140,848 ms. Les deux BM ont dépassé la latence de 1.3 ms à environ 139,883 1.2 IOPS avec le BM.Standard culminant à XNUMX XNUMX IOPS avec une latence de XNUMX ms et le BM.DenseIO culminant à XNUMX XNUMX IOPS et XNUMX ms de latence.

La connexion initiale avec NVMe a vu une performance maximale de 24,228 326 IOPS et 242,778 μs pour le VM.DenseIO et 234 XNUMX IOPS avec XNUMX μs pour le BM.DenseIO.

Enfin, avec VDI Linked Clone Monday Login avec BV, le VM.Standard avait des performances de latence inférieures à la milliseconde jusqu'à environ 27 39,874 IOPS avec un pic de 2.86 1 IOPS et une latence de 25 ms. VM.DenseIO a cassé 42,469 ms à environ 3 135 IOPS et a culminé à 146 1.6 IOPS et une latence de 1.76 ms. Les deux BM avaient une latence inférieure à la milliseconde jusqu'à environ XNUMX XNUMX IOPS, les deux culminant à XNUMX XNUMX IOPS, le denseIO ayant une latence de XNUMX ms et le standard ayant une latence de XNUMX ms.

Avec VDI Linked Clone Monday Login avec NVMe, le VM.DenseIO a culminé à 34,016 464 IOPS et une latence de 260,527 μs. BM.DenseIO a culminé à 317 XNUMX IOPS et une latence de XNUMX μs.

Conclusion

L'infrastructure cloud d'Oracle s'attaque à l'un des principaux problèmes du cloud, à savoir les performances ou leur absence, et le résout avec ses instances bare metal. Oracle propose des instances de calcul bare metal et virtuelles ainsi que des versions NVMe avec jusqu'à 25 To de stockage NVMe pour des performances sans précédent dans le cloud. Il faut plus que du stockage NVMe pour atteindre les performances annoncées par Oracle allant jusqu'à 5.1 millions d'IOPS ; les instances ont également jusqu'à 52 OCPU, 768 Go de RAM, deux cartes réseau 25 GbE et jusqu'à 51 To de stockage NVMe connecté localement. Ce niveau de performance est principalement utilisé pour les cas d'utilisation tels que les applications de base de données critiques, les charges de travail HPC et les applications Web intensives en E/S.

Du côté des performances, nous avons effectué nos tests VDBech pour les formes bare metal (BM) et VM en utilisant à la fois le stockage NVMe local (DenseIO) et le stockage en bloc réseau (Standard). La performance, tout simplement, nous a époustouflés. Pour chaque test, nous avons exécuté deux ensembles de graphiques, car l'écart de latence entre le DenseIO et le Standard était si important que les graphiques seraient difficiles à lire s'ils étaient tous sur un seul ensemble. En termes de performances de stockage sur ces instances par rapport au stockage traditionnel, elles rivalisent avec bon nombre des meilleures options de stockage partagé sur le marché, sans parler des alternatives cloud. Les BV connectés qui sont hébergés sur iSCSI et sauvegardés offrent une forte combinaison de débit et de bande passante servis à faible latence. Pour mettre cela en contexte, nous avons vu de nombreux tests avec 32 BV attachés sur les 52 instances OCPU dépasser les performances des baies de stockage 250 % Flash que nous avons testées dans notre laboratoire. Certains pourraient en fait avoir été légèrement plus rapides, ce qui est assez impressionnant étant donné que nous comparons une instance cloud à un AFA de XNUMX XNUMX $ +, une commutation FC et plusieurs hôtes de calcul.

Ce qui rend les instances Oracle Cloud bare metal vraiment incroyables, cependant, c'est le stockage NVMe connecté localement. Le DenseIO2.8 avait 1 appareil, tandis que le DenseIO2.52 en avait 8, donnant à ces instances des performances mesurées en millions d'IOPS. L'instance avec 1 SSD NVMe a vu la vitesse de lecture aléatoire 4K atteindre 569 8 IOPS, tandis que l'instance avec 4.4 a vu ses performances monter en flèche à 2.5 millions d'IOPS. La bande passante n'était pas une blague non plus; la plus petite instance a enregistré un pic de lecture de 20 Go/s, tandis que la plus grande a dépassé XNUMX Go/s. Assurez-vous d'avoir un plan de sauvegarde en place, car les formes NVMe sont après tout un stockage attaché localement, qui doit être protégé.

Oracle a construit des serveurs et un stockage de pointe dans le cloud ; la seule chose qui peut rivaliser avec leurs instances bare metal est de créer un serveur haut de gamme hébergé localement, ainsi que tous les autres composants et services pour le prendre en charge. Comme pour toutes les solutions cloud, Oracle offre la fluidité pour activer et désactiver vos instances et la flexibilité pour ajuster les besoins de stockage selon les besoins. Avec ces cas, le problème évident qui se posera est le coût. L'opportunité d'obtenir une instance en ligne dans Oracle Cloud par rapport aux efforts et aux dépenses nécessaires pour configurer un matériel comparable dans votre propre centre de données est peut-être le facteur décisif. Bien que le stockage attaché NVMe soit coûteux, les avantages en termes de performances que nous avons constatés ne font aucun doute. Si votre entreprise est affectée par le temps de traitement de grands ensembles de données, il n'existe pas de solution plus simple ou plus rapide pour obtenir des charges de travail telles que l'analyse complète que les formes basées sur NVMe que nous avons utilisées. Et ce n'est pas que les formes de bloc attachées standard étaient mauvaises, les formes NVMe étaient tellement irréelles qu'elles éclipsent le reste. L'essentiel est que les entreprises avant-gardistes qui peuvent tirer une valeur mesurable du cloud haute performance devraient certainement évaluer ce qu'Oracle a en cours. Il existe de nombreux choix pour passer au cloud, mais rien n'est aussi rapide que ce que nous avons vu avec les instances bare metal d'Oracle Cloud, ce qui fait de ces solutions un gagnant clair et méritant de notre premier Editor's Choice Award décerné à un service cloud. fournisseur.