Odoo (tidigare känt som OpenERP) är en svit med affärsappar med öppen källkod. Den finns i två versioner - community och enterprise. Några av de mest populära apparna (och gratis!) integrerade i den här plattformen är Discuss, CRM, Inventory, Website, Employee, Leaves, Recruitment, Expenses, Accounting, Invoicing, Point of Sale och många fler.
I det här blogginlägget kommer vi att titta på hur man klusterar Odoo för att uppnå hög tillgänglighet och skalbarhet. Det här inlägget liknar våra tidigare inlägg om skalning av Drupal, WordPress, Magento. Programvaran som används är Odoo 12, HAProxy 1.8.8, Keepalived 1.3.9, PostgreSQL 11 och OCFS2 (Oracle Cluster File System).
Vår installation består av 6 servrar:
- lb1 (HAProxy) + keepalived + ClusterControl - 192.168.55.101
- lb2 (HAProxy) + keepalived + delad lagring - 192.168.55.102
- odoo1 - 192.168.55.111
- odoo2 - 192.168.55.112
- postgresql1 (master) - 192.168.55.121
- postgresql2 (slav) - 192.168.55.122
Alla noder körs på Ubuntu 18.04.2 LTS (Bionic). Vi kommer att använda ClusterControl för att distribuera och hantera PostgreSQL, Keepalived och HAProxy eftersom det kommer att spara oss en massa arbete. ClusterControl kommer att samlokaliseras med HAProxy på lb1 medan vi kommer att lägga till en extra disk till lb2 för att användas som en leverantör av delad lagring. Denna disk kommer att monteras med hjälp av ett klustrat filsystem som kallas OCFS2 som en delad katalog. En virtuell IP-adress, 192.168.55.100, fungerar som den enda slutpunkten för vår databastjänst.
Följande diagram illustrerar vår övergripande systemarkitektur:
Följande är innehållet i /etc/hosts på alla noder:
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 postgresql2Distribuera PostgreSQL Streaming Replication
Vi börjar med att installera ClusterControl på lb1:
$ wget severalnines.com/downloads/cmon/install-cc
$ chmod 755 ./install-cc
$ sudo ./install-ccFölj installationsguiden, du måste svara på några frågor under processen.
Ställ in lösenordslös SSH från ClusterControl-noden (lb1) till alla noder som kommer att hanteras av ClusterControl, vilket är lb1 (själv), lb2, postresql1 och postgresql2. Men först, generera en SSH-nyckel:
$ whoami
ubuntu
$ ssh-keygen -t rsa # press Enter on all promptsKopiera sedan nyckeln till alla målnoder med verktyget 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]Öppna ClusterControl UI på http://192.168.55.101/clustercontrol och skapa en superadminanvändare med lösenord. Du kommer att omdirigeras till instrumentpanelen för ClusterControl UI. Installera sedan ett nytt PostgreSQL-kluster genom att klicka på knappen "Distribuera" i toppmenyn. Du kommer att presenteras med följande distributionsdialogruta:
Här är vad vi skrev i nästa dialogruta, "Definiera PostgreSQL-servrar":
- Serverport:5432
- Användare:postgres
- Lösenord:s3cr3t
- Version:11
- Datadir:
- Förråd:Använd leverantörsförråd
I avsnittet "Definiera topologi" anger du IP-adressen för postgresql1 och postgresql2 i enlighet med detta:
Under det sista avsnittet "Deployment Summary" har du möjlighet att aktivera synkron replikering. Eftersom vi endast kommer att använda slaven för failover-ändamål (slaven kommer inte att utföra några läsoperationer), lämnar vi bara standardvärdet som det är. Tryck sedan på "Distribuera" för att starta databasklusterdistributionen. Du kan övervaka distributionsförloppet genom att titta på Aktivitet> Jobb> Skapa kluster :
Under tiden kan du ta lite kaffe och klusterinstallationen bör slutföras inom 10~15 minuter.
Distribuera lastbalanserare och virtuell IP för PostgreSQL-servrar
Vid det här laget har vi redan ett PostgreSQL-replikeringskluster med två noder som körs i en master-slave-installation:
Nästa steg är att distribuera lastbalanseringsnivån för vår databas, vilket gör att vi kan knyta ihop den virtuella IP-adressen och tillhandahålla en enda slutpunkt för applikationen. Vi kommer att konfigurera HAProxy-distributionsalternativen enligt nedan:
Applikationen stöder inte läs-skrivdelning inbyggt så vi kommer att använda aktiv-passiv metod för att uppnå hög tillgänglighet. Den bästa lastbalanseringsalgoritmen är "källa"-policyn, eftersom vi bara använder en PostgreSQL-nod åt gången.
Upprepa samma steg för den andra lastbalanseraren, lb2. Ändra "Serveradress" till 192.168.55.102 istället. Så här ser det ut efter att distributionen är klar om du går under sidan Noder:
Den röda linjen på den första lyssnaren förväntas där HAProxy visar att postgresql2 (192.168.55.122) är nere eftersom hälsokontrollskriptet returnerar att noden är uppe men inte en master. Den andra lyssnaren med blå linje (haproxy_5434_ro) visar att noden är UPP, men i "backup"-tillstånd. Denna lyssnare kan dock ignoreras eftersom applikationen inte stöder läs-skrivdelning.
Därefter distribuerar vi Keepalved-instanser ovanpå dessa belastningsutjämnare för att binda dem till en enda virtuell IP-adress. Gå till Hantera -> Load Balancer -> Keepalived -> Implementera Keepalived och ange den första och andra HAProxy-instansen, sedan den virtuella IP-adressen och nätverksgränssnittet att lyssna på:
Klicka på "Deploy Keepalived" för att starta distributionen. PostgreSQL-anslutningstjänsten är nu lastbalanserad till någon av databasnoderna och tillgänglig via 192.168.55.100 port 5433.
Konfigurera iSCSI
Lagringsservern (lb2) behöver exportera en disk via iSCSI så att den kan monteras på båda Odoo-applikationsservrarna (odoo1 och odoo2). iSCSI berättar i princip för din kärna att du har en SCSI-disk, och den transporterar den åtkomsten över IP. "Servern" kallas "mål" och "klienten" som använder den iSCSI-enheten är "initiatorn".
Installera först iSCSI target i lb2:
$ sudo apt install -y tgtAktivera tgt vid uppstart:
$ systemctl enable tgtDet är att föredra att ha en separat disk för filsystemklustring. Således kommer vi att använda en annan disk monterad i lb2 (/dev/sdb) för att delas mellan applikationsservrar (odoo1 och odoo2). Skapa först ett iSCSI-mål med tgtadm-verktyget:
$ sudo tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.2019-02.lb2:odcfs2Tilldela sedan blockenheten /dev/sdb till logiskt enhetsnummer (LUN) 1 tillsammans med mål-ID 1:
$ sudo tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/sdbLåt sedan initiatornoderna på samma nätverk komma åt detta mål:
$ sudo tgtadm --lld iscsi --op bind --mode target --tid 1 --initiator-address 192.168.55.0/24Använd verktyget tgt-admin för att dumpa iSCSI-konfigurationsraderna och spara dem som en konfigurationsfil för att göra den beständig under omstart:
$ sudo tgt-admin --dump > /etc/tgt/conf.d/shareddisk.confSlutligen, starta om iSCSI-måltjänsten:
$ sudo systemctl restart tgt** Följande steg bör utföras på odoo1 och odoo2.
Installera iSCSI initiator på respektive värddator:
$ sudo apt-get install -y open-iscsiStäll in iSCSI-initiatorn så att den startar automatiskt:
$ sudo systemctl enable open-iscsiUpptäck iSCSI-mål som vi har ställt in tidigare:
$ sudo iscsiadm -m discovery -t sendtargets -p lb2
192.168.55.102:3260,1 iqn.2019-02.lb2:odcfs2Om du ser liknande resultat som ovan betyder det att vi kan se och kunna ansluta till iSCSI-målet. Använd följande kommando för att ansluta till iSCSI-målet på 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.Se till att du kan se den nya hårddisken (/dev/sdb) listad under /dev-katalogen:
$ sudo ls -1 /dev/sd*
/dev/sda
/dev/sda1
/dev/sda2
/dev/sda3
/dev/sdbVår delade disk är nu monterad på båda applikationsservrarna (odoo1 och odoo2).
Konfigurera OCFS2 för Odoo
** Följande steg bör utföras på odoo1 om inte annat anges.
OCFS2 gör att filsystemet kan monteras på mer än en plats. Installera OCFS2-verktyg på både odoo1- och odoo2-servrar:
$ sudo apt install -y ocfs2-toolsSkapa diskpartitionstabell för hårddisken /dev/sdb:
$ sudo cfdisk /dev/sdbSkapa en partition genom att använda följande sekvenser i cfdisk-guiden:Ny> Primär> acceptera storlek> Skriv> ja> Avsluta .
Skapa ett OCFS2-filsystem på /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 successfulSkapa en klusterkonfigurationsfil på /etc/ocfs2/cluster.conf och definiera nod- och klusterdirektiven enligt nedan:
# /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 = ocfs2Observera att attributen under noden eller klustersatsen måste vara efter en tabb.
** Följande steg bör utföras på odoo1 och odoo2 om inte annat anges.
Skapa samma konfigurationsfil (/etc/ocfs2/cluster.conf) på odoo2. Den här filen bör vara densamma över alla noder i klustret, och ändringar som görs i den här filen måste spridas till de andra noderna i klustret.
Starta om o2cb-tjänsten för att tillämpa ändringarna vi gjorde i /etc/ocfs2/cluster.conf:
$ sudo systemctl restart o2cbSkapa Odoo-filkatalogen under /var/lib/odoo:
$ sudo mkdir -p /var/lib/odooHämta block-ID för /dev/sdb1-enheten. UUID rekommenderas i fstab om du använder iSCSI-enhet:
$ sudo blkid /dev/sdb1 | awk {'print $3'}
UUID="93a2b6c4-d800-4532-9a9b-2d2f2f1a726b"Använd UUID-värdet när du lägger till följande rad i /etc/fstab:
UUID=93a2b6c4-d800-4532-9a9b-2d2f2f1a726b /var/lib/odoo ocfs2 defaults,_netdev 0 0Registrera ocfs2-klustret och montera filsystemet från fstab:
$ sudo o2cb register-cluster ocfs2
$ sudo mount -a
Verifiera med:
$ 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)Om du kan se ovanstående rad på alla applikationsservrar är vi bra att installera Odoo.
Installera och konfigurera Odoo 12
** Följande steg bör utföras på odoo1 och odoo2 om inte annat anges.
Installera Odoo 12 via paketförrådet:
$ 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 odooSom standard installerar ovanstående kommando automatiskt PostgreSQL-servern på samma värd som en del av Odoo-beroenden. Vi vill förmodligen stoppa det eftersom vi inte kommer att använda den lokala servern ändå:
$ sudo systemctl stop postgresql
$ sudo systemctl disable postgresqlPå postgresql1, skapa en databasanvändare som heter "odoo":
$ sudo -i
$ su - postgres
$ createuser --createrole --createdb --pwprompt odooAnge ett lösenord i prompten. Sedan på både postgresql1 och postgresql2, lägg till följande rad inuti pg_hba.conf för att tillåta applikations- och belastningsbalansnoderna att ansluta. Som i vårt fall finns den på /etc/postgresql/11/main/pg_hba.conf:
host all all 192.168.55.0/24 md5Ladda sedan om PostgreSQL-servern för att ladda ändringarna:
$ su - postgres
$ /usr/lib/postgresql/11/bin/pg_ctl reload -D /var/lib/postgresql/11/main/Redigera Odoo-konfigurationsfilen på /etc/odoo/odoo.conf och konfigurera parametrarna admin_passwd, db_host och db_password i enlighet med detta:
[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/addonsStarta om Odoo på båda servrarna för att ladda de nya ändringarna:
$ sudo systemctl restart odooÖppna Odoo på en av applikationsservrarna via webbläsaren. I det här exemplet kopplade vi till odoo1, så webbadressen är http://192.168.55.111:8069/ och du bör se följande första sida:
Ange "Master Password" identisk med admin_passwd-värdet som definierats i Odoo-konfigurationsfilen. Fyll sedan i all nödvändig information för det nya företaget som kommer att använda den här plattformen.
När du är klar, vänta ett ögonblick tills initieringen är klar. Du kommer att omdirigeras till Odoo-administrationspanelen:
Vid denna tidpunkt är Odoo-installationen klar och du kan börja konfigurera företagsapparna för detta företag. Alla filändringar som görs av denna applikationsserver kommer att lagras i det klustrade filsystemet som finns på "/var/lib/odoo/.local" (som också är monterat på en annan applikationsserver, odoo2), medan ändringar i databasen kommer att ske på PostgreSQL-masternoden.
Trots att den körs på två olika värdar, notera att Odoo-applikationen i sig inte är belastningsbalanserad i denna skrift. Du kan använda HAProxy-instanserna som distribueras för databasklustret för att uppnå bättre tillgänglighet precis som databastjänsten. Dessutom är det delade diskfilsystemet (OCFS2) som används av båda applikationsservrarna fortfarande utsatt för single-point of failure, eftersom de alla använder samma iSCSI-enhet på lb2 (tänk dig om lb2 är otillgänglig).
Databasfailoveroperation
Du kanske undrar vad som skulle hända om PostgreSQL-mastern går ner. Om det händer kommer ClusterControl automatiskt att marknadsföra den löpande slaven till att bli en master, som visas i skärmdumpen nedan:
Inget behöver göras från slutanvändaren eftersom failover utförs automatiskt (efter en 30-sekunders respitperiod). När failover har slutförts kommer den nya topologin att rapporteras av ClusterControl som:
Om den gamla mastern kommer upp igen kommer PostgreSQL-tjänsten att stängas av automatiskt och nästa sak som användaren behöver göra är att synkronisera tillbaka den gamla mastern från den nya mastern genom att gå till Nod Actions> Rebuild Replication Slave :
Den gamla mastern kommer sedan att bli en slav till den nya mastern efter att synkroniseringsoperationen är klar:
ClusterControl förbättrar säkert databasens tillgänglighet med sin automatiska återställningsfunktion och omsynkronisering av en dålig databasnod är helt enkelt bara två klick bort. Hur enkelt är det efter ett katastrofalt misslyckande?
Det var allt för nu gott folk. Lycka till med klustringen!