Tout apprendre sur le cloud computing ou l'informatique dans les nuages

Explications et fonctionnement du cloud computing

Chrtophe

Le cloud computing ou informatique dans les nuages peut être vu comme la dématérialisation des systèmes informatiques.

Vous verrez dans ce tutoriel des exemples d’utilisation du cloud tant grand public que professionnel. Il vous donnera les bases de la compréhension du cloud et des services gravitant autour.

Commentez

- Titre : Tout apprendre sur le cloud computing ou l'informatique dans les nuages

- Auteur : Chrtophe

- Parution : 15 novembre 2020

- Licence : Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright ® 2020 Chrtophe. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- 1. Introduction : Qu'est-ce que le cloud ?

- 1-1. Pourquoi ai-je besoin du cloud ?

- 1-2. Nomenclature

- 1-3. Les différents modules cloud

- 1-4. Cloud public/privé/hybride

- 2. Les services cloud grand public les plus connus

- 3. Les services cloud pour les professionnels : Le cloud à grande échelle

- 3-1. OpenStack

- 3-2. VMWare

- 3-3. Amazon Web Service (AWS)

- 3-4. Microsoft Azure

- 3-5. Oracle Cloud Infrastructure

- 3-6. Google Cloud Platform

- 3-7. Hadoop

- 4. Les solutions d’autohébergement (utilisable en cloud)

- 5. Étude de création de notre propre cloud

- 6. Les briques minimales

- 6-1. Le cloud et la virtualisation

- 6-2. Et les conteneurs dans tout ça ?

- 6-3. Cadre des tests

- 7. Synchronisation de fichiers

- 8. Systèmes de fichiers distribués

- 9. Centralisation de la gestion des accès

- 9-1. Installation de NIS

- 9-1-1. Ajout d'un client NIS

- 9-1-1-1. Test de connexion à un compte de test

- 9-1-1-2. Test de changement de mot de passe

- 9-1-1-3. Ajout/suppression d'utilisateur

- 9-1-2. Ajout d’un serveur secondaire

- 9-1-3. Conclusion

- 9-2. LDAP

- 9-2-1. Installation

- 9-2-2. Installation de LAM (LDAP Account Manager)

- 9-2-3. Authentification Linux avec une base LDAP

- 9-2-4. Authentification Mac OS avec une base LDAP

- 9-2-5. Authentification Windows sur un serveur LDAP

- 9-2-6. Sauvegarde restauration LDAP

- 9-2-6-1. Par copie des fichiers

- 9-2-6-2. Par import/export LDIF

- 9-2-7. Serveur secondaire LDAP

- 9-3. Kerberos

- 9-4. Windows Server

- 9-5. Mac OS X

- 9-6. Bilan

- 10. Réplication/clustering de bases de données

- 10-1. Réplication

- 10-1-1. Maitre-esclave

- 10-1-2. Maitre-maitre

- 10-1-3. Détails

- 10-1-4. Activation de la réplication entre un maitre et un esclave

- 10-1-5. Activation de la réplication maitre-maitre

- 10-2. Le moteur Federated de Mysql Server

- 10-3. Clustering

- 10-3-1. Installation de Galera cluster avec MariaDB

- 10-3-1-1. Création du cluster

- 10-3-1-2. Ajout d'une seconde machine au cluster

- 10-3-2. Clustering Galera Cluster avec MySQL

- 10-3-3. Maintenance : perte de srv2

- 10-3-3-1. Remontage de srv2

- 10-3-4. Maintenance : perte de srv1

- 10-3-4-1. Remise de srv1 en maitre

- 10-3-5. Ajout d'un nouveau serveur

- 10-3-6. Galera arbitrator

- 10-3-7. Perte d’un nœud dans une configuration à plus de deux machines

- 10-3-8. Percona XtraDB cluster

- 10-4. Sauvegardes/restaurations

- 10-4-1. Sauvegarde par mysqldump

- 10-4-2. Restauration d'une sauvegarde mysqldump

- 10-4-3. Sauvegarde avec Percona XtraBackup

- 10-4-3-1. Réalisation d'une sauvegarde complète

- 10-4-3-2. Restauration d'une sauvegarde complète

- 10-4-3-3. Sauvegarde incrémentale

- 10-4-3-4. Restauration incrémentale

- 10-4-3-5. Chaînage de plusieurs sauvegardes

- 10-5. Autres bases que MySQL

- 11. Haute disponibilité

- 11-1. Répartition de charge

- 11-2. Redondance

- 11-3. Les politiques de load balancing les plus connues

- 11-3-1. Le DNS Round-Robin

- 11-3-2. Heartbeat

- 11-3-2-1. Exemple avec un serveur web

- 11-3-3. Pacemaker

- 11-3-4. Corosync

- 11-3-5. Corosync/Pacemaker

- 11-3-6. Keepalived

- 11-3-6-1. keepalived - tests

- 11-3-6-2. Test

- 11-3-6-3. Détection de bascule

- 11-3-6-4. Répartition de charge

- 11-3-6-5. Test de fonctionnement d’un serveur

- 12. Surveillance

- 12-1. Le plus simple : par mail

- 12-2. Syslog

- 12-3. Nagios

- 12-4. Prometheus/Grafana

- 12-5. Solution maison

- 13. Orchestration

- 14. Conclusion

- 15. Remerciements

1 - Introduction : Qu'est-ce que le cloud ?

Cette version est une version allégée de mon livre sur le cloud computing. La version complète se trouve ici.

Le cloud computing ou informatique dans les nuages peut être vu comme la dématérialisation totale ou partielle des systèmes informatiques.

C'est un terme qui regroupe beaucoup de choses, rendant ses aspects flous comme les nuages formant du brouillard. Le but de ce tutoriel est de sortir de ce brouillard concernant le cloud.

Le cloud computing est donc un ensemble de services vous fournissant pour l'aspect grand public :

- un hébergement web (Apache/PHP/MSQL) ;

- l'hébergement de vos mails/contacts/agendas ;

- un espace de stockage/synchronisation partagé ou non ;

- une application métier.

Pour l'aspect professionnel :

- des serveurs virtuels avec redondance, répartition de charge et possibilité d'augmentation de puissance (temporaire ou non) pour supporter une montée en charge ;

- des espaces de stockage en mode bloc ou en mode objet ;

- des espaces de stockage et de bases de données distribués pour le big data notamment.

Dans les deux cas, toutes les ressources seront virtualisées, sauf dans le cas où vous louez un emplacement de baie dans un datacenter pour y placer vos propres machines.

Vos services fonctionneront en général sur une ferme de serveurs dont les capacités allouées peuvent changer avec le temps (en termes de puissance, d'espace de stockage, de bande passante). Ces serveurs peuvent être répartis ou répliqués dans plusieurs centres de données (data-center), c'est même indispensable pour les services de haute disponibilité.

Ceci vous permet de louer des services externalisés et/ou du matériel et ainsi de ne pas avoir à les gérer.

Avec le cloud, on ne vous fournit pas du matériel (bien que ce soit possible), mais plutôt de la ressource d'accès à celui-ci.

Ce tutoriel est composé de quatre parties :

- une présentation des services cloud grand public les plus connus ;

- une présentation des services cloud professionnels ;

- une présentation de solutions d’autohébergement pouvant être utilisées (ou non) en mode cloud ;

- une présentation des différentes briques constituant le cloud vous permettant une meilleure compréhension et éventuellement une mise en place de solutions adaptées à votre besoin.

1-1 - Pourquoi ai-je besoin du cloud ?

Vous aurez besoin de services cloud si vous souhaitez avoir un accès permanent à vos services depuis n'importe où, ou si vous souhaitez avoir une sauvegarde sur Internet permanente.

Pour accéder par exemple à un serveur de fichiers dans une entreprise, il n'est pas forcément nécessaire d'utiliser une solution cloud, un VPN permettant d'entrer sur le réseau interne de l'entreprise pouvant suffire. Une solution cloud sera justifiée si vous souhaitez dématérialiser vos serveurs internes.

1-2 - Nomenclature

Vous trouverez ci-dessus une définition des termes qui reviendront régulièrement dans ce tutoriel.

- Datacenter : un datacenter ou centre de données est un lieu où vont être regroupés des serveurs installés dans des baies informatiques. À cela viendra s'ajouter une infrastructure réseau, un système de climatisation adapté, des systèmes anti-incendies, anti-intrusions, une alimentation électrique redondante et sécurisée par groupe électrogène. Vous y louerez soit des serveurs soit un emplacement (un quart, un tiers de baie) pour y placer vos équipements et vous permettant de bénéficier de l'infrastructure (réseau, électrique, climatisation).

- Virtualisation : en informatique, la virtualisation consiste en une abstraction des ressources. Une machine virtuelle contient un système d'exploitation exécuté sur un hôte nommé hyperviseur. Avec la virtualisation, il est par exemple possible d’exécuter un Windows virtualisé depuis un serveur Linux exécutant un hyperviseur. L'inverse est également possible, Hyper-V, hyperviseur de Microsoft peut exécuter des machines virtuelles Linux dans Windows.

- Hyperviseur : ordinateur ayant des capacités de virtualisation (support de la virtualisation par le CPU) et exécutant un logiciel de virtualisation nommé hyperviseur. (comme VMWare, KVM, VirtualBox). Il existe deux types d'hyperviseurs :

- hyperviseur de type 1 ou bare metal : celui-ci ne va servir qu'à exécuter et gérer des machines virtuelles (VMWare ESX, KVM, Xen) ;

- Hyperviseur de type 2 : un logiciel hyperviseur va s’exécuter sur un système d'exploitation. Le gestionnaire de machines virtuelles et les machines virtuelles peuvent être considérés comme des applications exécutées sur l'OS hôte (VirtualBox, VMWare Workstation).

- Conteneur : un conteneur consiste en la virtualisation d'une application ou d'un service. Plus léger qu'une machine virtuelle, un conteneur va utiliser le noyau du système d'exploitation qui l'accueille en cloisonnant les ressources. Docker est un système de gestion de conteneurs faisant référence.

- Network Attached Server (NAS) : il s'agit d'un serveur dédié au stockage, en général un boîtier contenant des disques accessibles sur le réseau via les protocoles classiques de partage de fichiers. Ceux-ci auront alors des fonctions plus ou moins avancées allant du simple partage de fichiers à des fonctions rivalisant avec un serveur d'entreprise.

- Storage Area Network (SAN) : il s'agit d'un réseau de stockage de données bas niveau. Les SAN fournissent des accès en mode blocs. Exemple, une baie de disque qui sera accessible à une ou plusieurs machines.

- Distributed File System (DFS) : il s'agit d'un système de fichiers réparti sur plusieurs machines. Le client (utilisateur ou matériel y accédant) n'a pas notion de cette répartition. Ce type de système est souvent associé à un mécanisme de redondance.

- Redondance : la redondance consiste à dupliquer les composants (matériels et/ou logiciels) de façon à garantir le fonctionnement d'un système en cas de défaillance d'un composant, ceci de façon transparente.

1-3 - Les différents modules cloud

Les services cloud se présentent en plusieurs couches dont voici les principales.

- Infrastructure as a Service (infrastructure en tant que service, IaaS) : ce service est celui de plus bas niveau. Par exemple, il consiste en la mise à disposition de machines virtuelles, de conteneurs, de systèmes de fichiers distribués, de NAS/SAN. La partie « matérielle » (les différentes machines, l'infrastructure réseau et de répartition de charge) est sous la responsabilité du fournisseur de services.

- Platform as a Service (plateforme en tant que service, PaaS) : ce type de service fournit le système d'exploitation, le ou les moteurs de base de données et peut donner ou non la liberté d'installer des logiciels. Les logiciels peuvent aussi être préinstallés.

- Software as a service (logiciel en tant que service, SaaS) : à ce niveau, ce sont les applications qui sont proposées. On peut citer Microsoft Office 365 (pour la partie modification en ligne de documents, ou le logiciel installé sur votre poste), Google Docs, ou tout simplement un hébergement web.

D'autres couches peuvent être fournies telles que le Desktop as a Service (bureau virtuel en tant que service), le Storage as a Service (stockage en tant que service), la première étant haut niveau (SaaS), la seconde bas niveau (IaaS).

Les différentes briques IaaS, PaaS, SaaS peuvent être vues comme des briques mises en commun pour fournir la solution qui vous sera proposée ou que vous mettrez en place. Les différentes couches s’imbriquent comme des poupées russes et peuvent être comparées au modèle de couches OSI.

La fourniture et la maintenance des couches IaaS et PaaS sont à la charge du fournisseur de service.

Avantages :

- gestion externalisée du matériel et de sa maintenance, facilité de montée en charge ;

- accessibilité depuis n'importe où ;

- synchronisation en temps réel ou différé en cas de rupture de liaison, par exemple des services tels que Dropbox ou Google Drive.

Inconvénients :

- captivité possible par rapport au produit utilisé et à Internet. En cas de coupure de liaison, aucune activité n’est possible ;

- la migration vers un autre fournisseur de services peut être compliquée. Cette contrainte a tendance à disparaître ;

- coûts d’utilisation pouvant être cachés ou difficiles à maîtriser, notamment si la facturation repose sur la bande passante ou l’espace utilisé, etc. ;

- exposition plus importante aux risques de piratage si tous les services d’une entreprise sont accessibles depuis Internet ;

- solution cadrée : vous n'aurez pas forcément accès à des réglages bien précis (c'est aussi un avantage pour la simplification de l'administration).

Cette liste est non exhaustive.

1-4 - Cloud public/privé/hybride

Le cloud privé consiste en un cloud dont les ressources vous sont dédiées. Il peut s'agir de votre propre matériel dans vos locaux, d’un matériel hébergé dans un centre de données dont vous louez une baie ou un équipement spécifique, ou d’un droit d’accès à l'infrastructure de votre hébergeur.

Dans le cloud public, vous utilisez des services mutualisés dans des fermes de serveurs. Évidemment, seules vos données vous sont accessibles et ne le sont qu'à vous, mais les ressources matérielles/système peuvent être partagées entre plusieurs clients. Vous formez votre infrastructure selon le cadre qui vous est fourni. Il s'agit d'un cloud managé.

Un cloud privé virtuel peut être déployé dans un cloud public.

Le cloud hybride, quant à lui, correspond à l'utilisation mixte d’un cloud public et d’un cloud privé. Par exemple, il peut s'agir de répartition de services entre plusieurs cloud, de redondance entre vos locaux et un centre de données, d'une partie de services externalisés communiquant avec des services internes par le biais de standards facilitant la communication.

2 - Les services cloud grand public les plus connus

- Dropbox : service de synchronisation et partage de fichiers, gratuit jusqu’à 2 Go. Une interface d’administration est fournie pour les usages multicomptes professionnels. Dropbox propose une synchronisation sélective permettant de ne stocker sur un poste que certains dossiers. Dans ce cas, les dossiers non sélectionnés ne seront accessibles qu'en ligne ou que sur les postes ne les ayant pas décochés ; l'intégralité des données restant accessibles depuis l'interface web. À l’installation, il vous sera proposé de stocker les données sur votre poste ou de ne les stocker qu'en ligne. Dans les deux cas, vous verrez vos fichiers dans l'explorateur de fichiers.

- Google G-Suite : il s'agit des services de la suite Google (Gmail, Google Drive, Google Agenda, YouTube, Maps, Forms…). Il y a également une interface d'administration pour les usages professionnels. L'espace de stockage est de 30 Go par utilisateur dans un espace professionnel G-Suite. En offre grand public, vous avez 15 Go d'espace de stockage. En version professionnelle, vous aurez accès à Google File Stream. Ce service permet de stocker des données uniquement en ligne (avec possibilité de cache local), comme avec DropBox. Il est possible dans les deux cas d'étendre l'espace de stockage. Celui-ci vous sera facturé. L'usage personnel propose un outil nommé « Google sauvegarde et synchronisation » effectuant comme son nom l'indique la synchronisation de vos données entre votre poste et le compte Google.

- Apple iCloud : service de synchronisation Apple, permettant de synchroniser les contacts, agendas, mots de passe entre les iPad, iPhone et les ordinateurs mac. Les dernières versions (depuis Mac OS X 10.12) permettent également la synchronisation du dossier Documents et du bureau. Le service est gratuit jusqu'à 5 Go. Il existe une version sur Windows permettant la synchronisation avec Outlook, l’espace iCloud pour les documents et les photos.

- Microsoft OneDrive/365 : synchronise les comptes utilisateurs entre les postes fonctionnant sur Windows 10 et les documents pour les systèmes antérieurs. Sous Windows 10, il est en théorie possible d'ouvrir une session sur un ordinateur tiers et de retrouver son environnement de travail. La partie emails et calendriers est gérée par Office 365 (en fait des comptes Exchange sur les serveurs de Microsoft), service à part. Un compte Office 365 peut ou non intégrer une licence Office 365 (il s'agit de la dernière version d'Office en mode location avec un espace de stockage OneDrive). Microsoft s'oriente vers la suite Microsoft 365, incluant les services Office 365, OneDrive, avec une licence Windows 10 incluse, et des services équivalents à ceux fournis par un Windows Server pour la version business : déploiement, stratégie de sécurité (restriction de copie de documents, réinitialisation appareils à distance).

- WeTransfer : service de partage de fichiers dont la validité est temporaire. WeTransfer fournit un lien permettant le téléchargement du fichier téléversé. Ce lien reste valide quelques jours seulement. La version payante WeTransfer Pro permet de garder en ligne jusqu'à 100 Go et de les retransférer. Ce service est essentiellement utilisé pour transférer des fichiers trop volumineux pour être envoyé par mail, son but premier n'est pas d'effectuer du stockage à long terme, même s'il s'agit d'un service cloud. Il est fort probable que vous ayez déjà utilisé ce service pour envoyer ou recevoir des fichiers trop volumineux pour le mail.

Ce type de service peut être vu comme du SaaS (Software as a Service), le plus haut niveau dans les services Cloud. Ces services ne nécessitent pas ou peu de compétences techniques.

3 - Les services cloud pour les professionnels : Le cloud à grande échelle

Les clouds à grande échelle présentés ci-dessous concernent principalement les entreprises. Ces services seront utilisés par des informaticiens et nécessitent des compétences techniques.

Les services suivants vous proposeront dans une console d'administration globalement la même nomenclature de briques pour réaliser votre cloud :

compute : gestion de ressources, avec notamment la gestion des machines virtuelles ;

storage : gestion de l'espace de stockage ;

network : la gestion réseau, avec en général un réseau interne pour l'interconnexion entre ressources, et un réseau public pour la communication extérieure.

Chacun des services présentés ci-dessous pourrait faire l'objet d'un article à part. Je n'ai malheureusement pas les ressources pour les présenter de façon étendue.

3-1 - OpenStack

OpenStack est un projet conjoint de la société Rackspace (acteur majeur des services cloud depuis des années) et de la NASA. L’intérêt principal d'OpenStack est de pouvoir fonctionner sur du matériel standard et hétérogène.

OpenStack est adapté aux infrastructures d'envergure, et est utilisé par OVH, le premier hébergeur européen pour son cloud public.

OpenStack est un ensemble de briques mises en commun pour utiliser une infrastructure cloud. Voici les briques principales :

Nova : gère les ressources de calcul (compute). C'est Nova qui va contrôler les hyperviseurs sur les machines physiques (et maintenant les gestionnaires de conteneurs comme Docker ou LXC) ;

Swift : c'est le système de stockage objet d'OpenStack (storage). Les données sont stockées sous forme d'objets (un fichier va être éclaté en plusieurs objets du point de vue bas niveau). Swift va gérer la redondance des données (réplication, répartition, autoréparation, ajout d'espace de stockage) ;

Cinder : Cinder est l'équivalent de Swift, mais en mode bloc (storage). Il va gérer l'attachement/détachement des périphériques virtuels, la gestion de snapshots ;

Neutron : c'est la brique qui va gérer le réseau : attribution d'IP, création de vswitch, etc. ;

Keystone : c'est le service qui va gérer les identités et autorisations ;

Glance : c'est le service de gestion d'images disque. Ce service va distribuer des images disque aux instances : modèles de disque, fichiers OVF.

Il s'agit là des briques les plus importantes.

OpenStack comporte des API pour communiquer avec les services EC2 et S3 d'Amazon.

Vous pouvez consulter ce tutoriel sur OpenStack. Ou vous rendre sur le site

site d'OpenStack.

3-2 - VMWare

VMWare est un acteur historique dans le monde de la virtualisation.

Oubliez les anciennes dénominations telles que ESX/ESXi au profit de VMWare vSphere.

La version vSphere gratuite se nomme VMWare vSphere Hypervisor, il s'agit en fait d'une version bridée de vSphere ne permettant l'utilisation que de la partie hyperviseur, suffisant dans le cadre de la gestion de trois ou quatre machines virtuelles, pour une petite structure.

Dans le cadre d'une utilisation payante, VMWare vSphere vCenter Server sera une machine virtuelle, installée sur un de vos hyperviseurs, qui gérera votre centre de données de façon globale. Vos hyperviseurs viendront s'intégrer dans une gestion centralisée. Certaines opérations ne seront alors faisables que depuis l'interface centralisée, d'autres pourront être effectuées depuis l'interface web de l'hyperviseur ou depuis l’interface web vCenter (les réglages seront alors visibles depuis l'une ou l'autre des interfaces). Vous pourrez facilement migrer à chaud une machine virtuelle d'un hyperviseur à un autre, et même d'un hyperviseur Intel vers un hyperviseur AMD (sous certaines conditions avec Enhanced vMotion Compatibility).

Dans VMWare vCenter Server, vous aurez une vision globale :

- des hyperviseurs ;

- des datastores ;

- des réseaux.

VMWare est utilisé en usage privé hors nuage, mais peut aussi servir de socle dans un ou des centres de données.

Dans le cadre d'une solution de cloud, le produit utilisé sera VMWare vCloud Suite, qui regroupe vSphere avec vRealize Suite, outil destiné à la modélisation et au provisionnement de projet.

3-3 - Amazon Web Service (AWS)

Amazon propose une multitude de services de cloud computing, le plus connu étant S3 (Amazon Simple Storage Service). Dropbox utilisait auparavant S3. Amazon propose aussi une offre grand public, reposant sur S3, nommée Amazon Drive. Dans certains pays (mais pas la France), Amazon propose une offre gratuite et met à disposition 5 Go. Il existe aussi le service Amazon Prime Photo : un service Amazon Drive dédié aux photos.

Amazon fournit des briques de virtualisation, dont les plus connues sont :

- EC2 : Elastic Compute Cloud ;

- S3 : Simple Storage Service.

Vous pourrez gérer votre infrastructure depuis une interface web.

EC2 vous fournira des serveurs virtuels utilisant Xen, avec répartition de charge (load balancing).

S3 fournit un accès aux données en mode SOAP, REST, BitTorrent, mais peut aussi être utilisé par des API pour simuler un système de fichiers. Une machine virtuelle utilisera plutôt un stockage en mode bloc (EBS pour Amazon Elastic Bloc Store).

Pour ce type d'offre, il faudra porter particulièrement attention à la tarification. Celle-ci dépendra de la puissance, de la taille de l'espace de stockage, du nombre d'accès (nombre lectures/écritures et/ou accès réseau).
Ceci a l’avantage de vous permettre d'augmenter votre puissance temporairement ou définitivement, de la réduire, et donc de vous adapter rapidement aux besoins.
L'inconvénient étant la nécessité de maîtrise des coûts.

Vous pourrez migrer vos machines virtuelles vers Amazon à l'aide de AWS Server Migration Service.

3-4 - Microsoft Azure

Les services Microsoft Azure sont comparables aux services fournis par Amazon avec lesquels ils sont en concurrence. Vous pourrez intégrer bien évidemment facilement tous les produits Microsoft.

Azure Migrate vous permettra de facilement migrer vos machines virtuelles locales vers Azure.

Bien qu'Azure soit une technologie Microsoft, il est tout à fait possible d'y utiliser des machines virtuelles Linux. Scott Guthrie, vice-président exécutif cloud et IA chez Microsoft, déclarait en 2018 :  «  Près de la moitié des machines Azure sont sous Linux ».

Le service propose en plus de l'interface web « Azure (remote) PowerShell » qui permet d'effectuer les opérations en ligne de commande et de façon scriptée. Azure Migrate Server Assesment permet de migrer des machines virtuelles Hyper-V vers Azure.

Un tutoriel sur Microsoft Azure.

La même règle de précaution que pour AWS est à appliquer en termes de tarification.

3-5 - Oracle Cloud Infrastructure

Oracle est à l'origine une entreprise spécialisée dans la base de données. Oracle a racheté Sun qui proposait VirtualBox, hyperviseur de type 2, gratuit.

Oracle est arrivé sur le tard dans le monde du cloud par rapport à AWS ou Azure. Leur interface va proposer globalement le même type de services que ses concurrents.

Tout comme Microsoft facilite l'intégration de ses différents produits dans son cloud, Oracle va faciliter l’intégration des siens dans son cloud, notamment ses produits de bases de données.

Il est possible depuis les versions 6 de VirtualBox d'uploader une machine virtuelle vers le cloud Oracle. Il faudra auparavant préparer celle-ci (voir la documentation), et l'upload devra se faire lorsque la machine virtuelle est arrêtée. Vous pourrez aussi importer une machine virtuelle du cloud, ou directement en créer une dans le cloud Oracle depuis VirtualBox. Il est également possible de télécharger une machine virtuelle du cloud Oracle dans VirtualBox.

Le même principe de précaution au niveau de la tarification des ressources est à appliquer.

3-6 - Google Cloud Platform

Les services fournis par Google sur leur infrastructure Google Cloud Platform s'appuient sur la même infrastructure utilisée par G-Suite. Ils vous fourniront le même type de services que ses concurrents.

La grosse différence de Google étant la fourniture de l'infrastructure G-Suite sur leurs services.

La même de précaution au niveau de la tarification des ressources est à appliquer.

3-7 - Hadoop

Hadoop est un framework open source fourni par l’Apache Fundation. Ce framework est destiné au traitement de données de très gros volumes en facilitant la création d'applications distribuées. Il est utilisé dans les traitements big data.

Il se décompose en deux parties principales :

- HDFS : Hadoop Distributed File System : il s'agit du système de fichiers distribués stockant les données ;

- MapReduce : il s'agit du module de traitement de données proprement dit (composé de la fonction Map qui va effectuer la répartition du traitement et de Reduce qui réduira le résultat en une seule synthèse).

À cela peut être ajouté un module nommé Hbase, SGBD distribué non relationnel orienté colonnes.

Les principaux acteurs du cloud (Google, Amazon, OVH, etc.) sont en mesure d'offrir des instances Hadoop à leurs clients.

Hadoop n'est pas adapté à n'être utilisé qu'en système de fichiers.

4 - Les solutions d’autohébergement (utilisable en cloud)

L'autohébergement consiste à installer sur son propre matériel et avec une ou plusieurs solutions que vous gérerez, des services proposés par des hébergeurs ou grands acteurs du cloud.

Cette partie est présenté sans un tutoriel à part :

Solutions d'autohébergement.

5 - Étude de création de notre propre cloud

Nous allons ici étudier la mise en place de notre propre cloud. Ce service pourra servir à titre personnel ou à titre professionnel.

Notre cloud proposera les services suivants :

- la synchronisation/partage de documents ;

- la synchronisation de contacts et calendriers ;

- un serveur mail.

Ces services seront fournis soit par un seul produit, soit par une agrégation de produits. Le système pourra être réparti et redondant (voir les chapitres sur la répartition de charge et la haute disponibilité).

Par contre, nous ne verrons pas spécifiquement l'utilisation du cloud pour stocker une application métier, dans ce document. Tout ce qui est vu ici sera applicable pour une application métier.

Aussi, il est possible d’ajouter des clients lourds ou des applications accessibles à travers un site web et se connectant à un serveur proposant une base de données :

- des Content Management System (CMS) ou système de gestion de contenu tel que WordPress, Joomla ;

- des Customer Relationship Management (CRM) ou Enterprise Resource Planning (ERP), systèmes de gestion de clients tels que SugarCRM, Oddo (anciennement OpenERP) ;

- des boutiques en ligne comme Prestashop ;

- des systèmes de Gestion Électronique de Documents (GED) comme SeedDMS.

Des solutions en mode web seront plus faciles d'utilisation en cloud qu'un client lourd, mais rien n'empêche l'utilisation d'un client lourd tant que l’infrastructure le prévoit.

6 - Les briques minimales

Pour réaliser notre cloud, il nous faudra :

- un système de fichiers (filesystem) répartis et/ou distribué (chapitre 8) ;

- un système de centralisation de la gestion des accès (login/mots de passe), compatible avec tous les services utilisés, et répliqué (chapitre 9) ;

- des bases de données répliquées (chapitre 10) ;

- un système de répartition de charges / tolérance de panne (chapitre 11).

À ce stade, nous aurons notre plateforme IaaS/PaaS sur laquelle nous pourrons ajouter les logiciels permettant d'avoir notre plateforme SaaS.

Tous ces services pourraient être gérés sur une seule machine, votre propre matériel stocké dans le centre de données d'un hébergeur, sur une machine louée chez celui-ci, ou même en ligne dans vos locaux. Dans ce dernier cas, il ne s'agira pas de cloud.

Toutes les briques peuvent être stockées sur une seule machine, mais cela n'aura pas de sens en termes de cloud, car le but du cloud est de répartir la charge, ne pas avoir de points de défaillance, et pouvoir facilement modifier augmenter/diminuer les ressources.

Sur ces briques, nous utiliserons des services de :

- partage de fichiers ;

- gestion d'agenda et de contacts.

6-1 - Le cloud et la virtualisation

Il faut voir le cloud comme un accès à de la ressource et non à du matériel. Bien qu'il soit possible d'avoir un cloud ou de monter un cloud avec votre propre matériel dans une baie d’un centre de données, ou même chez vous, il est beaucoup plus simple d'avoir de la ressource virtualisée.

Un système de fichiers virtualisé permettra plus facilement de mettre en place une politique de redondance, de tolérance de panne et l'augmentation d'espace. L'usage de disques en RAID matériel vous permettra de pallier une panne disque, mais ne vous permettra pas d'agrandir facilement un volume. LVM vous permettra de facilement ajouter de l'espace en ajoutant par exemple un disque à un volume logique, vous permettra de facilement remplacer un disque en déplaçant son contenu d'un disque à l'autre, de créer des snapshots, voire d'utiliser un SSD en cache d'un disque mécanique. L’utilisation d’un système de fichiers distribué, comme nous allons le voir, vous permettra de gérer cela à plus grande échelle : il sera possible de sortir une machine contenant x disques du système pour la remplacer, et cela automatiquement. Le système de fichiers distribué se chargera de la répartition/duplication des données.

Même sans parler de cloud, utiliser un hyperviseur vous permettra de limiter le nombre de serveurs physiques à gérer (il faudra bien entendu une machine correctement dimensionnée) et de plus facilement le remplacer en déplaçant, d'une machine à l'autre, les machines virtuelles à chaud. Vous pourrez mettre en place une réplication et gérer de la répartition de charge.

L'intérêt d'utiliser des ressources mises à votre disposition par un hébergeur plutôt que votre propre matériel vous décharge de la surveillance matérielle de celui-ci, et vous permet de facilement augmenter ou diminuer les ressources que vous utilisez. La mise à disposition d'une machine virtuelle se fait en quelques minutes, voire quelques secondes ; solution qui vous demanderait en interne beaucoup de ressources ne serait-ce que par la préparation de templates (en temps passé et en matériel), vous monopolisant de la ressource pour un usage pas forcément fréquent. Chez un hébergeur, ce type de template n'occupe pas forcément de ressources de votre point de vue et n’est pas facturé si vous utilisez des templates prédéfinis par votre hébergeur.

6-2 - Et les conteneurs dans tout ça ?

Un conteneur peut être vu comme un système de virtualisation léger, qui va servir à virtualiser une application ou un service (au sens démon Unix) plutôt qu'un OS complet. Contrairement à une machine virtuelle, un conteneur va partager le noyau de l'hôte. C'est un cloisonnement moins strict, mais demandant moins de ressources.

Les conteneurs prennent de plus en plus d'ampleur, et la plupart des fournisseurs de cloud fournissent du Container as a Service (CaaS).

Kubernetes est le système d'orchestration faisant référence et à la mode. Il est utilisé par la plupart des services cloud. Il vous permettra de déployer et de surveiller vos conteneurs.

6-3 - Cadre des tests

Nos tests seront effectués depuis une distribution Debian 9 Stretch 64 bits. Au moment de la rédaction, Debian 10 Buster est la dernière version de la distribution, sortie le 6 juillet 2019. Celle-ci étant encore jeune, nous utilisons la version antérieure.

Les machines seront nommées srv1, srv2 et ainsi de suite. Aussi, le fichier hosts de chaque machine virtuelle doit permettre la correspondance entre l’adresse IP de la machine et son nom. Il est également possible d'utiliser un serveur DNS.

La compatibilité étant en général ascendante, le tutoriel pourra globalement s'appliquer aux versions système supérieures.

Les outils utilisés sont en général disponibles dans les autres distributions Linux.

Certaines commandes devront être adaptées comme remplacer :

/etc/init.d/mysql start

par :

service mysql start

ou :

systemctl mysql start

7 - Synchronisation de fichiers

Nous allons commencer par présenter la fonction me paraissant la plus simple à implémenter : la synchronisation de fichiers. Il s'agit globalement d'une des fonctions les plus utilisées par le grand public. Nous remplacerons ici les solutions grand public comme Dropbox ou Google Drive, ou les solutions similaires comme Owncloud/Nextcloud que nous avons déjà étudié.

Nous n'évoquerons dans cette partie que l'aspect brique minimal bas niveau de synchronisation.

Dans cette partie, nous ferons abstraction de l'aspect répartition de charge/haute disponibilité/tolérance de panne. Nous supposerons que votre système de synchronisation s'appuie sur une seule machine ou que le système de haute disponibilité est opérationnel.

Plusieurs produits de synchronisation de fichiers ont été testés :

- Seafile ;

- Syncthing ;

- SparkleShare ;

- Pydio.

Vous trouverez plus d'informations dans ce tutoriel sur la synchronisation de fichiers.

8 - Systèmes de fichiers distribués

Un système de fichiers distribué est un système ou le poste client accède à un espace de stockage virtuel unique. Les données peuvent être réparties/dupliqués sur plusieurs machines de façon transparente pour celui-ci. C'est le moteur du système de fichiers distribué qui a la charge de répartir les données et de les dispatcher au client.

Les systèmes de fichier distribués les plus répandus sont :

- Ceph ;

- GlusterFS ;

- Hadoop Distributed File System (HDFS) ;

- Lustre (utilisé par les super-calculateurs) ;

- NFS - Network File System.

Sur les tests effectués, il ressort deux approches :

- une approche en blocs (chunks) répartis sur plusieurs machines et pour lesquels les métadonnées peuvent être centralisées ou distribuées et permettent de reconstruire les fichiers ;

- une approche reposant sur la notion de fichiers et utilisant ou non des métadonnées. Certains nécessitent d'avoir une ou plusieurs machines dédiées aux métadonnées, d'autres permettant d'intégrer les métadonnées sur les machines stockant les données, ou éventuellement sur des machines autonomes.

Ceci a un impact sur le minimum de machines requis pour créer le système de fichiers distribués, sur la souplesse de retrait et d’ajout de machine, sur les performances, la maintenance et la sauvegarde.

Pour de plus amples informations, vous pouvez consulter la partie sur les systèmes de fichier distribués qui couvre couvre les systèmes de fichiers suivants :

- GlusterFS ;

- OCFS2 couplé à DRBD ;

- Ceph ;

- Minio.

En réalité, OCFS2 (Oracle Cluster File System) n'est pas un système de fichiers distribué, mais un système de fichiers gérant la concurrence d'accès aux fichiers entre plusieurs machines. Cela permet de gérer les accès concurrentiels, la répartition de charge sur plusieurs machines (deux dans notre cas) sera à gérer à part. C'est une approche intéressante pour un petit cloud.

Ceph, à son niveau le plus bas, va stocker des objets (des couples de clé/valeur). Un cache d'abstraction nommée RBD (Rados Block Device) fournira un accès en mode bloc. Par-dessus cela, CephFS fournira une abstraction permettant l'accès en mode fichier.

9 - Centralisation de la gestion des accès

Pour gérer la centralisation des accès, c’est-à-dire des identifiants et des mots de passe, j'ai testé NIS et LDAP.

9-1 - Installation de NIS

Network Information Service (NIS) est aussi connu sous le nom de Yellow Pages. Le service permet de distribuer les différents fichiers de configuration tels que /,etc/hosts /,etc/password sur différentes machines via le réseau. Ceci permet la recopie automatique des mots de passe et configurations entre différents hôtes. NIS est spécifique au monde Unix/Linux.

Dans notre exemple, nous fixerons le nom de notre première machine sur srv1.

Nous installons NIS :

apt-get install nis

il vous sera demandé le domaine NIS, nous utiliserons « cloudsrv ».

L'installation reste bloquée un moment sur :

Paramètrage de nis ...

mais finit par aboutir.

Avant toute chose, pour sécuriser le service, nous modifions le fichier /etc/ypserv.securenets et créons un fichier /var/yp/securenets, dans lequel nous n’autorisons que notre serveur et une seconde machine 192.168.1.200 qui sera utilisée dans les prochains tests :

host 127.0.0.1
host 192.168.1.200
host 192.168.1.201

Nous modifions ensuite le fichier /,etc/default/nis et remplaçons la ligne

NISSERVER=false

par :

NISSERVER=master

Nous redémarrons ensuite le serveur :

service nis restart

Nous initialisons ensuite la base de données :

/usr/lib/yp/ypinit -m

Vous devez ensuite entrer la liste des serveurs, terminée par Ctrl-D. Nous n'avons que le serveur local actuellement.

9-1-1 - Ajout d'un client NIS

Nous installons NIS sur la machine qui nous servira de client via apt-get install nis. Nous entrons le même domaine NIS que pour la première machine : cloudsrv. Ce serveur sera appelé srv2.

Il va nous falloir ensuite modifier le fichier /etc/nssswitch.conf et ajouter « nis » à la fin des lignes passwd, group, shadow (et des autres lignes si vous le souhaitez) :

passwd:         compat nis
group:          compat nis
shadow:         compat nis

Cela va permettre de rechercher les informations dans la base NIS en plus des fichiers standards.

9-1-1-1 - Test de connexion à un compte de test

J'ai fait une tentative de connexion avec un compte de test présent sur srv1 avant installation de NIS (et non présent sur srv2, le client).

La connexion fonctionne, avec le message :

Pas de répertoire, connexion avec HOME=/

Ce qui est logique, le dossier home de l'utilisateur n'existant que sur srv1. NIS recopie le fichier de mots de passe /,etc/passwd, mais ne va pas créer le dossier home sur un autre poste.

9-1-1-2 - Test de changement de mot de passe

Je tente de modifier le mot de passe depuis srv2 avec la commande passwd.

Ceci me retourne :

passwd : Erreur de manipulation du jeton d'authentification
mot de passe non changé.

Il n'est possible de modifier le mot de passe que depuis le serveur NIS.

Par contre, si vous modifiez le mot de passe sur le serveur, il faut ensuite lancer la commande :

cd /var/yp
make

make[1] : Entering directory '/var/yp/cloudsrv'
Updating passwd.byname...
Updating passwd.byuuid...
Updating netid.byname...
Updating shadow.byname... Ignored -> merged with passwd
make[1] : Leaving directory '/var/yp/cloudsrv'

Pourquoi ? Car NIS ne travaille pas directement avec les fichiers, etc/passwd, /,etc/group, etc., mais avec ses propres fichiers qui sont synchronisés avec la commande /var/yp/make.

9-1-1-3 - Ajout/suppression d'utilisateur

La règle est la même pour l'ajout et la suppression d’un utilisateur. Il faut faire l'opération avec les commandes habituelles et appeler : /var/yp/make.

9-1-2 - Ajout d’un serveur secondaire

Nous allons transformer srv2 en serveur NIS secondaire, nommé slave.

Cela est très simple, il suffit de modifier les lignes suivantes de /,etc/default/nis :

Je vais remplacer :

NISSERVER=

par :

NISSERVER=slave

et :

NISMASTER=

par :

NISMASTER=srv1

Ce dernier paramètre permettant de lancer ypinit à chaque démarrage de serveur (pour mettre à jour la synchronisation).

9-1-3 - Conclusion

L'arrêt du serveur master (srv1), et le passage du serveur slave en master ne m'a pas permis de m'authentifier avec un compte créé sur srv1.

NIS n'étant pas sécurisé (il reste possible d'ajouter un serveur Kerberos avec) et en voie d’abandon, je ne suis pas allé plus loin dans mes tests.

9-2 - LDAP

Lightweight Directory Access Protocol (LDAP) est une référence dans les services d’annuaire. Celui-ci permet à la plupart des serveurs (au sens logiciel) d'avoir une base de données centralisée incluant les utilisateurs, éventuellement leurs coordonnées, des machines, des ressources, etc. Active Directory de Windows Server s'appuie sur LDAP, la plupart des serveurs SMB, serveurs mails, serveurs d'impression, copieurs, peuvent s'authentifier à travers LDAP. Il est possible de s'authentifier sous Linux via LDAP également (ce que nous allons voir).

Sur une base LDAP vient se greffer des schémas. Ceux-ci vont définir des objets et des attributs venant s'intégrer dans la base LDAP. Des démons vont fournir des schémas pour intégrer des objets ou attributs à la base LDAP qu'ils vont ensuite utiliser.

Il est possible d'importer et d'exporter des données depuis un annuaire LDAP via des fichiers .ldif (LDAP Data Interchange Format).

LDAP est à mon avis difficile à prendre en main. C'est par contre la solution pour centraliser une authentification depuis plusieurs briques logicielles différentes. Il est également possible d'avoir un serveur de réplication, ce qui est dans le cadre de ce tutoriel indispensable pour assurer la redondance.

Les termes les plus courants utilisés par LDAP sont :

- dc: Domain Component ;

- dn: Distinguished Name ;

- cn: Common Name ;

- ou: Organisational unit.

Et voici un schéma sur l'organisation :

dc=FR
|
dc=EXEMPLE
/          \
ou=machines    ou=personnes
/              \
cn=ordinateur       cn=Jean

Ceci aboutissant à deux Distinguished Names :

- cn=ordinateur,ou=machines,dc=EXEMPLE,dc=FR

- cn=Jean,ou=personnes,dc=EXEMPLE,dc=FR

9-2-1 - Installation

Nous allons installer l’implémentation OpenLDAP via le paquet slapd (Stand-alone LDAP Daemon).

apt-get install slapd

Il vous sera demandé un mot de passe administrateur.

Nous configurons ensuite le service :

dpkg-reconfigure slapd

Le premier écran vous demande si vous voulez « omettre la configuration », il faut donc répondre « non » pour effectuer celle-ci :

Nous allons ensuite entrer le « nom de domaine » LDAP. Dans l'exemple je vais utiliser developpez.com.

Le second écran demande le nom de l'organisation, je saisis « developpez »

On vous demandera ensuite le mot de passe administrateur, ce qui est normal, car nous créons une nouvelle base. L'écran suivant demande le format de base de données à utiliser, nous laissons le choix proposé : MDB.

L'écran suivant demande s’il faut supprimer la base en cas de désinstallation de LDAP, et s’il faut déplacer l'ancienne base. Comme celle-ci est vide, nous pouvons répondre « non ».

9-2-2 - Installation de LAM (LDAP Account Manager)

Pour éviter de devoir utiliser des lignes de commande intégrant des fichiers .ldif pour l'ajout d'utilisateurs, nous allons utiliser LAM (LDAP Account Manager) qui permet de piloter la base LDAP depuis un navigateur web.

Il est tout à fait possible de se passer de LAM et d'utiliser des fichiers .ldif et les commandes Shell. Ce tutoriel ciblera uniquement l'utilisation de LAM.

Pour installer LAM :

apt-get install ldap-account-manager

Avant d'aller plus loin, nous allons commencer par activer le support de HTTPS. Si vous avez ajouté LAM sur une machine possédant déjà Apache avec un certificat, vous pouvez modifier directement le fichier VirtualHost. Sinon il va vous falloir installer un certificat ou en créer un autosigné.

Pour la création d'un certificat autosigné :

openssl req -new -x509 -days 365 -nodes -out /ets/ssl/certs/lam.crt -keyout /etc/ssl/private/lam.key

Nous activons ensuite le module SSL d'Apache :

a2enmod ssl

Modification de la configuration de LAM :

il va falloir éditer le fichier /etc/apache2/conf-enabled/ldap-account-manager.conf.

Nous entourons le contenu avec une balise <Virtualhost> et ajoutons les éléments de configuration SSL :

<VirtualHost *:443>
SSLEngine on
SSLCertificateFile /etc/ssl/certs/lam.crt
SSLCertificateKeyFile /etc/ssl/private/lam.key

… contenu original

</VitualHost>

Nous redémarrons Apache :

service apache2 restart

À ce stade, vous pourrez appeler LAM avec http://[adresse ip/nom DNS]/lam ou https://[adresse ip/nom DNS]/lam.

Il restera à éventuellement modifier la configuration pour forcer le passage en HTTPS.

Lors de la connexion, vous aurez l'écran suivant :

En lançant l'interface web, j'ai eu des messages d'erreur indiquant l'absence de support du XML et de zip avec ma version de PHP. Pour régler ce souci, il faut installer les paquets php-xml et php-zip et redémarrer Apache.

Passons à la configuration de LAM. Nous cliquons sur « Configuration de LAM » en haut à droite :

Il va nous falloir aller dans « modifier les profils » :

Le mot de passe par défaut est « lam », la première chose à faire est de le changer :

Ceci va changer le mot de passe de l'édition de profil. Nous allons ensuite créer un nouveau profil :

Configuration de LAM → Modifier les profils → Gestion des profils serveur :

Nous ajoutons un nouveau profil :

Il vous faudra entrer le mot de passe principal renseigné auparavant :

Nous passerons directement sur l'écran de configuration du nouveau profil :

Il va nous falloir effectuer les réglages suivants :

- suffixe d'arborescence : remplacer dc=yourdomain,dc=org par dc=developpez,dc=com (le domaine que nous avions paramétré étant developpez.com) ;

- paramètre de langue : sélection du langage par défaut ainsi que du fuseau horaire ;

- paramètres de sécurité-->liste des utilisateurs valides : remplacer cn=Manager,dc=my-domain,dc=com par cn=admin,dc=developpez,dc=com. (admin est l'utilisateur administrateur par défaut sur un serveur LDAP) ;

- puis le mot de passe.

Avant de valider, il va falloir effectuer des modifications dans l'onglet type de compte :

Il faut modifier les champs dc= des suffixes LDAP, pour les utilisateurs, les groupes, les machines, et les domaines Samba. Nous n'utiliserons que les suffixes utilisateurs (ou=People) et groupe (ou=group), mais fixons correctement les entrées machines et Samba, en cas d'utilisation ultérieure. Nous mettons dc=developpez,dc=com.

Une fois tous ces éléments entrés, vous pourrez vous connecter :

Pensez à retourner dans le gestionnaire de profil afin de supprimer le profil lam.

Lors de la première connexion, vous verrez l'écran suivant :

Si les éléments sont corrects, cliquez sur « Créer ». Vous aurez le message « Modifications effectuées avec succès ».

Il va nous falloir créer un groupe, sans quoi nous ne pouvons pas créer d’utilisateurs :

Je crée un groupe nommé « users ».

Nous voyons que l'opération est réussie, mais ne voyons pas le groupe. Un clic sur Groupes rafraîchira la page et nous verrons le groupe.

Nous créons ensuite un utilisateur « test ».

Beaucoup de champs sont à notre disposition, nous n'utiliserons que le champ nom (champ obligatoire).

Nous allons permettre plus tard une authentification Unix depuis ce compte (pour nos tests), il va falloir cliquer sur le bouton « Unix » à gauche. Vous verrez que le champ répertoire utilisateur est positionné sur /home/$user, le chemin normal des comptes utilisateurs dans une arborescence Unix, $user étant bien entendu remplacé par le nom de l'utilisateur. Si vous ne souhaitez pas qu'un utilisateur puisse lancer un Shell, il faudra positionner le champ Shell de connexion sur false.

Il vous faudra ensuite cliquer sur le bouton définir le mot de passe pour positionner celui-ci.

Et ensuite, dernière étape, enregistrer le compte en cliquant sur le bouton Sauvegarder.

En cliquant sur Vue arborescente en haut, vous aurez comme le nom l’identique, une vue arborescente, mais vous pourrez également importer et exporter des fichiers .ldif, et exporter également aux formats csv et vcard.

9-2-3 - Authentification Linux avec une base LDAP

PAM (Pluggable Authentication Modules) est l'API utilisée sous Linux permettant de déléguer l'authentification à plusieurs services différents (LDAP, NIS, bases de données au format Berkeley, etc.). Cette API nous permettra d'effectuer une authentification transparente avec un utilisateur de notre annuaire LDAP. Nous nous authentifierons avec un compte LDAP avec la simple commande login. nssswitch (Name Service Switch) va travailler en collaboration avec le service PAM pour se substituer ou modifier les fichiers de configuration password, shadow, hosts, aliases.

Nous aurons besoin pour cela du paquet libnss-ldapd et ses dépendances :

apt-get install libnss-ldapd

Le premier écran demandera l'adresse du serveur LDAP, nous remplaçons l'URL ldapi:// par ldap://127.0.0.1 pour une utilisation locale, et l'adresse IP du serveur depuis un poste client.

Sur le prochain écran, il faudra entrer le dn utilisé, soit : dc=developpez,dc=com :

Le paquet vous demande les services à activer, il faudra au minimum cocher password et shadow.

Une fois la configuration effectuée, vous pourrez vous loguer depuis la console avec le compte « test ».

Une fois logué, vous vous trouverez à la racine. Le dossier utilisateur n'a pas été créé. lam ne crée pas automatiquement celui-ci. Dans le cadre de notre tutoriel, cela est très bien. Si vous souhaitez gérer cela, consulter la documentation de lam.

Si vous changez le mot de passe avec la commande passwd, celui mettra bien à jour le compte ldap :

Une fois l'authentification LDAP activée, il ne sera toujours pas possible de s'authentifier avec le compte root local. LAM ne vous laissera pas créer un compte avec un UID inférieur à 10 000, empêchant la création d'un compte root dans LDAP.

Si vous souhaitez ajouter un compte, en cas d'utilisation de la commande adduser, vous pourrez constater que le compte est créé en local et non dans la base LDAP. Pour ajouter un utilisateur LDAP, il faut utiliser la commande lpadadd avec en paramètre un fichier ldif, d’où l’intérêt d'utiliser LAM pour simplifier l'opération.

La création d'un compte utilisateur LDAP ne déclenche pas la création du dossier de l'utilisateur. Ceci peut être fait en ajoutant la ligne suivante au fichier /etc/pam.d/common-session :

session     required      pam_mkhomedir.so skel=/,etc/skel umask=0022

9-2-4 - Authentification Mac OS avec une base LDAP

Mac OS permet de s'authentifier sur une base LDAP. La procédure est documentée ici. Mac OS peut se connecter sur un Active Directory et intègre dans sa version serveur Open Directory proposant des services similaires à Active Directory. Utiliser spécifiquement un serveur LDAP pour gérer la connexion utilisateur me parait faiblement justifié. Par ailleurs, les services tels qu'un serveur SMB ou serveur mail distant peuvent gérer de leur côté une authentification LDAP, transparente pour le client.

9-2-5 - Authentification Windows sur un serveur LDAP

Aspect serveur

Il est possible de faire agir un contrôleur de domaine comme un serveur LDAP à l'aide du service ADLDS (Active Directory Lightweight Directory Service). Cela peut être utilisé pour un produit compatible LDAP, mais non compatible AD.

Aspect client

Windows ne permet pas nativement la connexion à un serveur LDAP. Ceci est justifié par l’existence d'Active Directory. Il n'est possible de se connecter sur un AD qu'avec une version Windows Pro. Si vous êtes sur une version Home, vous pourrez vous connecter sur un dossier partagé par un serveur Windows, mais ne pourrez pas bénéficier de la centralisation d'administration apportée par Active Directory.

Il existe un produit libre nommé pgina qui permet une authentification LDAP (ainsi que d'autres connexions de type MySQL par exemple via des plugins).

9-2-6 - Sauvegarde restauration LDAP

9-2-6-1 - Par copie des fichiers

Il faudra arrêter le service et copier les fichiers de configuration présents dans /,etc/ldap, et les fichiers de base dans /var/lib/ldap.

Ces fichiers devront être restaurés à leur endroit respectif.

9-2-6-2 - Par import/export LDIF

L'export se fera par la commande :

slapcat -b rootsuffix -l fichier.ldif

L'import par :

slapadd -c -b suffixroot -l fichier.ldif

Le service ldap doit être préalablement stoppé.

Exemple de suffixroot : dc=exemple,dc=com.

9-2-7 - Serveur secondaire LDAP

Le principe sera d'avoir un autre serveur LDAP qui hébergera une copie du serveur LDAP principal. La synchronisation pourra se faire via syncrepl, fourni avec slapd.

syncrepl sera configuré dans le fichier /etc/ldap.conf.

Le serveur principal sera le serveur maitre, le second le serveur esclave. Il sera possible de faire une relation maitre-maitre avec une première relation maitre-esclave entre le premier et second serveur, configuré sur le premier serveur ; et une seconde relation maitre-esclave entre le second et le premier serveur, configuré sur le second serveur.

Ceci n'a pas été étudié dans le cadre de ce tutoriel.

Il reste également possible d'effectuer un import/export comme vu au chapitre précédent.

9-3 - Kerberos

Kerberos est un protocole d'authentification basé sur un échange de clés secrètes et générant des tickets d'authentification. Il ne vous servira pas à vous connecter directement, mais permettra à des services comme LDAP de vous identifier. Une fois authentifié, un ticket a une durée de vie et peut être invalidé, une reconnexion sera alors nécessaire.

Kerberos est assez répandu. Il est utilisé par l'Active Directory de Microsoft et il peut être utilisé avec LDAP (notamment via l'implémentation Linux Heimdal).

Voici comment fonctionne l’authentification Kerberos :

Kerberos se décompose en deux parties :

- Authentication Service (AS) : qui délivrera un ticket de demande d'accès en cas d'authentification réussie ;

- Ticket Granting Service (TGS) : qui fournira un ticket d'accès au service demandé.

Précisément, l'utilisateur s'authentifie auprès de l'AS via un ticket généré par son client Kerberos (couple login, mot de passe hashé (pas de mot de passe en clair), horodatage), si l'authentification est correcte, il reçoit un ticket TGT (clé de session TGS) : comparable à un contrôle d'identité par un vigile qui va vous délivrer un badge. Ce ticket n'est pas déchiffrable par l'utilisateur.

L'utilisateur va ensuite demander un ticket d'accès au TGS via la clé de session qu'il a reçue. Un peu comme une carte magnétique qui vous sera donnée en plus du badge par un second vigile après avoir passé le premier contrôle, et vous donnera accès à un étage ou non, carte magnétique délivrée en plus du badge et valable pour le porteur du badge pendant un temps précis et pour des choses précises.

Kerberos ne sert qu'à faire la preuve de votre identité. Les services utilisant Kerberos (exemple serveur de fichiers) sauront que vous avez été authentifié et que votre authentification est valide jusqu'à une heure précise, mais les droits d'accès restent à leur charge (dans le cas d'un serveur de fichiers un utilisateur A a accès au dossier X, mais pas au dossier Y).

Une extension à Kerberos nommée PKINIT permet de remplacer l'authentification via un couple login/mot de passe par une carte à puce.

9-4 - Windows Server

En environnement Windows, Active Directory va centraliser la gestion des ressources (serveurs, ordinateurs, utilisateurs, partages). Active Directory s'appuie sur une implémentation LDAP propriétaire et utilise Kerberos. Active Directory permet aussi le déploiement d'applications (ou de systèmes complets), de politiques de sécurité (pouvant être vues comme des réglages comme l'impossibilité d'accéder à la configuration système, à la ligne de commande, lancement d'une seule application sans accès au système notamment avec le bureau à distance, fond d'écran paramétré à distance, etc.). Une infrastructure AD part d'une racine nommée forêt, qui va contenir un ou plusieurs domaines (comme une arborescence DNS). Un domaine va contenir au minimum un serveur qui fera contrôleur de domaine. Si un seul serveur est présent dans l’infrastructure, il fera office de contrôleur de foret et contrôleur de domaine. Les objets d'un domaine sont répliqués entre les différents contrôleurs membres du domaine.

9-5 - Mac OS X

Mac OS Server intègre un système nommé OpenDirectory, fork d'OpenLDAP pour fournir son service centralisé d'authentification. OpenDirectory permet la connexion à un domaine Microsoft Active Directory.

Depuis Mac OS 10.8 Mountain Lion, Mac OS Server est une application à acheter sur l'Apple Store, qui devient une simple extension de Mac OS. Mac OS Server est depuis un moment en déclin notamment avec l'abandon des serveurs Apple Xserve. Mac OS High Sierra peut faire serveur Time Machine. La montée en puissance des NAS à prix abordable permettant l'utilisation de services proposés par Mac OS Server ne fait qu’accélérer son déclin.

9-6 - Bilan

NIS n'est pas réputé pour être très sécurisé. Il est envisageable de l'utiliser à travers un réseau sécurisé en VLAN en interne ou via un tunnel VPN entre plusieurs sites. Il est spécifique au monde Unix et est plus que déprécié. Cette solution ne sera pas utilisée dans un environnement cloud.

LDAP n'est pas simple à implémenter, mais à l’avantage d'être un standard très répandu.

10 - Réplication/clustering de bases de données

Nous verrons dans ce chapitre le cas des bases de données MySQL, mais le principe est applicable sur les autres moteurs de bases de données gérant cette possibilité.

10-1 - Réplication

Le principe de réplication va consister à garder une ou plusieurs copies des bases de données en les synchronisant entre plusieurs machines.

Cette réplication peut être de type :

- maitre-esclave ;

- maitre-maitre.

10-1-1 - Maitre-esclave

On écrit sur le maitre et on peut lire sur la ou les machines esclaves (ainsi que sur le maitre). La machine esclave peut-être considérée comme le client du maitre. Les esclaves sont en lecture seule.

10-1-2 - Maitre-maitre

Les deux machines ont en même temps le statut de maitre et d'esclave la machine A étant l'esclave de la machine B et vice-versa. Par conséquent, une modification effectuée sur B sera répercutée sur A et inversement.

10-1-3 - Détails

Les modifications effectuées sur un maitre sont synchronisées sur les autres membres du groupe de synchronisation. Les données peuvent être lues sur n'importe quelle machine, ce qui permet une répartition de charge et une tolérance de panne. Avec les dernières versions de MySQL, il est possible d’avoir plus de deux nœuds, mais il est conseillé d'utiliser un cluster.

Pour fonctionner en mode réplication, MySQL va écrire les modifications de la base dans des fichiers journaux (logs), qui seront transmis aux serveurs secondaires. Ceux-ci se mettront à jour depuis ces journaux en rejouant les modifications nécessaires depuis leur position actuelle dans ces logs vers la dernière position pour être à jour par rapport au serveur maitre. Une position peut être vue comme une ligne dans le journal.

10-1-4 - Activation de la réplication entre un maitre et un esclave

Pour activer les journaux, il est nécessaire de modifier la configuration de MySQL (/etc/mysql/my.cnf). Il faut décommenter la ligne commençant par log-bin. Profitons-en pour décommenter la ligne server-id, chaque serveur devant avoir un id différent.

j'en profite pour modifier la ligne :

bind-addess    = 127.0.0.1

par :

bind-addess    = 0.0.0.0

Par défaut, MySQL n'autorise l'accès qu'à l'adresse de loopback (127.0.0.1).

MySQL autorise soit une seule adresse, soit toutes les adresses. Il n'est pas possible de n'autoriser que deux adresses par exemple. C’est au niveau du pare-feu qu’il faudra gérer des plages d’adresses autorisées.

Ces réglages seront pris en compte après redémarrage du démon.

Pour nos tests nous utiliserons srv1 (192.168.1.200) en serveur maitre, et srv2 (192.168.1.201) en serveur esclave.

Une fois la modification du fichier de configuration effectuée, nous commençons par donner les droits de réplication à un utilisateur que nous nommerons « sync ».

mysql -u root -p
Enter password :
Welcome to the MYSQL monitor. Commands end with ; or \g.
Your MySQL connection id is 94
Server version: 5.5.59-0+deb8u1-log (Debian)

Copyright ( c ) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registerd trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

Myslq > GRANT REPLICATION SLAVE ON *.* TO ‘sync’@'192.168.1.201’ IDENTIFIED BY 'motdepasse';
Query OK, 0 rows affected (0.00 sec)

Nous forçons l'enregistrement des droits :

FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

Nous allons ensuite mettre un verrou sur les tables, le temps d'activer la réplication. À ce stade l'accès en écriture sera donc bloqué. Vous devrez donc avoir préparé srv2 avant pour minimiser le temps d’immobilisation.

FLUSH TABLES WITH READ LOCK;
Query OK, 0 rows affected (0.00 sec)

Nous allons ensuite relever la position actuelle dans les journaux :

mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000002 |    68145 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

Nous aurons besoin du nom du fichier journal (mysql-bin.000002 dans notre exemple) ainsi que de la position (68145 dans notre exemple).

Nous pouvons maintenant quitter le client MySQL avec exit.

Nous faisons ensuite un dump de nos bases :

mysqldump –all-databases -u root -p >export.sql
Enter password:
– Warning: Skipping the data of table mysql.event. Specify the –events option explicitly.

Nous pouvons ensuite lever le verrou sur les tables :

mysql > UNLOCK TABLES ;
Query OK, 0 rows affected (0.00 sec)

Nous transférons ensuite le dump sur srv2.

Avant de l'intégrer, nous modifions le fichier /etc/mysql/my.cnf pour changer le server-id (sans oublier de redémarrer le service).

Nous importons le dump :

mysql -u root -p <export,sql
Enter password:

Nous procédons ensuite à l'activation de la réplication. Voici les opérations à effectuer :

mysql> STOP slave;
Query OK, 0 rows affected, 1 warning (0.00 sec)

puis :

mysql> CHANGE MASTER TO MASTER_HOST='192.168.1.200',
-> MASTER_USER='sync',
-> MASTER_PASSWORD='motdepasse',
-> MASTER_LOG_FILE='mysql-bin.000002',
-> MASTER_LOG_POS=68145;
Query OK, 0 rows affected (0.10 sec)

Dans l'exemple ci-dessus, à la fin de la première ligne (après la virgule), un retour chariot a été fait, ceci afin de faciliter la lisibilité. Il aurait été possible d'écrire toute la requête sur la même ligne. Vous pouvez voir l'intégration de la position récupérée précédemment (nom du fichier et position).

Nous pouvons finalement démarrer l’esclave :

mysql> START slave;
Query OK, 0 rows affected (0.00 sec)

La base devrait être maintenant répliquée. Il est possible de contrôler le résultat avec la commande suivante :

mysql> SHOW SLAVE STATUS \g
+----------------------------------+-------------+--------------+-------------+---------------+------------------+---------------------+-------------------------+---------------+-----------------------+------------------+-------------------+-----------------+---------------------+--------------------+------------------------+-------------------------+-----------------------------+------------+------------+--------------+---------------------+-----------------+-----------------+----------------+---------------+--------------------+--------------------+--------------------+-----------------+-------------------+----------------+-----------------------+-------------------------------+---------------+---------------+----------------+----------------+-----------------------------+------------------+
| Slave_IO_State                   | Master_Host | Master_User  | Master_Port | Connect_Retry | Master_Log_File  | Read_Master_Log_Pos | Relay_Log_File          | Relay_Log_Pos | Relay_Master_Log_File | Slave_IO_Running | Slave_SQL_Running | Replicate_Do_DB | Replicate_Ignore_DB | Replicate_Do_Table | Replicate_Ignore_Table | Replicate_Wild_Do_Table | Replicate_Wild_Ignore_Table | Last_Errno | Last_Error | Skip_Counter | Exec_Master_Log_Pos | Relay_Log_Space | Until_Condition | Until_Log_File | Until_Log_Pos | Master_SSL_Allowed | Master_SSL_CA_File | Master_SSL_CA_Path | Master_SSL_Cert | Master_SSL_Cipher | Master_SSL_Key | Seconds_Behind_Master | Master_SSL_Verify_Server_Cert | Last_IO_Errno | Last_IO_Error | Last_SQL_Errno | Last_SQL_Error | Replicate_Ignore_Server_Ids | Master_Server_Id |
+----------------------------------+-------------+--------------+-------------+---------------+------------------+---------------------+-------------------------+---------------+-----------------------+------------------+-------------------+-----------------+---------------------+--------------------+------------------------+-------------------------+-----------------------------+------------+------------+--------------+---------------------+-----------------+-----------------+----------------+---------------+--------------------+--------------------+--------------------+-----------------+-------------------+----------------+-----------------------+-------------------------------+---------------+---------------+----------------+----------------+-----------------------------+------------------+
| Waiting for master to send event | 192.168.8.1 | sync |        3306 |            60 | mysql-bin.000003 |               19312 | mysqld-relay-bin.000003 |         19458 | mysql-bin.000003      | Yes              | Yes               |                 |                     |                    |                        |                         |                             |          0 |            |            0 |               19312 |           36625 | None            |                |             0 | No                 |                    |                    |                 |                   |                |                     0 | No                            |             0 |               |              0 |                |                             |                1 |
+----------------------------------+-------------+--------------+-------------+---------------+------------------+---------------------+-------------------------+---------------+-----------------------+------------------+-------------------+-----------------+---------------------+--------------------+------------------------+-------------------------+-----------------------------+------------+------------+--------------+---------------------+-----------------+-----------------+----------------+---------------+--------------------+--------------------+--------------------+-----------------+-------------------+----------------+-----------------------+-------------------------------+---------------+---------------+----------------+----------------+-----------------------------+------------------+
1 row in set (0.00 sec)

\g à la place de ; en fin de requête permet l'affichage en format vertical, facilitant ainsi la lecture.

10-1-5 - Activation de la réplication maitre-maitre

Une réplication maitre-maitre consiste à faire une réplication maitre-esclave du premier serveur vers le second, puis une autre du second vers le premier. Pour notre cas, nous reprenons l’état des serveurs comme à la fin de la section précédente : c’est-à-dire que la réplication maitre-esclave entre srv1 et srv2 est déjà en place. Nous allons donc en faire une entre srv2 et srv1.

Nous activons les logs sur srv2 comme vu précédemment.

Nous continuons par l'autorisation :

mysql> GRANT REPLICATION SLAVE ON *.* TO 'sync'@'192.168.8.200' IDENTIFIED BY 'motdepasse';
Query OK, 0 rows affected (0.00 sec)

Puis nous récupérons la position :

mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |      265 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

Nous appliquons ensuite cette position sur srv1 :

mysql> STOP slave;
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> CHANGE MASTER TO
-> MASTER_HOST='192.168.1.200',
-> MASTER_USER='sync',
-> MASTER_PASSWORD='motdepasse',
-> MASTER_LOG_FILE='mysql-bin.000001',
-> MASTER_LOG_POS=265;
Query OK, 0 rows affected (0.06 sec)

mysql> START slave;
Query OK, 0 rows affected (0.00 sec)

Il est possible d'ajouter d'autres serveurs sur le principe d'une réplication maitre-esclave entre deux machines et de façon bidirectionnelle comme vu précédemment. Mais dans la réalité, la lourdeur et les risques de problème rendent cette idée aberrante. Dans le cas de plus de deux machines, l'utilisation d'un cluster me parait indispensable.

10-2 - Le moteur Federated de Mysql Server

Le moteur Federated de MySQL Server permet de « voir » une table sur un serveur distant dans une base locale. Ceci n'a pas pour but d'apporter des fonctions de clustering, mais peut permettre par exemple la centralisation d'une table d'utilisateurs pour plusieurs serveurs.

Ce moteur comporte des contraintes :

- il faut démarrer MySql Server avec l'option –federated ;

- les transactions sont impossibles sur cette table ;

- pas de modification de la table en local, celle-ci doit impérativement être faite sur le serveur distant ;

- pas de cache de requêtes, les données proviennent de la base de données distante et ralentissent donc les lectures ;

- si le serveur distant est indisponible, la table FEDERATED l'est également.

Sa mise en place se fait comme suit :

Déclaration sur le serveur hébergeant la table :

CREATE TABLE test (
id     int(20) NOT NULL auto_increment,
nom   varchar(32) NOT NULL default '',
PRIMARY KEY  (id),
KEY name (name),
)
ENGINE=InnoDB;

Déclaration sur le serveur voulant utiliser la table distante :

CREATE TABLE test_distant (
id     int(20) NOT NULL auto_increment,
nom   varchar(32) NOT NULL default '',
PRIMARY KEY  (id),
KEY name (name),
)
ENGINE=FEDERATED
COMMENT='mysql://utilisateur@serveur:9306/federated/test';

10-3 - Clustering

Un cluster de bases de données est un système distribué dans une grappe de serveurs. Celle-ci va permettre la répartition de charge et la tolérance de panne. Le principe est similaire aux systèmes de fichiers distribués.

Pour mettre en place notre cluster de bases de données, nous utiliserons Galera Cluster.

Galera Cluster est un cluster libre pour MySQL. Il se compose de deux parties :

- de Galera ;

- d’une version de MySQL, fournie intégrant l'API WSREP.

Galera cluster est fourni avec MariaDB.

10-3-1 - Installation de Galera cluster avec MariaDB

Dans ce tutoriel, sur Debian Stretch, nous testerons Galera avec MariaDB, installé par défaut avec la commande apt-get install mysql-server.

10-3-1-1 - Création du cluster

La première étape consiste en la création d’un cluster, c’est-à-dire d’un ensemble de machines.

Voici un fichier de configuration nous permettant la création d'un cluster nommé par le nom très original « mon-cluster ». Cette configuration sera stockée dans le fichier /etc/mysql/conf.d/galera.cnf :

[mysqld]
query_cache_size=0
binlog_format=ROW
default_storage_engine=innodb
innodb_autoinc_lock_mode=2
innodb_doublewrite=1
bind-address=0.0.0.0
server-id = 1

# Configuration Galera
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_provider_options="gcache.size=4G"
wsrep_cluster_address=gcomm://
wsrep_cluster_name='mon-cluster'
wsrep_sst_method=rsync
wsrep_node_name='sql1'

# Tunning InnoDB à personnaliser selon ses besoins
#innodb_buffer_pool_size=4G
#innodb_file_per_table
#innodb_flush_log_at_trx_commit=2
innodb_log_file_size=100M

Pour plus de détails, je vous invite à consulter la documentation.

Les lignes importantes étant :

- binlog_format=ROW : activation des logs avec le format ROW, prérequis de Galera ;

- default_storage_engine=innodb : INNODB est le format de tables compatible avec Galera, c'est celui qui est utilisé par défaut avec MySQL à ce jour ;

- Bind-address=0.0.0.0 : permet au serveur d'être contacté par d'autres machines, nécessaire pour le dialogue entre les différentes machines du cluster. Par défaut, seul localhost peut dialoguer avec MySQL ;

Rappel : Il n'est pas possible de choisir les machines autorisées à dialoguer avec MySQL. C'est soit localhost, soit toutes les machines du réseau.

- wsrep_provider=/usr/lib/galera/libgalera_smm.so : c'est la ligne qui va charger les bibliothèques Galera ;

- wsrep_cluster_address=gcomm:// : sur cette ligne apparaîtra la liste des machines du cluster (noms ou adresses IP) ;

- wsrep_cluster_name='mon-cluster' : le nom du cluster ;

- wsrep_sst_method=rsync : c'est la méthode de transfert des changements entre les différents nœuds. rsync est l'option par défaut, les autres possibilités sont : mysqldump, xtrabackup (que nous verrons plus tard pour les sauvegardes) et xtrabackup-v2.

Une fois la configuration préparée, nous lançons la commande suivante :

/usr/bin/galera_new_cluster

Nous redémarrons mariaDB ;

service mysql restart

Nous testons l'état du cluster avec la commande suivante :

MariaDB [(none)]> SHOW STATUS LIKE  'wsrep_cluster_size';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 0     |
+--------------------+-------+
1 row in set (0.00 sec)

Notre cluster ne contient aucune machine.

Ceci est dû au fait que l'option wsrep_on est désactivée par défaut. Nous pouvons le voir avec la commande SQL suivante :

SHOW VARIABLES LIKE 'wsrep_on';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wsrep_on      | OFF   |
+---------------+-------+
1 row in set (0.00 sec)

Nous changeons la valeur de cette variable :

set GLOBAL wsrep_on=on;
Query OK, 0 rows affected (0.00 sec)

Nous pouvons vérifier le nouvel état de la variable wsrep_on :

SHOW VARIABLES LIKE 'wsrep_on';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wsrep_on      | ON    |
+---------------+-------+
1 row in set (0.00 sec)

Nous réinterrogeons wsrep_cluster_size, mais celle-ci est toujours à 0.

Nous plaçons la variable wsrep_on dans le fichier galera.cnf :

wsrep_on=on

Une fois le service redémarré, cela fonctionne :

MariaDB [(none)]> show variables like 'wsrep_on';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wsrep_on      | ON    |
+---------------+-------+
1 row in set (0.00 sec)

MariaDB [(none)]> show status like 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 1     |
+--------------------+-------+
1 row in set (0.00 sec)

À ce stable, nous avons un cluster SQL d'une machine.

Nous pouvons contrôler et voir l'état du cluster depuis des commandes SQL SHOW STATUS :

mysql> SHOW STATUS LIKE 'wsrep_local_state_comment';
+---------------------------+--------+
| Variable_name             | Value  |
+---------------------------+--------+
| wsrep_local_state_comment | Synced |
+---------------------------+--------+
1 row in set (0,01 sec)

Nous créons ensuite une base de test avec quelques enregistrements.

10-3-1-2 - Ajout d'une seconde machine au cluster

Comme pour la première machine, nous installons le paquet mysql-server. Cette seconde machine sera appelée, sans surprise, srv2. Nous recopions ensuite les fichiers /etc/mysql/conf.d/galera.cnf présents sur le premier serveur sur le nouveau serveur.

Nous ajoutons le nom de la première machine srv1 (nom déterminé par le fichier host de la première machine) sur la ligne wsrep_cluster_address=gcomm:// sur ce nouveau serveur.

Ce qui donnera :

wsrep_cluster_address=gcomm://srv1

Nous modifions également le server-id :

server-id = 2

Nous redémarrons ensuite le serveur MySQL de srv2 :

/etc/init.d/mysql restart

Le démarrage prend un peu de temps, les bases devant se synchroniser.

Une fois la synchronisation effectuée, nous pouvons constater le fonctionnement en affichant les précédentes variables :

MariaDB [(none)]> SHOW STATUS LIKE 'wsrep_local_state_comment';
+---------------------------+--------+
| Variable_name             | Value  |
+---------------------------+--------+
| wsrep_local_state_comment | Synced |
+---------------------------+--------+
1 row in set (0.01 sec)

MariaDB [(none)]> show status like 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 2     |
+--------------------+-------+
1 row in set (0.01 sec)

Un SHOW DATABASE depuis le second serveur nous montrera la présence de la base de test.

En allant consulter le dossier où MariaDB stocke les bases (/var/lib/mysql par défaut), nous pouvons constater la présence d'un dossier test contenant db.opt, essai.frm, essai.ibd (ma base de test contient une table nommée essai).

Si nous ajoutons une entrée dans la base, nous pourrons immédiatement constater sa présence sur l'autre machine.

10-3-2 - Clustering Galera Cluster avec MySQL

Nous commencerons par l'installation des clés de dépôts :

apt-key adv --keyserver keyserver.ubuntu.com --recv BC19DDBA

Vous pourrez constater que le serveur de clés utilisé est celui d'Ubuntu. Cela ne posera pas de problèmes pour une installation sous Debian. C’est d’ailleurs la procédure d’installation officielle.

Ensuite, nous pouvons ajouter les dépôts de Galera dans le fichier /etc/apt/sources.list :

deb http://releases.galeracluster.com/mysql-wsrep-VERSION/DIST RELEASE main
deb http://releases.galeracluster.com/galera-3/DIST RELEASE main

N'hésitez pas à consulter la documentation officielle, les versions peuvent évoluer, et les noms de dépôts évoluer en conséquence.

Pour notre exemple nous utiliserons :

deb http://releases.galeracluster.com/mysql-wsrep-5.7/debian stretch main
deb http://releases.galeracluster.com/galera-3/debian stretch main

Après un apt-get update, nous installons les paquets nécessaires :

apt-get install mysql-wsrep-5.7 galera-3 galera-arbitrator-3

Contrairement à MariaDB, il vous sera demandé un mot de passe root pour MySQL. Sous MariaDB, l'utilisateur root peut se connecter par défaut au client MariaDB sans authentification.

Si vous aviez une autre version de MySQL d'installée, celle-ci sera remplacée. J'ai testé le remplacement d’une version MySQL classique ayant des données et ceci n'a créé aucune perturbation. Je recommande évidemment d'effectuer une sauvegarde avant toute manipulation.

Il va ensuite falloir créer le cluster. Pour ceci, j'utilise le même fichier de configuration que pour MariaDB.

J'arrête le serveur :

service mysql stop

Je le redémarre ensuite avec l'option permettant la création du cluster :

mysqld_bootstrap

Ceci va démarrer le démon MySQL avec l'option -–wsrep-new-cluster.

Tout comme avec MariaDB, nous pourrons interroger les variables wsrep_cluster_size et wsrep_local_state_comment pour vérifier l’état de notre cluster et le nombre de machines l’intégrant.

Contrairement à MariaDB, il n'y a pas de variable ws_on à activer.

10-3-3 - Maintenance : perte de srv2

Le processus de remise en service sera le même avec MariaDB qu’avec MySQL.

Avec la configuration actuelle, l’arrêt ou la perte de sql2 empêche l’utilisation de sql1.

Une requête SELECT nous retournera l'erreur :

MariaDB [test]> select * from essai;
ERROR 1047 (08S01): WSREP has not yet prepared node for application use
MariaDB [test]>

Pour réactiver le cluster avec le seul nœud srv1, il va falloir modifier le fichier /var/lib/mysql/grastate.dat et remplacer :

safe_to_bootstrap : 0

par :

safe_to_bootstrap : 1

Il faut modifier le fichier lorsque le serveur SQL est arrêté. Une fois le serveur relancé, les bases seront à nouveau disponibles.

10-3-3-1 - Remontage de srv2

Pour remonter srv2, il faut considérer la machine comme nouvelle et y recopier le fichier /etc/mysql/conf.d/galera.cnf.

Il faudra mettre à jour la ligne wsrep_cluster_address=gcomm:/ dans le fichier /etc/mysql/conf.d/galera.cnf et y ajouter srv1. Il faudra également mettre à jour le server-id.

Une fois les fichiers de configuration prêts, un démarrage du service déclenchera la synchronisation.

La synchronisation effectuée repositionnera la valeur safe_to_bootstrap du fichier /var/lib/mysql/grastate.dat à 0.

10-3-4 - Maintenance : perte de srv1

La procédure de reprise sera exactement la même que pour srv2, la seule différence se trouvant dans la ligne wsrep_cluster_address qui doit être vide sur le poste « maitre » (l'initiateur du cluster), et le définir correctement pour le ou les autres serveurs.

10-3-4-1 - Remise de srv1 en maitre

Nous arrêtons srv1 (l’esclave), puis srv2 (le maitre), le sens « maitre-esclave » ayant été inversé avec la réinstallation de srv1. Ceci n'est pas forcément utile.

Il suffira de modifier la ligne wsrep_cluster_address=gcomm:/ dans les fichiers /etc/mysql/conf.d/galera.cnf des deux machines pour remettre l'ordre voulu. Sur le maitre, la ligne wsrep_cluster_address=gcomm : doit être vide. L’esclave doit y spécifier l’adresse du maitre. Ensuite, il faut définir la variable safe_to_bootstrap à 1 sur le serveur maitre. Finalement, il faut redémarrer les serveurs dans l’ordre (maitre puis esclave).

10-3-5 - Ajout d'un nouveau serveur

Pour ajouter des serveurs supplémentaires, la méthode sera la même. Il faudra insérer toutes les machines dans la ligne wsrep_cluster_address:// de chaque serveur.

10-3-6 - Galera arbitrator

Le Galera arbitrator est un outil à part, fourni avec Galera Cluster. Celui-ci permet comme son nom l’indique d’arbitrer le cluster. Le démon Galera Arbitrator se nomme garbd. Il n’est pas configuré par défaut. Sa configuration est simple, il faut éditer le fichier /,etc/default/garb.

Il faudra décommenter les lignes :

GALERA_NODES

et :

GALERA_GROUP

GALERA_GROUP devra contenir le même nom du cluster mentionné dans la ligne wsrep_cluster_name du fichier de configuration de Galera.

Il va gérer la notion de quorum (rôle d'arbitrage). En cas de coupure de liaison entre deux centres de données, ceux-ci vont pouvoir continuer à fonctionner chacun de leur côté et donc de manière indépendante. En conséquence, les données vont commencer à différer. Cette situation se nomme Split Brain : chaque serveur pense que l'autre ne fonctionne plus. Soit, les serveurs vont s'arrêter ou passer en lecture seule, soit ils vont fonctionner de façon autonome et cela posera un problème. Quel sera le nœud dont les données sont légitimes ? C’est là qu’intervient le quorum : en étant une machine indépendante, il y aura toujours une autorité contrôlant la légitimité des données. Si le quorum de machines minimal n'est pas présent, ou qu'une machine ne peut pas contacter la machine gérant le quorum,le système va se bloquer ou passer en lecture seule.

Avec trois serveurs, vous n’aurez pas besoin de l’arbitrator. Il est réellement nécessaire dans deux cas :

- vous avez un nombre pair de nœuds ;

- vous effectuez des sauvegardes via la méthode State Snapshot Transfer (SST).

10-3-7 - Perte d’un nœud dans une configuration à plus de deux machines

La perte d’un des serveurs est transparente pour l’utilisation de la base, celle-ci sera simplement indisponible depuis le serveur tombé. Si le serveur revient en ligne, il se resynchronisera. Dans le cas où la synchronisation est impossible (position trop ancienne par rapport aux logs par exemple), celui-ci ne démarrera pas. Il faudra alors refaire la configuration.

10-3-8 - Percona XtraDB cluster

Ayant évoqué Percona XtraBackup, je ne pouvais pas ne pas évoquer Percona XtraDB Cluster.

Son utilisation est identique à Galera cluster, Percona XtraDB Cluster utilisant la Galera Library et fournissant Percona XtraBackup.

Percona XtraDB Cluster peut utiliser le moteur InnoDB ou utiliser son propre moteur XtraDB, une version améliorée d'InnoDB.

Je vous laisse vous référer à sa documentation pour l’installation, celle-ci étant quasi identique.

10-4 - Sauvegardes/restaurations

10-4-1 - Sauvegarde par mysqldump

Pour effectuer une sauvegarde simple et efficace, il suffit de taper la commande :

mysqldump –all-databases -u root -p mot_de_passe >fichier.sql

L’option -all-databases permet de sauvegarder toutes les bases, il est possible de n’exporter qu’une seule base via :

mysqldump -u root -p mot_de_passe nom_de_la base>fichier.sql

Le fichier .sql créé est un simple fichier texte qui contiendra toutes les commandes pour recréer la base et la réalimenter avec son contenu.

10-4-2 - Restauration d'une sauvegarde mysqldump

La restauration se fera avec la commande :

mysql -u root -p mot_de_passe <fichier.sql

ou en cas de base unique :

mysql -u root -p mot_de_passe nom_de_la_base <fichier.sql

Par défaut, si la base existe déjà lors d'un import mysqldump, MySQL écrasera l'ancienne base.

mysqldump, effectuant un dump sur la sortie standard (stdout), il est possible de le compresser à la volée via une commande du type :

mysqldump –all-databases -u root -p mot_depasse |gzip >fichier.sql.gz

et de la restaurer via :

zcat fichier.sql.gz| mysql -u root -p mot_de_passe

mysqldump permet de ne sauvegarder qu’une table précise, mais cela ne sera pas abordé dans ce tutoriel, l’idée étant d’avoir une sauvegarde complète.

L’avantage de la méthode mysqldump est sa simplicité et sa fiabilité. L’inconvénient est que le temps du dump, la base est bloquée.

Pour éviter cette situation, il faut utiliser des outils spécialisés permettant une sauvegarde sans interruption. Percona XtraBackup est l’un d’entre eux.

10-4-3 - Sauvegarde avec Percona XtraBackup

Percona XtraBackup s’installe depuis un fichier .deb disponible sur le site :https://www.percona.com/downloads/Percona-XtraBackup-LATEST/

10-4-3-1 - Réalisation d'une sauvegarde complète

Celle-ci s’effectua avec la commande :

xtrabackup --backup –target-dir=backup-full –user=utilisateur --password=mot_de_passe

backup-full étant le dossier où nous effectuerons la sauvegarde.

Il est possible de stocker les identifiants dans un fichier /etc/mysql/conf.d/xtrabackup.cnf ayant pour contenu :

[xtrabackup]
user=<utilisateur>
password=<mot de passe>

La commande doit se terminer avec une ligne :

completed OK!

Il est à noter que la sauvegarde va inclure le fichier my.cnf.

10-4-3-2 - Restauration d'une sauvegarde complète

Pour restaurer une sauvegarde effectuée avec XtraBackup, il est nécessaire de l’installer sur le poste de destination. De plus, il faut préparer la sauvegarde avec la commande :

xtrabackup --prepare --target-dir=backup-full

devant toujours se terminer par :

completed OK!

Ceci va utiliser les journaux pour mettre à jour la ou les bases par rapport aux commits et rollbacks. Ensuite, pour intégrer les données sauvegardées, il faut que le serveur soit arrêté :

service mysql stop

Nous supprimons ensuite le contenu de /var/lib/mysql.

Nous partons ici du postulat d'une restauration de toutes les bases. En cas de restauration d'une seule base parmi d'autres, il ne faudra effacer que la base concernée.

Nous appliquons ensuite la commande de restauration proprement dite :

xtrabackup --copy-back --target-dir=backup-full

Ensuite, il ne reste plus qu’à mettre les bons droits sur les fichiers :

chown -R mysql:mysql varlib/mysql/*

À moins d'avoir utilisé le même compte que mysql pour effectuer la sauvegarde/restauration.

Il nous restera alors à redémarrer le service :

service mysql start

10-4-3-3 - Sauvegarde incrémentale

Une sauvegarde incrémentale va s’appuyer sur une première sauvegarde totale en lui appliquant des deltas, il faut donc commencer par effectuer une sauvegarde complète :

xtrabackup --backup --target-dir=backup-full

Effectuer une sauvegarde incrémentale n’est guère plus compliqué :

xtrabackup --backup –target-dir=backup-increment1 --incremental-basedir=backup-full

La sauvegarde complète de base se trouvant dans le dossier backup-full, le delta correspondant à la sauvegarde incrémentale se trouvant dans le dossier backup-increment1. La sauvegarde incrémentale est bien sûr inexploitable sans la sauvegarde de base.

10-4-3-4 - Restauration incrémentale

Nous commençons par préparer la sauvegarde de base :

xtrabackup --prepare --apply-log-only --target-dir=backup-full

Nous appliquons ensuite le delta de la sauvegarde incrémentale :

xtrabackup --prepare --apply-log-only –target-dir=backup-full --incremental-dir=backup-increment1

Il nous faudra ensuite effectuer les mêmes opérations que pour une restauration complète, vues précédemment :

- arrêt du service MySQL après préparation de la sauvegarde ;

- suppression ou sauvegarde du contenu de /var/lib/mysql ;

- application de la commande de restauration (xtrabackup --copy-back –target-dir=backup-full) ;

- application des droits.

Lisez attentivement ce qui concerne l'option -–apply-log-only dans le chapitre suivant.

10-4-3-5 - Chaînage de plusieurs sauvegardes

Il est possible de chaîner les sauvegardes. Ceci permet de réduire la taille globale de la sauvegarde, d'avoir un versionning, mais nécessite de restaurer tous les points de sauvegarde, un par un, dans le bon ordre.

Le processus de sauvegarde, étalé dans le temps doit ressembler à :

xtrabackup --backup –target-dir=backup-full
xtrabackup --backup –target-dir=backup-increment1 –incremental-basedir=backup-full
xtrabackup --backup –target-dir=backup-increment2 –incremental-basedir=backup-increment1

Vous pouvez voir que la seconde sauvegarde incrémentale utilise la première comme base.

La restauration se fera de la façon suivante :

xtrabackup --prepare --apply-log-only –target-dir=backup-full
xtrabackup --prepare --apply-log-only –target-dir=backup-full –incremental-dir=backup-increment1
xtrabackup --prepare  -–target-dir=backup-full –incremental-dir=backup-increment2

--apply-log-only doit être absent du dernier point de restauration.

Il m’a été possible de restaurer le point increment1 en omettant --apply-log-only. Il est donc possible de s’arrêter à une version précise tant que toutes les versions intermédiaires précédentes sont restaurées.

Je vous recommande d'utiliser des dates dans les noms des dossiers de sauvegardes incrémentales, ce qui vous permettra de facilement effectuer une restauration en appliquant les deltas dans le bon ordre.

Je vous invite à consulter les liens suivants :

https://www.percona.com/doc/percona-xtrabackup/LATEST/backup_scenarios/incremental_backup.html

https://www.percona.com/doc/percona-xtrabackup/LATEST/backup_scenarios/full_backup.html#full-backup

10-5 - Autres bases que MySQL

PosGresSQL intègre la gestion de réplication. Le fonctionnement est similaire aux clusters MySQL en se basant sur les journaux de transactions.

Documentation sur la haute disponibilité, la répartition de charges, et la réplication pour PostGresSQL.

Microsoft SQL Server permet également la mise en place d'un cluster. Ceci se fera avec le rôle AD « cluster de basculement » (Failover Clustering).

11 - Haute disponibilité

Un service est dit hautement disponible si sa moyenne de fonctionnement est supérieure à 99 % du temps.

Il est courant d'avoir des services proposés avec une disponibilité de 99,9% ou plus.

Un taux de disponibilité de 99 %, soit proche de 100 % représente une moyenne d'indisponibilité de trois jours par an, sept heures par mois, quinze minutes par jour.

Il s'agit d'une moyenne pouvant ne pas signifier grand-chose. Une panne pendant trois jours consécutifs sur un service aura un impact significatif au moment de celle-ci, mais pas sur le taux de disponibilité annuel, contrairement à une panne de trois jours étalés sur plusieurs heures ou plusieurs minutes sur l'année.

Sur un service mondial, une panne peut se présenter sur une zone géographique (régulièrement vu avec les services des GAFA) et ne pas impacter les autres régions, et donc avoir globalement une faible répercussion et ne pas impacter le taux de disponibilité, mais localement présenter un problème significatif.

Par ailleurs, si un dysfonctionnement des services mails de quelques minutes ou dizaines de minutes se verra à peine, voire pas du tout si les serveurs mails ne retournent pas d'erreur de connexion aux clients de messagerie, ce ne sera pas le cas pour un service utilisé massivement comme CloudFront ou Amazon S3 qui aura un impact immédiat sur un nombre considérable de services dont la cause de leur panne sera liée à un fournisseur externe.

Pour avoir un service à haute disponibilité, il ne faut aucun point de défaillance unique.

Exemples de point de défaillance unique :

- disque dur sans utilisation de RAID dans une machine ;

- une machine non répliquée et sans système de surveillance et de bascule ;

- une seule connexion vers Internet ;

- pas de serveur DNS secondaire ou sur le même réseau ;

- pas de redondance électrique en cas de coupure de courant (groupe électrogène) ;

- pas de redondance d'un système de refroidissement dans une salle serveur ;

- dépendance à l'utilisation de service externe (S3, CloudFront, etc.).

11-1 - Répartition de charge

La répartition de charge (appelé aussi load balancing) permet :

- d’étaler la charge de travail sur plusieurs systèmes ;

- rendre transparent une panne matérielle ou au moins faire en sorte qu'il n'y ait pas de coupure de service, même si le service peut être dégradé.

Un load-balancer a pour rôle de répartir la charge de travail entre les différents nœuds participants. Il pourra utiliser un algorithme simple dit statique comme utiliser les machines à tour de rôle ou utiliser un algorithme dit dynamique qui va s'adapter à la situation.

11-2 - Redondance

Pour qu'un système à charge répartie puisse rester en ligne, il ne doit y avoir aucun point de défaillance. Cela signifie que tous les éléments indispensables au système doivent être redondants, comme un nombre suffisant de machines sur un système de fichiers répartis, une redondance sur le système de load balancing, une redondance électrique ou de datacenter.

11-3 - Les politiques de load balancing les plus connues

11-3-1 - Le DNS Round-Robin

Le Round-Robin est un algorithme d'ordonnancement qui fait tourner des processus au sein d'une file d'attente dans un système à temps partagé.

Appliqué aux DNS, plusieurs machines (du moins leur adresse IP) vont être affectées à un FQDN.

À chaque requête DNS, une IP différente est retournée par la rotation des adresses enregistrées. Le client gardera ensuite cette IP dans son cache DNS.

Le fait que les DNS présentent des machines différentes de façon tournante lorsqu'une requête leur est faite va générer automatiquement une répartition de charge.

En cas de panne d'une machine, il sera nécessaire à un client déjà connecté de refaire une requête DNS pour obtenir une des autres adresses disponibles.

En cas de suppression d'une machine, ou de l'ajout d'une machine supplémentaire, la modification ne sera prise en compte qu'une fois le TTL de l'enregistrement DNS expiré.

Le point de défaillance est le serveur DNS lui-même, censé être pallié par un DNS secondaire.

11-3-2 - Heartbeat

Heartbeat que l'on peut traduire par prise de pouls va surveiller la disponibilité de plusieurs serveurs. Ceux-ci vont communiquer depuis une interface réseau en UDP ou via un lien série. Le système sera accessible par une adresse IP que nous appellerons virtuelle. Elle sera le point d'entrée du service.

Chacun aura sa propre IP et une seule machine, la machine maitre aura l'IP sur laquelle se trouve le service (exemple un serveur web). Si le serveur maitre tombe, un des autres serveurs le détectera, deviendra le maitre et prendra l'IP virtuelle.

Il est possible de faire de la répartition de charge. Le gestionnaire servira à répartir cette charge. En cas de panne d'une des machines accueillant celle-ci, la charge sera distribuée aux autres. Le gestionnaire devra être redondé sous peine de service coupé en cas de panne de celui-ci.

Les algorithmes de répartition de charges suivants sont disponibles :

- Least-Connection (lc) : envoi de la demande vers la machine la moins chargée ;

- Weighted Least-Connection (wlc) : envoi de la demande vers la machine avec le moins de connexions ;

- Round-Robin (rr) : envoi de la demande à tour de rôle (vu au chapitre précédent) ;

- Weighted Round-Robin (wrr) : round robin pondéré ;

- Locality-Based Least-Connection (lblc) : envoi des demandes d'un client toujours vers la même destination en favorisant les machines qui ont le moins de connexions ;.

- Destination-Hashing (dh) : envoi des demandes d'un client vers une des destinations selon une table de hashage sur la destination ;

- Source-Hashing (sh) : envoi des demandes d'un client vers une des destinations selon une table de hashage sur la source ;

- Shorted Expected Delay (sed) : envoi sur le serveur qui doit statistiquement répondre le plus vite ;

- Never Queue (nq) : envoi de la demande sur un serveur inutilisé ou sinon vers le Shorted Expected Delay.

11-3-2-1 - Exemple avec un serveur web

Nous préparons deux machines hébergeant un serveur web Apache et distribuant la même page HTML de test. Ces machines ont comme adresses IP 192.168.1.201 et 192.168.1.202. L'adresse 192.168.1.200 sera réservée au point d'entrée HeartBeat.

Pour facilement repérer le serveur actif, la page de test du 1er serveur affichera Essai 1, la page de test du second, Essai 2. Nous fixerons en conséquence les fichiers /,etc/hosts ainsi que le hostname.

Sur ces deux machines, nous aurons une carte réseau supplémentaire sur un autre réseau, cartes réservées au dialogue HeartBeat. Nous utiliserons pour ceci les adresses 10.1.1.1 et 10.1.1.2.

Commençons par installer Heartbeat sur la première machine :

apt-get install heartbeat

Il va ensuite falloir créer trois fichiers de configuration :

- /etc/heartbeat/ha.cf : c'est le fichier de configuration principal, il va contenir les paramètres du cluster ;

- /etc/heartbeat/haressources : ce fichier va décrire les opérations à effectuer ;

- /etc/heartbeat/authkeys : ce fichier va contenir les réglages de sécurité.

Commençons par le fichier /etc/heartbeat/ha.cf :

logfile         /var/log/ha-log
keepalive       2
deadtime        10
bcast           eth1
node            srv1 srv2
auto_failback   no
respawn         root /usr/lib/heartbeat/ipfail
apiauth         ipfail gid=root uid=root

Explications :

- logfile : nom et emplacement du fichier de logs ;

- keepalive : intervalle de prise de pouls (en secondes, ajouter ms pour mettre en microsecondes) ;

- deadtime : temps nécessaire pour déclarer un nœud HS ;

- bcast : interface réseau utilisée pour faire la prise de pouls (dans notre cas, la seconde carte avec l'adresse en 10.1.1.x) ;

- node : les noms DNS des machines ;

- auto_failback : si positionné sur no, ne repasse pas la machine maitre en mode actif après remise en ligne ;

- respawn : permet de lancer un programme au démarrage de HeartBeat (1er paramètre : le nom d'utilisateur. Nous lançons ici ipfail, permettant de ne pas attendre de pulsations avant de prendre la main en cas de lien HS) ;

- apiauth : indique les utilisateurs autorisés à dialoguer avec les logiciels lancés par respawn, dans notre cas uniquement root.

Nous continuons ensuite avec le fichier /,etc/heartbeat/haressources :

srv1 Ipaddr::192.168.1.200 apache2

Chaque action à appliquer doit être séparée par un espace, nous indiquons ici pour srv1 l'adresse IP à utiliser soit 192.168.1.200, puis le service à démarrer : apache2.

Si nous avions d'autres services à activer, il aurait fallu les indiquer les uns derrière les autres.

En action, il est également possible de monter un système de fichiers. Voici un exemple avec le montage d’un NFS :

srv1 Filesystem::192.x.x.x:/partage_distant::/point_de_montage::nfs

La documentation décrit les actions possibles.

Pour plus d'informations : http://linux-ha.org

Et enfin le dernier fichier : /etc/heartbeat/authkeys :

auth 1
1 sha1 "le precieux"

Nous déclarons ici utiliser le protocole sha1 avec le mot de passe ajouté en paramètre. La ligne auth 1 étant un index pour le cas où plusieurs clés sont utilisées (non abordé dans ce tutoriel).

Les protocoles utilisables sont :

- crc : ne nécessite pas de clé, non sécurisé, utilisable dans le cas d'une liaison par port série ;

- md5 :faiblement sécurisé ;

- sha1 : plus sécurisé que md5, mais demande plus de ressources CPU.

Nous changeons les droits du fichier :

chmod 600 /,etc/heartbeat/haresources

Nous désactivons ensuite le démarrage automatique d'Apache :

systmctl disable apache2

Nous arrêtons également le service :

systemctl stop apache2

Nous lançons maintenant HeartBeat :

systemctl start heartbeat

Après son démarrage, le serveur web répond sur l'adresse 192.168.1.200 ainsi que sur son adresse d'origine 192.168.1.201.

ifconfig nous fait apparaître une interface supplémentaire : eth0:0

...
eth0:0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 192.168.1.200  netmask 255.255.255.0  broadcast 192.168.1.255
ether 08:00:27:ba:77:c4  txqueuelen 1000  (Ethernet)
...

Le système fonctionnant, nous l'activons au démarrage :

systemctl enable heartbeat

Nous recopions les fichiers de configuration sur la machine srv2 (192.168.1.202) précédemment préparée (serveur web configuré, heartbeat installé).

Nous modifions le fichier /,etc/heartbeat/haresource pour remplacer l'entrée srv1 par srv2.

Après démarrage du service sur srv2, pour tester, nous arrêtons srv1. Le serveur web répond toujours et nous pouvons constater le changement de machine par l'affichage de Essai 2 au lieu d'Essai 1.

En interrogeant HeartBeat sur son état avec :

cl_status hbstatus -v

Nous voyons que srv1 est inactif.

version:        3.0.6 (node: 958e11be8686759f1b99204c17812f2c2633b169)
managed by:     "haresources"

srv2    active  (nodetype: normal)
eth1    up

srv1    dead  (nodetype: normal)
eth1    up

Une fois srv1 redémarré, l'IP virtuelle reste sur srv2 (option auto_failback sur no). Le redémarrage du service HeartBeat sur srv2 rétablira la situation initiale.

Ceci fonctionnera pour un site statique et si la perte d'une session n'est pas problématique. Pour un site dynamique, il y aura pour commencer le problème de session démarrée sur le serveur HS, celle-ci sera perdue. Le module apache mod_session_dbd permet de stocker les sessions dans une base MySQL. Dans l'optique d'un système haute disponibilité, à tolérance de panne, un cluster MySQL comme vu précédemment répondra à la problématique. Il devrait également être possible de stocker les fichiers de session dans un système de fichiers distribué.

11-3-3 - Pacemaker

Pacemaker permet de démarrer, arrêter, superviser des ressources (système de fichiers, adresse IP, service). Jusqu'en 2017, il faisait partie de HeartBeat.

11-3-4 - Corosync

Corosync permet la gestion de la communication entre plusieurs nœuds, il devra être couplé avec un gestionnaire de ressources comme pacemaker.

Pus d'informations sur Cororosync.

11-3-5 - Corosync/Pacemaker

Corosync est souvent couplé avec Pacemaker pour gérer un cluster de ressources.

11-3-6 - Keepalived

keepalived est un autre système permettant l'équilibrage de charge et la haute disponibilité.

11-3-6-1 - keepalived - tests

Comme pour les tests HeartBeat, nous préparerons deux serveurs Apache srv1 et srv2 avec pour adresse IP 192.168.1.201 et 202 respectivement. Nous réserverons l'adresse 192.168.1.200 pour l’adresse virtuelle du système. Il sera possible de directement appeler 192.168.1.201 ou 202, mais dans ce cas nous ne passerons pas le système de haute disponibilité/l'équilibrage de charge.

J'ai préparé deux serveurs apache 192.168.1.201 (srv1) et 192.168.1.202 (srv2) affichant « It Works <nom serveur> » selon le serveur répondant à la requête :

À ce stade, l'adresse web http://192.168.1.201 affiche « It works srv1 » et 192.168.1.202 affiche « it works srv2 ».

Ceci va nous permettre de voir facilement quel serveur répond depuis l'adresse IP virtuelle présentant le service réparti.

Nous effectuons les prérequis réseau en modifiant le fichier /etc/sysctl.conf :

- décommentage de la ligne net.ipv4.ip_forward=1 ;

- ajout de la ligne net.ipv4.ip_nonlocal_bind=1.

Pour prendre en compte les réglages :

~# sysctl -p
net.ipv4.ip_forward = 1
net.ipv4.ip_nonlocal_bind = 1
~#

Nous installons ensuite keepalived :

apt-get install keepalived

Nous créons ensuite un fichier de configuration sur srv1 (192.168.1.201) :

vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 101
priority 100
virtual_ipaddress {
192.168.1.200
}
}

Nous créons dans le fichier de configuration une instance VRRP (Virtual Router Redonduncy Protocol) avec les éléments suivants :

- state : valeurs MASTER|BACKUP : le MASTER est le serveur maitre, le BACKUP est le serveur de secours ;

- interface : le nom de l’interface réseau à l’écoute ;

- virtual_router_id : doit être identique sur chaque nœud ;

- priority : la priorité du serveur (la valeur la plus faible définissant le serveur prioritaire) ;

- virtual_ipadress : l'adresse IP virtuelle du cluster.

- nopreemt : (non présent dans la configuration en exemple) permet à un MASTER qui renaît de ne pas reprendre automatiquement l’IP qui avait basculé sur le serveur BACKUP.

Après redémarrage du service par systemctl restart keepalived, la machine répondra sur l’IP 192.168.1.200 et 201.

Nous installons ensuite le paquet sur le second serveur, modifions sysctl.conf, et copions le fichier de configuration.

Nous modifions la valeur priority de 100 à 101 sur srv2, de façon à ce que srv1 soit prioritaire dans son rôle de MASTER.

Pour des configurations plus importantes, il est possible de créer des groupes d’instances sous la forme :

vrrp_sync_group VG1 {
group {
VI_1
VI_2
}
}

VI_1 et VI_2 étant des vrrp_instance.

11-3-6-2 - Test

Nous coupons la liaison réseau de srv1. L’adresse 192.168.1.200 répond toujours. Nous pouvons voir la bascule de serveur par l’affichage de « It works srv2 » démontrant que svr2 a bien pris le relais.

Comme nous n’avons pas utilisé l’option noprempt, srv2 reste la machine active après remise en service de srv1. Il suffit de stopper le service keepalived sur srv2 le temps que srv1 reprenne la main pour repartir sur la configuration initiale.

À ce stade, keepalived garantira la disponibilité de l’ip 192.168.1.200, mais ne fera pas de répartition de charge. Pour cela, il faudrait ajouter un bloc « virtual_server » dans la configuration, ce que nous verrons un peu plus loin.

11-3-6-3 - Détection de bascule

keepalived peut vous avertir par mail en cas de bascule de l’IP virtuelle. Pour cela nous ajouterons un bloc « global_defs » avant notre bloc « vrrp » :

global_defs {
notification_email {
<adresse mail>
}
notification_email_from <adresse émettrice>
smtp_server <adresse ip/fqdn serveur mail>
smpt_connect_timeout 30
router_id 100
}

11-3-6-4 - Répartition de charge

Nous modifions la définition de l’instance VRRP comme ceci :

vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 101
priority 100
virtual_ipaddress {
192.168.1.200
}
virtual_server 192.168.1.200 80 {
lb_algo wlc
lb_kind DR
#sorry_server 192.168.1.199
}
real_server 192.168.1.201 80 {
weight 1
inhibit_on_failure
}
real_server 192.168.1.202 80 {
weight 2
inhibit_on_failure
}
}

Dans la définition de l'interface virtuelle, nous pouvons voir le choix du protocole wlc pour la répartition de charge. Les protocoles disponibles sont :

- wlc : Weighted Least-Connection ;

- lblc : Locality-based Least-connection ;

- lblcr : Locality-based Least-connection with replication ;

- rr : round-robin ;

- wrr : Weighted round-robin ;

- dh :Destination hashing ;

- sh :Source hashing ;

- sed : Shorted Expected Dealy ;

- nq : never queue.

Nous avons déjà vu ces protocoles dans la partie Heartbeat.

L'option lb_kind permet de choisir le type de réglage réseau (ici DR).

DR : il s'agit du mode de fonctionnement le plus simple, les adresses IP réelles des machines sont sur le même réseau que l'adresse IP virtuelle.

NAT : dans cette configuration, les machines réelles ne sont pas sur le même réseau que l'IP virtuelle. Le répartiteur de charge aura un accès aux deux réseaux, le réseau interne et le réseau externe. Les échanges entre le monde extérieur et les serveurs internes seront « natés », un peu comme ce que fait votre box Internet. Cette solution permet notamment d'utiliser des serveurs réels avec d'autres systèmes d'exploitation que Linux sur lesquels keepalived ne peut être installé.

TUN : les paquets à destination des serveurs réels sont transmis via un tunnel encapsulant le trafic. Il s'agit ici d’une configuration particulière nécessitant des compétences réseau avancées.

Vous pouvez voir dans la configuration la définition sorry_server commentée. Ce paramètre permet de définir les réglages d'un serveur devant répondre en cas d'indisponibilité d'une machine réelle.

11-3-6-5 - Test de fonctionnement d’un serveur

Pour tester le fonctionnement d’un serveur, il est possible de lancer un script à intervalle régulier. Ce script testera ce que vous souhaitez (IP répondant, service actif, capacité mémoire/disque, etc.) et devra retourner 0 si OK et 1 sinon (exit 0 ; ou exit 1).

Pour cela il faudra ajouter le nom du script dans le bloc vrrp_instance comme ceci :

vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 101
priority 100
virtual_ipaddress {
192.168.1.200
}
virtual_server 192.168.1.200 80 {
lb_algo wlc
lb_kind DR
#sorry_server 192.168.1.199
}
track_script {
test_ip
}
real_server 192.168.1.201 80 {
weight 1
inhibit_on_failure
}
real_server 192.168.1.202 80 {
weight 2
inhibit_on_failure
}
}

L'option weight va permettre de générer une incidence sur la priorité d'utilisation d'un serveur réel par rapport à une autre.

L'option inhibit_on_failure permet de désactiver le load-balancing sur un serveur ne répondant pas.

Nous ajoutons également le bloc vvrp_script ci-dessous avant l'instance vrrp :

vvrp_script test_cluster {
script "/usr/share/test_cluster.sh"
interval 5 # test toutes les 5 secondes
fall 2 # nécessite deux échecs pour déclarer un KO
rise 2 # nécessite deux réussites  pour déclarer un OK
}

Un nouveau bloc vvrp_script, dans notre exemple test_cluster est ajouté au fichier pour définir le script à exécuter, et il est déclaré dans l’instance vvrp.

Il est possible d’appeler plusieurs vrrp_script les uns à la suite des autres.

Voici un exemple de script testant une IP :

test_ip.sh

#!/bin/bash
if ping -c 1 192.168.1.201 >/dev/null
then
exit 0;
else
exit 1;
fi

Exemple de test permettant de vérifier le fonctionnement d'un serveur Apache (répondant sur l'adresse 192.168.1.201) :

test_apache.sh

#!/bin/bash
test=$(wget -qO- 192.168.1.201>>/dev/null;echo $?)
if $test=0
then exit 0 ;
else exit 1 ;
fi

Ajouter dans l'instance une entrée notify suivi du nom du script va permettre d’effectuer des traitements supplémentaires, par exemple, arrêter le service apache :

notif.sh

#!/bin/bash

TYPE=$1
NAME=$2
STATE=$3

case $STATE in
"MASTER") service apache2 start
exit 0
;;
"BACKUP") service apache2 stop
exit 0
;;
"FAULT")  service apache2 stop
exit 0
;;
*)        echo "unknown state"
exit 1
;;
esac

- TYPE contiendra GROUP ou INSTANCE ;

- NAME contiendra le nom du groupe ou de l’instance ;

- et enfin STATE contiendra MASTER, BACKUP, ou FAULT.

On trouvera plus de détails dans la documentation officielle de Keeplived.

12 - Surveillance

Dans le cadre d'utilisation de services cloud grand public, vous n'aurez pas à vous préoccuper de la surveillance du bon fonctionnement du système, ceci étant effectué par votre fournisseur de services. Les drives type Google ou DropBox gardent en général par défaut une rétention des modifications et suppressions pendant 30 jours. Pour ce qui est des sites web mutualisés pouvant contenir des systèmes critiques tels que des CMS, des ERP fonctionnant sur les technologies PHP/MySQL, il vous faut connaître ce que propose votre hébergeur en termes de sauvegarde : sauvegarde intégrée (voir la fréquence et la rétention)/pas de sauvegarde, service gratuit/payant. Vous pourrez avoir des alertes automatiques notamment sur des comportements suspects (exemple :connexion inhabituelle), mais la surveillance du bon fonctionnement en dehors du matériel et du système reste à votre charge.

Une sauvegarde autonome hors hébergement (sur disque externe par exemple) reste indispensable, en cas de bug, de piratage de comptes, et aussi par le fait que les hébergeurs sont de plus en plus visés par des attaques de type cryptolockers.

Pour les services professionnels, votre prestataire vous garantira la disponibilité des ressources qu'il vous fournit, mais vous serez responsable de vos contenus et de leur protection, donc de leur sauvegarde. Des outils pourront vous être fournis pour vous faciliter la tâche.

Le terme informatique adopté et utilisé pour cette activité est la supervision.

12-1 - Le plus simple : par mail

La plupart des services (au sens démon) seront capables de vous envoyer des mails en cas de problèmes. Cela peut être un moyen simple, mais pas forcément fiable. Exemple si le module générant les erreurs ou le serveur mail sont en défaut, vous ne recevrez plus les alertes. Ce système peut suffire si vous pouvez recevoir un rapport de bon fonctionnement. Dans ce cas, la non-réception de celui-ci indiquera un problème.

12-2 - Syslog

syslog est un protocole de gestion de logs. Ceci permet à un logiciel de centraliser ses logs vers un serveur syslog plutôt que de les gérer dans son coin. La plupart des services sont capables de se greffer sur un serveur syslog. syslog gère dans ses messages des niveaux de priorité et de gravité.

Utiliser syslog dans un logiciel est simple, la fonction libc syslog le permettant.

Il existe des utilitaires permettant l'analyse des messages syslog.

syslog reste une solution bas niveau (c.-à-d. pour l'administrateur système) avec ses avantages et ses inconvénients.

Un tutoriel sur syslog.

12-3 - Nagios

Nagios est un logiciel de supervision libre faisant référence. Il permet une surveillance centralisée de plusieurs équipements. Il se compose de son moteur de supervision, d'une interface web permettant une vue globale, et de greffons dédiés à la surveillance d'éléments précis, les plus simples étant la réponse au ping, l'état S.M.A.R.T d'un disque, l'état d'occupation disque, mémoire ; ainsi que des greffons plus poussés comme la présence d'un processus, il est possible de créer ses propres greffons.

Il existe des options similaires gratuites et payantes.

Un tutoriel sur Nagios.

12-4 - Prometheus/Grafana

Prometheus est un logiciel de surveillance et d'alerte libre créé à l'origine par SoundCloud pour ses besoins internes.

Grafana est un logiciel libre de génération de tableaux de bord et graphiques.

Les deux produits vont utiliser des informations stockées dans une base de données, dans notre cas la base sera alimentée par Prometheus, puis exploitée par Grafana.

Les deux solutions couplées vous permettront de générer votre propre système de surveillance personnalisé comme présenté dans ce tutoriel.

12-5 - Solution maison

Si vous trouvez que Nagios est une usine à gaz, vous pourrez utiliser des outils existants ou développer votre propre solution maison.

Il vous faudra commencer par déterminer les points à surveiller. Nous mettons de côté la réponse au ping, le contrôle de l'espace disque qui sont les éléments de base à surveiller et considérés comme des prérequis.

Si nous devons surveiller le fonctionnement d'un site web par exemple, il vous faudra automatiser un dialogue avec celui-ci avec cUrl (client URL request Library) par exemple de façon à vérifier le comportement normal du site. Une simple requête HTTP ne permettra que de tester si le serveur HTTP est opérationnel, mais ne permettra pas de détecter un site en erreur.

Pour une solution à grande échelle, Nagios sera le produit adapté, car considéré comme un standard, il pourra être pris en main par n'importe quel administrateur système et non pas uniquement par vous suite à la mise en place d'une solution « exotique ».

13 - Orchestration

L'orchestration consiste en la coordination et la gestion automatique d'un système informatique.

Dans les systèmes cloud à grande échelle, c'est ce qui va vous permettre la mise en service d'une machine virtuelle en 2-3 clics. C’est ce qui permet à un hébergeur de vous déployer un site web sans intervention humaine, quasi instantanément.

La partie la plus visible de l'orchestration est donc le déploiement. Kubernetes que nous avons déjà évoqué est une plateforme permettant le déploiement automatique de conteneurs, qui fait référence. Pour les machines virtuelles, cela se présentera sous forme de templates que l'on peut voir comme des modèles de machines virtuelles à déployer. Le déploiement d'un template est bien sûr automatisable.

Une des plateformes les plus connues de déploiement se nomme Ansible. Ansible est utilisable sous Windows pour certaines tâches, mais le serveur devra être installé sous Linux.

Dans le monde Microsoft, vous pourrez utiliser le serveur de déploiement WDS. D'autre part, Active Directory est conçu de façon à pouvoir installer automatiquement des logiciels depuis des stratégies de groupe qui sont appliquées à des utilisateurs, des groupes, des ordinateurs lors de la connexion au domaine Active Directory.

14 - Conclusion

J'espère que ce tutoriel vous a éclairé sur ce qu'est le cloud computing et son principe de fonctionnement, j'ai essayé d'aborder tous les aspects possibles, de solutions cloud toutes faites à des solutions à mettre en place soi-même, plus ou moins complexes. Le domaine est vaste et le lecteur est invité à continuer ses recherches et ses expérimentations sur le sujet.

15 - Remerciements

Je remercie Mickael Baron, khayyam90, LittleWhite, et Louis-Guillaume Morland pour leur relecture technique.

Je remercie Claude Leloup pour sa relecture orthographique.