Alta disponibilidade com nós de aplicação

Como funciona

A alta disponibilidade permite que a produção de uma base de dados Odoo corra em vários servidores ao mesmo tempo. Se um servidor deixar de responder, os visitantes são enviados para os outros.

Um cluster é composto por projetos que correm o mesmo código:

• O principal: um projeto cuja instância de produção corre o Odoo e a base de dados. A sua base de dados fica aberta aos nós de aplicação, e a mais ninguém.
• Nós de aplicação: outros projetos, cada um num servidor de produção diferente, cuja instância de produção corre apenas o Odoo e usa a base de dados do principal.

Os visitantes usam o endereço do principal. O CICDoo aponta esse endereço para o principal e para cada nó de aplicação que esteja a responder, e verifica cada nó a cada poucos minutos. Um nó que deixe de responder é retirado do endereço até recuperar.

A base de dados continua a correr num único servidor, o do principal. Os nós de aplicação tornam a parte do Odoo redundante; se o servidor do principal for abaixo, o site vai abaixo com ele.

Antes de começar

• Mesmo código: todos os projetos de um cluster têm de usar o mesmo repositório, o mesmo ramo predefinido, a mesma versão do Odoo e a mesma edição. Se o Time Machine estiver ativo, os commits fixados também têm de coincidir.
• Servidores diferentes: cada nó de aplicação tem de ter o seu próprio servidor de produção, diferente do do principal e dos dos outros nós.
• Proxy do Cloudflare: a distribuição do tráfego pelos nós funciona atualmente em servidores que têm o proxy do Cloudflare ativo. Usa servidores da mesma região, já que cada página servida por um nó de aplicação comunica com a base de dados do principal.
• Filestore partilhado: cada servidor do cluster tem de montar o mesmo armazenamento partilhado para o filestore do Odoo. Sem isso, um anexo carregado através de um nó não existe nos outros, e um visitante que chegue a outro nó perde a sessão. Pede ajuda ao suporte se precisares de ajuda para configurar isto.
• Ligações à base de dados: cada nó de aplicação abre as suas próprias ligações à base de dados do principal. À medida que adicionas nós, aumenta max_connections na Configuração do PostgreSQL da instância de produção do principal, no separador Definições da sua consola.

As definições de alta disponibilidade estão em Definições do projeto, no separador Avançado, no cartão Alta disponibilidade. Precisas de permissão para alterar as definições do projeto.

Configurar o principal

Abre o projeto que vai correr a base de dados, vai a Definições do projeto > Avançado e, em Alta disponibilidade, define Função como Principal (aplicação + base de dados). Clica em Aplicar e confirma.

A instância de produção reinicia. Quando volta, a sua base de dados aceita ligações dos nós de aplicação do cluster. As ligações entre servidores são cifradas, a menos que os teus servidores partilhem uma rede privada.

A instância de produção tem de usar a sua própria base de dados incluída. Um projeto cuja instância de produção aponta para uma base de dados externa não pode ser principal.

Adicionar um nó de aplicação

Cria um projeto para o nó como farias normalmente: mesmo repositório e mesmo ramo predefinido, mesma versão e edição, e um servidor de produção só seu. Remove as instâncias de staging e de desenvolvimento que tenha: um nó de aplicação só corre produção, e os ramos de staging e de desenvolvimento ficam no projeto principal.

Depois abre as Definições do projeto > Avançado do nó, define Função como Nó de aplicação (usa a base de dados de um principal), escolhe o principal em Origem da base de dados, clica em Aplicar e confirma. Só são apresentados principais do mesmo espaço de trabalho que correm o mesmo código.

O nó não arranca de imediato. Primeiro o servidor do principal tem de o deixar entrar, o que acontece na sua próxima verificação, normalmente em cinco minutos. Até lá o cartão mostra "A aguardar que o principal permita este nó", e o nó arranca sozinho assim que for permitido. Alguns minutos depois de responder, começa a receber visitantes.

No principal, o cartão Alta disponibilidade lista os seus nós de aplicação e se o servidor da base de dados já aplicou a lista de acesso atual.

O que muda num nó de aplicação

• A sua instância de produção não tem base de dados própria. As definições da sua base de dados são geridas pelo CICDoo e não podem ser alteradas na configuração do Odoo da instância.
• As tarefas agendadas (crons do Odoo) só correm no principal.
• As cópias de segurança são feitas no principal. Faz cópias de segurança e restauros da base de dados do cluster a partir do projeto principal.
• Fazer push para o ramo de um nó de aplicação não faz nada por si só. O cluster é atualizado a partir do principal.

Fazer deploy de atualizações

Faz push para o ramo do principal como de costume. O CICDoo atualiza então todo o cluster por ordem:

1. Cada nó de aplicação é parado.
2. O principal é atualizado, incluindo qualquer atualização de módulos, enquanto nenhum outro servidor está a usar a base de dados.
3. Cada nó de aplicação é arrancado de novo com o código novo.

Podes acompanhar cada passo no separador Fila da instância onde corre. Se a atualização do principal falhar, os nós de aplicação não voltam a arrancar, e as suas entradas na fila indicam porquê. Corrige o problema e faz deploy de novo.

Como as atualizações de módulos precisam da base de dados só para si, o site fica indisponível enquanto o principal é atualizado, tal como acontece com uma única instância.

Sair de um cluster

Para remover um nó de aplicação, volta a definir a sua Função como Autónomo (base de dados própria) e clica em Aplicar. A sua instância de produção para, porque a sua própria base de dados não contém os dados do cluster. Restaura uma cópia de segurança nela antes de a voltar a arrancar.

Um principal não pode ser alterado enquanto ainda tiver nós de aplicação. Remove primeiro os nós.

Resolução de problemas

• O nó continua à espera de ser permitido: verifica se a instância de produção do principal está a correr e se o seu servidor está online. O principal tem de reiniciar uma vez depois de se tornar principal antes de algum nó ser permitido.
• O nó arranca mas o Odoo não sobe: abre os registos do nó. Uma mensagem a dizer que a base de dados do principal não está inicializada significa que o principal ainda não terminou o seu primeiro arranque.
• Os carregamentos ou as sessões não acompanham os visitantes entre nós: os servidores não estão a partilhar o filestore. Consulta "Antes de começar" acima.

Consulta Ramos e instâncias para saber como as instâncias correspondem aos ramos, e Utilizar um balanceador de carga para a definição de balanceador de carga ao nível do servidor, que é uma funcionalidade diferente.