Aller au contenu

Haute disponibilité

Vous pouvez déployer Drovio Server en haute disponibilité pour éviter toute interruption qui dégraderait l'expérience des utilisateurs. Drovio Server s'appuie pour cela sur le clustering Hazelcast.

Déployer plusieurs instances

Déployez Drovio Server sur au moins deux machines distinctes. Assurez-vous que chaque instance est configurée de la même façon.

Vous devrez héberger la base de données sur une machine à part, afin qu'elle soit joignable par les deux instances. Drovio Server ne prend en charge que PostgreSQL 14 et supérieur.

Tailles des pools

Réglez soigneusement les deux tailles de pool (pool_options.main.max_size et pool_options.licensing.max_size) sur chaque instance : leur somme globale doit rester inférieure au nombre maximal de connexions que votre base peut accepter. Par exemple, avec max_connections = 60 et deux instances, fixez les deux max_size à 15 sur chaque instance.

Vous pouvez relever la valeur du maximum de connexions avec l'outil PostgreSQL psql, par show max_connections;.

Activer le clustering

Ouvrez le fichier de propriétés du cluster :

/etc/drovio-server/cluster.properties

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

Puis :

  • Passez enabled à true.
  • Vérifiez que config_path désigne bien le fichier cluster.xml, normalement situé dans le même dossier que cluster.properties.
  • Renseignez host avec l'IP privée de la machine, celle qui sert à communiquer avec les autres membres du cluster, ou 0.0.0.0 pour écouter sur toutes les interfaces disponibles.
  • Vous pouvez laisser port à 0 : Vert.x choisit automatiquement un port libre et Hazelcast l'annonce aux autres membres lors de la découverte. Ne fixez un port que si vos règles de pare-feu l'exigent.

Configurer le clustering

Ouvrez le fichier XML du cluster :

/etc/drovio-server/cluster.xml

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

Vous devez modifier le contenu de la balise <network></network>, les autres balises ne devant pas être touchées. Plusieurs options s'offrent alors à vous pour que vos instances se découvrent mutuellement.

Le multicast doit être activé sur votre réseau pour que cela fonctionne.

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

Renseignez les IP statiques des autres membres, en veillant à désactiver le 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>

Toutes ces balises sont facultatives. Sans access-key ni secret-key, le rôle IAM est utilisé, ce qui est recommandé, et il en va de même pour iam-role. region vaut us-east-1 par défaut, et host-header vaut ec2.amazonaws.com, auquel cas region ne doit pas être renseigné. Enfin, security-group-name puis le couple tag-key et tag-value restreignent la découverte aux instances correspondantes.

Le plus simple pour démarrer avec la découverte AWS EC2 est de :

  • Créer un rôle IAM disposant de la permission ec2:DescribeInstances.
  • L'attribuer à chaque instance.
  • N'utiliser que region, tag-key et tag-value.

Pour aller plus loin : README de hazelcast-aws.

Si les machines disposent de plusieurs interfaces réseau, par exemple en présence d'un VPN, vous pouvez indiquer à Hazelcast laquelle utiliser avec la balise <interface></interface> :

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

L'adresse indiquée est celle associée à votre interface réseau. Pour aller plus loin : Hazelcast, mécanismes de découverte.

Démarrer le cluster

Démarrez chaque instance une par une. Surveillez les journaux et attendez une entrée comme celle ci-dessous avant de démarrer la suivante, en général une dizaine de secondes entre chaque démarrage :

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
}

Mettre à jour le cluster

Lorsque vous devez mettre à jour Drovio Server, procédez une instance à la fois pour éviter toute interruption et pour ne pas perdre les données partagées entre les instances. Arrêtez l'instance manuellement, consultez les journaux de l'autre instance et attendez une entrée de ce type avant de lancer la mise à jour :

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

Bascule d'adresse (Linux uniquement)

Votre cluster fonctionne, mais les instances ont des adresses IP différentes. Vous voudrez configurer une bascule d'adresse simple, pour qu'une seule IP puisse désigner l'une ou l'autre instance. Sous Linux, keepalived s'y prête bien.

Le principe est assez simple :

  • Pour deux instances, vous disposez de trois adresses IP, dont une partagée par les deux instances.
  • Vous désignez l'instance maître et l'instance de secours.
  • L'IP partagée, par exemple 10.0.12.16, désigne l'instance maître, par exemple 10.0.12.17.
  • Quand l'instance maître tombe, l'IP partagée désigne alors l'instance de secours, par exemple 10.0.12.18.

keepalived doit être déployé sur toutes vos instances Drovio pour que cela fonctionne.

La bascule d'adresse est la solution la plus rapide quand vous voulez garantir la disponibilité du service. Lorsque le clustering est activé, Drovio Server répartit déjà en interne une bonne partie des opérations. En revanche, les requêtes HTTP aboutissent toujours sur la même instance, et les connexions WebSocket que Drovio Server maintient avec les clients actifs sont elles aussi portées par la même instance. Vous voudrez donc sans doute répartir la charge sur l'ensemble de l'installation à mesure que la charge et le nombre d'utilisateurs augmentent.

Répartition de charge (Linux uniquement)

La répartition de charge s'obtient avec HAProxy ou Nginx (Plus). Drovio Server est une application HTTP et WebSocket. Il vous faut au moins une machine supplémentaire sur laquelle déployer HAProxy ou Nginx.

Warning

Dans ce scénario, si la machine de répartition tombe, tout le service tombe avec elle. Vous voudrez sans doute déployer au moins deux machines supplémentaires et les combiner avec une technique de bascule comme celle décrite plus haut, par exemple HAProxy et keepalived.

AWS Elastic Load Balancing

Si les instances de Drovio Server sont déployées sur Amazon AWS, vous pouvez monter rapidement un répartiteur avec AWS ELB. Bascule, répartition de charge, WebSockets, tout est pris en charge et ne demande que quelques clics. Reportez-vous à la documentation AWS, Application Load Balancer.

Drainage des connexions

Lorsque vous devez arrêter une instance pour maintenance, retirez-la temporairement du groupe cible et attendez la fin du drainage avant de l'arrêter réellement. Sans cela, l'ELB renverra des réponses HTTP 502 pendant environ une minute, la connexion persistante avec l'instance arrêtée étant rompue.

Réponse multivaleur AWS Route 53

Si votre nom de domaine est géré par AWS Route 53, une autre solution est la politique de routage à réponse multivaleur. Associé à des contrôles de santé, le DNS répond aux requêtes avec l'IP de l'une ou l'autre instance encore debout, jusqu'à huit, à tour de rôle. Voir politiques multivaleur et simple.

Note

La connexion entre un client Drovio et le cluster met plus de temps à se rétablir qu'avec la méthode ELB, environ cinq secondes pour l'ELB contre trente secondes à une minute pour la réponse multivaleur. En revanche, pendant le basculement, les sessions de partage d'écran en cours ne sont pas interrompues, grâce à l'architecture pair à pair de Drovio.