Odoo (tidligere kendt som OpenERP) er en suite af open source-virksomhedsapps. Det kommer i to versioner - community og enterprise. Nogle af de mest populære apps (og gratis!) integreret i denne platform er Discuss, CRM, Inventory, Website, Employee, Leaves, Recruitment, Expenses, Accounting, Invoicing, Point of Sale og mange flere.
I dette blogindlæg vil vi se på, hvordan man kan gruppere Odoo for at opnå høj tilgængelighed og skalerbarhed. Dette indlæg ligner vores tidligere indlæg om skalering af Drupal, WordPress, Magento. De anvendte software er Odoo 12, HAProxy 1.8.8, Keepalived 1.3.9, PostgreSQL 11 og OCFS2 (Oracle Cluster File System).
Vores opsætning består af 6 servere:
- lb1 (HAProxy) + keepalived + ClusterControl - 192.168.55.101
- lb2 (HAProxy) + keepalived + delt lager - 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
Alle noder kører på Ubuntu 18.04.2 LTS (Bionic). Vi vil bruge ClusterControl til at implementere og administrere PostgreSQL, Keepalived og HAProxy, da det vil spare os for en masse arbejde. ClusterControl vil blive placeret sammen med HAProxy på lb1, mens vi tilføjer en ekstra disk til lb2, der skal bruges som en delt lagerudbyder. Denne disk vil blive monteret ved hjælp af et klynget filsystem kaldet OCFS2 som en delt mappe. En virtuel IP-adresse, 192.168.55.100, fungerer som det eneste endepunkt for vores databasetjeneste.
Følgende diagram illustrerer vores overordnede systemarkitektur:
Følgende er indholdet af /etc/hosts på alle noder:
192.168.55.101 lb1.local lb1 cc.local cc192.168.55.102 lb2.local lb2 storage.local storage192.168.55.111 odoo1.local odoo1192.168.55.1192.168.55. .local postgresql1192.168.55.122 postgresql2.local postgresql2 Implementering af PostgreSQL Streaming Replication
Vi starter med at installere ClusterControl på lb1:
$ wget severalnines.com/downloads/cmon/install-cc$ chmod 755 ./install-cc$ sudo ./install-cc Følg installationsguiden, du bliver nødt til at besvare nogle spørgsmål under processen.
Konfigurer adgangskodefri SSH fra ClusterControl node (lb1) til alle noder, der vil blive administreret af ClusterControl, som er lb1 (selv), lb2, postresql1 og postgresql2. Men først, generer en SSH-nøgle:
$ whoamiubuntu$ ssh-keygen -t rsa # tryk på Enter på alle prompter Kopier derefter nøglen til alle målknuder ved hjælp af ssh-copy-id tool:
$ whoamiubuntu$ ssh-copy-id [email protected]$ ssh-copy-id [email protected]$ ssh-copy-id [email protected]$ ssh-copy-id example@sqldat .com Åbn ClusterControl UI på http://192.168.55.101/clustercontrol og opret en superadmin-bruger med adgangskode. Du vil blive omdirigeret til ClusterControl UI-dashboardet. Implementer derefter en ny PostgreSQL-klynge ved at klikke på knappen "Deploy" i topmenuen. Du vil blive præsenteret for følgende implementeringsdialog:
Her er, hvad vi skrev i den næste dialog, "Definer PostgreSQL-servere":
- Serverport:5432
- Bruger:postgres
- Adgangskode:s3cr3t
- Version:11
- Datadir:
- Repository:Brug leverandørlagre
I afsnittet "Definer topologi" skal du angive IP-adressen for postgresql1 og postgresql2 i overensstemmelse hermed:
Under det sidste afsnit "Deployment Summary" har du mulighed for at aktivere synkron replikering. Da vi kun vil bruge slaven til failover-formål (slaven vil ikke betjene nogen læseoperationer), lader vi bare standardværdien være som den er. Tryk derefter på "Deploy" for at starte databaseklyngeimplementeringen. Du kan overvåge implementeringsprocessen ved at se på Aktivitet> Jobs> Opret klynge :
Snup i mellemtiden noget kaffe, og klyngeinstallationen skulle være afsluttet inden for 10~15 minutter.
Implementering af belastningsbalancere og virtuel IP til PostgreSQL-servere
På dette tidspunkt har vi allerede en to-node PostgreSQL-replikeringsklynge, der kører i en master-slave-opsætning:
Det næste trin er at implementere belastningsbalanceringsniveauet til vores database, som giver os mulighed for at binde den virtuelle IP-adresse og levere et enkelt slutpunkt til applikationen. Vi konfigurerer HAProxy-implementeringsmulighederne som nedenstående:
Applikationen understøtter ikke indbygget læs-skriv-opdeling, så vi vil bruge aktiv-passiv metode for at opnå høj tilgængelighed. Den bedste belastningsbalanceringsalgoritme er "kilde"-politikken, da vi kun bruger én PostgreSQL-node ad gangen.
Gentag det samme trin for den anden belastningsbalancer, lb2. Skift "Serveradressen" til 192.168.55.102 i stedet for. Sådan ser det ud efter implementeringen er fuldført, hvis du går under siden Nodes:
Den røde linje på den første lytter forventes, hvor HAProxy viser, at postgresql2 (192.168.55.122) er nede, fordi sundhedstjekscriptet returnerer, at noden er oppe, men ikke en master. Den anden lytter med blå linje (haproxy_5434_ro) viser, at noden er OP, men i "backup"-tilstand. Denne lytter kan dog ignoreres, da applikationen ikke understøtter læse-skriveopdeling.
Dernæst implementerer vi Keepalved-instanser oven på disse belastningsbalancere for at binde dem sammen med en enkelt virtuel IP-adresse. Gå til Administrer -> Load Balancer -> Keepalived -> Implementer Keepalived og angiv den første og anden HAProxy-instans, derefter den virtuelle IP-adresse og netværksgrænsefladen, der skal lyttes til:
Klik på "Deploy Keepalived" for at starte implementeringen. PostgreSQL-forbindelsestjenesten er nu belastningsbalanceret til en af databasenoderne og tilgængelig via 192.168.55.100 port 5433.
Konfiguration af iSCSI
Lagerserveren (lb2) skal eksportere en disk gennem iSCSI, så den kan monteres på begge Odoo-applikationsservere (odoo1 og odoo2). iSCSI fortæller dybest set din kerne, at du har en SCSI-disk, og den transporterer den adgang over IP. "Serveren" kaldes "målet", og den "klient", der bruger den iSCSI-enhed, er "initiatoren".
Installer først iSCSI target i lb2:
$ sudo apt install -y tgt Aktiver tgt ved opstart:
$ systemctl aktiver tgt Det foretrækkes at have en separat disk til filsystemklynger. Således vil vi bruge en anden disk monteret i lb2 (/dev/sdb) til at blive delt mellem applikationsservere (odoo1 og odoo2). For det første skal du oprette et iSCSI-mål ved hjælp af tgtadm-værktøjet:
$ sudo tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.2019-02.lb2:odcfs2 Tildel derefter blokenheden /dev/sdb til logisk enhedsnummer (LUN) 1 sammen med mål-ID 1:
$ sudo tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/sdb Tillad derefter initiatorknuderne på det samme netværk at få adgang til dette mål:
$ sudo tgtadm --lld iscsi --op bind --mode target --tid 1 --initiator-adresse 192.168.55.0/24 Brug værktøjet tgt-admin til at dumpe iSCSI-konfigurationslinjerne og gemme det som en konfigurationsfil for at gøre det vedvarende under genstart:
$ sudo tgt-admin --dump>
/etc/tgt/conf.d/shareddisk.conf Til sidst skal du genstarte iSCSI-måltjenesten:
$ sudo systemctl genstart tgt ** Følgende trin skal udføres på odoo1 og odoo2.
Installer iSCSI initiator på de respektive værter:
$ sudo apt-get install -y open-iscsi Indstil iSCSI-initiatoren til automatisk at starte:
$ sudo systemctl aktiver open-iscsi Opdag iSCSI-mål, som vi har konfigureret tidligere:
$ sudo iscsiadm -m discovery -t sendtargets -p lb2192.168.55.102:3260,1 iqn.2019-02.lb2:odcfs2 Hvis du ser lignende resultat som ovenfor, betyder det, at vi kan se og være i stand til at oprette forbindelse til iSCSI-målet. Brug følgende kommando til at oprette forbindelse til iSCSI-målet på lb2:
$ sudo iscsiadm -m node --targetname iqn.2019-02.lb2:odcfs2 -p lb2 -lLogger på [iface:default, target:iqn.2019-02.lb2:odcfs2, portal:192.168.55.102,3260] (multiple)Login til [iface:default, target:iqn.2019-02.lb2:odcfs2, portal:192.168.55.102,3260] vellykket. Sørg for, at du kan se den nye harddisk (/dev/sdb) under /dev-mappen:
$ sudo ls -1 /dev/sd*/dev/sda/dev/sda1/dev/sda2/dev/sda3/dev/sdb Vores delte disk er nu monteret på begge applikationsservere (odoo1 og odoo2).
Konfiguration af OCFS2 til Odoo
** Følgende trin skal udføres på odoo1, medmindre andet er angivet.
OCFS2 giver mulighed for, at filsystemet kan monteres mere end ét sted. Installer OCFS2-værktøjer på både odoo1- og odoo2-servere:
$ sudo apt install -y ocfs2-tools Opret diskpartitionstabel til harddisk /dev/sdb:
$ sudo cfdisk /dev/sdb Opret en partition ved at bruge følgende sekvenser i cfdisk-guiden:Ny> Primær> accepter størrelse> Skriv> ja> Afslut .
Opret et OCFS2-filsystem på /dev/sdb1:
$ sudo mkfs.ocfs2 -b 4K -C 128K -L "Odoo_Cluster" /dev/sdb1mkfs.ocfs2 1.8.5Klyngestak:klassisk o2cbEtiket:Odoo_ClusterFeatures:sparse extended-slotmap-unstrictw backup-en -journal-super xattr indexed-dirs refcount discontig-bg append-dioBlokstørrelse:4096 (12 bits)Klyngestørrelse:131072 (17 bits)Lydstyrkestørrelse:21473656832 (163831 klynger) (5242592 dækgrupper:5242592 dækgrupper:5242592) klynger, restomslag 32256 klynger) Omfangsfordelingsstørrelse:4194304 (1 grupper)Journalstørrelse:134217728Nodepladser:8Oprettelse af bitmaps:færdigInitialisering af superblok:færdigSkrivning af systemfiler:færdigSkrivning af superblok:udførtSkrivning af journal sikkerhedskopiering alt(superblokering:Growning blokerer alt) :færdigFormattering af slotkort:færdigFormattering af kvotefiler:færdigSkrivning tabt+fundet:donemkfs.ocfs2 vellykket Opret en klyngekonfigurationsfil på /etc/ocfs2/cluster.conf og definer node- og klyngedirektiverne som nedenfor:
# /etc/ocfs2/cluster.confcluster:node_count =2 navn =ocfs2node:ip_port =7777 ip_address =192.168.55.111 nummer =1 navn =odoo1 klynge =ocfs2node:ip7_7_port 1.7_port 1.7_port 1.2 =2 navn =odoo2 klynge =ocfs2 Bemærk, at attributterne under noden eller klyngesætningen skal være efter en tabulator.
** Følgende trin skal udføres på odoo1 og odoo2, medmindre andet er angivet.
Opret den samme konfigurationsfil (/etc/ocfs2/cluster.conf) på odoo2. Denne fil bør være den samme på tværs af alle noder i klyngen, og ændringer foretaget i denne fil skal udbredes til de andre noder i klyngen.
Genstart o2cb-tjenesten for at anvende de ændringer, vi lavede i /etc/ocfs2/cluster.conf:
$ sudo systemctl genstart o2cb Opret Odoo-filbiblioteket under /var/lib/odoo:
$ sudo mkdir -p /var/lib/odoo Hent blok-id'et for /dev/sdb1-enheden. UUID anbefales i fstab, hvis du bruger iSCSI-enhed:
$ sudo blkid /dev/sdb1 | awk {'print $3'}UUID="93a2b6c4-d800-4532-9a9b-2d2f2f1a726b" Brug UUID-værdien, når du tilføjer følgende linje i /etc/fstab:
UUID=93a2b6c4-d800-4532-9a9b-2d2f2f1a726b /var/lib/odoo ocfs2 defaults,_netdev 0 0 Registrer ocfs2-klyngen og monter filsystemet fra fstab:
$ sudo o2cb register-cluster ocfs2$ sudo mount -a
Bekræft med:
$ mount | grep odoo/dev/sdb1 på /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) Hvis du kan se ovenstående linje på alle applikationsservere, er vi gode til at installere Odoo.
Installation og konfiguration af Odoo 12
** Følgende trin skal udføres på odoo1 og odoo2, medmindre andet er angivet.
Installer Odoo 12 via pakkelager:
$ 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 opdatering &&sudo apt installer odoo Som standard vil ovenstående kommando automatisk installere PostgreSQL-server på den samme vært som en del af Odoo-afhængigheder. Vi vil sandsynligvis stoppe det, fordi vi alligevel ikke kommer til at bruge den lokale server:
$ sudo systemctl stop postgresql$ sudo systemctl deaktiver postgresql På postgresql1 skal du oprette en databasebruger kaldet "odoo":
$ sudo -i$ su - postgres$ createuser --createrole --createdb --pwprompt odoo Angiv en adgangskode i prompten. På både postgresql1 og postgresql2 skal du tilføje følgende linje inde i pg_hba.conf for at tillade applikations- og belastningsbalancer-noder at forbinde. Som i vores tilfælde er den placeret på /etc/postgresql/11/main/pg_hba.conf:
vært alle alle 192.168.55.0/24 md5 Genindlæs derefter PostgreSQL-serveren for at indlæse ændringerne:
$ su - postgres$ /usr/lib/postgresql/11/bin/pg_ctl genindlæs -D /var/lib/postgresql/11/main/ Rediger Odoo-konfigurationsfilen på /etc/odoo/odoo.conf og konfigurer admin_passwd, db_host og db_password parametrene i overensstemmelse hermed:
[indstillinger]; Dette er adgangskoden, der tillader databaseoperationer:admin_passwd =admins3cr3tdb_host =192.168.55.100db_port =5433db_user =odoodb_password =odoopassword;addons_path =/usr/lib/python3/dist-codes/dist-codes/odoo
Genstart Odoo på begge servere for at indlæse de nye ændringer:
$ sudo systemctl genstart odoo
Åbn Odoo på en af applikationsserverne via webbrowser. I dette eksempel oprettede vi forbindelse til odoo1, så URL'en er http://192.168.55.111:8069/ og du bør se følgende startside:
Angiv "Master Password" identisk med admin_passwd-værdien defineret i Odoo-konfigurationsfilen. Udfyld derefter alle de nødvendige oplysninger for det nye firma, der skal bruge denne platform.
Når du er færdig, skal du vente et øjeblik, indtil initialiseringen er færdig. Du vil blive omdirigeret til Odoo administrations dashboard:
På dette tidspunkt er Odoo-installationen færdig, og du kan begynde at konfigurere business-apps for denne virksomhed. Alle filændringer foretaget af denne applikationsserver vil blive gemt i det klyngede filsystem placeret på "/var/lib/odoo/.local" (som også er monteret på en anden applikationsserver, odoo2), mens ændringer i databasen vil ske på PostgreSQL-masternoden.
På trods af at den kører på to forskellige værter, skal du være opmærksom på, at Odoo-applikationen i sig selv ikke er belastningsbalanceret i denne skrivning. Du kan bruge HAProxy-instanserne, der er implementeret til databaseklyngen, for at opnå bedre tilgængelighed ligesom databasetjenesten. Derudover er det delte disk-filsystem (OCFS2), der bruges af begge applikationsservere, stadig udsat for single-point of failure, da de alle bruger den samme iSCSI-enhed på lb2 (tænk, hvis lb2 er utilgængelig).
Database Failover Operation
Du spekulerer måske på, hvad der ville ske, hvis PostgreSQL-masteren går ned. Hvis det sker, vil ClusterControl automatisk fremme den kørende slave til at blive en master, som vist på skærmbilledet nedenfor:
Der kræves ikke noget fra slutbrugeren, da failover udføres automatisk (efter en henstandsperiode på 30 sekunder). Når failover er fuldført, vil den nye topologi blive rapporteret af ClusterControl som:
Hvis den gamle master kommer op igen, lukkes PostgreSQL-tjenesten automatisk, og den næste ting, brugeren skal gøre, er at synkronisere den gamle master tilbage fra den nye master ved at gå til Node Actions> Rebuild Replication Slave :
Den gamle master bliver derefter slave af den nye master, efter at synkroniseringen er fuldført:
ClusterControl forbedrer helt sikkert databasens tilgængelighed med dens automatiske gendannelsesfunktion, og gensynkronisering af en dårlig databaseknude er simpelthen kun to klik væk. Hvor enkelt er det efter en katastrofal fiasko?
Det var alt for nu folkens. Glædelig klyngedannelse!