Esta semana, en nuestra sección de Citrix XenServer, veremos más trucos sobre la gestión de discos que ya empezamos la semana pasada. Espero que, como siempre, te resulte interesante.

VBDs a fondo

Vimos que Citrix XenServer es capaz de abstaer el sistema físico de almacenamiento ya sea, SAN, I-SCSI, Storage Link, NFS, etc. De manera que las máquinas virtuales siempre tendrán asociados VBDs y estos hacen de “enlace” con nuestros discos virtuales VDIs.

Eso es muy importante ya que por ejemplo el core de Citrix XenServer utiliza aplicaciones como Pygrub, un grub hecho en python para arrancar los domU (máquinas virtuales) con su propio Kernel. Este, necesita parametros para saber que disco tiene que utilizar para arrancar el sistema. Este parámetro en cuestión es el parámetro “bootable”.

Es común el error: “No bootable device.” Cuando por ejemplo borramos un snapshot que tenia ese parámetro puesto automáticamente.

Sabiendo cual de los VBD->VDI contiene el Kernel de nuestra máquina virtual, simplemente tendríamos que establecer dicho VDB como “bootable” para que el domU arrancara sin problemas:

#xe vbd-param-set uuid=<UUID VBD> bootable=true

Tambien el VDB establece que tipo de disco se presenta (CDRom/Disk), modo (lectura/escritura), dispositivo de la maquina virtual (xvda/ hda) y un largo etc. Os invito a que veais los diferentes parametros en una máquina virtual vuestra con:

# xe vbd-list vm-name-label=<Nombre VM> params=all

Los VBDs tienen tambien comandos extra de gestión como:

• vbd-eject/vbd-insert: Expulsa/inserta un VDI
• vbd-plug/vbd-unplug: Conecta/desconecta un VBD
• xe vbd-create: Como parametro los siguientes flags -> bootable=     device=       mode=         type=         unpluggable=  vdi-uuid=     vm-uuid=
• vbd-destroy: Elimina un VBD por UUID

No olvidemos que el principal objetivo del VBD es el enlace con el VDI. Así que ya podemos saber que VDIs tiene una máquina virtual mediante:

# xe vbd-list vm-name-label=<Nombre VM> params=vdi-name-label

VDIs a fondo

Existen tres típos en función del típo de SR (Storage Repository) que tengamos montado:

• File based VHD: Utiliza thin provisioning y no soporta almacenamiento compartido, solamente es posible usar este típo en SRs de discos locales EXT  o como recurso SR por NFS.

• LVM: La opcón predeterminada de Xenserver. Puede ser por SAN, I-SCSI o SAS. Básicamente los VDIs son representados como volumenes LVM.

• LUN por VDI: Mapeo directo de Luns contra una máquina virtual. Para eso es necesario usar pluguins especificos (NetApp, EqualLogic o StorageLink)

Podemos ver todos los parametros del VDI con:

#xe vdi-list uuid=<UUID-VDI> params=all

También tienen un montón de opciones, espacio virtual, utilización física, sr donde está alojado el vdi, y un largo etc.

Algunos comandos extra para las gestión de VDIs

• vdi-clone: Clona el VDI y lo almacena con un nuevo UUID, nuevo nombre, etc. En el mismo SR
• vdi-copy: Copia el VDI en otro SR
• vdi-import: Importa un VDI desde un fichero exportado con vm-export
• vdi-resize: Reasigna el espacio virtual del disco

Con esto, me despido por hoy, espero que haya podido enseñarte algo nuevo sobre la gestión de discos y como funcionan en XenServer y animarte a que lo veas con tus propias máquinas virtuales.

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Gracias por el apoyo.

La política de Round Robin no emite E/S de una forma simple y llanamente como su propio nombre indica.

Por defecto, cuando seleccionas el PSP – de las siglas en inglés Path Selection Plugin – de Round Robin, esta política envía 1.000 comandos E/S de disco por cada ruta antes de pasar al siguiente camino, lo cual es llamado IO Operation Limit.

En algunas configuraciones, yo diría en la gran mayoría, esta configuración por defecto no muestra la agregación de caminos en su máximo exponente porque muchas veces algunos de los miles de comandos de E/S de disco se han completado antes de que el último comando fuese enviado. Esto significa que los caminos de almacenamiento no estarán llenos (a pesar de que la cola en la cabina de almacenamiento puede ser que si este llena).

Cuando se utiliza 1 Gbit en una conexión iSCSI, muy frecuentemente la ruta física es el factor limitante en el rendimiento, y haciendo uso de varias rutas al mismo tiempo con la política de Round Robin, puede que muestre un mejor rendimiento.

Lo interesante de esta política de PSP es que puedes reducir el número de órdenes emitidas por un camino en particular, antes de pasar al siguiente camino hasta llegar a una E/S de disco, lo que garantiza que cada comando posterior se envíe por un camino diferente.

En una configuración con una cabina de almacenamiento de Dell EqualLogic, yo recomiendo un valor de 3 E/S de disco para el campo IO Operation Limit.

Para poder hacer este cambio, es necesario ejecutar el siguiente comando:

esxcli – server nmp roundrobin setconfig – device – IOPS — type iops

No obstante, ten en cuenta que el hecho de disminuir el número de IOPS presenta algunos problemas potenciales.

Mediante la difusión de las solicitudes de E/S a disco a través de varias rutas, estamos influenciando de una manera negativa la optimización de la cache de cualquier cabina almacenamiento lo que puede acabar por afectar el rendimiento de esta.

Afortunadamente, muchos de los sistemas de almacenamiento más modernos no “cachean” por puerto. No obstante, y aunque menos importante, el cambiar constantemente la E/S de disco entre las rutas disponibles representa un uso adicional de ciclos de reloj de la CPU de nuestro servidor VMware ESX/ESXi con lo que hay que tenerlo en cuenta.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Hola de nuevo, soy Jose Maria Gris y seguimos comentando el caso APD.

La foto no es un cuadro de Miró, es un masking de pintores…. (Nota del Blogger…)

Hoy vamos a ver como tenemos que hacer para que aunque tengamos o no el parche adecuado para solventar el APD, pues si nos aseguramos de quitar de forma correcta la LUN, estaremos mas tranquilos no?

El KB 1015084 nos indica paso a paso lo que hay que hacer por consola.

- Dejar de usar el datastore en cuestión

• Desregristrar las VM que estén allí registradas
• Asegurarse de que no hay scripts que están trabajando con la LUN en cuestión

- En ESX tenemos el NMP (Native Multi Path) y el MASK-PATH Plugin que es el que usamos para hacer masking con las LUNs. Para saber si están disponibles:

• # esxcfg-mpath –G

El output debe ser parecido a

• # esxcfg-mpath -G?MASK_PATH?NMP

Listamos las claimrules existentes

• # esxcli corestorage claimrule list

El output será parecido a

• # esxcli corestorage claimrule list?Rule Class Type Plugin Matches?0 runtime transport NMP transport=usb?1 runtime transport NMP transport=sata?2 runtime transport NMP transport=ide?3 runtime transport NMP transport=block?4 runtime transport NMP transport=unknown?101 runtime vendor MASK_PATH vendor=DELL model=Universal Xport?101 file vendor MASK_PATH vendor=DELL model=Universal Xport?65535 runtime vendor NMP vendor=* model=*

Añadimos una rule mediante el la siguiente instrucción:

• # esxcli corestorage claimrule add –rule  -t location -A -C -T -L -P MASK_PATH

donde -A <hba_adapter> -C <channel> -T <Target> -L <lun> define un único path. El numero de la “rule” debe ser entre 101 y 200.

Verificamos que la rule esta incluida….

# esxcli corestorage claimrule list

Y la cargamos. Así con todos los paths.

# esxcli corestorage claimrule load

Si todo ello esta correcto podemos hacer el claiming

# esxcli corestorage claiming reclaim -d

Donde <naa.id> es el identificador del device.

Con todo ello efectuado y borrados todos los paths, iremos a vCenter y nos iremos a Host > Configuration > Storage, click Refresh y el datastore desaparecerá.

Podemos deshacer el maping de la LUN desde nuestro Array.

Como ultimo paso, nos quedaría limpiar la tabla de rules

# esxcli corestorage claimrule delete –rule

Cargar

# esxcli corestorage claimrule load

Y listar para ver que todo queda limpio. Si queda alguna rule, pues a empezar el proceso de cleaning de nuevo.

Espero haya sido interesante.

Referencias :

Unpresenting a LUN containing a datastore from ESX 4.x and ESXi 4.x (1009449)

Masking a LUN from ESX and ESXi 4.x using the MASK_PATH plug-in (1009449)

Hola amigos,

Imaginaros que disponemos de una Lun en una san iSCSI del fabricante X y por necesidades de espacio desde la interfaz de administración de la san incrementamos el tamaño de la partición gestionada por LVM.

Posteriormente tendremos que realizar los siguientes pasos en XenServer para que podamos disfrutar de ese espacio adicional en la Lun.

1.- Apagamos las máquinas virtuales.

2.- Buscamos el uuid del SR

# xe sr-list

3.- Sacamos más información del SR localizado anteriomente

# xe sr-param-list uuid=”uuid” |grep PBD

4.- desadjuntamos el PBD

# xe pbd-unplug uuid=”uuid del PBD”

5.- Adjuntamos el PBD

# xe pbd-plug uuid=”uuid del PBD”

6.- Arrancamos las máquinas virtuales.

Con esto tendremos el SR redimensionado y funcionando. Como siempre espero que esta breve lectura os sea de utilidad.

Aprovecho la ocasión para desearos unas felices vacaciones a todos.

Un abrazo,