Haute disponibilité d'un service Web dynamique

Dimension: px
Commencer à balayer dès la page:

Download "Haute disponibilité d'un service Web dynamique"

Transcription

1 Haute disponibilité d'un service Web dynamique Propriétés Type de publication Intitulé court Intitulé long Module Côté Labo Date de publication Septembre 2013 Date de modification Septembre 2013 Version V1.0 Description Haute disponibilité d'un serveur Web dynamique Haute disponibilité d'un serveur Web avec réplication de la base de données correspondante. BTS SIO2 SISR3 Exploitation des services Transversalité SI7 : Justifier le choix d une solution de mise en production d un service Stratégies et techniques associées à la continuité de service Stratégies et techniques de sauvegarde et de restauration de données Stratégies et techniques de répartition et de réplication Présentation Activités Pré-requis Savoir-faire principaux SISR4 : Justifier le choix d une solution de gestion de la disponibilité d un serveur Installer et configurer une solution de disponibilité de serveurs Disponibilité des systèmes, méthodes, technologies, techniques, normes et standards associés L'objectif de ce Coté Labo (mis en œuvre en module) est de mettre en place une solution de haute disponibilité pour l'application de gestion de frais du laboratoire pharmaceutique Galaxy-Swiss Bourdin (GSB) Il fait suite au Coté Labo «Le service Web sécurisé» : D1.3 - Mise en production d'un service A1.3.2 Définition des éléments nécessaires à la continuité d'un service D2.1 - Exploitation des services A2.1.2 Évaluation et maintien de la qualité de service D3.2 - Installation d une solution d infrastructure D3.3 - Administration et supervision d'une infrastructure A3.3.1 Administration sur site ou à distance des éléments d'un réseau, de serveurs, de services et d'équipements terminaux Avoir quelques notions sur l'installation, la configuration et l'administration d'un serveur Linux (ou Ubuntu). Exploitation des services Web et bases de données (dont sauvegarde et restauration). L'application gestion de frais est installée et opérationnelle. En SISR3 : Caractériser les éléments nécessaires à la qualité, à la continuité et à la sécurité d'un service Installer et configurer les éléments nécessaires à la qualité et à la continuité du service Valider et documenter la qualité, la continuité et la sécurité d'un service CERTA - septembre 2013 v1.0 Page 1/30

2 Prolongements En SI7 : Rédiger, mettre en place et tester un Plan de Continuité D'activité (PCA) En SISR3 : Assurer la haute disponibilité des autres services présents sur le serveur Intégrer la répartition de charges En SISR5 : Superviser le Cluster Outils Mots-clés Durée Auteur(es) SE : Serveur Linux Debian Wheezy (stable actuelle) ou ultérieur Serveurs/services : Apache2, PHP, MySQL-server installé et configuré à l'identique sur deux serveurs, Hearbeat et Pacemaker. Clients : navigateur web sur STA Linux, Windows ou autre système. Outils d'analyse et de tests de bon fonctionnement ainsi que phpmyadmin. Contexte : organisation/gsb-organisation.doc. Site officiel de Pacemaker : Documentation : Disponibilité, HA, HD, Cluster, Heartbeat, Pacemaker, réplication. 12 heures en TP Apollonie Raffalli La haute disponibilité La «haute disponibilité» (en anglais «high availability») regroupe de nombreuses techniques et processus permettant de garantir un certain pourcentage de disponibilité d'un service. Par exemple, un taux de 99 % de disponibilité assure une disponibilité d'environ 361 jours sur 364 alors qu'un taux de 99,5 % assure une disponibilité de plus de 363 jours sur 365. La réalité économique fait que les organisations tendent de plus en plus vers des taux encore plus grands comme 99,9 % ou 99,99 % notamment sur certains services critiques. En effet, les conséquences d'une interruption de service sont innombrables et peuvent coûter très cher à tous points de vue. Par exemple, sur le site on pouvait lire qu'une interruption de service de 40 mn le 19 août 2013 aurait fait perdre à Amazon près de 5 millions de dollars. (http://www.zdnet.fr/actualites/comme-google-amazon-a-subi-une-panne-informatique htm) Pour améliorer la haute disponibilité, il existe de nombreuses configurations possibles. Dans une configuration très simple (celle que nous allons découvrir dans ce Côté labo), la haute disponibilité nécessite la présence d'un serveur secondaire, fonctionnant sous le même système d'exploitation et fournissant un accès aux services que l'on souhaite rendre «hautement» disponibles. Ce second serveur configuré à l'identique, en règle générale services arrêtés, surveillera le premier en permanence. En cas de panne du serveur primaire, il le détectera et prendra la relève, devenant alors le nouveau serveur actif. CERTA - septembre 2013 v1.0 Page 2/30

3 Comment ça marche? Selon Un des algorithmes utilisés pour ce genre d'opérations est basé sur la tachycardie. Il est appelé «heartbeat», ou battements de cœur. Le serveur actif émet régulièrement des informations sur le réseau pour dire qu'il est vivant, pendant que l'autre écoute passivement. Si plus aucune information n'arrive au serveur en écoute, celui-ci s'alarme : Il prend alors le rôle de serveur actif (les services basculent sur ce serveur) et se met à son tour à émettre des battements de cœur. Si l'autre serveur est restauré, il jouera, au moins dans un premier temps, le rôle de serveur en écoute. N'importe quelle machine pourra ainsi tomber en panne sans que l'ensemble ne soit pénalisé. Ces techniques seront mises en œuvre via deux outils à installer et configurer : Heartbeat qui permet de détecter la défaillance d'un poste grâce à un système de communication basé sur un échange de paquets UDP et de gérer le Cluster en lui-même (on aurait pu tout aussi bien utiliser ici un autre outil comme «Corosync»). Pacemaker qui est un gestionnaire de ressources. Il est chargé de créer, démarrer, arrêter et superviser les ressources du Cluster c'est à dire les services gérés en Cluster et donc inclus dans la continuité de services. Problématique n 1 La haute disponibilité sous-entend que plusieurs machines seront utilisées pour répondre à un même service. Seulement, chaque machine a normalement une adresse IP différente sur le réseau, ce qui est problématique puisque le client ne connaît qu'une seule adresse IP et/ou le nom d'hôte pleinement qualifié (qui n'est associé qu'à une seule adresse IP). Comment alors faire en sorte que toutes les machines en haute disponibilité répondent à la même adresse? Il faut mettre en place une adresse IP virtuelle, c'est-à-dire une adresse IP qui ne sera pas toujours reliée à la même machine physique. L'adresse IP virtuelle est en fait attribuée au Cluster c'est à dire au groupe de machines participant à la haute disponibilité. L'utilisateur ne connaîtra que cette adresse, et sera en fait redirigé vers l'un ou l'autre des serveurs par un mécanisme réseau. Pour cela, plusieurs solutions sont possibles. Dans notre cas, nous n'utilisons que 2 machines en haute disponibilité (une active et une passive) ; une seule d'entre elles fonctionne pour répondre aux requêtes, on peut lui demander de reconnaître 2 adresses IP au lieu d'une : la sienne et l'adresse virtuelle. Toute requête est adressé à l'adresse IP virtuelle. Lorsqu'elle tombe en panne, la machine passive prend la main, lance ses services et se met à répondre à son tour aux requêtes à destination de l'ip virtuelle. CERTA - septembre 2013 v1.0 Page 3/30

4 Exemple d'un fonctionnement en cas de serveur maître disponible : Serveur maître IP : Serveur esclave IP : IP virtuelle Lors de son lancement et après configuration, Heartbeat, via Pacemaker, activera l'ip virtuelle au serveur considéré comme «actif» à un instant donné. Si le serveur maître n'est plus disponible : À noter qu'il n'y a pas que l'ip virtuelle qui sera activée sur un serveur et désactivée sur l'autre mais aussi les services (appelés ressources) que l'on a décidé de mettre en haute disponibilité (comme HTTP). Serveur maître IP : Serveur esclave IP : IP virtuelle En cas de défaillance du serveur primaire, c'est le serveur secondaire qui sera accessible à l'adresse Lorsque la première machine est restaurée, deux options peuvent être envisagées : elle pourra faire à son tour office de secours ; elle pourra forcer l'autre machine à redevenir passive, et prendre sa place actuelle. Remarque : c'est l'adresse IP virtuelle qui doit «apparaître» dans les fichiers de configuration des services (par exemple, dans la configuration des serveurs Web virtuels et celle du serveur DNS). Problématique n 2 Cette architecture basée sur un basculement de services nécessite aussi une solution qui va permettre d'accéder à tout moment aux données actuelles. La plupart des services inclus dans un système de haute disponibilité utilise des données, parmi eux : le service Web utilise quasi systématiquement des données stockées dans des bases de données SQL (et/ou XML) qu'il est donc nécessaire de répliquer également comme nous allons le faire dans ce coté labo ; le service d'authentification (parfois lui-même également utilisé par le service Web) stocke des données dans des annuaires (comme LDAP) qu'il faut également répliquer ; Le service de fichier (comme Active Directory ou Samba sur Linux, un serveur NFS, un serveur FTP, etc.) utilise bien évidemment les données des utilisateurs stockées sur une partition locale ou distante. il est alors nécessaire de disposer d'un programme qui synchronise en temps réel une partition entre deux machines (une sorte de RAID 1 réseau) : la solution la plus utilisée pour créer ce type de serveur est d'utiliser Distributed Replicated Block Device (DRBD) comme nous allons l'étudier dans le Côté labo suivant. CERTA - septembre 2013 v1.0 Page 4/30

5 Plusieurs architectures sont possibles. En règle générale, les données sont stockées sur un serveur «à part» (un serveur de base de données, par exemple) : La base de données est accessible par chaque serveur Web. Les disques sont éventuellement en RAID. Serveur maître Hearbeat + Pacemaker + service Web actif Lien HA Serveur esclave Hearbeat + Pacemaker + service Web non actif IP virtuelle Si le serveur maître n'est plus disponible, tout ce qui est écrit dans la base de données sera retrouvé par le serveur esclave puisqu il s'agit de la même base de données mais nous introduisons ici un point de faiblesse car en cas de défaillance physique du serveur de bases de données lui-même (et pas seulement d'un disque), les données ne sont plus disponibles. Il faut donc assurer aussi la haute disponibilité du serveur de bases de données en répliquant les bases contenant les données utiles en temps réel sur une autre machine. Par mesure de simplification, les bases de données seront, dans ce Coté labo, implantées sur le même serveur que le serveur Web mais le principe de réplication est strictement identique. L'architecture mise en place est la suivante : Serveur maître IP : Hearbeat + Pacemaker + serveur Web (Apache 2) + serveur de bases de données (MySQL) IP virtuelle Lien HA + Réplication MySQL Serveur esclave IP : Hearbeat + Pacemaker + serveur Web (Apache 2) + serveur de bases de données (MySQL) CERTA - septembre 2013 v1.0 Page 5/30

6 La réplication d'un système de gestion de base de données L'architecture native de la réplication MySQL est basée sur une architecture maître-esclave ou réplication unidirectionnelle. Le principe est simple : un seul serveur (le maître) assure les opérations d écriture (commandes SQL INSERT, UPDATE et DELETE) et éventuellement de lecture (commande SQL SELECT), tandis que les esclaves se contentent d'enregistrer les modifications opérés sur le maître. Dans certains cas (lorsque l'application cliente est développée à cet effet) les esclaves assurent aussi les opérations de lecture. La synchronisation entre le maître et les esclaves est quasi instantanée. Une solution existe en cas de défaillance du maître : il suffit d activer les opérations d écriture sur un esclave pour disposer d un nouveau maître ; cette solution peut être mise en œuvre manuellement ou automatiquement si l'on s'adjoint d'autres outils comme un outil capable de dire si le serveur est tombé et/ou des scripts pour basculer un serveur d'esclave vers maître et vice versa. Le type de réplication idéal lorsque deux nœuds sont en jeu reste quand même la réplication bidirectionnelle : tout ce qui est réalisé sur un serveur est recopié sur l'autre en temps réel et viceversa : relation maître-maître ou pour être plus précis (maître/esclave et esclave/maître). Ce type de réplication est obligatoire lorsqu'on a pour but d'équilibrer la charge d'une base de données en lecture et écriture. Mais une base de données devant se mettre à jour en écriture simultanément sur plusieurs serveurs pose des problèmes techniques et il est nécessaire d'utiliser des technologies de Clustering comme le fait MySQL Cluster qui est la base de données distribuée de MySQL. Cette dernière solution est, sommes toutes, difficile à mettre en œuvre, aussi des configurations plus simples et fiables permettant de transformer une réplication maitre-esclave en maître-maître (ou multi maître) ont vu le jour et correspondent à la majeure partie des contextes de production. C'est cette dernière que nous mettrons en œuvre dans ce Coté labo. Vous trouverez en : annexe 1 : le fonctionnement et la configuration des outils Heartbeat dans sa version 3 et Pacemaker ; annexe 2 : la configuration des ressources ; annexe 3 : le principe de la réplication sur MySQL ; annexe 4 : un récapitulatif des commandes courantes. Contexte Le laboratoire pharmaceutique Galaxy-Swiss Bourdin (GSB) met à disposition des visiteurs médicaux une application Web sécurisée de gestion des frais de remboursement (Cô té labo «Service Web sécurisé»). Cette application nécessite : un serveur Web sécurisé (HTTPS, SSL/TLS) ; l'accès à une base de données relationnelle, éventuellement administrable par interface Web. L'authentification des visiteurs pour l'accès au contenu est gérée par l'application à travers la base de données. L'entreprise a choisi d'héberger en interne les serveurs exécutant l'application sur un serveur Linux. Par mesure de simplification, les deux serveurs sont sur la même machine physique. À noter aussi que ce Côté labo peut être réalisé même si le protocole HTTPS n'a pas été mis en œuvre. GSB désire disposer d'un serveur de secours prêt à prendre le relais si le serveur principal venait à ne plus être opérationnel. Vous disposez, dans la ferme des serveurs, d'une machine virtuelle (et vous êtes en mesure d'en créer d'autres) sur laquelle se trouve l'application Web opérationnelle en HTTP ou HTTPS. Les fichiers de configuration devront être à terme modifiés pour intégrer l'adresse IP virtuelle. La résolution des noms est prise en charge par un serveur DNS déjà configuré qui a (en interne) autorité sur la zone gsb.coop. Votre serveur fait partie de la zone gsb.coop, il est accessible par son nom pleinement qualifié déclaré sur le serveur DNS (par exemple, pour les tests, servintralabxx.gsb.coop où XX représente les initiales de vos prénoms et noms). CERTA - septembre 2013 v1.0 Page 6/30

7 Déroulement de la séquence Préalable : Rédigez une note listant les techniques et processus communément utilisés pour améliorer la disponibilité d'un service. 1. Préparation des serveurs primaire et secondaire (aide en annexe 1) Le travail sera dans un premier temps réalisé sur le serveur qui tiendra lieu de serveur maître que l'on clonera par la suite. Le serveur primaire aura pour nom d'hôte «interne» «intralabxx» et le serveur secondaire «hdintralabxx» où XX représente les initiales des prénoms et noms des étudiants). Vérifiez que l'application Gestion de frais est bien accessible sur le serveur maître. Installez Heartbeat, configurez les deux fichiers principaux et accordez les droits nécessaires. Assurez-vous que les noms d'hôtes présents dans les fichiers de configuration puissent être convertis en adresse IP via /etc/hosts. Clonez le serveur primaire et procédez à la configuration IP du serveur esclave. Démarrez les nœuds et vérifiez que Heartbeat s'est correctement lancé sur les deux nœuds. Vérifiez la configuration de Hearbeat sur chaque nœud et désactivez STONITH et le quorum. Vérifiez de nouveau la configuration ainsi que le fichier XML généré. 2. Configuration des ressources «failover IP» et «serviceweb» (aide en annexe 2) Configuration du Failover IP Créez la ressource permettant le «failover IP». En option, vous créez un moniteur pour cette ressource avec un test de vie de la ressource de 10 secondes, un timeout de démarrage de 30 secondes et un timeout d'arrêt de 40 secondes. Sur quel nœud la ressource a-t-elle été lancée? Justifiez et vérifiez. Migrez éventuellement la ressource (si elle n'y était pas déjà) sur le nœud primaire ; vérifiez que la ressource est bien activée sur ce nœud et que la préférence a été donnée à ce nœud. Testez l'accès au service Web à partir de l'adresse IP virtuelle. Procédez aux modifications nécessaires au niveau des fichiers de configuration d'apache. Quel autre service est obligatoirement impacté par le changement d'adresse IP? Testez le «failover IP» des deux manières présentées en annexe 2. Y a-t-il une différence? Configuration de la ressource HTTP Sur les deux nœuds, arrêtez le service HTTP et supprimez ce service du démarrage. Créez la ressource «serviceweb» et vérifiez sur quel nœud elle démarre. Vérifiez que le service HTTP soit bien démarré sur le serveur spécifié et non activé sur l'autre. Groupez les ressources de manière à ce qu'elles soient actives sur le même nœud. Quels sont les tests que vous effectuez pour vérifier la solution mise en place? 3. Configuration de la réplication des bases de données (aide en annexe 3) La réplication de la base de données se fera dans un premier temps isolé des problématiques de Heartbeat et de Pacemaker et selon une architecture de type maître-esclave. Écrivez la procédure détaillée que vous allez mettre en œuvre pour configurer la réplication de la base de données. Cette procédure fera l'objet d'un échange avec votre professeur avant son implémentation. Mettez en œuvre la réplication selon le procédure. Proposez et réalisez des tests permettant de vérifier l'opérationnalité de la solution dans un tableau à 4 colonnes (actions à effectuer, résultats attendus, résultats obtenus, statut). Transformez l'architecture maître-esclave en architecture multi maître afin de ne pas perdre de données lorsque le serveur maître sera de nouveau opérationnel après une défaillance. Vous rédigerez au préalable une procédure. Après l'avoir testée, intégrez cette solution au Cluster. CERTA - septembre 2013 v1.0 Page 7/30

8 Proposez et réalisez des tests permettant de vérifier l'opérationnalité de la solution complète en complétant votre tableau. CERTA - septembre 2013 v1.0 Page 8/30

9 Annexes Annexe 1 : fonctionnement et configuration de Hearbeat 3 et de Pacemaker Un Cluster est un groupe d'ordinateurs reliés qui travaillent en étroite collaboration. Un Cluster est donc constitué d'au moins 2 machines (physiques ou virtuelles). Les machines d'un Cluster sont appelées «nœuds» (nodes en anglais). Un nœud est donc une machine qui participe à un Cluster (qui est membre d'un Cluster). À partir de Hearbeat dans sa version 2, il est possible d'intégrer autant de nœuds que l'on veut dans le Cluster et une gestion en natif du monitoring de services est réalisée. Les clusters sont basés sur le principe des battements de coeur. Un «heartbeat» (battement de cœur, en anglais), c'est le fait qu'un nœud puisse entendre le «coeur» d'un autre nœud battre. Donc, avec le «heartbeat», un nœud peut savoir si les autres nœuds sont encore vivant ou non. Lorsque le «cœur» d'un autre nœud ne bat plus, on considère qu'il est mort. Nous installerons la version 3 du service Heartbeat (apt-get install heartbeat)à partir de laquelle, l'équipe de Linux-HA conseille de lui adjoindre un gestionnaire de Cluster tel que Pacemaker (stimulateur cardiaque) qui est d'ailleurs installé automatiquement sous Wheezy à l'installation de Heartbeat. Pacemaker est un gestionnaire de Cluster haute disponibilité. Il est chargé de créer, démarrer, arrêter et superviser les ressources du Cluster c'est à dire les services gérés en Cluster et donc inclus dans la continuité de services. Heartbeat permet donc de gérer différents services de haute disponibilité (High Availability : HA) au sein d'un Cluster. Il permet de détecter la défaillance d'un poste grâce à un système de communication basé sur un échange de paquets UDP. Dans son mode le plus simple, cette solution de clustering est basée sur le modèle actif-passif : lorsqu'un serveur considéré comme «primaire» n'est plus considéré comme accessible, Heartbeat démarre sur un serveur secondaire les services qu'on lui indique dans la configuration. Gérer un service en Cluster (un service étant une ressource au sens de Pacemaker) consiste donc, dans sa forme la plus simple (mode actif/passif), à installer le service sur tous les nœuds participants au Cluster et à n'activer ce service que sur le nœud dit maître (nœud actif). Lorsque ce nœud est défaillant, le service est activé automatiquement sur le nœud dit esclave (nœud passif qui devient actif). Le retour automatique du service (auto failback) sur le nœud maître (lorsque celui-ci est de nouveau en état) n'est pas systématique et doit être géré au niveau de la configuration de chaque ressource. Heartbeat est lancé en démon (ce qui est visible avec la commande netstat) et il se charge(via Pacemaker) d'activerl'adresse IP virtuelle sur le serveur qui joue le rôle de maître ainsi que le lancement des services (ressources au sens de Pacemaker) mis en haute disponibilité. Ces derniers, lancés par Pacemaker, doivent donc être supprimés du démarrage automatique de Linux. Par exemple, pour Apache2 : update-rc.d -f apache2 remove ou insserv -r -v apache2 Les fichiers de configuration se trouvent dans /etc/ha.d et dans /var/lib/heartbeat/crm/ (mais aucun fichier n'est créé à l'installation). C'est dans le fichier /etc/ha.d/ha.cf qu'on indique à Heartbeat qu'il «travaillera» avec Pacemaker. Pour démarrer et/ou stopper le Cluster, il suffit de démarrer et/ou stopper le démon «heartbeat». L'exemple de configuration qui suit est basé sur la configuration IP suivante : intralab : serveur maître IP réelle : > c'est celle qui est dans /etc/network/interfaces IP virtuelle : hdintralab : serveur esclave IP réelle : > c'est celle qui est dans /etc/network/interfaces IP virtuelle : CERTA - septembre 2013 v1.0 Page 9/30

10 La configuration s'articule autour des fichiers suivants qui doivent être identiques sur les deux serveurs. /etc/ha.d/ha.cf : ce fichier contient la configuration générale de Heartbeat Directives et valeurs logfacility local7 logfile /var/log/ha-log debugfile /var/log/ha-debug use_logd no udpport 694 keepalive 2 deadtime 20 initdead 50 auto_failback off node intralabar node hdintralabar ucast eth ucast eth crm yes Explications Gestion des logs : il serait plus judicieux d'utiliser un système de gestion de log avec démon (avec l'option use_logd yes) mais par mesure de simplification, nous utiliserons la méthode classique. logfacility local7 indique un fichier de log de niveau debug Port utilisé par les mécanismes de "battements de coeur" Délai entre 2 battements (en secondes) Temps nécessaire (en secondes) avant de déclarer un nœud comme mort Valeur utilisée pour le démarrage (> 2 fois le deadtime) La gestion du retour automatique d'une ou plusieurs ressources sur le nœud primaire ne sera pas gérée par Heartbeat mais par Pacemaker au cas par cas selon la manière dont nous déciderons de configurer la ressource. Liste des nœuds participants au Cluster (ne pas oublier de configurer le fichier «hosts» sur chacun des nœuds) Lien réseau utilisé pour les battements de cœur Avec «crm yes» : format de configuration des ressources qui exploite un fichier de configuration XML et la gestion du Cluster est réalisée par un Pacemaker. Avec «crm no», Heartbeat exploite un fichier de configuration /etc/ha.d/haresources comme dans sa première version mais les possibilités sont limitées. /etc/ha.d/authkeys : ce fichier détermine le niveau de sécurité des échanges entre les différents noeuds du Cluster. Lorsque ces informations passent pas le réseau, il vaut mieux crypter l'échange avec md5 sha (plus gourmand en temps processeur). Dans ce cas, il faut fournir une «passphrase». auth 1 1 sha1 PassPhrase D'autres méthodes d'authentification sont possibles Par mesure de sécurité, les droits sur ce fichier doivent être réduit à la lecture et écriture seulement à l'utilisateur root (si ce n'est pas fait, Heartbeat ne démarre pas) La configuration du Cluster est contenue dans un Cluster Information Base (CIB) qui est un fichier XML. /var/lib/heartbeat/crm/cib.xml : ce fichier est généré (au démarrage de Heartbeat) à partir des deux fichiers vus précédemment et est complété au fur des ajouts de ressources. Ce dernier fichier ne doit JAMAIS être modifié directement mais via les commandes vues ci-après. Heartbeat peut être démarré lorsqu'il est configuré sur les deux serveurs. Consultez la note en fin d'annexe 1 pour disposer d'un Cluster «neuf» si le Cluster n'est pas ou plus stable (fichier cib.xml différent, démarrage de Hearbeat avant clonage, etc.). Les commandes utiles Pour vérifier que heartbeat est lancé : /etc/init.d/heartbeat status (ou service heartbeat status ou cl_status hbstatus) Pour voir la liste des noeuds : cl_status listnodes Et l'état d un noeud : cl_status nodestatus ma-machine-esclave.mondomaine.com CERTA - septembre 2013 v1.0 Page 10/30

11 La commande crm implémentée par pacemaker (qui peut être avantageusement utilisée aussi en interactif) permet de gérer la configuration et les différentes ressources. Elle se propage sur chaque nœud automatiquement : la commande s'effectue donc sur n'importe quel nœud. Avant toute chose, un petit aperçu des commandes importantes pour vérifier l'état du Cluster : Pour vérifier le status d'heartbeat : crm status ============ Last updated: Sat Nov 24 01:09: Stack: Heartbeat Current DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee d) - partition with quorum Version: a28b7f31d7ddc bd23114f58978b 2 Nodes configured, unknown expected votes 0 Resources configured. ============ Online: [ hdintralabar intralabar ] La commande suivante permet de suivre l'évolution de la configuration en direct : crm_mon ============ Last updated: Sat Nov 24 15:23: Stack: Heartbeat Current DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee d) - partition with quorum Version: a28b7f31d7ddc bd23114f58978b 2 Nodes configured, unknown expected votes 0 Resources configured. ============ Online: [ hdintralabar intralabar ] Ces deux précédentes commandes remontent un certain nombre d informations sur l état général du Cluster (nœuds ok, hs, offline ou en standby) et sur l état des ressources (quel nœud gère quelle ressource, les éventuels problèmes rencontrés lors du lancement ou du monitoring des ressources ). Last updated et stack : la dernière mise à jour des informations du moniteur et le fournisseur (provider) utilisé : ici, Heartbeat Current DC : c est le nœud qui va coordonner les actions sur le Cluster. Les autres nœuds remonteront leurs informations au nœud DC. Ce nœud n est pas nécessairement le nœud «maître» du Cluster. Nodes & votes : le nombre de nœuds et le nombre de votes disponibles pour le quorum (voir page suivante). Resources configured : le nombre de ressources configurées dans le Cluster. Online : la liste des nœuds online. On pourra aussi trouver ici, la liste des nœuds offline ou en stand-by. Le contrôle d'un service actif (ou pas) sur un nœud peut aussi s'effectuer via les commandes usuelles ps, netstat et nmap. Pour afficher la configuration (beaucoup plus lisible que le fichier xml) : crm configure show node $id="462d81f0-07d8-4c88-af27-d4ee d" hdintralabar node $id="f21c8f9a-8d38-4e1d-a9c8-96e403cd7596" intralabar property $id="cib-bootstrap-options" \ dc-version=" a28b7f31d7ddc bd23114f58978b" \ Cluster-infrastructure="Heartbeat" \ stonith-enabled="false"\ no-quorum-policy="ignore" CERTA - septembre 2013 v1.0 Page 11/30

12 Il existe une commande qui permet de vérifier la validité du fichier de configuration XML alors généré :crm_verify -L -V. À la première exécution de cette commande (après le démarrage correct de Heartbeat), des erreurs sont remontées : crm_verify -L -V crm_verify[690]: 2012/11/24_00:31:01 ERROR: unpack_resources: Resource start-up disabled since no STONITH resources have been defined crm_verify[690]: 2012/11/24_00:31:01 ERROR: unpack_resources: Either configure some or disable STONITH with the stonith-enabled option crm_verify[690]: 2012/11/24_00:31:01 ERROR: unpack_resources: NOTE: Clusters with shared data need STONITH to ensure data integrity Errors found during check: config not valid «Stonith» (shot the other node in the head) permet de tuer proprement les nœuds qui sont morts. C'est en fait un mécanisme pour éteindre complètement le serveur qui vient de flancher en éteignant son onduleur. C'est surtout utilisé avec des disques partagés car il serait dangereux que l'ordinateur qui est supposé être hors d'état vienne écrire sur le disque partagé et corrompre/altérer les données. Par mesure de simplification, pour ce coté labo, nous allons désactiver STONITH par la commande : crm configure property stonith-enabled=false crm configure property stonith-enabled=false INFO: building help index La vérification ne renvoie plus d'erreur. Vous pouvez consulter le fichier XML généré : /var/lib/heartbeat/crm/cib.xml : <cib validate-with="pacemaker-1.0" crm_feature_set="3.0.1" have-quorum="1" dc-uuid="462d81f0-07d8-4c88-af27-d4ee d" epoch="8" num_updates="0" admin_epoch="0" cib-last-written="sat Nov 24 00:49: "> <configuration> <crm_config> <Cluster_property_set id="cib-bootstrap-options"> <nvpair id="cib-bootstrap-options-dc-version" name="dc-version" value=" a28b7f31d7ddc bd23114f58978b"/> <nvpair id="cib-bootstrap-options-cluster-infrastructure" name="cluster-infrastructure" value="heartbeat"/> <nvpair id="cib-bootstrap-options-stonith-enabled" name="stonith-enabled" value="false"/> </Cluster_property_set> </crm_config> <nodes> <node id="462d81f0-07d8-4c88-af27-d4ee d" uname="hdintralabar" type="normal"/> <node id="f21c8f9a-8d38-4e1d-a9c8-96e403cd7596" uname="intralabar" type="normal"/> </nodes> <resources/> <constraints/> </configuration> </cib> Persiste encore un petit problème à régler concernant le quorum qui est le nombre minimum de nœuds en ligne pour être capable de valider une décision. Dans le cas d un Cluster avec Pacemaker, il faut que plus de la moitié des nœuds soit en ligne. Avec un Cluster à deux nœuds, il n y a plus de quorum dès qu un nœud est perdu. Il faut donc demander à Pacemaker d ignorer le quorum dans cette situation car le fonctionnement par défaut, quand le quorum n est pas atteint, est de couper toutes les ressources. Pour désactiver le quorum, saisir la commande suivante : crm configure property no-quorumpolicy="ignore". CERTA - septembre 2013 v1.0 Page 12/30

13 Note : comment retrouver un nœud propre? Plusieurs raisons peuvent être à l'origine de l'instabilité d'un Cluster dont : la modification «à la main» du fichier de configuration XML ; si on démarre Heartbeat avant clonage sur la première machine pour tester les fichiers de configuration, il se crée un UUID associé à la machine ; lors du clonage, il maintient cet UUID pour la seconde machine. Heartbeat ne voit donc qu'un nœud et "switche" sans arrêt entre les deux (on le voit parfaitement dans les logs) ; une erreur dans la configuration qu'il est difficile d'annuler via une commande crm. Pour repartir sur une configuration de départ «propre»: arrêter le service Heartbeat sur les 2 machines ; supprimer dans /var/lib/heartbeat les fichiers hostcache et hb_uuid (sur les deux machines) ; supprimer dans /var/lib/heartbeat/crm le fichier cib.xml ; redémarrer Heartbeat. Le fichier «hostcache» contient les UUID valides (à rapprocher des UUID écrits dans le fichier de configuration). Il est aussi possible d'éditer et de modifier le fichier de configuration via la commande crm configure edit. CERTA - septembre 2013 v1.0 Page 13/30

14 Annexe 2 : création et configuration des ressources Après avoir installé les services sur chaque nœud du Cluster, il est nécessaire de configurer le comportement de ceux que l'on désire mettre en haute disponibilité. Rappel : un service est une ressource au sens de Pacemaker. La commande crm qui va permettre de configurer les ressources dans le Cluster est implémentée par Pacemaker ; quelque soit le nœud sur laquelle la commande est exécutée, la configuration se propage sur chaque nœud automatiquement en modifiant le fichier cib.xml Pour vérifier votre configuration, utilisez les commandes vues dans l'annexe 1 «crm status», «crm_mon» et «crm configure show» ainsi que celles permettant de contrôler si un service est actif ou non (ps, netstat et nmap). Comment créer une ressource? La création d une ressource s effectue avec une entrée nommée «primitive» dans la CIB (voir annexe 1). On trouvera au minimum dans la commande : crm configure primitive <nom de la ressource> <espace de nom:nom du script>. Par exemple : crm configure primitive serviceweb ocf:heartbeat:apache2 crm configure primitive serviceweb lsb:apache Cette «primitive» fait appel à un script d application correspondant au service à mettre en haute disponibilité. Le script du service peut être : De type OCF (http://linux-ha.org/wiki/ocf_resource_agent) qui est un script développé pour Pacemaker : ils sont, pour la plupart, dans le répertoire /usr/lib/ocf/resource.d/heartbeat/ ou /usr/lib/ocf/resource.d/pacemaker ; la liste des scripts est obtenue avec les commandes crm ra list ocf heartbeat et crm ra list ocf pacemaker. Dans la commande l'espace de nom est dans de cas ocf:heartbeat ou ocf:pacemaker. De type LSB : c'est un script de démarrage sur Linux présent dans /etc/init.d ; pour qu'il puisse être utilisé avec Pacemaker, ce script doit être conforme à la spécification LSB : Le type lsb:service utilise au minimum les capacités start, stop, status des scripts de démarrage système de /etc/init.d. Pour en vérifier la compatibilité minimum, les scripts doivent répondre à une commande start, stop et status. Le lien aide à la vérification de la compatibilité totale. Dans la mesure du possible, il est conseillé d'utiliser les scripts OCF ou d'écrire (s'il n'existe pas) un script OCF basé sur le script d'initialisation existant. D'autant plus que pour certains services, les scripts OCF offrent des finesses supplémentaires de configuration. On indique ensuite éventuellement (dans la commande crm configure primitive) des paramètres propres à la ressource et des options de monitoring (voir plus loin les configurations spécifiques). La configuration passe donc par la commande crm que l'on peut utiliser directement en ligne de commande (voir notamment «configuration du failover IP») ou en interactif (voir notamment «configuration de la ressource «serviceweb»). Cette commande se propage sur tous les nœuds (ce qui est très pratique) et modifie bien évidemment le fichier XML sur chaque noeud. Attention, il est très dangereux de modifier ce fichier à la main (surtout quand Hearbeat est lancé) ; il faut utiliser à la place la commande crm configure edit. Si, en dernier recours, vous devez passer par la modification du fichier à la main, il est nécessaire de sauvegarder le fichier, arrêter le service «heartbeat» et opérer la même modification sur les deux nœuds. Note : vous trouverez en annexe 4 un récapitulatif des commandes utiles (y compris certaines que nous ne verrons pas explicitement dans ce Côté labo mais qui peuvent s'avérer utiles). CERTA - septembre 2013 v1.0 Page 14/30

15 Configuration du failover d'ip Le failover d'ip (en anglais, fail-over se traduit par «passer outre la panne») est le basculement de l'adresse IP (virtuelle) du serveur maître vers le serveur esclave si le premier venait à défaillir. Première étape : attribution de l'adresse IP virtuelle À minima, on crée une ressource nommée «IPFailover» (le nom est libre) qui va créer une adresse IP virtuelle /16 (d'autres options sont disponibles) crm configure primitive IPFailover ocf:heartbeat:ipaddr2 params ip=" " cidr_netmask=" " nic="eth0" iflabel="vip" Primitive : argument pour ajouter une primitive regroupant plusieurs valeurs indiquant au Cluster quels scripts utiliser pour la ressource, où le trouver et à quel standard il correspond. Ocf : classe de la ressource (ça pourrait donc aussi être lsb) Hearbeat : fournisseur de la ressource IPaddr2 : ressource gérant les adresses IPv4 virtuelles ==> le script appelé Params : déclaration des paramètres nécessaires à la ressource IPFaillover : le nom de la ressource (il est évidemment libre... mais doit être suffisamment «parlant») IPaddr2 : le script appelé params : suivent les différents paramètres à appliquer ip= « » : nom et valeurs du paramètre «ip» cidr_netmask= « » : masque de sous-réseau nic= «eth0» : carte réseau sur laquelle est appliquée l'adresse IP virtuelle iflabel= «VIP» permet de donner un label à la carte réseau virtuelle. Sans ce label, la VIP n est pas visible avec la commande ifconfig mais seulement avec la commande ip addr show. Remarques : pour connaître tous les paramètres de la primitive IPaddr2 (ainsi que ses options par défaut comme tout ce qui concerne le monitoring de la ressource) : crm ra info ocf:heartbeat:ipaddr2 ; pour visualiser en direct l évolution de la configuration, il est intéressant de réaliser la commande sur un nœud et de laisser tourner un «crm_mon» sur l autre (attendre un peu que la propagation soit effective) ; en cas d'erreur de syntaxe dans la commande, le système peut demander s'il va quand même enregistrer en terminant son retour d'erreur par «Do you still want to commit?» : il faut évidemment répondre par «n» ; chaque script de la classe ocf permet la supervision de la ressource via l'option monitor (voir ci-après) et/ou la promotion d une ressource dans le cadre d un Cluster actif/actif (comme nous allons le voir dans le Coté labo suivant). Avec crm_mon ou crm status, on peut constater qu'une ressource est configurée : ============ Last updated: Sat Jul 27 01:39: Last change: Fri Jul 26 15:48: via crm_attribute on intralabar Stack: Heartbeat Current DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee d) - partition with quorum Version: ee0730e13d124c3d58f00016c3376a1de5323cff 2 Nodes configured, unknown expected votes 1 Resources configured. ============ Online: [ hdintralabar intralabar ] IPFailover (ocf::heartbeat:ipaddr2): Started hdintralabar Et nous pouvons constater aussi que l'adresse virtuelle démarrera sur l'un ou l'autre nœud de manière aléatoire (ici Started hdintralabar). CERTA - septembre 2013 v1.0 Page 15/30

16 Pour vérifier l'adresse IP attribuée on utilise la commande «ip addr show» (attention, pas ifconfig si le paramètre iflabel n'a pas été défini) : ip addr show 1: lo:... 2:... 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 7e:e9:2e:18:13:b7 brd ff:ff:ff:ff:ff:ff inet /16 brd scope global eth0 inet /16 brd scope global eth0:vip inet6 fe80::7ce9:2eff:fe18:13b7/64 scope link valid_lft forever preferred_lft forever 4: eth1:... Si le paramètre «iflabel» a été défini : ifconfig eth0 Link encap:ethernet HWaddr 7e:e9:2e:18:13:b7 inet adr: Bcast: Masque: adr inet6: fe80::7ce9:2eff:fe18:13b7/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets: errors:0 dropped:0 overruns:0 frame:0 TX packets: errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes: (23.3 MiB) TX bytes: (33.2 MiB) eth0:vip Link encap:ethernet HWaddr 7e:e9:2e:18:13:b7 inet adr: Bcast: Masque: UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Pour éditer/modifier une ressource : crm configure edit <id_ressource> ; cela vous placera dans une instance de «vim» pour effectuer une modification. À la sauvegarde, la modification est directement appliquée. Par exemple, si l'on veut ajouter à la ressource configurée précédemment des options de monitoring : crm configure edit IPFailover : primitive IPFailover ocf:heartbeat:ipaddr2 \ params ip=" " cidr_netmask=" " nic="eth0" op monitor interval="30s" timeout="20s" «op» définit des options et «monitor» est l'action de monitoring du pacemaker : toutes les 30 secondes, Pacemaker va appeler le script OCF avec comme paramètre monitor. Avant le timeout de 20 secondes, on devra avoir un code retour à 0 pour que Pacemaker considère la ressource comme fonctionnelle. Sinon, il arrêtera/relancera la ressource ou effectuera une bascule (selon le paramétrage des autres options). Remarque : Pour éditer/modifier l'ensemble d'une configuration : crm configure edit. CERTA - septembre 2013 v1.0 Page 16/30

17 Deuxième étape : définir une préférence de nœud primaire pour l'adresse virtuelle Il s'agit en fait de définir une contrainte «locative» qui va définir une préférence d une ressource sur un nœud : le plus simple est, en fait, de laisser Pacemaker «écrire» lui même cette contrainte. On migre la ressource sur le nœud que l'on veut et Pacemaker comprend qu'on a une préférence pour ce nœud : crm resource move IPFailover intralabar Et on constate : crm configure show... À partir de ce moment là, dès que le location cli-prefer-ipfailover IPFailover \ nœud intralabar est actif, la ressource rule $id="cli-prefer-rule-ipfailover" inf: #uname eq intralabar migrera vers ce nœud (auto failback).... Cette situation n'est peut-être pas la situation idéale car il est souvent préférable de revenir à un nœud de manière manuelle après avoir vérifié que toutes les conditions favorables sont réunies et qu'il n'y aura pas de perte de données. Dans ce cas, il faut utiliser le paramètre «resource-stickiness» qui empêche la ressource de retourner sur la machine élue par défaut après que celle-ci est défaillit et soit revenue en ligne. La ressource devra être migrée manuellement. Et dans certains cas, on ne privilégie aucun serveur par rapport à d'autres (par exemple, quand les machines maître et esclave sont strictement identiques, notamment en terme de capacités). Test du failover d'ip Plusieurs possibilités pour tester la solution mise en place dont : arrêter le serveur ou le service ; mettre un nœud en maintenance : crm node standby sur le nœud que l'on veut rendre inactif (crm node online pour le remettre actif). Par exemple cette commande sur le nœud «intralabar» a pour effet de faire basculer l'adresse IP virtuelle sur le nœud hdintralabar : ============ Last updated: Sat Jul 27 01:39: Last change: Fri Jul 26 15:48: via crm_attribute on intralabar Stack: Heartbeat Current DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee d) - partition with quorum Version: ee0730e13d124c3d58f00016c3376a1de5323cff 2 Nodes configured, unknown expected votes 1 Resources configured. ============ Node intralabar (f21c8f9a-8d38-4e1d-a9c8-96e403cd7596): standby Online: [ hdintralabar ] IPFailover (ocf::heartbeat:ipaddr2): Started hdintralabar Un crm node online doit permettre de récupérer l'adresse IP sur intralab car nous avons défini la préférence ainsi : ============ Last updated: Sat Jul 27 01:39: Last change: Fri Jul 26 15:48: via crm_attribute on intralabar Stack: Heartbeat Current DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee d) - partition with quorum Version: ee0730e13d124c3d58f00016c3376a1de5323cff 2 Nodes configured, unknown expected votes 1 Resources configured. ============ Online: [ hdintralabar intralabar ] IPFailover (ocf::heartbeat:ipaddr2): Started intralabar CERTA - septembre 2013 v1.0 Page 17/30

18 Rappel : en production, il est parfois préférable de maîtriser le retour au serveur maître. Configuration de la ressource «serviceweb» Nous allons configurer cette ressource en «interactif» car cela procure plusieurs avantages dont : l'utilisation de la touche tabulation qui peut aider à trouver la «bonne» commande ou le «bon» argument (la double tabulation listera les possibilités) ; l'utilisation de la commande help qui liste les commande possibles ; la possibilité de configurer plusieurs ressources avec leurs propriétés avant de valider le tout. crm configure crm(live)configure# primitive serviceweb ocf:heartbeat:apache params configfile="/etc/apache2/apache2.conf" op monitor interval="60s op start timeout="40s" op stop timeout="40s" crm(live)configure# commit crm(live)configure# quit On crée une ressource nommée «serviceweb» avec comme paramètre le chemin du fichier de configuration d'apache2. Remarque :«configfile» a, pour paramètre par défaut /etc/apache2/http.conf (on peut le constater avec la commande : crm ra info ocf:heartbeat:apache), ce qui n'est pas valable dans notre configuration => il faut donc lui préciser ce paramètre. Les autres paramètres par défaut sont corrects. Chaque option (en règle générale, chaque action à effectuer) est ensuite précédée du mot clé «op». On crée un moniteur pour cette ressource avec un test de la «vie» de la ressource toutes les 60 secondes (op monitor interval="60s") et on spécifie en plus un timeout de démarrage de 40 secondes ("op start timeout="40s") et un timeout d'arrêt de 40 secondes ("op stop timeout="40s"). On valide la ressource par «commit» et on sort de la commande interactive par «quit» ou «exit» N'hésitez pas à utiliser la tabulation et double tabulation... Remarque : avant de valider la ressource, on peut la consulter : crm(live)configure# show... primitive serviceweb ocf:heartbeat:apache \ params configfile="/etc/apache2/apache2.conf" \ op start interval="0" timeout="40s" \ op stop interval="0" timeout="40s" \ op monitor interval="60s"... À la validation, un «Warning» peut apparaître : WARNING: serviceweb: specified timeout 40s for stop is smaller than the advised 60s Vous pouvez l'ignorer ou... en tenir compte. Les développeurs ont estimé qu'un délai de 60s pour arrêter ce service était raisonnable. Si vous pensez qu'effectivement, l'arrêt du service Web prendra plus de 40 secondes, il vaut mieux augmenter le délai. Sur la console crm_mon, il apparaît bien la nouvelle ressource : ============ Last updated: Sat Jul 27 01:45: Last change: Fri Jul 26 15:48: via crm_attribute on intralabar Stack: Heartbeat Current DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee d) - partition with quorum Version: ee0730e13d124c3d58f00016c3376a1de5323cff 2 Nodes configured, unknown expected votes 2 Resources configured. ============ Online: [ hdintralabar intralabar ] CERTA - septembre 2013 v1.0 Page 18/30

19 IPFailover (ocf::heartbeat:ipaddr2): Started intralabar intralab (lsb:intralab): Started hdintralabar Mais, comme on peut le voir, la ressource serviceweb n'est pas démarré sur le même nœud que celle concernant l'ip virtuelle. Par défaut Pacemaker répartit les ressources entre les membres du Cluster. Pour que l'adresse IP virtuelle et le service «serviceweb» soient sur le même nœud, il existe plusieurs possibilités comme le groupement des ressources (solution la plus simple) : crm configure crm(live)configure# group servintralab IPFailover serviceweb meta migration-threshold="5" crm(live)configure# commit crm(live)configure# quit On crée un groupe nommé «servintralab» composé des ressources «IPFailover» et «serviceweb» qui seront toujours démarrées dans l'ordre des entrées du groupe (arrêtées en sens inverse). On spécifie aussi le nombre d'incidents tolérés avant de migrer la ressource définitivement vers un autre noeud ("meta migration-treshold=5"). Ainsi, au bout de cinq incidents, le groupe de ressources sera définitivement migré vers un autre nœud mais si une ressource échoue au démarrage, l'ensemble des ressources du groupe sera démarré sur un autre nœud. ==> La ressource «serviceweb» migre immédiatement sur le même nœud que celui de «IPFailover». Nous étudierons, dans le prochain Coté labo, d'autres possibilités de configuration plus compliquées mais permettant des paramétrages plus fins. Test de la solution Plusieurs possibilités pour tester la solution mise en place dont : arrêtez le serveur ou le service (utile pour tester la migration des autres ressources) ; mettre un nœud en maintenance : crm node standby sur le nœud que l'on veut rendre inactif (crm node online pour le remettre actif). Si le service est arrêté, pacemaker a été configuré pour essayer de le redémarrer dans un premier temps : c'est le premier point à tester. Ensuite, pour tester un arrêt définitif du service de manière à ce que l'ensemble des ressources migrent sur l'autre nœud, il faut s'arranger pour que le service ne puisse pas redémarrer... Quand le Cluster bascule sur l autre nœud suite à un certain nombre d'erreurs sur une ressource, le nœud qui a rencontré les erreurs ne pourra plus héberger les ressources tant que toutes les erreurs n'auront pas été effacées par la commande suivante : crm resource cleanup <id_resource> CERTA - septembre 2013 v1.0 Page 19/30

20 Annexe 3 : principes de la réplication sur MySQL Comment ça marche? La réplication MySQL est basée sur le fichier log binaire du serveur maître qui garde une trace de toutes les requêtes SQL (update, delete, etc.) et un fichier d'index des modifications à prendre en compte. L'esclave, au moment de la connexion, informe le maître où il s'est arrêté, rattrape les modifications qui ont eu lieu depuis (lecture du fichier log binaire du serveur maître pour qu'il puisse exécuter les requêtes SQL stockées dans ce fichier), puis se bloque en attente des prochaines modifications. Le fichier de log binaire (ou binlogs) est simplement un enregistrement des modifications depuis un point fixe dans le temps (le moment où vous activez le log binaire). Tous les esclaves qui seront activés auront besoin de la copie des données qui existaient au moment du démarrage du log. Ainsi, si l'on désire mettre une réplication en place, alors que la base de données, concernée par la réplication, du maître est déjà fournie en données, il faut tout d'abord effectuer une copie complète de celle-ci avant de commencer la réplication. Ensuite, l'esclave va simplement se connecter au maître et attendre des requêtes de modifications. Il lira le fichier journal binaire du maître, en copiera les requêtes dans un fichier tampon, ou fichier «relais» (relay) en terminologie MySQL, et il les «jouera» sur son serveur. Si le maître est indisponible ou que l'esclave perd la connexion avec le maître, il va essayer de se reconnecter selon une période fixée en secondes par le paramètre «master-retry-count» jusqu'à ce qu'il soit capable d'établir la communication, et de recommencer à appliquer les modifications. Chaque esclave garde la trace du point où il en était rendu. Le serveur maître n'a pas de notions du nombre d'esclaves qui se connectent, ou qui sont à jour à un moment donné. Remarque : un esclave peut aussi servir de maître à son tour pour réaliser une chaîne de réplication. Étapes avant modification des fichiers de configuration Installation des services de bases de données sur les serveurs ; Réplication de bases de données entre plusieurs serveurs qui présuppose l'existence d'un utilisateur MySQL ayant des droits suffisants sur chaque serveur maître ; le serveur esclave doit pouvoir se connecter au maître avec cet utilisateur de manière à ce qu'il puisse consulter l état du log binaire et répliquer les données si des modifications ont été apportées ; pour cela : le droit spécial «REPLICATION SLAVE» suffit ; lui attribuer aussi les droits de connexion depuis tous les esclaves. 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 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;». Configuration de la réplication via le fichier /etc/mysql/my.cnf sur chaque serveur : la réplication de bases de donnés 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. CERTA - septembre 2013 v1.0 Page 20/30

TARDITI Richard Mise en place d une Haute Disponibilité

TARDITI Richard Mise en place d une Haute Disponibilité TARDITI Richard Mise en place d une Haute Disponibilité Dans le cadre du projet GSB j ai mis en place un cluster de deux machines virtuelles Apache sous Linux, avec une haute disponibilité produite grâce

Plus en détail

SERVEUR WEB HAUTE DISPONIBILITÉ

SERVEUR WEB HAUTE DISPONIBILITÉ SERVEUR WEB HAUTE DISPONIBILITÉ Page 1 Table des matières I. Sujet... 3 II. Caractéristiques du projet... 2 A. Contexte... 2 B. Configuration... 2 C. Étapes et gestion du projet et travail en groupe...

Plus en détail

Haute disponibilité avec Heartbeat

Haute disponibilité avec Heartbeat Haute disponibilité avec Heartbeat Consignes : Ce TP peut être réalisé seul ou en binôme à l aide de machines virtuelles Debian GNU/Linux. Un serveur DNS opérationnel est recommandé pour finaliser le TP.

Plus en détail

GOUTEYRON ALEXIS. SIO2 N candidat: 0110692972. UEpreuve E4. USituation professionnelle 2. serveurs de fichiers. Uen haute disponibilité

GOUTEYRON ALEXIS. SIO2 N candidat: 0110692972. UEpreuve E4. USituation professionnelle 2. serveurs de fichiers. Uen haute disponibilité GOUTEYRON ALEXIS SIO2 N candidat: 0110692972 UEpreuve E4 USituation professionnelle 2 serveurs de fichiers Uen haute disponibilité Session 2014 2015 I- Présentation a) Utilité Aujourd hui, dans le monde

Plus en détail

Heartbeat - cluster de haute disponibilité

Heartbeat - cluster de haute disponibilité Page 1 sur 7 L'idée générale pour assurer la disponibilité d'un service est de faire fonctionner plusieurs machines (deux au minimum) en même temps. Ces machines forment ce qu'on appelle un cluster et

Plus en détail

PPE 4.2: Tolérance aux pannes et répartition de charge (Haproxy et Heartbeat)

PPE 4.2: Tolérance aux pannes et répartition de charge (Haproxy et Heartbeat) PPE 4.2: Tolérance aux pannes et répartition de charge (Haproxy et Heartbeat) La demande Dans le contexte STE Puzzle (1), il est primordial de bénéficier d une solution de haute disponibilité pour les

Plus en détail

Redondance de service

Redondance de service BTS S.I.O. 2 nd Année Option SISR TP 15 Redondance de service 1 Objectifs Mettre en œuvre différentes techniques de haute disponibilité de services et de serveurs. 2 Présentation du déroulement Ce TP se

Plus en détail

La haute disponibilité dans la vraie vie

La haute disponibilité dans la vraie vie La haute disponibilité dans la vraie vie Arnaud Gomes-do-Vale Le 2 août 2010 Arnaud Gomes-do-Vale () La haute disponibilité dans la vraie vie Le 2 août 2010 1 / 37 Sommaire 1 Généralités 2 Problématique

Plus en détail

Service WEB, BDD MySQL, PHP et réplication Heartbeat. Conditions requises : Dans ce TP, il est nécessaire d'avoir une machine Debian sous ProxMox

Service WEB, BDD MySQL, PHP et réplication Heartbeat. Conditions requises : Dans ce TP, il est nécessaire d'avoir une machine Debian sous ProxMox Version utilisée pour la Debian : 7.7 Conditions requises : Dans ce TP, il est nécessaire d'avoir une machine Debian sous ProxMox Caractéristiques de bases : Un service web (ou service de la toile) est

Plus en détail

Agenda. Bienvenue. Agenda

Agenda. Bienvenue. Agenda Bienvenue Présentateur : Armel Kermorvant armelk@fedoraprojectorg Fonction FedoraProject : Ambassadeur / Mentor Fonction Fedora-frorg : Vice-Président chkconfig Portable off Haute Disponibilité Fonctionnement

Plus en détail

Configuration matériel. Tâche 2 : Installation proprement dite de l application sur un serveur de test virtualisé sous VmWare Workstation.

Configuration matériel. Tâche 2 : Installation proprement dite de l application sur un serveur de test virtualisé sous VmWare Workstation. PPE 1 MISSION 1 Tâche 1 : Se renseigner sur les exigences logicielles et matérielles de l utilisation de MRBS sur une distribution Linux (Debian). Proposer une configuration matérielle suffisante pour

Plus en détail

BTS SIO SISR3 TP 1-I Le service Web [1] Le service Web [1]

BTS SIO SISR3 TP 1-I Le service Web [1] Le service Web [1] SISR3 TP 1-I Le service Web [1] Objectifs Comprendre la configuration d'un service Web Définir les principaux paramètres d'exécution du serveur Gérer les accès aux pages distribuées Mettre à disposition

Plus en détail

Configuration réseau Basique

Configuration réseau Basique Configuration réseau Basique 1. Configuration réseau bas niveau Les outils de configuration réseau bas niveau traditionnels des systèmes GNU/Linux sont les programmes ifconfig et route qui viennent dans

Plus en détail

Mise en réseau d'une station Linux

Mise en réseau d'une station Linux Stéphane Gill Stephane.Gill@CollegeAhuntsic.qc.ca Table des matières Introduction 2 Fichiers de paramétrage et scripts 2 /etc/hosts 2 /etc/networks 3 /etc/hosts.conf 3 /etc/resolv.conf 4 /etc/sysconfig/network

Plus en détail

COURS SUR L ADRESSAGE IP

COURS SUR L ADRESSAGE IP COURS SUR L ADRESSAGE IP FORMATEUR : NOUTAIS JEAN-MARC PLAN DU COURS I. GENERALITES II. STRUCTURE D UNE ADRESSE IP III. LES DIFFERENTES CLASSES DE RESEAUX IV. LES ADRESSES RESERVEES a) L adresse de réseau

Plus en détail

Solution Haute Disponibilité pour Linux

Solution Haute Disponibilité pour Linux Solution Haute Disponibilité pour Linux Nicolas Schmitz Ecole Centrale de Nantes Nicolas.Schmitz@ec-nantes.fr Introduction La haute disponibilité c'est notamment : Doubler au maximum le matériel Mettre

Plus en détail

Principes de DHCP. Le mécanisme de délivrance d'une adresse IP à un client DHCP s'effectue en 4 étapes : COMMUTATEUR 1. DHCP DISCOVER 2.

Principes de DHCP. Le mécanisme de délivrance d'une adresse IP à un client DHCP s'effectue en 4 étapes : COMMUTATEUR 1. DHCP DISCOVER 2. DHCP ET TOPOLOGIES Principes de DHCP Présentation du protocole Sur un réseau TCP/IP, DHCP (Dynamic Host Configuration Protocol) permet d'attribuer automatiquement une adresse IP aux éléments qui en font

Plus en détail

Les modules SI5 et PPE2

Les modules SI5 et PPE2 Les modules SI5 et PPE2 Description de la ressource Propriétés Intitulé long Formation concernée Matière Présentation Les modules SI5 et PPE2 BTS SIO SI5 PPE2 Description Ce document présente une approche

Plus en détail

SISR3- Mise à disposition d une application web sécurisée

SISR3- Mise à disposition d une application web sécurisée Contexte : Le laboratoire pharmaceutique Galaxy-Swiss Bourdin (GSB) désire mettre à disposition des visiteurs médicaux une application Web de gestion des frais de remboursement. Il souhaite disposer d'une

Plus en détail

OpenMediaVault installation

OpenMediaVault installation OpenMediaVault installation 2013-01-13/YM: version initiale 1 Introduction L'installation de OpenMediaVault, basé sur Debian, présente quelques difficultés pour l'utilisateur de Windows. Cette procédure

Plus en détail

PPE. Haute disponibilité Étude des solutions de clustering. cluster actif/passif Évolution en actif/actif avec équilibrage de charges

PPE. Haute disponibilité Étude des solutions de clustering. cluster actif/passif Évolution en actif/actif avec équilibrage de charges PPE Haute disponibilité Étude des solutions de clustering cluster actif/passif Évolution en actif/actif avec équilibrage de charges Présentation des solutions et documentation technique Ce document traite

Plus en détail

Architectures haute disponibilité avec MySQL. Olivier Olivier DASINI DASINI - - http://dasini.net/blog

Architectures haute disponibilité avec MySQL. Olivier Olivier DASINI DASINI - - http://dasini.net/blog Architectures haute disponibilité avec MySQL Architectures Architectures haute disponibilité haute disponibilité avec MySQL avec MySQL Olivier Olivier DASINI DASINI - - http://dasini.net/blog Forum PHP

Plus en détail

Installation d'un cluster ejabberd

Installation d'un cluster ejabberd Installation d'un cluster ejabberd Sommaire 1. Avant-propos 2. Configuration DNS 3. Installation 1. Installation sur le premier noeud 2. Configuration du noeud 1. Configuration de base 2. Configuration

Plus en détail

Synchronisation Mysql (Replication)

Synchronisation Mysql (Replication) Synchronisation Mysql (Replication) [Petit avertissement : Bon, après relecture, je constate que c'est l'un des plus mauvais document que j'ai écrit. Mais bon, il est quand même utile ce torchon.] Nous

Plus en détail

Activité - Serveur sous Linux Suse

Activité - Serveur sous Linux Suse Activité - Serveur sous Linux Suse Configuration de services réseaux Problématique : Configurer les services réseaux (DHCP, SAMBA, APACHE2) sur un serveur afin de répondre au besoin des postes clients

Plus en détail

WEBMESTRE : CONCEPTION DE SITES ET ADMINISTRATION DE SERVEURS WEB

WEBMESTRE : CONCEPTION DE SITES ET ADMINISTRATION DE SERVEURS WEB WEBMESTRE : CONCEPTION DE SITES ET ADMINISTRATION DE SERVEURS WEB Installation et administration d un serveur web Module 25793 TP A5 (1/2 valeur) Chapitre 7 Serveurs virtuels basés sur IP ou sur port Le

Plus en détail

La continuité de service

La continuité de service La continuité de service I INTRODUCTION Si la performance est un élément important de satisfaction de l'utilisateur de réseau, la permanence de la disponibilité des ressources l'est encore davantage. Ici

Plus en détail

SISR3 : Cluster de basculement de serveurs de fichiers

SISR3 : Cluster de basculement de serveurs de fichiers SISR3 : Cluster de basculement de serveurs de fichiers Objectif : Mettre en place un cluster de basculement de deux serveurs de fichiers. Il est nécessaire pour ce TP de disposer d'un Active Directory,

Plus en détail

Installation d'un miroir local sur Debian Squeeze

Installation d'un miroir local sur Debian Squeeze Installation d'un miroir local sur Debian Squeeze INTRODUCTION... 1 1. CONFIGURATION DU SERVEUR... 2 A.CONFIGURATION DE «APT-MIRROR»... 3 B.CONFIGURATION DE «APACHE2»... 4 2. CONFIGURATION DU CLIENT...

Plus en détail

Préparation à l installation d Active Directory

Préparation à l installation d Active Directory Laboratoire 03 Étape 1 : Installation d Active Directory et du service DNS Noter que vous ne pourrez pas réaliser ce laboratoire sans avoir fait le précédent laboratoire. Avant de commencer, le professeur

Plus en détail

Contexte InfoRéseau50. Charles SAINT-LÔ SIO2 Lycée Notre Dame de la Providence Année 2014-2015

Contexte InfoRéseau50. Charles SAINT-LÔ SIO2 Lycée Notre Dame de la Providence Année 2014-2015 Contexte InfoRéseau50 Charles SAINT-LÔ SIO2 Lycée Notre Dame de la Providence Année 2014-2015 1 Présentation du contexte : Je travaille chez InfoRéseau50, qui est une société spécialisée dans la gestion

Plus en détail

Cluster High Availability. Holger Hennig, HA-Cluster Specialist

Cluster High Availability. Holger Hennig, HA-Cluster Specialist Cluster High Availability Holger Hennig, HA-Cluster Specialist TABLE DES MATIÈRES 1. RÉSUMÉ...3 2. INTRODUCTION...4 2.1 GÉNÉRALITÉS...4 2.2 LE CONCEPT DES CLUSTERS HA...4 2.3 AVANTAGES D UNE SOLUTION DE

Plus en détail

HAPROXY 1- CREATION DES DEUX SERVEUR WEB

HAPROXY 1- CREATION DES DEUX SERVEUR WEB HAPROXY 1- CREATION DES DEUX SERVEUR WEB Tout d abord je me connecte à VM Ware afin d utiliser la machine virtuelle Linux qui faisant office de serveur web et ayant pour adresse IP : 192.168.3.10 Sur cette

Plus en détail

Network Shutdown Module V3 Extension du Manuel Utilisateur pour architecture Virtualisée VMWare ESX Server 3, 3.5

Network Shutdown Module V3 Extension du Manuel Utilisateur pour architecture Virtualisée VMWare ESX Server 3, 3.5 Network Shutdown Module V3 Extension du Manuel Utilisateur pour architecture Virtualisée VMWare ESX Server 3, 3.5 Machine virtuelle Machine virtuelle Machine virtuelle VMware ESX Network Shutdown Module

Plus en détail

Firewall et Nat. Démarrez ces machines et vérifiez leur fonctionnement. Faites attention à l'ordre de démarrage.

Firewall et Nat. Démarrez ces machines et vérifiez leur fonctionnement. Faites attention à l'ordre de démarrage. BTS S.I.O. 2 nd Année Option SISR Firewall et Nat TP 10 Firewall & Nat Notes : remplacer unserveur.sio.lms.local par le nom d'un serveur sur le réseau sio. Trouver les adresses du cœurs de réseau du lycée

Plus en détail

Serveur Linux : Haproxy

Serveur Linux : Haproxy Mise en place d un service haproxy sous Linux Bouron Dimitri 09/11/2013 Ce document sert de démonstration concise pour l installation, la configuration, d un serveur haproxy sous Linux. Table des matières

Plus en détail

Date : 28/03/12 tp.reseau.linux.dhcp.dns Durée : 1h

Date : 28/03/12 tp.reseau.linux.dhcp.dns Durée : 1h L'objectif de ce tp est d'apprendre à mettre en place un serveur DHCP sous Linux. Nous verrons dans une deuxième partie la mise en place d'un serveur dns sous Packet Tracer. Exercice 1 Tout d'abord, un

Plus en détail

Mission HAUTDISPO-WEB

Mission HAUTDISPO-WEB Mission HAUTDISPO-WEB Intitulé Propriétés Présentation Rapide Durée estimée en heures Savoir-faire SI mobilisés en priorité Documents joints Modalités de réception Serveur Web hautement disponible Description

Plus en détail

FreeNAS 0.7.1 Shere. Par THOREZ Nicolas

FreeNAS 0.7.1 Shere. Par THOREZ Nicolas FreeNAS 0.7.1 Shere Par THOREZ Nicolas I Introduction FreeNAS est un OS basé sur FreeBSD et destiné à mettre en œuvre un NAS, système de partage de stockage. Pour faire simple, un NAS est une zone de stockage

Plus en détail

LANDPARK NETWORK IP LANDPARK NETWORK IP VOUS PERMET D'INVENTORIER FACILEMENT VOS POSTES EN RÉSEAU

LANDPARK NETWORK IP LANDPARK NETWORK IP VOUS PERMET D'INVENTORIER FACILEMENT VOS POSTES EN RÉSEAU LANDPARK NETWORK IP Avril 2014 LANDPARK NETWORK IP VOUS PERMET D'INVENTORIER FACILEMENT VOS POSTES EN RÉSEAU Landpark NetworkIP est composé de trois modules : Un module Serveur, que l'on installe sur n'importe

Plus en détail

La sécurité. Chapitre 6. 1. Introduction. 2. La sécurité des accès

La sécurité. Chapitre 6. 1. Introduction. 2. La sécurité des accès 259 Chapitre 6 La sécurité 1. Introduction La sécurité La sécurité des données est un enjeu capital. Une base de données peut être amenée à stocker des données très sensibles, confidentielles. L'implémentation

Plus en détail

2010 Ing. Punzenberger COPA-DATA GmbH. Tous droits réservés.

2010 Ing. Punzenberger COPA-DATA GmbH. Tous droits réservés. 2010 Ing. Punzenberger COPA-DATA GmbH Tous droits réservés. La distribution et/ou reproduction de ce document ou partie de ce document sous n'importe quelle forme n'est autorisée qu'avec la permission

Plus en détail

Linux Solutions de Haute Disponibilité (2ième édition)

Linux Solutions de Haute Disponibilité (2ième édition) Introduction 1. Introduction 19 2. Remerciements 22 Disponibilité du stockage 1. Introduction au SAN 23 1.1 Mutualiser le stockage 23 1.2 Avantages 24 1.3 Protocoles 25 1.4 Infrastructure 26 1.5 Accès

Plus en détail

La Haute disponibilité des modules EOLE

La Haute disponibilité des modules EOLE La Haute disponibilité des modules EOLE EOLE 2.3 révisé : Janvier 2014 Documentation sous licence Creative Commons by-nc-sa - EOLE (http ://eole.orion.education.fr) V e r s i o n d u d o c u m e n t r

Plus en détail

WINDOWS 2003 CLUSTER, MISE EN OEUVRE

WINDOWS 2003 CLUSTER, MISE EN OEUVRE Windows - Systèmes WINDOWS 2003 CLUSTER, MISE EN OEUVRE Réf: WCL Durée : 3 jours (7 heures) OBJECTIFS DE LA FORMATION Ce cours permet de découvrir puis de maîtriser les techniques de cluster disponibles

Plus en détail

et Groupe Eyrolles, 2006, ISBN : 2-212-11747-7

et Groupe Eyrolles, 2006, ISBN : 2-212-11747-7 Tsoft et Groupe Eyrolles, 2006, ISBN : 2-212-11747-7 OEM Console Java OEM Console HTTP OEM Database Control Oracle Net Manager 6 Module 6 : Oracle Enterprise Manager Objectifs Contenu A la fin de ce module,

Plus en détail

Desktop Manager 2.8 Guide de mise à jour. Janvier 2014

Desktop Manager 2.8 Guide de mise à jour. Janvier 2014 Desktop Manager 2.8 Guide de mise à jour Janvier 2014 Ce document d'aide présente une méthodologie pour migrer d'une ancienne version de Desktop Manager vers la nouvelle version 2.8. Elle comporte deux

Plus en détail

SUPERVISION. Centreon 5.9

SUPERVISION. Centreon 5.9 SUPERVISION Centreon 5.9 Steven DELAPRUNE BTS SIO 11/03/2015 Sommaire CAHIER DES CHARGES... 3 INTRODUCTION... 3 PRINCIPES GENERAUX... 3 Définition... 3 Problématique... 3 Description du besoin... 3 Solution...

Plus en détail

Installation et configuration d un serveur Web Sauvegarde et restauration

Installation et configuration d un serveur Web Sauvegarde et restauration Installation et configuration d un serveur Web Sauvegarde et restauration Serveur Web Page 1 Sommaire Présentation 3 Configuration d une machine virtuelle 3 Création d une machine virtuelle 3 Configuration

Plus en détail

Mise en place Active Directory, DNS Mise en place Active directory, DNS sous Windows Serveur 2008 R2

Mise en place Active Directory, DNS Mise en place Active directory, DNS sous Windows Serveur 2008 R2 BTS SIO Mise en place Active Directory, DNS Mise en place Active directory, DNS sous Windows Serveur 2008 R2 Frédéric Talbourdet Centre de formation Morlaix - GRETA BTS SIO CAHIER D ES CHARGES - Projet

Plus en détail

Documentation de CMS-gen

Documentation de CMS-gen Table des matières GÉNÉRALITÉ... 1 LA ZONE D'ADMINISTRATION... 2 LOGIN SUR LA ZONE D ADMINISTRATION... 2 EDITION DU CONTENU EN LIGNE... 3 LE MODE EDITION... 3 PUBLICATION... 3 SUPPRIMER DES MODIFICATIONS...

Plus en détail

Virtualisation et Haute disponibilité

Virtualisation et Haute disponibilité Virtualisation et Haute disponibilité Fabien Muller Hubert Hollender Plan de l exposé Présentation Problématique de départ OpenVZ Pacemaker Solutions mises en oeuvre Bilan Présentation Institut de Physique

Plus en détail

Serveur FTP. 20 décembre. Windows Server 2008R2

Serveur FTP. 20 décembre. Windows Server 2008R2 Serveur FTP 20 décembre 2012 Dans ce document vous trouverez une explication détaillé étapes par étapes de l installation du serveur FTP sous Windows Server 2008R2, cette présentation peut être utilisée

Plus en détail

Guide de déploiement

Guide de déploiement Guide de déploiement Installation du logiciel - Table des matières Présentation du déploiement du logiciel CommNet Server Windows Cluster Windows - Serveur virtuel CommNet Agent Windows Cluster Windows

Plus en détail

Cours admin 200x serveur : DNS et Netbios

Cours admin 200x serveur : DNS et Netbios LE SERVICE DNS Voici l'adresse d'un site très complet sur le sujet (et d'autres): http://www.frameip.com/dns 1- Introduction : Nom Netbios et DNS Résolution de Noms et Résolution inverse Chaque composant

Plus en détail

http://cri.univ-lille1.fr Virtualisation de Windows dans Ubuntu Linux

http://cri.univ-lille1.fr Virtualisation de Windows dans Ubuntu Linux http://cri.univ-lille1.fr Virtualisation de Windows dans Ubuntu Linux Version 1.0 Septembre 2011 SOMMAIRE 1. Introduction 3 2. Installation du logiciel de virtualisation VirtualBox 4 3. Création d'une

Plus en détail

Réf. 2402 Implémentation et gestion de Microsoft Exchange Server 2003

Réf. 2402 Implémentation et gestion de Microsoft Exchange Server 2003 Public Ce cours est destiné aux informaticiens qui gèrent une messagerie électronique dans un environnement comprenant entre 250 et 5000 utilisateurs, réparti sur de nombreux sites, utilisant divers protocoles

Plus en détail

La hiérarchie du système DNS

La hiérarchie du système DNS LA RÉSOLUTION DE NOMS 1. PRÉSENTATION DU SYSTÈME DNS 1.1 INTRODUCTION À LA RÉSOLUTION DE NOMS Pour pouvoir communiquer, chaque machine présente sur un réseau doit avoir un identifiant unique. Avec le protocole

Plus en détail

Online Help StruxureWare Data Center Expert

Online Help StruxureWare Data Center Expert Online Help StruxureWare Data Center Expert Version 7.2.7 Système virtuel StruxureWare Data Center Expert Le serveur StruxureWare Data Center Expert 7.2 est disponible comme système virtuel pris en charge

Plus en détail

Installation Manuelle DRBD et GFS2

Installation Manuelle DRBD et GFS2 Installation Manuelle DRBD et GFS2 DRBD est un système de réplication de disque au travers d'un réseau. Il permet de "recopier" le contenu d'un disque vers un serveur distant. Ceci est particulièrement

Plus en détail

BTS SIO option SISR Lycée Godefroy de Bouillon Clermont-Ferrand

BTS SIO option SISR Lycée Godefroy de Bouillon Clermont-Ferrand Active Directory sous Windows Server SAHIN Ibrahim BTS SIO option SISR Lycée Godefroy de Bouillon Clermont-Ferrand Sommaire I - Introduction... 3 1) Systèmes d exploitation utilisés... 3 2) Objectifs...

Plus en détail

LES RESEAUX SOUS LINUX

LES RESEAUX SOUS LINUX LES RESEAUX SOUS LINUX AVERTISSEMENT : Les commendes utilisées dans ce document ne sont toutes valables que pour les distributions LINUX de type DEBIAN PROGRAMME DE FORMATION I. GENERALITES SUR LES RESEAUX

Plus en détail

INTRODUCTION. Mysql-server est un serveur de bases de données. Cest un logiciel libre.

INTRODUCTION. Mysql-server est un serveur de bases de données. Cest un logiciel libre. INTRODUCTION Mysql-server est un serveur de bases de données. Cest un logiciel libre. Une base de données informatique est un ensemble de données qui ont été stockées sur un support informatique, organisées

Plus en détail

CONFIGURER VOTRE HEBERGEMENT LINUX

CONFIGURER VOTRE HEBERGEMENT LINUX CONFIGURER VOTRE HEBERGEMENT LINUX Ref : FP. P858 V 6.0 Ce document vous indique comment utiliser votre hébergement Linux à travers votre espace abonné. A - Accéder à la gestion de votre Hébergement...

Plus en détail

L3 ASR Projet 1: DNS. Rapport de Projet

L3 ASR Projet 1: DNS. Rapport de Projet L3 ASR Projet 1: DNS Rapport de Projet Table des matières I. Maquette de travail...1 II. Configuration des machines...2 III. Type de zone...3 IV. Délégation de zone...3 V. Suffixes DNS...4 VI. Mise en

Plus en détail

Parcours IT Projet réseaux informatiques Christophe DOIGNON

Parcours IT Projet réseaux informatiques Christophe DOIGNON FORMATION INGENIEURS ENSPS EN PARTENARIAT (2008-2009) MODULE MI6 DU PARCOURS INFORMATIQUE ET TELECOMMUNICATIONS MISE EN OEUVRE D'UN RESEAU INFORMATIQUE LOCAL EMULE ROUTAGE SOUS LINUX 1. Introduction La

Plus en détail

DÉMARRAGE RAPIDE. Présentation et installation de NetStorage

DÉMARRAGE RAPIDE. Présentation et installation de NetStorage Novell NetStorage www.novell.com DÉMARRAGE RAPIDE Présentation et installation de NetStorage Novell NetStorage est une fonction de NetWare 6 qui permet d'accéder facilement, via Internet, au système de

Plus en détail

Haute disponibilité d'un serveur FTP

Haute disponibilité d'un serveur FTP Haute disponibilité d'un serveur FTP Propriétés Type de publication Intitulé court Intitulé long Module Côté Labo Date de publication Septembre 2013 Date de modification Septembre 2013 Version V1.0 Description

Plus en détail

Exploitation de l Active Directory

Exploitation de l Active Directory Exploitation de l Active Directory Mise à jour Date Version Auteur Diffusion Description 30/11/2013 1.0 VALAYER - JUGE 02/12/2013 Installation, réplication sauvegarde, restauration, de l AD. Ajout d utilisateurs

Plus en détail

TP2a : Windows 2008 Server et Active Directory + station windows 7

TP2a : Windows 2008 Server et Active Directory + station windows 7 TP2a : Windows 2008 Server et Active Directory + station windows 7 Description de la configuration et des objectifs du TP : Installer un serveur Windows 2008 contrôleur de domaine en machine virtuelle

Plus en détail

Protocoles DHCP et DNS

Protocoles DHCP et DNS Protocoles DHCP et DNS DHCP (Dynamic Host Configuration Protocol) est un protocole qui permet à un serveur DHCP (Unix, Windows, AS400...) d'affecter des adresses IP temporaires (et d'autres paramètres)

Plus en détail

TP : installation de services

TP : installation de services TP : installation de services Ce TP a été rédigé rapidement. Il ne donne certainement pas toutes les explications nécessaires à la compréhension des manipulations. Assurez vous de bien comprendre ce que

Plus en détail

Guide d utilisation. Table des matières. Mutualisé : guide utilisation FileZilla

Guide d utilisation. Table des matières. Mutualisé : guide utilisation FileZilla Table des matières Table des matières Généralités Présentation Interface Utiliser FileZilla Connexion FTP Connexion SFTP Erreurs de connexion Transfert des fichiers Vue sur la file d'attente Menu contextuel

Plus en détail

II Importation et retrait automatiques de

II Importation et retrait automatiques de II Importation et retrait automatiques de postes de travail Les services d'importation et de retrait automatiques de postes de travail de Novell ZENworks for Desktops (ZfD) permettent de gérer facilement

Plus en détail

Heartbeat DRBD. Application aux vservers. 29 mai 2008. JT-SIARS Marseille - 29 mai 2008 - F Lichnowski 1

Heartbeat DRBD. Application aux vservers. 29 mai 2008. JT-SIARS Marseille - 29 mai 2008 - F Lichnowski 1 Heartbeat DRBD Application aux vservers 29 mai 2008 JT-SIARS Marseille - 29 mai 2008 - F Lichnowski 1 Pourquoi vserver? Isoler les différents services Optimiser la mutualisation Utilise peu de ressources

Plus en détail

PARAGON SYSTEM BACKUP 2010

PARAGON SYSTEM BACKUP 2010 PARAGON SYSTEM BACKUP 2010 Paragon System Backup 2010 2 Manuel d'utilisation SOMMAIRE 1 Introduction...3 1.1 Comment System Backup protège mon ordinateur?...3 1.1.1 Emplacement du stockage des clichés...

Plus en détail

Configuration réseau Linux

Configuration réseau Linux Configuration réseau Linux 1 Page 1 Il s'agit de paramétrer un système LINUX pour qu'il soit connecté à un réseau local, et puisse éventuellement accéder au réseau Internet via un accès distant par routeur

Plus en détail

Active Directory sous 2008 R2

Active Directory sous 2008 R2 Active Directory sous 2008 R2 Le livre de référence de ce chapitre est «Windows Server 2008 - Installation, configuration, gestion et dépannage» des éditions ENI, disponible sur egreta. Le site de référence

Plus en détail

DOCUMENTATION TECHNIQUE

DOCUMENTATION TECHNIQUE DOCUMENTATION TECHNIQUE Installation et configuration d un serveur OCS Inventory et GLPI Active Directory et DHCP Benjamin Dupuy BTS Services Informatiques aux Organisations Option : Solutions d infrastructures,

Plus en détail

TP2 : Windows 2003 Server et Active Directory

TP2 : Windows 2003 Server et Active Directory TP2 : Windows 2003 Server et Active Directory Description de la configuration et des objectifs du TP : Un serveur Windows 2003 contrôleur de domaine est accessible sur le réseau, son adresse IP vous sera

Plus en détail

Installation d'un serveur DHCP sous Windows 2000 Serveur

Installation d'un serveur DHCP sous Windows 2000 Serveur Installation d'un serveur DHCP sous Windows 2000 Serveur Un serveur DHCP permet d'assigner des adresses IP à des ordinateurs clients du réseau. Grâce à un protocole DHCP (Dynamic Host Configuration Protocol),

Plus en détail

Windows Internet Name Service (WINS)

Windows Internet Name Service (WINS) Windows Internet Name Service (WINS) WINDOWS INTERNET NAME SERVICE (WINS)...2 1.) Introduction au Service de nom Internet Windows (WINS)...2 1.1) Les Noms NetBIOS...2 1.2) Le processus de résolution WINS...2

Plus en détail

Installation des outils OCS et GLPI

Installation des outils OCS et GLPI Installation des outils OCS et GLPI MAYERAU David 06/02/2012 PRESENTATION. --------------------------------------------------------------------------------------------- 3 INSTALLATION DE GLPI. ------------------------------------------------------------------------------------

Plus en détail

Mise en place d un cluster. De basculement. Et DHCP Failover. Installation. Préparation. Vérification

Mise en place d un cluster. De basculement. Et DHCP Failover. Installation. Préparation. Vérification Mise en place d un cluster De basculement Et DHCP Failover Valentin Banse Thomas Haën-Boucher Thomas Bichon Présentation Installation Préparation B T S S I O 2 2 / 0 4 / 2 0 1 4 Configuration Vérification

Plus en détail

Mise en place Active Directory / DHCP / DNS

Mise en place Active Directory / DHCP / DNS Mise en place Active Directory / DHCP / DNS Guillaume Genteuil Période : 2014 Contexte : L entreprise Diamond Info localisé en Martinique possède une cinquantaine de salariés. Basé sur une infrastructure

Plus en détail

Projet Personnalisé Encadré PPE 2

Projet Personnalisé Encadré PPE 2 BTS Services Informatiques aux Organisations Session 2014 Projet Personnalisé Encadré PPE 2. GESTION D'UTILISATEURS SYSTÈMES ET BASE DE DONNÉES, INSTALLATION ET CONFIGURATION D'OUTILS DE SUPERVISION ET

Plus en détail

IP & Co. 1. Service DHCP. L'objectif de ce TP est de voir l'ensemble des services élémentaires mis en oeuvre dans les réseaux IP.

IP & Co. 1. Service DHCP. L'objectif de ce TP est de voir l'ensemble des services élémentaires mis en oeuvre dans les réseaux IP. IP & Co L'objectif de ce TP est de voir l'ensemble des services élémentaires mis en oeuvre dans les réseaux IP. 1. Service DHCP Faire un réseau de 4 machines comme ci-dessous. Pour l'instant seul la machine

Plus en détail

But de cette présentation. Serveur DHCP (rédigé pour Ubuntu Server) Le protocole DHCP. Le protocole DHCP. Hainaut P. 2013 - www.coursonline.

But de cette présentation. Serveur DHCP (rédigé pour Ubuntu Server) Le protocole DHCP. Le protocole DHCP. Hainaut P. 2013 - www.coursonline. Serveur DHCP (rédigé pour Ubuntu Server) But de cette présentation Vous permettre de comprendre et de configurer le service DHCP sur un serveur Ubuntu Linux via l invite de commande Voir comment configurer

Plus en détail

Configuration de Telnet dans Linux

Configuration de Telnet dans Linux Configuration de Telnet dans Linux Durée prévue: 25 minutes Objectif Équipement Scénario Procédures Dans ce TP, l'étudiant va apprendre à configurer les services Telnet sur un système de manière à ce que

Plus en détail

Un serveur FTP chez soi Tutoriel pour Filezilla FTP server

Un serveur FTP chez soi Tutoriel pour Filezilla FTP server Space-OperaRécitsLogicielsCréationsBlogForum Un serveur FTP chez soi Tutoriel pour Filezilla FTP server DynDNS : Pourquoi et comment? Téléchargement et installation de Filezilla Server Configuration réseau

Plus en détail

DESCRIPTION DU CONTEXTE INFORMATIQUE ET MISE EN PLACE DU CONTEXTE

DESCRIPTION DU CONTEXTE INFORMATIQUE ET MISE EN PLACE DU CONTEXTE DESCRIPTION DU CONTEXTE INFORMATIQUE ET MISE EN PLACE DU CONTEXTE Sommaire Description du réseau GSB... 2 Réseau GSB original... 2 Réseau GSB utilisé en PPE... 2 Liste des s de l'infrastructure... 3 Implémentation

Plus en détail

Installation de Windows 2000 Serveur

Installation de Windows 2000 Serveur Installation de Windows 2000 Serveur Introduction Ce document n'explique pas les concepts, il se contente de décrire, avec copies d'écran, la méthode que j'utilise habituellement pour installer un Windows

Plus en détail

Installation de Windows 2003 Serveur

Installation de Windows 2003 Serveur Installation de Windows 2003 Serveur Introduction Ce document n'explique pas les concepts, il se contente de décrire, avec copies d'écran, la méthode que j'utilise habituellement pour installer un Windows

Plus en détail

1. La plate-forme LAMP

1. La plate-forme LAMP Servi ces pour intranet et Internet Ubuntu Linux - Création et gestion d un réseau local d entreprise 1. La plate-forme LAMP Services pour intranet et Internet La fourniture d'un site pour le réseau ou

Plus en détail

Table des matières STE PUZZLE

Table des matières STE PUZZLE Table des matières... 1 I - Présentation de la STE Puzzle... 3 A - Présentation de l entreprise... 3 1) Activité... 3 2) Données économiques et juridiques... 3 3) Situation et répartition géographique...

Plus en détail

Situation professionnelle n X

Situation professionnelle n X BENARD Jérémy BTS SIO 2 Situation professionnelle n X ========================================= Thème : Gestion et amélioration d'une infrastructure ========================================= Option SISR

Plus en détail

Le meilleur de l'open source dans votre cyber cafe

Le meilleur de l'open source dans votre cyber cafe Le meilleur de l'open source dans votre cyber cafe Sommaire PRESENTATION...1 Fonctionnalités...2 Les comptes...3 Le système d'extensions...4 Les apparences...5 UTILISATION...6 Maelys Admin...6 Le panneau

Plus en détail

Infrastructure Exemple

Infrastructure Exemple Infrastructure Exemple Table des matières 1. Serveurs...2 1.1 Serveurs physiques...2 1.2 Serveurs Virtuels...2 2. Services...3 2.1 Service mail...3 2.2 Service MySQL...3 2.3 Service Web...4 2.4 Cas particulier

Plus en détail

Téléchargement d OCS Inventory Serveur et Agent. Sommaire

Téléchargement d OCS Inventory Serveur et Agent. Sommaire Téléchargement d OCS Inventory Serveur et Agent Tout d abord, Connectez-vous sur le site suivant : http://www.ocsinventory-ng.org/ Sélectionner le langage Français en cliquant sur le drapeau France Cliquer

Plus en détail

Installation de Freenas

Installation de Freenas Installation de Freenas Dans le cadre cet article, le PC qui va hébergé le serveur Freenas à les caractéristiques suivante: un CPU AMD Sempron(tm) Processor 2800+, 1024Mo RAM, 1 disque dur IDE 40Go pour

Plus en détail