Todo el mundo miente: una epopeya con servidores NVMe y Hi-CPU

Es mejor usar Diskspd en lugar de CrystalDiskMark, porque el código del primero en la interfaz con la GUI del segundo da un error gracioso.Nosotros



, en RUVDS, no teníamos un servidor NVMe en la línea para hacerlo más rápido y más potente. .. Porque en el último año la moda se fue a desplegar en tales Bitrix y 1C ... Existe una demanda para el servicio, otros servicios de alojamiento también lo tienen y se solicitan; en general, todo se debió al hecho de que solo necesita elegir una configuración y opciones de hardware específicas y comprar en las 11 ubicaciones en todo el mundo. Y aquí debo decir que actualmente solo admitimos dos configuraciones: más rápido y más lento. Porque repuestos, porque soporte, porque software, etc. es una de las partes de la política de precios adecuados. Es decir, se agregará un tercio y será posible cambiar algo allí en cuatro años.



Tenemos SSD RAID en todas partes (incluso donde HDD se muestra con una tarifa), pero queríamos más fuerte, más alto y más rápido.



Lo primero que aprendimos fue que NVMe no se combina en RAID de manera normal, es decir, como resultado, no se deben esperar discos confiables. En segundo lugar, queríamos colocar la Hi-CPU en el mismo servidor y nos sorprendió descubrir que la frecuencia de 4,5 GHz no es una de servidor, pero el hardware de escritorio doméstico y las soluciones de servidor de tal frecuencia simplemente no existen físicamente en la naturaleza todavía.



Además, en el camino, nuestro administrador encontró un error fatal en la utilidad de prueba. En general, déjeme decirle con pruebas cómo se ve la solución NVMe en el alojamiento VDS.



Debo decir de inmediato que quizás hicimos algo mal, y si alguien lo entiende, estaré muy agradecido.

▍ Expectativas de NVMe

Cuando cambiamos de HDD a SSD, la diferencia era como el cielo y la tierra. Ejecuta cualquier prueba y obtiene un aumento de rendimiento múltiple. Este no fue el caso en NVMe. Además, en una colisión frontal con nuestras configuraciones NVMe existentes, las unidades no siempre las esquivaban. Fueron más rápidos o más lentos, según las condiciones de la prueba.



Para empezar, compramos un par de opciones de servidor. Por lo general, compramos una plataforma, la probamos, entendemos qué está mal, la probamos nuevamente y luego solo la implementamos en 11 ubicaciones, porque muchas piezas de repuesto a la vez y nuevos procesos de soporte son costosos. Luego compramos una plataforma e inmediatamente nos topamos con un resultado increíblemente pobre.



En el mismo hipervisor en diferentes sistemas operativos invitados, era imposible distinguir entre SSD dentro del servidor o NVMe. Incluso con la masa.



Al usar NVMe en RAID, la velocidad será más lenta que SSD. En términos generales, cuando usamos RAID, lo incluimos en un bus PCIe y estamos limitados a este PCI Express, y podemos paralelizar solo unos pocos discos en diferentes buses. Necesitamos controladores.



Nadie podría dar una respuesta normal. Le preguntaron a un antiguo proveedor de confianza, a nuevos proveedores y, en general, a proveedores de izquierda. Todos se encogieron de hombros y dijeron: "Bueno, en general idiotas, ¿quién pega NVMe en RAID? ¡No habrá rendimiento!". La redacción era diferente a la dada, pero el significado se mantuvo sin cambios. Entonces nos dimos cuenta de que probablemente deberíamos usar NVMe sin una incursión. Hay una empresa (un competidor amistoso), y entonces, solo ellos explicaron que tenían lo mismo hace unos años. Tiraron varias plataformas y al final se decidió no usar RAID.



Es decir, el primer problema es que cuando se libera el disco, no habrá una reconstrucción automática para uno nuevo, que será traído por el administrador. Sin RAID, los clientes perderán el estado y los datos de su máquina virtual. No es lo mismo, pero estamos intentando seguir adelante.



Entonces hay una opción entre U2 y M2. Compramos llantas U2 caras. Están atrapados a través de la interfaz Okulinka en el bus. M2 se usa con más frecuencia en computadoras de escritorio, se adhieren a la placa base. También lo probamos, no hay mucha diferencia entre ellos. Pero si el disco está pegado directamente en la placa sin una interfaz intermedia, entonces es más difícil repararlo; en caso de falla, tendrá que quitar la cubierta del servidor y hurgar.

▍ Ahora las pruebas son la realidad de NVMe

El resultado depende del sistema operativo host, la versión del hipervisor, la versión del sistema operativo doméstico en la máquina virtual y la elección del método de prueba.



Depende del hecho de que los hipervisores más recientes admiten NVMe con sus controladores de forma nativa, mientras que otros funcionan como una sobrecarga SSD. Este tampoco es un resultado muy bueno, porque estamos acostumbrados a utilizar soluciones probadas. Hay un servidor Windows 12-16-19. Usamos la versión máxima 16. Cuando salga la próxima, usaremos 19. Porque las últimas versiones son siempre beta. En general, solo los geeks y suicidas usan la última versión del software en la administración del servidor. Y sí, si tu mano está temblando en este momento, eres un geek. O un probador beta. Aunque, es posible que aún no lo sepas. El proveedor de software lanza regularmente una nueva versión, reinicia, actualiza y aplica parches; es necesario pasar por una generación para que funcione de manera estable. Como siempre, estamos esperando el segundo paquete de servicios. No puede explicarle a un cliente sobre una nueva vulnerabilidad o un nuevo paquete de actualizaciones de MS. Más precisamente,podemos explicar, pero el cliente no siempre cree. Con nuestra flota de coches en el 19 de Windu, no es muy bueno correr. Si todos los servidores comienzan a hacer música en color con actualizaciones y reinicios, no querrás darte una paliza.



El segundo punto importante se refiere a la rareza del archivo de 45 GB, lo verá ahora.

Metodología: durante las pruebas, utilizamos la utilidad diskspd . CrystalDiskMark se enrosca alrededor de él , lo que se quiere utilizar en primer lugar, pero encontramos un bicho muy divertido.



Para nosotros es importante que ambas utilidades:

• Le permite especificar varios archivos de prueba al mismo tiempo. Además, estos archivos se pueden ubicar en diferentes discos. Esto puede resultar útil para comprobar el rendimiento general del controlador cuando se lee de forma independiente en diferentes discos. Número de hilos. Cuántos subprocesos independientes entre sí se crearán que leerán y escribirán archivos.
• En diskspd, número de solicitudes de E / S pendientes por subproceso; puede haber algunas discrepancias en la traducción. Además, en CrystalDiskMark este parámetro se llama Cola, aunque difícilmente se puede llamar cola.

▍ Comprensión del número de parámetros de E / S pendientes

Para entender cómo funciona la utilidad, podemos buscar en su código fuente. Las siguientes líneas son las más interesantes.



Para leer:

 if (useCompletionRoutines)
{
    rslt = ReadFileEx(...);
}
else
{
    rslt = ReadFile(...);
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Y líneas similares para escribir:

if (useCompletionRoutines)
{
    rslt = WriteFileEx(...);
}
else
{
    rslt = WriteFile(...);
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Argumentos omitidos para mayor claridad. Estamos más interesados ​​en el hecho de que la lectura y la escritura se realizan mediante las funciones estándar de WinAPI:



ReadFile

WriteFile



Y las funciones asincrónicas correspondientes:



ReadFileEx

WriteFileEx



Si observa más de cerca el código, puede comprender lo siguiente:



Al establecer el número de pendientes IO = 1 , se utilizarán las opciones síncronas ReadFile y WriteFile. El pseudocódigo para la operación de escritura se ve así:

void testThreadFunc() {
	while (!stopTesting) {
		WriteFile(...) //   
      }
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Si establece el número de E / S pendientes> 1 , se utilizarán las opciones asíncronas ReadFileEx y WriteFileEx, y el número de E / S pendientes establece la profundidad de dichas llamadas para cada subproceso. El pseudocódigo para una operación de escritura con un número de E / S pendientes = 3 se ve así:

void callback1() {
	while (!stopTesting) {
		WriteFileEx(..., callback1)
      }
}

void callback2() {
	while (!stopTesting) {
		WriteFileEx(..., callback2)
      }
}

void callback3() {
	while (!stopTesting) {
		WriteFileEx(..., callback3)
      }
}

void testThreadFunc() {
	WriteFileEx(..., callback1) //    
	WriteFileEx(..., callback2) //    
	WriteFileEx(..., callback3) //    

	//     
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Por tanto, el número de E / S pendientes es el número de llamadas asincrónicas en cada hilo.

▍ Por qué no usamos CrystalDiskMark

La utilidad CrystalDiskMark es solo una interfaz gráfica para diskspd . Es fácil adivinar esto si instala la utilidad y va al directorio CdmResource \ DiskSpd.







Pero hay varios problemas con la implementación de este shell.



Primero, modifica el código diskspd de alguna manera . Es fácil de entender si observa el código CrystalDiskMark:

command.Format(L"\"%s\" %s -d%d -A%d -L \"%s\"", ..., GetCurrentProcessId(), ...);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Al llamar a diskspd, se le pasa el parámetro -A con el Id del proceso actual. Diskspd no tiene dicho parámetro. El autor de CrystalDiskMark decidió no analizar la salida de la consola diskspd y decidió obtener los datos de una manera más complicada. Además, el método elegido no es el más exitoso.



En esta función, diskspd se llama directamente :

int ExecAndWait(TCHAR *pszCmd, BOOL bNoWindow, double *latency)
{
	DWORD Code = 0;
	…
	GetExitCodeProcess(pi.hProcess, &Code);
	*latency = (double)*pMemory * 1000; // milli sec to micro sec
	return Code;
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

En principio, no hay preguntas sobre la transferencia de latencia a través de SharedMemory . Pero si consideramos más en el código donde se usa el valor de la variable Código , queda claro que esta es la velocidad del disco medida. No es una buena idea devolverlo a través del ErrorCode del proceso. Por ejemplo, si el proceso finaliza con un error por alguna otra razón, el código de error simplemente se mostrará como resultado de la prueba.



También existen dudas sobre la exactitud del valor de retorno de latencia . Al especificar el modificador -L, diskspd devuelve algo como esto:





Por ejemplo, la sexta línea significa que el 95% de las veces la latencia será inferior a 54.306 ms . CrystalDiskMark simplemente devuelve el promedio de todos los valores de la tabla. Esto puede resultar engañoso.

▍ Parámetros de prueba

Para ver los beneficios de NVME, debe establecer el número de E / S sobresalientes lo suficientemente grande. Elegimos el número 32.



❒ Plataforma:



Supermicro SuperServer SYS-6029P-WTRT 2U



❒ Unidades:



Intel SSD DC P4610 Series 1.6TB, 2.5in PCIe 3.1 x4, 3D2, TLC



❒ Comandos para ejecutar diskspd para archivos 10G:

DiskSpd64.exe -b128K -t32 -o32 -w0 -d10 -si -S -c10G G:/testfile.dat
DiskSpd64.exe -b128K -t32 -o32 -w100 -d10 -si -S -c10G G:/testfile.dat
DiskSpd64.exe -b4K -t32 -o32 -w30 -d10 -r -S -c10G G:/testfile.dat
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

❒ Comandos para ejecutar diskspd para archivos 50G:

DiskSpd64.exe -b128K -t32 -o32 -w0 -d10 -si -S -c50G G:/testfile.dat
DiskSpd64.exe -b128K -t32 -o32 -w100 -d10 -si -S -c50G G:/testfile.dat
DiskSpd64.exe -b4K -t32 -o32 -w30 -d10 -r -S -c50G G:/testfile.dat
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

▍ Resultados

❒ Tabla 1 Sistema operativo host Windows Server 2019



❒ Tabla 1 Sistema operativo host Windows Server 2016



En Hyper-V y un invitado de Windows Server, los resultados son difíciles de explicar. En un archivo pequeño de aproximadamente 10G, obtenemos un gran aumento de IOPS en comparación con un SSD en una incursión. Pero si tomamos un archivo de 45G , por el contrario, obtenemos una caída significativa de IOPS.

▍ Ahora vamos a Hi-CPU

La segunda sorpresa se abrió en procesadores de 4.5 GHz.



Debe decirse aquí que los procesadores en las líneas del servidor también son utilizados por la generación -1 desde el escritorio. Porque los probadores beta son jugadores y puedes enviarles parches de software. Pero en los servidores, incluso la misma hoja del corazón no se corrigió de inmediato, y no todo. Todas las soluciones de servidor son fiables y caras, pero siempre tienen una velocidad inferior.



Tenemos tareas que no son de escritorio. La máquina se divide entre muchos clientes. Y ahora vemos configuraciones a 4.5 GHz, que no están en la naturaleza.



Resulta que hay dos implementaciones:

• Hi-CPU ( , ). , , . .
• , turbo boost-, . ! - 3,6 4,5 . , -, : . ( ), . .

▍

Como resultado, decidimos permanecer en nuestro probado 3.6 GHz (turbo boost 4.4 GHz) y así cerrar la investigación con el procesador.



Con NVMe, después de haber obtenido resultados aleatorios de una utilidad súper estándar, como puede ver, cambiamos la herramienta. Lo siguiente es la cuestión del hipervisor y el sistema operativo.



Comercialmente, estos discos ofrecen cada vez más, hay que aprender a trabajar. Para nosotros, dejamos una cierta combinación de la versión de host del hipervisor y seguiremos probando, presentando los discos también. Si un proveedor de alojamiento escribe NVMe, todavía no significa nada. En KVM con ciertos ensamblajes * nix nuevos y una configuración minuciosa, puede obtener excelentes ganancias, pero cada prueba debe marcarse con un asterisco: "en tales condiciones, si cambia un poco, y en general no todo es así". En el 12 de Windows o Debian, todo es diferente.



En general, NVMe es un estándar incondicional, pero hasta ahora esto no significa que definitivamente será más rápido con él. Estamos implementando servidores con él con cuidado, pero mientras la ganancia corresponda aproximadamente al aumento de precio, no hay magia.