web-dev-qa-db-ja.com

ボリューム管理：あるパーティションから別のパーティションにスペースを移動する方法は？

Redhat ec2インスタンスを設定しています。デフォルトで、使用しているソフトウェア（ qradar と呼ばれます）は、インスタンスに接続された2つの500g ebsストレージデバイスに次のボリュームを作成しました。

$ lvs
  LV        VG        Attr       LSize    Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  storetmp  rootrhel  -wi-ao----   20.00g                                                    
  varlog    rootrhel  -wi-ao----  <20.00g                                                    
  store     storerhel -wi-ao---- <348.80g                                                    
  transient storerhel -wi-ao----  <87.20g 

$ df -h
Filesystem                       Size  Used Avail Use% Mounted on
/dev/xvda2                       500G  1.4G  499G   1% /
devtmpfs                          16G     0   16G   0% /dev
tmpfs                             16G     0   16G   0% /dev/shm
tmpfs                             16G   17M   16G   1% /run
tmpfs                             16G     0   16G   0% /sys/fs/cgroup
/dev/mapper/storerhel-store      349G   33M  349G   1% /store
/dev/mapper/storerhel-transient   88G   33M   88G   1% /transient
/dev/mapper/rootrhel-storetmp     20G   33M   20G   1% /storetmp
/dev/mapper/rootrhel-varlog       20G   35M   20G   1% /var/log
tmpfs                            3.2G     0  3.2G   0% /run/user/1000

storetmpを100gにする必要があります。 80gのストレージをstoreからstoretmpに移動するにはどうすればよいですか？

また、一部のスペースをxvdb3からxvdb2にシフトする必要があるようです。

# lsblk
NAME                    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
xvda                    202:0    0   500G  0 disk 
├─xvda1                 202:1    0     1M  0 part 
└─xvda2                 202:2    0   500G  0 part /
xvdb                    202:16   0   500G  0 disk 
├─xvdb1                 202:17   0    24G  0 part [SWAP]
├─xvdb2                 202:18   0    40G  0 part 
│ ├─rootrhel-varlog     253:2    0    20G  0 lvm  /var/log
│ └─rootrhel-storetmp   253:3    0    20G  0 lvm  /storetmp
└─xvdb3                 202:19   0   436G  0 part 
  ├─storerhel-store     253:0    0 348.8G  0 lvm  /store
  └─storerhel-transient 253:1    0  87.2G  0 lvm  /transient

ディレクトリは現在、ボックスで実行されているソフトウェアによって使用されており、空ではないため、それらを削除することは問題外であり、オンザフライで実行する必要があります。

$ ls -l /dev/mapper/storerhel-transient
lrwxrwxrwx 1 root root 7 Aug 10 16:00 /dev/mapper/storerhel-transient -> ../dm-3
$ ls -l /dev/mapper/rootrhel-varlog 
lrwxrwxrwx 1 root root 7 Aug 10 16:00 /dev/mapper/rootrhel-varlog -> ../dm-0
$ ls -l /dev/mapper/storerhel-store 
lrwxrwxrwx 1 root root 7 Aug 17 04:10 /dev/mapper/storerhel-store -> ../dm-2
linuxstoragerhelvolume
7
Alex Cohen

EC2 EBSで80 GBを追加すると、1か月あたり$ 12未満になります。オンラインでの操作には1時間以上かかることが多く、何か問題が発生した場合のダウンタイムのリスクがあります。どれだけの価値がありますか？

追加の容量を支払い、インスタンスに3番目のディスクxvdcとして追加し、LVM PVとして初期化します（パーティションテーブルを配置する必要さえありません。pvcreate /dev/xvdcは十分です）。次に、新しいPVをrootrhel VG（vgextend rootrhel /dev/xvdc）に追加すると、追加した容量で/storetmpを拡張できます。

lvextend -L +80G /dev/mapper/rootrhel-storetmp
xfs_growfs /storetmp  #or the appropriate tool for your filesystem type

差し迫った問題が解決したら、適切な時間にダウンタイムをスケジュールできます。

XFSファイルシステムを使用している場合（RHEL/CentOS 7はデフォルトで使用されます）、次にスケジュールされたダウンタイム中に、/storeおよび/transientの現在の内容のtarballを作成し、アンマウントして削除しますstorerhel VG全体、PV xvdb3をrootrhel VGに追加してから、/storeおよび/transientファイルシステムのLVを、より現実的な推定値を使用して再作成します。容量が必要であり、tarballの内容を復元します。ダウンタイムの終わり。

これで、あなたのrootrhel VGには、xvdb2、xvdb3とxvdcの3つのPVがあり、ニーズに合わせて十分なスペースがあります。

xvdcの支払いを停止する場合は、pvmove /dev/xvdcを使用して、VG内のデータをxvdcからxvdb2内の未割り当てスペースに自動的に移行できます。またはxvdb3。これはオンラインで行うことができます。パフォーマンスへの影響を回避するために、I/Oワークロードのピーク時には行わないでください。次に、vgreduce rootrhel /dev/xvdc、echo 1 > /sys/block/xvdc/device/deleteを使用して、xvdcデバイスが廃止されることをカーネルに通知し、Amazonにxvdcディスクが不要になったことを通知します。

LVMディスクストレージでの作業には20年近くの経験があります（最初はHP-UX LVMで、後でエンタープライズ環境で使用できるように十分成熟した後はLinux LVMで）。これらは、私がLVMで使用するようになった経験則です。

  • 1つで十分な場合は、2つのVGを作成しないでください。

特に、1つのディスク上に2つのVGがあることは、頭痛の種となる間違いです。 VG内のディスク容量の再割り当ては、ファイルシステムのタイプが許す限り柔軟です。既存のPVの1つよりも小さいチャンクでVG間で容量を移動することは、通常、面倒な価値はありません。

  • ディスク領域の要件に不確実性がある場合（そして常に存在する場合）、LVを小さい側に、いくつかの未割り当て領域を確保してください。

VGに未割り当ての容量がある限り、1つまたは2つのクイックコマンドを使用して、必要に応じてオンラインでLVとファイルシステムを拡張できます。それは1バナナの仕事です 訓練された猿 ジュニアsysadmin。

VGに未割り当ての容量がない場合は、新しいディスクを取得し、新しいPVとして初期化して、容量を必要とするVGに追加し、通常どおりに拡張を続行します。ファイルシステムの種類によっては、ファイルシステムを縮小するとエラーが発生しやすくなり、ダウンタイムが必要になったり、ファイルシステムをより小さいサイズでバックアップおよび再作成しないと不可能になる場合があります。したがって、ファイルシステムをオンラインで縮小する必要がある状況はできるだけ避けたいでしょう。

  • ディスク領域のマイクロ管理はリスクを伴う可能性があり、多くの作業です。仕事は高いです。

はい。技術的には、あなたができます/store、losetupに80 GBのファイルを作成し、それをループデバイスにしてから、 rootrhel VGに追加できるPV ...しかし、そうすると、これらのファイルシステム用にカスタマイズされた起動スクリプトを設定しない限り、起動時にシステムがシングルユーザーリカバリモードに陥る可能性が高くなります。とVGで、初めて正しく表示されました

それを誤解して、次に何らかの理由でシステムが再起動されたときに、トラブルシューティングと修正のために計画外のダウンタイムをとる必要があります。あるいは、トラブルシューティングを試みるよりも簡単なので、ファイルシステムを最初から再作成し、バックアップから内容を復元する必要があります。この陪審員が仕掛けた混乱。

または、オンラインで縮小できるext4ファイルシステムを使用している場合は、/storeファイルシステムを縮小し、LVを縮小し、pvmove --alloc anywhereを使用して空き領域を末尾に統合することができます。 xvdb3 PV、PVの縮小、パーティションの縮小、partprobeを実行して再起動なしで変更を有効にし、新しいパーティションxvdb4を作成して、新しいPVとして初期化し、 rootrhel VGに追加...

ただし、このシーケンスで1つの間違いを犯してファイルシステム/ PVがLV /パーティションコンテナーを超えて拡張され、ファイルシステムが読み取り専用モードに切り替わった場合、ファイルシステムチェックを実行することによってのみリセットできるエラーフラグが発生し、結果として計画外の必須ダウンタイム。

3
telcoM