AzureLinux云计算系统经验菜鸟

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)

LVM是Logical Volume Manager(逻辑卷管理)的简写,它是Linux环境下对磁盘分区进行管理的一种机制。目前在Microsoft Azure平台上使用的RedHat版本大多数默认都使用了LVM进行磁盘管理。虽然启用LVM将极大方便在On-Prem环境的磁盘管理,但是对于在Azure上的磁盘扩展将会造成更多的挑战。

通常你可以尝试将Disk扩展之后新建分区并将其纳入LVM中的PV,进而继续扩展LV。但这大多数客户依然想在Disk扩展之后保持原封不动的磁盘结构。在本文中就以后者的场景进行实验操作。

[本文由AndyX撰写,本文的“Azure Portal”门户界面以英文为主,仅供参考。]

[本人中所有涉及到 Azure 的实验均在 Azure Global 国际版中进行配置,部分功能可能在 Azure 世纪互联中受到限制]

[本文为AndyX.Net原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明!]

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图

 

初始化实验环境

平台镜像: Redhat 8.2 with LVM
系统磁盘: RHEL8-ResizeOSDisk_OsDisk_1_2e25efaa00014975836704441c659b17
磁盘类型: Premium SSD LRS, 64GB

 

实验目标

将原始的系统磁盘(OSDisk)从默认的64GB扩展至128GB,在此之后逐步扩展分区/LVM/文件系统,并最终保持磁盘结构不变。

 

思路清理

  1. 整个磁盘扩展应该按照“从外向内”的思维逐步扩展: 扩展磁盘(Disk)->分区(Partition)->LVM(扩展PV)->LVM(扩展LV)->文件系统(FileSystem)
  2. 由于无法在系统在线的情况下扩展系统磁盘(OSDisk)文件系统,因此需要使用搭建救援用(Rescue)VM的方法进行离线扩展,之后再使用SwapDisk功能将扩展完成的系统磁盘(OSDisk)切换到原始VM。
  3. 此方法同样适用于扩展带有LVM结构的数据磁盘(DataDisk)

 

先行警告

  1. 该操作方法有一定风险性,操作失误将可能会导致数据丢失,本文仅作实验环境测试。
  2. 如果您期望从生产环境的VM中扩展系统磁盘(OSDisk),请联系微软Azure技术支持以便获得更专业的帮助。
  3. 如果您确定要自己进行此类操作,请先执行系统磁盘(OSDisk)快照,以防万一。(本文中会有涉及)

 

详细操作

阶段一:准备阶段

1.将测试用的VM(原始VM)执行进行关机(Deallocate)操作。

(为了保持数据完整性,Azure会检测VM的状态,当处于运行状态时将会禁止对磁盘的变更操作)

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图1

2. 在Azure门户(portal)中进行系统磁盘扩展操作:

Azure门户 -> 虚拟机 -> 磁盘(选择OSDisk) -> 点击 “大小与性能” -> 修改 “自定义磁盘大小” 为128GB(或者从列表中选择128GB)

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图2

3. 创建一台救援用(Rescue)VM,并且使用不带LVM结构的镜像

  • 这是为了避免 LVM 名称冲突, 当然如果你已经创建了完全相同的带有LVM的救援用VM,请参考本文<故障排查>的2步骤;
  • 强烈建议使用相似系统版本或者系统内核的镜像(比如:如果原始系统使用了RHEL8,那么建议救援系统也适用RHEL8);
  • 根据之前的测试,由于RHEL8的内核4.x进行了完全升级,这将导致RHEL7的3.x内核无法正常识别RHEL8中的XFS文件系统。

 

3.1 在镜像市场中搜索关键字“RHEL”,并找到镜像“Red Hat Enterprise Linux Raw”

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图3

3.2 选择版本 “Red Hat Enterprise Linux 8.2 RAW with cloud-init GEN 1”,该版本具有普通磁盘结构。

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图4

 

阶段二:复制磁盘

1. 创建系统磁盘快照(snapshot),用于磁盘复制。

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图5

2. 从上一步的磁盘快照中创建新的磁盘,以便于复制这块系统磁盘(OSDisk)。

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图6

<***可选项: 其实你也可以在这一步修改磁盘大小,请参照下面的截图***>

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图7

3. 将这块复制的新的磁盘以数据磁盘(DataDisk)的方式附加至救援用(Rescue)VM。

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图8

 

阶段三:扩展分区以及LVM

登录到你的救援用(Rescue)VM, 开始运行如下命令:

1. 切换至root超级账户:

sudo -i

2. 准备相关工具, 需要安装以下工具包(如果已安装,请忽略该步骤):

dnf install lvm2 parted gdisk -y

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图9

3. 激活所有LVM卷,检查磁盘结构以及分区结构:

# 激活所有LVM卷
vgchange -ay

# 检查结构
lsblk

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图10
从以上截图中我们可以得知:

  • 当前复制的系统盘大小为 128GB
  • 当前分区2 (sdb2) 大小为 63GB
  • 对比LVM逻辑卷信息,似乎小于分区2 (sdb2) 大小,这意味着默认LVM逻辑卷并没有完全使用分区2 (sdb2),我们稍后讲解。
  • 下一步我们将根据之前的思路开始扩展分区2 (sdb2)到 128GB

 

4. 检查磁盘基本信息:

gdisk -l /dev/sdb

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图11

5. 检测到磁盘Secondary header异常,需要修正GPT磁盘的Secondary header信息:
(这是由于磁盘扩展后的末位地址与Secondary header记录位置不同导致的,需要进行修正)

gdisk /dev/sdb
Command: w
Do you want to proceed? Y

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图12

6. 将分区2(/dev/sdb2) 扩展至 128GB:

parted /dev/sdb
(parted) resizepart
Partition number? 2
End? [68.7GB]? 128G  <== 在这里选择128GB实际偏小,可以根据实际情况做最大化扩展。
(parted) p

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图13

7. 强制重新载入分区表,以便同步分区信息

partprobe

8. 验证分区变动:

lsblk

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图14
从以上截图中我们可以得知:

  • 分区/dev/sdb2 已经从 64GB 扩展至 118.2GB
  • 下一步我们将根据之前的思路开始扩展 LVM的PV以及LV

 

9. 检查LVM的PV以及VG状态:

pvdisplay
vgdisplay

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图15

从以上截图中我们可以验证之前提到的LVM逻辑卷并没有完全使用分区2 (sdb2)空间。

 

10. 开始扩展 LVM 的 PV:

pvresize /dev/sdb2

Physical volume "/dev/sdb2" changed
1 physical volume(s) resized or updated / 0 physical volume(s) not resized

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图16

11. 验证VM的PV以及VG的变更:

pvdisplay
vgdisplay

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图17

 

12. 开始扩展LVM的LV:

举例: 扩展rootvg-rootlv(以及其文件系统), 请执行以下命令:

##将LV扩展至所有剩余空间:
lvresize -r -l +100%FREE /dev/mapper/rootvg-rootlv

##指定LV扩展的大小(单位G/M/K):
lvresize -r -L +5G /dev/mapper/rootvg-rootlv

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图18

13. 最终验证分区以及LVM的变更:

lsblk

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图19

14. 在执行下一步之前,需要对文件系统进行双重检查,以便确认其可以正常挂载:

mkdir /test
mount /dev/mapper/rootvg-rootlv /test

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图20

15. 当所有验证操作都已经完成,需要手动的安全卸载并且将已经激活的LVM卷禁用:

umount /dev/mapper/rootvg-rootlv
vgchange -an

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图21

 

阶段四:将磁盘切换回原始VM

1. 将救援用(Rescue)VM进行关机(Deallocate), 并且分离数据磁盘(DataDisk)

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图22

2. 返回原始测试用VM, 点击磁盘的“交换OS磁盘(Swap OSDisk)”

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图23
微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图24
3. 将这台测试用VM开机,验证其是否可以正常启动,然后再验证磁盘分区以及文件系统是否已经扩展完成

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图25

 

故障排查

如果你已经创建了带有LVM的救援用(Rescue)VM,你可能会在执行vgchange -ay的时候遇到如下报错:

1. 症状:WARNING: PV nqwdS4-Gvs3-eccT-l4w6-e0fd-yFan-73oea9 prefers device /dev/sda2 because device is used by LV.

[root@RHEL8 ~]# vgchange -ay
  WARNING: Not using device /dev/sdc2 for PV nqwdS4-Gvs3-eccT-l4w6-e0fd-yFan-73oea9.
  WARNING: PV nqwdS4-Gvs3-eccT-l4w6-e0fd-yFan-73oea9 prefers device /dev/sda2 because device is used by LV.
  Cannot activate LVs in VG rootvg while PVs appear on duplicate devices.
  Cannot activate LVs in VG rootvg while PVs appear on duplicate devices.
  Cannot activate LVs in VG rootvg while PVs appear on duplicate devices.
  Cannot activate LVs in VG rootvg while PVs appear on duplicate devices.
  Cannot activate LVs in VG rootvg while PVs appear on duplicate devices.
  5 logical volume(s) in volume group "rootvg" now active

原因:

你创建了一个具有完全相同LVM结构的OS,这可能是从同一个Image中创建的VM,例如:RHEL8.2 -> RHEL8.2

解决:

请避免使用源自同一个镜像的Image来部署救援用VM,因为这会导致LVM中所有UUID都冲突。

 

2. 症状:device-mapper: create ioctl on rootvg-homelv xxxxxxxxxx failed: Device or resource busy

[root@RHEL8 ~]# vgchange -ay
  device-mapper: create ioctl on rootvg-tmplv LVM-NGC5rPBBtPjbezosh52uJgYVMaFDbcXC1O1Ahpg1l1W23jmfrWa6PJlumOBlPFOd failed: Device or resource busy
  device-mapper: create ioctl on rootvg-usrlv LVM-NGC5rPBBtPjbezosh52uJgYVMaFDbcXCjzJMnpl2DW4re4JfzI5GrbCIn9MlDx0Y failed: Device or resource busy
  device-mapper: create ioctl on rootvg-homelv LVM-NGC5rPBBtPjbezosh52uJgYVMaFDbcXCTC3fpel7M6JSJPFuJLRcsNZA7zixaWqW failed: Device or resource busy
  device-mapper: create ioctl on rootvg-varlv LVM-NGC5rPBBtPjbezosh52uJgYVMaFDbcXC0NqimpgbXtm0c3cQxQsandTATiij89Iy failed: Device or resource busy
  device-mapper: create ioctl on rootvg-rootlv LVM-NGC5rPBBtPjbezosh52uJgYVMaFDbcXCrPTVU6qKfSHGeKdBDF6YLFJ4qkqvdcum failed: Device or resource busy
  0 logical volume(s) in volume group "rootvg" now active
  5 logical volume(s) in volume group "rootvg" now active

原因:

这是因为使用类似Image部署的OS可能会具有相同的LVM结构/名称(但是UUID不同),当进行激活LVM的时候就会发生重名冲突。

此时你需要将Rescue所在的vg改名,以便确保DataDisk中的LVM卷可以被正常挂载(请注意,Rescue VM中的LVM改名之后请不要重启,否则将会造成启动失败)。

解决:

1. 检查磁盘结构以便确保uuid不同:

lsblk

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图26

2. 检查LVM中的VG所属的UUID:

vgdisplay

微软Azure云 IAAS故障排除与实战101:扩展含有LVM结构的OS系统磁盘(RHEL8.2)插图27

3. 更改Rescue VM所在系统分区的VG UUID:

# 使用方法:
vgrename  VG-UUID  NEW-VGNAME


# 本次案例中:
[root@RHEL8 ~]# vgrename NGC5rP-BBtP-jbez-osh5-2uJg-YVMa-FDbcXC andyx
Processing VG rootvg because of matching UUID NGC5rP-BBtP-jbez-osh5-2uJg-YVMa-FDbcXC
Volume group "NGC5rP-BBtP-jbez-osh5-2uJg-YVMa-FDbcXC" successfully renamed to "andyx"

4. 再次尝试激活所有LVM卷:

[root@RHEL8 ~]# vgchange -ay
  5 logical volume(s) in volume group "andyx" now active
  5 logical volume(s) in volume group "rootvg" now active

 

(END)

 

参考文献

文章撰写:作者AndyX,来自AndyX.Net。技术指导Ken,来自Microsoft。

文章遵循 CC 4.0 BY-SA 版权协议,若需转载本文,请标注来源与链接:原创内容AndyX.Net版权所有

https://andyx.net/azurelab_101_expand_the_lvm_linux_osdisk_on_azure_rhel8/