Ahorramos en un controlador RAID, o cómo alimentar a Varia con Iops

En nuestra era de servicios en la nube, AWS Lambda y otro alojamiento compartido de recursos informáticos absolutamente intangibles, a veces quiero un poco propio. Además del deseo, a veces también es necesario modificar cuidadosamente uno u otro producto de software con costos mínimos de plataforma. Casi siempre puede encontrar algún exceso de equipo, a veces incluso resulta que todo se junta y se enciende. Si estos excedentes representan una CPU con al menos 4-6 núcleos y memoria de 64 GB, generalmente excelente, puede tomar ESXi y trabajar con cualquier cosa. Un problema: con una capacidad de disco en hardware doméstico en VMWare, absolutamente nada. El rendimiento de los discos duros individuales locales es bajo, y perder el contenido de un solo tornillo en el vacío en el siglo XXI es como un saludo. Intentemos conectar algo a través de la red.

TL; DR> asociación, equilibrio, límite de rr, eso es todo.

En realidad, el texto a continuación no trata sobre el hecho de que esto es generalmente posible o algún tipo de conocimiento. Internet está lleno de artículos para tontos (marque aquí, luego Siguiente, Siguiente, Listo) sobre cómo enviar una capacidad de disco iSCSI. Estoy escribiendo solo para excluir los "errores de los sobrevivientes" y compartir los momentos en que "todo saldrá mal" (y saldrá, Murphy tenía razón), y cuando intentas cargar la solución, simplemente falla.

Por lo tanto, intentaremos sofocar nuestro "hipervisor doméstico" con una matriz de discos externos conectados a través de la red. Dado que todo gira en torno a nosotros "a bajo costo", que sea FreeNAS y 4 discos SATA, que son atendidos por un mediocre porcentaje de 3 GHz de 45 nm. Observamos Ebay, y por dinero comparable a un controlador RAID usado, arrastran un par de tarjetas de red i350-T4 desde allí. Estos son adaptadores gigabit de cuatro puertos de Intel. Según ellos, asociaremos el almacenamiento con el hipervisor.

Cuenta un poco. La velocidad promedio de transferencia de datos de un disco SATA promedio es de 160-180 MB / s con un ancho de interfaz de 6 Gb / s. De hecho, la velocidad de transferencia de datos real del HDD no supera los 2 Gb / s. Esta no es una cifra tan grande, dado que planeamos comunicarnos en puertos de 4 gigabits (cómo convertir 4x1Gbps en 4Gbps, discutiremos más a fondo). Todo con velocidades de acceso aleatorio es mucho peor: aquí todo cae casi al nivel de los disquetes.


Dado que el perfil de carga de disco de muchos sistemas operativos invitados está lejos de ser lineal, me gustaría ver más números divertidos. Para corregir la situación en el sistema de archivos del hipervisor (VMFS v6), el tamaño del bloque es de 1 MB, lo que ayuda a compactar muchas operaciones aleatorias y acelera el acceso a los datos en discos virtuales. Pero incluso con esto, un disco físico no será suficiente para manejar las operaciones de E / S de todos los "invitados".

Haré una reserva de inmediato; todo tiene más sentido si tiene más de dos adaptadores para la "red de almacenamiento". ESXi con una licencia de uniprocesador gratuita puede conectarse, además de los discos locales, a dos tipos de almacenamiento: NFS e iSCSI. NFS implica acceso a nivel de archivo y también es bueno a su manera. En él, puede implementar invitados poco exigentes para el rendimiento del disco. Es un placer respaldarlos. puede abrir la misma bola NFS en otro lugar y copiar instantáneas vm. En general, con una interfaz de red (si no es 10GE, por supuesto): NFS es su elección.

ISCSI tiene varias ventajas sobre NFS. Para realizarlos completamente, ya nos hemos preparado, ya que hemos establecido 4 puertos gigabit para la red de almacenamiento. ¿Cómo suele ocurrir la expansión del ancho de banda de la red a una velocidad de interfaz conocida? Así es, agregación. Pero para la utilización completa del canal agregado, se necesitan varias condiciones, y esto es más adecuado para la comunicación entre conmutadores o para un enlace ascendente de red de un hipervisor. La implementación del protocolo iSCSI proporciona una función como múltiples rutas (literalmente, muchas rutas): la capacidad de conectar el mismo volumen a través de diferentes interfaces de red. Por supuesto, también existe la posibilidad de equilibrar la carga allí, aunque el objetivo principal es la tolerancia a fallas de la red de almacenamiento. (Para ser justos, NFSv4.1 admite el trunking de sesión basado en la magia más avanzada, como RDMA y MPTCP, pero este es un intento de cambiar los problemas de acceso a los archivos de un dolor de cabeza a uno saludable a niveles más bajos).

Entonces, para empezar, publicaremos nuestro objetivo. Creemos que FreeNAS está instalado, la dirección IP de administración nos envía regularmente la interfaz web, cortamos la matriz y zvol en ella de acuerdo con nuestras convicciones internas. En nuestro caso, esta es una unidad de 4 x 500GB combinada en raidz1 (que proporciona solo 1.3 TiB de capacidad efectiva), y zvol tiene exactamente 1 TB de tamaño. Configuraremos las interfaces de red i350, por simplicidad aceptamos que todos pertenecerán a diferentes subredes.


Luego configuramos la bola iSCSI utilizando el método "Siguiente, Siguiente, Listo". Al configurar el portal, no olvide agregar todas las interfaces de red dedicadas a iSCSI allí. Debería verse como en las fotos.



Deberá prestarse un poco más de atención para establecer la extensión: al presentar un volumen, es necesario forzar un tamaño de bloque de 512 bytes. Sin esto, el iniciador ESXi se negó a identificar los volúmenes presentados. En aras de la fidelidad, es mejor deshabilitar los tamaños de probros del bloque físico (que en zvol no es y no puede ser) y habilitar el modo de soporte Xen.
Con FreeNAS por ahora.

En el lado de ESXi, es un poco más difícil configurar una red. Nuevamente, creemos que el hipervisor mismo está instalado y también administrado en un puerto separado. Deberá seleccionar 4 interfaces de kernel VM que pertenezcan a 4 grupos de puertos diferentes en 4 conmutadores virtuales diferentes. Cada uno de estos conmutadores tiene su propio puerto físico de enlace ascendente. Tomamos las direcciones vmk #, por supuesto, en las subredes correspondientes, de manera similar a la configuración de los puertos de almacenamiento. El orden de configuración de las direcciones es, en general, importante: conectamos las tarjetas de puerto a puerto sin un conmutador, o le damos diferentes enlaces a diferentes redes (bueno, eso es de forma adulta), por lo que la coincidencia de puertos físicos es importante.




Al configurar una red para iSCSI, prestamos especial atención al parámetro MTU. Este es exactamente el caso cuando "el tamaño importa": tomamos el máximo que todos los componentes de la red pueden instalar. Si las tarjetas están conectadas directamente, puede apuntar el mtu 9000 en ambos lados, en ESXi y FreeNAS. Sin embargo, los interruptores normales admitirán este valor. Hacemos ping, vemos que la red es normal y pasan los paquetes del tamaño requerido. Genial Le prendimos fuego al iniciador.

Active iSCSI, agregue direcciones IP a la sección de configuración dinámica (Almacenamiento -> Adaptadores -> Configurar iSCSI -> Destinos dinámicos). Después de guardar, los portales iSCSI se sondearán en estas direcciones, el iniciador determinará que cada uno de ellos tiene el mismo volumen y se conectará a él en todas las direcciones disponibles (la misma ruta múltiple). A continuación, necesitamos crear un almacén de datos en el dispositivo que aparece.

Después de eso, puede implementar la máquina virtual y medir lo que tenemos.


No resultados tan impresionantes. Abra la consola de almacenamiento, muestre el estado actual de la red y ejecute las pruebas.

root@freenas:~ # systat -ifstat

Solo se ha utilizado uno de los cuatro puertos de red (igb1). Esto sucede porque el mecanismo de equilibrio proporcionado por defecto para múltiples rutas selecciona el mismo adaptador con cada paquete de datos. Necesitamos usar todo.
Estamos conectados al hipervisor a través de SSH y comando.
Primero, veamos qué ID tiene la luna con trayectos múltiples y cómo funciona:

[root@localhost:~] esxcfg-mpath -b
naa.6589cfc000000b478db42ca922bb9308 : FreeNAS iSCSI Disk (naa.6589cfc000000b478db42ca922bb9308)

[root@localhost:~] esxcli storage nmp device list -d naa.6589cfc000000b478db42ca922bb9308 | grep PSP
Path Selection Policy: VMW_PSP_MRU

La política de selección de ruta es MRU, es decir, la más recientemente utilizada. Todos los datos van al mismo puerto, la re-selección de la ruta ocurre solo cuando la conexión de red no está disponible. Cambiamos a round-robin, en el que todas las interfaces cambian a su vez después de un cierto número de operaciones:

[root@localhost:~] esxcli storage nmp device set -d naa.6589cfc000000b478db42ca922bb9308 -P VMW_PSP_RR

Reiniciamos ESXi, monitoreo abierto, ejecutamos pruebas. Vemos que la carga se distribuye uniformemente a través de los adaptadores de red (al menos valores pico, demasiado raspado), los resultados de la prueba también son más divertidos.

  Interface Peak igb3 in 43.233 MB/s out 46.170 MB/s igb2 in 42.806 MB/s out 45.773 MB/s igb1 in 43.495 MB/s out 45.489 MB/s igb0 in 43.208 MB/s out 46.079 MB/s 

Hay algunas desviaciones en los puertos, esto se debe a los límites de la Política de selección de ruta: el número de operaciones o bytes, después de lo cual se produce el cambio a otro puerto. Por defecto, 1000 IOPS, es decir, si el intercambio de datos está dentro de las 999 operaciones, pasará por un puerto de red. Puede cambiar, comparar y seleccionar el valor apropiado. No puede cambiar, el valor predeterminado es suficiente para la mayoría de las tareas.

Tomamos medidas, prueba, trabajo. Los resultados son significativamente superiores a las capacidades de un solo disco, por lo que ahora nuestras máquinas virtuales pueden no tener problemas en las operaciones de E / S. Las velocidades resultantes y la tolerancia a fallas de la matriz dependerán del hardware y de cómo esté configurado el volumen.