ARION ENTERPRISE LTE 19-03-2025

Para oferecer uma solução mais robusta e eficiente, apresento detalhes sobre a estrutura enterprise. Também abordarei as principais questões sobre a solução, com o objetivo de aprimorar o discurso de vendas deste produto.

Estudo de Caso: Arquitetura Novo Arion Enterprise

A arquitetura do Novo Arion Enterprise é composta por uma estrutura de três servidores, projetada para garantir a alta disponibilidade e o balanceamento de carga nas aplicações. O fluxo de comunicação entre os componentes é detalhado da seguinte forma:

1. Servidores de Aplicação: O sistema é composto por dois servidores de aplicação, que executam as funções principais das aplicações. Ambos os servidores de aplicação estão configurados para compartilhar a carga de trabalho, garantindo que, em caso de falha de um dos servidores, o outro continue a atender as requisições dos usuários, proporcionando alta disponibilidade.

2. Servidor de Banco de Dados: Um terceiro servidor é dedicado exclusivamente ao banco de dados, centralizando as informações e garantindo a integridade e a segurança dos dados manipulados pelas aplicações. Este servidor recebe as mensagens de ambos os servidores de aplicação, assegurando a comunicação contínua entre a camada de aplicação e a base de dados.

3. Middleware Keepalived: O sistema faz uso de um middleware denominado Keepalived, responsável pelo gerenciamento do balanceamento de carga. Através de um IP virtual, os usuários acessam a aplicação web. O Keepalived, em conjunto com os servidores de aplicação, realiza o controle de acesso, direcionando as requisições para o servidor de aplicação ativo, com base na disponibilidade e na carga do servidor. Essa funcionalidade garante que o tráfego seja distribuído de forma eficiente e que a experiência do usuário seja agradável.

4. Protocolo VRRP: O keepalived utiliza o protocolo VRRP (Virtual Router Redundancy Protocol) os servidores se comunicam entre si utilizando o keepalived, a partir do momento que um deles para de enviar essa mensagem (seja por problema no servidor, falha na rede, etc) o outro assume. Essa arquitetura foi projetada para oferecer uma solução escalável, resiliente e com alta disponibilidade, garantindo a continuidade das operações e a mínima interrupção no serviço, mesmo diante de falhas em componentes individuais.

Arquitetura:

Open

Principais dúvidas:

1. Como server Keepalived identifica a que o server 01 está indisponível, somente em caso de desligamento? A configuração atual do KeepAlived que usamos usa VRRP (Virtual Router Redundancy Protocol) o que significa que, o servidor master(01) precisa enviar uma informação via VRRP e caso ele não envie significa que ele está down e assim quem assume a liderança é o servidor que está como Backup(02), tanto falha crítica quanto problemas na interface de rede fazem com que a troca seja feita.

2. Em caso de falha no server 01,  e o server 02 assuma como host principal,  como a integração com o TP se comporta, teremos que recarregar a aplicação? Em testes realizados a integração não sofre queda neste cenário, não é necessário reiniciar.

3. Em caso de falha no server 01, e o server 02 assuma como host principal,   como a integração com o Neoexpress se comporta, teremos que recarregar a aplicação? Em testes realizados a aplicação do Neo não acusou nada, e não foi preciso reiniciar a aplicação após o failover (se recuperou sozinho).

4. Em caso de falha no server 01, e o server 02 assuma como host principal, como se comporta a sessão do usuário, o mesmo terá que logar novamente? Precisa dar um refresh na tela? Se não salvou antes da queda, perde as informações e tudo que for escrito após a queda (antes de logar) não será salvo, o comportamento de refresh é explicado mais abaixo.

5. Caso o usuário esteja digitando um texto e no meio do processo houver uma interrupção do serviço, ele perderá o texto? Se não tiver salvo, sim.

6. Em caso de falha no server 01, e o server 02 assuma como host principal, existe alguma mensagem a ser apresentada para o usuário? Sim antes do failover irá apresentar uma informação de falha no sistema, assim que o servidor backup assumir o usuário vai receber uma informação que a sessão está expirada e será necessário recarregar a página para acessar novamente.

7. Em caso de falha no servidor de banco de dados, como a aplicação se comporta, é apresentada alguma mensagem para o usuário? Sim é apresentada uma mensagem de erro, e o login se torna impossível, neste caso é preciso seguir esta documentação para a resolução do problema Atuação em caso de queda do server DB.

8. Se tratando do recurso de hardware do servidor, qual o intervalo seguro da rotina de backup em um cenário onde teremos 100 usuários logados no ambiente, sendo que esta rotina não compromete o desempenho da aplicação? A rotina de backup a princípio não onera o servidor, porém em testes realizados o período seguro de backup é a cada 15 minutos, abaixo disso dependendo do tamanho da base pode causar uma bagunça na organização dos arquivos nas pastas compartilhadas, testes realizados com base de 1.2GB.

9. Em caso de falha no servidor de banco de dados, qual o tempo médio para fazer o restore da base de dados nos host´s 01 ou 02? levando em consideração que os acessos estarão disponíveis. Não existe uma média para que o backup seja restaurado pois isto depende de fatores como o tamanho do backup e o entendimento do analista sobre o problema, porém em testes realizados com bases de 1GB o tempo médio que leva desde a fase de restaurar o backup até o sistema 100% operacional em torno de 20 minutos seguindo a documentação.

10. Em caso de falha no server 01, o server 02 irá assumir conforme regras definidas no keep alive. Como proceder quando server01 estiver ON, esse retorno é automático?  Essa dúvida se estende para toda a solução, inclusive para o banco de dados. Em caso de falha apenas entre os servidores (excluindo o server DB) assim que o server 1 voltar ele já assume como líder automaticamente (levando em consideração que não houve troca de máquina, se houve é preciso reconfigurar o keepalived nessa máquina nova), assim que ele assumir como líder os usuários receberão uma mensagem de sessão expirada e precisarão refazer o login, no cenário de problema no serverDB será necessário realizar o procedimento desta documentação (Atuação em caso de queda do server DB) para configurar o novo serverDB em caso de falha com perda de hardware e ou falha momentânea.

Conclusão:

A criação de uma nova versão do Arion Enterprise, mais simplificada e robusta, surge como uma solução estratégica para resolver esses desafios, proporcionando uma infraestrutura mais eficiente e de fácil manutenção, alinhada às necessidades crescentes do cliente. A transição para essa nova arquitetura não apenas trará uma melhora significativa no desempenho, como também garantirá maior estabilidade e confiabilidade ao sistema. Estamos confiantes de que as mudanças propostas resultarão em um ambiente mais estável, seguro e ágil, o que, sem dúvida, contribuirá para a otimização das operações dos clientes e para a continuidade do excelente serviço prestado pela Snews.

 Artigos relacionados