PowerStore: Técnicas eficaces para evaluar el rendimiento de los arreglos de almacenamiento

Nota: El análisis comparativo solo es válido si todo está configurado de acuerdo con las prácticas recomendadas de PowerStore y no hay problemas de conectividad o configuración. De lo contrario, es probable que la prueba produzca datos irrelevantes.

• Pruebe con variables que se asemejen a lo que será la carga de trabajo/entorno real. Recuerde que la mayoría de las herramientas son simuladores y nunca alcanzan el 100 % de una verdadera carga de trabajo de producción simulada.
• Si la carga de trabajo varía ampliamente, considere realizar varias iteraciones de pruebas de lectura/escritura con distintos tamaños de bloques y patrones de acceso.
• Utilice operaciones o pruebas multiproceso y asíncronas para garantizar funcionalidades de rendimiento paralelas o simultáneas y asegurarse de que se está ejerciendo el potencial de rendimiento agregado general. 
• Considere y revise los parámetros de referencia estándar de la industria para los equipos que se están evaluando, ya que se relacionan con la carga de trabajo de producción de su empresa.
• Evite realizar pruebas contra un sistema de archivos o volúmenes vacíos o con bajo uso de espacio. Si no asigna espacio previamente en las cargas de trabajo de escritura, puede ver latencia debido a la asignación dinámica de espacio durante la prueba.
• No olvide probar la E/S de lectura, ya que suele ser la dominante de las dos en la mayoría de los entornos. Tenga en cuenta la pérdida de paquetes/tramas en la infraestructura de red durante las pruebas.
• Verifique que esté probando en varios dispositivos para simular un entorno típico con muchos hosts o clientes. Por ejemplo, en PowerStore, un buen número es 16 volúmenes. Por lo general, el conteo de volúmenes coincide con la cantidad de hosts o clientes utilizados (físicos o virtuales); Aquí es donde se logra la simultaneidad.

 

Herramientas y simuladores de
evaluación comparativaTenga en cuenta que la mayoría de las herramientas son simuladores y es probable que nunca se simule el 100 % de una verdadera carga de trabajo de producción. Estas herramientas de análisis comparativo se utilizan para tener una idea de cómo podría, debería o sería el rendimiento en determinadas situaciones. Dell no posee estas herramientas y no es responsable de ningún problema que pueda estar asociado con ellas.

Con cualquier situación de pruebas de rendimiento, asegúrese de que se utilicen herramientas con funcionalidades asíncronas y multiproceso. Algunos ejemplos de estas herramientas son:

• Comprobador de E/S flexible (FIO)
• IOmeter
• Vdbench (requiere una cuenta de Oracle)
• Medidor NFSometer (Solo Fedora/NFS)
• Lista de comprobación del rendimiento del NAS de Intel

 

Evite los siguientes tipos de pruebas:

• Copiar y pegar
• Arrastrar y soltar
• Respaldo en disco de un solo sistema de archivos
• Pruebas de DD
• Agrandar
• Wlarge
• Mkfile
• Descomprimir, extraer y comprimir

Hay ciertas cosas a tener en cuenta en la mayoría de los escenarios de referencia. Esta sección no sustituye la comprensión del tamaño y las características de la carga de trabajo. Sin embargo, si carece de datos pasados y necesita una estimación aproximada del comportamiento de la aplicación para comparar las funcionalidades de PowerStore (no el rendimiento de cargas de trabajo específicas), tenga en cuenta los siguientes factores:

 

 

IODepth (profundidad de la línea de espera)
Una profundidad de I/O baja (o no lo suficientemente alta) puede limitar el rendimiento potencial según la situación. Por lo tanto, verifique siempre que la profundidad de IO sea lo suficientemente alta como para reflejar o emular los requisitos de simultaneidad de una carga de trabajo. Es posible que una profundidad de IO demasiado baja no utilice correctamente el dispositivo en todo su potencial. Además, tenga cuidado con una profundidad de IO demasiado alta, esto puede causar algunas colas significativas en el dispositivo y, según el tiempo de servicio del dispositivo, podría haber tiempos de respuesta más grandes como resultado. Esto puede ser un reflejo de cómo podría verse un sistema sobrecargado.

Para esta prueba, los números son significativamente más bajos cuando hay una profundidad de IO de uno en comparación con una profundidad de IO de algo más real, como 64. Tenga en cuenta que se trata de un arreglo todo flash, por lo que este concepto se ve en su forma extrema, pero cada vez más común".

IOdepth = 1 ", es alrededor de ~ 30,000 operaciones de entrada y salida por segundo (IOPS) promedio para la prueba.

 

"IOdepth=64" es alrededor de ~107 000 IOPS promedio para la prueba.

 

 

"IOdepth=256" es alrededor de ~142 000 IOPS promedio para la prueba.

 

 

Como se mencionó, el rendimiento se nivela a cierta profundidad de IO en la mayoría de las configuraciones. Aquí hay una profundidad de cola de 512 y solo hay un pequeño aumento en IOPS desde una profundidad de IO de 64".

IOdepth = 512 ", es alrededor de ~ 146,000 IOPS promedio para la prueba.

 

 


Asíncrono vs Síncrono
Se utilizan dos motores principales distintos. Las más populares y, por mucho, las más eficientes en términos de rendimiento son las "I/O asíncronas". El tipo de motor menos eficiente y de menor rendimiento es la I/O síncrona y se utiliza normalmente con aplicaciones que tienen requisitos estrictos de integridad y garantía de datos. Las I/O síncronas también se pueden encontrar en tecnologías de replicación de objetivo de punto de recuperación (RPO) casi nulas. En las pruebas de rendimiento y el análisis comparativo, desde la perspectiva del host, asíncrono significa que no se necesita una confirmación para una sola I/O a fin de solicitar la siguiente I/O. En las cargas de trabajo síncronas, se necesita una confirmación para una I/O antes de emitir la siguiente y una confirmación (ACK) para cada operación de I/O subsiguiente solicitada. Por lo tanto, las I/O síncronas suelen tener una cola de 1 o menos y nunca utilizan completamente el recurso en todo su potencial. El acoplamiento de operaciones síncronas con un conteo de subprocesos bajo o único puede limitar gravemente el potencial de rendimiento, por lo que siempre verifique que está realizando pruebas asíncronas y, si está utilizando pruebas síncronas, asegúrese de emplear varios subprocesos, a menos que el entorno de la aplicación indique explícitamente lo contrario.

Asíncrona (Libaio: asíncrona nativa de Linux) = sincronización de 1 subproceso



(I/O síncrona):  

 

 

Hilos
Los hilos de ejecución son importantes. Las pruebas siempre se deben realizar con varios subprocesos, especialmente en las pruebas/cargas de trabajo síncronas. Esto intenta simular varias iteraciones de un trabajo/prueba en función del comportamiento del proceso de una aplicación empresarial. Múltiples subprocesos junto con actividad simultánea son donde se logra el rendimiento agregado de un sistema. La mayoría de los motores asíncronos emplean varios subprocesos, por lo que no tiene que preocuparse tanto por el número de subprocesos. Si no tiene suficientes subprocesos durante las cargas de trabajo síncronas, puede limitar gravemente el rendimiento potencial total de una prueba de carga en un sistema".

"Multiproceso" significa que varios subprocesos funcionan en paralelo. Por ejemplo, si tiene un solo dispositivo que puede atender 1000 IOPS en una carga de trabajo síncrona, esto significa que el dispositivo tiene un tiempo de respuesta de 1 ms sin cola (por lo tanto, sin cola, tiempo de servicio y tiempo de respuesta deberían ser sinónimos). Obviamente, los dispositivos con tiempos de respuesta de 1 ms pueden hacer mucho más trabajo que 1000 IOPS, y esto se logra mediante el apilamiento de varios subprocesos o flujos paralelos de la misma carga de trabajo. Por lo tanto, si aumenta los subprocesos (o "cosas que hacen este trabajo específico") a 10, ahora tiene 10 subprocesos individuales realizando E/S a un dispositivo a 1 ms. Cada subproceso de carga de trabajo individual aún obtiene 1 ms, lo que significa que cada subproceso aún solo alcanza 1000 IOPS, pero ahora todo el "proceso" o "trabajo" que ejecutan estos subprocesos múltiples obtiene 10 000 IOPS.

Existen herramientas y cargas de trabajo que pueden alcanzar adecuadamente los límites de un dispositivo con un solo subproceso, y algunas necesitan más. En resumen, cuando se simula una carga síncrona, desea tener tantos subprocesos/trabajadores/flujos como sea posible sin afectar el tiempo de respuesta general. Hay un punto en el que el aumento del número de subprocesos deja de tener un efecto positivo (cuando el dispositivo está 100 % ocupado). Por lo general, con las cargas de trabajo asíncronas, el conteo de subprocesos se realiza de manera predeterminada. Por ejemplo, a continuación, aún puede ver una diferencia entre 1 subproceso y 10 para una carga de trabajo asíncrona, aunque no es significativa. La moraleja de la historia es que con las cargas de trabajo asíncronas, no debería tener que preocuparse tanto por los subprocesos. 

Un solo subproceso aquí puede lograr 68 000 IOPS mediante el motor "libaio" (asíncrono). 

 

Si aumenta los subprocesos (numjobs) a 10, aún puede ver un aumento en las IOPS.

 

Cuando se trata de cargas de trabajo síncronas, si bien este es un caso extremo, podría tener dos factores principales que hacen que esta prueba tenga un rendimiento deficiente, que son la naturaleza síncrona. 

enviar I/O-1, esperar ACK, enviar I/O-2, esperar ACK y así sucesivamente

 Y no poder apilar varios subprocesos para el mismo propósito. 

job1=enviar I/O-1 - job2=enviar I/O-1 - job3=enviar I/O-1..... job1=get ack, send I/O-2 - job2=get ack, send I/O-2 - job3= get ack, send I/O-2 etc

Marca directa

Con algunas herramientas, especialmente las herramientas/SO basados en *nix, es posible que vea una opción para "I/O directa". Esto se puede utilizar con motores "asíncronos" y no se debe confundir con la I/O "síncrona". En algunas herramientas sin esta marca especificada, podría estar escribiendo en la caché del servidor y no directamente en el disco. Lo que el host desea hacer es omitir su propia caché y escribir directamente en el disco. Este es un factor esencial cuando se prueba el almacenamiento. Cuando tiene la marca "direct" configurada, técnicamente está escribiendo en el disco, aunque "disco" en este caso es realmente caché de almacenamiento. Esto sigue siendo aceptable para fines de prueba porque, incluso con la carga de trabajo correcta, aún está simulando e imitando con precisión cómo se comporta esta carga de trabajo en un entorno del mundo real, ya que la carga de producción también llegará a la caché antes de enviar la confirmación. (No se sienta engañado solo porque está obteniendo números de caché de rendimiento involucrados y no solo los ejes de back-end).

 

Ancho de banda (MB/s) frente a rendimiento (IOPS)

Hay dos perspectivas principales que puede probar. El rendimiento en el mundo de las redes y el rendimiento generalmente se refiere a la transferencia de datos; sin embargo, en el entorno de SAN/bloques, es común usar "rendimiento" para representar IOPS. Por lo tanto, primero debe comprender las características de la carga de trabajo que está probando.

Ancho de banda (MB/s): el ancho de banda es la medida de datos que puede colocar a la vez (o dentro de un intervalo X, generalmente "por segundo") en una tubería o sistema. Esto significa que está midiendo la cantidad de datos que ha transferido durante un período de tiempo. Aunque el ancho de banda y las IOPS no son mutuamente excluyentes, puede tener números de ancho de banda más altos o más bajos con la misma cantidad de IOPS, todo depende del tamaño del bloque. Recuerde que no está midiendo la velocidad con ancho de banda, la velocidad es algo completamente diferente y, aunque afecta el ancho de banda, por lo general es algo que no puede controlar con cargas de trabajo de gran ancho de banda. Por lo tanto, si realiza pruebas de ancho de banda, utilice siempre bloques más grandes (dentro de lo razonable) para que sus datos por I/O sean más grandes que si realizaría pruebas de IOPS, ya que los bloques más grandes naturalmente tardarán más en repararse. Si, por ejemplo, desea alcanzar 1 MB/s, pero utiliza tamaños de bloque de 8 KB, debe insertar alrededor de 125 IOPS para lograrlo. Sin embargo, si utilizara bloques de 512 KB, solo se necesitarían dos (2) IOPS.
(Si mantuviera las 125 IOPS y aumentara el tamaño de bloque de 8 KB a 512 KB, ¡ahora está impulsando 64 MB/s!)

Sin embargo, debido a que hay más datos dentro de una sola I/O, por lo general, se tarda más en "empaquetar" esa I/O (búsqueda, encadenamiento, etc.). Por lo tanto, los tiempos de servicio pueden ser naturalmente más altos. A veces tienes una cola más pequeña, por lo que tus tiempos de respuesta, aunque naturalmente más altos, deberían ser bastante cercanos. Tenga en cuenta que, si bien el tiempo de respuesta juega un papel importante en la cantidad de ancho de banda que puede lograr, el aumento en la cantidad de datos que hay por I/O generalmente supera cualquier ligero aumento en el tiempo de respuesta (RT) por ese tipo de I/O. Dado que los tiempos de respuesta son mayores, no es conveniente que las cargas de trabajo de bloques grandes tengan que ser aleatorias. Las cargas de trabajo de ancho de banda tienden a ser secuenciales. Cuando introduce una naturaleza aleatoria en una carga de trabajo de bloques grandes, la velocidad de transferencia de datos constante se interrumpe constantemente y comienza a sentir los efectos de los tiempos de respuesta ligeramente más altos por I/O.

Rendimiento (IOPS): el rendimiento/IOPS es la perspectiva más común con las cargas de trabajo de bloques pequeños, especialmente a medida que se vuelven más aleatorias. Todo lo que supere los 32 KB-64 KB se puede considerar un bloque grande. Con el rendimiento, los factores mencionados anteriormente son los más importantes (cosas como el conteo de subprocesos, la sincronización o la asincronía, la profundidad de la línea de espera, etc.). Aquí se trata de medir no la cantidad total de datos que se pueden transferir durante X intervalo, sino la cantidad de paquetes individuales (solicitudes de E/S) que transportan esos datos a los que se intenta dar servicio (cada x intervalo). A los entornos como OLTP (bancos) les importa poco la cantidad de datos que pueden transferir porque su huella de datos suele ser pequeña. Sin embargo, estos pequeños conjuntos de datos pueden estar, y normalmente lo están, ocupados. Estos conjuntos de datos tienen una asimetría alta (se hace referencia a una pequeña cantidad de espacio, pero varía de manera agresiva y coherente). Por lo general, los paquetes pequeños de datos solo contienen solicitudes para modificar/actualizar bloques con valores numéricos o de cadena más pequeños y, por lo tanto, no se requieren paquetes de E/S grandes. Sin embargo, debido a la naturaleza de las transacciones y debido a que hay muchas de ellas, queremos verificar que podemos mantenernos al día con cada demanda individual. Por lo general, cuanto menor sea el tamaño de bloque, más IOPS puede lograr en un escenario determinado y, aunque las cargas de trabajo de bloques pequeños se asocian principalmente con el acceso aleatorio, puede lograr incluso más rendimiento con cargas de trabajo secuenciales de bloques pequeños. Sin embargo, las cargas de trabajo secuenciales de bloques pequeños son específicas y no tan comunes, por lo que debe probar estos escenarios solo si su entorno lo requiere.