Stockage

À propos de ces notes...

Ces notes sont issues de mon wiki personnel : https://innertech.ovh/mediawiki/

Le format adopté est "tout sur la même page", dans l'optique de garder un sommaire du wiki simple et calqué sur la Licence professionnelle. Il va de soi que dans un contexte professionnel, ces notes seraient divisées en plusieurs pages.

Stockage local

Matériel

Au fil du temps, plusieurs types de matériels se sont développés dans le but de stocker des données.

Les bandes magnétiques

Une des plus anciennes méthodes de stockage "amovible", nous sommes successivement passés de bandes magnétiques simples, au cassettes type "cassette audio", jusqu'au LTO 3/4 (Linear Tape-Open : une technique de stockage sur bande magnétique, au format ouvert développé par HP, IBM et Seagate à la fin des années 90). Leur temps d'accès étant supérieur à 1 seconde, elles servent de nos jours à des sauvegardes, par accès séquentiels.

Médias magnétique rotatifs

Cela inclut les disquettes (aujourd'hui bien dépassées : bien qu'ayant un temps d'accès court, le débit est limité et la fiabilité douteuse) et les disques durs à plateaux, dont les temps d'accès est supếrieur à 20 ms. Le débit étant important, ils servent en général de stockage principal.

Médias optiques

Cela inclut les CD-Rom (en lecture seule), et les CD-R, RW, DVD-R/R+/RAM, disque opto-magnétiques... Ces derniers ne pouvant rivaliser avec les disques durs pour ce qui est du débit et du temps d'accès, ils servent en général à l'archivage.

Médias électroniques

Cela inclut la RAM, très rapide mais volatile, et la mémoire flash, plus lente mais non volatile. Le SSD, un assemblage de mémoires flash, constitue un véritable disque dur. Celui-ci inclue :

• Un processeur SOC,
• Une interface de DD standard,
• De la RAM pour la mémoire cache
• Des modules de mémoire flash

Il a de nombreux avantages : pas de pièces mobiles, consomme et chauffe peu, est assez fiable et performant, et est un matériel standard. En revanche, il coûte cher !

Bus et Interfaces

Ils servent à assurer la connexion entre la carte mère et le périphérique. Dans la catégorie "Desktop", les moins chers, qui mettent l'intelligence sur le poste et favorisent les connexions internes, on a:

• IDE, le plus vieux
• ATA (Parrallèle), ou PATA
• ATA (Série), ou SATA
  • Moins coûteux, ils montent à 7200 RPM, et en général dans les 2 To. Les vitesses sont de 1.5 (Sata 1), 3 Gbps (Sata 2), et 6 GBps (Sata 3), et ils fonctionnent en half-duplex ! On ne peut en brancher qu'un seul par interface.

Les interfaces serveur sont plus chères, mais elles mettent l'intelligence dans le périphérique, et peuvent proposer des connexions internes ou externes. On utilise en général :

• Le SCSI (Parrallèle)
• Le SAS (série), qui se rapporte au SATA
  • On peut en brancher jusqu'à 128 par interface, ils montent à 15000 RPM, et font en général dans les 450 Go. Ils coûtent cher, mais fonctionnent en full-duplex et vont de 3Gbps (SAS) à 6 Gbps (SAS 2.0).
• Le Fibre Channel en série.

Différence série / parallèle

La transmission en série (norme RS-232) se fait de façon asynchrone (sans signal d'horloge), le périphérique devant être capable de distinguer les différents cractères de 8 bits (on utilise pour cela des bits start et stop, qui utilisent 20% de la bande passante). La transmission en parallèle consiste à envoyer simultanément des données sur plusieurs canaux. Différents types de ports parallèles permettent différents débits (EPP permet 8 à 16 Mbps, et ECP y ajoute du plug-and-play). Les connecteurs DB25 permettent de connecter un élements extérieur à l'ordinateur en parallèle.

Universal Serial Bus

L'USB (Port Série Universel, qu'on peut aussi appliquer au FireWire) est universel, aussi on peut y brancher n'importe quoi (y compris du stockage). Dans le raccordement, le protocole USB Mass Storage est utilisé. Peut s'appliquer au disques SATA.

Si les disques/clefs USB sont plug and play, ils sont aussi unplug and pray : des données non contrôlées et non sécurisées sont en danger. Il faut mettre en place une politique de stockage pour limiter la prolifération des données !

Politique de stockage

Chaque disque dur est découpé en partitions, chacune de ces partitions utilisant un FS (File Système), soit une façon d'organiser les fichiers sur le disque. Certains sont Multi-système. On compte différents FS :

• ext4
• swapFS
• XFS
• btrfs
• NTFS
• etc...

Une politique de stockage a pour but de ne pas laisser les données éparpillées, mais de les sécuriser (en les mutualisant, et en effectuant des contrôles et des sauvegardes). Le support de cette politique est le réseau de stockage.

Sécuriser

Une baie de stockage est un périphérique intelligent, qui contient un CPU, de la mémoire cache, des contrôleurs... La sécurité se fait de plusieurs façons :

• En sécurisant l'environnement de la salle machines
• En ayant des élements redondants et échangeables à chaud, sans perte de données ni arrêts
• En utilisant le RAID
• Les accès possibles (généralement indépendants des disques internes utilisés) sont:
  • e-SATA
  • SAS
  • Fibre Channel
  • Ethernet

 

Le RAID

Le RAID (Redundant Array of Independent Disks), permet de dupliquer automatiquement les données sur plusieurs disques, pour que celles-ci restent accessibles en cas de panne d'un disque. Le RAID agit au niveau bloc, et il n'as donc rien à faire du FS en place, à moins de travailler sur du RAID logiciel à l'ancienne.Les recopies de données peuvent être faites de 2 façons :

• Raid Software : effectué par l'OS ou par un pilote spécifique
• Raid Hardware : effectué par un contrôleur spécifique.

Il existe plusieurs niveaux de RAID :

Niveau de RAID	Description	Nombre min. de disques	Capacité utile (Nbre de disques)	Particularités
0	Striping/Concaténation	2	N	Zéro RAID : pas de duplication !
1	Miroir	2	N/2	Chaque donnée est dupliquée sur un autre disque.
1+0	Miroir puis striping	4	N/2
5	Stripes avec parité distribuée et E/S aléatoires	3	N-1	Chaque disque fait la parité d'un/plusieurs autres : la reconstruction est longue et stressante
6	Stripes avec deux calculs de parité différents distribués et E/S aléatoires	4	N-2	La double parité rend le processus plus complexe.

 

Augmenter l'espace de stockage

On peut étendre via des JBOD, on a alors pas d'intelligence intégrée. On augmente la capacité de stockage mais pas la puissance de traitement. On peut aussi ajouter des baies, pour augmenter la puissance de traitement; certains constructeurs permettent d'augmentation de la puissance de traitement en ajoutant des contrôleurs. Les fonctions dépendent de l'intelligence de la baie : il faut faire le rapport prix/fonctions.

Partitionnement d'une baie

Sur une baie de 24 To, on peut partitionner comme suit :

• Un volume utile de 12 TO en RAID6, de 8*2To (prendre en compte les disques de parité !)
• Un volume de 12To en RAID5, de 7*2 To (toujours avec les disques de parité), en gardant un emplacement "Hot spare".

Performance des baies

Pour choisir le constructeur, le mieux est de tester en conditions réelles. Le choix SAS/SATA peut se faire comme suit :

• SAS : BDD, E/S aléatoires
• SATA : Le Reste
• SAS SSD : Est-ce raisonnable?

Le cache est important : la baie embarque beaucoup de cache, les différences sont lissées mais elles existent. SATA suffit dans beaucoup de cas.

Modes : bloc, objet, fichier

On distingue plusieurs façons d'accéder au contenu d'un stockage.

• Mode fichier : Basé sur les fichiers, selon l'arborescence de l'OS. C'est le plus classique.
• Mode bloc : Les données sont rassemblées en mode bloc, qui sont vues comme des élements séparés. Chaque bloc contient des données brutes et se voit attribuer un numéro. Généralement utilisé dans les SAN.
• Mode Objet : " Le stockage en mode objet est une structure plate dans laquelle les fichiers sont décomposés en éléments et répartis sur du matériel. Avec le stockage en mode objet, les données sont décomposées en petites unités distinctes appelées objets et sont conservées dans un référentiel unique, au lieu d'être conservées sous forme de fichiers dans des dossiers ou sous forme de blocs sur des serveurs. " (source : https://www.redhat.com/fr/topics/data-storage/file-block-object-storage)

Mise en place d'un serveur de sauvegardes

<pdf>Fichier:Stockagetp1.pdf</pdf>

Le but du TP est, à partir d'une VM sous Debian dotée de trois disques additionnels d'un 1 Go chacun, de mettre en place du RAID1. On utilise pour cela mdadm : il s'agira de faire du RAID logiciel. Mdadm est l'utilitaire standard sous Linux pour gérer ce genre de RAIDs, qui permet non seulement de monter des grappes RAID mais également de les monitorer.

Machine de départ

Je part d'une Debian 9, dotée de 2 Gbo de RAM et de 2 processeurs (on peut certainement être moins généreux, mais j'ai les ressources disponibles alors je préfère gagner un peu de temps les allouant). Elle est contrôlée par SSH.

Installation des outils

Je commence par une installation de sudo et vim (par habitude), avant de mettre à jour les paquets.

su
apt update && apt install sudo vim
visudo #Je rajoute mon utilisateur
exit
sudo apt full-upgrade
sudo apt install mdadm

Mise en place du RAID à proprement parler

Nous avons bel et bien nos trois disques (au total) : un disque système, et trois qui serviront dans le cadre du RAID. On peut les voir ainsi que leur nom à l'aide d'un fdisk -l:

justine@serveurlvmraid:~$ sudo fdisk -l
Disque /dev/sdd : 1 GiB, 1073741824 octets, 2097152 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets

Disque /dev/sdc : 1 GiB, 1073741824 octets, 2097152 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets

Disque /dev/sdb : 1 GiB, 1073741824 octets, 2097152 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets

Disque /dev/sda : 8 GiB, 8589934592 octets, 16777216 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x468ddc7c

Périphérique Amorçage    Début      Fin Secteurs Taille Id Type
/dev/sda1    *            2048 12582911 12580864     6G 83 Linux
/dev/sda2             12584958 16775167  4190210     2G  5 Étendue
/dev/sda5             12584960 16775167  4190208     2G 82 partition d'échange Linux / Solaris

Mon disque système est sda, mes disques additionnels sont sdb, sdc et sdd.

On choisit de faire un RAID 1 (miroir - cf le tableau un peu plus haut):

justine@serveurlvmraid:~$ sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb /dev/sdc
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
Continue creating array?
Continue creating array? (y/n) y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.

Le détail de la commande :

• --level=1 correspond à du RAID1
• --raid-devices sert à choisir les disques à mettre en RAID
• --create /dev/md0 sert à préciser le disque dur virtuel qui sera constitué de nos deux disques.

On vérifie que cela s'est bien passé :

justine@serveurlvmraid:~$ sudo mdadm -D /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Tue Jan  8 22:42:29 2019
     Raid Level : raid1
     Array Size : 1047552 (1023.00 MiB 1072.69 MB)
  Used Dev Size : 1047552 (1023.00 MiB 1072.69 MB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Tue Jan  8 22:42:36 2019
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           Name : serveurlvmraid:0  (local to host serveurlvmraid)
           UUID : a0045f45:6ad1c193:fe374a5b:fb7a654b
         Events : 17

    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       1       8       32        1      active sync   /dev/sdc

Notre création s'est bien passée, un fdisk -l nous informe même de la création de /dev/md0, reconnu comme étant un disque d'1 Go :

Disque /dev/md0 : 1023 MiB, 1072693248 octets, 2095104 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets

Ajout d'un disque en spare

Notre troisième disque sera ajouté en spare au RAID, c'est-à-dire qu'il servira de disque de remplacement en cas de problème:

justine@serveurlvmraid:~$ sudo mdadm --manage /dev/md0 --add /dev/sdd
mdadm: added /dev/sdd

On peut vérifier comme tout à l'heure:

justine@serveurlvmraid:~$ sudo mdadm -D /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Tue Jan  8 22:42:29 2019
     Raid Level : raid1
     Array Size : 1047552 (1023.00 MiB 1072.69 MB)
  Used Dev Size : 1047552 (1023.00 MiB 1072.69 MB)
   Raid Devices : 2
  Total Devices : 3
    Persistence : Superblock is persistent

    Update Time : Tue Jan  8 22:48:50 2019
          State : clean
 Active Devices : 2
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 1

           Name : serveurlvmraid:0  (local to host serveurlvmraid)
           UUID : a0045f45:6ad1c193:fe374a5b:fb7a654b
         Events : 18

    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       1       8       32        1      active sync   /dev/sdc

       2       8       48        -      spare   /dev/sdd

On voit que le disque en spare a été ajouté.

Que faire avec un système qui ne boote plus et deux disques en RAID?

La procédure donnée dans le TP est la suivante :

• Booter sur un liveCD (genre systemrescuecd)
• mdadm --examine -scan >> /etc/mdadm/mdadm.conf #Donne entre autre l'UUID du RAID
• service mdadm-raid restart
• mount /dev/mdX /mnt/raidX

Remplacement d'un disque dur à chaud

Mise en panne (simulée) d'un disque

Pour tester l'efficacité de notre RAID, on va simuler la panne d'un disque physique, afin de montrer l'utilité du RAID :

justine@serveurlvmraid:~$ sudo mdadm --fail /dev/md0 /dev/sdc
mdadm: set /dev/sdc faulty in /dev/md0

On suit ensuite les différentes étapes de reconstruction :

watch -n 1 'cat /proc/mdstat'
#Ou, plus clair :
watch -n 1 'sudo mdadm --detail /dev/md0'

Sur nos disques vides, c'est très rapide, mais on voit bien que sdd a pris le relais :

Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       2       8       48        1      active sync   /dev/sdd

       1       8       32        -      faulty   /dev/sdc

Remplacement (simulé) d'un disque

Il suffit d'enlever le disque et de le remettre, comme on le ferait dans une baie :

justine@serveurlvmraid:~$ sudo mdadm --manage --remove /dev/md0 /dev/sdc
mdadm: hot removed /dev/sdc from /dev/md0
justine@serveurlvmraid:~$ sudo mdadm --manage --add /dev/md0 /dev/sdc
mdadm: added /dev/sdc

Une dernière vérification avec mdadm -D /dev/md0 nous donne :

    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       2       8       48        1      active sync   /dev/sdd

       3       8       32        -      spare   /dev/sdc

sdc est bel et bien de retour, cette fois-ci en tant que spare.

Rendre la config définitive

C'est simple :

root@serveurlvmraid:/etc/mdadm# mdadm --detail -scan >> /etc/mdadm/mdadm.conf

(Pour une raison étrange, cela ne fonctionne pas avec sudo, il faut se logger en tant que root). 

LVM

NB : Des notes plus anciennes concernant LVM (un peu plus "noob-friendly") sont disponibles là : Filesystems

<pdf>Fichier:02-lvm.pdf</pdf>

LVM signifie "Logical Volume Manager". Il permet différents type d'opérations:

• Ajout et retrait d'unités de disques : cela permet de la maintenance et l'utilisation temporaire de disques
• Augmentation / diminution de la capacité de stockage, avec des transferts entre volumes logiques sur un même système
• Redimensionnement dynamique : Permet l'extension d'un système de fichiers en ligne
• Déplacement des données entre les unités de disques, avec une préparation à l'extraction d'unités de disques
• Des snapshots des volumes logiques
• De la réplication, via des copies entre les volumes logiques.

On a trois solutions pour faire du RAID :

• Du LVM, sur lequel viennent se greffer dmsetup / mdadm pour le RAID et ext4
• ZFS
• btrfs

LVM est un gestionnaire de périphérique en mode bloc, qui fonctionne au niveau système : il prend en charge des partitions ou n'importe quel autre périphérique de stockage. La vue système est homogène, les périphériques étant vus comme un seul périphérique logique par le système. On peut donc faire l'analogie entre volume et partition, puisqu'on peut tous les deux les formater, mais ils sont bel et bien DIFFÉRENTS ! La configuration peut changer de façon dynamique, avec des snapshots, du redimensionnement, extensions, déplacements... Pour reprendre le schéma de mes précédentes notes, qui met en valeur Volume Physique, Groupe de Volumes et Volume Logique :

LVM2 sur Linux

LVM2 sur Linux est pris en charge au niveau Kernel par Device mapper module et au niveau utilisateur par le paquet lvm2, avec le striping en option.

À chacune de nos unités semble correspondre une commande:

• pvcreate pour Physical Volume
• vgcreate pour Volume Group
• lvcreate pour Logical Volume

LVM : mise en place

<pdf>Fichier:tp2lvm.pdf</pdf>

Pour ce TP, je repars de la machine précédente, telle que je l'avais laissée.

Je commence par installer le paquet lvm2:

sudo apt install lvm2

Création des volumes

Nous avons notre RAID, qui travaille au niveau bloc. LVM travaille lui au niveau "gestionnaire de périphérique". On aura donc trois couches successives (en quelque sorte) sur nos disques:

• mdadm qui gère le RAID au niveau bloc
• LVM qui gère le disque virtuel du RAID (md0) en tant que périphérique
• ext4 qui sera le FS utilisé par le système.

On va devoir créer nos trois "unités" LVM.

Création du volume physique

justine@serveurlvmraid:/etc/mdadm$ sudo pvcreate /dev/md0
  Physical volume "/dev/md0" successfully created.

Création du groupe de volumes

justine@serveurlvmraid:/etc/mdadm$ sudo vgcreate groupevol /dev/md0
  Volume group "groupevol" successfully created

Notre groupe de volumes est créé, il porte le nom "groupevol".

Création de deux volumes logiques

On va créer deux volumes logiques (qui fonctionneront donc un peu comme disques traditionnels directement formatés en ext4) de 256 Mo chacun, vol1 et vol2, à partir de notre groupe groupevol.

justine@serveurlvmraid:~$ sudo lvcreate -n vol1 -L 256M groupevol
  Logical volume "vol1" created.
justine@serveurlvmraid:~$ sudo lvcreate -n vol2 -L 256M groupevol
  Logical volume "vol2" created.

Ils sont mêmes visibles dans fdisk !

Disque /dev/mapper/groupevol-vol1 : 256 MiB, 268435456 octets, 524288 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets

Disque /dev/mapper/groupevol-vol2 : 256 MiB, 268435456 octets, 524288 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
justine@serveurlvmraid:~$

Formatage et montage des volumes

Il faut désormais les formater en ext4, ici avec mkfs:

justine@serveurlvmraid:~$ sudo mkfs -t ext4 /dev/groupevol/vol1
mke2fs 1.43.4 (31-Jan-2017)
En train de créer un système de fichiers avec 262144 1k blocs et 65536 i-noeuds.
UUID de système de fichiers=0497b299-d302-4bfa-b2a9-d0fad5c96e0f
Superblocs de secours stockés sur les blocs :
    8193, 24577, 40961, 57345, 73729, 204801, 221185

Allocation des tables de groupe : complété                        
Écriture des tables d'i-noeuds : complété                        
Création du journal (8192 blocs) : complété
Écriture des superblocs et de l'information de comptabilité du système de
fichiers : complété

justine@serveurlvmraid:~$ sudo mkfs -t ext4 /dev/groupevol/vol2
mke2fs 1.43.4 (31-Jan-2017)
En train de créer un système de fichiers avec 262144 1k blocs et 65536 i-noeuds.
UUID de système de fichiers=d3663a80-cb8b-42a9-be70-f4b271486735
Superblocs de secours stockés sur les blocs :
    8193, 24577, 40961, 57345, 73729, 204801, 221185

Allocation des tables de groupe : complété                        
Écriture des tables d'i-noeuds : complété                        
Création du journal (8192 blocs) : complété
Écriture des superblocs et de l'information de comptabilité du système de
fichiers : complété

Enfin, on a plus qu'à les monter pour les utiliser (il faut d'abord créer les dossiers qui serviront de point de montage):

justine@serveurlvmraid:~$ sudo mkdir /mnt/lv1 /mnt/lv2
justine@serveurlvmraid:~$ sudo mount /dev/groupevol/vol1 /mnt/lv1
justine@serveurlvmraid:~$ sudo mount /dev/groupevol/vol2 /mnt/lv2

Si à ce stade, mount renvoie une erreur du type "le disque est en lecture seule", il faut vérifier qu'ils ont bien été formatés.

Agrandissement à chaud des volumes logiques

On va ici vouloir agrandir à chaud le système de fichiers vol2 à 512 Mo : c'est possible.

Agrandissement du volume logique

On commence bien sûr par agrandir notre volume logique.

justine@serveurlvmraid:~$ sudo lvresize -L 512M /dev/groupevol/vol2
  Size of logical volume groupevol/vol2 changed from 256,00 MiB (64 extents) to 512,00 MiB (128 extents).
  Logical volume groupevol/vol2 successfully resized.

Agrandissement du système de fichiers

On agrandit le FS afin que les 512 Mo soient utilisables.

justine@serveurlvmraid:~$ sudo resize2fs -p /dev/groupevol/vol2 512M
resize2fs 1.43.4 (31-Jan-2017)
Le système de fichiers de /dev/groupevol/vol2 est monté sur /mnt/lv2 ; le changement de taille doit être effectué en ligne
old_desc_blocks = 2, new_desc_blocks = 4
Le système de fichiers sur /dev/groupevol/vol2 a maintenant une taille de 524288 blocs (1k).

 

Vérifications

La commande df -h nous montre bel et bien nos deux volumes logiques, parfaitement utilisables :

/dev/mapper/groupevol-vol1   240M    2,1M  222M   1% /mnt/lv1
/dev/mapper/groupevol-vol2   488M    2,3M  459M   1% /mnt/lv2

On constate au passage que les métadonnées prennent une certaine place.

Stockage en réseau : SAN

<pdf>Fichier:03-stockage-reseau.pdf</pdf>

Le stockage est devenu une fonction du réseau avec SAN. Les enjeux sont nombreux :

• Les besoins augmentent, on parle d'un facteur 2 tous les 18 mois
• On veut des systèmes interopérables et évolutifs, qui puissent étendre, copier, déplacer un volume de stockage
• On veut de la continuite de service, avec un service dispo 99,999% du temps
• Et tout cela avec de bonnes performances.

Les objectifs sont donc la "manageabilité", la scalabilité, et la disponibilité. On doit pourvoir faire face à nos contraintes : reprendre facilement le service en cas de panne, faire des sauvegardes, avoir des accès multi-liens (redondance, load balancing et QoS) et de la réplication.

Modes de stockage

On a différents modes de stockage :

• Bloc (Données rassemblées en blocs qui sont stockés comme des éléments séparés, chaque bloc a un identifiant) (Souvent présent en SAN)
• Fichier (Données stockées en tant qu'élément unique d'information dans un dossier : la méthode "classique")
• Objet (Fichier décomposés en éléments qui sont stockés répartis sur du matériel, au lieu d'être de simples fichiers ou des blocs sur un serveur)

cf https://www.redhat.com/fr/topics/data-storage/file-block-object-storage

Chacun de ces modes a une relation distincte avec les autres, ainsi que des avantages et des inconvénients.

Définition DAS

DAS signifie Direct Attached Storage. Il fonctionne en mode bloc : le dialogue se fait sous forme de trames, via SCSI ou Fiber Channel. Il est principalement utilisé sur les hôtes et sur les VM, ainsi que pour les transactions des SGBD. Il est performant, mais dépend pour sa redondance et sa haute disponibilité du matériel (avec RAID), et les nombres de disques par baie sont limités. Il prend généralement place au sein d'un réseau de stockage "dorsal", qui est composé de baies auxquelles sont rattachés l'hyperviseurj, par exemple : l'hyperviseur lui-même communique via un réseau IP "frontal" avec le reste de l'infra.

Système de fichiers virtuels VFS

Un VFS, c'est :

1. Un service du noyau
2. Une interface entre les applications / processus et les dispositifs de stockage
3. Une bibliothèque standard

Son but est d'avoir un accès transparent pour les applications et les utilisateurs. Il permet une gestion uniforme du contrôle d'accès au fichiers et répertoires, ainsi qu'un système de nommage cohérent entre les fichiers, qu'ils soient locaux ou sur le réseau. De plus, les performances d'accès doivent être uniformes grâce au cache.

Définition NAS

NAS signifie "Network Attached Storage". Il utilise différents FS : NFS chez Linux, SMB chez Microsoft. Il a l'avantage d'acceuillir beaucoup de clients, de coûter peu cher par unité de stockage, et de permettre diverses choses : tiering (positionner les données là ou c'est le mieux pour elles), caching, de-duplication. Il permet aussi la réplication et le multi-tenancy (servir plusieurs clients à partir d'une seule installation). Son incovénient est que sa Qualité de Service dépend du réseau.

Redéfinition du tiering : On fait des tiers (penser aux jeux vidéo : top tier, god tier, etc) des données en fonction de leur utilisation. Les plus utilisées seront dans le top tier, les moins utilisées dans le dernier tier. Ensuite, elles sont positionnées selon leur tier : le top tier aura des SSD ultra rapides, le dernier tier aura des disques à plateuax très lents... Les données sont hiérarcisée selon leur utilisation et les supports de stockage selon leur coût.

Les différents tiers permettent aussi d'avoir plusieurs niveaux de protection, selon la confidentialité des données.

NFS (Network File System)

Tuto NFS :

https://linux.developpez.com/formation_debian/nfs.html

NFS fonctionne simplement avec le système de montage sous Linux : des dossiers situés sur un NAS quelque part dans le réseau sont montés sur des dossiers locaux, ce qui permet d'y accéder de façon transparente. Je peux avoir mon dossier ~ situé sur un NAS, et le monter dans /home afin d'y accéder comme si de rien n'était.

On parle d'exportation côté NAS et de montage côté client.

Ses fonctions principales sont donc:

• Être un système de fichiers distribué, auquel on accède comme aux fichiers locaux
• Sur un modèle client/serveur
  • Le Serveur propose ses répertoires locaux accessibles aux clients
  • Les clients montent les répertoires distants
• Il est par nature hiérarchique, avec des chaînes de répertoires et de fichiers

Ses usages:

• Partage de dossiers : utilisateurs, données et applications exécutés localement
• Bases de données et VM datastores
• VMware supporte NFS4.1 en mode client pour le stockage de fichiers VMDK
• Amazon supporte NFS4.0 à travers EFS (AWS Elastic File System).

NFSv2, apparu en 83, était un protocole UDP uniquement local, qui était nul en performances d'écritures. La version 3 de 1995 a vu apparaître l'exportation de FS POSIX 64 bits, l'utilisation de TCP et UDP avec multiplexage de ports et de meilleures performances. La v4 de 2003, mise à jour en 2015, a réduit les temps de latence, et vu apparaître un port dédié : tcp 2049 (pour faciliter le filtrage); de plus, on a désormais des appels de procédures groupés (compound RPC) et un chiffrement des flux.

Une des évolutions de ce protocole est PNFS (ou Parallel NFS), qui agrège des serveurs NFS autonomes. La relation client-serveur est de type point-à-point : le client s'adresse à un serveur pNFS, qui redirige les clients vers différents NAS.

SMB (Server Message Block)

Les fonctions principales de SMB sont :

• Être un mode de partage standard des systèmes Crosoft
• SMB 3.0 est intégré à Windows Server 2012, et est optimisé pour les applications serveur.
• SMB 3.0 permet des performances adaptées aux clusters, de la tolérance aux pannes et du chiffrement AES.

Il est utilisé pour l'intégration Hyper-V et les produits Windows Server, ainsi que les bases de données SQL server.

SMB Direct permet le RDMA (Remote Direct Memory Access), et fournit des canaux d'accès directs de la mémoire d'un hôte à un autre à travers le réseau, grâce à Hyper-V.

SMB Multichannel quant à lui sert à distribuer les flux entres des interfaces mutliples.

Définition SAN

SAN, ou Storage Area Network, fonctionne en mode bloc. Il utilise deux technologies : Fiber Channel pour ses trames, et iSCSI pour ses trames iSCSI + TCP. Ses usages sont les mêmes que ceux de DAS.

Il a pour avantage d'être très performant avec un réseau adapté, en 10Gbps d'un bout à l'autre. Il permet aussi la redondance de liens avec multipath. Cependant, il faut acheter des commutateurs avec des fonctions spécifiques (FCoE, Fiber Channel Over Ethernet).

Définition de l'object Storage

Un objet est composé d'un fichier plus ses métadonnées. On compte deux types de métadonnées:

• System metadata : Nom, taille, droits, horodatage
• Custom metadata : Genre, auteur, localisation, contexte de sécurité

Les métadonnées sont plus importantes que les données. Il est dans la tendance des stockages non structurés (mobile et cloud).

Nature des accès au stockage

On a un profil d'accès par application:

• Ratio R/W
• Ratio données/métadonnées
• Accès aléatoires ou séquentiels
• Efficacité de la compression
• Taille unitaire de blocs
• Commandes d'accès asynchrones ou par lots

On parle d'"IO blender effect" : "The I/O blender effect occurs when multiple virtual machines (VMs) all send their input/output (I/O) streams to a hypervisor for processing. Under heavy work loads, I/O processes which might otherwise have been relatively sequential, become random.  This increases the read/write activity on disk heads, which in turn, increases latency. This randomization can occur with all virtualization platforms. " (source : https://searchstorage.techtarget.com/definition/I-O-blender-effect)

Résumé des protocoles

Protocoles IP:

• iSCSI : protocole de stockage en réseau IP, en mode bloc, qui permet aux hôtes d'accéder à un disque via le réseau TCP/IP
• NFS : Protocole d'accès au réseau basé sur le FS
• SMB : Protocole Microsoft d'accès au stockage réseau basé sur le FS. SMB Direct est une variante d'accès direct entre application et réseau.

Les protocoles objet sont :

• CEPH : Protocole ouvert conçu pour le matériel de base. Il utilise l'algorithme CRUSH (Controlled Replication Under Sclabale Hashing) qui s'assure que les données sont réparties uniformément sur le stockage.
• Swift : modèle OpenStack de stockage objet redondant et évolutif. Peut utiliser un disposiutif de stockage unique et est compatible avec Amazon S3.
• Amazon S3 : solution de stockage en ligne AWS. Propose l'accès au stockage via REST, SOAP, Bittorent.

Détails d'iSCSI

Il présente des similitudes avec FC : mode bloc, mutlichemins et redondance MPIO, VLAN dédié au stockage. Il peut être un protocole sans pertes : les contraintes de latence sont gérées par oversubscription (connecter plusieurs appareils au même port de switch pour optimiser l'utilisation du switch). Les solution logicielles imposent un coût CPU plus élevé, et il demande un commutateur avec DCB (Data Center Bridging), qui est une série d'améliorations d'Ethernet pour l'utilisation dans le cadre d'un réseau de stockage / clustering.

On peut quand même aboutir à une architecture performante avec des switches en 10 gigas et des fonctions de DCB.

Plus clairement

SCSI signifie Small Computer System Interface, qui est la façon dont un système interagit avec un stockage. iSCSI est la même chose en réseau, ce qui permet de voir le stockage comme un disque local. Dans un lien iSCSI, on a deux composants:

• L'initiator, qui est la partie logicielle (comportant un pilote) sur le client qui va échanger des donner avec le stockage.
• La target, le server qui stocke les données. Chaque target est identifié par un nom unique appellé IQN. Une target peut être un composant matériel qui possède des disques durs, ou un convertisseur vers FC, etc.

Il s'agit donc d'un transport en mode bloc entre target et initiator, sur une connexion TCP/IP. Quand il reçoit les paquets, l'initiator sépare les blocs que le paquet TCP contient et les présente à l'OS comme un stockage normal. Ses perfs sont quasi-similaire à Fibre Channel, mais contrairement à FC, on a pas besoin d'infra-structure dédiée.

L'initiator utilise en général deux interfaces réseau par souci de redondance. On peut avoir alors plusieurs types :

• De l'aggrégat, ou LACP (Link Aggregation Control Protocol). LACP, comme quand on l'utilise sur un switch, permet d'agréger les interfaces entre elles pour en faire une seule "grosse". En réalité, LACP et le NIC teaming n'améliore pas le throughput sur un flux unique : chaque flux unique prendra toujours le même chemin et la même interface. LACP est utile quand on a plusieurs flux venant de plusieurs sources. Plus on aura de flux uniques, plus ajouter des NICs améliorera le throughput. Mais LACP en soi ne fait qu'améliorer la redondance.
• Du multipath, ou MPIO (pour MultiPath I/O). MPIO fait la même chose, mais peut être actif/passif ou actif/actif. Il permet d'utiliser plusieurs NICs pour envoyer et recevoir des I/O vers / depuis un server lui aussi en MPIO. MPIO améliore le throughput.

Mise en place d'un cluster de stockage en réseau GlusterFS

<pdf>Fichier:Tpcluster.pdf</pdf>

Dans cette mise en pratique, il s'agira de mettre en place un cluster de stockage en réseau avec GlusterFS. J'ai 3 machines sous Debian 9, à jour, auxquelles j'accède en SSH via le réseau NAT de VB :

• stockage1, 10.0.2.15
• stockage2, 10.0.2.6
• stockageclient, 10.0.2.7

Les IP ne sont pas logiques, mais c'est dû au DHCP (de toute façon, les noms d'hôtes sont configurés, alors je ne me perdrais pas).

Installation

On commence par installer glusterFS-server sur nos deux serveurs:

Sur les deux :

sudo apt update && sudo apt install glusterfs-server

On ouvre ensuite le port 111, toujours sur les deux machines :

sudo iptables -A INPUT -i enp0s3 -p tcp --dport 111 -j ACCEPT

On peut vérifier qu'il est ouvert :

justine@stockage1:~$ sudo lsof -i :111
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
rpcbind 5394 root    6u  IPv4  20885      0t0  UDP *:sunrpc
rpcbind 5394 root    8u  IPv4  20887      0t0  TCP *:sunrpc (LISTEN)
rpcbind 5394 root    9u  IPv6  20888      0t0  UDP *:sunrpc
rpcbind 5394 root   11u  IPv6  20890      0t0  TCP *:sunrpc (LISTEN)

(Les ports 24007 et les suivants sont normalement déjà ouverts).

Configuration

On autorise les deux serveurs à communiquer :

Sur serveur1:

justine@stockage1:~$ sudo gluster peer probe 10.0.2.6
peer probe: success. 

 

On peut vérifier l'état du stockage, sur l'un comme sur l'autre :

justine@stockage1:~$ sudo gluster peer status
Number of Peers: 1

Hostname: 10.0.2.6
Uuid: f0600e68-755f-4fd1-b7ac-3b8917f1d9c6
State: Peer in Cluster (Connected)

 

On va créer le volume de stockage :

Sur le serveur 1, j'essaye d'abord ça:

justine@stockage1:~$ sudo gluster volume create volumegluster replica 2 transport tcp 10.0.2.15:/donnees 10.0.2.6:/donnees
volume create: volumegluster: failed: The brick 10.0.2.15:/donnees is being created in the root partition. It is recommended that you don't use the system's root partition for storage backend. Or use 'force' at the end of the command if you want to override this behavior.

Ici, on crée le volume nommé "volumegluster", avec 2 répliques, en tcp; cependant, il n'as pas l'air enchanté à l'idée de créer le dossier "donnees" à la racine du disque, et nous demande de forcer. Pour coller au TP, je force :

justine@stockage1:~$ sudo gluster volume create volumegluster replica 2 transport tcp 10.0.2.15:/donnees 10.0.2.6:/donnees force
volume create: volumegluster: success: please start the volume to access data

Sur mes deux machines, le dossier "donnees" est apparu à la racine du disque :

justine@stockage2:~$ sudo ls /
bin   dev      etc   initrd.img      lib    lost+found    mnt  proc  run     srv  tmp  var        vmlinuz.old
boot  donnees  home  initrd.img.old  lib64  media    opt  root  sbin  sys  usr  vmlinuz

 

Je peux maintenant démarrer le volume :

Sur le serveur 1:

justine@stockage1:~$ sudo gluster volume start volumegluster
volume start: volumegluster: success

Il faut ensuite (dans mon cas) que je redémarre glusterfs avec systemctl (et non la commande service, qui n'as pas l'air de fonctionner), avant de pouvoir vérifier que le daemon glusterd tourne:

Sur les deux:

justine@stockage2:~$ sudo systemctl restart glusterfs-server
justine@stockage2:~$ sudo netstat -antpu | grep glusterd
tcp        0      0 0.0.0.0:24007           0.0.0.0:*               LISTEN      9027/glusterd       
tcp        0      0 127.0.0.1:24007         127.0.0.1:49147         ESTABLISHED 9027/glusterd       
tcp        0      0 10.0.2.6:49150          10.0.2.15:24007         ESTABLISHED 9027/glusterd       
tcp        0      0 10.0.2.6:24007          10.0.2.15:49151         ESTABLISHED 9027/glusterd       
tcp        0      0 10.0.2.6:24007          10.0.2.6:49149          ESTABLISHED 9027/glusterd    

 

On vérifie que le volume a bien démarré :

Sur les deux:

justine@stockage1:~$ sudo gluster volume info
 
Volume Name: volumegluster
Type: Replicate
Volume ID: ea863f7c-71cb-4670-a3fe-a0378d0a591d
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: 10.0.2.15:/donnees
Brick2: 10.0.2.6:/donnees
Options Reconfigured:
nfs.disable: on
performance.readdir-ahead: on
transport.address-family: inet

 

On va autoriser uniquement le client à accéder au volume :

Sur le serveur 1:

justine@stockage1:~$ sudo gluster volume set volumegluster auth.allow 10.0.2.7
volume set: success

Je peux vérifier que le changement s'est bien propagé et qu'il est effectif, en vérifiant directement depuis le deuxième serveur:
Serveur 2:

justine@stockage2:~$ sudo gluster volume info
 
Volume Name: volumegluster
Type: Replicate
Volume ID: ea863f7c-71cb-4670-a3fe-a0378d0a591d
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: 10.0.2.15:/donnees
Brick2: 10.0.2.6:/donnees
Options Reconfigured:
auth.allow: 10.0.2.7   #<=== C'est bon !
nfs.disable: on
performance.readdir-ahead: on
transport.address-family: inet

 

 

Configuration du client GlusterFS

Installation du client

Je vais installer le client GlusterFS sur la machine client.

Client:

justine@clientstockage:~$ sudo apt update && sudo apt install glusterfs-client

Avant de créer le point de montage :

Client:

justine@clientstockage:~$ sudo mkdir /mnt/donnees

 

On va ensuite monter le système de fichiers glusterfs sur ce point de montage :

justine@clientstockage:~$ sudo mount.glusterfs 10.0.2.15:/volumegluster /mnt/donnees

Et on vérifie que le montage s'est déroulé sans accrocs:

justine@clientstockage:~$ sudo mount | grep donnees
10.0.2.15:/volumegluster on /mnt/donnees type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072)

 Je peux vérifier que le stockage est bien à disposition, en l'occurence, il offre 5,3 Gigas:

justine@clientstockage:~$ df -h | grep donnees
10.0.2.15:/volumegluster   6,9G    1,3G  5,3G  20% /mnt/donnees

 

Je vais rajouter une ligne dans fstab pour que le montage soit automatique :

10.0.2.15:/volumegluster /mnt/donnees glusterfs defaults,_netdev 0 0

Attention de bien adapter la ligne, notamment l'adresse IP ! Un Fstab mal configuré est vite source de gros problèmes, comme un système de fichier inutilisable...

Avant de redémarrer le client puis de revérifier :

justine@clientstockage:~$ df -h
Sys. de fichiers         Taille Utilisé Dispo Uti% Monté sur
udev                       488M       0  488M   0% /dev
tmpfs                      100M    1,7M   99M   2% /run
/dev/sda1                  6,9G   1005M  5,5G  16% /
tmpfs                      499M       0  499M   0% /dev/shm
tmpfs                      5,0M       0  5,0M   0% /run/lock
tmpfs                      499M       0  499M   0% /sys/fs/cgroup
tmpfs                      100M       0  100M   0% /run/user/1000
10.0.2.15:/volumegluster   6,9G    1,3G  5,3G  20% /mnt/donnees

 

Tests

On va désormais tester la haute disponibilité.

D'abord créer quelques fichiers depuis le client:

sudo touch /mnt/donnees/test1 /mnt/donnees/test2

On vérifie qu'ils sont bien présent sur le serveur 1 et le client :

justine@clientstockage:~$ ls /mnt/donnees/
test1  test2

justine@stockage1:~$ sudo ls /donnees
test1  test2

(En passant, ils sont également présents sur le second serveur)

J'éteins le premier serveur, puis je modifie un peu les fichiers depuis le client:

Serveur 1 :

justine@stockage1:~$ sudo halt

Client :

justine@clientstockage:~$ sudo touch /mnt/donnees/test3 /mnt/donnees/test4
justine@clientstockage:~$ sudo rm -f /mnt/donnees/test2

Je rallume ensuite le serveur, et je regarde si les fichiers ont bien changé chez lui :

Serveur1:

justine@stockage1:~$ sudo ls /donnees/
test1  test3  test4

On voit que les données ont bien étées propagées à ce serveur qui était pourtant éteint lors des modifications ! Si besoin, il est apparement nécessaire parfois d'accéder au fichier depuis le client (avec un ls) pour que les changement soient propagés. Il en est de même pour le deuxième serveur:

justine@stockage2:~$ sudo ls /donnees/
test1  test3  test4

Cela fonctionne.

Mise en place d'un réseau iSCSI

<pdf>Fichier:Tpiscsi.pdf</pdf>

Dans ce TP, nous allons mettre en place un réseau de stockage SAN via iSCSI assez simple, composé de deux machines :

• L'initiateur sera une nouvelle VM Debian, IP : 10.0.2.9
• La cible sera ma machine "serveurlvmraid", qui a déjà servi lors d'un tp précédent (IP : 10.0.2.5)

Configuration de la cible

Méthode targetcli

Pour la configuration de la cible, je me base sur :

https://www.server-world.info/en/note?os=Debian_9&p=iscsi

J'utilise ici Targetcli. Targetcli est l'outil d'administration de LinuxIO (le moteur SCSI target depuis le noyau 2.6.3.8), créé par Datera, Inc. Il est fourni avec son propre shell.

Installation des outils d'administration :

sudo apt install -y targetcli-fb

Création d'un répertoire :

justine@serveurlvmraid:~$ sudo mkdir /var/lib/iscsi_disks

 

On ensuite rentrer dans la console de targetcli, et on se rend dans le dossier "backstores/fileio":

justine@serveurlvmraid:~$ sudo targetcli
Warning: Could not load preferences file /root/.targetcli/prefs.bin.
targetcli shell version 2.1.fb43
Copyright 2011-2013 by Datera, Inc and others.
For help on commands, type 'help'.

/> cd backstores/fileio
/backstores/fileio>

Création d'une image disque avec avec le nom disk01, de 3G, dans le dossier précédemment créé:

/backstores/fileio> create disk01 /var/lib/iscsi_disks/disk01.img 3G
Created fileio disk01 with size 3221225472
/backstores/fileio> cd /iscsi

Création de la cible:

/iscsi> create iqn.2019-01.world.srv:storage.target01
Created target iqn.2019-01.world.srv:storage.target01.
Created TPG 1.
Global pref auto_add_default_portal=true
Created default portal listening on all IPs (0.0.0.0), port 3260.
/iscsi> cd iqn.2019-01.world.srv:storage.target01/tpg1/luns

On va configurer le LUN. Le LUN (logical Unit Number) désigne le numéro d'unité logique d'un équipement SCSI; par extension, il désigne aussi le numéro d'identification d'une unité de stockage SAN. On utilise parfois le terme pour parler de l'espace de stockage lui-même.

/iscsi/iqn.20...t01/tpg1/luns> create /backstores/fileio/disk01
Created LUN 0.
/iscsi/iqn.20...t01/tpg1/luns> cd ../acls

On va mettre en place l'ACL, qui correspond à l'IQN (le nom unique de l'initiateur, un peu comme un FQDN). La règle de nommage est:

iqn.année-mois.domaine:un nom

/iscsi/iqn.20...t01/tpg1/acls> create iqn.2019-01.world.srv:www.srv.world
Created Node ACL for iqn.2019-01.world.srv:www.srv.world
Created mapped LUN 0.
/iscsi/iqn.20...t01/tpg1/acls> cd iqn.2019-01.world.srv:www.srv.world/

On va mettre en place UserID pour l'authentification (je garde mes identifiants de TP bien sûr, mais dans un contexte réel il faut quelque chose de sécurisé):

/iscsi/iqn.20...www.srv.world> set auth userid=justine
Parameter userid is now 'justine'.
/iscsi/iqn.20...www.srv.world> set auth password=Prevert77
Parameter password is now 'Prevert77'.
/iscsi/iqn.20...www.srv.world> exit
Global pref auto_save_on_exit=true
Last 10 configs saved in /etc/rtslib-fb-target/backup.
Configuration saved to /etc/rtslib-fb-target/saveconfig.json

La configuration est presque terminée... Une fois revenue sur mon shell bash, je vérifie que la cible est bien en écoute :

justine@serveurlvmraid:~$ ss -napt | grep 3260
LISTEN     0      256          *:3260                     *:*   

Méthode tgt

Cette méthode est plus simple, notamment parce qu'on aura pas besoin de donner un iqn à l'initiateur.

On va d'abord installer les paquets:

apt -y install tgt dkms

 

Puis on va configurer la cible. On commence par créer une image disque :

justine@serveurlvmraid:~$ sudo mkdir /var/lib/iscsi_disks

justine@serveurlvmraid:~$ sudo dd if=/dev/zero of=/var/lib/iscsi_disks/disk01.img count=0 bs=1 seek=3G
0+0 enregistrements lus
0+0 enregistrements écrits
0 bytes copied, 0,00161598 s, 0,0 kB/s

On va ensuite créer le fichier de configuration:

#/etc/tgt/conf.d/target01.conf

#create new
# naming rule : [ iqn.yaer-month.domain:any name ]

<target iqn.2019-01.ju.lab:macible>
    # provided devicce as a iSCSI target
    backing-store /var/lib/iscsi_disks/disk01.img
    # iSCSI Initiator's IP address you allow to connect
    initiator-address 10.0.2.9
    # authentication info ( set anyone you like for "username", "password" )
    incominguser justine Prevert77
</target>

Et on relance le service :

justine@serveurlvmraid:~$ sudo systemctl restart tgt

Puis on vérifie :

justine@serveurlvmraid:~$ sudo tgtadm --mode target --op show
Target 1: iqn.2019-01.ju.lab:macible
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: null
            Backing store path: None
            Backing store flags:
        LUN: 1
            Type: disk
            SCSI ID: IET     00010001
            SCSI SN: beaf11
            Size: 3221 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: rdwr
            Backing store path: /var/lib/iscsi_disks/disk01.img
            Backing store flags:
    Account information:
        justine
    ACL information:
        10.0.2.9

 

Configuration de l'initiateur

Installation des paquets nécessaires :

sudo apt install open-iscsi

On passe ensuite à la configuration via le fichier /etc/iscsi/iscsid.conf. Il en existe déja un en place, je le modifie :

#/etc/iscsi/iscsid.conf

node.startup = automatic
node.session.auth.authmethod = CHAP
node.session.auth.username = justine
node.session.auth.password = Prevert77
discovery.sendtargets.auth.username = justine
discovery.sendtargets.auth.password = Prevert77

Et de relancer le service et de vérifier :

justine@iscsiinitiateur:/etc/iscsi$ sudo systemctl restart open-iscsi
justine@iscsiinitiateur:/etc/iscsi$ sudo systemctl status open-iscsi
● open-iscsi.service - Login to default iSCSI targets
   Loaded: loaded (/lib/systemd/system/open-iscsi.service; enabled; vendor preset: enabled
   Active: active (exited) since Thu 2019-01-10 18:10:51 CET; 5s ago
     Docs: man:iscsiadm(8)
           man:iscsid(8)

 

On va se connecter à notre cible pour voir ce qu'elle partage :

justine@iscsiinitiateur:/etc/iscsi$ sudo iscsiadm -m discovery -t st -p 10.0.2.5
10.0.2.5:3260,1 iqn.2019-01.ju.lab:macible

justine@iscsiinitiateur:/etc/iscsi$ sudo iscsiadm -m node
10.0.2.5:3260,1 iqn.2019-01.ju.lab:macible

 

On va inscrire nos identifiants dans iqn.2019-01.ju.lab:macible/10.0.2.5,3260,1/default

justine@iscsiinitiateur:/etc/iscsi$ sudo iscsiadm -m node --targetname "iqn.2019-01.ju.lab:macible" --portal "10.0.2.5:3260" --op=update --name node.session.auth.authmethod --value=CHAP

justine@iscsiinitiateur:/etc/iscsi$ sudo iscsiadm -m node --targetname "iqn.2019-01.ju.lab:macible" --portal "10.0.2.5:3260" --op=update --name node.session.auth.username --value=justine

justine@iscsiinitiateur:/etc/iscsi$ sudo iscsiadm -m node --targetname "iqn.2019-01.ju.lab:macible" --portal "10.0.2.5:3260" --op=update --name node.session.auth.password --value=Prevert77

Puis on redémarre le service afin de vérifier la connexion automatique :

sudo systemctl restart open-iscsi
justine@iscsiinitiateur:/etc/iscsi$ sudo systemctl status open-iscsi

###On voit, à la fin du status:
janv. 10 19:30:07 iscsiinitiateur systemd[1]: Stopped Login to default iSCSI targets.
janv. 10 19:30:07 iscsiinitiateur systemd[1]: Starting Login to default iSCSI targets...
janv. 10 19:30:07 iscsiinitiateur iscsiadm[15477]: Logging in to [iface: default, target:
janv. 10 19:30:07 iscsiinitiateur iscsiadm[15477]: Login to [iface: default, target: iqn.2 [...]
janv. 10 19:30:07 iscsiinitiateur systemd[1]: Started Login to default iSCSI targets.

 

Mon disque est bien apparu en tant que sdb:

justine@iscsiinitiateur:/etc/iscsi$ sudo fdisk -l
Disque /dev/sda : 8 GiB, 8589934592 octets, 16777216 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x327a2f96

Périphérique Amorçage    Début      Fin Secteurs Taille Id Type
/dev/sda1    *            2048 14680063 14678016     7G 83 Linux
/dev/sda2             14682110 16775167  2093058  1022M  5 Étendue
/dev/sda5             14682112 16775167  2093056  1022M 82 partition d'échange Linux / Solaris


Disque /dev/sdb : 3 GiB, 3221225472 octets, 6291456 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets

On va le formater, le monter, vérifier son état :

justine@iscsiinitiateur:/etc/iscsi$ sudo fdisk /dev/sdb  # Créer une partition primaire

justine@iscsiinitiateur:/etc/iscsi$ sudo mkfs.ext4 /dev/sdb1
mke2fs 1.43.4 (31-Jan-2017)
En train de créer un système de fichiers avec 786176 4k blocs et 196608 i-noeuds.
UUID de système de fichiers=308ef889-89f7-4001-928d-3454ae6196c8
Superblocs de secours stockés sur les blocs :
    32768, 98304, 163840, 229376, 294912

Allocation des tables de groupe : complété                        
Écriture des tables d'i-noeuds : complété                        
Création du journal (16384 blocs) : complété
Écriture des superblocs et de l'information de comptabilité du système de
fichiers : complété

justine@iscsiinitiateur:/etc/iscsi$ sudo mount /dev/sdb1 /mnt

justine@iscsiinitiateur:/etc/iscsi$ df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev               488M       0  488M   0% /dev
tmpfs              100M    3,0M   97M   3% /run
/dev/sda1          6,9G    1,2G  5,3G  19% /
tmpfs              499M       0  499M   0% /dev/shm
tmpfs              5,0M       0  5,0M   0% /run/lock
tmpfs              499M       0  499M   0% /sys/fs/cgroup
tmpfs              100M       0  100M   0% /run/user/0
tmpfs              100M       0  100M   0% /run/user/1000
/dev/sdb1          2,9G    9,0M  2,8G   1% /mnt

Il marche ! On peut l'ajouter dans fstab:

justine@iscsiinitiateur:/etc/iscsi$ sudo mkdir /stockage

#Ajouter à Fstab:
/dev/sdb1       /stockage       ext4    defaults,auto,_netdev 0 0

Je peux reboot et vérifier à nouveau avec df -h:

justine@iscsiinitiateur:~$ df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev               488M       0  488M   0% /dev
tmpfs              100M    1,7M   99M   2% /run
/dev/sda1          6,9G    1,2G  5,3G  19% /
tmpfs              499M       0  499M   0% /dev/shm
tmpfs              5,0M       0  5,0M   0% /run/lock
tmpfs              499M       0  499M   0% /sys/fs/cgroup
/dev/sdb1          2,9G    9,0M  2,8G   1% /stockage
tmpfs              100M       0  100M   0% /run/user/1000

Sauvegarde et stockage

Il existes plusieurs type de sauvegardes :

• Complète : On stocke un volume / Système de fichiers complet. Consomme beaucoup de temps et de bande passante.
• Incrémentale : On ne stocke que les choses qui ont changé depuis la dernière sauvegarde. Consomme moins de temps et de bande passante.
• Différentielle : On ne stocke que ce qui as changé depuis la dernière sauvegarde complète. Consomme peu de temps et de bande passante.
• Hors ligne : On a alors une fenêtre de blocage des écritures qui est imposée, cela a un impact important sur l'architecture des services.
• En ligne : Le contrôle d'intégrité est difficile, et on peut avoir des conflits entre les services et les sauvegardes.

La déduplication est importante, car elle permet d'économiser de l'espace disque et des écritures. Elle sert pour les VMs. De la même façon, il est important d'avoir du chiffrement : que ce soit au niveau du transfert quand le client est sauvegardé via des réseaux publics, ou au niveau du stockage quand il est fait sur des ressources publiques.

La restauration doit être testée, et si possible facilitée par une interface pour que les utilisateurs puissent être autonomes. Il existe des solutions locales :

• BackupPC
• BareOS (un fork de bacula)
• Duplicity ou BorgBackup
• Burp
• Backshift
• Obnam
• Tahoe-LAFS
• BackupNinja
• Bup

Mais aussi des solutions cloud :

• Amazon (S3 / Glacier)
• Google Drive
• OVH
• Rackspace
• etc

Mais dans tous les cas, un système corrompu doit pouvoir accéder aux sauvegardes.Un utilisateur spécifique du système à sauvegarder est utilisé pour accéder aux ressources, et l'accès est fait à la demande par le serveur de sauvegarde avec un script et par un canal chiffré. Les sauvegardes et archives sont chiffrées également avec une clef connue uniquement du serveur de sauvegarde.

 

Mise en place d'un serveur de sauvegardes backuppc

<pdf>Fichier:Tpbackuppc.pdf</pdf>

Il s'agira de créer un serveur de sauvegarde sous BackupPC, avec des machines hétérogènes et de la déduplication. On va reprendre notre serveurlvmraid (après avoir enlevé le SAN du fstab, histoire de repartir sur des bases simples) déjà préparé avec LVM. Il nous permettra de faire face à un volume de sauvegardes grandissant. Le client sera la machine utilisée comme client GlusterFS (clientstockage). Il faut aussi penser à la redirection de ports dans le réseau NAT de VB pour le web vers le serveur backuppc.

Attention : Ce TP est un peu complexe; on va souvent devoir changer d'utilisateur. Il faut bien regarder le prompt que j'ai mis à chaque fois dans mes blocs de texte ! Par exemple, quand je suis connectée en tant que backuppc sur le serveur, le prompt donne juste le signe $.

Serveur : serveurlvmraid (10.0.2.5)
Client : clientstockage (10.0.2.8)

Installation

Comme toujours, on installe les paquets:

justine@serveurlvmraid:~$ sudo apt install backuppc rsync libfile-rsyncp-perl par2 rrdtool openssh-client

Pendant l'installation, noter l'utilisateur backuppc et son mot de passe (ici : backuppc - U24xZN5p). si besoin, on peut modifier ce mot de passe avec :

sudo htpasswd /etc/backuppc/htpasswd backuppc

#Au pire:
sudo dpkg-reconfigure backuppc
#Et ajouter un alias backuppc à la configuration apache

Je peux aller voir mon interface web d'administration (après un reboot).

Configuration du serveur

Je vais ajouter la machine client aux machines à sauvegarder :

#/etc/backuppc/hosts
#J'ajoute à la fin:
10.0.2.8        0       root

Et je configure la méthode de sauvegarde:

#/etc/backuppc/config.pl
#Je vérifie que les lignes concernées correspondent bien, noter que la dernière est commentée et doit le rester !

$Conf{XferMethod} = 'rsync';
$Conf{RsyncClientPath} = '/usr/bin/rsync';
$Conf{RsyncClientCmd} = '$sshPath -q -x -l root $hostIP $rsyncPath $argList+';
$Conf{RsyncClientRestoreCmd} = '$sshPath -q -x -l root $hostIP $rsyncPath $argList+';
$Conf{RsyncShareName} = '/mnt/glusterfs'; #Correspond à: quels dossiers du client je sauvegarde?
#$Conf{RsyncShareName} = ['/', '/var', '/data', '/boot']; #À commenter si ce n'est pas le cas

Puis je redémarre le service.

justine@serveurlvmraid:~$ sudo systemctl restart backuppc

 

 Configuration du client

On installe les paquets sur le client :

sudo apt install rsync openssh-server

On lui crée une paire de clefs:

justine@clientstockage:~$ sudo ssh-keygen -t rsa

On va faire de même SUR LE SERVEUR:

justine@serveurlvmraid:~$ su
root@serveurlvmraid:/home/justine# su backuppc
$ cd ~
$ cd  .ssh
$ ssh-keygen -t rsa

On va copier la clef publique du serveurlvmraid vers le client (après avoir ajouté le PermitRootLogin yes au fichier de configuration sshd du client et en redémarrant sshd) (Attention, le ~ de backuppc est dans /var/lib/backuppc):

$ scp id_rsa.pub root@10.0.2.8:/root/.ssh/BackupPC_id_rsa.pub

On autorise backuppc à s'identifier automatiquement sur le client :

root@clientstockage:~/.ssh# cat ~/.ssh/BackupPC_id_rsa.pub >> ~/.ssh/authorized_keys2

On copie la clef publique de client vers le serveur Backuppc (en ajoutant là aussi le PermitRootLogin et en redémarrant sshd):

root@clientstockage:~/.ssh# scp id_rsa.pub root@10.0.2.5:/root/.ssh/client_id_rsa.pub

On ajoute la clef publique client à Backuppc.

root@serveurlvmraid:/var/lib/backuppc/.ssh# mv ~/.ssh/client_id_rsa.pub /var/lib/backuppc/.ssh/
root@serveurlvmraid:/var/lib/backuppc/.ssh# su backuppc
$ cat ~/.ssh/client_id_rsa.pub >> ~/.ssh/known_hosts
$ exit
root@serveurlvmraid:/var/lib/backuppc/.ssh# rm -f /var/lib/backuppc/.ssh/client_id_rsa.pub
root@serveurlvmraid:/var/lib/backuppc/.ssh# su backuppc
$ chmod -R go-rwx ~/.ssh

Idem sur le client :

root@clientstockage:~/.ssh# chmod -R go-rwx ~/.ssh

 

 

Tests

On a plus qu'à tester l'authentification automatique depuis le serveur :

root@serveurlvmraid:~/.ssh# su backuppc
$ ssh -l root 10.0.2.8 whoami
root

Il doit bien renvoyer root sans demander de mot de passe. 

ATTENTION !!! : Une chose que le TP ne détaille pas, c'est que backuppc essaye de stocker dans ses backups le contenu de /mnt/glusterfs (d'après le fichier /etc/backuppc/config.pl) : il faut que ce dossier existe. Ça peut être un montage glusterfs ou pas, mais il faut bien qu'il existe  sur le client!

D'ailleurs, ce serait étrange de faire des backups du NAS glusterfs en passant depuis le client de ce NAS... Non?

On va du coup tenter une backup de notre hôte : depuis l'interface web:

• "Select a host" ===> Choisir le client
• "Start full backup"  ===> Il répond toujours OK, même quand c'est pas OK
• Il faut aller voir dans les logs (Menu de gauche => "LOG File")
• En cas de backup réussie, la ligne "Finished full backup on 10.0.2.8" doit apparaître
  • On peut aussi avoir des infos sur la page dédiée au client

Sauvegarde d'un client Windows (via SMB et non plus NFS):

Je n'ai pas de client Windows pour tester, mais la config donnée est la suivante :

#/etc/backuppc/windows.pl
$Conf{SmbShareName} = 'nomdupartagesmb';
$Conf{SmbShareUserName} = 'utilisateur';
$Conf{SmbSharePasswd} = 'motdepasse';
$Conf{XferMethod} = 'smb';

Sachant que l'on part d'un dossier Windows partagé.

TP : Serveur FreeNAS clefs en mains

<pdf>Fichier:FreeNAS.pdf</pdf>

Principales différences entre le SAN et le NAS.

SAN	NAS
Orienté paquets SCSI	Orienté fichier
Basé sur le protocole Fibre Channel	Basé sur le protocole Ethernet
Le stockage est isolé et protégé de l’accès client général	Conçu spécifiquement pour un accès client général
Support des applications serveur avec haut niveau de performances SCSI	Support des applications client dans un environnement NFS/CIFS hétérogène
Le déploiement est souvent complexe	Peut être installé rapidement et facilement

Taille de secteur, taille de bloc

Il faut distinguer les deux notions.

Secteur

Le secteur est la plus petite unité *physique* de stockage sur un disque dur. Sa capacité est au minimum de 512 octets sur un disque dur ou une disquette, 2048 octets pour un disque optique.

La plupart des systèmes d'exploitation regroupent les secteurs dans leur système de fichiers en unités logiques de stockage appelées unité d'allocation sous Windows (et *NIX, semble-t'il). Le nombre de secteurs par bloc varie en fonction de la taille de la partition ou du médium, de 2 pour une disquette (FAT12) à 128 (64 ko) pour les plus grandes partitions ext4, NTFS.

Bloc

https://fr.wikipedia.org/wiki/Bloc_(disque_dur) Le bloc (ou en anglais cluster) est la plus petite unité *logique* de stockage d'un système de fichiers (utilisé sur une partition d'un disque dur) d'un système informatique. Le choix de la taille de bloc est effectué lors du formatage du disque, et influe sur les performances et sur la capacité utile du disque.

Il y'a un compromis à trouver pour la taille de bloc, puisque c'est la plus petite unité de données qui sera transmise : le ratio est donc entre taille de bloc et quantité d'I/O. En effet:

• Si j'ai un fichier de 1 ko et des blocs de 4 ko, je perd trois ko.
• Si j'ai des fichiers de 100 ko répartis sur 100 bloc de 1 ko, j'ai 100 I/O !

Consulter la taille de bloc

Linux :

blockdev --getbsz /dev/vdb1

Windows (cmd):

fsutil fsinfo sectorInfo C: