惊险一刻:系统盘爆满后的在线扩容救援实录
00 分钟
2024-11-19
2024-11-22
type
status
date
slug
summary
tags
category
icon
password
网址
突然接到客户的紧急通知:服务超时,系统功能出现异常。我第一时间 SSH 登录系统查看,发现原先的 100GB 系统盘已经被占满。客户的服务是关键业务,停机意味着损失。于是,我们决定采用 在线扩容方案,在不中断服务的情况下完成从 100GB 扩展到 300GB 的操作。这次扩容经历可谓惊心动魄,最终完美收尾,下面是详细的过程分享。

第一步:快速响应,紧急扩容

时间紧迫,我通过甲方客户直接联系了甲方财务,通过视频会议快速完成扩容费用的确认和支付流程。确定预算后,立即登录阿里云控制台开始操作。
  1. 阿里云控制台在线扩容
      • 打开实例管理页面,选择目标实例。
      • 块存储中找到系统盘,调整容量至 300GB。
      • 确认后,系统提示扩容成功,服务依然在线且未中断。
  1. 为什么在线扩容可以不停机?
    1. 阿里云的在线扩容功能支持热扩展,磁盘容量在后台调整完成,实例无需停止即可完成磁盘的物理扩展。

第二步:Ubuntu 中完成扩容操作

尽管控制台显示扩容成功,但在 Ubuntu 系统中,磁盘分区和文件系统的容量并未发生变化,还需要进一步操作来释放新增的空间。
  1. 确认磁盘大小变化
    1. 使用以下命令查看磁盘信息:
      输出结果显示 /dev/vda 已经扩展到 300GB。
      notion image
      notion image
  1. 扩展分区
      • 执行 growpart 工具扩展分区:
        • 执行过程中出现 growpart /dev/vda 3mkdir: cannot create directory '/tmp/growpart.2219316’: No space left on deviceFAILED: failed to make temp dir
          • 说明磁盘空间完全不足,找几个日志文件删删,找点冗余空间
        • 如果 growpart 提示命令未找到,需要先安装:
      1. 扩展文件系统
        1. 最后一步是将文件系统调整为新的磁盘大小:
          运行 df -h 确认扩展完成后,系统盘已经显示 300GB 的可用容量。

      中途的小插曲

      扩容过程并不是一帆风顺,我遇到了两个意外问题:
      1. 命令未找到
        1. 在执行 growpart 时,系统提示找不到命令。排查发现是因为云实例没有预装 cloud-guest-utils 工具,导致扩展分区失败。花了几分钟完成工具安装后重新尝试,问题顺利解决。
      1. 服务负载增高
        1. 扩容时正值业务高峰,服务响应时间变长。分析后发现是因为日志清理未及时完成,导致 /var/log 的空间占用飙升,触发了磁盘写入的性能瓶颈。迅速清理了冗余日志后问题才缓解。

      扩容后,我们得到了什么?

      经过扩容和优化,系统终于恢复正常运行。服务性能稳定,客户反馈良好。这次扩容带来了几点重要的经验:
      1. 在线扩容的价值
        1. 阿里云的在线扩容功能为业务连续性提供了保障,尤其在无法停机的场景下显得尤为重要。
      1. 磁盘容量规划的重要性
        1. 不仅要定期检查磁盘使用情况,还要提前评估未来业务增长对存储的需求。
      1. 工具的准备
        1. 云实例中常用的分区管理工具(如 growpart)应提前安装,并熟悉使用方法。
      1. 日志管理不可忽视
        1. 定期清理和归档日志文件,使用工具如 logrotate 自动完成切割,避免日志堆积。

       
      上一篇
      CentOS 7/8 安装指定版本 Docker
      下一篇
      自主构建高并发 MQTT 服务端的构思

      评论
      Loading...