Servidor SAN con iSCSI para el centro

per Victor Carceler — darrera modificació 2020-04-06T11:20:33+01:00

A raíz de un crédito de síntesis (realizado por Miguel Ángel García, Òscar Molina y Carlos Olmo) se ha completado la instalación de un servidor SAN para el centro. La nueva máquina exporta discos iSCSI a las aulas donde es posible:

  • Arrancar el ordenador desde un target iSCSI sin utilizar ningún medio local
  • Utilizar un SO arrancado localmente para acceder a targets iSCSI (por ejemplo para /home)
  • Utilizar una herramienta de virtualización (VirtualBox o KVM con virt-manager) para acceder a imágenes proporcionadas por el servidor SAN

Gracias a que en el servidor se utiliza Btrfs para respaldar los ficheros imagen exportados se cuenta con:

  • Almacenamiento basado en un pool de dispositivos
  • Tolerancia a fallos al utilizar una configuración Btrfs (-m, -d) equivalente a un nivel RAID con redundancia
  • Copy on write para clonar ficheros imagen con eficiencia de almacenamiento
  • Snapshots de subvolúmenes
  • Compresión transparente opcional

 

Introducción a SAN: Storage Area Network

En un ordenador personal los medios de almacenamiento acostumbran a ser locales, es decir están directamente conectados al ordenador mediante alguna interfaz como: SATA, ATA, SCSI, SAS. Es una configuración simple y que proporciona un buen rendimiento pero obliga a actuar sobre cada una de las máquinas (que tienen sus propios discos) para instalar software como el sistema operativo y las aplicaciones o realizar backups. Además no es fácil conseguir un buen aprovechamiento de los discos pues mucha información que está copiada localmente es común a diferentes máquinas y el espacio libre disponible en una máquina no es aprovechable desde otra. A esta configuración le corresponde el acrónimo DAS (Direct Attached Storage).

Los sistemas de archivos de red (NFS, SMB/CIFS y otros) permiten que un servidor exporte un sistema de archivos a través de la red para que los clientes lo puedan montar y tratar con un sistema de archivos local. En este caso se acaba centralizando el almacenamiento en un servidor (lo que permite un mayor aprovechamiento del espacio y facilidad para compartir información o realizar copias de seguridad) pero el ordenador cliente solo puede acceder al espacio remoto a través del sistema de archivos de red utilizado. Es decir, no puede ver el equivalente a un dispositivo de almacenamiento físico local. No es posible, por ejemplo, hacer particiones sobre el recurso montado o configurar un RAID. Pues se trata de un sistema de archivos no de un dispositivo de bloques. A esta configuración le corresponde el acrónimo NAS (Network-attached Storage).

Finalmente la tecnología SAN (Storage Area Network) permite que un servidor exporte a través de la red discos que los clientes ven como dispositivos físicos locales. De manera que pueden realizar cualquier acción sobre estos discos como particionarlos, configurar un RAID o utilizar el sistema de archivos que deseen. En este caso la red no transporta primitivas de un sistema de archivos sino primitivas de acceso al dispositivo de bloques, en concreto del protocolo SCSI para el caso de iSCSI.

Fuente: http://upload.wikimedia.org/wikipedia/commons/9/9f/CompSAN.GIF

El estándar de alto rendimiento para la tecnología NAS es Fibre Channel, pero iSCSI (que transporta el protocolo SCSI sobre TCP/IP) ha ganado mucha popularidad gracias a que permite desplegar una solución SAN sobre hardware común con la reducción de costes que esto supone. Existe otro protocolo, AoE (ATA over Ethernet), que transporta comandos ATA sobre una red Ethernet (sobre sus tramas, no utiliza TCP/IP y por lo tanto no es enrutable) pero es una solución mucho menos extendida.

Introducción a iSCSI

Como he explicado iSCSI transporta comandos SCSI sobre TCP/IP, por lo tanto se puede utilizar en cualquier red tanto LAN como WAN pues es enrutable, aunque debido a las limitaciones impuestas por la latencia, ancho de banda disponible y probablemente de seguridad su uso habitual se ve limitado a redes LAN.

El protocolo iSCSI es completamente independiente de la tecnología física de red utilizada y puede ser utilizado sobre hardware común. Claro está que en un entorno de alto rendimiento se utilizará una red independiente para la SAN, pero en nuestro centro se utiliza la única red física existente (eso sí, segmentada en VLANs) que además es heterogénea y cuenta tanto con conmutadores GigabitEthernet como FastEthernet. Pese a todo el rendimiento, fuera del momento puntual en el que se arrancan a través de la red todas las máquinas de un aula, es satisfactorio.

En la terminología iSCSI conviene saber que se llama:

  • TARGET: al disco exportado por un servidor NAS. Cada target representa un dispositivo SCSI tradicional y puede tener dentro todas las particiones que se deseen crear. Para referirse a un target se utiliza un IQN.
  • INITIATOR: al componente que inicia el acceso a un target. El iniciador será la capa de software que se ejecuta en un cliente y accede a uno o más target.
  • IQN (iSCSI Qualified Name): el nombre que permite identificar a un target, existen otros formatos de referencia alternativos (EUI y NAA) pero están menos extendidos. Un IQN típico tiene el siguiente formato: iqn.2012-05.net.xeill.elpuig:KVM-FreeBSD9.img

 

En GNU/Linux, así como en otros sistemas operativos, existe software tanto para implementar el servidor como el cliente. Respecto al servidor la solución utilizada en el crédito de síntesis ha sido iSCSI Enterprise Target. Una solución que ha gozado de relativa popularidad e implementa un servidor iSCSI en el espacio de usuario, su fichero de configuración principal tiene una sintaxis sencilla. En la versión 2.6.38 de Linux se incluyó LIO Target, una solución SAN multiprotocolo (iSCSI, Fibre Channel, FCoE e InfiniBand) que forma parte del propio núcleo. LIO Target se administra desde el espacio de usuario (con la herramienta targetcli) a través de configfs. Es una solución más moderna y probablemente con más futuro pero en Ubuntu no ha estado disponible de serie hasta la versión 12.04LTS lo que excusa su uso en el crédito de síntesis.

Yo he probado mínimamente ambas soluciones y pese a las diferencias filosóficas de administración ambas parecen funcionar bien pese a haber detectado una pequeña incompatibilidad al acceder a iSCSI Enterprise Target desde el iniciador integrado en el VirtualBox que viene en Ubuntu 12.04LTS. Cuando se utiliza LIO Target no hay ningún problema con dicho VirtualBox. En los demás casos iSCSI Enterprise Target ha funcionado bien.

En ambos servidores se pueden escoger distintas opciones de almacenamiento para respaldar los targets exportados: ficheros imagen, dispositivos de bloques virtuales como volúmenes lógicos de LVM2 o dispositivos físicos (un disco o partición).

En el caso de nuestra aplicación particular, al utilizar Btrfs, la opción más cómoda ha sido utilizar ficheros imagen. Basta con crear un fichero disperso (por ejemplo con truncate -s 40G fedora17-x86_64.img) que pese a la apariencia de contener cierta cantidad de información inicialmente no consume espacio y solo lo hará en la medida en la que se escriba en su interior al realizar la instalación del sistema operativo. Una vez instalado, gracias al mecanismo COW de Btrfs es posible realizar clones que únicamente consumirán espacio al realizar cambios. En Btrfs se puede sacar partido de COW al clonar un subvolumen o bien símplemente un fichero al realizar una copia con el parámetro --reflink="always" (cp --reflink="always" fichero_origen fichero_clonado). Así, una vez obtenida una imagen maestra es posible desplegarla para un grupo de alumnos con gran eficiencia. De hecho, en el crédito de síntesis que menciono se han escrito tres scripts que permiten desplegar (y redesplegar) y quitar una imagen para un grupo o alumno. Al desplegar una imagen, por ejemplo para un grupo de alumnos, se realizan los clones y se modifica la configuración del servidor para exportar los nuevos targets.

Arranque en red

Una de las aplicaciones más vistosas de la tecnología SAN puede ser el arranque de un ordenador sin utilizar los medios de almacenamiento locales. Es decir, utilizar durante el arranque un sistema operativo que está instalado en un target iSCSI.

Para poder arrancar un ordenador personal a través de la red se suele utilizar PXE (Preboot eXecution Environment) para descargar utilizando TFTP la imagen de un núcleo (con su initramfs) y posteriormente montar el sistema de archivos raíz a través de NFS. El firmware de algunas tarjetas de red servidor incluye su propio iniciador iSCSI, aunque esta no es una opción en el hadware económico que tenemos en las aulas.

Por ello, para poder arrancar un disco iSCSI se ha utilizado un componente extra: iPXE. Esta implementación libre de PXE permite acceder a targets iSCSI (también soporta arranque AoE, FCoE o incluso HTTP) y se puede cargar de multitud de maneras diferente. En nuestra aplicación se descarga desde el servidor mediante TFTP.

Una de las buenas características que tiene iPXE es que soporta una configuración dinámica del menú de arranque. Es posible realizar scritps que controlan el menú de opciones presentado al usuario y es posible descargar dicho script mediante una conexión HTTP. Así que por ejemplo, podemos tener una página PHP que genere dinámicamente el script de iPXE en función del día, la hora, o la IP desde la que se hizo la solicitud para mostrar unas u otras opciones de arranque.

Resumiendo, la secuencia de arranque quedaría así:

  1. Al seleccionar en la BIOS o el firmware de nuestra tarjeta de red el arranque en red se realiza una petición DCHP.
  2. El servidor DHCP realiza una concesión en la que también proporciona la dirección de un servidor TFTP.
  3. En lugar de descargarse el núcleo del sistema a arrancar, del servidor TFTP se descarga la imagen de iPXE.
  4. iPXE vuelve a realizar una petición DHCP para configurar su interfaz.
  5. iPXE realiza una petición HTTP a una página web PHP desde la que se descarga el script que controla el menú que se presenta al usuario.
  6. iPXE, una vez que el usuario selecciona una de las opciones de arranque, monta el target iSCSI y arranca (el gestor de arranque que está instalado en dicho target).
  7. El gestor de arranque, normalmente GRUB2, presenta sus propias opciones y acaba cargando un núcleo con su initramfs.
  8. Una vez que ha sido cargado en memoria y comienza la ejecución del núcleo, este debe montar su sistema de archivos raíz. Así que debe ser posible montar la raíz a través de iSCSI.
  9. Finalmente se ejecutan los scripts de arranque, o systemd, y se carga el resto del SO.

 

La configuración del DHCP para el aula debe incluir las directivas que están marcadas con el comentario SAN BOOT iSCSI:

        # STALLMAN
        subnet 192.168.11.0 netmask 255.255.255.0 {
                option routers 192.168.11.8;
                option domain-name "asi2.puigcastellar.";
                option domain-name-servers 192.168.11.8;

                range 192.168.11.101 192.168.11.200;
                allow unknown-clients;

                # SAN BOOT iSCSI
                next-server 192.168.11.12; # TFTP
                if exists user-class and option user-class = "iPXE" {
                        filename "http://192.168.11.12/menu.php";
                }
                else {
                        filename "undionly.kpxe";
                }
        }

Es importante aclarar la función del condicional, sirve para evitar un bucle infinito en el que PXE descargaría iPXE que descagaría iPXE que descargaría... En la primera petición se indica el nombre de la imagen iPXE a descargar, pero en las siguientes se accede a la URL que determina el menú a mostrar.

La instalación del sistema operativo en el target iSCSI maestro podría considerarse tricky. Hay diversos métodos, pero el que mejor resultado práctico ha dado con F17 de los que hemos probado ha sido:

  1. Exportar un target vacío para realizar la instalación
  2. Desconectar los discos duros locales del ordenador en el que se realizará la instalación (para que no aparezcan en la pantalla de particionado ni generen confusión a la hora de instalar el gestor de arranque en el MBR)
  3. Colocar el DVD de instalación de F17 en el ordenador
  4. Arrancar el ordenador con iPXE y utilizar el comando sanboot iscsi:hyarmen::::iqn.2012-05.net.xeill.elpuig:fedora-17-x86_64 para conectar (Hyarmen es el nombre DNS de nuestro equipo, se puede utilizar la IP), e intentar arrancar, con el target iSCSI. Como el target no tiene SO falla y una vez establecida la conexión el ordenador pasa a arrancar desde el DVD.
  5. En la pantalla de particionado hay que escoger la opción de utilizar dispositivos SAN iSCSI. Se mostrará el target con el que se conectó inicialmente y se podrá realizar la instalación con normalidad.

Una vez completada la instalación en el servidor se podrá clonar el target para diferentes usuarios. Y utilizarlos para arrancar mediante iPXE ordenadores que cuentan con sus propios discos duros locales, pero no son necesarios aunque podría accederse a ellos.

Cuando se realiza una instalación master sobre iSCSI, al desplegarla nos podemos encontrar con los siguientes inconvenientes:

  1. Si los equipos son de diferente modelo y por tanto el hardware es distinto, algunos sistemas operativos requerirán una instalación propia para cada modelo de equipo pues durante la instalación se utilizan drivers específicos. No es el caso de GNU/Linux en el que si el hardware está soportado se utiliza cuando está disponible.
  2. La configuración de red también puede impedir desplegar una imagen master en diferentes aulas. En nuestro centro mantenemos una VLAN con una subred propia para cada aula. Así en el aula STALLMAN se utiliza la VLAN 10 con direcciones pertenecientes a 192.168.10.0/24 en la que el servidor SAN tiene la IP 192.168.10.12. En el aula TORVALDS se utiliza la VLAN 11 con la subred 192.168.11.0/24 y así sucesivamente. Si durante la instalación del sistema operativo queda configurado para montar la raíz desde un target ofrecido por 192.168.10.12 fallará al intentar arrancar desde otra VLAN. Esto ocurre en F17.
  3. Finalmente algunas distribuciones como Ubuntu 12.04LTS durante la instalación dejan apuntado el iqn del target utilizado. Y después, al clonar la imagen y pretender arrancar con otro target, el núcleo persiste en montar como raíz el target original. Con lo que la ventaja de realizar una instalación, clonarla y utilizar los clones de manera independiente se pierde. Esto se trata de un comportamiento conocido y no deseado de la instalación de esta versión de GNU/Linux sobre iSCSI, aún así es posible sortear el problema con  algo de trabajo:
    1. Realizar una instalación master
    2. Realizar un backup de la imagen instalada
    3. Arrancar con el master y editar el fichero /etc/iscsi/iscsi.initramfs, para cambiar la línea ISCSI_TARGET_NAME = "iqn.2012-05.net.xeill.elpuig:ficheroimagen" a lo que corresponda.
    4. Utilizar dicha imagen como master para un alumno y repetir el proceso, con el backup de la imagen master, para cada uno de los otros alumnos

 

Iniciador iSCSI

El componente que inicia el acceso a un target iSCSI recibe el nombre de iniciador. En GNU/Linux el más común es Open-iSCSI. En Ubuntu 12.04LTS basta con instalar los paquetes open-iscsi y open-iscsi-utils para poder utilizarlo.

  1. Se pueden descubrir los targets disponibles en un servidor: 
    root@ubuntu:~# iscsiadm --mode discovery --type sendtargets --portal 10.0.2.15
    10.0.2.15:3260,1 iqn.2003-01.org.linux-iscsi.ubuntu.i686:sn.1273106e1d4c
    192.168.100.1:3260,1 iqn.2003-01.org.linux-iscsi.ubuntu.i686:sn.79c53121fcb7
    10.0.2.15:3260,1 iqn.2003-01.org.linux-iscsi.ubuntu.i686:sn.b003ce55ed2c
    root@ubuntu:~#
  2. Realizar login en uno de ellos: 
    root@ubuntu:~# iscsiadm --mode node --targetname iqn.2003-01.org.linux-iscsi.ubuntu.i686:sn.1273106e1d4c --portal 10.0.2.15 --login
    Logging in to [iface: default, target: iqn.2003-01.org.linux-iscsi.ubuntu.i686:sn.1273106e1d4c, portal: 10.0.2.15,3260]
    Login to [iface: default, target: iqn.2003-01.org.linux-iscsi.ubuntu.i686:sn.1273106e1d4c, portal: 10.0.2.15,3260]: successful
    root@ubuntu:~#
  3. Utilizarlo: 
    root@ubuntu:~# dmesg | tail
    [ 2244.845756] scsi 4:0:0:0: Direct-Access     LIO-ORG  FILEIO           4.0  PQ: 0 ANSI: 5
    [ 2244.859985] sd 4:0:0:0: Attached scsi generic sg3 type 0
    [ 2244.882711] sd 4:0:0:0: [sdc] 10485761 512-byte logical blocks: (5.36 GB/5.00 GiB)
    [ 2244.914735] sd 4:0:0:0: [sdc] Write Protect is off
    [ 2244.914766] sd 4:0:0:0: [sdc] Mode Sense: 2f 00 00 00
    [ 2244.924597] sd 4:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
    [ 2245.478231]  sdc: sdc1 sdc2 sdc3
    [ 2245.510759] sd 4:0:0:0: [sdc] Attached SCSI disk
    [ 2246.970267] TARGET_CORE[iSCSI]: Unsupported SCSI Opcode 0x85, sending CHECK_CONDITION.
    [ 2246.976672] TARGET_CORE[iSCSI]: Unsupported SCSI Opcode 0x85, sending CHECK_CONDITION.
    root@ubuntu:~#
    
root@ubuntu:~# fdisk /dev/sdc

AVISO: GPT (Tabla de partición GUID) detectado en '/dev/sdc'! La utilidad fdisk no soporta GPT. Use GNU Parted.


Orden (m para obtener ayuda): p

Disco /dev/sdc: 5368 MB, 5368709632 bytes
256 cabezas, 63 sectores/pista, 650 cilindros, 10485761 sectores en total
Unidades = sectores de 1 * 512 = 512 bytes
Tamaño de sector (lógico / físico): 512 bytes / 512 bytes
Tamaño E/S (mínimo/óptimo): 512 bytes / 524288 bytes
Identificador del disco: 0x00000000

Dispositivo Inicio    Comienzo      Fin      Bloques  Id  Sistema
/dev/sdc1   *           1    10485760     5242880   ee  GPT

Orden (m para obtener ayuda): d
Se ha seleccionado la partición 1

Orden (m para obtener ayuda): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Número de partición (1-4, valor predeterminado 1): 
Se está utilizando el valor predeterminado 1
Primer sector (2048-10485760, valor predeterminado 2048): 
Se está utilizando el valor predeterminado 2048
Último sector, +sectores o +tamaño{K,M,G} (2048-10485760, valor predeterminado 10485760): 
Se está utilizando el valor predeterminado 10485760

Orden (m para obtener ayuda): w
¡Se ha modificado la tabla de particiones!

Llamando a ioctl() para volver a leer la tabla de particiones.
Se están sincronizando los discos.
root@ubuntu:~# mkfs.jfs /dev/sdc1 
mkfs.jfs version 1.1.15, 04-Mar-2011
Warning!  All data on device /dev/sdc1 will be lost!

Continue? (Y/N) Y
   \

Format completed successfully.

5241856 kilobytes total disk space.
root@ubuntu:~#
  4. Y, cuando ya no sea necesario, realizar logout del target 
    root@ubuntu:~# iscsiadm --mode node --targetname iqn.2003-01.org.linux-iscsi.ubuntu.i686:sn.1273106e1d4c --portal 10.0.2.15 --logout
    Logging out of session [sid: 1, target: iqn.2003-01.org.linux-iscsi.ubuntu.i686:sn.1273106e1d4c, portal: 10.0.2.15,3260]
    Logout of [sid: 1, target: iqn.2003-01.org.linux-iscsi.ubuntu.i686:sn.1273106e1d4c, portal: 10.0.2.15,3260]: successful
    root@ubuntu:~#

De este modo es posible acceder con gran facilidad a un target para utilizarlo como una partición (tal vez para /home) local.

Un caso al que merece la pena prestar atención especial es a la combinación de virtualización con almacenamiento basado en iSCSI. Por supuesto un servidor iSCSI puede servir para centralizar las imágenes de las máquinas virtuales, además al utilizar en el servidor Btrfs se obtienen las ventajas propias del copy on write. Pero es que además, en la medida que los sistemas de virtualización abstraen al sistema huésped de los detalles del anfitrión se puede utilizar con cualquier SO.

Pongamos por caso Haiku, aunque el ejemplo sirve con cualquier otro SO como FreeBSD. Es posible crear un nuevo target vacío en el servidor. Utilizar un sistema de virtualización como Virtual Box o VirtManager (QEMU/KVM) para crear una nueva máquina virtual que utilice el nuevo target como disco duro. Realizar la instalación del sistema operativo en la máquina virtual, de modo que el huésped observa un disco duro convencional y una red virtualizada. Clonar la imagen del disco duro y ofrecer un target diferente a cada alumno con el sistema operativo instalado en su interior. En este caso el sistema operativo huésped no precisa ningún soporte de iSCSI y además, puesto que la herramienta de virtualización presenta la misma red, se puede utilizar la máquina virtual en cualquier aula con independencia de su VLAN.