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

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

私はRedhat EC2インスタンスを設定しており、デフォルトで私が使用しているソフトウェア(グレダ)インスタンスに接続されている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

100グラムが必要ですstoretmp。 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

ベストアンサー1

EC2 EBSの追加80GBの費用は月12ドル未満です。オンラインで作業すると、作業時間が1時間以上かかることがあり、問題が発生した場合にダウンタイムが発生するリスクがあります。これはあなたにとってどれほど価値がありますか?

追加容量の費用を支払い、インスタンスに3番目のディスクとして追加し、xvdcLVM PVに初期化します(パーティションテーブルを配置する必要はありません。これでpvcreate /dev/xvdc十分です)。その後、新しいPVをrootrhelVG(vgextend rootrhel /dev/xvdc)に追加すると、追加/storetmpした容量を使用してVGを拡張できるようになりました。

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

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

/storeXFSファイルシステム(RHEL / CentOS 7はデフォルトでこれを実行します)を使用している場合は、次の計画中断中に現在のコンテンツのタールボールを作成し、VG全体をマウント解除および削除し、/transientそのstorerhelPVをVGxvdb3に追加してrootrhelLV/storeおよび/transientファイルシステムを再作成してtarballの内容を復元するには、より現実的な容量要件の見積もりを使用してください。ダウンタイムが終了しました。

VGには、、、rootrhelおよびの3つのPVがあり、必要なスペースが十分です。xvdb2xvdb3xvdc

支払いを中止するには、VGの未割り当て領域からVGの内部および/またはVGへ、および/またはVGのデータ自動移行をxvdc使用できます。これはオンラインで行うことができます。パフォーマンスへの影響を避けるために、最大I / Oワークロードの間は実行しないでください。その後、デバイスが消えるとカーネルに通知し、Amazonにディスクが不要になったことを通知します。pvmove /dev/xvdcxvdcxvdb2xvdb3vgreduce rootrhel /dev/xvdcecho 1 > /sys/block/xvdc/device/deletexvdcxvdc

私はほぼ20年間LVMディスクリポジトリを使用してきました(最初はHP-UX LVMを使用し、後でエンタープライズ環境で使用するのに十分な成熟したLinux LVMを使用)。 LVM が使用する経験的ルールは次のとおりです。

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

特に、1 つのディスクに 2 つの VG があると、面倒なことになります。 VG内でディスク容量を再割り当てする柔軟性は、ファイルシステムの種類が許可する程度によって異なります。従来のPVよりも小さいブロックでVG間で容量を移動することは通常問題ではありません。

  • ディスク容量の要件がわからない場合(常に存在する場合)、LVを小さく保ち、未割り当て領域を残します。

VGに割り当てられていない空き容量がある限り、必要に応じて1つまたは2つのクイックコマンドを使用してLVとファイルシステムをオンラインで拡張できます。訓練された猿ジュニアシステム管理者にとって、これはただのバナナの仕事に過ぎません。

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

  • ディスク容量を細かく管理するのは危険で作業量が多い場合があります。作業コストがかかります。

わかりました技術的にはできるPVに80GBのファイルを作成し、/storeそれをlosetupループデバイスに挿入し、PVに追加できるVGのPVに挿入しますrootrhel。ただし、これを行うと、システムがシングルユーザー回復に入る可能性が高くなります。これらのファイルシステムとVGにカスタム起動スクリプトを設定しない限り、起動モードでそして最初からしっかりしてみてください。

問題が発生した場合は、次に何らかの理由でシステムを再起動するときに、計画外のダウンタイムをかけて問題を解決して修復する必要があります。または、より現実的には、ファイルシステムを最初から再作成し、バックアップから内容を復元する必要があります。なぜなら、試すよりも簡単だからです。この即興的な混乱を解決するために

ext4またはオンラインで縮小できるファイルシステムを使用している場合は、/storeファイルシステムの縮小(Shrink LV)を使用してpvmove --alloc anywhere空き領域をPVの尾にマージしxvdb3、Shrink PV、Shrinkパーティションを実行してpartprobe変更を適用せずに適用できます。あります。再起動して新しいパーティションを作成し、xvdb4それを新しいPVに初期化してからrootrhelVGに追加します。

ただし、この順序で間違えてファイルシステム/PVがLV/パーティションコンテナを超え、ファイルシステムがファイルシステムチェックを実行しなければリセットできないというエラーフラグで読み取り専用モードに切り替えると、これは計画外の強制ダウンタイムが発生します。

おすすめ記事