La idea de esta serie de Posts es obtener una idea global de los principales conceptos de vRealize Operations Manager, vROps para los amigos, con el fin de familiarizarnos con esta poderosa herramienta.
Es preocupante la cantidad de infraestructuras de VMware que disponen no solo de licencias de vROps, sino que además el servicio está instalado y funcionando aunque es muy bajo el porcetaje de empresas que realmente saben utilizarlo.
El motivo es muy claro y no es otro que la falta de conceptos sumado a muy poco tiempo invertido en la herramienta.
Comprender 50 conceptos clave es la diferencia entre leer y comprender un texto técnico.
Vamos a comenzar con una pequeña descripción de qué es vROps.
vRealize Operations Manager es un sistema de Gestión de la Capacidad y Monitorización de los Recursos que, a través de su sistema de auto-aprendizaje, tiene la capacidad de proveer recomendaciones y alertas de forma proactiva.
La instalación y configuración de vROps es muy pero muy simple ya que está compuesto por pocos componentes y tanto el despliegue como la configuración inicial se hacen en pocos minutos.
1-Nodo: Un nodo es una instancia del Appliance de vROps que cumple una determinada función. Existen 4 tipos de Nodos para dar servicio al Cluster de vRealize Operations Manager como son el Master, Replica, Data y el Collector.
Cualquier despliegue de vROps requiere, al menos, un nodo.
El instalador es el mismo para los Nodos del Master, Replica y Data y el OVA en versión 8.1 ocupa un tamaño de 2.57 GB.
2-Cluster: Todo despliegue de vROps incluye un Cluster. No importa si nuestra instalación es muy simple y está compuesto por un único Nodo, siempre tendremos el servicio de Cluster. Tal servicio estará Online mientras esté operando y para ejecutar tareas de mantenimiento como añadir otro Nodo, Actualizar o Parchear debemos detener el servicio dejando el servicio de Cluster en estado Offline.
TIP: Para acceder al panel de gestión del cluster apuntamos a https://fqdn-vrops/admin, mientas que para las tareas del día a día de vROps utilizamos https://fqdn-vrops/ui.
3-Master (Node): El Master Node es el servidor principal de vROps que se encarga de todas las tareas como recoger métricas, analizarlas, clasificarlas, almacenarlas, presentarlas, enviar notificaciones y otras tareas como autenticación y gestión de APIs y el interface de usuario.
El primer Nodo del Cluster ejecutará todas las tareas mencionadas anteriormente. En pruebas de concepto o instalaciones pequeñas que no requieran alta disponibilidad es posible utilizar un único Nodo en el Cluster que operará como Master.
TIP: Al tratarse de un sistema de monitorización y análisis es un MUST apuntar a un NTP, el mismo al que estén apuntando sistemas como DC’s, vCenter, nodos NSX, etc.
4-Replica (Node): El Replica Node o Master Replica Node nos permite disponer de Alta Disponibilidad en el Cluster de vROps.
Los Nodos Master y Replica se repartirán las tareas de Análisis y, en caso de fallo del Master Nodo, el Replica Node se encargará de la continuidad del servicio. Los datos del Master Node se replicarán en el Replica Node incrementando la disponibilidad del Cluster.
El despliegue en Alta Disponibilidad requiere de un servicio externo de balanceo que se encargue de la monitorización de los Nodos y de la distribución del tráfico.
TIP: Crea reglas de anti-afinidad para distribuir la ejecución de los Nodos del Cluster en Hosts diferentes. Idéntico caso si estamos utilizando Storage DRS.
Aplicar las recomendaciones del sizing recomendado por VMware según el tamaño y considerar aprovisionar los appliances (Nodos) sobre almacenamiento con buen rendimiento.
5-Data (Node): La forma de escalar nuestro Cluster de vROps después de haber desplegado un Master y un Replica Node es desplegar una o más instancias de Data Node.
El Data Node se encarga del almacenamiento de los Datos, especialmente orientado para grandes despliegues como indican los diseños validados de VMware.
TIP: Tenemos a nuestra disposición el vROpsSizer, una excelente web que nos permite introducir los datos de nuestro entorno y nos recomendará el número de Nodos y sus correspondientes capacidades.
Link: https://vropssizer.vmware.com/sizing-wizard/choose-installation
https://vropssizer.vmware.com/sizing-wizard/choose-installation
6-Collector: Los collectors o recopiladores son instancias mínimas de vROps que únicamente recogen métricas y las reenvían al servicio de Cluster. Es especialmente útil cuando contamos con una infraestructura distribuida en varios Sites, incluso separados por miles de kilómetros, ya que nos permite disponer de un único punto de control para múltiples Sites.
Otro caso de uso de los Collectors es distribuir la carga (o liberar al Master y Replica Node) para la tarea de recepción de métricas.
7-Adapter o Account: Anteriormente llamado Adapter o recientemente renombrado a Account (o Cloud Account) es el nombre que utilizamos para llamar al conector que apunta a un determinado recurso o servicio para poder recibir métricas, parámetros y estados.
Por ejemplo el Account más común es el que utilizamos para conectarnos a una o múltiples instancias de vCenter Server.
TIP: Utilizar cuentas de servicio para conectar nuestro vROps al vCenter nos permite identificar las tareas y carga de trabajo que procede de vROps en nuestras instancias de vCenter.
8-Metrica: Valor de un determinado contador asociado a una instancia de un objeto que proviene de un Adaptador o Cuenta Cloud.
Ejemplo: Valor [65] de un contador [CPU Workload] asociado a una instancia de un objeto [VM] que proviene de una Cuenta Cloud [vCenter].
Las cuentas Cloud/Adaptadores cuentan con múltiples tipos de objetos asociados y cada objeto tiene su colección de propiedades, estados y métricas.
TIP: Independientemente de conocer cómo funciona vROps, si no estamos familiarizados con ciertos valores de referencia como son las métricas principales será algo complicado comprender qué es lo que está ocurriendo con ese objeto de la infraestructura.
9-Threshold: Existen determinados umbrales que delimitan el estado de las métricas de los objetos. vRealize Operations Manager utiliza 4 colores que son verde, amarillo, naranja y rojo. Siguiendo con el ejemplo del consumo de vCPU podemos decir que un valor de consumo de hasta 69% se mostrará en color verde. De 70 a 79% el color del estado será amarillo y resentará un aviso. Un valor de entre 80 y 89% estará “pintado” de color naranja y deberá ser considerado con una alerta y si el consumo de vCPU supera el 90% de uso veremos el estado del contador en color rojo y, en consecuencia, debemos considerar el estado como critico.
En el supuesto caso que no estemos recibiendo métricas del objeto el color que represente el estado será gris.
TIP: No todas las cargas de trabajo deberían ser consideradas bajo la vara del mismo umbral ya que no es lo mismo un Cluster crítico en Producción que otro destinado a pruebas y desarrollo. Podemos adaptar los Thresholds a través de las Políticas.
10-Parametro: Es muy fácil confundir una métrica con un parámetro. Una métrica puede cambiar su valor con cierta frecuencia dependiendo de lo que esté representando.
Un parámetro nos sirve para obtener valores que cambian muy poco con el tiempo o que directamente no cambian. Como ejemplos podemos mencionar la versión del SO del guest, el nombre de una BBDD, la dirección IP de un controlador de dominio o el número de discos de capacidad de un Disk Group en vSAN.
Además es posible crear grupos de objetos dinámicos en base a propiedades como Tags o Etiquetas y gestionar esos objetos agrupados, por ejemplo, en base a un SLA en común.
TIP: Podemos definir nuestros Parametros utilizando el API de vROps y extender de esta forma la monitorización de determinadas aplicaciones sin necesidad de desarrollar con el SDK.
Bonus Track -> eBook gratuito “Maximizing VMware vRealize Operations” por David Davis
Como decía al principio, espero que les resulte de utilidad. Si te gustó por favor ayudame a compartirlo para que pueda llegar a mas gente.
Nos vemos en el próximo Post!!!