troubleshooting

Servidores virtuales ESXi (Nested) y valores de %KAVG

rsz_vmware

Que tal gente, el día de hoy les voy a platicar sobre un problema que tuve en mi laboratorio. Me encontraba instalando un vPOD de Horizon Suite donde incluía Mirage, View, etc, lo interesante es que también estoy incluyendo VSAN para poder mostrar la interacción. Como he platicado en algunas otras ocasiones, mi laboratorio esta […]

Troubleshooting de base vPostgres en vCenter – ¿Como eliminar inconsistencias?

Que tal gente, hace algunos días (en realidad al menos 1 mes) me encontraba listo para realizar una demo de Horizon Suite para el grupo de ingeniería preventa de VMware México, por lo que encendí mi laboratorio y oh sorpresa… mi appliance de vCenter Server no levantaba… algo extraño ocurría  en el momento de levantar la base de datos embebida, lo primero que me paso por la mente fue verificar si desde la consola web de administración podía conectarme a la base y pues bueno este fue el resultado:

web-basenocontecta

 

 

Como pueden ver efectivamente no se tenia conexión con la base, por lo que comencé a investigar un poco y con apoyo de algunos colegas internamente pude verificar que efectivamente se tenia un problema con la base de datos y esto era registrado en el log “postgresql.log”:

  db: pid:18939 LOG:  database system was interrupted while in recovery at 2013-04-16 08:51:20 CDT
db: pid:18939 HINT:  This probably means that some data is corrupted and you will have to use the last backup for recovery.
db: pid:18939 LOG:  database system was not properly shut down; automatic recovery in progress
db: pid:18939 LOG:  consistent recovery state reached at 3/6B08B9E8
db: pid:18939 LOG:  redo starts at 3/6AF58C50
db: pid:18939 PANIC:  checksum mismatch: disk has 0x39835139, should be 0x76213af3 filename base/16385/17482_fsm, BlockNum 2, block specifier 1663/16385/17482/1/2 —> bloque corrupto
db: pid:18939 CONTEXT:  xlog redo insert: rel 1663/16385/17482; tid 2/31
db: pid:18937 LOG:  startup process (PID 18939) was terminated by signal 6: Aborted
db: pid:18937 LOG:  aborting startup due to startup process failure

Por lo que claramente tuve que recurrir a apoyo de el excelente equipo de soporte que tenemos (GSS – Global Support Services, Marcelo y Andrew) ellos me apoyaron a poder resolver el problema y poder levantar mi appliance virtual, básicamente se tuvo que ejecutar un comando que detecta inconsistencias en los checksums, pero esto en el appliance virtual funciona un poco distinto que en el caso de vPostgres en otro SO, esto debido a que el usuario “postgres” no tiene definido bash en el archivo /etc/passwd lo cual requiere una modificación de este archivo para cambiar:

/bin/false

a

/bin/bash

Con esto podemos continuar y realizar dos tareas, un respaldo de seguridad de la base de datos y después intentar corregir las inconsistencias:

  • obtenemos el password para podernos conectar a la base de datos embebida, para esto, ejecutamos el comando:

cat /etc/vmware-vpx/embedded_db.cfg

lo cual nos desplegará información de la base de datos, solo copiamos el password que podemos encontrar después de “EMB_DB_PASSWORD”

Screen Shot 2013-06-25 at 2.36.47 PM

  • Una vez obtenida la password es necesario realizar el respaldo como medida de seguridad antes de trabajar con la base de datos, para esto, necesitamos ejecutar los siguientes comandos:

su postgres      —> esto nos cambiará el usuario de Root a postgres

cd /opt/vmware/vpostgres/1.0/bin  —> esto nos cambiará el directorio de trabajo para poder ejecutar el respaldo

./pg_dump VCDB > /storage/db/vpostgres/VCDB.bak   —> esto realizará el respaldo, se nos pedirá el password

Screen Shot 2013-06-25 at 2.44.08 PM

  • Después de haber realizado el respaldo es momento de identificar las inconsistencias y resolverlas, para esto debemos ejecutar el siguiente comando donde debemos especificar el bloque o los bloques corruptos (estos aparecen en el log, pueden comprobarlo en el inicio del post):

/opt/vmware/vpostgres/1.0/bin/postgres –single -D /storage/db/vpostgres -c fix_block_checksum=”1663/16385/17482/1/2

Screen Shot 2013-06-25 at 2.50.26 PM

Después de haber realizado estas tareas mi appliance virtual de vCenter levantó (¡Gran felicidad para mi! no tenia que reconstruir mi lab que incluye vCD,etc!!) como lo podemos ver en la imagen:

Screen Shot 2013-06-25 at 2.52.36 PM

RECORDEMOS QUE ESTO SOLO ES PARA MOTIVOS EDUCACIONALES Y DE PRUEBAS, EN EL CASO QUE SE ENCUENTREN EN ESTE MISMO PROBLEMA DEBEN DE LEVANTAR TICKET DE SOPORTE CON VMWARE, ESTO DEBE DE SER MANEJADO A TRAVÉS DE GSS.

 

 

VCAP – Sección 6 – troubleshoot de vCenter y administración de hosts ESX/ESXi

Que tal gente, vamos a continuar con los temas para el examen VCAP-DCA, en este caso nos toca hablar un poco sobre troubleshooting de vCenter y de la administración de hosts, que herramientas y comandos podremos estar ocupando para este fin.

Identificar comandos y herramientas utilizadas para realizar troubleshooting de administración

Bueno aquí básicamente en el caso de tener problemas de conexión con nuestros hosts ESX/ESXi seria utilizar los comandos que nos permiten observar cual es la configuración actual de red:

  • esxcfg-vswitch
  • esxcfg-vswif (solo ESX)
  • esxcfg-nics

En este punto también es bueno saber que tenemos la opción para utilizar los dos métodos de colección de logs que tenemos a nuestro alcance:

  • vm-support –  este script recolecta logs de vpxa (agente de vCenter),configuración de este, y dumps del mismo, realiza lo mismo en el caso de hostd y de HA.
  • vc-support – con esta utilidad que encontramos en el servidor de vCenter, podemos recolectar archivos de configuración del vpxd, logs, etc.

Troubleshoot del servicio de vCenter y la conexión a la base de datos del mismo

Aquí les recomiendo leer los siguientes kb de VMware:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003928

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003926

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003960

Y también una fuente excelente para poder comenzar con nuestro troubleshooting son los logs que pertencen al vCenter, los cuales encontramos en:

  • C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\Logs

Esta ruta la podemos modificar ingresando las siguientes líneas en el archivo vpxd.cfg:

<log>
<directory>c:\ruta</directory>
</log>

Troubleshooting del firewall en el Service Console (ESX)

Bueno para poder consultar y modificar la configuración del firewall que se tiene en el Service Console lo realizamos con el comando esxcfg-firewall, estas son las opciones que acepta:

  • -q –query – nos muestra la configuración del firewall
  • -q –query (nombreservicio) – nos muestra si el estatus de dicho servicio.
  • -q –query incoming|outgoing – nos muestra si los puertos ya sean de entrada o salida estan bloqueados, por default vienen bloqueados excluyendo aquellos que ya tienen una regla para permitir su uso.
  • -s –services – nos muestra aquellos servicios conocidos que están permitidos.
  • -l –load – carga la configuración actual de firewall
  • -r –resetDefaults – regresa la configuración de firewall a sus valores default.
  • –blockIncoming – bloquea todos los puertos de entrada, a menos que tengamos un servicio o regla permitido.
  • –blockOutgoing – bloquea todos los puertos de salida, a menos que tengamos un servicio o regla permitido.
  • –allowIncoming – permite conexiones en todos los puertos de entrada.
  • –allowOutgoing – permite conexiones en todos los puertos de salida.
  • –e –enableService (nombreservicio) – habilita un servicio en especifico, abriendo así los puertos que se necesitan para el funcionamiento del mismo.
  • –d –disableService (nombreservicio) – deshabilita un servicio en especifico, cerrando así los puertos que se necesitan para el funcionamiento del mismo.
  • -o –openPort -AR -port,tcp|udp,in|out,name – con esta opción podemos abrir un puerto, ej. esxcfg-firewall -o 500,tcp,out,servicio
  • -c –closePort – con esta opción cerramos un puerto, ej. esxcfg-firewall -c 500,tcp,out,servicio

Troubleshoot management de hosts ESX/ESXi y problemas de conexión

Bueno aquí mas que nada les recomiendo leer mi post de troubleshooting de red VCAP – Sección 6 – Troubleshooting de Red y también VCAP – Sección 6 – Configurar,administrar y analizar logs de vSphere.

Paso-a-paso – vscsiStats

Que tal gente, hoy lunes después de una semana pasada algo ocupada  y de no haber podido postear nada decidí regresar con información que a mi parecer es muy interesante y les va servir mucho, este día les voy a hablar de una utilidad de VMware con la cual podemos monitorear directamente los adaptadores virtuales SCSI de nuestras vms, la información es recolectada al nivel del kernel de vmware, con esto tenemos la capacidad de ver el comportamiento de nuestros  VMDKs o RDMs sin importar que tipo de almacenamiento tengamos o mejor dicho el protocolo que manejamos(iSCSI, NFS, Fibra).

Para poder comenzar con el uso de esta herramienta tenemos que ir directamente a su directorio, esto porque no se encuentra directamente en el PATH, lo cual no nos permite invocarla desde cualquier ubicación .

Paso 1

Vamos al directorio :

/usr/lib/vmware/bin/

Paso 2

Ejecutamos la aplicación y pedimos que se nos enlisten las maquinas o procesos :

‘ ./vscsiStats  –l ’

Paso 3

Una vez enlistados los procesos, decidimos que proceso o vm es la que queremos monitorear,  el numero del proceso será identificado como  worldGroupID, en este caso el ID que monitorearemos será el 4292 , para ello ingresamos el comando :

‘./vscsiStats -s -w 4292 ’

“-s” nos indica que comienze el monitoreo, y  “-w” nos indica el proceso o vm a monitorear.

Paso  4

Una vez transcurrido el tiempo necesario o el tiempo que hayamos decidido para monitorear la vm exportamos la información directamente a un archivo CSV (comma delimited value) a nuestra carpeta temporal, para esto ingresamos el siguiente comando:

‘./vscsiStats -w 4292 -p all –c vscsi.csv > /tmp/vscsi.csv ’

en este caso “-p” nos indica el tipo de información que exportaremos (ioLength, seekDistance, outstandingIOs, latency, interarrival)

“-c” indica que esta información sera exportada en formato .csv.

Paso 5

Una vez exportado el archivo , cancelamos el monitoreo con el commando:

‘./vscsiStats –x’

Utilizamos una herramienta de scp para copiar el archivo de la ruta /tmp de nuestro servidor ESX , en mi caso WinSCP:

Graficar resultados de vscsiStats

Honestamente nunca me ha gustado estar leyendo números y el archivo CSV que generamos con vscsiStats es números y mas números,  navegando por internet me encontré con un muy buen macro de Excel para poder graficar estos datos y tener una manera mas “amigable” de leerlos, aquí les dejo el link a dicho macro:

http://www.gabesvirtualworld.com/wp-content/uploads/2010/02/vscsiStats-excel-macro.txt

Paso 1

Abrimos el archivo csv con Excel, y tecleamos  ‘Alt + F11’ , esto nos dará acceso a Visual Basic:

Paso 2

Copiamos el texto tal cual de el macro y tecleamos ‘F5´ esto nos generara una serie de worksheets con las graficas , estas serán nombradas basadas en el contenido de dichas graficas y del handleID de nuestro disco :

Aquí le dejo un ejemplo de las graficas generadas :

Usos de vscsiStats

1-. Identificar workloads o tipos de acceso a disco (secuencial o al azar).

2-. Tamaños de las operaciones de IO, ej.  4k 8k, etc

3-. Latencia de nuestro almacenamiento , recordemos que en el caso de vscsiStats el protocolo no importa, por lo cual podemos monitorear NFS cosa que con esxtop no es posible.

Instalando y Configurando Stratusphere – Parte I

Que tal Gente, el día de hoy les voy a hablar de una herramienta la cual es excelente para poder hacer troubleshooting, poder saber que recursos vamos a necesitar para poder virtualizar nuestra infraestructura física existente, monitoreo, etc. Aquí a lo largo de varios posts les iré presentando varios pequeños artículos con información que esta herramienta nos arroja, les comento que yo trabajo para Goldmahn Solutions en México, y somos la representante de LiquidwareLabs es por eso que tengo mucho contacto con esta herramienta.
En la pagina oficial de liquidware labs, podemos encontrar bastante información de la herramienta, también existen varios tipos de webex para conocerla, aquí les dejo la liga:
http://www.liquidwarelabs.com/
Vamos a comenzar con lo básico para poder conocer la herramienta , el como instalarla en nuestro laboratorio , aquí les dejo los pasos:

Instalación en VI3 o vSphere:

1-. Agregamos la maquina ya sea por .OVF:

Nos aparecerá la siguiente ventana :

Aquí ingresaremos la URL que se nos proporcionará una vez que llenemos una pequeño formulario en la página de Liquidware, aquí les dejo el link directo para ese formulario :

http://www.liquidwarelabs.com/Download/

Una vez que importamos el Stratusphere Hub dentro de nuestra infraestructura virtual, es momento de configurar el portgroup donde conectamos nuestro appliance, ambos appliances virtuales tanto el Hub como el Network station, tienen 2 vNics, la primera la utilizamos con propósitos administrativos y de comunicación, y la segunda esta en modo monitor, para poder atrapar paquetes y en base a eso hacer todo el análisis de red. Mas adelante posteare como funciona exactamente la solución de Stratusphere, les describiré su arquitectura, pero esto será en un próximo post.
Habilitamos en el portgroup donde se conecto la segunda vNic de nuestro appliance el que acepte modo promiscuo :

Una vez hecho esto, tenemos todo listo para configurar nuestro appliance, en el siguiente post configuraremos nuestro hub y una network station.

Si tienen alguna duda o comentario haganmela saber, dejenme un post y las resolvemos.