Redondance

Dans le cadre d’une infrastructure d’entreprise, les administrateurs souhaitent surtout éviter la panne matérielle. Aussi, très souvent les serveurs sont équipés de cartes mères ou d’ alimentations redondées. Le chapitre précédent a expliqué les moyens de secourir les disques internes via les matrices RAID, nous allons ici étudier différentes façons de sécuriser les équipements. Bien évidemment, ces derniers s’étendent aussi aux cartes d’interface réseau, à la présentation des disques sur les baies de stockage et aux services d’infrastructures : serveurs de noms DNS, serveurs d’annuaire NIS, etc. Nous terminerons d’ailleurs cette présentation par un complément essentiel à la sécurisation : un service de déploiement pour permettre d’uniformiser et d’automatiser les différents packages ou fonctions à installer. Cette réflexion amène tout naturellement au cluster applicatif et à ses composantes.

Ce chapitre illustrera les moyens pour mettre en place de la redondance pour les points suivants :

disques de stockage en baie SAN et multipath
snapshot des systèmes de fichiers sur LVM
carte d’interface réseau et bonding
synchronisation des disques
redondance de services DNS et NIS

1. Présentation des volumes SAN

Dans les chapitres précédents, nous avons étudié comment sécuriser un serveur ou quelques serveurs interconnectés mais, au sein d’une entreprise, la thématique de sécurité impacte plus largement l’ensemble des équipements. Pour y arriver, le maître-mot c’est la redondance. Deux niveaux sont principalement impactés par ce genre de problématique :

l’architecture de stockage SAN (Storage Area Network)
l’architecture réseau

Aujourd’hui, peu de serveurs d’entreprises possèdent des disques internes. La plupart du temps, les administrateurs utilisent des unités de stockage, appartenant à des baies de stockage mutualisées. Il faut voir une baie de stockage comme un silo à disque que l’on peut découper et associer aux différentes machines de l’infrastructure....

Mise en œuvre d’un cluster

Un cluster de service doit permettre de redonder le(s) service(s) d’un serveur en le(s) répliquant sur une autre machine, mais également d’équilibrer la charge entre plusieurs serveurs en fonctionnement. C’est le rôle proposé par Linux Virtual Server, abrégé en LVS.

1. Utilisation de LVS

Il s’agit d’un équilibreur de charge permettant non seulement de redonder un service (comme un serveur Apache, un serveur LDAP), mais également d’équilibrer la charge induite par les requêtes générées par les clients. Il est conseillé de lire l’excellent ouvrage décrivant l’intégralité des solutions pour les serveurs Linux en matière de haute disponibilité : « Linux - Solutions de haute disponibilité (2e édition) » de Sébastien ROHAUT aux Éditions ENI, dans lequel nous trouvons un chapitre intégralement consacré à cet outil.

Le serveur LVS est généralement appelé directeur. C’est d’ailleurs à ce niveau qu’il faut commencer, en installant le package ipvsadm :


# apt-get install ipvsadm

Sur ce même serveur, nous utiliserons une adresse IP virtuelle (abrégée en VIP), déclarée au niveau de l’interface réseau du directeur, en mettant en place un bond comme cela a été vu précédemment :


auto bond0:0  
iface bond0:0 inet static  
    address 192.168.1.142  
    netmask 255.255.255.255  
    broadcast 192.168.1.255  
    network 192.168.1.0

Pour démarrer l’interface, il faut alors exécuter la commande ci-dessous :


# ifup bond0:0

Le simple fait d’exécuter après la commande ifconfig devrait afficher la nouvelle interface. Si ce n’est pas le cas, c’est que celle-ci n’a pas été correctement déclarée et il faut alors revoir la configuration.

L’adresse IP virtuelle est partagée entre le directeur et les serveurs physiques (le monde réel), mais il n’y a que le directeur qui réponde aux requêtes adressées sur l’adresse VIP. Cela explique pourquoi...

Haute disponibilité

1. Architecture à initialiser

Au vu de ce qui a été abordé précédemment, l’architecture la plus évidente à mettre en œuvre est le cluster haute disponibilité. Il suffit alors de coupler la fonctionnalité de cluster avec un heartbeat pour disposer d’une structure applicative de haute disponibilité. Pour illustrer ces propos, nous mettons en œuvre un cluster Corosync avec pacemaker. En effet, la haute disponibilité désigne le fait d’améliorer la disponibilité d’un système ou de services, en augmentant la tolérance aux pannes, grâce à de la redondance matérielle, via un cluster ou une réplication à chaud des données. Généralement, on s’applique à mettre en œuvre une architecture matérielle à base de matrice RAID (RAID1 ou RAID5), ou de façon logicielle, en utilisant les prises de clichés, ou l’application DRBD, et permettre la gestion des situations de crises, au travers de mode dégradé du rendu de service ou d’un plan de secours. A été mentionné précédemment l’utilisation de heartbeat qui ne peut malheureusement gérer un cluster de plus de deux nœuds et dont la gestion des ressources et des règles de bascule d’un nœud sur l’autre n’est pas faite de façon très granulaire. Nous initialiserons, pour exemple, une maquette de deux nœuds Debian, hébergeant un service web Apache2, auquel on peut accéder via une adresse de cluster.

Cela signifie que ces nœuds disposent de quatre interfaces réseau deux à deux joints sous forme de bond :

Les interfaces eth0 et eth1 sont agrégées sous forme logique de liens et servent au cluster afin de vérifier l’état des autres nœuds, constituant ainsi un réseau privé avec le second nœud, dans le réseau 192.168.1.0/255.255.255.0. Les deux autres interfaces sont également agrégées et fournissent le service à l’extérieur, dans le réseau 10.84.2.0/24. L’agrégation logique, au niveau du réseau, aussi appelée bonding, fournit une redondance supplémentaire....

Application aux bases de données

La haute disponibilité appliquée aux bases de données est possible au travers du mécanisme de réplication. Il est possible de créer une base (appelée esclave), dépendante d’une autre (appelée maître). Cela permet de synchroniser entièrement une base de données, en temps réel d’un serveur à un autre, permettant ainsi, en cas de panne de la première, de basculer sur le second serveur et d’utiliser le service de base de données de celui-ci, sans perdre d’informations.

1. Installation

L’outil phpMyAdmin vu au chapitre Services Système et administration est une suite logicielle permettant d’administrer facilement les sites web et autres applications utilisant des architectures AMP (Apache/MySQL/HP). Son installation s’effectue grâce à la commande suivante :


# apt-get install phpmyadmin

On rappelle que durant cette étape, le gestionnaire de configuration propose d’installer et configurer une base de données pour y stocker les informations d’administration :

Il faut alors fournir (et confirmer) le mot de passe de l’administrateur de cette instance de base de données :

ATTENTION : si deux services web tels qu’apache2 et lighttpd, sont installés sur le même serveur, il faut en sélectionner un pour permettre à phpMyAdmin d’être administré :

Dès lors, phpMyAdmin peut être utilisé en se connectant via un navigateur à l’URL http://localhost/phpmyadmin.

2. Utilisation et configuration

L’accès au menu général offre alors la possibilité de visualiser l’ensemble des instances MySQL disponibles sur le serveur, mais il est aussi possible non seulement de créer, mais également de dupliquer les informations d’une base à une autre.

Pour preuve, créons une base TEST sur le serveur maître, en sélectionnant l’onglet Base de données, puis en cliquant sur le bouton Créer :