Veritas Volume Manager (VxVM)
Introduction
"Veritas Volume Manager" (ou VxVM) est un gestionnaire de volumes logiques propriétaire et payant, disponible pour de nombreux systèmes Unix, et même pour Windows. En France, on le trouve à peu près une fois sur deux sur les systèmes Solaris, à la place du gestionnaire de volumes logiques de Sun, "Solaris Volume Manager" ou "SVM" (anciennement "Solstice Disk Suite"), qui lui, est offert avec Solaris.
Par rapport à SVM et à beaucoup d'autres concurrents, VxVM apporte :
- pas de problème de nombre d'Inodes : il sont illimités sur VxVM
- transforme le niveau de Raid à chaud
- possibilité d'ajouter une patte en stripping (raid 0) à chaud
- réduction à chaud des partitions (uniquement si elles ont été formattées en VxFS – système de fichiers Veritas. Ne marche pas avec UFS – système de fichiers par défaut de Solaris).
Certains passages sont illustrés d'exemples ; ces exemples sont tirés d'un serveur Solaris 8 HW 7/03 avec Veritas Volume Manager 3.5.
Précision : cet article est issu de mon expérience personnelle, sur le "terrain", sans avoir reçu de "vraie" formation. Mais certaines commandes m'ont été données par des spécialistes du sujet. Aussi, les méthodes que j'utilise ne sont peut-être pas les meilleures, mais elles fonctionnent.
Installation
Avant d'installer
Avant de commencer quoique ce soit, il est préférable de faire une sauvegarde des données, et surtout une copie du disque système, surtout si des patchs sont nécessaires.
Licence
Veritas Volume Manager s'installe avec une clé de licence. Pour obtenir cette clé de licence, il faut contacter Sun (si vous avez acheté la licence chez eux) et leur fournir :
- le product name (inscrit sur le certificat de licence fournit avec le cd)
- le numéro de série (inscrit sur le certificat de licence fournit avec le cd)
- l'adresse de votre société
- un contact dans votre société (nom + téléphone + mail)
- le hostid du serveur (taper hostid sous Solaris)
Préparation des disques durs
Lorsqu'on met un disque dur sous contrôle de VxVM, on peut encapsuler ou non. Ne pas encapsuler signifie mettre le disque sous contrôle de VxVM en supprimant tout ce qui est dessus, ce qui ne nécessite aucun prérequis. Encapsuler signifie qu'on rajoute la couche VxVM sur un disque en conservant les données existantes, ce qui implique quelques prérequis. Pour qu'un disque soit "encapsulable", il faut qu'il ait deux partitions de libres au sens "format" du terme ; c'est à dire qu'il doit y avoir deux slices inutilisées et quelques Mo de non alloués aux autres slices (à prioris, un ou deux cylindres suffisent).
Ces deux slices seront ensuite utilisés par VxVM et taggués 14 et 15 (visible en faisant prtvtoc /dev/rdsk/cxtydzs2). La partition 15 est la "private", que VxVM utilise pour son fonctionnement interne. La 14 est la "public" qui couvre tout le disque (à l'identique de la slice 2 pour Solaris) et qui représente les données.
Patcher Solaris
Installer les patchs Sun Solaris pré-requis à l'installation des packages Veritas. Ces patchs dépendent de la version de Solaris, de la version de Veritas Volume Manager et des patchs déjà installés. Ils sont détaillés dans la documentation d'installation de Veritas Volume Manager fournie avec le cd d'installation. Les détails dépassent le cadre de ce document.
Avant de passer à la suite, il est préférable de rebooter le serveur et de vérifier que le serveur se comporte correctement, car certains patchs peuvent apporter des problèmes.
Installer les packages Veritas Volume Manager
Cette étape est facultative : si on ne la rentre pas tout de suite, elle sera demandée plus tard. Pour entrer la clé, taper la commande vxlicinst.
# vxlicinst VERITAS License Manager vxlicinst utility version 3.00.007d Copyright (C) VERITAS Software Corp 2002. All Rights reserved. Enter your license key : XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXX License key successfully installed for VERITAS Volume Manager
Installer / configurer Veritas
Taper la commande vxinstall et suivre les instructions en répondant aux questions (des explications sont données au fur et à mesure). Il est conseillé de choisir "custom installation". Si on veut mettre le disque système sous contrôle de VxVM, il faut répondre "yes" à la question "Encapsulate boot disk ?". Pour cela, il faut que le disque soit "encapsulable" (voir chapitre Préparation des disques durs).
Une fois l'installation terminée, il faudra rebooter le serveur. Ça sera l'occasion de vérifier que rien n'a été cassé par l'installation, et que tout démarre bien dans le cas où on a encapsulé le système.
Mirrorer le disque système
Présentation
Pour des raisons évidentes de sécurité, il est intéressant de faire un miroir du disque système. Le miroir étant un miroir logiciel géré par VxVM, il est bien sûr impératif que le disque système soit déjà sous contrôle de VxVM.
Dans l'explication qui suit, on considère que le disque système est c0t0d0 et que le disque miroir est c0t2d0.
Créer le mirroir
Voici les différentes étapes :
- ajouter un nouveau disque dans le serveur
- vérifier avec format qu'il est bien reconnu par Solaris. S'il ne l'est pas, forcer la reconnaissance du nouveau matériel avec "devfsadm -v".
- vérifier qu'il est vu par VxVM avec "vxdisk list". S'il ne l'est pas, taper les commandes suivantes "drvconfig", puis "disks", puis "vxdctl enable". Vérifier que cette fois il est bien reconnu.
- mettre le nouveau disque sous contrôle de VxVM, l'appeler "rootmir" et le faire appartenir au même disk group (dg) que le disque système (si on a conservé les choix par défaut, le disque système s'appelle "rootdisk" et appartient au groupe "rootdg"). La commande à utiliser est "vxdiskadd c0t2d0" ; il suffit de répondre aux questions.
- Mirrorer les disques avec la commande interactive "vxdiskadm" :
- dans le menu, valider le choix "6 Mirror volumes on a disk"
- faire "list" pour vérifier qu'on voit bien "rootdisk" et "rootmir"
- lorsqu'il demande le disque à mirrorer, lui dire "rootdisk"
- lorsqu'il demande le disque de destination, lui dire "rootmir"
- confirmer. Il va alors mirrorer chaque volume existant d'un disque à l'autre, en affichant la progression.
On peut taper les commandes "prtvtoc /dev/rdsk/c0t2d0s2" pour vérifier que les tags 14 et 15 ont été créés, preuve que le disque est sous contrôle de VxVM.
# prtvtoc /dev/rdsk/c0t2d0s2 * /dev/rdsk/c0t2d0s2 partition map * * Dimensions: * 512 bytes/sector * 135 sectors/track * 16 tracks/cylinder * 2160 sectors/cylinder * 3882 cylinders * 3880 accessible cylinders * * Flags: * 1: unmountable * 10: read-only * * Unallocated space: * First Sector Last * Sector Count Sector * 2095200 4292874256 2159 * 8380800 4288681696 2095199 * 3144960 615600 3760559 * 7497360 883440 8380799 * * First Sector Last * Partition Tag Flags Sector Count Sector Mount Directory 0 2 00 2160 2093040 2095199 1 3 01 2095200 1049760 3144959 2 5 01 0 8380800 8380799 3 15 01 0 2160 2159 4 14 01 2160 8378640 8380799 6 4 00 3760560 2097360 5857919 7 7 00 5857920 1639440 7497359
Configurer l'Openboot Prom (OBP)
Maintenant, il va falloir configurer l'OBP pour pouvoir booter sur l'un ou l'autre des disques. Pour cela, on va créer des alias "rootdisk" et "rootmir" qui vont pointer respectivement sur le disque principal et le mirroir.
Pour commencer, sous Solaris, il faut repérer le chemin long des deux devices :
# ls -l /dev/rdsk/c0t0d0s2 /dev/rdsk/c0t2d0s2 lrwxrwxrwx 1 root root 45 Oct 27 15:31 /dev/rdsk/c0t0d0s2 -> ../../devices/pci@1f,4000/scsi@3/sd@0,0:c,raw lrwxrwxrwx 1 root other 45 Oct 27 15:31 /dev/rdsk/c0t2d0s2 -> ../../devices/pci@1f,4000/scsi@3/sd@2,0:c,raw
La partie à retenir, pour cet exemple, est "/pci@1f,4000/scsi@3/sd@0,0" et "/pci@1f,4000/scsi@3/sd@2,0", c'est à dire le chemin sans "../../devices" au début et sans ":" et les caractères suivants à la fin. Si on a oublié de les noter, on pourra les retrouver dans l'OBP en tapant devalias et en repérant les disques "disk 0" et "disk 2".
Ensuite, il faut rebooter le serveur pour se retrouver dans l'OBP : init 0.
Une fois dans l'OBP, taper les commandes suivantes :
setenv use-nvramrc? True nvalias rootdisk /pci@1f,4000/scsi@3/sd@0,0 nvalias rootmir /pci@1f,4000/scsi@3/sd@2,0 setenv boot-device rootdisk rootmir reset-all
Le serveur va alors rebooter. Par défaut, il va booter sur "rootdisk". Pour le forcer à booter sur le miroir (il est conseillé de le faire pour vérifier qu'il marche), il faut taper "boot rootmir" dans l'OBP.
Mettre un disque non système sous contrôle de VxVM
Lister les disques sous contrôle de VxVM
Avant de mettre un disque sous contrôle de VxVM, on peut s'assurer qu'il n'y est pas déjà, ou simplement regarder quels sont les autres disques gérés par VxVM. Pour cela, on utilise la commande "vxdisk list".
# vxdisk list DEVICE TYPE DISK GROUP STATUS c0t0d0s2 sliced rootdisk rootdg online c0t1d0s2 sliced - - error c0t2d0s2 sliced rootmir rootdg online c0t3d0s2 sliced - - error c2t0d0s2 sliced - - error c2t3d0s2 sliced - - error c3t3d0s2 sliced - - error
Si le disque n'est pas vu par VxVM
Si le disque qu'on veut ajouter est bien vu par "format", mais n'est pas listé par "vxdisk list", alors exécuter les commandes suivantes : "drvconfig", puis "disks", puis "vxdctl enable". Maintenant, "vxdisk list" doit le voir.
Détail des commandes :
- drvconfig : scanne la chaîne scsi et détecte les nouveaux disques
- disks : créé les fichiers device dans /dev
- vxdctl enable : demande à VxVM de prendre les disques en compte
Note : la méthode ci-dessus est toujours fonctionnelle, mais maintenant il faudrait plutôt utiliser devfsadm pour remplacer les deux premières commandes. Ce qui nous donne, pour faire la même chose, les deux commandes suivantes :
- devfsadm -Cv : détecte et configure les nouveaux devices (le C est facultatif, il fait un clean des devices qui n'existent plus
- vxdctl enable : demande à VxVM de prendre les disques en compte
Mettre le disque sous contrôle de VxVM (disk group)
La commande à utiliser est vxdiskadd. Elle a pour effet d'associer le disque à un groupe (existant ou nouveau).
vxdiskadd c2t0d0
Il va alors demander si on veut ajouter le disque à un Disk Group existant (il affiche la liste) ou si on veut en créer un nouveau (il va demander le nom).
Il faut ensuite dire si le disque doit être encapsulé ou pas. Pour rappel, encapsuler consiste à conserver les données existantes, mais nécessite que le disque soit encapsulable (voir chapitre Préparation des disques durs). Si le disque ne contient pas de données, il ne faut pas encapsuler.
Il existe une autre possibilité pour faire la même chose : taper "vxdiskadm" et choisir "1. Add or initialize one or more disks" dans le menu, et répondre aux questions comme avec vxdiskadd.
Il existe même une troisième méthode entièrement en ligne de commandes qui m'a un jour sauvé la vie, car les deux autres ne fonctionnaient pas, je n'ai jamais compris pourquoi (ça m'indiquait que le disque était invalide). La voici :
vxdg -g mondg adddisk mondg05=c2t0d0
A noter que "mondg05" est le nom du disque dans le disque group. On peut choisir le nom qu'on veut du moment qu'il n'est pas déjà pris. Avec les deux premières méthodes ce nom est déterminé automatiquement (nom du dg suivi de deux chiffres).
Remarque : lorsqu'un disque est géré par VxVM, son raw device n'est plus vu comme /dev/rdsk/..., mais comme /dev/vx/rdsk.... De même, le spécial devient /dev/vx/dsk/....
Gestion des volumes
Créer un volume
Pour créer un volume (une partition logique) dans un disk group (dg), on utilise la commande vxassist. Puis on formate le volume avec newfs ou mkfs, comme pour n'importe quelle partition physique. Pour finir, il faudra l'ajouter dans /etc/vfstab.
Syntaxe :
vxassist -b -g nom_disk_group make nom_volume taille
Exemple :
vxassist -b -g dbdg make oraclelv 20g
Création d'un filesystem UFS :
newfs /dev/vx/rdsk/nom_disk_group/nom_volume
Création d'un filesystem VxFS :
mkfs -F vxfs /dev/vx/rdsk/nom_disk_group/nom_volume
Ajout de la ligne correspondante dans /etc/vfstab :
/dev/vx/dsk/nom_disk_group/nom_volume /dev/vx/rdsk/nom_disk_group/nom_volume /point_de_montage vxfs defaults 1 2
Remarque : la création d'un filesystem VxFS nécessite une licence Veritas File System.
Vérifier l'espace restant sur un volume
Syntaxe :
vxdg [-g groupe] free
Renvoie la taille en blocs de 512 octets (colonne OFFSET=taille utilisée, LENGTH=taille restante)
Exemple :
# vxdg -g rootdg free DISK DEVICE TAG OFFSET LENGTH FLAGS rootdisk c0t0d0s2 c0t0d0 71109846 11556 n rootmir c1t0d0s2 c1t0d0 24576723 5778 - rootmir c1t0d0s2 c1t0d0 24588278 1 - rootmir c1t0d0s2 c1t0d0 71121402 2889 -
Agrandir ou réduire un volume
Agrandir de 4 Go :
vxresize -g nom_disk_group nom_volume +4g
Réduire de 3 Go :
vxresize -g nom_disk_group nom_volume -3g
Bien sûr, tout ça se fait à chaud, sans avoir besoin de démonter les partitions. Tout le monde peut continuer à travailler. C'est formidable !
Si vxresize n'est pas dans le PATH, le rechercher avec "grep vxresize /var/sadm/install/contents". Il est normalement dans /usr/lib/vxvm/bin/.
Renommer un volume (et renommer ses plexes)
Si on veut changer le nom d'un volume, utiliser la syntaxe suivante :
vxedit rename oldlv newlv
Lorsqu'on fait vxprint, on remarque que le volume possède des plexes qui lui sont associés. Les plexes sont nécessaires au fonctionnement de VxVM, mais n'ont pas vraiment d'intérêt pour l'administrateur système. Cependant, lorsqu'on créé un volume, les plexes associés sont automatiquement créés avec un nom reprenant le nom du volume, mais renommer le volume ne renomme pas les plexes. Il peut être intéressant de renommer également les plexes pour garder une cohérence, notamment quand on fait un vxprint. La syntaxe pour renommer les plexes est la suivante :
vxedit -g rootdg -p rename oldlv-01 newlv-01
Supprimer un volume
Syntaxe :
vxassist -g nom_groupe remove volume nom_volume
Exemple :
vxassist -g dbdg remove volume oraclelv
Voir la liste de tous les dg
# vxdg list NAME STATE ID rootdg enabled 1247755677.135.uyqev3 exploitdg enabled 1151484964.148.uyqev3 tkappli00dg enabled 1142590040.99.uyqev3 tk00dg enabled 1142591823.119.uyqev3 tk01dg enabled 1171641444.4311.bakctl01 zonedg enabled 1141381993.11.uyqev3
Retirer un disque d'un DG
Nous allons suivre l'exemple d'un DG qui est réparti sur deux disques. La totalité des volumes occupe moins de place que la taille d'un disque. Nous allons donc migrer les volumes d'un disque pour tous les placer sur le même disque, puis retirer le disque qui n'a plus de données. Ainsi on pourra réutiliser le disque pour autre chose.
Dans l'exemple qui suit, le DG s'appelle exampledg composé de exampledg_01 et exampledg_02.
On regarde l'espace utilisé sur chacun des disques :
# vxdg -g exampledg free DISK DEVICE TAG OFFSET LENGTH FLAGS exampledg exampledg_01 emcpower108s2 emcpower108 34213888 175484928 - exampledg exampledg_02 emcpower109s2 emcpower109 134217728 75481088 -
Maintenant on va déplacer les données de exampledg_01 vers exampledg_02 :
/etc/vx/bin/vxevac -g exampledg exampledg_01 exampledg_02
Ca peut être long. On peut regarder l'avancement avec "vxtask list".
A noter qu'il n'est pas impératif de préciser le disque de destination (exampledg_02 ici). Dans ce cas, vxvm déplace les données sur un des autres disques du DG.
Une fois que c'est fini, on vérifie que tout l'espace a bien été libéré :
# vxdg -g exampledg free DISK DEVICE TAG OFFSET LENGTH FLAGS exampledg_01 emcpower108s2 emcpower108 0 209698816 - exampledg_02 emcpower109s2 emcpower109 168431616 41267200 -
On peut maintenant retirer le disque du DG :
# vxdg -g exampledg rmdisk exampledg_01
Et on vérifie qu'il ne fait plus partie du DG :
# vxdg -g exampledg free DISK DEVICE TAG OFFSET LENGTH FLAGS exampledg_02 emcpower109s2 emcpower109 168431616 41267200 -
Retirer un disque du contrôle de VxVM
Pour retirer un disque, il faut d'abord avoir supprimé tous les volumes qu'il contenait (voir Supprimer un volume), et également supprimer les disk group.
Détruire un disk group
vxdg destroy mon_dg
Retirer le disque
vxdisk rm c3t0d0
Puis vérifier que ça a bien fonctionné avec :
vxdctl enable vxdisk list
Échanger physiquement un disque sous contrôle de VxVM
Pour changer un disque qui est sous contrôle de VxVM (par exemple parce qu'il est en fin de vie), le principe est de :
- avertir VxVM qu'on va changer le disque
- faire une copie du disque
- remettre le disque sous contrôle de VxVM
Les détails sont ci-dessous.
Avertir VxVM qu'on va changer le disque
Taper "vxdiskadm", choisir l'option "4. Remove a disk for replacement" et indiquer le volume (ex: datadg01, pour le premier volume du groupe datadg).
Faire une copie du disque
On peut maintenant faire une copie brute du disque vers le nouveau avec dd. C'est brutal, mais ça marche.
Remettre le disque sous contrôle de VxVM
Taper "vxdiskadm", choisir l'option "5. Replace a failed or removed disk" et indiquer le disque (ex: c1t1d0s2).
Il arrive que cette méthode ne fonctionne pas. Dans ce cas, on peut utiliser les outils en ligne de commande :
- /etc/vx/bin/vxreattach -b
- si ça ne marche pas : vxdg -g datadg -k adddisk datadg01=c1t1d0s2
- on vérifie que les volumes sont ENABLE : vxprint -Ath
- s'ils ne sont pas ENABLE, faire : vxvol -g datadg startall et si toujours pas ENABLE, forcer avec vxvol -g datadg -f startall
Pour finir, remonter les partitions associées avec mount.
Remarque : on peut également faire plus "propre" en copiant d'abord les données du disque, en ne prenant que le contenu des volumes VxVM qui sont sur le disque en question, mais c'est plus long à expliquer et je n'ai pas encore testé.
Export / import
Les disk group peuvent facilement s'exporter d'un serveur pour s'importer sur un autre serveur. Voici rapidement les différentes étapes sur un dg "testdg".
Sur le serveur source
1/ démonter les points de montage associés au dg
umount /directories
2/ stopper les volumes
vxvol -g testdg stopall
3/ exporter le dg
vxdg deport testdg
4/ déconnecter physiquement le disque ou la LUN du serveur
Sur le serveur cible
5/ connecter physiquement le disque ou la LUN sur le serveur
6/ importer le dg (veritas est capable tout seul de retrouver le dg sur le nouveau volume)
vxdg import testdg
7/ démarrer tous les volumes sur le nouveau système et resynchroniser les mirroirs en arrière plan
vxrecover -g testdg -sb
8/ monter les répertoires (créer si nécessaire les points de montage et éventuellement mettre à jour la vfstab)
Et voilà. C'est à peine plus compliqué que de passer une clé usb d'un pc à un autre !
Les quotas
Les quotas s'appliquent pour un utilisateur ou un groupe. Pour un fs, on fixe une limite soft et hard en nombre de blocs et/ou en nombre d'inodes.
Afficher la valeur actuelle
Pour afficher les quotas, on utilise la commande vxquota avec le nom ou l'uid.
vxquota -v 1399 Disk quotas for (no account) (uid 1399): Filesystem usage quota limit timeleft files quota limit timeleft /export/home 41304 250000 250000 33 0 0
Modifier les valeurs
On utilise vxedquota avec le nom ou l'uid. On se retrouve dans un editeur.
vxedquota -u 1399 ==> fs /export/home blocks (soft = 250000, hard = 250000) inodes (soft = 0, hard = 0)
Divers
Afficher la licence Veritas
On utilise la commande vxlicrep.
# vxlicrep VERITAS License Manager vxlicrep utility version 3.00.007d Copyright (C) VERITAS Software Corp 2002. All Rights reserved. Creating a report on all VERITAS products installed on this system -----------------***********************----------------- License Key = XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXX Product Name = VERITAS Volume Manager Serial Number = 9547 License Type = PERMANENT_NODE_LOCK OEM ID = 7 Node Lock Type = (Hostid and Architecture ID) Features := VxVM = Enabled CPU Count = Not Restricted
Gestion des largefiles (fichiers de plus de 2 Go)
Avec VxFS, on peut activer ou désactiver la gestion des fichiers de plus de 2 Go. C'est l'option "largefiles" qui gère ça. Cette option se met à la création du filesystem, mais peut bien sûr s'activer ou se désactiver à chaud... Il n'y a donc rien à modifier dans /etc/vfstab.
Seules les versions anciennes de VxFS n'activent pas les largefiles par défaut.
Voir si les largefiles sont activés
# fsadm -F vxfs /point/de/montage nolargefiles
"-F vxfs" est facultatif.
Les activer
# fsadm -o largefiles /point/de/montage
Les déactiver
# fsadm -o nolargefiles /point/de/montage
Faire un fsck d'un filesystem VxFS
Si on doit faire un fsck sur un filesystem VxFS, la syntaxe est la suivante :
/usr/sbin/fsck -F vxfs -o nolog,full /dev/vx/rdsk/mon_dg/mon_volume
Explications :
- nolog : demande à fsck d'accéder directement au filesystem sans passer par le log
- full : force à vérifier le filesystem en entier
Voir la liste des tâches en cours
Pour voir la liste des actions en cours par Veritas (ainsi que la progression en poucentage), taper :
# vxtask list
On obtient également le numéro de tâche. Avec, on peut mettre en pause la tâche avec "vxtask pause task_id" et la relancer avec "vxtask resume task_id".
Script d'affichage de l'espace restant dans un DG
Voici un petit script qui permet d'afficher l'espace disque restant, utilisé, total et pourcentage utilisé, dans un DG.
#!/bin/bash
#
# Pour tous les dg veritas existant, affiche l'espace disponible en Go
# ainsi que l'espace utilise, l'espace total et le pourcentage d'utilisation.
#
LISTE_DG=$(vxdg -q list|awk '{print $1}' |sort |uniq)
echo -e "Disk Group \t Free space \t Used space \t Total space \t Percent used"
for i in ${LISTE_DG}
do
FREE=`echo $(vxdg -qg $i free |awk '{print $5}' |tr '\n' '+') |sed "s/.*/(0+&/"| sed "s/+$/)\/2\/1024\/1024/"|bc`
TEMP=`vxdisk -qg $i -o size list 2>/dev/null |awk '{print $2}' |tr '\n' '+'`
USED=`echo "($TEMP" |sed "s/+$/)\/1024/g" |bc`
TOTAL=`echo $(($FREE + $USED))`
PERCENT_USED=`echo "scale=2 ; 100*$USED/$TOTAL"|bc`
# l'ajout du "0+" est indispensable pour les DG qui n'ont plus d'espace libre, car ils n'apparaissent pas avec "vxfg free"
echo -e "$i \t\t ${FREE} Go \t ${USED} Go \t ${TOTAL} Go \t ${PERCENT_USED}%"
done
Exemple d'utilisation :
# /root/espace_dispo_sur_dg.sh Disk Group Free space Used space Total space Percent used bkpdg 359 Go 1400 Go 1759 Go 79.59% datadg 403 Go 1200 Go 1603 Go 74.85% zonedg 169 Go 200 Go 369 Go 54.20%
Ca permet de voir très rapidement où on en est.