VCAP – Sección 1 – Configurar,administrar plugins PSA y arquitecturas complejas

Que tal gente, el día de hoy vamos a hablar del objetivo 1.3 de nuestra guía de VCAP, en este caso estaremos tocando temas referentes a la nueva arquitectura para el manejo de nuestro almacenamiento en vSphere – PSA (Pluggable Storage Architecture).

Un poco antes de comenzar con esta serie de posts de VCAP publique este post:

vSphere – ¿Que es VMware PSA?

aquí plasmo de manera completa (a mi parecer) como está conformada esta nueva arquitectura de almacenamiento y que ventajas tenemos. Creo que faltan algunos puntos en este post, vamos a echar un  vistazo:

¿Como modifico el PSP (Path Selection Plugin) predefinido de un SATP (Storage Array Type Plugin)?

Ej. Para un almacenamiento reconocido como Activo/Activo se le asigna un PSP Fixed.  Ejecutando el siguiente comando podemos ver cuáles son las reglas predefinidas

esxcli nmp satp list

En este caso estaremos trabajando con un almacenamiento Netapp, el cual es activo/activo. Así que haremos las modificaciones a la regla correspondiente para cada vez que se detecte un LUN de este almacenamiento se le asigne Round Robin en lugar de MRU.

Aquí tenemos el cómo se detecta un LUN por default para este tipo de almacenamiento:

Este tipo de almacenamiento es detectado como “VMW_SATP_DEFAULT_AA” así que haremos las modificaciones necesarias en dicho SATP:

esxcli nmp satp setdefaultpsp –satp VMW_SATP_DEFAULT_AA –psp VMW_PSP_RR

–SATP (Storage Array Type Plugin)

–PSP (Path Selection Plugin) en este caso lo modificamos a “VMW_PSP_RR” el cual es Round Robin.

con esto tenemos el siguiente resultado:

Una vez reiniciado nuestro host ESX/ESXi detectará todas las LUNS presentadas por almacenamientos activo/activo y les asignará el PSP de Round Robin:

Configurar iscsi port binding (iscsi multipathing)

ISCSI al ser un protocolo basado en tcp/ip y en el caso de iscsi basado en software (manejado por el vmkernel) este entabla todas las comunicaciones a traves de nuestras pNICS o tarjetas de red. En el caso que nosotros quisiéramos tener varios “paths” o caminos también conocido como multipathing necesitamos seguir ciertos pasos para poder habilitar varios puertos de vmkernel para la comunicación de ISCSI.

Inicialmente tenemos una configuración como la siguiente, un puerto vmkernel y en el mismo vSwitch donde reside este puerto puede existir una o más tarjetas de red realizando un nic teaming.

En este punto tenemos comunicación con nuestro almacenamiento iscsi de manera redundante mas no distintos “paths” o caminos hacia dicho almacenamiento ya que la comunicación es a través de una sola ip del lado de nuestro servidor ESX/ESXi siguiendo los siguientes pasos habilitaremos la comunicación para dos puertos vmkernel esto lo conocemos como iscsi port binding:

Paso 1-. Creamos uno o más puertos vmkernel (segun numero de pNics):

 

Nos aseguramos que cada uno de los puertos de vmkernel estén utilizando una de las tarjetas asignadas a dicho vSwitch, damos click en “properties…” seleccionamos uno de los puertos de vmkernel y damos click en “edit” después seleccionamos el tab de “nic teaming” y marcamos el checkbox de “override vSwitch failover order”, con esto tendremos la capacidad de seleccionar una pNIC como activa y la otra(s) desactivadas, esto lo realizamos en cada uno de los puertos de vmkernel asignados para nuestra comunicación ISCSI habilitando una tarjeta exclusiva para cada uno de ellos:

 

Paso 2-. En este momento necesitamos crear la asociación entre puerto vmkernel y pnic para que nuestro servidor ESX/ESXi sea capaz de utilizar ambos puertos para la comunicación ISCSI.

dentro de nuestro service console o del tsm (esxi) e ingresamos el siguiente comando para crear dicha asignación:

esxcli swiscsi nic add -n vmk1 -d vmhba33

-n nombre del puerto vmkernel, vmk#

-d hba de sw iscsi (esto lo verificamos en “configuration>Storage Adapters”)

Paso 3-. Verificamos que efectivamente ya esta asignado el vmknic:

esxcfg-vmknic -l

 

VCAP – Sección 1 – LUN masking utilizando comandos de PSA

Que tal gente, continuando con los temas para la preparación de VCAP nos toca hablar de cómo hacer un mask o prevenir que ciertos hosts ESX/ESXi puedan tener visibilidad de algún LUN en especifico, esto basándonos sobre el nuevo plugin de PSA MASK_PATH de PSA.

En el diseño de nuestra arquitectura siempre es importante tomar en cuenta la cantidad de Hosts que estarán accediendo concurrentemente a un LUN, debido a que a mayor cantidad de hosts , mayor cantidad de operaciones SCSI. Si nosotros tenemos un granja de servidores ESX/ESXi 15+  servidores es un punto que tenemos que tener muy presente, aquí es donde entra el objetivo de enmascarar ciertas LUNs para ciertos hosts.

Generalmente este enmascaramiento lo hacemos del lado de la SAN y lo conocemos como zoning, pero también tenemos la capacidad de hacer este enmascaramiento directamente en los hosts ESX/ESXi, tengamos en cuenta que lo recomendado y lo más sano en términos de administración es hacerlo del lado de nuestro almacenamiento.

¿Cómo enmascaro algun LUN en mis hosts ESX/ESXi?

Paso 1-. Ingresamos a nuestro servidor ESX/ESXi con el vSphere Client, una vez dentro, navegamos a configuration>Storage Adapters

Paso 2-. Seleccionamos el adaptador a través del cual se esté llegando a dicho almacenamiento (HBA de FC , SW iscsi o HBA de ISCSI). Una vez seleccionado, en  los detalles de dicho adaptador encontraremos 2 tipos de vista Devices/Paths , damos click en Paths, aquí se nos mostrará cuales son los paths a través de los cuales se llega a dicho almacenamiento:

Paso 3-. Una vez que ya tenemos enlistados los paths, es cuestión de crear reglas para enmascarar cada uno de ellos, comenzamos por enlistar las reglas existentes para poder saber con que numero de regla podemos comenzar:

esxcli corestorage claimrule list

Paso 4-. Creamos las reglas necesarias (numero de paths) para enmascarar dicho LUN:

esxcli corestorage claimrule add -P MASK_PATH -r 120 -t location -A vmhba33 -C 3 -T 0 -L 0
esxcli corestorage claimrule add -P MASK_PATH -r 121 -t location -A vmhba33 -C 2 -T 0 -L 0
esxcli corestorage claimrule add -P MASK_PATH -r 122 -t location -A vmhba33 -C 1 -T 0 -L 0
esxcli corestorage claimrule add -P MASK_PATH -r 123 -t location -A vmhba33 -C 0 -T 0 -L 0

-C Canal o channel

-T destino o Target

-L LUN

-A adaptador

Recuerden que estos son los elementos del runtime name

Paso 5-. 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

Paso 6-. Si se trata de un LUN que ya se presentaba en nuestro host ESX/ESXi, necesitamos quitar la regla actual:

esxcli corestorage claiming unclaim -t location -A vmhba33

Paso 7-. Ejecutamos nuestras reglas:

esxcli corestorage claimrule run

Una vez realizados estos pasos ya hemos enmascarado dicho LUN a nuestro host, si ingresamos con nuestro vSphere client y navegamos a configuration>Storage Adapters se nos muestran los paths como “dead”: