Haute disponibilité avec des nœuds applicatifs

Fonctionnement

La haute disponibilité permet à la production d'une base de données Odoo de tourner sur plusieurs serveurs à la fois. Si un serveur cesse de répondre, les visiteurs sont envoyés vers les autres.

Un cluster est composé de projets qui exécutent le même code :

• Le principal : un projet dont l'instance de production exécute Odoo et la base de données. Sa base de données est ouverte aux nœuds applicatifs, et à personne d'autre.
• Nœuds applicatifs : d'autres projets, chacun sur un serveur de production différent, dont l'instance de production n'exécute que Odoo et utilise la base de données du principal.

Les visiteurs utilisent l'adresse du principal. CICDoo fait pointer cette adresse vers le principal et vers chaque nœud applicatif qui répond, et vérifie chaque nœud toutes les quelques minutes. Un nœud qui cesse de répondre est retiré de l'adresse jusqu'à ce qu'il se rétablisse.

La base de données elle-même tourne toujours sur un seul serveur, celui du principal. Les nœuds applicatifs rendent la partie Odoo redondante ; si le serveur du principal tombe, le site tombe avec lui.

Avant de commencer

• Même code : tous les projets d'un cluster doivent utiliser le même dépôt, la même branche par défaut, la même version d'Odoo et la même édition. Si Time Machine est activé, les commits épinglés doivent aussi correspondre.
• Serveurs différents : chaque nœud applicatif doit avoir son propre serveur de production, différent de celui du principal et de ceux des autres nœuds.
• Proxy Cloudflare : la répartition du trafic entre les nœuds fonctionne actuellement pour les serveurs dont le proxy Cloudflare est activé. Utilisez des serveurs de la même région, car chaque page servie par un nœud applicatif communique avec la base de données du principal.
• Filestore partagé : chaque serveur du cluster doit monter le même stockage partagé pour le filestore d'Odoo. Sans lui, une pièce jointe envoyée via un nœud manque sur les autres, et un visiteur qui arrive sur un autre nœud est déconnecté. Demandez au support si vous avez besoin d'aide pour le mettre en place.
• Connexions à la base de données : chaque nœud applicatif ouvre ses propres connexions à la base de données du principal. À mesure que vous ajoutez des nœuds, augmentez max_connections dans la Configuration PostgreSQL de l'instance de production du principal, dans l'onglet Paramètres de sa console.

Les réglages de haute disponibilité se trouvent dans Paramètres du projet, sur l'onglet Avancé, dans la carte Haute disponibilité. Vous avez besoin de la permission de modifier les paramètres du projet.

Configurer le principal

Ouvrez le projet qui exécutera la base de données, allez dans Paramètres du projet > Avancé et, dans Haute disponibilité, réglez Rôle sur Principal (application + base de données). Cliquez sur Appliquer et confirmez.

L'instance de production redémarre. À son retour, sa base de données accepte les connexions des nœuds applicatifs du cluster. Les connexions entre serveurs sont chiffrées, sauf si vos serveurs partagent un réseau privé.

L'instance de production doit utiliser sa propre base de données intégrée. Un projet dont l'instance de production pointe vers une base de données externe ne peut pas être principal.

Ajouter un nœud applicatif

Créez un projet pour le nœud comme d'habitude : même dépôt et même branche par défaut, même version et même édition, et un serveur de production qui lui est propre. Supprimez ses éventuelles instances de préproduction et de développement : un nœud applicatif n'exécute que la production, et les branches de préproduction et de développement vivent sur le projet principal.

Ouvrez ensuite Paramètres du projet > Avancé du nœud, réglez Rôle sur Nœud applicatif (utilise la base d'un principal), choisissez le principal dans Source de la base de données, cliquez sur Appliquer et confirmez. Seuls les principaux du même espace de travail qui exécutent le même code sont proposés.

Le nœud ne démarre pas tout de suite. Le serveur du principal doit d'abord l'autoriser, ce qui se produit lors de sa prochaine vérification, généralement sous cinq minutes. D'ici là, la carte affiche "En attente de l'autorisation du principal", et le nœud démarre de lui-même dès qu'il est autorisé. Quelques minutes après qu'il commence à répondre, il reçoit des visiteurs.

Sur le principal, la carte Haute disponibilité liste ses nœuds applicatifs et indique si le serveur de base de données a appliqué la liste d'accès actuelle.

Ce qui change sur un nœud applicatif

• Son instance de production n'a pas de base de données propre. Les réglages de sa base de données sont gérés par CICDoo et ne peuvent pas être modifiés dans la configuration Odoo de l'instance.
• Les tâches planifiées (crons Odoo) ne s'exécutent que sur le principal.
• Les sauvegardes sont faites sur le principal. Sauvegardez et restaurez la base de données du cluster depuis le projet principal.
• Pousser vers la branche d'un nœud applicatif ne fait rien en soi. Le cluster est mis à jour depuis le principal.

Déployer des mises à jour

Poussez vers la branche du principal comme d'habitude. CICDoo met alors à jour tout le cluster dans l'ordre :

1. Chaque nœud applicatif est arrêté.
2. Le principal est mis à jour, y compris toute mise à niveau de modules, pendant qu'aucun autre serveur n'utilise la base de données.
3. Chaque nœud applicatif est redémarré avec le nouveau code.

Vous pouvez suivre chaque étape dans l'onglet File d'attente de l'instance sur laquelle elle s'exécute. Si la mise à jour du principal échoue, les nœuds applicatifs ne sont pas redémarrés, et leurs entrées dans la file d'attente en indiquent la raison. Corrigez le problème et déployez à nouveau.

Comme les mises à niveau de modules ont besoin de la base de données pour elles seules, le site est indisponible pendant la mise à jour du principal, comme pour une instance unique.

Quitter un cluster

Pour retirer un nœud applicatif, remettez son Rôle sur Autonome (base de données propre) et cliquez sur Appliquer. Son instance de production s'arrête, car sa propre base de données ne contient pas les données du cluster. Restaurez-y une sauvegarde avant de la redémarrer.

Un principal ne peut pas être modifié tant qu'il a encore des nœuds applicatifs. Retirez d'abord les nœuds.

Dépannage

• Le nœud attend toujours d'être autorisé : vérifiez que l'instance de production du principal tourne et que son serveur est en ligne. Le principal doit redémarrer une fois après être devenu principal avant qu'un nœud soit autorisé.
• Le nœud démarre mais Odoo ne se lance pas : ouvrez les journaux du nœud. Un message indiquant que la base de données du principal n'est pas initialisée signifie que le principal n'a pas terminé son premier démarrage.
• Les envois de fichiers ou les connexions ne suivent pas les visiteurs d'un nœud à l'autre : les serveurs ne partagent pas le filestore. Voir "Avant de commencer" ci-dessus.

Consultez Branches et instances pour savoir comment les instances correspondent aux branches, et Utiliser un répartiteur de charge pour le réglage de répartiteur de charge au niveau du serveur, qui est une fonctionnalité différente.