Contestaré en dos partes: primero "por qué la respuesta tradicional sobre la separación de secuencial y aleatoria a menudo no se aplica".
Luego, analizaré los beneficios potenciales de separar archivos en el disco físico de Windows y agregar vHBA adicionales y distribuir los discos físicos entre ellos.
Esperar el beneficio de separar la E / S de disco aleatoria y secuencial en el nivel de disco físico de Windows generalmente supone dispositivos HDD para el almacenamiento de datos. También suele suponer que los discos físicos de Windows separados significan dispositivos HDD separados. La idea es que algunos conjuntos de HDD manejan principalmente E / S de disco secuenciales y tienen un movimiento de cabeza de disco muy limitado (por ejemplo, los HDD que alojan un txlog * ocupado) mientras que un conjunto separado de HDD maneja E / S de disco aleatorio.
Esos supuestos raramente se mantienen hoy, especialmente en una VM. En primer lugar, a menos que los discos físicos de Windows de las máquinas virtuales sean RDM, varios de ellos podrían estar en un único almacén de datos, o tal vez varios almacenes de datos estén en un único LUN host ESXi. Entonces, lo que está separado en el invitado se puede mezclar en el nivel de host ESXi.
Pero supongamos que se usan RDM, o que cada disco físico invitado está en su propio almacén de datos, en su propio ESXi LUN. Incluso entonces, la secuencia secuencial independiente de io aleatorio en el invitado a menudo se combina en la matriz, porque los LUN presentados al host ESXi pueden provenir del mismo grupo único de dispositivos de disco. Casi todas las matrices de almacenamiento hacen esto ahora, ya sea exclusivamente o como una opción para facilitar la administración y aumentar la eficiencia de la matriz / utilización de recursos.
Finalmente, hoy tanto almacenamiento es flash o flash híbrido + HDD. Sin tener que preocuparse por el movimiento de la cabeza, al flash no le importa la separación de secuencial para aleatorio ... ni siquiera le importa el tejido IO.
Entonces ... esas son todas las razones por las que separar secuencial de aleatorio puede no ser tan beneficioso. A continuación, explicamos por qué la difusión de archivos a través de los discos físicos y la distribución de los discos físicos a través de los vHBA aún puede aumentar el rendimiento de todos modos.
* Mencioné a propósito un único registro de transacciones en este ejemplo de HDD. Cuando varias secuencias de E / S de disco secuenciales separadas (por ejemplo, 8 registros de transacciones ocupadas) se llevan a cabo en los mismos discos duros, a menos que de alguna manera casi toda la actividad esté dentro de la memoria caché SAN, el movimiento constante de la cabeza entre las pistas de E / S secuenciales conduce al tejido de E / S. Ese es un tipo específico de golpes en la cabeza del disco que conduce a una latencia del disco que es "peor que aleatoria". Ocurre en RAID5 y RAID10, aunque RAID10 puede tolerar un poco más de variación en este sentido que RAID5 antes de una degradación significativa.
Ahora, dado el largo discurso acerca de cómo separar la secuencia de lo aleatorio podría no ayudar, ¿cómo puede ayudar la distribución de archivos a través de discos físicos? ¿Cómo puede ayudar la difusión de los riesgos físicos entre los vHBA?
Se trata de colas de E / S de disco.
Cualquier disco físico de Windows o LogicalDisk puede tener hasta 255 E / S de disco pendientes a la vez en lo que perfmon informa como "Cola de disco actual". Desde las E / S de disco pendientes en la cola de discos físicos, el almacenamiento puede pasar hasta 254 al minidriver. Pero el minidriver también puede tener una cola de servicio (transmitida al siguiente nivel inferior) y una cola de espera. Y se le puede decir a storport que reduzca el número que pasa de 254.
En un invitado VMware Windows, el controlador pvscsi tiene una profundidad de cola de "dispositivo" predeterminada de 64, donde el dispositivo es un disco físico. Por lo tanto, aunque perfmon podría mostrar hasta 255 E / S de disco en la "longitud de la cola de disco actual" para un solo disco físico, solo se pasarían hasta 64 al siguiente nivel a la vez (a menos que se cambien los valores predeterminados).
¿Cuántas E / S de disco pueden ser excepcionales para una?registro de transacciones ocupado a la vez? Bueno, las escrituras del registro de transacciones pueden tener un tamaño de hasta 60 kb. Durante un ETL a gran escala, a menudo veo cada escritura en el txlog a 60kb. El escritor de txlog puede tener hasta 32 escrituras de 60 kb pendientes para un txlog a la vez. Entonces, ¿qué sucede si tengo un txlog de preparación ocupado y un dw txlog ocupado en el mismo disco físico, con la configuración predeterminada de VMware? Si ambos txlogs están alcanzando un máximo de 32 escrituras pendientes de 60 kb cada uno, ese disco físico está en su profundidad de cola de 64. Ahora ... ¿qué pasa si también hay archivos planos como fuente ETL en el disco físico? Bueno ... entre las lecturas de los archivos planos y las escrituras de txlog, tendrían que usar la cola de espera, porque solo 64 pueden salir a la vez. Para bases de datos con txlogs ocupados como ese, ya sea servidor físico o virtual, recomiendo el txlog en su propio disco físico, sin nada más en el disco físico. Eso evita las colas a ese nivel y también elimina cualquier preocupación con el contenido de múltiples archivos intercalados (que es una preocupación mucho, mucho menor en estos días).
¿Cuántas E / S de disco pueden estar pendientes de un archivo de fila a la vez (desde la perspectiva de SQL Server, no necesariamente enviadas a niveles inferiores)? En realidad, no hay un límite en SQL Server (que he encontrado, de todos modos). Pero suponiendo que el archivo está en un solo disco físico de Windows (no recomiendo el uso de discos dinámicos a rayas para SQL Server, que es un tema para otro momento), no es un límite. Es el 255 que mencioné antes.
Con la magia de la lectura anticipada de SQL Server y la E / S asincrónica, he visto 4 consultas simultáneas que se ejecutan cada una en una unidad en serie con una "longitud de cola de disco actual" total de más de 1200. Debido al límite de 255, eso ni siquiera es posible con todo el contenido del archivo de filas en un solo disco físico. Fue contra un grupo de archivos primario con 8 archivos, cada uno en su propio disco físico.
Por lo tanto, las lecturas leídas pueden ser muy agresivas y pueden enfatizar las colas de E / S. Pueden ser tan agresivos que otras lecturas y escrituras de archivos de fila terminan esperando. Si los registros de transacciones están en el mismo disco físico que los archivos de fila, durante las lecturas simultáneas de lectura y escritura de txlog, es muy fácil esperar a que ocurra. Incluso si esa espera no está en el nivel de "longitud actual de la cola del disco", puede estar esperando en la cola del dispositivo (64 por defecto con pvscsi).
Las lecturas de respaldo contra archivos de fila también pueden ser agresivas, especialmente si se ha ajustado el conteo de búferes para maximizar el rendimiento del respaldo.
Hay un tipo más de SQL Server io que debe tener en cuenta al considerar aislar txlogs: consulta de derrame a tempdb. Cuando se produce un derrame de consultas, cada derrame de trabajo escribe en tempdb. ¿Se derramaron muchos trabajadores paralelos al mismo tiempo? Eso puede ser una gran carga de escritura. Mantener un txlog ocupado y archivos de fila importantes alejados de eso puede ser realmente útil :-)
Ahora, es posible cambiar la profundidad predeterminada de la cola del dispositivo para el controlador pvscsi. El valor predeterminado es 64, y se puede configurar hasta 254, que es el que más información transmitirá. Pero ten cuidado al cambiar esto. Siempre recomiendo alinear la profundidad de la cola del dispositivo invitado con la profundidad de la cola LUN del host ESXi subyacente. Y establecer la profundidad de la cola de LUN del host ESXi según las mejores prácticas de matriz. ¿Usando un EMC VNX? La profundidad de la cola del LUN del host debe ser 32. ¿El invitado usa RDM? Excelente. Establezca la profundidad de la cola del dispositivo pvscsi invitado en 32 para que esté alineada con la profundidad de la cola LUN del host ESXi. EMC VMAX? Típicamente 64 en el nivel de host ESXi, 64 en invitado. Pure / Xtremio / IBM FlashSystem? ¡A veces, la profundidad de la cola de LUN del host se establecerá en 256! Continúe y configure la profundidad de la cola del dispositivo pvscsi en 254 (máximo posible).
Aquí hay un enlace con instrucciones.
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2053145
El enlace también habla acerca de requestringpages - WhatAreThose ?? Determinan la profundidad de la cola para el propio adaptador pvscsi. Cada página ofrece 32 ranuras en la profundidad de la cola del adaptador. De forma predeterminada, requestringpages es 8 para una profundidad de cola de adaptador de 256. Se puede configurar hasta 32 para 1024 ranuras de profundidad de cola de adaptador.
Digamos que todo está por defecto. Tengo 8 discos físicos con archivos de fila, y SQL Server está ligeramente ocupado. Hay un promedio de 32 "longitud de cola de disco actual" entre los 8, y ninguno es superior a 64 (todo cabe en las diversas colas de servicio del dispositivo). Genial, eso da 256 OIO. Encaja en las colas de servicio del dispositivo, encaja en la cola del servicio del adaptador para que los 256 salgan del invitado a las colas en el nivel de host ESX.
Pero ... si las cosas se ponen un poco más ocupadas, entonces un promedio de 64 con una cola de algunos discos físicos de hasta 128. Para aquellos dispositivos con más de 64 pendientes, el excedente está en una cola de espera. Si hay más de 256 en la cola de servicio de los dispositivos en los 8 discos físicos, el excedente está en una cola de espera hasta que se abran las ranuras en la cola de servicio del adaptador.
En ese caso, agregar otro pvscsi vHBA y distribuir los discos físicos entre ellos duplica la profundidad total de la cola del adaptador a 512. Al mismo tiempo, se puede pasar más io de invitado a host.
Algo similar podría lograrse al quedarse en un adaptador pvscsi y aumentar las páginas de solicitud. Ir a 16 produciría 512 espacios, y 32 produce 1024 espacios.
Cuando sea posible, recomiendo ir a lo ancho (agregar adaptadores) antes de profundizar (aumentar la profundidad de la cola del adaptador). Pero ... en muchos de los sistemas más ocupados, tengo que hacer ambas cosas: poner 4 vHBA en el invitado y aumentar las páginas de solicitudes a 32.
También hay muchas otras consideraciones. Cosas como sioc y limitación de profundidad de cola adaptativa si se usan vmdks, configuración de múltiples rutas, configuración del adaptador ESXi más allá de la profundidad de cola LUN, etc.
Pero no quiero quedarme más de la cuenta :-)
Lonny Niederstadt @sqL_handLe