☰

EC2 – 硬件故障

tag-icon • tag-icon amazon-ec2 amazon-web-services
EC2 – 硬件故障

我在 Debian 实例上使用 EBS 存储。我将实例设置为在关机时不终止。

我想知道如果出现硬件故障（RAM、CPU、HD 等），会发生什么情况。

  1. 我应该配置哪种类型的警报来接收通知？我可以依赖“StatusCheckFailed”吗？

  2. 我是否应该期望 AWS 团队自动在不同的硬件上完成重启/重新启动？如果不是，我需要遵循哪些步骤才能在不同硬件上重启我的实例？需要多长时间？

  3. 我可以放心地认为我不会丢失数据 (/var/www 等) 吗？目前，如果我停止并启动，一切都会正常，但我不确定我是否可以依赖它，

  4. 如果硬盘出现故障，是否因为 AWS 使用 RAID 或其他方式而透明？或者我是否也必须收到通知并可能从上一个快照手动重新启动？

在“云”上，尤其是 AWS，我期望它包括故障转移管理，使用像 VMware 这样的产品，只需在另一个硬件上自动重新启动虚拟机即可。所以我明白我必须期待故障转移，但我正在寻找解决方案，以便在检测到硬件故障时自动在另一个区域/地区运行实例，或者，如果不可能，至少通过几个步骤手动运行？

谢谢，罗德

答案1

AWS 不太可能重启您的实例。他们为您提供了监控和重启实例的所有工具，因此他们把这件事交给您。如果您需要做某事，他们可能会给您发电子邮件。如果您停止然后启动实例，它将移动到新硬件，但重启不会将其移动到新硬件。我的 Amazon Linux 实例的重启通常需要一分钟左右。

如果 EC2 硬件发生故障，您不应该丢失 EBS 磁盘中的数据，因为 EBS 卷冗余存储在单个可用区域内。EBS 快照存储在 S3 中，S3 将数据存储在单个区域内的三个可用区域中，因此它们的稳定性更高。可以使用各种工具自动按小时、每天、每周等拍摄快照。第一个快照很大，随后的差异据说占用的空间相对较少。根据我的经验，快照彼此靠近会占用很少的空间，但随着时间的推移，它们会增加大小和成本，所以我会定期删除不需要的快照。

除了快照之外，你还应该使用类似以下应用程序进行应用程序级备份Borg 备份，雷斯蒂奇或商业工具。

您可以在 CloudWatch 中创建警报，如果出现 StatusCheckFailed，则会重新启动您的实例。带有分步说明的文档是这里。

答案2

在某些情况下，亚马逊会注意到他们的硬件处于降级状态并告诉您在某个日期之前停止它（停止并启动您的实例），否则它将自动停止。

在某些情况下，不会有任何警告，它会停止。或者不进入停止状态，只是变得无法访问。他们处理后，它可能会重新启动，也可能不会重新启动。有时，事后会发一封道歉邮件。

我还没有遇到过 EBS 卷故障（我遇到过很多实例异常，但不是卷），但仍然在为此做计划。我不知道那是什么样子。

为可达性状态检查失败设置警报是最好的选择。

答案3

我刚刚遇到了 EBS 故障，导致在 Elastic Beanstalk 上运行所谓容错服务的两个 EC2 都瘫痪了。

症状是 HTTP GET 请求仍然有效，但 POST 失败。这意味着我们基于 GET 的健康检查没有检测到任何问题，但由于登录过程使用了 POST，因此用户无法登录。

查看日志，有很多/var/log/messages有关 I/O 错误的消息。

EXT4-fs warning (device dm-3): ext4_end_bio:314: I/O error -28 writing to inode 5905292 (offset 3198976 size 4096 starting block 1475341)
Buffer I/O error on device dm-3, logical block 1475341
EXT4-fs warning (device dm-3): ext4_end_bio:314: I/O error -28 writing to inode 5905292 (offset 0 size 0 starting block 1475340)
Buffer I/O error on device dm-3, logical block 1475340
JBD2: Detected IO errors while flushing file data on dm-3-8
EXT4-fs warning (device dm-3): ext4_end_bio:314: I/O error -28 writing to inode 5905292 (offset 0 size 0 starting block 1475341)
Buffer I/O error on device dm-3, logical block 1475341

nginx 日志中有消息抱怨由于文件系统的只读状态导致 POST 请求失败。

open() "/var/lib/nginx/body/0000522584" failed (30: Read-only file system)
open() "/var/lib/nginx/body/0000522585" failed (30: Read-only file system)
open() "/var/lib/nginx/body/0000522586" failed (30: Read-only file system)

似乎发生了通常的 Linux 行为，即磁盘故障导致文件系统进入只读模式，从而阻止 nginx 创建任何临时文件来存储 POST 数据。但 GET 工作正常，因为读取文件系统仍然正常。

有趣的是，由于健康检查报告一切正常，Elastic Beanstalk 不会终止并重新创建任何 EC2 实例，即使大约 35％ 的请求因 HTTP 500 错误而失败。

学到了什么教训？确保您的健康检查 URL 尝试写入 EC2 上其他进程使用的同一文件系统，这样磁盘故障也会导致健康检查失败。否则，问题可能无法自动检测到，可能需要手动干预。

相关内容