Alta disponibilidade
Para criar um ambiente de alta disponibilidade é importante que haja redundância dos servidores das bases de dados e dos Engines. No cenário de utilização do sistema, os principais componentes que demandam atenção são:
- Banco de dados: a interrupção do acesso ao banco de dados impede o uso da maioria das aplicações desenvolvidas no sistema. Somente continuarão funcionando aquelas desenvolvidas especificamente para operações offline, que não dependam dos dados do SGBD e realizem gravações de dados de forma assíncrona via agendamento de scripts.
- Servidores de aplicação: os servidores de aplicação são intermediários no acesso dos servidores de borda e dos Engines instalados nas estações clientes, portanto a interrupção deles afeta o uso geral do sistema, de forma similar a uma interrupção do banco de dados.
- Servidores de borda: a interrupção dos servidores de borda normalmente afeta apenas as unidades de negócio onde eles estão instalados. No entanto, como normalmente são instalados em redes locais que não são conectadas diretamente à rede utilizada pelo banco de dados, a reconstrução do cache local desses Engines pode ser demorada por necessitar de um alto tráfego de dados. Por esse motivo, eles também requerem uma atenção quanto a disponibilidade em bases com cache de dados de tamanho elevado.
Este documento não trata das questões de redundância de infraestrutura, conectividade e de equipamentos, pois atualmente a redundância desses elementos pode ser obtida com facilidade ao se utilizar os principais provedores de computação em nuvem. Serão destacadas apenas as questões relacionadas aos softwares e principalmente a interação deles no contexto de uso do sistema.
Redundância do banco de dados
A configuração de um ambiente de alta disponibilidade do banco de dados é uma atividade realizada por um DBA e normalmente é transparente para o sistema. Deve-se ter atenção ao Oracle e ao Microsoft SQL Server, pois nem todas as edições suportam configurações de alta disponibilidade.
Em relação à configuração do sistema, é recomendado que o endereço do banco de dados seja um nome em vez de um IP, permitindo que a mudança do ambiente principal do banco de dados para o de contingência possa ser realizado via configuração do endereço IP associado ao nome, sem a necessidade de reconfigurar o Manage dos servidores de aplicação.
Além da cópia de dados provida pelo ambiente de contingência, é recomendado que seja criada uma política de backup que mantenha cópias históricas da base de dados para eventuais cenários de sequestro ou exclusão de dados. Essas cópias preferencialmente devem ser gravadas em um ambiente offline ou devem ser protegidas contra exclusões originadas a partir do ambiente de produção ou de contingência.
Importante: em caso de incidentes onde o ambiente de contingência não corresponde fielmente ao último estado do ambiente de produção, seja devido a falhas de sincronização ou a restauração de backups com perda parcial de dados, mesmo que seja por uma defasagem de horas ou de minutos, deve-se descartar o cache local de todos os Engines por meio do processo “Administração do sistema > Cache local > Descarte dos caches de dados e de chaves”. Esse descarte precisa ocorrer antes dos usuários voltarem a utilizar o sistema, caso contrário poderão ser geradas chaves duplicadas no sistema, entre outros problemas de consistência e integridade dos dados. Por esse motivo, é sugerido que a transição entre o ambiente de produção e o de contingência não seja automático, caso não seja possível dar garantia de que os dois ambientes são idênticos quanto aos dados gravados nos bancos de dados.
Redundância dos servidores de aplicação e de borda
Via de regra, os dados do sistema são gravados no banco de dados. Portanto, se este ambiente estiver protegido e for redundante, os demais componentes do sistema podem ser facilmente reestabelecidos, sendo necessário apenas o esforço de reconfiguração do ambiente.
No entanto, para aplicações críticas, o tempo de interrupção para a configuração de um novo ambiente pode ser indesejado ou proibitivo. Para evitar esse prejuízo, deve-se configurar um ambiente com redundância dos servidores de aplicação, evitando tempos de parada para todas as unidades de negócio e usuários externos, e, idealmente, para os servidores de borda, nas unidades de negócio específicas que utilizem esses servidores.
A redundância dos servidores de aplicação e borda pode ser obtida instalando mais de um Engine, idealmente em um servidor distinto, garantindo assim a proteção para falhas de hardware e distribuindo o custo de processamento do sistema. A carga sobre esses vários Engines pode ser distribuída manualmente, por meio de URLs de acesso diferentes, ou pode ser utilizado um balanceador de carga, garantindo que os usuários não precisem alterar o endereço de acesso do sistema em caso de um incidente. Os requisitos e as recomendações de configuração de balanceadores de carga, proxies reversos e demais intermediadores de rede estão detalhados no manual Balanceadores de carga e proxies reversos .
Cópia do cache de dados do Engine
Em servidores distantes do banco de dados, a construção do cache de dados do Engine pode ser uma operação demorada em função da quantidade de registros das tabelas cadastrais e da velocidade da conexão de rede entre o Engine local e o servidor de aplicação. A redundância de Engines no ambiente local diminui o impacto da interrupção de um Engine para uma eventual reconstrução do cache de dados, mas, caso seja importante reestabelecer mais agilmente um Engine, o cache de dados pode ser copiado a partir de um outro Engine em funcionamento. Para isso, devem ser realizados os seguintes passos:
- Interrompa o Engine com o cache de dados a ser copiado.
- Copie o diretório “dbCache” desse Engine para um outro diretório local.
- Reinicie o Engine que teve o cache de dados copiado.
- Mova o diretório “dbCache” copiado no passo 2 para o diretório de instalação do Engine a ser reestabelecido.
- Apague os diretórios “dbCacheProvider” e “dbCacheBackup” que eventualmente possam existir no diretório do Engine a ser reestabelecido.
- Inicie o Engine que recebeu a cópia do cache de dados.
Importante: o diretório de instalação do Engine contém arquivos de controle que devem ser únicos para cada Engine em operação, além de dados de controle como scripts agendados e cache de chaves do sistema que jamais podem ser duplicados. Portanto, nunca copie o diretório de instalação de um Engine com o objetivo de acelerar a inicialização de outro Engine. Para esse fim, apenas o subdiretório “dbCache” é relevante e pode ser copiado com segurança.
Monitoramento do Engine
Para monitoramento do Engine, é recomendado o uso de soluções de monitoramento instaladas diretamente no sistema operacional. Deve ser acompanhada de uma forma geral a carga do servidor, principalmente o uso de CPU, memória, rede e disco.
Para verificar a disponibilidade do sistema em atender requisições, deve ser realizada uma requisição para a URL “/api/service-status/v1/status” nos servidores a serem monitorados. Será retornado o código de status 200 se o Engine estiver apto à atender requisições.
É recomendado que os balanceadores de carga sejam configurados para verificar a disponibilidade do Engine, evitando a distribuição de requisições para Engines em estado de erro ou que ainda estejam em processo de inicialização.