En este artículo, me gustaría hablar sobre las características del funcionamiento de los arrays All Flash de AccelStor con una de las plataformas de virtualización más populares: VMware vSphere. En particular, quiero enfatizar esos parámetros que ayudarán a obtener el máximo efecto del uso de una herramienta tan poderosa como All Flash.
Los arrays All Flash AccelStor NeoSapphire™ son o dispositivos nodales basados en unidades SSD con un enfoque fundamentalmente diferente en la implementación del concepto de almacenamiento de datos y la organización del acceso a ellos utilizando su propia tecnología en lugar de los algoritmos RAID bastante populares. Los arrays proporcionan acceso en bloque para los hosts a través de las interfaces Fibre Channel o iSCSI. A modo de justicia, cabe destacar que los modelos con interfaz iSCSI también tienen acceso de archivos como un agradable bono. Pero en este artículo, nos centraremos en la aplicación de protocolos de bloque como los más productivos para All Flash.
Todo el proceso de despliegue y la posterior configuración del trabajo conjunto entre el array AccelStor y el sistema de virtualización VMware vSphere se puede dividir en varias etapas:
- Implementación de la topología de conexión y configuración de la red SAN;
- Configuración del array All Flash;
- Configuración de los hosts ESXi;
- Configuración de máquinas virtuales.
Como equipo para los ejemplos se utilizaron los arrays AccelStor NeoSapphire™ con interfaz Fibre Channel y con interfaz iSCSI. Como software base: VMware vSphere 6.7U1.
Antes de desplegar los sistemas descritos en el artículo, se recomienda encarecidamente revisar la documentación de VMware sobre cuestiones de rendimiento ( ) y configuraciones iSCSI ()
Topología de conexión y configuración de la red SAN
Los componentes principales de la red SAN son los adaptadores HBA en los hosts ESXi, los conmutadores SAN y los nodos del array. Una topología típica de tal red se vería así:
Bajo el término Switch se entiende tanto un conmutador físico separado o un conjunto de conmutadores (Fabric), así como un dispositivo compartido entre diferentes servicios (VSAN en el caso de Fibre Channel y VLAN en el caso de iSCSI). El uso de dos conmutadores/Fabric independientes permitirá eliminar un posible punto de falla.
La conexión directa de los hosts al arreglo, aunque es posible, no se recomienda en absoluto. El rendimiento de los arreglos All Flash es bastante alto. Para alcanzar la máxima velocidad, es necesario utilizar todos los puertos del arreglo. Por lo tanto, es imprescindible contar con al menos un conmutador entre los hosts y NeoSapphire™.
La presencia de dos puertos en el HBA del host también es un requisito fundamental para lograr el máximo rendimiento y asegurar la redundancia.
En el caso de utilizar la interfaz de Fibre Channel, es necesaria la configuración de zonas para evitar posibles colisiones entre iniciadores y objetivos. Las zonas se construyen sobre la base de "un puerto de iniciador - uno o más puertos del arreglo".
Si se utiliza la conexión a través de iSCSI en el caso de compartir un conmutador con otros servicios, es imprescindible aislar el tráfico de iSCSI dentro de una VLAN separada. También se recomienda encarecidamente habilitar el soporte para Jumbo Frames (MTU = 9000) para aumentar el tamaño de los paquetes en la red y, de este modo, reducir la cantidad de información de overhead durante la transmisión. Sin embargo, es importante recordar que para un funcionamiento correcto se debe cambiar el parámetro MTU en todos los componentes de la red en la cadena "iniciador-conmutador-objetivo".
Configuración del arreglo All Flash
El arreglo se entrega a los clientes con grupos ya formados. Por lo tanto, no es necesario realizar ninguna acción para unir los dispositivos en una única estructura. Simplemente se deben crear volúmenes del tamaño requerido y en la cantidad necesaria.
Para mayor comodidad, existe la funcionalidad de creación masiva de varios volúmenes de un tamaño específico. Por defecto, se crean volúmenes "delgados", ya que esto permite un uso más eficiente del espacio de almacenamiento disponible (también gracias al soporte de Space Reclamation). Desde el punto de vista del rendimiento, la diferencia entre volúmenes "delgados" y "gruesos" no supera el 1%. Sin embargo, si se requiere "exprimir al máximo" el arreglo, siempre se puede convertir cualquier volumen "delgado" en "grueso". Pero se debe tener en cuenta que esta operación es irreversible.
Luego, se deben «publicar» los volúmenes creados y establecer los permisos de acceso desde los hosts mediante ACL (direcciones IP para iSCSI y WWPN para FC) y la separación física por puertos del array. Para modelos iSCSI, esto se realiza a través de la creación de un Target.
Para los modelos FC, la publicación se lleva a cabo mediante la creación de un LUN para cada puerto del array.
Para acelerar el proceso de configuración, los hosts se pueden agrupar. Además, si en el host se utiliza una HBA FC de varios puertos (lo cual es lo más común en la práctica), el sistema identifica automáticamente que los puertos de esa HBA pertenecen a un único host gracias a los WWPN, que difieren en uno. También se soporta la creación masiva de Target/LUN para ambas interfaces.
Una observación importante en el caso de utilizar la interfaz iSCSI es la creación de múltiples targets para los volúmenes, con el fin de aumentar el rendimiento, ya que la cola en el target no se puede modificar y, de hecho, será el cuello de botella.
Configuración de hosts ESXi
Desde los hosts ESXi, la configuración básica se lleva a cabo según un escenario bastante previsible. El orden de acciones para la conexión iSCSI es:
- Agregar el Adaptador iSCSI de Software (no es necesario si ya está agregado o en caso de estar usando un Adaptador iSCSI de Hardware);
- Crear un vSwitch a través del cual pasará el tráfico iSCSI, y agregar en él uplinks físicos y VMkernal;
- Agregar las direcciones del array en Dynamic Discovery;
- Crear un Datastore
Algunas observaciones importantes:
- En general, se puede utilizar un vSwitch ya existente, pero en el caso de un vSwitch separado, la gestión de la configuración del host será significativamente más sencilla.
- Es necesario separar el tráfico de Management y iSCSI en enlaces físicos y/o VLAN distintos para evitar problemas de rendimiento.
- Las direcciones IP de VMkernal y de los puertos correspondientes del array All Flash deben estar dentro de la misma subred, nuevamente por cuestiones de rendimiento.
- Para garantizar la alta disponibilidad según las reglas de VMware, el vSwitch debe tener al menos dos uplinks físicos.
- Si se utilizan Jumbo Frames, es necesario cambiar el MTU tanto en el vSwitch como en el VMkernal.
- No estará de más recordar que, de acuerdo con las recomendaciones de VMware para adaptadores físicos que se utilizarán para gestionar el tráfico iSCSI, es imprescindible realizar la configuración de Teaming y Failover. En particular, cada VMkernel debe operar solo a través de un uplink, y el segundo uplink debe ser configurado en modo unused. Para garantizar la alta disponibilidad, es necesario añadir dos VMkernels, cada uno de los cuales funcionará a través de su propio uplink.
Adaptador VMkernel (vmk#)
Adaptador de Red Física (vmnic#)
vmk1 (Almacenamiento01)
Adaptadores Activos
vmnic2
Adaptadores No Utilizados
vmnic3
vmk2 (Almacenamiento02)
Adaptadores Activos
vmnic3
Adaptadores No Utilizados
vmnic2
Para realizar la conexión a través de Fibre Channel no se requieren acciones previas. Se puede crear el Datastore de inmediato.
Después de crear el Datastore, es necesario asegurarse de que se está utilizando la política Round Robin para los caminos hacia el Target/LUN como la más eficiente.
Por defecto, las configuraciones de VMware prevén el uso de esta política como sigue: 1000 solicitudes a través del primer camino, las siguientes 1000 solicitudes a través del segundo camino, y así sucesivamente. Esta interacción del host con un arreglo de doble controlador no será equilibrada. Por lo tanto, se recomienda establecer el parámetro Round Robin policy = 1 a través de Esxcli/PowerCLI.
Parámetros
Para Esxcli:
- Listar LUN disponibles
esxcli storage nmp device list
- Copiar Nombre del Dispositivo
- Modificar la Política de Round Robin
esxcli storage nmp psp roundrobin deviceconfig set —type=iops —iops=1 —device=«Device_ID»
La mayoría de las aplicaciones modernas están diseñadas para intercambiar paquetes de datos de gran tamaño con el objetivo de maximizar el uso del ancho de banda y reducir la carga en la unidad central de procesamiento. Por lo tanto, ESXi, de manera predeterminada, envía las solicitudes de entrada/salida al dispositivo de almacenamiento en bloques de hasta 32767KB. Sin embargo, para ciertos escenarios, intercambiar en porciones más pequeñas será más eficiente. En el caso de los arreglos AccelStor, estos escenarios son los siguientes:
- La máquina virtual utiliza UEFI en lugar de BIOS Legacy
- Se utiliza vSphere Replication
Para tales escenarios, se recomienda cambiar el valor del parámetro Disk.DiskMaxIOSize a 4096.
Para conexiones iSCSI, se recomienda modificar el parámetro Login Timeout a 30 (por defecto 5) para aumentar la estabilidad de la conexión y desactivar la demora en las confirmaciones de los paquetes transmitidos DelayedAck. Ambas opciones se encuentran en vSphere Client: Host → Configurar → Almacenamiento → Adaptadores de Almacenamiento → Opciones Avanzadas para el adaptador iSCSI.
Un aspecto importante es la cantidad de volúmenes utilizados para el datastore. Es comprensible que, para simplificar la gestión, surja el deseo de crear un gran volumen que abarque toda la capacidad del arreglo. Sin embargo, tener varios volúmenes y, por lo tanto, varios datastores, beneficia el rendimiento general (más detalles sobre las colas se proporcionarán más adelante). Por ello, recomendamos crear al menos dos volúmenes.
Hasta hace poco, VMware aconsejaba limitar la cantidad de máquinas virtuales en un datastore con el objetivo de obtener el máximo rendimiento posible. Sin embargo, actualmente, especialmente con la proliferación de VDI, este problema ya no es tan urgente. No obstante, esto no elimina la regla de siempre: distribuir las máquinas virtuales que requieren un IO intensivo entre diferentes datastores. Para determinar el número óptimo de máquinas virtuales en un volumen, no hay nada mejor que realizar dentro de su infraestructura.
Configuración de máquinas virtuales
En la configuración de máquinas virtuales, no hay requisitos especiales, más bien son bastante comunes:
- Utilizar la versión de VM (compatibilidad) más reciente disponible
- Tener cuidado al establecer el tamaño de la RAM al ubicar densamente las máquinas virtuales, por ejemplo, en VDI (ya que por defecto se crea un archivo de paginación del mismo tamaño que la RAM, lo que consume capacidad útil y afecta el rendimiento final)
- Utilizar adaptadores que sean los más eficientes en términos de IO: red tipo VMXNET 3 y SCSI tipo PVSCSI
- Utilizar el tipo de disco Thick Provision Eager Zeroed para el máximo rendimiento y Thin Provisioning para un uso eficiente del espacio de almacenamiento
- Limitar, si es posible, el funcionamiento de las máquinas no críticas en cuanto a IO mediante Virtual Disk Limit
- Asegurarse de instalar VMware Tools
Notas sobre las colas
La cola (o Outstanding I/Os) es el número de solicitudes de entrada/salida (comandos SCSI) que están en espera de ser procesadas en un momento dado por un dispositivo/aplicación específica. En caso de que la cola se desborde, se emite un error QFULL, lo que finalmente se traduce en un aumento del parámetro de latencia. Cuando se utilizan sistemas de almacenamiento en disco (de plato), teóricamente, cuanto mayor sea la cola, mayor será su rendimiento. Sin embargo, no se debe abusar, ya que es fácil encontrarse con QFULL. En el caso de los sistemas All Flash, por un lado, todo es un poco más sencillo: el arreglo tiene latencias mucho más bajas y, por lo tanto, a menudo no se requiere regular el tamaño de las colas por separado. Pero, por otro lado, en ciertos escenarios de uso (una fuerte dependencia de IO para máquinas virtuales específicas, pruebas de rendimiento máximo, etc.), es necesario, si no cambiar los parámetros de cola, al menos comprender qué métricas se pueden alcanzar y, lo más importante, de qué maneras.
En el propio arreglo All Flash de AccelStor, no hay límites en relación con los volúmenes o puertos de entrada/salida. Si es necesario, incluso un único volumen puede obtener todos los recursos del arreglo. La única limitación sobre las colas se encuentra en los objetivos iSCSI. Precisamente por esta razón se mencionó anteriormente la necesidad de crear varios (idealmente hasta 8) objetivos para cada volumen para superar este límite. También reiteramos que los arreglos AccelStor son soluciones altamente productivas. Por lo tanto, se deben utilizar todos los puertos de interfaz del sistema para alcanzar la máxima velocidad.
Desde el lado del host ESXi, la situación es completamente diferente. El propio host aplica la práctica de acceso equitativo a los recursos para todos los participantes. Por ello, existen colas IO separadas para el sistema operativo huésped y el HBA. Las colas hacia el sistema operativo huésped se combinan a partir de las colas hacia el adaptador SCSI virtual y el disco virtual:
La cola hacia el HBA depende del tipo/vendedor específico:
El rendimiento final de la máquina virtual estará determinado por el valor más bajo del límite de profundidad de cola (Queue Depth limit) entre los componentes del host.
Gracias a estos valores, se pueden evaluar los indicadores de rendimiento que podemos obtener en diferentes configuraciones. Por ejemplo, queremos conocer el rendimiento teórico de una máquina virtual (sin relación a la unidad) con una latencia de 0.5ms. Entonces, su IOPS = (1,000/latencia) * I/Os sobresalientes (límite de profundidad de cola)
Ejemplos
Ejemplo 1
- Adaptador HBA FC Emulex
- Una VM en el datastore
- Adaptador SCSI Paravirtual de VMware
Aquí, el límite de profundidad de cola está determinado por el HBA Emulex. Por lo tanto, IOPS = (1000/0.5)*32 = 64K
Ejemplo 2
- Adaptador de software iSCSI de VMware
- Una VM en el datastore
- Adaptador SCSI Paravirtual de VMware
Aquí, el límite de profundidad de cola ya está determinado por el Adaptador SCSI Paravirtual. Por lo tanto, IOPS = (1000/0.5)*64 = 128K
Los modelos de gama alta de matrices All Flash AccelStor (por ejemplo, ) son capaces de proporcionar un rendimiento de 700K IOPS en escritura con un bloque de 4K. Con este tamaño de bloque, es evidente que una sola máquina virtual no puede sobrecargar una matriz de este tipo. Se necesitarán 11 (para el ejemplo 1) o 6 (para el ejemplo 2) máquinas virtuales.
Como resultado, con la configuración adecuada de todos los componentes del centro de datos virtual descritos, se pueden obtener resultados bastante impresionantes en términos de rendimiento.
4K aleatorio, 70% lectura/30% escritura
De hecho, el mundo real es mucho más complejo para describirlo con una fórmula simple. En un host siempre hay muchas máquinas virtuales con diversas configuraciones y requisitos de E/S. Además, el procesador del host se encarga del manejo de la entrada/salida, cuya potencia no es infinita. Así, para aprovechar al máximo el mismo en realidad se necesitarían al menos tres hosts. Además, las aplicaciones que funcionan dentro de las máquinas virtuales hacen sus propias correcciones. Por lo tanto, para un dimensionamiento preciso, recomendamos de matrices All Flash dentro de la infraestructura del cliente en tareas actuales reales.
Fuente: habr.com
