Comment mettre en cluster Odoo 12 avec la réplication en continu PostgreSQL pour une haute disponibilité

Odoo (anciennement connu sous le nom d'OpenERP) est une suite d'applications professionnelles open source. Il existe en deux versions - communautaire et entreprise. Certaines des applications les plus populaires (et gratuites !) intégrées à cette plate-forme sont Discuss, CRM, Inventory, Website, Employee, Leaves, Recruitment, Expenses, Accounting, Invoicing, Point of Sale et bien d'autres.

Dans cet article de blog, nous verrons comment regrouper Odoo pour obtenir une haute disponibilité et une évolutivité. Cet article est similaire à nos articles précédents sur la mise à l'échelle de Drupal, WordPress, Magento. Les logiciels utilisés sont Odoo 12, HAProxy 1.8.8, Keepalived 1.3.9, PostgreSQL 11 et OCFS2 (Oracle Cluster File System).

Notre configuration se compose de 6 serveurs :

lb1 (HAProxy) + keepalived + ClusterControl - 192.168.55.101
lb2 (HAProxy) + keepalived + stockage partagé - 192.168.55.102
odoo1 - 192.168.55.111
odoo2 - 192.168.55.112
postgresql1 (maître) - 192.168.55.121
postgresql2 (esclave) - 192.168.55.122

Tous les nœuds fonctionnent sur Ubuntu 18.04.2 LTS (Bionic). Nous utiliserons ClusterControl pour déployer et gérer PostgreSQL, Keepalived et HAProxy, car cela nous évitera beaucoup de travail. ClusterControl sera colocalisé avec HAProxy sur lb1 tandis que nous ajouterons un disque supplémentaire à lb2 pour être utilisé comme fournisseur de stockage partagé. Ce disque sera monté à l'aide d'un système de fichiers en cluster appelé OCFS2 en tant que répertoire partagé. Une adresse IP virtuelle, 192.168.55.100, agit comme point de terminaison unique pour notre service de base de données.

Le schéma suivant illustre l'architecture globale de notre système :

Voici le contenu de /etc/hosts sur tous les nœuds :

192.168.55.101  lb1.local lb1 cc.local cc
192.168.55.102  lb2.local lb2 storage.local storage
192.168.55.111  odoo1.local odoo1
192.168.55.112  odoo2.local odoo2
192.168.55.121  postgresql1.local postgresql1
192.168.55.122  postgresql2.local postgresql2

Déploiement de la réplication en continu PostgreSQL

Nous allons commencer par installer ClusterControl sur lb1 :

$ wget severalnines.com/downloads/cmon/install-cc
$ chmod 755 ./install-cc
$ sudo ./install-cc

Suivez l'assistant d'installation, vous devrez répondre à quelques questions pendant le processus.

Configurez SSH sans mot de passe du nœud ClusterControl (lb1) à tous les nœuds qui seront gérés par ClusterControl, c'est-à-dire lb1 (lui-même), lb2, postresql1 et postgresql2. Mais d'abord, générez une clé SSH :

$ whoami
ubuntu
$ ssh-keygen -t rsa # press Enter on all prompts

Copiez ensuite la clé sur tous les nœuds cibles à l'aide de l'outil ssh-copy-id :

$ whoami
ubuntu
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]

Ouvrez l'interface utilisateur de ClusterControl sur http://192.168.55.101/clustercontrol et créez un utilisateur super administrateur avec un mot de passe. Vous serez redirigé vers le tableau de bord de l'interface utilisateur de ClusterControl. Ensuite, déployez un nouveau cluster PostgreSQL en cliquant sur le bouton "Déployer" dans le menu du haut. La boîte de dialogue de déploiement suivante s'affichera :

Voici ce que nous avons tapé dans la boîte de dialogue suivante, "Définir les serveurs PostgreSQL":

Port du serveur :5432
Utilisateur :postgres
Mot de passe :s3cr3t
Version :11
Répertoire des données :
Référentiel :Utilisez les référentiels des fournisseurs

Dans la section "Définir la topologie", spécifiez l'adresse IP de postgresql1 et postgresql2 en conséquence :

Sous la dernière section "Résumé du déploiement", vous avez la possibilité d'activer la réplication synchrone. Puisque nous n'utiliserons l'esclave qu'à des fins de basculement (l'esclave ne servira à aucune opération de lecture), nous laissons simplement la valeur par défaut telle quelle. Ensuite, appuyez sur "Déployer" pour démarrer le déploiement du cluster de bases de données. Vous pouvez surveiller la progression du déploiement en consultant Activité > Tâches > Créer un cluster :

Pendant ce temps, prenez un café et le déploiement du cluster devrait être terminé dans les 10 à 15 minutes.

Déployer des équilibreurs de charge et une adresse IP virtuelle pour les serveurs PostgreSQL

À ce stade, nous avons déjà un cluster de réplication PostgreSQL à deux nœuds exécuté dans une configuration maître-esclave :

L'étape suivante consiste à déployer le niveau d'équilibrage de charge pour notre base de données, ce qui nous permet de l'attacher à une adresse IP virtuelle et de fournir un point de terminaison unique pour l'application. Nous allons configurer les options de déploiement HAProxy comme suit :

L'application ne prend pas en charge nativement le fractionnement lecture-écriture, nous utiliserons donc la méthode active-passive pour obtenir une haute disponibilité. Le meilleur algorithme d'équilibrage de charge est la politique "source", puisque nous n'utilisons qu'un seul nœud PostgreSQL à la fois.

Répétez la même étape pour l'autre équilibreur de charge, lb2. Changez "l'adresse du serveur" en 192.168.55.102 à la place. Voici à quoi cela ressemble une fois le déploiement terminé si vous accédez à la page Nœuds :

La ligne rouge sur le premier écouteur est attendue là où HAProxy indique que postgresql2 (192.168.55.122) est en panne car le script de vérification de l'état renvoie que le nœud est actif mais pas maître. Le deuxième écouteur avec une ligne bleue (haproxy_5434_ro) montre que le nœud est UP mais en état "sauvegarde". Cet écouteur peut cependant être ignoré car l'application ne prend pas en charge le fractionnement en lecture-écriture.

Ensuite, nous déployons des instances Keepalived au-dessus de ces équilibreurs de charge pour les lier à une seule adresse IP virtuelle. Allez dans Gérer -> Équilibreur de charge -> Keepalived -> Déployer Keepalived et spécifiez les première et deuxième instances HAProxy, puis l'adresse IP virtuelle et l'interface réseau à écouter :

Cliquez sur "Déployer Keepalived" pour démarrer le déploiement. Le service de connexion PostgreSQL est maintenant équilibré en charge sur l'un des nœuds de la base de données et accessible via le port 192.168.55.100 5433.

Configurer iSCSI

Le serveur de stockage (lb2) doit exporter un disque via iSCSI afin qu'il puisse être monté sur les deux serveurs d'application Odoo (odoo1 et odoo2). iSCSI indique essentiellement à votre noyau que vous avez un disque SCSI, et il transporte cet accès sur IP. Le "serveur" est appelé la "cible" et le "client" qui utilise ce périphérique iSCSI est l'"initiateur".

Tout d'abord, installez la cible iSCSI dans lb2 :

$ sudo apt install -y tgt

Activer le cible au démarrage :

$ systemctl enable tgt

Il est préférable d'avoir un disque séparé pour le clustering du système de fichiers. Ainsi, nous allons utiliser un autre disque monté dans lb2 (/dev/sdb) à partager entre les serveurs d'application (odoo1 et odoo2). Tout d'abord, créez une cible iSCSI à l'aide de l'outil tgtadm :

$ sudo tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.2019-02.lb2:odcfs2

Attribuez ensuite le périphérique bloc /dev/sdb au numéro d'unité logique (LUN) 1 avec l'ID cible 1 :

$ sudo tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/sdb

Ensuite, autorisez les nœuds initiateurs du même réseau à accéder à cette cible :

$ sudo tgtadm --lld iscsi --op bind --mode target --tid 1 --initiator-address 192.168.55.0/24

Utilisez l'outil tgt-admin pour vider les lignes de configuration iSCSI et l'enregistrer en tant que fichier de configuration pour le rendre persistant après le redémarrage :

$ sudo tgt-admin --dump > /etc/tgt/conf.d/shareddisk.conf

Enfin, redémarrez le service cible iSCSI :

$ sudo systemctl restart tgt

** Les étapes suivantes doivent être effectuées sur odoo1 et odoo2.

Installez l'initiateur iSCSI sur les hôtes respectifs :

$ sudo apt-get install -y open-iscsi

Configurez l'initiateur iSCSI pour qu'il démarre automatiquement :

$ sudo systemctl enable open-iscsi

Découvrez les cibles iSCSI que nous avons configurées précédemment :

$ sudo iscsiadm -m discovery -t sendtargets -p lb2
192.168.55.102:3260,1 iqn.2019-02.lb2:odcfs2

Si vous voyez un résultat similaire à celui ci-dessus, cela signifie que nous pouvons voir et pouvoir nous connecter à la cible iSCSI. Utilisez la commande suivante pour vous connecter à la cible iSCSI sur lb2 :

$ sudo iscsiadm -m node --targetname iqn.2019-02.lb2:odcfs2 -p lb2 -l
Logging in to [iface: default, target: iqn.2019-02.lb2:odcfs2, portal: 192.168.55.102,3260] (multiple)
Login to [iface: default, target: iqn.2019-02.lb2:odcfs2, portal: 192.168.55.102,3260] successful.

Assurez-vous que vous pouvez voir le nouveau disque dur (/dev/sdb) répertorié sous le répertoire /dev :

$ sudo ls -1 /dev/sd*
/dev/sda
/dev/sda1
/dev/sda2
/dev/sda3
/dev/sdb

Notre disque partagé est maintenant monté sur les deux serveurs d'applications (odoo1 et odoo2).

Configurer OCFS2 pour Odoo

** Les étapes suivantes doivent être effectuées sur odoo1 sauf indication contraire.

OCFS2 permet au système de fichiers d'être monté à plusieurs endroits. Installez les outils OCFS2 sur les serveurs odoo1 et odoo2 :

$ sudo apt install -y ocfs2-tools

Créez une table de partition de disque pour le disque dur /dev/sdb :

$ sudo cfdisk /dev/sdb

Créez une partition en utilisant les séquences suivantes dans l'assistant cfdisk :Nouveau> Principal> accepter Taille> Écrire> oui> Quitter .

Créez un système de fichiers OCFS2 sur /dev/sdb1 :

$ sudo mkfs.ocfs2 -b 4K -C 128K -L "Odoo_Cluster" /dev/sdb1
mkfs.ocfs2 1.8.5
Cluster stack: classic o2cb
Label: Odoo_Cluster
Features: sparse extended-slotmap backup-super unwritten inline-data strict-journal-super xattr indexed-dirs refcount discontig-bg append-dio
Block size: 4096 (12 bits)
Cluster size: 131072 (17 bits)
Volume size: 21473656832 (163831 clusters) (5242592 blocks)
Cluster groups: 6 (tail covers 2551 clusters, rest cover 32256 clusters)
Extent allocator size: 4194304 (1 groups)
Journal size: 134217728
Node slots: 8
Creating bitmaps: done
Initializing superblock: done
Writing system files: done
Writing superblock: done
Writing backup superblock: 3 block(s)
Formatting Journals: done
Growing extent allocator: done
Formatting slot map: done
Formatting quota files: done
Writing lost+found: done
mkfs.ocfs2 successful

Créez un fichier de configuration de cluster dans /etc/ocfs2/cluster.conf et définissez les directives de nœud et de cluster comme ci-dessous :

# /etc/ocfs2/cluster.conf
cluster:
        node_count = 2
        name = ocfs2
node:
        ip_port = 7777
        ip_address = 192.168.55.111
        number = 1
        name = odoo1
        cluster = ocfs2
node:
        ip_port = 7777
        ip_address = 192.168.55.112
        number = 2
        name = odoo2
        cluster = ocfs2

Notez que les attributs sous la clause node ou cluster doivent être après une tabulation.

** Les étapes suivantes doivent être effectuées sur odoo1 et odoo2, sauf indication contraire.

Créez le même fichier de configuration (/etc/ocfs2/cluster.conf) sur odoo2. Ce fichier doit être le même sur tous les nœuds du cluster, et les modifications apportées à ce fichier doivent être propagées aux autres nœuds du cluster.

Redémarrez le service o2cb pour appliquer les modifications que nous avons apportées dans /etc/ocfs2/cluster.conf :

$ sudo systemctl restart o2cb

Créez le répertoire des fichiers Odoo sous /var/lib/odoo :

$ sudo mkdir -p /var/lib/odoo

Obtenez l'ID de bloc pour le périphérique /dev/sdb1. UUID est recommandé dans fstab si vous utilisez un périphérique iSCSI :

$ sudo blkid /dev/sdb1 | awk {'print $3'}
UUID="93a2b6c4-d800-4532-9a9b-2d2f2f1a726b"

Utilisez la valeur UUID lors de l'ajout de la ligne suivante dans /etc/fstab :

UUID=93a2b6c4-d800-4532-9a9b-2d2f2f1a726b       /var/lib/odoo     ocfs2   defaults,_netdev        0 0

Enregistrez le cluster ocfs2 et montez le système de fichiers à partir de fstab :

$ sudo o2cb register-cluster ocfs2
$ sudo mount -a

Confirmez avec :

$ mount | grep odoo
/dev/sdb1 on /var/lib/odoo type ocfs2 (rw,relatime,_netdev,heartbeat=local,nointr,data=ordered,errors=remount-ro,atime_quantum=60,coherency=full,user_xattr,acl,_netdev)

Si vous pouvez voir la ligne ci-dessus sur tous les serveurs d'applications, nous pouvons installer Odoo.

Installer et configurer Odoo 12

** Les étapes suivantes doivent être effectuées sur odoo1 et odoo2, sauf indication contraire.

Installez Odoo 12 via le référentiel de packages :

$ wget -O - https://nightly.odoo.com/odoo.key | sudo apt-key add -
$ echo "deb http://nightly.odoo.com/12.0/nightly/deb/ ./" | sudo tee -a /etc/apt/sources.list.d/odoo.list
$ sudo apt update && sudo apt install odoo

Par défaut, la commande ci-dessus installera automatiquement le serveur PostgreSQL sur le même hôte dans le cadre des dépendances Odoo. Nous voulons probablement l'arrêter car nous n'allons de toute façon pas utiliser le serveur local :

$ sudo systemctl stop postgresql
$ sudo systemctl disable postgresql

Sur postgresql1, créez un utilisateur de base de données appelé "odoo":

$ sudo -i
$ su - postgres
$ createuser --createrole --createdb --pwprompt odoo

Spécifiez un mot de passe dans l'invite. Ensuite, sur postgresql1 et postgresql2, ajoutez la ligne suivante dans pg_hba.conf pour permettre aux nœuds d'application et d'équilibrage de charge de se connecter. Comme dans notre cas, il se trouve dans /etc/postgresql/11/main/pg_hba.conf :

host  all  all       192.168.55.0/24    md5

Rechargez ensuite le serveur PostgreSQL pour charger les modifications :

$ su - postgres
$ /usr/lib/postgresql/11/bin/pg_ctl reload -D /var/lib/postgresql/11/main/

Modifiez le fichier de configuration Odoo sur /etc/odoo/odoo.conf et configurez les paramètres admin_passwd, db_host et db_password en conséquence :

[options]
; This is the password that allows database operations:
admin_passwd = admins3cr3t
db_host = 192.168.55.100
db_port = 5433
db_user = odoo
db_password = odoopassword
;addons_path = /usr/lib/python3/dist-packages/odoo/addons

Redémarrez Odoo sur les deux serveurs pour charger les nouvelles modifications :

$ sudo systemctl restart odoo

Ensuite, ouvrez Odoo sur l'un des serveurs d'applications via un navigateur Web. Dans cet exemple, nous nous sommes connectés à odoo1, donc l'URL est http://192.168.55.111:8069/ et vous devriez voir la page initiale suivante :

Spécifiez le "Master Password" identique à la valeur admin_passwd définie dans le fichier de configuration d'Odoo. Remplissez ensuite toutes les informations requises pour la nouvelle entreprise qui va utiliser cette plate-forme.

Une fois cela fait, attendez un moment jusqu'à ce que l'initialisation se termine. Vous serez redirigé vers le tableau de bord d'administration d'Odoo :

À ce stade, l'installation d'Odoo est terminée et vous pouvez commencer à configurer les applications professionnelles pour cette entreprise. Toutes les modifications de fichiers apportées par ce serveur d'application seront stockées dans le système de fichiers en cluster situé dans "/var/lib/odoo/.local" (qui est également monté sur un autre serveur d'application, odoo2), tandis que les modifications apportées à la base de données se produiront sur le nœud maître PostgreSQL.

Bien qu'il fonctionne sur deux hôtes différents, notez que l'application Odoo elle-même n'est pas équilibrée dans cette écriture. Vous pouvez utiliser les instances HAProxy déployées pour le cluster de bases de données pour obtenir une meilleure disponibilité, tout comme le service de base de données. De plus, le système de fichiers sur disque partagé (OCFS2) utilisé par les deux serveurs d'applications est toujours exposé à un point de défaillance unique, car ils utilisent tous le même périphérique iSCSI sur lb2 (imaginez si lb2 est inaccessible).

Opération de basculement de la base de données

Vous vous demandez peut-être ce qui se passerait si le maître PostgreSQL tombait en panne. Si cela se produit, ClusterControl promouvra automatiquement l'esclave en cours d'exécution pour qu'il devienne un maître, comme indiqué dans la capture d'écran ci-dessous :

Rien n'est requis de la part de l'utilisateur final car le basculement est effectué automatiquement (après une période de grâce de 30 secondes). Une fois le basculement terminé, la nouvelle topologie sera signalée par ClusterControl comme :

Si l'ancien maître revient, le service PostgreSQL sera automatiquement arrêté et la prochaine chose que l'utilisateur doit faire est de resynchroniser l'ancien maître à partir du nouveau maître en allant dans Node Actions> Rebuild Replication Slave :

L'ancien maître deviendra alors esclave du nouveau maître une fois l'opération de synchronisation terminée :

ClusterControl améliore sûrement la disponibilité de la base de données grâce à sa fonction de récupération automatique et la resynchronisation d'un mauvais nœud de base de données n'est qu'à deux clics. Est-ce simple après une panne catastrophique ?

C'est tout pour le moment, les gens. Bon regroupement !