A.4.1 Configuration initiale

Configurez le matériel de la machine, du réseau et du stockage, ainsi que les systèmes d'exploitation, les comptes utilisateur et les autres ressources système de base conformément aux instructions du document relatif à la configuration requise pour Sentinel et le client local. Testez les systèmes afin de vérifier leur bon fonctionnement et leur stabilité.

A.4.2 Configuration de l'espace de stockage partagé

Configurez votre espace de stockage partagé et assurez-vous de pouvoir le monter sur chaque noeud de grappe. Si vous utilisez FibreChannel et un sous-réseau de stockage (SAN), des connexions physiques et d'autres opérations de configuration seront peut-être nécessaires. L'espace de stockage partagé servira à contenir les bases de données et les données d'événements Sentinel. Sa taille doit dès lors être adaptée à l'environnement client, en fonction du taux d'événements attendu et des stratégies de conservation des données.

Une implémentation classique peut consister en un SAN rapide attaché via FibreChannel à tous les noeuds de grappe, avec un vaste tableau RAID pour stocker les données d'événements locales. Un stockage en réseau (NAS) distinct ou un noeud iSCSI peuvent être utilisés pour le stockage réseau plus lent. Pour autant que le noeud de grappe puisse monter le stockage local comme un périphérique de bloc normal, la solution peut l'utiliser. Le stockage réseau peut également être monté en tant que périphérique de bloc ou consister en un volume NFS ou CIFS.

Notre exemple de solution utilise des cibles iSCSI configurées sur une machine virtuelle SUSE Linux. La machine virtuelle est storage03 telle que répertoriée dans la Configuration initiale. Les périphériques iSCSI peuvent être créés à l'aide d'un fichier ou d'un périphérique de bloc, mais pour plus de simplicité, nous utiliserons dans ce cas un fichier créé à cette fin.

Connectez-vous à storage03 et démarrez une session de console. Utilisez la commande dd pour créer un fichier vide de la taille souhaitée pour l'espace de stockage local de Sentinel :

dd if=/dev/zero of=/localdata count=10240000 bs=1024

Dans ce cas, nous créons un fichier de 10 Go rempli de zéros (copié à partir de /dev/zero pseudo-device). Consultez la page d'informations ou du manuel pour la commande dd afin de connaître les options de la ligne de commande. par exemple pour créer des « disques » de tailles différentes. La cible iSCSI traite ce fichier comme s'il s'agissait d'un disque, mais vous pouvez bien entendu utiliser un disque réel si vous préférez.

Répétez cette procédure afin de créer un fichier destiné au stockage réseau :

dd if=/dev/zero of=/networkdata count=10240000 bs=1024

Pour cet exemple, nous utilisons deux fichiers (« disques ») à la taille et aux performances identiques. Pour un déploiement en production, vous pouvez prévoir le stockage local sur un SAN rapide et le stockage réseau sur un volume iSCSI, NFS ou CIFS plus lent.

Configurez ces fichiers comme cibles iSCSI :

La procédure susmentionnée expose deux cibles iSCSI sur le serveur à l'adresse IP 10.0.0.3. Vérifiez qu'il est possible sur chaque noeud de monter le périphérique de stockage partagé des données locales. Vous devez également formater les périphériques (une seule fois) :

Répétez les étapes 1 à 15 de la procédure susmentionnée pour vous assurer que chaque noeud de cluster peut monter le stockage partagé local. Remplacez toutefois l'adresse IP du noeud à l'étape 5 par une autre (par ex. node02 > 10.0.0.2).

A.4.3 Installation de Sentinel

Sentinel peut être installé de deux façons : vous pouvez installer tous les composants de Sentinel à l'emplacement de stockage partagé (en utilisant l'option --location pour rediriger l'installation de Sentinel vers l'emplacement de montage du stockage partagé) ou y placer uniquement les données variables de l'application.

Dans notre exemple de solution, nous suivrons cette seconde approche et installerons Sentinel sur chaque noeud de cluster qui peut l'héberger. À la première installation de Sentinel, nous effectuerons une installation complète, y compris les fichiers binaires de l'application, la configuration et toutes les banques de données. Les installations suivantes sur les autres noeuds de cluster installeront uniquement l'application et supposeront que les données effectives de Sentinel seront disponibles ultérieurement (par ex. une fois le stockage partagé monté).

Dans cet exemple, nous installerons Sentinel sur chaque noeud de cluster et n'enregistrerons sur le stockage partagé que les données variables de l'application. De cette façon, les fichiers binaires et la configuration de l'application restent à leur emplacement standard. Nous pouvons alors vérifier les RPM et prendre en charge l'application de correctifs à chaud dans certains scénarios.

Répétez l'installation sur les autres noeuds :

Le programme d'installation initial de Sentinel crée pour le produit un compte utilisateur qui emploie l'ID utilisateur suivant disponible au moment de l'installation. Les installations suivantes en mode sans surveillance tentent d'employer le même ID utilisateur pour la création du compte, mais des conflits sont possibles (si les noeuds de cluster ne sont pas identiques au moment de l'installation). Il est vivement recommandé d'effectuer l'une des opérations suivantes :

À la fin de ce processus, Sentinel doit être installé sur tous les noeuds, mais il est très probable qu'il ne fonctionne correctement que sur le premier tant que les diverses clés n'ont pas été synchronisées. Cette synchronisation a lieu lors de la configuration des ressources de cluster.

A.4.4 Installation de clusters

Installez le logiciel de cluster sur chaque noeud et enregistrez chaque noeud de cluster auprès du gestionnaire. Les procédures pour ce faire dépendent de l'implémentation du cluster, mais à la fin du processus, chaque noeud de cluster doit s'afficher dans la console de gestion des clusters.

Dans notre exemple, nous allons configurer l'extension SUSE Linux Enterprise High Availability Extension et la superposer avec des agents de ressource propres à Sentinel :

Si vous n'utilisez pas l'agent de ressource OCF pour surveiller Sentinel, vous devez développer une solution de surveillance similaire pour l'environnement de cluster local. L'agent de ressource OCF pour Sentinel est un script Shell simple qui effectue différents contrôles pour vérifier si Sentinel est fonctionnel. Si vous souhaitez développer le vôtre, examinez l'agent de ressource existant à titre d'exemple (l'agent de ressource figure dans le fichier sentinel-ha.rpm du package de téléchargement Sentinel.)

Il existe de nombreuses manières de configurer un cluster SLE HAE, mais les options que nous allons sélectionner permettent à la procédure de rester relativement simple. La première étape consiste à installer le logiciel SLE HAE. La procédure est expliquée en détail dans la Documentation SLE HAE. Pour plus d'informations sur l'installation de produits complémentaires SLES, reportez-vous au Guide de déploiement.

Vous devez installer l'extension SLE HAE sur tous les noeuds de cluster (node01 et node02 dans notre exemple). Le produit complémentaire installe le logiciel de communication et de gestion du cluster principal ainsi que les nombreux agents de ressource utilisés pour surveiller les ressources de grappe.

Une fois le logiciel de cluster installé, vous devez encore installer un RPM supplémentaire afin de disposer des agents de ressource de grappe spécifiques à Sentinel. Le RPM se trouve dans le fichier novell-Sentinel-ha-7.1*.rpm contenu dans le paquetage de téléchargement normal de Sentinel que vous avez décompressé pour installer le produit.

Sur chaque noeud de cluster, copiez le fichier novell-Sentinel-ha-7.1*.rpm dans le répertoire /tmp, puis entrez les commandes suivantes :

cd /tmp

rpm -i novell-Sentinel-ha-7.1*.rpm

A.4.5 Configuration du cluster

Le logiciel de cluster doit être configuré pour enregistrer chaque noeud en tant que membre du cluster. Dans le cadre de cette configuration, vous pouvez également définir des paramètres d'isolement ainsi que les ressources STONITH pour assurer la cohérence du cluster.

Dans notre exemple de solution, nous utilisons la plus simple des configurations, sans redondance supplémentaire ni la moindre fonction avancée. De même, nous utilisons une adresse monodiffusion (au lieu de l'adresse multidiffusion recommandée) car elle nécessite moins d'interaction avec les administrateurs réseau et suffit pour effectuer des tests. Nous configurons également une simple ressource d'isolement SBD.

L'exemple de solution utilise des adresses IP pour les communications de cluster internes et applique la monodiffusion pour ne pas devoir demander d'adresse multidiffusion à l'administrateur réseau. La solution utilise également une cible iSCSI configurée sur la machine virtuelle SUSE Linux qui héberge déjà le système de stockage partagé pour servir de périphérique SBD à des fins d'isolement. Comme indiqué ci-avant, les périphériques iSCSI peuvent être créés à l'aide d'un fichier ou d'un périphérique de bloc, mais pour plus de simplicité, nous utiliserons dans ce cas un fichier créé à cette fin.

La procédure suivante ressemble fort à celle de la configuration du stockage partagé :

Configuration du périphérique SBD

Connectez-vous à storage03 et démarrez une session de console. Utilisez la commande dd pour créer un fichier vide de la taille souhaitée :

dd if=/dev/zero of=/sbd count=1024 bs=1024

Dans ce cas, nous créons un fichier de 1 Mo rempli de zéros (copié à partir de /dev/zeropseudo-device).

Configurez ce fichier en tant que cible iSCSI :

Cette procédure doit exposer une cible iSCSI pour le périphérique SBD sur le serveur à l'adresse IP 10.0.0.3 (storage03).

Configuration du noeud

Connectez-vous à un noeud de cluster (node01) et ouvrez une console :

Connectez-vous à chaque noeud de cluster supplémentaire (node02) et ouvrez une console :

Dans certains cas, les communications de cluster ne s'initialisent pas correctement. Si le cluster ne démarre pas (le service openais ne parvient pas à démarrer) :

Dans certains cas, le script risque d'échouer car le service xinetd n'ajoute pas correctement le nouveau service csync2. Ce service est nécessaire pour que l'autre noeud puisse synchroniser les fichiers de configuration du cluster sur ce noeud. En cas d'erreurs du type csync2 run failed (échec de l'exécution de csync2), ce problème risque de vous concerner. Pour le résoudre, exécutez kill -HUP `cat /var/run/xinetd.init.pid, puis réexécutez le script sleha-join.

À ce stade, vous devriez pouvoir exécuter la commande crm_mon sur chaque noeud de cluster et constater que le cluster s'exécute correctement. Une alternative consiste à utiliser « hawk », la console Web. Les références de connexion par défaut sont « hacluster / linux  ».

Deux autres paramètres doivent être légèrement modifiés pour cet exemple ; leur application au cluster de production d'un client dépend de sa configuration :

A.4.6 Configuration des ressources

Comme mentionné dans la section dédiée à l'installation de clusters, cette solution fournit un agent de ressource OCF pour surveiller les principaux services hébergés par SLE HAE, mais vous pouvez créer des alternatives si vous le souhaitez. Le logiciel dépend également de plusieurs autres ressources pour lesquelles des agents de ressource sont fournis par défaut avec SLE HAE. Si vous ne souhaitez pas utiliser SLE HAE, vous devez surveiller ces ressources supplémentaires à l'aide d'une autre technologie :

Il existe d'autres ressources, notamment MongoDB utilisé pour Security Intelligence et le bus de messages ActiveMQ. Pour l'instant, ces ressources, au minimum, sont surveillées dans le cadre des services de base.

Cet exemple de solution utilise des versions simplifiées des ressources requises telles que l'agent de ressource simple du système de fichiers. Au besoin, vous pouvez utiliser des ressources de grappe plus sophistiquées telles que cLVM (une version de volume logique du système de fichiers).

La solution de l'exemple fournit un script crm facilitant la configuration du cluster. Le script extrait les variables de configuration pertinentes du fichier d'installation sans surveillance généré dans le cadre de l'installation de Sentinel. Si vous n'avez pas généré de fichier d'installation ou que vous souhaitez modifier la configuration des ressources, vous pouvez modifier le script en conséquence.

Connectez-vous au noeud d'origine sur lequel vous avez installé Sentinel (ce doit être le noeud sur lequel vous avez effectué une installation complète de Sentinel) et procédez comme suit (<SHARED1> est le volume partagé créé ci-dessus) :

mount /dev/<SHARED1> /var/opt/novell

cd /usr/lib/ocf/resource.d/novell

./install-resources.sh

Si vous rencontrez des problèmes lors de l'arrivée de nouvelles ressources dans le cluster; exécutez la commande /etc/rc.d/openais restart sur node02.

Le script install-resources.sh vous demande d'entrer quelques valeurs, à savoir l'adresse IP virtuelle que vous souhaitez voir utilisée pour l'accès à Sentinel ainsi que le nom du périphérique de stockage partagé. Il crée ensuite automatiquement les ressources de grappe requises. N'oubliez pas que le script exige que le volume partagé soit déjà monté, mais aussi que le fichier d'installation sans surveillance créé pendant l'installation de Sentinel soit présent à l'emplacement /tmp/install.props. Vous ne devez exécuter ce script que sur le premier noeud installé ; tous les fichiers de configuration pertinents seront automatiquement synchronisés avec les autres noeuds.

Si l'environnement du client diffère de la solution de l'exemple, vous pouvez modifier le fichier resources.cli (dans le même répertoire) et modifier les définitions à partir de ce fichier. Par exemple, la solution de l'exemple utilise une ressource de système de fichiers simple, mais vous préférerez peut-être utiliser une ressource cLVM davantage axée sur le cluster.

Après avoir exécuté le script Shell, vous pouvez exécuter une commande d'état crm. Le résultat devrait se présenter comme suit :

crm status

Last updated: Thu Jul 26 16:34:34 2012
Last change: Thu Jul 26 16:28:52 2012 by hacluster via crmd on node01
Stack: openais
Current DC: node01 - partition with quorum
Version: 1.1.6-b988976485d15cb702c9307df55512d323831a5e
2 Nodes configured, 2 expected votes
5 Resources configured.

Online: [ node01, node02 ]
stonith-sbd    (stonith:external/sbd):    Started node01
 Resource Group: sentinelgrp
     sentinelip    (ocf::heartbeat:IPaddr2):    Started node01
     sentinelfs    (ocf::heartbeat:Filesystem):    Started node01
     sentineldb    (ocf::novell:pgsql):    Started node01
     sentinelserver    (ocf::novell:sentinel):    Started node01

À ce stade, les ressources Sentinel pertinentes doivent être configurées dans le cluster. Vous pouvez examiner la façon dont elles sont configurées et groupées dans l'outil de gestion du cluster, par exemple, en exécutant l'état crm.

A.4.7 Configuration du stockage réseau

Afin de finaliser ce processus, configurez le stockage réseau pour que Sentinel puisse migrer les partitions d'événement vers un système de stockage meilleur marché. Cette étape est facultative, le système de stockage réseau ne devant effectivement pas obtenir le même niveau de haute disponibilité que celui dont bénéficiait le reste du système. Vous pouvez utiliser n'importe quel répertoire (monté à partir d'un SAN ou non), ou un volume NFS ou CIFS.

Cliquez sur Stockage en haut, dans la barre de menus, puis sélectionnez Configuration. Pour effectuer ce paramétrage, sélectionnez ensuite l'un des boutons sous Stockage réseau non configuré.

Dans l'exemple, la solution utilise une simple cible iSCSI comme emplacement de stockage réseau partagé avec une configuration relativement comparable à celle du système de stockage local. Dans les implémentations de production, les technologies de stockage seront probablement différentes.

Utilisez la procédure suivante pour configurer le stockage réseau que Sentinel doit utiliser :

L'exemple de solution utilise des versions simples des ressources requises telles que l'agent de ressource simple du système de fichiers. S'ils le souhaitent, les clients peuvent utiliser des ressources de grappe plus sophistiquées telles que cLVM (une version de volume logique du système de fichiers).