Attention, certaines étapes spécifiques sont nécessaires pour configurer sur l'adresse IP virtuelle sinon le basculement ne fonctionne pas.
1. Lancez la console SafeKit
- Lancez la console Web dans un navigateur sur un nœud du cluster en vous connectant à
http://localhost:9010
. - Entrez
admin
comme nom d'utilisateur et le mot de passe défini durant l'installation.
Vous pouvez également exécuter la console dans un navigateur sur un poste de travail externe au cluster.
La configuration de SafeKit se fait sur les deux nœuds depuis un seul navigateur.
Pour sécuriser la console Web, consultez 11. Sécurisation de la console Web SafeKit dans le Guide de l'utilisateur.
2. Configurez les adresses des nœuds
- Saisissez les adresses IP des nœuds.
- Ensuite, cliquez sur
Apply
pour enregistrer la configuration.
Si la couleur d'arrière-plan du nœud 1 ou du nœud 2 est rouge, vérifiez la connectivité du navigateur aux deux nœuds et vérifiez le pare-feu sur les deux nœuds pour résoudre le problème.
Cette opération placera les adresses IP dans le fichier cluster.xml
sur les deux nœuds (plus d'information dans la formation avec la ligne de commande).
4. Configurez le module
- Choisissez un démarrage automatique du module au boot sans délai.
- Normalement, vous disposez d'un seul réseau heartbeat sur lequel la réplication est effectuée. Mais, vous pouvez définir un réseau privé si nécessaire.
- Vérifiez que les répertoires répliqués sont installés sur les deux nœuds et contiennent les données de l'application.
La réplication des données ainsi que des journaux est requise pour une base de données.
Vous pouvez ajouter de nouveaux répertoires répliqués si nécessaire. - Entrez une adresse IP virtuelle. Une adresse IP virtuelle est une adresse IP standard dans le même réseau IP (même sous-réseau) que les adresses IP des deux nœuds.
Les clients de l'application doivent être configurés avec l'adresse IP virtuelle (ou le nom DNS associé à l'adresse IP virtuelle).
L'adresse IP virtuelle est automatiquement basculée en cas de panne. start_prim
etstop_prim
doivent contenir le démarrage et l'arrêt de l'application .
Vous pouvez ajouter de nouveaux services dans ces scripts.
Vérifiez que les noms des services dans ces scripts sont ceux installés sur les deux nœuds, sinon modifiez-les dans les scripts.- Arrêtez les services configurés dans
start_prim
sur les deux nœuds. - Sous Windows et sur les deux nœuds, avec le gestionnaire de services Windows, définissez
Boot Startup Type = Manual
pour tous les services enregistrés dansstart_prim
(SafeKit contrôle le démarrage des services dansstart_prim
).
- Les bases de données système de SQL (comme master.mdf et mastlog.ldf) doivent être situées dans les mêmes répertoires sur les deux nœuds. Les répertoires doivent être configurés comme répliqués.
- SQL doit également être installé au même emplacement dans le système de fichiers sur les deux nœuds car la base de données de ressources de SQL se trouve dans le binaire et est requise pour le basculement sur panne. Cette base de données n'a pas besoin d'être répliquée.
- Les bases de données SQL de Milestone (.mdf et .ldf) doivent se trouver dans les mêmes répertoires sur les deux nœuds. Les répertoires doivent être configurés comme répliqués. Les bases de données Milestone sont les suivantes selon cet article .
Si SQL est sur les serveurs de management :
Notez que si un nom de processus est affiché dans Process Checker, il sera surveillé avec une action de redémarrage en cas de panne. La configuration d'un nom de processus erroné entraînera l'arrêt du module juste après son démarrage.
Cette opération reportera la configuration dans les fichiers userconfig.xml
, start_prim
, stop_prim
sur les deux nœuds (plus d'informations dans le training avec la ligne de commande).
7. Accédez au bureau du nœud 1 et définissez l'adresse IP virtuelle dans les fichiers Milestone internes
Depuis Milestone 2022 R3, cette étape n'est plus utile et sera effectuée automatiquement avec "Server Configurator - Registering servers - http://virtual-IP" dans une prochaine étape.
Dans une ligne de commande Powershell en tant qu'administrateur, exécutez sur le nœud 1 ce script :
c:/safekit/modules/milestone/bin/UpdateAuthServerUri.ps1
Ce script définit l'adresse IP virtuelle dans 2 fichiers Milestone internes :
C:\ProgramData\Milestone\XProtect Management Server\ServerConfig.xml
<AuthorizationServerUri>http://<virtual-ip>/IDP</AuthorizationServerUri>
C:\Program Files\Milestone\XProtect Management Server\IIS\IDP\appsettings.json
"Authority": "http://<virtual-ip>/IDP"
Nous supposons à cette étape que l'adresse IP virtuelle a été correctement configurée dans les étapes précédentes (le script utilise l'adresse IP virtuelle saisie dans la console SafeKit et stockée dans userconfig.xml
).
Notez que la même procédure est requise lorsque Milestone est exécuté avec Microsoft Cluster, sinon il y a un problème de reconnexion des serveurs d'enregistrement : https://developer.milestonesys.com/s/article/RS-goes-offline-mode-after-switching-the-Management-Server-cluster-node.
8. Démarrez le nœud 1 en tant que nœud primaire dans la console, le nœud avec des données à jour
Nous supposons depuis l'étape 7 que le nœud 1 a les répertoires répliqués à jour.
Forcez le démarrage du nœud 1 en tant que nœud primaire. Lorsque le nœud 2 sera démarré, toutes les données du nœud 1 seront copiées vers le nœud 2.
Si vous faites le mauvais choix, vous courez le risque de synchroniser des données obsolètes sur les deux nœuds.
On suppose également que l'application est stoppée sur le noeud 1 afin que SafeKit installe les mécanismes de réplication puis lance l'application dans le script start_prim
.
9. Attendez le passage à ALONE (vert)
- Le nœud 1 doit atteindre l'état ALONE (vert), ce qui signifie que le script
start_prim
a été exécuté sur le nœud 1.
Si le statut est ALONE (vert) et que l'application n'est pas démarrée, vérifiez les messages de sortie de start_prim
dans l'Application Log du nœud 1.
Si le nœud 1 n'atteint pas l'état ALONE (vert), analysez pourquoi avec le Module Log du nœud 1.
Si le cluster est dans l'état WAIT (rouge) not uptodate, STOP (rouge) not uptodate
, arrêtez le nœud WAIT et forcez son démarrage en tant que primaire.
10. Dans le bureau du nœud 1, arrêtez, puis enregistrez sur l'adresse IP virtuelle et redémarrez le Milestone Management Server
Exécutez les points suivants sur le nœud 1 suivant l'image :
- Cliquez avec le bouton droit sur l'icône Milestone Management Server dans la barre de tâches.
- Stop Management Server Service
- Choisissez ensuite Server Configurator... et enregistrez l'adresse IP virtuelle.
- Start Management Server Service
Cette procédure enregistre le Management Server du nœud 1 dans la base de données SQL (exécutée sur le nœud 1) via une connexion à l'adresse virtuelle.
Avant Milestone 2022 R3, l'enregistrement peut avoir supprimé la configuration de l'adresse IP virtuelle dans les fichiers internes de Milestone. Dans ce cas, répétez l'étape 7.
Remarque : Pour enregistrer une version antérieure à Milestone 2020 R2, utilisez Change encryption settings...
11. Dans le bureau du nœud 1 avec Milestone Management Client, définissez l'adresse IP virtuelle dans les URL pour les services et le réseau
Depuis Milestone 2022 R3, cette étape n'est plus utile et a été faite automatiquement avec "Server Configurator - Registering servers - http://virtual-IP".
Selon l'image :
- Démarrez Milestone XProtect Management Client sur le nœud 1.
- Dans le menu Tools, sélectionnez Registered Services.
- Dans la fenêtre Add/Remove Registered Services, sélectionnez un service dans la liste et cliquez sur Edit.
- Dans la fenêtre Edit Registered Service, modifiez l'adresse URL du service avec la même adresse URL mais contenant l'adresse IP virtuelle.
- Répétez ces étapes pour tous les services répertoriés dans la fenêtre.
- Dans la même fenêtre, cliquez sur Network.
- Dans la fenêtre Network Configuration, modifiez l'adresse URL du serveur avec la même adresse URL mais contenant l'adresse IP virtuelle.
12. Dans le bureau du nœud 1 avec Milestone Management Client, définissez les rôles d'administrateur pour assurer un basculement correct
Si l'authentification Windows de Milestone a été configurée avec un Active Directory, l'utilisateur/mot de passe sera récupéré dans l'AD externe sur le nœud secondaire après un basculement, il n'y a donc pas de configuration particulière.
Lorsque vous démarrez Milestone XProtect Management Client, vous devez vous authentifier soit avec la "Windows authentication" soit avec la "Basic authentication" (cliquez ici pour voir la capture d'écran).
Ouvrez Milestone XProtect Management Client et dans Security / Roles (voir image)
- Définissez le groupe Windows BUILTIN\Administrators. Ainsi, suite à un basculement, un utilisateur administrateur pourra se connecter à Milestone sur le nœud secondaire avec la "Windows authentication".
- Créez un utilisateur avec une "Basic authentication" (Admin dans l'image) pour être sûr de vous ré-authentifier sur le nœud secondaire après un basculement. Pour la "Basic authentication", l'utilisateur/mot de passe est stocké dans la base de données SQL et sera récupéré sur le nœud secondaire après un basculement.
En définissant le groupe BUILTIN\Administrators, vous pourrez vous authentifier sur le nœud secondaire avec un administrateur Windows local.
Sinon aucune authentification ne sera possible avec un compte Windows local sur le secondaire après un basculement.
C'est parce que le groupe BUILTIN\Administrators a le même SID sur les deux nœuds. Pour les autres groupes locaux ou utilisateurs locaux, l'authentification ne sera pas possible sur le secondaire car les SID sont différents entre les deux nœuds même s'ils portent le même nom.
13. Accédez au bureau du nœud 2 et définissez l'adresse IP virtuelle dans les fichiers Milestone internes
Depuis Milestone 2022 R3, cette étape n'est plus utile et sera effectuée automatiquement avec "Server Configurator - Registering servers - http://virtual-IP" dans une prochaine étape.
Dans une ligne de commande Powershell en tant qu'administrateur, exécutez sur le nœud 2 ce script :
c:/safekit/modules/milestone/bin/UpdateAuthServerUri.ps1
Ce script définit l'adresse IP virtuelle dans 2 fichiers Milestone internes :
C:\ProgramData\Milestone\XProtect Management Server\ServerConfig.xml
<AuthorizationServerUri>http://<virtual-ip>/IDP</AuthorizationServerUri>
C:\Program Files\Milestone\XProtect Management Server\IIS\IDP\appsettings.json
"Authority": "http://<virtual-ip>/IDP"
14. Dans le bureau du nœud 2, enregistrez le serveur de gestion sur l'adresse IP virtuelle
- Choisissez Server Configurator dans la barre des tâches du nœud 2 et enregistrez-le sur l'adresse IP virtuelle (voir image).
- Puis arrêtez les services avec Stop Management Server Service.
Le compte de l'utilisateur exécutant l'enregistrement sur le nœud 2 doit avoir le rôle d'administrateur dans Milestone sur le nœud 1.
Si c'est l'administrateur local sur le nœud 2 qui effectue l'enregistrement, le groupe Windows BUILTIN\Administrators
doit avoir été défini dans Management Client / Security / Roles à l'étape 12. Sinon, l'enregistrement ne fonctionnera pas.
Cette procédure enregistre le serveur de gestion du nœud 2 dans la base de données SQL (exécutée sur le nœud 1) via une connexion à l'adresse virtuelle.
Avec une version de Milestone inféreure à 2022 R3, l'enregistrement peut avoir supprimé la configuration de l'adresse IP virtuelle dans les fichiers internes de Milestone. Dans ce cas, répétez l'étape 13.
15. Démarrez le nœud 2
- Démarrer le nœud 2 avec son menu contextuel.
- Attendre l'état SECOND (vert).
Le nœud 2 reste dans l'état SECOND (magenta) pendant la resynchronisation des répertoires répliqués (copie du nœud 1 vers le nœud 2).
Cela peut prendre un certain temps en fonction de la taille des fichiers à resynchroniser dans les répertoires répliqués et de la bande passante du réseau.
Pour voir la progression de la copie, consultez le Module Log du nœud 2 avec l'option verbose sans oubliez de rafraichir la fenêtre.
16. Vérifiez que le cluster est opérationnel
- Vérifiez que le cluster est vert/vert avec les services exécutés sur le nœud PRIM et ne s'exécutant pas sur le nœud SECOND.
Seules les modifications à l'intérieur des fichiers sont répliquées en temps réel dans cet état.
Les composants clients des services doivent être configurés avec l'adresse IP virtuelle. La configuration peut se faire avec un nom DNS (si un nom DNS a été créé et associé à l'adresse IP virtuelle).
17. Configurez l'adresse IP virtuelle dans les serveurs d'enregistrement
- Soit installez les serveurs d'enregistrement, en spécifiant l'adresse IP virtuelle dans l'URL d'installation.
- Ou, côté serveurs d'enregistrement, définissez l'adresse IP virtuelle dans les champs du fichier suivant :
C:\ProgramData\Milestone\XProtect Recording Server\RecorderConfig.xml
<server><address>
<server><authorizationserveraddress>
- Connectez le "Milestone Management Client" et le "Milestone Smart Client" à l'adresse IP virtuelle.
18. Le Management Client et le Smart Client ne fonctionnent pas correctement après un basculement de nœud
Dans une configuration de XProtect® Management Server en cluster, le Smart Client et le Management Client présentent divers problèmes après un basculement de nœud. Le problème est lié aux jetons générés sur les différents nœuds avant et après le changement de nœud, ainsi qu'aux problèmes d'accès à certains certificats nécessaires à la validation des jetons. Une solution est disponible (pour les versions 2022 R3 à 2023 R2) — cet article Milestone explique en détail comment appliquer la solution.
Lisez cet article dans la base de connaissances Milestone.
Le problème est résolu dans Milestone 2023 R3.
19. Testez
- Arrêtez le nœud PRIM en faisant défiler son menu contextuel et en cliquant sur Stop. N'utilisez pas swap pour un premier test (voir pourquoi ci-dessous).
- Vérifiez qu'il y a un basculement sur le nœud SECOND qui doit devenir ALONE (vert).
- Et avec la Microsoft Management Console (MMC) sous Windows ou avec des lignes de commande sous Linux, vérifiez le basculement des services (arrêtés sur le nœud 1 dans le script
stop_prim
et démarrés sur le nœud 2 dans le scriptstart_prim
).
Si tout va bien, lancez un démarrage sur node1, qui resynchronisera les répertoires répliqués depuis node2.
Si les choses tournent mal, arrêtez node2 et forcez le démarrage en tant que primaire de node1, qui redémarrera avec ses données localement saines au moment de l'arrêt.
Le swap implique un arrêt-démarrage du PRIM, qui resynchronisera les données de node2 immédiatement après son arrêt, ne laissant aucune chance de redémarrage sur des données saines en cas de problème de configuration de réplication.
Si l'application n'est pas démarrée sur le nœud 2 alors que l'état est ALONE (vert ), vérifiez les messages de sortie du script start_prim
dans l'Application Log du nœud 2.
Si ALONE (vert) n'est pas atteint, analysez pourquoi avec le Module Log du nœud 2.