En este post vamos a ver como agregar un Clúster de Proxmox VE a nuestra infraestructura de backup con Veeam Backup & Replication versión 13.

• Lo primero que vamos a realizar será irnos hasta Inventory > Virtual Infraestructure > Proxmox VE > Add Server:

• Le indicamos el nombre DNS o la dirección IP del primer nodo del Cluster Proxmox VE, con una descripción:

• Introducimos las credenciales con permisos administrativos sobre el Cluster de Proxmox VE:

• Le indicamos que es un servidor de confianza:

• En caso de que la máquina virtual original no soporte snapshots, le indicamos que utilice el mayor almacenamiento disponible a nivel de archivos, Apply:

• Como podemos ver se ha agregado correctamente, Next:

• Nos muestra un resumen y finalizamos:

• Aquí nos indica que Veeam Backup para Proxmox VE, requiere al menos un worker (virtual machine) que entregue los datos respaldados desde y hacia los repositorios de respaldo, y que para un mejor rendimiento, se recomienda desplegar un Worker en cada nodo de Proxmox VE, le indicamos que Sí:

• Sobre Virtual Machine, le indicamos el nombre de la máquina, le indicamos el datastore, una descripción y los trabajos máximos concurrentes, Next:

• Sobre Network, añadimos el direccionamiento IP para la máquina virtual y los DNS:

• Sobre Summary, nos muestra un resumen de todo lo configurado, le indicamos que haga un testeo del worker y finalizamos:

• Aquí vemos que comienza el testeo del worker, tal y como le hemos indicado:

• Vemos como el worker, está desplegado sobre nuestro nodo de Proxmox VE:

• Una vez finalizado el testeo del worker, vemos que ya tenemos el primer nodo de nuestro clúster Proxmox VE añadido:

• Para los otros dos nodos, haremos lo mismo, y como podemos ver, ya tenemos añadidos los tres nodos de nuestro clúster de Proxmox VE:

• Si accedemos a Backup Infrastructure > Backup Proxies, podemos ver los tres workers desplegados, uno por cada nodo:

• Aquí los tenemos desplegados cada uno en su nodo:

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 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 este post vamos a ver cómo migrar máquinas virtuales de forma online o en vivo en un clúster Proxmox VE 9.0 con Ceph, sin pérdida de servicios de estas máquinas.

La topología utilizada sería la siguiente:

• Vamos a migrar una máquina que está en el nodo 2 de nuestro cluster, pvelab02, al nodo 1, pvelab01, como podemos ver le tenemos un ping tirado, para verificar que no perdemos servicio, accedemos a la máquina y damos a Migrar:

• Como podemos ver, está en línea en el nodo pvelab02 y la vamos a migrar a pvelab01:

• Comienza la migración en vivo de la máquina, y vemos que se realiza correctamente:

• Ya la tenemos corriendo sobre el nodo pvelab01 y como nos indica el ping, no hemos perdido servicio en ningún momento:

Saludos y espero que os resulte de ayuda

En este post veremos cómo crear OSDs (Object Storage Device), pool de OSD y agregar almacenamiento al clúster Ceph, los OSDs son los discos físicos de cada nodo que se van a presentar al pool de OSD Ceph y poder así crear nuestros datastores para el clúster Ceph.

La topología utilizada sería la siguiente:

• Empezamos a crear el OSD para el nodo pvelab01 > Ceph > OSD > Crear OSD:

• Seleccionamos el disco y Crear:

• Una vez creado, damos a Recargar y vemos que ya nos muestra el OSD para el nodo pvelab01:

• Ahora creamos el OSD para el nodo pvelab02:

• Ahora creamos el OSD para el nodo pvelab03:

• Una vez creados los OSDs en cada uno de nuestros nodos, vamos a crear el pool de OSD Ceph y agregarlo o presentarlo como almacenamiento (datastore) al clúster Ceph, para ello, accedemos a pvelab01 > Ceph > Conjuntos > Crear:

• Le asignamos un nombre, marcamos el check Agregar como almacenamiento, y todo lo demás lo dejamos por defecto, Crear:

• Como podemos ver, aquí tenemos el pool de OSD Ceph creado:

• Si accedemos a los otros nodos del clúster, vemos que también nos muestra el pool de OSD Ceph:

• Si accedemos a Centro de datos > Almacenamiento, ya vemos que tenemos el datastore Ceph del tipo RBD operativo y listo para usarlo, también vemos como se ha agregado automáticamente a todos los nodos de nuestro clúster Ceph:

• Con todo esto, ya tendríamos configurado y operativo todo el almacenamiento compartido para nuestro clúster Ceph, si accedemos a cada nodo > Ceph, podemos ver el estado del nodo Ceph:

• Ahora vamos a desplegar una máquina virtual en este datastore Ceph, para ver como sus discos virtuales se replican de manera automática en todos los nodos del clúster, quedando almacenados estos discos virtuales en cada disco físico de cada nodo.
• Esta es la máquina que hemos desplegado en almacenamiento Ceph RBD:

• Al desplegar la máquina virtual sobre el nodo pvelab02, si accedemos al datastore ceph en cada uno de nuestros nodos del clúster, vemos que los discos virtuales de la máquina se han replicado en cada datastore de cada nodo del clúster Ceph:

Saludos y espero que os sea de ayuda

En este post veremos cómo agregar monitores a los nodos del clúster Ceph.

La topología utilizada sería la siguiente:

• Para empezar a agregar los monitores al cluster de Ceph, accedemos a nuestro nodo principal, pvelab01 > Ceph > Monitor > Crear, como vemos, el nodo pvelab01 ya está añadido desde la instalación inicial de Ceph, ahora debemos de agregar como monitores a los otros nodos del clúster:

• Como podemos ver, ya tenemos los tres nodos agregados al Monitor y como Manager está nuestro nodo pvelab01:

• Si accedemos a los otros nodos de nuestro clúster, ya nos lo debería mostrar todo igual que en el nodo maestro:

• En el siguiente post, veremos cómo crear OSDs, pool de OSD y agregar almacenamiento al clúster Ceph, tal y como nos indican los pasos a seguir al finalizar la instalación de Ceph.

Saludos y espero que os resulte de ayuda

En este post veremos cómo instalar y configurar los paquetes de Ceph en cada uno de nuestros nodos de un clúster Proxmox.

La topología utilizada sería la siguiente:

• Para empezar, hemos agregado a cada nodo de nuestro clúster, un disco duro de 500 GB, los discos deben tener la misma capacidad en todos los nodos:

• Debemos agregar y habilitar en cada nodo de nuestro clúster los repositorios para Ceph, sobre nodo > Actualizaciones > Repositorios > Agregar > Ceph Squid No-Subcription > Agregar:

• Empezamos a instalar Ceph, en el nodo pvelab01 > Ceph > Instalar Ceph:

• Sobre Info, le indicamos la versión de Ceph a instalar y el repositorio, que en mi caso, es el repositorio sin suscripción:

• Sobre Instalación, le indicamos que queremos continuar:

• Vemos que se ha instalado correctamente, Siguiente:

• Sobre Configuración, le indicamos las IPs que vamos a utilizar para nuestro nodo, en este caso la Public Network IP será la IP de managenemt y la del Cluster Network IP será la IP que configuramos para nuestro clúster, nos indica que este nodo será el primer monitor de Ceph, las réplicas lo dejamos por defecto, Siguiente:

• Sobre Éxito, nos indica que la instalación ha sido correcta, y los pasos que debemos dar para seguir configurando nuestro clúster con Ceph, Finalizar:

• Ahora, debemos de hacer lo mismo en el nodo pvelab02:

• Ahora, debemos de hacer lo mismo en el nodo pvelab03:

• Aquí vemos la configuración de cada nodo del clúster:

• Con todo esto, ya tenemos instalado Ceph y realizada la configuración inicial para un clúster con Ceph, en el siguiente post, veremos cómo agregar monitores a los nodos del clúster Ceph, tal y como nos indican los pasos a seguir al finalizar la instalación.

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 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 veremos cómo migrar máquinas virtuales en vivo en un cluster proxmox con almacenamiento ZFS Pool.

La topología utilizada sería la siguiente:

• Para empezar, vemos que la máquina virtual se está ejecutando en el nodo pvelab03, y su disco virtual lo tiene ubicado en el datastore ZFS de ese mismo nodo, en los otros datastore ZFS de los demás nodo no tenemos nada:

• Para comenzar con la migración en vivo, accedemos a la máquina y damos a Migrar, le dejamos tirado un ping para ver que no perdemos servicio:

• Como podemos ver, está en línea en el nodo pvelab03 y la vamos a migrar a pvelab01 al datastore ZFS, como vemos en los warnings, nos indica que la migración puede tardar mucho tiempo debido a que tiene que mover los discos virtuales entre datastores ZFS, Migrar:

• Comienza la migración en vivo de la máquina virtual y de sus discos virtuales, y vemos que se realiza correctamente:

• Ya la tenemos corriendo sobre el nodo pvelab01 y como nos indica el ping, no hemos perdido servicio en ningún momento:

• Si accedemos al datastore ZFS del nodo al que la hemos migrado, pvelab01, vemos que ya tenemos los discos migrados:

• Y si accedemos al datastore ZFS del nodo del que la hemos migrado, pvelab03, vemos que ya NO tenemos los discos de la máquina virtual:

Saludos y espero que os resulte de ayuda

En este post veremos cómo agregar y configurar almacenamiento ZFS local en un clúster Proxmox VE 9.0.

La topología utilizada sería la siguiente:

• Para empezar, hemos agregado a cada nodo de nuestro clúster, un disco duro de 200 GB, los discos deben tener la misma capacidad en todos los nodos:

• Ahora, sobre nuestro nodo 1, pvelab01, nos vamos a crear un pool para ZFS, para ello, accedemos a pvelab01 > Discos > ZFS > Crear ZFS:

• Le indicamos el nombre, y muy importante, NO marcar el check Agregar almacenamiento, ya que como vamos a trabajar en clúster, lo vamos a configurar a posteriori, le indicamos el nivel de RAID que nos interese, la compresión, seleccionamos el disco y Crear:

• Como vemos, ya tenemos el pool de ZFS, creado:

• Ahora, vamos a agregar el almacenamiento al clúster, para ello, accedemos a Centro de datos > Almacenamiento > Agregar > ZFS:

• Sobre General, le indicamos el ID, el ZFS Pool que creamos anteriormente, el contenido, que se cree en todos los nodos y lo activamos, Agregar:

• Como vemos, el datastore se ha agregado correctamente al cluster, pero si nos fijamos bien, sólo lo tenemos operativo en el nodo 1, pvelab01, en pvelab02 y pvelab03 nos aparece con un signo de interrogación, esto quiero decir que no podemos acceder, y que nos faltan configuraciones por asignar, que las veremos ahora:

• Para activar este nuevo datastore ZFS en los nodos pvelab02 y pvelab03, accedemos al nodo > Discos > ZFS > Crear ZFS, para crear el pool ZFS, muy importante, asignarle el mismo Nombre y no marcar el check Agregar almacenamiento, una vez creado vemos que el signo de interrogación desaparece del datastore y ya lo tendríamos operativo:

• Con todo esto, ya tenemos almacenamiento compartido por ZFS en los tres nodos de nuestro clúster, realmente no es un almacenamiento compartido como en iSCSI, aquí el disco de la máquina virtual solo va a estar en un ZFS perteneciente al nodo, cuando migremos la máquina entre nodos, el proceso va a ser más lento que en iSCSI, ya que tiene que migrar el disco virtual completo al ZFS del nodo al que se realice la migración.

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 ZFS local.

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
• Agregar y configurar almacenamiento ZFS local en Clúster Proxmox VE 9.0
• Migración en vivo de máquinas virtuales en un Cluster Proxmox con ZFS Pool
• Configuración de replicación de máquinas virtuales con ZFS local para HA en un clúster Proxmox

Saludos.

En este post vamos a ver cómo agregar almacenamiento iSCSI multipath al clúster Proxmox VE 9.1.2 con configuraciones más avanzadas y mejor preparadas para trabajar en clúster, esto nos va a permitir:

• Definir parámetros avanzados, como round-robin, no_path_retry, rr_min_io…
• Asignar alias legibles a nuestras LUNs.
• Evitaremos que multipath intente agrupar discos locales con la opción de blacklists.
• Aseguraremos un comportamiento idéntico en todos los nodos de nuestro clúster.

Recordamos la topología:

• Para empezar, vamos a instalar en cada nodo los paquetes para el iniciador iSCSI y DM-Multipath, para ello, ejecutamos, apt install -y open-iscsi y apt install -y multipath-tools:

• Habilitamos e iniciamos los servicios para iscsid, ejecutamos, systemctl enable –now iscsid.service y systemctl enable –now open-iscsi.service:

• Habilitamos e iniciamos los servicios para multipathd, ejecutamos, systemctl enable –now multipathd.service:

• Comprobamos el estado de ambos servicios con systemctl status iscsid.service y systemctl status multipathd.service:

• Ahora vamos a ajustar conf, Proxmox recomienda reducir node.session.timeo.replacement_timeout = 15 para iSCSI, por defecto en 120s, lo pasamos a 15s, y para que la sesión sea persistente al arranque modificamos node.startup = automatic, para ello, editamos nano /etc/iscsi/iscsid.conf, esta modificación ayuda a que los timeouts de sesión sean más ágiles y evita esperas largas cuando tenemos fallos:

• Reiniciamos el servicio iscsid, systemctl restart iscsid.service y systemctl restart open-iscsi.service:

• Ahora vamos a descubrir los targets (IQNs) que nos ofrece nuestra cabina en cada IP/portal, esto no cambia ficheros manualmente, sino que guarda la información de esos targets en el directorio /etc/iscsi/nodes/ automáticamente, iscsiadm -m discovery -t st -p 10.10.2.4 y iscsiadm -m discovery -t st -p 10.10.3.4:

• Hacemos login en ambos portales, iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.2.4 -l y iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.3.4 -l, con esto conectamos los nodos pve a la cabina a través de las dos redes iSCSI:

• Para que el login sea persistente y se reconecte en cada reinicio, debemos de ejecutar, iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.2.4 -o update -n node.startup -v automatic y iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.3.4 -o update -n node.startup -v automatic:

• Comprobamos que ambos caminos están activos con, iscsiadm -m session -P3:

• Si accedemos a nuestra cabina SAN iSCSI, podemos ver, que ya tenemos los discos, en este caso, las LUNs conectadas:

• Ejecutamos en cada nodo, ls -l /dev/disk/by-path | grep 10.10 y como vemos la LUN0 tiene dos caminos, por 10.10.2.4 que aparece como /sdf y por 10.10.3.4 que aparece como /sdh, la LUN1 tiene dos caminos, por 10.10.2.4 que aparece como /sdg y por 10.10.3.4 que aparece como /sdi:

• Ahora, Multipath se basa en el WWID único de cada LUN, para obtenerlo ejecutamos:
• Para LUN0, /lib/udev/scsi_id -g -u -d /dev/sdf y /lib/udev/scsi_id -g -u -d /dev/sdh, ambos deben devolver el mismo WWID:

• Para LUN1, /lib/udev/scsi_id -g -u -d /dev/sdg y /lib/udev/scsi_id -g -u -d /dev/sdi, ambos deben devolver el mismo WWID:

• Añadimos el WWID de cada LUN para que multipath lo gestione.
• Para LUN0, multipath -a 360003ff44dc75adcbda106c1b22f4b5b
• Para LUN1, multipath -a 360003ff44dc75adc922dc286607e2e6f

• Recargamos multipath con multipath -r:

• Verificamos multipath con multipath -ll, esto significa que multipath creó un dispositivo /dev/dm-2 que representa a la LUN1, y dentro están los dos caminos activos (sdg y sdi), y otro dispositivo /dev/dm-1 que representa a la LUN0, y dentro están los dos caminos activos (sdf y sdh):

• Si ejecutamos ls -l /dev/mapper/ vemos lo siguiente:
• 360003ff44dc75adc922dc286607e2e6f, es el WWID de la LUN1.
• 360003ff44dc75adcbda106c1b22f4b5b, es el WWID de la LUN0.
• Ambos son enlaces simbólicos a los dispositivos multipath, /dev/dm-1 y /dev/dm-2
• control, es el dispositivo de control interno de multipath.

• Ahora vamos a crear el fichero /etc/multipath.conf en nuestros tres nodos con este contenido:

defaults {

user_friendly_names no

find_multipaths strict

path_selector «round-robin 0»

path_checker tur

rr_min_io 100

failback immediate

no_path_retry 12

}

blacklist {

devnode «^sda»

devnode «^sr0»

}

multipaths {

multipath {

wwid «360003ff44dc75adcbda106c1b22f4b5b»

alias «iscsi_saniscsipve_lun0»

}

multipath {

wwid «360003ff44dc75adc922dc286607e2e6f»

alias «iscsi_saniscsipve_lun1»

}

}

• Con este fichero configuramos:
• Round-robin activado
• Alias legibles (iscsi_saniscsipve_lun0 y iscsi_ saniscsipve _lun1)
• Parámetros ajustados para clusters (retry, failback, tur)
• Disco local sda y cdrom sr0 excluidos

• Ahora verificamos que el fichero /etc/multipath/wwids es exactamente igual en los tres nodos:

• Ahora ejecutamos estos tres comandos en los tres nodos:
• systemctl restart multipathd para recargar multipath.
• multipath -r para releer dispositivos multipath.
• multipath -ll para verificar.

• Con el comando ls -l /dev/mapper/iscsi_saniscsipve_lun* verificamos que existen los nuevos dispositivos:

• Ahora, la creación del Physical Volumen (PV) y Volume Group (VG), solo la vamos a hacer en un nodo, en este caso en el nodo 1, pvelab01.
• Para LUN0, pvcreate /dev/mapper/iscsi_saniscsipve_lun0 y vgcreate vg_iscsi0 /dev/mapper/iscsi_saniscsipve_lun0
• Para LUN1, pvcreate /dev/mapper/iscsi_saniscsipve_lun1 y vgcreate vg_iscsi1 /dev/mapper/iscsi_saniscsipve_lun1

• En los otros dos nodos ejecutamos, pvscan –cache y vgscan para que detecte el Physical Volumen (PV) y el Volume Group (VG):

• Si accedemos a todos los nodos > Discos > LVM, vemos que se han creado los Volume Group:

• Para terminar, accedemos a Centro de datos > Almacenamiento > Agregar > LVM:

• Sobre General, le indicamos el ID, Almacenamiento de base, Grupo del volumen, Contenido, Nodos, Activar, Compartido (importante activar para las migraciones en vivo), Agregar, para agregar la LUN0:

• Agregamos también la otra LUN1:

• Como podemos ver en, Centro de datos > Almacenamiento, tenemos los dos datastores añadidos:

• Aquí vemos, que los tres nodos, ya disponen del almacenamiento compartido por iSCSI y con Multipath:

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 este post vamos a ver cómo migrar máquinas virtuales de forma online o en vivo en un clúster Proxmox VE 9.0, sin pérdida de servicios de estas máquinas.

Recordamos la topología:

• Vamos a migrar una máquina que está en el nodo 3 de nuestro cluster, pvelab03, al nodo 1, pvelab01, como podemos ver le tenemos un ping tirado, para verificar que no perdemos servicio, accedemos a la máquina y damos a Migrar:

• Como podemos ver, está en línea en el nodo pvelab03 y la vamos a migrar a pvelab01:

• Comienza la migración en vivo de la máquina, y vemos que se realiza correctamente:

• Ya la tenemos corriendo sobre el nodo pvelab01 y como nos indica el ping, no hemos perdido servicio en ningún momento:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo agregar almacenamiento iSCSI multipath al clúster Proxmox VE 9.0

Recordamos la topología:

• Para empezar, vamos a instalar en cada nodo los paquetes para el iniciador iSCSI y DM-Multipath, para ello, ejecutamos, apt install -y open-iscsi y apt install -y multipath-tools:

• Habilitamos e iniciamos los servicios para iscsid, ejecutamos, systemctl enable –now iscsid.service y systemctl enable –now open-iscsi.service:

• Habilitamos e iniciamos los servicios para multipathd, ejecutamos, systemctl enable –now multipathd.service:

• Comprobamos el estado de ambos servicios con systemctl status iscsid.service y systemctl status multipathd.service:

• Ahora vamos a ajustar /etc/iscsi/iscsid.conf, Proxmox recomienda reducir node.session.timeo.replacement_timeout = 15 para iSCSI, por defecto en 120s, lo pasamos a 15s, y para que la sesión sea persistente al arranque modificamos node.startup = automatic, para ello, editamos nano /etc/iscsi/iscsid.conf, esta modificación ayuda a que los timeouts de sesión sean más ágiles y evita esperas largas cuando tenemos fallos:

• Reiniciamos el servicio iscsid, systemctl restart iscsid.service y systemctl restart open-iscsi.service:

• Ahora vamos a descubrir los targets (IQNs) que nos ofrece nuestra cabina en cada IP/portal, esto no cambia ficheros manualmente, sino que guarda la información de esos targets en el directorio /etc/iscsi/nodes/ automáticamente, iscsiadm -m discovery -t st -p 10.10.2.4 y iscsiadm -m discovery -t st -p 10.10.3.4:

• Hacemos login en ambos portales, iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.2.4 -l y iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.3.4 -l, con esto conectamos los nodos pve a la cabina a través de las dos redes iSCSI:

• Para que el login sea persistente y se reconecte en cada reinicio, debemos de ejecutar, iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.2.4 -o update -n node.startup -v automatic y iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.3.4 -o update -n node.startup -v automatic:

• Comprobamos que ambos caminos están activos con, iscsiadm -m session -P3:

• Si accedemos a nuestra cabina SAN iSCSI, podemos ver, que ya tenemos los discos, en este caso, las LUNs conectadas:

• Ejecutamos en cada nodo, ls -l /dev/disk/by-path | grep 10.10 y como vemos la LUN0 tiene dos caminos, por 10.10.2.4 que aparece como /sdc y por 10.10.3.4 que aparece como /sde, la LUN1 tiene dos caminos, por 10.10.2.4 que aparece como /sdd y por 10.10.3.4 que aparece como /sdf:

• Ahora, Multipath se basa en el WWID único de cada LUN, para obtenerlo ejecutamos:
• Para LUN0, /lib/udev/scsi_id -g -u -d /dev/sdc y /lib/udev/scsi_id -g -u -d /dev/sde, ambos deben devolver el mismo WWID:

• Para LUN1, /lib/udev/scsi_id -g -u -d /dev/sdd y /lib/udev/scsi_id -g -u -d /dev/sdf, ambos deben devolver el mismo WWID:

• Añadimos el WWID de cada LUN para que multipath lo gestione.
• Para LUN0, multipath -a 360003ff44dc75adcbda106c1b22f4b5b
• Para LUN1, multipath -a 360003ff44dc75adc922dc286607e2e6f

• Recargamos multipath con multipath -r:

• Verificamos multipath con multipath -ll, esto significa que multipath creó un dispositivo /dev/dm-0 que representa a la LUN0, y dentro están los dos caminos activos (sdc y sde), y otro dispositivo /dev/dm-1 que representa a la LUN1, y dentro están los dos caminos activos (sdd y sdf):

• Si ejecutamos ls -l /dev/mapper/ vemos lo siguiente:
• 360003ff44dc75adc922dc286607e2e6f, es el WWID de la LUN1.
• 360003ff44dc75adcbda106c1b22f4b5b, es el WWID de la LUN0.
• Ambos son enlaces simbólicos a los dispositivos multipath , /dev/dm-0 y /dev/dm-1
• control, es el dispositivo de control interno de multipath.

• Ahora, la creación del Physical Volumen (PV) y Volume Group (VG), solo la vamos a hacer en un nodo, en este caso en el nodo 1, pvelab01.
• Para LUN0, pvcreate /dev/mapper/360003ff44dc75adcbda106c1b22f4b5b y vgcreate vg_iscsi0 /dev/mapper/360003ff44dc75adcbda106c1b22f4b5b
• Para LUN1, pvcreate /dev/mapper/360003ff44dc75adc922dc286607e2e6f y vgcreate vg_iscsi1 /dev/mapper/360003ff44dc75adc922dc286607e2e6f

• Si accedemos a todos los nodos > Discos > LVM, vemos que se han creado los Volume Group:

• Para terminar, accedemos a Centro de datos > Almacenamiento > Agregar > LVM:

• Sobre General, le indicamos el ID, Almacenamiento de base, Grupo del volumen, Contenido, Nodos, Activar, Compartido (importante activar para las migraciones en vivo), Agregar, para agregar la LUN0:

• Agregamos también la otra LUN1:

• Como podemos ver en, Centro de datos > Almacenamiento, tenemos los dos datastores añadidos:

• Aquí vemos, que los tres nodos, ya disponen del almacenamiento compartido por iSCSI y con Multipath:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo crear y configurar un clúster de 3 nodos en Proxmox VE 9.0

Recordamos la topología:

• Para empezar a crear el clúster, vamos a acceder a nuestro nodo1, pvelab01, sobre Centro de datos > Cluster > Crear cluster:

• Le indicamos un nombre para el cluster, y debemos asignarle dos interfaces de red, la primera es la de la red de management y la segunda es la dedicada para el clúster, Crear:

• Vemos que se crea el clúster y se añade el nodo correctamente, y ya tenemos nuestro primer nodo en el clúster:

• Ahora vamos a unir los otros dos nodos al clúster, para ello, necesitamos la información de unión, que nos la da este primer nodo:

• Accedemos al segundo nodo, pvelab02, sobre Centro de datos > Cluster > Unirse al cluster y pegamos la información que copiamos del clúster creado sobre el nodo 1, le indicamos la IP del nodo 1, la contraseña de root, la huella digital, y configuramos la red del clúster al igual que hicimos en el nodo 1, Unir al clúster:

• Accedemos al tercer nodo, pvelab03, sobre Centro de datos > Cluster > Unirse al cluster y pegamos la información que copiamos del clúster creado sobre el nodo 1, le indicamos la IP del nodo 1, la contraseña de root, la huella digital, y configuramos la red del clúster al igual que hicimos en el nodo 1 y en el nodo 2, Unir al clúster:

• Ahora sobre el nodo 1, pvelab01 > Centro de datos > Cluster, podemos ver, que ya tenemos el clúster de proxmox creado y configurado con tres nodos:

• Sobre Centro de datos > Resumen, podemos ver, un resumen del estado de nuestro clúster:

• Ahora desde cualquiera de los nodos del clúster, tendremos acceso:

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