Heatbeat au LAL Marec erwan Charbonnel Jaclin.

Présentation au sujet: "Heatbeat au LAL Marec erwan Charbonnel Jaclin."— Transcription de la présentation:

1 Heatbeat au LAL marec@lal.in2p3.fr Marec erwan charbonnel@lal.in2p3.fr Charbonnel Jaclin

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

3 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 ?)

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

5 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

6 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é)

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

8 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

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

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

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

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

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

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

15 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 ?

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

17