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

« Architectures de haute disponibilité » page 15

« Cluster SafeKit dans le cloud page 299

Installation

« Installation » page 25

Console

« La console web de SafeKit » page 37

« Sécurisation du service web de SafeKit » page 177

Configuration avancée

« Cluster.xml pour la configuration du cluster SafeKit » page 205

« Userconfig.xml pour la configuration du module » page 211

« Scripts du module pour la configuration du module » page 271

« Exemples de userconfig.xml et scripts du module » page 277

Administration

« Administration d'un module miroir » page 95

« Administration d'un module ferme » page 107

« Interface ligne de commande » page 143

« Administration avancée » page 157

Support

« Tests » page 69

« Résolution de problèmes » page 111

« Accès au support Evidian » page 133

« Index des messages du log page 315

Autres

« Table des matières » page 5

« Logiciels tiers » page 311

Version

SafeKit 8.2

OS supportés

Windows et Linux ; pour une liste détaillée des OS supportés, voir ici

Site web

Site marketing Evidian : http://www.evidian.com/safekit
Site support Evidian :     https://support.evidian.com/safekit

Ref

39 F2 38MC 03

Si vous avez des commentaires ou des questions relatives à ce document, envoyez-nous s'il vous plaît
un courriel à institute@evidian.com

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

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.

Sur upgrade, cette étape peut être ignorée si cela a déjà été fait lors de l’installation précédente de SafeKit 8.2. Si elle est réappliquée, cela aura pour effet de réinitialiser le mot de passe avec la nouvelle valeur.

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.

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>  

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>  

  ip 1.1     ip 1.2

virtual ip =      ip 1.10

miroir(app1)=    app1

                        dir1                dir1

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

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.

In Windows

Désinstaller via Control Panel-Add/Remove Programs applet

In Linux

Utiliser la commande safekit uninstall

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)

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 section 8 page 133.

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.

Consulter le Release Notes, sur https://support.evidian.com/safekit, pour la liste des restrictions et problèmes connus avec la console web. 

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.

·         Quand la console est connectée à un serveur SafeKit sur lequel le cluster est configuré, le nom du nœud correspond au serveur (tel que défini dans la configuration du cluster) est affiché dans l’entête. Il s’agit du nœud de connexion (node1 dans l’exemple).

Si le cluster n’est pas encore configuré, aucun nom n’est affiché.

·         (1) Cliquer sur  pour ouvrir le menu afin d’accéder au Guide de l’utilisateur SafeKit, sélectionner la langue, activer/désactiver le mode sombre et se déconnecter.

·         (2) Cliquer sur  pour réduire ou développer la barre latérale de navigation.

·         (3) Cliquer sur  Configuration pour configurer le cluster et les modules. La configuration n'est autorisée qu'aux utilisateurs ayant le rôle Admin. Par défaut, l’utilisateur admin a le rôle Admin.

·         (4) Cliquer sur  Supervision pour superviser et contrôler les modules configurés. La supervision est autorisée aux utilisateurs qui ont les rôles Admin, Control et Monitor. Avec le rôle Monitor, les actions sur les modules (démarrage, arrêt...) sont interdites.

La console web offre des aides contextuelles en cliquant sur l’icône.

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.

·         (1) Remplir le formulaire pour affecter d’abord le nom convivial pour le lan. Ce nom est utilisé plus tard pour configurer les réseaux de surveillance utilisées par un module.

Cliquer sur  pour ajouter un nouveau nœud /lan ou sur  pour supprimer un nœud/lan du cluster.

·         (2) Saisir l’adresse IP du nœud, puis appuyer sur la touche tabulation pour vérifier la disponibilité du serveur et l’insertion automatique de son nom.

L'icône à côté de l'adresse reflète l’accessibilité du nœud.

·         Modifier le nom du nœud si besoin. Ce nom est celui qui sera utilisé par le service d’administration de SafeKit pour identifier de manière unique chaque nœud du cluster. C’est également le nom affiché dans la console web.

·         (3) Si besoin, cliquer sur Configuration avancée pour basculer sur l’édition du cluster au format XML.

Cliquer sur  pour ouvrir le Guide de l’utilisateur SafeKit sur la description de la configuration dans le fichier cluster.xml.

·         Cliquer sur Recharger pour abandonner vos modifications en cours et recharger la configuration d’origine.

·         (4) Une fois l'édition terminée, cliquez sur Sauvegarder et appliquer pour enregistrer et appliquer la configuration à tous les nœuds du cluster.

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

·         (1) Lire le résultat de la configuration sur chaque nœud :

ü  Succès signifie que la configuration a réussi.

ü  É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

·         Cliquer sur  pour quitter l’assistant de configuration du cluster et aller sur la page d’accueil de configuration du cluster.

Dans cet exemple, la console est chargée depuis 10.0.0.107 qui correspond au nœud node1 dans le cluster existant. Il s’agit du nœud de connexion.

·         (1) Cliquer sur Configuration dans la barre de navigation latérale

·         (2) Cliquer sur l’onglet Configuration du cluster

·         Les nœuds configurés dans le cluster sont listés avec leur date de configuration

·         (3) Cliquer sur  pour afficher des détails sur le nœud (nom des lans et adresses définies dans la configuration du cluster…)

·         (4) Cliquer sur l’un des boutons :

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

ü   pour télécharger la configuration du cluster au format XML depuis le nœud de connexion.

ü   pour déconfigurer le cluster sur un ou plusieurs nœuds.

Dans cet exemple, la console est chargée depuis 10.0.0.107 qui correspond au nœud node1 dans le cluster existant. Il s’agit du nœud de connexion.

·         Cliquer sur Configuration dans la barre de navigation latérale

·         (2) Cliquer sur l’onglet Configuration des modules

·         (3) Cliquer sur Nouveau module

·         La page propose de sélectionner un nouveau module parmi plusieurs propositions visibles en cliquant sur  :

ü  Les Principaux modules, notamment les modules génériques mirror.safe et farm.safe à 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.

Ils sont récupérés depuis node1 sous SAFE/Application_Modules/other.

ü  Un module stocké localement accessible depuis Charger un module.

·         (4) Sélectionner un module à configurer parmi les propositions listées ci-dessus. Dans l’exemple, mirror.safe.

·         (5) Cliquer sur le bouton Configurer le nouveau module.

·         Un dialogue s’ouvre pour saisir le nom du nouveau module

·         (6) Entrer le nom du nouveau module

·         (7) Cliquer sur Confirmer

·         L’assistant de configuration du module est ouvert. Celui-ci est décrit ci-dessous.

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

Ci-dessous l'exemple de l'édition de la configuration du module miroir mirror.safe.

·         (1) Remplir le formulaire pour affecter les valeurs aux différents composants, en ajouter ou en supprimer. Cliquer sur  pour ouvrir le panneau détaillé pour chaque composant.

Ce formulaire permet de saisir uniquement les principaux paramètres de configuration du module.

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

Ci-dessous l'exemple de l'édition des scripts du module miroir mirror.safe.

·         (1) Cliquer sur start_prim ou stop_prim pour l’éditer et y insérer le démarrage/arrêt de votre application.

Cliquer sur  pour copier le contenu du script et l’éditer avec votre éditeur syntaxique favori. Une fois fait, copier le contenu mis à jour dans le champ d’input avec .

·         (2) Si besoin, cliquer sur Configuration Avancée pour lister les autres scripts du module et les éditer (prestart, poststop, scripts pour les checkers…).

Cliquer sur  pour ouvrir le Guide de l’utilisateur SafeKit sur la description des scripts du module.

·         Si besoin, cliquer sur Recharger pour abandonner vos modifications et recharger la configuration complète d’origine (y compris la configuration du module si celle-ci avait été modifiée dans l’étape précédente).

·         (3) Une fois l’édition des scripts du module achevée, cliquer sur Étape suivante.

  Le cryptage des communications internes du module entre les nœuds du cluster, est activé par défaut. Pour plus de détails, voir section 10.5 page 166.

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

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.

  Étape de sélection des nœuds concernés par la configuration.

·         (1) Cochez/décochez pour sélectionner/désélectionner les nœuds. Veuillez noter que le nœud de connexion (node1 dans l'exemple) est obligatoire.

Il y a 2 cas où Sauvegarder et appliquer est désactivé :

Dans les deux cas, décochez le nœud ou cliquer sur Sauvegarder et vérifier pour l'appliquer plus tard, après avoir arrêté le module ou résolu le problème de communication.

·         (2) Cliquer sur Sauvegarder et vérifier pour sauvegarder la configuration modifiée sur le nœud de connexion et vérifier sa cohérence. Il passe ensuite à l'étape suivante pour afficher le résultat de cette opération.

Une fois cette opération terminée, toutes les modifications sont enregistrées sur le nœud de connexion. L'assistant de configuration peut être quitté et relancé ultérieurement pour appliquer la configuration sauvegardée. Tant que la configuration sauvegardée n'est pas appliquée, la dernière configuration appliquée reste active.

·         (3) Cliquer sur Sauvegarder et appliquer pour sauvegarder et appliquer la configuration modifiée aux nœuds sélectionnés. Il passe ensuite à l'étape suivante pour afficher le résultat de cette opération.

Si l'opération est réussie, la configuration appliquée devient la configuration active du module.

La configuration du module est sauvegardée du côté serveur sous SAFE/modules/AM (où AM est le nom du module). Lors de la reconfiguration du module, ce répertoire est détruit et écrasé à partir des modifications faites dans la console. Du côté serveur, fermer tous les éditeurs, explorateur de fichiers, shells ou cmd sous SAFE/modules/AM (au risque sinon que la configuration se passe mal).

L’exemple ci-dessous montre le résultat de l’opération Sauvegarder et appliquer. La présentation pour Sauvegarder et vérifier est similaire.

·         (1) Lire le résultat de l’opération sur chaque nœud :

ü  Succès signifie que l’opération a réussi

ü  É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.

Dans cet exemple, la console est chargée depuis 10.0.0.107 qui correspond au nœud node1 dans le cluster existant. Il s’agit du nœud de connexion.

·         (1) Cliquer sur Configuration dans la barre de navigation latérale.

·         (2) Cliquer sur l’onglet Configuration 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 :

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

ü   pour télécharger le .safe, composé de tous les fichiers du module (userconfig.xml, scripts) depuis le nœud de connexion.

ü  pour reconfigurer le module depuis le contenu d’un .safe stocké localement.

ü  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).

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

ü  pour désinstaller complètement le module sur un ou plusieurs nœuds.

L’ensemble des fichiers de configuration du module 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.

Dans cet exemple, le script checker.ps1 est ajouté au module mirror.

·         (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) Éditer le mirror.safe (qui est un fichier zip) pour ajouter vos scripts sous le répertoire bin (checker.ps1 dans l’exemple).

·         (5) Charger le mirror.safe modifié (l’extension zip est aussi acceptée).

·         (6) Cliquer sur  pour sélectionner le fichier à charger, puis Confirmer.

·         L'assistant de configuration du module est lancé avec le contenu de ce fichier. Les nouveaux scripts sont visibles avec la Configuration avancée à l'étape 2. Passez à l'étape 4 pour Sauvegarder et appliquer cette nouvelle configuration.

Dans cet exemple, la console est chargée à partir de 10.0.0.107, qui correspond à node1 dans le cluster. Il s'agit du nœud de connexion. Deux modules sont configurés : farm et mirror.

·         (1) Cliquer sur Supervision dans la barre de navigation latérale

·         Pour chaque module installé, sont affichés :

ü  le nom du module et des nœuds sur lesquels il est installé

ü  l’état du module et son status sur chaque nœud

ü  une notification pour chaque changement d’état, si l’utilisateur a accordé la permission et l’URL est https or http://localhost

Pour sa description, voir 3.4.1 page 56.

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

(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 leur description, voir 3.4.2 page 57.

·         (4) Cliquer sur le panneau du nœud (mirror>node1 dans l’exemple) pour ouvrir les détails du module sur ce nœud (journaux, ressources…). Depuis SafeKit 8.2.2, cliquer plutôt sur  pour ouvrir/fermer les détails.

Pour sa description, voir 3.4.3 page 59.

Le module est installé mais non configuré :

Le nœud ne répond pas 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 section 7.1 page 111.

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

Le module est configuré et le nœud répond :

STOP       arrêté (prêt à démarrer)

WAIT       en attente d’une ressource

ALONE      primaire sans secondaire (module miroir)

PRIM       primaire avec secondaire (module miroir)

SECOND    secondaire avec primaire (module miroir)

UP          actif (module ferme)

Avec les icônes/couleurs associés qui signifient :

 ou  NotReady   état bloqué

 Transient             état transitoire

Ready                     état stable

Pour la description des changements d’états d’un module miroir, voir section 5.2 page 97.

Pour la description des changements d’états d’un module miroir, voir section 6.2 page 108.

Pour un module miroir, il affiche le status des répertoires répliqués :
à jour ou non à jour.

Dans le cas particulier du mode dégradé (voir 7.6 page 117), il affiche :

Pour un module ferme, il affiche la part de partage de charge réseau sur l’IP virtuelle : 0%, 50% or 100% (pour 2 nœuds).

Lorsque le module (ferme ou miroir) est dans l'état WAIT (NotReady), la raison est affichée, généralement le nom de la règle de failover qui bloque le module jusqu'à ce que la ressource associée repasse de l'état down à l'état up. Pour plus de détails, voir 7.9 page 118.

Dans l'exemple ci-dessus, le module est bloqué par la règle de failover nommée c_checkfile. Pour analyser le problème, lisez les journaux et les états des ressources comme décrit plus loin.

Quand le nœud ne répond pas, le status est erreur de connexion.

Dans cet exemple, le module mirror est configuré sur node1 et node2.

·         (1) Cliquer sur pour ouvrir le menu d’actions sur node1.

·         (2) Utiliser Forcer le démarrage lorsque vous devez décider quel nœud doit démarrer en primaire ou secondaire.

Par exemple, au 1er démarrage d’un module miroir, vous devez Forcer le démarrage /En primaire le nœud qui a les répertoires répliqués à jour.

·         (3) pour les démarrages suivants, cliquer sur  Démarrer, car SafeKit mémorise le dernier nœud à jour.

·         Cliquer sur Debug pour télécharger les journaux ou snapshots du module depuis un seul nœud, ou depuis tous les nœuds.

Se référer aux sections listées ci-dessous :

ü  Pour le premier démarrage d’un module miroir, voir section 5.3 page 98

ü  Pour le démarrage d’un module miroir avec les données à jour, voir section 5.5 page 100

ü  Pour continuer les tests, voir section 4 page 69.

ü  Pour comprendre et vérifier le bon fonctionnement d'un module miroir, voir section 5 page 95

Dans cet exemple, le module farm est configuré sur node1 et node2.

·         (1) Cliquer sur pour ouvrir le menu d’actions globales.

·         (2) Cliquer sur  Start pour démarrer le module sur node1 et node2.

·         (3) Cliquer sur pour ouvrir le menu et exécuter des actions uniquement sur  node2.

·         Cliquer sur Debug pour télécharger les journaux ou snapshots du module depuis un seul nœud, ou depuis tous les nœuds.

Se référer aux sections listées ci-dessous :

ü  Pour continuer les tests, voir section 4 page 69.

ü  Pour comprendre et vérifier le bon fonctionnement d'un module ferme, voir section 6 page 107

Dans l'exemple, les détails du module mirror sur le node1 sont affichés.

·         (1) Cliquer sur  (mirror>node1 dans l'exemple) 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 (SafeKit version and licence…).

Le panneau de gauche affiche le journal non verbeux du module>nœud sélectionné.

·         (1) Cliquer sur  pour reprendre/suspendre la visualisation en temps réel du journal du module.

·         (2) Cliquer sur  pour télécharger le journal du module (non verbeux ou verbeux).

·         (3) Sélectionner le type de messages à afficher :

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

Pour afficher le journal du script du module, cliquer sur le message S(cript) dont vous souhaitez visualiser l’output.

·         (1) Cliquer sur le message S(cript) qui consiste en :

ü  la date et l’heure d’exécution du script

ü  le nom du script exécuté

ü  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)

Pour afficher le journal verbeux du module, cliquer sur un message autre que S(cript).

·         (1) Cliquer sur le message qui consiste en :

ü  la date et l’heure de l’évènement

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

Voir la section 7 page 111, pour une liste de messages démontrant un problème.

Le panneau de gauche affiche l’état courant des ressources du module>nœud sélectionné.

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

·         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 page 266).

Pour afficher l’historique des valeurs d’une ressource, cliquer sur la ressource qui vous intéresse.

·         (1) Cliquer sur la ligne qui consiste en :

ü  la dernière date à laquelle la ressource a été affectée

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

Il ouvre un panneau qui affiche une chronologie inversée : les états du module sur tous les nœuds au fil du temps, en commençant par la date la plus récente.

·         (1) Cliquer sur  pour ouvrir/fermer la chronologie. La chronologie affichée est celle disponible au moment du chargement.

·         (2) Cliquer sur  pour rafraîchir la chronologie avec les derniers changements d’état.

·         (3) Cliquer sur un événement de changement d'état pour afficher le journal du module pour le nœud à partir de cette date.

Dans l’exemple suivant, le module mirror est configuré sur node1 et node2. Notez qu'un snapshot peut être téléchargé dans n'importe quel état du module.

·         (1) Cliquer sur pour ouvrir le menu d’actions globales.

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

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

Installation du 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 :

ü  in Windows

SAFE=C:\safekit si SystemDrive=C:
SAFEVAR=C:\safekit\var

ü  in Linux
SAFE=/opt/safekit"

SAFEVAR=/var/safekit

Pour plus d'informations, voir la section 10.1 page 157.

       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 :

ü  la console web avec l’URI
/console/fr/monitoring/modules/AM/nodes/node1/logs

ü  la commande safekit logview –m AM exécutée sur node1, pour le journal du module

ü  sur node1, dans les fichiers SAFEVAR/modules/AM/userlog_<year>_<month>_<day>T<time>_<script name>.ulog, pour le journal des scripts

       safekit level retourne

Host : <hostname>
OS : <OS version>
SafeKit : <SafeKit version>
License : 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

Test du service safeadmin :

       Le processus safeadmin doit apparaître dans la liste des processus

       Sans ce processus, aucune commande safekit n'est réalisable et rend :

"Waiting for safeadmin .........."
"Error: safeadmin administrator daemon not running"

       En Windows, safeadmin est un service et il se démarre dans l'interface Services de Windows

Test du service safewebserver :

       safekit boot webstatus retourne le démarrage ou non du service safewebserver au boot ("on" ou "off", "on" par défaut)

       Les processus httpd doivent apparaître dans la liste des processus

       Sans ces processus, la console web n'arrive pas à se connecter aux serveurs ; les checkers de <module> (userconfig.xml) et les commandes distribuées au cluster ne peuvent pas fonctionner

       Pour démarrer/arrêter le service safewebserver, safekit webserver start |stop |restart

Test du service safeagent (uniquement en Windows):

       safekit boot snmpstatus retourne le démarrage ou non du service safeagent au boot ("on" ou "off", "off" par défaut)

       Le processus safeagent doit apparaître dans la liste des processus

       Pour démarrer/arrêter le service safeagent taper, safekit safeagent start |stop |restart

Test des modules :

       safekit boot status retourne le démarrage ("on") ou non ("off") des modules au boot

       safekit state retourne l'état de tous les modules configurés : STOP (miroir ou ferme), WAIT (miroir ou ferme), ALONE (miroir), PRIM (miroir), SECOND (miroir), UP (ferme)

       vérifier les processus d'un module (voir section 10.2 page 159)

       safekit module listid retourne le nom des modules installés et leurs ids : l'id d'un module doit être le même sur tous les serveurs

       aller dans SAFE/modules/AM/conf (où AM est le nom du module); le fichier userconfig.xml donne le type de module, mirror ou  farm: <service mode="mirror"> ou <service mode="farm">

       connecter un navigateur web à http://<server IP>:9010

       la page d'accueil de la console web apparaît

       message dans les journaux du module sur les 2 serveurs (pour lire les journaux, voir 7.3 page 115)

"Action start called by web@<IP>/SYSTEM/root"

       le module va dans l'état stable PRIM (Ready) et SECOND (Ready) sur les 2 nœuds avec dans le 1^er log

"Remote state SECOND Ready" 
"Local state PRIM Ready" 

       et dans le 2^nd log

"Local state SECOND Ready"
"Remote state PRIM Ready"

       l'application est démarrée dans le script start_prim du module PRIM avec le message dans son log

"Script start_prim"

       message dans le journal du module (pour lire les journaux voir 7.3 page 115)

"Action stop called by web@<IP>/SYSTEM/root"

       le module arrêté exécute le script stop_prim qui arrête l'application sur le serveur avec le message dans son journal :

"Script stop_prim"

       le module arrêté devient STOP (NotReady) avec les messages dans son journal :

"End of stop"

"Local state STOP NotReady"

       le module sur le serveur de reprise devient ALONE (Ready) avec le message dans son journal :

"Reason of failover: remote stop"

       l'application est redémarrée avec le script start_prim script du module qui passe dans l'état ALONE sur le serveur de reprise avec le message dans son journal :

"Script start_prim"

       message dans le journal du module redémarré (pour lire les journaux voir 7.3 page 115)

"Action start called by web@<IP>/SYSTEM/root" 

       le module STOP (NotReady) devient SECOND (Ready)

       le module sur l'autre serveur passe de ALONE (Ready) à PRIM (Ready) et continue à exécuter l'application

       message dans le journal du module redémarré (pour lire les journaux voir 7.3 page 115)

"Action restart called by web@<IP>/SYSTEM/root"

       le module PRIM devient PRIM (magenta) puis PRIM (Ready)

       les scripts du module stop_prim/start_prim sont exécutés sur le module PRIM et redémarre localement l'application avec les messages dans son journal :

"Script stop_prim"
"Script start_prim" 

       l'autre serveur reste SECOND (Ready)

       message dans le journal du module où la commande swap est passée (pour lire les journaux voir 7.3 page 115)

"Action swap called by web@<IP>/SYSTEM/root"

"Transition SWAP from SYSTEM"

"Begin of Swap"

       Et dans le journal du module sur l'autre serveur, seulement :

"Begin of Swap"

       inverse les rôles de PRIM et SECOND entre les 2 serveurs

       le script stop_prim est d'abord exécuté sur l'ancien module PRIM avec dans son journal :

"Script stop_prim" 

       puis le script start_prim est exécuté sur le nouveau module PRIM avec dans son journal :

"Script start_prim"

       à la fin du swap, le module PRIM (Ready) et le module SECOND (Ready) sont inversés sur les 2 serveurs et l'application s'exécute sur le module PRIM

Module miroir dans l'état PRIM (Ready) sur le serveur node1 et SECOND (Ready) sur le serveur node2.

userconfig.xml :

<vip>
 <interface_list>
 <interface arpreroute="on">
 <real_interface>
   <virtual_addr addr="virtip"
             where="one_side_alias"/>
  </real_interface>
  </interface>
 </interface_list>
</vip>

1.    Sur une station de travail externe (ou un serveur) dans le même LAN, ping des 2 adresses IP physiques + adresse IP virtuelle :

ping adresse_ip_node2
ping adresse_ip_node1

ping virtip
arp –a

2.    safekit swap –m AM (où AM est le nom du module) sur le serveur primaire

3.    Sur la station de travail externe (ou le serveur) dans le même LAN,

ping adresse_ip_node2
ping adresse_ip_node1

ping virtip
arp –a

Note: refaire le ping vers virtip avant de regarder la table ARP car l'entrée peut être marquée obsolète et est rafraichie après le ping

1.    Sur le serveur node1, ipconfig ou ifconfig  (ou ip addr show) retourne virtip en alias sur l'interface réseau

Sur la station externe (ou le serveur), les 3 pings répondent

Sur la station externe (ou le serveur) dans le même LAN, virtip est mappé sur l'adresse MAC de node1

arp –a
adresse_ip_node1        00-0c-29-0a-5c-fc
adresse_ip_node2        00-0c-29-26-44-93
virtip      00-0c-29-0a-5c-fc

2.    Après le swap avec SECOND (Ready) sur serveur node1 et PRIM (Ready) sur serveur node2

Dans le journal du nouveau PRIM, message :

"Virtual IP <virtip of mirror> set"

3.    Sur le serveur node2, ipconfig ou ifconfig  (ou ip addr show)  retourne virtip en tant qu'alias sur l'interface réseau

Sur la station externe (ou le serveur), les 3 pings répondent

Sur la station externe (ou le serveur), virtip est mappé sur l'adresse MAC de ip1.2

arp –a
adresse_ip_node1        00-0c-29-0a-5c-fc
adresse_ip_node2        00-0c-29-26-44-93
virtip      00-0c-29-26-44-93

Module miroir dans l’état PRIM (Ready) sur serveur node1 et SECOND (Ready) sur serveur node2.

userconfig.xml :

<rfs>
  <replicated dir "/replicated" mode="read_only" />
                         (ou "C:\replicated")
</rfs>

1.    Sur le serveur PRIM (Ready), aller sous /replicated et créer 1 fichier file1.txt

2.    Sur le serveur SECOND (Ready), aller sous /replicated et essayer de détruire file1.txt

3.    Arrêter le serveur PRIM (Ready) et attendre qu'il soit STOP (NotReady). Puis aller sur l'autre serveur devenu
ALONE (Ready) et créer un nouveau fichier file2.txt

4.    Redémarrer le serveur STOP (NotReady) et attendre qu'il soit SECOND (Ready).

1.  Le fichier file1.txt a été répliqué sur le serveur  SECOND (Ready) sous /replicated

2.    Echec car le répertoire répliqué /replicated est en lecture seule sur le serveur SECOND (Ready)

3.    Le fichier file2.txt n'est pas répliqué dans /replicated sur le serveur
STOP (NotReady)

4.    Le fichier file2.txt est réintégré sur le serveur redémarré. Pendant la phase de réintégration, le serveur est SECOND (Transient)

Dans le journal du serveur réintégré, message
"Updating directory tree from /replicated" 

Et à la fin de la réintégration de /replicated, lorsqu'au moins 1 fichier avec des données modifiées a été réintégré de la machine primaire vers la machine secondaire, message

"Copied <reintegration statistics>" 

"Reintegration ended (synchronize)"

Ce message donne les statistiques de réintégration du répertoire : taille réintégrée, nombre de fichiers, temps, débit sur le réseau de réplication en KB/sec

Note : réintégrer un fichier de plus de 100 MB pour avoir des statistiques fiables

A la fin de la réintégration, le serveur est SECOND (Ready)

       sur Windows, vérifier que la procédure spéciale d'arrêt des modules au shutdown a été réalisé (voir section 10.4 page 165)

       effectuer un shutdown du serveur PRIM (Ready)

       vérifier dans le journal du serveur SECOND (Ready) le message

"Reason of failover: remote stop"

       le serveur SECOND (Ready) devient ALONE (Ready); l'application dans le script start_prim du module est redémarrée sur le serveur ALONE avec le message dans le log

"Script start_prim"

       sur timeout dans la console web, l'ancien serveur PRIM (Ready) devient gris

       après reboot du serveur arrêté, vérifier que le shutdown de l'OS a réellement appelé avec un shutdown du module avec le message

"Action shutdown called by SYSTEM" 

       vérifier que le script stop_prim de l'application a été exécuté avec le message

"Script stop_prim"

       et vérifier que le module a été complètement arrêté avant le shutdown du serveur avec le dernier message

"End of stop"

       après reboot du serveur arrêté, si le module est automatiquement démarré au boot (safekit boot status), message dans le log

"Action start called at boot time"

       après démarrage du module sur le serveur arrêté, le module devient SECOND (Ready) sur ce serveur et PRIM (Ready) sur l'autre serveur

userconfig.xml :

<heart>
 <heartbeat name="default" />
 <heartbeat ident="flow" />
</heart>

Note : si vous voulez faire un test de double panne électrique simultanée sur les deux serveurs, vérifier que <rfs async="none"> est positionné dans userconfig.xml. Pour plus d'information, voir section 1.3.6 page 18

       dans le journal du nœud SECOND (Ready), message pour tous les heartbeats définis dans userconfig.xml

"Resource heartbeat.default  set to down by heart"
"Resource heartbeat.flow set to down by heart"
"Remote state UNKNOWN grey" 
"Reason of failover: no heartbeat "

       les messages apparaissent après 30 secondes suite au power-off (si aucun timeout configuré dans la section <heart> de userconfig.xml)

       le serveur SECOND (Ready) devient ALONE (Ready) ; l'application dans le script start_prim du module est redémarrée sur le serveur ALONE avec le message dans son log

"Script start_prim"

       sur timeout dans la console web, l'ancien serveur PRIM (Ready) devient gris

       après reboot du serveur arrêté, si le module est démarré automatiquement au boot (safekit boot status), message dans le log

"Action start called at boot time"

       après reboot, message dans le journal:

"Previous halt unexpected"

       après redémarrage du module sur le serveur arrêté, le module devient
SECOND (Ready) sur ce serveur et PRIM (Ready) sur l'autre serveur

Le split brain se produit en situation d'isolation réseau entre les deux serveurs SafeKit. Chaque serveur devient primaire ALONE et tourne l'application. Au retour du split brain, un sacrifice doit être réalisé en arrêtant l'application sur un seul des deux serveurs.

Module miroir dans l’état PRIM (Ready) et SECOND (Ready)

userconfig.xml :

<heart>
 < heartbeat name=”default” />
 < heartbeat name=”repli” ident="flow" />
</heart>

+
sur Windows pour gérer le conflit d'adresse IP sur l’IP virtuelle virtip

<vip>

 <interface_list>

  <interface check="on" arpreroute="on">

   <real_interface>

    <virtual_addr addr="virtip"   

       where="one_side_alias"/>

   </real_interface>

  </interface>

 </interface_list>

</vip>

Pour obtenir le split brain, vérifier qu'il n'y a pas de checkers dans userconfig.xml qui peuvent détecter l'isolation : pas de <interface check="on"> ou de <ping> checker

1.    déconnecter en même temps tous les réseaux avec heartbeat (réseau default et repli)

2.    reconnecter les réseaux

       après isolation réseau des deux serveurs, tous les heartbeats sont perdus. Dans les logs des 2 serveurs,

"Resource heartbeat.default  set to down by heart"
"Resource heartbeat.flow set to down by heart"
"Remote state UNKNOWN grey" 
"Local state ALONE Ready"

       cas de split brain : les 2 serveurs sont ALONE (Ready) et exécute l'application démarrée dans start_prim

       lorsque les réseaux de heartbeat sont reconnectés, sacrifice d'un des 2 serveurs ALONE : l'ancien serveur SECOND

       journal de l'ancien PRIM non sacrifié :

"Remote state ALONE Ready"
"Split brain recovery: staying alone"

       journal de l'ancien SECOND sacrifié :

"Remote state ALONE Ready"
"Split brain recovery: exiting alone"
"Script stop_prim"

Le serveur réalise un stopstart : arrêt de l'application avec stop_prim puis réintégration des fichiers répliqués à partir de l'autre serveur

       retour à l'état PRIM (Ready) et SECOND (Ready) sur les 2 serveurs tel qu'ils étaient avant split brain

Note : la situation de split brain dans un module miroir avec réplication est malsaine. En effet, le sacrifice de l'ex secondaire provoque la réintégration des données sur ce serveur à partir de la primaire et la perte des données enregistrées sur la secondaire pendant la situation de split brain.

Pour cette raison, 2 voies de heartbeat sur 2 réseaux physiquement distincts sont conseillées. Typiquement, un câble entre les deux serveurs va permettre (1) d'éviter le split brain avec un réseau supplémentaire de heartbeat et (2) de faire passer le flux de réplication.

       message dans les logs de tous les nœuds (pour lire les journaux, voir 7.3 page 115)

"Action start called by web@<IP>/SYSTEM/root"

       le module va dans l'état UP (Ready) sur tous les serveurs

       l'application est démarrée dans le script start_both du module sur tous les serveurs avec le message dans les logs

"Script start_both"

       message dans le journal du nœud arrêté (pour lire les journaux, voir 7.3 page 115)

"Action stop called by web@<IP>/SYSTEM/root"

       le nœud arrêté exécute le script stop_both qui arrête l'application sur le serveur avec le message dans le log

"Script stop_both"

       le module sur le serveur arrêté devient STOP (NotReady) avec les messages dans son journal :

"End of stop"

"Local state STOP NotReady"

       l'autre serveur reste UP(Ready) et continue à exécuter l'application

       redémarrer le serveur STOP (NotReady) avec la commande start

       message dans le journal du module où la commande restart est serveurs (pour lire les journaux, voir 7.3 page 115)

"Action restart called by web@<IP>/SYSTEM/root"

       le module redémarré devient UP (Transient) puis devient UP (Ready)

       les scripts du module stop_both/start_both sont exécutés sur le serveur et redémarre localement l'application avec les messages dans le log

"Script stop_both"
"Script start_both"

Module ferme dans l’état UP (Ready) sur les 3 serveurs ip1.1, ip1.2

userconfig.xml avec load balancing sur le service safewebserver (port TCP 9010) :

<farm>
<lan name=”default” />
</farm>

<vip>
 <interface_list>
  <interface>
  <virtual_interface type="vmac_invisible" >
    <virtual_addr addr="virtip" where="alias"/>
  </virtual_interface>
  </interface>
 </interface_list>

<loadbalancing_list>
<group name="FarmProto">
  <rule port="9010" proto="tcp" filter="on_port"/>
</group>
</loadbalancing_list>
</vip>

Sur un poste (ou un serveur) externe dans le même LAN, ping des 2 IP physiques + IP virtuelle + arp –a

       Dans le journal de tous les serveurs :

"Vitual IP <virtip  of farm> set"

       Sur les 2 serveurs, ipconfig ou ifconfig  (ou ip addr show) retourne virtip  en alias de l'interface réseau

       Sur une station de travail (ou un serveur) du même LAN, les pings répondent et virtip est mappée sur l'adresse MAC virtuelle :

ping adresse_ip_node1; ping adresse_ip_node2; ping virtip; arp –a
adresse_ip_node1   00-0c-29-0a-5c-fc
adresse_ip_node2   00-0c-29-26-44-93
virtip       5a-fe-c0-a8-38-14

       Note: par défaut, l'adresse MAC virtuelle est une adresse Ethernet unicast construite avec 5A:FE (SAFE) et l'adresse IP virtuelle en hexadécimale

Module ferme dans l’état UP (Ready) sur les 3 serveurs ip1.1, ip1.2

userconfig.xml avec load balancing sur le service safewebserver (port TCP 9010) :

<farm>
<lan name=”default” />
</farm>

<vip>
 <interface_list>
  <interface arpreroute=”on”>
  <virtual_interface type="vmac_directed" >
    <virtual_addr addr="virtip" where="alias"/>
  </virtual_interface>
  </interface>
 </interface_list>

<loadbalancing_list>
<group name="FarmProto">
  <rule port="9010" proto="tcp" filter="on_port"/>
</group>
</loadbalancing_list>
</vip>

Sur un poste (ou un serveur) externe dans le même LAN, ping des 2 IP physiques + IP virtuelle + arp –a

       Dans le journal de tous les serveurs :

"Vitual IP <virtip of farm> set"

       Sur les 2 serveurs, ipconfig ou ifconfig  (ou ip addr show)  retourne virtip en alias de l'interface réseau

       Sur une station de travail (ou un serveur) du même LAN, les pings répondent et virtip  est mappée sur l'adresse MAC de l’un des deux serveurs:

ping ip1.1; ping ip1.2; ping ip1.20; arp –a
adresse_ip_node1   00-0c-29-0a-5c-fc
adresse_ip_node2   00-0c-29-26-44-93
virtip        00-0c-29-26-44-93

Le module ferme est dans l'état UP (Ready) sur les 2 serveurs node1, node2.

Même configuration de load balancing dans userconfig.xml que le test précédent.

Sur une station distante :

1.    Se connecter à l'URL http://virtip:9010/safekit/mosaic.html, puis cliquer sur Mosaic Test.  node1, node2 répondent

2.    stop du module sur node2. Rechargement de l'URL. Seul node1 répond

Commande spéciale pour vérifier la bitmap de load balancing sur le port 9010 et sur chaque nœud
UP (Ready) :

       safekit –r vip_if_ctrl –l

Une entrée de la bitmap de 256 bits doit être à 1 sur un seul serveur

De plus, les 256 bits sont distribués de manière équitable dans les bitmaps de tous les serveurs UP (Ready) (si pas de définition de la variable power dans userconfig.xml)

     UP (Ready) sur les 2 serveurs : load balancing des sessions TCP entre node1, node2 en chargeant l'URL

Dans les ressources du module, pour node1 et node2 : FarmProto 50%.

Exemple de logs avec node1 et node2

"farm  membership: node1 node2 (group FarmProto)"
"farm load: 128/256 (group FarmProto)"

128/256: 128 bits sur 256 sont gérés par chacun des serveurs

safekit –r vip_if_ctrl –l sur node1 et node2 :

Bitmap 1:00000000:00000000:00000000:00000000:
ffffffff:ffffffff:ffffffff:ffffffff
Bitmap 2:ffffffff:ffffffff:ffffffff:ffffffff:
00000000:00000000:00000000:0000000

Les bits sont équitablement répartis entre les 2 serveurs

     STOP (NotReady) sur node2 : les sessions TCP sont servies par node1 lorsqu'on charge l'URL

Dans le journal de node1 :

"farm  membership: node1 (group FarmProto)"
"farm load: 256/256 (group FarmProto)"

256/256: tous les bits sont gérés par node1

safekit –r vip_if_ctrl –l sur node1:

Bitmap 1:ffffffff:ffffffff:ffffffff:ffffffff:
ffffffff:ffffffff:ffffffff:ffffffff

Le split brain se produit en situation d'isolation réseau entre les serveurs SafeKit.

Le module ferme est UP (Ready) UP (Ready) sur les serveurs ip1.1, ip1.2.

Même configuration de load balancing dans userconfig.xml que le test précédent. Pour obtenir le split brain, vérifier qu'il n'y a pas de checker pouvant détecter l'isolation : pas de <interface check="on"> ou de checker <ping>.

Sur la station externe:

1.    Se connecter à http://virtip:9010/safekit/mosaic.html, puis cliquer sur Mosaic Test.  node1 and node2 répondent

2.    Déconnecter le réseau entre ip1.1 et ip1.2. Suivant l'endroit où se trouve la station externe, node 1 ou node 2 répond

ou

3.    reconnecter le réseau et se connecter à l'URL

Même commande spéciale que le test précédent pour vérifier la bitmap de load balancing sur le port 9010 sur chaque nœud
UP (Ready)

       avant split brain, état UP (Ready) UP (Ready). Dans les ressources pour node1 et node2 : FarmProto 50%

Dans les logs de node1 et node2:

"farm  membership: node1 node2 (group FarmProto)"
"farm load: 128/256 (group FarmProto)"

128/256: 128 bits sur 256 sont gérés par chacun des serveurs

safekit –r vip_if_ctrl –l sur node1 et node2 :

Bitmap 1:00000000:00000000:00000000:00000000:
ffffffff:ffffffff:ffffffff:ffffffff
Bitmap 2:ffffffff:ffffffff:ffffffff:ffffffff:
00000000:00000000:00000000:0000000

Les bits sont équitablement répartis entre les 2 serveurs

     après isolation réseau, split brain :

Dans les ressources, pour node1 et node2 : FarmProto 100%

dans le journal de node1 :

"farm  membership: node1 (group FarmProto)"
"farm load: 256/256 (group FarmProto)"

256/256 : tous les bits sont gérés par node 1

safekit –r vip_if_ctrl –l on node1:

Bitmap 1:ffffffff:ffffffff:ffffffff:ffffffff:
ffffffff:ffffffff:ffffffff:ffffffff

dans le journal de node 2:

"farm  membership: node2 (group FarmProto)"
"farm load: 256/256  (group FarmProto)"

256/256: tous les bits sont gérés par node 2

Bitmap 2:ffffffff:ffffffff:ffffffff:ffffffff:
         ffffffff:ffffffff:ffffffff:ffffffff

     après split brain lorsque le réseau est reconnecté entre ip1.1 et ip1.2, les mêmes messages peuvent être trouvés dans le journal et les mêmes bitmaps que ceux avant split brain

Le comportement par défaut d'une ferme en situation de split brain est correct. La recommandation est de mettre dans userconfig.xml un réseau de surveillance <lan> </lan>, là où se trouve l'adresse IP virtuelle.

En vmac_directed, les messages dans le journal et le résultat de vip_if_ctrl sont différents.

4.3.7.1      Prérequis réseau

Une adresse MAC Ethernet unicast 5a-fe-xx-xx-xx-xx est associée à l'adresse virtuelle ip1.20 d'un module ferme. Elle n'est jamais présentée par les serveurs SafeKit en tant qu'adresse Ethernet source (MAC invisible). Les switchs ne peuvent donc pas localiser cette adresse. Lorsqu'ils font suivre un paquet à destination de l'adresse MAC 5a-fe-xx-xx-xx-xx, ils doivent broadcaster le paquet sur tous les ports du LAN ou VLAN où se situe l'adresse IP virtuelle (flooding). Et tous les serveurs de la ferme reçoivent donc les paquets à destination de l'adresse MAC virtuelle 5a-fe-xx-xx-xx-xx.

Noter que ce prérequis n'existe pas pour un module miroir : voir section 4.2.6 page 74

4.3.7.2      Prérequis serveur

Les paquets remontent dans les cartes Ethernet mises en mode promiscuous par SafeKit. Et les paquets sont filtrés par le module kernel <vip> suivant la bitmap de load balancing. Pour réaliser le test, il faut un outil de monitoring du réseau.

Ex. monitoring réseau sur Linux :

       tcpdump host ip1.20 : capture tous les paquets réseau

       tous les serveurs sont UP (Ready)

       le monitoring réseau est lancé dans chaque serveur en filtrant sur ip1.20

       une console externe envoie un seul ping vers l'adresse IP virtuelle avec ping –n (ou –c) 1 ip1.20

       résultat : 1 paquet "ICMP: Echo: From ipconsole To ip1.20" envoyé et reçu par l'ensemble des serveurs

       résultat : il doit y avoir autant de paquets "ICMP: Echo Reply: To ipconsole From ip1.20" qu'il y a de serveurs UP (Ready)

       si ce n'est pas le cas, vérifier si des options restreignent le "port flooding" dans les switchs et empêche le broadcast de "ICMP: Echo" vers tous les serveurs

       attention : la restriction "port flooding" dans les switchs peut avoir lieu après un certain nombre de flooding (temps, nombre de KB floodés) : le test ping est à répéter sur plusieurs heures en créant du flooding sur l'adresse IP virtuelle

Note : pour éviter les outils de monitoring réseau, une console externe Linux peut être utilisée. Le ping Linux permet de vérifier les paquets dupliqués revenant des 3 serveurs
UP (Ready) :
ping virtip
64 bytes from ip1.20 icmp_seq=1
64 bytes from ip1.20 icmp_seq=1 (DUP!)
64 bytes from ip1.20 icmp_seq=1 (DUP!)
64 bytes from ip1.20 icmp_seq=2
64 bytes from ip1.20 icmp_seq=2 (DUP!)
64 bytes from ip1.20 icmp_seq=2 (DUP!)
...
Ce test peut être réalisé pendant plusieurs heures en stockant l'output du ping dans un fichier et en vérifiant ensuite qu'il y a eu des (DUP!) tout le temps : date > /tmp/ping.txt ; ping ip1.20 >> /tmp/ping.txt

       sur Windows, vérifier que la procédure spéciale d'arrêt des modules au shutdown a été réalisée : voir section 10.4 page 165

       effectuer un shutdown d'un serveur UP (Ready)

       les autres serveurs restent UP (Ready) et continuent à exécuter l'application

       sur timeout de la console web, l'ancien serveur UP (Ready) devient gris

       après reboot du serveur arrêté, vérifier que le shutdown de l'OS a réellement appelé un shutdown du module avec le message

"Action shutdown called by SYSTEM" 

       vérifier que le script stop_both de l'application a été exécuté avec le message

"Script stop_both"

       et vérifier que le module a été complètement arrêté avant le shutdown du serveur avec le dernier message

"End of stop"

       après reboot du serveur arrêté, si le module est automatiquement démarré au boot (safekit boot status), message dans le log

"Action start called at boot time"

       après démarrage du module sur le serveur arrêté, le module devient UP (Ready) sur ce serveur et il exécute le script start_both qui redémarre l'application sur le serveur avec le message dans le log

"Script start_both"

       les autres serveurs restent UP (Ready) et continuent à exécuter l’applicatif

       sur timeout dans la console web, l’ancien serveur UP (Ready) devient gris

       après reboot du serveur arrêté, si le module est démarré automatiquement au boot (safekit boot status), message dans le log

"Action start called at boot time"

       après reboot, message dans le log

"Previous halt unexpected"

       après redémarrage du module sur le serveur rebooté, le module devient UP (Ready) et il exécute le script start_both qui relance l’applicatif sur ce serveur avec le message dans le log

"Script start_both"

Dans userconfig.xml :

<errd>

<proc name="appli.exe" atleast="1"
                                     action="restart "
                                     class="prim "/>
</errd>

       name="appli.exe" atleast="1": au moins un processus "appli.exe" doit s'exécuter

       class="prim" (cas d’un module miroir) checker exécuté sur le serveur dans l’état  (Ready) (i.e. PRIM ou ALONE) ; démarré après start_prim (arrêté avant stop_prim)

       class="both" (cas d’un module ferme) checker exécuté sur tous les serveurs dans l’état  UP (Ready), démarré après start_both (arrêté avant stop_both)

       action="restart" : si "appli.exe" n'est pas présent, action restart qui exécute seulement les scripts stop_xx ; start_xx

       action="stopstart" : si "appli.exe" n'est pas présent, action stopstart qui arrête totalement le module puis le redémarre

Kill du processus "appli.exe" sur le serveur (Ready) ; c’est-à-dire dans l’état PRIM ou ALONE pour un module miroir et l’état UP pour un module ferme :

       messages dans le journal :

"Process appli.exe not running" 
"Action restart|stopstart called by errd" 

       le module passe dans un état
 (Transient), respectivement PRIM, ALONE ou UP

       dans le cas restart, le module redevient (Ready), respectivement dans l’état PRIM, ALONE ou UP

       dans le cas stopstart, le module redevient (Ready),  respectivement dans l’état SECOND, ALONE ou UP

message dans le log

"Action start called automatically"

Note : un stopstart sur PRIM (Ready) provoque un basculement

Reproduire le test sur le même serveur s'il tourne toujours l'application (i.e. (Ready) ALONE ou UP) :

       avec les valeurs par défaut de maxloop="3" et loop_interval="24" (userconfig.xml <service>)

       au bout de 4 kills sur un même serveur, le module devient STOP (NotReady)

       message dans le journal avant l'arrêt :

"Stopping loop" 

Dans userconfig.xml :

<tcp ident="id" when="prim ">
  <to addr="virtip" port="idport" interval="10"
                                                timeout="5" />
</tcp>

<failover>
<![CDATA[
tcpid_failure: if (tcp.id == down) then stopstart();
]]>
</failover>

       le checker vérifie que l'application tcp lancée sur le port idport répond à des demandes de connexion

       addr="ip.virtual", port="idport" : connexions TCP testées sur l'adresse IP virtip  et sur le port TCP idport

       interval="10", timeout="5" par défaut : test fait toutes les 10 secondes et avec un timeout de 5 secondes

       class="prim" (cas d’un module miroir) checker exécuté sur le serveur dans l’état  (Ready) (i.e. PRIM ou ALONE) ; démarré après start_prim (arrêté avant stop_prim)

       class="both" (cas d’un module ferme) checker exécuté sur tous les serveurs dans l’état  UP (Ready), démarré après start_both (arrêté avant stop_both)