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

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爱好者的网址是www.iloveaws.cn。
  • 可以通过扫码加入【AWS爱好者】微信公众号,查看原创的AWS知识点相关文章
  • 加入【AWS爱好者】微信群,和其他同学一起备考,以及探讨交流AWS相关知识
  • 加入【AWS知识星球】持续学习。

我们今天的视频课程就到这里,感谢大家的观看,我们下一课程再见。

2020年10月16日

0 responses on "38-实例的状态检查和自动恢复"

Leave a Message

error: Content is protected !!