En este post vamos a ver cómo configurar la alta disponibilidad HA en un clúster Proxmox VE 9.0 con Ceph, con la HA configurada, cuando tengamos problemas en un nodo, las máquinas que están corriendo en ese nodo, se van a reiniciar en otro nodo disponible del clúster de forma automática.

La topología utilizada sería la siguiente:

• Para empezar a configurar HA accedemos a Centro de datos > HA, y lo primero que tenemos que ver que el quorum esté en estado OK:

• Sobre Centro de datos > HA, agregamos las máquinas virtuales que queramos proteger con HA:

• Le indicamos el ID de la máquina que queremos proteger, marcar el chek de Failback y en Estado de la solicitud le indicamos que la máquina se inicie en el host al que se migre, Agregar:

• Como podemos ver, ya tenemos la máquina protegida con HA:

• Si accedemos al resumen de la máquina, podemos ver, que el Estado de HA está en started:

• Ahora, para verificar que el HA está funcionando correctamente, vamos a simular el nodo pvelab02 se nos ha caído, y que las máquinas virtuales protegidas por HA que están corriendo en ese nodo se migran a los otros nodos del cluster:

• Como vemos, el nodo pvelab02, ya no está disponible y la máquina se ha migrado e iniciado automáticamente en otro nodo:

Saludos y espero que os sea de ayuda

En estos posts veremos cómo desplegar y configurar una infraestructura virtualizada con Proxmox VE 9.0, usando el Failover Clúster de Proxmox y la alta disponibilidad HA, vamos a usar tres nodos, pvelab01, pvelab02 y pvelab03, para el almacenamiento vamos a montar y configurar un pool local con Ceph, para entender que es y cómo funciona Ceph, digamos que es un híbrido entre el almacenamiento iSCSI y ZFS que hemos visto en los post anteriores, siendo almacenamiento local como en ZFS y compartido como en iSCSI, pero tiene la particularidad de que no tenemos que configurar la replicación como en ZFS, ya que al configurar Ceph los discos de las máquinas virtuales se replican de forma automática entre todos los almacenamientos Ceph del tipo RBD del clúster.

La topología utilizada sería la siguiente:

Estos post los vamos a dividir en las siguientes entradas:

• Creación y configuración Clúster de tres nodos en Proxmox VE 9.0
• Instalación y configuración de Ceph en Proxmox VE
• Agregar monitores a los nodos del clúster Ceph
• Crear OSDs, pool de OSD Ceph y agregar almacenamiento al clúster Ceph
• Migración en vivo de máquinas virtuales en un Cluster Proxmox con Ceph
• Configuración alta disponibilidad HA en un clúster Proxmox con Ceph

Saludos y espero que os resulte de ayuda

En este post vamos a ver como configurar la replicación de máquinas virtuales con ZFS local en cada nodo para tener alta disponibilidad (HA) en un cluster proxmox.

La topología utilizada sería la siguiente:

• Para configurar las réplicas de las máquinas virtuales, accedemos a la máquina que queremos replicar, que en este caso esta en el nodo pvelab02, y nos vamos a Replicación > Agregar:

• Le indicamos el nodo, en este caso, pvelab01, al que la queremos replicar, que se replique cada 15 minutos, la primera réplica es una copia completa, las siguientes son copias diferenciales, Crear:

• Y aquí vemos la tarea de replicación creada:

• Ahora, para el nodo pvelab03, agregamos otra tarea de replicación con las mismas características:

• Como podemos ver aquí, ya se ha realizado correctamente la replicación en cada uno de los nodos que le hemos indicado:

• Si accedemos a los nodos pvelab01 y pvelab03, podemos ver, que en sus datastores ZFS locales se han replicado los discos virtuales de la máquina:

• Una vez que ya tenemos las réplicas configuradas para cada nodo, ya podemos habilitar la alta disponibilidad HA para estas máquinas que se encuentran en almacenamiento local ZFS, para ello, accedemos a Centro de datos > HA > Agregar:

• Le indicamos el ID de la máquina que queremos proteger, marcar el chek de Failback y en Estado de la solicitud le indicamos que la máquina se inicie en el host al que se migre, Agregar:

• Como podemos ver, ya tenemos la máquina protegida con HA:

• Si accedemos al resumen de la máquina, podemos ver, que el Estado de HA está en started:

• Ahora, para verificar que el HA está funcionando correctamente, vamos a simular el nodo pvelab02 se nos ha caído, y que esta máquina virtual protegida por HA que está corriendo en ese nodo se migra a otro nodo del clúster:

• Como vemos, el nodo pvelab02, ya no está disponible y la máquina se ha migrado e iniciado automáticamente en otro nodo, concretamente en el nodo pvelab01:

• Aquí vemos que la máquina virtual, ahora está en el nodo pvelab01, y si nos vamos a su configuración de replicación, vemos que automáticamente, empieza a replicar en los otros nodos del clúster, tal y como estaba en el nodo pvelab02:

• Para terminar, hacemos una migración en vivo de la máquina, desde el nodo pvelab01 al nodo pvelab03, y una vez que termine, accedemos a su configuración de replicación, y vemos que automáticamente, empieza a replicar en los otros nodos del clúster:

Saludos y espero que os resulte de ayuda

En este post vamos a ver cómo configurar la alta disponibilidad HA en un clúster Proxmox VE 9.0, con la HA configurada, cuando tengamos problemas en un nodo, las máquinas que están corriendo en ese nodo, se van a reiniciar en otro nodo disponible del clúster de forma automática.

Recordamos la topología:

• Para empezar a configurar HA accedemos a Centro de datos > HA, y lo primero que tenemos que ver que el quorum esté en estado OK:

• Sobre Centro de datos > HA, agregamos las máquinas virtuales que queramos proteger con HA:

• Le indicamos el ID de la máquina que queremos proteger, marcar el chek de Failback y en Estado de la solicitud le indicamos que la máquina se inicie en el host al que se migre, Agregar:

• Como podemos ver, ya tenemos estas dos máquinas protegidas con HA:

• Si accedemos al resumen de las máquinas, podemos ver, que el Estado de HA está en started:

• Ahora, para verificar que el HA está funcionando correctamente, vamos a simular que el nodo pvelab03 se nos ha caído, y que las máquinas virtuales protegidas por HA que están corriendo en ese nodo se migran a los otros nodos del cluster:

• Como vemos, el nodo pvelab03, ya no está disponible y las máquinas se han migrado e iniciado automáticamente en los otros nodos:

Saludos y espero que os resulte de ayuda

En estos posts veremos cómo desplegar y configurar una infraestructura virtualizada con Proxmox VE 9.0, usando el Failover Clúster de Proxmox y la alta disponibilidad HA, vamos a usar tres nodos, pvelab01, pvelab02 y pvelab03, para el almacenamiento vamos a montar y configurar una SAN iSCSI.

La topología utilizada sería la siguiente:

Estos post los vamos a dividir en las siguientes entradas:

• Preparación Servidores Proxmox VE 9.0 y Cabina SAN iSCSI
• Creación y configuración Clúster de tres nodos en Proxmox VE 9.0
• Agregar almacenamiento iSCSI multipath al Clúster Proxmox VE 9.0
• Agregar almacenamiento iSCSI multipath al Clúster Proxmox VE 9.1.2 configuración avanzada
• Migración de máquinas virtuales online o en vivo en Clúster Proxmox VE 9.0 con SAN iSCSI
• Configuración de alta disponibilidad HA en Clúster Proxmox VE 9.0 con SAN iSCSI

Saludos.

En este post vamos a ver cómo desplegar y configurar dos firewalls OPNSense en modo clúster HA en Azure.

La topología que vamos a utilizar será esta:

• Lo primero que vamos a realizar es acceder a este link de dmauser, aquí vamos a encontrar un desarrollo para desplegar dos firewalls OPNSense sobre FreeBSD en modo cluster HA Activo-Activo:

• Se nos abrirá esta plantilla para el despliegue de OPNSense, sobre Deployment Scenarios le indicamos la suscripción, el grupo de recursos, la región y muy importante OPNSense Scenario que le indicamos Active-Active:

• Sobre Virtual Machine Settings le indicamos el nombre y tamaño de máquina, la URL para la descarga del script, la versión de OPNSense y la versión del agente de Azure:

• Para el despliegue y la configuración de la red virtual en Azure, vamos a seleccionar un espacio de direcciones en la red virtual, y le configuraremos las distintas subredes que va a utilizar el firewall y la que utilizaremos como la red local de Azure dónde se conectarán nuestras máquinas virtuales (ésta última la configuraremos a posteriori de la plantilla de despliegue):
• Red virtual: opnsenseha-vnet168.128.0/18
• Subred Externa: Untrusted-Subnet168.191.0/27
• Subred Interna: Trusted-Subnet168.191.32/27
• LAN Azure: SubnetLAN-192_168_128_0-24
• DMZ Azure: SubnetLAN-192_168_129_0-24

• Sobre Virtual Network Settings estas serían las configuraciones para nuestra infraestructura:

• Sobre Revisar y crear, nos muestra un resumen de todas las configuraciones realizadas, comenzamos a Crear todos los recursos de la plantilla OPNSense deployment:

• Como podemos ver, comienza el despliegue:

• Aquí vemos que ya ha terminado y se ha implementado correctamente, podemos ver, los distintos recursos que ha creado el despliegue de esta plantilla:

• Accedemos al grupo de recursos y vemos todos los recursos que se nos han creado, entre ellos, dos firewalls opnsense (primario y secundario), dos Load Balancer (Externo e Interno) y una IP pública:

• Ahora vamos a clicar sobre la máquina virtual opnsense-Primary:

• En la máquina virtual accedemos a Configuración de red y cómo podemos ver tenemos dos interfaces de red, una es la interface WAN de OPNSense que tiene asignada una IP privada del rango de la subred Untrusted, y la otra es la interface LAN que tiene asignada una IP privada del rango de la subred Trusted:

• Debemos de configurar las IPs privadas como estáticas, tanto la WAN cono la LAN:

• Para la máquina opnsense-Secondary hacemos lo mismo:

• Otro de los recursos que se han creado es el Load Balancer Interno:

• Sobre Configuración de IP de front-end, vemos que la IP asignada es una IP del rango de la subred Trusted:

• Sobre Grupos de back-end, vemos que tenemos asignados los dos firewall opnsense en su interface Trusted:

• Sobre Sondeos de estado, vemos que tenemos uno agregado para el protocolo TCP puerto 443:

• Sobre Reglas de equilibrio de carga, vemos que tenemos una regla configurada para equilibrar la carga entre los dos firewalls:

• Otro de los recursos que se han creado es el Load Balancer Externo:

• Sobre Configuración de IP de front-end, vemos que la IP asignada es una IP pública, que será la que nos dará la entrada y salida desde y hacia la WAN:

• Sobre Grupos de back-end, vemos que tenemos asignados los dos firewall opnsense en su interface Untrusted:

• Sobre Sondeos de estado, vemos que tenemos uno agregado para el protocolo TCP puerto 443:

• Sobre Reglas de equilibrio de carga, vemos que tenemos una regla configurada a modo de ejemplo para definir cómo se distribuye el tráfico entrante a todas las instancias del grupo de back-end, en este ejemplo sería una regla creada en el puerto 3389 para equilibrar la carga del tráfico RDP:

• Sobre Regla NAT de entrada, tenemos dos reglas configuradas para el acceso a los firewalls opnsense a través de su IP pública, al firewall primario se accede por el puerto 50443 y al firewall secundario por el puerto 50444, que como vemos está mapeado al puerto 443 de cada firewall:

• Sobre Reglas de salida, tenemos configurada una regla para la salida a la WAN de nuestra infraestructura, con esta regla todas las máquinas ubicadas detrás de los firewalls van a salir a Internet con la IP pública de nuestro load balancer externo:

• Para acceder a los firewalls accedemos a través de su IP pública, https://PublicIP:50443 para el primario y https://publicip:50444 para el secundario, las credenciales por defecto son root/opnsense:

• Lo primero que vamos a configurar en los firewall opnsense, va a ser la configuración de HA.
• Nos vamos primero al firewall primario y sobre System > High Availability > Settings configuramos el peer del firewall secundario:

• Ahora accedemos al firewall secundario y sobre System > High Availability > Settings configuramos el peer del firewall primario:

• Accedemos de nuevo al firewall primario y sobre System > High Availability > Status sincronizamos y reconfiguramos todo, una vez configurado este cambio, todo lo que hagamos y configuremos en el firewall opnsense primario se va a replicar en el firewall opnsense secundario:

• Veamos un ejemplo, hemos configurado los servidores NTP en el firewall primario:

• Sincronizamos todos los servicios:

• Una vez que se ha sincronizado todo, si accedemos al firewall secundario, vemos que la configuración de los servidores NTP se ha replicado correctamente:

• Como comentamos anteriormente, vamos a configurar la red local de Azure dónde se conectarán nuestras máquinas virtuales, LAN Azure: SubnetLAN-192_168_128_0-24 y DMZ Azure: SubnetDMZ-192_168_129_0-24:

• Lo siguiente que vamos a desplegar y configurar es una tabla de rutas UDR (User Definition Routes) en Azure.
• Accedemos al Marketplace, buscamos Route table y damos a crear:

• Sobre Básico le indicamos el grupo de recursos, la región, le damos un nombre y le indicamos que propague las rutas de puerta de enlace:

• Sobre Etiquetas podemos configurar las que nos interesen:

• Sobre Revisar y crear nos muestra un resumen sobre todo lo que le hemos configurado a la tabla de rutas:

• Aquí vemos que se ha implementado correctamente:

• Accedemos al recurso y sobre subredes vamos a asociar las subredes LAN y DMZ que configuramos anteriormente, estas subredes son dónde vamos a ubicar las máquinas virtuales de nuestra infraestructura en Azure:

• Como podemos ver, ya las tenemos asociadas:

• Ahora vamos a configurar las rutas, para ello, accedemos a Rutas > Agregar:

• La primera ruta que vamos a agregar, será la ruta por defecto:

• La siguiente ruta será para el acceso a la subred LAN dónde vamos a ubicar nuestras máquinas virtuales:

• La siguiente ruta será para el acceso a la subred DMZ dónde vamos a ubicar nuestras máquinas virtuales:

• Aquí vemos las rutas agregadas:

• Sobre Información general en la tabla de rutas, podemos ver, todo lo que se ha configurado:

• Una vez configurada la tabla de rutas, accedemos a nuestro OPNSense HA en Azure, y nos vamos a crear estas dos rutas estáticas, la primera es la ruta por defecto, para que todo lo que no se encuentre en la tabla de enrutamiento del OPNSense lo envíe por la interface WAN al gateway de la subred Untrusted, y la segunda ruta son para servicios internos de Azure, para que lo envíe por la interface LAN al gateway de la subred Trusted:

• Para todas las demás configuraciones de opnsense, podemos seguir los enlaces a estos post creados hace algún tiempo en el blog.

Saludos y espero que os sea de ayuda

En este post vamos a ver como configurar las interfaces virtuales para administración en un cluster HA con dispositivos Fortigate, en un post anterior vimos como configurar interfaces dedicadas de management utilizando un puerto físico del dispositivo, en muchas ocasiones, podemos encontrarnos con dispositivos Fortigates con pocas interfaces físicas, y si queremos un puerto dedicado para administración, entonces lo mejor es configurar estas interfaces virtuales, utilizando un puerto físico que ya tenemos en uso.

• Lo primero que tenemos que hacer es acceder a System > HA > Fortigate Primario > Editar y verificar que Management Interface Reservation está deshabilitado en nuestro cluster:

• Para configurar las interfaces virtuales debemos de acceder por consola:

• Ejecutamos el comando system config interface y editamos el puerto 10 con edit port10:

• Le hacemos un get y cómo podemos ver tenemos la opción de configurar el management-ip, esta IP virtual no se va a sincronizar entre los dispositivos del cluster:

• Ahora con el comando set management-ip 192.168.14.225 255.255.255.0 le vamos a asignar al dispositivo con el rol primario del cluster, una dirección IP virtual que utilizaremos para la gestión y administración del dispositivo:

• Si le hacemos un get podemos ver que ya tiene la IP virtual configurada:

• Con end salimos y guardamos los cambios:

• Ahora ya podemos acceder a través de la IP de management virtual sobre el Fortigate01:

• Ahora vamos a configurar la interface de management virtual del Fortigate que tiene el rol de secundario, para ello nos abrimos una consola CLI y ejecutamos el comando execute ha manage 0 admin para acceder al dispositivo con el rol de secundario:

• Ejecutamos el comando system config interface y editamos el puerto 10 con edit port10:

• Le hacemos un get y cómo podemos ver tenemos la opción de configurar el management-ip, esta IP virtual no se va a sincronizar entre los dispositivos del cluster:

• Ahora con el comando set management-ip 192.168.14.226 255.255.255.0 le vamos a asignar al dispositivo con el rol secundario del cluster, una dirección IP virtual que utilizaremos para la gestión y administración del dispositivo:

• Si le hacemos un get podemos ver que ya tiene la IP virtual configurada:

• Con end salimos y guardamos los cambios:

• Ahora ya podemos acceder a través de la IP de management virtual sobre el Fortigate02:

Saludos y espero que os sea de ayuda

En este post vamos a ver como configurar dos Firewall Fortigate en HA (Alta Disponibilidad) en modo Activo-Activo:

• Vamos a utilizar dos Interfaces de cada dispositivo para HA para vincularlos y sincronizarlos.
• En HA uno de los Fortigate estará como primario y éste sincronizará su información con el otro Fortigate que será el secundario.
• El link para el HA entre los Fortigate, que en este caso usaremos dos (HA1 y HA2) se llama Heartbeat y se utiliza para la sincronización y detección entre los equipos.
• Tenemos dos modos de configurar HA: Activo-Pasivo y Activo-Activo.

En este segundo post vamos a ver el modo Activo-Activo, en este modo todos los dispositivos procesan tráfico, pero seguimos teniendo un dispositivo que actúa como primario y otro como secundario, el dispositivo primario se encarga de distribuir todas las sesiones en el cluster, pero si el primario cae, entonces el secundario pasaría a tener el rol de primario.

Vamos a ver que necesitamos para crear y configurar un cluster HA en Firewall FortiGates:

• Dos Fortigates del mismo modelo
• Misma versión de FortiOS en ambos equipos
• Mismas licencias
• Un link entre los equipos que componen el cluster HA, en este caso vamos a utilizar dos
• Las mismas interfaces deben de estar conectadas al mismo dominio de broadcast, es decir, los puertos usados deben de ser los mismos en ambos dispositivos y conectados en el mismo segmento de red.

• Para empezar con la configuración de nuestro cluster HA Activo-Activo, vamos a realizar las configuraciones básicas sobre uno de nuestros Fortigate, que actuará como primario, el otro Fortigate lo dejamos con las configuraciones de fábrica, en este link podemos ver la configuración inicial y puesta en marcha.
• Aquí vemos como tenemos configurado el hostname y las interfaces de red del primer Fortigate (LAN y WAN):

• Del segundo Fortigate, está tal y como viene de fábrica:

• Lo primero que vamos a realizar es configurar sobre el Fortigate01 el nombre de las interfaces de red que van a participar en el cluster HA, se llaman interfaces de Heartbeat y se utilizan para la sincronización y detección entre los equipos, utilizaremos los puertos 4 y 5:

• Ahora sobre System > HA > seleccionamos el modo que nos interese, en este caso Active-Active:

• Sobre High Availability le indicamos el modo y la prioridad, sobre Cluster Settings le damos un nombre al cluster, le asignamos un password, habilitamos Session pickup para que automáticamente se pasen las sesiones de un Fortigate a otro y así los clientes no tengan que volver a reconectarse, el Monitor interfaces lo vamos a habilitar más adelante y explicaremos de que se trata y sobre Heartbeat Interfaces vamos a configurar las interfaces que van a participar en el cluster HA, sobre Heartbeat Interface Priority vamos a configurar las prioridades de las interfaces de Heartbeat, que en este caso el port4 va a tener prioridad sobre el port5:

• Ahora podemos ver que en System > HA nos muestra los puertos 4 y 5 con un corazón indicando que son los puertos de Heartbeat para el cluster:

• Sobre el Fortigate01 ya tenemos las configuraciones de HA realizadas, ahora debemos de configurar el Fortigate02, y como el nombre del host no se sincroniza, es lo primero que tenemos que configurar, en System > Settings:

• Ahora sobre System > HA realizamos las mismas configuraciones que hemos hecho sobre el Fortigate01, excepto que en la prioridad del dispositivo la vamos a bajar a 100, clic sobre OK:

• Como podemos ver, perdemos conexión con nuestro Fortigate02, ya que la dirección IP que tenía, ha desaparecido al unirlo al cluster, ahora estos dos dispositivos es como si fuesen uno solo y los dos van a tener las mismas configuraciones:

• Sobre el Fortigate01 accedemos a System > HA y podemos ver que ya tenemos el segundo dispositivo unido al cluster, aunque todavía está sincronizando, esto nos lo muestra muy claro el checksum, que como podemos observar, son números diferentes, ya que al no estar sincronizados todavía cada dispositivo tiene una configuración:

• Pasados unos minutos, ya podemos ver que los dos dispositivos están sincronizados, el checksum es el mismo, como también podemos ver, el Fortigate01 está actuando como primario y el Fortigate02 como secundario:

• Para ver de un solo vistazo el estado de nuestro Cluster HA, vamos a habilitar el siguiente panel, nos vamos a Dashboard y añadir:

• Añadimos el Widget HA Status:

• Como podemos ver, de un solo vistazo podemos ver el estado del cluster HA:

• Ahora vamos a realizar una prueba, apagando el Fortigate01, para ver si el Fortigate02 coge el control como primario, y como podemos ver, todo funciona correctamente sin pérdida de servicio y el que estaba antes como secundario pasa a ser primario:

• Si volvemos a iniciar el Fortigate01, podemos ver que ahora tiene el rol de secundario, ya que el Uptime del Fortigate02 es mayor que el del Fortigate01:

• Si queremos que el Fortigate01 vuelva a coger el rol de primario, debemos de ejecutar este comando diagnose sys ha reset-uptime, lo que hace este comando es resetear el Uptime del dispositivo, en este caso del Fortigate02:

• Como podemos ver, el Fortigate01 vuelve a tener el rol de primario:

• Ahora, vamos a configurar el Monitor interfaces en el cluster HA, esto significa, que la interface que vamos a monitorizar, si pierde conexión con el Firewall primario, automáticamente éste Firewall pasará a ser el secundario, tomando el otro Firewall el control, por lo tanto, vamos a configurar como Monitor interface, nuestra LAN:

• Para terminar, vamos a ver como configurar las interfaces de management de cada Fortigate, ya que siempre que accedemos lo estamos haciendo sobre el dispositivo que tiene el rol de primario, estas interfaces de management nos van a permitir acceder a cada dispositivo por separado, para ello, accedemos a System > HA seleccionamos el Fortigate con el rol de primario y Edit:

• Habilitamos Management Interface Reservation, le indicamos el puerto, el gateway y la subred, al habilitar esta opción le estamos indicando al cluster que vamso a usar el puerto 9 de cada Fortigate para management y por lo tanto las configuraciones en este puerto no se van a sincronizar entre los dispositivos pertenecientes al cluster:

• Una vez habilitado el puerto de management en el cluster (puerto9), vamos a configurar este puerto sobre el Fortigate con el rol de primario, para ello, accedemos a Network > Interfaces > port9 > Edit:

• Le indicamos un Alias, le asignamos el direccionamiento IP correspondiente, habilitamos los accesos y OK:

• Como podemos ver ya tenemos configurado el puerto de management sobre el Fortigate primario:

• Ahora ya podemos acceder a través de la IP de management sobre el Fortigate01:

• Ahora vamos a configurar la interface de management del Fortigate que tiene el rol de secundario, para ello desde la consola web nos abrimos una consola CLI:

• Ejecutamos el comando execute ha manage ? y cómo podemos ver nos indica que el dispositivo 0 es el secundario:

• Por lo tanto, para acceder al Fortigate secundario debemos de ejecutar el comando execute ha manage 0 admin el admin es el usuario que tenemos dado de alta en nuestro Fortigate secundario con permisos administrativos, y cómo podemos ver ya estamos dentro del Fortigate secundario (FORTIGATE02):

• Ahora ya le podemos asignar el direccionamiento IP al puerto que configuramos para management (puerto9), con el comando config system interface accedemos al modo de configuración de interface, con edit port9 accedemos a la configuración del puerto 9, con set ip 192.168.99.221 255.255.255.0 le asignamos el direccionamiento IP, con set allowaccess ping https http ssh fgfm le habilitamos los accesos y con end salimos de las configuraciones:

• Con el comando show system interface podemos ver las configuraciones realizadas:

• Ahora ya podemos acceder a través de la IP de management sobre el Fortigate02, y cómo podemos ver ya tenemos el puerto de management configurado (puerto9):

Saludos y espero que os resulte de ayuda

En este post vamos a ver como configurar dos Firewall Fortigate en HA (Alta Disponibilidad) en modo Activo-Pasivo:

• Vamos a utilizar dos Interfaces de cada dispositivo para HA para vincularlos y sincronizarlos.
• En HA uno de los Fortigate estará como primario y éste sincronizará su información con el otro Fortigate que será el secundario.
• El link para el HA entre los Fortigate, que en este caso usaremos dos (HA1 y HA2) se llama Heartbeat y se utiliza para la sincronización y detección entre los equipos.
• Tenemos dos modos de configurar HA: Activo-Pasivo y Activo-Activo.

En este primer post vamos a ver el modo Activo-Pasivo, en este modo solo el dispositivo primario procesa el tráfico, el otro dispositivo está en modo de espera y sólo entrará a funcionar en caso de caída del primario, toda la configuración realizada en el dispositivo primario se sincronizará con el dispositivo secundario.

Vamos a ver que necesitamos para crear y configurar un cluster HA en Firewall FortiGates:

• Dos Fortigates del mismo modelo
• Misma versión de FortiOS en ambos equipos
• Mismas licencias
• Un link entre los equipos que componen el cluster HA, en este caso vamos a utilizar dos
• Las mismas interfaces deben de estar conectadas al mismo dominio de broadcast, es decir, los puertos usados deben de ser los mismos en ambos dispositivos y conectados en el mismo segmento de red.

• Para empezar con la configuración de nuestro cluster HA Activo-Pasivo, vamos a realizar las configuraciones básicas sobre uno de nuestros Fortigate, que actuará como primario, el otro Fortigate lo dejamos con las configuraciones de fábrica, en este link podemos ver la configuración inicial y puesta en marcha.
• Aquí vemos como tenemos configurado el hostname y las interfaces de red del primer Fortigate (LAN y WAN):

• Del segundo Fortigate, está tal y como viene de fábrica:

• Lo primero que vamos a realizar es configurar sobre el Fortigate01 el nombre de las interfaces de red que van a participar en el cluster HA, se llaman interfaces de Heartbeat y se utilizan para la sincronización y detección entre los equipos, utilizaremos los puertos 4 y 5:

• Ahora sobre System > HA > seleccionamos el modo que nos interese, en este caso Active-Passive:

• Sobre High Availability le indicamos el modo y la prioridad, sobre Cluster Settings le damos un nombre al cluster, le asignamos un password, habilitamos Session pickup para que automáticamente se pasen las sesiones de un Fortigate a otro y así los clientes no tengan que volver a reconectarse, el Monitor interfaces lo vamos a habilitar más adelante y explicaremos de que se trata y sobre Heartbeat Interfaces vamos a configurar las interfaces que van a participar en el cluster HA, sobre Heartbeat Interface Priority vamos a configurar las prioridades de las interfaces de Heartbeat, que en este caso el port4 va a tener prioridad sobre el port5:

• Ahora podemos ver que en System > HA nos muestra los puertos 4 y 5 con un corazón indicando que son los puertos de Heartbeat para el cluster:

• Sobre el Fortigate01 ya tenemos las configuraciones de HA realizadas, ahora debemos de configurar el Fortigate02, y como el nombre del host no se sincroniza, es lo primero que tenemos que configurar, en System > Settings:

• Ahora sobre System > HA realizamos las mismas configuraciones que hemos hecho sobre el Fortigate01, excepto que en la prioridad del dispositivo la vamos a bajar a 100, clic sobre OK:

• Como podemos ver perdemos conexión con nuestro Fortigate02, ya que la dirección IP que tenía, ha desaparecido al unirlo al cluster, ahora estos dos dispositivos es como si fuesen uno solo y los dos van a tener las mismas configuraciones:

• Sobre el Fortigate01 accedemos a System > HA y podemos ver que ya tenemos el segundo dispositivo unido al cluster, aunque todavía está sincronizando, esto nos lo muestra muy claro el checksum, que como podemos observar son números diferentes, ya que al no estar sincronizados todavía cada dispositivo tiene una configuración:

• Pasados unos minutos, ya podemos ver que los dos dispositivos están sincronizados, el checksum es el mismo, como también podemos ver, el Fortigate01 está actuando como primario y el Fortigate02 como secundario:

• Para ver de un solo vistazo el estado de nuestro Cluster HA, vamos a habilitar el siguiente panel, nos vamos a Dashboard y añadir:

• Añadimos el Widget HA Status:

• Como podemos ver, de un solo vistazo podemos ver el estado del cluster HA:

• Ahora vamos a realizar una prueba, apagando el Fortigate01, para ver si el Fortigate02 coge el control como primario, y como podemos ver, todo funciona correctamente sin pérdida de servicio y el que estaba antes como secundario pasa a ser primario:

• Si volvemos a iniciar el Fortigate01, podemos ver que ahora tiene el rol de secundario, ya que el Uptime del Fortigate02 es mayor que el del Fortigate01:

• Si queremos que el Fortigate01 vuelva a coger el rol de primario, debemos de ejecutar este comando diagnose sys ha reset-uptime, lo que hace este comando es resetear el Uptime del dispositivo, en este caso del Fortigate02:

• Como podemos ver, el Fortigate01 vuelve a tener el rol de primario:

• Para terminar, vamos a configurar el Monitor interfaces en el cluster HA, esto significa, que la interface que vamos a monitorizar, si pierde conexión con el Firewall primario, automáticamente éste Firewall pasará a ser el secundario, tomando el otro Firewall el control, por lo tanto, vamos a configurar como Monitor interface, nuestra LAN:

Saludos y espero que os sea de ayuda

• En este post vamos a ver cómo se crea, configura y gestiona un clúster HA (High Availability) y DRS (Distributed Resource Scheduler) en VMware vSphere 6.7

HA – High Availability – Alta Disponibilidad

• Necesitamos almacenamiento compartido SAN o NAS, que ya lo hemos configurado en un post anterior.
• Es necesario vCenter.
• Las CPUs de los hosts miembros del clúster han de ser del mismo fabricante.
• Durante las tareas de mantenimiento de los hosts, debemos desactivar host monitoring.
• No debemos deshabilitar Admission control.
• Para quitar un host del clúster tenemos que ponerlo en modo mantenimiento.
• Reduce el tiempo de parada en tareas de mantenimiento.
• Recuperación automática en caso de fallo, el servicio sufre una mínima parada.
• Redundar todos los componentes para aumentar la disponibilidad.
• vSphere HA se compone de:
• 1) FDM (Fault Domain Manager)
• 2) HOSTD
• 3) VCENTER
• Estos tres componentes los explica perfectamente mi amigo, Leandro Ariel Leonhardt en el libro VMware por vExperts que os podéis descargar libremente en el link.

• Lo primero que haremos será crear el clúster, para ello, botón derecho sobre el Datacenter y Nuevo clúster:

• Le indicamos el nombre y aceptamos, de momento no habilitamos nada:

• Aquí vemos que ya lo tenemos creado:

• Ahora vamos a agregar los hosts ESXi al clúster, para ello, botón derecho sobre el clúster Agregar hosts, para agregar los host ESXi al clúster las máquinas virtuales deben estar apagadas o que los ESXi no tengan máquinas virtuales, ya que, al pasarlos al clúster, los hosts entrarán en modo mantenimiento:

• Se nos abre este asistente, para agregar los hosts ESXi al clúster:

• Aquí podemos ver los hosts ESXi agregados al clúster, y como comentaba anteriormente, los añade en modo mantenimiento:

• Sacamos los hosts ESXi del modo mantenimiento:

• Aquí tenemos los hosts ESXi operativos en el clúster con sus máquinas virtuales:

• Ahora habilitamos y configuramos el clúster para HA, para ello, nos situamos sobre el Clúster > Configurar > Servicios > vSphere Availability > EDITAR:

• Habilitamos vSphere HA:

• Sobre la primera opción Errores y respuestas, habilitamos el Host Monitoring o Supervisión de host, aquí tenemos varias opciones a configurar:

• Vamos a ver Respuesta de error de host, aquí se configura que operación vamos a realizar con las máquinas virtuales cuando uno de nuestros host ESXi falla, en este caso, las máquinas virtuales se van a reiniciar en otro host disponible del clúster, la prioridad del reinicio la configuramos como Mediano, más adelante veremos que podemos asignarle prioridades de reinicio por máquina virtual:

• Respuesta para el aislamiento del host, con aislamiento del host se refiere, a que nuestro host ESXi ha perdido la conexión con la red de Management, pero las máquinas virtuales siguen funcionando ya que tienen acceso a las demás redes y a los datastores, por lo tanto, lo dejamos deshabilitado:

• Almacén de datos con PDL, si nos falla la conexión entre un host ESXI y un datastore, habilitamos la opción Apagar y reiniciar las máquinas virtuales, así nuestras máquinas virtuales se van a iniciar en otros hosts ESXi que tengan conexión con el datastore:

• Almacén de datos con APD, si nos falla la conexión entre un host ESXI y un datastore, habilitamos la opción Apague y reinicie las máquinas virtuales (directiva de reinicio conservadora), así nuestras máquinas virtuales se van a iniciar en otros hosts ESXi que tengan conexión con el datastore:

• Supervisión de máquinas virtuales, si vSphere HA no recibe heartbeat de la máquina virtual a través de las VMware Tools, esto será indicativo que esta máquina no estará dando servicios, seguramente algún cuelgue por la circunstancia que sea, si habilitamos Solo supervisión de máquinas virtuales, entonces nuestra máquina virtual se va a reiniciar automáticamente, le configuramos la sensibilidad de supervisión como Bajo:

• Sobre la segunda opción Control de admisión, es una política que utiliza vSphere HA para garantizar la conmutación por error del clúster, y que siempre tenga reservado los recursos necesarios en caso de fallo, en este caso, en las políticas de control le decimos que permitimos la caída de un host, y como tenemos dos hosts en nuestro clúster le vamos a reservar el 15% de CPU y Memoria:

• Sobre la tercera opción Almacenes de datos de latidos, vSphere HA utiliza almacenes de datos para supervisar hosts y máquinas virtuales cuando no se puede conectar la red de HA, en este caso, seleccionamos el check Seleccionar almacenes de datos automáticamente a los que pueda accederse desde los hosts:

• Sobre la cuarta opción Opciones avanzadas, podemos configurar opciones que afectan al comportamiento del clúster vSphere HA, en este caso no configuramos nada, pulsamos sobre ACEPTAR para validar todas las configuraciones realizadas:

• El estado de los hosts para vSphere HA nos quedaría de la siguiente manera, siempre uno de los hosts será el maestro y los restantes tendrán el rol de esclavo, si el maestro falla, uno de los esclavos cogerá el rol de maestro:

• Ahora si accedemos al clúster en Supervisar > vSphere HA > Resumen, podemos ver de un solo vistazo el estado general de nuestro clúster vSphere HA:

• Si accedemos al clúster en Supervisar > vSphere HA > Latido, podemos ver los datastores que vSphere HA utiliza para supervisar los hosts y las máquinas virtuales:

• Si accedemos al clúster en Supervisar > vSphere HA > Problemas de configuración, podemos ver si tenemos alguna configuración errónea en vSphere HA:

• Si accedemos al clúster en Supervisar > vSphere HA > Almacenes de datos en APD o PDL, de un solo vistazo podremos ver el error de conexión entre cualquiera de los hosts del clúster y los datastores:

• Una vez que habilitemos y configuremos DRS veremos la parte de Proactive HA, pero es requisito indispensable tener habilitado el DRS en nuestro clúster:

DRS – Distributed Resource Scheduler

• Ahora veremos cómo se configura y gestiona un clúster vSphere DRS
• Hace un balanceo automático de las máquinas virtuales, es decir, balancea las cargas de trabajo para evitar que cualquiera de los hosts ESXi del clúster, esté saturado a nivel de CPU, RAM y RED.
• Utiliza vMotion para reubicar las máquinas virtuales entre los distintos hosts del clúster, por lo que tenemos que crear una red de vMotion (esto lo vimos en el post dedicado a redes virtuales).
• Necesita almacenamiento compartido SAN o NAS.
• Las CPUs de los hosts miembros del clúster han de ser del mismo fabricante.
• Es necesario vCenter

• Para habilitar y configurar el clúster para DRS, nos situamos sobre el Clúster > Configurar > Servicios > vSphere DRS > EDITAR:

• Habilitamos vSphere DRS:

• Sobre la opción de Automatización, vamos a configurar los siguientes parámetros:
• Nivel de automatización, aquí tenemos tres niveles:
• 1) Manual, DRS recomendará migrar las máquinas virtuales para equilibrar la carga entre nuestros hosts ESXi, pero nunca va a migrar las máquinas de manera automatizada, simplemente nos mostrará las recomendaciones y seremos nosotros como administradores del entorno de VMware vSphere quién migremos las máquinas.
• 2) Parcialmente automatizado, es exactamente igual que el Manual dónde el DRS recomendará migrar las máquinas virtuales para equilibrar la carga entre nuestros hosts ESXi, pero nunca va a migrar las máquinas de manera automatizada, en lo que si se diferencia es que si iniciamos una máquina virtual que se encuentra apagada o desplegamos una nueva máquina, DRS la va a ubicar en el host ESXi con menos carga.
• 3) Totalmente automatizado, DRS migrará las máquinas virtuales de forma automatizada sin intervención del administrador de la infraestructura de VMware vSphere, para así equilibrar la carga entre nuestros hosts ESXi, también cuando iniciemos una máquina que se encontraba apagada o desplegamos una nueva máquina, DRS la ubicará en el host con menos carga de trabajo, nosotros vamos a elegir esta opción.

• Umbral de migración, aquí tenemos los distintos niveles de migraciones, se dividen en 5 niveles, del más conservador (nivel 1) al más agresivo (nivel 5), nosotros vamos a elegir el nivel 3, en este nivel vSphere DRS va a aplicar las recomendaciones que suponen una mejora en el equilibrio de la carga de nuestro clúster:

• Sobre Opciones adicionales podemos configurar la Distribución de las máquinas virtuales, Métricas de memoria, Sobreasignación de CPU, todo ello según queramos nosotros equilibrar las cargas de trabajo de nuestro clúster, en este caso lo vamos a dejar todo como viene por defecto:

• La opción Administración de energía nos va a permitir habilitar DPM (Distributed Power Management), la función de DPM una vez habilitada va a permitir apagar host ESXi de forma automatizada, estos hosts los apagará cuando tienen poca carga de trabajo y las máquinas virtuales que están corriendo sobre él pueden ser migradas a otros hosts del clúster y sin llegar a saturarlos, DPM utiliza Wake on LAN, IPMI, ILO, iDRAC, iRMC, etc…, en nuestro caso no lo habilitamos:

• Sobre Opciones avanzadas, podemos configurar opciones que afectan al comportamiento del clúster vSphere DRS, en este caso no configuramos nada, pulsamos sobre ACEPTAR para validar todas las configuraciones realizadas:

• Aquí podemos ver que ya tenemos vSphere DRS activado y configurado:

• Ahora vamos a crear reglas de afinidad y antiafinidad, según nos interese agrupar a nuestras máquinas virtuales, nosotros nos crearemos dos servicios llamados Services01 y Services02.
• Services01: DC01, Mail01, MX01 Siempre permanecerán juntas (mismo host)
• Services02: DC02, Mail02, MX02 Siempre permanecerán juntas (mismo host)
• DC01 y DC02: permanecerán separadas (diferentes hosts)
• MAIL01 y MAIL02: permanecerán separadas (diferentes hosts)
• MX01 y MX02: permanecerán separadas (diferentes hosts)
• Para ello, nos vamos al Clúster > Configurar > Configuración > Reglas de host/máquina virtual > Agregar:

• Configuramos el Services01, donde mantenemos juntas a las máquinas virtuales para este servicio:

• Aquí tenemos la regla configurada:

• Configuramos el Services02, donde mantenemos juntas a las máquinas virtuales para este servicio:

• Aquí tenemos la regla configurada:

• Configuramos los controladores de dominio para que permanezcan separados:

• Aquí tenemos la regla configurada:

• Configuramos los servidores de correo para que permanezcan separados:

• Aquí tenemos la regla configurada:

• Configuramos los intercambiadores de correo para que permanezcan separados:

• Aquí tenemos la regla configurada:

• Para ver que todas estas reglas están funcionando correctamente, arrancamos todas nuestras máquinas y vemos como automáticamente se ubican según las reglas que hemos definido en el clúster:

• También podemos crear grupos de hosts ESXi o grupos de máquinas virtuales, estos grupos los podemos usar para crear reglas de afinidad y antiafinidad, para ello, nos vamos al Clúster > Configurar > Configuración > Grupos de host/máquina virtual > Agregar:

• Nos vamos a crear tres grupos de máquinas virtuales, uno para los DOMAIN CONTROLLERS:

• Otro para los MAILS:

• Y otro para los MXS:

• Aquí tenemos los tres grupos de máquinas virtuales creados:

• Ahora vamos a crear un grupo de hosts ESXi:

• Aquí tenemos el grupo de hosts ESXi creado:

• Estos grupos que hemos creado, los podemos utilizar para crear reglas de afinidad y antiafinidad en nuestro clúster, aquí podemos ya configurar lo que nos vaya interesando en nuestra infraestructura:

• Otra opción interesante es la de Reemplazos de máquina virtual, esta opción nos va a permitir anular las configuraciones del clúster a nivel de HA y DRS, y personalizar la configuración a nivel de máquina virtual, según nos interese que haga una cosa u otra:

• Por ejemplo, vamos a seleccionar la máquina DC01:

• Y le configuramos, que la prioridad del reinicio si HA entra en acción sea la más alta:

• Como podemos ver aquí tenemos el reemplazo de configuración de clúster creado:

• Para monitorizar vSphere DRS, nos vamos al Clúster > Supervisar > vSphere DRS:

• Opción Recomendaciones, aquí vamos a ver las recomendaciones de vSphere DRS cuando nuestro clúster está en modo Manual o Parcialmente automatizado:

• Opción Errores, aquí veremos los errores producidos en vSphere DRS, porque ha fallado, elementos afectados, etc…

• Opción Historial, aquí nos encontraremos con las operaciones realizadas por vSphere DRS:

• Opción Uso de CPU, nos muestra el uso de la CPU en tiempo real, en cada uno de nuestros hosts ESXi del clúster:

• Opción Utilización de memoria, nos muestra el uso de la memoria en tiempo real, en cada uno de nuestros hosts ESXi del clúster:

• Opción Utilización de red, nos muestra el uso de la red en tiempo real, en cada uno de nuestros hosts ESXi del clúster:

PROACTIVE HA

• Una vez que hemos habilitado y configurado vSphere DRS, ya podemos habilitar y configurar Proactive HA, que nos va a permitir detectar posibles fallos en el hardware de los hosts ESXi (fuentes de alimentación, memoria, red, almacenamiento y ventiladores), y migrar las máquinas virtuales a otros hosts del clúster antes de que se produzca un fallo en el hardware, evitando así una pérdida del servicio.
• Para habilitar y configurar PROACTIVE HA, nos situamos sobre el Clúster > Configurar > Servicios > vSphere Availability > Proactive HA > EDITAR:

• Habilitamos Proactive HA:

• Si nos situamos sobre Errores y respuestas, podemos configurar la forma en que Proactive HA responde cuando un proveedor notifica la degradación de su estado a vCenter, lo que indica un error parcial en ese host. En el caso de un error parcial, vCenter Server puede migrar de forma proactiva las máquinas virtuales en ejecución del host a un host con un mejor estado, aquí tenemos estas dos opciones:
• 1) Nivel de automatización, aquí podemos configurar:
• Manual, DRS va a sugerir recomendaciones para las máquinas virtuales y los hosts:

• Automatizado, las máquinas virtuales se migrarán a hosts en buen estado y los hosts degradados se pondrán en cuarentena o en modo de mantenimiento según el nivel de automatización configurado de Proactive HA:

• 2) Corrección, aquí podemos configurar:
• Modo mixto, equilibra el rendimiento y la disponibilidad; para ello, evita usar los hosts parcialmente degradados siempre que el rendimiento de las máquinas virtuales no se vea afectado:

• Modo de cuarentena, equilibra el rendimiento y la disponibilidad; para ello, evita usar los hosts parcialmente degradados siempre que el rendimiento de las máquinas virtuales no se vea afectado:

• Modo de mantenimiento, se asegura de que las máquinas virtuales no se ejecuten en hosts con errores parciales:

• En nuestro caso lo vamos a dejar el Nivel de automatización Manual y Correción en Modo de cuarentena:

• En Proveedores, podemos añadir fallos específicos de los proveedores del hardware:

Saludos y espero que os resulte de ayuda