vSphere 5: What's New - Performance

Con el lanzamiento de vSphere 5 se obtienen una serie de mejoras en la performance de nuestra plataforma VMware, las cuales detallaremos a continuación.

Las mejoras de performance se dividen en 5 pilares, los cuales detallaremos brevemente:

• Mejoras a nivel de vCenter Server
• Mejoras a nivel de capacidad de computo
• Mejoras a nivel de almacenamiento
• Mejoras a nivel de networking
• Mejoras a nivel de vMotion

Mejoras a nivel de vCenter Server
vSphere 5 incluye mejoras en la escalabilidad que permite, por ejemplo, un mayor número de máquinas virtuales por clúster.  Aún con esta mayor escalabilidad, vSphere 5 incluye una serie de mejoras en la performance relacionadas a las operaciones de administración en vCenter Server, así como también en las funcionalidades relacionadas  con High Availability (HA):

• Hasta un 120% de mejora en el throughput (operaciones/minuto) de las operaciones de administración en vCenter.  Por ejemplo, en el encendido/apagado/migración/registro de máquinas virtuales.
• Una mejora del 25% al 75% en la latencia de las operaciones de administración, dependiendo del tipo de operación.
• La configuración de un cluster HA puede ser realizada hasta 9 veces más rápido en vSphere 5, dependiendo del tamaño del cluster.
• En vSphere 5 se puede realizar el failover de hasta un 60% más de máquinas virtuales, en el mismo periodo, respecto a versiones anteriores
• El tiempo mínimo de recuperación, desde la falla hasta que la primera máquina virtual es reiniciada, ha sido mejorado en un 44.4%
• El tiempo promedio para el failover de máquinas virtuales ha sido mejorado en un 14%.
• El Slot size por defecto para la CPU ahora es de solo 32Mhz, permitiendo un mayor radio de consolidación en comparación con versiones anteriores.

Mejoras a nivel de capacidad de computo

• vSphere 5 soporta hasta 32 vCPU y hasta 1TB de vMEM por máquina virtual, lo cual permite que aplicaciones Tier 1  y de misión critica alcancen una mayor performance.
• Mejoras en el scheduler de la CPU en arquitecturas Intel SMT, permitiendo una mejora del 10% al 30% en la performance de las aplicaciones, dependiendo de la carga de trabajo.
• En vSphere 5 se incluye Virtual NUMA o vNUMA, que expone la topología NUMA al sistema operativo de las máquinas virtuales, permitiendo que el sistema operativo y aplicaciones hagan un mejor uso de la arquitectura NUMA del host.  Se requiere Virtual Hardware versión 8.
• vSphere 5 permite a los usuarios configurar un caché para Swap en un disco de estado sólido o SSD.  De esta manera, cuando Transparent Page Sharing, Ballooning y la Compresión de memoria no han sido suficientes para obtener los recursos de memoria requeridos, el proceso de swapping se realizará en ésta cache en vez de utilizar un archivo normal de swap en disco.  Esto permite una mejora importante en la performance reduciendo la latencia en escenarios de escasez de memoria.

Mejoras a nivel de almacenamiento

• vSphere 5 Storage I/O control ahora soporta NFS y “shares” basados en NAS.  Esto permite regular dinámicamente el acceso de múltiples máquinas virtuales a recursos de I/O compartidos en un clúster, basados en los shares asignados a las máquinas virtuales.

Mejoras a nivel de Networking

• vSphere 5 incluye mejoras en NetIOC, donde agrega funcionalidades de QoS (802.1p) y permite la creación de Resource Pools para limitación de anchos de banda.
• vSphere 5 incluye splitRxMode, una nueva funcionalidad para dividir el costo de la replicacion de paquetes para multicast entre varias CPUs físicas, permitiendo que vSphere 5 sea una plataforma altamente escalable y eficiente para receptores de multicast.  En versiones previas, la replicación de paquetes para multicast es hecha usando un único contexto, y en escenarios con una alta densidad de máquinas virtuales por host, esto puede provocar cuellos de botella y causar perdida de paquetes.  SplitRxMode puede ser habilitado en una virtual NIC VMXNET3, y permite dividir el costo del procesamiento de paquetes recibidos en multiples contextos, mejorando  significativamente la performance de multicast.

Mejoras a nivel de vMotion

• vSphere 5 permite que vMotion sature en forma efectiva el ancho de banda de un adaptador de red 10GbE durante una migración, reduciendo los tiempos de transferencia en una operación de vMotion.
• Se permite el uso de multiples adaptadores de red para las operaciones de vMotion, donde el VMkernel balanceara la carga del trafico de vMotion, en forma transparente, sobre todas las vmknics con vMotion habilitado, tratando de saturar todas las conexiones para distribuir el trafico de vMotion, incluso en operaciones unicas de vMotion.
• Se incluye una nueva funcionalidad de “Metro vMotion” que provee de una mejor performance sobre redes con alta latencia y aumenta los limites de latencia para redes de vMotion de 5ms a 10ms.
• Se incluye soporte de Live Migration para Storage (Storage vMotion) con el uso de I/O Mirroring.  Esto permite una mayor movilidad de máquinas virtuales, mantenimiento con zero downtime, y balanceo de carga de almacenamiento manual y automatico.

Conclusión

Como podemos ver, vSphere 5 incluye un numero importante de mejoras a nivel de performance, lo cual nos permite virtualizar aplicaciones de cualquier envergadura, tanto en pequeños ambientes, como en grandes implementaciónes con aplicaciones de mision critica y Tier-1.

Para mayor información, pueden revisar el siguiente White Paper de VMware con todo el detalle de las novedades de vSphere 5, relacionados con la performance:

http://www.vmware.com/files/pdf/techpaper/Whats-New-VMware-vSphere-50-Performance-Technical-Whitepaper.pdf

Read More

VMware vSphere 5 /iSCSI: Upgrade de datastore a VMFS-5

Finalizando con la configuración iSCSI en vSphere 5, a continuación revisaremos los pasos para realizar el upgrade de un Datastores VMFS-3 a VMFS-5

Introducción

vSphere 5 incluye VMFS-5, una nueva versión del sistema de archivos VMware para los Datastores, que provee mejoras en la performance y escalabilidad. Entre estas mejoras podemos mencionar:

• Soporte para LUNs de más de 2TB
• Mejoras en la escalabilidad usandi VAAI
• Estandarización del Block Size en 1MB para los Datastores VMFS formateados en VMFS-5
• Sencillo proceso de Upgrade desde VMFS-3
• Posibilidad de Montar y Desmontar Datastores a traves del vSphere Client.

Los dispositivos de almacenamiento soportados por los hosts, pueden utilizar particiones con formato MBR (Master Boot Record), o GPT ( GUID Particion Table).

Cuando se crea un nuevo datastore VMFS-5 en un dispositivo de almacenamiento en blanco, o se sobrescribe un datastore VMFS-3 existente, el dispositivo es formateado con GPT, el cual soporta tamaños mayores a 2TB, llegando incluso a los 64TB.

Los Datastores VMFS-3 continuan usando el formato MBR, por lo que estos Datastore están limitados a 2TB de capacidad, incluso si el volumen donde se está creando el Datastore, tenga una capacidad superior. Para superar esta restriccion, se debe actualizar el Datastore VMFS-3 a VMFS-5.

Antes de realizar el Upgrade, hay que asegurarse de remover cualquier particion que no sea reconocida por ESXi, como por ejemplo las particiones que utilicen el formato EXT2 o EXT3. De lo contrario, el host no podrá formatear el volumen con GPT y el Upgrade fallará.

Cuando se realiza el Upgrade de VMFS-3 a VMFS-5, el mecanismo de file-locking de ESXi se asegura que ningun proceso este accediendo al datastore VMFS que está siendo convertido. El host preserva todos los archivos del Datastore, quedando estos intactos luego del Upgrade.

El Upgrade de VMFS-3 a VMFS-5 es un proceso que no puede ser deshecho, por lo que luego que el datastore VMFS ha sido convertido a VMFS-5, este no puede ser revertido nuevamente a VMFS-3.
Pre-requisitos.

• Para realizar un Upgrade desde VMFS-2, primero este Datastore debe ser convertido a VMFS-3, y luego a VMFS-5. Los datastores VMFS-2 no pueden ser convertidos directamente a VMFS-5
• Si el Datastore ha sido convertido previamente de VMFS-2 a VMFS-3, se debe asegurar de que el Block Size no exceda los 8MB, de lo contrario el proceso de Upgrade a VMFS-5 no podrá llevarse a cabo.
• Todos los hosts que tengan acceso a este datastore, deben soportar el formato VMFS-5. Esto quiere decir que los hosts deben encontrarse al menos en la versión ESXi 5.0.
• Respaldar el volumen VMFS-3 antes de realizar el Upgrade. Como el proceso de Upgrade no puede ser revertido, este respaldo nos da un mecanismo de "vuelta atras".
• Verificar que no hayan hosts adicionales accediendo al volumen VMFS.
  
  

Upgrade de Datastore

A continuación se detalla el proceso de Upgrade de VMFS-3 a VMFS-5.

Con esto finalizamos la serie de articulos dedicados a la configuración de almacenamiento iSCSI en vSphere 5.

Read More

VMware vSphere 5 /iSCSI: Agregar un Datastore y Configurar Multipathing

Siguiendo con la configuración iSCSI en vSphere 5, a continuación revisaremos los pasos para agregar Datastores a un host ESXi. Dentro del mismo procedimiento se detallarán los pasos para configurar la politica de Multipath en cada Datastore.

Para mantener una conexión constante entre un host ESX/ESXi y su storage, VMware soporta funcionalidades de multipathing. Multipathing es una tecnica que permite utilizar más de una ruta fisica(path) para transferir datos entre el host y un dispositivo de almacenamiento externo.

En caso de una falla de cualquier elemento en una red SAN, ya sea un adaptador de red, un switch o un cable, el host puede cambiar a otra ruta fisica (path), la cual no utiliza ninguno de los componentes con problemas. Este proceso de cambio de ruta es conocido como Path Failover.

Adicionalmente al Path Failover, Mutipathing provee balanceo de carga, distribuyendo la carga de I/O entre multiples rutas fisicas. El balanceo de carga reduce o remueve potenciales cuellos de botella.

El I/O de una VM puede ser retrasado por hasta 60 segundos mientras se realiza el proceso de Path Failover. Estas demoras le permiten a la SAN estabilizar estabilizar su configuracion despues de los cambios en la topologia. Generalmente estas demoras en el I/O pueden ser más extensas en arreglos activo-pasivos que en arreglos activo-activos. En algunos casos puede ser necesario realizar configuraciones adicionales en las maquinas virtuales para evitar problemas en los servicios producto de estas demoras en el I/O.

Para administrar Multipathing, VMware utiliza una capa especial de VMkernel, la PSA (Pluggable Storage Architecture), que es un framework abierto y modular, que permite coordinar las operaciones simultaneas de multiples plug-ins de multipathing (MPP).

El plug-in de multipathing que ESX/ESXi provee por defecto es el "VMware Native Multipathing Plug-in" o NMP, el cual es un modulo extensible que administra sub-plugins. Hay dos tipo de sub-plugins de NMP:

• Storage Array Type Plug-Ins (SATPs). SATP se preocupa de manejar los Path Failovers para un arreglo de Storage.
• Path Selection Plug-Ins (PSPs). PSP se preocupa de determinar cual ruta fisica es usada para emitir un requerimiento I/O a un dispositivo de Storage.

Los plug-ins SATP y PSP pueden ser provistos por VMware o por software de terceros. Si se requieren funcionalidades adicionales de Multipathing, un software de terceros puede proveer un MPP para ejecutarse como complemento o reemplazo de NMP (Plug-in por defecto de VMware).

NMP asigna un PSP por defecto para cada dispositivo logico basado en el SATP asociado con la ruta fisica para ese dispositivo, sin embargo esta asignacion puede ser sobrescrita. Por defecto VMware NMP soporta los siguientes PSP:

• MRU (Most Recently Used): Selecciona la ruta que el host uso más recientemente para acceder a un dispositivo de storage. Si esta ruta llega a encontrarse no disponible, el host cambia a una ruta alternativa y la continua utilizando mientras ésta se encuentre disponible. MRU es la politica de multipathing por defecto para arreglos activo-pasivo.
• Fija o Fixed: Utiliza la ruta designada como preferida si esta ha sido configurada. De lo contrario utiliza la primera ruta descubierta que se encuentre funcionando correctamente. Si el host no puede usar la ruta preferida, selecciona una ruta alternativa disponible en forma aleatoria. El host vuelve a utilizar la ruta preferida tan pronto como dicha ruta vuelva a encontrarse disponible. Esta politica es la politica por defecto para arreglos activo-activo.
• Round Robin: Utiliza un algoritmo de seleccion de rutas que va rotando a través de todas las rutas activas disponibles, permitiendo balanceo de carga a traves de las rutas. Este algoritmo es recomendado para arreglos activo-activo, o sistemas ALUA.

 Agregar Datastores y Configurar una politica de Multipathing

Al completar estos pasos ya tenemos habilitada nuestra red iSCSI, incluyendo la configuración inicial del iniciador iSCSI por Software, y hemos agregado un Datastore VMFS-3 y VMFS-5. En los siguientes artículos detallaremos los pasos para la migración de datastores VMFS-3 a VMFS-5.

Read More

VMware vSphere 5 /iSCSI: Habilitación del Iniciador iSCSI

Siguiendo con la configuración iSCSI en vSphere 5, a continuación revisaremos los pasos para habilitar el iniciador iSCSI por software. Dentro del mismo procedimiento se detallarán los pasos para realizar el Port Binding, y se explicará como agregar un target iSCSI en la configuración del iniciador.

Para acceder a un Target iSCSI, los hosts utilizan Iniciadores iSCSI. Este iniciador transporta los requerimientos y respuestas SCSI, encapsulandolos en el protocolo iSCSI, entre el host y el Target iSCSI.
Los hosts en vSphere 5 soportan diferentes tipos de iniciadores:

• Adaptador iSCSI por Software: Es un adaptador incluido en el VMkernel, que permite al host conectarse a un Storage iSCSI a través de adaptadores de red standard. Esta opción permite utilizar la tecnologia iSCSI sin comprar hardware especializado.
• Adaptador iSCSI por Hardware: Es un adaptador de teceros que libera al host del procesamiento de red y iSCSI. Estos se dividen en dos categorias:
  
  • Dependientes: Dependen de la red de VMware, y de la configuración iSCSI y las interfaces de administración provistas por VMware. Puede ser una tarjeta que incluye un adaptador de red standard y funcionalidades de iSCSI offload por el mismo puerto. Estas funcionalidades de offload dependen de la configuración de red del host para obtener la IP, MAC, y otros parametros usados por las sesiones iSCSI
  • Independientes: Implementan su propia configuración de red y iSCSI, asi como sus propias interfaces de administración. Puede ser una tarjeta que presenta solo funcionalidades de iSCSI offload. Estas funcionalidades de offload tienen configuraciones independientes que asignan IP, MAC y otros parametros usados por las sesiones iSCSI.

Una SAN iSCSI utiliza una arquitectura cliente servidor, donde el cliente llamado iniciador iSCSI opera en el host. Este cliente inicia las sesiones iSCSI emitiendo comandos SCSI y trasmitiendolos, encapsulados en el protocolo iSCSI, a un servidor conocido como iSCSI target. El iSCSI target representa un sistema de almacenamiento fisico en la red y responde a los comandos del iniciador transmitiendo los datos iSCSI requeridos.

VMware utiliza puertos VMkernel como los iniciadores de sesiones, por lo que debemos configurar cada puerto que queramos utilizar como un camino (path) para el Storage. Esto es independiente del numero de NICs o HBAs iSCSI, pero en la mayoria de los casos será una relación uno a uno entre los puertos VMkernel y las interfaces disponibles. Una vez que las sesiones a la SAN son iniciadas, VMware NMP se encargará de balancear la carga y distribuir el trafico I/O entre todos los caminos disponibles.

Los volumenes en una SAN iSCSI pueden ser utilizados por ESX/ESXi como un Datastore VMFS o un Raw Device Map (RDM). El iniciador iSCSI por software utiliza los puertos VMkernel que fueron creados y establece una sesion a la SAN y a los volumenes. A partir de vSphere 4 se pueden utilizar multiples caminos (multipathing) a la SAN para un mayor ancho de banda y performance.

Cada puerto VMkernel se encuentra asignado a un adaptador fisico. Dependiendo de la plataforma se pueden crear hasta 8 sesiones simultaneas a un volumen. Para una implementación estandar se recomienda el uso de una relación uno a uno (1:1) entre los puertos VMkernels y las interfaces fisicas, o sea si existen 4 interfaces fisicas, se crearía 4 puertos VMkernel, y se asociaria cada uno de estos puertos a una NIC separada. Este esquema puede ser expandido dependiendo del numero de NICs que se tengan disponibles.
A medida que la infraestructura va creciendo se pueden establecer multiples sesiones a la SAN suscribiendo más puertos VMkernel a las interfaces fisicas existentes. Esto establece multiples sesiones a un volumen, pero aun utiliza las mismas interfaces fisicas para acceder a dicho volumen.

Habilitación de Iniciador iSCSI

 

Al completar estos pasos ya tenemos habilitada nuestra red iSCSI, incluyendo la configuración inicial del iniciador iSCSI por Software. En los siguientes articulos detallaremos los pasos para la creación de los datastores VMFS creados sobre LUNs iSCSI, y como migrar datastores VMFS-3 a VMFS-5.

Read More

VMware vSphere 5 /iSCSI: Configuración de la red para iSCSI

Siguiendo con la configuración iSCSI en vSphere 5, a continuación revisaremos la configuración de red requerida para iSCSI.

Si se usa un adaptador iSCSI por Software o por Hardware, se debe configurar la red para iSCSI antes de poder habilitar y configurar los adaptadores iSCSI. La configuración de red para iSCSI incluye abrir los puertos VMkernel para el trafico entre el adaptador iSCSI y la interfaz fisica.

Dependiendo del numero de interfaces fisicas que se utilicen para el trafico iSCSI, la configuración de la red puede variar:

• Si se tiene una unica NIC fisica, se crea un puerto iSCSI sobre un vSwitch conectado a dicha NIC. VMware recomienda que se designe un adaptador de red separado para iSCSI. Este adaptador debe ser de 1Gbit o superior.
• Si se tiene dos o más NIC fisicas, se deben crear puertos iSCSI por cada NIC fisica y usar dichas NICs para el multipathing iSCSI.

Las NIC fisicas deben estar en la misma subred que el Storage iSCSI para que el host pueda conectarse a este.

El adaptador iSCSI y las NICs fisicas se conectan a traves de un adaptador VMkernel virtual, tambien conocido como adaptador de red virtual o puerto VMkernel. Se crea un adaptador VMkernel (vmk) en un vSwitch utilizando una relacion 1:1 entre cada adaptador de red fisico y virtual.

Para lograr esta relacion 1:1 cuando se tienen multiples NICs, se designa un vSwitch separado por cada par adaptador fisico-virtual.

En forma alternativa, se pueden agregar todas las NICs y puertos VMkernel en un unico vSwitch Standard. En este ultimo caso, se debe sobrescribir la configuración de red por defecto, para asegurarse de que cada adaptador VMkernel esta asociado solo a una NIC fisica.

Configuración de red iSCSI

A continuación realizamos la creación del vSwitch para iSCSI, asi como los puertos VMkernel para cada una de las interfaces fisicas existentes.

Si se tiene una unica interfaz de red fisica para el trafico iSCSI, los puertos VMkernel que se creen deberan asignarse a esa unica interfaz de red.

Creación del vSwitch para iSCSI

Al completar estos pasos ya tenemos la primera parte de la configuración requerida para habilitar una red iSCSI. En los siguientes articulos detallaremos como habilitar el iniciador iSCSI por software, y como asignar los puertos VMkernel a dicho iniciador (Port Binding).

Read More

VMware vSphere 5.0: Conexión a una SAN iSCSI

Hace algunos dias se realizó el lanzamiento de la nueva plataforma de virtualizacion en VMware, vSphere 5.0, con importantes mejoras en lo que a almacenamiento se refiere. Una de estas mejoras, es la facilidad de realizar la configuración iSCSI completamente a traves del vSphere Client, sin la necesidad de utilizar la linea de comandos como era requerido en vSphere 4.

En los siguientes articulos detallaremos el proceso de configuración de vSphere 5, de manera de poder utilizar una SAN iSCSI como repositorio para los Datastores VMFS. Incluiremos la configuración requerida a nivel de red, iSCSI y multipathing, entre otras.

Si quieren conocer el proceso de configuración de iSCSI en vSphere 4, lo pueden ver en el siguiente link:
http://www.patriciocerda.com/2010/10/vmware-vsphere-41-conexion-una-san.html

Introducción

Es posible utilizar ESX/ESXi en conjunto con una SAN, que es basicamente una red especializada que conecta sistemas computacionales con subsistemas de almacenamiento de alta performance. El uso de una SAN, ya sea iSCSI o de Fiber Channel, provee una consolidacion del almacenamiento, al mismo tiempo que mejora la disponibilidad y facilita la recuperacion ante desastres. Por otro lado, el uso de una SAN como almacenamiento compartido es un requerimiento para poder crear un Cluster HA/DRS en VMware (aunque como alternativa se puede utilizar una NAS, o el nuevo vStorage Appliance).

Una SAN iSCSI utiliza una conexión Ethernet entre servidores y un sistema de almacenamiento de alta performance. Los componentes de una SAN incluyen HBAs (host bus adapters) iSCSI o interfaces de red (NICs) en el servidor, switches y routers que transportan el trafico del storage, Storage Processors (SP o controladoras) y sistemas de discos.

Iniciadores iSCSI

Para acceder a un Target iSCSI, los hosts utilizan Iniciadores iSCSI. Este iniciador transporta los requerimientos y respuestas SCSI, encapsulandolos en el protocolo iSCSI, entre el host y el Target iSCSI.
Los hosts en vSphere 5 soportan diferentes tipos de iniciadores:

• Adaptador iSCSI por Software: Es un adaptador incluido en el VMkernel, que permite al host conectarse a un Storage iSCSI a través de adaptadores de red standard. Esta opción permite utilizar la tecnologia iSCSI sin comprar hardware especializado.
• Adaptador iSCSI por Hardware: Es un adaptador de teceros que libera al host del procesamiento de red y iSCSI. Estos se dividen en dos categorias:
  
  • Dependientes: Dependen de la red de VMware, y de la configuración iSCSI y las interfaces de administración provistas por VMware. Puede ser una tarjeta que incluye un adaptador de red standard y funcionalidades de iSCSI offload por el mismo puerto. Estas funcionalidades de offload dependen de la configuración de red del host para obtener la IP, MAC, y otros parametros usados por las sesiones iSCSI
  • Independientes: Implementan su propia configuración de red y iSCSI, asi como sus propias interfaces de administración. Puede ser una tarjeta que presenta solo funcionalidades de iSCSI offload. Estas funcionalidades de offload tienen configuraciones independientes que asignan IP, MAC y otros parametros usados por las sesiones iSCSI.

.

Como funcion el iniciador iSCSI por software?

Una SAN iSCSI utiliza una arquitectura cliente servidor, donde el cliente llamado iniciador iSCSI opera en el host. Este cliente inicia las sesiones iSCSI emitiendo comandos SCSI y trasmitiendolos, encapsulados en el protocolo iSCSI, a un servidor conocido como iSCSI target. El iSCSI target representa un sistema de almacenamiento fisico en la red y responde a los comandos del iniciador transmitiendo los datos iSCSI requeridos.

VMware utiliza puertos VMkernel como los iniciadores de sesiones, por lo que debemos configurar cada puerto que queramos utilizar como un camino (path) para el Storage. Esto es independiente del numero de NICs o HBAs iSCSI, pero en la mayoria de los casos será una relación uno a uno entre los puertos VMkernel y las interfaces disponibles. Una vez que las sesiones a la SAN son iniciadas, VMware NMP se encargará de balancear la carga y distribuir el trafico I/O entre todos los caminos disponibles.

Los volumenes en una SAN iSCSI pueden ser utilizados por ESX/ESXi como un Datastore VMFS o un Raw Device Map (RDM). El iniciador iSCSI por software utiliza los puertos VMkernel que fueron creados y establece una sesion a la SAN y a los volumenes. A partir de vSphere 4 se pueden utilizar multiples caminos (multipathing) a la SAN para un mayor ancho de banda y performance.

Cada puerto VMkernel se encuentra asignado a un adaptador fisico. Dependiendo de la plataforma se pueden crear hasta 8 sesiones simultaneas a un volumen. Para una implementación estandar se recomienda el uso de una relación uno a uno (1:1) entre los puertos VMkernels y las interfaces fisicas, o sea si existen 4 interfaces fisicas, se crearía 4 puertos VMkernel, y se asociaria cada uno de estos puertos a una NIC separada. Este esquema puede ser expandido dependiendo del numero de NICs que se tengan disponibles.

A medida que la infraestructura va creciendo se pueden establecer multiples sesiones a la SAN suscribiendo más puertos VMkernel a las interfaces fisicas existentes. Esto establece multiples sesiones a un volumen, pero aun utiliza las mismas interfaces fisicas para acceder a dicho volumen.

Tipos de Storage iSCSI

ESXi soporta diferentes tipos de arreglos de Storage:

• Storage Activo-Activo: Permite acceso a las LUNs en forma simultanea a traves de todos los Puertos de Storage disponibles, sin una degradación de performance significativa. Todos los paths son activos todo el tiempo, a menos que un path falle.
• Storage Activo-Pasivo: Corresponde a un storage en la cual un Storage Procesos provee acceso en forma activa a una LUN determinada. El otro SP actua como un respaldo para la LUN, y puede proveer acceso activo a otra LUN. Si el acceso a traves de un SP falla, uno de los SP pasivos puede ser activado.
• Storage Asimetrico: Soporta Asymmetric Logical Unit Access (ALUA). Los Storage con soporte ALUA proveen diferentes niveles de acceso por puerto. ALUA le permite a los hosts determinar el estado de los puertos del Target y priorizar los paths. El host utiliza algunos de los paths activos como Primarios, mientras que trata al resto como Secundarios.
• Storage de Puerto Virtual: Permite acceso a todas las LUNs disponibles a través de un unico puerto virtual. Estos son basicamente Storages activo-activo, pero esconden sus multiples conexiones a traves de un unico puerto virtual. Los mecanismos de Multipathing no pueden detectar las conexiones multiples al Storage. Estos tipos de Storage manejan el Port Failover y el balanceo de conexiones en forma transparente, lo cual es conocido frecuentemente como Transparent Failover.

Nuevas caracteristicas del iniciador iSCSI en vSphere 5

VMware vSphere 5 ofrece mejoras sobre el iniciador iSCSI por Software, junto con la conectividad para SAN iSCSI.

• Iniciador iSCSI por Software: Este iniciador debe ser agregado entre los Storage Adapters, ya que no viene incluido por defecto.
• Port Binding: Ahora es posible realizar las operaciones de Port Binding completamente a traves del vSphere Client, sin la necesidad del uso de la linea de comandos como se estilaba en vSphere 4.
• Jumbo Frames: Ahora es posible habilitar Jumbo Frame, tanto en los Virtual Switch como en los puertos VMkernel, completamente a traves de vSphere Client.

Buenas Practicas

• Se recomienda el uso de un Switch de red Gigabit Ethernet o 10GE separado para el manejo del trafico iSCSI. Se recuerda que el trafico en una red iSCSI no se encuentra encriptado.
• Se recomienda conectar cada host ESXi a 2 Switches iSCSI, cada uno de estos conectados a todas las controladoras disponibles en el Storage.  Esto permite contar con alta disponibilidad y balanceo de carga en las conexiones iSCSI.
• Los servidores, Switches y puertos de las controladoras del Storage deben estar en el mismo segmento de red
• Se recomienda tener más de una HBA iSCSI o NIC dedicada para el trafico iSCSI.
• Se recomienda habilitar Jumbo Frame para mejorar la performance en la comunicación iSCSI. Se recuerda que la habilitación de Jumbo Frame debe realizarse end-to-end.

Requisitos

Para la configuración de iSCSI en vSphere existen algunos requisitos que se detallan a continuación:

• Al menos una HBA iSCSI o NIC para el trafico iSCSI. En nuestro ambiente utilizaremos 2 NICs para la configuración iSCSI.
• Un segmento de IP dedicado para el trafico iSCSI. En nuestro caso utilizaremos el segmento no ruteable 10.10.10.x
• Verificar que el Storage está soportado por ESXi.
• Se debe utilizar solo un datastore VMFS por LUN.
• ESXi no soporta multipathin cuando se combinan adaptadores por Hardware independientes, con adaptadores por Hardware dependientes, o adaptadores por Software.

Configuración de iSCSI en vSphere

Habiendo entendido la arquitectura de una SAN iSCSI y sus requerimientos y buenas practicas, a continuación detallaremos el proceso de configuración de iSCSI en VMware vSphere 5.0:

• Configuración de Red para iSCSI y habilitación de Jumbo Frames
• Habilitación del iniciador iSCSI y Port Binding
• Agregar Datastores y configurar Multipathing
• Upgrade de VMFS-3 a VMFS-5

Para una documentación más detallada del proceso y que cubra todos los escenarios, pueden revisar la documentación oficial de VMware.

Read More

vSphere 5: What's New - Storage

Hace solo un par de dias se lanzó vSphere 5, y en este blog publiqué un resumen de lo nuevo que viene en vSphere 5.

En esta ocasión, veremos más en profundidad las mejoras que incluye vSphere 5 desde el punto de vista del Almacenamiento.

VMFS-5
vSphere 5 trae una nueva versión de su sistema de archivos VMFS, el cual contiene importantes cambios y mejoras en su arquitectura, mejorando la escalabilidad y performance respecto a la versión anterior, VMFS-3.

vSphere incluye mecanismos para la migración de VMFS-3 a VMFS-5 en un proceso consistente sin interrupciones.  Durante el proceso de Upgrade, los volumenes migrados a VMFS-5 mantendrán el Block Size configurado, debido a que modificar este parametro requeriría formatear el volumen.

VMFS incluye las siguientes mejoras:

• Soporte de dispositivos de hasta 64TB. Una gran mejora considerando el limite de 2TB impuesto en VMFS-3 (sin considerar los extents)
• Block Size unificado de 1MB, que reduce la complejidad desde el punto de vista de la arquitectura y la operacion, mientras aun se mantienen la escalabilidad y flexibilidad que existia previamente con Block Sizes más grandes.
• Mecanismo mejorado de Sub-bloques.  Permite una mayor escalabilidad, reduciendo el overhead asociado con los archivos pequeños.  VMFS-5 es capaz de asignar hasta 30.000 sub-bloques de 8KB para archivos como archivos de Logs y metadata (Ej. archivos .vmx).

A continuación una cuadro que nos permite comparar los cambios en la arquitectura entre VMFS-3 y VMFS-5

Todo esto permite soportar volumenes más grandes, de hasta 64TB, y una mayor densidad de máquinas virtuales.

Storage DRS

Un desafio permamente en una infraestructura virtual, es el monitoreo de la capacidad de los datastores, y de la carga de I/O.

Durante la creación de MV y Virtual Disks, es frecuente ver que la selección de cual Datastore utilizar está dado por una selección aleatora, lo cual puede llevar a una sobreutilización de algunos datastores, mientras otros practicamente no son utilizados.

Para enfrentar estos desafios, vSphere 5 incluye una caracteristica llamada Storage DRS, la cual provee de una asignación inteligente de datastore para las máquinas virtuales, y mecanismos de balanceo de carga entre los datastores, basados en espacio disponible y en capacidad de I/O.

Se crea un nuevo objeto de inventario en vCenter, llamado Datastore Cluster, el cual es la base de Storage DRS.  Un Datastore Cluster es un conjunto de datastores agrupados en una unica unidad.
Cuando se crea un Datastore Cluster, sDRS puede gestionar los recursos de almacenamiento en forma similar a como DRS gestiona los recursos de CPU y Memoria en un cluster.

Respecto a las recomendaciones de ubicación inicial para las MV provistas por Storage DRS, al momento de crear una MV, se puede seleccionar un Datastore Cluster como la ubicación para la MV y/o Virtual Disks, en vez de la seleccion de Datastore individual que se realizaba tradicionalmente.  Storage DRS se asegura además que la ubicación inicial de las MV esté acorde con la utilización actual de los Datastores, y la carga de I/O en cada uno de estos, reduciendo el riesgo de cuellos de botella en las operaciones de I/O, y el consiguiente impacto en la performance de las máquinas virtuales.

Respecto a las recomendaciones de balanceo de carga, estas son hechas cuando uno o más datastores en un Datastore Cluster, exceden los umbrales previamente definidos en la utilización de espacio, o en la latencia de las operaciones de I/O (15ms por defecto).  Estos Umbrales son definidos durante la creación del Datastore Cluster, y pueden ser modificados en el tiempo.

Para realizar recomendaciones, sDRS aplica los mecanismos de reporte de utilización de Datastores provistos por vCenter Server (y que ya estaba disponible en vSphere 4), a la vez que la carga de I/O es evaluada, por defecto, cada 8 horas.  Cuando uno de los umbrales es superado, sDRS calcula todos los movimientos posibles para balancear la carga, considerando ademas el costo y beneficio de dichas migraciones.

Storage DRS incluye además, asi como el DRS tradicional, reglas de afinidad y anti-afinidad, asi como el uso del Modo de Mantenimiento.  Esto permite controlar cuales virtual disks debieran o no ser ubicados en el mismo datastore en un Datastore Cluster.  Por defecto, los virtual disks de una VM son mantenidos juntos en el mismo Datastore.  Storage DRS ofrece 3 tipos de reglas de afinidad.

• Anti-Afinidad de VMDK, donde una los Virtual Disks de una MV son ubicados en diferentes datastores.
• Afinidad de VMDK, donde los virtual disks de una MV son mantenidos juntos en un mismo datastore
• Anti-afinidad de VM, donde 2 MV especificas, incluyendo sus Virtual Disks, son ubicadas en diferentes datastores.

Adicionalmente, Storage DRS ofrece el Modo de Mantenimiento de un Datastore, el cual permite liberar un Datastore especificado, de todas las MV y Virtual Disks que este contenga, a los datastores restantes en el Datastore Cluster.

Storage DRS funciona con Datastores VMFS y NFS, pero estos no pueden ser mezclados en un unico Datastore Cluster.

vSphere Storage APIs - Storage Awareness

Es un nuevo conjunto de APIs que le permite a vCenter Server detectar las capacidades de los datastores/LUNs del arreglo de Storage, haciendo mucho más facil seleccionar el datastore para la ubicación inicialde una MV, o incluso facilitando el proceso de creación de un Datastore Cluster.

Las capacidades del Storage, como el nivel de RAID, Thin o Thick Provisioning, Replicación, etc., es visible dentro de vCenter Server utilizand estas APIS.

Profile-Driven Storage
Permite una ubicación rapida e inteligente de una MV en un Datastore, basado en SLAs, Disponibilidad, Performance u algún otro requisito.

Usando Profile-Driven Storage, diferentes capas, o Tiers, pueden ser requeridos por un perfil de storage de una MV.  Estos perfiles son usados durante la provisión de una MV, durante el clonado, y durante las operaciones de Storage vMotion, asegurandose que solo aquellos Datastores o Datastores Clusters que cumplen con el perfil de storage de la VM, se encuentran disponibles para dicha VM.

Con esto, uno puede definir una serie de perfiles (tiers) de MV, cada uno con ciertas caracteristicas de Disponibilidad, Performance, Capacidad, Costo, etc., y aplicarlos a diferentes MV automatizando la selección del Datastore a utilizar, y asegurando que dichas MV solo utilicen Datastores o Datastore Clusters que cumplan con dicho perfil.

Profile-Driven Storage se integra completamente con "vSphere Storage APIs - Storage Awareness", e incluye soporte para Storage NFS, iSCSI y FC que se encuentren en la HCL.

vCenter Server permite además un chequeo sencillo del estado de cumplimiento de las máquinas virtuales y sus virtual disks asociados.

Como resultado, la gestion de capas (tiers) de storage, el provisionamiento, migración, clonación y ubicación inicial de MV en vSphere, se ha vuelto más eficiente y más amigable.

Iniciador por software para Fibre Channel over Ethernet (FCoE)
Si bien vSphere 4 ya soportaba FCoE, vSphere 5 da un paso más allá introduciendo un adaptador FCoE por software, equivalente al iniciador iSCSI por Software.

El adaptador FCoE por software requiere de un adaptador de red que soporte capacidades parciales de FCoE offload.

Mejoras en el iniciador iSCSI
Si bien con vSphere 4, el iniciador iSCSi por software fue completamente rescrito y optimizado por performance, la configuración solo era posible a traves de la linea de comandos, y era considerada una tarea "dificil" =D

Para enfrentar esto, vSphere 5 incluye la posibilidad de configurar iSCSI completamente a través de vSphere Client. Incluso la habilitación de Jumbo Frames es ahora posible de realizar utilizando vSphere Client.

vSphere Storage I/O Control
En vSphere 4 se introdujo inicialmente esta funcionalidad para proveer de priorización de I/O de MV corriendo en un cluster VMware, que tenia acceso a almacenamiento compartido iSCSI o FC.  Este tipo de control estaba basado en Shares y limites, muy similar a lo que existe para el control de los recursos de CPU y Memoria.

vSphere 5 extiende esta funcionalidad para proveer de Shares y limites de I/O para datastores VMFS.  Con esto podriamos lograr que ninguna MV sea capaz de crear un cuello de botella en un ambiente VMware, sin importar el tipo de almacenamiento utilizado.

vSphere Storage APIs – Array Integration

VAAI fue incluido ya en vSphere 4.1 permitiendo liberar al hypervisor de operaciones como:

• Full Copy, permitiendo que el Storage haga las copias completas dentro del arreglo.
• Block Zeroing, permitiendo al arreglo ejecutar operaciones de Zeroing en un gran numero de bloques
• Locking asistido por hardware, lo que provee de un mecanismo alternativo para proteger la metadata de VMFS.

En vSphere 5.0, el soporte VAAI ha sido mejorado adicionado nuevas capacidades:

• vSphere Thin Provisioning, permitiendo la reclamación del espacio no utilizado cuando un archivo es borrado o removido del datastore con Storage vMotion, y el monitoreo del espacio usado por LUNs con Thin Provisioning, evitando situaciones en que una LUN se pueda quedar sin espacio debido a la sobresuscripción de Storage.

• Aceleracion de hardware para NAS, lo cual permitirá un provisionamiento más rapido, y el uso de Virtual Disks en formato Thick (en vSphere 4 un Virtual Disk en un Storage NAS era creado con Thin Provisioning por defecto, no permitiendo el uso de discos Thick) utilizando dos nuevas funcionalidades VAAI:
• Full File Clone, similar a Full Copy, que permite que los virtual disks sean clonados en un dispositivo NAS.
• Espacio Reservado, que permite la creación de virtual disks en formato Thick en una NAS.

• Estandarizacion SCSI para cumplimiento de T10 para Full Copy, Block Zeroing y Locking asistido por Hardware.

vSphere Storage vMotion

Incluido inicialmente en vSphere 4, permite la migración en caliente de los discos virtuales de una MV desde un datastore a otro, sin downtime o perdida de servicio.

vSphere 5 ha incluido una serie de mejoras para que el proceso de Storage vMotion sea mas eficiente, permitiendo ademas la migración de MV que contengan Snapshots, y la migración de Linked Clones (View, Lab Manager).

Storage vMotion en vSphere 5 incluye un nuevo proceso de migración a traves del uso de una caracteristica llamada Mirror Mode, la cual permite una copia de bloques desde el disco de origen al disco de destino, espejando los I/Os de bloques copiados.  Esto mejora la eficiencia de Storage vMotion, logrando además que los tiempos de migración sean predecibles, facilitando la planificación de las migraciones.

El mirror driver se habilita por MV y reside dentro del VMKernel  Cuando el sistema operativo en la máquina virtual que está siendo migrada con Storage vMotion, inicia una operacion de escritura a un bloque ya copiado, el Mirror Driver espejara en forma sincrona esta operacion de escritura.

Espero que les haya sido de utilidad, y les haya aclarado un poco sobre las nuevas funcionalidades de vSphere 5 enfocadas al Almacenamiento.

Read More

VMware vSphere: Que tipo de disco utilizar en nuestra VM?

Antes de crear una máquina virtual debemos decidir el tipo de discos que utilizaremos, y esta decición dependerá de los requerimientos especificos de cada máquina virtual.

Disco RDM o VMDK?
Para la mayoría de los casos se recomienda utilizar discos virtuales VMDK, a menos que exista una necesidad especifica, como crear un Cluster MSCS, que requiera el uso de discos RDM.

• Los discos VMDK son más portables
• Los discos VMDK son más faciles de redimensionar.
• Hay menos complejidad administrativa con discos VMDK.
• Los discos VMDK son más faciles de respaldar y recuperar.
• Es más sencillo clonar MV con discos VMDK.
• Facilidad para el uso de Snapshots.

Tanto los discos VMDK como los discos RDM tienen caracteristicas similares de performance, por lo que esto no debiera ser un factor relevante a la hora de definir el tipo de discos a utilizar.  Para una comparación de performance pueden revisar el withepaper "Performance Characterization of VMFS and RDM Using a SAN".

En que casos podemos necesitar utilizar discos RDM?

• Para configurar un Cluster MSCS en una configuración Cluster Across Boxes.
• Para configurar una MV para usar NPort ID Virtualization (NPIV)
• Para utilizar herramientas de administración nativas de un Storage SAN.  Por ejemplo, realizar Snapshots a nivel de Storage, Replicación  a nivel de Storage, etc.
• Si requerimos adjuntar una LUN existente a una MV, sin que esta sea formateada como un Datastore VMFS.  Por ejemplo, adjuntar la LUN de un FileServer.  Esto puede ser de utilidad con el fin de evitar además la migración de grandes volumenes de datos a un disco VMDK durante una conversión P2V.
• Para eliminar potenciales problemas de compatibilidad o permitir que las aplicaciones se ejecuten en un ambiente virtualizado sin perder ninguna funcionalidad.
• Para ejecutar Software de administración de SAN desde la MV, y este tiene impacto directo en la LUN.

RDM en Compatibilidad Virtual o Fisica?

En caso de decidir utilizar discos RDM, se debe decidir además si utilizar el modo de Compatibilidad Virtual o el modo de Compatibilidad Física.

• Modo de Compatibilidad Virtual: Este modo virtualiza completamente el dispositivo adjunto, el cual aparece en  la máquina virtual como un disco virtual de un volumen VMFS.  Este modo provee de los beneficios de VMFS, como la protección de datos y el uso de Snapshots.
• Modo de Compatibilidad Física: Este modo provee de acceso a la mayoria de las caracteristicas de hardware del dispositivo adjunto.  VMKernel pasa todos los comandos SCSI al dispositivo, exponiendo de este modo todas las características fisicas del hardware subyacente.

El modo de Compatibilidad virtual es el recomendado para la mayoría de los casos, a menos que se requiera explícitamente el uso de la compatibilidad fisica.  Por ejemplo, en un Failover Cluster Microsoft sobre Windows Server 2008, se requiere Persistent Group Reservation (PGR) SCSI-3, la cual es solo disponible utilizando RDM en modo de compatibilidad física.

Al utilizar discos RDM en modo de compatibilidad fisica debemos considerar que habrá una serie de funcionalidades que ya no se encontrarán disponibles:

• Snapshots.  Esto en particular puede ser muy critico, considerando que muchas soluciones de respaldo, como vDR requieren del uso de Snapshots.
• vMotion; No es posible mover con vMotion una MV con RDM en Compatibilidad Física.
• Clonado de MV con RDM en compatibilidad fisica.
• No es posible convertir una MV con discos RDM en un Template.

Al utilizar discos RDM en modo de compatibilidad virtual se pueden superar casi todas estas limitaciones, permitiendo el uso de vMotion, Snapshots y Clonado de VM.

Disco Virtual con Thin o Thick Provisioning?

Cuando se crea un disco virtual en VMware, por defecto el tipo a utilizar es Thick.  Un disco Thick reserva todo el espacio especificado durante la creación del disco, utilizandolo efectivamente en el Datastore.

Un disco Thin no realiza una reserva previa de todo el espacio asignado durante la creación del disco.  Los bloques en el archivo VMDK no son reservados en el Storage fisico hasta que ellos son escritos durante el curso normal de su operación.

Un detalle completo de los discos Thin y Thick, con sus diferencias lo pueden encontrar en el KB 1005418.

Cada tipo de disco tiene claras ventajas y desventajas, y la decisión dependerá del uso que le daremos al disco.  Por ejemplo, si el disco será utilizado por una base de datos con muchas transacciones, se recomienda el uso de discos en formato Thick, ya que en formato Thin el disco crecería muy rapidamente, haciendo injustificado el uso de este tipo de discos.

Ventajas y Desventajas de Thick Provisioning:

• Configuración y Monitoreo de almacenamiento más simple
• Soporte para Fault Tolerance en VMware
• Menos eficiente en el uso de espacio
• Mayores costos de almacenamiento

Ventajas y Desventajas de Thin provisioning

• Reduce el costo de almacenamiento
• Elimina la necesidad de dedicar desde un comienzo, toda la capacidad requerida por una aplicación.
• La fragmentación de los discos tiene efectos insignificantes en la performance del disco.
• Thin Provisioning podria no ser lo más adecuado en ambientes donde el tamaño de los discos virtuales tendrá una rapida tasa de crecimiento.
• Thin Provisioning aumenta el riesgo de quedarse sin espacio en un Datastore.  Este riesgo puede ser mitigado usando alarmas y reportes de Storage.
• Se deben monitorear y crear alarmas apropiadas.

Nota: El uso combinado de Thin Provisioning basado en Storage y en el VMkernel esta bien, mientras se administre correctamente para evitar quedarse sin espacio en disco.

Espero les haya sido de utilidad!

Read More

OS Nexus - QuantaStor: Un util Appliance iSCSI

Para quienes requieran de una buena alternativa a una cabina iSCSI/FC, y a otras soluciones iSCSI gratuitas como Openfiler, les presento QuantaStor de OS Nexus, un Appliance iSCSI/FC virtual, el cual posee una versión gratuita, así como otras tres versiones corporativas.

Este appliance viene en formato OVF, el cual se instala facilmente en una plataforma vSphere, obteniendo una IP con DHCP, pudiendo luego esta ser modificada por una IP estática.

QuantaStor puede funcionar como un Storage SAN o NAS, y su sistema operativo se encuentra construido sobre Ubuntu Server, utilizando una arquitectura de 64-Bits.

Las versiones corporativas incluyen funcionalidades avanzadas incluyendo Snapshots, Compresión, Thin Provisioning y Replicación, entre otras.  Pueden ver las distintas versiones y sus funcionalidades en el siguiente link:

http://www.osnexus.com/product-editions/


Toda la configuración se realiza a través de una cómoda consola web, compatible con todos los browsers utilizados usualmente (IE, Firefox, Chrome), contando con una interfaz amigable y extremadamente intuitiva, especialmente en comparación con otras alternativas gratuitas, incluyendo Openfiler, cuya configuración requiere de mayor conocimiento en configuraciones iSCSI.

Aqui se puede configurar la red y los Targets iSCSI (incluyendo Jumbo Frames):

Luego podemos crear los Storage Pools con los discos existentes, pudiendo crear distintas configuraciones RAID, dependiendo de la cantidad de discos disponibles y la versión que estemos utilizando.

La configuración de los Storage Pools puede luego ser modificada según nuestras necesidades.  Del mismo modo, uno puede deshabilitar temporalmente un Storage Pool, y habilitarlo posteriormente.

A continuación podemos crear volúmenes o LUNs, las cuales pueden posteriormente ser asignadas a uno o más hosts.  Estos volúmenes pueden ser modificados posteriormente, redimensionados, clonados, asignados a un host o eliminados, así como se le puede sacar un Snapshots.  Aqui también se pueden realizar configuraciones adicionales, como el modo de acceso (solo lectura, o completo), así como la configuración CHAP.

Luego debemos crear los hosts a los cuales les permitiremos acceso a los volumenes que acabamos de crear, pudiendo utilizarse el IQN o IP para iSCSI o el Word Wide Por Name para Fiber Channel.  Estos hosts los podemos modificar posteriormente, o simplemente eliminarlos.

En esta misma sección podemos asignarle LUNs a uno de los hosts que tenemos ya registrados en nuestra configuración.

Luego pueden también configurar Hosts Groups, lo cual permite crear configuraciones en Cluster, como por ejemplo un Cluster HA/DRS VMware

Como pueden ver, la configuración de este Appliance es bastante sencilla e intuitiva, con lo cual podemos tener nuestra SAN funcionando en cosa de minutos.

Este Appliance, en su versión gratuita, puede ser de bastante utilidad para aquellos que requieren armar un buen laboratorio de pruebas para practicar para el examen VCAP-DCA de VMware, o simplemente para ganar experiencia en la configuración de Storage SAN.

Espero les sea de utilidad!!!

Read More

VMware vSphere: Trabajar con LUN Masking

Hola a todos, en el presente articulo hablaremos de LUN Masking a nivel de VMware (VMKernel).

Enmascarar los Paths o Caminos, permite evitar que los hosts ESX/ESXi accedan a dispositivos de almacenamientos o LUNs, o evitar que utilizan Paths especificos. Cuando se aplica LUN Masking, se crean reglas que asignan el plug-in MASK_PATH en el Path especificado.

Una razon para aplicar LUN Masking, es proteger una o más LUNs en el caso de que se quiera reinstalar un host con booteo desde la SAN. Cuando se utiliza Boot desde la SAN, LUN Masking permite configurar el host para que este vea solo la LUN que le corresponde, y evitar de esta forma que se corrompa una LUN de otro host, o un Datastore de Maquinas Virtuales.

Por otro lado, como buena practica, se recomienda que se aplique LUN Masking cuando se quiera quitar una LUN desde uno o más hosts ESX/ESXi. Esto antes de quitar la LUN a nivel de Storage.

En vSphere, la configuración de LUN Masking no es posible realizarla a traves del vSphere Client. Esta configuración debe llevarse a cabo desde la Service Console, vCLI o a traves de la vMA.

Aplicar LUN Masking

A continuación detallare el proceso de aplicación de LUN Masking en un host ESX/ESXi

En primer lugar debemos determinar cuales son los Paths o caminos que está utilizando la LUN para llegar al Storage. Los Paths en VMware tienen el siguiente formato: vmhba37:C1:T7:L0 Donde: C: Canal o Channel T: Destino o Target L: LUN Esto podemos realizarlo a traves de vSphere Client o por linea de comandos
	En vSphere Client nos dirigimos a la pestaña "Configuration" del host, e ingresamos a la sección Storage Adapters. Seleccionamos el adaptador iSCSI (en nuestro caso el adaptador por Software). En la sección inferior, en la división de Paths, buscamos las rutas que ocupa la LUN que queremos enmascarar. En nuestro caso, aplicaremos LUN Masking en la LUN VMFS-EQL-ISOS, la cual tiene 2 rutas según lo que aparece en la lista de Paths. vmhba37:C1:T7:L0 vmhba37:C0:T7:L0
	Del mismo modo, utilizando CLI debemos ejecutar los siguientes comandos: # vmkfstools --queryfs /vmfs/volumes/NombreLUN Con lo que obtemos el ID de la LUN. # esxcfg-mpath --list-paths --device LUN_ID Con lo que obtenemos los Paths utilizados por la LUN.
	Teniendo ya los Paths, podemos proseguir creando las reglas Claimrule para enmascarar cada uno de ellos. En primer lugar listamos las reglas existentes para saber que numero de regla podemos utilizar. # esxcli corestorage claimrule list El numero de la regla puede ir de la 101 a la 200.
Proseguimos creando las reglas necesarias, requiriendose una regla por Path a enmascarar. En nuestro caso tenemos 2 Paths, por lo que crearemos 2 reglas: esxcli corestorage claimrule add -P MASK_PATH -r 120 -t location -A vmhba37 -C 0 -T 7 -L 0 esxcli corestorage claimrule add -P MASK_PATH -r 121 -t location -A vmhba33 -C 1 -T 7 -L 0
	Como vimos anteriormente, C: Canal o Channel T: Destino o Target L: LUN A: Adaptador
	Cargamos las reglas que recién creamos y verificamos que efectivamente ya se muestran en la lista de reglas. # esxcli corestorage claimrule load # esxcli corestorage claimrule list Las reglas deben aparecer como clase File y Runtime (cada una).
A continuación debemos de-registrar (unclaim) el Path, y ejecutar las reglas. # esxcli corestorage claiming unclaim -t location -A vmhba37 -C 0 -T 7 -L 0 # esxcli corestorage claiming unclaim -t location -A vmhba37 -C 0 -T 7 -L 0 # esxcli corestorage claimrule run
	El comando de Unclaim se debe realizar por cada regla creada (1 por Path).
Con estos pasos, la LUN ya no debiera ser visibile para el host.
	En vSphere Client nos dirigimos a la pestaña "Configuration" del host, e ingresamos a la sección Storage Adapters. Aqui vemos que ya solo tenemos 9 Devices (LUNs), con lo que confirmamos que el Masking se ha aplicado correctamente. En ocasiones, las rutas aparecen como "Dead" antes de desaparecer completamente, lo cual ocurre con un Rescan.
	Si ingresamos por linea de comandos a la ruta /vmfs/volumes, podemos ver que la LUN enmascarada ya no aparece. Con eso se concluye el proceso de LUN Masking.

Deshacer LUN Masking

A continuación detallare el proceso para deshacer una configuración de LUN Masking en un host ESX/ESXi, y que una LUN sea nuevamente visible.

	En primer lugar listamos las reglas existentes para saber el numero de las reglas que actualmente enmascaran la LUN. # esxcli corestorage claimrule list En este caso, son las reglas 120 y 121.
A continuación debemos eliminar las reglas necesarias. # esxcli corestorage claimrule delete -r 120 # esxcli corestorage claimrule delete -r 121.
	Si listamos las reglas podemos ver ahora que las reglas solo aparecen como clase "Runtime".
	A continuación cargamos las reglas. Podemos ver ahora que las reglas clase Runtime han desaparecido definitivamente.
A continuación debemos registrar el Path, y ejecutar las reglas. # esxcli corestorage claiming unclaim -t location -A vmhba37 -C 0 -T 7 -L 0 # esxcli corestorage claiming unclaim -t location -A vmhba37 -C 0 -T 7 -L 0 # esxcli corestorage claimrule run
	El comando de Unclaim se debe realizar por cada regla creada (1 por Path).
Con estos pasos, la LUN ya debiera ser visibile nuevamente para el host.
	En vSphere Client nos dirigimos a la pestaña "Configuration" del host, e ingresamos a la sección Storage Adapters. Aqui vemos que tenemos nuevamente 10 Devices (LUNs), con lo que confirmamos que el Masking se ha quitado correctamente.
	Vemos también que el Datastore figura nuevamente en la lista de Datastores del host.
	Si ingresamos por linea de comandos a la ruta /vmfs/volumes, podemos ver que la LUN aparece nuevamente Con eso se concluye el proceso de deshacer LUN Masking.

Espero que les sea de utilidad, y no duden en consultar si tienen alguna pregunta.
Saludos!!!

Read More