Etiqueta: homelab

vCenter data en Prometheus – visualizando con Grafana!

vCenter data en Prometheus – visualizando con Grafana!

En los últimos días tuve muchos problemas con mi instalación de LibreNMS, esto me llevo a re-evaluar mi solución de monitoreo, desde hace annos estaba usando LibreNMS y antes de este tenia Observium, la facilidad de agregar equipos para monitorear, simplemente es fácil y funcional.

Volviendo al tema, LibreNMS falló, dos veces en menos de un mes. Decidido, tenia que probar la plataforma de la que todos hablan, Prometheus.

Prometheus con AlertManager se ha vuelto la solución de monitoreo para muchos, por el hecho de usar Grafana como visualización nos da un gran abanico de posibilidades y a la vez nos enfrentamos a una curva brutal de aprendizaje. Para los que han usado Grafana, saben el tiempo que se tiene que invertir en tener los gráficos deseados pero una vez hecho es una hermosura. Sumado a esto tenemos AlertManager, actualmente no tengo tanta experiencia con este software pero lo estaré investigando mas a fondo.

Continuar leyendo «vCenter data en Prometheus – visualizando con Grafana!»

FreeLoadBalancer.org – Kemp LoadMaster para el HomeLab.

KEMP es un proveedor de soluciones para alta disponibilidad y balanceo de carga (LoadMaster), mi primer contacto con el producto fue buscando una solución tipo empresarial para reemplazar Ngnix y/o Apache (mod_proxy). Uno de los primeros escenarios donde leí sobre el despliegue de las soluciones de LoadMaster (LVM100 para ser exacto) fue con vSphere Web Client y Exchange Server.

Cuando fue mi turno de desplegar LoadMaster lo hice usando ESXi como plataforma y en ese momento use dos servidores físicos cada uno con una VM de LoadMaster.

Para ese momento KEMP no tenía una versión gratuita como lo hace ahora y por esta razón no podía jugar con la solución en el homelab, ahora todo cambia, hace varios días KEMP anuncio la versión gratuita que tanto he esperado e inmediatamente un VLM y estoy probando como configurar la plataforma y reemplazar un ZenLoadBalancer que tengo corriendo desde hace un tiempo y es el usado para publicar muchos de los servicios que uso de prueba o uso personal.

La configuración tradicional de un LoadMaster es para tener alta disponibilidad de un aplicativo web, digamos un Lync, Exchange o VMware Horizon View. En mi caso la idea de usar LoadMaster (como lo ha sido con ZenLoadBalancer) es poder publicar todo lo que necesite ya sea HTTP(80) o HTTPS(443) usando una única dirección IP (o varias si es necesario). Me gustaría aclarar que la solución ZenLoadBalancer no me ha fallado y ha cubierto la necesidad que tenía, entonces porque cambiarlo?

La decisión podría decirse que es personal ya que pienso, es más probable que termine administrando un LoadMaster a que me encuentre o que decida instalar ZenLoadBalancer en un ambiente empresarial.

Las funcionalidades, si miramos en http://freeloadbalancer.com. Podemos ver que la versión gratuita nos trae Layer4-7 Load Balancer, Reverse Proxy, Edge Security, WAF (Web Application Firewall) y GSLB (Global Server Load Balanceing), para ser versión gratuita tiene buena pinta, la única funcionalidad que podría hacer falta es HA pero como esto esta apuntado a pequeñas empresas o homelab como es mi caso puede que sea la razón de que no esté disponible HA.

Para más información de las diferencias se puede ver directamente en http://freeloadbalancer.com

La razón de este post es tratar de documentar los pasos y configuraciones que necesite para poder usar LoadMaster como un Reverse Proxy que es actualmente como uso ZenLoadMaster en mi homelab, una diferencia que aplica en mi homelab es que dos de los host ESXi están en un datacenter a unas cuantas miles de millas de mi localidad y me conecto con ellos a través de una VPN tipo mesh (Tinc VPN). Para LoadMaster los Real Servers no están en la misma subred e inicialmente falla al ser agregados en los Virtual Servers si no hacemos los cambios necesarios, esto podría aplicar si los VirtualServers están en 192.168.100.0/24, los RealServers están en 192.168.200.0/24 y el LoadMaster está en modo One-ARM.

Aquí un pequeño diagrama de red donde se ve un VLM en un lado de la red:

Lo primero que debemos hacer es definir algunos Content Rules.

 

 

En mi caso quedo algo asi:

Aquí se puede ver mientras modifico una regla llamada guacamole:

Procedemos a agregar un Virtual Server, en mi configuración inicialmente tendré un Virtual Server para el puerto 80 y otro para el puerto 443.

En Advanced Properties habilitamos Content Switching.

Ahora toca crear los SubVS que queramos o necesitemos. Actualmente solo tengo 2 en la parte de HTTP:

Como se puede ver en la imagen anterior, ya estos 2 SubVS tienen Content Rules habilitadas y seleccionadas, si hacemos click en el numero podremos remover o agregar otro Content Rule.

Con relación a los Real Servers, estos serán agregados en cada SubVSs, cuando usamos Content Rule los Real Servers podrían ser el mismo ya que el Content Rule se encargaría de definir el Host Header y re-direccionar el tráfico a donde sea necesario.

Lo importante es tener en cuenta los Content Rule, allí es donde decidiremos cuales dominios serían los aceptados, esto es parecido a los Virtual Name de Apache.

Otra configuración que tuve que aplicar en mi caso fue habilitar fue la de Eable Non-Local Real Servers que se encuentra en System Configuration > Miscellaneous Options > Network Options., además de esto los Virtual Servers no pueden tener habilitado Transparency.

Aquí la documentación oficial -> https://support.kemptechnologies.com/hc/en-us/articles/201849033-How-do-I-add-remote-Real-Servers

Configurando la Base de Datos para Eventos en View 5.3

Como a otros, no me gusta tener servicios a ciegas, me refiero a no saber que pasa dentro del aplicativo y sus componentes, VMware View tiene la opción de conectar el Connection Server a una DB, en este caso lo estaré conectando a MSSQL para salvar esos eventos y poder analizarlos en caso de problemas en el servicio de View. Si hacemos click en Monitoring > Events tendremos la siguiente pantalla donde podemos ver un mensaje que nos indica que aún no hemos configurado la DB para los eventos.  Procederemos a realizar esta configuración, ya había creado la DB para estos fines, así que solo falta decirle al Manager cual es el servidor, las credenciales y el prefijo. Realizada la configuración podemos ver que la opción de eventos nos muestra que mi usuario realizo una configuración. View Connection Server también nos brinda enviar logs a un log server el cual más adelante también configurare.

VMware DRS con DPM en el HomeLAB.

Hoy llegue a casa para encontrar el área del HomeLAB demasiado caliente, en estos momentos en mi HomeLAB creo que existen demasiados dispositivos. (no!!!! Nunca!) En fin, mi ambiente de VMware consta de 3 ESXi los cuales están encendidos la mayoría del tiempo, la habitación donde están el HomeLAB por naturaleza es caliente ya que el Sol muere en sus paredes a eso agréguenle equipos generando calor. Hace tiempo atrás intente usar DPM para conseguir lo mismo que he conseguido esta vez, que DRS & DPM se encarguen de encender los ESXi cuando vSphere los necesite sin intervención manual.

Lo primero es que ninguno de mis equipos tiene iLO/IPMI u otra variante que ayude a DPM a realizar su tarea así que he recurrido al viejo y no tan confiable WoL (Wake-on-LAN). Uno de los inconvenientes conocidos con DPM es que no puede enviar la señal de levantar el ESXi si este no cuenta con un IP de manejo en un vSwitch, normalmente no uso vSwitch y siempre despliego vDSwitch para ahorrarme cosas y simplificar la conectividad de mis ESXi, por suerte esta vez contaba con una NIC que no la agregue a los vDSwitch y solo tuve que crearle otro vmk para manejo.

Los pasos son los siguientes:

Asegurarnos de que nuestra tarjeta soporta la funcionalidad.

Habilitar DPM en el Cluster y especificar Manual en las opciones de DPM dentro de DRS.

Seleccionamos un Host para hacer la prueba antes de permitirle a DPM que tome el control y lo enviamos a Standby de forma manual.

Una vez el host este en modo Standby intetamos traerlo devuelta usando la opción de PowerOn.

Si el ESXi vuelve del modo Standby quiere decir que estamos listos para dejar que DPM tome el control, en mi caso solo quería enviar a Standby un equipo el cual agregue hace unos días y que solo cuenta con 8GB de RAM (si, necesita mas memoria.) y que será solo para correr vESXi. Para solo enviar este equipo a Standby dirigimos nuestro mouse a Cluster -> Manage -> Host Options, editamos las opciones para el ESXi en específico, yo decidí dejar la configuración principal en Manual y editar los Host asignando Disable, Manual y Automatic respectivamente a mis ESXi. Aquí una imagen de como quedo la configuración.

 

Instalando VMware Horizon View (Composer).

Composer es un componente de VMware Horizon View y se basa en el uso de la tecnología de Linked-clone la cual posiblemente ya se conoce desde hace un tiempo.

Pre-requisitos:

View Composer solo soporta ser instalado en una versión de Windows 64bit. Puede ser instalado en la misma maquina donde tenemos nuestro vCenter o podemos instalarlo de manera “stand-alone”.

Los requerimientos exactos de Composer se pueden encontrar en este link: http://pubs.vmware.com/view-52/index.jsp#com.vmware.view.installation.doc/GUID-AF050FEA-5382-4D4A-BB83-24A087FD644B.html#GUID-AF050FEA-5382-4D4A-BB83-24A087FD644B

Lo primero que debemos hacer es decidir si nos conviene instalar Composer en la misma maquina o stand-alone, la siguiente instalación es stand-alone porque ya tengo en mi vCenter el software de manejo de PernixData FVP y no quería cargar más la maquina con el servicio de vCenter.

Con relación a la Base de Datos para Composer, este soporta MSSQL & Oracle, la siguiente instalación es realizada con una DB de MSSQL que en mi caso es el mismo SQL Server que uso para vCloud Director y otras aplicaciones en aaNetworks. La forma implementada en Composer para conectar a la DB es mediante DSN (System DSN) el cual debemos crear en el servidor donde queremos instalar el servicio. Una vez que tenemos nuestra DB y usuarios creados en el SQL procedemos a crear el System DNS.

Una vez creado nuestro ODBC podemos lanzar la instalación de Composer.

Listo, ya está instalado. En mi ambiente de LAB ya tenía instalado un Connection Manager conectado al vCenter, me toca editar esa conexión para ahora decirle que existe un Composer.

A estas alturas solo faltaría crear una VM con Windows7/8 para designarla como “Parent VM” y luego crear un pool en donde usaremos esta VM y crear los linked-clones necesarios en nuestro ambiente de VMware Horizon View.