翻译于 2012/12/27 06:53
Github 上周末宕机故障分析 已翻译 100%
加载中
上周六，也就是12月22日，我们遭遇了一次重大停机事件。我们想要花时间来解释发生了什么事。这是 Github 历史上最糟糕的一次中断，这个中断是我们无法接受的，我很抱歉发生了这次中断，我们整个团队正在努力防止今后出现类似的问题。
出了什么问题？
在我们网络中，每个连接服务器的交换机也连接到一对聚合交换机。这些聚合交换机成对安装并用一种叫做MLAG 的功能来伪装为一个单路由，因为 link aggregation, spanning tree, 和其他layer 2 协议希望有一个单一的主设备. 这使得我们能够在一个聚合交换机上执行维护任务，而不会影响合作伙伴交换机或接入交换机的连接。我么已经成功运用这项功能很多次了。
翻译于 2012/12/27 09:49
在升级后，我们遇到了一些无法预知的故障，这些故障引起了20-30分钟的网络抖动(不稳定)，但是我们尝试在维护期间处理这些问题。我们断掉了一半聚合层到接入层交换机的链路，这样子能够是缓和一些问题，然后我们配合网络供应商试图找到让我们不稳定的原因。这仍然没有起到作用，受累于繁琐的制度，使我们只能够操作一半的上级链路，但是我们的流量是比较低的，这在当时并没有产生真的问题，在太平洋时间 11:00，根据我们以往的经验，如果我们对着这个新的版本没有一个好的解决方案，我们打算回滚这次软件的升级，并且回滚到太平洋时间 13:00的状态。
翻译于 2012/12/27 13:14
在太平洋时间12:15分，我们的网络供应商开始从交换机上收集最后的取证信息，以便他们尝试找出本次事故的原因。绝大多数的信息收集是隔离开进行的，包括收集日志文件和检索交换机各部分的硬件状态。作为最后一个步骤，他们尝试收集一个运行在交换机上的代理的状态。这涉及到停止的过程和促使它以某种方式写入状态，并在稍后进行分析。于是我们断开了接入交换机之间的链路，让它们彼此不相互受影响。这与我们之前以MLAG模式重启交换机类似，而在此前多次测试中都是没有出过意外的。
翻译于 2013/01/07 21:55
这时候，事情开始变得糟糕起来。一个部署在交换机上的代理被终止后，（成对部署的）另一个节点将等待 5 秒钟窗口期判断前者是否会恢复。如果它无法收到第一个节点的响应，却看到两者之间链路处于活跃状态，它会默认对方处于运行但状态不同步的情况。在这种情况下，它不能安全地接管与另一个路由器共同管理的资源，因此它会默认回到link aggregation, spanning tree和其他两层协议下的独立交换机运行状态。
翻译于 2013/01/07 21:54
当第一个交换机上的代理被终止时，这一对路由器之间的链接并未被中断，因为代理无法操作硬件去中断链接。只有当代理程序重新启动后才可能发送命令操作底层 硬件。当时间非常不巧，且路由器还需要更多额外时间由代理程序为分析而记录运行状态时，这一对路由器之间的链接保持了足够长时间的活跃状态，最终使得对端 路由器发现了在活跃线路上心跳消息的缺失，因此进行了后面这种有着更强破坏性的故障转移操作。
翻译于 2013/01/07 21:54
当发生这些的时候它引起巨大的流量损失并且我们所有的链路要重新建立，leader 选择使用生成树协议( spanning-tree 网络协议)，并且所有网络中的链路通过生成树协议恢复。这使得通过接入层交换机的流量被阻塞了1.5分钟。
翻译于 2012/12/27 11:44
加载中
删除一条评论
评论删除后，数据将无法恢复
深圳市奥思网络科技有限公司版权所有
粤ICP备12009483号
评论(2)
引用来自“ChanMelo”的评论
@红薯 如何修改自己的翻译？