Dans un précédent article, nous avons installé un runtime d’intégration auto-hébergé permettant le transfert de données locales vers Azure. Nous avions évoqué dans les options avancées, la possibilité de faire de la haute disponibilité pour notre runtime.
Nous allons dans cet article configurer la haute disponibilité sur notre runtime d’intégration en installant un nouveau nœud pour créer un cluster d’IR ! Nous rendrons donc notre installation robuste à la perte d’une machine, tout en améliorant les performances globales de ce runtime d’intégration.
Prérequis & considération
Prérequis
Afin de créer un cluster de runtime, nous partons d’une situation ou nous avons déjà installé un runtime « simple ». Si ce n’est pas déjà fait, vous pouvez consulter l’article suivant :
Configurer un runtime dans Synapse pour la connexion à une base de données On-Prem – NiceData
Considérations
Une instance par machine
Il n’est pas possible d’installer deux instances de runtime d’intégration sur le même ordinateur / serveur. Dans notre cas de figure, cela pourrait se comprendre, car si nous installons nos deux runtime sur la même machine, la haute disponibilité et l’augmentation des performances ne seraient qu’illusoires puisque partagées sur la même machine.
Il est cependant envisageable de créer des machines virtuelles et d’installer un runtime sur différentes VM. Il faudra dans ce cas comprendre les implications liées à l’infrastructure sous-jacente pour être sur de l’augmentation possible des performances ainsi que de la « véracité » de la « Haute-dispo ».
Version de service
Aussi, il est nécessaire d’utiliser la même version de runtime sur l’ensemble des nœuds du cluster. Pour s’en assurer, vous pouvez utiliser le même fichier d’installation utilisé pour le premier nœud. Ou bien, s’assurer de la version actuelle est aller télécharger la même version.
Adaptation pour notre tutoriel
Suite aux considérations évoquées plus haut, je ne suis pas en mesure d’utiliser l’environnement créé dans le post précédent pour y ajouter un nœud et je vais donc utiliser un autre environnement qui possède déjà son propre runtime sur une machine indépendante pour rajouter un nœud hébergé sur mon poste de Dev. Cela ne change absolument rien à la procédure, mais il ne faut pas s’étonner que le nom de mon workspace et de mon runtime ne soient pas les mêmes que précédemment.
Configuration et installation
Configuration du nœud actuel
Pour l’installation de notre cluster, nous allons procéder dans un premier temps à la modification d’un paramètre de notre runtime actuel. Pour la configuration du cluster, il est nécessaire que le runtime ait le paramètre « Accès à distance à partir de l’internet » activé. Par défaut celui-ci ne l’est pas :
La configuration s’effectue sur la machine hôte du runtime, dans le gestionnaire de configuration du runtime dans la section « Paramètres ».
Il est de plus important de faire ceci AVANT la configuration du 2ème nœud, car ce paramètre est obligatoire pour le bon fonctionnement général.
Si vous avez des considérations de sécurité spécifique, il peut être nécessaire de configurer le certificat de sécurité et le port de connexion. Dans notre cas, nous allons utiliser la configuration « standard », qui reste cependant chiffrée pour la communication « Nœud – Cloud ».
Pour application du paramètre, il nous faudra redémarrer le service. Ce qui rendra notre Intégration runtime inaccessible pendant ce temps. Attention lors de ce paramétrage en Production donc !
La configuration de notre nœud de runtime existant est maintenant valide pour notre cluster.
Installation du nouveau nœud
Comme pour de nombreux outils Microsoft, lors de l’exécution du fichier .msi d’installation nous allons être guidé par de joli wizzard le long de notre installation
Nous allons accepter le Contrat de Licence Utilisateur Final (qui est le même que pour l’installation du premier nœud)
Nous choisissons le dossier d’installation
Et l’installation commencera
Nous allons maintenant rentrer dans le vif du sujet ! L’inscription du runtime à notre runtime existant.
Nous allons avoir besoin de la clef d’accès de notre runtime. Et nous allons « simplement » utiliser la clef de notre runtime existant. La clef en question se trouve dans la page de configuration de notre runtime en cliquant sur son nom :
Nous allons copier l’une des clefs présentes (peu importe laquelle)
Et nous allons la copier dans la fenêtre de configuration du runtime installé précédemment :
Le nœud existant est automatiquement détecté et le wizard nous demande d’entrer un nom de nœud pour notre cluster, nous montre la configuration qu’aura notre runtime avec la liste de l’ensemble des nœuds après configuration de celui-ci et nous « oblige » à activer l’accès à distance à partir d’internet (comme nous l’avons configuré sur le premier nœud)
De la même façon, nous configurons la sécurité de l’accès à distance. Sans certificat dans notre exemple.
Si tout s’est bien déroulé, la configuration est maintenant finie et nous pouvons quitter le wizzard de configuration pour aller vérifier dans Synapse que tout s’est bien passé.
Pas très loin de là où nous avons récupéré la clef d’association du runtime, nous pouvons maintenant aller voir les nœuds qui composent notre runtime.
Ce qui nous intéressera le plus cependant est maintenant dans la partie « Monitoring » de notre Integration Runtime :
Cette interface nous indique plusieurs choses :
- Nous avons 2 nœuds qui sont opérationnels (sur 2 nœuds existants) –>, car nous pouvons avoir jusqu’à 4 nœuds physiques sur un runtime
- La fonctionnalité « Haute-dispo / High Availability » est activée
- La liste de nos nœuds avec
- Leur état
- leur Rôle qui peut être :
- Worker : cette instance ne fait « que » exécuter des jobs
- Dispatcher / Worker : cette instance dispatch les jobs sur les différents nœuds et exécute des jobs
Nous avons maintenant 2 machines qui sont associées au même « runtime d’intégration » dans Synapse et nos jobs seront dispatché entre les différentes machines par le nœud qui fait office de « Dispatcher ».
En pratique ?
Le crash
C’est bien beau d’avoir configuré tout ça, mais au final ça sert à quoi ? Pour comprendre, nous allons arrêter le service qui est à l’instant le dispatcher. (sur les captures c’est celui qui possède le nombre de jobs concurrent le plus faible des deux – vu que les noms sont invisibles pour vous)
Nous avons de ce fait simulé un nœud qui tombe. Il est possible d’arrêter la machine, de couper le réseau pour simuler la perte d’un nœud. Peu importe le problème, c’est le symptôme qui nous intéresse : le service de runtime ne peut plus communiquer avec notre ressource Azure !
En observant ce qu’il se produit dans l’interface de monitoring, nous pouvons voir quelques changements.
Attention, cela n’est pas totalement instantané. Il peut y avoir un certain laps de temps entre le moment où le nœud s’arrête et le moment où nous voyons les conséquences sur l’interface de monitoring. Il est aussi potentiellement nécessaire de rafraichir la page du navigateur pour que toutes les vérifications de statut se réactualisent.
- Le statut est en « Running (limited) » : Cela indique que notre IR marche, tout en ayant un problème
- nous voyons ensuite qu’il n’y a qu’un seul nœud qui fonctionne malgré les deux enregistré : ce qui explique le (Limited) du statut Running évoqué plus haut
- La haute disponibilité n’est plus disponible : Il ne nous reste plus qu’un seul nœud fonctionnel donc si celui-ci tombe … c’est la fin !
- sur la liste de nos nœuds, nous voyons les deux différents nœuds :
- Le premier fonctionne correctement et est passé du rôle de « Worker » à « Dispatcher/worker » : Il a pris le rôle du nœud tombé
- Le second est indisponible : son rôle a changé et les différentes infos normalement affichées ne le sont plus.
Nous observons donc que malgré l’arrêt d’un service, notre runtime, bien qu’affichant un warning est toujours fonctionnel : c’est ça la « Haute-dispo » !
Etat intermédiaire
Comme évoqué, au moment du crash, suivant le nœud qui tombe, la situation ne se met pas à fonctionner de manière instantanée et nous pouvons avoir une interruption de service.
Le dispatcher tombe
Le dispatcher à un rôle primordial dans le cluster, c’est lui qui « dispatch » les jobs sur les différents nœuds. Et c’est à lui que le service Synapse envoie le besoin d’exécution d’un job. Si celui-ci tombe, il n’y a pas de service qui peut dire sur quelle machine exécuter les jobs. l’IR est donc injoignable et non fonctionnel tant qu’un dispatcher n’est pas de nouveau disponible.
Le statut du nœud qui n’est « que » worker est en erreur, car lui non plus n’arrive plus à communiquer avec le dispatcher.
Le changement de rôle de ce nœud pour que l’IR soit de nouveau opérationnel en mode dégradé prend quelques secondes, mais il n’y a rien à faire grâce à la configuration en « Haute-dispo ».
Un worker tombe
Ce cas de figure est moins critique, car il n’y a pas d’état inaccessible. Les jobs qui étaient éventuellement en train de tourner vont échouer, mais le runtime en soi restera disponible et s’il y a un retry-pattern sur nos jobs, ceux-ci pourront démarrer sur le nœud restant.
La restauration
Pour notre exemple, la restauration est assez simple, il suffit de redémarrer le service en cliquant au même endroit que là où on l’a arrêté. Dans la vraie vie, la résolution pourrait être plus complexe, mais ce n’est pas dans nos considérations.
Après redémarrage et après avoir attendu et rafraichi notre interface de monitoring, nous allons observer un phénomène particulier.
Si tout est rentré dans l’ordre, nous remarquons que le nœud qui était à l’origine le Dispatcher et qui est tombé n’est pas redevenu le dispatcher. Cela n’a aucun impact sur le bon fonctionnement de notre runtime comme ses statuts l’indiquent. Mais il faut simplement en avoir conscience et ne pas s’étonner.
Si vraiment l’on souhaite que l’ancien dispatcher redevienne le dispatcher après redémarrage, il est possible d’éteindre l’autre nœud pour que le processus de changement de rôle se re fasse dans l’autre sens. Il ne faut cependant pas oublier de redémarrer le service après le changement !!
Retour à l’état initial
Pour le retour à l’état initial ou la suppression d’un nœud, nous devons dans un premier temps supprimer le nœud au niveau de la configuration de l’IR dans le management de celle-ci côté Synapse.
Une confirmation nous sera demandée
Sur le serveur, le service sera marqué comme non inscrit.
Et nous pourrons désinstaller notre runtime depuis l’interface Windows d’application et fonctionnalités, pour ne laisser aucune trace, car ça prend malgré tout un peu d’espace disque !
Conclusion
Nous avons vu comment installer et configurer un cluster de runtime d’intégration runtime afin de palier à la perte d’une machine hébergeant le service tout en augmentant le nombre de jobs qui peuvent être exécutés en parallèle.
Il faudra cependant bien réfléchir à l’infrastructure sous-jacente et comprendre les implications réelles lorsque le nœud dispatcher tombe. En tous cas pour un environnement de prod avec un SLA, cette configuration est un « Must Have » !