Plan du site  
pixel
pixel

Articles - Étudiants SUPINFO

Mise en place d'un SAN ISCSI sous linux avec DRBD

Par Francis VIALLET Publié le 12/01/2017 à 10:09:02 Noter cet article:
(0 votes)
Avis favorable du comité de lecture

Nous utiliserons un système à noyau linux (Debian), et les outils :

  • DRBD afin de répliquer le disque entre les deux contrôleurs (serveurs Debian) du SAN

  • Iscsitarget afin de partager le disque DRBD en iscsi vers les clients du SAN

  • Heartbeat sera le point central pour le Basculement automatique et quasiment sans perte de ping du serveur primaire vers le secondaire en en cas de panne du serveur maître.

Introduction

  • SAN

Un SAN (pour Storage Area Network), est un espace (baies) de stockage partagé à bas niveau (blocs) (Protocoles : FiberChannel, iSCSI, etc.).

Au contraire, un NAS est un stockage partagé à un niveau plus haut (fichiers), (Protocoles : NFS, CIFS, etc.).

Pour simplifier, le trafic sur un SAN est très similaire aux principes utilisés pour l'utilisation des disques internes (ATA, SCSI). Les périphériques sont partagés en mode blocs et apparaissent en tant que tel sur le périphérique client (en clair : le client voit un disque dur en plus). C'est l'OS qui accès au périphérique qui est chargé de gérer le sytème de fichier, l'écriture des blocs, etc. Sur un NAS, c'est le serveur qui gère celà (en clair, le client voit un nouveau dossier), le client lui ne transfère que des fichiers.

  • DRBD

DRBD signifie "Distributed Replicated Block Device".

En français on pourrait le traduire en "Périphérique de niveau Blocs Ditribué et Répliqué".

C'est un module noyau open source développé par la société Linbit , qui permet de synchroniser/répliquer du stockage via le réseau (disques, partitions, etc.), et donc entre différentes machines.

On parle vulgairement de RAID-1 sur le réseau, afin de comprendre rapidement le concept.

Tout comme le RAID-1, DRBD assure une consistance des données au niveau du périphérique. C'est à charge du système de fichiers de s'assurer, conserver et retrouver l'intégrité des données au niveau des fichiers. De même, c'est à charge des applications de retrouver un état cohérent si un problème survient.

Architecture avec deux noeuds DRBD :

Les outils permettant de configurer le module noyau et de mettre en place une architecture DRBD sont, sous debian, installés avec le paquet drbd8-utils, et ils sont :

  • drbdadm : Outil d'administration de haut niveau de DRBD. Il récupère les informations depuis le fichier de configuration /etc/drbd.conf. Il sert d'interface pour drbdsetup et drbdmeta. Un mode "dry-run" permet d'afficher les commandes à destination de ces programmes.

  • drbdsetup : Permet aux utilisateurs de configurer le module DRBD après son chargement. C'est un outil d'assez bas niveau, auquel toutes les options doivent-être passées par la ligne de commande, ce qui le rend à la fois plus flexible, au prix d'une difficulté d'utilisation.

  • drbdmeta : Permet à l'utilisateur de créer, sauvegarder, restaurer et modifier les méta-données des structures de données de DRBD.

  • drbd-overview : Permet d'afficher l'état du cluster DRBD, l'avancement de la synchonisation, l'état des noeuds, etc.

  • ISCSITARGET

Iscsitarget est un outil servant à créer une Cible iSCSI. Explications :

Le SCSI est un type de connectique comme le SATA ou l’IDE qui est principalement utilisé sur les serveurs car il offre de très bonne vitesse (de 10k à 15k rpm).

Le iSCSI est une émulation des commandes du protocole SCSI via le réseau TCP/IP. Il permet de s’abstenir de l’achat de connectiques coûteuses. Il est comparable au FBoE (FibreChannel over Ethernet) pour le FibreChannel, mais qui utilise une connectique et du matériel propriétaires et spécifiques.

Un Target iSCSI est un serveur iSCSI, c’est à dire notre SAN. C’est lui qui va distribuer nos données de type bloc via le réseau.

Un initiator iSCSI est le client qui va se connecter au Target.

Ici, ISCSITARGET nous permettra de partage notre disque DRBD.

  • HEARTBEAT

Heartbeat sera le point central pour le Basculement automatique et quasiment sans perte de ping du serveur primaire vers le secondaire en en cas de panne du serveur maître.

Il nous permettra de mettre en place la HA en basculant l'IP virtuelle accédée par les clients, et le service iSCSI vers le deuxième contrôleur SAN (serveur debian DRBD secondaire) en cas de panne du serveur maître.

(et aussi passer le DRBD sur le secondaire en master, car c'est lui qui aura les dèrnieres données a jour étant donné que le SAN aura basculé dessus).

Mise en place

Nous avons nos deux serveurs SAN :

  • 5VTZ-SAN-1 (192.168.1.11/24) (primaire)

  • 5VTZ-SAN-2 (192.168.1.12/24) (secondaire)

Ils ont chacun deux cartes réseaux :

  • une pour la réplication DRBD (localhost ou réseau isolé)

  • une pour le partage en iSCSI et la connexion avec l'extérieur

Et aussi un disque dur de 550G à part, celui qui servira pour le SAN.

Si l'on a un serveur DNS, on ajoute les IP LAN de nos deux serveurs SAN et leurs noms (ci-dessus), sinon on modifie les fichiers hosts des deux serveurs pour que la résolution fonctionne même sans serveur DNS.

Puis on va éditer leurs fichiers hosts dans tous les cas afin de permettre la résolution les addresses dans le réseau isolé pour la réplication DRBD :

vi /etc/hosts :

10.0.0.2 nodesan1.locallink nodesan1

10.0.0.3 nodesan2.locallink nodesan2

Puis sur chaque serveur, on va créer avec fdisk deux partitions sur le disque dur 2. Chacune sera répliquée avec DRBD, une de 100Mo environ stockera la configuration iSCSI, l'autre qui aura l'espace restant sera partagées en iSCSI.

Une fois les partitions créées on doit avoir avec fdisk -l :

Device Boot Start End Sectors Size Id Type

/dev/sdb1 2048 206847 204800 100M 83 Linux

/dev/sdb2 206848 1153433599 1153226752 549,9G 83 Linux

Puis on va créer nos fichiers de définition des ressources DRBD (2 par serveur donc) dans /etc/drbd.d/ :

Puis on les initialise, on créé les métadonnées, on les mets up, et on passe le SAN-1 en primaire :

  • modprobe drbd (node 1 puis node 2)

  • drbdadm create-md conf.iscsi (node 1 puis node 2)

  • drbdadm create-md datatarget.iscsi (node 1 puis node 2)

  • drbdadm up conf.iscsi (node 1 puis node 2, puis attendre que drbd-overview montre le status "connected")

  • drbdadm invalidate conf.iscsi (node 1)

  • drbdadm primary conf.iscsi (node 1)

  • drbdadm up datatarget.iscsi (node 1 puis node 2, puis attendre que drbd-overview montre le status "connected")

  • drbdadm invalidate conf.iscsi (node 1)

  • drbdadm primary datatarget.iscsi (node 1)

  • on vérifie avec drbd-overview :

Sur le Primaire on va formater le disque drbd1 en ext4 et le monter :

mkfs.ext4 /dev/drbd1

mkdir /mnt/conf.iscsi

mount /dev/drbd1 /mnt/conf.iscsi

On teste la réplication :

  • Sur le primaire :

    dd if=/dev/zero of=/mnt/conf.iscsi/test.bin bs=1M count=9

    ls -l /mnt/conf.iscsi

    umount /dev/drbd1

    drbdadm secondary conf.iscsi

  • Sur le secondaire :

    drbdadm primary conf.iscsi

    mkdir /mnt/conf.iscsi

    mount /dev/drbd1 /mnt/conf.iscsi

    ls -l /mnt/conf.iscsi

    #The file is present !

    rm /mnt/conf.iscsi/test.bin

    umount /dev/drbd1

    drbdadm secondary conf.iscsi

  • Sur le primaire :

    drbdadm primary conf.iscsi

    mount /dev/drbd1 /mnt/conf.iscsi

    ls -l /mnt/conf.iscsi

    #Le fichier à bien été supprimé !

On passe à la mise en place le iSCSI; sur les deux serveurs on installe donc iscsitarget :

  • apt install iscsitarget

On édite /etc/default/iscsitarget pour l'activer (ne se lancera pas lors du démarrage du service sinon) :

  • vi /etc/default/iscsitarget

  • mettre ISCSITARGET_ENABLE à true

Ce sera HEARTBEAT qui contrôlera le service iscsitarget et le démarrera sur le primaire, ou le secondaire en cas de faille du primaire. On désactive donc le service sur les deux noeuds SAN afin qu'il ne soit pas démarré automatiquement :

  • systemctl disable iscsitarget

  • update-rc.d -f iscsitarget remove

Afin d'avoir une configuration iscsi homogène sur les deux SAN, elle sera stockée sur la partition DRBD 1 de 100 Mo.

Sur le primaire, on déplace la configuration iscsi sur iscsi.conf (drbd1), puis on fait un lien symbolique pour que le service iscsitarget aille la lire :

mv /etc/iet/ietd.conf /mnt/conf.iscsi/

ln -s /mnt/conf.iscsi/ietd.conf /etc/iet/

ls -l /etc/iet/

Sur le secondaire, on supprimme la conf et ont fait le lien vers celle déjà présente sur iscsi.conf :

mv /etc/iet/ietd.conf /mnt/conf.iscsi/

ln -s /mnt/conf.iscsi/ietd.conf /etc/iet/

ls -l /etc/iet/ #Broken (red) link, c'est normal drbd1 n'est pas monté car il n'est pas accessible en lecture, on est sur le secondaire, en cas de faille il passera en primaire via heartbeat et sera monté, puis iscsitarget démarré.

Sur le primaire, on édite la conf iscsi :

  • vi /etc/iet/iet.conf ou vi /mnt/conf.iscsi/ietd.conf

On passe à la configuration du cluster heartbeat :

  • Sur le SAN1 : vi /etc/ha.d/ha.cf

  • Sur le SAN2 : vi /etc/ha.d/ha.cf

On configure une clé pour la communication des membres du cluster heartbeat :

  • vi /etc/ha.d/authkeys

  • chmod 600 /etc/ha.d/authkeys

Sur les deux noeuds, le haresources doit être identique, il défini les ressources disponibles sur quel serveur en priorité, une ligne est une suite de ressources montées à la suite et dépendantes (du succès) de la précédente.

On créé une IP virtuelle HA (.10) qui sera celle qui sera jointe par nos clients.

En revanche chaque ligne est indépendante de la précédente.

  • vi /etc/ha.d/haresources

On attends la fin de la synchro des doeux noeuds (drbd-overview); puis on peut tester.

ATTENTION : Pendant le rédaction de cet article, un BUG Heartbeat fait qu’il ne pouvait pas démarrer le service iscsitarget et était très instable.

Le problème a été résolu en installant heartbeat depuis les dépôts de la distribution Debian SID (unstable) sur les deux nœuds SAN.

Démarche :

  • On ajoute des dépôts testing dans les sources de nos SAN :

    echo -e "\n# Sid repository\ndeb http://ftp.fr.debian.org/debian unstable main contrib non-free\ndeb-src http://ftp.fr.debian.org/debian unstable main contrib non-free" >> /etc/apt/sources.list

  • On créé le fichier de préférences pour apt afin qu’il ne prenne pas de paquets dans SID sauf s’il est vraiment obligé, sinon a la prochaine MAJ on cassera toute la machine :

    echo -e "Package: *\nPin: release a=unstable\nPin-Priority: 100" >> /etc/apt/preferences

  • On installe/met à jour heartbeat depuis SID après avoir mis à jour le cache apt :

    apt -t unstable install heartbeat

Conclusion

Voilà, vous n'avez donc désormais plus qu'a monter votre cible iscsi sur l'un de vos clients avec leurs initiateurs (ESXi, Windows Server, etc.), pour qu'ils puissent accéder au disque sur drbd2 qui est partagé en iSCSI.

Si le primaire tombe l'IP virtuelle (.10) accédée par les initiateurs (clients) est basculée sur le deuxième, les disque drbd sont passés en primaire sur le secondaire, drbd1 (iscsi.conf) est monté afin de rendre la conf iscsi lisible par le service iscsitarget, puis le service iscsi est lancé sur le secondaire et partage drbd2.

Tout ceci est exécuté en quelques secondes, vous avez donc maintenant un SAN en Haute-Disponibilité.

A propos de SUPINFO | Contacts & adresses | Enseigner à SUPINFO | Presse | Conditions d'utilisation & Copyright | Respect de la vie privée | Investir
Logo de la société Cisco, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société IBM, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sun-Oracle, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Apple, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sybase, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Novell, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Intel, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Accenture, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société SAP, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Prometric, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Toeic, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo du IT Academy Program par Microsoft, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management

SUPINFO International University
Ecole d'Informatique - IT School
École Supérieure d'Informatique de Paris, leader en France
La Grande Ecole de l'informatique, du numérique et du management
Fondée en 1965, reconnue par l'État. Titre Bac+5 certifié au niveau I.
SUPINFO International University is globally operated by EDUCINVEST Belgium - Avenue Louise, 534 - 1050 Brussels