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

背景

我们有个项目部署在政务云上,有一个服务器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命令就能看到效果了。

经验

  1. 执行命令前,应该先充分了解命令执行后会发生什么;
  2. 对于可能会造成删库跑路的操作,应该先要在测试环境试验,切莫直接在生产环境上操作。