Come eseguire il cluster Odoo 12 con la replica in streaming PostgreSQL per un'elevata disponibilità

Odoo (precedentemente noto come OpenERP) è una suite di app aziendali open source. È disponibile in due versioni:community e enterprise. Alcune delle app più popolari (e gratuite!) integrate in questa piattaforma sono Discuss, CRM, Inventory, Website, Employee, Leaves, Recruitment, Expenses, Accounting, Fatturazione, Point of Sale e molte altre.

In questo post del blog, esamineremo come raggruppare Odoo per ottenere un'elevata disponibilità e scalabilità. Questo post è simile ai nostri post precedenti sul ridimensionamento di Drupal, WordPress, Magento. I software utilizzati sono Odoo 12, HAProxy 1.8.8, Keepalived 1.3.9, PostgreSQL 11 e OCFS2 (Oracle Cluster File System).

La nostra configurazione è composta da 6 server:

lb1 (HAProxy) + keepalived + ClusterControl - 192.168.55.101
lb2 (HAProxy) + keepalived + storage condiviso - 192.168.55.102
odoo1 - 192.168.55.111
odoo2 - 192.168.55.112
postgresql1 (master) - 192.168.55.121
postgresql2 (slave) - 192.168.55.122

Tutti i nodi sono in esecuzione su Ubuntu 18.04.2 LTS (Bionic). Utilizzeremo ClusterControl per distribuire e gestire PostgreSQL, Keepalived e HAProxy poiché ci farà risparmiare un sacco di lavoro. ClusterControl sarà collocato insieme a HAProxy su lb1 mentre aggiungeremo un disco aggiuntivo a lb2 da utilizzare come provider di archiviazione condivisa. Questo disco verrà montato utilizzando un file system in cluster chiamato OCFS2 come directory condivisa. Un indirizzo IP virtuale, 192.168.55.100, funge da singolo endpoint per il nostro servizio di database.

Il diagramma seguente illustra la nostra architettura generale del sistema:

Quello che segue è il contenuto di /etc/hosts su tutti i nodi:

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

Distribuzione della replica in streaming PostgreSQL

Inizieremo installando ClusterControl su lb1:

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

Segui la procedura guidata di installazione, dovrai rispondere ad alcune domande durante il processo.

Imposta SSH senza password dal nodo ClusterControl (lb1) a tutti i nodi che saranno gestiti da ClusterControl, che è lb1 (stesso), lb2, postresql1 e postgresql2. Ma prima, genera una chiave SSH:

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

Quindi copia la chiave su tutti i nodi di destinazione utilizzando lo strumento 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]

Aprire l'interfaccia utente di ClusterControl su http://192.168.55.101/clustercontrol e crea un utente super amministratore con password. Verrai reindirizzato al dashboard dell'interfaccia utente di ClusterControl. Quindi, distribuisci un nuovo cluster PostgreSQL facendo clic sul pulsante "Distribuisci" nel menu in alto. Ti verrà presentata la seguente finestra di dialogo di distribuzione:

Ecco cosa abbiamo digitato nella finestra di dialogo successiva, "Definisci server PostgreSQL":

Porta del server:5432
Utente:postgres
Password:s3cr3t
Versione:11
Dir dati:
Repository:Utilizza i repository dei fornitori

Nella sezione "Definisci topologia", specifica l'indirizzo IP di postgresql1 e postgresql2 di conseguenza:

Nell'ultima sezione "Riepilogo distribuzione" è disponibile un'opzione per abilitare la replica sincrona. Poiché utilizzeremo lo slave solo per scopi di failover (lo slave non servirà alcuna operazione di lettura), lasciamo semplicemente il valore predefinito così com'è. Quindi, premere "Distribuisci" per avviare la distribuzione del cluster di database. Puoi monitorare l'avanzamento della distribuzione esaminando Attività> Lavori> Crea cluster :

Nel frattempo, prendi un caffè e la distribuzione del cluster dovrebbe essere completata entro 10~15 minuti.

Distribuzione di Load Balancer e IP virtuale per i server PostgreSQL

A questo punto, abbiamo già un cluster di replica PostgreSQL a due nodi in esecuzione in una configurazione master-slave:

Il passaggio successivo consiste nel distribuire il livello di bilanciamento del carico per il nostro database, che ci consente di collegarlo all'indirizzo IP virtuale e fornire un singolo endpoint per l'applicazione. Configurare le opzioni di distribuzione HAProxy come segue:

L'applicazione non supporta la suddivisione in lettura e scrittura in modo nativo, quindi utilizzeremo il metodo attivo-passivo per ottenere un'elevata disponibilità. Il miglior algoritmo di bilanciamento del carico è il criterio "source", poiché utilizziamo solo un nodo PostgreSQL alla volta.

Ripetere lo stesso passaggio per l'altro servizio di bilanciamento del carico, lb2. Modificare invece "Indirizzo server" in 192.168.55.102. Ecco come appare dopo il completamento della distribuzione se vai nella pagina dei nodi:

È prevista la linea rossa sul primo listener dove HAProxy mostra che postgresql2 (192.168.55.122) è inattivo perché lo script di controllo dello stato restituisce che il nodo è attivo ma non un master. Il secondo listener con una linea blu (haproxy_5434_ro) mostra che il nodo è attivo ma in stato di "backup". Tuttavia, questo listener può essere ignorato poiché l'applicazione non supporta la suddivisione in lettura-scrittura.

Successivamente, distribuiamo le istanze Keepalived su questi sistemi di bilanciamento del carico per collegarle a un unico indirizzo IP virtuale. Vai a Gestisci -> Load Balancer -> Keepalived -> Distribuisci Keepalived e specificare la prima e la seconda istanza HAProxy, quindi l'indirizzo IP virtuale e l'interfaccia di rete da ascoltare:

Fare clic su "Distribuisci Keepalived" per avviare la distribuzione. Il servizio di connessione PostgreSQL ora è bilanciato dal carico su uno dei nodi del database ed è accessibile tramite la porta 192.168.55.100 5433.

Configurazione di iSCSI

Il server di archiviazione (lb2) deve esportare un disco tramite iSCSI in modo che possa essere montato su entrambi i server delle applicazioni Odoo (odoo1 e odoo2). iSCSI fondamentalmente dice al tuo kernel che hai un disco SCSI e trasporta quell'accesso su IP. Il "server" è chiamato "target" e il "client" che utilizza quel dispositivo iSCSI è l'"iniziatore".

Innanzitutto, installa la destinazione iSCSI in lb2:

$ sudo apt install -y tgt

Abilita tgt all'avvio:

$ systemctl enable tgt

È preferibile avere un disco separato per il clustering del file system. Pertanto, utilizzeremo un altro disco montato in lb2 (/dev/sdb) da condividere tra i server delle applicazioni (odoo1 e odoo2). Innanzitutto, crea una destinazione iSCSI utilizzando lo strumento tgtadm:

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

Quindi, assegna il dispositivo a blocchi /dev/sdb al numero di unità logica (LUN) 1 insieme all'ID di destinazione 1:

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

Quindi, consenti ai nodi iniziatori sulla stessa rete di accedere a questa destinazione:

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

Usa lo strumento tgt-admin per scaricare le righe di configurazione iSCSI e salvarlo come file di configurazione per renderlo persistente al riavvio:

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

Infine, riavvia il servizio di destinazione iSCSI:

$ sudo systemctl restart tgt

** I seguenti passaggi devono essere eseguiti su odoo1 e odoo2.

Installa l'iniziatore iSCSI sui rispettivi host:

$ sudo apt-get install -y open-iscsi

Imposta l'iniziatore iSCSI per l'avvio automatico:

$ sudo systemctl enable open-iscsi

Scopri i target iSCSI che abbiamo configurato in precedenza:

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

Se vedi risultati simili a quelli sopra, significa che possiamo vedere e connetterci alla destinazione iSCSI. Utilizzare il comando seguente per connettersi alla destinazione iSCSI su 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.

Assicurati di poter vedere il nuovo disco rigido (/dev/sdb) elencato nella directory /dev:

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

Il nostro disco condiviso è ora montato su entrambi i server delle applicazioni (odoo1 e odoo2).

Configurazione di OCFS2 per Odoo

** I seguenti passaggi devono essere eseguiti su odoo1 se non diversamente specificato.

OCFS2 consente di montare il file system in più di una posizione. Installa gli strumenti OCFS2 su entrambi i server odoo1 e odoo2:

$ sudo apt install -y ocfs2-tools

Crea una tabella delle partizioni del disco per il disco rigido /dev/sdb:

$ sudo cfdisk /dev/sdb

Crea una partizione utilizzando le seguenti sequenze nella procedura guidata di cfdisk:Nuovo> Primario> accetta dimensione> Scrivi> sì> Esci .

Crea un file system OCFS2 su /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

Crea un file di configurazione del cluster in /etc/ocfs2/cluster.conf e definisci le direttive del nodo e del cluster come segue:

# /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

Tieni presente che gli attributi nella clausola del nodo o del cluster devono trovarsi dopo una scheda.

** I seguenti passaggi devono essere eseguiti su odoo1 e odoo2 se non diversamente specificato.

Crea lo stesso file di configurazione (/etc/ocfs2/cluster.conf) su odoo2. Questo file deve essere lo stesso in tutti i nodi del cluster e le modifiche apportate a questo file devono essere propagate agli altri nodi del cluster.

Riavvia il servizio o2cb per applicare le modifiche apportate in /etc/ocfs2/cluster.conf:

$ sudo systemctl restart o2cb

Crea la directory dei file di Odoo in /var/lib/odoo:

$ sudo mkdir -p /var/lib/odoo

Ottieni l'ID del blocco per il dispositivo /dev/sdb1. UUID è consigliato in fstab se utilizzi un dispositivo iSCSI:

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

Usa il valore UUID quando aggiungi la seguente riga in /etc/fstab:

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

Registra il cluster ocfs2 e monta il filesystem da fstab:

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

Verifica con:

$ 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)

Se riesci a vedere la riga sopra su tutti i server delle applicazioni, possiamo installare Odoo.

Installazione e configurazione di Odoo 12

** I seguenti passaggi devono essere eseguiti su odoo1 e odoo2 se non diversamente specificato.

Installa Odoo 12 tramite il repository dei pacchetti:

$ 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

Per impostazione predefinita, il comando precedente installerà automaticamente il server PostgreSQL sullo stesso host come parte delle dipendenze Odoo. Probabilmente vogliamo fermarlo perché non utilizzeremo comunque il server locale:

$ sudo systemctl stop postgresql
$ sudo systemctl disable postgresql

Su postgresql1, crea un utente del database chiamato "odoo":

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

Specificare una password nel prompt. Quindi su entrambi postgresql1 e postgresql2, aggiungi la seguente riga all'interno di pg_hba.conf per consentire la connessione dei nodi dell'applicazione e del bilanciamento del carico. Come nel nostro caso, si trova in /etc/postgresql/11/main/pg_hba.conf:

host  all  all       192.168.55.0/24    md5

Quindi ricarica il server PostgreSQL per caricare le modifiche:

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

Modifica il file di configurazione di Odoo in /etc/odoo/odoo.conf e configura i parametri admin_passwd, db_host e db_password di conseguenza:

[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

Riavvia Odoo su entrambi i server per caricare le nuove modifiche:

$ sudo systemctl restart odoo

Apri Odoo su uno dei server delle applicazioni tramite il browser web. In questo esempio, ci siamo collegati a odoo1, quindi l'URL è http://192.168.55.111:8069/ e dovresti vedere la seguente pagina iniziale:

Specificare la "Master Password" identica al valore admin_passwd definito nel file di configurazione di Odoo. Quindi compila tutte le informazioni richieste per la nuova azienda che utilizzerà questa piattaforma.

Una volta terminato, attendere un momento fino al termine dell'inizializzazione. Verrai reindirizzato alla dashboard di amministrazione di Odoo:

A questo punto, l'installazione di Odoo è completa e puoi iniziare a configurare le app aziendali per questa azienda. Tutte le modifiche ai file apportate da questo server delle applicazioni verranno archiviate all'interno del file system del cluster situato in "/var/lib/odoo/.local" (montato anche su un altro server delle applicazioni, odoo2), mentre verranno apportate modifiche al database sul nodo master PostgreSQL.

Nonostante sia in esecuzione su due host diversi, tieni presente che l'applicazione Odoo stessa non è bilanciata in questo momento. È possibile utilizzare le istanze HAProxy distribuite per il cluster di database per ottenere una migliore disponibilità, proprio come il servizio di database. Inoltre, il file system del disco condiviso (OCFS2) utilizzato da entrambi i server delle applicazioni è ancora esposto a un singolo punto di errore, poiché utilizzano tutti lo stesso dispositivo iSCSI su lb2 (immagina se lb2 è inaccessibile).

Operazione di failover del database

Ti starai chiedendo cosa accadrebbe se il master PostgreSQL si interrompesse. In tal caso, ClusterControl promuoverà automaticamente lo slave in esecuzione a diventare un master, come mostrato nella schermata seguente:

Non è necessario eseguire alcuna operazione da parte dell'utente finale poiché il failover viene eseguito automaticamente (dopo un periodo di grazia di 30 secondi). Al termine del failover, la nuova topologia verrà segnalata da ClusterControl come:

Se il vecchio master si riattiva, il servizio PostgreSQL verrà chiuso automaticamente e la prossima cosa che l'utente deve fare è risincronizzare il vecchio master dal nuovo master andando su Azioni nodo> Ricostruisci replica slave :

Il vecchio master diventerà quindi uno slave del nuovo master al termine dell'operazione di sincronizzazione:

ClusterControl migliora sicuramente la disponibilità del database con la sua funzione di ripristino automatico e la risincronizzazione di un nodo di database danneggiato è a soli due clic di distanza. Quanto è semplice dopo un evento di guasto catastrofico?

Questo è tutto per ora gente. Buon raggruppamento!