亚马逊aws 服务器删除_亚马逊解释了上周AWS严重宕机停运的原因

上周发生的大规模AWS中断造成大量物联网(IoT)设备和在线服务瘫痪，这是由于亚马逊一项名为Kinesis的服务而引起的。Kenesis的任务是在AWS上收集和分析实时流数据，因此在亚马逊开始向其添加少量容量后就显得有些ic异。尽管它影响了广泛的设备和服务，但中断特别发生在位于美国东部1区的亚马逊北弗吉尼亚州的AWS设施。

在冗长而复杂的解释中，亚马逊将Kinesis的少量新增功能称为触发因素，而不是问题的根本原因。该公司在描述用于该服务的路径时说，Kinesis使用了一系列“后端”细胞簇来处理流。

这些流通过“前端”服务器机群拥有的分片机制分布在后端。前端的工作是将身份验证，限制和请求路由处理到后端群集上的正确流分片。该前端机队增加了容量。

前端队列中的每个服务器都会缓存某些数据，包括后端集群的成员资格详细信息和分片所有权。每个前端服务器都会为前端队列中的每个其他服务器创建操作系统线程。添加新容量后，已经属于团队的服务器将花费一个小时的时间来了解任何新参与者。

11月25日感恩节前一天，太平洋时间上午5:15响起第一个警钟，表明Kinesis记录存在错误。新功能可能会引起故障，促使亚马逊开始将其删除，但同时还要寻找其他潜在原因。

太平洋标准时间上午9:39，亚马逊发现了罪魁祸首，发现新容量导致机队中的所有服务器超过了操作系统配置所允许的最大线程数。由于不断超过此限制，因此缓存构造不断失败，因此前端服务器无法将请求路由到后端集群。

为了解决该问题，在删除了导致崩溃的其他容量之后，Amazon工程师重新启动了前端服务器。在太平洋标准时间上午10:07添加了第一组服务器。从那里开始，亚马逊缓慢地添加服务器，每小时仅增加几百个。随着流量的逐渐增加，错误率开始稳定下降，Kinesis完全恢复并在太平洋标准时间晚上10:23恢复正常。

与任何类型的服务中断一样，我们也要汲取教训并进行修复。为对AWS客户的影响深表歉意，亚马逊描述了几种措施，以确保不会再次发生此类事件。

首先，该公司将把Kinesis转移到更大的CPU和内存服务器，以减少所需的服务器总数。其次，该公司表示正在为服务中的线程消耗添加细粒度的警报。第三，亚马逊计划在完成必要的测试后增加线程数限制。第四，该公司正在做出更改，以缩短前端机队的冷启动时间，例如将前端服务器缓存移至专用机队，并将大型AWS服务(如CloudWatch)移至单独的前端机队。

提醒客户注意该问题也并非一件容易的事。

亚马逊表示：“在服务问题之外，我们在此次活动的初期与客户交流服务状态有些延迟。”亚马逊指出，它使用其服务健康仪表板向客户发出有关广泛运营问题和个人健康仪表板的警报。与受影响的客户直接沟通。

在此类事件中，Amazon通常将其发布到其服务运行状况仪表板。但是，由于使用了称为Cognito的服务，因此该工具无法以常规方式进行更新，该服务本身也受到中断的影响。尽管该公司转向了手动备份方法来更新此仪表板，但由于亚马逊的支持工程师对此工具的熟悉程度不足，因此更新被推迟了。

亚马逊补充说：“展望未来，我们已经更改了支持培训，以确保我们的支持工程师定期接受有关备份工具的培训，以将其发布到Service Health Dashboard。”

随着越来越多的组织和个人依靠云来使用关键设备和服务，像这样的事件不可避免地影响着越来越多的人。AWS客户尤其容易受到影响，因为亚马逊的云产品是最受欢迎和最常用的产品之一。这意味着组织需要为联机中断做好准备，就像为本地服务问题做准备一样。这就需要适当的数据保护和恢复计划，以确保当云中出现问题时，您自己的业务不会受到影响。