实例的状态检查和自动恢复

关注公众号：AWS爱好者（iloveaws）
文 | 沉默恶魔（禁止转载，转载请先经过作者同意）
网站：www.iloveaws.cn

Hello大家好，欢迎来到《AWS解决方案架构师认证 Professional(SAP)中文视频培训课程》，我们今天的课程讨论实例的状态检查和自动恢复的内容。

我们开始今天的课程。

实例的状态检查知识点

首先，我们先来了解下实例的状态检查的一些重要知识点。
Amazon EC2 会对每个运行的 EC2 实例执行自动检查以识别硬件和软件问题。当我们启动一台实例后，状态检查就会自动开启检测软硬件问题。

状态检查是内置到 Amazon EC2 中的，所以不能禁用或删除。

状态检查每分钟进行一次，会返回一个通过或失败状态。如果所有的检查都通过，则实例的整体状态是OK，如果有一个或多个检查故障，则整体状态为受损。

您也可以创建 Amazon CloudWatch 警报，用于监控 Amazon EC2 实例并可以在实例由于潜在问题而受损时自动恢复实例，这也是我们本节课实例的自动恢复采用的方式，一会会进行实操演示。

EC2的状态检查可分为两种类型：系统状态检查和实例状态检查。
我们首先看下系统状态检查。

EC2的状态检查-系统状态检查

系统状况检查，会检测出需要AWS参与修复的深层实例问题，比如，以下是可能导致系统状况检查失败的问题：

实例的网络连接丢失
实例的系统电源损耗
实例所属物理主机上的软件问题。这个主要是指实例所在底层物理硬件的虚拟化相关软件的问题。
以及实例所属物理主机上影响到网络连接状态的硬件问题
一般当我们的实例出现 系统状况检查失败 是需要AWS参与和处理的，所以当我们遇到这个问题时，可以选择等待AWS修复问题，也可以自行解决问题。但是这里所谓自行解决问题，一般就是将有问题的实例手动停止在启动一下，这样的话这台实例就会从所在故障的底层硬件 自动迁移到 其他没有问题的底层硬件上。注意这种情况是需要停止实例而不是重启实例，重启实例的话实例还是会在原有的有问题的底层硬件之上运行。

AWS也支持当实例出现状态检查失败时自动的为我们恢复指定的实例，不需要人为手动干预，我们在这节课后面也会实操演示这部分内容。

以上是系统状态检查。

EC2的状态检查-实例状态检查

我们在看下 实例状态检查。
实例状况检查，是监控您的各个实例的软件和网络配置等。
Amazon EC2 通过向网络接口 (NIC) 发送地址解析协议 (ARP) 请求，检查实例的运行状况，这些检查检测是需要您参与修复的问题。
如果 实例状态检查 失败，通常必须由您自行解决问题（例如，重启实例或更改实例配置）。

以下是可能导致 实例状态检查失败 的问题的示例：

系统状态检查故障
网络或启动配置不正确
内存耗尽
文件系统损坏
内核不兼容
以上是实例状态检查的内容，所以，通过上面的介绍不难发现，实例状态检查，通常是需要由您也就是客户自行解决的问题；而系统状况检查，是需要AWS参与修复的深层实例问题。

好，以上是我们的知识点内容，接下来我们就进入实操演示环节。

实操演示-查看实例的状态检查信息

首先，我们先来看下如何在AWS控制台查看前面介绍的 实例状态检查的信息。
访问EC2控制台，目前运行着一台实例-server 1，选择这台实例后，通过下面的“状态检查”选项卡，可以查看该实例的“系统状态检查”以及“实例状态检查”。

我们可以看到控制台上的绿字“系统可到达性检查已通过” 以及 “实例可到达检查已通过”，说明这台实例目前已经通过了“系统状态检查”以及“实例状态检查”。

系统状况检查，是需要AWS参与修复的深层实例问题；而实例状态检查，通常是需要由您也就是客户自行解决的问题，具体的问题所包括的内容前面已经介绍过了。

另外，通过“监控”选项卡，然后在往下可以查看选择的实例 各类状态检查失败的次数。

当出现系统状态检查失败时，如果我们配置实例的自动恢复后，EC2会自动的为我们恢复指定的实例，不需要人为手动干预。
但是需要注意的是自动恢复这个功能只支持“系统状态检查”失败时自动恢复，并不支持“实例状态检查”。

实操演示-实例的自动恢复

接下来我们就来实操演示下自动恢复的内容，假设我们要配置server1这台实例的自动恢复。

选择实例后，在状态检查选项卡，点击“创建状态检查警报”，可以在该实例 状态检查失败时 发送通知到SNS主题，比如邮件，这样我们可以在失败时可及时收到通知，我们这里因为是测试就不发送通知了，建议生产环境勾选。

然后选择执行的操作，包括：恢复此实例，停止此实例，终止此实例，重启此实例。
恢复此实例，是指当实例“系统状况检查”失败时，会为我们自动停止然后启动该实例， 达到自动恢复“系统状况检查”失败的实例的效果，因为当停止实例在启动实例后，该实例会切换到其他底层物理服。

比如我们目前这台实例在物理服A上运行，然后物理服A出现问题了，导致该实例“系统状况检查”失败，当我们勾选“恢复此实例”后，EC2会自动为我们停止然后在启动该实例，启动过后该实例就从有问题的物理服A，切换到了其他正常的物理服比如物理服B后运行。

而这个“重启该实例”，如果实例在物理服A上，重启后不会切换物理服，还会在物理服A上运行。
所以如果我们需要EC2帮我们恢复实例，就要在这里选择“恢复此实例”,其实也就是EC2自动帮我们停止在启动实例，切换实例所属底层硬件达到恢复实例的效果。

注意，在强调一下，恢复实例的功能只有在 系统状态检查失败时 才支持。

后面是配置连续的周期和时间。

接下来我们做个实例自动恢复的快速演示，我们选择“恢复此实例”，条件配置为，当系统状态检查失败时，至少1个周期，时间为1分钟。输入警报名称为：test，然后创建警报。

创建后我们点击警报名称就会跳转到CloudWatch警报控制台，由于刚添加的警报目前数据不足，我们等待1分钟，等收集数据完整。
好，大概1分钟左右，目前警报的状态由“数据不足”变为“确定”。

那么现在 系统状态检查警报 我们就创建好了，当系统状况检查失败时，EC2会自动为我们恢复实例。我们接下来就测试下。

测试的方式非常简单，我们就通过 AWS的 CLI命令，将系统状况检查手动设置为“警报”状态，看看会发生什么。

我们先看下将系统状况检查手动设置为“警报”状态这条命令：

aws cloudwatch set-alarm-state --alarm-name “test”–state-value ALARM --state-reason “test” --region ap-northeast-1

alarm-name 后面需要加警报的名称，我们之前创建的警报名称为“test” ，然后state-value的值为ALARM，最后region后面配置所在区域，我测试所在的区域是东京。

当我们手动执行这条命令之后，会将我们之前配置的名为test的警报，状态由“正常”变更为“警报”状态，然后会触发我们之前配置的对应的操作—“恢复此实例”操作，我们现在测试一下。

切换到我本地终端，然后我们复制下命令，执行：

aws cloudwatch set-alarm-state --alarm-name “test”
–state-value ALARM
–state-reason “test”
–region ap-northeast-1
好，然后切换到cloudwatch控制台，可以看到我们之前创建的名为test警报，状态已经由“确定”变为“警报中”，说明我们刚才执行的cli命令已经生效了。

我们可以通过test警报的历史记录看一下具体的执行日志，在历史记录中可以清晰的查看状态更新的日志以及操作记录。

在我们执行cli命令后，历史记录中显示警告从“确定”更新到了“警报中”，然后，自动为我们触发了操作，已成功执行操作对实例进行recover，然后警告从“警报中”变更为“确定”。

也就是说，我们上面通过cli命令手动将警报状态设置为ALARM后，系统状态检查失败，然后EC2自动为我们执行了“恢复该实例”的操作，我们的实操演示成功了。

这里有一个小提示，我们这个演示是通过cli手动将警报状态设置为ALARM，所以AWS并没有真正的为我们停止和启动实例切换不同的底层硬件。但是在实际使用中如果发生系统状态检查失败，EC2是会自动执行停止、启动从而切换底层物理硬件达到恢复实例的作用的。

好，以上就是我们今天的课程内容，我们今天讨论了实例的状态检查知识点，以及实操演示了实例的自动恢复的内容，希望能够给大家带来帮助。

希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助，如您有任何疑问

关注公众号：AWS爱好者（iloveaws）
文 | 沉默恶魔（禁止转载，转载请先经过作者同意）
网站：www.iloveaws.cn