I- CONTEXTE ET OBJECTIF
Afin de réduire les coûts de stockage, mais aussi leur dépendance vis à vis des grands fournisseurs de systèmes de stockage traditionnels, de plus en plus d’entreprises sont tentées d’utiliser les solutions de Software Defined Storage libres, notamment lorsqu’elles déploient des technologies de cloud comme OpenStack ou des technologies d’analyse Big Data comme Hadoop/Spark ou Kubernetes.
L’une des technologies de stockage open source les plus prometteuses et les plus populaires est Ceph, une technologie dont le principal sponsor, Inktank, a été racheté en avril 2014 par Red Hat.
Ceph est un système de stockage distribué qui a la particularité de délivrer à la fois des services de stockage en mode bloc (par exemple pour le stockage de VM), des services de stockage en mode objet (compatibles S3 et Swift) et depuis peu des services en mode fichiers (via CephFS).
Ceph est notamment devenu populaire dans le monde du stockage du fait de ses nombreux points d’intégration avec OpenStack qui en font la technologie de stockage la plus déployée avec le framework de cloud libre et kubernetes à travers l’opérateur « rook » que nous allons déployer dans un prochain article.
Dans ce présent article nous allons mettre en place un cluster CEPH.
Environnement
Virtualbox :
4 VM (nodes)
3Go RAM pour chaque VM
40 Go HDD pour chaque VM
40 Go supplémentaire pour chaque VM (dédié aux OSD)
Networking :
93.123.35.0/24 (enp0s3)
10.17.87.0/24 (enp0s8)
Pour le HA il faut:
-3 daemons “mons”
-3 daemons “osds”
-2 daemons “mgrs”
-1 daemons “mdss”
Outils :
Ceph-Ansible
Docker
Ubuntu server 18.04 LTS
II- ARCHITECTURE SOFTWARE DEFINED STORAGE (SDS)
Le « Software Defined Storage » il s’agit de virtualisation de stockage ou de baies SAN logicielles ou virtuelles – promet flexibilité accrue et réduction des coûts. Et cela, sans remettre en cause la façon de délivrer le stockage. De quoi donner des cauchemars aux acteurs traditionnels du secteur.
Le stockage défini par logiciel apporte une abstraction entre le logiciel et le matériel au sein d’une solution de stockage. Il s’oppose aux formes de stockage telles que les NAS ou les SAN dont les systèmes intègrent un logiciel de gestion et du matériel dépendant et indissociable.
L’un des intérêts du Software-Defined Storage est de bénéficier d’une architecture de stockage basée sur un ensemble de logiciels, agnostiques des technologies matériels, et qui permettrait d’automatiser le provisionnement de stockage au sein d’un système d’information.
III- PRINCIPE DE FONCTIONNEMENT CEPH
Un système de stockage Ceph se présente sous la forme d’un cluster de nœuds serveurs (en général des machines standards x86 équipées de disques et/ou de SSD et interconnectées par un réseau rapide à 10 Gbit/s ou plus). Chaque nœud serveur fait tourner de multiples processus chargés de traiter les requêtes d’entrées/sorties, de distribuer les données, de répliquer les données, d’assurer leur intégrité (via un processus de scrubbing régulier) et de gérer les défaillances (et les reconstructions éventuelles de données qui s’ensuivent
IV- ARCHITECTURE MODULAIRE CEPH
- Un mode natif à Ceph via la librairie LIBRADOS. Des librairies sont proposées pour la plupart des langages de programmation communs comme C, C++, Java, Python, Ruby ou PHP.
- Un mode de stockage objet : via la passerelle RADOSGW, Ceph propose un mécanisme de stockage objet de type “bucket” accessible via des API compatibles avec Amazon S3 et OpenStack Swift.
- Un mode de stockage en mode bloc : via le pilote noyau RBD, un hôte Linux peut monter un volume Ceph et l’utiliser comme un disque local. Des intégrations sont aussi fournies avec KVM/QEMU pour fournir du stockage en mode bloc à des machines virtuelles.
- Un stockage en mode fichier : via CephFS, Ceph propose depuis peu un accès en mode fichiers compatible POSIX et intégré avec OpenStack Manila. CephFS est considéré comme stable depuis la version actuelle de Ceph (nom de code “Jewel”). La mise en œuvre de CephFS nécessite l’installation de serveurs de métadonnées spécifiques en plus des serveurs habituellement déployés pour un cluster Ceph. Certaines fonctions restent expérimentales comme la mise en œuvre de plusieurs systèmes de fichiers sur un même cluster ou les snapshots.
*Moniteurs (mon): Un moniteur Ceph (ceph-mon) maintient les cartes de l’état du cluster, y compris la carte du moniteur, la carte du gestionnaire, la carte OSD, la carte MDS et la carte CRUSH. Ces cartes sont des états de cluster critiques requis pour que les démons Ceph se coordonnent les uns avec les autres. Les moniteurs sont également responsables de la gestion de l’authentification entre les démons et les clients. Au moins trois moniteurs sont normalement requis pour la redondance et la haute disponibilité.
*Gestionnaires (mgr) : un démon Ceph Manager (ceph-mgr) est responsable du suivi des métriques d’exécution et de l’état actuel du cluster Ceph, y compris l’utilisation du stockage, les métriques de performances actuelles et la charge du système. Les démons Ceph Manager hébergent également des modules basés sur python pour gérer et exposer les informations du cluster Ceph, y compris un tableau de bord Ceph basé sur le Web et une API REST. Au moins deux gestionnaires sont normalement requis pour la haute disponibilité.
*OSD Ceph : Un Ceph OSD (démon de stockage d’objets ceph-osd) stocke les données, gère la réplication, la récupération, le rééquilibrage des données et fournit des informations de surveillance aux moniteurs et aux gestionnaires Ceph en vérifiant les autres démons Ceph OSD pour un battement de cœur. Au moins 3 OSD Ceph sont normalement requis pour la redondance et la haute disponibilité.
*MDS : Un serveur de métadonnées Ceph (MDS ceph-mds) stocke les métadonnées pour le compte du système de fichiers Ceph (c’est-à-dire que les périphériques Ceph Block et Ceph Object Storage n’utilisent pas MDS). Ceph serveurs de métadonnées permettent aux utilisateurs du système POSIX de fichiers pour exécuter des commandes de base (comme ls, find, etc.) sans imposer un fardeau énorme sur le cluster de stockage CEPH.
OSDs Monitors Managers MDSs
Ceph stocke les données sous forme d’objets dans des pools de stockage logiques. À l’aide de l’algorithme CRUSH, Ceph calcule quel groupe de placement doit contenir l’objet et calcule en outre quel démon Ceph OSD doit stocker le groupe de placement. L’algorithme CRUSH permet au cluster de stockage Ceph de mettre à l’échelle, de rééquilibrer et de récupérer dynamiquement.
V- INSTALLATION ET CONFIGURATION
a- changer le nom de chaque host
root@ceph: sudo hostnamectl
root@ceph: sudo hostnamectl set-hostname node-1
root@node-1: sudo vi /etc/cloud/cloud.cfg
root@node-1:~# vi /etc/hosts
93.123.35.4 ceph
93.123.35.5 node-1
93.123.35.6 node-2
93.123.35.7 node-3
b- adressage IP pour chaque host
root@ceph:/opt/ceph-ansible# vi /etc/netplan/50-cloud-init.yaml
c- Bac à sable
root@ceph:~# cd /opt/
recupération du répository (veuillez installer git)
root@ceph:/opt# git clone https://github.com/ceph/ceph-ansible.git
root@ceph:/opt# cd ceph-ansible/
Allez sur la branche qui contient la dernière version stable de ceph “octopus”
root@ceph:/opt/ceph-ansible# git checkout stable-5.0
root@ceph:/opt/ceph-ansible# git pull
Installer les dépendances et ansible(version 2.9)
root@ceph:/opt/ceph-ansible# sudo apt update
root@ceph:/opt/ceph-ansible# sudo add-apt-repository ppa:ansible/ansible
root@ceph:/opt/ceph-ansible# sudo apt install ansible -y
Générez les clé SSH et assurez vous que les noeuds communiquent entre eux par SSH via le compte root
root@ceph/opt/ceph-ansible# ssh-keygen -t rsa -b 4096
root@ceph:/opt/ceph-ansible# ssh-copy-id node-2
root@ceph:/opt/ceph-ansible# ssh node-2
root@node-2:~#
root@node-2:~# logout
Modifier le fichier d’inventaire
root@ceph:/opt/ceph-ansible# vi /etc/ansible/hosts
[mons]
node-[1-3]
[osds]
node-[1-3]
[mgrs]
ceph ansible_connection=local
[grafana-server]
ceph ansible_connection=local
d- Configuration
On surcharge les variables pour l’adapter à notre environnement
root@ceph:/opt/ceph-ansible# cp site.yml.sample site.yml
root@ceph:/opt/ceph-ansible# cd group_vars/
root@ceph:/opt/ceph-ansible/group_vars# vi all.yml
Nous allons installer la dernière version stable qui est «octopus »
**MONs
**OSDs
**DASHBOARD CEPH
**DASHBOARD GRAFANA
**PROMETHEUS, ALERT MANAGER
Nous allons vérifier la disponibilité des disques sur chaque noeuds
root@ceph:~# ssh node-1
Ici on voit qu’on a un disque qui est disponible “/dev/sdb” et qui est de 40GiB sur le NODE-1
Ajout des disques OSDs
root@ceph:/opt/ceph-ansible/group_vars# cp osds.yml.sample osds.yml
root@node-1:/opt/ceph-ansible/group_vars# vi osds.yml
e- Déploiement
Nous allons installer les dépendances de python et lancer le déploiement
NB: Il est possible d’augmenter le nombre de noeuds en fonction de vos besoins
root@ceph:/opt/ceph-ansible# apt install python-pip -y
root@ceph:/opt/ceph-ansible# pip install -r requirements.txt
root@ceph:/opt/ceph-ansible# ansible –version
ansible 2.9.14
root@ceph:/opt/ceph-ansible# ansible-playbook site.yml
f- Vérification de notre déploiement via l’interface graphique
Après avoir déployé CEPH via « ceph-ansible », nous allons vérifier la solution à travers les différents Dashboard
**REDIRECTION DE PORT
**DASHBOARD CEPH
**DASHBOARD GRAFANA
LIEN UTILE DOCUMENTATION :
https://docs.ceph.com/en/latest/start/intro/
https://github.com/ceph/ceph-ansible
https://docs.ceph.com/projects/ceph-ansible/en/latest/
CONCLUSION
Dans ce tutoriel nous avons vu la mise en place d’un cluster CEPH en haute disponibilité, une solution opensource qui est une alternative aux baie de stockage afin de réduire les coûts .
Il faut noter qu’aussi CEPH se positionne comme l’un des meilleurs backends de stockage pour fournir du stockage à tout type d’application que ce soit On-Premise où dans le Cloud à travers ces différents interfaces que nous avons vu dans ce tutoriel.
Il a su se positionné comme le meilleur backend sur les solutions comme PROXMOX et OPENSTACK.
Aujourd’hui il se positionne comme le meilleur sur KUBERNETES à travers son opérateur “rook” qui donne la possibilité de fournir du stockage de manière dynamique aux PODs.
Le prochain article sera sur l’intégration de CEPH avec OPENSTACK et KUBERNETES
Auteur : Moussadia Soumahoro Ingénieur DevOps / Cloud