几点:
您必须必须备份您的 Amazon EBS 卷。
他们声称“更好”的可靠性,但不是 100%,而且它比 S3 的“12 9”耐用性低了几个数量级。S3 耐用性 >> EBS 耐用性。这是事实。EBS 支持“快照”功能,该功能可以高效且增量地备份您的存储到 S3。此外,使用 EBS 快照,您只需为压缩增量付费,这通常远小于分配的卷大小。在另一种生活中,我向像您这样“认为”EBS 是“耐用”并信任它的任务关键型数据库的唯一副本的小型客户发送了丢失量的电子邮件……这令人心碎。
您的问题:自动启动新实例
您提到的设计路径相对未走;这就是为什么...许多公司运行冗余的“热备用”实例,其中第二个实例已启动并运行。这允许在“故障”(可能是硬件或软件)的情况下快速故障转移(秒)。“冷备用”的问题在于,很难让机器保持最新状态并准备好从旧盒子停止的地方拿起。更重要的是,验证备件是否能够成功恢复您的生产服务是很棘手的。硬件比未经测试的软件系统更可靠。测试测试测试。如果你没有测试你的故障转移,它就不起作用。
启动新 EBS 实例的简单自动化很容易,几乎是微不足道的。它只是一个调用EC2 命令行工具的单行 bash 脚本。棘手的是最重要的一切。这样的解决方案几乎意味着完全 100% 自动化的部署过程。这都是特定于您的应用程序的。您的应用程序能否拉取运行所需的所有数据(可能存储在 S3 中?)。您今天可以杀死您的实例并使用 0.000 个手动设置/安装步骤启动一个新实例吗?
或者,您可能正在谈论我称之为“重新实例化 EBS 卷”的场景:
- EC2 盒死机(根卷为 EBS)
- 强制分离 EBS 卷
- 使用 EBS 卷启动新的 EC2 实例
...这主要是有效的。问题:
- 不能防止 EBS 故障,无论是总卷丢失还是可用性丢失
- 假设一切正常,恢复时间为 O(分钟)
- 您的服务需要配置为自动重启。如果 Nginx 没有运行,把盒子拿回来是没有好处的。
- 您的 DNS 路由或其他服务或任何需要更改 IP 地址的东西。这可以通过 ElasticIP 解决。
- 您的主机 SSH 密钥是如何处理的?同名,新主机密钥在收到主机密钥更改的强烈警告时可能会破坏基于 SSH 的自动化。
- 我没有这方面的证据(除了看到它发生一次),但我相信 EC2/EBS _already_does_this_ 自动用于从 EBS 实例启动
同样,这里的困难部分在你的盘子上。您今天可以停止生产服务并在新实例上可靠地启动它吗?如果是这样,故事的 EC2 部分真的很简单。