Bajo rendimiento tanto iSCSI como AoE

Estamos buscando un almacenamiento de velocidad razonable. Debido al bajo presupuesto, decidimos usar objetivos de software iSCSI o AoE. Antes de cambiar nuestra infraestructura de producción, estamos haciendo algunas pruebas para elegir la mejor tecnología.

Para las pruebas usamos:

• Fujitsu Siemens RX200 S4 como objetivo
• Fujitsu Siemens RX200 S4 como iniciador
• NetGear gestionó el conmutador de 1 GB
• NIC incorporadas (Broadcom con TOE), NIC EdiMax, NIC Broadcom con TOE: todas de 1 GB
• el servidor de destino está utilizando un controlador QLogic con 6 unidades SATA WD Blue de 2 TB.
• Los sistemas operativos tanto objetivo como iniciador son Ubuntu 16.04 LTS con todas las actualizaciones. El interruptor está dedicado para fines de almacenamiento. Probamos enlaces y multirrutas.

Nuestro problema es la baja velocidad de lectura. Para las pruebas usamos ddun archivo de 40-100GB.

• La lectura y escritura local en un servidor de destino supera los 300 MB / s.
• escribir en el servidor por iSCSI o AoE supera los 200 MB / s, lo que nos satisface.
• la lectura desde el servidor siempre es de 95-99 MB / s.

Hemos intentado ietd, aoetools, LIO. Hemos utilizado enlaces de 2 NIC: balance-rr y LACP, múltiples rutas con rr. Marcos normales y jumbo usados. Finalmente, incluso hicimos una conexión directa de Ethernet entre el destino y el host (sin conmutador).

Todas las pruebas dan más menos los mismos resultados (por supuesto, usar NIC comunes sin TOE e iSCSI dieron 20-30% peores resultados).

Las pruebas de red con iperf mostraron transferencias de aproximadamente 200 MB / s (2 GBit). Ver el uso de NIC en el destino con bmon mostró la misma utilización de ambos dispositivos (cada uno de unos 50 MB / s para leer, unos 100 MB / s para escribir).

Como no tuvimos suerte, decidimos usar un tercer NIC (ambos lados, por supuesto). Los resultados fueron extraños:

• 2 NIC: 50 MB / s cada uno
• 3 NIC: 33 MB / s cada uno

¿Existe algún límite en el software de destino que deshabilita la salida superior a 1 GBit / s?

¿Qué hacemos mal?

Para obtener el máximo rendimiento del almacenamiento conectado iSCSI, debe usar Jumbo Frames y MPIO (no LACP). Se recomienda RDMA / iSER si puede hacer eso.

AOE (ATA sobre Ethernet) es viejo y es una mierda. Ya nos hemos librado de Coraid hace años. Estamos usando StarWind https://www.starwindsoftware.com/ como objetivo iSCSI desde hace bastante tiempo y StarWind nos pidió que migremos de Coraid a cualquier almacenamiento que podamos hacer.

En este momento, estamos muy bien con iSCSI proporcionado por StarWind y con Windows, ESX y SCST http://scst.sourceforge.net/ en Linux como iniciadores. Con RDMA / iSER lo hace hasta 10 Gbit, muy feliz hasta ahora.

Su expectativa sobre cómo funciona la agregación de enlaces Ethernet es incorrecta.

Todos los métodos de agregación que no sean balance-rr (es decir, todos los métodos cuyo modo> 0) no le proporcionan un mayor rendimiento de conexión única; más bien, aumentan el ancho de banda total disponible cuando se establecen múltiples conexiones desde / hacia los hosts afectados. En otras palabras, LAG / LACP no le dará ningún beneficio para este escenario de conexión única.

El único método de agregación que puede proporcionarle un rendimiento de sesión única mayor que el que normalmente puede tener en una sola interfaz es balance-rr , que distribuye los paquetes de forma circular. Había que establecer el balance-rr en tanto el iniciador y el destino. Sin embargo, una gran trampa es que esto depende en gran medida del interruptor.

De todos modos, si configura tanto el objetivo como el iniciador en balance-rr, conectar directamente las dos máquinas debería proporcionarle un mayor rendimiento. Si no, ¿puede publicar un iperfcon balance-rr y ambas máquinas conectadas directamente (sin interruptor)? Además, publique el ddcomando exacto que utilizó para la evaluación comparativa.

Nota: solo estoy hablando de iSCSI aquí. No tengo experiencia con AoE más allá de leer sobre él, y de todos modos no lo implementaría en ninguna infraestructura nueva (es bastante difunto).

No use balance-rr para otra cosa que no sean protocolos punto a punto muy específicos. Tiene un rendimiento horrible cuando se encuentra bajo casi cualquier tipo de carga del mundo real, y causa una gran cantidad de problemas de red (como MUCHA inquietud). Definitivamente no lo use con un interruptor.

Use MPIO sin ninguna unión en el lado del iniciador para lograr el equilibrio de carga y la tolerancia a fallas. Para asegurarse de que sus rutas no se "mezclen" enviando todo su tráfico por una sola ruta, coloque rutas individuales (NIC de gigabit entre el objetivo y el iniciador, en su caso) en subredes separadas.

Siéntase libre de vincular el lado objetivo con LACP por ruta (como en dos enlaces para dos rutas para un total de cuatro NIC, como ejemplo de configuración de puerto objetivo). Esto funciona muy bien y puede equilibrar múltiples conexiones de iniciador que usan las mismas rutas. También use marcos jumbo e iSER si es posible. El uso de LACP en el objetivo equilibrará las conexiones a cada ruta entre varias NIC.

Usar LACP en el iniciador solo será efectivo si está haciendo muchas conexiones de portal de destino con uso simultáneo (no es común para casi cualquier carga de trabajo). Incluso si implementara efectivamente LACP por ruta en el iniciador, rápidamente se convertiría en una pesadilla de cableado usar (por ejemplo) cuatro telas adicionales para cada caja. Si necesita más de ~ 2Gib / s de rendimiento para un solo iniciador, considere 10GiB / s ethernet.

La mayoría de las respuestas en AoE son totalmente incorrectas, contrafácticas y muestran una falta de conocimiento y experiencia de AoE. En primer lugar, no está difunto. CORAID es el proveedor detrás de AoE y se reiniciaron como "SouthSuite" mientras conservaban la marca CORAID. También son los mismos desarrolladores. Están haciendo nuevos productos y respaldan a la mayoría de los antiguos. También están impulsando el desarrollo de AoE, como lo muestran claramente sus listas de correo técnicas abiertas. Revise el sitio web, está todo actualizado y cuenta toda la historia en su página de historia.

Alguien dijo que AoE no se beneficiaría de los marcos jumbo y también estaba completamente equivocado. Fue compatible después de que se lanzó la versión 13 de 'vbladed'. Necesita ajustar su MTU para admitir el nuevo tamaño de cuadro, pero de lo contrario funciona muy bien.

iSCSI se ejecuta en la capa 5 del modelo OSI. Su transporte habitual es TCP. Eso le brinda cierta corrección de errores (debido a sumas de verificación en TCP) y le permite enrutar el tráfico sobre IP en la capa 3. Ahí es donde se detienen las ventajas de iSCSI. Su rendimiento en el mundo real es francamente horrible cuando realmente lo comparas con algo como FCP, AoE o FCoE. Te invito a google "comparación de rendimiento iscsi" para el espectáculo de terror.

Su problema de velocidad de lectura podría deberse a una configuración incorrecta de la red, apague el control de flujo y asegúrese de usar un búfer de socket lo suficientemente grande. Tampoco mencionó si su sistema de archivos subyacente se había ajustado para la captación previa de lectura o no. Según su escenario, eso podría ayudarlo mucho, pero tenga cuidado de no usarlo con ciertas bases de datos que exigen que se deshabilite el almacenamiento en caché.

La agregación 802.3ad no aumentará mucho el rendimiento de su flujo único, incluso en un escenario de operación por turnos. También complicará la configuración de su red y le dará un par de nuevas oportunidades para dispararse en el pie al no coincidir los intervalos de PDU o configurar mal su enlace Cisco VPC para admitir el estado activo-activo. No use LACP con AoE, déjelo manejar sus propias rutas múltiples y multiplexación. Las versiones posteriores de AoE manejan esto maravillosamente, y en la mayoría de los casos con más gracia que incluso FCP, ya que todo es automático. Los puertos Ethernet adicionales le brindan más ancho de banda y más resistencia. Si distribuye los puertos Ethernet del host y del iniciador en varios conmutadores, eso puede proporcionar aún más redundancia. No hay necesidad de configurar un modo de enlace. Además, no ejecute IP en las mismas interfaces que usa para AoE.

En resumen, no escuches a los detractores de AoE, dicen que no tienen mucha experiencia y solo están montando ondas cerebrales de moda. Evita la manada. Vaya a configurar una tienda de respaldo con captación previa ajustada a mano y probablemente verá que su rendimiento de lectura aumenta mucho. Elimine el uso de protocolos de agregación y ejecute gritos desde iSCSI. Una última cosa, dejar de usar 'dd' no es una gran prueba y está sujeta a malos efectos de almacenamiento en caché. Utilice una herramienta de referencia real como 'fio', 'iozone' o 'dbench'. Esos dan resultados mucho más confiables.

Sé que LACP es para múltiples conexiones. Probarlo fue un acto de desesperación :)

Todas las pruebas se realizaron con balance-rr y dos NIC.

Escribir en el destino iSCSI:
dd if = / dev / zero of = / mnt / zero.bin bs = 1M count = 2000
2000 + 0 przeczytanych recordów
2000 + 0 zapisanych recordów
2097152000 bytes (2,1 GB, 2,0 GiB) copiados , 10,1093 s, 207 MB / s

Lectura del objetivo iSCSI:
dd if = / mnt / zero.bin of = / dev / null bs = 1M
2000 + 0 przeczytanych recordów
2000 + 0 zapisanych recordów
2097152000 bytes (2,1 GB , 2,0 GiB) copiado, 16,1684 s, 130 MB / s

Velocidad de red:
iperf -c 172.16.10.80
------------------------ ------------------------------------
Cliente que se conecta a 172.16.10.80, puerto
TCP 5001 Tamaño de ventana TCP: 325 KByte (predeterminado)
--------------------------------------------- ---------------
[3] 172.16.10.70 puerto local 37024 conectado con 172.16.10.80 puerto 5001
[ID] Intervalo Transferencia Ancho de banda
[3] 0.0-10.0 seg 2.30 GBytes 1.98 Gbits / seg Las

pruebas con marcos iperf y jumbo dieron los mismos resultados.

He ganado algo de velocidad de lectura al ejecutar el iniciador:
hdparm -a 2048 / dev / dm-1
Anteriormente era 256 y la velocidad de lectura era de 96 MB / s
Mi objetivo es lograr una velocidad de lectura de aproximadamente 200 MB / s.

EDITAR:
1. No usamos LACP - fue una prueba única.
2. Las pruebas con balance-rr y MPIO dan exactamente los mismos resultados. La ruta múltiple se probó con NIC en diferentes subredes.
3. Agregar más NIC no aumenta la velocidad de lectura, sino que solo reduce la utilización de cada NIC.
4. Creemos que el problema es una limitación (controlador, módulo?) Que no permite leer más rápido. Pero no estoy seguro, si es el objetivo o el lado del iniciador.


EDIT 2: acabo de hacer una prueba adicional: configuré el mismo host como objetivo e iniciador para deshacernos de los problemas de hardware de red. Me sorprendió: ¡exactamente la misma velocidad de lectura! 130 MB / s! La escritura es de 227 MB / s.

¿Cómo ha configurado sus nic? ¿Están todos los buffers configurados correctamente? ¿Ha asignado suficiente memoria RAM a los buffers de red? tampoco use la vinculación aquí, puede usar 2 canales iscsi y multirrutas en el iniciador, lo mismo con ATAoE, las multirrutas del iniciador a través de la plataforma y la ID de lun en cualquier ruta.