Discussion :

[tck-lt]

Bonjour,

je dispose aujourd'hui d'un LV présent sur un PV dont la localisation physique est sur le SAN. Il s'appelle /dev/vgtest/lvtest. J'ai en local la place disponible pour créer un LV mirroir de lvtest. Mes question sont les suivantes :
- Dois-je d'abord créer mon LV /dev/VolGroup00/lv_test_mirroir qui sera la copie mirroir ?
- Comment ensuite agréger mes 2 LVs dans un miroir ?

J'ai bien vu la commande lvconvert et son man mais je n'arrive pas à comprendre comment l'adapter dans ma situation (/dev/VolGroup00 contient d'autres LVs qui ne sont pas à mirorrer).

Merci d'avance pour vos réponses.

NB : je suis sur RHEL

[frp31]

Bonjour,

je dispose aujourd'hui d'un LV présent sur un PV dont la localisation physique est sur le SAN. Il s'appelle /dev/vgtest/lvtest. J'ai en local la place disponible pour créer un LV mirroir de lvtest. Mes question sont les suivantes :
- Dois-je d'abord créer mon LV /dev/VolGroup00/lv_test_mirroir qui sera la copie mirroir ?
- Comment ensuite agréger mes 2 LVs dans un miroir ?

J'ai bien vu la commande lvconvert et son man mais je n'arrive pas à comprendre comment l'adapter dans ma situation (/dev/VolGroup00 contient d'autres LVs qui ne sont pas à mirorrer).

Merci d'avance pour vos réponses.

NB : je suis sur RHEL

MMM ah moins que je me trompe, je dis ça de mémoire, il suffit de modifier le LVexistant en lui disant mirroir On et la chemin vers le LV qui sera son mirroir ...


genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
lvconfig -m1 vg_fs00/lv00 /dev/d-28 /dev/d-29
 
lvconfig -m1 vg_fs00/NOM_DU_LV_MOUNTABLE /dev/NOM_DISK1 /dev/NOM_DISK2

ou lvsetup ou lvconvert ... j'ai oublié le nom de la commande...

[Katyucha]

Absolument pas conseillé de faire un mirroir SAN-Local

[tck-lt]

Pourriez-vous être un plus prolixe svp ?

Nous voudrions avoir une sécurisation de nos archives logs Oracle en cas de crash de la connexion avec le SAN.

[Katyucha]

Le SAN n'est pas fait pour crashé à la base

Normalement, vous avez deux cartes fibres sur 2 fabriks différents donc vous voyez non pas une(ou un, ca dépend des gens) LUN mais plusieurs, suivant le nombre de chemins. Donc aucun risque de crash sauf si vous décidez de redémarrer vos fabriks en même temps.

La personne qui redémarre toutes ses fabriks en même temps avec les serveurs UP doit changer de métier

Pour voir si vous voyez vos disques en multi chemin

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
multipath -ll

Vous devez voir un truc dans le genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
mpathX (xxxxxxxxxxxxxxx) dm-XXType-Baie
[size=XXXG][features=0][hwhandler=0][rw]
\_ round-robin 0 [prio=200][active]
 \_ 5:0:0:0 sdc        8:32  [active][ready]
\_ round-robin 0 [prio=40][enabled]
 \_ 5:0:0:0 sda        8:0   [active][ready]

La, ca veut dire deux chemins, sur deux cartes différentes : c'est le minimum, on se pose pas de question. Ca fonctionne.

Pour le mirroir InterneDD/SAN, ce n'est absolument pas conseillé par les constructeurs. Que ca soit IBM ou EMC² (je ne connais pas Hitachi mais je pense que ca sera pareil), on vous répondra "pas conseillé" (sauf si ça a changé en quelques mois). Ca fonctionne pour sûr, mais il y a des risques.

Sinon la commande est bien

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

lvconvert -m1 LogVolume DevicePath

pour rajouter du code

[tck-lt]

Merci pour ces précisions et comme d'habitude les réponses appellent à d'autres questions.

Nous avons eu en fait 2 coupures :
La première s'est déroulée lorsque que le serveur a été ajouté à la seconde Fabric. Nous ne savons pas pourquoi cela a perturbé le fonctionnement de notre serveur, comme s'il perdait ses 2 premiers chemins et nous a obligé à un reboot pour découvrir les 2 nouveaux chemins (2 cartes*1 Fabric) pour chaque LUN (je dis aussi une). Aujourd'hui nous avons donc "peur" qu'à chaque modification sur une Fabric (dans le cas d'une maintenance telle qu'un upgrade de firmware de switch Brocade) cela bloque notre prod alors que ça ne devrait pas puisque 2 chemins subsistent.

La deuxième coupure est dûe je pense à une erreur humaine. En effet, la procédure de suppression d'une LUN n'a pas été respectée. La LUN a été enlevée du Storage Group du serveur avant d'avoir été supprimée de ce dernier. Avec LVM ça ne pardonne pas, au moindre scan dans ce cas, la machine démonte violemment ce qui entraine des corruptions de filesystems.

Dernier point, le fichier multipath.conf. J'ai beau regarder de la doc sur le net, je ne comprends pas tout ce que je dois faire y figurer pour une optimisation optimale. Toujours est-il que j'ai compris qu'en ajoutant (en forçant en fait) les entrées multipath de cette manière :

multipaths {
multipath {
wwid 3600508e0000000008d4bef7089c42f09
alias mpath0
}

multipath {
wwid 36006016052102e00ee89bffaf710e111
alias mpath1
}

multipath {
wwid 36006016052102e00b428da082c5ee111
alias mpath2
}

multipath {
wwid 36006016052102e00b281d0622f5ee111
alias mpath3
}

multipath {
wwid 36006016052102e00461255d3d35ee111
alias mpath4
}

multipath {
wwid 36006016052102e009c15951c385ee111
alias mpath5
}

multipath {
wwid 36006016052102e0016112caffe61e111
alias mpath6
}

multipath {
wwid 36006016052102e00d2d4d1246c72e111
alias mpath7
}

multipath {
wwid 36006016052102e00e28c7ad12177e111
alias mpath8
}
}

nous avons remarqué que la machine était beaucoup plus stable. Nous allons donc le généraliser sur d'autres machines. La variable user_friendly_names permet-elle de remonter le nom de la LUN en lieu et place du WWID ?

Il me vient encore une dernière question. Si nous étions amenés à faire du mirroir, uniquement via nos 2 SAN, pour toutes nos LUN (voire carrément du clustering par cluster de 2 noeuds), penses-tu qu'il est préférable de faire du mirroring via LVM ou le faire via le SAN (nous sommes avec de l'EMC VNX5300).

Merci de m'avoir lu.

[Katyucha]

Pour reprendre un peu ton historique :
La première coupure, aucune idée : les symptomes ne sont pas très éloquents hélas...
La deuxième coupure : ouep, ca sent l'erreur humaine ! Avant de sortir tout disque d'un serveur, il faut le libérer complétement -> Le sortir du LVM, il doit être le plus vierge possible

Pour le multipath, donne moi plutot le résulat de "multipath -ll", ca donne une meilleure idée

Enfin pour le RAID, il faut mieux du Raid directement sur la baie. Surtout quand on a du beau matos comme EMC², la baie est faite pour cela.
D'ailleurs, je sors de formation Redhat et le formateur était formel : le Raid logiciel faut éviter un maximum

[tck-lt]

voici le résultat de multipath -ll :

# multipath -ll
mpath2 (36006016052102e00b428da082c5ee111)
[size=20 GB][features="1 queue_if_no_path"][hwhandler="1 emc"]
\_ round-robin 0 [prio=2][active]
\_ 1:0:0:2 sdd 8:48 [active][ready]
\_ 2:0:0:2 sdr 65:16 [active][ready]
\_ round-robin 0 [enabled]
\_ 1:0:1:2 sdj 8:144 [active][ready]
\_ 2:0:1:2 sdw 65:96 [active][ready]

mpath1 (36006016052102e00ee89bffaf710e111)
[size=8 GB][features="1 queue_if_no_path"][hwhandler="1 emc"]
\_ round-robin 0 [prio=2][active]
\_ 1:0:0:1 sdc 8:32 [active][ready]
\_ 2:0:0:1 sdq 65:0 [active][ready]
\_ round-robin 0 [enabled]
\_ 1:0:1:1 sdi 8:128 [active][ready]
\_ 2:0:1:1 sdv 65:80 [active][ready]

mpath8 (36006016052102e00e28c7ad12177e111)
[size=25 GB][features="1 queue_if_no_path"][hwhandler="1 emc"]
\_ round-robin 0 [prio=2][active]
\_ 1:0:0:7 sdae 65:224 [active][ready]
\_ 2:0:0:7 sdag 66:0 [active][ready]
\_ round-robin 0 [enabled]
\_ 1:0:1:7 sdaf 65:240 [active][ready]
\_ 2:0:1:7 sdah 66:16 [active][ready]

mpath7 (36006016052102e00d2d4d1246c72e111)
[size=10 GB][features="1 queue_if_no_path"][hwhandler="1 emc"]
\_ round-robin 0 [prio=2][active]
\_ 1:0:0:6 sdaa 65:160 [active][ready]
\_ 2:0:0:6 sdac 65:192 [active][ready]
\_ round-robin 0 [enabled]
\_ 1:0:1:6 sdab 65:176 [active][ready]
\_ 2:0:1:6 sdad 65:208 [active][ready]

mpath6 (36006016052102e0016112caffe61e111)
[size=200 GB][features="1 queue_if_no_path"][hwhandler="1 emc"]
\_ round-robin 0 [prio=2][active]
\_ 1:0:0:5 sdg 8:96 [active][ready]
\_ 2:0:0:5 sdu 65:64 [active][ready]
\_ round-robin 0 [enabled]
\_ 1:0:1:5 sdm 8:192 [active][ready]
\_ 2:0:1:5 sdz 65:144 [active][ready]

mpath5 (36006016052102e009c15951c385ee111)
[size=2 GB][features="1 queue_if_no_path"][hwhandler="1 emc"]
\_ round-robin 0 [prio=2][active]
\_ 1:0:0:0 sdb 8:16 [active][ready]
\_ 2:0:0:0 sdo 8:224 [active][ready]
\_ round-robin 0 [enabled]
\_ 1:0:1:0 sdh 8:112 [active][ready]
\_ 2:0:1:0 sdp 8:240 [active][ready]

mpath4 (36006016052102e00461255d3d35ee111)
[size=2 GB][features="1 queue_if_no_path"][hwhandler="1 emc"]
\_ round-robin 0 [prio=2][active]
\_ 1:0:1:4 sdl 8:176 [active][ready]
\_ 2:0:1:4 sdy 65:128 [active][ready]
\_ round-robin 0 [enabled]
\_ 1:0:0:4 sdf 8:80 [active][ready]
\_ 2:0:0:4 sdt 65:48 [active][ready]

mpath3 (36006016052102e00b281d0622f5ee111)
[size=30 GB][features="1 queue_if_no_path"][hwhandler="1 emc"]
\_ round-robin 0 [prio=2][active]
\_ 1:0:0:3 sde 8:64 [active][ready]
\_ 2:0:0:3 sds 65:32 [active][ready]
\_ round-robin 0 [enabled]
\_ 1:0:1:3 sdk 8:160 [active][ready]
\_ 2:0:1:3 sdx 65:112 [active][ready]

On faisait du mirroring matériel avec l'ancien SAN (CX500) (une LUN primaire active et une secondaire passive mais synchro), mais nous étions en majorité sur AIX et il savait bien géré la bascule en cas de crash disque (avec ARF si tu connais par exemple). Pour les serveurs Linux, ça me parait bien plus compliqué c'est pour cela que nous n'avons pas encore pris de décision définitive mais on voudrait arriver à une solution de clustering efficace.

[Katyucha]

Ton "multipath -ll" me plait !
Tu as 4 chemins, via 2 cartes. C'est amplement suffisant pour de la redondance. Evidemment, il ne faut pas avoir des imbéciles à l'administration, mais malheureusement, y a aucune solution contre eux (celui qui trouve, y a moyen de déposer un bon brevet).
Il faut juste mettre à jour ces fabriks de manière complétement asynchrone. Lors d'un reboot d'un switch SAN, il faut vérifier que les liens sont bien ups partout avant de lancer le reboot du second..!

On faisait du mirroring matériel avec l'ancien SAN (CX500) (une LUN primaire active et une secondaire passive mais synchro), mais nous étions en majorité sur AIX et il savait bien géré la bascule en cas de crash disque (avec ARF si tu connais par exemple). Pour les serveurs Linux, ça me parait bien plus compliqué c'est pour cela que nous n'avons pas encore pris de décision définitive mais on voudrait arriver à une solution de clustering efficace.

Attention, la tu parles de clustering (services hautes disponibilités sur plusieurs serveurs), moi je te parle de redondance (sur un serveur).

Dans le cadre de redondance, ton serveur est vraiment bien là. D'ailleurs, si tu as un serveur de test, n'hésite pas faire des tests ! Tu met une LUN sur un serveur test via tes 4 chemins et tu décables derrière... tu vois les chemins disparaitre, réapparaitre... etc Je conseille toujours avant de livrer un serveur, de faire ce genre de test. "Arrracher" une fibre au cul du serveur : que se passe t il?

Pour du cluster, ca dépend vraiment de la mise en place... il y a plusieurs modèles différents, suivant ton architecture, la localisation des serveurs, le besoin...etc. La, ca devient vachement plus complexe.

[tck-lt]

Merci pour cet échange constructif et bonne continuation.

(Résolu !)