Revisión de instancias de Oracle Cloud Infrastructure Compute Bare Metal

Oracle Cloud Infrastructure incluye una amplia variedad de ofertas de servicios que incluyen cómputo, almacenamiento, redes, base de datos y equilibrio de carga; en efecto, toda la infraestructura necesaria para construir un centro de datos basado en la nube. En el contexto de esta revisión, estamos interesados en la categoría Compute de Oracle Cloud Infrastructure, con un enfoque muy específico en sus instancias bare metal. Como la mayoría de los proveedores de la nube, Oracle ofrece instancias de cómputo virtualizadas, pero a diferencia de la mayoría de las otras ofertas virtuales, Oracle puede respaldarlas con formas que contienen hasta ~25 TB de almacenamiento NVMe para aplicaciones que necesitan baja latencia. Por excelentes que sean, Oracle ha subido aún más la apuesta por el rendimiento de la computación en la nube al ofrecer las primeras instancias bare metal de alto rendimiento de la industria, ideales para aplicaciones de misión crítica donde la latencia es primordial. Las instancias vienen con hasta 52 OCPU, 768 GB de RAM, NIC duales de 25 GbE y hasta 51 TB de almacenamiento NVMe conectado localmente. Para aquellos que desean más, hay disponibles hasta 512 TB de almacenamiento en bloque NVMe conectado a la red, así como opciones de GPU. Todas las diferentes ofertas informáticas de Oracle se ejecutan en una red definida por software altamente optimizada y ajustada para minimizar la contención y maximizar el rendimiento.

Oracle Cloud Infrastructure incluye una amplia variedad de ofertas de servicios que incluyen cómputo, almacenamiento, redes, base de datos y equilibrio de carga; en efecto, toda la infraestructura necesaria para construir un centro de datos basado en la nube. En el contexto de esta revisión, estamos interesados en la categoría Compute de Oracle Cloud Infrastructure, con un enfoque muy específico en sus instancias bare metal. Como la mayoría de los proveedores de la nube, Oracle ofrece instancias de cómputo virtualizadas, pero a diferencia de la mayoría de las otras ofertas virtuales, Oracle puede respaldarlas con formas que contienen hasta ~25 TB de almacenamiento NVMe para aplicaciones que necesitan baja latencia. Por excelentes que sean, Oracle ha subido aún más la apuesta por el rendimiento de la computación en la nube al ofrecer las primeras instancias bare-metal de alto rendimiento de la industria, ideales para aplicaciones de misión crítica donde la latencia es primordial. Las instancias vienen con hasta 52 OCPU, 768 GB de RAM, NIC duales de 25 GbE y hasta 51 TB de almacenamiento NVMe conectado localmente. Para aquellos que desean más, hay disponibles hasta 512 TB de almacenamiento en bloque NVMe conectado a la red, así como opciones de GPU. Todas las diferentes ofertas informáticas de Oracle se ejecutan en una red definida por software altamente optimizada y ajustada para minimizar la contención y maximizar el rendimiento.

Hay una amplia variedad de ofertas en la nube en este momento e incluso varias ofertas grandes en la nube con AWS, Google Cloud Platform y Microsoft Azure en la parte superior de esa lista. Si bien estos proveedores de servicios en la nube ofrecen muchos productos y servicios excelentes, una cosa que normalmente no tienen es el rendimiento. Cuando se compara la nube con el entorno local, el entorno local siempre supera a la nube sin lugar a dudas. Oracle está buscando cambiar esta visión con sus ofertas de infraestructura en la nube.

Las ofertas de cómputo de Oracle vienen con promesas que uno esperaría del almacenamiento o los servidores en las instalaciones, incluido el rendimiento, la disponibilidad, la versatilidad y la gobernanza. El lado del rendimiento admite un rendimiento máximo y constante para aplicaciones de misión crítica y está respaldado por el SLA de infraestructura en la nube de extremo a extremo recientemente anunciado, que a partir de este escrito es el único como este en la industria. La oferta admite la disponibilidad en varias capas, incluidos DNS, balanceo de carga, replicación, copia de seguridad, instantáneas de almacenamiento y agrupación en clústeres. Las ofertas de cómputo van desde una VM de un solo núcleo hasta bare metal de un solo arrendatario de 52 núcleos, lo que ofrece la versatilidad para ejecutar todo, desde cargas de trabajo comunes hasta clústeres de HPC. Y con las instancias bare metal de Oracle, los clientes obtienen el aislamiento y el control de un servidor local, ya que no contienen otros inquilinos ni software de proveedor de Oracle.

Las ofertas de cómputo de Oracle Cloud vienen en varias "formas", incluidas instancias bare metal, instancias de GPU bare metal e instancias de VM. Para esta revisión, analizaremos las instancias bare metal que, según Oracle, pueden ofrecer hasta 5.1 millones de IOPS y son para casos de uso como aplicaciones de bases de datos de misión crítica, cargas de trabajo de HPC y aplicaciones web intensivas de E/S. A modo de comparación, también mostraremos las formas de VM de Oracle, con almacenamiento NVMe local (DenseIO) y con almacenamiento en bloque de red (estándar).

Gestionamiento

La GUI de administración para Oracle Cloud Infrastructure es bastante simple de entender. La página principal tiene tutoriales y asistencia, si es necesario. En la parte superior se encuentran el arrendamiento o la cuenta, la región que se está usando (us-ashburn-1, en nuestro caso), junto con las pestañas de Inicio (que es la página principal), Identidad, Cómputo, Base de datos, Redes, Almacenamiento, Auditoría y correo electrónico. Para nuestras pruebas, se muestran DenseIO2 y Standard2.

Dado que esta revisión se enfoca en el lado de Computación, mirando debajo de esa pestaña podemos ver las instancias que usaremos para nuestras pruebas de rendimiento. Cada instancia tiene su nombre, forma, región, dominio de disponibilidad y cuándo se creó. En el lado izquierdo, los usuarios pueden cambiar la lista seleccionando el estado, por ejemplo, "en ejecución".

Al hacer clic en los puntos suspensivos en el lado derecho, se puede profundizar un poco más en una instancia. Mirando el BM.DenseIO2.52, uno puede ver fácilmente si la instancia se está ejecutando y obtener información más detallada al respecto. Aquí también se pueden asociar etiquetas. En la parte superior de la información se encuentra la capacidad de crear una imagen personalizada, iniciar, detener o reiniciar la instancia, finalizarla o aplicar etiquetas. Desplazarse hacia abajo le da a uno la capacidad de adjuntar volúmenes en bloque también.

En la pestaña Redes, se puede ver la red virtual en la nube que se está utilizando o crear una. Para la VCN, hay información como la región, la tabla de rutas predeterminada, el dominio DNS y cuándo se creó. Nuevamente, los puntos suspensivos a la derecha permiten profundizar, aplicar etiquetas y crear una subred.

En la pestaña Almacenamiento, los usuarios pueden ver los volúmenes en bloque en su compartimento y crear más. Los volúmenes en bloque se enumeran por fecha de creación y los usuarios pueden profundizar para obtener más información, crear copias de seguridad manuales, separar el volumen en bloque de la instancia, eliminar el volumen o aplicar etiquetas.

Y como implica Auditoría, uno puede mirar rápidamente eventos pasados seleccionando el rango de fecha y hora. Esto permite a las empresas satisfacer las necesidades de cumplimiento de la gestión donde se capturan el usuario y la acción para cada evento o cambio en el entorno.

Desempeno

Análisis de carga de trabajo de VDBench

Para evaluar el rendimiento de estas instancias de Oracle Cloud, aprovechamos vdbench instalado localmente en cada plataforma. Nuestras pruebas se distribuyeron en todo el almacenamiento local al mismo tiempo, por lo que si tanto el almacenamiento BV (Block Volume) como el NVMe estaban presentes, probamos un grupo a la vez. Con ambos tipos de almacenamiento, asignamos el 12 % de cada dispositivo y los agrupamos en conjunto para observar el rendimiento máximo del sistema con una cantidad moderada de localidad de datos.

Estas cargas de trabajo ofrecen una gama de diferentes perfiles de prueba que van desde pruebas de "cuatro esquinas", pruebas comunes de tamaño de transferencia de bases de datos, así como capturas de seguimiento de diferentes entornos VDI. Todas estas pruebas aprovechan el generador de cargas de trabajo vdBench común, con un motor de secuencias de comandos para automatizar y capturar resultados en un gran clúster de pruebas informáticas. Esto nos permite repetir las mismas cargas de trabajo en una amplia gama de dispositivos de almacenamiento, incluidos arreglos flash y dispositivos de almacenamiento individuales.

perfiles:

Lectura aleatoria 4K: 100 % de lectura, 128 subprocesos, 0-120 % de iorate
Escritura aleatoria 4K: 100 % de escritura, 64 subprocesos, 0-120 % de iorate
Lectura secuencial de 64 K: 100 % de lectura, 16 subprocesos, 0-120 % de iorate
Escritura secuencial de 64 K: 100 % de escritura, 8 subprocesos, 0-120 % de iorate
Base de datos sintética: SQL y Oracle
Trazas de clones vinculados y clones completos de VDI

Analizamos los dispositivos de bloqueo remoto (BV) y NVMe. Dado que existe una diferencia de rendimiento tan drástica, hemos separado los resultados en dos gráficos (la latencia estaría tan separada que los gráficos serían muy difíciles de leer). Para esta revisión, analizamos las configuraciones Bare Metal (BM) y VM con ejecuciones de E/S estándar y densas en BV y solo ejecuciones de E/S densas para NVMe.

En cuanto a la lectura máxima de 4K para BV, las cuatro ejecuciones comenzaron con una fuerte latencia de submilisegundos. El primero en despegarse fue el VM.Standard, con un poco menos de 53 60,591 IOPS y luego alcanzó un máximo de 15 1 IOPS con una latencia de 72,626 ms. El siguiente en romper la latencia de submilisegundos fue VM.DenseIO, superando 7.5 ms en aproximadamente el mismo lugar que el estándar, pero alcanzando un máximo de 235 252,275 IOPS con una latencia de 4.1 ms. Ambas ejecuciones bare metal funcionaron mucho mejor con DenseIO ejecutando un rendimiento de latencia de menos de un milisegundo hasta aproximadamente 250 1 IOPS, alcanzando un máximo de 258,329 4.05 IOPS con una latencia de XNUMX ms. El BM.Standard alcanzó aproximadamente XNUMX XNUMX IOPS antes de superar XNUMX ms y alcanzó un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms.

En cuanto al rendimiento máximo de lectura de 4K para NVMe, ambas ejecuciones tuvieron una latencia inferior al milisegundo en todo momento. El VM.DenseIO alcanzó un máximo de 569,534 214 IOPS con una latencia de 4,419,490 μs. El BM.DenseIO alcanzó un máximo de 174.6 XNUMX XNUMX IOPS con una latencia de solo XNUMX μs.

Al cambiar al rendimiento máximo de escritura 4K aleatorio para BV, vemos una ubicación similar a la anterior con las VM alcanzando su punto máximo mucho antes que las BM. El VM.Standard llegó a alrededor de 63 77,229 IOPS antes de romper la latencia de submilisegundos y alcanzó un máximo de 5.3 69 IOPS con una latencia de 1 ms. El VM.DenseIO se desempeñó un poco mejor alcanzando alrededor de 84,274 3.9 IOPS antes de pasar de 263 ms y alcanzó un máximo de 1 280,158 IOPS con una latencia de 2.02 ms. El BM.DenseIO pudo llegar al norte de 278 280,844 IOPS antes de superar los 1.84 ms de latencia y alcanzó un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms. Y BM.Standard fue la configuración de mayor rendimiento con aproximadamente XNUMX XNUMX IOPS antes de superar la latencia de submilisegundos y alcanzó un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms.

Con NVMe en escritura 4K, nuevamente el BM superó a la VM y ambos tuvieron un rendimiento de latencia inferior al milisegundo en todo momento. El VM.DenseIO alcanzó un máximo de 412,207 141 IOPS con una latencia de 3,232,215 μs. El BM.DenseIO alcanzó un máximo de 125 XNUMX XNUMX IOPS con una latencia de XNUMX μs.

Pasando al trabajo secuencial, primero observamos la lectura de 64K para BV. Tanto el VM.Standard como el VM.DenseIO superaron la latencia de 1 ms a aproximadamente 15.5 K IOPS o 968 MB/s. Y ambos mantuvieron más o menos el mismo rendimiento ya que la latencia subió a 8.2ms. Nuevamente, vimos algo similar con BM.Standard y BM.DenseIO, ambos rompiendo 1ms a aproximadamente 37.5K IOPS o 2.35GB/s. Ambas configuraciones alcanzaron su punto máximo justo al norte de 47 2.95 IOPS o 8.4 GB/s con una latencia de XNUMX ms.

La lectura secuencial de 64K de NVMe hizo que ambas configuraciones se mantuvieran por debajo de la latencia de submilisegundos en todo momento. El VM.DenseIO alcanzó un máximo de 39,512 2.5 IOPS o 403 GB/s con una latencia de 323,879 μs, mientras que el BM.DenseIO alcanzó un máximo de 20.2 361 IOPS o XNUMX GB/s con una latencia de XNUMX μs.

Con escrituras secuenciales de 64 1 para BV, nuevamente vemos un fenómeno similar con VM.Standard y VM.DenseIO, ambos rompiendo la latencia de 12 ms con un rendimiento de 770 15.1 IOPS o 943 MB/s. Ambos alcanzaron un máximo de alrededor de 3.1 K IOPS o 1 MB/s con una latencia de 42 ms. Con BM.Standard y BM.DenseIO ambos rompieron la latencia de 2.6 ms a aproximadamente 46,768 2.92 IOPS o 2.6 GB/s con el BM.DenseIO alcanzando un máximo de 46,787 2.92 IOPS o 3.4 GB/s con una latencia de XNUMX ms. El BM.Standard alcanzó un máximo de XNUMX XNUMX IOPS o XNUMX GB/s con una latencia de XNUMX ms.

Para escrituras secuenciales de 64 25 para NVMe, tanto VM.DenseIO como BM.DenseIO tuvieron un rendimiento de latencia inferior al milisegundo nuevamente, pero ambos también sufrieron un aumento en la latencia (junto con una reducción final en el rendimiento de BM.DenseIO). El VM.DenseIO alcanzó un máximo de 1.56K IOPS o 311 GB/s con una latencia de 754 μs después de un pico de hasta 160,895 μs. El BM.DenseIO tuvo un rendimiento máximo mucho mejor (10.1 170 IOPS o 132,192 GB/s con una latencia de 8.8 μs), pero disminuyó un poco al final con un aumento en la latencia también, terminando en 310 XNUMX IOPS o XNUMX GB/s con una latencia de XNUMXμs.

En nuestra carga de trabajo de SQL para BV, VM.Standard fue el primero en superar 1 ms con aproximadamente 50 73,259 IOPS y alcanzó un máximo de 3.4 1 IOPS con una latencia de 58 ms. VM.DenseIO superó la latencia de 78,624 ms con alrededor de 3.1 1 IOPS y alcanzó un máximo de 275 305,368 IOPS con una latencia de 1.7 ms. Con los BM, ambos se mantuvieron por debajo de 307,979 ms de latencia hasta alrededor de 1.35 K (con el BM.DenseIO ejecutándose un poco más). El BM.Standard alcanzó un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms, mientras que el BM.DenseIO alcanzó un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms.

SQL para NVMe nuevamente tuvo una latencia de menos de un milisegundo en todo momento con el VM.DenseIO alcanzando un máximo de 188,786 IOPS con 167 μs. El BM.DenseIO alcanzó un máximo de 1,684,869 142 XNUMX IOPS con una latencia de XNUMX μs.

En el punto de referencia de SQL 90-10 para BV, ambas máquinas virtuales rompieron el rendimiento de latencia de submilisegundos en alrededor de 58 71,691 IOPS. El VM.Standard alcanzó un máximo de 3.5 79,033 IOPS con una latencia de 3.05 ms. El VM.DenseIO alcanzó un máximo de 1 270 IOPS con una latencia de 303,904 ms. El BM.Standard superó la latencia de 1.7 ms con un rendimiento de aproximadamente 290 307,472 IOPS y alcanzó un máximo de 1.34 XNUMX IOPS con una latencia de XNUMX ms. El BM.DenseIO tuvo una latencia de submilisegundos hasta alrededor de XNUMX XNUMX IOPS y alcanzó un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms.

Para NVMe SQL 90-10, VM.DenseIO alcanzó un máximo de 172,693 182 IOPS con una latencia de 1,328,437 μs. El BM.DenseIO alcanzó un máximo de 165 XNUMX XNUMX IOPS con XNUMX μs.

En el punto de referencia de SQL 80-20 para BV, VM.Standard llegó a alrededor de 54 1 IOPS antes de superar 72,204 ms y alcanzó un máximo de 3.4 59 IOPS con una latencia de 78,787 ms. El VM.DenseIO tuvo una latencia de submilisegundos hasta alrededor de 2.99 280 IOPS y alcanzó un máximo de 1 300,014 IOPS con una latencia de 1.6 ms. El BM.Standard alcanzó aproximadamente 1 285 IOPS con una latencia inferior a 299,730 ms y alcanzó un máximo de 1.3 XNUMX IOPS con una latencia de XNUMX ms. El BM.DenseIO superó la latencia de XNUMX ms con aproximadamente XNUMX XNUMX IOPS y alcanzó un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms antes de caer en el rendimiento.

En el punto de referencia de SQL 80-20 para NVMe, VM.DenseIO alcanzó un máximo de 144,010 218 IOPS con una latencia de 1,114,056 μs. El BM.DenseIO alcanzó su punto máximo en 182 IOPS con una latencia de XNUMX μs antes de tener una ligera caída en el rendimiento.

En nuestra carga de trabajo de Oracle con BV, VM.Standard tuvo un rendimiento de latencia inferior al milisegundo hasta que alcanzó aproximadamente 52 70,096 IOPS y alcanzó un máximo de 3.4 1 IOPS con una latencia de 58 ms. El VM.DenseIO superó la latencia de 75,000 ms con aproximadamente 3.1 1 IOPS y alcanzó un máximo de 255 280,599 IOPS con una latencia de 1.41 ms. BM.Standard rompió la latencia de 260 ms alrededor de 267,632 K con un rendimiento máximo de 1.3 XNUMX IOPS con una latencia de XNUMX ms. BM.DenseIO tuvo una latencia de submilisegundos hasta alrededor de XNUMX XNUMX IOPS y alcanzó un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms.

Nuestra carga de trabajo de Oracle con NVMe mostró un rendimiento máximo para VM.DenseIO de 132,553 257 IOPS con una latencia de 1,043,104 μs. Con BM.DenseIO, el rendimiento máximo fue de 199 XNUMX XNUMX IOPS y una latencia de XNUMX μs.

En Oracle 90-10 para BV, VM.Standard tenía una latencia de submilisegundos hasta poco más de 54 72,533 IOPS y alcanzó un máximo de 2.2 1 IOPS con una latencia de 61 ms. El VM.DenseIO superó la latencia de 76,908 ms con aproximadamente 1.86 297 IOPS y alcanzó un máximo de 1 305,771 IOPS con una latencia de 1.17 ms. Ambos BM llegaron a 297,509 1.03 IOPS antes de romper la latencia de XNUMX ms. El BM.Standard alcanzó un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms. BM.DenseIO tuvo un rendimiento máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms.

En Oracle 90-10 para NVMe, VM.DenseIO tuvo un rendimiento máximo de 133,330 163 IOPS y una latencia de 1,088,454 μs. El BM.DenseIO tuvo un rendimiento máximo de 142 XNUMX XNUMX IOPS y una latencia de XNUMX μs.

En Oracle 80-20 con BV, VM.Standard llegó a unos 55 1 en menos de 74,032 ms y alcanzó un máximo de 2.14 51 IOPS con una latencia de 75,666 ms. El VM.DenseIO tuvo una latencia de submilisegundos hasta alrededor de 2 K y alcanzó un máximo de 295 1 IOPS con una latencia de 306,955 ms. Ambos BM alcanzaron alrededor de 1.14 295 IOPS antes de romper 893 ms. El BM.Standard alcanzó un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms. El BM.DenseIO alcanzó un máximo de aproximadamente XNUMX XNUMX IOPS con una latencia de XNUMX μs.

En Oracle 80-20 con NVMe, VM.DenseIO alcanzó un máximo de 108,483 195 IOPS con una latencia de 956,326 μs. El BM.DenseIO alcanzó un máximo de 158 XNUMX IOPS con una latencia de XNUMX μs.

A continuación, analizamos VDI Full Clone. Para el arranque con BV, VM.Standard superó 1 ms justo por debajo de 40 56,057 IOPS y alcanzó un máximo de 4.2 43 IOPS con una latencia de 61,570 ms. VM.DenseIO lo logró con una latencia de submilisegundos hasta aproximadamente 3.6 200 IOPS y alcanzó un máximo de 220 2.1 IOPS con una latencia de XNUMX ms. Ambos BM tenían una latencia de menos de un milisegundo hasta poco más del umbral de XNUMX XNUMX IOPS. Ambos alcanzaron un máximo de aproximadamente XNUMX XNUMX IOPS con una latencia de XNUMX antes de caer en el rendimiento.

Para el arranque de Full Clone con NVMe, VM.DenseIO alcanzó un máximo de aproximadamente 136 235 IOPS con una latencia de 1,032,322 μs. El BM.DenseIO alcanzó un máximo de 213 XNUMX XNUMX IOPS con una latencia de XNUMX μs.

Con el inicio de sesión inicial de VDI Full Clone con BV, ambas máquinas virtuales lograron aproximadamente 41 55,522 IOPS con una latencia de menos de un milisegundo, con VM.Standard alcanzando un máximo de 3.7 59,560 IOPS con una latencia de 3.6 ms y VMDenseIO alcanzando un máximo de 203 225 IOPS con una latencia de 2.04 ms . Ambos BM rompieron la latencia de submilisegundos alrededor de 224,385K IOPS (con el estándar yendo antes que el denso). BM.Standard alcanzó un máximo de aproximadamente 1.8 XNUMX IOPS con una latencia de XNUMX ms y BM.DenseIO alcanzó un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms.

Para el inicio de sesión inicial de VDI Full Clone con NVMe, VM.Standard alcanzó un máximo de 59,883 506 IOPS con una latencia de 467,761 μs. Y el BM.DenseIO alcanzó un máximo de 262 XNUMX IOPS con una latencia de XNUMX μs.

VDI Full Clone Monday Login con BV tenía el VM.Standard con una latencia de submilisegundos hasta casi 36 50,685 IOPS con un pico de 2.3 1 IOPS y una latencia de 38 ms. VM.DenseIO funcionó por debajo de 53,304 ms hasta justo al norte de 2.2 1 IOPS y alcanzó un máximo de 205 224,764 IOPS con una latencia de 1.5 ms. BM.Standard superó la latencia de 1 ms con aproximadamente 210 220 IOPS y alcanzó un máximo de 1.2 XNUMX IOPS con una latencia de XNUMX ms. BM.DenseIO superó XNUMX ms alrededor de XNUMX XNUMX con un pico de poco más de XNUMX XNUMX IOPS y una latencia de XNUMX ms.

VDI Full Clone Monday Login con NVMe mostró un rendimiento máximo de VM.DenseIO de 44,384 356 IOPS con una latencia de 356,691 μs. BM.DenseIO alcanzó un máximo de 252 XNUMX IOPS con una latencia de XNUMX μs.

Nuestra selección final de pruebas analiza VDI Linked Clone. Comenzando nuevamente con la prueba de arranque con BV, VM.Standard tuvo una latencia de menos de un milisegundo hasta alrededor de 29 38 IOPS, alcanzando un máximo de alrededor de 2.4 32 IOPS con una latencia de 1 ms. VM.DenseIO llegó hasta aproximadamente 38 2.16 IOPS antes de romper 100 ms y también alcanzó un máximo de aproximadamente 1 114 IOPS con una latencia de 3 ms. Ambos BM lograron aproximadamente XNUMX XNUMX IOPS antes de superar la latencia de XNUMX ms. Ambos tuvieron un rendimiento máximo de alrededor de XNUMX XNUMX IOPS con una latencia de XNUMX ms.

Con VDI Linked Clone Boot para NVMe, vimos el pico de VM.DenseIO en 65,384 238 IOPS con una latencia de 555,004 μs. El BM.DenseIO alcanzó un máximo de 217 XNUMX IOPS con una latencia de XNUMX μs.

Con el inicio de sesión inicial con BV, ambas máquinas virtuales superaron la latencia de 1 ms con aproximadamente 28 36,682 IOPS, con VM.Standard alcanzando un máximo de 1.6 38,525 IOPS con una latencia de 1.6 ms y VM.DenseIO alcanzando un máximo de 1 132 IOPS con una latencia de 140,848 ms. Ambos BM rompieron la latencia de 1.3 ms con alrededor de 139,883 1.2 IOPS, con el BM.Standard alcanzando un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms y el BM.DenseIO alcanzando un máximo de XNUMX XNUMX IOPS y una latencia de XNUMX ms.

El inicio de sesión inicial con NVMe vio un rendimiento máximo de 24,228 326 IOPS y 242,778 μs para VM.DenseIO y 234 XNUMX IOPS con XNUMX μs para BM.DenseIO.

Finalmente, con VDI Linked Clone Monday Login con BV, VM.Standard tuvo un rendimiento de latencia inferior al milisegundo hasta aproximadamente 27 39,874 IOPS con un pico de 2.86 1 IOPS y una latencia de 25 ms. VM.DenseIO rompió 42,469 ms con alrededor de 3 135 IOPS y alcanzó un máximo de 146 1.6 IOPS y una latencia de 1.76 ms. Ambos BM tenían una latencia de menos de un milisegundo hasta alrededor de XNUMX XNUMX IOPS y ambos alcanzaron un máximo de XNUMX XNUMX IOPS, el denseIO con una latencia de XNUMX ms y el estándar con una latencia de XNUMX ms.

Con VDI Linked Clone Monday Login con NVMe, VM.DenseIO alcanzó un máximo de 34,016 464 IOPS y una latencia de 260,527 μs. BM.DenseIO alcanzó un máximo de 317 XNUMX IOPS y una latencia de XNUMX μs.

Conclusión

La infraestructura en la nube de Oracle toma uno de los principales problemas con la nube, el rendimiento o la falta de este, y lo aborda con sus instancias bare metal. Oracle ofrece instancias informáticas virtuales y bare metal, así como versiones NVMe con hasta 25 TB de almacenamiento NVMe para un rendimiento sin igual en la nube. Se necesita más que almacenamiento NVMe para alcanzar el rendimiento cotizado de Oracle de hasta 5.1 millones de IOPS; las instancias también tienen hasta 52 OCPU, 768 GB de RAM, NIC duales de 25 GbE y hasta 51 TB de almacenamiento NVMe conectado localmente. Este nivel de rendimiento se usa principalmente para casos de uso como aplicaciones de bases de datos de misión crítica, cargas de trabajo de HPC y aplicaciones web intensivas de E/S.

Por el lado del rendimiento, ejecutamos nuestras pruebas VDBech para las formas bare metal (BM) y VM utilizando tanto el almacenamiento NVMe local (DenseIO) como el almacenamiento en bloque de red (estándar). La actuación, en pocas palabras, nos dejó boquiabiertos. Para cada prueba, ejecutamos dos conjuntos de gráficos, ya que la discrepancia de latencia entre DenseIO y Standard era tan grande que los gráficos serían difíciles de leer si todos estuvieran en un solo conjunto. En términos de cómo se compara el buen rendimiento del almacenamiento en estas instancias con el almacenamiento tradicional, compiten con muchas de las mejores opciones de almacenamiento compartido del mercado, por no hablar de las alternativas en la nube. Los BV adjuntos que están alojados en iSCSI y respaldados ofrecen una sólida combinación de rendimiento y ancho de banda con baja latencia. Para poner esto en contexto, vimos muchas pruebas con 32 BV adjuntos en las 52 instancias de OCPU que superaron el rendimiento de los arreglos de almacenamiento all-flash que probamos en nuestro laboratorio. Algunos podrían haber sido un poco más rápidos, lo cual es bastante impresionante considerando que estamos comparando una instancia en la nube con un AFA de $250k+, conmutación FC y múltiples hosts de cómputo.

Sin embargo, lo que hace que las instancias bare metal de Oracle Cloud sean realmente increíbles es el almacenamiento NVMe conectado localmente. El DenseIO2.8 tenía 1 dispositivo, mientras que el DenseIO2.52 tenía 8, dando a estas instancias un rendimiento medido en millones de IOPS. La instancia con 1 NVMe SSD vio un máximo de velocidad de lectura aleatoria de 4K a 569k IOPS, mientras que la instancia con 8 tuvo un rendimiento que se disparó a 4.4 millones de IOPS. El ancho de banda tampoco era una broma; la instancia más pequeña vio un pico de lectura de 2.5 GB/s, mientras que la más grande superó los 20 GB/s. Asegúrese de tener un plan de copias de seguridad implementado, ya que, después de todo, las formas de NVMe son almacenamiento conectado localmente y deben protegerse.

Oracle ha construido servidores y almacenamiento de alta especificación en la nube; lo único que puede rivalizar con sus instancias bare metal es construir un servidor de alta especificación alojado localmente, junto con todos los demás componentes y servicios para admitirlo. Al igual que con todas las soluciones en la nube, Oracle ofrece la fluidez para encender y apagar sus instancias y la flexibilidad para ajustar los requisitos de almacenamiento según sea necesario. Con estos casos, el problema obvio que surgirá es el costo. La conveniencia de obtener una instancia en línea dentro de Oracle Cloud frente al esfuerzo y los gastos necesarios para configurar un hardware comparable en su propio centro de datos es quizás el factor decisivo clave. Si bien el almacenamiento adjunto de NVMe es costoso, no se discuten los beneficios de rendimiento que vimos. Si tiene una empresa que se ve afectada por el tiempo de procesamiento de grandes conjuntos de datos, no existe una solución más fácil o más rápida para completar cargas de trabajo como análisis que las formas basadas en NVMe que usamos. Y no es que las formas estándar de los bloques adjuntos fueran malas, las formas NVMe eran tan irreales que eclipsaban al resto. La conclusión es que las empresas con visión de futuro que pueden obtener un valor medible de la nube de alto rendimiento definitivamente deberían evaluar lo que Oracle está haciendo. Hay muchas opciones cuando se va a la nube, pero no hay nada que sea tan rápido como lo que hemos visto con las instancias bare metal de Oracle Cloud, lo que convierte a estas soluciones en un claro y merecido ganador de nuestro primer premio Editor's Choice otorgado a servicios en la nube. proveedor.