26 août 2016

Vert.x Basics : haute disponibilité et failover

Design & Code

Grow

Together

26 août 2016

Vert.x Basics : haute disponibilité et failover

Design & Code

Grow

Together

26 août 2016

Vert.x Basics : haute disponibilité et failover

Design & Code

Grow

Together

Vert.x permet d’exécuter les verticles avec l’option de haute disponibilité grâce au mécanisme de failover. Cette option de haute disponibilité est utilisable entres plusieurs instances de Vert.x faisant parti d’un même cluster.

Concrètement, cela se manifeste comme suit : lorsqu’un verticle est déployé avec l’option de haute disponibilité(ha) dans une instance de Vert.x et que cette instance de Vert.x s’arrête de façon inattendue (pas suite à un CTRL-C), alors le mécanisme de failover est enclenché et une autre instance de Vert.x en cours d’exécution déploie le verticle (le déploiement échoue si l’instance de Vert.x n’a pas accès au code du verticle).

Le listing 2.9 montre comment lancer par programmation des verticles en mode ha. Comme la plupart des options, le mode ha peut être activé avec l’outil de ligne de commande de Vert.x : http://vertx.io/docs/vertx-core/java/#_high_availability_and_fail_over.


Listing 2‑9 Lancement du verticle HelloWorld en mode HA

A la ligne 2 du listing, on définit un objet VertxOptions en activant l’option ha :

Ensuite il faut démarrer Vert.x en mode cluster :


Pour démarrer en mode cluster de cette façon, il faut qu’un gestionnaire de cluster soit disponible dans le classpath, à défaut de quoi le démarrage échouera. On peut utiliser Hazelcast, le gestionnaire de cluster historique de Vert.x :


Ce n’est pas fini, il faut aussi activer l’option ha dans les options de déploiement du verticle :


Nous allons déployer le verticle GreetingService sur un second nœud Vert.x en mode ha :


Une fois le second nœud démarré, on peut voir dans les logs :

Figure 2‑6 Logs sur le cluster et le mode HA

Pour voir le failover à l’œuvre, arrêtons un des nœuds*, j’ai choisi le nœud contenant le verticle GreetingService, et observons ce qui se passe dans les logs du nœud restant. Nous voyons d’abord que le gestionnaire de cluster fait le ménage après la disparition du second nœud :

*Il semble qu’un arrêt « propre » ne provoquera pas de failover, c’est-à-dire un Ctrl-C : http://vertx.io/docs/vertx-core/java/#_high_availability_and_fail_over

Figure 2‑7 Réaction du gestionnaire de cluster à la disparition d'un noeud

Ensuite c’est autour du gestionnaire ha de mettre en œuvre le failover :

Figure 2‑8 Mise en œuvre du failover

Il existe un type de nœud Vert.x particulier appelé instance bare (car ne contenant aucun déploiement de verticle). En démarrant un tel nœud en mode ha, il peut aussi mettre en œuvre le failover pour redéployer les verticles d’un nœud tombé.

Le mode ha comporte d’autres notions intéressantes comme les groupes HA et les quorums. Rapidement, les groupes ha permettent de définir des sous-ensembles spécifiques de nœuds du cluster entre lesquels appliquer le failover. Et les quorums définissent le nombre minimal de nœuds requis dans le cluster par un nœud pour déployer un verticle lorsque le mode ha est activé.