Configuración de iScsi en una red L3 para una utilización eficiente de las capacidades de canal y almacenamiento / Sudo Null IT News
Después de probar NVME sobre TCP, como se describe aquí, decidimos comprobar qué tan bien funciona iScsi en una red L3 en comparación con una solución especializada en FC.
configuración iScsi
TL/DR
- name: Setup iScsi
ini_file:
dest: /etc/iscsi/iscsid.conf
no_extra_spaces: false
option: "{{item.name}}"
value: "{{item.value}}"
backup: no
loop:
- { name: "node.session.iscsi.InitialR2T" , value: "Yes" }
- { name: "node.session.cmds_max" , value: "256" }
- { name: "node.session.queue_depth" , value: "256" }
- { name: "node.session.nr_sessions" , value: "8" }
- name: Setup /etc/sysctl.conf
ansible.posix.sysctl:
name: "{{item.key}}"
value: "{{item.val}}"
loop:
- { key: net.ipv4.fib_multipath_hash_policy, val: "1 #iscsi"}
- { key: net.ipv4.fib_multipath_use_neigh, val: "1 #iscsi"}
- { key: net.ipv4.tcp_slow_start_after_idle, val: "0 #iscsi"}
Las velocidades alcanzadas de 12,3 GB/s en una red de 100 GB se consideran buenas.
Prueba inicial
Realizamos un volcado de una base de datos de productos para un día determinado, con varias horas de tráfico en ella.
En una plataforma prometedora con configuraciones de rutas múltiples recomendadas por el proveedor de almacenamiento, configuramos la conexión de varias docenas de LUN.
La configuración de iScsid se utilizó “lista para usar”
Transferimos los datos a la futura plataforma.
Empezamos a jugar al tráfico.
En los gráficos vimos que la utilización de la red alcanza solo el 50%.
Empezamos a descubrir por qué esto es así. Y qué se debe hacer para ocupar por completo el canal de la red.
Optimización a nivel de dispositivo
De forma predeterminada, Oracle Linux permite combinar varios comandos para leer y escribir en un dispositivo en uno solo.
Esto no era muy adecuado para algunos dispositivos, por lo que fue necesario desactivar la optimización para ellos.
ls -l /dev/mapper/*my_mask* | awk -F "-> ../" '{print $2}' | while read dev; do echo "$dev" ;echo 2 > /sys/devices/virtual/block/$dev/queue/nomerges; cat /sys/devices/virtual/block/$dev/queue/nomerges ;done
Analisis inicial.
Utilizando el DBMS, se lanzó la validación de la tabla, lo que generó una carga que alcanzó los 50 Gb/s y estableció récords de consumo de electricidad en el servidor.
htop mostró un alto porcentaje de espera en el kernel.
Decidimos mirar la configuración del iscsid.
Encontrado en él
################################
# session and device queue depth
################################
# To control how many commands the session will queue, set
# node.session.cmds_max to an integer between 2 and 2048 that is also
# a power of 2. The default is 128.
node.session.cmds_max = 128
# To control the device's queue depth, set node.session.queue_depth
# to a value between 1 and 1024. The default is 32.
node.session.queue_depth = 32
Se cambió la profundidad de node.session.queue_ Depth a 256.
Después de lo cual reiniciamos iscsid y repetimos la prueba con la validación de la tabla.
El consumo de CPU (y electricidad) se volvió normal y la velocidad aumentó a aproximadamente 75 Gb/s.
Otros aumentos en node.session.queue_ Depth no tuvieron ningún efecto, por lo que decidimos utilizar pruebas sintéticas para descubrir qué era necesario modificar. El objetivo final era cargar completamente la red con operaciones de disco.
Pruebas sintéticas
Se decidió realizar pruebas sintéticas utilizando FIO en una máquina de la misma configuración en cuanto a modelo y procesador. memoria, red en el mismo switch.
Para las pruebas ya había 48 discos con sistemas de almacenamiento, lo cual es un poco peor que en el soporte original con base, pero aceptable.
Los discos recibieron nombres a través de multipath.conf, bajo el cual eran visibles en /dev/mapper
Una línea de shell simple como esta
cat 1.txt | grep " ->" | awk -F">" '{print $2}' | tr "." "_" | awk '{print "\tmultipath {\n\t\twwid\t3"$3"\n\t\talias\t"$1"\n\t}"}'
Le permite crear rápidamente las líneas necesarias para la configuración /etc/multipath.conf.
'3' antes de '$3', en el cual wwid, esto es específico del protocolo
This issue has been explained in the man page of scsi_id:
– scsi_id queries a SCSI device via the SCSI INQUIRY vital product data (VPD) page 0x80 or 0x83 and uses the resulting data to generate a value that is unique across all SCSI devices that properly support page 0x80 or page 0x83.
– If a result is generated it is sent to standard output, and the program exits with a zero value. If no identifier is output, the program exits with a non-zero value.
– scsi_id is primarily for use by other utilities such as udev that require a unique SCSI identifier.
– By default all devices are assumed blacklisted, the –whitelisted option must be specified on the command line or in the config file for any useful behavior.
– SCSI commands are sent directly to the device via the SG_IO ioctl interface.
– In order to generate unique values for either page 0x80 or page 0x83, the serial numbers or worldwide names are prefixed as follows.
Identifiers based on page 0x80 are prefixed by the character ‘S’, the SCSI vendor, the SCSI product (model) and then the the serial number returned by page 0x80. For example:
# /lib/udev/scsi_id --page=0x80 --whitelisted --device=/dev/sda
SIBM 3542 1T05078453
Identifiers based on page 0x83 are prefixed by the identifier type followed by the page 0x83 identifier. For example, a device with a NAA (Name Address Authority) type of 3 (also in this case the page 0x83 identifier starts with the NAA value of 6):
Puedes montar un pequeño volumen de 48 piezas para realizar pruebas así:
ls -1 /dev/mapper/*testdata* | grep exp | xargs vgcreate vg_testdata
lvcreate -i 4 -I 64 -n testdata -l 100%FREE vg_testdata
Para nuestras pruebas utilizamos franjas de disco de 256k, respectivamente -I 256
Si no necesita construir LVM, pero solo necesita transferir las particiones que ocupan el 100% del disco bajo el control del DBMS, entonces puede crear la siguiente regla udev para ellas.
ENV{ID_PART_ENTRY_SCHEME}=="gpt", ENV{ID_PART_ENTRY_NAME}=="prefix*", ENV{DM_NAME}=="*p1", ENV{DM_NAME}=="*pattern*p1", OWNER="rdbmuser", GROUP="rdbmgroup", MODE="0660", SYMLINK+="prefix_disk/pattern_$env{DM_NAME}"
Las pruebas mismas
Una vez montado el stand, comenzamos a lanzar FIO, obteniendo cifras bastante estables, ejecutándose en una terminal paralela. sar -n DEV 3observando la distribución del tráfico entre los adaptadores, la reacción a la bajada de uno de 4x, 2x de 4x y el regreso de los adaptadores.
La distribución fue desigual.
Tenemos 2 tarjetas de doble puerto, el segundo puerto de cada una estaba subcargado.
Surgió la idea de verificar la configuración de consumo de energía en el BIOS. Allí no se seleccionó ningún perfil. Instalamos HPC.
La velocidad aumentó un poco.
Con el mismo espíritu, decidimos actualizar el firmware de las tarjetas de red al último FW estable. La velocidad no se vio afectada.
Decidimos descubrir cómo afecta la velocidad MTU 9000 en lugar de 1500.
La distribución entre adaptadores se ha vuelto más uniforme. Con solo cambiar la MTU recibimos un 2% de utilización adicional del canal. Entonces decidimos dejarlo.
No fue posible jugar con la configuración NUMA en el servidor de prueba.
pwd;cat en*np{0..1}/device/num*
/sys/class/net
-1
-1
-1
-1
Este paso de configuración se ha omitido.
Según las recomendaciones del fabricante, se configuraron 4 puertos en el sistema de almacenamiento. La configuración predeterminada de iscsid se basó en una ruta.
Empezamos a jugar con la cantidad de conexiones paralelas al puerto.
Para hacer esto, necesita restablecer la configuración existente para /var/lib/iscsi/nodes, reinicie iscsid, repita el registro mediante sendtargets. E inicie sesión en el sistema de almacenamiento.
No tiene sentido perder el tiempo aumentando el número de caminos. Cada ruta crea un dispositivo de bloque. Su número está limitado a 10 mil por una razón. Y a partir de cierto punto, la productividad empieza a decaer.
Paramos a las 8.
Resultó ser un camino de 4×8 hacia el dispositivo. En este caso, el tráfico comenzó idealmente a distribuirse uniformemente entre 4 tarjetas de red y tender a 100 Gb/s.
Para mejorar aún más la velocidad, dividimos nuestras unidades en varios grupos lógicos.
Discos para sistemas de archivos.
Discos para registros de bases de datos
Discos para datos de bases de datos.
Cada grupo de discos se suministraba desde sus 4 puertos al sistema de almacenamiento.
Finalmente logramos casi el 100% de carga de la red.
conclusiones
Después de pasar las primeras 2 semanas laborales completas de mayo en investigación (es decir, 5 días hábiles, pero las semanas son peores), recibimos configuraciones que demostraron ser 5 veces mejores que la infraestructura existente en FC.
Colocamos la matriz IOPS en pequeños bloques para escritura y lectura (1 millón de escrituras y 1,5 millones de lecturas)
Casi ponemos el rendimiento de la red en un bloque medio (12,3 Gb/s)
Registro
# fio --rw=write --bs=4k --numjobs=136 --iodepth=256 --size=10T --ioengine=libaio --direct=1 -group_reporting --name=jour
nal-test --filename=/dev/mapper/vg_exp_data-exp_data
journal-test: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=256
...
fio-3.19
Starting 136 processes
^Cbs: 136 (f=136): (W(136))(0.0%)(w=4575MiB/s)(w=1171k IOPS)(eta 04d:00h:33m:27s)
fio: terminating on signal 2
Lectura
# fio --rw=read --bs=4k --numjobs=136 --iodepth=256 --size=10T --ioengine=libaio --direct=1 -group_reporting --name=journ
al-test --filename=/dev/mapper/vg_exp_data-exp_data
journal-test: (g=0): rw=read, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=256
...
fio-3.19
Starting 136 processes
^Cbs: 136 (f=136): (R(136))(0.0%)(r=5731MiB/s)(r=1467k IOPS)(eta 02d:21h:33m:50s)
Bonificación: comparación con NVME sobre TCP
De repente quise comparar el rendimiento resultante con NVME.
Lo configuré de acuerdo con las instrucciones del artículo mencionado anteriormente.
Por supuesto, hice las pruebas en 1 disco.
La primera prueba estuvo limitada por la velocidad de este único disco.
Al darme cuenta de que la prueba era incorrecta, monté un volumen LVM de 4 discos NVME sobre TCP en la máquina local. En teoría, hay 128 conexiones para cada uno.
Pero con los parámetros de la prueba, que arrojaron 12,3 GB/s a través de iScsi, obtuve solo 9 GB/s
Conclusión
Quizás lo estemos haciendo todo mal. Si este es el caso, comparta en los comentarios sus recetas para utilizar eficazmente el ancho de banda de la red iScsi con el tráfico.
