eviden-logo

Evidian > Produits > Logiciel de haute disponibilité - Zéro surcoût matériel > Guide de l'utilisateur de SafeKit 8.2

Guide de l'utilisateur de SafeKit

SafeKit 8.2

Guide Evidian de l'utilisateur de SafeKit 8.2

 

 

 

 

 

Guide de l'utilisateur de SafeKit

Logiciel de haute disponibilité pour applications critiques


 

 

 


Vue générale

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
visé

Architectures

Aperçu technique

Installation

Installation

Console

La console web de SafeKit

Sécurisation du service web de SafeKit

Configuration avancée

Cluster.xml pour la configuration du cluster SafeKit

Userconfig.xml pour la configuration du module

Scripts du module pour la configuration du module

Exemples de configurations de module

Administration

Administration d'un module miroir

Administration d'un module ferme

Interface ligne de commande

Administration avancée

Support

Tests

Résolution de problèmes

Accès au support Evidian

Index des messages du log

Autres

Table des matières

Logiciels tiers

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
Site support Evidian :    
https://support.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.


 


Table des matières

Guide de l'utilisateur de SafeKit  Logiciel de haute disponibilité pour applications critiques  1

Vue générale. 3

Table des matières. 5

1.... Aperçu technique. 15

1.1..... Généralités, solutions, architectures 15

1.1.1          Introduction à SafeKit 15

1.1.2          Solutions SafeKit 16

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.1.6          Limites de SafeKit 18

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.3          Étape 2. Basculement 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.... Installation. 29

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.1          Prérequis matériel 35

2.2.2          Prérequis réseau. 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.1          Prérequis matériel 36

2.3.2          Prérequis réseau. 36

2.3.3          Prérequis application. 36

2.4..... Upgrade de SafeKit 36

2.4.1          Préparer l'upgrade. 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.2          État du module. 58

3.4.3          Menus de contrôle d’un module. 60

3.4.4          Détails du module. 63

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.... Tests. 73

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.2..... Automate d'état d'un module miroir (STOP, WAIT, ALONE, PRIM, SECOND - NotReady, Transient, Ready) 101

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... Problème pour récupérer le certificat de l'autorité de certification depuis une PKI externe  130

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.3..... Créer un compte. 137

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.2          Création d’un Call 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.1          Service safeadmin. 143

9.1.2          Service safewebserver 144

9.1.3          SNMP service. 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..... Exemples 156

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.1.1       Global 159

10.1.2       Module. 159

10.2... Services et démons SafeKit 161

10.2.1       Services 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.3.3       Autres pare-feux. 164

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.7.4       API SafeKit 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.9.3       La MIB SafeKit 176

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... Vue générale. 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.1.1       <macro> Exemple. 212

13.1.2       <macro> Syntaxe. 212

13.1.3       <macro> Attributs. 212

13.2... Module ferme ou miroir - <service>. 213

13.2.1       <service> Exemple. 213

13.2.2       <service> Syntaxe. 213

13.2.3       <service> Attributs. 213

13.3... Heartbeats - <heart>, <heartbeat >. 216

13.3.1       <heart> Exemple. 216

13.3.2       <heart> Syntaxe. 216

13.3.3       <heart>, <heartbeat> Attributs. 217

13.4... Topologie d'une ferme - <farm>, <lan>. 218

13.4.1       <farm> Exemple. 218

13.4.2       <farm> Syntaxe. 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.4       <vip> Syntaxe. 221

13.5.5       <interface_list>, <interface>, <virtual_interface>, <real_interface>, <virtual_addr> Attributs. 222

13.5.6       <loadbalancing_list>, <group>, <cluster>, <host> Attributs 225

13.5.7       <vip> Description. 226

13.6... Réplication de fichiers - <rfs>, <replicated>. 228

13.6.1       <rfs> Exemple. 228

13.6.2       <rfs> Syntaxe. 228

13.6.3       <rfs>, <replicated> Attributs. 229

13.6.4       <rfs>Description. 237

13.7... Activer les scripts du module - <user>, <var>. 246

13.7.1       <user> Exemple. 246

13.7.2       <user> Syntaxe. 246

13.7.3       <user>, <var> Attributs. 247

13.8... Hostname virtuel - <vhost>, <virtualhostname>. 247

13.8.1       <vhost> Exemple. 247

13.8.2       <vhost> Syntaxe. 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.1       <errd> Exemple. 249

13.9.2       <errd> Syntaxe. 249

13.9.3       <errd>, <proc> Attributs 250

13.9.4       <errd> Commandes 254

13.10. Checkers - <check>. 255

13.10.1     <check> Exemple. 255

13.10.2     <check> Syntaxe. 256

13.10.3     <checker> Description. 256

13.11. TCP checker - <tcp>. 259

13.11.1     <tcp> Exemple. 260

13.11.2     <tcp> Syntaxe. 260

13.11.3     <tcp> Attributs. 260

13.12. Ping checker - <ping>. 262

13.12.1     <ping> Exemple. 262

13.12.2     <ping> Syntaxe. 262

13.12.3     <ping> Attributs. 263

13.13. Interface checker - <intf>. 264

13.13.1     <intf> Exemple. 264

13.13.2     <intf> Syntaxe. 265

13.13.3     <intf> Attributs. 265

13.14. IP checker - <ip>. 265

13.14.1     <ip> Exemple. 265

13.14.2     <ip> Syntaxe. 266

13.14.3     <ip> Attributs. 266

13.15. Custom checker - <custom>. 267

13.15.1     <custom> Exemple. 267

13.15.2     <custom> Syntaxe. 268

13.15.3     <custom> Attributs 268

13.16. Module checker - <module>. 269

13.16.1     <module> Exemple. 270

13.16.2     <module> Syntaxe. 270

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... Liste des scripts 279

14.1.1       Scripts start/stop. 279

14.1.2       Autres scripts 280

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

17.. Logiciels tiers. 335

Index des messages du journal du module. 339

Index. 343

 

 


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.

·         En cas de défaillance ou d'arrêt d'un serveur, le « health check » ne renvoie rien à l'équilibreur de charge, qui arrête alors d'acheminer les requêtes vers ce serveur.

·         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
si
%SYSTEMDRIVE%=C:

·         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.

Commentaire important contour

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.

Commentaire important contour

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 :

En Windows

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

Commentaire important contour

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         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 (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 « Supervision/
du nœud/Forcer le démarrage/En primaire »

·         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 « Supervision/
du nœud/Forcer le démarrage/En secondaire »

·         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 « Supervision/
du nœud/Démarrer/ 
»

·         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 « Supervision/
du nœud/Démarrer/ 
»

·         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

SafeKit Solution

La solution SafeKit y est entièrement détaillée.

Formation SafeKit

Reportez-vous à cette formation en ligne pour un démarrage rapide de l'utilisation de SafeKit.

SafeKit Release Notes

Il contient :

·         Dernières instructions d'installation

·         Changements majeurs

·         Restrictions et problèmes connus

·         Instructions de migration

Software Release Bulletin

Bulletin listant les packages SafeKit 8.2 avec la description des changements et des problèmes corrigés.

SafeKit Knowledge Base

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.

Guide de l’utilisateur SafeKit

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 /Guide de l’utilisateur.

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.

Commentaire, ajouter contour

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

Image de la console web SafeKit
Page d'accueil avec la barre de navigation pour la surveillance et la configuration, le nom du nœud de connexion et le menu principal

·         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

Commentaire, ajouter contour

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.

Commentaire important contour

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 :

Image de la console web SafeKit
L'assistant de configuration du cluster

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.

Image de la console web SafeKit
Éditer la configuration du cluster en utilisant l'assistant de configuration du cluster . Définir 2 LAN et les adresses IP de 2 nœuds sur ces réseaux

·         (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.

Commentaire important contour

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.

Image de la console web SafeKit
Infobulle avec des informations sur le nœud du cluster dans l'assistant de configuration du cluster

 signifie que le server SafeKit est disponible. L’infobulle donne des informations sur le serveur.

Image de la console web SafeKit
Infobulle lors de problèmes de connexion avec le nœud du cluster dans l'assistant de configuration du cluster

 signifie que le serveur n’a pas répondu dans le délai imparti. Résoudre le problème, afin de pouvoir administrer ce nœud. 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.

 

·         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.

Commentaire important contour

Si besoin, vous pouvez réappliquer la configuration du cluster sur tous les nœuds sans la modifier.

 

Sous-titres contour

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

Image de la console web SafeKit
Vérifier le résultat de configuration du cluster sur tous les nœuds avec l'assistant de configuration du cluster

·         (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.

Image de la console web SafeKit
Page d’accueil de la configuration du cluster

·         (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.

Image de la console web SafeKit
Sélectionner un nouveau module à configurer depuis la page d'accueil de la configuration

·         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

Image de la console web SafeKit
Entrer 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 :

Image de la console web SafeKit
L’assistant de configuration du module

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.

Commentaire important contour

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.

Image de la console web SafeKit
Éditer la configuration du module avec l'assistant de configuration du module

·         (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.

Commentaire, ajouter contour

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 ».

Sous-titres contour

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.

Image de la console web SafeKit
Éditer les scripts du module avec l'assistant de configuration du module

·         (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 ».

Sous-titres contour

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.

Image de la console web SafeKit
Activer/désactiver le cryptage des communications du module avec l'assistant de configuration du module

·         (1) Cliquer Activer pour activer ou désactiver le cryptage des communications du module.

Commentaire important contour

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.

Image de la console web SafeKit
Sélectionner les nœuds sur lesquels enregistrer et appliquer la configuration du module à l'aide de l'assistant de configuration du module

·         (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é :

Image de la console web SafeKit
Cas où le nœud ne peut pas être sélectionné, dans l'assistant de configuration du module, parce que le module est en cours d'exécution

Le module sur le nœud sélectionné est démarré et dans un état différent de STOP (NotReady).

Image de la console web SafeKit
Cas où le nœud ne peut pas être sélectionné, dans l'assistant de configuration du module, parce que le nœud ne répond pas

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.

Commentaire important contour

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.

Image de la console web SafeKit
Vérifier le résultat de la configuration du module sur les nœuds en utilisant l'assistant de configuration du module

·         (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 »

Commentaire important contour

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.

Image de la console web SafeKit
Page d'accueil de la configuration des modules

·         (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.

Image de la console web SafeKit
Télécharger la configuration du module pour la mettre à jour localement, puis l'appliquer, à partir de la page d'accueil de la configuration du module

·         (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).

Image de la console web SafeKit
Sélectionnez un fichier local avec l'extension .safe ou .zip pour charger une configuration de module à partir de la page d'accueil de la configuration du module

·         (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.

Image de la console web SafeKit
Page d’accueil de la supervision des modules

·         (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 Une image contenant noir, obscurité

Description générée automatiquement pour ouvrir/fermer les détails.

Pour sa description, voir section 3.4.4.

·         (5) Cliquer sur Une image contenant noir, obscurité

Description générée automatiquement 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.

STOP (NotReady)(rouge)                 Module arrêté (prêt à démarrer)

WAIT (Transient)(orange)        État transitoire du module

ALONE (Transient)(orange)       État transitoire du module miroir primaire sans
secondaire

ALONE (Ready)(vert)                     État stable du module miroir primaire sans
secondaire

PRIM (Transient)(orange)             État transitoire du module miroir primaire avec
secondaire

PRIM (Ready)(vert)                       État stable du module miroir primaire avec
secondaire

SECOND (Transient)(orange)          État transitoire du module miroir secondaire
avec primaire, pendant la phase de resynchronisation des répertoires répliqués

SECOND (Ready)(vert)                   État stable du module miroir, secondaire                                                        avec primaire

UP (Transient) (orange) État transitoire du module ferme

UP (Ready)(vert)                          État stable du module ferme

WAIT (NotReady) (rouge)                État bloqué du module en attente d’une
ou plusieurs ressources

NOT CONFIGURED (gris)                      Module installé mais non configuré

ERROR (rouge)                                 Pas de réponse du nœud 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 (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

              Les répertoires répliqués du module miroir ne sont pas à jour

non à jour

              Le module miroir est en mode dégradé décrit en section 7.6

 degradé

50%, 100%             La part de partage de charge du module ferme (par exemple 50% ou 100% pour 2 nœuds)

              Aucune charge prise par le module ferme

   0%

              Le module a appliqué la règle de failover (par exemple, la règle

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

              Avec le module dans l’état ERREUR (rouge)

  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.

Image de la console web SafeKit
Démarrer ou arrêter le module sur tous les nœuds, télécharger tous les snapshots et journaux à partir du menu global du module

·         (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.

Image de la console web SafeKit
Actions du menu local du module miroir sur le nœud sélectionné. Démarrer, arrêter, redémarrer, forcer le démarrage en primaire, forcer le démarrage en secondaire, forcer le démarrage en secondaire avec synchronisation complète des données

·         (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.

Image de la console web SafeKit
Actions du menu local du module ferme sur le nœud sélectionné. Démarrer, arrêter, redémarrer

·         (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.

Image de la console web SafeKit
Actions du menu local du module sur le nœud sélectionné. Activer ou désactiver la détection d'erreur par les checkers configurés dans le module ; Activer ou désactiver la détection d'erreur par la surveillance de processus  ou la surveillance de services

·         (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.

Image de la console web SafeKit
Cliquer pour ouvrir ou fermer les détails du module sur un nœud : 
les journaux du module avec l'onglet Journaux
les ressources du module avec l'onglet Ressources
les informations sur le nœud  avec l'onglet information

·         (1) Cliquer sur Une image contenant noir, obscurité

Description générée automatiquement 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é.

Image de la console web SafeKit
Afficher, filtrer et télécharger les journaux du module en utilisant l'onglet Journaux

·         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 :

Image de la console web SafeKit
Liste des différents niveaux de messages dans le journal du module et des icônes associés, affichés dans l'onglet Journaux

·         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.

Image de la console web SafeKit
Afficher le contenu du journal du script en cliquant sur un message S (Script) dans le journal du module, à partir de l'onglet Journaux

·         (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).

Image de la console web SafeKit
Afficher le journal verbeux du module en cliquant sur un message autre que S (Script) dans le journal du module, eà partir de  l'onglet Journaux

·         (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é.

Image de la console web SafeKit
Afficher la valeur courante des ressources du module en utilisant l'onglet Ressources

·         (1) Sélectionner le groupe de ressources à afficher

Image de la console web SafeKit
Liste des différents groupes de ressources à afficher dans l'onglet Ressources

·         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.

Image de la console web SafeKit
Afficher l’historique des valeurs d’une ressource en cliquant sur la ressource souhaitée dans l'onglet Ressources

·         (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 Une image contenant noir, obscurité

Description générée automatiquement 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.

Image de la console web SafeKit
Afficher la chronologie des états du module

·         (1) Cliquer sur Une image contenant noir, obscurité

Description générée automatiquement pour ouvrir/fermer la chronologie. La chronologie affichée est celle disponible au moment du chargement.

·         (2) Cliquer sur Une image contenant noir, obscurité

Description générée automatiquement 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.

Image de la console web SafeKit
Télécharger le snapshot du module pour chaque nœud

·         (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
 Configuration et  Supervision dans la barre de navigation latérale

Rôle Control

Ce rôle accorde tous les droits de supervision et contrôle en autorisant l’accès à la Supervision

Rôle Monitor

Ce rôle n'accorde que des droits de supervision, interdisant les actions sur les modules (démarrage, arrêt...) sous Supervision

 

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 :