一次政务云生产环境的磁盘热扩容过程

背景

我们有个项目部署在政务云上，有一个服务器400GB的数据盘最近经常空间爆满，虽然增加了定时清理缓存的crontab脚本，但是随着空间使用的增长，问题并没有解决。

这个400GB的数据盘，后来政务云给扩展成了900GB，但是之前同事没注意验证，导致新增的500GB磁盘并没有挂载进去，只是挂载在那里：

lsblk命令可以看到vdb共有900GB，但是只有vdb1的400GB挂载到了/data目录，使用df -h命令也可以看到这个挂载的/data目录，而且空间很紧张。

如果一开始就操作扩容是比较简单的，但是现在数据已经有几百GB了，潜意识中总感觉这种扩容感觉是很危险的，很容易变成了删库跑路的节奏，把整个数据全丢了，而这个服务器又没有其他的空间可以备份这些数据，连打包下载的空间都没有，而且就政务云这网络，下载下来可能得五六天，线上服务是不可能停机那么久的。

还有一点拖着不去扩容的原因是，这个扩容只能放到深夜没人用的时候去进行。。。

把内网一个服务器搞废的过程

下面是政务云搞网络的人给的操作步骤：

原磁盘扩容（参考）：（不支持Windows系统）

1、确认磁盘设备已经扩容

[root@localhost ~]# lsblk

2、按需卸载磁盘

[root@localhost ~]# umount /homework

3、检查磁盘分区文件系统的正确性

[root@localhost ~]# e2fsck -f /dev/vdb1

4、执行扩容操作

[root@localhost ~]# growpart /dev/vdb1 将第n分区进行扩容，未安装请执行yum install cloud-utils-growpart

5、挂载磁盘

[root@localhost ~]# mount /homework

6、查看磁盘类型 FSTYPE

[root@localhost ~]# lsblk -f

7、扩展文件系统大小

[root@localhost ~]# xfs_growfs /home 扩展文件系统大小，对于xfs文件系统

[root@localhost ~]# resize2fs /home 扩展文件系统大小，对于ext2、ext3或ext4文件系统

操作系统格式：MBR支持的磁盘最大容量为2 TB，GPT最大支持的磁盘容量为18 EB，因此当您初始化容量大于2 TB的磁盘时，分区形式请采用GPT。对于Linux操作系统而言，当磁盘分区形式选用GPT时，fdisk分区工具将无法使用，需要采用parted工具。

查了growpart，是一个热扩容工具，看起来挺适合解决我们现在这个问题的，但是毕竟没操作过，没用过，心里不踏实。

于是在内网找了一个服务器做测试，就照着上面的步骤进行操作。先卸载磁盘，然后执行e2fsck，执行这一步的时候，感觉不太妙，赶紧把这个盘挂载回来看看，糟糕，旧数据都被清空了。。。

还好，这只是内网的一个服务器。

正确的道路

重新查了growpart这个工具的工作原理，发现原来对这个工具有点误解，发现这个扩容是基于磁盘原有的空间进行扩容，例如这个磁盘本来有900GB，但是只分配了400GB，这是可以扩容的，但是并不是用另一个磁盘的空间来给这个磁盘扩容。

实际上，特别简单，只要执行一个命令即可：

代码语言：javascript

复制

growpart /dev/vdb 1

这时再执行：

代码语言：javascript

复制

resize2fs /dev/vdb1

这样两个命令就能完成操作，用df命令就能看到效果了。

经验