Le titre fait rêver, non? Bon, avant de perdre définitivement tous les lecteurs, je vais présenter rapidement le contexte. Les baies SAN de la gamme Clariion d'EMC² permettent de retailler dynamiquement des volumes (appelés LUNs), c'est-à-dire qu'on peut augmenter à chaud la taille d'un disque présenté à une machine. Cette fonctionnalité, fort utile au demeurant, n'en pose pas moins un problème fondamental au niveau du serveur concerné : comment lui faire comprendre que le disque sous-jacent à changé de taille. Ce billet va s'intéresser au sujet, et en particulier présenter les multiples problèmes que j'ai pu rencontrer avec un serveur Solaris 10 équipé de Veritas Volume Manager ...

La théorie

En théorie, c'est censé être tout simple. On procède à une extension au niveau des LUNs dans la baie Clariion, extension qui peut se gérer de deux façons différentes que je ne ferai que survoler ici :

  • extension directe de la LUN (expand) : cette méthode est la plus rapide, mais présente diverses limitations (la plus notable étant que dans le cas d'une LUN stripée, on est obligé de rajouter au minimum l'équivalent d'une colonne du stripe : pour une LUN de 100 Go stripée sur deux colonnes de 50 Go, on doit rajouter au minimum 50 Go pour pouvoir réaliser une extension)
  • migration de la LUN (migrate) : cette méthode consiste à recréer une nouvelle LUN de la taille souhaitée, et à demander à la baie de migrer l'ancienne LUN sur la nouvelle. La baie va alors copier les données de manière transparente, à chaud, et une fois l'opération terminée, elle présentera aux serveurs la nouvelle LUN avec les mêmes caractéristiques que l'ancienne (même ID et WWN, notamment).

Une fois l'extension réalisée au niveau de la baie, il reste à expliquer au serveur que le device sous-jacent à changé de taille. Solaris 10 s'en rend compte tout seul (ce qui fut pour moi une agréable surprise), mais il reste à passer le mot à Volume Manager, ce que l'on fait avec la commande vxdisk resize.

Enfin, la nouvelle taille de disque reconnue par VM, on peut étendre le(s) volume(s) avec vxresize.

La pratique

Changeons de monde, voici la vraie vie. Au niveau des baies Clariion, rien à dire, elle font bien leur travail, et ça marche exactement tel que c'est annoncé par le constructeur, ce qui mérite d'être souligné.

En revanche, une fois arrivés au niveau de la reconnaissance de la nouvelle taille par VM, ça se gâte :

# vxdisk -g mondg resize mondisque VxVM vxdisk ERROR V-5-1-8643 Device mondisque: resize failed: Private region will overlap public region

Ca fait peur, non? Il y a de quoi, quand on sait que la private region contient toute la configuration des objets Veritas ... Bon, je ne vous fait pas mariner plus longtemps, il y a une explication rationnelle, même si elle est loin d'être évidente au premier abord. La source du problème est le format de l'objet disque qui a été créé dans VM : dans mon cas, ce format a été forcé à sliced, au lieu de la valeur par défaut CDS.

# vxdisk list | grep mondisque mondisque auto:sliced mondg01 mondg online

Alors, en quoi ce paramètre, à lui seul, explique-t-il l'erreur renvoyée ci-dessus? C'est finalement assez simple. Avec le format sliced, le disque est utilisé sous forme de partitions (au sens Solaris du terme) classiques, contrairement au format CDS, prévu pour être plus portable. On a notamment la private region sur une partition (normalement la partition 3), et la public region sur une autre (normalement la 4). Or, quand la taille du disque sous-jacent (ici une LUN, mais ça ne change rien) évolue, la géométrie du disque présentée au système évolue également, comme on peut le voir sur l'exemple ci-dessous, avec un passage de 50 à 300 Go (réalisé sur un disque CDS pour que le vxdisk resize fonctionne) :

# prtvtoc /dev/rdsk/c7tXXXXXXXXXXXXXXXXXXXXXXXd0s2 | grep sector * 512 bytes/sector * 2560 sectors/cylinder # vxdisk -g mondg resize mondisque # prtvtoc /dev/rdsk/c7tXXXXXXXXXXXXXXXXXXXXXXXd0s2 | grep sector * 512 bytes/sector * 10240 sectors/cylinder

On le voit, le nombre de secteurs (de 512 octets) par cylindre change considérablement. Or, il se trouve que les slices Solaris sont alignées par défaut sur des limites de cylindres. Reprenons un disque sliced, avec une private de 32 Mo environ, installée dans la partition 3 :

* First Sector Last * Partition Tag Flags Sector Count Sector Mount Directory 2 5 01 0 104852480 104852479 3 15 01 2560 66560 69119 4 14 01 69120 104783360 104852479

66560 secteurs, à 2560 secteurs par cylindre, ça représente 26 cylindres. Imaginons maintenant que l'on change la géométrie du disque par une extension de la LUN, et que l'on arrive à 10240 secteurs par cylindre : 66560/10240 = 6.5, ce n'est pas un compte rond. Pour pouvoir conserver l'ensemble des données de la private region, il faudra donc l'étendre un peu, en s'alignant sur le dernier cylindre entamé, soit un total de 7 cylindres, qui nous amèneront alors à 71680 secteurs. Et crac, ça y est, notre private dépasserait sur la public, d'où le message d'erreur.

Evidemment, savoir d'où vient le problème, c'est bien. Savoir comment le corriger, c'est mieux, et c'est à suivre dans la partie 2 : comment passer du format sliced au CDS



102 Comments »