Forum général.général Extension LVM dans environnement SAN

Posté par .
Tags : aucun
1
11
jan.
2011
Bonjour,

je tente d'agrandir un filesystem sur RHEL4 suite à une extension d'une de mes LUN. Je connais bien les commandes LVM (enfin je pense !) pour retaille mon PV et mon FS. Cependant, un pvresize ne change rien car la machine ne doit pas réussir à comprendre que le disque a changé de taille. En effet, j'ai tenté ce qui est indiqué dans [URL="http://jbbarth.com/archives/2009/6/6/extension_dun_disque_lv(...)]cette doc[/URL] mais j'utilise Powerpath (impératif) et non multipath. J'ai essayé d'adapter à mon système mais sans succès. Vais-je être obligé de créer une seconde partition primaire que je rattacherai à mon VG ou mon PV est-il en mesure de reconnaitre la nouvelle taille de la LUN svp ?

La partie qui me dérange vraiment est l'impossibilité de faire un pvresize puisque le pvscan n'indique pas une nouvelle taille de disque. (Sous AIX, nous faisons cette manipulation avec un cfgmgr).
  • # Il me semble que ce soit possible ....

    Posté par . Évalué à 2.

    Par contre je ne sais plus comment on fait. Tout dépend de la façon dont le disque a été créé initialement. Je sais que quelqu'un m'en a parlé au taf il y a peu de temps mais il n'est pas la. Sinon je lui aurai demandé.

    Si tu peux tester sur un autre environnement ce serai bien, parce que ce que je vais te dire la c'est de mémoire.

    Il faut avant tout faire une sauvegarde
    ensuite via un utilitaire de partitionnement, agrandir ta partition LVM (gparted ou équivalent jer ne sais plus ce qu'il a utilisé, ni comment il l'a fait. Il y a quelques précautions à prendre me semble-t-il)
    ensuite il est possible que le pvresize fonctionne (modulo un reboot après agrandissement ? je ne sais plus).
    Ensuite tu as la nouvellle volumétrie à dispo.

    Celà dit quand je dois agrandir une volumétrie SAN, je préfère augmenter le nombre de LUNS plutot que d'agrandir un LUN. Je trouve ça plus propre et moins risqué.
    • [^] # Re: Il me semble que ce soit possible ....

      Posté par . Évalué à 1.

      Merci pour la réponse.

      Nous le faisons très bien "à chaud" sur des AIX 5.3 avec la commande cfgmgr. En revanche, impossible sur redhat de lui faire comprendre que le PV a changé de situation et tnat que mon PV n'est pas étendu, je ne peux pas étendre mes LVs associés.
      Il est à noter également que nous le faisons sur un environnement de production et donc que nous ne pouvons pas (ou du moins il faut éviter) faire un reboot de la machine. En effet, de nombreuses bases de données y sont présentes.

      Pour finir, nous préférons de loin étendre une LUN plutôt de d'en créer une autre pour la même fonctionnalité, car nous en avons environ 180 à gérer ce qui représente une grosse volumétrie
      • [^] # Re: Il me semble que ce soit possible ....

        Posté par (page perso) . Évalué à 1.

        Quelques pistes à creuser:
        # echo 1 > /sys/bus/scsi/devices/w:x:y:z/rescan (chemin à adapter)
        # blockdev --rereadpt /dev/blah
        # partprobe


        Tu peux utiliser blockdev --getsz /dev/blah pour vérifier la taille du LUN telle que vue par le système.
        • [^] # Re: Il me semble que ce soit possible ....

          Posté par . Évalué à 1.

          Je pense que la piste est bonne. En ce qui concerne le rescan je l'avais déjà tenté, c'est ce qui est indiqué dans le lien fourni dans mon premier post d'ailleurs. En revanche, la commande blockdev m'a permis de mettre une info intéressante à jour :

          [root@XXX bin]# blockdev --getsize /dev/emcpowerl1
          10477194
          [root@XXX bin]# blockdev --getsize /dev/emcpowerl
          12582912

          On remarque que la nouvelle taille disque a bien été prise en compte au niveau partition physique. En revanche, je suis obligé du coup de créer avec fdisk une seconde partition primaire, /dev/emcpowerl2, ou puis-je étendre ma première partition /dev/emcpowerl1 ?

          Merci en tout cas pour le coup de main car ça fait 3 mois que je tape à plusieurs portes et je n'ai pas eu de réponse concrète pour le moment (et c'est super bloquant).

          Bonne soirée et à demain.
      • [^] # Re: Il me semble que ce soit possible ....

        Posté par . Évalué à 2.

        Pour finir, nous préférons de loin étendre une LUN plutôt de d'en créer une autre pour la même fonctionnalité, car nous en avons environ 180 à gérer ce qui représente une grosse volumétrie
        180 LUNS de quelle taille ? C'est rien ça ... :)
        • [^] # Re: Il me semble que ce soit possible ....

          Posté par . Évalué à 1.

          J'ai peur que ma question n'ait pas été vue correctement :
          En revanche, je suis obligé du coup de créer avec fdisk une seconde partition primaire, /dev/emcpowerl2, ou puis-je étendre ma première partition /dev/emcpowerl1 ?

          totof>Les LUN varient de 5Go à 600Go. Mais en ce qui me concerne je préfère avoir une LUN par instance Oracle, au moins je sais tout de suite sur laquelle elle se trouve. Nous utilisons Navisphere.
          • [^] # Re: Il me semble que ce soit possible ....

            Posté par . Évalué à 2.

            En revanche, je suis obligé du coup de créer avec fdisk une seconde partition primaire, /dev/emcpowerl2, ou puis-je étendre ma première partition /dev/emcpowerl1 ?
            Je sais que quelqu'un la fait ici au taf : on peut agrandir une partition en prenant quelques précautions. Mais comme la personne qui m'ne a parlé n'est pas là, je ne peux rien te dire malhereusement.

            Sinon, agrandir les LUNs, c'est bien pour un OS qui permet ce genre de manip de façon simple. Je sais que c'est possible qous AIX, mais aussi sur les versions récentes de LVM/HP-UX. Pour VxVm je n'en sais rien. Par contre pour Linux, je ne pense pas que ce soit possible de façon simple aujourd'hui. Il faut bidouiller un peu. Ce qui me pousse à te conseiller, si tu n'arrive pas à modifier la taille de ton PV, à ajouter des LUNS dans ton VG plutot que d'avoir 2 partitions sur la même LUN : je trouve ça plus propre.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.