Gcore - 云 | 阿姆斯特丹事件详情 – 故障详情

根本原因分析

问题
2026年3月4日，阿姆斯特丹地区某存储集群的存储容量出现问题，导致临时写入操作被阻塞。这造成依赖于该存储系统的虚拟机出现磁盘I/O故障和服务中断。

该问题发生在一次涉及存储平台升级的维护活动中。虽然升级成功完成，但由于后台数据重新分布和异常高的写入活动，导致存储利用率超过了临界阈值，触发了保护机制，暂时阻止了新的写入操作。
采取紧急措施回收存储容量后，服务功能已恢复。

时间线（UTC）

• 2026年3月4日 – 15:50：存储平台升级完成，后台数据重新分发开始

• 2026年3月4日 – 16:20：存储利用率达到临界阈值；集群转为写阻塞状态

• 2026年3月4日 – 16:21：由于依赖的虚拟机出现存储错误，监控系统不可用

• 2026年3月4日 – 16:23：多份客户报告显示，虚拟机可用性问题普遍存在。

• 2026年3月4日 – 17:25：调查确定存储容量耗尽是根本原因

• 2026年3月4日 – 17:28：存储工程团队启动紧急容量恢复程序

• 2026年3月4日 – 17:40：写入操作已恢复，受影响的虚拟机开始恢复

• 2026年3月4日 – 18:00：通过系统测试验证平台功能

• 2026年3月4日 – 18:59：剩余虚拟机已恢复，事件已结束

根本原因
此次事件是由于两种情况同时发生导致存储利用率暂时飙升所致。在维护期间存储系统重启后，自动数据重新分配过程启动，在数据于节点间重新平衡期间，存储使用量暂时增加。

与此同时，工作负载异常高的写入活动消耗了额外的存储容量。由于集群的利用率已经相对较高，这两种因素叠加导致存储使用量超过了系统的安全阈值。因此，存储平台自动阻止了写入操作以保护数据完整性，导致使用受影响存储的虚拟机出现磁盘 I/O 故障。

行动事项

• 实施强制性的维护前验证步骤，以确保在存储服务重启或升级期间禁用或控制自动数据重新分发机制。

• 在维护程序中引入容量保障措施，以防止在存储利用率超过安全运行阈值时执行升级。

• 增加受影响区域内的可用存储容量，以保持足够的后台数据操作和工作负载峰值所需的空间。

• 审查维护活动安排的操作规程，以确保升级期间系统容量充足且可视性良好。

我们很高兴地通知您，影响我们云服务的阿姆斯特丹重大故障已得到解决。但是，如果您仍然遇到任何问题，请随时联系我们的支持团队。我们的团队将竭诚为您提供帮助，并确保及时解决您提出的任何其他问题。

感谢您在此次事件中的耐心和理解，也感谢您的合作。
目前正在准备一份正式的根本原因分析报告（RCA），报告完成后将予以公布。

如需进一步帮助，请通过support@gcore.com联系我们的支持团队。

我们很高兴地通知您，我们的工程团队已修复了云服务的主要故障。但是，我们仍在密切监控情况，以确保服务稳定运行。

一旦确认问题已彻底解决，我们将立即向您提供最新进展。