• 1To
• 1,5To
• 2To
• 2To

Ce qui me donnait donc en RAID5 : (4-1 disques)*1To = 3To

Le dernier disque de 1To est à remplacer et je me présente donc avec des disques de 1,5To et 2To. On peut donc envisager d’utiliser toute l’espace disponible c’est à dire (4-1 disques)*1,5To=4,5To.

Pourquoi se priver de ces 1,5To supplémentaires sans trop de souci ?

Étapes à suivre pour éviter la perte de données

Voici donc la manip basée en machine virtuelle sur des disques de 10Go, 15Go, et 4 de 20Go. Je change le disque de 10Go pour un 20Go. J’aurai donc 15Go et 5 de 20Go.

1. Vérifier l’état de son raid
2. Vérifier le système de fichier
3. Remplacer le disque dur
4. Augmenter l’array
5. Augmenter le système de fichier

Vérifier l’état de son raid

Vérifier que votre RAID n’a pas de secteur défectueux avant tout!

root@omv:~# cat /sys/block/md0/md/sync_action
idle
root@omv:~# echo check > /sys/block/md0/md/sync_action 
root@omv:~# cat /sys/block/md0/md/sync_action
check

Vous pouvez voir l’état d’avancement du check via mdstat :

root@omv:~# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdb[6] sdg[5] sdf[4] sde[3] sdd[2] sdc[1]
      52385280 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU]
      [>....................]  check =  1.0% (108552/10477056) finish=7.9min speed=21710K/sec
      
unused devices: <none>

Les disques du test sont en RAID5 avec 6 disques avec le plus petit de 10Go, donc 50Go sur le RAID.

Vérifier les caractéristiques de votre RAID :

root@omv:~# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Thu May  7 20:53:42 2015
     Raid Level : raid5
     Array Size : 52385280 (49.96 GiB 53.64 GB)
  Used Dev Size : 10477056 (9.99 GiB 10.73 GB)
   Raid Devices : 6
  Total Devices : 6
    Persistence : Superblock is persistent

    Update Time : Tue May 12 00:14:17 2015
          State : clean 
 Active Devices : 6
Working Devices : 6
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : omv:data  (local to host omv)
           UUID : 66136108:2ba95ce4:6f028202:33e061ea
         Events : 411

    Number   Major   Minor   RaidDevice State
       7       8       96        0      active sync   /dev/sdg
       6       8      112        1      active sync   /dev/sdh
       2       8       32        2      active sync   /dev/sdc
       3       8       48        3      active sync   /dev/sdd
       4       8       64        4      active sync   /dev/sde
       5       8       80        5      active sync   /dev/sdf

Vérifier le système de fichier

Vu que vous aller augmenter le système de fichiers, pensez à le vérifier et corriger les problèmes :

fsck.ext4 -fy /dev/md0

Remplacer le disque dur

Mettez le disque de plus petite taille en fault et retirez le du RAID :

mdadm /dev/md0 -f /dev/sdc
mdadm /dev/md0 -r /dev/sdc

Vous pouvez maintenant retirer physiquement le disque dur pour y mettre le nouveau.

Il ne reste plus qu’à faire un add du nouveau disque et attendre la synchronisation mdadm.

mdadm /dev/md0 -a /dev/sdb

Augmenter l’array RAID mdadm

Une fois que le RAID a été reconstruit suite à l’ajout d’un nouveau disque de 20Go, il reste donc un disque de 15Go et des disques de 20Go. Je peux donc passer de 50Go de RAID à 75Go : 6 disques en RAID5 15Go*5=75Go.

Avec grow on peut soit ajouter un nouveau disque au RAID, soit comme ici prendre en compte que la taille des disques a changé. On peut réduire un array RAID en lui mettant une taille définie, pour supprimer un disque p.e. Mais dans notre cas on veut augmenter au maximum et donc on utilise le mot clé « max » :

root@omv:~# mdadm --grow /dev/md0 --size=max
mdadm: component size of /dev/md0 has been set to 15720448K
root@omv:~# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdg[7] sdf[5] sde[4] sdd[3] sdc[2] sdh[6]
      78602240 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU]
      [==============>......]  resync = 73.0% (11488508/15720448) finish=0.9min speed=72246K/sec
      
unused devices: <none>
root@omv:~# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdg[7] sdf[5] sde[4] sdd[3] sdc[2] sdh[6]
      78602240 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU]

On voit que l’on passe à 15Go d’espace par disques au lieu de 10Go : 15720448K

On vérifie que l’on dispose bien de 75Go dans notre RAID mdadm :

root@omv:~# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Thu May  7 20:53:42 2015
     Raid Level : raid5
     Array Size : 78602240 (74.96 GiB 80.49 GB)
  Used Dev Size : 15720448 (14.99 GiB 16.10 GB)
   Raid Devices : 6
  Total Devices : 6
    Persistence : Superblock is persistent

    Update Time : Tue May 12 00:33:14 2015
          State : active 
 Active Devices : 6
Working Devices : 6
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : omv:data  (local to host omv)
           UUID : 66136108:2ba95ce4:6f028202:33e061ea
         Events : 420

    Number   Major   Minor   RaidDevice State
       7       8       96        0      active sync   /dev/sdg
       6       8      112        1      active sync   /dev/sdh
       2       8       32        2      active sync   /dev/sdc
       3       8       48        3      active sync   /dev/sdd
       4       8       64        4      active sync   /dev/sde
       5       8       80        5      active sync   /dev/sdf

Augmenter le système de fichier

On vérifie la taille actuelle avant, ici j’avais 50Go :

root@omv:~# df -h
Sys. fich.                                             Taille Util. Dispo Uti% Monté sur
rootfs                                                   7,6G  1,1G  6,1G  15% /
udev                                                      10M     0   10M   0% /dev
tmpfs                                                    303M  484K  302M   1% /run
/dev/disk/by-uuid/0caa296b-e542-4302-a240-7faaee84af1a   7,6G  1,1G  6,1G  15% /
tmpfs                                                    5,0M     0  5,0M   0% /run/lock
tmpfs                                                    682M     0  682M   0% /run/shm
tmpfs                                                    1,5G     0  1,5G   0% /tmp
/dev/md0                                                  50G  180M   49G   1% /mnt

Et on fait un simple resize2fs et on vérifie que l’on à bien 75Go après.

root@omv:~# resize2fs /dev/md0
resize2fs 1.42.5 (29-Jul-2012)
Le système de fichiers de /dev/md0 est monté sur /mnt ; le changement de taille doit être effectué en ligne
old_desc_blocks = 7, new_desc_blocks = 10
En train d'effectuer un changement de taille en ligne de /dev/md0 vers 19650560 (4k) blocs.
Le système de fichiers /dev/md0 a maintenant une taille de 19650560 blocs.

root@omv:~# df -h
Sys. fich.                                             Taille Util. Dispo Uti% Monté sur
rootfs                                                   7,6G  1,1G  6,1G  15% /
udev                                                      10M     0   10M   0% /dev
tmpfs                                                    303M  484K  302M   1% /run
/dev/disk/by-uuid/0caa296b-e542-4302-a240-7faaee84af1a   7,6G  1,1G  6,1G  15% /
tmpfs                                                    5,0M     0  5,0M   0% /run/lock
tmpfs                                                    682M     0  682M   0% /run/shm
tmpfs                                                    1,5G     0  1,5G   0% /tmp
/dev/md0                                                  74G  180M   74G   1% /mnt

Voilà tout cela a été fait avec le plus de précaution possible afin d’avoir une augmentation de l’espace disque gratuite! Et tout cela en ligne sans interruption de service! Je vous conseille toutefois d’éviter d’avoir de la charge sur le serveur durant l’opération et n’oubliez jamais de faire un backup avant toute modification à votre RAID mdadm!

L’article mdadm augmentation du RAID howto est apparu en premier sur Mon linux.

Un grow mdadm est nécessaire qu’à deux moment. Le premier, vous faite un grow pour remplacer les disques durs existant par ceux de plus grande capacité. Le deuxième, lorsque vous ajouter un nouveau disque dur pour passer de 8To à 10To par exemple et que vous disposer d’un slot libre, chanceux

Mais, l’opération sur le RAID à du être arrêtée par une coupure de courant… Si vous n’êtes pas équipé d’un UPS… Faite le! Mais pour cette fois, voici l’opération :

Voici donc l’état du RAID après redémarrage de la machine :

root@omv:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active (auto-read-only) raid5 sdb[0] sdg[5] sdf[4] sde[3] sdd[2] sdc[1]
41908224 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU]

unused devices: <none>

Pour reprendre le RAID à son état d’augmentation (reshape), voici la commande utilisée :

root@omv:~# mdadm --readwrite /dev/md0
root@omv:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdb[0] sdg[5] sdf[4] sde[3] sdd[2] sdc[1]
41908224 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU]
[========>............]  reshape = 40.1% (4207616/10477056) finish=2.2min speed=45568K/sec

Voilà vous êtes sauvé, mais pensez à 3 choses à l’avenir :

• l’utilisation d’un fichier de sauvegarde de l’état du grow mdadm en lisant la suite de l’article
• Équipez vous d’un UPS!
• Mais surtout pensez à sauvegarder vos données essentielles ailleurs! Un RAID n’est en rien une garantie de protection des données! Il permet une tolérance au panne disque, un gain de bande passante, rien de plus.

Source : unix.stackexchange.com

Éviter la perte de données lors d’un grow mdadm

Le reshape lors d’un crash prend du temps et peu ne pas aboutir!

Tout d’abord il faut vérifier l’état de votre RAID mdadm avant de faire un grow! S’il y a un secteur défectueux cela va foirer à tous les coups…

Voici comment vérifier et lancer un check manuel du RAID :

root@omv:~# cat /sys/block/md0/md/sync_action
idle
root@omv:~# echo check > /sys/block/md0/md/sync_action 
root@omv:~# cat /sys/block/md0/md/sync_action
check

Vous pouvez voir l’état d’avancement du check via mdstat :

root@omv:~# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdb[6] sdg[5] sdf[4] sde[3] sdd[2] sdc[1]
      52385280 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU]
      [>....................]  check =  1.0% (108552/10477056) finish=7.9min speed=21710K/sec
      
unused devices: <none>

Une fois que c’est vérifié, pour éviter des problèmes lors d’un grow mdadm, le mieux est d’utiliser l’option de fichier de backup :

mdadm --grow --raid-devices=4 --backup-file=/root/grow_md1.bak /dev/md1

Cette option permet de reprendre un grow raid plus surement en cas d’arrêt de la machine.

Source : raid.wiki.kernel.org

Réduire le temps de synchronisation d’un RAID mdadm

Pour réduire le temps de synchronisation d’un RAID5 ou RAID6 mdadm lors d’un resync ou d’un grow, vous pouvez aller vérifier et modifier certains paramètres :

Vitesse min et max de la synchronisation mdadm

# sysctl dev.raid.speed_limit_min
# sysctl dev.raid.speed_limit_max

C’est une valeur en Kio :

• le minimum peut être 50000 pour 50Mo/s
• Le maximum peut être mise à 500000 pour 500Mo/s si votre raid n’est pas utilisé actuellement

Vous gagnez un peu en performance avec ces options :

Façon old school :

echo 50000 > /proc/sys/dev/raid/speed_limit_min
echo 500000 > /proc/sys/dev/raid/speed_limit_max

En utilisant sysctl :

sysctl -w dev.raid.speed_limit_min=50000
sysctl -w dev.raid.speed_limit_max=500000

Vous n’avez qu’à ajouter ces paramètres via le fichier /etc/sysctl.conf pour fixer au redémarrage de la machine.

Augmenter la taille de bloc

Cet option se fait pour chaque périphérique RAID mdadm, donc pour chaque mdX. Il s’agit du paramètre « readahead » qui est défini en bloc de 512 octets :

Pour un bloc de 32Mio :

blockdev --setra 65536 /dev/md0

Augmenter le cache

Pour moi, c’est option qui donne le meilleur résultat : l’optimisation de la taille du cache des tripes mdadm. L’option n’est donc valable que pour les RAID5 et RAID6.

La formule pour la taille est de la forme suivante :

memory_consumed = system_page_size * nr_disks * stripe_cache_size

Un nombre intéressant est 16Mio, si vous ne voulez pas aller plus loin. Voici pour md0 :

# echo 16384 > /sys/block/md0/md/stripe_cache_size

Vous réduirez déjà par 2 le temps de synchronisation comme dans mon cas :

root@omv:~# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdb[6] sdg[5] sdf[4] sde[3] sdd[2] sdc[1]
      52385280 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/5] [_UUUUU]
      [======>..............]  recovery = 32.7% (3427852/10477056) finish=9.9min speed=11788K/sec
      
unused devices: <none>
root@omv:~# echo 16384 > /sys/block/md0/md/stripe_cache_size
root@omv:~# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdb[6] sdg[5] sdf[4] sde[3] sdd[2] sdc[1]
      52385280 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/5] [_UUUUU]
      [========>............]  recovery = 40.5% (4244444/10477056) finish=4.0min speed=25918K/sec

Source : cyberciti.biz

Avec tout ça, vous êtes sur la bonne voie!

L’article mdadm problème de RAID durant un grow et les optimisations à faire est apparu en premier sur Mon linux.

Utilitaire de gestion des disques

HP ne fournissant que des RPM, il va falloir bricoler et adapter sous Debian…

Il existe des drivers pour faire apparaitre les disques du RAID en périphérique dev, afin de vérifier leur état par exemple :

• outil Debian rapide de gestion : cciss-vol-status
• voir le RPM sur le site d’HP cpq_cciss-4.6.28-6.sles11.i586.rpm

cpq_cciss contient les drivers pour créer des disques du type /dev/cciss/c0d0p1

Interface CLi pour la gestion du RAID

Le nom du rpm est : hpacucli-9.0-24.0.noarch.rpm

Il est disponible sur le site d’HP.

# rpm2cpio hpacucli-9.0-24.0.noarch.rpm | cpio -idmv
# mv opt/compaq /opt/
# mv usr/sbin/hpacu* /opt/compaq/sbin/
# ln -s /opt/compaq/sbin/hpacuscripting /usr/local/bin/ && ln -s /opt/compaq/sbin/hpacucli /usr/local/bin/
# mv usr/man/man8/hpacucli.8.gz /opt/compaq/man/
# mkdir /usr/local/man/man8 && ln -s /opt/compaq/man/hpacucli.8.gz /usr/local/man/man8

Exemple de commande :

# hpcucli
=> controller slot=0 show status
Smart Array P410i in Slot 0 (Embedded)
   Controller Status: OK
   Cache Status: OK
   Battery/Capacitor Status: OK

Ce n’est que quelques notes mais toujours utiles…

L’article RAID HP Smart Array P410i sous Linux Debian est apparu en premier sur Mon linux.

Il y a quelques notes sur le CLi également.

Installation des outils RAID via le dépôt

Ajouter les dépôts nécessaires :

echo "#Pour megaCLI LSI megaraid
deb http://hwraid.le-vert.net/debian wheezy main" >> /etc/apt/sources.list.d/megaraid

Ajouter les paquets suivants :

• megacli – LSI Logic MegaRAID SAS MegaCLI
• megaclisas-status – get RAID status out of LSI MegaRAID SAS HW RAID controllers

Pour activer la vérification automatique des disques :

Créer le fichier /etc/default/megaclisas-statusd

MAILTO=root,alertes-clients@test.tld # Where to report problems
PERIOD=600 # Seconds between each check (10 minutes)
REMIND=14400 # Seconds between each reminder (4 hours)
RUN_DAEMON=yes

Redémarrer le daemon :

/etc/init.d/megaclisas-statusd restart

Commande manuelle pour voir rapidement le statut du RAID :

megaclisas-status

Utilisation du CLi

Voici quelques notes sur l’utilisation du CLi :

Lister les infos de l’adaptateur :

megacli -AdpAllInfo -aALL

Lister les disques de l’adaptateur 0 :

megacli -PDList a0

Vérifier l’état de la batterie :

megacli -AdpBbuCmd -GetBbuCapacityInfo -aALL

Infos des disques :

megacli -LDPDInfo -a0

Initialiser un disque :

megacli –PDClear -Start |-Stop|-ShowProg |-ProgDsply -PhysDrv[248:3] -aALL

Rebuild d’un disque en tant que spare :

megacli -PDRbld -ProgDsply -PhysDrv[248:3] -aALL
        Adapter: 0: Set Physical Drive at EnclId-248 SlotId-3 as Hot Spare Success.

Vérification du rebuild sur un LD :

megacli -LDRecon ShowProg L0 -a0

Vérification rebuild sur un PD :

megacli -PDRbld -ProgDsply -PhysDrv[248:3] -aALL

Pour avoir l’aide complète :

megacli help

Installation manuelle des outils RAID sous Debian Squeeze – obsolète

Version obsolète vu que le dépôt existe, mais au cas où :

Dans mon cas, j’avais un noyau 2.6.32. Il faut donc regarder pour prendre le driver LSI du même noyau. Le module noyau pour Debian Squeeze étant 2.6.32, il faut donc prendre la version Ubuntu 10.10 du module LSI sur leur site après avoir accepté leurs conditions d’utilisations.

Pour installer, rien de plus simple :

unzip megaraid_sas_Ubuntu_10.10_05.30.zip<br>tar -xf megaraid_sas-v00.00.05.30-src.gz
make -C /lib/modules/2.6.32-5-686/build SUBDIRS=/root/megaraid_sas-v00.00.05.30
mkdir /lib/modules/2.6.32-5-686/kernel/drivers/megaraid && cp megaraid_sas.ko /lib/modules/2.6.32-5-686/kernel/drivers/megaraid<br>depmod -a
modprobe megaraid_sas

N’oubliez pas de vérifier les données SMART de vos disques dur et d’en être alerté, smartctl le fait très bien.

L’article RAID hardware LSI sous Debian est apparu en premier sur Mon linux.

Il est préférable d’utiliser des disques de même capacité et de performances égales afin d’optimiser son RAID.

Catégories de RAID

RAID0

• permet d’agréger 2 disques pour avoir le double de volume d’un seul disque.
• On y gagne également en vitesse car les données sont écrites en même temps sur les 2 disques. C’est également vrai pour la lecture des données.
• Attention, vu que les données sont dispersées sur les 2 disques, si l’un d’eux est défectueux, toutes les données sont perdues. C’est donc à proscrire pour éviter la perte de données! Ne l’utilisez que pour des données temporaires ayant besoin d’un accès disque important.

RAID1

• surnommer « miroir », ce RAID permet de dupliquer les données sur 2 disques ou plus.
• Les données sont écrites en même temps donc aucun avantage d’écriture, par contre la lecture de données différentes peut se faire sur les 2 disques en même temps.
• Si un disque rend l’âme, l’intégrité des données reste intacte car le deuxième disque contient toutes les données.

RAID5

• permet d’utiliser la parité et nécessite au moins 3 disques. La parité consiste à créer un résultat à partir de 2 « blocs » de données. Si un des blocs de données est perdu à cause d’un disque défectueux, il peut être recréé à partir des blocs restant sur les autres disques et du résultat de parité.
• Pour 3 disques, on a 3-1=2 fois la capacité d’un disque dans notre RAID. Donc avec 3 disques de 2To, on obtient 4To exploitable.
• Avec 4 disques, on a 4-1=3 fois la capacité, donc 6To dans notre exemple. On a toujours capacité=n-1 avec n=nombre de disques.
• Pour la vitesse de lecture/écriture c’est le même principe. On ne peut perdre qu’un seul disque. Si on en perd deux, toutes les données sont perdues.

RAID5+

• Ce n’est pas un RAID à proprement parlé. On appelle RAID5+ un RAID5 avec un disque de « hot-spare ». C’est un disque qui est en veille et inutilisé qui est  la en secours.
• Lorsqu’un disque de notre RAID5 lâche, le disque hot-spare se met en route et prend la place du défectueux. Une reconstruction à partir des bits de parité se fait et peut prendre un certains temps, mais l’opération est automatique.
• On peut tranquillement retirer le disque défectueux pour en mettre un neuf, qui sera à son tour un hot-spare.

RAID 6

• Même principe que pour le RAID5 mais avec 2 disques de parité. On compte donc en capacité=n-2 avec n étant le nombre de disques. Donc pour 6 disques de 2To, on a 8To exploitable.
• L’avantage est qu’on a une tolérance aux pannes de 2 disques au lieu d’un seul dans le cas du RAID5.

RAID 10

• Son nom l’indique. C’est du RAID1 (miroir) pour sécuriser les données par dessus lequel il y a du RAID0 pour la rapidité en lecture/écriture aux données.
• Sur 4 disques, on peut perdre 1 ou 2 disques, selon lequel est défectueux.

RAID 50

• Même principe que pour le RAID 10. C’est du RAID5 par dessus lequel il y a du RAID0 pour avoir une rapidité d’accès aux données.
• Pour 6 disques, on a 2 disques de tolérances aux pannes.

Il en existe d’autres comme les RAID4, RAID05, RAID15 etc ; mais ils ne sont pas utilisés en production, ou par des incompétents… Je vous redirige vers l’article Wikipédia sur les RAID pour plus d’informations si la théorie vous intéresse.

Type de RAID

Il existe différents types de RAID :

• Le RAID logiciel : mdadm pour Linux par exemple
• Le RAID « semi-matériel » : Souvent Intel avec ses chipsets ICH8, ICH9, ICH10, etc
• Le RAID matériel : différent selon les marques (LSI, Adaptec, HP, etc)

Selon moi, les RAID « semi-matériel » n’apportent rien et sont à proscrire. Ils sont surnommés « fake-raid ». Ce sont des chipsets intégrés à la carte mère ou disponibles sur les cartes RAID low-cost. Ils utilisent la puissance de calcul du processeur, tout comme un RAID logiciel.

Pour simple information, il faut utiliser DMRAID sous Linux (pour Device Mapper RAID), mais je ne l’aborderai pas. Pour le « fake-raid », rendez-vous sur un tutoriel Ubuntu si vous tenez vraiment à l’utiliser…

A venir

Un article sera consacré au RAID logiciel sous Linux avec mdadm. Plusieurs autres articles seront consacrés aux RAID matériels qui sont passés entre mes mains.

Je parlerai prochainement des spécificités de configuration d’un RAID matériel ou logiciel sous Debian. Il faut savoir que le stripe du RAID à prendre en compte, l’alignement des partitions et les blocs du système de fichiers sont tout aussi importants.

L’article Brève description des RAID est apparu en premier sur Mon linux.