实验2：模拟灾难与故障发生验证高可用架构
业务系统的稳定性，可靠性对我们非常重要。 在本章节我们通过灾难的模拟检验系统的可用性，评估是否满足生产系统要求。我们将完成下面架构图的模拟：
应用层高可用
1,登录到您的Odoo界面，您或许已经通过上一个实验搭建了您的第一个网站，可能是电商，可能是在线教育。现在请您处于登录状态，任意做一些操作，例如，将商品添加都购物车、创建一个新的报销单，打开网站编辑模式等。
像示范中，实验admin账户登录，并将两个商品放入了购物车。
2,登录到您的EC2控制台界面，如果您使用默认的Cloudformation参数进行部署，您可以查看到3台实例，分别是两台跨AZ的EKS worknode和一台管理环境用的堡垒机
3,现在我们关闭一台EKS worknode，勾选任意一台odoo-ng-odoo-Node为名称的实例，点击实例状态，点击终止实例。
4,我们回到刚刚打开的Odoo页面，查看我们是否依然处于登录状态，继续进行您刚刚的操作，例如，继续添加购物车，继续填报报销，检查关闭一台机器系统是否正常运行。
5,现在我们回到EC2控制台界面，您会发现刚刚我们手动关闭的EC2已经关闭，但是自动重新启动了一台同类型的EC2实例。
这是因为我们EKS节点组的默认节点数配置如下：
- desiredSize: 2
- minSize: 1
- maxSize: 5
您可以通过控制台扩展EKSCTL命名更改这些配置
6,现在您可以再回到EC2控制台界面，勾选全部的EKS work Node 将他们一起关闭。再观察实例自动回复的状态。可以预见的是，您的系统会有3分钟左右的不可用（新实例启动时间），而一旦ASG触发的新的实例启动完成，您的Odoo又将恢复服务，并且玩着保存着关机前的会话和所有系统数据。
Ps:如果您习惯更直观的使用EKS控制台管理EKS节点组，您可能会发现控制台中并未出现我们部署的两台ec2实例所反应的应用层work node。那是因为您当前登录控制台的用户没有在kubeconf中配置权限。在实验1中我们已经提到，将用户的权限加到EKS kubeconf中。请您转移到实验1的配置堡垒机之外的Role获得EKS集群控制权
数据库层高可用
1，登录RDS控制台，检查您的RDS postgreSQL是否多AZ部署，如果您按照默认参数启动Cloudformation，将设定为默认部署。如果你当前不是多AZ部署，您可以通过modify，勾选多AZ部署，选择立即生效改成多AZ部署以继续试验。
2，导航至RDS控制台点击您的数据库，导航至配置，您可以看到当前实例所处的AZ和辅助实例所处的AZ。
3，现在我们回到odoo应用，进行操作，如果碰巧，您可能会感觉到响应出现一点点卡顿，但依然正常返回我们进行的任何操作。
4，回到RDS控制台点击您的数据库，导航至配置，您会发现数据库当前可用区已经切换到刚才的辅助可用区，而之前的当前可用区变为了现在的辅助可用区。因为后台数据库完成了自动故障转移。
数据库实例故障转移完全自动化，无需管理干预。Amazon RDS 会监控您的主实例和备用实例的运行状况，并且会启动故障转移以应对各种故障条件。 Amazon RDS 可检测多可用区部署中最常见的故障并自动从中恢复过来，这样您可在无管理干预的情况下尽快恢复数据库操作。如果发生以下任何一种情况，Amazon RDS 将自动执行故障转移：
- 主可用区的可用性受损
- 主节点的网络连接受损
- 主节点的计算单位出现故障
- 主区域的存储故障
万一发生基础设施故障，Amazon RDS 可自动故障转移至备用实例中 (如果是 Amazon Aurora，则会故障转移至只读副本中)，以便您能够在故障转移结束后立即恢复数据库操作。由于故障转移后数据库实例的终端节点维持不变，因此应用程序可在无需手动管理干预的情况下恢复数据库操作。
会话层高可用
1，登录ElastiCache控制台，检查您的Redis 是否多AZ部署，如果您按照默认参数启动Cloudformation，将设定为默认部署。如果你当前不是多AZ部署，您可以通过modify，勾选多AZ部署，选择立即生效改成多AZ部署以继续试验。
2，导航至您的redis节点，选择主节点，选择操作，选择主节点故障转移
3，选择确认切换，回到您的redis控制台，发现主节点和备用节点的AZ发生互换
4，回到您的Odoo应用，您会发现您的登录状态依然还在，可以继续进行任何操作。如果您有购物车选项，购物车内的内容依然存在。
