CloudFormation部署OpenSearch遇超时错误及回滚失败求助

问题背景 #

我们在CloudFormation堆栈部署中执行了两项变更：

• 将OpenSearch版本从1.0升级至1.3
• 将存储卷容量从500扩容至1024

部署耗时约4小时后，OpenSearch成功升级到1.3，但存储卷扩容未完成，堆栈部署失败且回滚操作也失败。当前存在以下疑问：

1. 是否可以回滚至1.0后重新部署？
2. 跳过回滚是否会导致OpenSearch与堆栈配置脱离？
3. 是否因数据量过大导致部署超时引发失败？

可能成因 #

• 部署超时触发失败：CloudFormation对OpenSearch集群这类资源有默认操作超时阈值，当集群数据量较大时，存储扩容需要完成数据重平衡/迁移，耗时远超默认阈值，导致CloudFormation判定操作失败并触发回滚。
• 回滚失败的核心原因：OpenSearch版本升级已成功完成，回滚时需要从1.3降级回1.0，但官方通常不支持跨版本降级，且高版本数据格式可能与低版本不兼容，导致降级操作卡住，最终回滚失败。
• 堆栈与资源状态不一致：版本升级成功但存储扩容失败，此时堆栈的期望配置与OpenSearch集群的实际状态出现偏差，后续的回滚或继续部署都会因这种不一致性无法正常执行。

解决方案 #

1. 修复堆栈与资源的一致性，完成未完成的扩容 #

• 先通过AWS控制台确认OpenSearch集群的实际状态：版本为1.3，存储容量仍为500。
• 修改CloudFormation模板，将OpenSearch版本固定为1.3，保留存储卷扩容至1024的配置，执行**继续部署（跳过回滚）**操作。此时CloudFormation会仅尝试完成存储扩容，避免重复执行已成功的版本升级。
• 如果扩容仍超时，在模板的OpenSearch资源节点中添加Timeout属性，设置足够长的超时时间（例如PT8H代表8小时），适配大存储量的扩容需求。

2. 处理回滚失败的情况 #

• 禁止强制回滚至1.0：OpenSearch从1.3降级到1.0无官方支持，强行回滚会导致数据损坏或集群无法启动。
• 若堆栈处于失败状态，可使用CloudFormation的继续更新回滚功能，指定仅回滚未完成的存储扩容操作，保留已成功升级的1.3版本。操作前需确认资源状态允许部分回滚。

3. 避免后续组合操作出错 #

• 拆分变更操作：不要同时执行版本升级和存储扩容，先完成版本升级并确认堆栈状态正常后，再单独执行存储扩容，降低单次操作的复杂度和耗时。
• 大存储量集群扩容前，提前评估操作所需时间，在模板中设置合理的Timeout值，避免CloudFormation提前判定失败。

关键注意事项 #

• 跳过回滚时，必须确保模板的期望状态与资源实际状态的差异仅为未完成的存储扩容，否则会加剧堆栈配置与资源状态的脱离。
• OpenSearch版本升级后，不要尝试降级，除非有官方明确支持的降级路径，否则极易引发数据丢失或集群故障。
• 大存储量集群的扩容操作建议在业务低峰期执行，减少对业务的影响，同时预留足够的操作时间。

内容的提问来源于stack exchange，提问作者Hong