{"id":2378,"date":"2026-04-24T02:26:38","date_gmt":"2026-04-24T02:26:38","guid":{"rendered":"https:\/\/dsantana.uas.edu.mx\/?p=2378"},"modified":"2026-04-24T02:32:40","modified_gmt":"2026-04-24T02:32:40","slug":"practica-cluster-de-alta-disponibilidad-en-debian-13","status":"publish","type":"post","link":"https:\/\/dsantana.uas.edu.mx\/index.php\/2026\/04\/24\/practica-cluster-de-alta-disponibilidad-en-debian-13\/","title":{"rendered":"Pr\u00e1ctica: Cl\u00faster de Alta Disponibilidad en Debian 13"},"content":{"rendered":"\n<figure class=\"wp-block-image aligncenter size-full\"><img fetchpriority=\"high\" decoding=\"async\" width=\"1024\" height=\"1024\" src=\"https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/Practica-Cluster-de-Alta-Disponibilidad-en-Debian_.png\" alt=\"\" class=\"wp-image-2383\" srcset=\"https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/Practica-Cluster-de-Alta-Disponibilidad-en-Debian_.png 1024w, https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/Practica-Cluster-de-Alta-Disponibilidad-en-Debian_-300x300.png 300w, https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/Practica-Cluster-de-Alta-Disponibilidad-en-Debian_-150x150.png 150w, https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/Practica-Cluster-de-Alta-Disponibilidad-en-Debian_-768x768.png 768w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p><strong>Descripci\u00f3n general:<\/strong> En esta pr\u00e1ctica crearemos un <strong>cl\u00faster de alta disponibilidad (HA)<\/strong> de dos nodos en modo <strong>activo\/pasivo<\/strong> usando <strong>Pacemaker<\/strong> (gestor de recursos de cl\u00faster) y <strong>Corosync<\/strong> (servicio de comunicaci\u00f3n entre nodos) sobre Debian 13. El objetivo es que un recurso (una direcci\u00f3n IP virtual) est\u00e9 siempre disponible: si el <strong>Nodo A<\/strong> falla, el <strong>Nodo B<\/strong> tomar\u00e1 autom\u00e1ticamente el control, minimizando la interrupci\u00f3n del servicio (<em>failover<\/em>). Configuraremos la IP virtual <strong>192.168.1.100<\/strong> que \u00abflotar\u00e1\u00bb entre los nodos, de modo que los clientes se conecten siempre a esa direcci\u00f3n sin importar qu\u00e9 servidor f\u00edsico la est\u00e9 atendiendo.<\/p>\n\n\n\n<p>Se trata de configurar un cl\u00faster de alta disponibilidad activo\/pasivo en el que uno de los dos equipos pueda responder siempre a la direcci\u00f3n IP que se pretende mantener en alta disponibilidad.<\/p>\n\n\n\n<p><strong>Escenario del laboratorio:<\/strong><\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><th><strong>Elemento<\/strong><\/th><th><strong>Nodo A<\/strong><\/th><th><strong>Nodo B<\/strong><\/th><\/tr><tr><th><strong>Hostname<\/strong><\/th><td><code>nodo-a<\/code><\/td><td><code>nodo-b<\/code><\/td><\/tr><tr><th><strong>IP fija<\/strong><\/th><td>192.168.1.10<\/td><td>192.168.1.11<\/td><\/tr><tr><th><strong>IP virtual (VIP)<\/strong><\/th><td>192.168.1.100<\/td><td>(la asume cuando A falla)<\/td><\/tr><tr><th><strong>SO<\/strong><\/th><td>Debian 13 m\u00ednimo<\/td><td>Debian 13 m\u00ednimo<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Ambos nodos est\u00e1n en la misma red local y se puede acceder con privilegios de <code>root<\/code> (o <code>sudo<\/code>).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<p><strong>Conceptos clave:<\/strong> Antes de empezar, repasemos los t\u00e9rminos esenciales que se usan a lo largo de la pr\u00e1ctica:<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" width=\"1024\" height=\"698\" src=\"https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/image-1024x698.png\" alt=\"\" class=\"wp-image-2379\" srcset=\"https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/image-1024x698.png 1024w, https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/image-300x204.png 300w, https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/image-768x523.png 768w, https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/image-1536x1046.png 1536w, https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/image-2048x1395.png 2048w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p>A continuaci\u00f3n se detalla <strong>paso a paso<\/strong> la configuraci\u00f3n, explicando <strong>qu\u00e9 hace cada comando, por qu\u00e9 es necesario y qu\u00e9 ocurre internamente en el cl\u00faster<\/strong>. Cada paso incluye <strong>verificaciones<\/strong>, posibles <strong>errores comunes<\/strong> y c\u00f3mo identificarlos. Al final se proponen preguntas de an\u00e1lisis y criterios de evaluaci\u00f3n.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" width=\"826\" height=\"1024\" src=\"https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/image-1-826x1024.png\" alt=\"\" class=\"wp-image-2380\" srcset=\"https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/image-1-826x1024.png 826w, https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/image-1-242x300.png 242w, https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/image-1-768x952.png 768w, https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/image-1-1239x1536.png 1239w, https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/image-1-1652x2048.png 1652w, https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/image-1.png 1829w\" sizes=\"(max-width: 826px) 100vw, 826px\" \/><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Paso 1: Preparaci\u00f3n de los Nodos (hostname, \/etc\/hosts, actualizaci\u00f3n)<\/h2>\n\n\n\n<p><strong>Qu\u00e9 se hace:<\/strong> En cada servidor asignamos nombres de host descriptivos, aseguramos la resoluci\u00f3n de nombres entre ellos y actualizamos el sistema operativo.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1.1 Cambiar el hostname<\/h3>\n\n\n\n<p>En <strong>Nodo A:<\/strong><\/p>\n\n\n\n<p>hostnamectl set-hostname nodo-a<br><\/p>\n\n\n\n<p>En <strong>Nodo B:<\/strong><\/p>\n\n\n\n<p>hostnamectl set-hostname nodo-b<br><\/p>\n\n\n\n<p>Esto define el nombre de m\u00e1quina a nivel del sistema (reflejado en <code>uname -n<\/code> y <code>hostname<\/code>). <strong>Los nombres de host deben coincidir exactamente<\/strong> con los que usaremos en la configuraci\u00f3n del cl\u00faster. Pacemaker y Corosync no usan el prompt de la terminal ni apodos; identifican los nodos por su hostname real del SO. Si hay discrepancia (por ejemplo, el hostname del sistema es <code>debian-01<\/code> pero en la configuraci\u00f3n del cl\u00faster se escribe <code>nodo-a<\/code>), el cl\u00faster no reconocer\u00e1 correctamente a los nodos, provocando errores de autenticaci\u00f3n y conectividad. En un entorno de cl\u00faster, para cambiar el nombre de una m\u00e1quina se puede ejecutar <code>hostnamectl set-hostname nombre_nuevo<\/code>. <a href=\"https:\/\/blogsaverroes.juntadeandalucia.es\/plataformaeiv\/files\/2022\/12\/PCluster-dos-nodos-recurso-ip.pdf\">[blogsaverr&#8230;dalucia.es]<\/a><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1.2 Editar <code>\/etc\/hosts<\/code><\/h3>\n\n\n\n<p>En <strong>ambos nodos<\/strong>, abrir <code>\/etc\/hosts<\/code>:<\/p>\n\n\n\n<p><\/p>\n\n\n\n<p>nano \/etc\/hosts<br><\/p>\n\n\n\n<p>Y a\u00f1adir las siguientes entradas:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>192.168.1.10   nodo-a\n192.168.1.11   nodo-b\n<\/code><\/pre>\n\n\n\n<p>De esta manera, cada nodo puede resolver el nombre del otro por IP. Esto es fundamental porque <code>pcs<\/code> y Corosync utilizar\u00e1n los nombres (<code>nodo-a<\/code>, <code>nodo-b<\/code>) para establecer la comunicaci\u00f3n. Sin resoluci\u00f3n correcta, los comandos de autenticaci\u00f3n o arranque de cl\u00faster fallar\u00e1n al no poder encontrar el host destino. El blog de maquinasvirtuales.eu muestra un ejemplo de <code>\/etc\/hosts<\/code> configurado para un cl\u00faster Pacemaker, donde cada nodo tiene su IP y nombre mapeados correctamente.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1.3 Actualizar el sistema<\/h3>\n\n\n\n<p>En ambos nodos:<\/p>\n\n\n\n<p><\/p>\n\n\n\n<p>apt update &amp;&amp; apt upgrade -y<br><\/p>\n\n\n\n<p>Mantener Debian actualizado garantiza versiones compatibles de Pacemaker, Corosync y PCS. Tras una actualizaci\u00f3n que incluya kernel nuevo, es recomendable reiniciar los nodos antes de continuar.<\/p>\n\n\n\n<p><strong>Verificaci\u00f3n:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>hostname<\/code> o <code>uname -n<\/code> en cada nodo \u2192 debe mostrar <code>nodo-a<\/code> o <code>nodo-b<\/code> respectivamente.<\/li>\n\n\n\n<li><code>ping -c 1 nodo-b<\/code> desde nodo-a \u2192 debe resolver a 192.168.1.11 y responder; lo mismo desde nodo-b hacia nodo-a.<\/li>\n\n\n\n<li>Confirmar que no hay conflictos en <code>\/etc\/hosts<\/code>: no a\u00f1adir <code>nodo-a<\/code> en la l\u00ednea de 127.0.0.1 (pues el cl\u00faster intentar\u00eda comunicarse consigo mismo).<\/li>\n<\/ul>\n\n\n\n<p><strong>Errores comunes:<\/strong><\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><th>Problema<\/th><th>S\u00edntoma \/ Mensaje<\/th><th>Soluci\u00f3n<\/th><\/tr><tr><th><strong>Hostname no cambiado<\/strong><\/th><td><code>pcs<\/code> indica <em>\u00abno configuration for host X\u00bb<\/em> o el nombre no aparece en <code>pcs status<\/code>.<\/td><td>Verificar con <code>uname -n<\/code>. Si no coincide, reejecutar <code>hostnamectl set-hostname<\/code> y reiniciar la sesi\u00f3n.<\/td><\/tr><tr><th><strong>Resoluci\u00f3n de nombres fallida<\/strong><\/th><td><code>pcs host auth<\/code> se cuelga o muestra error de conexi\u00f3n\/<em>refused<\/em> hacia <code>nodo-b<\/code>.<\/td><td>Verificar las entradas en <code>\/etc\/hosts<\/code> de ambos nodos. Probar <code>ping nodo-b<\/code> desde nodo-a.<\/td><\/tr><tr><th><strong>Firewall bloquea puertos de cl\u00faster<\/strong><\/th><td>Un nodo aparece <em>OFFLINE<\/em> en <code>pcs status<\/code> tras configurar el cl\u00faster.<\/td><td>Asegurar que el firewall permite tr\u00e1fico <strong>UDP 5404\/5405<\/strong> (puertos est\u00e1ndar de Corosync). En laboratorio, <code>ufw disable<\/code> o abrir reglas espec\u00edficas.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Paso 2: Instalaci\u00f3n del Stack de Cl\u00faster (Pacemaker, Corosync, PCS)<\/h2>\n\n\n\n<p><strong>Qu\u00e9 se hace:<\/strong> Se instalan en <strong>ambos nodos<\/strong> los tres componentes del stack de HA:<\/p>\n\n\n\n<p><\/p>\n\n\n\n<p>apt install -y pacemaker corosync pcs<br><\/p>\n\n\n\n<p>Este comando instala: <a href=\"https:\/\/linuxmind.dev\/es\/2025\/05\/22\/implementa-un-cluster-de-alta-disponibilidad-con-pacemaker-y-corosync\/\">[linuxmind.dev]<\/a><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Pacemaker:<\/strong> el gestor de cl\u00faster HA. Se encarga de la gesti\u00f3n de recursos, asegurando que los servicios cr\u00edticos se mantengan en funcionamiento incluso en caso de fallos de nodo.<\/li>\n\n\n\n<li><strong>Corosync:<\/strong> la capa de comunicaci\u00f3n y consenso entre nodos (anillo o multicast\/unicast).<\/li>\n\n\n\n<li><strong>PCS (Pacemaker\/Corosync Configuration System):<\/strong> herramienta de l\u00ednea de comandos (y GUI) para configurar y administrar cl\u00fasteres basados en Pacemaker. Permite a los usuarios ver, modificar y crear cl\u00fasteres f\u00e1cilmente. PCS incluye un demonio llamado <code>pcsd<\/code> que opera como servidor remoto para pcs.<\/li>\n<\/ul>\n\n\n\n<p>Tras la instalaci\u00f3n, <strong>habilitamos y arrancamos PCSD<\/strong> en cada nodo:<\/p>\n\n\n\n<p><\/p>\n\n\n\n<p>systemctl enable pcsd<\/p>\n\n\n\n<p>systemctl start pcsd<br><\/p>\n\n\n\n<p><code>pcsd<\/code> escucha en cada nodo y permite que, al autenticarse, podamos ejecutar comandos de configuraci\u00f3n del cl\u00faster en todos los nodos desde uno solo.<\/p>\n\n\n\n<p><strong>Por qu\u00e9 se hace:<\/strong> Pacemaker y Corosync forman el motor del cl\u00faster HA. Sin Pacemaker no habr\u00eda orquestaci\u00f3n de recursos; sin Corosync no habr\u00eda detecci\u00f3n de fallos entre nodos. La herramienta <code>pcs<\/code> simplifica enormemente la configuraci\u00f3n, evitando la edici\u00f3n manual de archivos XML o configuraci\u00f3n de Corosync; adem\u00e1s, distribuye autom\u00e1ticamente las claves de autenticaci\u00f3n a todos los nodos. Habilitar <code>pcsd<\/code> lo hace persistente tras reinicios.<\/p>\n\n\n\n<p><strong>Internamente:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Se instalan los servicios systemd <code>pacemaker<\/code>, <code>corosync<\/code> y <code>pcsd<\/code>, pero <strong>a\u00fan no<\/strong> se inician Pacemaker ni Corosync \u2014 primero debemos completar la autenticaci\u00f3n y definici\u00f3n del cl\u00faster. Solo <code>pcsd<\/code> se inicia ahora para poder usar <code>pcs<\/code>.<\/li>\n\n\n\n<li>Corosync maneja un anillo de comunicaci\u00f3n (por defecto, UDP unicast \u2014UDPU\u2014 cuando se configura con <code>pcs cluster setup<\/code>) para enviar mensajes de heartbeat. Para un cl\u00faster de dos nodos, es necesario a\u00f1adir <code>two_node: 1<\/code> en el bloque de qu\u00f3rum de Corosync; <code>pcs cluster setup<\/code> lo configura autom\u00e1ticamente.<\/li>\n<\/ul>\n\n\n\n<p><strong>Componentes internos de Pacemaker<\/strong> que conviene conocer:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>CIB (Cluster Information Base):<\/strong> Almacena la configuraci\u00f3n y el estado del cl\u00faster, replic\u00e1ndolos en todos los nodos para mantener coherencia.<\/li>\n\n\n\n<li><strong>Resource Agents:<\/strong> Scripts que encapsulan el conocimiento necesario para gestionar un recurso espec\u00edfico (iniciar, detener, monitorizar).<\/li>\n\n\n\n<li><strong>CRM (Cluster Resource Manager):<\/strong> Toma decisiones sobre la gesti\u00f3n de recursos basadas en la informaci\u00f3n del CIB y las pol\u00edticas configuradas.<\/li>\n\n\n\n<li><strong>Fencing:<\/strong> Mecanismo para aislar un nodo defectuoso del resto del cl\u00faster y asegurar la integridad de los datos.<\/li>\n<\/ul>\n\n\n\n<p><strong>Verificaci\u00f3n:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>systemctl status pcsd<\/code> \u2192 debe mostrarlo <strong>active (running)<\/strong> en ambos nodos.<\/li>\n\n\n\n<li><code>pcs --version<\/code> \u2192 muestra la versi\u00f3n instalada de PCS.<\/li>\n\n\n\n<li><code>corosync -v<\/code> \u2192 muestra la versi\u00f3n de Corosync.<\/li>\n\n\n\n<li>No iniciar a\u00fan Pacemaker\/Corosync manualmente; lo haremos con <code>pcs<\/code> tras definir el cl\u00faster.<\/li>\n<\/ul>\n\n\n\n<p><strong>Errores comunes:<\/strong><\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><th>Problema<\/th><th>S\u00edntoma \/ Mensaje<\/th><th>Soluci\u00f3n<\/th><\/tr><tr><th><strong>Repositorios faltantes<\/strong><\/th><td><code>apt<\/code> no encuentra paquetes <code>pacemaker<\/code> o <code>pcs<\/code>.<\/td><td>Asegurarse de tener los repositorios de Debian 13 correctos en <code>\/etc\/apt\/sources.list<\/code>.<\/td><\/tr><tr><th><strong>Permisos insuficientes<\/strong><\/th><td>Error de permisos al instalar.<\/td><td>Ejecutar como <code>root<\/code> o con <code>sudo<\/code>.<\/td><\/tr><tr><th><strong><code>pcsd<\/code> no habilitado<\/strong><\/th><td>Al intentar autenticaci\u00f3n, <code>pcs<\/code> responde <em>\u00abError: unable to connect to node&#8230;\u00bb<\/em>.<\/td><td>Verificar que <code>pcsd<\/code> est\u00e1 activo en ambos nodos (<code>systemctl status pcsd<\/code>). Iniciar\/habilitar si es necesario.<\/td><\/tr><tr><th><strong>Versiones distintas entre nodos<\/strong><\/th><td>Errores de protocolo o incompatibilidad durante la autenticaci\u00f3n.<\/td><td>Usar la misma versi\u00f3n de paquetes en ambos nodos (mismo SO y actualizaciones).<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Paso 3: Autenticaci\u00f3n del Cl\u00faster (usuario <em>hacluster<\/em> y <code>pcs host auth<\/code>)<\/h2>\n\n\n\n<p><strong>Qu\u00e9 se hace:<\/strong> Para que <code>pcs<\/code> pueda controlar ambos nodos de forma remota, se usa un usuario dedicado llamado <strong><code>hacluster<\/code><\/strong> (creado autom\u00e1ticamente al instalar <code>pcs<\/code>). Se realizan dos tareas:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3.1 Asignar contrase\u00f1a al usuario <code>hacluster<\/code><\/h3>\n\n\n\n<p>En <strong>cada nodo<\/strong> (ambos):<\/p>\n\n\n\n<p><\/p>\n\n\n\n<p>passwd hacluster<br><\/p>\n\n\n\n<p>Elegir una contrase\u00f1a (se recomienda la misma en ambos para simplificar el proceso de autenticaci\u00f3n). Este usuario es el que <code>pcs<\/code> utiliza internamente para autenticarse contra los nodos del cl\u00faster.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3.2 Autenticaci\u00f3n entre nodos<\/h3>\n\n\n\n<p>Desde <strong>nodo-a<\/strong>:<\/p>\n\n\n\n<p><\/p>\n\n\n\n<p>pcs host auth nodo-a nodo-b<br><\/p>\n\n\n\n<p>Este comando establece la <strong>confianza mutua<\/strong> entre <code>nodo-a<\/code> y <code>nodo-b<\/code>. <code>pcs<\/code> solicita las credenciales del usuario <code>hacluster<\/code> y las usa para crear una relaci\u00f3n de confianza segura entre ambos nodos. Si pide confirmaci\u00f3n de huella digital (<em>fingerprint<\/em>), aceptar con \u00abyes\u00bb.<\/p>\n\n\n\n<p><strong>Por qu\u00e9 se hace:<\/strong> Sin autenticaci\u00f3n, <code>pcs<\/code> solo puede administrar el nodo local. Este paso habilita la gesti\u00f3n centralizada: al crear el cl\u00faster o recursos, la configuraci\u00f3n se propagar\u00e1 autom\u00e1ticamente a ambos nodos. <code>pcs host auth<\/code> realiza un intercambio de claves de autenticaci\u00f3n seguras entre los nodos.<\/p>\n\n\n\n<p><strong>Internamente:<\/strong><code>pcs host auth<\/code> realiza conexiones HTTPS al demonio <code>pcsd<\/code> de cada nodo peer, autentic\u00e1ndose con las credenciales de <code>hacluster<\/code>. Tras la autenticaci\u00f3n exitosa, distribuye los archivos de claves de autenticaci\u00f3n de Corosync y Pacemaker. En la salida del comando se observan mensajes como:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Sending 'corosync authkey', 'pacemaker authkey' to 'nodo-a', 'nodo-b'\nnodo-a: successful distribution of the file 'corosync authkey'\nnodo-a: successful distribution of the file 'pacemaker authkey'\nnodo-b: successful distribution of the file 'corosync authkey'\nnodo-b: successful distribution of the file 'pacemaker authkey'\n<\/code><\/pre>\n\n\n\n<p>Esto confirma que las claves de autenticaci\u00f3n de Corosync y Pacemaker se transfirieron y propagaron exitosamente a ambos equipos.<\/p>\n\n\n\n<p><strong>Verificaci\u00f3n:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>El comando <code>pcs host auth<\/code> debe terminar con un mensaje de \u00e9xito para cada nodo (ej.: <em>\u00abnodo-a: Authorized\u00bb<\/em>, <em>\u00abnodo-b: Authorized\u00bb<\/em>).<\/li>\n\n\n\n<li>Confirmar desde nodo-b que tambi\u00e9n reconoce a nodo-a como parte del cl\u00faster.<\/li>\n<\/ul>\n\n\n\n<p><strong>Errores comunes:<\/strong><\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><th>Problema<\/th><th>S\u00edntoma \/ Mensaje<\/th><th>Soluci\u00f3n<\/th><\/tr><tr><th><strong>Contrase\u00f1a distinta o no establecida<\/strong><\/th><td><code>pcs host auth<\/code> falla en uno de los nodos (error de autenticaci\u00f3n).<\/td><td>Aseg\u00farate de asignar la <strong>misma contrase\u00f1a<\/strong> en ambos nodos. Repetir <code>passwd hacluster<\/code> si es necesario.<\/td><\/tr><tr><th><strong>Hostname no resoluble<\/strong><\/th><td>Error: <em>\u00abUnable to authenticate to host nodo-b\u00bb<\/em><\/td><td>Revisar resoluci\u00f3n de nombres (Paso 1). Alternativamente, usar IPs directamente, aunque lo ideal es que los nombres funcionen.<\/td><\/tr><tr><th><strong><code>pcsd<\/code> no corriendo en el nodo destino<\/strong><\/th><td>Error de conexi\u00f3n rechazada.<\/td><td>Verificar <code>systemctl status pcsd<\/code> en ambos nodos.<\/td><\/tr><tr><th><strong>Relojes desincronizados<\/strong><\/th><td>Problemas SSL o certificados inv\u00e1lidos.<\/td><td>Verificar que la hora\/fecha de ambos nodos sea correcta y est\u00e9 sincronizada (recomendable usar NTP\/Chrony) <a href=\"https:\/\/linuxmind.dev\/es\/2025\/05\/22\/implementa-un-cluster-de-alta-disponibilidad-con-pacemaker-y-corosync\/\">[linuxmind.dev]<\/a>.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Paso 4: Creaci\u00f3n y Arranque del Cl\u00faster (<code>pcs cluster setup\/start\/enable<\/code>)<\/h2>\n\n\n\n<p><strong>Qu\u00e9 se hace:<\/strong> Ahora que los nodos conf\u00edan entre s\u00ed, definimos el cl\u00faster e iniciamos todos los servicios. Desde <strong>nodo-a<\/strong> ejecutamos tres comandos en secuencia:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">4.1 Crear el cl\u00faster<\/h3>\n\n\n\n<p><\/p>\n\n\n\n<p>pcs cluster setup laboratorio-ha nodo-a nodo-b<br><\/p>\n\n\n\n<p>Esto configura un nuevo cl\u00faster con nombre \u00ab<code>laboratorio-ha<\/code>\u00bb integrado por los dos nodos especificados. Internamente, <code>pcs<\/code> realiza varias acciones de una sola vez:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Genera la configuraci\u00f3n de Corosync:<\/strong> incluye el nombre del cl\u00faster, el transporte de red (UDPU \u2014unicast UDP\u2014 por defecto), la lista de nodos (<code>nodo-a<\/code>, <code>nodo-b<\/code> con sus IPs correspondientes) y la clave de autenticaci\u00f3n para cifrar el tr\u00e1fico. Esta configuraci\u00f3n se almacena en <code>\/etc\/corosync\/corosync.conf<\/code>.<\/li>\n\n\n\n<li><strong>Distribuye la configuraci\u00f3n a ambos nodos:<\/strong> gracias a la autenticaci\u00f3n del Paso 3, <code>pcs<\/code> copia autom\u00e1ticamente todos los archivos necesarios.<\/li>\n<\/ul>\n\n\n\n<p>En la salida del comando se observan mensajes similares a los del paso de autenticaci\u00f3n, confirmando la distribuci\u00f3n exitosa de archivos de configuraci\u00f3n y claves a ambos nodos.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">4.2 Iniciar el cl\u00faster<\/h3>\n\n\n\n<p><\/p>\n\n\n\n<p>pcs cluster start &#8211;all<br><\/p>\n\n\n\n<p>Arranca los servicios Corosync <strong>y<\/strong> Pacemaker en ambos nodos simult\u00e1neamente.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">4.3 Habilitar inicio autom\u00e1tico<\/h3>\n\n\n\n<p><\/p>\n\n\n\n<p>pcs cluster enable &#8211;all<br><\/p>\n\n\n\n<p>Configura que los servicios de cl\u00faster inicien autom\u00e1ticamente tras un reinicio del sistema en ambos nodos.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">4.4 Verificar estado<\/h3>\n\n\n\n<p><\/p>\n\n\n\n<p>pcs status<br><\/p>\n\n\n\n<p><strong>Por qu\u00e9 se hace:<\/strong><code>pcs cluster setup<\/code> nos ahorra editar manualmente archivos XML o de Corosync y garantiza que ambos nodos tengan la misma configuraci\u00f3n. Nombrar al cl\u00faster ayuda a identificarlo en entornos con m\u00faltiples cl\u00fasteres. Arrancar y habilitar el cl\u00faster pone en funcionamiento la infraestructura HA: Corosync establece el enlace de comunicaci\u00f3n y Pacemaker espera instrucciones (todav\u00eda no hay recursos, los a\u00f1adiremos en el siguiente paso).<\/p>\n\n\n\n<p><strong>Internamente (qu\u00e9 ocurre al arrancar):<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Corosync inicia su anillo:<\/strong> Los dos nodos establecen comunicaci\u00f3n UDP (unicast por defecto al usar <code>pcs<\/code>). Se intercambian mensajes de <em>heartbeat<\/em> y forman un <strong>qu\u00f3rum<\/strong>. En un cl\u00faster de dos nodos, Corosync habilita autom\u00e1ticamente el modo <code>two_node: 1<\/code>, permitiendo al nodo sobreviviente continuar operando aunque el otro caiga.<\/li>\n\n\n\n<li><strong>Pacemaker inicia en cada nodo:<\/strong> Uno de los nodos es elegido como <strong>DC (Designated Coordinator)<\/strong>, el nodo l\u00edder que coordina las decisiones de gesti\u00f3n de recursos (no confundir con \u00abPrimary\u00bb a nivel de recurso individual). Ambos nodos reportan su estado (\u00abOnline\u00bb) al CIB. Puedes identificar el DC en la salida de <code>pcs status<\/code> (ej.: <code>Current DC: nodo-a<\/code>).<\/li>\n\n\n\n<li>Al no tener recursos a\u00fan, Pacemaker simplemente mantiene el estado. Ambos nodos aparecen <strong>Online<\/strong> y no hay recursos configurados.<\/li>\n<\/ul>\n\n\n\n<p><strong>Verificaci\u00f3n:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>pcs status<\/code> debe mostrar <strong>2 nodos online<\/strong>. La secci\u00f3n de nodos indicar\u00e1 algo como: <code>Online: [ nodo-a nodo-b ]<\/code>.<\/li>\n\n\n\n<li>Puede aparecer una advertencia: <em>\u00abWARNINGS: No stonith devices and stonith-enabled is not false\u00bb<\/em>. Esto es esperado y se resolver\u00e1 en el Paso 5.<\/li>\n\n\n\n<li>Debe figurar \u00abNo resources\u00bb o una lista vac\u00eda de recursos.<\/li>\n\n\n\n<li>Otra herramienta de verificaci\u00f3n: <code>crm_mon -1<\/code> muestra informaci\u00f3n similar de nodos online y recursos.<\/li>\n<\/ul>\n\n\n\n<p><strong>Errores comunes:<\/strong><\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><th>Problema<\/th><th>S\u00edntoma \/ Mensaje<\/th><th>Soluci\u00f3n<\/th><\/tr><tr><th><strong>Fallo en setup<\/strong><\/th><td><code>pcs cluster setup<\/code> lanza errores al conectar con el nodo remoto o copiar archivos.<\/td><td>Asegurarse de haber completado el Paso 3 (auth). Verificar que <code>pcsd<\/code> est\u00e9 corriendo en ambos.<\/td><\/tr><tr><th><strong>Nodo aparece OFFLINE<\/strong><\/th><td>En <code>pcs status<\/code>, uno de los dos nodos figura <em>OFFLINE<\/em>.<\/td><td>Verificar en ese nodo: <code>systemctl status corosync<\/code> y <code>journalctl -xe<\/code> para ver errores (auth key inv\u00e1lida, firewall, problemas de red). Reintentar <code>pcs host auth<\/code> y luego <code>pcs cluster start --all<\/code>.<\/td><\/tr><tr><th><strong>Error HTTP 400<\/strong><\/th><td>Corosync no arranca (posible en contenedores LXC o entornos restringidos).<\/td><td>Verificar que el entorno de virtualizaci\u00f3n permita los servicios necesarios. En LXC Proxmox se requieren par\u00e1metros adicionales de configuraci\u00f3n del contenedor.<\/td><\/tr><tr><th><strong>Cluster ya existe<\/strong><\/th><td>Error: <em>\u00abCluster already exists\u00bb<\/em>.<\/td><td>Si necesitas repetir, primero destruye el cl\u00faster previo con <code>pcs cluster destroy --all<\/code> en ambos nodos (esto borra la configuraci\u00f3n completa). Luego reintenta setup.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Paso 5: Configuraci\u00f3n de la IP Virtual en Pacemaker (Recurso <strong>IPaddr2<\/strong> y STONITH)<\/h2>\n\n\n\n<p>Con el cl\u00faster en marcha, a\u00f1adiremos el <strong>primer recurso<\/strong>: una direcci\u00f3n IP flotante gestionada por Pacemaker.<\/p>\n\n\n\n<p><strong>Qu\u00e9 se hace:<\/strong> Desde <strong>nodo-a<\/strong>, ejecutamos los siguientes comandos:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">5.1 Crear el recurso de IP virtual<\/h3>\n\n\n\n<p><\/p>\n\n\n\n<p>pcs resource create IP-Virtual ocf:heartbeat:IPaddr2 ip=192.168.100.100 cidr_netmask=24 op monitor interval=30s<br><\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>\u26a0\ufe0f <strong>Advertencia cr\u00edtica (discrepancia de IP):<\/strong> El comando anterior usa la IP <code>192.168.100.100<\/code> (subred <code>192.168.100.x<\/code>), pero el escenario del laboratorio define a los nodos en la subred <code>192.168.1.x<\/code> (IPs <code>192.168.1.10<\/code> y <code>192.168.1.11<\/code>) con VIP <code>192.168.1.100<\/code>. Esto es un error tipogr\u00e1fico en la actividad original. Para que la VIP funcione correctamente <strong>en la misma subred que los nodos<\/strong>, el par\u00e1metro deber\u00eda ser <code>ip=192.168.1.100<\/code>. Si se usa <code>192.168.100.100<\/code>, la IP flotante quedar\u00e1 en una subred diferente y no ser\u00e1 accesible desde equipos en la red <code>192.168.1.x<\/code>. <strong>Antes de ejecutar este comando, verifica con el docente cu\u00e1l es la IP correcta.<\/strong><\/p>\n<\/blockquote>\n\n\n\n<p>Desglose del comando:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong><code>pcs resource create &lt;nombre> &lt;agente> &lt;par\u00e1metros> op monitor &lt;intervalo><\/code><\/strong> \u2014 estructura est\u00e1ndar para crear un recurso en Pacemaker.<\/li>\n\n\n\n<li><strong><code>IP-Virtual<\/code><\/strong> \u2014 nombre l\u00f3gico del recurso (descriptivo, sin espacios).<\/li>\n\n\n\n<li><strong><code>ocf:heartbeat:IPaddr2<\/code><\/strong> \u2014 el <strong>agente OCF<\/strong> (<em>Open Cluster Framework<\/em>) utilizado. Pacemaker emplea agentes OCF para controlar servicios. <code>IPaddr2<\/code> (de la colecci\u00f3n <em>heartbeat<\/em>) gestiona direcciones IP flotantes: sabe asignarla a una interfaz de red, verificar su estado y removerla. Otros ejemplos de agentes OCF incluyen <code>ocf:linbit:drbd<\/code> para replicaci\u00f3n de bloques y <code>systemd:apache2<\/code> para servidores web. <\/li>\n\n\n\n<li><strong><code>ip=192.168.1.100<\/code><\/strong> (o la IP que corresponda) \u2014 direcci\u00f3n IP flotante a gestionar. <strong><code>cidr_netmask=24<\/code><\/strong> \u2014 m\u00e1scara de subred en formato CIDR (24 equivale a 255.255.255.0). Opcionalmente, podr\u00edamos indicar la interfaz de red con <code>nic=&lt;nombre_iface><\/code> (por defecto, el agente elige una interfaz en la red de la IP dada).<\/li>\n\n\n\n<li><strong><code>op monitor interval=30s<\/code><\/strong> \u2014 Pacemaker ejecutar\u00e1 una acci\u00f3n de <strong>monitorizaci\u00f3n<\/strong> cada 30 segundos para verificar que la IP sigue asignada. Si la IP desapareciera (por error humano o fallo de interfaz), Pacemaker lo detectar\u00eda en ese intervalo e intentar\u00eda recuperarla.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5.2 Deshabilitar STONITH (solo laboratorio)<\/h3>\n\n\n\n<p><\/p>\n\n\n\n<p>pcs property set stonith-enabled=false<br><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">5.3 Habilitar y arrancar el recurso<\/h3>\n\n\n\n<p><\/p>\n\n\n\n<p>pcs resource enable IP-Virtual<\/p>\n\n\n\n<p>pcs resource start IP-Virtual<br><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">5.4 Verificar<\/h3>\n\n\n\n<p><\/p>\n\n\n\n<p>pcs status<br><\/p>\n\n\n\n<p><strong>Explicaci\u00f3n de STONITH y por qu\u00e9 se desactiva:<\/strong><\/p>\n\n\n\n<p><strong>STONITH<\/strong> (<em>Shoot The Other Node In The Head<\/em>) es el mecanismo de fencing m\u00e1s com\u00fan en cl\u00fasteres Pacemaker. Su funci\u00f3n es <strong>aislar o \u00abmatar\u00bb un nodo defectuoso<\/strong> para que no pueda interferir con los recursos del cl\u00faster, previniendo <strong>corrupci\u00f3n de datos<\/strong>. Si un nodo falla pero a\u00fan \u00abcree\u00bb estar activo, podr\u00eda continuar accediendo a recursos compartidos de forma descontrolada.<\/p>\n\n\n\n<p>Existen distintos tipos de fencing:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Power fencing:<\/strong> v\u00eda IPMI, iLO, DRAC (apaga el nodo por hardware).<\/li>\n\n\n\n<li><strong>Storage fencing:<\/strong> bloquea el acceso al almacenamiento compartido (ej. SBD).<\/li>\n\n\n\n<li><strong>Software fencing:<\/strong> detiene servicios o m\u00e1quinas virtuales.<\/li>\n<\/ul>\n\n\n\n<p><strong>\u00bfPor qu\u00e9 se desactiva en laboratorio?<\/strong> Porque no disponemos de hardware de fencing (IPMI, iLO, etc.) en un entorno acad\u00e9mico. Pacemaker, por defecto, <strong>se niega a iniciar recursos si no hay un dispositivo STONITH configurado<\/strong> \u2014 muestra la advertencia <em>\u00abNo stonith devices and stonith-enabled is not false\u00bb<\/em>. Al establecer <code>stonith-enabled=false<\/code>, silenciamos esta restricci\u00f3n y permitimos que los recursos arranquen.<\/p>\n\n\n\n<p><strong>Riesgo en producci\u00f3n:<\/strong> Desactivar STONITH elimina la \u00faltima l\u00ednea de defensa contra situaciones de <em>split-brain<\/em> (dos nodos que creen ser el activo simult\u00e1neamente). En entornos de producci\u00f3n, <strong>siempre se debe implementar un mecanismo de fencing adecuado<\/strong>. La gu\u00eda de Junta de Andaluc\u00eda lo explica como desactivar STONITH \u00abpara parar un nodo que est\u00e9 dando problemas y as\u00ed evitar un comportamiento inadecuado del cl\u00faster\u00bb.<\/p>\n\n\n\n<p><strong>Internamente (qu\u00e9 ocurre al crear el recurso):<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Pacemaker actualiza el CIB con un nuevo <em>primitive<\/em> llamado <code>IP-Virtual<\/code>. Inmediatamente eval\u00faa en qu\u00e9 nodo iniciarlo.<\/li>\n\n\n\n<li>Sin restricciones de ubicaci\u00f3n, cualquier nodo es candidato. Normalmente, Pacemaker iniciar\u00e1 el recurso en el primer nodo Online disponible (generalmente <code>nodo-a<\/code>).<\/li>\n\n\n\n<li>El agente <code>IPaddr2<\/code> ejecuta internamente:\n<ul class=\"wp-block-list\">\n<li>Agrega la IP al interfaz de red del nodo seleccionado mediante herramientas del sistema (ej. <code>ip addr add<\/code>).<\/li>\n\n\n\n<li>Publica un mensaje <strong>ARP gratuito<\/strong> (<em>gratuitous ARP<\/em>) para que los switches\/routers actualicen sus tablas (la MAC de la IP .100 ahora es la de nodo-a).<\/li>\n\n\n\n<li>Cada 30 segundos, verifica que la IP sigue presente en la interfaz.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>Pacemaker marca el recurso como <strong>Started<\/strong> en el nodo correspondiente.<\/li>\n<\/ul>\n\n\n\n<p><strong>Verificaci\u00f3n:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>pcs status<\/code> debe mostrar: <code>Full list of resources: IP-Virtual (ocf::heartbeat:IPaddr2): Started nodo-a<\/code> Si en lugar de \u00abStarted\u00bb aparece \u00abStopped\u00bb o \u00abFailed\u00bb, revisa los errores comunes.<\/li>\n\n\n\n<li><code>pcs resource status<\/code> muestra el estado del recurso de forma m\u00e1s concisa.<\/li>\n\n\n\n<li>Comprobar en <code>nodo-a<\/code> que la IP est\u00e1 asignada: <code>ip addr show<\/code> \u2192 debe listar <code>192.168.1.100<\/code> (o la IP configurada) como direcci\u00f3n secundaria en la interfaz de red. Ej.: <code>ip addr | grep 192.168.1.100<\/code> debe devolver una l\u00ednea con la IP.<\/li>\n\n\n\n<li>Desde un tercer equipo o desde nodo-b: <code>ping -c 3 192.168.1.100<\/code> \u2192 debe responder.<\/li>\n<\/ul>\n\n\n\n<p><strong>Errores comunes:<\/strong><\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><th>Problema<\/th><th>S\u00edntoma \/ Mensaje<\/th><th>Soluci\u00f3n<\/th><\/tr><tr><th><strong>IP en subred incorrecta<\/strong><\/th><td>El recurso se marca <em>Started<\/em> pero no responde al ping desde la red de los nodos.<\/td><td>Verificar que la IP del recurso est\u00e9 en la <strong>misma subred<\/strong> que las IPs de los nodos (192.168.1.x). Si se us\u00f3 192.168.100.100 por error, recrear el recurso con la IP correcta.<\/td><\/tr><tr><th><strong>IP duplicada en la red<\/strong><\/th><td>Conflicto de ARP: otra m\u00e1quina ya tiene esa IP.<\/td><td>Elegir una IP libre, no asignada a ning\u00fan equipo de la red. Verificar con <code>arping -D &lt;IP&gt;<\/code>.<\/td><\/tr><tr><th><strong>STONITH no deshabilitado<\/strong><\/th><td>Recurso <em>Stopped<\/em> con warning de fencing.<\/td><td>Ejecutar <code>pcs property set stonith-enabled=false<\/code> <strong>antes<\/strong> de crear\/arrancar recursos. Verificar con <code>pcs property list<\/code>.<\/td><\/tr><tr><th><strong>NIC incorrecta<\/strong><\/th><td>El recurso falla si no encuentra una interfaz adecuada en la red de la IP.<\/td><td>Especificar <code>nic=&lt;nombre_iface&gt;<\/code> al crear el recurso (ej. <code>nic=ens33<\/code>).<\/td><\/tr><tr><th><strong>Recurso en nodo-b en vez de nodo-a<\/strong><\/th><td>No es un error; Pacemaker decidi\u00f3 libremente.<\/td><td>Es v\u00e1lido. Para forzar la ubicaci\u00f3n inicial, se puede crear una restricci\u00f3n de ubicaci\u00f3n preferencial con <code>pcs constraint location<\/code>.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Paso 6: Verificar el Funcionamiento en Nodo Activo<\/h2>\n\n\n\n<p>Con el cl\u00faster completamente operativo, confirmamos que todo funciona correctamente antes de proceder a la prueba de failover.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6.1 Estado global del cl\u00faster<\/h3>\n\n\n\n<p>Ejecutar <code>pcs status<\/code>. Se espera:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cluster name:<\/strong> laboratorio-ha.<\/li>\n\n\n\n<li><strong>Nodes:<\/strong> <code>nodo-a<\/code> <em>Online<\/em>, <code>nodo-b<\/code> <em>Online<\/em>.<\/li>\n\n\n\n<li><strong>Resources:<\/strong> <code>IP-Virtual (ocf::heartbeat:IPaddr2)<\/code> corriendo en <code>nodo-a<\/code>.<\/li>\n\n\n\n<li>Sin <em>warnings<\/em> activos (STONITH ya desactivado).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.2 Comprobar IP en el nodo activo<\/h3>\n\n\n\n<p>En <code>nodo-a<\/code>:<\/p>\n\n\n\n<p><\/p>\n\n\n\n<p>ip addr | grep 192.168.1.100<br><\/p>\n\n\n\n<p>Deber\u00eda mostrar la IP asociada a la interfaz de red como direcci\u00f3n secundaria. Ejemplo:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>inet 192.168.1.100\/24 scope global secondary eth0\n<\/code><\/pre>\n\n\n\n<p>Esto confirma que el agente <code>IPaddr2<\/code> asign\u00f3 exitosamente la VIP al nodo activo.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6.3 Prueba de conectividad desde otro equipo<\/h3>\n\n\n\n<p>Desde un equipo externo en la misma red o desde nodo-b:<\/p>\n\n\n\n<p><\/p>\n\n\n\n<p>ping 192.168.1.100<br><\/p>\n\n\n\n<p>La VIP debe responder. Resulta especialmente \u00fatil iniciar un <strong>ping continuo<\/strong> (<code>ping -t<\/code> en Windows o <code>ping<\/code> sin <code>-c<\/code> en Linux) para medir la interrupci\u00f3n exacta durante el failover del siguiente paso.<\/p>\n\n\n\n<p><strong>Estado esperado:<\/strong> El VIP est\u00e1 atendido por <code>nodo-a<\/code>. Los clientes usan 192.168.1.100 para acceder al servicio. <code>nodo-b<\/code> est\u00e1 en espera (<em>standby<\/em>), con Pacemaker ejecut\u00e1ndose pero sin recursos asignados.<\/p>\n\n\n\n<p><strong>Problemas potenciales:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Si el ping <strong>no responde<\/strong> pero <code>pcs status<\/code> muestra el recurso <em>Started<\/em>: verificar que los nodos y el equipo de prueba est\u00e1n en la misma subred, y que no hay firewalls bloqueando ICMP.<\/li>\n\n\n\n<li>Si <strong>ambos<\/strong> nodos mostraran la IP simult\u00e1neamente, significar\u00eda un error grave de configuraci\u00f3n (esto <strong>no deber\u00eda ocurrir<\/strong>, ya que Pacemaker nunca iniciar\u00e1 el mismo recurso en dos nodos a la vez en modo single-instance).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Paso 7: Prueba de <strong>Failover<\/strong> \u2013 Simulaci\u00f3n de Ca\u00edda del Nodo A<\/h2>\n\n\n\n<p>La prueba clave de la pr\u00e1ctica: verificamos que la alta disponibilidad funciona en la pr\u00e1ctica.<\/p>\n\n\n\n<p><strong>Qu\u00e9 se hace:<\/strong> Apagamos el nodo activo y observamos la transferencia autom\u00e1tica del recurso al nodo secundario.<\/p>\n\n\n\n<p>En <strong>nodo-a<\/strong>:<\/p>\n\n\n\n<p><\/p>\n\n\n\n<p>shutdown -h now<br><\/p>\n\n\n\n<p>Esto simula un <strong>fallo catastr\u00f3fico<\/strong> del nodo principal. Alternativamente, se puede apagar directamente la m\u00e1quina virtual (Power off) para emular una ca\u00edda abrupta.<\/p>\n\n\n\n<p><strong>Qu\u00e9 ocurre internamente durante el failover:<\/strong><\/p>\n\n\n\n<p>El proceso sigue la secuencia de detecci\u00f3n-decisi\u00f3n-acci\u00f3n que define la interacci\u00f3n entre Corosync y Pacemaker:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Detecci\u00f3n del fallo (Corosync):<\/strong> Corosync en <code>nodo-b<\/code> detecta que dej\u00f3 de recibir mensajes de heartbeat de <code>nodo-a<\/code>. Tras el <em>token timeout<\/em> configurado, declara a <code>nodo-a<\/code> como offline en el cl\u00faster. Corosync configura y gestiona la comunicaci\u00f3n entre los nodos del cl\u00faster y detecta cu\u00e1ndo un nodo falla.<\/li>\n\n\n\n<li><strong>Notificaci\u00f3n a Pacemaker:<\/strong> Corosync comunica el evento de fallo a Pacemaker en <code>nodo-b<\/code>. <code>nodo-b<\/code> ahora tiene el qu\u00f3rum (modo <code>two_node: 1<\/code>).<\/li>\n\n\n\n<li><strong>Elecci\u00f3n de DC:<\/strong> Si <code>nodo-a<\/code> era el Designated Coordinator, <code>nodo-b<\/code> asume ese rol autom\u00e1ticamente.<\/li>\n\n\n\n<li><strong>Recuperaci\u00f3n del recurso:<\/strong> Pacemaker en <code>nodo-b<\/code> ve que el recurso <code>IP-Virtual<\/code> ya no est\u00e1 activo (el nodo que lo ten\u00eda ha desaparecido). Decide ejecutar la acci\u00f3n <em>start<\/em> del agente <code>IPaddr2<\/code> en <code>nodo-b<\/code> para mantener la disponibilidad del servicio. Pacemaker recibe la informaci\u00f3n de fallo de Corosync y toma decisiones sobre c\u00f3mo reubicar los recursos, ejecutando las acciones necesarias para recuperarlos en otros nodos.<\/li>\n\n\n\n<li><strong>ARP Anuncio:<\/strong> Al iniciarse la IP en <code>nodo-b<\/code>, el agente <code>IPaddr2<\/code> env\u00eda un <em>gratuitous ARP<\/em> para actualizar a los switches y routers: la IP .100 ahora corresponde a la MAC de <code>nodo-b<\/code>.<\/li>\n<\/ol>\n\n\n\n<p>Todo este proceso ocurre r\u00e1pidamente. En un ping continuo se observar\u00e1 la p\u00e9rdida de quiz\u00e1s uno o dos paquetes durante la transici\u00f3n, tras lo cual el servicio se restablece desde <code>nodo-b<\/code>.<\/p>\n\n\n\n<p><strong>Verificaci\u00f3n del failover en <code>nodo-b<\/code>:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Ejecutar <code>pcs status<\/code> en <code>nodo-b<\/code>: <code>Cluster name: laboratorio-ha ... Online: [ nodo-b ] OFFLINE: [ nodo-a ] ... IP-Virtual (ocf::heartbeat:IPaddr2): Started nodo-b<\/code> Esto indica que solo <code>nodo-b<\/code> est\u00e1 en l\u00ednea y la IP virtual est\u00e1 corriendo en \u00e9l.<\/li>\n\n\n\n<li>Comprobar la interfaz de red: Shellip addr | grep 192.168.1.100<br>Mostrar m\u00e1s l\u00edneas Debe mostrar la VIP asignada en la interfaz de <code>nodo-b<\/code>.<\/li>\n\n\n\n<li>Si se manten\u00eda un ping continuo desde un tercer equipo: Se observar\u00e1n quiz\u00e1s uno o dos paquetes sin respuesta durante la transici\u00f3n, luego el ping se reanuda normalmente. La MAC en la tabla ARP del cliente habr\u00e1 cambiado de nodo-a a nodo-b.<\/li>\n\n\n\n<li>Verificar la web o servicio (en pr\u00e1cticas posteriores con Apache): Shellcurl http:\/\/192.168.1.100<br>Mostrar m\u00e1s l\u00edneas La respuesta debe provenir ahora de <code>nodo-b<\/code>.<\/li>\n<\/ul>\n\n\n\n<p><strong>Qu\u00e9 ve el usuario final:<\/strong> El cliente final nota poca o ninguna interrupci\u00f3n. Si la VIP alojara un servidor web (que se configurar\u00e1 en la siguiente pr\u00e1ctica), quiz\u00e1s la p\u00e1gina tardar\u00eda un par de segundos extra, pero luego seguir\u00eda funcionando. <strong>El usuario no necesita cambiar la IP<\/strong>, porque sigue siendo <strong>192.168.1.100<\/strong>, independientemente de qu\u00e9 nodo la atienda.<\/p>\n\n\n\n<p><strong>Comportamiento al retornar nodo-a:<\/strong> Si se enciende de nuevo <code>nodo-a<\/code>, \u00e9ste reingresar\u00e1 al cl\u00faster (estado ONLINE), pero Pacemaker <strong>no revierte autom\u00e1ticamente<\/strong> el recurso al nodo original (para evitar vaivenes innecesarios). El recurso permanece en <code>nodo-b<\/code> a menos que se fuerce una migraci\u00f3n manual (<code>pcs resource move IP-Virtual nodo-a<\/code>). Si se desea que el recurso regrese autom\u00e1ticamente al nodo preferido tras su recuperaci\u00f3n, se puede configurar la propiedad <code>resource-stickiness<\/code> de Pacemaker.<\/p>\n\n\n\n<p><strong>Errores comunes \/ Situaciones a monitorear:<\/strong><\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><th>Problema<\/th><th>S\u00edntoma \/ Mensaje<\/th><th>Soluci\u00f3n<\/th><\/tr><tr><th><strong>El failover no ocurre<\/strong><\/th><td><code>nodo-b<\/code> no asumi\u00f3 el recurso tras apagar <code>nodo-a<\/code>.<\/td><td>Puede deberse a pol\u00edtica de qu\u00f3rum restrictiva. Verificar que en un cl\u00faster de 2 nodos, Pacemaker tiene habilitado <code>two_node: 1<\/code>. Si es necesario, ejecutar <code>pcs property set no-quorum-policy=ignore<\/code>.<\/td><\/tr><tr><th><strong>Recurso queda Stopped<\/strong><\/th><td>En <code>pcs status<\/code> de nodo-b, el recurso aparece <em>Stopped<\/em> en vez de <em>Started<\/em>.<\/td><td>Revisar logs: <code>journalctl -u pacemaker -e<\/code>. Puede haber un error del agente (ej. la interfaz de red de nodo-b no est\u00e1 en la misma subred).<\/td><\/tr><tr><th><strong>Ping no vuelve despu\u00e9s del failover<\/strong><\/th><td>P\u00e9rdida de paquetes persistente tras la migraci\u00f3n.<\/td><td>Verificar que el agente IPaddr2 gener\u00f3 el ARP gratuito. Comprobar <code>ip addr<\/code> en nodo-b. Posible problema de switch o cach\u00e9 ARP en el cliente (<code>arp -d 192.168.1.100<\/code> en el cliente para forzar actualizaci\u00f3n).<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Paso 8: An\u00e1lisis y Conclusiones para el Estudiante<\/h2>\n\n\n\n<p>Tras observar un <strong>failover exitoso<\/strong> (la IP virtual pas\u00f3 de nodo-a a nodo-b con m\u00ednima interrupci\u00f3n), es momento de analizar el comportamiento y responder preguntas clave:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Preguntas de an\u00e1lisis<\/h3>\n\n\n\n<p><strong>\u00bfQu\u00e9 servicio detect\u00f3 la falla de nodo-a y c\u00f3mo?<\/strong><em>Corosync<\/em> detect\u00f3 la ca\u00edda mediante la ausencia de mensajes de heartbeat. Al vencer el <em>token timeout<\/em> sin respuesta de nodo-a, Corosync indic\u00f3 la p\u00e9rdida del nodo en el anillo de comunicaci\u00f3n y se lo comunic\u00f3 a Pacemaker. En resumen: Corosync configura y gestiona la comunicaci\u00f3n entre los nodos del cl\u00faster, detecta cu\u00e1ndo un nodo falla y comunica este evento a Pacemaker; Pacemaker recibe la informaci\u00f3n y toma decisiones sobre c\u00f3mo reubicar los recursos.<\/p>\n\n\n\n<p><strong>\u00bfCu\u00e1nto tiempo tard\u00f3 el failover?<\/strong> Si se realiz\u00f3 un ping continuo, la cantidad de paquetes perdidos indica la duraci\u00f3n aproximada. Cada paquete ICMP perdido representa ~1 segundo (intervalo est\u00e1ndar). Un cl\u00faster bien configurado en red local logra failovers suficientemente r\u00e1pidos para que el usuario perciba, a lo sumo, una breve pausa. El tiempo exacto depende de par\u00e1metros de Corosync (token timeout) y de Pacemaker (intervalo de monitorizaci\u00f3n).<\/p>\n\n\n\n<p><strong>\u00bfPor qu\u00e9 el usuario final no necesita cambiar la IP?<\/strong> Porque se implement\u00f3 una <strong>IP virtual flotante<\/strong> que <strong>pertenece al cl\u00faster, no a un servidor fijo<\/strong>. Antes del fallo, la VIP estaba en nodo-a; despu\u00e9s, en nodo-b, pero sigue siendo la misma direcci\u00f3n. Los mecanismos de red (ARP) y Pacemaker redirigieron autom\u00e1ticamente esa IP al nodo sobreviviente. Para el cliente, la direcci\u00f3n nunca cambi\u00f3.<\/p>\n\n\n\n<p><strong>\u00bfQu\u00e9 pasar\u00eda si ambos nodos fallan?<\/strong> La alta disponibilidad protege contra <strong>fallos individuales<\/strong>, no contra la ca\u00edda total del cl\u00faster. Si ambos nodos fallan, no hay ning\u00fan equipo para mantener la IP virtual ni los servicios \u2014 se produce una <strong>interrupci\u00f3n completa<\/strong> hasta que al menos un nodo se recupere. Este escenario requiere planificaci\u00f3n de disaster recovery a nivel geogr\u00e1fico, que es una tem\u00e1tica diferente. En nuestro cl\u00faster de 2 nodos, no hay tolerancia a la ca\u00edda simult\u00e1nea de ambos.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Evidencias solicitadas<\/h3>\n\n\n\n<p>Para documentar la pr\u00e1ctica, se solicitan capturas de:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Salida de <code>pcs status<\/code><\/strong> \u2014 antes y despu\u00e9s del failover: ambos nodos online con el recurso en nodo-a inicialmente, luego nodo-a OFFLINE con el recurso en nodo-b.<\/li>\n\n\n\n<li><strong>IP virtual en nodo-b<\/strong> \u2014 resultado de <code>ip addr<\/code> en nodo-b tras el failover, donde se vea la VIP asignada.<\/li>\n\n\n\n<li><strong>Ping continuo durante el failover<\/strong> \u2014 captura que evidencie que el ping a la VIP se mantuvo y quiz\u00e1s perdi\u00f3 solo uno o dos paquetes durante la transici\u00f3n.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Extensiones (para profundizar)<\/h3>\n\n\n\n<p>Para alumnos avanzados o para continuar la pr\u00e1ctica:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Agregar Apache o Nginx como recurso:<\/strong> Configurar un servidor web gestionado por Pacemaker, vincul\u00e1ndolo a la VIP con restricciones de orden y colocaci\u00f3n. En general, el recurso gestionado por el cl\u00faster <strong>nunca debe ser iniciado\/reiniciado por nada que no sea Pacemaker<\/strong>. Esto implica deshabilitar el servicio en systemd (<code>systemctl disable apache2<\/code>) y dejar que Pacemaker controle su ciclo de vida.<\/li>\n\n\n\n<li><strong>Implementar STONITH:<\/strong> Configurar un dispositivo de fencing real (ej. <code>fence_xvm<\/code> para libvirt, <code>fence_ipmilan<\/code> para IPMI) para ver c\u00f3mo act\u00faa el cl\u00faster al aislar autom\u00e1ticamente un nodo fallido. Comparar el comportamiento con y sin fencing.<\/li>\n\n\n\n<li><strong>Simular p\u00e9rdida de red:<\/strong> Desconectar la interfaz de nodo-a (en vez de apagarlo) para observar c\u00f3mo el cl\u00faster interpreta un nodo inaccesible. Luego reconectar y ver la reintegraci\u00f3n.<\/li>\n\n\n\n<li><strong>Pruebas de quorum en 3+ nodos:<\/strong> Si es posible, agregar un tercer nodo para observar c\u00f3mo Pacemaker maneja el qu\u00f3rum con mayor\u00edas en vez del modo <code>two_node<\/code>.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Tabla Resumen: Comando \u2192 Funci\u00f3n \u2192 Verificaci\u00f3n \u2192 Error Frecuente<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><th><strong>Paso<\/strong><\/th><th><strong>Comando(s)<\/strong><\/th><th><strong>Qu\u00e9 hace<\/strong><\/th><th><strong>Verificaci\u00f3n<\/strong><\/th><th><strong>Error frecuente<\/strong><\/th><\/tr><tr><td>1<\/td><td><code>hostnamectl set-hostname nodo-a\/b<\/code><\/td><td>Establece el hostname del SO para que coincida con la config del cl\u00faster<\/td><td><code>hostname<\/code> o <code>uname -n<\/code> muestra el nombre correcto<\/td><td>Hostname no coincide con la configuraci\u00f3n del cl\u00faster<\/td><\/tr><tr><td>1<\/td><td><code>nano \/etc\/hosts<\/code> (a\u00f1adir entradas)<\/td><td>Habilita resoluci\u00f3n de nombres entre nodos<\/td><td><code>ping nodo-b<\/code> desde nodo-a (y viceversa) responde<\/td><td>Entrada incorrecta o duplicada en <code>\/etc\/hosts<\/code><\/td><\/tr><tr><td>1<\/td><td><code>apt update &amp;&amp; apt upgrade -y<\/code><\/td><td>Actualiza paquetes del sistema<\/td><td>Sin errores en la salida de apt<\/td><td>Repositorios mal configurados<\/td><\/tr><tr><td>2<\/td><td><code>apt install -y pacemaker corosync pcs<\/code><\/td><td>Instala el stack de HA completo<\/td><td><code>pcs --version<\/code> muestra versi\u00f3n<\/td><td>Paquetes no encontrados en los repos<\/td><\/tr><tr><td>2<\/td><td><code>systemctl enable\/start pcsd<\/code><\/td><td>Activa el demonio PCS para administraci\u00f3n remota<\/td><td><code>systemctl status pcsd<\/code> \u2192 <em>active (running)<\/em><\/td><td><code>pcsd<\/code> no arrancado \u2192 error de conexi\u00f3n en pasos posteriores<\/td><\/tr><tr><td>3<\/td><td><code>passwd hacluster<\/code> (en ambos)<\/td><td>Asigna credenciales al usuario de gesti\u00f3n del cl\u00faster<\/td><td>Contrase\u00f1a aceptada sin error<\/td><td>Contrase\u00f1a distinta en cada nodo<\/td><\/tr><tr><td>3<\/td><td><code>pcs host auth nodo-a nodo-b<\/code><\/td><td>Establece confianza mutua entre nodos<\/td><td><em>\u00abAuthorized\u00bb<\/em> para cada nodo<\/td><td>Hostname no resoluble o <code>pcsd<\/code> no activo<\/td><\/tr><tr><td>4<\/td><td><code>pcs cluster setup laboratorio-ha nodo-a nodo-b<\/code><\/td><td>Crea la configuraci\u00f3n del cl\u00faster y la distribuye<\/td><td>Archivos de config distribuidos exitosamente<\/td><td>Auth no completada previamente<\/td><\/tr><tr><td>4<\/td><td><code>pcs cluster start --all<\/code><\/td><td>Inicia Corosync y Pacemaker en todos los nodos<\/td><td><code>pcs status<\/code> \u2192 nodos Online<\/td><td>Firewall bloquea puertos UDP 5404\/5405<\/td><\/tr><tr><td>4<\/td><td><code>pcs cluster enable --all<\/code><\/td><td>Habilita arranque autom\u00e1tico tras reboot<\/td><td><code>pcs status<\/code> persiste tras reinicio<\/td><td>Olvidar este paso \u2192 cl\u00faster no arranca tras reboot<\/td><\/tr><tr><td>5<\/td><td><code>pcs property set stonith-enabled=false<\/code><\/td><td>Desactiva fencing (solo laboratorio)<\/td><td><code>pcs property list<\/code> \u2192 <code>stonith-enabled: false<\/code><\/td><td>No desactivar \u2192 recursos no inician<\/td><\/tr><tr><td>5<\/td><td><code>pcs resource create IP-Virtual ...<\/code><\/td><td>Crea recurso de IP flotante con agente IPaddr2<\/td><td><code>pcs status<\/code> \u2192 <code>IP-Virtual: Started nodo-a<\/code><\/td><td>IP en subred incorrecta \/ IP duplicada en la red<\/td><\/tr><tr><td>6<\/td><td><code>ip addr | grep 192.168.1.100<\/code><\/td><td>Confirma que la VIP est\u00e1 asignada en el nodo activo<\/td><td>L\u00ednea con <code>inet 192.168.1.100\/24<\/code> visible<\/td><td>IP no aparece \u2192 recurso no iniciado correctamente<\/td><\/tr><tr><td>6<\/td><td><code>ping 192.168.1.100<\/code><\/td><td>Prueba de conectividad externa<\/td><td>Respuestas ICMP recibidas<\/td><td>Firewall bloquea ICMP o subred incorrecta<\/td><\/tr><tr><td>7<\/td><td><code>shutdown -h now<\/code> (en nodo-a)<\/td><td>Simula fallo del nodo principal<\/td><td>En nodo-b: <code>pcs status<\/code> \u2192 <code>IP-Virtual: Started nodo-b<\/code><\/td><td>Failover no ocurre \u2192 problema de qu\u00f3rum<\/td><\/tr><tr><td>7<\/td><td><code>ip addr | grep 192.168.1.100<\/code> (nodo-b)<\/td><td>Confirma migraci\u00f3n de la VIP a nodo-b<\/td><td>VIP visible en interfaz de nodo-b<\/td><td>VIP no migr\u00f3 \u2192 revisar logs de Pacemaker<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"822\" src=\"https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/image-2-1024x822.png\" alt=\"\" class=\"wp-image-2381\" srcset=\"https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/image-2-1024x822.png 1024w, https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/image-2-300x241.png 300w, https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/image-2-768x617.png 768w, https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/image-2-1536x1234.png 1536w, https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/image-2-2048x1645.png 2048w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n","protected":false},"excerpt":{"rendered":"<p>Descripci\u00f3n general: En esta pr\u00e1ctica crearemos un cl\u00faster de alta disponibilidad (HA) de dos nodos en modo activo\/pasivo usando Pacemaker (gestor de recursos de cl\u00faster) y Corosync (servicio de comunicaci\u00f3n entre nodos) sobre Debian 13. El objetivo es que un recurso (una direcci\u00f3n IP virtual) est\u00e9 siempre disponible: si el Nodo A falla, el Nodo B tomar\u00e1 autom\u00e1ticamente el control, minimizando la interrupci\u00f3n del servicio (failover). Configuraremos la IP virtual 192.168.1.100 que \u00abflotar\u00e1\u00bb entre los nodos, de modo que los clientes se conecten siempre a esa direcci\u00f3n sin importar qu\u00e9 servidor f\u00edsico la est\u00e9 atendiendo. Se trata de configurar un cl\u00faster de alta disponibilidad activo\/pasivo en el que uno de los dos equipos pueda responder siempre a la direcci\u00f3n IP que se pretende mantener en alta disponibilidad. Escenario del laboratorio: Elemento Nodo A Nodo B Hostname nodo-a nodo-b IP fija 192.168.1.10 192.168.1.11 IP virtual (VIP) 192.168.1.100 (la asume cuando A falla) SO Debian 13 m\u00ednimo Debian 13 m\u00ednimo Conceptos clave: Antes de empezar, repasemos los t\u00e9rminos esenciales que se usan a lo largo de la pr\u00e1ctica: A continuaci\u00f3n se detalla paso a paso la configuraci\u00f3n, explicando qu\u00e9 hace cada comando, por qu\u00e9 es necesario y qu\u00e9 ocurre internamente en el cl\u00faster. Cada paso incluye verificaciones, posibles errores comunes y c\u00f3mo identificarlos. Al final se proponen preguntas de an\u00e1lisis y criterios de evaluaci\u00f3n. Paso 1: Preparaci\u00f3n de los Nodos (hostname, \/etc\/hosts, actualizaci\u00f3n) Qu\u00e9 se hace: En cada servidor asignamos nombres de host descriptivos, aseguramos la resoluci\u00f3n de nombres entre ellos y actualizamos el sistema operativo. 1.1 Cambiar el hostname En Nodo A: hostnamectl set-hostname nodo-a En Nodo B: hostnamectl set-hostname nodo-b Esto define el nombre de m\u00e1quina a nivel del sistema (reflejado en uname -n y hostname). Los nombres de host deben coincidir exactamente con los que usaremos en la configuraci\u00f3n del cl\u00faster. Pacemaker y Corosync no usan el prompt de la terminal ni apodos; identifican los nodos por su hostname real del SO. Si hay discrepancia (por ejemplo, el hostname del sistema es debian-01 pero en la configuraci\u00f3n del cl\u00faster se escribe nodo-a), el cl\u00faster no reconocer\u00e1 correctamente a los nodos, provocando errores de autenticaci\u00f3n y conectividad. En un entorno de cl\u00faster, para cambiar el nombre de una m\u00e1quina se puede ejecutar hostnamectl set-hostname nombre_nuevo. [blogsaverr&#8230;dalucia.es] 1.2 Editar \/etc\/hosts En ambos nodos, abrir \/etc\/hosts: nano \/etc\/hosts Y a\u00f1adir las siguientes entradas: De esta manera, cada nodo puede resolver el nombre del otro por IP. Esto es fundamental porque pcs y Corosync utilizar\u00e1n los nombres (nodo-a, nodo-b) para establecer la comunicaci\u00f3n. Sin resoluci\u00f3n correcta, los comandos de autenticaci\u00f3n o arranque de cl\u00faster fallar\u00e1n al no poder encontrar el host destino. El blog de maquinasvirtuales.eu muestra un ejemplo de \/etc\/hosts configurado para un cl\u00faster Pacemaker, donde cada nodo tiene su IP y nombre mapeados correctamente. 1.3 Actualizar el sistema En ambos nodos: apt update &amp;&amp; apt upgrade -y Mantener Debian actualizado garantiza versiones compatibles de Pacemaker, Corosync y PCS. Tras una actualizaci\u00f3n que incluya kernel nuevo, es recomendable reiniciar los nodos antes de continuar. Verificaci\u00f3n: Errores comunes: Problema S\u00edntoma \/ Mensaje Soluci\u00f3n Hostname no cambiado pcs indica \u00abno configuration for host X\u00bb o el nombre no aparece en pcs status. Verificar con uname -n. Si no coincide, reejecutar hostnamectl set-hostname y reiniciar la sesi\u00f3n. Resoluci\u00f3n de nombres fallida pcs host auth se cuelga o muestra error de conexi\u00f3n\/refused hacia nodo-b. Verificar las entradas en \/etc\/hosts de ambos nodos. Probar ping nodo-b desde nodo-a. Firewall bloquea puertos de cl\u00faster Un nodo aparece OFFLINE en pcs status tras configurar el cl\u00faster. Asegurar que el firewall permite tr\u00e1fico UDP 5404\/5405 (puertos est\u00e1ndar de Corosync). En laboratorio, ufw disable o abrir reglas espec\u00edficas. Paso 2: Instalaci\u00f3n del Stack de Cl\u00faster (Pacemaker, Corosync, PCS) Qu\u00e9 se hace: Se instalan en ambos nodos los tres componentes del stack de HA: apt install -y pacemaker corosync pcs Este comando instala: [linuxmind.dev] Tras la instalaci\u00f3n, habilitamos y arrancamos PCSD en cada nodo: systemctl enable pcsd systemctl start pcsd pcsd escucha en cada nodo y permite que, al autenticarse, podamos ejecutar comandos de configuraci\u00f3n del cl\u00faster en todos los nodos desde uno solo. Por qu\u00e9 se hace: Pacemaker y Corosync forman el motor del cl\u00faster HA. Sin Pacemaker no habr\u00eda orquestaci\u00f3n de recursos; sin Corosync no habr\u00eda detecci\u00f3n de fallos entre nodos. La herramienta pcs simplifica enormemente la configuraci\u00f3n, evitando la edici\u00f3n manual de archivos XML o configuraci\u00f3n de Corosync; adem\u00e1s, distribuye autom\u00e1ticamente las claves de autenticaci\u00f3n a todos los nodos. Habilitar pcsd lo hace persistente tras reinicios. Internamente: Componentes internos de Pacemaker que conviene conocer: Verificaci\u00f3n: Errores comunes: Problema S\u00edntoma \/ Mensaje Soluci\u00f3n Repositorios faltantes apt no encuentra paquetes pacemaker o pcs. Asegurarse de tener los repositorios de Debian 13 correctos en \/etc\/apt\/sources.list. Permisos insuficientes Error de permisos al instalar. Ejecutar como root o con sudo. pcsd no habilitado Al intentar autenticaci\u00f3n, pcs responde \u00abError: unable to connect to node&#8230;\u00bb. Verificar que pcsd est\u00e1 activo en ambos nodos (systemctl status pcsd). Iniciar\/habilitar si es necesario. Versiones distintas entre nodos Errores de protocolo o incompatibilidad durante la autenticaci\u00f3n. Usar la misma versi\u00f3n de paquetes en ambos nodos (mismo SO y actualizaciones). Paso 3: Autenticaci\u00f3n del Cl\u00faster (usuario hacluster y pcs host auth) Qu\u00e9 se hace: Para que pcs pueda controlar ambos nodos de forma remota, se usa un usuario dedicado llamado hacluster (creado autom\u00e1ticamente al instalar pcs). Se realizan dos tareas: 3.1 Asignar contrase\u00f1a al usuario hacluster En cada nodo (ambos): passwd hacluster Elegir una contrase\u00f1a (se recomienda la misma en ambos para simplificar el proceso de autenticaci\u00f3n). Este usuario es el que pcs utiliza internamente para autenticarse contra los nodos del cl\u00faster. 3.2 Autenticaci\u00f3n entre nodos Desde nodo-a: pcs host auth nodo-a nodo-b Este comando establece la confianza mutua entre nodo-a y nodo-b. pcs solicita las credenciales del usuario hacluster y las usa para crear una relaci\u00f3n de confianza segura entre ambos nodos. Si pide confirmaci\u00f3n de huella digital (fingerprint), aceptar con \u00abyes\u00bb. Por qu\u00e9 se hace: Sin autenticaci\u00f3n, pcs solo puede administrar el nodo local. Este paso habilita<\/p>\n","protected":false},"author":1,"featured_media":2383,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[134,16,5,12,1,10,6],"tags":[],"class_list":["post-2378","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-clusters","category-debian","category-docencia","category-linux","category-sin-categoria","category-sistemas-operativos","category-talleres"],"_links":{"self":[{"href":"https:\/\/dsantana.uas.edu.mx\/index.php\/wp-json\/wp\/v2\/posts\/2378","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dsantana.uas.edu.mx\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dsantana.uas.edu.mx\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dsantana.uas.edu.mx\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dsantana.uas.edu.mx\/index.php\/wp-json\/wp\/v2\/comments?post=2378"}],"version-history":[{"count":2,"href":"https:\/\/dsantana.uas.edu.mx\/index.php\/wp-json\/wp\/v2\/posts\/2378\/revisions"}],"predecessor-version":[{"id":2384,"href":"https:\/\/dsantana.uas.edu.mx\/index.php\/wp-json\/wp\/v2\/posts\/2378\/revisions\/2384"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/dsantana.uas.edu.mx\/index.php\/wp-json\/wp\/v2\/media\/2383"}],"wp:attachment":[{"href":"https:\/\/dsantana.uas.edu.mx\/index.php\/wp-json\/wp\/v2\/media?parent=2378"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dsantana.uas.edu.mx\/index.php\/wp-json\/wp\/v2\/categories?post=2378"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dsantana.uas.edu.mx\/index.php\/wp-json\/wp\/v2\/tags?post=2378"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}