PostgreSQL
 sql >> Base de Dados >  >> RDS >> PostgreSQL

Como agrupar o Odoo 12 com a replicação de streaming do PostgreSQL para alta disponibilidade


Odoo (anteriormente conhecido como OpenERP) é um conjunto de aplicativos de negócios de código aberto. Ele vem em duas versões - comunidade e empresa. Alguns dos aplicativos mais populares (e gratuitos!) integrados a esta plataforma são Discussão, CRM, Inventário, Site, Funcionário, Folhas, Recrutamento, Despesas, Contabilidade, Faturamento, Ponto de Venda e muitos mais.

Nesta postagem do blog, veremos como agrupar o Odoo para obter alta disponibilidade e escalabilidade. Este post é semelhante aos nossos posts anteriores sobre dimensionamento de Drupal, WordPress, Magento. Os softwares utilizados são Odoo 12, HAProxy 1.8.8, Keepalived 1.3.9, PostgreSQL 11 e OCFS2 (Oracle Cluster File System).

Nossa configuração consiste em 6 servidores:
  • lb1 (HAProxy) + keepalived + ClusterControl - 192.168.55.101
  • lb2 (HAProxy) + keepalived + armazenamento compartilhado - 192.168.55.102
  • odoo1 - 192.168.55.111
  • odoo2 - 192.168.55.112
  • postgresql1 (mestre) - 192.168.55.121
  • postgresql2 (escravo) - 192.168.55.122

Todos os nós estão sendo executados no Ubuntu 18.04.2 LTS (Bionic). Usaremos o ClusterControl para implantar e gerenciar PostgreSQL, Keepalived e HAProxy, pois isso nos poupará muito trabalho. ClusterControl será co-localizado com HAProxy em lb1 enquanto adicionaremos um disco adicional a lb2 para ser usado como um provedor de armazenamento compartilhado. Este disco será montado usando um sistema de arquivos em cluster chamado OCFS2 como um diretório compartilhado. Um endereço IP virtual, 192.168.55.100 atua como o único ponto de extremidade para nosso serviço de banco de dados.

O diagrama a seguir ilustra nossa arquitetura geral do sistema:

A seguir está o conteúdo de /etc/hosts em todos os nós:
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

Implantando a replicação de streaming do PostgreSQL


Começaremos instalando o ClusterControl em lb1:
$ wget severalnines.com/downloads/cmon/install-cc
$ chmod 755 ./install-cc
$ sudo ./install-cc

Siga o assistente de instalação, você precisará responder algumas perguntas durante o processo.

Configure o SSH sem senha do nó ClusterControl (lb1) para todos os nós que serão gerenciados pelo ClusterControl, que é lb1 (próprio), lb2, postresql1 e postgresql2. Mas primeiro, gere uma chave SSH:
$ whoami
ubuntu
$ ssh-keygen -t rsa # press Enter on all prompts

Em seguida, copie a chave para todos os nós de destino usando a ferramenta 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]

Abra a IU do ClusterControl em http://192.168.55.101/clustercontrol e crie um usuário super admin com senha. Você será redirecionado para o painel da interface do usuário do ClusterControl. Em seguida, implante um novo cluster PostgreSQL clicando no botão "Implantar" no menu superior. Você verá a seguinte caixa de diálogo de implantação:

Aqui está o que digitamos na próxima caixa de diálogo, "Definir servidores PostgreSQL":
  • Porta do servidor:5432
  • Usuário:postgres
  • Senha:s3cr3t
  • Versão:11
  • Datadir:
  • Repositório:Use repositórios de fornecedores

Na seção "Definir topologia", especifique o endereço IP de postgresql1 e postgresql2 de acordo:

Na última seção "Resumo da implantação", você tem a opção de habilitar a replicação síncrona. Como usaremos o escravo apenas para fins de failover (o escravo não servirá para nenhuma operação de leitura), apenas deixamos o valor padrão como está. Em seguida, pressione "Implantar" para iniciar a implantação do cluster de banco de dados. Você pode monitorar o progresso da implantação consultando Atividade> Trabalhos> Criar cluster :

Enquanto isso, pegue um café e a implantação do cluster deve ser concluída em 10 a 15 minutos.

Implantação de balanceadores de carga e IP virtual para servidores PostgreSQL


Neste ponto, já temos um cluster de replicação PostgreSQL de dois nós em execução em uma configuração mestre-escravo:

A próxima etapa é implantar a camada do balanceador de carga para nosso banco de dados, o que nos permite vincular o endereço IP virtual e fornecer um único ponto de extremidade para o aplicativo. Vamos configurar as opções de implantação do HAProxy conforme abaixo:

O aplicativo não oferece suporte nativo à divisão de leitura e gravação, portanto, usaremos o método ativo-passivo para obter alta disponibilidade. O melhor algoritmo de balanceamento de carga é a política "source", pois estamos usando apenas um nó PostgreSQL por vez.

Repita a mesma etapa para o outro balanceador de carga, lb2. Altere o "Endereço do servidor" para 192.168.55.102. Aqui está o que parece após a conclusão da implantação, se você for na página Nós:

A linha vermelha no primeiro ouvinte é esperada onde o HAProxy mostra que o postgresql2 (192.168.55.122) está inativo porque o script de verificação de integridade retorna que o nó está ativo, mas não um mestre. O segundo ouvinte com linha azul (haproxy_5434_ro) mostra que o nó está UP, mas no estado "backup". Esse ouvinte pode ser ignorado, pois o aplicativo não oferece suporte à divisão de leitura e gravação.

Em seguida, implantamos instâncias Keepalived nesses balanceadores de carga para vinculá-los a um único endereço IP virtual. Vá para Gerenciar -> Load Balancer -> Keepalived -> Implantar Keepalived e especifique a primeira e a segunda instâncias do HAProxy e, em seguida, o endereço IP virtual e a interface de rede para escutar:

Clique em "Implantar Keepalived" para iniciar a implantação. O serviço de conexão PostgreSQL agora tem balanceamento de carga para qualquer um dos nós do banco de dados e pode ser acessado pela porta 5433 192.168.55.100.

Configurando iSCSI


O servidor de armazenamento (lb2) precisa exportar um disco por meio de iSCSI para que possa ser montado em ambos os servidores de aplicativos Odoo (odoo1 e odoo2). O iSCSI basicamente informa ao seu kernel que você tem um disco SCSI e transporta esse acesso por IP. O “servidor” é chamado de “destino” e o “cliente” que usa esse dispositivo iSCSI é o “iniciador”.

Em primeiro lugar, instale o destino iSCSI em lb2:
$ sudo apt install -y tgt

Habilite o tgt na inicialização:
$ systemctl enable tgt

É preferível ter um disco separado para cluster do sistema de arquivos. Assim, vamos utilizar outro disco montado em lb2 (/dev/sdb) para ser compartilhado entre os servidores de aplicação (odoo1 e odoo2). Em primeiro lugar, crie um destino iSCSI usando a ferramenta tgtadm:
$ sudo tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.2019-02.lb2:odcfs2

Em seguida, atribua o dispositivo de bloco /dev/sdb ao número de unidade lógica (LUN) 1 junto com o ID de destino 1:
$ sudo tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/sdb

Em seguida, permita que os nós iniciadores na mesma rede acessem este destino:
$ sudo tgtadm --lld iscsi --op bind --mode target --tid 1 --initiator-address 192.168.55.0/24

Use a ferramenta tgt-admin para despejar as linhas de configuração iSCSI e salvá-lo como um arquivo de configuração para torná-lo persistente durante a reinicialização:
$ sudo tgt-admin --dump > /etc/tgt/conf.d/shareddisk.conf

Por fim, reinicie o serviço de destino iSCSI:
$ sudo systemctl restart tgt

** As etapas a seguir devem ser executadas em odoo1 e odoo2.

Instale o iniciador iSCSI nos respectivos hosts:
$ sudo apt-get install -y open-iscsi

Configure o iniciador iSCSI para iniciar automaticamente:
$ sudo systemctl enable open-iscsi

Descubra os destinos iSCSI que configuramos anteriormente:
$ sudo iscsiadm -m discovery -t sendtargets -p lb2
192.168.55.102:3260,1 iqn.2019-02.lb2:odcfs2

Se você vir um resultado semelhante ao acima, significa que podemos ver e nos conectar ao destino iSCSI. Use o seguinte comando para se conectar ao destino iSCSI em 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.

Verifique se você pode ver o novo disco rígido (/dev/sdb) listado no diretório /dev:
$ sudo ls -1 /dev/sd*
/dev/sda
/dev/sda1
/dev/sda2
/dev/sda3
/dev/sdb

Nosso disco compartilhado agora está montado em ambos os servidores de aplicativos (odoo1 e odoo2).

Configurando o OCFS2 para Odoo


** As etapas a seguir devem ser executadas no odoo1, a menos que especificado de outra forma.

O OCFS2 permite que o sistema de arquivos seja montado em mais de um local. Instale as ferramentas OCFS2 nos servidores odoo1 e odoo2:
$ sudo apt install -y ocfs2-tools

Crie uma tabela de partição de disco para a unidade de disco rígido /dev/sdb:
$ sudo cfdisk /dev/sdb

Crie uma partição usando as seguintes sequências no assistente do cfdisk:Novo> Primário> aceitar Tamanho> Gravar> sim> Sair .

Crie um sistema de arquivos OCFS2 em /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

Crie um arquivo de configuração de cluster em /etc/ocfs2/cluster.conf e defina as diretivas de nó e cluster conforme abaixo:
# /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

Observe que os atributos sob a cláusula de nó ou cluster precisam estar após uma guia.

** As etapas a seguir devem ser executadas em odoo1 e odoo2, a menos que especificado de outra forma.

Crie o mesmo arquivo de configuração (/etc/ocfs2/cluster.conf) no odoo2. Esse arquivo deve ser o mesmo em todos os nós do cluster e as alterações feitas nesse arquivo devem ser propagadas para os outros nós do cluster.

Reinicie o serviço o2cb para aplicar as alterações que fizemos em /etc/ocfs2/cluster.conf:
$ sudo systemctl restart o2cb

Crie o diretório de arquivos Odoo em /var/lib/odoo:
$ sudo mkdir -p /var/lib/odoo

Obtenha o ID do bloco para o dispositivo /dev/sdb1. O UUID é recomendado no fstab se você usar o dispositivo iSCSI:
$ sudo blkid /dev/sdb1 | awk {'print $3'}
UUID="93a2b6c4-d800-4532-9a9b-2d2f2f1a726b"

Use o valor UUID ao adicionar a seguinte linha em /etc/fstab:
UUID=93a2b6c4-d800-4532-9a9b-2d2f2f1a726b       /var/lib/odoo     ocfs2   defaults,_netdev        0 0

Registre o cluster ocfs2 e monte o sistema de arquivos do fstab:
$ sudo o2cb register-cluster ocfs2
$ sudo mount -a

Verifique com:

$ 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 você puder ver a linha acima em todos os servidores de aplicativos, é bom instalar o Odoo.

Instalando e configurando o Odoo 12


** As etapas a seguir devem ser executadas em odoo1 e odoo2, a menos que especificado de outra forma.

Instale o Odoo 12 através do repositório de pacotes:
$ 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

Por padrão, o comando acima instalará automaticamente o servidor PostgreSQL no mesmo host como parte das dependências do Odoo. Provavelmente queremos pará-lo porque não vamos usar o servidor local de qualquer maneira:
$ sudo systemctl stop postgresql
$ sudo systemctl disable postgresql

No postgresql1, crie um usuário de banco de dados chamado "odoo":
$ sudo -i
$ su - postgres
$ createuser --createrole --createdb --pwprompt odoo

Especifique uma senha no prompt. Em seguida, em postgresql1 e postgresql2, adicione a seguinte linha dentro de pg_hba.conf para permitir que o aplicativo e os nós do balanceador de carga se conectem. Como no nosso caso, está localizado em /etc/postgresql/11/main/pg_hba.conf:
host  all  all       192.168.55.0/24    md5

Em seguida, recarregue o servidor PostgreSQL para carregar as alterações:
$ su - postgres
$ /usr/lib/postgresql/11/bin/pg_ctl reload -D /var/lib/postgresql/11/main/

Edite o arquivo de configuração do Odoo em /etc/odoo/odoo.conf e configure os parâmetros admin_passwd, db_host e db_password de acordo:
[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

Reinicie o Odoo em ambos os servidores para carregar as novas alterações:
$ sudo systemctl restart odoo

O, abra o Odoo em um dos servidores de aplicativos via navegador da web. Neste exemplo, conectamos a odoo1, portanto, a URL é http://192.168.55.111:8069/ e você deve ver a seguinte página inicial:

Especifique a "Senha Mestra" idêntica ao valor admin_passwd definido no arquivo de configuração do Odoo. Em seguida, preencha todas as informações necessárias para a nova empresa que vai utilizar esta plataforma.

Feito isso, aguarde um momento até que a inicialização termine. Você será redirecionado para o painel de administração do Odoo:

Neste ponto, a instalação do Odoo está concluída e você pode começar a configurar os aplicativos de negócios para esta empresa. Todas as alterações de arquivo feitas por este servidor de aplicação serão armazenadas dentro do sistema de arquivos em cluster localizado em "/var/lib/odoo/.local" (que também montado em outro servidor de aplicação, odoo2), enquanto as alterações no banco de dados estarão acontecendo no nó mestre do PostgreSQL.

Apesar de ser executado em dois hosts diferentes, observe que o aplicativo Odoo em si não possui balanceamento de carga neste artigo. Você pode usar as instâncias do HAProxy implantadas para o cluster de banco de dados para obter melhor disponibilidade, assim como o serviço de banco de dados. Além disso, o sistema de arquivos de disco compartilhado (OCFS2) usado por ambos os servidores de aplicativos ainda está exposto a um único ponto de falha, pois todos estão usando o mesmo dispositivo iSCSI em lb2 (imagine se lb2 estiver inacessível).

Operação de failover do banco de dados


Você pode estar se perguntando o que aconteceria se o mestre do PostgreSQL fosse desativado. Se isso acontecer, o ClusterControl promoverá automaticamente o escravo em execução para se tornar um mestre, conforme mostrado na captura de tela abaixo:

Não é necessário fazer nada do usuário final, pois o failover é executado automaticamente (após um período de carência de 30 segundos). Após a conclusão do failover, a nova topologia será relatada pelo ClusterControl como:

Se o mestre antigo voltar a funcionar, o serviço PostgreSQL será encerrado automaticamente e a próxima coisa que o usuário deve fazer é ressincronizar o mestre antigo com o novo mestre indo para Node Actions> Rebuild Replication Slave :

O antigo mestre se tornará escravo do novo mestre após a conclusão da operação de sincronização:

O ClusterControl certamente melhora a disponibilidade do banco de dados com seu recurso de recuperação automática e a ressincronização de um nó de banco de dados ruim está a apenas dois cliques de distância. Quão simples é isso após um evento de falha catastrófico?

Por enquanto é só pessoal. Boa aglomeração!