All Posts by Albert Gris

vRealize Operations Manager: Primeros pasos

Capura de vrealize vRealize Operations Manager

Serie de posts sobre vRealize Operations Manager

vRealize Operations Manager es la solución de VMware que nació para darle a nuestro entorno vSphere una visibilidad profunda y eficiente, de una manera fácil y sobretodo flexible. Cada vez se está consolidando más como la herramienta de monitorización para estos entornos: el hecho que sea del mismo VMware ayuda, pero sobre todo es la facilidad de recolectar métricas y presentar los datos, adaptándose muchísimo a los procesos u operativas de cada departamento de IT.

“Out-of-the-box” ya nos da muchísima información tanto a nivel de análisis como a nivel de generación de alertas o notificaciones, pero es sin duda cuando se genera una necesidad de datos sobre el entorno en nuestro departamento cuando podemos sacarle el máximo partido, generando el reporte, dashboard o alerta que precisamos de manera personalizada.

Es por ello que voy a dedicar los siguientes post a ver con profundidad vRealize Operations Manager, desde su instalación a cómo configurarlo de manera que nos ayude precisamente a dar respuesta a nuestras demandas.

¿En qué consiste vRealize Operations Manager?

vRealize Operations Manager es una solución de monitorización y Capacity Planning que, como tal, se enfoca en tres grandes funciones: recolectar datos, analizarlos y presentarlos.

En todos estos puntos, vROps destaca de entre los demás de la siguiente manera:

  • En cuanto a recolección, es rápido y muy fácil de configurar para que acceda a las métricas/datos de los sistemas origen. Es importante resaltar que, aunque sea de VMware, no es un producto orientado únicamente a monitorizar nuestro vCenter, ni siquiera orientado a monitorizar sólo productos de VMware. Por defecto lo que nos viene es vROps con el conector para vCenter, ése siempre estará ahí, pero existen un montón de “Management Packs” del propio VMware para integrar vRealize Operations Manager y monitorizar otras de sus soluciones más allá de vCenter o incluso de terceros para monitorizar dispostivos (switches, cabinas, …) o aplicaciones (SAP HANA, Oracle, Antivirus, …). Aquí podréis ver qué plug-ins, ampliaciones y Management Packs existen. Hay fabricantes como Blue Medora que se dedican a desarrollar este tipo de conectores.
  • En cuanto a análisis, estaremos de acuerdo en que previamente a la caída o malfuncionamiento de un sistema, este experimentará en la mayoría de los casos un comportamiento distinto al “normal”, anómalo. Las soluciones de monitorización tradicionales basan sus sistemas de alertas en tratar la evolución de una métrica según evolucione en el tiempo y dar su comportamiento como “correcto” mientras esté contenida en un umbral preestablecido. vROps va mucho más allá. Aprende el comportamiento normal según patrones que ya ha analizado para ese objeto y su motor analítico es tan potente que permite no solo levantar alertas por que tal métrica ha alcanzado el umbral que le hemos establecido, sino que además nos dirá si ese objeto está teniendo el comportamiento esperado para ese momento. De esta manera podemos preveer un potencial problema en cada elemento monitorizado. Además, es sencillo poder crear escenarios “What-If” que nos permiten simular qué niveles de servicio tendría nuestro actual entorno si le añadiéramos más capacidad, más VMs/demanda, le quitaramos un host…,
    Finalmente, tenemos la capacidad de aplicar políticas según queramos ser más agresivos o más conservadores en cuanto a todo lo que el análisis y tratamiento de las métricas se refiere, ya sea en umbrales de alertas, Capacity Planning, …
  • En presentación de datos, además de traer reportes, widgets y Dashboards por defecto, nos aporta una gran flexibilidad para poder crear nuestros propios paneles y reportes a medida, según más nos convenga.

Una vez tiene analizadas las métricas de los objetos a monitorizar, genera unas métricas propias llamadas “Badges” que consisten en un resumen del estado de cada objeto en los siguientes términos: Salud, donde nos indicará si el objeto está actualmente experimentando algún problema o error. Riesgo, que aporta la información de capacidad y tiempo restante de nuestra infraestructura según la proyección del uso y crecimiento actual de la misma, así como problemas de salud sostenidos en el tiempo. Por último eficiencia, detallando qué oportunidades de ahorro o reclamación de recursos tenemos según el uso que estemos haciendo de la infraestructura.

De este modo que podemos tener una gran variedad de entornos monitorizados bajo una sola herramienta.  Esto nos da la gran ventaja de poder relacionar los diferentes objetos de nuestra infraestructura en todas las capas. Aún mas, ofréce toda la potencia de un motor analítico muy desarrollado y customizable. Finalmente, la libertad de customizar la presentación de datos para adaptar la herramienta a las operativas de nuestro departamento.

Arquitectura de vRealize Operations Manager

A nivel de arquitectura/implementación, vROps tiene dos tipos de despliegue según los niveles de disponibilidad que se quiera de la aplicación o la cantidad de datos que se gestionen: un modo “all-in-one” en el que un solo nodo se encarga de recolectar los datos, analizarlos y mostrarlos o un modelo distribuido en el que se pueden desplegar los siguientes nodos:

  • Master Node: siempre habrá uno nodo con este rol en nuestro “cluster” de vROps, ya sea “all-in-one” o distribuido. Este nodo se encarga de gestionar todos los demás y lleva todos los roles.
  • Data Node: Lleva los conectores para poder recolectar datos de las diferentes fuentes
  • Replica Node: Réplica del master para dar HA al cluster de vROps
  • Remote Collector Node: Estos solo recolectan información de los objetos de inventario, no almacenan los datos ni los tratan, sirven para reducir el consumo de ancho de banda para monitorizar entornos externos.

Conclusión

vROps es la solución para dar la visibilidad que todo entorno necesita. VROps permite así ser mucho más eficientes en la resolución de incidencias, poder prevenir las mismas y tener el control de cuánta infraestructura nos queda.

VMware está ofreciendo un programa de optimización de infraestructuras mediante vROps con el que se entrega un informe detallado de los problemas reales y potenciales de cada entorno basado en vSphere, así como las oportunidades de ahorro en recursos que tenemos. No dude en contactar con nosotros rellenando este formulario con la opción “Monitorización de sistemas” para llevar a cabo uno de estos estudios y tener una imagen real del estado de salud y la proyección de su entorno.

La entrada vRealize Operations Manager: Primeros pasos aparece primero en Un cio como tu ….


Source: jmgriscom

Configurando OVAs i OVFs con OVFTOOL

packageovaovf

La portabilidad es sin duda una de los principales beneficios de definir nuestras máquinas como virtuales. Al ser éstas un compendio de ficheros de configuración, son fácilmente exportables e importables en otros entornos manteniendo su consistencia. Sin embargo, la proliferación de hipervisores y versiones de los mismos hace que no siempre sea “tan” fácil.

Para tal efecto nació el formato OVF (Open Virtualization Format). Su objetivo era sencillo: una manera standard de poder definir una VM para que pudiera ser importada en un hipervisor distinto del que fue “originada”. Consiste en una carpeta que incluye un fichero XML con extensión .ovf (podemos verlo como el equivalente a el .vmx que describe la configuración de nuestra VM en origen) juntamente con los .vmdk, los discos de nuestra VM y normalmente un fichero .mf que contiene un hash SHA1 de los ficheros del ovf. Poco después, salió el .ova, que no es más que la compresión de la carpeta que conforma el OVF.

Hasta aquí todo suena bien, pero la realidad nos lo suele complicar bastante más: ¿qué sucede por ejemplo si tenemos una VM en un entorno VMware Fusion 8 de desarrollo y queremos importarla en un ESXi 6.0? Lo más normal es que hubiéramos creado la VM en versión de Hardware 12 en origen cuando, en destino, esta versión no está soportada.

Para todas las tareas relacionadas con la gestión y configuración de un fichero .ova o un paquete .ovf, nació ovftool, una herramienta de VMware.

¿Cómo solventamos el problema expuesto antes?

Normalmente, al intentar importar el .ovf de nuestra VM exportada de Fusion en vSphere 6.0, recibiremos el siguiente error:

The OVF package requires unsupported hardware
Details: Line 25: Unsupported hardware family ‘vmx-10’.

Primero de todo, vamos a descargar ovftool desde aquí. A continuación, vamos a obtener el fichero .vmx a partir del .ovf. Ejecutamos el siguiente comando:

ovftool <ruta donde se encuentra el fichero .ovf> <ruta donde queremos guardar el fichero .vmx>

Una vez tenemos el .vmx, lo abrimos con un editor de texto y cambiamos la línea virtualHW.version a la versión de hardware que soporte nuestro hipervisor en destino.

Imaginemos ahora que no partimos de un fichero .ovf y partimos de un .ova. Para pasar del formato comprimido a .ovf nos valemos también de ovftool mediante el siguiente comando:

ovftool.exe --lax <ruta donde se encuentra el fichero .ova> <ruta donde queremos guardar el fichero .ovf>

Para más información, recomiendo ver su manual acerca de lo que nos puede aportar ovftool.


Source: jmgriscom

Organiza tus jobs de Veeam mediante políticas

organiza-tus-jobs-mediante-veeam

El hecho de que la virtualización es una tecnología ya bastante madura en cada vez más entornos supone muchos retos. Vamos añadiendo cargas (seguramente cada vez más críticas y sensibles) a los hipervisores, nuevas máquinas, ratios de consolidación más agresivos y demás realidades que parece que induzcan la idea de que mantener el control de nuestra infraestructura tenga que ser más una cuestión de “hacer malabares”. Estos fenómenos son los que o ya afrontamos o afrontaremos en algún momento y es por ello que por ahí van las tendencias de los fabricantes cada vez apostando más por la automatización y la monitorización.

Estas realidades aplican por supuesto también a las soluciones que dependen directamente de nuestra infraestructura vSphere, como por ejemplo Veeam Backup&Replication. Antes de nada, en el caso de Veeam, lo primordial es mantener una definición de los requerimientos de cada VM en cuanto a su nivel de disponibilidad, luego veremos cómo aplicarlos y sobretodo mantenerlos de manera ágil.

Al final, lo que queremos es una manera ordenada y dinámica de proteger nuestras VMs según las condiciones específicas de cada una de ellas.

Para definir estas políticas deberemos analizar qué requerimientos tienen nuestras VMs o nuestros perfiles de VMs: tenemos que declarar los parámetros en los que basaremos nuestras políticas de Backup/Replicación.

Paso 1 – definir parámetros y valores

Un ejemplo sencillo de estos parámetros podría ser el siguiente:

  • RPO
    • ¿Cada cuanto tiempo debemos ejecutar una copia de la VM? Lo podemos medir en minutos, horas, días …
  • Ventana
    • ¿Qué intervalo tenemos para ejecutar la copia? Pierde relevancia si usamos Storage Snapshots. Expresado en franja horaria.
  • Retención
    • ¿Qué histórico de copias debemos almacenar para esa VM? Lo especificaremos en valores “absolutos”. Es decir, si quiero mantener una semana de copias y mi RPO es de 24h, tendrá un valor de 7.
  • RTO
    • Tiempo en poner la máquina en producción a partir de la declaración del desastre. En sí no es un parámetro que apliquemos al job como el RPO, pero podemos agilizarlo usando Reverse Incremental o más aún con replicas.
  • Encriptación
    • ¿Debemos encriptar los datos de esa VM?
  • OS
    • Mantener VMs de OS/Datos/Apps parecidos nos ayudará a tener mejores ratios de deduplicación.
  • ¿Backup secundario?
    • Hay que almacenar una copia de la VM en algún otro lugar.

Paso 2 – agrupar

Con  este análisis como primer paso, tendremos una descripción en términos de protección de datos de nuestras VMs, “metadatos” para cada una. Ahora nos hará falta agruparlas según valores parecidos. Fácilmente, acabaremos (siga esto entendiéndose como ejemplo) con un grupo que será “Producción – Linux” con unos valores iguales para cada parámetro en todas las VMs. Con estos grupos, tendremos una posible propuesta de organización/distribución de nuestros Jobs de Backup/Replicación.

Paso 3 – “dinamizarlo”

Sin embargo, no olvidemos que el principal ánimo de este post es hacer el trabajo (sobretodo el de mantenimiento) más sencillo. De momento, tenemos una manera ordenada de proteger a nuestras VMs según los requisitos específicos de cada una, pero no hemos hablado de cómo hacer todo este proceso dinámico o semi-automatizado.

Cuando hablamos de Jobs dinámicos en Veeam Backup & Replication, nos referimos a Jobs que como origen tienen un objeto que no es/son una VM en sí. En la definición del job, como “Source”, podemos añadir una a una cada VM que cumpla los requisitos definidos por el Job. Si tu entorno es pequeño, y sobretodo, con pocas modificaciones, es algo planteable, pero si el entorno va evolucionando (que es lo más normal), habrá que empezar a plantear otras maneras, puesto que no vamos a ir añadiendo VMs a los Jobs, sería bastante ineficiente.

En el fondo, para tener un job dinámico bastaría con crear uno solo para toda tu infraestructura que, como “Source”, incluyera todo el vCenter. De esta manera, toda máquina nueva sería incluida directamente en la copia sin necesidad de dar “un paso más” añadiéndola. Sin embargo, catalogar todas las VMs bajo la misma definición no es lo que buscamos tampoco.

Es aquí donde toman relevancia objetos de vCenter que quizás no habías tenido en cuenta antes, como son las etiquetas (o “tags”) y las carpetas. En este whitepaper, Luca Dell’Oca nos sugiere que, una vez definidos los grupos de VMs que hemos visto en el paso 2, cada grupo se mapee a un tag de vCenter y luego, creando un Job para cada grupo, añadir cada etiqueta como “source” del job. Así pues, para nuestro grupo de ejemplo “Producción – Linux”, tendremos que crear su etiqueta en vCenter, etiquetar cada VM que pertenezca a este grupo con ella, y luego crear un Job de Veeam que como Source tenga dicho tag. Además de ser un genial White Paper (recomiendo descargarlo y leerlo detenidamente sobre todo por cómo se detallan los pasos), me parece un método perfecto para entornos heterogéneos, diversificados, (muy) grandes y con muchos usuarios y permisos en vCenter. Sin embargo, quizás vea más acorde a un entorno “standard” de los que tenemos hoy en día por nuestras tierras usar las carpetas de vCenter . La razón es sencilla: al crear una VM, ya sea mediante el wizard tradicional del cliente de vSphere o incluso mediante herramientas de terceros como Chef, nos dejará (de hecho nos “obligará”) especificar en qué carpeta la ubicamos.

Esto hace que no tengamos que dar ese “paso más” de luego ir y etiquetar la VM. Luca habla de maneras muy válidas mediante scripting por ejemplo de automatizar el proceso de etiquetar, pero quizás es demasiado complejo si ya nos sirven las carpetas.

La idea es que no queden máquinas virtuales fuera de copia. Si usamos carpetas, nos aseguramos que siempre nos pregunte en qué carpeta ponemos la VM, pero cabe la posibilidad de que la VM caiga en la carpeta “Discovered Virtual Machines” o en la matriz del Datacenter. Para mitigar este problema, podemos por ejemplo ejectuar un pequeño script que cada dia revise que no queden VMs en carpetas que no estén incluidas en ningún job.


Source: jmgriscom

Planificando vuestra visita al VMWORLD 2016

vmworld-2016

Se acerca Octubre y con él llega el VMworld europeo de este año. Después del éxito del evento americano que reunió a casi 25000 personas en Las Vegas durante este final de Agosto. Por lo que ha llegado de los asistentes, poquitas novedades significativas se anunciaron y estuvieron muy centradas en OpenStack, containers y Cloud con especial foco en este último con presentaciones como Cloud Foundation i vCloud Availability. Es por eso que se esperan mayores noticias para el evento europeo (no olvidemos la noticia de la compra de EMC por parte de Dell durante el evento del año pasado).

VMworld siempre aporta grandes experiencias en muchos planos. Ver el “state of the Art” de todo lo relacionado con virtualización y Software Defined DataCenter, reencontrar amigos de todos los rincones, los eventos paralelos, los regalos… A todos nos encanta, sin embargo, en mis últimas experiencias siempre acabo con una sensación de que podría haber aprovechado más a nivel técnico ya que la cantidad y sobretodo calidad de las sesiones es altísima. No nos engañaremos, en los días que dura el evento no da tiempo a verlo todo. Es imposible. Pero a más planificación, más probabilidades de ver todo lo que nos propongamos.

Así que si lo que queréis es “actualizaros”, ver en profundidad funcionalidades o productos de o sus Partners, os recomiendo encarecidamente que le deis un vistazo a este enlace. Se trata del catálogo de contenidos de todas las charlas que se realizarán en el VMworld europeo este año. Las plazas para las sesiones son limitadas, así que si teneis claro que queréis asistir a alguna, registraros cuanto antes. Podréis montaros un pequeño calendario de sesiones a las que asistir Además, en breve debería aparecer la app para el VMworld 2016 EU donde podréis realizar lo mismo de manera más cómoda e ir consultándolo in-situ (incluso recibir notificaciones de los eventos a los que estáis suscritos).


Source: jmgriscom

Reclamando espacio en cabinas Thin Provision a nivel de vSphere

Una de las grandes novedades que trajo vSphere 5.0 fueron las APIs de integración con las cabinas para optimizar ciertas tareas, sobretodo aligerando la carga del hipervisor. La idea es pasar esta carga a la cabina, quien tiene más facilidad para operar con los datos que ya residen en ella.

Si tenemos una cabina con configuración compatible con estas APIs, las tenemos habilitadas por defecto por lo que el uso de muchas de sus funcionalidades las usamos de manera transparente. Sin embargo, hay algunas de estas “primitivas” que nos pueden ayudar muchísimo pero hay que conocerlas, puesto que requiere que las invoquemos de alguna manera. Una de ellas es “Unmap”:

“Unmap” resuelve un dolor de cabeza con el que te habrás enfrentado si usas una cabina con Thin Provisioning, que es la reclamación. Thin Provisioning, como toda innovación, aporta muchas ventajas pero también tiene sus consideraciones. Una de ellas es la necesidad de reclamar el espacio inutilizado.

Este espacio se genera cuando el SO de nuestras máquinas virtuales deja de usar una cantidad de almacenamiento que anteriormente usaba. Lo que sucede es que en realidad, el sistema operativo marca este espacio como libre pero no hace lo propio la cabina, quien aún lo mostrará como espacio ocupado en nuestros Disk Groups.
A nivel de vSphere es más sencillo de entender: Supongamos que tenemos una LUN/Datastore de 500GB de capacidad con una VM en ella de 100GB en uso. En ese momento, nuestro Disk Pool en la cabina marcará que tenemos 100GB utilizados. Pero pongamos que, por algún motivo, tenemos que restaurar esa misma VM, en esa misma LUN. Sin problema, podremos mantener las dos VMs y nuestro Datastore marcará un uso de 200GB, hasta que a posteriori, cuando eliminemos la VM original, el uso de nuestro Datastore será 100GB de nuevo. Sin embargo, en nuestro Disk Pool, aparecerán usados 200GB. Tradicionalmente, el procedimiento por el cual recuperábamos esos 100GB que corresponden a la VM original consistía en crear un VMDK “Thick Provisioned – Lazy Zeroed” de un espacio un poco menor que el que marca el Datastore como libre. En nuestro ejemplo, el Datastore marcará 400GB libres por lo que creando un VMDK de ese modo, lo que haremos es marcar todos los bloques que use ese nuevo disco a cero. Una vez realizado, tendremos que decirle a la cabina que reclame espacio en ese Disk Pool. Lo que hará este comando, es buscar bloques a cero que no estén en uso, por lo que podremos recuperar casi la totalidad de los 100GB que ocupaba la VM que hemos ocupado.

Este método conlleva bastantes problemas potenciales más allá de su relativa complejidad:
El paso de crear el VMDK en Eager Zeroed marcará en cero bastantes bloques. Esta operación es bastante pesada para la cabina por lo que podríamos impactar en el rendimiento de otros servicios. Volviendo a las VAAI, otra primitiva que ayuda un montón es “Write Same”. Tradicionalmente, cuando un host ESXi quería marcar a cero bloques (como al crear un disco en Eager Zeroed), lo hacía mandando comandos SCSI a la cabina que lo cargaban en ciclos de procesador y sobretodo, en la cola de la HBA de turno. Con VAAI esta operación la realiza la cabina de manera transparente descargando al host, pero si no es compatible nuestra LUN, querremos tener control con esta operación.
No podemos crear un VMDK del mismo tamaño que el que marca el datastore como libre, pues lo llenaríamos y bloquearíamos las VMs que se ejecutan en él. Igualmente, querremos quedarnos cuanto más cerca posible de ese valor para recuperar cuanto más espacio. La avaricia rompe el saco, cuanto más cerca queramos quedarnos, en más riesgo entraremos.

Todo este procedimiento podemos resumirlo en un simple comando, el comando de esxcli “unmap” (valga la redundancia). Además, nos va a recuperar todo el espacio realmente disponible, pues va iterando en búsqueda de bloques ya no usados y los marca a cero automáticamente. Es importante remarcar que, aunque VMware anuncia que a partir de 5.5 el impacto es mínimo, igualmente vamos a sobrecargar cabina al reclamar, así que mejor hacerlo en horario de mantenimiento.

Visto lo que nos puede aportar “unmap”, veamos cómo podemos invocarlo.

Primero de todo, debemos tener el UUID del datastore anotado. Nos conectaremos por SSH a cualquier ESXi que tenga ese Datastore presentado y, una vez dentro, anotaremos qué UUID tienen las LUNs sobre las que queremos reclamar. Para ello, ejecutaremos el comando
# esxcli storage vmfs extent list.
El output nos dará un listado de los Datastores que ve el host con el nombre que les hayamos dado, y al lado qué UUID tienen las LUNs que lo componen, en la columna “Devices”. Tomamos nota de la que nos interesa y listo.
Antes de nada, tendremos que asegurarnos que nuestro datastore soporta VAAI. Para verlo, # esxcli storage core device vaai status get -d naa.xxxxxxxxxxxxxxxxxxxxxxxxxx. El campo “Delete” debe estar en “Supported”.
En este momento ya lo tenemos todo listo para ejecutar el comando “unmap”. Solo queda por discutir un punto: cuantos bloques vamos a “unmapear” por iteración. Aquí, lo mejor es hablar con el fabricante de vuestra cabina para acordar qué valor le damos. Así que estamos preparados, vamos a ejecutar:
# esxcli storage vmfs unmap –u XXXXXXXX-XXXXXXXX-XXXX-XXXXXXX –n YYY, donde la cadena de Xs será el UUID que anotamos en el paso 1 y las Ys el número de bloques que queremos que reclame por iteración.
Por último, podremos monitorizar el proceso mediante esxtop. Ejecutamos el comando # esxtop en nuestro ESXi, clickamos “u” para ir a la ventana de discos/devices, clickamos “f” y escogemos qué campos queremos mostrar.

fields

Depende de la resolución de vuestra pantalla, seleccionad solo el campo de “Device name”, que nos mostrará los naa de las LUNs y “o” y “p” para ver las métricas de comandos de VAAI. Además, si os cabe, podéis incluir el campo “i” para ir monitorizando también los tiempos de latencia en general (R/W) y poder ir viendo que no tengamos ningún susto.

Entonces, una vez hemos seleccionado los campos que queremos ver en nuestra ventana de esxtop y hemos ejecutado nuestro comando de unmap en una LUN, veremos algo como esto:

extop

Las columnas que nos interesan son:
DELETE: número de comandos de unmap que se han ejecutado sobre la LUN
DELETE_F: número de comandos de unmap que han fallado sobre la LUN
MBDEL/s: MB que está “unmapeando” en este momento el comando que hemos ejecutado. Aquí solo deberías ver distinto de cero la LUN que has seleccionado.

Por último, tendremos que reclamar. Recordad que con unmap estamos liberando bloques, o informando a la cabina de qué bloques ya no están en uso en vSphere. Lo que faltará és que la cabina los reclame y por lo tanto los marque como Free en nuestro Disk Pool. Aquí ya cada una lo hará a su manera. La mayoría tendrán un botón de “Reclaim” que barrerá todo el Disk Pool en búsqueda de los bloques que habremos liberado, y que por lo tanto, pueda marcar como libres. En el caso de Datacore por ejemplo, al ejecutar el comando de unmap, se dispara automáticamente la funcionalidad de “Auto-Reclaim” que lo que hará será ir reclamando los bloques que vamos liberando de manera transparente, unmap lo desencadena todo. Lo veréis así (Storage Source – Online, auto-reclamation in progress):

cabina


Source: jmgriscom

VMmark: benchmarks para nuestro entorno virtualizado

Realizar pruebas de carga sobre nuestra infraestructura para ver sus niveles de respuesta bajo niveles previamente estipulados es un “must”. Tanto en el momento de instalar como para evaluar el nivel de respuesta de la infraestructura ante potenciales cambios. Aún así, puede resultar difícil realizar test realísticos pues hay que o dominar muy bien la aplicación para crear cargas sintéticas, que simulen reales, o disponer de herramientas específicas para cada test de simulación de stress para cada recurso.

Aunque estas opciones sirven para dar ciertos niveles de información con sus métricas, ninguna de ellas está pensada para testear una infraestructura virtualizada orientada a la consolidación de servicios.

Al final, VMmark usa aplicaciones que usamos día a día en nuestros Datacenters. Las agrupa en “tiles”, que son grupos de VMs que ejecutan varios servicios, cada tile con su cliente. Esta unidad precisamente, el tile, nos sirve para medir la capacidad de consolidación de nuestra infraestructura, contabilizando cuantos de ellos podemos ejecutar bajo niveles aceptables de rendimiento. Los servicios que simula cada tile son:

  • VM en Standby
    • Windows Server 2003 32bit, 1 vCPU, 512MB RAM, 4GB disco
  • Mail Server (Exchange 2007)
    • Windows Server 2008 64bit, 4 vCPU, 8GB RAM, 72GB disco
  • Web 2.0 (Olio)
    • Back End: SLES 11 64bit, 2vCPU, 2GB RAM, 14GB disco
    • Front End: SLES 11 64bit, 4vCPU, 6 GB RAM, 80GB disco
  • E-commerce (DVDStore 2)
    • Back End: SLES 11 64bit, 4vCPU, 4GB RAM, 45GB disco
    • 3xFront End: SLES 11 64bit, 2vCPU, 2GB RAM, 10GB disco

Todos ellos con ficheros de configuración perfectamente descritos por las guías de VMware, los clientes para los servicios y sobretodo los scripts de ejecución y reporting, nos darán datos muy exhaustivos, reales y directamente orientados a un entorno virtualizado.

Podéis obtenerlo la herramienta vmmark benchmark aquí.

maxresdefault


Source: jmgriscom

Obtener datos e informes de storage en tiempo real de nuestra infraestructura de vSphere II

La semana pasada vimos como sacar datos de caracterización y rendimiento de nuestros discos virtuales mediante la herramienta vscsiStats nativa de ESXi. Hasta donde conté en ese post, podíamos ver los datos directamente en el terminal pero además, podemos exportarlos y tratarlos para generar informes de uso que pueden resultar muy útiles.

graficos-stats

Para ello, primero de todo tenemos que modificar los comandos con opción –p para que exportar los histogramas a csv y luego poder tratarlos. El comando para exportar todos los histogramas a csv sería:

# vscsiStats -p all –w <worldID> -c > /root/vscsiStats-export.csv

Una vez generado en el directorio que le indiquemos como parámetro, lo podemos importar mediante scp por ejemplo. Una vez descargado en nuestro equipo es cuando podemos empezar a tratarlo. De por sí tendremos los datos en “crudo”, pero hay maneras de poder graficar los resultados para analizarlos de manera más visual.

Lo que necesitaremos es Excel y una macro que podemos obtener aquí desarrollada por Paul Dunn y Matt Kelliher. Así los obtendremos:

  • Abrir el fichero csv que hemos obtenido desde el ESX en excel
  • Apretar alt+f11 y añadir el código de la macro
  • Para ejecutar el código, bastará con apretar f5

Con ello, obtendremos los gráficos de los datos que hemos recabado desde vscsiStats.

Otra gran herramienta más sencilla y directa es ésta desarrollada por virten.net. Subimos el fichero .csv  e inmediatamente obtendremos los gráficos.

Source: jmgriscom

Obtener datos e informes de storage en tiempo real de nuestra infraestructura de vSphere

Cada vez hay más soluciones de terceros o del propio VMware que nos sirven para monitorizar y analizar nuestra infraestructura. Las infraestructuras van madurando y se vuelven más confiables, hecho que hace que se virtualicen más cargas en ellas. Además, ya prácticamente todas las aplicaciones están soportadas dando niveles de rendimiento a la par o incluso mejores que en entornos físicos. Más consolidación de máquinas virtuales por host, más dispersión y máquinas virtuales más sensibles hacen que la necesidad de monitorizar de manera más exhaustiva sea una realidad

Como decía, hay herramientas de diversos tipos y funcionalidades que sacan, procesan y almacenan datos de rendimiento de nuestra infraestructura virtual para que podamos generar alertas o informes predictivos. Podríamos entrar a valorar muchas de ellas, pero antes creo que es casi obligado conocer las herramientas nativas en vSphere/vCenter. Conocerlas, además de otras ventajas que expondré seguidamente, nos ayudará a conocer “de base” las métricas más críticas que luego podremos explotar con otras soluciones.
 
Una de estas herramientas nativas es vscsiStats, nativa en ESXi. Con ella, obtendremos datos de caracterización del uso a nivel de Storage de nuestras máquinas virtuales. Qué ventajas supone? Como decimos, es nativa, por lo que ya la tienes incluida en tu hipervisor, es rápida en obtener datos en real-time, puesto que estamos consultando directamente el scheduler de ESXi, es relativamente sencilla de usar (veremos cómo a continuación) y fácilmente podemos exportar los datos que nos aporta. A diferencia de los datos de storage que nos aporta esxtop, otra herramienta nativa de monitorización para ESXi, que solo aplican para almacenamiento basado en iSCSI o Fibre Channel, vscsiStats nos da más variedad de información y sobretodo sin importarle en qué tipo de almacenamiento esté la VM, pues se sacan los datos a nivel de disco virtual.
 
Podremos sacar información de storage de cualquier VM, pero qué información? Básicamente lo que nos dará vscsiStats son datos de utilización y carácter de las operaciones de I/O de storage durante un periodo de muestreo en forma de histograma, por lo que será importante ejecutar las cargas que queremos monitorizar durante ese momento. Podemos sacar los siguientes histogramas:

  • seekDistance: localidad “espacial” de los I/Os
    • Dada una VM, podemos ver la secuencialidad de los bloques que consulta/escribe. Si un bloque está más cerca que los consultados/leídos inmediatamente antes, se accederá mucho más rápido. En cambio, si el patrón de uso de bloques es muy aleatorio, impactará en el rendimiento. Es interesante juntar patrones de uso común en las mismas LUNs para intentar optimizar el rendimiento.
  • ioLength: tamaño de IO
    • Como comentaba en anteriores posts, es importante alinear las configuraciones en todas las capas que intervienen en el uso de disco, pero a su vez puede resultar muy complejo. Sobretodo a alto nivel, pues puede resultar complicado sacar patrones de IO a nivel de sistema operativo de la VM o incluso la aplicación que use. Con vscsiStats, podremos sacar datos del tamaño de IO real que están utilizando nuestras VMs sin importar qué OS/aplicación estén ejecutando. Por ejemplo, si sabemos el tamaño medio de IO de nuestras VMs, podemos configurar el tamaño de stripe de nuestra cabina a ese valor para maximizar su rendimiento.
  • latency: análisis de latencias
    • Rápidamente podemos sacar analizar qué tiempos de respuesta están teniendo nuestras operaciones de I/O para sacar medias, ver a qué máximos estamos llegando y ver qué latencias son las más comunes.
  • interarrival
    • Nos sacará qué tiempo entre llegada de I/Os están teniendo nuestras VMs.
  • outstandingIOs
    • Al llegar una operación de I/O, se calculan cuantas otras para ese disco virtual están aún pendientes por llegar. Al verlo en histograma, se puede ver que concurrencia de I/Os se tiene para ese disco y ver si hay contención a nivel de profundidad de colas.

Vistas sus posibilidades, vayamos a ver como funciona:

  • Recoger IDs de las VMs y los discos: como hemos visto, vscsiStats se invoca para empezar a captar datos. Estos pueden ser referentes a todas las VMs y todos sus discos o de una VM o disco en concreto.

Si queremos recoger datos de todos los discos y VMs, podemos obviar este primer paso. En caso contrario, deberemos introducir el siguiente comando en la consola de nuestro ESXi (por SSH o DCUI):

# vscsiStats –l

El output serà un listado de las VMs y discos. Los datos que queremos obtener serán el “Virtual Machine worldID” que identificará nuestra VM y el “Virtual SCSI Disk handleID” que identifica el disco virtual. Con estos dos datos, seguimos adelante.

  • Empezamos la recolección de datos: debemos usar la opción “-s” para empezar a capturar datos de uso de nuestras VMs.

Si queremos capturar datos de todas las VMs y discos, tan solo hace falta que ejecutemos el siguiente comando:

# vscsiStats –s

En caso de que querramos monitorizar todos los discos de una VM en concreto, necesitaremos el parámetro “Virtual Machine worldID”:

#vscsiStats –s –w <worldID>

Si queremos concretar más y solo capturar datos de un solo disco virtual necesitaremos el “Virtual Machine worldID” y el “Virtual SCSI Disk handleID”

# vscsiStats –s –w <worldID> -i <handleID>

A partir de ejecutar el comando con la opción –s, empieza el periodo de muestreo que durará (si no indicamos lo contrario) 30 minutos. Si queremos alargárlo, tenemos que volver a ejecutar el comando –s con los parámetros que hayamos especificado anteriormente para “renovar” otros 30 minutos más.

  • Sacar histogramas: una vez hemos empezado a llenar los contadores, ya podemos obtener histogramas del uso. Como hemos visto previamente, hay varios disponibles así que previamente debemos saber cuál queremos sacar. Una vez está claro:
    1. seekDistance: # vscsiStats –p seekDistance
    2. ioLength: # vscsiStats –p ioLength
    3. latency: # vscsiStats –p latency
    4. interrarrival: # vscsiStats –p interarrival
    5. OIOs: #vscsiStats –p outstandingIOs

De esta manera podremos obtener los datos que precisamos en la pantalla de nuestra consola. En el siguiente post veremos como exportar datos con esta herramienta y ver como podemos sacar informes con los datos en excel.

.code {
font-family: “Courier New”, Courier, monospace;
}

Source: jmgriscom