VMFS resignature

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 – 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.