场景:
一家公司再具有Amazon EBS存储的单个m4.2xlarge
Amazon EC2实例上运行遗留系统Web服务器。
还有自我管理的Oracle数据库,每12小时对EBS卷进行一次快照。
并从完全配置的EC2实例间建AMI。
最近终止EC2实例的事件导致数小时的停机时间。
该应用程序已从AMI成功启动,但EBS快照的存续时间和数据库的修复导致丢失了8个小时的数据。
在系统操作员手动执行这些过程的同事,系统也停机了4个小时
问:哪些体系结构更改将最大程度地减少停机时间并减少丢失数据的机会?
解决方案
- A
创建一个Amazon Cloud Watch警报,以自动恢复实例,创建一个脚本,该脚本将在重新启动后检车并修复数据库,将Operations团队订阅到Cloud Watch警报生成的Amazon SNS消息 - B
在Elastic Load Balance[ELB]/Application Load Balancer[ALB]之后的m4.xlarge
EC2实例上运行应用程序,跨多个可用区Auto Scaling组中运行EC2实例,实例数量最少为2。将数据库迁移到Amazon RDS Oracle Multi-AZ数据库实例中 - C
在Elastic Load Balance[ELB]/Application Load Balancer[ALB]之后的m4.2xlarge
EC2实例上运行应用程序。在Auto Scaling组中运行EC2实例,以最少一个实例数访问多个可用区。将数据迁移到Amazon RDS Oracle Multi-AZ数据库实例 - D
将Web服务器实例数增加到