[RESOLU] pb inversion entre disque physique et iscsi

[mtiburs]

Bonjour à tous,

J'ai un gros problème d'assignation sur des disques iscsi (Nas4Free en cîble):
(je pense que c'est un bug de Nas4Free).

Voici mes tests.

J'ai 8 disques durs SAS (en plus de mes sata):
Ces disques SAS se trouvent sur mon nas7/10.2.0.2 - Prester (revision 2545):
Je n'affiche ici que les disques SAS:
/dev/mfid0
/dev/mfid1
/dev/mfid2
/dev/mfid3 (physiquement ici se trouve un disque de 146Go)
/dev/mfid4
/dev/mfid5
/dev/mfid6
/dev/mfid7
/dev/mfid8

Tous les disques font 69376MB, sauf le mfid3 qui fait 139392MB (soit 146Go)

Soit, du webgui:
http://192.168.0.207/disks_manage.php
mfid0 n/a 69376MB
mfid1 n/a 69376MB
mfid2 n/a 69376MB
mfid3 n/a 139392MB
mfid4 n/a 69376MB
mfid5 n/a 69376MB
mfid6 n/a 69376MB
mfid7 n/a 69376MB

Pour les extensions iscsi sur Nas4Free, j'ai:
extent0 /dev/mfid0
extent1 /dev/mfid1
extent2 /dev/mfid2
extent3 /dev/mfid3
extent4 /dev/mfid4
extent5 /dev/mfid5
extent6 /dev/mfid6
extent7 /dev/mfid7

Pour les cîbles iscsi sur Nas4Free, j'ai:
iqn.207.istgt:disk0 LUN0=/dev/mfid0
iqn.207.istgt:disk1 LUN0=/dev/mfid1
iqn.207.istgt:disk2 LUN0=/dev/mfid2
iqn.207.istgt:disk3 LUN0=/dev/mfid3
iqn.207.istgt:disk4 LUN0=/dev/mfid4
iqn.207.istgt:disk5 LUN0=/dev/mfid5
iqn.207.istgt:disk6 LUN0=/dev/mfid6
iqn.207.istgt:disk7 LUN0=/dev/mfid7

Si je fais une découverte des disques iscsi sur Lunix/Debian-Jessie:
j'ai:
lrwxrwxrwx 1 root root 10 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk0-lun-0 -> ../../sdan
lrwxrwxrwx 1 root root 11 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk0-lun-0-part1 -> ../../sdan1
lrwxrwxrwx 1 root root 11 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk0-lun-0-part9 -> ../../sdan9
lrwxrwxrwx 1 root root 10 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk1-lun-0 -> ../../sdao
lrwxrwxrwx 1 root root 11 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk1-lun-0-part1 -> ../../sdao1
lrwxrwxrwx 1 root root 11 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk1-lun-0-part9 -> ../../sdao9
lrwxrwxrwx 1 root root 10 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk2-lun-0 -> ../../sdap
lrwxrwxrwx 1 root root 11 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk2-lun-0-part1 -> ../../sdap1
lrwxrwxrwx 1 root root 11 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk2-lun-0-part9 -> ../../sdap9
lrwxrwxrwx 1 root root 10 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk3-lun-0 -> ../../sdaq
lrwxrwxrwx 1 root root 11 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk3-lun-0-part1 -> ../../sdaq1
lrwxrwxrwx 1 root root 11 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk3-lun-0-part9 -> ../../sdaq9
lrwxrwxrwx 1 root root 10 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk4-lun-0 -> ../../sdar
lrwxrwxrwx 1 root root 11 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk4-lun-0-part1 -> ../../sdar1
lrwxrwxrwx 1 root root 11 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk4-lun-0-part9 -> ../../sdar9
lrwxrwxrwx 1 root root 10 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk5-lun-0 -> ../../sdas
lrwxrwxrwx 1 root root 11 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk5-lun-0-part1 -> ../../sdas1
lrwxrwxrwx 1 root root 11 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk5-lun-0-part9 -> ../../sdas9
lrwxrwxrwx 1 root root 10 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk6-lun-0 -> ../../sdat
lrwxrwxrwx 1 root root 11 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk6-lun-0-part1 -> ../../sdat1
lrwxrwxrwx 1 root root 11 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk6-lun-0-part9 -> ../../sdat9
lrwxrwxrwx 1 root root 10 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk7-lun-0 -> ../../sdau
lrwxrwxrwx 1 root root 11 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk7-lun-0-part1 -> ../../sdau1
lrwxrwxrwx 1 root root 11 juil. 23 18:34 ip-192.168.0.207:3260-iscsi-iqn.207.istgt:disk7-lun-0-part9 -> ../../sdau9

Donc, pour les disque 3, j'ai /dev/sdaq (normalement un disque de 146Go)
mais ... en fait, si je fais un fdisk -l j'ai:
root@bx:~# fdisk -l /dev/sdaq
Disque /dev/sdaq : 67,8 GiB, ...

et si je regarde /dev/sdar (normalement disk4=73GB)
j'ai:
root@bx:~# fdisk -l /dev/sdar
Disque /dev/sdar : 136,1 GiB, ...

Je suis repartis plusieurs fois de zéro, ordi éteint, et, j'ai bien redémarré mes services (çà fait 4 fois que je reconfigure le tout), j'ai même mis des nom en plus des numéros, rien n'y fait, j'ai toujours cette inversion sur le disque 3 et 4, mais aussi sur d'autres disques !

Si je prends un autre Nas4Free avec la même configuration, c'est à dire, un disque de 146Go aussi physiquement au niveau du disk3, le système verra celui-ci en disk4 !

Si je prends un autre Nas4Free (en initiateur), le nas6 au lieu de Linux, j'ai:

http://192.168.0.206/disks_manage_iscsi.php
disk3i207 iqn.207.istgt:disk3 192.168.0.207

http://192.168.0.206/disks_manage.php
da1 FreeBSD iSCSI DISK 0001 69376MB NFSN00W3TUWQNA iscsi1

et pour le disk4:
disk4i207 iqn.207.istgt:disk4
da2 FreeBSD iSCSI DISK 0001 139392MB NFSN00S73T8CQV iscsi2

Voilà dans tous les cas, aucun système (Linux ou un autre Nas4Free) ne veux voir ce disque de 146Go en disk3 !!!, de plus d'autres disques aussi sont mélangés, mais c'est plus facile de distinguer le 146Go parmis les autres, c'est pourquoi je m'attarde sur ce dernier.

Pour finir, si j'utilise les pools directement sur Nas4Free (en désactivant l'iscsi), ils sont cohérent avec les disques (le disque 3 physique est bel est bien un 146Go)

Je vais devenir fou, si vous n'avez plus de nouvelles de moi, c'est que je suis dans un asile

[mtiburs]

petit ajout:

chose étrange mais qui a son importance, ce pb ne se pose pas sur le nas6 (le nas6 et le nas7 sont construit de la même façon au niveau "physique", même carte SAS, même câbles et même disques)

root@bx:~# ls -l /dev/disk/by-path/ | grep 206
lrwxrwxrwx 1 root root 9 juil. 23 22:41 ip-192.168.1.206:3260-iscsi-iqn.206.istgt:disk3-lun-0 -> ../../sdn

root@bx:~# fdisk -l /dev/sdn
Disque /dev/sdn : 136,1 GiB,

[mtiburs]

Je pense avoir trouvé !

1) J'ai sauvegardé ma config
2) installé la dernière version 10.3.0.3 - Pilingitam (revision 2898)
3) fait une RAZ de la config (pour tester avec "que du neuf")
4) fait un import des disques, et là ... les disque de 146Go se retrouve désormais en disk4 (/dev/mfid4)
pour aller plus loin
4) j'ai remis ma config
le disque de 146Go est revenu en disk3 (comme il l'a toujours été)
5) fait un rebalayage des disques ... rien (me demande à quoi çà sert, çà voit jamais rien)
6) fait un éffacement et une importation des disques
et là le disque de 146Go est en disk4
mfid3 n/a 69376MB
mfid4 n/a 139392MB

A rien n'y comprendre, cela fait des mois que çà tournait avec le disque en disk3

M'enfin bon, çà remarche, c'est l'essentiel

[mtiburs]

Après avoir fait beaucoup d'essais, j'ai compris enfin mes déboires

En fait, il peut facilement se produire un décalage de numérotation dans l'affectation des disques (entre le physique et le logique), et ceci non seulement sur la carte SAS mais aussi dans Nas4Free !

Je reprends mon cas (la carte SAS est une Perc6-i (256Mo de cache).
Cette carte est utilisé avec 8 disques SAS qui correspondent pour moi à 8 sauvegardes de MV.
La deduplication est activée, mais pas la compression (ceci dans un but précis).

Il y a 7 disques de 73Go et 1 de 146Go.
Un disque de 73 contient presque un mois de stockage d'une MV (ratio de déduplication allant de 5 à 10).

Voici le problème:

Lors de la configuration des disques il est nécessaire de créer des DG (Groupe de Disk), car la carte à la base est faite pour des raids matériels.
Donc pour faire 8 disques distincts, il faut faire 8 DG crée en raid0 (un raid0 d'un seul disque).
Chaque disque se voit donc attribué d'un DG: c'est à dire qu'on obtient:
disk0 = DG0 (le disque dur 0 est affecté au DG0)
disk1 = DG1
disk2 = DG2
... etc
Quand tout est fait dans le bon sens çà va.

Petite parenthèse, imaginons le cas d'un raid1 de 2 disques (sur le disque 1 et 2)
disk0 = DG0
disk1/2 = DG1
disk3 = DG2
là, les choses se gâtent, car les numéros ne se suivent plus.

Mais dans mon cas, pas de raid matériel, tout se suit, donc
disk0 = DG0
disk1 = DG1
...
disk7 = DG7
ouf !

Mais, çà c'est vrai quand tout va bien.

Maintenant, je veux supprimer le DG1 ... que va t-il se passer ?
la réaffectation des DG est immédiate, les DG sont "ré-organisé"
disk0 = DG0
disk1 = libre
disk2 = DG1
disk3 = DG2
disk4 = DG3
disk5 = DG4
disk6 = DG5
disk7 = DG6

Maintenant, je désire refaire un DG sur le disk1, j'aurai cette fois:
disk0 = DG0
disk1 = DG7
disk2 = DG1
disk3 = DG2
disk4 = DG3
disk5 = DG4
disk6 = DG5
disk7 = DG6

Et ceci se ré-organisera pour chaque changement de config

On recommence (on revient dans le cas normal)
disk0 = DG0
à
disk7 = DG7

Je débranche cette fois le disque 2
disk0 = DG0
disk1 = DG1
disk2 =
disk3 = DG3
disk4 = DG4
disk5 = DG5
disk6 = DG6
disk7 = DG7
et je rédémarre
Le bios de la carte mère, va me dire qu'il y a un soucis sur un disque.

J'arrête le PC, je rebranche le disque à froid et je rédémarre.
Le bios m'informe que je peux importer le disque manquant, ce qui donnera
disk0 = DG0
disk1 = DG1
disk2 = DG7
disk3 = DG2
disk4 = DG3
disk5 = DG4
disk6 = DG5
disk7 = DG6
Cette ré-organisation s'éffectue aussi lors de l'import de disque

Mais çà c'est rien, il y a pire
reprenons cette fois en visualisant les dev de Nas4Free (je crée juste 2 disques)
disk0 = DG0 (/dev/mfid0)
disk1 = DG1 (/dev/mfid1)
(sur le webgui on ne voit que les /dev/...)

Je débranche le disque 0 et visualise les dev dans le webgui:
disk0 = DG0 (/dev/mfid0 sera barré en rouge)
disk1 = DG1 (/dev/mfid1)

Je rebranche mon disque et l'importe par le bios de la carte SAS:
disk0 = DG1
Je fais cette fois une éffacement et un ré-import des disques (webgui):
disk0 = DG1 (/dev/mfid1)
disk1 = DG0 (/dev/mfid0)
les deux disques sont inversés !!!
car le webgui se base sur le DG, en fait, Nas4free, ne voit pas le disque physique, il voit çà:
DG0 (/dev/mfid0)
DG1 (/dev/mfid1)
donc pour lui ... çà roule

Ceci ne pose aucun soucis avec les FS (surtout les modernes), car Nas4Free (en fait FreeBSD) se basera sur l'uuid)
Mais dans le cas précis de l'iscsi (il n'y a pas de notion de FS monté), le système se base uniquement sur /dev/...
donc, dans le dernier exemple, Nas4Free présentera /dev/mfid0 en cible iscsi mais avec le disque physique1

Voilà, j'ai passé presque tout mon we pour trouver le soucis, sympa !

Mon verdict:
Lorsque Nas4Free voit un soucis de disques, il faut:
- aller sur le bios de la carte SAS et remettre en état
- remettre la config disk0 = DG0 (chaque numéro de disque physique doit être le même que le DG)
- puis refaire un effacement de la config et un ré-import des disques sous Nas4Free

A noter que ce type de problème (iscsi) se posera aussi pour les dev amovible (usb), en fait tous les dev "changeant".

Sous Linux, le pb se poserait également avec un dev genre /dev/sdb, mais pour éviter ce genre de déboire, on peut utiliser /dev/disk/by-id (ou /dev/disk/by-uuid) justement pour avoir un dev "non-changeant".

[octave]

salut salut

j'avais eu un soucis presque similaire avec un ubuntu server.
ma solution fut de débrancher tous les disques et de les rebrancher un a pres l'autre avant le boot os
pour que le carte raid puisse retrouver ces petits.
c'est du bricolage mais j'ai pas eu trop le choix.
en passant, super exposé de problématique et de résolution.

[mtiburs]

Salut Octave,

j'avais eu un soucis presque similaire avec un ubuntu server.
ma solution fut de débrancher tous les disques et de les rebrancher un a pres l'autre avant le boot os
pour que le carte raid puisse retrouver ces petits.

t'avais accès au bios de la carte raid ?
Sinon, çà s'explique comme manoeuvre (et éffectivement, il faut y aller un par un)

en passant, super exposé de problématique et de résolution.

Merci pour le compliment, çà veut dire que çà se lit alors ?
J'ai hésité a mettre des copies d'écran, mais c'est long, et, au lieu de ne rien faire, je l'ai joué en "texte tout simple"