Ir para o conteúdo

Alta disponibilidade

Pode implantar o Drovio Server em alta disponibilidade para evitar qualquer interrupção que degrade a experiência dos utilizadores. O Drovio Server apoia-se para isso no clustering Hazelcast.

Implantar várias instâncias

Implante o Drovio Server em pelo menos duas máquinas distintas. Certifique-se de que cada instância está configurada da mesma forma.

Terá de alojar a base de dados numa máquina à parte, para que seja acessível às duas instâncias. O Drovio Server só suporta PostgreSQL 14 e superior.

Tamanhos dos pools

Defina cuidadosamente os dois tamanhos de pool (pool_options.main.max_size e pool_options.licensing.max_size) em cada instância: a sua soma global deve manter-se inferior ao número máximo de ligações que a sua base pode aceitar. Por exemplo, com max_connections = 60 e duas instâncias, fixe os dois max_size em 15 em cada instância.

Pode obter o valor do máximo de ligações com a ferramenta PostgreSQL psql, através de show max_connections;.

Ativar o clustering

Abra o ficheiro de propriedades do cluster:

/etc/drovio-server/cluster.properties

C:\ProgramData\Drovio\Drovio Server\cluster.properties

Depois:

  • Passe enabled para true.
  • Verifique que config_path designa efetivamente o ficheiro cluster.xml, normalmente situado na mesma pasta que cluster.properties.
  • Preencha host com o IP privado da máquina, aquele que serve para comunicar com os outros membros do cluster, ou 0.0.0.0 para escutar em todas as interfaces disponíveis.
  • Pode deixar port a 0: o Vert.x escolhe automaticamente uma porta livre e o Hazelcast anuncia-a aos outros membros durante a descoberta. Só fixe uma porta se as suas regras de firewall o exigirem.

Configurar o clustering

Abra o ficheiro XML do cluster:

/etc/drovio-server/cluster.xml

C:\ProgramData\Drovio\Drovio Server\cluster.xml

Deve alterar o conteúdo da etiqueta <network></network>, não devendo as outras etiquetas ser tocadas. Várias opções se lhe apresentam então para que as suas instâncias se descubram mutuamente.

O multicast deve estar ativado na sua rede para que isto funcione.

<network>
  <join>
    <multicast enabled="true">
      <multicast-group>224.2.2.3</multicast-group>
      <multicast-port>54327</multicast-port>
    </multicast>
  </join>
</network>

Preencha os IP estáticos dos outros membros, tendo o cuidado de desativar o multicast.

<network>
  <join>
    <multicast enabled="false"/>
    <tcp-ip enabled="true">
      <member>10.12.38.2</member>
      <member>10.12.38.3</member>
    </tcp-ip>
  </join>
</network>

<network>
  <join>
    <multicast enabled="false"/>
    <aws enabled="true">
      <access-key>my-access-key</access-key>
      <secret-key>my-secret-key</secret-key>
      <iam-role>role</iam-role>
      <region>us-west-1</region>
      <host-header>ec2.amazonaws.com</host-header>
      <security-group-name>hazelcast-sg</security-group-name>
      <tag-key>type</tag-key>
      <tag-value>hz-nodes</tag-value>
    </aws>
  </join>
</network>

Todas estas etiquetas são facultativas. Sem access-key nem secret-key, é utilizado o papel IAM, o que é recomendado, e o mesmo se aplica a iam-role. region vale us-east-1 por predefinição, e host-header vale ec2.amazonaws.com, caso em que region não deve ser preenchido. Por fim, security-group-name e depois o par tag-key e tag-value restringem a descoberta às instâncias correspondentes.

O mais simples para começar com a descoberta AWS EC2 é:

  • Criar um papel IAM com a permissão ec2:DescribeInstances.
  • Atribuí-lo a cada instância.
  • Utilizar apenas region, tag-key e tag-value.

Para ir mais longe: README de hazelcast-aws.

Se as máquinas dispuserem de várias interfaces de rede, por exemplo na presença de uma VPN, pode indicar ao Hazelcast qual utilizar com a etiqueta <interface></interface>:

<network>
  <join>
    […]
  </join>
  <interfaces enabled="true">
    <interface>192.168.1.20</interface>
  </interfaces>
</network>

O endereço indicado é o que está associado à sua interface de rede. Para ir mais longe: Hazelcast, mecanismos de descoberta.

Iniciar o cluster

Inicie cada instância uma a uma. Vigie os registos e aguarde uma entrada como a de baixo antes de iniciar a seguinte, em geral uma dezena de segundos entre cada arranque:

Members [2] {
  Member [192.168.1.105]:5701 - 899898be-b8aa-49aa-8d28-40917ccba56c
  Member [192.168.1.105]:5702 - d6b81800-2c78-4055-8a5f-7f5b65d49f30 this
}

Atualizar o cluster

Quando tiver de atualizar o Drovio Server, proceda uma instância de cada vez para evitar qualquer interrupção e para não perder os dados partilhados entre as instâncias. Pare a instância manualmente, consulte os registos da outra instância e aguarde uma entrada deste tipo antes de lançar a atualização:

Members [1] {
  Member [192.168.1.105]:5702 - d6b81800-2c78-4055-8a5f-7f5b65d49f30 this
}

Comutação de endereço (apenas Linux)

O seu cluster funciona, mas as instâncias têm endereços IP diferentes. Vai querer configurar uma comutação de endereço simples, para que um único IP possa designar uma ou outra instância. Em Linux, o keepalived presta-se bem a isso.

O princípio é bastante simples:

  • Para duas instâncias, dispõe de três endereços IP, dos quais um partilhado pelas duas instâncias.
  • Designa a instância principal e a instância de reserva.
  • O IP partilhado, por exemplo 10.0.12.16, designa a instância principal, por exemplo 10.0.12.17.
  • Quando a instância principal cai, o IP partilhado designa então a instância de reserva, por exemplo 10.0.12.18.

O keepalived deve estar implantado em todas as suas instâncias Drovio para que isto funcione.

A comutação de endereço é a solução mais rápida quando quer garantir a disponibilidade do serviço. Quando o clustering está ativado, o Drovio Server já reparte internamente uma boa parte das operações. Em contrapartida, os pedidos HTTP acabam sempre na mesma instância, e as ligações WebSocket que o Drovio Server mantém com os clientes ativos são igualmente suportadas pela mesma instância. Vai portanto provavelmente querer repartir a carga em toda a instalação à medida que a carga e o número de utilizadores aumentam.

Repartição de carga (apenas Linux)

A repartição de carga obtém-se com HAProxy ou Nginx (Plus). O Drovio Server é uma aplicação HTTP e WebSocket. Precisa de pelo menos uma máquina suplementar na qual implantar o HAProxy ou o Nginx.

Warning

Neste cenário, se a máquina de repartição cair, todo o serviço cai com ela. Provavelmente vai querer implantar pelo menos duas máquinas suplementares e combiná-las com uma técnica de comutação como a descrita acima, por exemplo HAProxy e keepalived.

AWS Elastic Load Balancing

Se as instâncias do Drovio Server estiverem implantadas na Amazon AWS, pode montar rapidamente um repartidor com o AWS ELB. Comutação, repartição de carga, WebSockets, tudo é suportado e não exige mais do que alguns cliques. Consulte a documentação AWS, Application Load Balancer.

Drenagem das ligações

Quando tiver de parar uma instância para manutenção, retire-a temporariamente do grupo alvo e aguarde o fim da drenagem antes de a parar realmente. Sem isso, o ELB devolverá respostas HTTP 502 durante cerca de um minuto, estando rompida a ligação persistente com a instância parada.

Resposta multivalor AWS Route 53

Se o seu nome de domínio for gerido pelo AWS Route 53, outra solução é a política de encaminhamento com resposta multivalor. Associado a verificações de saúde, o DNS responde aos pedidos com o IP de uma ou outra instância ainda de pé, até oito, à vez. Ver políticas multivalor e simples.

Note

A ligação entre um cliente Drovio e o cluster demora mais tempo a restabelecer-se do que com o método ELB, cerca de cinco segundos para o ELB contra trinta segundos a um minuto para a resposta multivalor. Em contrapartida, durante a comutação, as sessões de partilha de ecrã em curso não são interrompidas, graças à arquitetura ponto a ponto do Drovio.