Heatbeat au LAL Marec erwan Charbonnel Jaclin

Objectifs : - Assurer la disponibilité d’un service en cas de panne du serveur. - Si les services sont interrompus, minimiser le downtime. - Automatiser la procédure de reprise du service ainsi que le retour à la normale. - Minimiser les pertes d’informations. Vœux pieux : - Si possible trouver une solution dans le domaine du logiciel libre ou une solution « non propriétaire ». - Intégrer cette solution dans une migration de l’architecture du SI/LAL - Mettre au point une migration par étape (si possible à grain fin).

Solution High Availability Linux : Un Cluster pour un autre cluster ? - Quel est l’univers « cluster » au LAL ? - Qu’attend on réèllement des outils HA linux ? - Est on capable d’estimer et d’exprimer correctement les besoins ? (notion de downtime et de automatic recovery) - Ou se place l’ASR dans ce type de solution ? (acteur actif ou observateur attentif ?)

Le matériel et les softs retenus ? - le plus banalisé possible, interchangeable, robuste et de préférence bénéficiant d’un bon rapport qualité/prix - permettant l’installation d’un OS Linux (SL4.2 ou SL4.3 parait bien) - HeartBeat 1.41 en production, version 2 en cours d’évaluation. - Dans une premier temps, link state ethernet, pas de drdb sur serial link et pas de stonith - Des services standards à passer en services HA, le premier de la liste étant le Web, le suivant les serveurs de BDD.

Logiciel HA Heartbeat : - S'exécute sur les deux ordinateurs qui vont former le cluster. - Communique d'une machine à l'autre via un lien ethernet. - Détecte la panne de l'autre. - Gère l'arrêt et le démarrage des services HA. - Deux modes possibles : - Actif-Passif - Actif-Actif

Préliminaires : Installer les deux machines de base (de préférence de même distribution, ça simplifie les choses) Installer les services de façon à ce que les fichiers de configuration, services et données soient sur le disque partagé(double attachement au SAN ou disponible via NFS clusturisé)

Point de panne unique (single point of failure, ou SPOF) Avec la configuration ci-dessus, nous avons : - Deux blocs d'alimentation redondants - Deux cartes maîtresses/mémoires/CPU redondants - Deux disques en miroir et/ou synchronisés qui ne sont pas dans le même boîtier + 2 attachement distant (NFS …) - Câble Ethernet standard, attention à la panne du commutateur Heartbeat : Agit comme init pour lancer et arrêter les services. Gère les services en groupe, c.-à.-d. les services dans ce groupe, incluant l'adresse IP de service, sont transférés d'une machine à l'autre. A besoin de deux autres adresses IP (une par machine) pour ses propre besoins.

HA peut réduire le transfert de service de façon importante : 90 % => 37 jours de non disponibilité de service par année 99 % => 3,7 jours 99,9 % => 8,8 heures 99,99 % => 53 min. 99,999 % => 5,3 min. 99,9999 % => 32 secondes

PUB2PUB 3 Service Web Client PUB 1 Pré production 80 virtual hosts 6 virtual hosts

Qui est le maître, qui est l’esclave ? - choix du mode Actif/Actif : pas de relation maître/esclave. - choix du mod Actif/Passif : existence d’une servitude.

Simplicité du produit à l’installation : - 1 prérequis sur la version kernel de linux s’assurer d’un kernel >= patch à passer suivant la version exacte du kernel. - 2 fichiers de configuration à renseigner dont le /etc/ha.d - Quelques paramètres à ajuster.

Une fois déployé, que faut il faire ? - S’assurer de pouvoir surveiller les services périodiquement (NAGIOS/ZABBIX). - Disposer de logs locaux de HeartBeat ne pas hésiter à regarder les logs debug pour se familiariser avec le comportement du soft. - Si stonith n’est pas installé, attention aux phases de « life lock » qui peuvent survenir (rare).

Les avantages et inconvénients (si il y en a) ? - On peut améliorer la redondance en pensant à rajouter des éléments redondants supplémentaires. la limite : le coût par rapport à l’effort. - Déployer Heartbeat sur d’autres services est rapide. le retour d’expérience est positif. - Le monitoring de HeartBeat est rudimentaire => NAGIOS indispensable à l’heure actuelle.

BDD1BDD2 Client SAN (BDD) Service de BDD Mysql Oracle ZODB Phase 2 envisagée

Jusqu’où irons nous // jusqu’où peut on aller ? - Atomisation et virtualisation puis mise en cluster possible pour une majorité de service. - Attention à ne pas transformer un outils simple en une usine à gaz compliquée (l’élan créateur) - Pourquoi pas un cluster NFS/SMB/Open GPFS sur le même principe ?

Finalement que peut on dire sur cette expérience ? - Très bon compromis simplicité/fonctionnalité. - Installation et déploiement aisé, petite phase de rodage sur les paramètres (discussion dans le démo de ce soir). - Petite faiblesse dans l’exploitation journalière des logs (nécessite de disposer d’un outil « externe » de type NAGIOS). - Bonne documentation et bonne réactivité communautaire. - Outil stable et ayant bien évolué (stabilité datant de 1999).