问EC2 -硬件故障

EN

AWS不太可能重新启动实例。它们为您提供了监视和重新启动实例的所有工具，因此将其留给您。如果你需要做些什么，他们可能会给你发电子邮件。如果停止，则启动实例，它将移动到新硬件，但重新启动不会将其移动到新硬件。重新启动Amazon实例通常需要一分钟左右。

如果EC2硬件出现故障，您不应该丢失来自EBS磁盘的数据，因为EBS卷是在单个可用性区域中冗余存储的。EBS快照存储在S3中，在单个区域内的三个可用区域中存储数据，因此它们更加健壮。快照可以被自动化，每小时，每日，每周等，使用各种工具。第一个快照是大的，随后的是差别被说是使用相对较少的空间。在我的经验中，快照紧密结合使用很少的空间，但是随着时间的推移，它们的大小和成本都会增加，所以我经常删除我不需要的快照。

除了快照之外，还应该使用应用程序(如博格备份、研究区或商业工具)进行应用级备份。

您可以在CloudWatch中创建一个警报，如果引发StatusCheckFailed，可以重新启动实例。有一步一步指令的文档是这里。

在某些情况下，Amazon会注意到他们的硬件处于退化状态，并告诉您在某一日期之前退出它(停止并启动您的实例)，否则它将自动停止。

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

我还没有一个EBS卷失败我(我有很多例子变得奇怪，但没有卷)，但仍然计划。我不知道那是什么样子。

为Reachability状态检查失败设置一个警报是最好的选择。

我刚刚经历了EBS的失败，这使得两个EC2s都瘫痪了，这两个EC2s都在ElasticBean秸秆上运行了一项所谓的容错服务。

其症状是HTTP请求仍然有效，但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数据。但是工作正常，因为读取文件系统仍然正常。

有趣的是，由于健康检查报告一切正常，ElasticBean秸秆没有终止和重新创建任何EC2实例，尽管大约35%的请求由于HTTP 500错误而失败。

吸取的教训？确保您的健康检查URL试图写入EC2上其他进程使用的同一个文件系统，以便失败的磁盘也会导致健康检查失败。否则，可能无法自动检测到问题，可能需要手动干预。