Almacenamiento compartido con LVM sobre iSCSI en Proxmox VE (Parte II)

Saludos nuevamente.

En la primera parte vimos cómo crear un Target iSCSI en un appliance de almacenamiento con NAS4Free, ahora corresponde mostrar cómo integrar este recurso a Proxmox VE como un nuevo almacenamiento compartido.

Entonces, sin más, manos a la obra.

Integración al Clúster Proxmox

Del lado de los iniciadores iSCSI, que serán los nodos del Clúster Proxmox, se utilizará el LUN que exporta el servidor NAS/SAN, pero no directamente, sino que será el dispositivo base de otro almacenamiento compartido: LVM.

Bueno, volviendo al tema, ya creado el Target iSCSI, se procede a añadirlo al clúster Proxmox de la siguiente manera:

Gestor de Proxmox —> Datacenter —> Storage —> Add —> iSCSI

Proxmox - Storage - iSCSI - 1

De ahí se muestra una nueva ventana…

Proxmox - Storage - iSCSI - 2

A la cual se le deben especificar valores a los siguientes parámetros:

ID: <ID del bloque>

Portal: <Nombre FQDN o dirección IP del servidor que contiene el Target iSCSI>

Target: <El dispositivo Target que exporta el servidor con el Target iSCSI>

Nodes: <Se deja tal y como está>

Enable: Sí (Activado)

Use LUNs directly: No (Desactivado)

NOTA: En el caso del valor del parámetro “Portal”, si se desea tener la seguridad de que no haya problemas para direccionar el LUN en el servidor que posee iSCSI Target, es mejor establecer la dirección IP y no el nombre FQDN, dado que puede fallar para casos en que el servidor o cabina NAS/SAN no sea un GNU/Linux tradicional o no se alcance el servidor DNS. Cabe destacar que el LUN previamente creado no se utilizará directamente en el clúster, sino que servirá como dispositivo base de un grupo de volúmenes LVM.

Entonces, todo quedaría así:

Proxmox - Storage - iSCSI - 3

Al pulsar el botón “Add” se añade el nuevo almacenamiento compartido en el clúster:

Proxmox - Storage - iSCSI - 4

Ahora bien, el nuevo dispositivo que se añadió será el disco base (como se dijo anteriormente) para el nuevo grupo de volúmenes LVM que se va a añadir:

Gestor de Proxmox —> Datacenter —> Storage —> Add —> LVM

Proxmox - Storage - LVM - 1

De ahí sale una nueva ventana…

Proxmox - Storage - LVM - 2

Donde también se le deben especificar varios valores:

ID: <ID del nuevo LVM>

Base storage: <Seleccionar el LUN iSCSI previamente añadido>

Base volume: <Seleccionar el dispositivo de bloques derivado de la configuración del LUN iSCSI previo>

Proxmox - Storage - LVM - 3

Volume group: <Nombre del nuevo grupo de volúmenes>

Nodes: <Dejarlo tal y como está>

Enable: Sí (Activado)

Shared: Sí (Activado)

Y todo quedaría de esta forma:

Proxmox - Storage - LVM - 4

Al pulsar el botón “Add” se añade el nuevo almacenamiento compartido LVM:

Proxmox - Storage - LVM - 5

Una vez completados estos pasos, ya se pueden crear nuevas máquinas virtuales en el nuevo almacenamiento compartido.

Aquí cabe destacar, una vez más, que la conectividad de red entre el servidor de almacenamiento y el clúster Proxmox debe tener un ancho de banda responsable (o sea, de 2, 4, 8, 10 Gbps o más) para evitar ralentizaciones o caídas en el rendimiento de las máquinas virtuales. Dicha conectividad puede ser a través dos variantes:

  • Canal de Fibra Óptica
  • Enlaces Infiniband (presentes mayoritariamente en Clústers de Alto Rendimiento, entre los que se encuentran los Clústers de Cálculo utilizados en universidades de prestigio y/o grandes empresas; las velocidades oscilan entre 20 y 56 GBps, o más)
  • Enlaces 10 Gbps sobre Ethernet (son tan caros como los canales de fibra óptica)
  • Enlaces Agregados de Ethernet (Bonding en los servidores y Trunking en los switches L2/L3) en caso de que el presupuesto no permita el uso de las variantes anteriores

 

Cabina SAN/NAS: Discos duros e Infraestructura de Red, algo importante a tener en cuenta

En la Lista de Distribución de Proxmox el usuario Gilberto Nuñes publicó un post donde planteaba que tenía un problema con el respaldo de las máquinas virtuales. La cuestión está en que, a pesar de que tiene una SAN IBM, la tasa de transferencia era lenta (varias horas le tomaba salvar una sola máquina virtual). ¿Cuál era el problema? Estaba usando un enlace a 1 Gbps. Evidentemente tenía un cuello de botella inmenso.

Esto hace que uno se detenga a pensar en el ancho de banda adecuado para esta parte de la infraestructura de servicios. Para nosotros, los pobres, a lo más que podemos aspirar es a  disponer de una cabina NAS/SAN de bajo costo (un servidor atiborrado de discos duros y dos o más tarjetas de red), se debe tener en cuenta que la velocidad de transferencia de la red siempre sea menor que la sumatoria de las velocidades de transferencia de los discos duros.

La siguiente lista muestra las equivalencias entre ancho de banda y tasa de transferencia de datos por red:

1 Mbps ≈ 128 KB/s

10 Mbps ≈ 1.25 MB/s

100 Mbps ≈ 12.5 MB/s

1 Gbps ≈ 128 MB/s

2 Gbps ≈ 256 MB/s

4 Gbps ≈ 512 MB/s

6 Gbps ≈ 768 MB/s

8 Gbps ≈ 1 GB/s

10 Gbps ≈ 1.25 GB/s

Por otro lado, los discos duros a los que podemos acceder son del tipo SATA I, II o III de 7.2K RPM (Revoluciones Por Minuto), los cuales no son discos rápidos como un SCSI o SAS que normalmente son de 10K o 15K RPM. La siguiente lista muestra las velocidades de transferencia de los discos SATA (tomado de Wikipedia):

SATA I —> 150 MB/s

SATA II —> 300 MB/s

SATA III —> 600 MB/s

La mayoría de las placas base actuales traen de 4 a 6 conectores SATA, donde se pueden conectar discos duros de 500 GB, 1 o 2 TB. La opción de ponerlos en modo RAID, ya sea por hardware o software, se deja a elección del administrador. En mi caso, me decanto por un RAID 1 (mirroring) o RAID 10 (stripping+mirroring), si dispongo de uno o varios pares de discos duros. Claro, eso no quiere decir que hay que olvidarse de los respaldos de la información. 🙂

Orden de inserción y eliminación de dispositivos de almacenamiento compartido

Como mismo se añaden dispositivos de almacenamiento en Proxmox, se pueden eliminar, pero hay que tener extremo cuidado en el orden en que se hace esto. En el ejemplo anterior, primero se añadió el dispositivo de bloques o LUN que exporta el Target iSCSI y luego se creó un grupo de volúmenes LVM sobre el LUN previamente añadido (usado como dispositivo base). Para eliminarlos se sigue el proceso inverso: eliminar primero el grupo de volúmenes LVM y luego su dispositivo base, el LUN del Target iSCSI. Si no se respeta este orden y se decide eliminar el LUN antes del LVM, Proxmox mostrará el siguiente error:

Proxmox - Storage - Delete Storage Error

Problema del No Multipathing de iSCSI

Hay que tener muy en cuenta un elemento en la configuración de los portales e iniciadores, y es la posibilidad de tener varias conexiones de red entre la SAN/NAS y los hipervisores. Si en la primera se configura el Target iSCSI para que escuche por todas las interfaces de red dedicadas a la transferencia de datos (en el ejemplo con NAS4Free por las interfaces em1 [10.0.0.3] y em2 [10.0.1.3]; en el ejemplo con Debian 7.0 por todas las interfaces de red configuradas) y permita a todas las subredes de iniciadores conectarse a las mismas (10.0.0.0/29 y 10.0.1.0/29), que es donde están también los hipervisores Proxmox (PRX-C0-1 con las direcciones IP 10.0.0.1 y 10.0.1.1; y PRX-C0-2 con las direcciones IP 10.0.0.2 y 10.0.1.2), durante la migración de las máquinas virtuales entre los nodos se pueden obtener efectos indeseados si no se configura en estos últimos el multipathing de iSCSI. Entre estos efectos está en que LVM detecta que hay duplicación de volúmenes físicos en dos o más discos duros (discos que están asociados a los portales iSCSI antes detectados durante la carga del servicio iSCSI Initiator). La siguiente imagen lo muestra:

Proxmox - Storage - LVM over iSCSI - PV Error

Como se ve, el sistema detectó que tanto en /dev/sdb como en /dev/sdc existe el mismo  identificador de volumen físico LVM, entonces emplea el tercer disco (/dev/sdc) y no el segundo disco (/dev/sdb). Esto provoca que existan lecturas/escrituras incorrectas de los discos duros de las máquinas virtuales (que no son más que volúmenes lógicos ubicados en el LVM sobre iSCSI) y estas terminen por explotar con su correspondiente pérdida de datos como se muestra en la imagen siguiente:

Proxmox - Storage - LVM over iSCSI - VM Explotando

Por lo tanto, si se configura correctamente el Target iSCSI (inicialmente con un solo camino, cosa no recomendable) se eliminan estos efectos indeseados y la migración de las máquinas virtuales entre los nodos ocurre sin problemas:

Proxmox - Storage - LVM over iSCSI - OK

En el caso de usar un Target iSCSI configurado en un servidor con Debian, basta con modificar las opciones de inicio del servicio en el archivo /etc/default/iscsitarget, o sea:

ISCSITARGET_OPTIONS=”–address=<Dirección IP que se pondrá a la escucha>”

Y hasta aquí este tema. La configuración del multipath en iSCSI se lo dejo de tarea para los que estén interesados. Se escuchan proposiciones.

😀

11 Comments

  1. darkend dice:

    Hector:
    He seguido de cerca este tema tuyo del manual de proxmox.
    Muy interesante y útil.
    ¿podrías enviarmelo al mail?

    walterco@giron.sld.cu

    1. Hector Suarez Planas dice:

      Saludos, Darkend.

      Gracias por su comentario.

      Bueno, los epígrafes del manual son los posts que he puesto en el blog, lo que hace que sea un poco grande. 🙂

  2. Rafael dice:

    Estimado, muchas grcaias!! he seguido paso a paso tus indicaciones y pude instalar un cluster de 3 nodos.

    Pero tengo una consulta, espero me puedas ayudar, cuando configuro el ISCSI y luego el LVM sobre el ISCSI y ejecuto el comando “vgdisplay” en los tres nodos, solo veo el VG en el nodo1 (coincide con el nodo desde el cual ternia abierta la consola web de administracion)…

    Es normal esto?, esto significa que las VMs solo estarian activas en un nodo al mismo tiempo, es decir, que no puedo tener 2 VMs en un nodo del cluster-HA, 2 en el otro y 1 en el tercero?, es mas bien un “activo-pasivo”?

    Gracias!!

    1. Hector Suarez Planas dice:

      Saludos, Rafael.

      Primero que todo, gracias por su comentario.

      El almacenamiento debe verse en todos los nodos del clúster, digo, si tiene ya el clúster armado y funcionando. No debe dar problemas.

      En el esquema de clustering de Proxmox VE todos los nodos están al mismo nivel. No obstante, puede configurar el HA de las VMs de la manera que desee, para ello crearon los grupos de recursos. Es sólo manipularlos a conveniencia.

      Espero le sirva. 🙂

  3. La_maquina_de_hacer_pajaros dice:

    Hola Hector, otra vez, Excelente post!
    tengo una duda, una vez que creamos el cluster del proxmox, al pasarle un disco iscsi, porque necesitamos que sea sobre lvm?

    saludos

    1. Hector Suarez Planas dice:

      Saludos, Sebastián.

      Porque se aprovecha la potencialidad del LVM en cuanto a alta disponibilidad y tolerancia a fallos. ¿Lograría Ud. lo mismo utilizando el LUN en bruto y poniéndole un sistema de archivos básico como… no sé… ext4 o XFS? 🙂

      Espero le sirva.

      1. La_maquina_de_hacer_pajaros dice:

        Siii, no tenia bien el concepto de lvm, pero ahora lo entendi. Gracias

  4. Virtualizando dice:

    Como separaste las red, de almacenamiento , por vlan ?

    1. Hector Suarez Planas dice:

      Saludos, otra vez.

      Por las dos vías se puede hacer. Incluso, he visto mucha literatura donde emplean Bonding + VLANs, y les funciona sin problemas.

      🙂

  5. iscsi o nfs dice:

    Hector, tengo una consulta, en una parte de tu tutorial citas:

    “Aquí cabe destacar, una vez más, que la conectividad de red entre el servidor de almacenamiento y el clúster Proxmox debe tener un ancho de banda responsable (o sea, de 2, 4, 8, 10 Gbps o más) para evitar ralentizaciones o caídas en el rendimiento de las máquinas virtuales. Dicha conectividad puede ser a través dos variantes:

    Canal de Fibra Óptica
    Enlaces Infiniband (presentes mayoritariamente en Clústers de Alto Rendimiento, entre los que se encuentran los Clústers de Cálculo utilizados en universidades de prestigio y/o grandes empresas; las velocidades oscilan entre 20 y 56 GBps, o más)
    Enlaces 10 Gbps sobre Ethernet (son tan caros como los canales de fibra óptica)
    Enlaces Agregados de Ethernet (Bonding en los servidores y Trunking en los switches L2/L3) en caso de que el presupuesto no permita el uso de las variantes anteriores”

    La pregunta es, que pasa en el caso de un servidor NFS, en ves de usar iscsi? si usamos un almacenamiento compartido NFS, para crear las maquinas, va a ser mas lento que iscsi?

    1. Hector Suarez Planas dice:

      Saludos, Sebastián.

      Como dije en el artículo, el ancho de banda es fundamental para obtener un buen rendimiento del lado de la SAN (almacenamiento). Ahora bien, el uso de NFS, iSCSI, GlusterFS, Ceph, etc., ya es según las necesidades y el objetivo del que lo vaya a implementar. Para el caso de NFS, con un buen enlace entre el servidor y los clientes, no se perciben ralentizaciones (esto basado en la experiencia de colegas míos que lo tienen implementado, dado que yo prefiero otro tipo de almacenamiento).

      Espero le sirva. 🙂

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *