Passer en RAID 1

Passer en RAID 1 jpp sam 26/12/2015 - 17:57

Note : le système est un Debian "Jessie" mais la plupart des remarques peuvent s'appliquer à d'autres distributions.
Sur la machine qui me sert de frontal Internet j'ai eu de multiples alertes "Smart" me signalant des dégradations sur des "seek..." et quelques autres anomalies. Ces disques sont assez anciens et très sollicités car la machine fonctionne 24/24 et héberge plusieurs services : mail, DNS, DHCP, serveur Apache, agent centralisateur de collectd, une base Mysql ainsi que Suricata et Snorby. Les deux disques de cette machine (500Go) deviennent par ailleurs un peu petits. Ils sont montés en LVM, chaque volume LVM est mirroré, mais c'est un peu lourd à gérer. Le système est sur un petit SSD que je sauvegarde régulièrement.
J'ai donc décidé de changer les disques et de mettre deux disques en RAID1 sur lesquels je mettrais trois partitions, dont deux avec LVM, plus un swap. Il ne faut pas oublier de charger le paquet "mdadm" pour disposer des outils adéquats.
Comme le contrôleur supporte 4 disques j'ai pu monter un des futurs disques en plus afin de :
- Le partitionner :

une partition pour le système,
une pour les disques des machines virtuelles,
une pour le stockage des données
une de swap.

Ensuite :

Créer le Raid1 avec une seule patte.
Créer les PV pour LVM sur les partitions 2 et 3
Charger les données, du système et copier les images de machines virtuelles.

Pour ceci il est nécessaire de stopper le maximum de services afin de ne pas se compliquer la tâche.
Ne pas oublier de mettre les partitions en type "Linux RAID" dans fdisk (type "fd") :
Command (m for help): t
Partition number (1-4, default 4): 1
Partition type (type L to list all types): 21
Changed type of partition 'Linux RAID' to 'Linux RAID'.
... idem pour les autres partitions.
On arrive alors à ceci dans fdisk :

Disk /dev/sdc: 931,5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 48D952DA-AF21-46D3-BB36-73DFFF32A96A
Device Start End Sectors Size Type
/dev/sdd1 2048 536872959 536870912 256G Linux RAID
/dev/sdd2 536872960 1073743871 536870912 256G Linux RAID
/dev/sdd3 1073743872 1912604671 838860800 400G Linux RAID
/dev/sdd4 1912604672 1953525134 40920463 19,5G Linux RAID

Ensuite il faut créer nos "RAID" en mettant à chacun un disque physique et un disque "missing" :
mdadm --create /dev/md2 --level=1 --raid-disks=2 missing /dev/sdd1
....
Puis enregistrer la config de nos RAID pour qu'ils soient reconnus au boot avec :
mdadm --examine --scan >>/etc/mdadm/mdadm.conf
Vous pouvez ensuite modifier dans ce fichier l'adresse mail de destination des messages.
Il est prudent de redémarrer la machine pour vérifier que nos RAID sont bien accrochés et se retrouvent après redémarrage.

On arrive alors a "voir" l'état de nos RAID en exécutant :
cat /proc/mdstat
Personalities : [raid1]
md3 : active raid1 sdc2[1]
268304384 blocks super 1.2 [2/1] [_U]
bitmap: 1/2 pages [4KB], 65536KB chunk

md4 : active raid1 sdc3[1]
419299328 blocks super 1.2 [2/1] [_U]
bitmap: 1/4 pages [4KB], 65536KB chunk

md5 : active raid1 sdc4[1]
20443840 blocks super 1.2 [2/1] [_U]

md2 : active raid1 sdc1[1]
268304384 blocks super 1.2 [2/1] [_U]
bitmap: 2/2 pages [8KB], 65536KB chunk

unused devices: <none>
-------------------------------------------------------
Le système signale par ailleurs dans les logs lors du démarrage que les RAID ne sont pas en bon état :
Nov 25 13:24:49 xxxxxx systemd-fsck[408]: /dev/md2 : propre, 17129/16769024 fichiers, 10491322/67076096 blocs
Nov 25 13:24:49 xxxxxx systemd-fsck[516]: BOOT : propre, 326/1222992 fichiers, 139566/4882432 blocs
Nov 25 13:24:49 xxxxxx mdadm-raid[196]: Assembling MD array md2...done (degraded [1/2]).

et mdadm-raid vous envoie régulièrement des mails tels que :
This is an automatically generated mail message from mdadm
running on xxxxxx.xxx.xxx

A DegradedArray event had been detected on md device /dev/md/4.

Faithfully yours, etc.

P.S. The /proc/mdstat file currently contains the following:

Personalities : [raid1]
md4 : active raid1 sdc3[1]
419299328 blocks super 1.2 [2/1] [_U]
bitmap: 1/4 pages [4KB], 65536KB chunk

md5 : active raid1 sdc4[1]
20443840 blocks super 1.2 [2/1] [_U]
.......
-------------------------------------------------------
On peut alors :
Formater la première partition en ext4
Recopier les répertoires système du vieux disque, /var, quelques morceaux de /usr ... sur la première partition, "cp -dpRx" est votre ami.
Créer le PV LVM sur la deuxième partition puis créer les volumes logiques destinés à mes machines virtuelles (je ne le fais pas à la main mais avec "kvpm" que j'aime bien).
Stopper les machines virtuelles et copier leurs images disque, bêtement avec :
"dd if=ancien of=nouveau bs=65536" et cela marche très bien.
J'ai ensuite modifié le fichier /etc/fstab" pour monter les "nouvelles" partitions à la place des "anciennes", les anciennes sont toujours là (au cas ou ?).
Modifié les scripts de lancement des MV pour utiliser les nouveaux volumes et redémarré.
Super, tout se passe bien, le système est OK, les MV ont bien démarré et leurs services sont accessibles. Je vais pouvoir démonter les anciens disques.
Je stoppe encore la machine, démonte les anciens disques et je les stocke dans un coin tranquille (encore au cas ou) et monte le nouveau disque encore vierge.
Il fait alors recommencer le partitionnement de ce nouveau disque, sans oublier de mettre le type de partition à "Linux RAID".
Faire gaffe au nom des disques, car le démontage des anciens disques décale tout. On arrive presque à la fin on va, enfin, créer un vrai RAID1 avec deux disques :
mdadm --manage /dev/md2 --add /dev/sdb1

cat /proc/mdstat
Personalities : [raid1]
md3 : active raid1 sdc2[1]
268304384 blocks super 1.2 [2/1] [_U]
bitmap: 1/2 pages [4KB], 65536KB chunk

md4 : active raid1 sdc3[1]
419299328 blocks super 1.2 [2/1] [_U]
bitmap: 1/4 pages [4KB], 65536KB chunk

md5 : active raid1 sdc4[1]
20443840 blocks super 1.2 [2/1] [_U]

md2 : active raid1 sdb1[2] sdc1[1]
268304384 blocks super 1.2 [2/1] [_U]
[>....................] recovery = 0.2% (781056/268304384) finish=28.5min speed=156211K/sec
bitmap: 2/2 pages [8KB], 65536KB chunk

La synchronisation de la première partie du RAID /dev/md2 est commencée et prévue pour un peu moins de 30 minutes, ne pas être pressé et éviter le café car il y a d'autres RAID à compléter.
La vitesse de construction varie un peu mais reste supérieure à 100000K/sec mais la première partition fait 256G, la plus grosse 400G ce qui va durer une éternité.
La première partition contient beaucoup de fichiers "actifs", par exemple tous les logs, la base de données mysql .... cela devrait augmenter le temps de construction. Mais, un peu plus tard : :
md2 : active raid1 sdb1[2] sdc1[1]
268304384 blocks super 1.2 [2/1] [_U]
[================>....] recovery = 84.4% (226534144/268304384) finish=6.7min speed=103609K/sec
bitmap: 2/2 pages [8KB], 65536KB chunk
Ca s'approche de la fin .... toujours à un peu plus de 100MO/seconde. Au passage "iotop" ne voit rien et affiche des chiffres "ridicules".
Nov 25 19:16:52 xxxxxx kernel: [ 939.531841] md: recovery of RAID array md2
Nov 25 19:59:28 xxxxxx kernel: [ 3493.885198] md: md2: recovery done.
43 minutes environ au lieu des #30 annoncées.

Pour la partition suivante il y a deux disques de machines virtuelles, je ne vais pas les stopper avant de commencer la construction du RAID pour environ 30 minutes annoncées.
Nov 25 20:34:04 xxxxxx kernel: [ 5569.372170] md: recovery of RAID array md3
Nov 25 21:24:56 xxxxxx kernel: [ 8618.957262] md: md3: recovery done.
Soit environ 50 minutes.
J'aurais mieux fait de stopper les MV car l'une d'elle a eu un problème lors du redémarrage (fsck manuel obligatoire).

Passons à la partition de 400G.
mdadm --manage /dev/md4 --add /dev/sdb3
mdadm: added /dev/sdb3
date
mercredi 25 novembre 2015, 21:28:55 (UTC+0100)
Et quelques instants plus tard :
cat /proc/mdstat
Personalities : [raid1]
md4 : active raid1 sdb3[2] sdc3[1]
419299328 blocks super 1.2 [2/1] [_U]
[=>...................] recovery = 6.5% (27293696/419299328) finish=95.4min speed=68420K/sec
bitmap: 0/4 pages [0KB], 65536KB chunk
La vitesse n'est "que" de 68Mo/seconde ? On doit approcher le milieu du disque ???
Beaucoup plus tard ... :
cat /proc/mdstat
Personalities : [raid1]
md4 : active raid1 sdb3[2] sdc3[1]
419299328 blocks super 1.2 [2/1] [_U]
[=======>.............] recovery = 36.8% (154667968/419299328) finish=70.2min speed=62746K/sec
bitmap: 0/4 pages [0KB], 65536KB chunk
date
mercredi 25 novembre 2015, 22:05:02 (UTC+0100)
En 37 minutes le temps restant n'a que diminué de 25 minutes .... que dire du résidu de 70 minutes ? Ensuite en 20 minutes le temps restant a diminué de 15 minutes.
A 22:40 ( durée 72 minutes) il reste encore 36 minutes ....
cat /proc/mdstat ; date
Personalities : [raid1]
md4 : active raid1 sdb3[2] sdc3[1]
419299328 blocks super 1.2 [2/1] [_U]
[=================>...] recovery = 89.9% (377065408/419299328) finish=13.5min speed=52082K/sec
bitmap: 0/4 pages [0KB], 65536KB chunk
mercredi 25 novembre 2015, 23:09:29 (UTC+0100)
Les 100 minutes sont atteintes il n'en reste plus que 13,5 mais la vitesse est tombée à 52MO/seconde. Pour finir :
Nov 25 21:28:53 xxxxxx kernel: [ 8856.327974] md: recovery of RAID array md4
Nov 25 23:24:41 xxxxxx kernel: [15800.532184] md: md4: recovery done.
1h56 minutes soit 116 minutes, heureusement que je n'ai pas utilisé des disques de 3To !

La dernière partition (futur SWAP) ne fait que 19G, cela devrait aller vite :
md5 : active raid1 sdb4[2] sdc4[1]
20443840 blocks super 1.2 [2/1] [_U]
[>....................] recovery = 1.5% (311040/20443840) finish=9.7min speed=34560K/sec
Par contre même pas 35MO/seconde ! Cette partie du disque est vraiment moins performante, mais après quelques minutes on monte à environ 45Mo/seconde ce qui est déjà un peu mieux.
Enfin, c'est fini !
La machine est sauvée et n'aura peut-être pas d'incident disques avant quelques années ... je croise les doigts.