Haute Disponibilité. A- Installation et Configuration du HeartBeat

Transcription

1 Haute Disponibilité A- Installation et Configuration du HeartBeat 1- De nombreuses techniques sont utilisées pour améliorer la disponibilité : -> la redondance des matériels et la mise en cluster ; -> la sécurisation des données : RAID, snapshots, Oracle Data Guard (en), BCV (Business Copy Volume), SRDF (Symmetrix Remote Data Facility), DRBD ; -> la possibilité de reconfigurer le serveur «à chaud» (c est-à-dire lorsque celui-ci fonctionne) ; -> mode dégradé ou un mode panique ; plan de secours ; et sécurisation des sauvegardes : externalisation, centralisation sur site tiers. # Configuration des deux fichiers principaux avec les droits nécessaires : nano /etc/heartbeat/ha.cf logfile /var/log/heartbeat.log logfacility local7 udpport 694 node node # On défini la périodicité de controle des noeuds entre eux (en seconde) keepalive 2 # Au bout de combien de seconde un noeud sera considéré comme "mort" deadtime 15 ucast eth > celui du voisin # Rebascule-t-on automatiquement sur le primaire si celui-ci redevient vivant? oui* auto_failback off

2 crm yes On doit emttre dans /etc/resolv.conf nameserver ( serveur DNS ) et et dans /etc/hosts on met intranet1 et 2 # Configuration de authkeys Un «node» est un noeud. Autrement dit un serveur membre du cluster. L auto_failback permet de rebasculer directement sur le serveur maitre quand il redevient opérationnel après qu il ai été déclaré comme «mort» (quand il est configuré à «yes «. Nous passons maintenant au fichier «/etc/heartbeat/authkeys «, ce fichier va définir la clé qui permettra d authentifier un minimum les serveurs membres du cluster entre eux : nano /etc/heartbeat/authkeys Voici un contenu possible : auth 1 1 sha1 MaClefSecrete Il faut savoir que l on peut utiliser trois modes de sécurisation dans ce fichier : sha1 md5 crc Par sécurité, on sécurise ce fichier en lui mettant des droits plus restreints : chmod 600 /etc/heartbeat/authkeys -> desactiver stonith -> desactiver quorum # crm configure property stonith-enabled=false # crm configure property no-quorum-policy="ignore"

3 # Configuration du DNS L adresse IP du DNS se trouve dans le fichier /etc/resolv.conf (DNS par défaut) Configuration de la zone inverse :

4 J entre les adresses IP correct pour test1 et test2 ainsi que les serveurs (ip non virtuelle), puis de meme pour la zone inverse

5 Puis je redémarre le service et je teste le DNS Puis j ai configuré test1.conf et test2.conf situé dans /etc/apache2/sites-available, en ajoutant l adresse Ip ou le FQDN (test1.sisr :80)

6 J active test1.conf Puis je desactive le service SSL afin qu il n entrave pas le fonctionnement de peacemaker, suite à quoi je redémarre le service web apache2 # Configuration du Failover IP du Cluster Heartbeat est maintenant configuré sur les deux serveurs Web. Cependant, le Failover IP doit également être configuré pour rendre le service Web hautement disponible sur une adresse IP virtuelle.

7 Pour cet article, le service Web sera accessible à l adresse IP virtuelle /24, correspondant au nom FQDN Voici donc la commande à utiliser pour configurer cette adresse IP virtuelle sur le Cluster : root@web1:~# crm configure primitive IPFailover ocf:heartbeat:ipaddr2 params ip=" " cidr_netmask=" " nic="eth0" op monitor interval="10s" timeout="20s" op start timeout="30s" op stop timeout="40s" La commande ci-dessus ne devra être saisie que sur l un des deux serveurs. Il sera ensuite possible de vérifier le fonctionnement du Failover IP à l'aide de la commande "crm status" : root@web1:~# crm status Cette commande retournera notamment l'état du Failover. Dans le cas présent, le Failover IP est lancé sur le serveur web1.domain.lan : On pourra également vérifier la présence de l'adresse IP virtuelle sur le serveur web1 à l'aide de la commande "ip addr show" : Depuis un client situé dans le même réseau, il sera possible d'accéder à cette adresse IP depuis un navigateur Web :

8 # Configuration de la ressource HTTP pour le Cluster A ce stade, le Cluster est pratiquement fonctionnel, il ne reste plus que la ressource HTTP à configurer. Actuellement, le Failover IP fonctionne mais le service Web Apache2 fonctionne simultanément sur les deux serveurs Web. Ainsi, il va être nécessaire de lier le fonctionnement du service Web au Failover Pour cela, il va d'abord être nécessaire d'arrêter le service Web Apache2 sur chacun des serveurs root@web1:~# service apache2 stop root@web2:~# service apache2 stop Ensuite, le service Web va devoir être supprimé de la liste des services du démarrage. Pour cela, il sera nécessaire d'utiliser la commande insserv sur chaque serveur Web comme montré ci-dessous : root@web1:~# insserv -r -v apache2 Le résultat devra alors être le suivant sur chaque serveur :

9 Il faudra ensuite créer une nouvelle ressource pour le Cluster. Elle sera nommée "serviceweb" et utilisera un script lsb : root@web1:~# crm configure primitive serviceweb lsb:apache2 op monitor interval= "60s" op start interval="0" timeout="60s" op stop interval="0" timeout= "60s" Test : on fait crm_mon sur le maître et on voit le IP virtuelle Maintenant que la ressource "serviceweb" est créée, elle va pouvoir être intégrée au Cluster. Pour cela, il va être nécessaire d'éditer la configuration du Cluster à l'aide de la commande suivante : root@web1:~# crm configure La commande group permettra de synchroniser le démarrage du service Web Apache2 à la présence de l'adresse IP virtuelle du Failover sur l'un des serveurs. crm(live)configure# group web IPFailover serviceweb meta migration-threshold="5" Il faudra alors appliquer les modifications puis quitter l'outil de configuration du Cluster crm(live)configure# commit crm(live)configure# quit Le Cluster Actif/Passif de serveurs Web est maintenant configuré, il ne reste plus qu'à tester ses fonctionnalités pour s'assurer de la Haute Disponibilité du service Web

10 Validation des fonctionnalités du Cluster Maintenant que le Cluster est mis en place, il va bien entendu être nécessaire de le tester Préparation de l'environnement pour les tests Pour réaliser les tests décrits dans cette partie, il va être nécessaire de modifier la page Web par défaut sur chaque serveur Web afin de les distinguer depuis un navigateur Web. Sur chaque serveur, il va donc être nécessaire d'éditer le fichier /var/www/index.html. Par exemple, pour le serveur web1.domain.lan, nous allons ajouter l'élément suivant : On fera ensuite la même chose sur le serveur web2.domain.lan : Comme nous l'avons vu précédemment, l'utilisation de la commande "ip addr show" permet de connaître le serveur sur lequel se trouve l'adresse IP virtuelle. Dans le cas présent, l'adresse IP virtuelle se trouve sur web1.domain.lan : A partir d'un navigateur Web depuis un client situé dans le même réseau IP que les serveurs, si le client se rend à l'adresse / ou l'écran suivant apparaîtra :

11 La présence du message "Serveur web1.domain.lan" permet de vérifier que le service Web est bien lancé sur le premier serveur du Cluster possédant l'ip virtuelle. Ainsi, on voit que le Failover IP est bien synchronisé avec le service Web Apache2. Les autres tests vont maintenant pouvoir être effectués Vérification du basculement du service Web Pour vérifier que la ressource HTTP peut passer d'un serveur Web à l'autre, il sera possible d'utiliser la commande suivante sur le serveur possédant actuelle l'adresse IP virtuelle (dans l'exemple présenté ici, web1.domain.lan) : root@web1:~# crm node standby Au bout de quelques instants, le serveur web1 devrait perdre son adresse IP virtuelle au profit du serveur web2.domain.lan :

12 L'adresse IP virtuelle est donc maintenant présente sur le second serveur Web En actualisant la page sur votre navigateur Web, on pourra constater le changement de serveur : Une fois que ce test est terminé et concluant, il ne reste plus qu'à vérifier la continuité de service en cas d'arrêt de l'un des noeuds du Cluster Continuité de service en cas d'arrêt d'un noeud Pour vérifier la continuité de service Web, il va être nécessaire d'arrêter le serveur Web sur lequel le service Apache2 fonctionne actuellement. Dans le cas présent, il s'agit du serveur web2.domain.lan root@web2:~# halt Au bout de quelques instants, le serveur sera arrêté. Vous pourrez alors constater que l'adresse IP virtuelle aura automatiquement été basculé sur le second noeud du Cluster : Le service Web devra également être toujours accessible, mais il aura lui aussi basculé sur le second serveur :

13 Conclusion Le Cluster Actif/Passif de serveurs Web est maintenant fonctionnel. Les sites qui seront stockés sur ces serveurs bénéficient donc d'une Haute Disponibilité. Il peut être intéressant, voire même indispensable de sécuriser les flux HTTP avec la mise en place d'une Autorité de Certification et la mise en place d'un certificat SSL/TLS. Ce sujet sera traité dans mon prochain article. # La réplication des données avec MySQL : Sur le serveur maître, créer l'utilisateur MySQL ayant des droits suffisants : mysql> GRANT REPLICATION SLAVE ON *.* TO replicateur@'%' IDENTIFIED BY 'mdpreplicateur' ; S'assurer que la base de données est identique sur les deux serveurs (en cas de doute, faire une sauvegarde sur l'un et restaurer sur l'autre) Mise en place des bases de données à répliquer qui doivent être identiques sur tous les serveurs avant de commencer la réplication : on va devoir s assurer qu aucune nouvelle donnée ne soit enregistrée pendant le laps de temps nécessaire à la configuration. À ce moment, il s agit de bloquer l écriture sur la (les) base(s) que l on souhaite répliquer de manière à s assurer qu aucune nouvelle donnée ne soit

14 enregistrée : on doit pour cela saisir la commande suivante sur le serveur «maître» «FLUSH TABLES WITH READ LOCK;» : cette dernière va alors fermer toutes les tables ouvertes, et verrouiller en lecture toutes les tables et bases. À ce moment-là, les requêtes qui voudront faire une écriture seront mises en file d'attente, jusqu'au déblocage par la commande «UNLOCK TABLES;». Bloquer l écriture sur les bases du serveur maître de manière à s assurer qu aucune nouvelle donnée ne soit enregistrée : mysql>flush TABLES WITH READ LOCK; Configuration de la réplication via le fichier /etc/mysql/my.cnf sur chaque serveur : la réplication de bases de données implique une configuration différente sur chaque serveur. Cette configuration dépend de leur rôle et nécessite (entre autres) un identifiant unique dans la chaîne de réplication. Quelques directives utilisées dans /etc/mysql/my.cnf sur des versions de MySQL inférieures à 5.5 ne fonctionnent plus (et empêchent MySQL de démarrer avec une erreur dans les logs «unknown variable»), même si ces directives sont encore présentes dans le fichier exemple! Aussi, il ne faut pas se fier complètement aux configurations proposées sur Internet et TOUJOURS exploiter les logs. Fichier de configuration : /etc/mysql/my.cnf Pour simplifier le processus (et pour faciliter l'ajout de nouveaux esclaves à un maître), les versions récentes de MySQL (5.x) permettent (et oblige parfois, à partir de la 5.5) d'effectuer des opérations «à chaud» directement dans la console SQL, à l'aide de la commande SQL CHANGE MASTER TO. Aussi, les fichiers de configuration déterminent uniquement un statut «maître» ou «esclave». Tous les paramètres permettant d'établir un lien entre le maître et l'esclave (comme l'adresse IP du maître, le nom de l'utilisateur et le mot de passe, etc) seront réalisés avec la commande SQL pré-citée.

15 Sur le serveur «maître» : [mysqld] # bind-address = log-error =/var/log/mysql.errs log_bin = /var/log/mysql/mysql-bin.log max_binlog_size = 100M b inlog_do_db = databasename Sur le serveur «esclave» : [mysqld] s erver-id = 104 #bind-address = log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 10 max_binlog_size = 100M replicate-do-db = databasename Remarque : la gestion des logs binaires sur l'esclave et notamment l'option log-slave-updates (comme le fait de commenter la variable «bind-address») n'est utile que lors d'une réplication circulaire ou d'une réplication multi maître. On peut maintenant redémarrer MySQL sur l'esclave. N'hésitez pas à lire en parallèle le fichier «/var/log/mysql.err» notamment si MySQL ne se lance plus

16 Configurer le serveur «maître» : fichier /etc/mysql/my.cnf [mysqld] #bind-address = log-error =/var/log/mysql.err server-id =1 log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 10 max_binlog_size = 100M binlog_do_db = gsb_valide Configurer le serveur «esclave» : fichier /etc/mysql/my.cnf (au minimum) [mysqld] #bind-address = log-error =/var/log/mysql.err server-id =2 log_bin = /var/log/mysql/mysql-bin.log log-salve-updates expire_logs_days = 10 max_binlog_size = 100M master-retry-count = 20 replicate-do-db = gsb_valide Redémarrer MySQL pour que les modifications soient prises en compte /etc/init.d/ mysql restart Lorsque la configuration est terminée, et si on ne l'a pas encore fait, il faut : s'assurer que les bases de données soient bien synchronisées, dans le cas contraire il faut le faire bloquer au préalable l'écriture sur le maître (si ce n'est déjà fait) ; récupérer des informations sur le maître (voir ci-après) ; indiquer à l'esclave via la commande SQL CHANGE MASTER TO l'ensemble des opérations à réaliser (voir ci-après) ; permettre l'écriture sur le maître ;

17 lancer l'esclave. Étapes après modifications des fichiers de configuration Sur le serveur maître, il est nécessaire, après s'être assuré que les deux bases de données sont identiques (voir comment faire dans la partie «dépannage» si vous avez un doute) : De bloquer l'écriture : mysql> FLUSH TABLES WITH READ LOCK; Query OK, 0 rows affected (0.09 sec) De repérer le log binaire et la position du jeu de commandes dans le log : mysql> show master status; Du résultat de cette requête, ce sont les champs File et Position qu'il faut noter. C'est à partir de cette position que tout ce qui sera écrit sur le maître sera répliqué sur l'esclave. Un fois que les données ont été répliquées, l'esclave garde la trace du point où il en était rendu (une nouvelle Position, voire un nouveau File ). Le serveur maître n'a pas de notions du nombre d'esclaves qui se connectent, ou qui sont à jour à un moment donné. Il faut donc ensuite indiquer au serveur esclave : à partir de quel serveur maître il doit répliquer ses bases de données (on utilisera l'adresse IP du serveur maître), en lisant quel fichier journal de requêtes (dans l'exemple, mysql-bin ), à partir de quelle position dans ce fichier journal (dans l'exemple, 3921 ), et enfin, avec quel utilisateur ( il s'agit du compte utilisateur créé précédemment Voir «Étapes avant modification des fichiers de configuration» ). Tout ceci est effectué en une seule ligne avec la syntaxe spéciale CHANGE MASTER TO.

18 Le processus esclave, s'il existe (ce que l'on peut voir avec la commande «show slave status ;», doit être arrêté auparavant. Pour ce faire, dans la console SQL du serveur esclave, exécutez : STOP SLAVE ;. Ce processus doit être redémarré ensuite. Il est temps maintenant de déverrouiller les bases de données sur le serveur maître : mysql> UNLOCK TABLES; Pour connaître le statut de l'esclave Sur l'esclave Bloquer de nouveau l écriture sur les bases du serveur maître. Sur le serveur maître, repérer le log binaire et la position du jeu de commandes dans le log (avec show master status) Sur le serveur esclave, déclarer le serveur maître : mysql> change master to -> master_host=' ', -> master_user='replicateur', -> master_password='mdpreplicateur', -> master_log_file='mysql-bin ', -> master_log_pos=3921; mysql> start slave ; Sur le serveur «maître», débloquer l'écriture : mysql> unlock tables;