Linux

使用物理範圍和 pvresize 擴展 LVM 卷組

  • June 1, 2015

關於擴展 LVM 託管卷,我有兩個有點相關的 LVM 問題。

首先,從(編輯:)我讀過的關於 LVM 以及卷組和物理範圍之間的關係的文件中,如果你想將 VG 增加到超過 256GB,你必須有一個大於 4MB 的 PE 大小。本文中的一個範例顯示了一條消息“最大邏輯卷大小為 255.99 Gigabyte ”,PE 為 4MB。但是,我希望這意味著如果 PE 大小為 4MB,VG 將不允許您在其中定義/添加超過 256GB 的捲,並且如果您嘗試它會引發錯誤或至少是警告。我提出這個是因為我有一個虛擬機,它顯示了它的一個卷組(摘錄):

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 由兩個物理卷組成,一個是 100GB (/dev/sda2),另一個是 400GB (/dev/sda3)。我怎麼可能成功地(?)在這個 VG 中定義了 500GB 的空間,而 PE 大小只有 4MB?我還沒有進行實際測試來嘗試填充已安裝的邏輯卷以查看我是否確實可以儲存 500GB,但除非 LVM 的操作方式發生了變化,否則邏輯卷將在達到 256GB 時“停止寫入”數據儘管顯示剩餘 244GB,但已使用空間?我可以成功地將 VG 的 PE 大小(就地)更改為 8MB 嗎?

其次,如果我希望擴展 LVM 分區/物理卷以增長以利用增加的空間,當我增加 vmdk 硬碟驅動器大小時,而不是創建新的物理卷並將其添加到 VG(正如這篇優秀的文章所涵蓋的 VMWare ) 那麼我會使用pvresize嗎?我的限制是不破壞任何現有數據並簡單地向卷中添加空間,VMWare 知識庫文章完成了這一點,而在閱讀這個 SE 問題後,我對您是否可以僅擴展卷或是否必須“刪除和創造一個更大的”。

由於 VMWare 文章依賴於添加主分區的能力,因此您顯然只能按照該過程最多 4 個主分區,之後您要麼不能再增加卷,要麼我假設您必須使用類似 pvresize 的東西(我不知道如何正確使用/因為害怕破壞現有數據而猶豫嘗試)。關於 pvresize 是否可以做我正在尋找的任何指示?

回答第一個問題

請考慮您基於所有考慮的文章非常過時!儘管您連結的 HOWTO 頁面中沒有報告明確的日期,但查看與提到的 HOWTO 相關的程式碼,您可以看到它指的是核心 2.3.99,可以追溯到 2000 年!15年前!

這完全符合我的直接經驗,我完全沒有問題,擁有 4MB PE 的多 TB PV。下面是一個正在執行的系統的輸出:一個 RAID5 VG (vg_raid) 建構在 5 x 2TB S-ATA 磁碟之上並為單個 7.28 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

回答第二個問題

你說:“ ……我懷疑……你是否可以僅僅擴展卷,或者你是否必須“刪除並創建一個更大的……

讓我們澄清一些初步概念:

  1. 假設您處於正常情況下:您有一個帶有通用 msdos 分區的 HDD。因此,您最多有 4 個主分區;
  2. 假設您的 LVM 物理卷定義在上述 4 個主分區之一的頂部,並且此類 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 中提到的相同設備),在您的情況下,這樣的設備是一個主分區(在我的情況下是 /dev/sda2,上面)

所以:

  1. 在您的情況下,擴大文件系統所需的步驟是:

i) 通過在磁碟末尾添加“未分區空間”來擴大物理磁碟;

ii) 讓 LVM 選擇使用這種未分區的空間。這可以通過兩種不同的模式實現:

iii/1) 擴大 LVM-type-8e 分區,使其在磁碟的新端結束(這只有在現有分區是磁碟上的最後一個分區時才有可能。因此上述第 2 點的要求)

iii/2) 將未分區的空間分配給新的主分區,分配類型為 8e。這將是一個新的 LVM-Physical_Volume,用於擴大 Volume_Group;

由於您似乎對第 iii/1 點感興趣,我將重點關注它。那麼……如何擴大現有的主分區

警告!:這將是有風險的!確保您有適當的數據備份,以及適當的災難恢復計劃。如果您不了解您正在執行的風險,請不要繼續!

答案很簡單。由於磁碟分區表中的 START_CYLINDER 和 END_CYLINDER 引用了主分區,因此您只需修改 END_CYLINDER。可以使用“fdisk -lu /dev/sda”檢索 START 和 END 柱面的目前值,如下所示:

[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並結束於3904294911。現在,您可以簡單地刪除 /dev/sda2 分區並創建一個新分區,從 1026048 開始,到… 擴大驅動器的新端結束。不要忘記將類型 8e 分配給此類分區,並且顯然不要忘記保存更改。如果你對這個過程不“舒服”——因為它有風險——你唯一的選擇是 iii/2

  • iv) 現在你有一個擴大的分區,你必須說服你的作業系統重新載入分區表。在你提到的SF問題中,有很多細節。作為最壞的情況,您將需要重新啟動伺服器
  • v) 現在你有一個擴大的分區,並且它被作業系統正確辨識,你有一個新問題:你有一個 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 。就我而言,我決定分配 100% 的可用空間(在 VG 中),我使用了:lvextend -l +100%FREE /dev/vg_raid/lv_raid

我們已經完成了大部分。現在我們有了一個擴展的 LV,不幸的是,它內部仍然有一個“更小”的文件系統。如果您依賴 EXT3 或 EXT4,您可以使用resize2fs的機會很高。從它的手冊頁:

" resize2fs 程序將調整 ext2、ext3 或 ext4 文件系統的大小。$$ … $$如果文件系統被掛載,它可以用來擴展掛載文件系統的大小,假設核心支持線上調整大小。"

resize2fs 完成調整大小所需的時間取決於多個因素:文件系統的大小和在其上執行的 I/O 活動是最重要的因素。

就這樣。

再說一遍:**在做上述所有事情時要小心,如果你覺得自己有任何風險,請不要繼續!**萬一出事了別怪我!

引用自:https://serverfault.com/questions/695902