Log Insight Sizing

 
Tomaremos como punto inicial de referencia la tabla con los diferentes tamaños de los virtual Appliances que nos ayudará con la primera orientación.

Opción: tamaño del Appliance seleccionado durante la instalación

GB/Día: Cantidad de GBs soportados por día sumando todos los sistemas conectados a Log Insight

vCPUs: Número de vCPUs, de al menos 2GHz, que necesita cada Appliance según el tamaño seleccionado

RAM: Cantidad vRAM con la que se aprovisionará (no necesariamente utilizará) el Appliance según la opción seleccionada

IOPS: Número estimado de IOPS que gestionará el Appliance según el tamaño seleccionado

Conexiones: Número de conexiones (Hosts, devices, etc,) al Log Insight

Eventos: Número de eventos por segundo estimado que gestionará el Appliance en esta opción seleccionada. Esta columna se deberá tener muy en cuenta ya que definirá en gran parte la carga de trabajo y, por lo tanto, el tipo o los tipos de Appliance a desplegar

Por ejemplo un Host ESXi envía 10 mensajes por segundo con un tamaño promedio de 170 bytes por segundo. Esto equivale a 150MB por día, por Host.

Si comenzamos utilizando el Appliance Extra Small y vamos a gestionar un número reducido (no más de 6 u 8) de Hosts, Sistemas y/o Dispositivos, es posible reducir la RAM del Appliance desde 4 hasta 2GB.

Para un correcto dimensionamiento es necesario considerar no solamente el número de Hosts, Sistemas (Switches, Routers, Firewalls, Almacenamiento, etc) y Sistemas Operativos. Debemos tener en cuenta el número de instancias de Log Insight a desplegar. No olvidemos que el licenciamiento de vRLI es por número de sistemas gestionados, no por instancia de Log Insight desplegado. Además cuando desplegamos múltiples Nodos de vRLI, al tener 3 o más Nodos configurados en Cluster, comenzaremos a utilizar el balanceador embebido. Los Clusters de 2 Nodos no están soportados en Log Insight.

Relación Eventos-IOPS

Otro de los aspectos importantes a la hora de diseñar e implementar cualquier sistema de gestión de Logs, naturalmente también aplica a vRLI, es considerar la relación entre el número de Eventos y los IOPS que generará.

A mayor número de Eventos, mayor será el impacto en el número de IOPS que tendremos que soportar. Pero este impacto no solo afecta a la hora de escribir sino que además damos por descartado que nos interesará disponer de un buen tiempo de respuesta en las búsquedas de los Logs.

Para tener una buena experiencia utilizando vRLI simplemente tendremos en cuenta las características o bien los recursos que dan soporte al Datastore (o grupo de Datastores cuando se trata de un Cluster) que dará servicio a cada Nodo de Log Insight.

Formato de disco a utilizar

Como sabemos existen tres opciones o formatos de disco virtual que podemos configurar. Divididos en dos grupos que son Thin Provisioning y Thick Provisioning, dentro del grupo Thick podemos elegir Lazy Zeroed o Eager Zeroed.

Para un entorno de pruebas podríamos utilizar Thin Provisioning sin problemas.

Recomiendo utilizar Thick Provisioning, a ser posible Eager Zeroed, para los despliegues con destino Producción.

El formato Thick Provisioning no solamente reservará el espacio necesario para cada Appliance en los Datastores correspondientes sino que además nos aseguraremos que vRLI continuará funcionando en caso de quedarnos sin espacio en esos Datastores.

Lo último que querremos en caso de problemas es quedarnos ciegos en cuanto a acceso a Logs verdad?

La recomendación del formato Eager Zeroed es debido a que durante la creación del disco se inicializan todos los bloques y eso nos garantiza el mejor rendimiento posible dentro de los formatos de disco virtual. Además es una buena práctica conocida.

Red y Registros DNS

La red a la que conectaremos el/los Appliance/s de vRealize Log Insight será la misma red de los Hosts y vCenter. En caso que también gestionemos los Logs de otros sistemas como Dispositivos físicos, Sistemas Operativos o cualquier otro, simplemente deberemos cerciorarnos que vRLI será capaz de llegar a esos sistemas a través del Router configurado en los parámetros de Red. Esto impactará en las ACLs InterVlan.

Al igual que con el resto de los Appliances de VMware debemos tener creados antes de la instalación los registros de tipo A y PTR. Otro Must!

Si bien esto es bastante obvio nunca viene mal recordarlo ;-)

Solo por comentar que si bien durante la instalación de Log Insight es posible configurar múltiples servidores DNS, el sistema únicamente utilizará los dos primeros servidores ignorando el resto….. Cosas de la tecnología…

Cuántos Nodos debo desplegar?

Vamos con una respuesta de Consultor: depende!

No hay un número exacto a partir del cual deberíamos comenzar a trabajar con múltiples Nodos. Ante todo vamos a recordar que un Cluster de Log Insight únicamente está soportado a partir de 3 Nodos.

Otro punto importante a considerar es que el Cluster de vRealize Log Insight no trabaja en modo Multi-Site. Esto define que necesitamos hacer un deploy de al menos un Appliance por Site. Lo que sí es posible es configurar un reenviador de Eventos desde una instancia (o Cluster) de un Site hacia otra instancia de Log Insight (o Cluster) para consolidar Logs e incluso para su archivado.

A considerar:

-Requerimientos

-Escalabilidad

-Disponibilidad*

-Balanceo

-Criticidad de los servicios de gestión y almacenamiento de Logs

-Número de Sistemas gestionados (Hosts, Devices, OSs, etc)

*Un Cluster de Log Insight trabaja con distribución de carga pero no funciona en Alta Disponibilidad

A partir de las consideraciones anteriores y conociendo el número de sistemas gestionados deberíamos estar en condiciones de decidir si trabajaremos con una única instancia de Log Insight, así como su tamaño.

Un motivo claro podría ser que tengamos que gestionar más de 250 sistemas, entre Hosts de ESXi, Switches, Routers, Sistemas Operativos y otras soluciones como sistemas de Almacenamiento, Firewalls, Hardware, etc, etc..

Con ese número (más de 250) tendríamos que decidir entre desplegar un Appliance XL o decantarnos por esa solución de múltiples Nodos en Cluster que mencionamos anteriormente.

Un ejemplo del escalado que soporta este sistema sería un Cluster de 12 Nodos de vRLI con una carga de hasta 180.000 eventos por segundo o 2.7 TB de eventos registrados en un día.

Buenas prácticas en un Cluster de HA

Si bien el título de este párrafo merece un Post aparta (y lo tendrá) vamos a definir el alcance de las buenas prácticas únicamente a los servicios de Log Insight.

HA: Nodos de vRLI habilitados con HA. Prioridad de reinicio media. Protección solo VM.

DRS: Reglas de anti-afinidad entre los Nodos de Log Insight.

VSAN: Política de VSAN para reservar espacio. Protección N+1.

vAPP: No hace falta reservar recursos de CPU ni de RAM. Automatizar encendido y apagado de todos los Nodos de Log Insight.

Servicios complementarios

Al igual que con cualquier otro servicio a desplegar es necesario disponer de servicios complementarios para un correcto funcionamiento de la solución a implementar.

NTP: Muy importante a la hora de consolidar Logs y permitir autenticación de terceros

SMTP: Fundamental si pretendemos configurar alertas con envíos de emails

NFS: Recurso necesario en caso de optar por utilizar el sistema de archiving en Log Insight

Active Directory: Nos permite integrar usuarios y/o grupos de Active Directory y facilitar/consolidar la autenticación

SSL: Ya sea para incrementar la seguridad como también si el servicio queda expuesto de forma pública, es otra buena práctica utilizar certificados públicos.

Y de esta forma cerramos este segundo Post sobre esta poderosa herramienta que es vRealize Log Insight.

Espero que te haya resultado de utilidad y agradeceré tu feedback. Como siempre, un placer ;-)