web-dev-qa-db-ja.com

物理エクステントとpvresizeを使用したLVMボリュームグループの拡張

LVM管理ボリュームの拡張に関して、LVMに関する2つの質問があります。

Firstly、from（edit：old）ドキュメントを読んだLVMと、ボリュームグループと物理エクステントの関係について、VGを256GBより大きくする場合は、PEサイズを4MBより大きくする必要があります。例は この記事 からのもので、4MBのPEで「最大論理ボリュームサイズは255.99ギガバイト」というメッセージが表示されます。ただし、これは、PEサイズが4MBの場合、VGが256GBを超えるボリュームを定義/追加することを許可せず、試行するとエラーまたは少なくとも警告をスローすることを意味すると思います。ボリュームグループの1つ（抜粋）についてこれを示すVM）があるため、これを取り上げます。

VG Size               499.50 GiB
PE Size               4.00 MiB
Total PE              127872
Alloc PE / Size       127872 / 499.50 GiB
Free  PE / Size       0 / 0

VGは、2つの物理ボリュームで構成されています。1つは100GB（/ dev/sda2）で、もう1つは400GB（/ dev/sda3）です。このVGで4MBのPEサイズだけで500GBのスペースを正常に（？）定義できたのはどうしてですか？マウントされた論理ボリュームをいっぱいにして500GBを実際に保存できるかどうかを確認する実際のテストはまだ行っていませんが、LVMの動作方法に変更がない限り、論理ボリュームは256GBに達するとデータの「書き込みを停止」します。残りの244GBを示しているにもかかわらず、スペースを利用しましたか？ VGのPEサイズ（インプレース）を8MBに正常に変更できますか？

次に、vmdkハードドライブのサイズを作成するのではなく増やすときに、追加されたスペースを利用するためにLVMパーティション/物理ボリュームを拡張することを希望する場合新しい物理ボリュームをVGに追加すると（ この優れた記事で説明されているように VMWareの場合）、pvresizeを使用しますか？私の制約は、既存のデータを破壊せず、単にボリュームにスペースを追加することです。これは、VMWare KBの記事で実現されていますが、 このSEの質問 を読んだ後、単にボリュームを拡張できるかどうかについて疑問があります。または、「より大きなものを削除して作成する」必要がある場合。

VMWareの記事はプライマリパーティションを追加する機能に依存しているため、明らかにその手順は最大4つのプライマリパーティションまでしか実行できません。その後は、ボリュームを拡張できなくなるか、pvresizeなどを使用する必要があると思います（適切に使用する方法がわからない/既存のデータを破壊することを恐れて試すのをためらっています）。 pvresizeが私が探していることを実行できるかどうかについてのポインタはありますか？

linuxlvmdiskmanagement
1
SeligkeitIstInGott

最初の質問への回答

あなたがあなたのすべての考慮事項に基づいている記事を考慮してください非常に時代遅れです！リンクしたHOWTOページでは明確な日付が報告されていませんが、 言及されたHOWTOに関連するコード を見ると、2000年に遡るカーネル2.3.99を参照していることがわかります。 15年前！

これは、4MBのPEを備えたマルチテラバイトのPVで問題が発生したという私の直接の経験と完全に一致しています[〜＃〜] no [〜＃〜]実行中のシステムの出力は次のとおりです。5x2TBS-ATAディスク上に構築され単一の7.28を提供するRAID5VG（vg_raid）TB LV（lv_raid）：

[root@nocdump ~]# cat /etc/centos-release 
CentOS release 6.5 (Final)

[root@nocdump ~]# uname -r
2.6.32-431.17.1.el6.x86_64

[root@nocdump ~]# rpm -q lvm2
lvm2-2.02.100-8.el6.x86_64

[root@nocdump ~]# vgdisplay 
  --- Volume group ---
  VG Name               vg_raid
  System ID             
  Format                lvm2
  Metadata Areas        5
  Metadata Sequence No  19
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                5
  Act PV                5
  VG Size               9,10 TiB
  PE Size               4,00 MiB
  Total PE              2384655
  Alloc PE / Size       2384655 / 9,10 TiB
  Free  PE / Size       0 / 0   
  VG UUID               rXke5K-2NOo-5jwR-74LT-hw3L-6XcW-ikyDp0    

[root@nocdump ~]# pvdisplay 
  --- Physical volume ---
  PV Name               /dev/sdb1
  VG Name               vg_raid
  PV Size               1,82 TiB / not usable 4,00 MiB
  Allocatable           yes (but full)
  PE Size               4,00 MiB
  Total PE              476931
  Free PE               0
  Allocated PE          476931
  PV UUID               7ToSLb-H9Of-unDk-Yt22-upwi-qkVE-ZiEKo2

  --- Physical volume ---
  PV Name               /dev/sdc1
  VG Name               vg_raid
  PV Size               1,82 TiB / not usable 4,00 MiB
  Allocatable           yes (but full)
  PE Size               4,00 MiB
  Total PE              476931
  Free PE               0
  Allocated PE          476931
  PV UUID               PaUyX1-jykz-B2Tp-KE2M-9VaT-E4uY-iv8ppi

  --- Physical volume ---
  PV Name               /dev/sdd1
  VG Name               vg_raid
  PV Size               1,82 TiB / not usable 4,00 MiB
  Allocatable           yes (but full)
  PE Size               4,00 MiB
  Total PE              476931
  Free PE               0
  Allocated PE          476931
  PV UUID               DCag4w-CWbp-bUUI-7S24-JCFL-NlUK-Vgskab

  --- Physical volume ---
  PV Name               /dev/sde1
  VG Name               vg_raid
  PV Size               1,82 TiB / not usable 4,00 MiB
  Allocatable           yes (but full)
  PE Size               4,00 MiB
  Total PE              476931
  Free PE               0
  Allocated PE          476931
  PV UUID               3GW2LM-b01Y-oIgd-DHJf-Or0a-fys2-wLesSX

  --- Physical volume ---
  PV Name               /dev/sdf1
  VG Name               vg_raid
  PV Size               1,82 TiB / not usable 4,00 MiB
  Allocatable           yes (but full)
  PE Size               4,00 MiB
  Total PE              476931
  Free PE               0
  Allocated PE          476931
  PV UUID               fxd1rG-E9RA-2WsN-hLrG-6IgP-lZTE-0U52Ge


[root@nocdump ~]# lvdisplay /dev/vg_raid/lv_raid
  --- Logical volume ---
  LV Path                /dev/vg_raid/lv_raid
  LV Name                lv_raid
  VG Name                vg_raid
  LV UUID                fRzAnT-BQZf-J1oc-nOK9-BC10-S7w1-zoEv2s
  LV Write Access        read/write
  LV Creation Host, time nocdump, 2014-05-23 00:17:02 +0200
  LV Status              available
  # open                 1
  LV Size                7,28 TiB
  Current LE             1907720
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     1280
  Block device           253:15

2番目の質問への回答

あなたはこう言います：「...ボリュームを単に拡張できるのか、それとも「より大きなボリュームを削除して作成する必要があるのか​​...」について疑問があります。

いくつかの予備的な概念を明確にしましょう。

  1. あなたが通常の状態にいるとしましょう：あなたは共通のmsdosパーティションを持つHDDを持っています。そのため、最大4つのプライマリパーティションがあります。

  2. LVM物理ボリュームが上記の4つのプライマリパーティションの1つの上に定義されており、そのようなLVMパーティション（タイプ8e）がディスクの最大使用可能スペースまで広がっている（つまり、間に他のパーティションがない）とします。 LVM-Type-8eとディスクの終わり）

したがって、上記に基づいて、次のようなHDDがあります。

[root@nocdump ~]# parted /dev/sda print
Modello: ATA ST2000DM001-1E61 (scsi)
Disco /dev/sda: 2000GB
Dimensione del settore (logica/fisica): 512B/4096B
Tabella delle partizioni: msdos

Numero  Inizio  Fine    Dimensione  Tipo     File system  Flag
 1      1049kB  525MB   524MB       primary  ext4         avvio
 2      525MB   1999GB  1998GB      primary               lvm

そのような状態で：

  1. スペースが不足している場合は、次のことを考慮する必要があります。

    3a）入力されるのは、ファイルシステム（EXT3、EXT4、NTFS、FAT32、HFSなどで一般的に参照される「もの」）です。

    3b）ファイルシステムがデバイス内にカプセル化されている。非LVMシナリオでは、このようなデバイスは通常「パーティション」です。しかし、あなたの場合、私たちはLVMを使用しているので、そのようなデバイスはLVM論理ボリュームです。

    3c）論理ボリュームがLVMボリュームグループに含まれている

    3d）ボリュームグループは物理ボリュームで構成されています。

    3e）物理ボリュームは「デバイス」（非LVMシナリオのステップ3bで参照されるのと同じデバイス）の上に構築され、あなたの場合、そのようなデバイスは1つのプライマリパーティション（私の場合は上記の/ dev/sda2）です。 ）

そう：

  1. あなたの場合、ファイルシステムを拡大するために必要な手順は次のとおりです。

    i）ディスクの最後に「パーティション化されていないスペース」を追加して、物理ディスクを拡大します。

    ii）LVMにそのようなパーティション化されていないスペースを使用するオプションを与えます。これは、2つの異なるモードで実現できます。

    iii/1）LVM-type-8eパーティションを拡大して、ディスクの新しい端で終了するようにします（これは、既存のパーティションがディスク上の最後のパーティションである場合にのみ可能です。したがって、上記のポイント2の要件）

    iii/2）パーティション化されていないスペースを新しいプライマリパーティションに割り当て、タイプ8eを割り当てます。これは新しいLVM-Physical_Volumeになり、Volume_Groupを拡大するのに役立ちます。

ポイントiii/1に興味があるようですので、焦点を当てます。だから...既存のプライマリパーティションを拡大する方法？

警告！：これは危険です！データの適切なバックアップと、適切な災害復旧計画があることを確認してください。実行しているリスクを理解していない場合は、先に進まないでください！

答えは非常に簡単です。プライマリパーティションはディスクPartition-Table内のSTART_CYLINDERおよびEND_CYLINDERで参照されるため、END_CYLINDERを変更するだけで済みます。 STARTおよびENDシリンダーの現在の値は、次のように「fdisk -lu/dev/sda」で取得できます。

[root@nocdump ~]# fdisk -lu /dev/sda

Disco /dev/sda: 2000.4 GB, 2000398934016 byte
[...]
Sector size (logical/physical): 512 bytes / 4096 bytes
[...]
Dispositivo Boot      Start         End      Blocks   Id  System
[...]
/dev/sda2         1026048  3904294911  1951634432   8e  Linux LVM

したがって、私の/ dev/sda2は1026048で始まり、904294911で終わります。これで、/ dev/sda2パーティションを削除して、1026048で始まり、拡大されたドライブの新しい端で終わる新しいパーティションを作成できます。そのようなパーティションにタイプ8eを割り当てることを忘れないでください。もちろん、変更を保存することを忘れないでください。 このプロセスに「満足」を感じない場合は、リスクが高いため、唯一の選択肢はiii/2です

  • iv）パーティションが拡大されたので、OSにパーティションテーブルをリロードするように説得する必要があります。 あなたが言及したSFの質問で 、詳細はたくさんあります。最悪のシナリオとして、サーバーを再起動する必要があります

  • v）パーティションが拡大され、OSによって正しく認識されたので、新しい問題が発生しました：特定のサイズであることがわかっているLVM-Physical_Volumeがあります（元のサイズ）、およびそのようなサイズは、基になる8e-Physicalパーティション（拡大したばかり）よりも小さくなります。このような不一致は、次の方法で自分で確認できます。

  • pvdisplay：元の小さいサイズを示します。

  • lvmdiskscan -l：新しい、より大きなサイズを示しています。上記の数値がわかったら、次のように、「pvresize "」とその「setphysicalvolumesize」パラメータを使用して、PVメタデータを新しいより大きなサイズに再設定できます。

    pvresize --setphysicalvolumesize 49.51G /dev/sda2

私は強く少しだけ使用することをお勧めします小さい pvresizeで、lvmdiskscanによって示される値よりも小さいことに注意してください。これは、PVサイズを物理的に使用可能なスペースよりも誤って大きい値に設定すると、非常に悪いことが起こる可能性があるためです（LVが中断され、オンラインに戻れないなど）。したがって、49.52Gの物理パーティションがある場合は、物理ボリュームサイズを49.51Gに設定する必要があります。

  • vi）PVが拡大されたので、VGで使用可能な空き領域があり、そのような空き領域をLVに割り当てることができます。そう...

  • vii）lvextendコマンドでLVを拡張できます。私の場合、（VG内の）空き領域の100％を割り当てることにした場合、次を使用しました：lvextend -l +100%FREE /dev/vg_raid/lv_raid

ほとんど完了しました。これで拡張LVができましたが、残念ながら、内部には「より小さな」ファイルシステムがまだあります。 EXT3またはEXT4に依存している場合は、resize2fsを使用できる可能性が高くなります。そのmanページから：

"resize2fsプログラムは、ext2、ext3、またはext4ファイルシステムのサイズを変更します。[...]ファイルシステムがマウントされている場合、カーネルがサポートしていると仮定すると、マウントされたファイルシステムのサイズを拡張するために使用できます。オンラインサイズ変更。」

Resize2fsがサイズ変更を完了するのにかかる時間は、複数の要因によって異なります。ファイルシステムのサイズとその上で実行されているI/Oアクティビティが最も重要です。

それで全部です。

繰り返しますが：上記のすべてを行う際は注意してください。何らかのリスクを冒していると少し思われる場合は、先に進まないでください！何か問題が発生しても、私を責めないでください。

3
Damiano Verzulli