1. 项目概述与核心需求解析1.1 这个项目解决了什么问题云服务器用久了最让人头疼的问题是什么不是性能不够也不是网络不稳定而是磁盘空间不够用了。这次做的是火山引擎云服务器ECS的磁盘挂载与扩容全流程实操覆盖Linux和Windows两种主流操作系统处理对象包括系统盘和数据盘两种磁盘类型。整个项目解决的核心痛点非常明确新购买的数据盘怎么挂载才能用系统盘满了怎么安全扩容数据盘空间不够怎么无损扩容云服务器和物理服务器最大的区别在于磁盘是虚拟化出来的不能像物理机那样直接插一块新硬盘就能识别。数据盘需要经过购买、挂载、分区、格式化、挂载到目录这一整套流程才能写入文件任何一个环节没做对磁盘都用不上。而扩容则更讲究系统盘不能直接扩容数据盘扩容后要刷新文件系统大小顺序错了或者步骤少了轻则扩容无效重则数据丢失。这篇文章适合的人群很明确正在使用或者准备使用火山引擎云服务器的人尤其是那些经历过磁盘满了但不知道怎么扩容、买了数据盘但mount不上等问题的开发者。不管你是刚上手云服务器的新手还是已经玩了一段时间但对磁盘这一块不太熟悉的运维应该都能在这篇实操指南里找到对应自己场景的解法。1.2 涉及的关键技术点把项目拆开来看涉及的技术点主要有几个方面磁盘挂载Linux下分区格式化挂载目录的操作Windows下的磁盘初始化和新建卷文件系统扩容针对ext4、xfs[Linux] 主流文件系统的在线扩容操作以及Windows下的卷扩展系统盘扩容通过控制台或整机镜像方式处理系统盘容量不足的问题数据盘扩容云盘扩容后在系统内部刷新文件系统大小的完整流程分区表处理MBR和GPT两种分区表类型的差异及对应工具选择关键配置文件/etc/fstab自动挂载配置防止重启后挂载失效整个项目做完之后我对云磁盘的整个生命周期有了更完整的认识从购买、挂载、使用到容量不足时的扩容再到最后的迁移备份每一个环节都有自己的坑。接下来我把整个操作过程按照实际执行顺序拆解给大家。2. 方案选型为什么这样设计操作路径2.1 Linux的挂载方案选择关于Linux环境下新数据盘的挂载有两种常见方案一种是直接格式化整个磁盘并挂载另一种是先分区再格式化再挂载。我选的是第二种先分区后格式化。原因很简单分区之后再扩容操作空间更大。如果直接把整个磁盘做成文件系统后面想再拆分分区就非常麻烦。而且现在的云硬盘默认都是GPT分区表最大支持的分区数远多于MBR先分区再格式化的方案几乎没有任何额外成本。格式化的文件系统类型我选了ext4。虽然xfs在大文件和大容量场景下有性能优势但ext4的支持最广泛在火山引擎的CentOS、Ubuntu系统上兼容性最好而且resize2fs扩容工具比xfs的xfs_growfs用起来更顺手。2.2 Linux的扩容方案选择数据盘扩容有两种路径一种是在控制台扩容云盘容量后在实例内部刷新文件系统另一种是新建一块更大的云盘把数据迁移过去。第一种是常规路径。控制台把云盘从100G扩容到200G之后云盘暴露给操作系统的块设备大小也会变化但文件系统大小不会自动跟着变化需要在系统内部自己更新分区表和文件系统信息。这就是growpart和resize2fs/xfs_growfs组合要做的事。第二种属于迁移方案适用于没有做LVM逻辑卷管理的情况。说实话如果一开始规划得当把数据盘做成LVM扩容根本不需要动分区表直接给逻辑卷扩容就行。但既然大多数人的云服务器都直接用了裸设备分区那就把直接扩容的路径搞清楚。两种方法的核心原则一样先让内核识别新的块设备大小再更新分区大小最后刷新文件系统大小。2.3 系统盘扩容的两种路径系统盘扩容在火山引擎上有个特殊限制系统盘不能直接在控制台扩容。这跟很多其他云厂商的操作习惯不太一样。系统盘容量不足时有两件事可以做一是通过实例操作里的更换云盘/操作系统功能在更换系统时选择更大的系统盘容量。这种方式适合还没怎么使用、数据量不大的场景本质上是重置系统。二是通过实例快照方案先给现有实例做快照再用快照创建一台配置更高的新实例选择更大的系统盘验证业务正常后切换流量。这种方式适合存量业务的系统盘扩容风险可控但步骤多、时间长。考虑到这篇文章谈的是全流程实操我按实际场景把它们拆开存量业务系统盘扩容走快照换机方案新业务规划则直接用足够大的系统盘起步。2.4 Windows方案的侧重点Windows系统的磁盘管理和Linux完全是两套逻辑。新手最常见的坑是数据盘挂载上了但在此电脑里看不到。这通常是因为磁盘处于未分配状态需要先初始化磁盘再新建简单卷。Windows磁盘管理的理解成本比Linux低图形界面点几下就能搞定但Windows挂在分区表、动态磁盘和GPT分区这些概念上的坑一点不比Linux少。比如超过2T的磁盘必须用GPT分区表动态磁盘转换后不能直接装回基础磁盘删除卷就丢数据等等。这些在实操部分我会详细展开。选择这些方案综合考量下来核心原则就一个用尽可能少的步骤、尽可能小的风险把磁盘用起来或者把容量扩上去。不搞花哨的操作每一步都有明确的目的出了问题也能很快定位到是哪一步造成的。3. Linux数据盘挂载与扩容实操3.1 数据盘挂载完整流程3.1.1 第一步确认磁盘是否已被系统识别控制台购买数据盘并挂载到实例后先登录服务器用lsblk查看块设备列表lsblk正常情况下你会看到类似下面的输出NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 253:0 0 40G 0 disk └─vda1 253:1 0 40G 0 part / vdb 253:16 0 100G 0 disk其中vda是系统盘40Gvdb就是新挂载的数据盘100G目前没有任何分区。如果看不到vdb大概率是控制台的挂载操作没有完成或者型号不匹配导致实例无法识别先去控制台确认挂载状态。有一个细节要注意部分较老的内核可能需要重启实例才能识别新挂载的云盘。不过火山引擎的虚拟化驱动比较新绝大多数情况下lsblk和fdisk -l都能直接看到新磁盘。3.1.2 第二步分区用fdisk或者parted对新磁盘分区。这里我用的partedparted /dev/vdb mklabel gpt mkpart primary 0% 100% print quit或者用更传统的fdisk方式fdisk /dev/vdb n p 1 回车默认起始扇区 回车默认结束扇区 w执行完之后再确认一下lsblk这时候应该能看到vdb1这个分区了。分区完成后内核不一定立即识别新分区用下面的命令让内核重新读取分区表partprobe /dev/vdb3.1.3 第三步格式化文件系统mkfs.ext4 /dev/vdb1如果是xfs用mkfs.xfs /dev/vdb1格式化的过程看起来就是刷刷刷的进度条几秒钟就完事。这里有个很多人不知道的细节格式化之后一定要用blkid记录下分区的UUID后面写/etc/fstab的时候用UUID比用设备名/dev/vdb1更可靠因为设备名在重启后可能发生变化而UUID是唯一的。blkid /dev/vdb1输出类似/dev/vdb1: UUID3f7e6c1d-9b3e-4e5a-9479-ddb71f9f2a1e TYPEext43.1.4 第四步挂载到目录mkdir -p /data mount /dev/vdb1 /data挂载后确认一下df -h /data看到类似下面的输出就说明挂载成功Filesystem Size Used Avail Use% Mounted on /dev/vdb1 98G 60M 93G 1% /data3.1.5 第五步配置开机自动挂载关键中的关键手动挂载只在当前会话有效重启之后挂载关系就没了。所以必须写进/etc/fstabecho UUID3f7e6c1d-9b3e-4e5a-9479-ddb71f9f2a1e /data ext4 defaults 0 2 /etc/fstab写完以后务必执行一次验证mount -a如果没有任何报错说明fstab配置正确。这一步不能省略因为fstab写错了会导致服务器重启后起不来非常难受。更稳妥的做法是直接重启一次实例验证确认开机后/data能自动挂载上再投入使用。注意这里有个常见的野路子操作很多教程会直接写/dev/vdb1 /data ext4 defaults 0 2不推荐这么干。设备名不固定重启后可能从vdb变成vdc挂载关系就乱了。用UUID才是规范的写法。3.2 数据盘扩容完整流程这里的场景是数据盘100G已经用了80G控制台把云盘扩容到了200G现在要把这多出来的100G在系统里用起来。3.2.1 第一步确认内核是否已经识别新容量lsblk fdisk -l /dev/vdb如果显示的还是100G先试试让内核重新读取partprobe /dev/vdb有些情况下需要重启实例才能让块设备大小刷新。不过通常云平台在控制台扩容后实例内部会实时看到新容量我的实测中这一步一般是同步的。3.2.2 第二步扩容分区这里用growpart来扩展分区。如果系统没有装先安装yum install cloud-utils-growpart # CentOS apt install cloud-guest-utils # Ubuntu然后扩容分区growpart /dev/vdb 1这个命令的意思是把/dev/vdb的第1个分区扩展到整块磁盘的末尾。执行成功后再用lsblk看vdb1应该从原来的100G变成200G了。如果没有growpart工具也可以用parted手动操作但growpart更简单也更安全它知道哪些情况下不能动比如分区表类型不支持时推荐优先用。3.2.3 第三步刷新文件系统大小分区变大了文件系统大小也得跟着扩否则多出来的空间还是看不到。ext4文件系统resize2fs /dev/vdb1xfs文件系统xfs_growfs /data注意两者的区别resize2fs后面跟的是设备路径xfs_growfs后面跟的是挂载点。xfs文件系统必须挂载后才能在线扩容ext4在线扩容没问题这也是我前面说的生产环境选ext4更省心的原因之一。执行完后再看df -h /data这时候应该能看到200G了。3.2.4 扩容是否会影响正在运行的服务正常情况下来讲在线扩容分区表和文件系统不会影响正在运行的进程。我实操的时候数据盘上跑着几个Java应用扩容过程中服务完全没中断内存占用和日志输出都没有异常。但有一点必须提前做扩容前给重要数据做快照或备份。云盘扩容本身风险不算高但只要是涉及分区表的变更都是磁盘层面的事一旦断电或者操作失误数据恢复的代价远高于事先做快照的代价。生产环境任何时候不要裸奔操作。3.3 系统盘扩容实操快照换机方案这里说一下存量系统盘容量不足的处理流程我按实际操作的顺序来写3.3.1 第一步创建实例快照登录控制台找到当前实例选择创建快照最好在业务低峰期操作。创建快照的时间取决于系统盘大小40G的盘一般几分钟就能完成。这一步关键点是快照创建完成之前不要动实例的任何状态不要升级配置、不要装大软件、不要改系统设置。快照代表的是整个磁盘某一时刻的完整状态如果它创建的前后有大量写入即便快照本身是做出来了也无法保证数据的一致性和完整性的。3.3.2 第二步用快照创建新实例并扩大系统盘快照创建完成后用快照-创建实例操作选择新的实例规格和更大的系统盘容量比如原来40G这次直接选到80G甚至100G。系统盘扩容的限制是容量选择必须大于当前系统盘实际使用量。比如系统盘用了35G最低也要选大于35G的规格否则创建会失败。新实例创建成功后登录验证系统盘分区确实变大了。由于系统盘通常采用LVM或根分区直接扩容的方式进入系统后可能需要额外执行一次根分区的growpart和resize2fs才能完全使用新容量growpart /dev/vda 1 resize2fs /dev/vda1如果不执行这两步df -h里面看到的根分区容量仍然是旧规格的值白白多花钱。3.3.3 第三步验证并切换流量先在新实例上做一轮全面验证网络是否正常应用能否启动数据库能否连接日志是否报错。验证通过后把原来实例的弹性IP解绑绑到新实例上或者在负载均衡如应用接入了LB里把后端实例切换为新实例。确认业务正常后旧实例就可以停掉或释放了。这套流程的风险点集中在数据一致性上。如果快照不是在业务低峰期做的数据库类应用可能会出现数据文件一致性问题。解决办法是有自建数据库就先停写、flush tables with read lock或者用云数据库RDS这类托管服务不要自建数据库跑在按快照迁移的路径上。4. Windows数据盘挂载与扩容实操4.1 磁盘初始化和挂载的完整流程4.1.1 第一步打开磁盘管理登录Windows实例后右键此电脑选择管理在左侧导航进入磁盘管理。或者直接用快捷键Win X选磁盘管理。打开后正常情况下会看到磁盘1或磁盘2显示为未初始化、未分配。如果压根没有出现新磁盘大概率是控制台没有完成挂载回到控制台确认。4.1.2 第二步初始化磁盘右键未初始化的磁盘选择初始化磁盘。这一步会弹出一个选择分区表类型的对话框。2TB以下容量MBR和GPT都可以但推荐直接用GPT。理由有三一是GPT分区数量不受4个主分区限制二是GPT支持2TB以上容量三是现在Windows 10/2012及以后的系统对GPT支持已经很完善了没有理由再用MBR。2TB以上容量必须选GPT。这个没有讨论空间MBR根本不认2TB以上的磁盘。4.1.3 第三步新建简单卷初始化完成后磁盘会变成未分配状态。右键未分配区域选择新建简单卷然后按向导操作。这一步里面有几个关键参数选择卷大小默认是整块磁盘全部容量如果不需要划分多个分区分给不同盘符直接用默认值即可驱动器号默认分配的是下一个可用盘符比如D盘可以手动改但尽量不要用A/B保留给软驱和C系统盘文件系统NTFS是默认且唯一推荐选项exFAT不推荐作为系统数据盘格式refs在Windows Server 2012上可用但兼容性不如NTFS分配单元大小默认值512字节或者4096字节都行没有特殊需求保持默认完成之后此电脑里就能看到新磁盘和盘符了。4.2 常见坑为什么挂载后看不到新磁盘这个坑值得单独拎出来说因为至少有一半的Windows磁盘问题都出在这里。场景再现控制台挂载了数据盘磁盘管理里磁盘状态是联机容量也正确显示但在此电脑里就是看不到。原因磁盘处于未分配状态没有分区、没有盘符资源管理器根本不会显示它。很多人在磁盘管理里看到联机就以为OK了其实差了新建简单卷这一步。还有一种情况是磁盘显示脱机。右键选择联机即可如果联机按钮置灰需要去设备管理器里把磁盘的状态调整一下。还有一种情况是磁盘已经初始化过、有分区但在此电脑里看不到盘符。去磁盘管理看分区状态如果显示没有盘符右键选择更改驱动器号和路径分配一个盘符问题就解决了。4.3 Windows磁盘扩容操作场景数据盘100G已经用了70G控制台把云盘扩容到了200GWindows里怎么用上这100G4.3.1 第一步刷新磁盘信息扩容后在磁盘管理里右键磁盘选择重新扫描磁盘。这一步执行后磁盘管理器会重新读取磁盘容量信息应该能看到容量从100G变成了200G。4.3.2 第二步扩展卷关键前提扩展卷要求NTFS分区。右键对应分区所在的区域选择扩展卷向导会让你选择要增加多少空间默认是全部未分配空间直接下一步即可。扩展完成后此电脑里就会显示200G了。需要注意的一种情况如果数据盘一开始被分成了多个分区比如C盘分错了的D盘和E盘而且D盘和E盘中间隔了其他分区扩展卷的时候扩展卷选项可能是灰色的。只有在分区右侧有连续未分配空间时才能扩展。解决方法是先把右侧的分区删除会丢失数据慎重或者在一开始规划的时候就不做多分区整块盘一个分区最简单。注意Windows的C盘系统盘在离线状态下无法直接扩容微软的传统限制要求必须在Windows PE环境里才能对系统分区执行扩展。云厂商提供的Windows公共镜像也继承了这一限制所以Windows系统盘的扩容相对少见一般直接走更换云盘的路径。4.4 Windows系统盘容量不足的应对Windows系统盘满了除了换系统盘规格还有一个临时缓解方案使用磁盘清理工具。右键系统盘选择属性-磁盘清理清理Windows更新残留、临时文件、回收站内容。通常能释放好几个GB空间对于只是差一点空间的情况够用了。再配合手动清理一下用户目录下的缓存、C:\Windows\Temp、浏览器缓存一套组合拳下来往往能不用换机也能撑住。长期方案还是通过快照迁移到更大系统盘的实例操作路径和Linux类似创建快照 - 用快照创建新实例选择更大的系统盘 - 验证 - 迁移流量。5. 常见问题与排查技巧实录5.1 高频问题速查把这些年遇到的磁盘相关问题整理成一张表基本覆盖了绝大多数场景问题现象排查方向解决方法lsblk看不到数据盘控制台是否完成挂载控制台确认挂载状态必要时重启实例挂载时报mount: /dev/vdb1 already mounted是否重复挂载df -h查看挂载点状态umount卸载后重新挂载重启后挂载失效fstab未配置或配置错误使用UUID写入/etc/fstab执行mount -a验证扩容后df -h看不到新容量分区未扩容或文件系统未刷新先growpart再resize2fs/xfs_growfs按顺序操作扩容分区时报unrecognized disk label磁盘没有分区表用parted创建GPT/msdos分区表后再操作Windows磁盘管理看不到新磁盘控制台未挂载控制台挂载后重新扫描磁盘Windows新盘未初始化未做初始化操作初始化磁盘并选择GPT分区表Windows扩展卷选项灰色分区右侧没有连续未分配空间或分区格式非NTFS确认文件系统是NTFS必要时删除右侧分区后重新扩展系统盘右键扩展卷灰色Windows系统盘不能在运行状态下直接扩容走快照迁移方案更换更大系统盘格式化后容量比标称小文件系统元数据占用正常现象例如100G磁盘ext4格式后约98G可用5.2 最容易出事的操作顺序磁盘类操作最忌讳乱序执行分享几个实战中踩过的教训案例一扩容分区顺序反了某次给数据盘扩容先执行了resize2fs再执行growpart结果文件系统刷新没有生效看起来容量还是原来的值。正确顺序是先扩分区growpart再扩文件系统resize2fs。顺序反了虽然不一定会损坏数据但会导致扩容无效还会让你误判是扩容失败还是操作方式有问题。案例二不保留连续未分配空间导致Windows无法扩展这也是一个实际案例某台Windows实例的数据盘被规划成多个分区空间快满的时候想扩展其中一个卷发现扩展卷选项灰色是因为该分区右侧还有其他分区占用。最终只能把后面的分区迁移出去并删除后才完成扩展。这个问题的根本原因是分区规划没做好新环境一律建议整块盘只做一个分区。案例三fstab写错导致开机失败fstab写错是最经典的云服务器故障场景之一。有一次在配置数据盘自动挂载的时候把设备名从/dev/vdb1写成了/dev/vdbp1当时执行mount -a没发现问题因为已经挂载上了结果重启后系统起不来只能通过控制台VNC进入单用户模式修复。从那以后每次配置fstab我都强制要求自己先blkid复制UUID再写配置文件最后执行mount -a验证并额外重启一次确认。5.3 排查工具的使用思路磁盘问题的排查工具不多但用得好能快速定位问题。这里聊一下几个常用工具的使用思路lsblk是整个排查流程的第一站。它一次能看到三件事块设备存在、是否有分区、分区挂载到了哪里。因为lsblk不读取文件系统信息即使文件系统损坏也能正常显示所以它是判断磁盘是否被系统识别最可靠的依据。df -h只关注文件系统层的容量使用情况。它显示的是文件系统容量而非分区容量。当lsblk显示分区已经是200G但df -h显示还是100G时就说明是文件系统没有刷新继续执行resize2fs即可。blkid用来查看分区的UUID和文件系统类型。写/etc/fstab前建议先执行一次直接把UUID复制过来手写最容易出错。fdisk -l是底层的块设备查看工具能看到磁盘真实容量、分区表类型、分区起止扇区、以及分区是否已经扩展到磁盘末尾。判断growpart是否生效用fdisk -l /dev/vdb看最后一个分区的结束扇区是否等于磁盘末尾扇区就可以了。这些工具配合起来用基本上能够应对绝大多数磁盘问题。5.4 磁盘操作的安全意识做磁盘相关操作有几条底线是必须守住的任何时候动手前先快照。快照成本很低但数据丢失的成本难以估量。尤其涉及分区表修改、格式化、卷删除这些操作时没有快照裸奔操作出了事就只能找数据恢复了。不要在业务高峰期操作扩容。虽然在线扩容理论上不影响服务但任何变更都有概率触发问题。我习惯把磁盘操作排在业务低峰期给自己留出故障响应空间。分区操作和数据备份不能互相替代。快照只能恢复到拍摄时点的状态如果操作时分区表已经损坏快照恢复可能也无法直接还原到可用状态。所以对于数据库这类强一致性要求的数据要结合应用层备份来保证安全。不要在扩容完成后马上删掉旧快照。扩容操作稳定运行一段时间后确认业务没有异常再清理旧快照。建议观察期至少72小时。区分清楚云盘扩容和文件系统扩容是两回事。控制台上的扩容只是改了云盘的容量上限系统里的分区和文件系统还是原来的大小。两步都做完扩容才算真正完成。6. 实操后的几个关键认识整套流程走完我个人的几个体会想单独说说。第一个体会是磁盘操作90%的问题都出在客户端没刷新而不是云平台没生效。控制台扩容完成后部门用户直接在控制台看云盘容量已经200G了然后跑到系统里发现还是100G就以为扩容失败了其实只是分区和文件系统还没跟着变。搞懂数据流通的链路控制台 - 块设备 - 分区 - 文件系统自然就明白哪一步没做到位。第二个体会是Linux的可用空间取决于分区和文件系统的最小值。云盘扩容到200G后只要分区表还停在100G或者分区表扩展了但文件系统没刷新实际可用空间就都不会变。检查的时候lsblk看分区层df -h看文件系统层两个都确认了才算到位。第三个体会是Windows的磁盘管理虽然图形化但傻瓜化程度远不如Linux命令行。你至少要知道初始化、新建卷、扩展卷这三级概念知道为什么新盘看不到知道什么情况下不能扩展。否则很容易在各个界面之间转圈圈问题的本质却没有抓住。最后说一个实用的小技巧给所有数据盘单独建一个挂载目录并且设置可读的目录名。不要图省事直接把数据盘挂到根目录或者/home下面。这样不管是做快照、做迁移、做扩容操作边界都很清晰。同时给数据盘打上标签比如数据盘-日志、数据盘-数据库多台机器的时候管理起来会省心很多。磁盘问题的排查思路如果用人打比方的话就是先确认这个人来没来控制台挂载是否成功再确认他有没有身份证分区表是否创建再确认他能不能干活文件系统是否格式化再确认他住不住得下挂载到目录再确认他是不是稳定居住fstab自动挂载。链路对了问题自然就清楚了。这套流程我相信不管以后换到哪个云平台思路都是通用的。
