VCAP – Sección 1.7 – Analizar comportamientos de I/O para determinar los requerimientos de almacenamiento

Que tal gente, continuando con los temas de VCAP nos toca hablar sobre el como analizar los comportamientos o workloads a nivel del almacenamiento, para esto estaremos primero entendiendo ciertos conceptos y factores que componen estos workloads.

Es importante conocer el comportamiento que tienen nuestras aplicaciones para poder hacer un correcto diseño de nuestra infraestructura, en este caso nos estamos enfocando al almacenamiento parte fundamental del performance que tendrán nuestras aplicaciones virtualizadas.

¿Que elementos determinan el performance de nuestro almacenamiento?

• IOPS: I/O per second, básicamente la cantidad de lecturas y escrituras que un disco puede realizar en un segundo, esto básicamente nos dirá la capacidad del disco o del tipo de disco que estaremos utilizando para responder a nuestras operaciones. Existen valores aceptados y utilizados como base para cada tipo de disco:

• Latencia: básicamente es la cantidad de tiempo que nuestro disco o almacenamiento tarda en responder a nuestras solicitudes en disco, este valor se mide en ms,  un valor aceptable estaría entre 5 ms a 10 ms dependiendo los requerimientos de las aplicaciones virtualizadas.
  

• Ancho de banda o capacidad del arreglo/disco/interfaz (Mbps): este ancho de banda depende de que interfaz estaremos utilizando, existen varias interfaces actualmente, IDE, SATA,SCSI,SAS y FC.  Estas interfaces son vistas de distinta manera en el lado de un almacenamiento central (SAN, NAS), ya que ahí estaríamos hablando de 2 tipos de interfaces, back-end y front-end. En el caso de back-end es la interconexión entre los distintos controladores o storage processors de dicho almacenamiento aquí generalmente hablamos de interfaces SAS y FC. Finalmente en el caso de Front-end hace referencia a la interfaz que tiene contacto directamente con los servidores o clientes de este almacenamiento, aquí demos interfaces de FC y ethernet (ISCSI , NFS ,CIFS).

• RAID: en un post anterior tocamos el tema de los niveles de RAID, aquí tenemos que tener en cuenta que el nivel de RAID implica cierta implicación al performance en cuanto a escritura se refiere , para ser más claro, debido a la paridad que se tenga dependiendo del nivel de RAID para poder hacer la escritura de un bloque tiene que también escribir los bloques de su paridad es por eso que debemos tener en consideración este punto en el momento de hacer el calculo de nuestro almacenamiento. Aquí les dejo el link a mi post anterior sobre los niveles de RAID:

http://hispavirt.wordpress.com/2010/10/11/vcap-%e2%80%93-seccion-1-%e2%80%93raid-y-vms/

• Cache: En los sistemas de almacenamiento central, incluso en los mismos discos que utilizamos día a día existe un factor clave para mejorar el performance, el cache, por cache entendemos escencialmente memoria RAM que actua como buffer almacenando las operaciones de I/O, existen 2 tipos de caches , volatiles y no volatiles estos se diferencian simplemente en si se pierde o no la información almacenada en el caso de perdida de energía. Generalmente el cache para operaciones de escritura es no volatil es decir no se pierde en el caso de perdida de energía al contrario del cache para lecturas. Al ser memoria RAM es mucho más veloz que cualquier sistema de disco con esto mejoramos significativamente el performance de nuestro almacenamiento debido a que las operaciones son almacenadas temporalmente en estos caches y después escritas a disco, con esto ganamos la capacidad de aceptar mas operaciones concurrentes y en el caso de lectura almacena las lecturas anteriores a disco y en casos de almacenamientos avanzados existen algoritmos que predicen que información será leída y se almacena en dicho cache para ser entregada mas rápido.

• Queuing: con esta capacidad del almacenamiento se encolan las operaciones de I/O para poder ser procesadas después, esto puede ser a nivel del almacenamiento y directamente en las HBAs de nuestros servidores.

• Coalescing: esta capacidad de algunos almacenamientos lo que realiza es ordenar las operaciones de I/O almacenadas en cache  en el caso que tengamos un comportamiento "random" con esto se busca reducir la cantidad de actividad en disco ya que los comportamientos de escritura serán uniformes.

¿Que tipos de comportamientos o workloads existen? ¿Que debo tener en cuenta?

Existen 2 principales tipos de comportamientos en cuanto a operaciones a disco se refiere, secuencial y random. En el caso de un comportamiento secuencial las operaciones de I/O se llevan a cabo de manera más rápida debido a que se necesita un menor numero operaciones de "seek" que básicamente lo que se realiza es un posicionamiento de la aguja del o los discos en el correcto sector donde reside la información. Al contrario en el caso de un comportamiento random o al azar las operaciones de I/O estarán tratando de acceder a distintos sectores del almacenamiento, aumentando así las operaciones de seek a este tiempo se le llama "seek latency".

Una vez que sabemos que tipo de comportamiento tiene nuestra aplicación sea secuencial o random es importante tener en cuenta los siguientes elementos:

• tamaño de las operaciones I/O (I/O request size):  el tamaño de la información leída o escrita a nuestro almacenamiento, entre más grande el tamaño de nuestra operación ej. 64k será más eficiente de procesar y decrece el uso de procesador. Existen distintos tamaños, podemos ver 2k, 4k, 8k, etc. En el caso que quisiéramos virtualizar servidores Windows podemos determinar el tamaño de nuestras operaciones utilizando perfmon y ejecutando el siguiente counter "Avg. Disk Bytes/Read".
• porcentaje de escritura y/o lectura: importante para determinar el nivel de RAID a utilizar, ej. en el caso de aplicaciones que requieran un alto nivel de escritura se benefician de un raid 10.

¿Como puedo obtener todos estos datos?

• Windows perfmon — http://www.windowsnetworking.com/articles_tutorials/Key-Performance-Monitor-Counters.html
• Esxtop — http://www.yellow-bricks.com/esxtop/
• vscsiStats    — http://hispavirt.wordpress.com/2010/07/05/paso-a-paso-vscsistats/ , http://communities.vmware.com/docs/DOC-10095
• herramientas de proveedores de almacenamiento
• VMware Capacity Planner

VCAP – Sección 1.6 – 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":

VCAP – Sección 1.5 – Entendiendo y aplicando resignature a volumenes VMFS

Que tal Gente, el día de hoy les voy a hablar sobre de resignature de nuestros VMFS. Los servidores ESX/ESXi necesitan diferenciar entre sus datastores de VMFS , es por eso que desde la versión de VI3 se introdujo un mecanismo para cumplir con esto VMFS resignaturing.

En estos tiempos casi todos los almacenamientos centrales cuentan con mecanismos de protección o respaldo de datos a nivel del almacenamiento, entre los muchos que podemos encontrar están los snapshots (No de VMware), estos snaps de almacenamiento lo que hacen es tomar el estado de algún LUN en un momento especifico, teniendo así un copia exacta byte por byte pero además de copiar la información que se encuentra en la misma se copia el metadata del volumen aquí es donde tenemos problemas con VMware debido a que los servidores ESX distinguen sus Datastores basados en un UUID (Universally Unique Identifier) y este uuid se encuentra en el metadata de dichos volúmenes es un valor hexadecimal de 16 caracteres asignado por el LVM.

¿Cómo puedo saber el UUID de mi volumen VMFS?

Haciendo uso de vmkfstools.

vmkfstools -P -h /vmfs/volumes/nombredevolumen

-P nos permite la lectura del metadata

-h nos presenta la información en MB y GB

¿Como esta compuesto este UUID?

 

Primera parte (verde) — El tiempo de nuestro COS (console of service).

Segunda parte (azul) — El tiempo TSC (time stamp counter) métrica propia del CPU para llevar una cuenta de tiempo.

Tercera parte (naranja) — valor aleatorio.

Cuarta Parte (rojo) — MAC address de nuestra COS.

 

En el momento que nosotros presentamos un LUN que sea snapshot o copia de un mismo LUN que ya este dado de alta en nuestros servidores ESX/ESXi se generarán entradas en el log de vmkernel, si hacemos un "tail -f /var/log/vmkernel.log"  en el caso de ESX y "tail -f /var/log/messages |grep vmkernel"  en el caso de ESXi veremos entradas como:

vmhba0:0:0:1 may be snapshot

esto nos indica que se ha presentado un LUN que tiene un mismo UUID de algún LUN que se está utilizando. Podemos verificar esto ejecutando el siguiente comando:

esxcfg-volume -l

Esto nos mostrará algo como lo siguiente en caso de tener un snapshot LUN:
VMFS3 UUID/label: 49d22e2e-996a0dea-b555-001f2960aed8/VMFS_1
Can mount: Yes
Can resignature: Yes
Extent name: naa.60a98000503349394f3450667a744245:1 range: 0 – 97023 (MB)

Aquí tenemos varias opciones para el montaje de dicho LUN:

• Forzar el montaje de un snapshot lun hasta el siguiente reboot del Host ESX

esxcfg-volume -m <UUID|nombredeVMFS>

ej.   esxcfg-volume -m "49d22e2e-996a0dea-b555-001f2960aed8″

• Forzar el montaje de un snapshot lun de forma persistente (se monta sin importar reinicios)

esxcfg-volume -M "49d22e2e-996a0dea-b555-001f2960aed8″

• Realizar un resignature del snapshot LUN (cambio de UUID),se monta inmediatamente:

esxcfg-volume -r "49d22e2e-996a0dea-b555-001f2960aed8″

 

¿Cómo realizo operaciones de resignature desde el vSphere Client?

1. Ingresamos con nuestro vSphere Client y seleccionamos nuestro Host ESX/ESXi y seleccionamos la pestaña de "configuration".
2. Seleccionamos "Storage" y damos click en add storage.
3. Seleccionamos Disk/LUN.
4. En la lista de LUNs presentadas seleccionamos aquella que en la columna de "VMFS label"  tenga un nombre de datastore, en este mismo nombre se nos mostrará que es un snapshot.
5. en Mount options seleccionamos "assign a new signature" y damos next.
6. Finalizamos el proceso.