VCAP – Sección 6 – Troubleshooting de almacenamiento

Que tal gente vamos a continuar con los temas para el examen VCAP-DCA, en este caso nos toca hablar de como realizar troubleshooting a nivel del almacenamiento, poder identificar donde esta el problema y conocer los comandos que nos pueden apoyar con estas tareas.

Comandos de vicfg-* utilizados para temas de almacenamiento

• vicfg-iscsi.pl – con este script de perl tenemos la capacidad para manejar el adaptador de sw iscsi y adaptadores físicos de iscsi.

• vicfg-volume – con este script podemos manejar aquellas LUNs (volúmenes) detectadas como replicas, montarlas,etc.
• vicfg-mpath – con este script podemos obtener información de los paths existentes para almacenamiento ISCSI y FC.

• vicfg-mpath35.pl - esta pensado para la administración de paths para hosts vi 3.5
• vicfg-nas.pl – con este script podemos manejar los exports de nas, montar,desmontar,etc.

• vicfg-rescan.pl – con este script podemos realizar rescans a nivel de adaptador.
• vicfg-scsidevs.pl – con este script podemos obtener información de LUNs, como identificadores (naa,vml,t11).

• vicfg-module.pl – con este script podemos manejar módulos del kernel de VMware, un ejemplo claro para el uso de este es el aumentar el queue depth de un adaptador:

vicfg-module -s ql2xmaxqdepth=64 <module_name>

C0nocer los máximos de almacenamiento

Aquí les dejo el link a la guía de máximos de vSphere 4.1 http://www.vmware.com/pdf/vsphere4/r41/vsp_41_config_max.pdf

Identificar logs utilizados para troubleshooting de almacenamiento

Aquí básicamente estaremos observando el log de /var/log/vmkernel , aquí podremos ver reservaciones scsi, snapshots luns, etc.

Describir VMFS

La verdad no voy a describir VMFS ya que me tomaría un tiempo demasiado largo, les recomiendo leer este articulo http://blog.laspina.ca/ubiquitous/understanding-vmfs-volumes.

Utilizar comandos de vicfg-* y esxcli para realizar troubleshooting de mutlipath y la arquitectura de PSA

En este caso estaríamos obteniendo información de los paths utilizando vicfg-mpath, les recomiendo leer la guia de “vSphere Command-Line Interface
Installation and Reference Guide” a partir de la pagina 83, donde podrán encontrar todos los usos de esxcli.

Vamos a ver algunos ejemplos:

Para cambiar el tipo de PSP (Path selection plugin):

esxcli nmp device setpolicy –device (naa.XXXX) –psp vmw_psp_XX

vmw_psp_RR – Round Robin

vmw_psp_fixed – Fixed

vmw_psp_mru – MRU

vmw_psp_fixed_AP – Fixed para almacenamientos Activos/pasivos con ALUA

Para enmascarar un LUN o algún path en especifico hacia un LUN:

Obtenemos la información de los paths utilizando esxcfg-mpath -l

Agregamos la regla con el plugin”Mask_path”:

esxcli corestorage claimrule add -r 121 –plugin mask_path –type location –adapter vmhba33 -C 3 -T 0 -L 0

-r numero de regla

–type tipo de regla

–adapter hba a través de la cual se ve dicho lun

Para que la nueva regla se vea reflejada:

esxcli corestorage claimrule load

En el caso que tengamos una regla para enmascarar un LUN o path en especifico y quisiéramos volver a tener acceso a dicho LUN/path debemos seguir estos pasos:

Liberamos el path en especifico o LUN:

esxcli corestorage claiming unclaim –type location –adapter vmhba33 -C 3 -T 0 -L 0

o Liberamos todo  de dicho adaptador:

esxcli corestorage claiming unclaim –adapter vmhba33

Una vez liberado, borramos la regla que enmascara dicho path/LUN , para esto enlistamos las reglas que tenemos:

esxcli corestorage claimrule list

Borramos dicha regla:

esxcli corestorage claimrule delete -r #numeroderegla

Y realizamos un reload de las reglas:

esxcli corestorage claimrule load

y podemos realizar un rescan

esxcfg-rescan -A

Obtener el path preferido para un dispositivo con PSP Fixed:

esxcli  nmp fixed getpreferred –device naa.xxx

Para cambiar el path preferido para un dispositivo con PSP fixed:

esxcli nmp fixed setpreferred –device naa.xxx vmhba33:C3:T0:L0

Utilizar vicfg-module para realizar troubleshooting de problemas con módulos de almacenamiento

Bueno aquí no tengo mucho que compartir con ustedes, aquí podríamos deshabilitar un modulo que este teniendo problemas con:

vicfg o esxcfg-module -d nombremodulo

Para poder ver los módulos que tenemos cargados

vicfg o esxcfg-module -l

Para configurar un parámetro en especifico de algún módulo:

vicfg o esxcfg-module -s  opcionavanzada nombredemodulo

Utilizar vicfg-* y esxcli para realizar troubleshoot de ISCSI

Aquí estaremos utilizando el comando esxcli swiscsi y vicfg-iscsi, vamos a ver algunos ejemplos:

vicfg-iscsi:

agregar un target iscsi dinámico:

vicfg-iscsi.pl –server esxi01.hispavirt.test.com –add -D -i 192.168.3.250:3260 vmhba33

agregar un target iscsi estático:

vicfg-iscsi.pl –server esxi01.hispavirt.test.com –add -S -i 192.168.3.250:3260 vmhba33

enlistar targets activos:

vicfg-iscsi.pl –server esxi01.hispavirt.test.com -T –list vmhba33

enlistar propiedades de LUNs para un adaptador en especifico:

vicfg-iscsi.pl –server esxi01.hispavirt.test.com –list –lun vmhba33

Configurar autentificación (CHAP) uni-direccional:

vicfg-iscsi.pl –server esxi01.hispavirt.test.com –authentication –level chapRequired –method CHAP –auth_username administrator –auth_password –ip 192.168.3.250 vmhba33

enlistar adaptadores de iscsi:

vicfg-iscsi.pl –server esxi01.hispavirt.test.com –device –list

esxcli:

Agregar un segundo puerto de vmkernel para sw iscsi:

esxcli swiscsi nic add -n vmk1 -d vmhba33

Quitar un puerto de vmkernel para sw iscsi:

esxcli swiscsi nic remove -n vmk1 -d vmhba33

Enlistar sesiones de sw iscsi:

esxcli swiscsi session list –d vmhba33

Remover sesión de sw iscsi:

esxcli swiscsi session remove -d vmhba33

Troubleshooting de NFS

Les recomiendo leer este kb de VMware: http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=1003967&sliceId=1&docTypeID=DT_KB_1_1&dialogID=97106231&stateId=1%200%2097104743

Utilizar esxtop y vscsiStats para troubleshooting de almacenamiento

En el caso de esxtop tenemos que echarle un ojo a los siguientes:

DAVG – (device avg) – latencia a nivel del adaptador (hba), latencia entre la hba y el almacenamiento. Si este valor es alto (davg ≥ 25) debemos verificar nuestro almacenamiento (cantidad de discos, problemas) e infraestructura para llegar a el (switches , hba’s ,etc).

KAVG – (kernel avg) – latencia a nivel del vmkernel, generalmente este valor debe de ser menor al valor de DAVG o “0″, en el caso que sea mayor es posible que tengamos encoladas peticiones a disco (QUED).

GAVG - (guest avg) – la suma de KAVG y DAVG nos da como resultado la latencia percibida por el guest o vm (GAVG),valores mayores a 25 nos indican problemas.

QUED – cantidad de comandos encolados a nivel del vmkernel, esto quiere decir que dichos comandos están esperando una oportunidad de entrar en el queue del almacenamiento. En el caso que se tenga un valor distinto a “0″ nos indica problemas con nuestro almacenamiento (queue depth).

ABRTS/s – cantidad de comandos abortados, esto sucede en el momento que después de cierta cantidad de tiempo (dependiendo el os), el almacenamiento  no ha sido capaz de responder a las peticiones de dicha vm, por lo cual el sistema operativo realiza dicho abort.

RESETS/s – reseteo del bus de scsi.

CONS/s – reservaciones scsi por segundo, en el caso de tener una cantidad alta de reservaciones (20+) se nos indica problemas con nuestro almacenamiento, las reservaciones scsi solo aplican para datastores VMFS. Estas ocurren en el momento ciertas operaciones requiere hacer un lock del metadata, por ej: encendido de vm, nueva vm, snapshot, vmotion de una vm, etc. Por estas se presentan comúnmente en el caso de tener una cantidad alta de VMs por cada datastore.

y para vscsiStats les recomiendo leer mi articulo Paso – a – paso – vscsiStats.

Configurar y realizar troubleshooting de VMFS con vmkfstools

vmkfstools es una herramienta para el manejo de VMFS y de VMDKs, vamos a conocer algunos ejemplos:

Para el manejo de VMFS:

Crear un VMFS con block size de 8mb con el nombre “iscsi-01″ en el path vmhba33:3:0:0

vmkfstools -C vmfs3 -b 8m -S iscsi-01 vmhba33:3:0:0

Extender un VMFS entre distintas particiones

vmkfstools -Z vmhba33:3:0:1 vmhba33:3:0:0

Crear un vmdk de 2 GB en nuestro VMFS recién creado:

vmkfstools -c 2048m /vmfs/volumes/iscsi-01/win2k3.vmdk

Crear un vmdk de 2 GB pero eagerzeroed:

vmkfstools -c 2048m /vmfs/volumes/iscsi-01/win2k3.vmdk -d eagerzeroedthick

Crear un vmdk de 2 GB pero thin:

vmkfstools -c 2048m /vmfs/volumes/iscsi-01/win2k3.vmdk -d thin

Para crear un rdm passthrough (modo físico):

vmkfstools -z /vmfs/devices/disks/naa.60a980006e424f4f6c4a595261485168 /vmfs/iscsi-01/win2k3_RDM.vmdk

Para crear rdm modo virtual:

vmkfstools -r /vmfs/devices/disks/naa.60a980006e424f4f6c4a595261485168 /vmfs/iscsi-01/win2k3_RDM.vmdk

Para clonar un vmdk:

vmkfstools -i /vmfs/volumes/iscsi-01/01.vmdk /vmfs/volumes/iscsi-01/02.vmdk

Para romper el lock de un VMFS:

vmkfstools -B  /vmfs/devices/disks/vmhbaX:Y:Z:0

Para realizar un reset del bus a nivel del LUN (liberar reservaciones SCSI):

vmkfstools –lock lunreset /vmfs/devices/disks

Troubleshooting de snaphots y problemas de resignature de VMFS

Aquí en el caso de tener problemas con un snapshot que no se elimina desde el gui, podemos ir directamente al service console /DCUI y seguir estos pasos:

Dentro de la línea de comando ejecutamos el siguiente comando para enlistar las VMs que tenemos y poder conocer su ID:

vim-cmd vmsvc/getallvms

Una vez obtenido el ID borramos los snaps de dicha vm:

vim-cmd vmsvc/snapshot.remove VMID

o también podemos quitar los snaps con vmware-cmd (Solo ESX)

vmware-cmd vmfs/volume/vmfslabel/VMName/VMName.vmx removesnapshots

Para realizar resignature de VMFS les recomiendo leer mi post “VCAP – Sección 1 – Entendiendo y aplicando resignature a volumenes VMFS”

 

VCAP – Sección 1 – Storage Best Practices

Que tal Gente, continuando con los temas de VCAP nos toca hablar de las mejores practicas sobre almacenamiento y VMware.

VMware al igual que cualquier ambiente físico de servidores tiene mejores practicas para el almacenamiento, de entrada VMware nos recomienda siempre utilizar VMFS por las cualidades que este nos ofrece ya que es un sistema de archivos creado específicamente con la idea de ser clusterizable y para trabajar con ambientes VMware.

Voy a tratar de hacer este post lo más breve posible, así que vamos directo a las mejores prácticas:

• Evitar el uso de Extents para el crecimiento de nuestros Datastores: siempre que podamos lo mejor será evitar el uso de extents, debido a que por su principio básico lo que se esta logrando es tener un único sistema de archivos (VMFS) que esta constituido por varios luns, el problema principal que veo aquí es el hecho de si se pierde un lun de dicho sistema de archivos el Datastore completo se viene abajo. Una mejor opción sería el uso de Volume grow.

• Definir “Tiers” o prioridades de LUNS: Es básico definir el performance que cada aplicación requiere, y tener en base al performance requerido distintos grupos de LUNS con características específicas de performance, capacidad, etc.
• NUNCA crear más de un VMFS por lun: Esto es algo esencial, debido a que cada vez que se requiere hacer una actualización al metadata del lun VMware hace un “lock” o reservación scsi de el LUN completo, no solo de una partición.
• Definir el tamaño de bloque de nuestro VMFS: Aquí antes que nada les comento que no existe ninguna ganancia en cuanto a performance se refiere si nosotros seleccionamos algún tipo de blocksize.Este punto tiene que ver más con un correcto dimensionamiento y planeación de nuestra arquitectura, ya que el blocksize de nuestro vmfs dictará el tamaño máximo de un archivo en dicho Datastore:

• Alinear nuestros VMDKs: En este punto vSphere ya crea los datastores alineados con el almacenamiento adyacente, pero el problema se sigue presentando a nivel de nuestras máquinas virtuales, por eso es necesario siempre alinear nuestros templates para una vez que tengamos que hacer entrega de una maquina virtual tenga los discos alineados con el almacenamiento. Aquí les dejo unos links para que sepan cómo realizarlo:

http://www.vmware.com/pdf/esx3_partition_align.pdf

http://www.tcpdump.com/kb/virtualization/vmware-esx-server/vmware-disk-alignment/intro.html

• Limitar el número de VMs por Datastore: Aquí no existe un límite definido por VMware en cuanto a las máquinas virtuales que debemos tener por datastore, pero una buena práctica es la de limitar el número de VMs a 16 por datastore en el caso de servidores, y en el caso de vms view no más de 30 – 40 vms por datastore. Con esto tenemos un menor número de reservaciones scsi.
• ¿RDM o VMDK?: Personalmente solo utilizo RDMs en el momento que una máquina virtual requiere de un disco duro mayor a 400 – 500  GB por cuestiones de movilidad, razones específicas para utilizar rdm son las siguientes: Cluster Microsoft y Acceso directo a SAN para hacer uso de utilidades del almacenamiento.

• Crear un Datastore específico para archivos swap:Útil para ambientes donde se este replicando ciertos volúmenes, este espacio en disco puede ser dado en un arreglo de menor performance , está claro que este datastore tendrá que ser presentado de igual manera a todos los host del cluster para poder tener funcionalidades como VMotion.
• Crear un Datastore específico para imágenes ISO: Con esto logramos una estandarización de nuestras imágenes, una mejor administración y claro una mejor velocidad en el momento de instalaciones.
• Crear un Datastore específico para Templates: una mejor administración de nuestra libreria de VMs.
• Multipathing: tanto en ISCSI como en FC es necesario tener varios canales de comunicación con nuestro almacenamiento, por cuestiones de disponibilidad del mismo y en caso de el uso de Round Robin o Multipathing de terceros la capacidad de distribuir la carga entre distintos paths hacia nuestro almacenamiento.

Existen muchas otras recomendaciones / best practices especificas para cada proveedor de almacenamiento, aquí les plasme las best practices mas comunes y sin tomar en cuenta el proveedor de almacenamiento.

 

 

 

Block size	Maximum file size
1 MB	256 GB
2 MB	512 GB
4 MB	1024 GB
8 MB	2048 GB

VCAP – Sección 1 – Determinar el nivel de RAID para nuestras aplicaciones.

Que tal gente, hoy vamos a hablar sobre los distintos tipos de RAID e identificar los tipos de aplicaciones y sus requerimientos.

Comencemos por definir la palabra RAID (Redundant Array of Independent Disks), cuando hablamos sobre almacenamiento generalmente estamos hablando de arreglos de discos, también podríamos estar hablando de almacenamiento local. Todas las empresas de almacenamiento NetApp, EMC, Hitachi , etc.,nos ofrecen arreglos de discos de nivel enterprise, con capacidades de rendimiento, seguridad de datos y funcionalidades muy avanzadas. Pero todos estos proveedores se basan en el principio básico de RAID, que es la creación de grupos lógicos de discos para poder aumentar la seguridad de nuestros datos, tolerancia a fallos o el rendimiento y con esto el sistema operativo (Windows, linux, UNIX, VMware ESX, etc) ven este grupo de discos como un solo disco donde se puede almacenar datos.

Es momento de conocer que tipos de arreglos son los más comunes con los cuales estaremos trabajando en

• RAID 0 – (Stripe) este tipo de arreglo básicamente distribuye los datos entre los discos que conforman esta entidad lógica, aquí el problema que tenemos es la falta de un cálculo de paridad y por lo tanto cero tolerancia a fallos. Con este tipo de RAID obtenemos mejor rendimiento.

• RAID 1 – también conocido como espejo, este tipo de RAID crea una copia exacta entre un numero de discos, ej. si tenemos 2 discos cada uno tendría la misma información ya que una vez que se está por escribir la información esta es escrita en ambos discos. Con este tipo de RAID obtenemos mejor tolerancia a fallos sacrificando rendimiento.

• RAID 5 – Con este tipo de RAID obtenemos tolerancia a fallos y un mejor rendimiento, se hace el cálculo de la paridad y se escribe alternativamente entre los discos que conforman el arreglo de igual manera toda la información que se necesite escribir a disco es escrita de manera alternativa entre los discos. Con esto tenemos la capacidad de perder un disco del arreglo, en el momento que se pierde se reconstruye la información perdida a partir de la paridad. Aquí necesitamos como mínimo 3 discos, este tipo de arreglo es uno de los más comunes y de los mas adoptados debido a su buen rendimiento y tolerancia a fallos.

• RAID 1+0 – Este tipo de RAID es una combinación tanto de RAID 1 y RAID 0, como podrán imaginarse aquí hacemos una combinación tanto de la tolerancia de fallos que nos ofrece el arreglo 1 con el rendimiento que nos ofrece el arreglo 0. Este arreglo también conocido como RAID 10 es el más rápido y ofrece buena seguridad de datos, el problema es la cantidad de discos y por lo tanto la cantidad de $$ que requerimos para implementarlo, como mínimo requerimos 4 discos y solo pudiendo utilizar 2.

Nota: Cabe destacar que existen un gran número de niveles de RAID que aquí no describí, muchos de carácter propietarios como podría ser RAID-DP de Netapp. Al final de este post les dejo referencia a documentos y páginas web donde podrán leer más sobre el tema.

Una vez que refrescamos o conocimos sobre el concepto de RAID es necesario también conocer y definir los puntos claves para poder hacer un correcto dimensionamiento de nuestro almacenamiento para alojar nuestra infraestructura VMware. Me gustaría por definir algunos conceptos que estaremos manejando:

• IOPS (I/O por segundo): Este concepto define el número de operaciones a disco (Lectura/Escritura) que se tienen por segundo, aquí podemos ver el numero de IOPS que una aplicación en especifico está requiriendo para tener un correcto funcionamiento o el numero general de IOPS que un servidor está requiriendo.
• MBps (MB por segundo): Con este concepto básicamente estamos haciendo referencia a la capacidad del almacenamiento para responder a las peticiones de I/O, puede ser visto como el ancho de banda de nuestro almacenamiento.

¿Que puntos son necesarios determinar sobre nuestras aplicaciones para poder tener un correcto dimensionamiento de nuestro almacenamiento?

1. Determinar el número de operaciones a disco por segundo – IOPS
2. Determinar el ancho de banda requerido en nuestro almacenamiento – MBps
3. La capacidad de almacenamiento requerida – GB/TB
4. El nivel de redundancia requerido en nuestros volúmenes.
5. Tiempo de respuesta requerido por nuestras aplicaciones – Latencia en ms

Yo creo que en este punto nos estaremos preguntando como es que podemos obtener toda esta información, existen distintas maneras de para obtenerlo:

• Windows Perfmon (solo equipos Windows).
• VMware Capacity Planner.
• Herramientas de terceros, ej. Platespin PowerRecon.
• Requerimientos de las aplicaciones dictados por los desarrolladores de las mismas.

Una parte esencial que tenemos que tener en cuenta  en la planeación de toda la arquitectura de nuestro almacenamiento es el definir prioridades por aplicación, para esto es necesario crear grupos RAID basados en los siguientes criterios:

• Performance requerido I/O
• Capacidad
• Redundancia

con esto podemos tener distintos grupos RAID según el nivel de criticidad de nuestras aplicaciones.

Aquí les dejo algunos links con información sobre estos temas:

http://www.virtualizationtrainings.com/vmware-basic-trainings/vmware-advanced-study/disk-io-considerations-for-new-virtual-machine-placement

http://technet.microsoft.com/en-us/library/cc786889%28WS.10%29.aspx

http://www.netapp.com/library/tr/3298.pdf

 

XenServer 5.5 – Habilitando Multipathing para nuestros SR’s

Que tal gente, hoy toca hablar sobre XenServer, últimamente he estado utilizándolo y me parece un producto solido . En este articulo les mostraré como habilitar el multipathing para nuestros SRs (Storage Repositories) por default no viene habilitado.

Pas0 1 – Apagamos todas las maquinas que esten residiendo en dicho SR.

Paso 2 - Nos logeamos a nuestro servidor Xen atravez de ssh o directamente por XenCenter a la consola del  Control Domain.

Paso 3 – Una vez dentro necesitamos averiguar cuál es el uuid de nuestro SR con el siguiente comando :

‘xe sr-list’

Paso 4 – Una vez obtenido el uuid de dicho SR vamos a obtener el PBD (Physical Block Device) que le corresponde con el comando

‘xe sr-list uuid=<uuid del sr> params=all’

Paso 5 - Ya teniendo el uuid del PBD que corresponde a nuestro SR, lo necesitamos desconectar con el siguiente comando:

‘xe pb-unplug uuid=<uuid del pbd>’

Paso 6 – Nos conectamos a nuestro XenCenter y ponemos en modo de mantenimiento al host :

Paso 7 – Una vez en modo mantenimiento seleccionamos dicho host desde XenCenter y nos vamos a sus propiedades y cuando nos aparece un recuadro nuevo vamos a la pestaña de “multipathing”  y marcamos la casilla.

Paso 8 - Reconectamos nuestros PBDs, desde ssh con el siguiente comando :

‘xe pbd-plug uuid=<uuid del pbd> ‘

Paso 9 - Confirmamos en nuestro XenCenter que el Storage Repository ya este mostrando que están activos los paths:

¿DRS para nuestro almacenamiento?

¿Alguna vez han querido darle cierta preferencia a una vm en cuanto al vmfs se refiere? Bueno, pues esto puede ser una realidad, en varios posts en la web se ha hablado de una nueva posible característica que VMware incluirá en un próximo release de vSphere ¿El nombre? Storage I/O Control (SIOC), les recomiendo que lean el post del gurú de performance en VMware Scott Drummonds, que lo pueden encontrar en este link : http://vpivot.com/2010/05/04/storage-io-control/#more-515.

Todos sabemos que muchas veces la perdida de performance en una infraestructura VMware se debe a una mala configuración de nuestro almacenamiento , o a que el mismo no tiene la capacidad de entregar la cantidad de IOPS que nuestra infraestructura requiere , SIOC lo que nos permitirá es definir shares de disco pero esta vez no a nivel servidor ESX, sino a nivel arreglo, es decir esto aplicara para todos los servidores ESX que estén accediendo a un VMFS determinado en algún arreglo de discos esto lo podemos ver en las siguientes imágenes :

En esta primera  imagen podemos ver claramente que la distribución de nuestro arreglo está totalmente dispareja, la vm C está teniendo 50% del Queue del almacenamiento, mientra s las otras maquinas se reparten el otro 50%.

En esta segunda imagen podemos ver él como SIOC en base a los shares que tenemos configurados para cada máquina virtual , asignará los respectivos porcentajes de queue a nuestras vms, repartiendo el acceso al arreglo de una manera más equitativa.

SIOC se basará en la latencia que está presentando nuestro vmfs , y esto como nos comenta Scott , se basa en el total de latencias que están teniendo todas las vms que residen en dicho vmfs. Cuando este valor sobrepase el valor que nosotros configuramos como tope, se reducirá el acceso a nuestro arreglo a las maquinas con menos shares, permitiendo así que las maquinas criticas puedan mantener un buen funcionamiento.

Recuerden que esta funcionalidad no ha sido revelada oficialmente, hasta ahora solo se ha comentado que se está trabajando en ella,  aquí les dejo un link de vmware donde pueden lver una presentación del vmworld 2009 sobre SIOC:

http://vmworld.com/docs/DOC-3855