La primera vez que eché un vistazo a ZFS me dejó helado. Es un sistema de ficheros que ha cambiado las reglas en los sistemas de almacenamiento tal como los conocemos y lo continúa haciendo. No hay duda de que es la mejor arquitectura hasta la fecha y ahora se puede usar como almacenes VMware.

Lo había probado anteriormente como almacén VMware pero me encontré con muchos problemas que me imposibilitaron su uso. Uno de ellos fue la respuesta ante una página VPD que provocaba que VMware viera únicamente  un almacén iSCSI usable. Pero esto cambiará en cuanto Sun publique la versión snv_93. Actualmente estoy usando una versión no publicada del código de iscsitgt de lo que será snv_93, y funciona perfectamente con VMware. Muchas gracias a los ingenieros de Sun por añadir la
compatibilidad NAA en el servicio de objetivo iSCSI. Dicho esto dejadme exponer los detalles y el comportamiento de la primera implementación con éxito de VMware en iSCSI sobre ZFS en un X4500 en el mundo real.

Echemos primero un vistazo a una vista de la arquitectura.

La arquitectura usa la idea de las buenas prácticas de tener completamente separadas las redes físicas del almacenamiento iSCSI. Todos los componentes tienen la alimentación y la conectividad de red redundadas. El nodo de almacenamiento iSCSI tiene sus tarjetas de red como agregados y sus VLANs no son accesibles desde la red de gestión del servidor. Se ha definido una conexión ISL entre los conmutadores HP 2900 pero no es crítica. Esto nos permitiría mayor disponibilidad de rutas de datos si se asignaran más tarjetas de red en el host ESX.

Los componentes de red y agregados se configuran en OpenSolaris del siguiente modo:

Para aquellos que usen Indiana... En Indiana está habilitado por defecto nwam y necesitaremos deshabilitarlo para activar el servicio de red físico:

svcadm disable svc:/network/physical:nwam
svcadm enable svc:/network/physical:default

Definiremos el agregado utilizando la utilidad de administraciones de conexiones de datos, pero primero deberemos limpiar las uniones existentes deshabilitando las tarjetas de red:

Ej: ifconfig unplumb e1000g0

Una vez limpias las uniones podremos agregar los dispositivos físicos usando los siguientes comandos:

dladm create-aggr –d e1000g0 –d e1000g1 –P L2,L3 1
dladm create-aggr –d e1000g2 –d e1000g3 –P L2,L3 2

De este modo hemos creado los agregados aggr1 y aggr2 y se ha definido la política de permitir las capas 2 y 3. Ahora podremos definir el interfaz de la VLAN (en nuestro caso la VLAN 500) relativo a cada instancia de los dispositivos agregados. Para definir los "interfaces" VLAN únicamente deberemos usar la siguiente fórmula:

(Nombre de adaptador) + vlan * 1000 + (Instancia del adaptador)

ifconfig aggr500001 plumb up 10.1.0.1 netmask 255.255.0.0 
ifconfig aggr500002 plumb up 10.1.0.2 netmask 255.255.0.0

Para que dicha configuración se aplique en cada arranque del sistema necesitaramos crear los ficheros de nombre de host y las entradas de hosts:

echo ss1.iscsi1 > /etc/hostname.aggr500001
echo ss1.iscsi2 > /etc/hostname.aggr500002

Edite el fichero /etc/hosts para que contenga las siguientes entradas:

::1 localhost
127.0.0.1 ss1.local localhost loghost
10.0.0.1 ss1 ss1.domain.name
10.1.0.1 ss1.iscsi1
10.1.0.2 ss1.iscsi2

En el conmutador HP necesitaremos definir únicamente los puertos 1 y 2 como agregados estáticos en su CLI (linea de comandos):

trunk 1-2 trk1 trunk 

Una vez que hayamos conseguido que los componentes de red estén correctamente configurados, deberemos definir el almacenamiento ZFS y los objetivos iSCSI. He decidido incluir grupos de discos tanto espejados como en raidz. Para crear la lista de los nombres de dispositivos cxtxdx se puede usar la salida del comando cfgadm o la del format para ver la controladora, el objetivo y los nombres de los discos si no se usa un X4500. Repartí los dispositivos raidz entre las controladoras para mejorar la E/S y distribuir la carga. No hubiera sido prudente usar una única controladora para gestionar todos los discos. Este es el modo en el que se configuraría usando los comandos de ZFS.

zpool create –f rp1 raidz1 c4t0d0 c4t6d0 c5t4d0 c8t2d0 c9t1d0 c10t1d0
zpool add rp1 raidz1 c4t1d0 c4t7d0 c5t5d0 c8t3d0 c9t2d0 c10t2d0
zpool add rp1 raidz1 c4t2d0 c5t0d0 c5t6d0 c8t4d0 c9t3d0 c10t3d0
zpool add rp1 raidz1 c4t3d0 c5t1d0 c5t7d0 c8t5d0 c9t5d0 c11t0d0
zpool add rp1 raidz1 c4t4d0 c5t2d0 c8t0d0 c8t6d0 c9t6d0 c11t1d0
zpool add rp1 raidz1 c4t5d0 c5t3d0 c8t1d0 c8t7d0 c10t0d0 c11t2d0
zpool add rp1 spare c11t3d0 
zpool create –f mp1 mirror c10t4d0 c11t4d0
zpool add mp1 mirror c10t5d0 c11t5d0
zpool add mp1 mirror c10t6d0 c11t6d0
zpool add mp1 spare c9t7d0

Crear un almacenamiento de terabytes solo requiere de unos pocos segundos, esto si que es bonito (guiño geek ;). Ahora definiremos algunos grupos de discos y almacenes para preparar la creación de los objetivos iSCSI. Decidí usar unidades de 750GB ya que VMware no funciona correctamente si asignamos tamaños algo mayores. Suele depender del tamaño de la máquina virtual y del tipo de transacciones de E/S pero generalmente el host ESX servirá muchos tipos diferentes de peticiones así que decidí usar un tamaño conservador para evitar encontrarme con problemas de reservas SCSI.

También deberemos considerar el tamaño del bloque de E/S antes de crear el almacén ZFS, ya que no podremos cambiarlo una vez creado. Esto lo haremos añadiendo "-b 64K" al comando ZFS create. Para el tamaño de bloque de 64K escogí usar un múltiplo de 8 (8 * 8). Con la opción "-s" habilitaremos los volúmenes "escasos" también conocidos como "provisión fina". Aunque en este caso había espacio disponible suficiente yo suelo asignar almacenamiento de este modo.

zfs create rp1/iscsi
zfs create -s -b 64K -V 750G rp1/iscsi/lun0
zfs create -s -b 64K -V 750G rp1/iscsi/lun1
zfs create -s -b 64K -V 750G rp1/iscsi/lun2
zfs create -s -b 64K -V 750G rp1/iscsi/lun3
zfs create mp1/iscsi 
zfs create -s -b 64K -V 750G mp1/iscsi/lun0

En un primer momento pensé en construir los hosts ESX utilizando discos locales, pero gracias a la mala ingeniería de los IBM x346 no pude utilizar ni la QLA4050C ni la controladora integrada Adaptec de los servidores ESX. Debido a esto decidí dar una oportunidad al arranque desde iSCSI y aquí está la definición de las LUNs que usé para ello. El diseño de la arquitectura original requiere discos locales para prevenir fallos en los hosts ESX en el caso de que se perdiera la conectividad iSCSI.

zfs create rp1/iscsi/boot 
zfs create -s -V 16G rp1/iscsi/boot/esx1

Ahora que ya tenemos configurados los almacenes ZFS podremos configurar los objetivos iSCSI que usarán los hosts ESX. He usado alias para los objetivos para intentar facilitar la gestión del sistema de almacenamiento. También he creado un almacén de configuración iSCSI para que dicha configuración no se borre durante un reinicio de los objetivos iSCSI (esto puede que esté ya incluido en OpenSolaris Indiana pero no lo he comprobado).

mkdir /etc/iscsi/config 
iscsitadm modify admin --base-directory /etc/iscsi/config 
iscsitadm create target -u 0 -b /dev/zvol/rdsk/rp1/iscsi/lun0 ss1-zrp1 
iscsitadm create target -u 1 -b /dev/zvol/rdsk/rp1/iscsi/lun1 ss1-zrp1 
iscsitadm create target -u 2 -b /dev/zvol/rdsk/rp1/iscsi/lun2 ss1-zrp1 
iscsitadm create target -u 3 -b /dev/zvol/rdsk/rp1/iscsi/lun3 ss1-zrp1
iscsitadm create target -b /dev/zvol/rdsk/mp1/iscsi/lun0 ss1-zmp1 
iscsitadm create target -b /dev/zvol/rdsk/rp1/iscsi/boot/esx1 ss1-esx1-boot

La mayoría de los ejemplos que he visto en blogs para habilitar los objetivos usan el método de línea de comandos ZFS como "shareiscsi=on". Esto funciona correctamente para un nuevo iqn, pero en el caso de que queramos añadir LUNs adicionales bajo este iqn se necesitará usar este modo de almacén de respaldo (usando la opción "-b" de iscsitadm).

Ahora que tenemos algunos objetivos podremos listarlos usando:

iscsitadm list target

Hay que fijarse en que únicamente podemos ver un iqn para 'ss1-zrp1'; en el caso de que queramos ver todas las LUNs podremos usar la opción "-v".

Target: ss1-zrp1
iSCSI Name: iqn.1986-03.com.sun:02:eb9c3683-9b2d-ccf4-8ae0-85c7432f3ef6.ss1-zrp1
Connections: 2
Target: ss1-zmp1
iSCSI Name: iqn.1986-03.com.sun:02:36fd5688-7521-42bc-b65e-9f777e8bfbe6.ss1-zmp1
Connections: 2
Target: ss1-esx1-boot
iSCSI Name: iqn.1986-03.com.sun:02:d1ecaed7-459a-e4b1-a875-b4d5df72de40.ss1-esx1-boot
Connections: 2

Sería conveniente crear algunas entradas de iniciadores de objetivos que nos permitieran el control de autorización sobre qué iniciadores iqn se pueden conectar a un objetivo en particular. Este es un paso importante, ya que nos permitirá utilizar CHAP o al menos permitir únicamente el acceso a los objetivos a los iqn que designemos. iSNS también proporciona un servicio similar.

iscsitadm create initiator --iqn iqn.2000-04.com.qlogic:qla4050c.esx1.1 esx1.1
iscsitadm create initiator --iqn iqn.2000-04.com.qlogic:qla4050c.esx1.2 esx1.2

Ahora podremos asignar estos iniciadores a un objetivo y dicho objetivo únicamente aceptará esos iniciadores. Podremos también añadir autenticación mediante CHAP, pero no lo vamos a explicar en este blog.

iscsitadm modify target --acl esx1.1 ss1-esx1-boot
iscsitadm modify target --acl esx1.2 ss1-esx1-boot
iscsitadm modify target --acl esx1.1 ss1-zrp1
iscsitadm modify target --acl esx1.2 ss1-zrp1
iscsitadm modify target --acl esx1.1 ss1-zmp1
iscsitadm modify target --acl esx1.2 ss1-zmp1

Para poder arrancar de la LUN objetivo necesitaremos configurar la funcionalidad de arranque en la QLA4050C. Para ello tendremos que pulsar la combinación Ctrl+Q durante la secuencia de arranque del host ESX. Tras ello únicamente deberemos introducir la IP del objetivo del que arrancaremos, configurar el modo en manual e introducir el iqn exactamente como se mostró en la salida del comando "iscsitadm list targets", por ejemplo:

iqn.1986-03.com.sun:02:d1ecaed7-459a-e4b1-a875-b4d5df72de40.ss1-esx1-boot

Una vez se haya introducido el iqn el software del host ESX se podrá instalar y configurar.
Hasta la próxima...


(Written by Mike LaSpina：Running ZFS over iSCSI as a VMware vmfs store. Translated by Pablo Méndez Hernández - pablomh@gmail.com)