Guide d'installation rapide de SafeKit avec une nouvelle application Linux (module farm.safe avec partage de charge réseau et reprise sur panne)

Guide d'installation rapide de SafeKit avec une nouvelle application sur Linux (farm.safe)

Configuration étape par étape

1. Lancez la console SafeKit

Lancez la console Web dans un navigateur sur un nœud du cluster en vous connectant à http://localhost:9010.
Entrez admin comme nom d'utilisateur et le mot de passe défini lors de l'installation.

Vous pouvez également exécuter la console dans un navigateur sur un poste de travail externe au cluster.

La configuration de SafeKit se fait sur les deux nœuds à partir d'un seul navigateur.

Pour sécuriser la console Web, consultez 11. Sécurisation du service web de SafeKit dans le Guide de l'utilisateur.

2. Configurer les adresses des nœuds

Entrez les adresses IP des nœuds et appuyez sur la touche Tabulation pour vérifier la connectivité et remplir le nom des nœuds.
Ensuite, cliquez sur Save and apply pour enregistrer la configuration.

Si le nœud 1 ou le nœud 2 a une couleur rouge, vérifiez la connectivité du navigateur aux deux nœuds et vérifiez le pare-feu sur les deux nœuds pour résoudre le problème.

Dans une architecture ferme, vous pouvez définir plus de 2 nœuds.

Si vous le souhaitez, vous pouvez ajouter un nouveau LAN pour un deuxième heartbeat.

Cette opération placera les adresses IP dans le fichier cluster.xml sur les deux nœuds (plus d'informations dans le training avec les lignes de commande).

4. Configurer le module

Choisissez un démarrage Automatic du module au boot sans délai dans Module startup at boot.
Normalement, vous disposez d'un seul réseau Heartbeat à moins que vous ayez ajouter un LAN à l'étape 2.
Saisissez une Virtual IP address.
Une adresse IP virtuelle est une adresse IP standard dans le même réseau IP (même sous-réseau) que les adresses IP des deux nœuds.
Les clients de l'application doivent être configurés avec l'adresse IP virtuelle (ou le nom DNS associé à l'adresse IP virtuelle).
Définissez le port du service sur lequel réaliser le load balancing (ex. : TCP 80 pour HTTP, TCP 443 pour HTTPS, TCP 9010 dans l'exemple).
Définissez la règle d'équilibrage de charge, Source address ou Source port :
- avec l'adresse IP source du client, le même client sera connecté au même nœud de la ferme sur plusieurs sessions TCP et récupérera son contexte sur le nœud.
- avec le port TCP source du client, le même client sera connecté à différents nœuds de la ferme sur plusieurs sessions TCP (sans retrouver un contexte).
Notez que si un nom de processus est affiché dans Monitored processes/services, il sera surveillé avec une action de redémarrage en cas de panne. La configuration d'un mauvais nom de processus entraînera l'arrêt du module juste après son démarrage.

5. Modifier les scripts (facultatif)

start_both et stop_both doivent contenir le démarrage et l'arrêt de l'application Linux (exemple fourni pour Microsoft IIS à droite).
Vous pouvez ajouter de nouveaux services dans ces scripts.
Vérifiez que les noms des services démarrés dans ces scripts sont ceux installés sur les deux nœuds, sinon modifiez-les dans les scripts.
Sous Windows et sur les deux nœuds, avec le gestionnaire de services Windows, définissez Boot Startup Type = Manual pour tous les services démarrés dans start_both (SafeKit contrôle le démarrage des services dans start_both).

8. Attendez la transition vers UP (vert) / UP (vert)

Le nœud 1 et le nœud 2 doivent atteindre l'état UP (vert), ce qui signifie que le script start_both a été exécuté sur le nœud 1 et le nœud 2.

Si UP (vert) n’est pas atteint ou si l'application n'est pas démarrée, analysez pourquoi avec le journal du module du nœud 1 ou du nœud 2.

cliquez sur l'icône « journal » de node1 ou node2 pour ouvrir le journal du module et recherchez des messages d'erreur tels qu'un checker détectant une erreur et arrêtant le module.
cliquez sur start_both dans le journal : les messages de sortie du script sont affichés à droite et des erreurs peuvent être détectées comme un service mal démarré.

9. Test

SafeKit apporte un test intégré dans le produit :

Configurez une règle pour le port TCP 9010 avec un équilibrage de charge sur le port TCP source.
Connectez un poste de travail externe en dehors des nœuds de la ferme.
Démarrez un navigateur sur http://virtual-ip:9010/safekit/mosaic.html.
Vous devriez voir une mosaïque de couleurs en fonction des nœuds répondant aux requêtes HTTP.
Arrêtez un nœud UP (vert) en faisant défiler son menu contextuel et en cliquant sur Stop.
Vérifiez qu'il n'y a plus de connexions TCP sur le nœud arrêté et sur l'adresse IP virtuelle.

Plus d'informations sur les tests dans le Guide de l'utilisateur.

Internes

Fichiers internes de SafeKit pour l'équilibrage de charge Linux avec haute disponibilité

Allez dans le tab Advanced Configuration de la console pour modifier les fichiers ci-dessous.

Fichiers internes au module Linux farm.safe

userconfig.xml (description dans le guide de l'utilisateur)

<!DOCTYPE safe>
<safe>
<service mode="farm" maxloop="3" loop_interval="24">
  <!-- Farm topology configuration for the membership protocol -->
  <!-- Names or IP addresses on the default network are set during initialization in the console -->
  <farm>
    <lan name="default" />
  </farm>
  <!-- Virtual IP Configuration -->
  <!-- Replace
     * VIRTUAL_IP_ADDR_TO_BE_DEFINED by the IP address of your virtual server 
  -->
  <vip>
    <interface_list>
      <interface check="on" arpreroute="on">
        <virtual_interface type="vmac_directed">
          <virtual_addr addr="VIRTUAL_IP_ADDR_TO_BE_DEFINED" where="alias"/>
        </virtual_interface>
      </interface>
    </interface_list>
    <loadbalancing_list>
      <group name="Windows_Appli">
        <!-- Set load-balancing rule on the TCP port of the service to load balance -->
        <rule port="TCP_PORT_TO_BE_DEFINED" proto="tcp" filter="on_addr"/>
      </group>
    </loadbalancing_list>
  </vip>
  <!-- TCP Checker Configuration -->
  <!-- Replace
     * VIRTUAL_IP_ADDR_TO_BE_DEFINED by the IP address of your virtual server 
     * TCP_PORT_TO_BE_DEFINED by the TCP port of the service to check
  -->
  <check>
    <tcp ident="Check_Appli" when="both">
      <to
         addr="VIRTUAL_IP_ADDR_TO_BE_DEFINED"
         port="TCP_PORT_TO_BE_DEFINED"
         interval="10"
         timeout="5"
       />
    </tcp>
  </check>
  <!-- User scripts activation -->
  <user nicestoptimeout="300" forcestoptimeout="300" logging="userlog" />
</service>
</safe>

start_both

#!/bin/sh
# Script called on the primary server for starting application

# For logging into SafeKit log use:
# $SAFE/safekit printi | printe "message" 

# stdout goes into Application log
echo "Running start_both $*" 

res=0

# Fill with your application start call

if [ $res -ne 0 ] ; then
  $SAFE/safekit printe "start_both failed"

  # uncomment to stop SafeKit when critical
  # $SAFE/safekit stop -i "start_both"
fi

stop_both

#!/bin/sh
# Script called on the primary server for stopping application

# For logging into SafeKit log use:
# $SAFE/safekit printi | printe "message" 

#----------------------------------------------------------
#
# 2 stop modes:
#
# - graceful stop
#   call standard application stop
#
# - force stop ($1=force)
#   kill application's processes
#
#----------------------------------------------------------

# stdout goes into Application log
echo "Running stop_both $*" 

res=0

# default: no action on forcestop
[ "$1" = "force" ] && exit 0

# Fill with your application stop call

[ $res -ne 0 ] && $SAFE/safekit printe "stop_both failed"