O servidor de licenças oferece suporte a instâncias globais da Control Room com alta disponibilidade e recursos de recuperação de desastres. Verificações regulares de saúde dos aplicativos acionam processos de failover para manter a continuidade do serviço.

O License Server (LS) é hospedado centralmente nos EUA. Todas as instâncias da Control Room ao redor do mundo que estão usando licença baseada em GUID ou licença em nuvem se conectam a esse servidor. Sendo um serviço essencial, o servidor de licenças possui alta disponibilidade e recursos de recuperação de desastres. O diagrama abaixo ilustra a arquitetura detalhada do nível de infraestrutura. Para obter mais informações sobre licença em nuvem, consulte Perguntas frequentes sobre licenciamento em nuvem.

Considere duas regiões, a do Oregon (primária) e a da Virgínia (reserva). A região da Virgínia em espera tem um trabalho de worker que verifica regularmente a integridade do aplicativo e do banco de dados da região primária do Oregon. O diagrama abaixo é sobre o estado ideal.

Estado ideal do servidor de licença

Se o aplicativo não estiver respondendo, o servidor verificará o banco de dados mestre primário. Se tanto o aplicativo quanto o banco de dados falharem repetidamente nas verificações de integridade, o trabalho de worker iniciará um processo de failover.

Os três cenários a seguir podem acionar o estado de recuperação de desastres e iniciar o processo de failover:
  • Se o aplicativo primário estiver inativo (todos os 3 dynos estão inativos), mas o banco de dados mestre estiver ativo, o trabalho de worker não realizará nenhuma ação. No entanto, o sistema de alerta e monitoramento notifica a equipe.
  • Se o aplicativo principal estiver ativo, mas o banco de dados mestre estiver inativo, o Heroku atribuirá automaticamente um banco de dados em espera de outra zona de disponibilidade na mesma região.
  • Se o aplicativo principal e o banco de dados mestre estiverem inativos, o trabalho de worker acionará o script de failover.
Se um dos três cenários mencionados acima ocorrer, o script de failover será ativado e o fluxo de trabalho a seguir será implementado:
  • O banco de dados seguidor na região da Virgínia sincroniza todos os commits com o banco de dados mestre na região do Oregon e, em seguida, deixa de segui-lo.
  • O banco de dados na região da Virgínia se torna o novo banco de dados mestre.
  • O aplicativo da Virgínia se conecta ao novo banco de dados mestre na região da Virgínia.
  • O Web Application Firewall (WAF) se conecta ao roteador do aplicativo Virginia.
  • A conexão entre o WAF e Oregon é removida.
Estado de recuperação de desastres do servidor de licenças

Quando a região do Oregon se torna ativa novamente, é necessária uma intervenção manual (de reconexão do Web Application Firewall (WAF)) para restaurar o Oregon como o aplicativo principal.