Servidor SAN con iSCSI para el centroA 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 NetworkEn 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.

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 iSCSIComo 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 contruncate -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 redUna 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 iSCSIEl 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.1510.0.2.15:3260,1 iqn.2003-01.org.linux-iscsi.ubuntu.i686:sn.1273106e1d4c192.168.100.1:3260,1 iqn.2003-01.org.linux-iscsi.ubuntu.i686:sn.79c53121fcb710.0.2.15:3260,1 iqn.2003-01.org.linux-iscsi.ubuntu.i686:sn.b003ce55ed2croot@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 --loginLogging 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]: successfulroot@ubuntu:~#

3. Utilizarlo:

4. 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:~#

5. root@ubuntu:~# fdisk /dev/sdc6.7. AVISO: GPT (Tabla de partición GUID) detectado en '/dev/sdc'! La utilidad

fdisk no soporta GPT. Use GNU Parted.8.9.10. Orden (m para obtener ayuda): p11.12. Disco /dev/sdc: 5368 MB, 5368709632 bytes13. 256 cabezas, 63 sectores/pista, 650 cilindros, 10485761 sectores en total14. Unidades = sectores de 1 * 512 = 512 bytes15. Tamaño de sector (lógico / físico): 512 bytes / 512 bytes16. Tamaño E/S (mínimo/óptimo): 512 bytes / 524288 bytes17. Identificador del disco: 0x0000000018.19. Dispositivo Inicio Comienzo Fin Bloques Id Sistema20. /dev/sdc1 * 1 10485760 5242880 ee GPT21.22. Orden (m para obtener ayuda): d23. Se ha seleccionado la partición 124.25. Orden (m para obtener ayuda): n26. Partition type:27. p primary (0 primary, 0 extended, 4 free)28. e extended29. Select (default p): p30. Número de partición (1-4, valor predeterminado 1): 31. Se está utilizando el valor predeterminado 132. Primer sector (2048-10485760, valor predeterminado 2048): 33. Se está utilizando el valor predeterminado 204834. Último sector, +sectores o +tamaño{K,M,G} (2048-10485760, valor

predeterminado 10485760): 35. Se está utilizando el valor predeterminado 1048576036.37. Orden (m para obtener ayuda): w38. ¡Se ha modificado la tabla de particiones!39.40. Llamando a ioctl() para volver a leer la tabla de particiones.41. Se están sincronizando los discos.

42. root@ubuntu:~# mkfs.jfs /dev/sdc1 43. mkfs.jfs version 1.1.15, 04-Mar-201144. Warning! All data on device /dev/sdc1 will be lost!45.46. Continue? (Y/N) Y47. \48.49. Format completed successfully.50.51. 5241856 kilobytes total disk space.

root@ubuntu:~#

52. 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 --logoutLogging 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]: successfulroot@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.

http://elpuig.xeill.net/Members/vcarceler/articulos/servidor-san-con-iscsi-para-el-centro

Seguro que las medianas empresas han descubierto iSCSI. Dickinson Wright, PLLC, un bufete de abogados de Michigan, optó por el iSCSI después de que este bufete en continuo crecimiento quedara descontento con DAS (direct-attached storage). "Digamos que era sencillo pero propenso a fallos de disco," explica Alan Hunt, director

de operaciones. El bufete optó por una SAN (storage area network) iSCSI de EqualLogic (ahora Dell Inc.), con 70 TB de capacidad en bruto. La SAN iSCSI resultó ser fácil de instalar y no tenía ningún problema de mantenimiento, lo cual animó al bufete a instalar una SAN SCSI en cada una de sus siete delegaciones y duplicarlas entre ellas para hacer copias de seguridad.

eDirect Impact Inc., Montgomery, TX, un proveedor de servicios especializado en detección electrónica (eDiscovery), ha reunido 100TB de almacenamiento iSCSI y está en proceso de duplicarlo a 200 TB. "El año que viene, podríamos alcanzar 300TB," comenta Sami Rahman, consejero delegado. La compañía ensambló su SAN iSCSI usando una cabeza SAN Reldata con un array de discos InforTrend. La cabeza Reldata también recogía varios JBOD capacity que la compañía ya tenía.

"Lo que nos gusta de iSCSI es su flexibilidad. No nos exigía cambiar nuestra infraestructura. Tampoco queríamos añadir más tecnología como FC [Canal de fibra]. Simplemente deseábamos usar lo que ya teníamos. E iSCSI nos da un buen rendimiento," explica Rahman.

AmeriVault Corp., Waltham, Massachusetts, un proveedor de copias de seguridad remotas, optó por iSCSI cuando decidió ofrecerles a los clientes una opción más barata a un nivel de servicio inferior. ""Si íbamos a ofrecer un servicio más económico, necesitábamos reducir nuestros costos operativos. El precio más bajo de iSCSI era atractivo,"" comenta Kevin Harris, co-fundador y Director de informática.

El uso de iSCSI se extiende

En 2007 Enterprise Strategy Group (ESG) declaró que el uso de iSCSI estaba muy extendido basándose en un estudio que realizó con 500 organizaciones en el que el 37% o bien habían elegido o tenían previsto elegir SANs iSCSI. Otros analistas se muestran de acueDRo en lo siguiente: "iSCSI ha llegado. Su atractivo es el bajo costo y la capacidad de mejorar infraestructuras IP ya existentes," aduce Greg Schulz, analista jefe en el StorageIO Group, una compañía de investigación con sede en Stillwater, Minnesota.

Nuestra publicación SearchStorage.com sobre encuestas de intenciones de compra bianual presenta unas cifras similares sobre la adopción del iSCSI. En el estudio más reciente realizado el pasado otoño, el 40% de los entrevistados dijo que habían implementado o planeaban implementar el almacenamiento iSCSI en 2008.

"No hay duda de que el iSCSI ha llegado para quedarse. Es más fácil de conocer (que el Canal de fibra), más rápido de instalar y más fácil de configurar y gestionar,"afirma Jeff Byrne, analista jefe, Taneja Group, Hopkinton, Massachusetts. Y dado el costo inferior del iSCSI, es normal que las pequeñas y medianas empresas busquen el almacenamiento en red.

Las mejores SANs iSCSI también van cargadas con extras que encarecen el precio en el mundo del Canal de fibra, como duplicación, snapshots, deduplicación de datos y thin

provisioning (mecanismo centralizado de almacenamiento) . "Algunas SANs iSCSI incluso tienen un balanceo de carga automático que vuelve a dividir y reequilibrar las cargas de trabajo," continúa Byrne. A eso, añádale herramientas integradas de gestión de gráficos basadas en un asistente y, así y todo, las mejores SANs iSCSI aún cuestan menos que las SANs FC.

La virtualización del servidor da un impulso al iSCSI

Si el bajo costo o la facilidad de uso no impulsa a las compañías hacia el iSCSI, la virtualización de servidores debería hacerlo. La virtualización requiere alguna forma de almacenamiento en red si las compañías desean la disponibilidad mejorada que la virtualización del servidor promete. La disponibilidad mejorada resulta de la capacidad de mover máquinas virtuales (VM) por la red a diferentes servidores físicos en caso de que un servidor físico falle. Sin embargo, si los datos están almacenados en discos conectados directamente al servidor físico que falla, entonces la organización queda atascada. Con un almacenamiento en red, como una SAN iSCSI, la VM puede continuar accediendo a sus datos en la SAN desde el lugar donde éstos acaben en la red.

Los proveedores cada vez se aprovechan más de la virtualización cargando software SAN iSCSI en una VM que funciona en un servidor físico con unidades de disco conectadas a él. "A éste se le denomina software enlatado (tin-wrapped software)," comenta Schulz. Cualquier organización que adopte el Servidor de almacenamiento Windows para iSCSI a través de Hewlett-PackaDR Co. o de Dell probablemente está obteniendo una SAN iSCSI como software enlatado (tin-wrapped software). "Muchos ni siquiera saben que lo están obteniendo porque está pre-empaquetado e integrado," añade.

A través de este enfoque, el negocio puede conseguir una SAN iSCSI casi al instante consistente en la VM iSCSI y las unidades de disco conectadas al servidor físico principal. Si el servidor tiene ocho unidades y cada una es de 1TB SATA drive, usted tiene entonces una SAN iSCSI de 8TB, que representa una importante capacidad de almacenamiento para un pequeño negocio e incluso para muchas empresas medianas. "Se pueden hacer muchas variaciones sobre esto," añade Schulz.

Una variación: LeftHand Networks, recientemente adquirida por HP, toma un grupo físico de tres servidores HP, lo que añade una alta disponibilidad, y carga su software SANiQ iSCSI en una VM que funciona en el grupo.

El enfoque de LeftHand no necesariamente da lugar a una solución barata; un único nodo de haDRware/software con un par de terabytes de almacenamiento cuesta alrededor de los 15.000 dólares. La mayoría de los clientes empiezan con tres nodos. No obstante, pueden comprarse otras SANs iSCSI por menos de 5.000 dólares, incluso por debajo de los 4.000, incluyendo un terabyte o dos de almacenamiento, característica que las hacen adecuadas para casi cualquier organización.

Hay muchos modos de conseguir una SAN iSCSI hoy en día. Los grandes proveedores de iSCSI, Dell/EqualLogic, NetApp Inc., EMC Corp., HP/LeftHand, ofrecen los productos

iSCSI a una gran variedad de precios. Los proveedores más pequeños como SANRAD Inc., Reldata Inc. y Nimbus ofrecen cabezas iSCSI que conectan con cualquier array de discos que se ponga tras ellas. Algunas admiten varios protocolos de almacenamiento: iSCSI, FC, NAS y NFS. Además, se necesitará un conmutador Ethernet, a partir de unos 300 dólares, y un Ethernet NIC, menos de 100 dólares, en cada servidor físico. El iniciador iSCSI, requerido por el servidor, ya va incluido en la mayoría de los sistemas operativos de los servidores. Los analistas esperan la presentación de un iniciador iSCSI nativo de VMware Inc. en el próximo lanzamiento de ESX.

"Usted puede reunir una pequeña SAN iSCSI por menos de 10.000 dólares y probablemente por menos de 5.000 dólares, dependiendo de la capacidad de almacenamiento que desee," asegura Byrne. El iSCSI tampoco requiere unos profundos conocimientos técnicos. La clave es averiguar qué desea respecto a la capacidad, la admisión de más de un protocolo, la extensibilidad y diversas características avanzadas, y cuánto está dispuesto a pagar. El salto a 10Gbs iSCSI costará bastante más. Pero con los precios de 1Gbs, el costo no debería ser un obstáculo para que las medianas empresas e incluso las pequeñas adquieran el iSCSI.

Ventajas y desventajas de la iSCSI frente al Canal de Fibra en entornos de servidores virtualesPublicado: 20 mar 2009

Correo electrónico Imprimir A AA AAA inShare Facebook Twitter Compartir esto Publicaciones Anteriores

Se ha hablado mucho de las redes de área de almacenamiento (o SANs, por sus siglas en ingles) de tipo iSCSI en entornos de servidores virtuales, pero el canal de fibra sigue siendo la tecnología más utilizada en estos casos.

El interés por las SANs iSCSI aumenta

Cuando los departamentos de TI (tecnología de la información) empezaron a virtualizar sus servidores, muchos de ellos optaron por la opción más conservadora en lo que se refiere al almacenamiento. Las pequeñas empresas decidieron adoptar, inicialmente, un sistema de almacenamiento directo (o DAS, por sus siglas en inglés, direct-attached storage) mientras sopesaban los méritos del almacenamiento compartido. Y las medianas y grandes empresas, por lo general, decidieron aprovechar las matrices (arrays) de canal de fibra de las que ya disponían.

La empresa AIMCO (Apartment Investment and Management Company) en Denver (EE. UU.) no fue una excepción. La incursión de este fondo de inversión inmobiliaria en el ámbito de la virtualización de servidores consistió en una licencia para dos procesadores de VMware ESX Server con un sistema DAS además de la SAN de canal de fibra con la que ya contaba. Cuando AIMCO incorporó a su sistema ocho servidores ESX nuevos el año pasado, también conservó su matriz de memoria virtual para empresas (o EVA, por sus siglas en inglés) StorageWorks 6100 de Hewlett-PackaDR (HP) para canal de fibra.

“Ya la teníamos. No tenía sentido comprar nada nuevo. Lo único que teníamos que hacer era añadir más discos”, comenta Chris Bell, administrador de sistemas del centro de datos que AIMCO tiene en Greenville (Carolina del Sur, EE. UU.).

Pero, ahora, Bell está intrigado con la Ethernet de 10 Gb (GbE) y con las SANs iSCSI, ya que es posible que AIMCO se plantee ampliar su entorno de servidores virtuales. Bell ha expresado un particular interés por la visualización del almacenamiento y por los dispositivos de almacenamiento multiprotocolo de NetApp, que soportan iSCSI fuera de la máquina, a diferencia de la EVA 6100, de la que AIMCO no tiene licencia para iSCSI.

La opción de NetApp es interesante porque “con el tiempo, nos permitiría eliminar los conmutadores de serie de la SAN de canal de fibra y pasar del tráfico basado en discos al tráfico de red ISCSI”, comenta Bell. “Todo gira en torno a reducir los costos”.

Que el costo sea bajo es un factor importante que ha de tenerse en cuenta a la hora de comprar una iSCSI, dado que una empresa puede utilizar su actual infraestructura IP en vez de gastar una suma importante en adquirir un sistema de canal de fibra nuevo. Los iniciadores de software que envían las óDRenes SCSI por la red IP están integrados en los principales sistemas operativos. Aún así, los departamentos de TI (tecnología de la información) tienen que realizar un análisis detallado de su entorno virtual para asegurarse de que el ahorro de costos responde a sus expectativas.

“Cuando se añaden máquinas virtuales a un servidor físico, se aumenta la cantidad de tráfico de E/S en los enlaces físicos”, comenta Stanley Zaffos, vicepresidente del departamento de investigación de la empresa Gartner, situada en StamfoDR (Connecticut, EE. UU.). Y el nivel de sobrecarga del iniciador de software aumentará proporcionalmente.

“Es posible que descubra, en algún momento, que aunque algo funcione en la prueba de concepto, no tiene porqué acabar respondiendo como usted esperaba”, comenta Zaffos.

Es posible que necesite comprar adaptadores de host o tarjetas de interfaz de red de mayor rendimiento que puede que eleven los costos hasta alcanzar a los del canal de fibra.

“El rendimiento tiene un precio. Y una vez que pagas ese precio, puede que la iSCSI pieDRa la ventaja que tenía frente al canal de fibra” dependiendo de si se la compara con un sistema de nivel básico o de alto costo, dice Greg Schulz, fundador y analista senior de StorageIO Group en Stillwater (Minnesota, EE. UU.).

Otros factores a tener en cuenta son si se van a virtualizar las cargas de trabajo de las aplicaciones en un servidor físico o no, así como sus necesidades de ancho de banda en caso de que así fuera. Bell de AIMCO, por ejemplo, ha comentado que él sólo se plantearía adoptar la Ethernet de 10 Gb.

Aunque el precio de las tarjetas de la Ethernet de 10 Gb está bajando, puede que muchas empresas consideren que la Ethernet de 1 Gb es más adecuada para ellas, sobre todo si están virtualizando cargas de trabajo de aplicaciones más ligeras.

A la espera de la Ethernet de 10 Gb

Saddle Creek Corporation, por ejemplo, no ha hecho nada en particular para reunir varias conexiones GbE y potenciar su rendimiento. Kathy Fulton, directora senior de servicios técnicos del proveedor de logística de terceros, ha comentado que la empresa no se ha encontrado con ningún problema de rendimiento, a pesar del gran volumen que debe afrontar su sistema de gestión de almacén.

“En algún momento, nos plantearemos [la Ethernet de 10 Gb] porque siempre que surge la ocasión de hacer algo para mejorar el rendimiento, merece la pena tenerlo en cuenta”, dijo.

Esta empresa con sede en Lakeland (Florida, EE. UU.) fusionó entre 70 y 80 servidores físicos para obtener aproximadamente 10 que utilizan VMware. Ahora, todas las aplicaciones están virtualizadas, incluyendo el servidor de intercambio de Microsoft, que contiene más de 600 buzones. Saddle Creek pasó de un sistema de almacenamiento directo o DAS a una SAN iSCSI de LeftHand Networks (que ahora pertenece a Hewlett-PackaDR) y una iniciativa propia de virtualización de servidores.

Fulton sabía que el sistema DAS ya no les permitía sacar partido de las funciones avanzadas de VMware, como son el alto nivel de disponibilidad y VMotion, que permite a los usuarios trasladar las máquinas virtuales de un servidor a otro. Según comenta Fulton, la decisión estaba entre una iSCSI y una SAN de canal de fibra, pero el precio, la flexibilidad y la facilidad de su administración inclinaron la balanza a favor de la iSCSI.

“El tiempo que mis ingenieros tenían que invertir en administrar la SAN parecía ser significativamente inferior en el caso de la iSCSI”, comenta Fulton. “Les gustó mucho la interfaz porque todo estaba organizado siguiendo un oDRen lógico”.

Las funciones del aprovisionamiento de almacenamiento se amplían

Según Jeff Boles, analista senior y director de los servicios de validación de Taneja Group en Hopkinton (Massachusetts, EE. UU.), la mayor parte del aprovisionamiento de almacenamiento de una iSCSI puede llevarla a cabo el personal a cargo del servidor (y no especialistas en almacenamiento). Muchos usuarios tienden a utilizar la iSCSI para nuevos proyectos o cuando sus sistemas de almacenamiento de canal de fibra les ofrecen esa opción, añade.

Según una encuesta realizada en diciembre de 2007 por Enterprise Strategy Group (ESG), con sede en MilfoDR (Massachusetts, EE. UU.), el 86% de las 365 organizaciones de TI (tecnología de la información) consultadas utilizaban un sistema de unidades de almacenamiento en red en sus entornos de servidores virtuales. ESG también descubrió que la mayoría de empresas participantes no habían comprador nuevos recursos de almacenamiento para dar soporte a la virtualización de sus servidores.

Bob Laliberte, analista de ESG, afirmó que el área que había experimentado un mayor crecimiento había sido el de las iSCSI, aunque reconoció que podría deberse a las numerosas pequeñas y medianas empresas (PYMEs) que están aprovechándose de los beneficios de la virtualización de servidores. A las PYMEs les suele gustar la iSCSI porque es una tecnología con la que ya están familiarizas, añadió.

Aún así, el canal de fibra sigue siendo la tecnología de almacenamiento más utilizada en entornos de servidores virtuales. Por ejemplo, la encuesta de intención de compra realizada por la revista Storage durante la primavera de 2009 muestra que de las 470 empresas consultadas que virtualizan sus servidores, el 51% utiliza SANs de canal de fibra como principal sistema de almacenamiento. Le siguen las SANs iSCSI (con un 12%), los sistemas de almacenamiento directo o DAS (con un 10%) y los sistemas de almacenamiento en red o NAS (con un 9%).

Según Jon Bock, director senior de marketing de soluciones de continuidad empresarial de VMware, VMware no ofrecía soporte nativo para iSCSI o para sistemas de almacenamiento NAS hasta que no salió al mercado el ESX 3.0 en junio de 2006. Antes de entonces, para utilizar una iSCSI y un sistema de almacenamiento NAS, el usuario tenía que conectarlos desde la máquina virtual, en vez de conectarlos directamente al servidor ESX.

Bock reconoció que VMware introdujo por primera vez funciones como Storage VMotion y VMware Consolidated Backup para canal de fibra porque este sistema tenía un porcentaje mayor de penetración en el mercado. Pero también señaló que, actualmente, la empresa tiene la intención de ofrecer las mismas funciones en todos los casos (siempre que esto sea técnicamente posible) independientemente del tipo de almacenamiento compartido que pueda utilizar el cliente.

Los inconvenientes del canal de fibra

Las principales desventajas que presenta el canal de fibra en entornos virtualizados son las mismas que en entornos no virtuales: su costo y complejidad. Pero el rendimiento, la fiabilidad y el alto nivel de disponibilidad que ofrece para aplicaciones fundamentales han impedido que muchas empresas adoptasen redes SAN iSCSI basadas en Ethernet, sobre todo si ya habían realizado previamente inversiones significativas en el sistema de canal de fibra.

Una red basada en Ethernet acarrea una sobrecarga de TCP/IP que le sirve para compensar los reintentos, las discoDRancias y el control de flujo a la hora de enviar la información. Pero incluso en estos casos, no hay ninguna garantía de que no se pieDRa algún paquete. El estándar CEE (Converged Enhanced Ethernet) pretende solventar estas deficiencias, pero aún se está trabajando en su desarrollo.

Cuando lleguen al mercado productos con soporte para CEE, el canal de fibra sobre Ethernet (FCoE) puede convertirse en otra opción viable para entornos de servidores virtuales. Para empresas que necesitan un gran ancho de banda, la Ethernet de 10 Gb supondrá una gran mejora respecto al canal de fibra de 8 Gbps.

Hasta entonces, las grandes empresas suelen inclinarse por lo que ya conocen. Por ejemplo, RiskMetrics Group, tiene años de experiencia en el ámbito del canal de fibra y sabe cómo hacer frente a problemas potenciales. La empresa de servicios financieros con sede en Nueva York sólo ha tenido cuatro averías (una relacionada con un adaptador de bus de host o HBA y las otras tres relacionadas con los cables del canal de fibra) en ocho años y ninguna de ellas ha sido crítica, según Ed Delgado, arquitecto de almacenamiento de la empresa.

“Eso fue lo que realmente nos confirmó que habíamos tomado la decisión correcta” para el entorno de servidores virtuales, escribió Delgado en un correo electrónico.

Otro factor adicional fue el salto que dio la empresa al canal de fibra de 4 Gbps. RiskMetrics tiene 30 servidores ESX de VMware repartidos entre seis ubicaciones distintas y de cada uno de ellos suelen depender entre 10 y 15 máquinas virtuales.

“El principal problema que tuvimos con la iSCSI tenía que ver con la confianza que nos inspiraba la infraestructura de red, que nuestros servidores ya utilizaban en gran medida para realizar labores generales de comunicación y transferencia de datos", escribía Delgado. “La fibra nos proporcionó un entorno especializado que podía someterse a diagnósticos y adaptarse a las necesidades del fabricante en caso de ser necesario fácilmente.”

Aunque Delgado consideraba que la iSCSI era “demasiado impredecible para que pudiésemos ejecutar una implementación de VMware completa”, apoyó la idea de que la empresa la pusiera a prueba en una de sus sucursales más pequeñas. Tres de las nuevas matrices o arrays de disco de RiskMetrics soportar iSCSI, aunque el personal encargado del almacenamiento aún no la ha utilizado.

“Hemos ido para adelante y para atrás respecto a la aplicación de la iSCSI en nuestro entorno, no sólo para los servidores virtuales”, escribe Delgado. “Aunque estaría bien aprovechar el equipo de red de Cisco [Systems] que ya tenemos, experimentaríamos una reducción en el ancho de banda y cargaríamos al personal de red con un trabajo adicional al tener que crear y gestionar diversas VLANs [LANs virtuales] independientes dedicadas exclusivamente al almacenamiento”.

Dan Iacono, ingeniero senior de sistemas SAN del departamento de ingeniería de sistemas multifabricante de HP, considera que el canal de fibra ya es más apropiado que la iSCSI para entornos de servidores virtualizados sólo por la sobrecarga asociada a la iSCSI y al sistema NAS.

“El proceso de traducción del sistema de almacenamiento al protocolo IP utiliza ciclos de la CPU del servidor”, dice. “Lo que siempre ha hecho más atractivo al cable de fibra es la encapsulación de protocolos de almacenamiento en un circuito integrado de aplicación específica [o ASIC, por sus siglas en inglés, application-specific integrated circuit ]. No se añade ningún tipo de sobrecarga a la CPU”.

Pero para esos casos en los que un usuario quiere pasar un volumen de almacenamiento de una máquina virtual a otra, la iSCSI y el sistema NAS son la mejor opción, según Iacono.

El NAS se utiliza pocas veces en entornos virtuales, aunque puede que tenga cierto éxito entre organizaciones de TI (tecnología de la información) que prefieren un sistema de almacenamiento basado en archivos y de fácil gestión. Con velocidades de red superiores, el rendimiento ya no es el problema que fue para las aplicaciones de gama más alta.

Bock, de VMware, considera que la mayoría de empresas toma esta decisión basándose en “cuál es la mejor opción teniendo en cuenta lo que [están] haciendo actualmente” y en si “esa plataforma de almacenamiento implementa o no las funciones que ellos necesitan”. No considera que una opción presente ninguna ventaja técnica inherente respecto a la otra.

“Es mejor un coche rojo o un coche azul?”, se pregunta Bock. “Hay coches rojos buenos y coches rojos malos, así como también hay coches azules buenos y coches azules malos”.

http://searchdatacenter.techtarget.com/es/noticias/2240164888/Ventajas-y-desventajas-de-la-iSCSI-frente-al-Canal-de-Fibra-en-entornos-de-servidores-virtuales

Guía sobre los conmutadores para redes SAN de Canal de Fibra

Correo electrónico Imprimir A AA AAA inShare Facebook Twitter Compartir esto Publicaciones Anteriores

Una empresa que esté a punto de comprar su primera SAN puede que considere una SAN con iSCSI, que puede hacer uso de la infraestructura de IP y la conmutación de Ethernet existentes. Sin embargo, la mayoría de las empresas que ya han utilizado una SAN han invertido de forma significativa en conmutadores de Canal de Fibra para conectar sus servidores y dispositivos de almacenamiento.

Las empresas que buscan implementar las SAN de Canal de Fibra necesitan comprar el conmutador correcto del proveedor correcto. En esta guía, aprenderá cómo decidirse por el conmutador de Canal de Fibra de SAN correcto y cómo mantener el rendimiento del conmutador.

Cómo seleccionar un conmutador de Canal de Fibra para su SAN

Para cualquier organización que esté construyendo una SAN, el conmutador supone un punto clave sobre el que decidir. El conmutador inspecciona un paquete de datos, determina de dónde proviene y adonde va, después envía el paquete al destino de almacenamiento previsto en el centro de datos.

Los conmutadores para SAN de Canal de Fibra tienen el mismo propósito general que cualesquiera otros conmutadores de redes: conectar automáticamente a los remitentes y los receptores.

Pero un conmutador de Canal de Fibra se ha diseñado específicamente para manejar cargas de transacción pesadas en redes de Canal de Fibra de gran rendimiento. Los dos tipos principales de conmutadores de Canal de Fibra para redes SAN son el conmutador director modular de gran número de puertos y el conmutador semi-modular o de puertos fijos más pequeño. A medida que una empresa amplía su entorno de SAN, puede habilitar puertos adicionales utilizando una clave de licencia del software para desbloquearlos.

Buenas prácticas para entornos de conmutación de Canal de Fibra

Las empresas que buscan implementar una SAN de Canal de Fibra deberían saber que es mala idea mezclar y combinar las marcas.

Los conmutadores de Canal de Fibra deben comunicarse y cooperar los unos con los otros para gestionar la estructura general. La mejor manera de asegurarse que eso ocurre es la de elegir un conmutador de los mejores proveedores como Brocade Communications Systems, Cisco Systems o QLogic.

“Existe un estándar para esta comunicación [entre los conmutadores], pero el estándar es una especie de denominador débil y poco común de las funciones necesarias para forjar una SAN”, dice Robert Passmore, analista de Gartner. “Todos los proveedores de conmutadores poseen una serie de funciones de gestión generales mucho más sólidas que son exclusivas de [cada uno de ellos].”

Existen algunas buenas prácticas comunes a todos los entornos de conmutación de Canal de Fibra, incluyendo:

Las consideraciones de planificación

La construcción de dos estructuras de Canal de Fibra independientes para obtener redundancia

El aspecto técnico de la gestión

Lo relativo al personal de gestión

La seguridad

Los servidores virtuales

http://searchdatacenter.techtarget.com/es/tutorial/Guia-sobre-los-conmutadores-para-redes-SAN-de-Canal-de-Fibra