Revisión de VMware vSAN de Western Digital Ultrastar DC SN630

Western Digital lanzó el Ultrastar DC SN630 en febrero de este año, como parte de una renovación y cambio de marca de su línea Ultrastar (anteriormente HGST) de unidades para centros de datos. Dentro de este portafolio, Western Digital ofrece varias unidades SSD NVMe empresariales, con el SN200 como líder en rendimiento y el nuevo SN630 reemplazando al SN620 en el segmento NVMe de un solo puerto, una alternativa cada vez más popular a las unidades SSD SATA y SAS. El SN630, la unidad SSD NVMe de referencia de Western Digital, está optimizado para cargas de trabajo centradas en lectura o para cargas de trabajo mixtas de alta resistencia. La construcción de la unidad es la misma en ambos casos; la diferencia funcional radica en el nivel de sobreaprovisionamiento, que a su vez produce la resistencia deseada.

Desde una perspectiva de diseño de SSD, el Ultrastar SN630 utiliza el controlador interno de Western Digital y la compilación de firmware y la NAND 64D BiCS3 de 3 capas de Western Digital. Desde una perspectiva de ingeniería, una solución integrada verticalmente como esta se está convirtiendo en el estándar para los SSD empresariales de primera clase. Si bien es posible usar NAND, controladores y firmware de diferentes fuentes, tendemos a ver soluciones más confiables y de mejor rendimiento de proveedores que pueden hacer todo el trabajo por su cuenta. La unidad en sí utiliza un factor de forma U.7 de 2.5 mm y 2″ y, al igual que otras ofertas de SSD de Western Digital, la SN630 ofrece algoritmos patentados de nivelación de desgaste y protección contra pérdida de energía.

Como se señaló, el SN630 viene en SKU de uso mixto y lectura intensiva. El primero se envía en capacidades de 6.40 TB, 3.20 TB, 1.60 TB y 800 GB, mientras que el segundo viene en capacidades de 7.68 TB, 3.84 TB, 1.92 TB y 960 GB. Todas las unidades ofrecen Instant Secure Erase (ISE), que utiliza claves de cifrado en segundo plano para gestionar la redistribución y el retiro de la unidad. Western Digital también ofrece descargas seguras de firmware con autenticación RSA para garantizar que el SN630 solo ejecute firmware auténtico. Por último, las unidades están respaldadas por una garantía limitada de 5 años.

En esta revisión, examinamos el rendimiento del SN630 en el contexto de VMware vSAN. La configuración de revisión utiliza un chasis de 2029 nodos Supermicro SuperServer BigTwin 4BT-HNR, 24 SSD Ultrastar DC SN630 NVMe y VMware vSAN 6.7 Update 1 para profundizar en el rendimiento del SN630 con una perspectiva más amplia del sistema.

Especificaciones de Western Digital Ultrastar DC SN630

Modelo	VRI/RI
CAPACIDAD	960GB / 800GB	1,920GB / 1,600GB	3,840GB / 3,200GB	7,680GB / 6,400GB
Factor de forma	Unidad U.2 de 2.5 pulgadas
Fácil de usar	PCIe Gen 3.1 x4 (compatible con NVMe 1.3)
Tecnología de memoria flash	Western Digital BiCS3 3D TLC NAND
Rendimiento
Lectura secuencial, (máx. MiB/s)	2,690/2,690	2,660/2,670	2,510/2,500	2,520/2,540
Escritura secuencial, (máx. MiB/s)	930/960	1,230/1,240	1,180/1,200	1,240/1,240
Lectura aleatoria (IOPS máx.)	278,760/281,790	358,220/356,870	332,420/332,510	360,280/306,520
Escritura aleatoria (IOPS máx.)	43,580/86,740	53,850/86,870	55,000/88,140	54,220/88,210
Mezcla aleatoria R70/W30 (IOPS máx.)	107,350/188,480	170,390/253,390	163,350/238,500	170,250/273,960
Latencia de lectura aleatoria (μs)	179/179	190/188	243/239	243/239
Confiabilidad
DWPD	0.8/2
UBER	1 en 10 ^ 17
Retención de datos de EOL	5° C a 40° C por un período máximo de 90 días
MTBF	2 millón de horas
AFR	0.44%
Potencia
Requisito (CC +/- 10%)	12V
Estados de potencia de funcionamiento (W, típico)	10.75 y 8.75
Inactivo (W, promedio)	5.80	5.80	5.90	6.10
Responsabilidad
Temperatura de Funcionamiento	0 ° C a 78 ° C
Temperatura media	-40° C a 70° C por 1 año
Física
Ancho (mm)	69.85 +/- 0.25
Longitud (mm, máx.)	100.45
Peso (g, máx.)	95
altura z (mm)	7.00 +0.2/-0.5 (incluidas las etiquetas)
Garantía	5 años limitada

Western Digital Ultrastar DC SN630 VMware vSAN Diseño y construcción

Western Digital Ultrastar DC SN630 es una unidad NVMe de 2.5” destinada al centro de datos. La unidad varía en capacidad de 800 GB a 7.68 TB. El SN630 está revestido de metal negro con una etiqueta adhesiva en la parte superior que contiene información como el nombre, la marca, la capacidad, el número de modelo y las certificaciones.

La parte frontal del chasis Supermicro SuperServer BigTwin tiene 24 bahías para unidades NVMe de 2.5″, con 6 asignadas por nodo. Cada nodo ofrece su propio botón LED de localización, así como un botón de encendido discreto.

La parte trasera de BigTwin muestra las cuatro bandejas de nodos de cómputo. Cada uno viene estándar con un puerto IPMI para administración fuera de banda, VGA, dos puertos USB 3 y una NIC configurable por el usuario. Con nuestra configuración, usamos una NIC de cuatro puertos, con dos puertos 10GBase-T y dos puertos SPF28 25G. Nuestra configuración de prueba aprovechó las conexiones 25G para el clúster de vSAN. Todos los nodos comparten una plataforma de alimentación de doble PSU común como parte del diseño del chasis.

Configuración de revisión de VMware vSAN de Western Digital Ultrastar DC SN630

Para probar los 24 SSD SN630 en un entorno vSAN, utilizamos un sistema de cuatro nodos Supermicro SuperServer BigTwin 2029BT-HNR. La configuración por nodo es la siguiente:

• 2 CPU Intel Gold 6150 (2.7 GHz, 18 núcleos)
• 12 memorias RAM ECC DDR32 de 2666 GB a 4 MHz
• 2 SSD Western Digital Ultrastar DC SN800 NVMe de 630 GB para vSAN Cache
• 4 SSD Western Digital Ultrastar DC SN1.92 NVMe de 630 TB para capacidad vSAN
• 1 SSD Western Digital Blue SATA de 500 GB para unidad de arranque
• Puerto dual 25Gb Mellanox ConnectX-4 NIC
• VMware ESXi 6.7u1 (10302608)

Aprovechamos una construcción de servidor bastante modesta para nuestras pruebas de VMware vSAN en torno a Western Digital Ultrastar DC SN630. Los servidores utilizaron CPU Intel Gold 6150 de rango medio superior, con una velocidad de reloj de 2.7 GHz y un número de núcleos de 18. Por servidor, eso nos brinda 97.2 GHz de potencia de cómputo, o 388.8 GHz a nivel de clúster. También usamos 384 GB de RAM por nodo, lo que nos brinda suficiente memoria para nuestras cargas de trabajo sintéticas y de aplicaciones.

En nuestra configuración de prueba, usamos un diseño de dos grupos de discos por nodo, cada uno con un SSD NVMe SN800 de 630 GB para caché y dos SSD NVMe SN1.92 de 630 TB para capacidad. La capacidad utilizable se reduce a cómo se aprovisionan las máquinas virtuales en el clúster, así como al nivel de duplicación que utiliza. El almacenamiento sin procesar mide 27.95 TB en nuestro clúster, pero con la política predeterminada de VM de duplicación bidireccional con sobrecarga de vSAN, nos quedan 13.79 TB de capacidad utilizable. Sin embargo, la reducción de datos lo amplía drásticamente para ciertos tipos de cargas de trabajo.

Si bien las cargas de trabajo de nuestras aplicaciones se centrarán en el rendimiento del clúster con la reducción de datos desactivada, incluiremos puntos de referencia sintéticos que muestren el rendimiento del clúster con y sin la reducción de datos habilitada. Si bien la reducción de datos tendrá un componente de sobrecarga de rendimiento asociado, aumentará drásticamente la capacidad utilizable del clúster de vSAN en ciertas implementaciones.

Revisión de rendimiento de VMware vSAN de Western Digital Ultrastar DC SN630

Rendimiento de SQL Server

El protocolo de prueba OLTP de Microsoft SQL Server de StorageReview emplea el borrador actual del Benchmark C (TPC-C) del Transaction Processing Performance Council, un benchmark de procesamiento de transacciones en línea que simula las actividades que se encuentran en entornos de aplicaciones complejos. El punto de referencia TPC-C se acerca más que los puntos de referencia de rendimiento sintéticos para medir las fortalezas de rendimiento y los cuellos de botella de la infraestructura de almacenamiento en entornos de bases de datos.

Cada máquina virtual con SQL Server está configurada con dos discos virtuales: un volumen de 100 GB para el arranque y un volumen de 500 GB para la base de datos y los archivos de registro. Desde la perspectiva de los recursos del sistema, configuramos cada VM con 16 vCPU, 64 GB de DRAM y aprovechamos el controlador LSI Logic SAS SCSI. Si bien nuestras cargas de trabajo de Sysbench probadas anteriormente saturaron la plataforma tanto en E/S de almacenamiento como en capacidad, la prueba de SQL busca el rendimiento de la latencia.

Esta prueba utiliza SQL Server 2014 ejecutándose en máquinas virtuales invitadas de Windows Server 2012 R2 y está destacada por Dell's Benchmark Factory for Databases. Si bien nuestro uso tradicional de este punto de referencia ha sido probar grandes bases de datos de escala 3,000 en almacenamiento local o compartido, en esta iteración nos enfocamos en distribuir cuatro bases de datos de escala 1,500 de manera uniforme en nuestros servidores.

Configuración de prueba de SQL Server (por VM)

• Windows Server 2012 R2
• Huella de almacenamiento: 600 GB asignados, 500 GB utilizados
• SQL Server 2014
  • Tamaño de la base de datos: escala 1,500
  • Carga de clientes virtuales: 15,000
  • Búfer RAM: 48GB
• Duración de la prueba: 3 horas
  • 2.5 horas de preacondicionamiento
  • Período de muestra de 30 minutos

Para nuestro punto de referencia transaccional de SQL Server, Western Digital Ultrastar DC SN630 VMware vSAN en Supermicro BigTwin pudo alcanzar una puntuación total de 12,610.3 3,152.01 TPS con máquinas virtuales individuales que se ejecutan de 3,153.2 TPS a XNUMX TPS.

Con SQL Server, vimos una puntuación total de 14.75 ms con máquinas virtuales individuales que oscilaban entre 14 y 15 ms.

Rendimiento Sysbench MySQL

Nuestro primer punto de referencia de la aplicación de almacenamiento local consiste en una base de datos OLTP MySQL de Percona medida a través de SysBench. Esta prueba mide el promedio de TPS (transacciones por segundo), la latencia promedio y también la latencia promedio del percentil 99.

Cada máquina virtual de Sysbench está configurada con tres discos virtuales: uno para arranque (~92 GB), uno con la base de datos preconstruida (~447 GB) y el tercero para la base de datos bajo prueba (270 GB). Desde la perspectiva de los recursos del sistema, configuramos cada VM con 16 vCPU, 60 GB de DRAM y aprovechamos el controlador LSI Logic SAS SCSI.

Configuración de prueba de Sysbench (por VM)

• CentOS 6.3 de 64 bits
• Percona XtraDB 5.5.30-rel30.1
  • Tablas de base de datos: 100
  • Tamaño de la base de datos: 10,000,000
  • Subprocesos de la base de datos: 32
  • Búfer RAM: 24GB
• Duración de la prueba: 3 horas
  • 2 horas preacondicionamiento 32 hilos
  • 1 hora 32 hilos

Con Sysbench OLTP probamos 8VM y obtuvimos una puntuación total de 11,739.7 1,326 TPS con máquinas virtuales individuales que van desde 1,552.3 TPS hasta XNUMX TPS.

Con la latencia de Sysbench, el servidor tenía una media de 21.86 ms.

En nuestro peor de los casos (percentil 99), la latencia de las unidades Western Digital nos dio 38.71 ms.

Análisis de carga de trabajo de VDBench

Cuando se trata de comparar matrices de almacenamiento, las pruebas de aplicaciones son las mejores y las pruebas sintéticas ocupan el segundo lugar. Si bien no es una representación perfecta de las cargas de trabajo reales, las pruebas sintéticas ayudan a los dispositivos de almacenamiento de referencia con un factor de repetibilidad que facilita la comparación de manzanas con manzanas entre las soluciones de la competencia. 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

En todas nuestras pruebas de VDBench, probamos las unidades Western Digital con DR activado y desactivado. Con una lectura aleatoria de 4K, ambas configuraciones comenzaron por debajo de 1 ms con la versión DR apareciendo y alcanzando un máximo de 387,937 7.5 IOPS con una latencia de 1 ms. Con la DR desactivada, las unidades se mantuvieron por debajo de 350 ms hasta justo al norte de 442,089 4.8 IOPS y alcanzaron un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms.

Para 4K, escriba nuevamente, ambas configuraciones comenzaron justo por debajo de 1 ms. La versión DR tenía una latencia de menos de un milisegundo hasta aproximadamente 90 182,791 IOPS y alcanzó un máximo de 7.4 1 IOPS con una latencia de 110 ms. Con DR desactivado, vimos que las unidades permanecían por debajo de 196,027 ms hasta aproximadamente 7 XNUMX IOPS y alcanzaban un máximo de XNUMX XNUMX IOPS con una latencia de aproximadamente XNUMX ms antes de dejar algunas.

El siguiente paso son nuestras cargas de trabajo secuenciales. En la lectura de 64K, la versión DR comenzó por encima de 1 ms y alcanzó un máximo de 132,918 8.3 IOPS o 3.7 GB/s con una latencia de 1 ms. Con DR desactivado, las unidades se mantuvieron por debajo de 130 ms hasta aproximadamente 8 159,681 IOPS o aproximadamente 9.98 GB/s y alcanzaron un máximo de 2.87 XNUMX IOPS o XNUMX GB con una latencia de XNUMX ms.

En la escritura de 64K, ambas configuraciones comenzaron con una latencia de submilisegundos, pero rápidamente superaron 1 ms. Con DR activado, vimos un pico de solo 22.7 K IOPS o alrededor de 1.4 GB/s y una latencia de 1.32 ms antes de una caída en el rendimiento y un gran pico de latencia. Con la recuperación ante desastres desactivada, las unidades alcanzaron un máximo de 63,347 4 IOPS o alrededor de 3.3 GB/s a XNUMX ms antes de dejar algunas.

Nuestro próximo conjunto de pruebas son nuestras cargas de trabajo de SQL: SQL, SQL 90-10 y SQL 80-20. Para SQL, ambas configuraciones comenzaron por debajo de 1 ms con la versión de recuperación ante desastres subiendo y luego por debajo de 1 ms hasta alcanzar un máximo de 349,851 2.6 IOPS con una latencia de 255 ms. Con la recuperación ante desastres desactivada, las unidades tenían una latencia de submilisegundos hasta alrededor de 358,787 2.24 IOPS y alcanzaron un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms antes de una ligera caída.

Con SQL 90-10, nuevamente vimos que la versión habilitada para DR apareció arriba y cayó por debajo de la línea de 1 ms varias veces antes de alcanzar un máximo de 283,524 3.42 IOPS con una latencia de 1 ms. La versión sin DR se mantuvo por debajo de 275 ms hasta alrededor de 334,737 2.45 IOPS y alcanzó un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms.

SQL 80-20 vio que ambas configuraciones comenzaban con una latencia de submilisegundos con la versión DR superando 1 ms a aproximadamente 155 256,926 IOPS y alcanzando un máximo de 3.5 210 IOPS con una latencia de 1 ms. La versión sin DR llegó a alrededor de 281,562 2.83 IOPS por debajo de XNUMX ms y alcanzó un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms.

Lo siguiente son nuestras cargas de trabajo de Oracle: Oracle, Oracle 90-10 y Oracle 80-20. Con Oracle, la versión habilitada para DR osciló por debajo y por encima de 1 ms y alcanzó un máximo de aproximadamente 264 3.7 IOPS a 250 ms antes de caer ligeramente. La versión sin DR tenía una latencia de submilisegundos hasta aproximadamente 314,954 3.17 IOPS y alcanzó un máximo de XNUMX XNUMX IOPS en XNUMX ms.

SQL 90-10 observó que la versión habilitada para DR permaneció por debajo de 1 ms hasta aproximadamente 225 252,034 IOPS y alcanzó un máximo de 2.44 300 IOPS con una latencia de 338,146 ms. El no DR tuvo un rendimiento de latencia de submilisegundos hasta alrededor de 1.72 XNUMX IOPS y alcanzó un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms.

Con SQL 80-20, la versión DR hace algunos cambios alrededor de 1 ms y alcanzó un máximo de 225,327 2.64 IOPS con una latencia de 211 ms. La versión sin DR tenía una latencia de submilisegundos hasta alrededor de 278,051 2 IOPS y alcanzó un máximo de XNUMX XNUMX IOPS y una latencia de XNUMX ms.

A continuación, cambiamos a nuestra prueba de clonación de VDI, completa y vinculada. Para VDI Full Clone (FC) Boot, ambas configuraciones comenzaron por debajo de 1 ms con la versión DR superando la latencia de submilisegundos a aproximadamente 85 250,209 IOPS y alcanzando un máximo de 4.04 1 IOPS y una latencia de 200 ms. La versión sin DR se mantuvo por debajo de 283,786 ms hasta aproximadamente 3.31 XNUMX IOPS y alcanzó un máximo de XNUMX XNUMX IOPS y una latencia de XNUMX ms antes de caer ligeramente.

Con el inicio de sesión inicial de VDI FC, la versión DR alcanzó un máximo de aproximadamente 129 4.2 IOPS a 1 ms antes de disminuir el rendimiento y aumentar significativamente la latencia. La versión sin DR comenzó por debajo de 75 ms y se mantuvo allí hasta alrededor de 139,401 6.3 IOPS y alcanzó un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms con una ligera caída.

VDI FC Monday Login hizo que la versión DR comenzara por debajo de 1 ms, pero rápidamente la superó y alcanzó un máximo de 108,611 2.22 IOPS con una latencia de 1 ms. La versión sin DR se mantuvo por debajo de 90 ms hasta apenas alcanzar los 152,516 3.25 IOPS y alcanzó un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms.

Para VDI LC Boot, ambas configuraciones comenzaron por debajo de 1 ms con DR apareciendo de inmediato y alcanzando un máximo de 214,327 2.34 IOPS con una latencia de 1 ms. La versión sin DR se mantuvo por debajo de 205 ms hasta aproximadamente 255,235 1.85 IOPS y alcanzó un máximo de XNUMX XNUMX IOPS y una latencia de XNUMX ms.

El inicio de sesión inicial de VDI LC vio el pico de la versión DR en aproximadamente 95K IOPS con una latencia de 2.2 ms antes de caer significativamente. La versión sin DR se mantuvo por debajo de 1 ms hasta aproximadamente 65 112,182 IOPS y alcanzó un máximo de 2.23 XNUMX IOPS con una latencia de XNUMX ms.

Finalmente, VDI LC Monday Login pintó una imagen similar a la anterior con la versión DR alcanzando un máximo de aproximadamente 108K IOPS con una latencia de aproximadamente 3.7ms antes de caer bastante. La versión sin DR tenía una latencia de submilisegundos hasta aproximadamente 65 126,656 IOPS y alcanzó un máximo de 3.91 XNUMX IOPS con una latencia de XNUMX ms.

Conclusión

El Western Digital Ultrastar DC SN630 es el nuevo SSD NVMe para centros de datos que viene en dos sabores: centrado en lectura y de uso mixto. Las unidades vienen en rangos de capacidad de 800 GB a 6.4 TB para uso mixto y de 960 GB a 7.68 TB para lectura centrada. La unidad aprovecha el controlador, el firmware y la NAND BiCS 64D de 3 capas de Western Digital. Todas las unidades ofrecen ISE, que es excelente para redespliegue o retiro. Otra característica de seguridad es el uso de descargas seguras de firmware con autenticación RSA para garantizar que el SN630 ejecute solo firmware auténtico. Dado que el SN630 tiene certificación vSAN, lo probamos en el contexto de VMware vSAN para ver cómo funcionaba.

Para el rendimiento, ejecutamos el SSD Western Digital DC SN630 NVMe a través de nuestro análisis de carga de trabajo de aplicaciones y nuestro análisis de carga de trabajo de VDBench. Para el análisis de la carga de trabajo de la aplicación, las unidades arrojaron buenos números. En SQL Server, el SN630 tuvo una puntuación transaccional agregada de 12,610.3 14.8 TPS y una latencia promedio agregada de 630 ms. Con Sysbench, el SN11,739.7 alcanzó los 21.86 TPS, una latencia media de 38.71 ms, y en el peor de los casos, las unidades nos dieron una puntuación total de XNUMX ms.

En nuestras cargas de trabajo de VDBench, probamos las unidades con su DR encendido y apagado. Obviamente, la desactivación de DR dará como resultado un mejor rendimiento; sin embargo, varios clientes necesitan ejecutar DR y es bueno tener una idea de cómo funcionarán las unidades con DR activado. Los aspectos más destacados de la desactivación de DR incluyen 442 4 IOPS en lectura de 196 K, 4 9.98 IOPS de escritura en 64 K, 4 GB/s en lectura de 64 K y 359 GB/s en escritura de 335 K. En nuestras cargas de trabajo de SQL, vimos 90 10 IOPS, 282 80 IOPS en SQL 20-315 y 338 90 IOPS en SQL 10-278. Para Oracle, vimos un rendimiento máximo de hasta 80 20 IOPS, 630 284 IOPS en Oracle 139-153 y 630 255 IOPS en Oracle 112-127. En nuestra prueba de clones de VDI, el SNXNUMX nos dio XNUMX XNUMX IOPS en el arranque, XNUMX XNUMX IOPS en el inicio de sesión inicial y XNUMX XNUMX IOPS en el inicio de sesión del lunes para el clon completo. En el clon vinculado, el SNXNUMX alcanzó XNUMX XNUMX IOPS en el arranque, XNUMX XNUMX IOPS en el inicio de sesión inicial y XNUMX XNUMX IOPS en el inicio de sesión del lunes.

Para nuestras cargas de trabajo de VDBench con DR habilitado, el SN630 tuvo aspectos destacados de 388 4 IOPS en lectura de 183 K, 4 8.3 IOPS de escritura en 64 K, 1.4 GB/s en lectura de 64 K y 350 GB/s en escritura de 283 K. En nuestras cargas de trabajo SQL vimos 90 10 IOPS, 257 80 IOPS en SQL 20-264 y 252 90 IOPS en SQL 10-225. Para Oracle, vimos un rendimiento máximo de hasta 80 20 IOPS, 630 220 IOPS en Oracle 129-109 y 630 214 IOPS en Oracle 95-108. En nuestra prueba de clones de VDI, el SNXNUMX nos dio XNUMX XNUMX IOPS en el arranque, XNUMX XNUMX IOPS en el inicio de sesión inicial y XNUMX XNUMX IOPS en el inicio de sesión de lunes para el clon completo. En el clon vinculado, el SNXNUMX alcanzó XNUMX XNUMX IOPS en el arranque, XNUMX XNUMX IOPS en el inicio de sesión inicial y XNUMX XNUMX IOPS en el inicio de sesión del lunes.

Cuando se utiliza dentro de VMware vSAN, la SSD Western Digital DC SN630 proporciona un rendimiento impresionante, incluso con DR activado. En este caso, aprovechamos la construcción de un servidor modesto y aun así obtuvimos resultados impresionantes. El SN630 sería una buena opción para aquellos que utilizan vSAN.

Página del producto WD Ultrastar DC SN630

Discutir esta revisión

Suscríbase al boletín de StorageReview

*Las pruebas de rendimiento en las que se basó esta revisión fueron encargadas por Western Digital