Para esto utilicé 3 máquinas virtuales de 512 MB de RAM cada una. A continuación coloco un esquema de red del laboratorio que construí:
El motivo de colocar dos redes de storage separadas, es evitar conflictos con los paquetes arp de las tarjetas ethernet conectadas a una misma red.
Como dije al principio, esta estructura puede que no sea aplicable en la vida real ya que haciendo bonding con eth1 y eth2 tendríamos una sola red IP.
Características de los servidores
Servidor iscsi (Target) y cliente iscsi (Initiatior)
Distribución: Centos 6.3
NIC's: 3
RAM: 512 MB
Características de red
Este entorno fue montado con 2 máquinas virtuales, las tarjetas conectadas a la red 192.168.122.0/24 están en modo NAT con dhcp (pueden tener diracciones estáticas).
Las tarjetas de red conectadas a las redes 192.168.144.0/24 y 192.168.42.0/24 están en modo "host-only" con lo que no tienen comunicación con el exterior.
No es objetivo de este post explicar cómo se configura el entorno a nivel de máquinas virtuales.
Configuración del servidor iscsi (Target)
El target es el "servidor de storage", será el que proporcionará los LUN's a los clientes, sería como la cabina de discos.Para configurar el target hay que instalar el paquete scsi-target-utils
yum install scsi-target-utils
Creamos el directorio /etc/tgt/temp para colocar ahí el archivo de configuración para las pruebas.
Editamos el archivo /etc/tgt/targets.conf y colocamos la siguiente línea
include /etc/tgt/temp/*.conf
Eso servirá para incluir cualquier archivo con extensión .conf que esté en
/etc/tgt/temp/
La línea
default-driver iscsi
debería estar descomentada también.
De ahora en adelante, todas las modificaciones las haremos en
/etc/tgt/temp/prueba.conf.
Nombre del target
La sintaxis del nombre está descrita en el rfc3721, este es un extracto:Constructing iSCSI names using the iqn. format
The iSCSI naming scheme was constructed to give an organizational
naming authority the flexibility to further subdivide the
responsibility for name creation to subordinate naming authorities.
The iSCSI qualified name format is defined in [RFC3720] and contains
(in order):
- The string "iqn."
- A date code specifying the year and month in which the
organization registered the domain or sub-domain name used as the
naming authority string.
- The organizational naming authority string, which consists of a
valid, reversed domain or subdomain name.
- Optionally, a ':', followed by a string of the assigning
organization's choosing, which must make each assigned iSCSI name
unique.
Para nuestro primer ejemplo, utilizaremos el nombre
iqn.2012-08.local.centos:pool01
Creación del LUN
Para poder "servir" un LUN es necesario crearlo a nivel de sistema operativo. Para este ejemplo utilizaremos lvoles que serán utilizados por los clientes como LUN's.Asumiendo que se dispone de un disco (/dev/sdb) de 1 GB, creamos el vg vg_iscsi.
pvcreate /dev/sdb
vgcreate vg_iscsi /dev/sdb
lvcreate -m lv_lun01 -l 500M vg_iscsi
El dispositivo que se servirá como LUN a los clientes es
/dev/vg_iscsi/lv_lun01
Editamos el archivo de configuración /etc/tgt/temp/prueba.conf y colocamos las siguientes líneas
<target iqn.2012-08.local.centos:pool01>
backing-store /dev/vg_iscsi/lv_lun01
</target>
Nos aseguramos que el demonio tgtd se arranque con el sistema operativo
chkconfig tgtd on
y arrancamos el servicio
/etc/init.d/tgtd start
Para verificar que se estén sirviendo el LUN que configuramos, utilizamos el siguiente comando:
tgt-admin -s
Target 1: iqn.2012-08.local.centos:pool01
System information:
Driver: iscsi
State: ready
I_T nexus information:
LUN information:
LUN: 0
Type: controller
SCSI ID: IET 00010000
SCSI SN: beaf10
Size: 0 MB, Block size: 1
Online: Yes
Removable media: No
Prevent removal: No
Readonly: No
Backing store type: null
Backing store path: None
Backing store flags:
LUN: 1
Type: disk
SCSI ID: IET 00010001
SCSI SN: beaf11
Size: 524 MB, Block size: 512
Online: Yes
Removable media: No
Prevent removal: No
Readonly: No
Backing store type: rdwr
Backing store path: /dev/vg_iscsi/lv_lun01
Backing store flags:
Account information:
ACL information:
ALL
Tenemos un LUN disponible para cualquier cliente.
Control de acceso
El control de acceso se hace por target, es decir, dentro de una directivaTambién se puede controlar el acceso mediante usuario/password. Para más información, man targets.conf.
Para el ejemplo de este post, usaremos un solo LUN.
Para administrar todo lo relacionado con el servicio tgtd (añadir LUN's, eliminar LUN's, añadir, modificar, eliminar targets, etc), se utiliza el comando tgtadm.
Ninguna operación realizada con tgtadm es persistente y solo queda en memoria. Para actualizar el archivo de configuración hay que ejecutar
tgt-admin --dump > /etc/tgt/temp/prueba.conf
Es importante tomar en cuenta la advertencia que viene en el manual de tgt-admin con respecto a la opción --dump:
Note: does not include detailed parameters, like write caching
Avisados están.
Ya tenemos el servidor configurado, faltan los clientes.
Configuración del cliente (initiator)
El cliente es cualquier máquina que vaya a hacer uso de algún LUN del servidor iSCSI, por lo tanto, cualquier máquina que vaya a necesitar discos de la SAN, es un cliente.Para configurar el cliente debemos comenzar por instalar el paquete iscsi-initiator-utils
yum install iscsi-initiator-utils
A continuación, editamos el archivo /etc/iscsi/initiatorname.iscsi y colocamos el nombre del initiator, puede ser el FQDN del host. En este ejemplo utilizaremos "cliente" como initiator name.
InitiatorName=cliente
Nos aseguramos que los servicios iscsi y iscsid arranquen en cada inicio del sistema operativo
chkconfig iscsi on
chkconfig iscsid on
Configuramos las interfaces de red que van a formar parte de la red iSCSI, en nuestro caso eth1 y eth2 (eth0 es para comunicarse con el "exterior").
iscsiadm -m iface -I eth1 -o new
iscsiadm -m iface -I eth1 -o update -n iface.hwaddress -v MAC
iscsiadm -m iface -I eth2 -o new
iscsiadm -m iface -I eth2 -o update -n iface.hwaddress -v MAC
donde:
-I es el nombre el la interfaz ethernet.
-n iface.hwaddress es el nombre del atributo.
-V MAC es para especificar la MAC address de la tarjeta ethernet.
En la primera línea creamos la interfaz y en la segunda le colocamos la MAC address al atributo iface.hwaddress.
Podemos revisar los contenidos de los archivos de configuración para cada interfaz haciendo
cat /var/lib/iscsi/ifaces/eth1
# BEGIN RECORD 2.0-872.41.el6
iface.iscsi_ifacename = eth1
iface.hwaddress = 00:50:56:37:B7:45
iface.transport_name = tcp
iface.vlan_id = 0
iface.vlan_priority = 0
iface.iface_num = 0
iface.mtu = 0
iface.port = 0
# END RECORD
Descubrimos los targets disponibles por cada interfaz
# iscsiadm -m discovery -t sendtargets -p 192.168.144.1 -I eth1
192.168.144.1:3260,1 iqn.2012-08.local.centos:pool01
# iscsiadm -m discovery -t sendtargets -p 192.168.42.1 -I eth2
192.168.42.1:3260,1 iqn.2012-08.local.centos:pool01
Ahora tenemos que hacer login en el target iqn.2012-08.local.centos:pool01 con cada una de las tarjetas
# iscsiadm -m node -l
Logging in to [iface: eth2, target: iqn.2012-08.local.centos:pool01, portal: 192.168.42.1,3260] (multiple)
Logging in to [iface: eth1, target: iqn.2012-08.local.centos:pool01, portal: 192.168.144.1,3260] (multiple)
Login to [iface: eth2, target: iqn.2012-08.local.centos:pool01, portal: 192.168.42.1,3260] successful.
Login to [iface: eth1, target: iqn.2012-08.local.centos:pool01, portal: 192.168.144.1,3260] successful.
Con esto ya deberíamos ver dos "discos", sdb y sdc.
# lsscsi
[1:0:0:0] cd/dvd NECVMWar VMware IDE CDR10 1.00 /dev/sr0
[2:0:0:0] disk VMware, VMware Virtual S 1.0 /dev/sda
[11:0:0:0] storage IET Controller 0001 -
[11:0:0:1] disk IET VIRTUAL-DISK 0001 /dev/sdb
[12:0:0:0] storage IET Controller 0001 -
[12:0:0:1] disk IET VIRTUAL-DISK 0001 /dev/sdc
Ya tenemos el cliente configurado, esta información no se perderá durante el reboot. Podemos probar reiniciando el cliente y luego de que arranque, volvemos a ejecutar lsscsi y deberíamos obtener el mismo resultado.
Nos queda configurar el multiptah.
Configuración de multipath
Primero instalamos el multipathyum install device-mapper-multipath
Esto instalará dos paquetes, el device-mapper-multipath y el device-mapper-multipath-libs.
El paquete de multipath no trae archivo de configuración, debemos copiar uno de /usr/share/doc/device-mapper-multipath-$VERSION/.
Para este caso, voy a copiar el multipath.conf.synthetic a /etc/multipath con el nombre multipath.conf.
Editamos el archivo /etc/multipath/multipath.conf y descomentamos toda la sección defaults y blacklist.
Creamos un enlace simbólico en /etc que apunte a
/etc/multipath/multipath.conf
ln -s /etc/multipath/multipath.conf /etc/multipath.conf
Nos aseguramos que el multipathd arranque al inicio con el comando
chkconfig multipathd on
Arrancamos el demonio de multipath
/etc/init.d/multipathd start
Ejecutamos el comando multipath -ll y deberíamos obtener una salida parecida a esta:
[root@cliente ~]# multipath -ll
1IET 00010001 dm-5 IET,VIRTUAL-DISK
size=500M features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=1 status=active
|- 3:0:0:1 sdb 8:16 active ready running
`- 4:0:0:1 sdc 8:32 active ready running
Indicando que el dispositivo "1IET 00010001" contiene a los dos path's sdb y sdc.
Esta es la configuración básica de multipath.
Hasta aquí este post, para más información, consultar el manual de multipath, tgt-admin y tgtadm
