Guide de l'utilisateur de SafeKit
SafeKit 8.2
Sujet |
Ce document couvre toutes les phases de mise en œuvre de SafeKit : architecture, installation, tests, administration, résolution de problèmes, support, interface ligne de commande |
|
Public |
Architectures |
|
Installation |
||
Console |
||
Configuration avancée |
Cluster.xml pour la configuration du cluster SafeKit Userconfig.xml pour la configuration du module |
|
Administration |
Administration d'un module miroir |
|
Support |
||
Autres |
||
Version |
SafeKit 8.2 |
|
OS supportés |
Windows et Linux ; pour une liste détaillée des OS supportés, voir ici |
|
Sites web |
Site marketing Evidian : http://www.evidian.com/safekit |
|
Ref |
39 F2 38MC 04 |
|
Si vous avez des commentaires ou des questions relatives à ce document, contactez-nous via https://www.evidian.com/company/contact-evidian/ |
Copyright © Evidian, 2024
Evidian reconnaît les droits des propriétaires des marques mentionnées dans ce document.
Il est interdit de reproduire, d'enregistrer sur système de recherche documentaire ou de transmettre sous quelque forme et par quelque moyen que ce soit, électronique, mécanique ou autre, tout ou partie de cette publication sans le consentement préalable par écrit de l'éditeur.
Evidian décline toute garantie implicite de qualité marchande ou d'utilisation dans un but particulier et ne fait aucune garantie, à l'exception de celles effectuées dans le cadre d'un accord écrit avec et pour ses clients. Evidian ne pourra en aucun cas être tenu responsable par qui que ce soit de tout dommage direct, indirect ou spécial.
Les informations et caractéristiques techniques contenues dans ce document sont susceptibles d'être modifiées sans préavis. Pour tout renseignement sur la disponibilité des produits ou services, veuillez consulter un représentant commercial d’Evidian.
Guide de l'utilisateur de SafeKit Logiciel de haute disponibilité pour applications critiques 1
1.1..... Généralités, solutions, architectures 15
1.1.1 Introduction à SafeKit 15
1.1.3 Architectures SafeKit 16
1.1.4 Définition du cluster SafeKit 17
1.1.5 Définition du module SafeKit 17
1.2..... Le cluster miroir de SafeKit 18
1.2.1 Réplication de fichiers en temps réel et basculement d'application. 18
1.2.2 Étape 1. Fonctionnement normal 19
1.2.4 Étape 3. Réintégration et resynchronisation. 20
1.2.5 Étape 4. Retour au fonctionnement normal 20
1.2.6 Réplication synchrone et réplication asynchrone. 20
1.2.7 Comportement en cas d'isolation réseau. 21
1.2.8 Réplication à 3 nœuds 21
1.2.9 SafeKit sur un seul nœud pour résister aux pannes logicielles. 22
1.3..... Le cluster ferme de SafeKit 22
1.3.1 Équilibrage de charge réseau et basculement d’application. 22
1.3.2 Principe d'une adresse IP virtuelle avec équilibrage de charge réseau. 22
1.3.3 Équilibrage de charge pour les services Web avec ou sans état 23
1.3.4 Solution de haute disponibilité en chaîne dans une ferme. 23
1.4..... Clusters exécutant plusieurs modules 24
1.4.1 Le cluster ferme+miroir de SafeKit 24
1.4.2 Le cluster actif/actif avec réplication de SafeKit 24
1.4.3 Le cluster N-1 de SafeKit 25
1.5..... Le cluster Hyper-V ou KVM de SafeKit 25
1.5.1 Équilibrage de charge, réplication, basculement de machines virtuelles complètes. 25
1.6..... Clusters SafeKit dans le cloud. 26
1.6.1 Cluster miroir dans Azure, AWS et GCP. 26
1.6.2 Cluster ferme dans Azure, AWS et GCP. 28
2.1..... Installation de SafeKit 29
2.1.1 Télécharger le package. 29
2.1.2 Répertoires d'installation et espace disque. 29
2.1.3 Procédure d’installation de SafeKit 30
2.1.4 Utilisation de la console web et de la ligne de commande SafeKit 32
2.1.5 Clés de licence SafeKit 34
2.1.6 Caractéristiques spécifiques à chaque OS. 34
2.2..... Recommandation pour une installation d'un module miroir 35
2.2.3 Prérequis application. 35
2.2.4 Prérequis réplication de fichiers 35
2.3..... Recommandation pour une installation d'un module ferme. 36
2.3.3 Prérequis application. 36
2.4..... Upgrade de SafeKit 36
2.4.2 Procédure de désinstallation. 37
2.4.3 Procédure de réinstallation et post-installation pour l’upgrade. 37
2.5..... Désinstallation complète de SafeKit 39
2.5.1 Désinstallation sur Windows 39
2.5.2 Désinstallation sur Linux. 39
2.6..... Documentations SafeKit 40
3.... La console web de SafeKit 41
3.1..... Démarrer la console web. 41
3.1.1 Lancer un navigateur web. 41
3.1.2 Connecter la console à un serveur SafeKit 42
3.2..... Configurer un cluster SafeKit 43
3.2.1 L’assistant de configuration du cluster 43
3.2.2 Page d’accueil de la configuration du cluster 46
3.3..... Configurer un module. 48
3.3.1 Sélectionner le nouveau module à configurer 48
3.3.2 L’assistant de configuration du module. 49
3.3.3 Page d’accueil de la configuration des modules 54
3.3.4 Éditer localement la configuration du module puis l’appliquer 56
3.4..... Superviser un module. 57
3.4.1 Page d’accueil de la supervision. 57
3.4.3 Menus de contrôle d’un module. 60
3.4.5 Chronologie des états du module. 69
3.5..... Snapshots et journaux du module pour le débogage et support 69
3.6..... Sécuriser la console web. 70
4.1..... Installation et tests après boot 73
4.1.1 Test installation package. 73
4.1.2 Test licence et version. 74
4.1.3 Test des services et modules SafeKit après boot 74
4.1.4 Test démarrage de la console web. 77
4.2..... Tests d'un module miroir 77
4.2.1 Test du
premier start d'un module miroir sur 2 serveurs STOP (NotReady). 77
4.2.2 Test start
d'un module miroir sur 2 serveurs STOP (NotReady). 77
4.2.3 Test stop
d'un module miroir sur le serveur PRIM (Ready). 77
4.2.4 Test start
du module miroir dans l'état STOP
(NotReady) 78
4.2.5 Test
restart du module miroir dans l'état PRIM (Ready). 78
4.2.6 Test adresse IP virtuelle d'un module miroir 78
4.2.7 Test réplication de fichiers d'un module miroir 79
4.2.8 Test shutdown du serveur PRIM (Ready). 80
4.2.9 Test power-off du serveur PRIM (Ready). 81
4.2.10 Test split-brain avec un module miroir 82
4.2.11 Continuer les tests de votre module miroir avec les checkers. 83
4.3..... Tests d'un module ferme. 83
4.3.1 Test start
d'un module ferme sur les serveurs STOP (NotReady). 83
4.3.2 Test stop
d'un module ferme sur un serveur UP (Ready). 83
4.3.3 Test
restart d'un module ferme sur un serveur UP (Ready). 83
4.3.4 Test adresse IP virtuelle d'un module ferme. 84
4.3.5 Test load balancing TCP sur une adresse virtuelle. 85
4.3.6 Test split-brain avec un module ferme. 86
4.3.7 Test de la compatibilité du réseau avec l'adresse MAC invisible (vmac_invisible) 87
4.3.8 Test shutdown d’ un serveur UP (Ready). 88
4.3.9 Test power-off d'un serveur UP (Ready). 89
4.3.10 Continuer les tests du module ferme avec les checkers 89
4.4..... Tests des checkers communs à un miroir et une ferme. 89
4.4.1 Test <errd> checker avec action restart ou stopstart 89
4.4.2 Test <tcp> checker avec action restart ou stopstart 90
4.4.3 Test <tcp> checker avec action wait 91
4.4.4 Test <interface check="on"> avec action wait 92
4.4.5 Test <ping> checker avec action wait 93
4.4.6 Test <module> checker avec action wait 94
4.4.7 Test <custom> checker avec action wait 95
4.4.8 Test <custom> checker avec action restart ou stopstart 96
5.... Administration d'un module miroir. 99
5.1..... Mode de fonctionnement d'un module miroir 99
5.3..... Premier démarrage d'un module miroir (commande prim) 102
5.4..... Différents cas de réintégration (utilisation des bitmaps) 103
5.5..... Démarrage d'un
module miroir avec les données à jour STOP (NotReady)
-
WAIT
(NotReady). 104
5.6..... Mode de
réplication dégradé (ALONE
(Ready) dégradé) 105
5.7..... Reprise
automatique ou manuelle failover="off"
- STOP
(NotReady) -
WAIT
(NotReady) 106
5.8..... Serveur primaire par défaut (swap automatique après réintégration) 108
5.9..... La commande prim échoue : pourquoi ? (commande primforce) 109
6.... Administration d'un module ferme. 111
6.1..... Mode de fonctionnement d'un module ferme. 111
6.2..... Automate d'état d'un module ferme (STOP, WAIT, UP - NotReady, Transient, Ready) 112
6.3..... Démarrage d'un module ferme. 113
7.... Résolution de problèmes. 115
7.1..... Problème de connexion avec la console web. 115
7.1.1 Contrôler le navigateur 115
7.1.2 Supprimer l’état du navigateur 116
7.1.3 Contrôler les serveurs. 116
7.2..... Problème de connexion HTTPS avec la console web. 116
7.2.1 Contrôler les certificats serveurs 117
7.2.2 Contrôler les certificats installés dans SafeKit 118
7.2.3 Revenir à la configuration HTTP. 118
7.3..... Comment lire les journaux et les ressources du module ? 119
7.4..... Comment lire le journal de commandes du serveur ? 119
7.5..... Module stable (Ready) et
(Ready). 120
7.6..... Module dégradé (Ready)
et
/
(NotReady). 120
7.7..... Module hors
service /
(NotReady) et
/
(NotReady). 120
7.8..... Module STOP
(NotReady) : redémarrer le
module. 120
7.9..... Module WAIT
(NotReady) : réparer la ressource="down". 121
7.10... Module oscillant
de (Ready)
à
(Transient). 122
7.11... Message sur stop après maxloop. 123
7.12... Module (Ready)
mais application non opérationnelle. 123
7.13... Module mirror ALONE (Ready) /
WAIT ou
STOP (NotReady). 124
7.14... Module ferme UP
(Ready) mais problème de load balancing. 125
7.14.1 Non cohérence des parts de la charge réseau. 125
7.14.2 L'adresse IP virtuelle ne répond pas correctement 125
7.15... Problème après boot 125
7.16... Analyse à partir des snapshots du module. 126
7.16.1 Fichiers de configuration du module. 126
7.16.2 Fichiers de dump du module. 127
7.17... Problème avec la taille des bases de données de SafeKit 129
7.18.1 Exporter les certificats CA depuis des certificats publics. 130
7.19... Problème persistant 133
8.... Accès au support Evidian. 135
8.1..... Page d’accueil du site support 135
8.2..... Clés de licence permanentes 136
8.4..... Accéder à votre compte. 137
8.5..... Le Call Desk pour remonter des problèmes 138
8.5.1 Les opérations du Call Desk. 138
8.5.3 Attacher les snapshots 139
8.5.4 Consultation des réponses au Call et échange avec le support 140
8.6..... Zone de download et d’upload de fichiers 141
8.6.1 2 zones de download et d’upload. 141
8.6.2 La zone de download des packages produit 141
8.6.3 La zone privée d’upload. 142
8.7..... Base de connaissances 142
9.... Interface ligne de commande. 143
9.1..... Commandes de contrôle des services SafeKit 143
9.1.2 Service safewebserver 144
9.2..... Commandes de configuration et surveillance du cluster 145
9.3..... Commandes de contrôle des modules 147
9.4..... Commandes de surveillance des modules 150
9.5..... Commandes de configuration des modules 151
9.6..... Commandes de support 153
9.7..... Commandes distribuées sur plusieurs serveurs SafeKit 154
9.8.1 Commande locale et distribuée. 156
9.8.2 Configuration globale du cluster 156
9.8.3 Configuration globale d’un module. 156
9.8.4 Snapshot d’un module. 157
10.. Administration avancée. 159
10.1... Variables d'environnement et répertoires SafeKit 159
10.2... Services et démons SafeKit 161
10.2.2 Démons SafeKit par module. 162
10.3... Paramétrage du pare-feu. 162
10.3.1 Paramétrage du pare-feu en Linux. 163
10.3.2 Paramétrage du pare-feu en Windows 163
10.4... Configuration au boot et au shutdown en Windows 167
10.4.1 Procédure automatique. 167
10.4.2 Procédure manuelle. 168
10.5... Paramétrage des antivirus 168
10.6... Sécurisation des communications internes au module. 169
10.6.1 Configuration avec la console web de SafeKit 169
10.6.2 Configuration en ligne de commandes 169
10.6.3 Configuration avancée. 170
10.7... Configuration du service web de SafeKit 171
10.7.1 Fichiers de configuration. 172
10.7.2 Configuration des ports de connexion. 173
10.7.3 Configuration de HTTP/HTTPS et de l’authentification utilisateur 174
10.8... Notification par mail 174
10.9... Surveillance SNMP. 174
10.9.1 Surveillance SNMP en Windows. 175
10.9.2 Surveillance SNMP en Linux. 175
10.10. Journal des commandes du serveur SafeKit 176
10.11. Messages SafeKit dans le journal système. 177
11.. Sécurisation du service web de SafeKit 179
11.1.1 Configuration par défaut 180
11.1.2 Configurations prédéfinies. 180
11.2... Configuration HTTP. 181
11.2.1 Configuration par défaut 181
11.2.2 Configuration non sécurisée basée sur un rôle identique pour tous. 183
11.3... Configuration HTTPS. 184
11.3.1 Configuration HTTPS avec la PKI SafeKit 185
11.3.2 Configuration HTTPS avec une PKI externe. 192
11.4... Configuration de l’authentification utilisateur 196
11.4.1 Configuration l’authentification à base de fichier 197
11.4.2 Configuration de l’authentification à base de serveur LDAP/AD. 199
11.4.3 Configuration de l’authentification à base de serveur OpenID Connect 201
12.. Cluster.xml pour la configuration du cluster SafeKit 205
12.1... Le fichier cluster.xml. 205
12.1.1 Cluster.xml exemple. 205
12.1.2 Cluster.xml syntaxe. 206
12.1.3 <lans>, <lan>, <node> attributs. 206
12.2... Configuration du cluster SafeKit 208
12.2.1 Configuration avec la console web de SafeKit 208
12.2.2 Configuration en ligne de commande. 208
12.2.3 Changements de configuration. 209
13.. Userconfig.xml pour la configuration du module. 211
13.1... Macro définition - <macro>. 212
13.2... Module ferme ou miroir - <service>. 213
13.2.3 <service> Attributs. 213
13.3... Heartbeats - <heart>, <heartbeat >. 216
13.3.3 <heart>, <heartbeat> Attributs. 217
13.4... Topologie d'une ferme - <farm>, <lan>. 218
13.4.3 <farm>, <lan> Attributs. 219
13.5... Adresse IP virtuelle - <vip>. 219
13.5.1 <vip> Exemple dans un module miroir 219
13.5.2 <vip> Exemple dans un module ferme. 220
13.5.3 Alternative à <vip> pour des serveurs dans des réseaux IP différents. 220
13.5.6 <loadbalancing_list>, <group>, <cluster>, <host> Attributs 225
13.6... Réplication de fichiers - <rfs>, <replicated>. 228
13.6.3 <rfs>, <replicated> Attributs. 229
13.7... Activer les scripts du module - <user>, <var>. 246
13.7.3 <user>, <var> Attributs. 247
13.8... Hostname virtuel - <vhost>, <virtualhostname>. 247
13.8.3 <vhost>, <virtualhostname> Attributs. 248
13.8.4 <vhost> Description. 248
13.9... Surveillance de processus ou services - <errd>, <proc>. 249
13.9.3 <errd>, <proc> Attributs 250
13.10. Checkers - <check>. 255
13.10.3 <checker> Description. 256
13.11. TCP checker - <tcp>. 259
13.12. Ping checker - <ping>. 262
13.13. Interface checker - <intf>. 264
13.15. Custom checker - <custom>. 267
13.15.3 <custom> Attributs 268
13.16. Module checker - <module>. 269
13.16.3 <module> Attributs. 270
13.17. Splitbrain checker - <splitbrain>. 271
13.17.1 <splitbrain> Exemple. 272
13.17.2 <splitbrain> Syntaxe. 272
13.17.3 <splitbrain> Attributs. 272
13.18. Failover machine - <failover>. 273
13.18.1 <failover> Exemple. 274
13.18.2 <failover> Syntaxe. 274
13.18.3 <failover> Attributs. 275
13.18.4 <failover> Description. 275
14.. Scripts du module pour la configuration du module. 279
14.1.1 Scripts start/stop. 279
14.2... Variables d’environnement et arguments passés aux scripts 280
14.3... Sortie des scripts 281
14.3.1 Sortie dans le journal du script 281
14.3.2 Sortie dans le journal du module. 281
14.4... Automate d’exécution des scripts 282
14.5... Commandes spéciales SafeKit pour les scripts 283
14.5.1 Commandes pour Windows. 283
14.5.2 Commandes pour Linux. 283
14.5.3 Commandes pour Windows et Linux. 284
15.. Exemples de configurations de module. 287
15.1... Exemple de module miroir avec mirror.safe. 288
15.1.1 Configuration du cluster avec deux réseaux. 288
15.1.2 Configurations du module miroir 289
15.1.3 Scripts du module miroir 290
15.2... Exemple de module ferme avec farm.safe. 292
15.2.1 Configuration du cluster avec trois nœuds 292
15.2.2 Configurations du module ferme. 293
15.2.3 Scripts du module ferme. 298
15.3... Exemple d’utilisation de macros et variables de script avec hyperv.safe. 299
15.3.1 Configuration du module avec macro et var 299
15.3.2 Accès des variables par les scripts du module. 300
15.4... Exemple de surveillance de processus avec softerrd.safe. 301
15.4.1 Configuration du module avec surveillance de processus 301
15.4.2 Configuration avancée des scripts du module. 302
15.5... Exemple de TCP checker 304
15.6... Exemple de ping checker 305
15.7... Exemple de custom checker avec customchecker.safe. 307
15.7.1 Configuration du module avec un custom checker 307
15.7.2 Configuration avancée du script du module checker 309
15.8... Exemple de splitbrain checker 310
15.9... Exemples de module checker 311
15.9.1 Exemple d’un module ferme dépendant d'un module miroir 311
15.9.2 Exemple avec leader.safe et follower.safe. 313
15.10. Exemple de checker d'interface réseau. 313
15.11. Exemple d’IP checker 314
15.12. Exemple de notification par mail avec notification.safe. 315
15.12.1 Notification sur démarrage et arrêt du module. 315
15.12.2 Notification sur changement d’état du module. 317
15.13. Exemple d'hostname virtuel avec vhost.safe. 319
15.13.1 Configuration du module avec un hostname virtuel 319
15.13.2 Scripts du module avec un hostname virtuel 320
16.. Cluster SafeKit dans le cloud. 323
16.1... Cluster SafeKit dans Amazon AWS. 323
16.1.1 Cluster miroir dans AWS. 324
16.1.2 Cluster ferme dans AWS. 325
16.2... Cluster SafeKit dans Microsoft Azure. 327
16.2.1 Cluster miroir dans Azure. 328
16.2.2 Cluster ferme dans Azure. 329
16.3... Cluster SafeKit dans Google GCP. 330
16.3.1 Cluster miroir dans GCP. 331
16.3.2 Cluster ferme dans GCP. 333
Index des messages du journal du module. 339
1. Aperçu technique
Section 1.1 « Généralités, solutions, architectures »
Section 1.2 « Le cluster miroir de SafeKit »
Section 1.3 « Le cluster ferme de SafeKit »
Section 1.4 « Clusters exécutant
plusieurs modules »
Section 1.5 « Le cluster Hyper-V ou KVM
de SafeKit »
Section 1.6 « Clusters SafeKit dans le
cloud »
1.1 Généralités, solutions, architectures
1.1.1 Introduction à SafeKit
SafeKit, développé par Evidian, est une solution logicielle de haute disponibilité conçue pour garantir une disponibilité 24/7 des applications critiques pour les entreprises. Il prend en charge les plateformes Windows et Linux et élimine le besoin de disques partagés, d’éditions entreprises de bases de données ou de compétences techniques avancées, ce qui en fait une alternative rentable aux solutions de clustering traditionnelles.
Caractéristiques clés :
· Réplication synchrone en temps réel : Réplication continue des données entre les nœuds pour éviter toute perte de données.
· Basculement et retour automatiques : Basculement transparent vers un système secondaire en cas de panne et retour au système d’origine une fois opérationnel.
· Répartition de charge : Optimise l’utilisation des ressources en répartissant les charges de travail sur plusieurs serveurs.
· Indépendant de la plateforme : Compatible avec les machines physiques, les machines virtuelles et les infrastructures de cloud public.
Avantages clés :
· Aucune compétence spécifique : Aucune compétence informatique spécialisée requise pour le déploiement.
· Aucun surcoût matériel : Pas besoin de matériel spécifique comme des disques partagés ou des répartiteurs de charge.
· Aucun surcoût logiciel : Fonctionne avec les éditions standard de Windows et Linux.
Solutions clés :
· Niveau application : Haute disponibilité avec des scripts de redémarrage par application.
· Niveau hyperviseur : Haute disponibilité sans scripts de redémarrage par application.
· Niveau conteneur ou pod : Haute disponibilité sans scripts de redémarrage par application.
SafeKit est idéal pour les éditeurs de logiciels, les revendeurs et les distributeurs souhaitant améliorer leurs produits avec des fonctionnalités de haute disponibilité. Il offre également une opportunité OEM pour les partenaires d’intégrer SafeKit dans leurs propres applications.
1.1.2 Solutions SafeKit
Cliquez ici pour une liste des solutions SafeKit.
HA au niveau de l'application Dans ce type de solution, seules les données applicatives sont répliquées. Et seule l'application est redémarrée en cas de panne. Des tâches d’intégration doivent être mises en œuvre : écrire les scripts de redémarrage pour l’application, définir les dossiers à répliquer, configurer les checkers logiciels, définir une adresse IP virtuelle. Cette solution est indépendante de la plate-forme et fonctionne avec des applications à l'intérieur de machines physiques, de machines virtuelles et dans le cloud. Tous les hyperviseurs sont pris en charge (par exemple, VMware, Hyper-V, etc.). |
HA au niveau de la machine virtuelle Dans ce type de solution, l'intégralité de la machine virtuelle (VM) est répliquée, y compris l'application et le système d'exploitation. La machine virtuelle complète est redémarrée en cas de panne. L'avantage est qu'il n'y a pas de scripts de redémarrage à écrire par application, ni d'adresse IP virtuelle à définir. Si vous ne savez pas comment fonctionne une application, c'est la solution la plus simple. Cette solution fonctionne avec Windows/Hyper-V et Linux/KVM, mais pas avec VMware. Il s'agit d'une solution active/active avec plusieurs machines virtuelles répliquées et redémarrées entre les deux nœuds. |
Note : Les applications exécutées dans des conteneurs ou des pods n’ont pas besoin non plus de scripts de redémarrage dédiés. SafeKit fournit des redémarrages génériques et une réplication en temps réel des données persistentes pour ces environnements (voir la liste des solutions SafeKit).
1.1.3 Architectures SafeKit
SafeKit propose deux clusters de haute disponibilité de base pour Windows et Linux :
· le cluster miroir, avec réplication de fichiers en temps réel et basculement, construit en déployant un module miroir sur 2 serveurs,
· Le cluster ferme, avec équilibrage de charge réseau et basculement, construit en déployant un module ferme sur 2 serveurs ou plus.
Plusieurs modules peuvent être déployés sur un même cluster. Ainsi, des architectures de clustering avancées peuvent être mises en œuvre :
· le cluster ferme+miroir construit en déployant un module ferme et un module miroir sur le même cluster,
· le cluster actif/actif construit en déployant plusieurs modules miroirs sur 2 serveurs,
· le cluster N-1 construit en déployant N modules miroirs sur N+1 serveurs.
Des clusters spécifiques sont également intéressants à prendre en compte avec SafeKit :
· le cluster Hyper-V ou KVM avec réplication en temps réel et basculement de machines virtuelles entières entre 2 hyperviseurs actifs,
· des clusters ferme ou miroir dans le Cloud.
1.1.4 Définition du cluster SafeKit
Un cluster SafeKit est un ensemble de serveurs sur lesquels SafeKit est installé et en cours d'exécution.
Tous les serveurs d'un cluster SafeKit donné partagent la même configuration de cluster, qui inclut la liste des serveurs et des réseaux utilisés. Ces serveurs communiquent entre eux pour maintenir une vue globale des configurations des modules SafeKit. Un serveur ne peut pas appartenir à plusieurs clusters SafeKit simultanément.
La configuration du cluster est une condition préalable à l'installation et à la configuration des modules SafeKit. Cela peut être fait à l'aide de la console Web de SafeKit ou de commandes en ligne.
1.1.5 Définition du module SafeKit
Un module est une personnalisation de SafeKit pour une application ou un hyperviseur spécifique. Cliquez ici pour une liste des modules et leurs guides d'installation rapide.
Types de modules
· Modules génériques ferme et miroir pour de nouvelles applications,
· Modules d'application préconfigurés pour des bases de données, des serveurs web...,
· Modules hyperviseurs (hyperv.safe, kvm.safe) pour la réplication en temps réel et le redémarrage de machines virtuelles complètes.
Contenu du module
En pratique, un module est un fichier « .safe » (type zip) qui comprend :
· Le fichier de configuration userconfig.xml, qui contient :
o L'adresse IP virtuelle (non nécessaire pour un module hyperviseur),
o Répertoires de fichiers à répliquer en temps réel (pour un module miroir),
o Critères d'équilibrage de charge réseau (pour un module ferme),
o Configuration des détecteurs de pannes logicielles et matérielles,
· Les scripts permettant de démarrer et d'arrêter une application ou une machine virtuelle.
Étapes de déploiement
Une fois qu'un module est configuré et testé, le déploiement ne nécessite aucune compétence informatique spécifique :
· Installer l'application ou l'hyperviseur sur 2 serveurs standards,
· Installez le logiciel SafeKit sur les deux serveurs,
· Installez le module sur les deux serveurs.
La configuration, le déploiement et la surveillance des modules peuvent être effectués à l'aide de la console Web de SafeKit ou de commandes en ligne.
1.1.6 Limites de SafeKit
Utilisation typique avec SafeKit |
|||
Réplication de quelques téraoctets |
Réplication < 1 millions de fichiers |
Réplication <= 32 machines virtuelles |
LAN 1 ou 10 G/s ou LAN étendu |
Limitation |
|||
La resynchronisation après une défaillance prend trop de temps. Sur un réseau de 1 Gbit/s, 3 heures pour 1 téraoctets. Sur un réseau 10 Gbit/s, 1 heure ou moins pour 1 téraoctets (dépend des performances d'E/S du disque en écriture). |
La resynchronisation après une défaillance prend trop de temps. Temps de vérifier chaque fichier entre les deux nœuds. |
En mode réplication complète de machines virtuelles, et avec une machine virtuelle dans un module miroir, la limite est de 32 modules par cluster. |
Le basculement de l'adresse IP virtuelle est intégré lorsqu'on est dans le même sous-réseau. Un LAN fournit une bande passante adéquate pour la resynchronisation. Un LAN offre une latence adéquate (généralement un aller-retour de moins de 2 ms) pour la réplication synchrone. |
Alternative |
|||
Utilisez un stockage partagé. |
Mettez les fichiers dans un disque dur virtuel répliqué par SafeKit. |
Utilisez une autre solution de HA avec stockage partagé. |
Utilisez des solutions de backup avec réplication asynchrone. |
1.2 Le cluster miroir de SafeKit
1.2.1 Réplication de fichiers en temps réel et basculement d'application
Le cluster miroir est une solution de haute disponibilité active-passive, créée en déployant un module miroir au sein d'un cluster à deux nœuds. L'application s'exécute sur un serveur primaire et est redémarrée automatiquement sur un serveur secondaire en cas de défaillance du serveur principal.
Avec sa fonction de réplication de fichiers temps réel, cette architecture est particulièrement adaptée pour fournir une haute disponibilité aux applications back-end avec des données critiques à protéger contre les pannes.
Les solutions Microsoft SQL Server, PostgreSQL, MariaDB, Oracle, Milestone, Nedap, Docker, Podman, Hyper-V et KVM sont des exemples de modules miroirs. Vous pouvez créer votre propre module miroir pour votre application sur la base du module générique mirror.safe. Voir ici une liste des modules.
Notez que les modules miroirs Hyper-V et KVM répliquent des machines virtuelles entières, y compris les applications et les systèmes d'exploitation. Ils ne nécessitent pas d'adresse IP virtuelle, car le redémarrage de la machine virtuelle gère le basculement de l'adresse IP physique de la VM.
Le cluster miroir fonctionne comme suit.
1.2.2 Étape 1. Fonctionnement normal
Le serveur 1 (PRIM) exécute l'application.
SafeKit réplique les fichiers ouverts par l'application. Seules les modifications apportées par l'application dans les fichiers sont répliquées en temps réel sur le réseau, limitant ainsi le trafic.
Pour la réplication, seuls les noms des répertoires de fichiers à répliquer sont configurés dans SafeKit. Il n'y a pas de conditions préalables à l'organisation des disques pour les deux serveurs. Les répertoires à répliquer peuvent se trouver sur le disque système.
1.2.3 Étape 2. Basculement
Lorsque le serveur 1 tombe en panne, le serveur 2 prend le relais. SafeKit bascule l'adresse IP virtuelle et redémarre automatiquement l'application sur le serveur 2. L'application retrouve les fichiers répliqués par SafeKit à jour sur le serveur 2, grâce à la réplication synchrone entre le serveur 1 et le serveur 2. L'application continue de s'exécuter sur le serveur 2 en modifiant localement ses fichiers qui ne sont plus répliqués sur le serveur 1.
Le temps de basculement est égal au temps de détection des pannes (défini à 30 secondes par défaut) plus le temps de démarrage de l'application. Contrairement aux solutions de réplication de disque, il n'y a pas de délai pour le remontage des systèmes de fichiers et l'exécution des procédures de récupération.
1.2.4 Étape 3. Réintégration et resynchronisation
La réintégration consiste à redémarrer le serveur 1 après avoir résolu le problème qui l'a mis en panne. SafeKit resynchronise automatiquement les fichiers, en ne mettant à jour que les fichiers modifiés sur le serveur 2 lorsque le serveur 1 a été arrêté.
Cette réintégration automatique s'effectue sans arrêter l'application, qui peut continuer à s'exécuter sur le serveur 2. Il s'agit d'une caractéristique majeure qui différencie SafeKit des autres solutions, qui nécessitent des opérations manuelles pour réintégrer le serveur 1 dans le cluster.
1.2.5 Étape 4. Retour au fonctionnement normal
Après la réintégration, les fichiers sont à nouveau en mode miroir, comme à l'étape 1. Le système est de nouveau en mode haute disponibilité, l'application s'exécutant sur le serveur 2 et SafeKit répliquant les mises à jour des fichiers sur le serveur 1.
Si les administrateurs souhaitent que l'application s'exécute sur le serveur 1, ils peuvent exécuter une commande « Stop / Start » sur le serveur PRIM soit à travers la console au moment opportun, soit automatiquement via la configuration d’un serveur primaire par défaut.
1.2.6 Réplication synchrone et réplication asynchrone
Il existe une différence significative entre la réplication synchrone, telle qu'elle est proposée par la solution miroir de SafeKit, et la réplication asynchrone traditionnellement proposée par d'autres solutions de réplication de fichiers.
Avec la réplication synchrone, lorsqu'une E/S disque est effectuée par l'application sur le serveur primaire à l'intérieur d'un fichier répliqué, SafeKit attend l'accusé de réception d'E/S du disque local et du serveur secondaire, avant d'envoyer l'accusé de réception d'E/S à l'application. Ce mécanisme est essentiel pour la récupération des applications transactionnelles.
La latence d'un LAN (généralement un aller-retour de moins de 2 ms) entre les serveurs est nécessaire pour mettre en œuvre la réplication synchrone des données, éventuellement avec un LAN étendu dans deux salles informatiques géographiquement éloignées.
Avec la réplication asynchrone implémentée par d'autres solutions, les E/S sont placées dans un journal sur le serveur primaire, mais le serveur primaire n'attend pas les accusés de réception d'E/S du serveur secondaire. Ainsi, toutes les données qui n'ont pas été copiées à travers le réseau sur le deuxième serveur sont perdues en cas de défaillance du premier serveur.
En particulier, une application transactionnelle peut perdre des données validées en cas de défaillance. La réplication asynchrone peut être utilisée pour la réplication de données sur un WAN à faible vitesse afin de sauvegarder des données à distance (backup), mais elle n'est pas adaptée à la haute disponibilité avec basculement automatique.
SafeKit fournit une solution semi-synchrone, mettant en œuvre l'asynchronisme non pas sur le serveur primaire mais sur le secondaire. Dans cette solution, SafeKit attend toujours l'accusé de réception des deux serveurs avant d'envoyer l'accusé de réception à l'application. Mais sur le secondaire, il y a 2 options asynchrone ou synchrone. Dans le cas asynchrone, le secondaire envoie l'accusé de réception au primaire à la réception de l'E/S et écrit sur le disque par la suite. Dans le cas synchrone, le secondaire écrit l'E/S sur le disque, puis envoie l'accusé de réception au primaire. Le mode synchrone est nécessaire si l'on considère une double panne de courant simultanée de deux serveurs, avec l’impossibilité de redémarrer l'ancien serveur primaire et la nécessité de redémarrer sur le serveur secondaire.
1.2.7 Comportement en cas d'isolation réseau
Un heartbeat est un mécanisme permettant de synchroniser deux serveurs et de détecter les défaillances en échangeant des données sur un réseau partagé. Si un serveur perd tous les heartbeats, il suppose que l'autre est en panne et exécute l'application seul (état ALONE).
SafeKit supporte plusieurs heartbeats sur plusieurs réseaux partagés. Un réseau dédié avec un deuxième heartbeat peut éviter l’isolation réseau et être également utilisé comme réseau de réplication.
Isolation réseau :
· Sur perte de tous les heartbeats, les deux serveurs passent à l’état ALONE, exécutant l'application indépendamment.
· Après l'isolation, un serveur s’arrête et resynchronise les données à partir de l’autre serveur.
· Le cluster revient à l'état PRIM-SECOND.
Checker splitbrain :
· Utilise une adresse IP témoin (généralement un routeur) pour éviter la double exécution pendant l’isolation réseau.
· Seul le serveur avec un accès au témoin passe ALONE ; l'autre attend (WAIT).
· Après l'isolation, le serveur WAIT se resynchronise et devient SECOND.
1.2.8 Réplication à 3 nœuds
SafeKit ne supporte la réplication qu'entre deux nœuds. Cependant, il est possible de mettre en œuvre une réplication à 3 nœuds en combinant SafeKit avec une solution de sauvegarde.
Une application est rendue hautement disponible entre 2 nœuds grâce à SafeKit avec sa réplication synchrone en temps réel (sans perte de données) et son basculement automatique. De plus, une solution de sauvegarde est mise en œuvre pour la réplication asynchrone vers un troisième nœud dans un site de reprise après sinistre. Étant donné qu'il y a une perte de données avec une solution de sauvegarde asynchrone, le basculement vers le troisième nœud est manuel et décidé par un administrateur.
Notez que la réplication en temps réel de SafeKit n'élimine pas la nécessité d'une solution de sauvegarde. Par exemple, une attaque par ransomware chiffrant les données répliquées sur le serveur primaire chiffrera également les données sur le serveur secondaire en temps réel avec SafeKit. Seule une solution de sauvegarde avec une politique de rétention peut résoudre une attaque par ransomware. L'administrateur doit restaurer la sauvegarde d'avant l'attaque par ransomware.
1.2.9 SafeKit sur un seul nœud pour résister aux pannes logicielles
Vous pouvez configurer un module en mode "light", ce qui correspond à un module fonctionnant sur un seul nœud sans se synchroniser avec d'autres nœuds (contrairement aux modules miroir ou ferme). Un module "light" inclut le démarrage et l'arrêt d'une application, ainsi que les vérificateurs SafeKit qui détectent les erreurs logicielles et effectuent des redémarrages automatiques sur un seul nœud.
Le module "light" s'interface avec la console SafeKit, permettant à un administrateur de visualiser l'état du module applicatif et de déclencher manuellement des redémarrages de l'application via une interface clic-bouton.
Il n'est pas nécessaire de définir une adresse IP virtuelle ou des répertoires à répliquer dans un module "light". Notez que cela peut servir également de première étape avant de passer à un module miroir ou à un module ferme
1.3 Le cluster ferme de SafeKit
1.3.1 Équilibrage de charge réseau et basculement d’application
Le cluster ferme est une solution de haute disponibilité active-active, créée en déployant un module ferme au sein d'un cluster de deux nœuds ou plus. Le cluster ferme fournit à la fois l'équilibrage de la charge réseau, grâce à une distribution transparente du trafic réseau, et le basculement logiciel et matériel. Cette architecture offre une solution simple pour supporter l’augmentation de la charge du système.
La même application s'exécute sur chaque serveur, et la charge est équilibrée par la répartition de l'activité réseau sur les différents serveurs de la ferme.
Les clusters fermes sont adaptés aux applications frontales telles que les services Web.
Les solutions Apache, Microsoft IIS, NGINX sont des exemples de modules ferme. Vous pouvez écrire votre propre module ferme pour votre application, basé sur le module générique farm.safe. Voir ici pour une liste des modules.
1.3.2 Principe d'une adresse IP virtuelle avec équilibrage de charge réseau
L'adresse IP virtuelle est configurée localement sur chaque serveur de la ferme. Le trafic en entrée pour cette adresse est réparti entre tous les serveurs par un filtre au sein du noyau de chaque serveur.
L'algorithme d'équilibrage de charge à l'intérieur du filtre est basé sur l'identité des paquets clients (adresse IP du client, port TCP du client). En fonction de l'identité du paquet client, un seul filtre sur un serveur accepte le paquet. Une fois qu'un paquet est accepté par le filtre sur un serveur, seuls le processeur et la mémoire de ce serveur sont utilisés par l'application répondant à la demande du client. Les messages de sortie sont envoyés directement du serveur d'application au client.
En cas de défaillance d'un serveur, le protocole de heartbeat de SafeKit dans une ferme reconfigure les filtres pour rééquilibrer le trafic entre les serveurs disponibles restants.
1.3.3 Équilibrage de charge pour les services Web avec ou sans état
Avec un serveur à état, l'affinité de session est requise. Le même client doit se connecter au même serveur sur plusieurs sessions TCP pour récupérer son contexte. Dans ce scénario, la règle d'équilibrage de charge dans SafeKit est configurée sur l'adresse IP du client. Cela garantit que le même client se connecte toujours au même serveur sur plusieurs sessions TCP, tandis que différents clients sont répartis sur différents serveurs de la ferme. Cette configuration est nécessaire lorsqu’il y a affinité de session.
Avec un serveur sans état, il n'y a pas d'affinité de session. Le même client peut se connecter à différents serveurs de la ferme sur plusieurs sessions TCP, car aucun contexte n'est stocké localement sur un serveur d'une session à l'autre. Dans ce cas, la règle d'équilibrage de charge dans SafeKit est configurée sur l'identité de session du client TCP. Cette configuration est optimale pour la distribution des sessions entre les serveurs, mais nécessite un service TCP sans affinité de session.
1.3.4 Solution de haute disponibilité en chaîne dans une ferme
Qu'est-ce qu'une solution de haute disponibilité en chaîne (également connue sous le nom de solution de haute disponibilité en cascade) ?
· Plusieurs serveurs sont liés en séquence : Si un serveur tombe en panne, le suivant dans la chaîne prend le relais.
· Gestion basée sur la priorité : Un seul serveur gère toutes les requêtes des clients, celui ayant la plus haute priorité dans la chaîne et qui est disponible.
· Processus de basculement : Si le serveur ayant la plus haute priorité tombe en panne, le prochain serveur disponible avec la plus haute priorité prend le relais.
· Réintégration : Lorsqu'un serveur revient en ligne et qu'il a la plus haute priorité, il reprend la gestion de toutes les requêtes des clients.
· Temps de récupération rapide : Cette solution a un temps de récupération rapide, car l'application est pré-démarrée sur tous les serveurs. Le temps de récupération est essentiellement le temps nécessaire pour reconfigurer les priorités entre les serveurs de la ferme (quelques secondes).
· Limitations de la réplication : Cette solution ne prend pas en charge la réplication en temps réel, qui est limitée à l'architecture miroir. Cependant, une architecture combinée ferme+miroir est disponible.
Pour mettre en œuvre une solution de haute disponibilité en chaîne, SafeKit offre une variable “power” dans les règles d'équilibrage de charge : elle se définit au niveau de chaque serveur du cluster. La variable power vous permet d'allouer plus ou moins de trafic à un serveur. Lorsque la variable power est définie comme un multiple de 64 entre les serveurs (par exemple, 1, 64, 64*64, 64*64*64, ...), la solution de haute disponibilité en chaîne est mise en œuvre
1.4 Clusters exécutant plusieurs modules
1.4.1 Le cluster ferme+miroir de SafeKit
Équilibrage de charge réseau, réplication de fichiers et basculement d'applications
Vous pouvez mélanger des modules ferme et miroir sur le même cluster.
Cette option vous permet d'implémenter une architecture d'application multiniveau, telle que apache_farm.safe (architecture ferme avec équilibrage de charge et basculement) et postgresql.safe (architecture miroir avec réplication de fichiers et basculement) sur les mêmes serveurs.
Par conséquent, l'équilibrage de charge, la réplication de fichiers et le basculement sont gérés de manière cohérente sur les mêmes serveurs.
1.4.2 Le cluster actif/actif avec réplication de SafeKit
Réplication croisée et basculement mutuel
Dans un cluster actif/actif avec réplication, il y a deux serveurs et deux modules miroirs en basculement mutuel (appli1.safe et appli2.safe). Chaque serveur d'application est une sauvegarde de l'autre serveur.
En cas de défaillance d'un serveur d'application, les deux applications s'exécutent sur le même serveur physique. Une fois le serveur défaillant redémarré, son application revient à son serveur primaire par défaut.
Un cluster de basculement mutuel est plus rentable que deux clusters miroirs distincts, car il élimine le besoin de serveurs de sauvegarde qui restent inactifs la plupart du temps, en attendant qu'un serveur principal tombe en panne. Toutefois, en cas de défaillance d'un serveur, le serveur restant doit être capable de gérer la charge de travail combinée des deux applications.
Notez que :
· Les deux applications, Appli1 et Appli2, doivent être installées sur chaque serveur pour permettre le basculement des applications.
· Cette architecture n'est pas limitée à deux applications ; N modules applicatifs peuvent être déployés sur les deux serveurs.
· Chaque module miroir aura sa propre adresse IP virtuelle, ses propres répertoires de fichiers répliqués et ses propres scripts de reprise.
1.4.3 Le cluster N-1 de SafeKit
Réplication et basculement d'applications de N serveurs vers 1
Dans un cluster N-1, N modules applicatifs miroirs sont déployés sur N serveurs principaux et un seul serveur de sauvegarde.
En cas de panne, contrairement à un cluster actif/actif, le serveur de sauvegarde n'a pas besoin de gérer une double charge de travail en cas de défaillance d'un serveur principal. Cela suppose qu'une seule défaillance se produit à la fois. Bien que la solution puisse prendre en charge plusieurs pannes de serveur principal simultanément, dans ce cas, le serveur de sauvegarde unique devra gérer la charge de travail combinée de tous les serveurs défaillants. Dans un cluster N-1, N modules applicatifs miroirs sont installés entre N serveurs principaux et un serveur de sauvegarde.
Notez que :
· Toutes les applications (Appli1, Appli2, Appli3) doivent être installées sur le serveur de sauvegarde unique pour permettre le basculement des applications.
· Chaque module miroir aura sa propre adresse IP virtuelle, ses propres répertoires de fichiers répliqués et ses propres scripts de reprise.
1.5 Le cluster Hyper-V ou KVM de SafeKit
1.5.1 Équilibrage de charge, réplication, basculement de machines virtuelles complètes
Le cluster Hyper-V ou KVM est un exemple de cluster actif-actif. Plusieurs applications peuvent être hébergées dans diverses machines virtuelles, qui sont répliquées et redémarrées par SafeKit. Chaque machine virtuelle est gérée par SafeKit au sein de son propre module miroir.
La solution présente les caractéristiques suivantes :
· Réplication synchrone en temps réel de machines virtuelles entières avec des capacités de basculement.
· Une console SafeKit centralisée et conviviale pour la gestion de toutes les machines virtuelles, y compris la possibilité de migrer des machines virtuelles entre les serveurs afin d'optimiser la répartition de la charge.
· Un checker pour chaque machine virtuelle afin de détecter si elle s'est verrouillée, s'est bloquée ou a cessé de fonctionner, et de redémarrer la machine virtuelle si nécessaire.
· Une solution attrayante qui ne nécessite aucune intégration d'application.
· Une architecture robuste adaptée aux solutions à haute disponibilité qui ne peuvent pas être intégrées au niveau applicatif.
Une version d'essai gratuite du cluster Hyper-V avec SafeKit est disponible ici.
Une version d'essai gratuite du cluster KVM avec SafeKit est disponible ici.
1.6 Clusters SafeKit dans le cloud
Pour une description complète, voir la section 16.
1.6.1 Cluster miroir dans Azure, AWS et GCP
SafeKit fournit des clusters de haute disponibilité avec réplication en temps réel et basculement dans Azure, AWS et GCP grâce au déploiement d'un module miroir.
La solution miroir dans le cloud est similaire à celle sur site, sauf que l'adresse IP virtuelle doit être configurée au niveau de l'équilibreur de charge :
· Les machines virtuelles sont placées dans différentes zones de disponibilité, qui se trouvent dans des sous-réseaux différents.
· L'application critique s'exécute sur le serveur primaire.
· Les utilisateurs se connectent à une adresse IP virtuelle primaire/secondaire gérée par l'équilibreur de charge du cloud.
· SafeKit fournit un « health check » configuré dans l'équilibreur de charge. Sur le serveur primaire, le « health check » renvoie OK à l'équilibreur de charge, tandis qu'il ne renvoie rien sur le serveur secondaire. Ainsi, toutes les requêtes adressées à l'adresse IP virtuelle sont acheminées vers le serveur primaire.
· Si le serveur primaire tombe en panne ou est arrêté, le serveur secondaire devient automatiquement le serveur primaire et renvoie OK au « health check ». Ainsi, toutes les requêtes adressées à l'adresse IP virtuelle sont redirigées vers le nouveau serveur primaire.
· SafeKit surveille l'application critique sur le serveur primaire à l'aide des checkers de SafeKit.
· SafeKit redémarre automatiquement l'application critique en cas de défaillance logicielle ou matérielle, grâce à des scripts de redémarrage.
· SafeKit effectue une réplication synchrone en temps réel des fichiers contenant les données critiques.
Pour plus d'informations, consultez le cluster miroir dans Azure, le cluster miroir dans AWS ou le cluster miroir dans GCP.
1.6.2 Cluster ferme dans Azure, AWS et GCP
SafeKit fournit des clusters à haute disponibilité avec équilibrage de charge réseau et basculement dans Azure, AWS et GCP grâce au déploiement d'un module ferme.
La solution ferme dans le cloud est similaire à celle sur site, sauf que l'adresse IP virtuelle doit être configurée au niveau de l'équilibreur de charge :
· Les machines virtuelles sont placées dans différentes zones de disponibilité, qui se trouvent dans des sous-réseaux différents.
· L'application critique s'exécute sur tous les serveurs.
· Les utilisateurs sont connectés à une adresse IP virtuelle gérée par l'équilibreur de charge du cloud.
· SafeKit fournit un « health check » configuré dans l'équilibreur de charge. Le « health check » renvoie OK sur tous les serveurs exécutant l'application.
· SafeKit surveille l'application critique sur tous les serveurs à l'aide des checkers de SafeKit.
· SafeKit redémarre automatiquement l'application critique sur un serveur en cas de défaillance logicielle, grâce à des scripts de redémarrage.
Pour plus d'informations, consultez le cluster ferme dans Azure, le cluster ferme dans AWS ou le cluster ferme dans GCP
2. Installation
Section 2.1 « Installation de SafeKit »
Section 2.2 « Recommandation pour une installation d'un
module miroir »
Section 2.3
« Recommandation pour une installation d'un module ferme »
Section 2.4
« Upgrade de SafeKit »
Section 2.5
« Désinstallation complète de SafeKit »
Section 2.6 « Documentations SafeKit »
2.1 Installation de SafeKit
2.1.1 Télécharger le package
1. Se connecter à https://support.evidian.com/safekit
2. Aller dans <Version 8.2>/Platforms/<Your platform>/Current versions
3. Télécharger le package
En Windows, deux packages sont disponibles :
o
un package Windows Installer (safekit_windows_x86_64_8_2_x_y.msi)
Il dépend du runtime C VS2022 qui doit être préalablement installé
· un bundle exécutable autonome (safekit_windows_x86_64_8_2_x_y.exe) qui contient l’installation SafeKit et le runtime C VS2022
Choisir l’un ou l’autre package suivant que le runtime C VS2022 est installé ou non.
2.1.2 Répertoires d'installation et espace disque
SafeKit est installé dans :
SAFE |
· sur Windows SAFE=C:\safekit · sur Linux SAFE=/opt/safekit |
Espace disque libre au minimum : 97MB
|
SAFEVAR |
· sur Windows SAFEVAR= C:\safekit\var si %SYSTEMDRIVE%=C: · sur Linux SAFEVAR=/var/safekit |
Espace disque libre minimum : 20MB + au moins 20MB (jusqu’à 3 GB) par module pour les dumps
|
2.1.3 Procédure d’installation de SafeKit
2.1.3.1 Installation sur Windows en tant qu’Administrateur
2.1.3.1.1 Installation du package SafeKit
1. Se loguer en tant qu’administrateur sur le serveur Windows
2. Localiser le fichier téléchargé safekit_windows_x86_64_8_2_x_y.msi (ou safekit_windows_x86_64_8_2_x_y.exe)
3. Installer en mode interactif en double-cliquant dessus puis dérouler l’assistant d’installation.
Avant SafeKit 8.2.3, après l’installation, vous devez exécuter les scripts de configuration du pare-feu (voir la section 10.3) et d’initialisation du service web SafeKit (voir la section 11.2.1.2).
Depuis SafeKit 8.2.3, à la fin de l’installation, il vous est demandé de cocher ou décocher « Définir les identifiants de la console et les règles du pare-feu maintenant. ».
Si la case reste cochée, lorsque le bouton « Terminer » est cliqué :
· Le pare-feu Microsoft est configuré pour SafeKit. Pour plus de détails ou d’autres pare-feu, voir la section 10.3.
· Une fenêtre est ouverte pour entre le mot de passe de l’utilisateur admin de la console web de SafeKit.
Cette étape est obligatoire pour initialiser la configuration par défaut du service web qui nécessite de s’authentifier. Elle est initialisée avec l’utilisateur admin et le mot de passe saisi, par exemple pwd. Cela permet ensuite d’accéder à toutes les fonctionnalités de la console web, en se connectant avec admin/pwd, et d’exécuter des commandes distribuées. Pour plus de détails, voir la section 11.2.1.
|
Le mot de passe doit être identique sur tous les nœuds qui appartiennent au même cluster SafeKit. Sinon, la console web et les commandes distribuées échoueront avec des erreurs d'authentification. |
Ou
3. Installer le .msi en mode non interactif en exécutant dans un terminal PowerShell en tant qu’administrateur:
msiexec /qn /i safekitwindows_8_2_x_y.msi
Une fois installé, la configuration du pare-feu et l’initialisation du service web SafeKit doivent être effectués.
2.1.3.1.2 Paramétrage du pare-feu
Cette étape est obligatoire pour permettre les communications entre les nœuds du cluster SafeKit, et avec la console web.
Aucune action supplémentaire n’est requise lorsque la configuration automatique du pare-feu a été appliquée pendant l'installation du package >= 8.2.3. Sinon, voir la section 10.3.
2.1.3.1.3 Initialisation du service web SafeKit
Cette initialisation est nécessaire pour la console web et les commandes distribuées.
Aucune action requise si l’initialisation a été faite pendant l’installation du package >= 8.2.3. Sinon, voir la section 11.2.1.2.
2.1.3.1.4 Paramétrage des antivirus
Cette étape est nécessaire uniquement en cas d’interférence de l’antivirus du serveur sur le fonctionnement de SafeKit. Voir la section 10.5 pour la liste des répertoires et processus légitimes de SafeKit qui ne doivent pas être impactés par l’antivirus.
2.1.3.2 Installation sur Linux en tant que root
2.1.3.2.1 Installation du package SafeKit
1. Se loguer en tant que root sur le serveur Linux
2. Localiser le fichier téléchargé safekitlinux_x86_64_8_2_x_y.bin
3. Exécuter chmod +x safekitlinux_x86_64_8_2_x_y.bin
4. Exécuter ./safekitlinux_x86_64_8_2_x_y.bin
Cela extrait le package SafeKit et le script safekitinstall
5. Installer en mode interactif en exécutant ./safekitinstall
Pendant l’installation :
· Répondre à “Do you accept that SafeKit automatically configure the local firewall to open these ports (yes|no)?”
Si vous répondez yes, le pare-feu Linux firewalld ou iptable est configuré pour SafeKit. Pour plus de détails ou d’autres pare-feu, voir la section 10.3.
· Répondre à “Please enter a password or "no" if you want to set it later”.
La saisie d’un mot de passe est obligatoire pour initialiser la configuration par défaut du service web. Celui-ci nécessite en effet de s’authentifier pour y accéder.
Si vous répondez pwd par exemple, cette valeur est utilisée comme mot de passe pour l'utilisateur admin. Cela permet ensuite d’accéder à toutes les fonctionnalités de la console web, en se connectant avec admin/pwd, et d’exécuter des commandes distribuées. Pour plus de détails, voir la section 11.2.1.
Le mot de passe doit être identique sur tous les nœuds qui appartiennent au même cluster SafeKit. Sinon, la console web et les commandes distribuées échoueront avec des erreurs d'authentification. |
Ou
5. Installer en mode non interactif en exécutant :
./safekitinstall -q
Ajouter l’option -nofirewall pour ne pas configurer le pare-feu.
Ajouter l’option -passwd pwd pour initialiser l’authentification, requise par le service web (pwd est le mot de passe affecté à l’utilisateur admin).
Le journal d’installation est /tmp/safekitinstall_log.
2.1.3.2.2 Paramétrage du pare-feu
Cette étape est obligatoire pour permettre les communications entre les nœuds du cluster SafeKit et avec la console web.
Aucune action supplémentaire n’est requise lorsque la configuration automatique du pare-feu a été appliquée pendant l'installation du package. Sinon, voir la section 10.3.
2.1.3.2.3 Initialisation du service web SafeKit
Cette initialisation est nécessaire pour la console web et les commandes distribuées.
Aucune action requise si l’initialisation a été faite pendant l’installation du package. Sinon, voir la section 11.2.1.2.
2.1.3.2.4 Paramétrage des antivirus
Cette étape est nécessaire uniquement en cas d’interférence de l’antivirus du serveur sur le fonctionnement de SafeKit. Voir la section 10.5 pour la liste des répertoires et processus légitimes de SafeKit qui ne doivent pas être impactés par l’antivirus.
2.1.4 Utilisation de la console web et de la ligne de commande SafeKit
Une fois installé, le cluster SafeKit doit être défini. Ensuite, les modules peuvent être installés, configurés et administrés. Toutes ces actions peuvent être effectuées avec la console ou l'interface en ligne de commande.
2.1.4.1 La console web SafeKit
1. Démarrer un navigateur web (Microsoft Edge, Firefox ou Chrome)
2. Le connecter à l’URL http://host:9010 (où host est l’adresse IP ou le nom d’un nœud SafeKit)
3. Dans la section de login, s’identifier avec admin comme nom d’utilisateur et le mot de passe que vous avez donné pendant l’initialisation juste au-dessus (par exemple, pwd)
4. Une fois la
console chargée, l’utilisateur admin
a accès à la « Supervision » et
à la
« Configuration » dans la barre latérale de navigation, car il a le
rôle Admin par défaut
Pour une description complète, voir la section 3.
2.1.4.2 La ligne de commande SafeKit
Elle repose sur la commande unique safekit située à la racine du répertoire d’installation de SafeKit. Presque toutes les commandes safekit peuvent être appliquées localement ou sur une liste de nœuds du cluster SafeKit. C’est ce qui est appelé commande globale ou distribuée.
Pour une description complète de la commande, voir la section 9.
Pour utiliser la commande safekit :
1. Ouvrir une console PowerShell en tant qu’administrateur 2. Aller à la racine du répertoire d’installation de SafeKit SAFE (par défaut SAFE=C:\safekit si %SYSTEMDRIVE%=C:) cd c:\safekit 3. Exécuter .\safekit.exe <arguments> pour la commande locale 4. Exécuter .\safekit.exe -H "<hosts>" <arguments> pour la commande distribuée sur plusieurs nœuds |
|
En Linux |
1. Ouvrir une console Shell en tant que root 2. Aller à la racine du répertoire d’installation de SafeKit SAFE (par défaut SAFE=/opt/safekit) cd /opt/safekit 3. Exécuter ./safekit <arguments> pour la commande locale 4. Exécuter ./safekit -H "<hosts>" <arguments> pour la commande distribuée sur plusieurs nœuds |
Par exemple, pour afficher la version (SafeKit, OS…):
· pour le nœud local
safekit level
· pour tous les nœuds configurés dans le cluster SafeKit
safekit -H "*" level
2.1.5 Clés de licence SafeKit
Les clés de licence sont déterminées et vérifiées en fonction du système d'exploitation (Windows ou Linux) et des noms d'hôtes des machines (pas le FQDN), comme renvoyé par la commande hostname dans une invite de commandes Windows ou un shell Linux. Elles sont livrées dans un fichier texte. Une fois le fichier de clé de licence installé, il n'est plus nécessaire d'être connecté à un serveur de licence.
· Si vous n'installez pas de fichier de clé de licence, le produit cessera de fonctionner tous les 3 jours. Cependant, il peut être redémarré pour 3 jours supplémentaires.
· Vous pouvez télécharger un fichier de clé d'essai d'un mois à l'adresse suivante : https://www.evidian.com/products/high-availability-software-for-application-clustering/high-availability-and-load-balancing-cluster-key/
· Lorsque la clé de licence expire ou est incorrecte (par exemple, système d'exploitation ou nom d'hôte erroné), le système entre dans le comportement de 3 jours.
· Après avoir passé une commande d'achat, vous obtenez un fichier de clé permanent (voir section 8.2). Le fichier de clé permanent peut être installé sans réinstaller ou arrêter le produit.
· Le fichier de clé peut contenir des clés pour plusieurs noms d'hôtes. SafeKit détectera la licence appropriée pour le bon système d'exploitation/nouveau d'hôte sur chaque serveur.
· Enregistrez le fichier de clé dans le fichier SAFE/conf/license.txt (ou tout autre fichier dans SAFE/conf) sur chaque serveur.
· Si les fichiers dans SAFE/conf contiennent plus d'un fichier de clé, la clé la plus favorable sera choisie.
· Vérifiez la conformité de la clé sur chaque serveur avec la commande SAFE/safekit level ou avec la console web SafeKit.
2.1.6 Caractéristiques spécifiques à chaque OS
2.1.6.1 Windows
· Il faut appliquer une procédure spéciale pour arrêter proprement les modules SafeKit au shutdown d'une machine et démarrer le service safeadmin au boot (voir la section 10.4)
· En cas d'interfaces réseau en teaming avec du load balancing SafeKit, il est nécessaire de décocher "Vip" sur les interfaces réseau physiques de teaming et de le conserver coché seulement sur l'interface virtuelle de teaming
2.1.6.2 Linux
· En Linux, le package SafeKit dépend d’autres packages système. La plupart sont installés automatiquement, excepté ceux spécifiques à la mise en œuvre du load balancing dans une ferme et de la réplication de fichiers dans un miroir.
· Pour la liste à jour des packages nécessaires, voir le SafeKit Release Notes.
· L'utilisateur safekit et un groupe safekit sont créés : tous les utilisateurs appartenant au groupe safekit et l'utilisateur root peuvent exécuter des commandes SafeKit.
· Dans une ferme avec load balancing, le module kernel vip est compilé au moment de la configuration du module. Pour réussir la compilation, des packages Linux doivent être installés. Voir le SafeKit Release Notes pour une liste des packages à jour.
· En ferme avec load balancing sur une interface de bonding, pas d'ARP dans la configuration de bonding. Sinon l'association <adresse IP virtuelle, adresse MAC virtuelle invisible> est cassée dans les caches ARP des clients avec l'adresse MAC physique de la carte de bonding.
· En mode miroir, si utilisation de la réplication de fichiers, installer le package nfs-util et retirer le package logwatch (rpm -e logwatch) ; sinon le service NFS et SafeKit seront arrêtés toutes les nuits
2.2 Recommandation pour une installation d'un module miroir
ip 1.1 ip 1.2 |
virtual ip = ip 1.10
miroir(app1)= app1
dir1 dir1 |
2.2.1 Prérequis matériel
· au moins 2 serveurs avec le même système d’exploitation
· OS supportés : https://support.evidian.com/supported_versions/#safekit
· Contrôleur disque avec cache write-back recommandé pour la performance des IO
2.2.2 Prérequis réseau
· 1 adresse IP physique par serveur (ip 1.1 et ip 1.2)
· Si vous devez définir une adresse IP virtuelle (ip 1.10), les deux serveurs doivent appartenir au même réseau IP avec la configuration standard de SafeKit (LAN ou LAN étendu entre deux salles informatiques distantes). Dans le cas contraire, voir une alternative dans la section 13.5.3.
2.2.3 Prérequis application
· L'application est installée et démarre sur les 2 serveurs
· L'application fournit des commandes en ligne pour démarrer et s'arrêter
· Sur Linux, commandes du style : service "service" start|stop ou su -user "appli-cmd"
· Sur Windows, commandes du style : net start|stop "service"
· Si nécessaire, définir une procédure de reprise suite à un crash serveur
· Retirer le démarrage automatique au boot de l'application et le remplacer par la configuration du démarrage au boot du module SafeKit
2.2.4 Prérequis réplication de fichiers
· Les répertoires de fichiers qui seront répliqués sont créés sur les 2 serveurs
· Ils se situent au même endroit sur les 2 serveurs dans l'arborescence fichier
· Il vaut mieux synchroniser les horloges des 2 serveurs pour la réplication de fichiers (protocole NTP)
· Sous Linux, aligner les valeurs des uids/gids sur les 2 serveurs pour les propriétaires des répertoires et fichiers à répliquer
· Voir aussi la section 2.1.6
2.3 Recommandation pour une installation d'un module ferme
ip 1.1 ip 1.2 ip 1.3 |
virtual IP = ip 1.20 ip 1.20 ip 1.20
ferme (app2) = app2 app2 app2 |
2.3.1 Prérequis matériel
· au moins 2 serveurs avec le même OS
· OS supportés : https://support.evidian.com/supported_versions/#safekit
· Linux : outils de compilation du kernel installés pour le module kernel vip
2.3.2 Prérequis réseau
· 1 adresse IP physique par serveur (ip 1.1, ip 1.2, ip 1.3)
· Si vous devez définir une adresse IP virtuelle (ip 1.20), les serveurs doivent appartenir au même réseau IP avec la configuration standard de SafeKit (LAN ou LAN étendu entre les salles informatiques distantes). Dans le cas contraire, voir une alternative décrite dans la section 13.5.3
· voir aussi la section 2.1.6
2.3.3 Prérequis application
Les mêmes prérequis que pour un module miroir décrits en section 2.2.3.
2.4 Upgrade de SafeKit
Si vous rencontrez un problème avec SafeKit, consulter le Software Release Bulletin pour consulter la liste des fixs produits.
Si vous souhaitez profiter de nouvelles fonctionnalités, consulter le SafeKit Release Notes. Ce document vous indiquera également si vous êtes dans le cas d'un upgrade majeur (ex. 7.5 vers 8.2) qui nécessite d'effectuer une procédure différente de celle présentée ici.
La procédure d'upgrade consiste à désinstaller l'ancien package puis à réinstaller le nouveau package. Tous les nœuds du même cluster doivent être upgradé.
2.4.1 Préparer l'upgrade
1. Noter l'état "on" ou "off" des services et modules SafeKit démarrés automatiquement au boot
safekit boot webstatus ; safekit boot status -m AM (où AM est le nom du module) et en Windows : safekit boot snmpstatus
|
Le démarrage au boot du module peut être défini dans son fichier de configuration. Si c’est le cas, l’usage de la commande safekit boot devient inutile. |
2. Pour un module miroir
Noter le serveur qui est dans l'état ALONE ou PRIM afin de connaître le serveur avec les fichiers répliqués à jour
3. Prise de snapshots, facultative
La désinstallation/réinstallation va réinitialiser les logs SafeKit et effacer les dumps de chaque module. Si vous souhaitez conserver ces informations, exécuter la commande safekit snapshot -m AM /chemin/snapshot_xx.zip pour chaque module (où AM est le nom du module)
2.4.2 Procédure de désinstallation
Sur Windows en tant qu’administrateur et sur Linux en tant que root :
1. Arrêter tous les modules avec la commande safekit shutdown
Pour un module miroir dans l'état PRIM-SECOND, commencer par l'arrêt du serveur SECOND afin d'éviter un basculement inutile
2. Fermer tous les éditeurs, explorateur de fichiers, shells ou terminaux sous SAFE et SAFEVAR
3. Désinstaller le package SafeKit
In Windows |
Désinstaller via Control Panel-Add/Remove Programs applet |
In Linux |
Utiliser la commande safekit uninstall |
4. Défaire les modifications manuelles effectuées sur le pare-feu
Voir la section 10.3
La désinstallation de SafeKit inclut la création d’un backup des modules installés dans SAFE/Application_Modules/backup, puis leur déconfiguration.
2.4.3 Procédure de réinstallation et post-installation pour l’upgrade
1. Installer le nouveau package comme décrit dans la section 2.1
2. Vérifier avec la commande safekit level la version SafeKit installée et la validité de la licence qui n'a pas été désinstallée
3. Si vous avez un problème avec le nouveau package et l'ancienne clé, prendre une licence temporaire (voir section 2.1.5)
4. Si la console web est utilisée, vider le cache du navigateur web et forcer l’actualisation des pages HTML
5. Depuis SafeKit 8.2.1, les modules précédemment configurés sont automatiquement reconfigurés sur upgrade.
Cependant, vous pouvez avoir à reconfigurer quand même le module pour appliquer d’éventuelles évolutions de configuration apportées par la nouvelle version (consulter le SafeKit Release Notes). Reconfigurer le module soit avec :
o
la console web en naviguant sur « Configuration/Configuration
des modules/
Configurer le module/ »
o la console web en entrant directement l’URL http://host:9010/console/fr/configuration/modules/AM/config/
o la commande safekit config -m AM
o où AM est le nom du module
6. Reconfigurer le démarrage automatique du module au boot si nécessaire
7. Le démarrage du module au boot peut être défini dans son fichier de configuration. Si c’est le cas, passer cette étape. Si non, exécuter la commande safekit boot -m AM on (où AM est le nom du module)
8. Redémarrer les modules
Module miroir |
Le module doit être démarré en primaire sur le nœud ayant les fichiers répliqués à jour (ancien PRIM ou ALONE) : ·
Avec la console web en naviguant sur · Avec la commande safekit prim -m AM (remplacer AM par le nom du module) Vérifier que l'application fonctionne correctement une fois le module dans l'état ALONE avant de démarrer l'autre nœud. Sur l’autre nœud (ancien SECOND), le module doit être démarré en secondaire : ·
Avec la console web en naviguant sur · Avec la commande safekit second -m AM (remplacer AM par le nom du module) Une fois ce premier démarrage réalisé en sélectionnant les nœuds primaire et secondaire, les démarrages suivants peuvent être effectués avec : ·
Avec la console web en naviguant sur · Avec la commande safekit start -m AM (remplacer AM par le nom du module) |
Module ferme |
Démarrer le module soit avec : ·
Avec la console web en naviguant sur · Avec la commande safekit start -m AM (remplacer AM par le nom du module) |
De plus, dans les cas exceptionnels où vous aviez modifié la configuration par défaut du service web SafeKit ou de la surveillance SNMP.
1. Le service web de SafeKit safewebserver
· Si son démarrage automatique avait été désactivé, désactivez-le à nouveau avec la commande safekit boot weboff
· Si vous aviez modifié des fichiers de configuration et que ceux-ci ont évolué dans la nouvelle version, vos modifications ont été sauvegardées dans SAFE/web/conf avant d'être écrasées par la nouvelle version. Le report de votre ancienne configuration dans la nouvelle version peut nécessiter quelques adaptations. Pour plus de détails sur la configuration par défaut et toutes les configurations prédéfinies, voir la section 11.
Pour les configurations HTTPS et login/mot de passe, les certificats et les fichiers user.conf/group.conf générés pour la version précédente devraient être compatibles.
2. La surveillance SNMP de SafeKit
· En Windows, si son démarrage automatique avait été activé, réactivez-le à nouveau avec la commande safekit boot snmpon
· Si vous aviez modifié des fichiers de configuration et que ceux-ci ont évolué dans la nouvelle version, vos modifications ont été sauvegardées dans SAFE/snmp/conf avant d'être écrasées par la nouvelle version. Le report de votre ancienne configuration dans la nouvelle version peut nécessiter quelques adaptations. Pour plus de détails, voir la section 10.9.
2.5 Désinstallation complète de SafeKit
Suivre la procédure décrite ci-dessous pour désinstaller complètement SafeKit.
2.5.1 Désinstallation sur Windows
1. Se loguer en tant qu’administrateur sur le serveur Windows
2. Arrêter tous les modules à l’aide de la commande safekit shutdown
3. Fermer tous les éditeurs, explorateur de fichiers, ou terminaux sous SAFE et SAFEVAR (SAFE=C:\safekit si %SYSTEMDRIVE%=C: ; SAFEVAR=C:\safekit\var si %SYSTEMDRIVE%=C:)
4. Désinstaller le package SafeKit via Control Panel-Add/Remove Programs
5. Redémarrer le serveur
6. Détruire le répertoire SAFE qui correspond à l’installation précédente de SafeKit
7. Défaire les modifications effectuées pour configurer le démarrage au boot/l’arrêt au shutdown de SafeKit
Voir la section 10.4
8. Défaire les modifications manuelles effectuées sur le pare-feu
Voir la section 10.3
2.5.2 Désinstallation sur Linux
1. Se loguer en tant que root sur le serveur Linux
2. Arrêter tous les modules à l’aide de la commande safekit shutdown
3. Fermer tous les éditeurs, explorateur de fichiers, ou terminaux sous SAFE et SAFEVAR (SAFE=/opt/safekit ; SAFEVAR=/var/safekit)
4. Désinstaller SafeKit avec la commande safekit uninstall -all et répondre yes lorsque cela est demandé pour confirmer la destruction de tous les répertoires créés lors de la précédente installation
5. Redémarrer le serveur
6. Défaire les modifications effectuées pour paramétrer les règles de pare-feu
Voir la section 10.3
7. Supprimer, l'utilisateur/groupe créés par l'installation précédente (par défaut safekit/safekit) avec les commandes :
userdel safekit
groupdel safekit
2.6 Documentations SafeKit
La solution SafeKit y est entièrement détaillée. |
|
Reportez-vous à cette formation en ligne pour un démarrage rapide de l'utilisation de SafeKit. |
|
Il contient : · Dernières instructions d'installation · Changements majeurs · Restrictions et problèmes connus · Instructions de migration |
|
Bulletin listant les packages SafeKit 8.2 avec la description des changements et des problèmes corrigés. |
|
Liste des problèmes et restrictions connus de SafeKit. D'autres KB sont accessibles sur le site support Evidian, mais sont accessibles uniquement aux utilisateurs enregistrés. Pour plus de détails sur le site support, voir la section 8. |
|
Il s'agit de ce guide. Veillez à consulter le guide
correspondant à votre numéro de version SafeKit. Celui-ci est installé avec
le package SafeKit et accessible via la console web sous Le lien ci-contre renvoie à la dernière version de ce guide. |
3. La console web de SafeKit
Section 3.1 « Démarrer
la console web »
Section 3.2
« Configurer un cluster SafeKit »
Section 3.3
« Configurer un module »
Section 3.4
« Superviser un module »
Section 3.5 « Snapshots et journaux du module pour le
débogage et support »
Section 3.6
« Sécuriser la console web »
La console web et l’API SafeKit ont évolué en SafeKit 8 par rapport aux versions précédentes. Par conséquent, la console livrée avec SafeKit 8 n’est capable d’administrer que des serveurs avec SafeKit 8 ; de plus, ceux-ci ne peuvent être administrés avec une ancienne console.
3.1 Démarrer la console web
La console web de SafeKit offre la possibilité d’administrer un cluster SafeKit. Un cluster SafeKit est un groupe de serveurs sur lesquels Safekit est installé et fonctionnel. Tous les serveurs appartenant à un cluster donné partagent la même configuration de cluster (liste des serveurs et réseaux utilisés) et communiquent entre eux afin d’avoir une vue globale des configurations des modules installés. Un même serveur ne peut appartenir à plusieurs clusters.
3.1.1 Lancer un navigateur web
· Le navigateur web peut être lancé sur n’importe quelle station de travail ou serveur ayant un accès réseau au(x) serveur(s) SafeKit et ayant l’autorisation d’accès
· Les réseaux, pare-feu et proxy doivent être configurés de manière à permettre l’accès à tous les serveurs SafeKit
· Le navigateur doit autoriser l’exécution de Javascript
· La console web a été validée avec les navigateurs Microsoft Edge, Firefox et Chrome
· Pour éviter les pop-ups de sécurité avec Microsoft Edge, il faut ajouter les adresses des serveurs SafeKit dans la zone des sites de confiance ou la zone d’Intranet local du navigateur
· Les messages dans la console sont affichés en anglais, français en fonction de la langue sélectionnée depuis la console
· Après upgrade de SafeKit, il est nécessaire de vider le cache du navigateur de façon à recharger la nouvelle console web. Pour cela, vous pouvez utiliser un raccourci clavier :
1. Ouvrir le navigateur sur n’importe quelle page web, et presser en même temps les touches Ctrl, Shift et Suppr
2. Cela ouvre une fenêtre de dialogue : cocher tous les items puis cliquer le bouton Nettoyer maintenant ou Supprimer.
3. Fermer le navigateur, arrêter tous les processus du navigateur qui continueraient à tourner en tâche de fond et le relancer pour la charger la console web
3.1.2 Connecter la console à un serveur SafeKit
Par défaut, l'accès à la console web nécessite que l’utilisateur s’authentifie avec un nom et mot de passe. A l’installation de SafeKit, vous avez dû l’initialiser avec l’utilisateur admin et lui affecter un mot de passe. Ce nom admin, et ce mot de passe sont suffisants pour accéder à toutes les fonctionnalités de la console. Pour plus de détails sur cette configuration, voir la section 11.2.1.
1. Lancer un navigateur web (Microsoft Edge, Firefox, or Chrome)
2. Le connecter à l’URL http://host:9010 (host est le nom ou l’adresse IP d’un des serveur SafeKit). Si HTTPS est configuré, il y a une redirection automatique sur https://host:9453.
3. Le serveur SafeKit sur laquelle la console est connectée (host dans l’URL) est nommé nœud de connexion. Ce nœud agit en tant que proxy pour communiquer au compte de la console avec tous les autres serveurs SafeKit.
|
Vous pouvez vous connecter à n'importe quel nœud du cluster puisque la console offre une vue et des actions globales. En cas d'erreur de connexion avec un nœud, connectez-vous à un autre nœud. |
4. Dans la page de login, s’identifier avec admin comme nom d’utilisateur et le mot de passe que vous avez donné pendant l’initialisation (par exemple, pwd).
5. La console web de SafeKit est chargée
· Quand la console est connectée à un serveur SafeKit sur lequel le cluster est configuré, le nom du nœud correspond au serveur (tel que défini dans la configuration du cluster) est affiché dans l’entête. Il s’agit du nœud de connexion (node1 dans l’exemple).
Si le cluster n’est pas encore configuré, aucun nom n’est affiché.
·
(1) Cliquer sur pour
ouvrir le menu afin d’accéder au Guide de l’utilisateur SafeKit, sélectionner
la langue, activer/désactiver le mode sombre et se déconnecter.
·
(2) Cliquer sur pour
réduire ou développer la barre latérale de navigation.
·
(3) Cliquer sur « Configuration » pour
configurer le cluster et les modules. La configuration n'est autorisée qu'aux
utilisateurs ayant le rôle Admin. Par défaut, l’utilisateur admin a le rôle Admin.
·
(4) Cliquer sur « Supervision » pour superviser et contrôler les
modules configurés. La supervision est autorisée aux utilisateurs qui ont les
rôles Admin, Control et Monitor. Avec le rôle Monitor, les actions sur les
modules (démarrage, arrêt...) sont interdites
La console web offre des aides contextuelles en cliquant
sur l’icône |
3.2 Configurer un cluster SafeKit
Le cluster SafeKit doit être défini avant d'installer, de configurer ou de démarrer un module SafeKit.
Le cluster est défini par un ensemble de réseaux et les adresses, sur ces réseaux, d’un groupe de serveurs SafeKit, appelés nœuds. Ces nœuds mettent en œuvre un ou plusieurs modules. Un serveur n’est pas obligatoirement connecté à tous les réseaux du cluster, mais tous les serveurs sont connectés à au moins un.
La configuration du cluster est sauvegardée du côté des serveurs dans le fichier cluster.xml (voir section 12). Pour que le fonctionnement soit correct, il est impératif que la configuration du cluster soit identique sur tous les nœuds.
Il est préférable de définir complètement tous les nœuds du cluster avant de configurer les modules. En effet, la modification de la configuration du cluster peut impacter la configuration et l’exécution des modules déjà installés. |
La page d’accueil de la configuration du cluster est accessible :
· Directement via l’URL http://host:9010/console/fr/configuration/cluster
Ou
·
En naviguant dans la console via « Configuration/Configuration du cluster »
Si le cluster n'est pas encore configuré, l'assistant de configuration du cluster s'ouvre automatiquement au chargement de la console web.
3.2.1 L’assistant de configuration du cluster
Ouvrir l’assistant de configuration :
· Directement via l’URL http://host:9010/console/fr/configuration/cluster/config
Ou
·
En naviguant dans la console via « Configuration/Configuration du cluster/
Configurer
le cluster »
L’assistant de configuration du cluster est un formulaire à étapes :
1. « Éditer la configuration du cluster » décrit en section 3.2.1.1
2. « Vérifier le résultat » décrit en section 3.2.1.2
3. pour « Quitter
l’assistant de configuration du cluster »
3.2.1.1 Éditer la configuration du cluster
L'assistant de configuration du cluster est un formulaire guidé étape par étape.
· (1) Remplir le formulaire pour affecter d’abord le nom convivial pour le réseau. Ce nom est utilisé plus tard pour configurer les réseaux de surveillance utilisés par un module.
Cliquer sur pour ajouter un nouveau nœud
/lan ou sur
pour supprimer un nœud/lan du
cluster.
|
Quand un nœud/lan est supprimé du cluster, tous les modules l’utilisant dans sa configuration peuvent devenir inutilisables. |
· (2) Saisir l’adresse IP du nœud, puis appuyer sur la touche tabulation pour vérifier la disponibilité du serveur et l’insertion automatique de son nom.
L'icône à côté de l'adresse reflète l’accessibilité du nœud.
|
|
· Modifier le nom du nœud si besoin. Ce nom est celui qui sera utilisé par le service d’administration de SafeKit pour identifier de manière unique chaque nœud du cluster. C’est également le nom affiché dans la console web.
· (3) Si besoin, cliquer sur « Configuration avancée » pour basculer sur l’édition du cluster au format XML.
Cliquer sur pour
ouvrir le Guide de l’utilisateur SafeKit sur la description de la configuration
dans le fichier cluster.xml.
· Cliquer sur « Recharger » pour abandonner vos modifications en cours et recharger la configuration d’origine.
· (4) Une fois l'édition terminée, cliquez sur « Sauvegarder et appliquer » pour enregistrer et appliquer la configuration à tous les nœuds du cluster.
|
Si besoin, vous pouvez réappliquer la configuration du cluster sur tous les nœuds sans la modifier. |
|
Pour des exemples de configuration du cluster avec deux réseaux voir la section 15.1.1 ; avec trois nœuds voir la section 15.2.1. |
3.2.1.2 Vérifier le résultat
· (1) Lire le résultat de la configuration sur chaque nœud :
o
« Succès » signifie que la configuration a
réussi.
o
« Échec »,
signifie que la configuration a échoué. Cliquer sur
pour
lire la sortie des commandes exécutées sur le nœud et rechercher l’erreur.
Vous pouvez avoir à modifier les paramètres saisis ou à vous connecter au
serveur afin de corriger le problème. Une fois l’erreur corrigée, Sauvegarder et appliquer à nouveau.
· (2) Cliquer sur « Configurer les modules » pour quitter l’assistant de configuration du cluster et naviguer vers la configuration des modules.
Ou
·
(3) Cliquer sur pour
« Quitter l’assistant de configuration du cluster »
et aller sur la page d’accueil de configuration du cluster.
3.2.2 Page d’accueil de la configuration du cluster
Lorsque le cluster est configuré, la page d’accueil de la configuration du cluster est accessible.
L’ouvrir :
· Directement avec http://host:9010/console/fr/configuration/cluster
Ou
·
En naviguant dans la console sur « Configuration/Configuration du cluster »
Dans cet exemple, la console est chargée depuis 10.0.0.107 qui correspond au nœud node1 dans le cluster existant. Il s’agit du nœud de connexion.
·
(1) Cliquer sur « Configuration »
dans la barre de navigation latérale
· (2) Cliquer sur l’onglet « Configuration du cluster »
Les nœuds configurés dans le cluster sont listés avec leur date de configuration
·
(3) Cliquer sur pour afficher des détails sur
le nœud.
Il s’agit du nom des lans et adresses définies dans la configuration du cluster, version et licence SafeKit, hostname et OS.
· (4) Cliquer sur l’un des boutons :
o
pour modifier la configuration
du cluster ou réappliquer la configuration courante. Cela ouvre l’assistant de
configuration du cluster et charge la configuration courante depuis le nœud de
connexion.
o
pour télécharger la
configuration du cluster au format XML depuis le nœud de connexion.
o
pour déconfigurer le cluster
sur un ou plusieurs nœuds.
3.3 Configurer un module
Une fois le cluster configuré, il est possible de configurer un nouveau module sur le cluster. La page d’accueil de la configuration des modules est accessible :
· Directement via l’URL http://host:9010/console/fr/configuration/modules
Ou
·
En naviguant dans la console via « Configuration/Configuration des modules »
S’il n’y a aucun module configuré, la console présente automatiquement la page pour configurer un « Nouveau Module ».
Pour des exemples de configuration de modules voir la section 15.
3.3.1 Sélectionner le nouveau module à configurer
Dans cet exemple, la console est chargée depuis 10.0.0.107 qui correspond au nœud node1 dans le cluster existant. Il s’agit du nœud de connexion.
·
Cliquer sur « Configuration »
dans la barre de navigation latérale
· (2) Cliquer sur l’onglet « Configuration des modules »
· (3) Cliquer sur « Nouveau module »
·
La page propose de sélectionner un nouveau module
parmi plusieurs propositions visibles en cliquant sur :
· Les « Principaux modules », notamment les modules génériques mirror.safe (voir la section 15.1.2) et farm.safe(voir la section 15.2.2) à utiliser pour l'intégration d'une nouvelle application dans une architecture miroir ou ferme.
Sont présentés les modules stockés sur le nœud de connexion, node1, sous SAFE/Application_Modules/generic, SAFE/Application_Modules/demo et SAFE/Application_Modules/published.
· Les « Modules archivés » sur le nœud de connexion qui sont sauvegardés lorsqu’un module est désinstallé sur ce nœud.
Ils sont récupérés depuis node1 sous SAFE/Application_Modules/backup.
· D’« Autres modules » qui sont des exemples d’utilisation de fonctionnalités de SafeKit dans des modules fournis en vue de tests uniquement. Voir la section 15 pour la description de certains d’entre eux.
Ils sont récupérés depuis node1 sous SAFE/Application_Modules/other.
· Un module stocké localement accessible depuis « Charger un module ».
Cette fonctionnalité peut être utilisée pour configurer un module, pour une application donnée (par exemple, Microsoft SQL Server, PostgreSQL…), téléchargé depuis l'un des guides d'installation rapide de SafeKit.
· (4) Sélectionner un module à configurer parmi les propositions listées ci-dessus. Dans l’exemple, mirror.safe.
·
(5) Cliquer sur le bouton « Configurer le nouveau module ».
· Un dialogue s’ouvre pour saisir le nom du nouveau module
· (6) Entrer le nom du nouveau module
· (7) Cliquer sur « Confirmer »
L’assistant de configuration du module est ouvert. Celui-ci est décrit ci-dessous.
3.3.2 L’assistant de configuration du module
L’assistant de configuration du module est un formulaire à étapes :
1. « Éditer la configuration du module » décrit en section 3.3.2.1
2. « Éditer les scripts du module (Optionnel) » décrit en section 3.3.2.2
3. « Activer le cryptage des communications (Optionnel) » décrit en section 3.3.2.3
4. « Sauvegarder et appliquer » décrit en section 3.3.2.4
5. « Vérifier le résultat » décrit en section 3.3.2.5
6.
pour « Quitter l’assistant de configuration du module »
Notez que la reconfiguration d’un module ne peut être appliquée qu'aux nœuds sur lesquels le module en question n'est pas démarré. Il convient donc d'arrêter le module avant de lancer l'assistant de configuration.
Si besoin, vous pouvez réappliquer la configuration du module sur tous les nœuds sans la modifier. |
3.3.2.1 Éditer la configuration du module
Ci-dessous l'exemple de l'édition de la configuration du module miroir mirror.safe.
·
(1) Remplir le formulaire pour affecter les valeurs aux
différents composants, en ajouter ou en supprimer. Cliquer sur pour
ouvrir le panneau détaillé pour chaque composant.
Ce formulaire permet de saisir uniquement les principaux paramètres de configuration du module.
|
Le nom des « Réseaux de heartbeat » proposés sont les noms des lans saisis lors de la configuration du cluster. |
· (2) Pour une configuration avancée du module, exhaustive par rapport au formulaire, cliquer sur « Configuration avancée ». Cela bascule sur l’édition du fichier de configuration du module au format XML, userconfig.xml.
Cliquer sur pour
ouvrir le Guide de l’utilisateur SafeKit sur la description de la configuration
des différents composants dans le fichier userconfig.xml.
· Si besoin, cliquer sur « Recharger » pour abandonner vos modifications et recharger la configuration complète d’origine (y compris les scripts si ceux-ci avaient été modifiés dans l’étape suivante).
· (3) Une fois l’édition de la configuration du module achevée, cliquer sur « Étape suivante ».
|
Pour des exemples de configuration d’un module miroir voir la section 15.1.2 ; d’un module ferme voir la section 15.2.2 . |
3.3.2.2 Éditer les scripts du module
Ci-dessous l'exemple de l'édition des scripts du module miroir mirror.safe.
· (1) Cliquer sur « start_prim » ou « stop_prim » pour l’éditer et y insérer le démarrage/arrêt de votre application.
Cliquer sur pour
copier le contenu du script et l’éditer avec votre éditeur syntaxique favori.
Une fois fait, copier le contenu mis à jour dans le champ d’input avec
.
· (2) Si besoin, cliquer sur « Configuration Avancée » pour lister les autres scripts du module et les éditer (prestart, poststop, scripts pour les checkers…).
Cliquer sur pour
ouvrir le Guide de l’utilisateur SafeKit sur la description des scripts du
module.
· Si besoin, cliquer sur « Recharger » pour abandonner vos modifications et recharger la configuration complète d’origine (y compris la configuration du module si celle-ci avait été modifiée dans l’étape précédente).
· (3) Une fois l’édition des scripts du module achevée, cliquer sur « Étape suivante ».
|
Pour des exemples de scripts d’un module miroir voir la section 15.1.3 ; d’un module ferme voir la section 15.2.3. |
3.3.2.3 Activer le cryptage des communications
Le cryptage des communications internes du module entre les nœuds du cluster, est activé par défaut. Pour plus de détails, voir la section 10.6.
· (1) Cliquer Activer pour activer ou désactiver le cryptage des communications du module.
|
Lorsque la clé de cryptage du module n’est pas identique sur tous les nœuds, la communication interne est impossible. Il faut réappliquer la configuration sur tous les nœuds pour propager la même clé. |
Pour générer de nouvelles clés de cryptage, il faut :
1. Désactiver le cryptage, puis « Sauvegarder et appliquer » la configuration sur tous les nœuds
2. Activer le cryptage, puis « Sauvegarder et appliquer » la configuration sur tous les nœuds
· Si besoin, cliquer sur « Recharger » pour abandonner vos modifications et recharger la configuration complète d’origine (y compris la configuration du module et les scripts si ceux-ci avaient été modifiées dans les étapes précédentes).
· (2) Une fois cette étape achevée, cliquer sur « Étape suivante ».
3.3.2.4 Sauvegarder et appliquer
Étape de sélection des nœuds concernés par la configuration.
· (1) Cochez/décochez pour sélectionner/désélectionner les nœuds. Veuillez noter que le nœud de connexion (node1 dans l'exemple) est obligatoire.
Il y a 2 cas où « Sauvegarder et appliquer » est désactivé :
Le module sur le nœud sélectionné est démarré et
dans un état différent de |
Le nœud sélectionné n’a pas répondu dans le délai imparti. Cela peut être dû à une mauvaise adresse, une défaillance du réseau ou du serveur, une mauvaise configuration du navigateur web ou du pare-feu, l’arrêt du service web SafeKit sur le nœud. Pour investiguer le problème, voir la section 7.1. |
Dans les deux cas, décochez le nœud ou cliquer sur « Sauvegarder et vérifier » pour l'appliquer plus tard, après avoir arrêté le module ou résolu le problème de communication.
· (2) Cliquer sur « Sauvegarder et vérifier » pour sauvegarder la configuration modifiée sur le nœud de connexion et vérifier sa cohérence. Il passe ensuite à l'étape suivante pour afficher le résultat de cette opération.
Une fois cette opération terminée, toutes les modifications sont enregistrées sur le nœud de connexion. L'assistant de configuration peut être quitté et relancé ultérieurement pour appliquer la configuration sauvegardée. Tant que la configuration sauvegardée n'est pas appliquée, la dernière configuration appliquée reste active.
· (3) Cliquer sur « Sauvegarder et appliquer » pour sauvegarder et appliquer la configuration modifiée aux nœuds sélectionnés. Il passe ensuite à l'étape suivante pour afficher le résultat de cette opération.
Si l'opération est réussie, la configuration appliquée devient la configuration active du module.
|
La configuration du module est sauvegardée du côté serveur sous SAFE/modules/AM (où AM est le nom du module). Lors de la reconfiguration du module, ce répertoire est détruit et écrasé à partir des modifications faites dans la console. Du côté serveur, fermer tous les éditeurs, explorateur de fichiers, shells ou cmd sous SAFE/modules/AM (au risque sinon que la configuration se passe mal). |
3.3.2.5 Vérifier le résultat
L’exemple ci-dessous montre le résultat de l’opération « Sauvegarder et appliquer ». La présentation pour « Sauvegarder et vérifier » est similaire.
· (1) Lire le résultat de l’opération sur chaque nœud :
o
« Succès » signifie que l’opération a
réussi
o
« Échec »,
signifie que l’opération a échoué.
Cliquer sur pour
lire la sortie des commandes exécutées sur le nœud et rechercher l’erreur.
Vous pouvez avoir à modifier les paramètres saisis ou à vous connecter au
serveur afin de corriger le problème. Une fois l’erreur corrigée, répéter
l’opération depuis l’étape précédente.
· (2) Ou cliquer sur « Superviser les modules » pour quitter l’assistant de configuration du module et naviguer vers la supervision des modules.
Ou
·
(3) Cliquer sur pour
« Quitter l’assistant de configuration du module »
et aller sur la page d’accueil de configuration des modules.
3.3.3 Page d’accueil de la configuration des modules
Lorsqu’un premier module est configuré, la page d’accueil de la configuration des modules est accessible. Elle permet de visualiser les modules installés sur le cluster et d’accéder à la configuration d’un nouveau module.
L’ouvrir :
· Directement avec http://host:9010/console/fr/configuration/modules
Ou
·
En naviguant dans la console sur « Configuration/Configuration des modules »
|
Avant chaque reconfiguration, déconfiguration et désinstallation, sur chaque nœud, fermer tous les éditeurs, explorateur de fichiers, shells ou cmd sous SAFE/modules/AM (au risque sinon que l’opération échoue). |
Dans l’exemple suivant, la console est chargée depuis 10.0.0.107 qui correspond au nœud node1 dans le cluster existant. Il s’agit du nœud de connexion.
·
(1) Cliquer sur « Configuration »
dans la barre de navigation latérale.
· (2) Cliquer sur l’onglet « Configuration des modules ».
· Les modules installés dans le cluster sont listés avec la date d’application de la configuration et éventuellement la date de sauvegarde d’une configuration qui n’a pas été encore appliquée.
· (3) Cliquer sur l’un des boutons associés au module :
o
pour modifier sa configuration
ou réappliquer sa configuration courante. Cela ouvre l’assistant de
configuration du module et charge sa configuration courante depuis le nœud de
connexion.
o
pour télécharger le .safe, composé de tous les fichiers du
module (userconfig.xml, scripts)
depuis le nœud de connexion.
o
pour reconfigurer le module
depuis le contenu d’un .safe
stocké localement.
o
pour restaurer une ancienne
configuration du module.
SafeKit conserve une copie des trois dernières configurations réussies (stockées sous SAFE/modules/lastconfig du côté serveur). L’ensemble des fichiers de configuration du module sont empaquetés dans un fichier .safe, dont le nom est du type AM_<date>_<heure> (où AM est le nom du module).
o
pour déconfigurer le module sur
un ou plusieurs nœuds, sans le désinstaller. Ses fichiers de configuration sont
conservés pour être éventuellement réappliquer plus tard.
o
pour désinstaller complètement
le module sur un ou plusieurs nœuds.
À la désinstallation du module, l’ensemble de ses fichiers sont empaquetés dans un fichier .safe qui est archivé du côté serveur sous SAFE/Application_Modules/backup.
· Pour configurer un nouveau module, cliquer sur « Nouveau module ».
3.3.4 Éditer localement la configuration du module puis l’appliquer
Vous préférerez peut-être utiliser votre éditeur favori sur votre station de travail pour éditer la configuration du module et/ou ajouter des scripts, tels qu’un custom checker.
Suivez la procédure suivante pour éditer la configuration du module sur votre station de travail puis l’appliquer.
·
(1) Cliquer sur « Configuration »
dans la barre de navigation latérale.
· (2) Cliquer sur l’onglet « Configuration des modules ».
·
(3) Cliquer sur pour télécharger le mirror.safe sur votre station de
travail
· (4) Extraire le contenu de mirror.safe (qui est un fichier zip) pour éditer conf/userconfig.xml, éditer/ajouter/détruire des scripts sous bin (un custom checker par exemple).
·
(5) Compresser le répertoire modifié dans un fichier xx.safe (ou xx.zip), puis le charger avec (.safe
et .zip acceptés).
·
(6) Cliquer sur pour sélectionner le fichier à
charger, puis « Confirmer ».
L'assistant de configuration du module est lancé avec le nouveau contenu de ce fichier. Passez à l'étape 4 pour « Sauvegarder et appliquer » cette nouvelle configuration
3.4 Superviser un module
Une fois un module configuré, vous pouvez superviser son état et exécuter des actions dessus (start, stop…).
La page d’accueil de supervision des modules est accessible :
· Directement avec http://host:9010/console/fr/monitoring
Ou
·
En naviguant dans la console sur « Supervision »
3.4.1 Page d’accueil de la supervision
Dans cet exemple, la console est chargée à partir de 10.0.0.107, qui correspond à node1 dans le cluster. Il s'agit du nœud de connexion. Deux modules sont configurés : farm et mirror.
·
(1) Cliquer sur « Supervision »
dans la barre de navigation latérale
· Pour chaque module installé, sont affichés :
o le nom du module et des nœuds sur lesquels il est installé
o l’état du module sur chaque nœud (voir section 3.4.2)
o une notification pour chaque changement d’état, si l’utilisateur a accordé la permission et l’URL est https, ou http://localhost
·
(2) Cliquer sur pour ouvrir le menu d’actions
(start, stop…) globales sur le module, qui s’appliquent à tous les nœuds (node1, node2
dans l’exemple).
Pour sa description, voir section 3.4.3.1.
·
(3) Cliquer sur pour ouvrir le menu d’actions
(start, stop…) locales sur le module, qui s’appliquent uniquement au nœud (node1 dans l’exemple).
Pour sa description, voir section 3.4.3.2.
·
(4) Cliquer sur le panneau du nœud (mirror>node1 dans l’exemple) pour
ouvrir les détails du module sur ce nœud (journaux, ressources…). Depuis
SafeKit 8.2.2, cliquer plutôt sur pour
ouvrir/fermer les détails.
Pour sa description, voir section 3.4.4.
·
(5) Cliquer sur pour
ouvrir/fermer la chronologie des états du module sur tous les nœuds où il est installé.
Pour sa description, voir section 3.4.5.
3.4.2 État du module
Le module est représenté par son état synthétique dans la partie gauche et par son état détaillé dans la partie droite.
3.4.2.1 État synthétique
La console affiche l’un des états synthétiques suivants pour le module sur le nœud.
|
|
|
|
|
|
|
|
|
|
|
NOT CONFIGURED (gris) Module installé mais non configuré |
Cela peut être dû à une mauvaise adresse, une défaillance du réseau ou du serveur, une mauvaise configuration du navigateur web ou du pare-feu, l’arrêt du service web SafeKit sur le nœud (voir section 7.1). Cela peut également être dû à l'indisponibilité temporaire du nœud de connexion. Dans ce cas, rechargez la console à partir d'un autre nœud du cluster. |
Pour la description des changements d’états d’un module miroir voir la section 5.2.
Pour la description des changements d’états d’un module ferme voir la section 6.2.
3.4.2.2 État détaillé
Il s’agit de l’état des principales ressources et règles de failover.
à jour Les répertoires répliqués du module miroir sont à jour |
non à jour |
degradé |
50%, 100% La part de partage de charge du module ferme (par exemple 50% ou 100% pour 2 nœuds) |
0% |
c_checkfile nommée c_checkfile) qui entraîne l’action restart, stop, stopstart ou wait sur le module en raison d’une ressource passé à down. Voir la section 13.18.4.2 pour des détails sur les règles de failover. Pour analyser le problème, lisez les journaux et les états des ressources comme décrit plus loin |
erreur Pas de réponse du nœud dans le délai imparti de connexion |
3.4.3 Menus de contrôle d’un module
3.4.3.1 Menu global
Les actions du menu global s'appliquent à tous les nœuds sur lesquels le module est configuré.
Dans cet exemple, les actions s’appliquent au module mirror sur node1 et node2.
·
(1) Cliquer sur pour ouvrir
le menu d’actions globales.
· Cliquer sur « Démarrer » pour démarrer le module sur tous les nœuds.
Pour un module miroir, un nœud est démarré automatiquement en tant que primaire s’il a les données à jour ; sinon, il démarre en tant que secondaire.
· Cliquer sur « Arrêter » pour arrêter le module sur tous les nœuds.
Pour un module miroir, le nœud qui est secondaire est arrêté en premier pour éviter un basculement inutile.
· Cliquer sur « Déboguer » pour le débogage et support comme décrit en section 3.5.
3.4.3.2 Menu local
Les actions du menu local s'appliquent uniquement au nœud sélectionné.
3.4.3.2.1 Contrôler un module miroir
Dans cet exemple, les actions s’appliquent au module mirror sur node1 uniquement.
·
(1) Cliquer sur pour ouvrir le menu d’actions locales
sur le nœud désiré (e.g. node1).
· Cliquer sur « Démarrer » pour démarrer le module sur le nœud.
Pour un module miroir, un nœud est démarré automatiquement en tant que primaire s’il a les données à jour ; sinon, il démarre en tant que secondaire. Voir la section 5.5.
· Cliquer sur « Arrêter » pour arrêter le module sur le nœud.
· Cliquer sur « Redémarrer » pour redémarrer le module sur le nœud.
Il exécute uniquement les scripts d'arrêt puis de démarrage pour redémarrer l'application localement sans entraîner de basculement
· Utiliser le sous-menu « Forcer le démarrage » lorsque vous devez décider quel nœud doit démarrer en primaire ou secondaire.
o Sélectionner « En primaire » pour forcer le nœud à démarrer en tant que primaire.
Par exemple, au 1er démarrage d’un module miroir tel que décrit en section 5.3, vous devez « Forcer le démarrage En primaire » le nœud qui a les répertoires répliqués à jour.
o Sélectionner « En secondaire » pour forcer le nœud à démarrer en tant que secondaire.
o La synchronisation des données peut être optimisée ou non en fonction du dernier état interne du module.
o Sélectionner « En secondaire avec la synchronisation complète des données » pour forcer le nœud à démarrer en tant que secondaire après recopie complète des données répliquées.
· Cliquer sur « Désactiver/activer » pour contrôler la détection d’erreur telle que décrite dans la section 3.4.3.2.3.
· Cliquer sur « Déboguer » pour télécharger le journal ou snapshot du module depuis le nœud plutôt que depuis tous les nœuds tels que décrit dans la section 3.5.
Pour comprendre et vérifier le bon fonctionnement d'un module miroir, voir la section 5. Pour le tester, voir la section 4.
3.4.3.2.2 Contrôler un module ferme
Dans cet exemple, les actions s’appliquent au module farm sur node2 uniquement.
·
(1) Cliquer sur pour ouvrir
le menu d’actions locales sur le nœud désiré (e.g. node2).
· Cliquer sur « Démarrer » pour démarrer le module sur le nœud.
· Cliquer sur « Arrêter » pour arrêter le module sur le nœud.
· Cliquer sur « Redémarrer » pour redémarrer le module sur le nœud.
Il exécute uniquement les scripts d'arrêt puis de démarrage pour redémarrer l'application localement sans entraîner de basculement
· Cliquer sur « Désactiver/activer » pour contrôler la détection d’erreur telle que décrite dans la section 3.4.3.2.3.
· Cliquer sur « Déboguer » pour télécharger le journal ou snapshot du module depuis le nœud plutôt que depuis tous les nœuds tels que décrit dans la section 3.5.
Pour comprendre et vérifier le bon fonctionnement d'un module ferme, voir la section 6. Pour le tester, voir la section 4.
3.4.3.2.3 Contrôler les checkers ou la surveillance des processus/services
Pour éviter une détection d'erreur infondée et un basculement automatique lors de la maintenance de l'application, vous pouvez désactiver les checkers configurés (TCP, ping, custom, etc.) ou la surveillance des processus/services. Une fois la maintenance terminée, ils peuvent être réactivés en toute sécurité. Ces actions peuvent être effectuées lorsque le module est démarré/arrêté et ne sont pas réinitialisées lorsque le module redémarre.
Dans l'exemple ci-dessous, les actions s'appliquent au mirror sur node1.
·
(1) Cliquer sur pour
ouvrir le menu d’actions locales sur le nœud désiré (e.g.
node1).
· (2) Cliquer sur « Désactiver/activer » pour ouvrir le sous-menu.
· (3) Cliquer sur « Checkers » ou « Surveillance des processus/services » pour ouvrir le sous-menu.
· (4) Cliquer sur « Désactiver » pour désactiver la détection d’erreur.
Cela désactive tous les checkers (TCP, ping, custom, etc.) ou la surveillance des processus/services configurés dans le module.
· (4) Cliquer sur « Activer » pour réactiver la détection d’erreur.
Cela réactive tous les checkers (TCP, ping, custom, etc.) ou la surveillance des processus/services configurés dans le module.
3.4.4 Détails du module
Vous pouvez afficher les détails d'un module sur un nœud :
· Directement via l’URL http://host:9010/console/fr/monitoring /modules/AM/nodes/node (remplacer AM par le nom du module et node par le nom du nœud)
Ou
·
En naviguant dans la console sur « Supervision/Cliquer sur module>nœud »
Le module>nœud sélectionné est mis en évidence par une couleur bleue.
Dans l'exemple suivant, les détails du module mirror sur le node1 sont affichés.
·
(1) Cliquer sur pour
ouvrir/fermer les détails du module sur ce nœud (logs, ressources...).
· (2) Cliquer sur l’onglet « Journaux » pour visualiser les journaux du module.
· (3) Cliquer sur l’onglet « Ressources » pour visualiser les ressources du module.
· (4) Cliquer sur l’onglet « Information » pour visualiser les informations sur le nœud.
Il s’agit du nom des lans et adresses définies dans la configuration du cluster, version et licence SafeKit, hostname et OS.
3.4.4.1 Journaux du module
Vous pouvez afficher les journaux d'un module sur un nœud :
· Directement via l’URL http://host:9010/console/fr/monitoring /modules/AM/nodes/node/logs (remplacer node par le nom du nœud et AM par le nom du module)
Ou
·
En naviguant dans la console sur « Supervision/Cliquer sur module>nœud/Onglet Journaux »
Le panneau de gauche affiche en temps réel le journal non verbeux du module>nœud sélectionné.
·
Cliquer sur pour reprendre/suspendre la
visualisation en temps réel du journal du module.
Voir la section 7, pour une explication des principaux messages.
·
(2) Cliquer sur pour télécharger le journal du
module (non verbeux ou verbeux).
· (3) Sélectionner le type de messages à afficher :
|
· C(ritique) messages tels que des détections d'erreurs · E(vènement) messages tels que l’état local et distant · U(ser) messages lorsque l'utilisateur exécute une action sur le module · S(cript) messages quand les scripts du module sont exécutés |
· Cliquer sur un message pour afficher le journal verbeux du module ou le journal des scripts (sortie des scripts) dans le détail du journal dans le panneau de droite.
3.4.4.1.1 Journal du script
Pour afficher le journal du script du module, cliquer sur le
message S(cript) dont vous souhaitez
visualiser l’output.
·
(1) Cliquer sur le message S(cript) qui
consiste en :
o la date et l’heure d’exécution du script
o le nom du script exécuté
o le nom du fichier userlog correspond
Le contenu du fichier userlog est affiché dans le panneau de droite. Dans l’exemple, il s’agit du contenu du fichier SAFEVAR/modules/AM/userlog_2024-02-12T091410_start_prim.ulog (où AM est le nom du module).
3.4.4.1.2 Journal verveux
Pour afficher le journal verbeux du module, cliquer sur un
message autre que S(cript).
· (1) Cliquer sur le message qui consiste en :
o la date et l’heure de l’évènement
o le message du module
· Tous les messages verbeux entre le message sélectionné et le précédent dans la table, sont affichés dans le panneau de droite.
3.4.4.2 Ressources du module
Vous pouvez afficher les ressources d'un module sur un nœud :
· Directement via l’URL http://host:9010/console/fr/monitoring /modules/AM/nodes/node/resources (remplacer AM par le nom du module et node par le nom du nœud)
Ou
·
En naviguant dans la console sur « Supervision/Cliquer sur module>nœud/Onglet Ressources »
3.4.4.2.1 État courant des ressources
Le panneau de gauche affiche en temps réel l’état courant des ressources du module>nœud sélectionné.
· (1) Sélectionner le groupe de ressources à afficher
|
· Status du module Ressources principales, notamment de la réplication de fichiers pour un module miroir · Checkers Ressources affectées par des checkers · Réplication de fichiers Ressources spécifiques à la réplication de fichiers qui démontrent la progression de la synchronisation · Toutes les ressources |
· Cliquer sur une ressource pour afficher la valeur de la ressource dans le temps dans le panneau de droite. Cet historique peut être vide pour certaines ressources (non affecté ou nettoyé).
L’état courant des ressources du module est contrôlé par la failover machine pour provoquer des actions sur le module en cas de défaillance (voir section 13.18).
3.4.4.2.2 Historique des valeurs d’une ressource
Pour afficher l’historique des valeurs d’une ressource, cliquer sur la ressource qui vous intéresse.
· (1) Cliquer sur la ligne qui consiste en :
o la dernière date à laquelle la ressource a été affectée
o le nom et la catégorie de la ressource. Le nom complet de la ressource est de la forme catégorie.nom (custom.checkfile dans l’exemple).
L’historique des valeurs de la ressource est affiché dans le panneau de droite. Dans l’exemple, il s’agit de la ressource custom.checkfile correspondant à une ressource affectée par un custom checker.
3.4.5 Chronologie des états du module
Depuis SafeKit 8.2.2, vous pouvez afficher la chronologie des états d'un module :
·
En naviguant dans la console sur « Supervision/Cliquer sur
pour le module »
Cela permet d'avoir une vue globale de l'état du module sur le cluster. Notez que :
· les horloges des deux nœuds doivent être synchronisées pour que la mise en correspondance des changements d'état soit significative.
· la chronologie affichée est inversée : les états du module sur tous les nœuds au fil du temps, en commençant par la date la plus récente.
·
(1) Cliquer sur pour
ouvrir/fermer la chronologie. La chronologie affichée est celle disponible au
moment du chargement.
·
(2) Cliquer sur pour
rafraîchir la chronologie avec les derniers changements d’état.
· (3) Cliquer sur un événement de changement d'état pour afficher le journal du module pour le nœud à partir de cette date.
3.5 Snapshots et journaux du module pour le débogage et support
Lorsque le problème n'est pas facilement identifiable, il est recommandé de prendre un snapshot du module sur tous les nœuds, comme décrit ci-dessous. Les snapshots permettent une analyse hors ligne et approfondie de l'état du module et du nœud, tel que décrit dans la section 7.16. Si cette analyse échoue, envoyez les snapshots au support comme décrit dans la section 8.
Dans l’exemple suivant, le module mirror est configuré sur node1 et node2. Notez qu'un snapshot peut être téléchargé dans n'importe quel état du module.
·
(1) Cliquer sur pour ouvrir le menu global sur
le module.
· (2) Cliquer sur « Déboguer » pour ouvrir le sous-menu de débogage.
· (3) Cliquer sur « Télécharger les snapshots » pour créer et télécharger le snapshot du module pour chaque nœud.
La console web s'appuie sur les paramètres de téléchargement du navigateur web pour sauvegarder les snapshots sur la station de travail. Certains navigateurs peuvent demander une confirmation pour télécharger plusieurs fichiers et des .zip.
La commande de génération du snapshot génère un nouveau dump et créé un fichier .zip qui contient les 3 derniers dumps et les 3 dernières configurations du module.
Dans cet exemple, 2 snapshots sont téléchargés : snapshot_node1_mirror.zip et snapshot_node2_mirror.zip.
· Cliquer sur « Télécharger les journaux » pour télécharger le journal du module (verbeux ou non) pour chaque nœud.
· En cas de problèmes de réplication de fichiers, il peut être nécessaire de « Générer les fichiers de dump » au moment où le problème se produit.
Le dump contient les journaux du module et des informations sur l'état du système et de SafeKit au moment du dump. Il est généré du côté serveur sous SAFEVAR/snapshot/modules/mirror/dump_AAAA_MM_DD_hh_mm_ss.
3.6 Sécuriser la console web
SafeKit propose différentes politiques de sécurité pour la console web mises en œuvre en modifiant la configuration du service web SafeKit. Ces configurations offrent aussi une gestion de rôles :
Rôle Admin |
Ce rôle accorde tous les droits d'administration en
autorisant l’accès à la |
Rôle Control |
Ce rôle accorde tous les droits de supervision et
contrôle en autorisant l’accès à la |
Rôle Monitor |
Ce rôle n'accorde que des droits de supervision,
interdisant les actions sur les modules (démarrage, arrêt...) sous |
SafeKit fournit différentes configurations pour le service web afin de renforcer la sécurité de la console. Les configurations prédéfinies sont listées ci-dessous de la moins sécurisée à la plus sécurisée :
· HTTP. Rôle identique pour tous les utilisateurs sans authentification
Cette solution ne peut être mise en œuvre qu'en HTTP et est incompatible avec les méthodes d'authentification des utilisateurs.
· HTTP/HTTPS avec authentification à base de fichiers et gestion de rôles facultative
Elle repose sur le fichier Apache user.conf pour authentifier les utilisateurs et, optionnellement, restreindre leurs accès en fonction des rôles avec le fichier group.conf. La connexion à la console nécessite la saisie du nom et du mot de passe de l’utilisateur tels qu’ils ont été configurés avec les mécanismes d’Apache.
Il s’agit de la configuration par défaut, en HTTP et initialisée avec un seul utilisateur admin ayant le rôle Admin. Cette configuration peut être étendue pour rajouter des utilisateurs ou passer en HTTPS.
· HTTP/HTTPS avec authentification à base de serveur LDAP/AD. Gestion de rôles facultative
Elle repose sur le serveur LDAP/AD pour authentifier les utilisateurs et, optionnellement, restreindre leurs accès en fonction des rôles. La connexion à la console nécessite la saisie de l’identifiant et du mot de passe de l’utilisateur tels qu’ils ont été configurés dans le serveur LDAP/AD. Elle peut être appliquée en HTTP ou HTTPS.
· HTTPS avec authentification à base de serveur d’OpenId Connect. Gestion de rôles facultative
Elle repose sur le serveur OpenID Identity Provider pour authentifier les utilisateurs et, optionnellement, restreindre leurs accès en fonction des rôles. La connexion à la console nécessite la saisie de l’identifiant et du mot de passe de l’utilisateur tels qu’ils ont été configurés dans le serveur OpenID. Depuis SafeKit 8.2.3, l’authentification OpenId ne peut être utilisée qu’avec HTTPS.
Pour les mettre en œuvre, se référer à la section 11.
4. Tests
Section 4.1
« Installation et tests après boot »
Section 4.2 « Tests
d'un module miroir »
Section 4.3 « Tests d'un module ferme »
Section 4.4
« Tests des checkers communs à un miroir et une ferme »
Les tests suivants permettent de mieux comprendre le fonctionnement de SafeKit et de s'assurer que la solution déployée retourne bien les résultats attendus. Ils peuvent être utilisés comme base de cahier de recette chez un client.
Dans la suite, l’analyse des résultats des tests peut nécessiter de consulter le journal du module, le journal des scripts (qui contient l’output des scripts du modules) ou l’état des ressources du module. Pour cela, voir la section 7.3.
4.1 Installation et tests après boot
4.1.1 Test installation package
Dans la suite, remplacer node1 par le nom du nœud et AM par le nom du module.
· safekit -p executé sur un nœud retourne, entre autres valeurs, la valeur de SAFE, le chemin d'installation racine de SafeKit, et SAFEVAR, le répertoire de travail de SafeKit :
o en Windows
SAFE=C:\safekit si SystemDrive=C:
SAFEVAR=C:\safekit\var
o
en Linux
SAFE="/opt/safekit"
SAFEVAR="/var/safekit"
Pour plus d'informations, voir la section 10.1.
· L'édition de userconfig.xml d'un module miroir (/ferme) et de ses scripts start_prim/start_both, stop_prim/stop_both est réalisée avec :
· La console web avec l’URI /console/fr/configuration/modules/AM/config
· Sous le répertoire SAFE/modules/AM sur node1
· Le journal du module et le journal des scripts (qui contient output des scripts du module) peuvent être consultés avec :
o
la console web avec l’URI
/console/fr/monitoring/modules/AM/nodes/node1/logs
o la commande safekit logview -m AM exécutée sur node1, pour le journal du module
o sur node1, dans les fichiers SAFEVAR/modules/AM/userlog_<year>_<month>_<day>T<time>_<script name>.ulog, pour le journal des scripts
4.1.2 Test licence et version
safekit level retourne
Host :
<hostname>
OS : <OS version>
SafeKit : <SafeKit version>
License : Demo (No license)| Invalid Product | Invalid Host | … Expiration… | <license id> for <hostname>…
or License : Expired license
· "No license"
signifie qu'il n'y a pas de fichier SAFE/conf/license.txt : le produit s'arrête tous les 3 jours
· "Invalid Product"
signifie que la licence a expiré dans SAFE/conf/license.txt
· "Invalid Host"
signifie que le hostname est invalide dans SAFE/conf/license.txt
· " …Expiration…"
indique une clé temporaire
· "<license id> for <hostname>"
indique une clé permanente
http://www.evidian.com/safekit/requestevalkey.php pour obtenir une clé temporaire d'un mois pour n'importe quel hostname/OS.
https://support.evidian.com pour obtenir une clé permanente basée sur le hostname et l'OS.
4.1.3 Test des services et modules SafeKit après boot
Pour Windows, voir aussi la section 10.4.
Test du service safeadmin
Le service safeadmin doit être démarré automatiquement au boot. Pour vérifier son état :
En Windows |
1. Ouvrir une console PowerShell en tant qu’administrateur 2. Exécuter Get-Service -name safeadmin Status Name DisplayName ------ ---- ----------- Running safeadmin safeadmin |
En Linux |
1. Ouvrir une console Shell en tant que root 2. Exécuter systemctl status safeadmin Redirecting to /bin/systemctl status safeadmin.service ● safeadmin.service - The SafeKit Administration Daemon Loaded: loaded (/usr/lib/systemd/system/safeadmin.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2024-11-12 17:30:56 CET; 20h ago … |
Lorsque le service safeadmin n’est pas actif, toutes les commandes safekit échouent et retournent par exemple :
safekit level
Waiting for safeadmin ..........
Error: safeadmin administrator daemon not running
Voir la section 9.1.1 pour démarrer le service safeadmin.
Test du service safewebserver
Par défaut, le service safewebserver est démarré automatiquement au boot. Pour vérifier son état :
En Windows |
1. Ouvrir une console PowerShell en tant qu’administrateur 2. Exécuter Run Get-Service -name safewebserver Status Name DisplayName ------ ---- ----------- Running safewebserver safewebserver |
En Linux |
1. Ouvrir une console Shell en tant que root 2. Exécuter systemctl status safewebserver systemctl status safewebserver Redirecting to /bin/systemctl status safewebserver.service ● safewebserver.service - SafeKit Apache Server Loaded: loaded (/usr/lib/systemd/system/safewebserver.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2024-11-13 11:01:31 CET; 2h 58min ago … |
Lorsque le service safewebserver n’est pas actif, les fonctionnalités suivantes ne sont pas opérationnelles :
· La console web SafeKit qui affiche :
· Le module checker
· La commande distribuée qui retourne par exemple :