Alta disponibilidad con nodos de aplicación

Cómo funciona

La alta disponibilidad permite que la producción de una base de datos Odoo se ejecute en varios servidores a la vez. Si un servidor deja de responder, los visitantes se envían a los demás.

Un clúster está formado por proyectos que ejecutan el mismo código:

• El principal: un proyecto cuya instancia de producción ejecuta Odoo y la base de datos. Su base de datos se abre a los nodos de aplicación, y a nadie más.
• Nodos de aplicación: otros proyectos, cada uno en un servidor de producción distinto, cuya instancia de producción solo ejecuta Odoo y usa la base de datos del principal.

Los visitantes usan la dirección del principal. CICDoo apunta esa dirección al principal y a cada nodo de aplicación que responde, y comprueba cada nodo cada pocos minutos. Un nodo que deja de responder se retira de la dirección hasta que se recupera.

La base de datos en sí sigue ejecutándose en un solo servidor, el del principal. Los nodos de aplicación hacen redundante la parte de Odoo; si el servidor del principal cae, el sitio cae con él.

Antes de empezar

• Mismo código: todos los proyectos de un clúster deben usar el mismo repositorio, la misma rama predeterminada, la misma versión de Odoo y la misma edición. Si Time Machine está activado, los commits fijados también deben coincidir.
• Servidores distintos: cada nodo de aplicación debe tener su propio servidor de producción, distinto del del principal y del de los demás nodos.
• Proxy de Cloudflare: repartir el tráfico entre los nodos funciona actualmente con servidores que tienen activado el proxy de Cloudflare. Usa servidores de la misma región, ya que cada página que sirve un nodo de aplicación se comunica con la base de datos del principal.
• Filestore compartido: cada servidor del clúster debe montar el mismo almacenamiento compartido para el filestore de Odoo. Sin él, un adjunto subido a través de un nodo falta en los demás, y un visitante que llega a otro nodo pierde la sesión. Pide ayuda al soporte si la necesitas para configurarlo.
• Conexiones a la base de datos: cada nodo de aplicación abre sus propias conexiones a la base de datos del principal. A medida que añades nodos, aumenta max_connections en la Configuración de PostgreSQL de la instancia de producción del principal, en la pestaña Ajustes de su consola.

Los ajustes de alta disponibilidad están en Ajustes del proyecto, en la pestaña Avanzado, en la tarjeta Alta disponibilidad. Necesitas permiso para cambiar los ajustes del proyecto.

Configurar el principal

Abre el proyecto que ejecutará la base de datos, ve a Ajustes del proyecto > Avanzado y, en Alta disponibilidad, establece Rol en Principal (aplicación + base de datos). Haz clic en Aplicar y confirma.

La instancia de producción se reinicia. Cuando vuelve, su base de datos acepta conexiones de los nodos de aplicación del clúster. Las conexiones entre servidores van cifradas, salvo que tus servidores compartan una red privada.

La instancia de producción debe usar su propia base de datos incluida. Un proyecto cuya instancia de producción apunta a una base de datos externa no puede ser principal.

Añadir un nodo de aplicación

Crea un proyecto para el nodo como lo harías normalmente: mismo repositorio y misma rama predeterminada, misma versión y edición, y un servidor de producción propio. Elimina las instancias de staging y de desarrollo que tenga: un nodo de aplicación solo ejecuta producción, y las ramas de staging y de desarrollo viven en el proyecto principal.

Después abre los Ajustes del proyecto > Avanzado del nodo, establece Rol en Nodo de aplicación (usa la base de datos de un principal), elige el principal en Origen de la base de datos, haz clic en Aplicar y confirma. Solo se ofrecen principales del mismo espacio de trabajo que ejecutan el mismo código.

El nodo no arranca de inmediato. Primero el servidor del principal tiene que dejarlo entrar, lo que ocurre en su siguiente comprobación, normalmente en cinco minutos. Hasta entonces la tarjeta muestra "Esperando a que el principal permita este nodo", y el nodo arranca por sí solo en cuanto se le permite. Unos minutos después de que responda, empieza a recibir visitantes.

En el principal, la tarjeta Alta disponibilidad lista sus nodos de aplicación y si el servidor de la base de datos ha aplicado la lista de acceso actual.

Qué cambia en un nodo de aplicación

• Su instancia de producción no tiene base de datos propia. Los ajustes de su base de datos los gestiona CICDoo y no se pueden cambiar en la configuración de Odoo de la instancia.
• Las tareas programadas (crons de Odoo) solo se ejecutan en el principal.
• Las copias de seguridad se hacen en el principal. Haz copias de seguridad y restaura la base de datos del clúster desde el proyecto principal.
• Hacer push a la rama de un nodo de aplicación no hace nada por sí solo. El clúster se actualiza desde el principal.

Desplegar actualizaciones

Haz push a la rama del principal como siempre. CICDoo actualiza entonces todo el clúster en orden:

1. Se detiene cada nodo de aplicación.
2. Se actualiza el principal, incluida cualquier actualización de módulos, mientras ningún otro servidor usa la base de datos.
3. Se vuelve a iniciar cada nodo de aplicación con el código nuevo.

Puedes seguir cada paso en la pestaña Cola de la instancia en la que se ejecuta. Si la actualización del principal falla, los nodos de aplicación no se vuelven a iniciar, y sus entradas de la cola indican el motivo. Corrige el problema y vuelve a desplegar.

Como las actualizaciones de módulos necesitan la base de datos en exclusiva, el sitio no está disponible mientras se actualiza el principal, igual que con una sola instancia.

Salir de un clúster

Para retirar un nodo de aplicación, vuelve a establecer su Rol en Independiente (base de datos propia) y haz clic en Aplicar. Su instancia de producción se detiene, porque su propia base de datos no contiene los datos del clúster. Restaura una copia de seguridad en ella antes de volver a iniciarla.

Un principal no se puede cambiar mientras todavía tenga nodos de aplicación. Retira primero los nodos.

Solución de problemas

• El nodo sigue esperando a que se le permita: comprueba que la instancia de producción del principal está en ejecución y que su servidor está en línea. El principal tiene que reiniciarse una vez después de convertirse en principal antes de que se permita ningún nodo.
• El nodo arranca pero Odoo no se levanta: abre los registros del nodo. Un mensaje que dice que la base de datos del principal no está inicializada significa que el principal no ha terminado su primer arranque.
• Las subidas o las sesiones no siguen a los visitantes entre nodos: los servidores no comparten el filestore. Consulta "Antes de empezar" más arriba.

Consulta Ramas e instancias para ver cómo se corresponden las instancias con las ramas, y Usar un balanceador de carga para el ajuste de balanceador de carga a nivel de servidor, que es una función distinta.