计划网络升级10月21日星期一晚上，我们进行了一次网络维护，用Juniper的新硬件替换了我们现有的核心路由基础设施。我们正在替换边缘路由器，这些路由器从数据中心的提供商那里引入连接，以及位于它们后面并处理整个路由的路由核心地区。优先在维护方面，我们的网络团队与TorreyPoint Consulting、Carousel和Juniper合作。我们一起设计了必要的硬件，检查了物理网络拓扑，并为齿轮。十月第21条冗余协议问题尽管现有网络处于冗余配置中，但将提供商转移到新的边界路由器的工作进展顺利。在将机架顶部的交换机配置到新的齿轮上之后，我们发现在配置更改过程中发生了短暂的中断。这事发生在午夜左右美国东部时间核心设置了MC-Lag冗余。这是大型云环境中常用的协议，消除了冗余网络中对生成树的需要。我们开始观察到，在对机架顶部交换机进行更改时，存在一些网络不一致的情况制造。工作通过JTAC和升级到ATAC，数据中国，后者是Juniper的技术支持渠道，我们能够追踪到我们的思科交换机，他们缺乏端口快速，导致了网络重新融合的问题。因此，物联网安全，当发生变化时，它们并没有以应有的速度传播。这是一个生成树设置，它被留在Cisco硬件上，在MC上加倍-滞后。这些在冗余设置中，协议是必需的，因为在冗余的情况下，云服务平台，网络拓扑的布局方式自然会产生环路。如果一个网络设备发生故障，这些物理环路允许通信量采取不同的路径。问题是，如果没有生成树或其他协议来帮助设备了解将流量发送到何处，交通将以一个环路结束，这将有效地摧毁任何依赖它的东西路径。十月第二个核心的移除在这一点上，我们已经解决了导致网络变化不能迅速传播的问题，我们正在使用新的硬件。10月25日，我们观察到网络中断，两个核心路由器开始抖动，它们的冗余协议不允许任何一个作为活动设备接管，并将流量推送到我们的提供商。最后，路由器确实在几分钟无法转发后重新聚合交通。我们向JTAC立案审查配置，并收集更多信息。大约一小时后，作为我们正常和日常工作的一部分，我们的数据中心运营总监通过插入机架顶部的交换机在该区域内增加了机架。在这一点上，我们观察到另一个网络问题，核心路由器再次开始故障和抖动。我们立即将问题上报JTAC，我们之前已经安排Juniper的现场工程师到达我们的现场办公室。在在这一点上，云估价，我们推出了JTAC建议的MTU更改，以匹配Juniper和Cisco gear的配置，我们还删除了仍然存在于思科机架式交换机上的生成树协议。经过Juniper的进一步审查，我们同意当前的配置应该可以工作，但是我们仍然观察到网络问题，因为核心未能适当地重新聚合网络。当时，我们确信问题与核心之间运行的MC Lag有关，因为到机架顶部交换机的下游配置是正确的，因此我们移除了冗余核心和网络重新融合。一次案件再次升级到Juniper，我们怀疑可能是硬件故障。我们还让Juniper的专业团队为运行我们配置的现有设置构建了一个测试实验室。这使得他们可以在实验室里测试东西，看看他们是否能找到其他不一致的地方，并观察我们在产品上看到的行为网络。我们希望排除从Juniper接收失败核心的可能性，并进一步升级问题。对于这个，Juniper提供了一个独立的操作系统，它运行一系列的自诊断功能，可以查找任何可能的硬件问题。不幸的是，这一过程相当漫长，我们不得不将其升级到管理链上。为了得到为什么不能立即（或至少在几个小时内）执行此诊断的答案，就需要通过Juniper升级这个问题。最终，我们在电话中得到的答案是，我们没有在安装操作系统的设备前面，尽管我们的数据中心运营总监在这次网络升级后基本上一直睡在数据中心开始。从在这一点上，我们是从一个核心运行。虽然这种配置并不冗余，但它是一种最佳状态，因为我们在主/被动状态下指定了支持网络负载的硬件。这意味着每个核心，单独地，完全能够处理所有的网络装载。计划对于配置和网络审查，我们再次通过Juniper将问题升级，并让他们的一名区域高级副总裁到我们在纽约的办公室，在那里我们讨论了我们遇到的问题。具体来说，Juniper在10月25日升级到Juniper时未能提供必要的支持，这使我们在技术可用之前等待了2个小时。他们还推荐TorreyPoint作为网络顾问，这将监督我们的配置和网络拓扑结构，因为显然我们正在对一个支持数万客户的生产网络进行更改，因此让更多的人提供同行评审必要的。我们安排了周三的办公室会议，10月30日，我们将深入查看所有配置、日志和网络拓扑结构，以便我们能够将第二个核心重新引入配置。十月第28条-jflow&BGP配置问题我们的客户可能知道，DDoS攻击现在是所有影响大小公司的网络上的常见问题。为了识别入站和出站的DDoS攻击，我们使用流分析。对于Juniper gear，这是通过jflow来完成的，jflow将数据包发送到传感器以进行自动操作。这个配置是在上个周末添加的，没有问题。开10月28日，我们遇到了nLayer的问题，这是我们的提供商之一，他们遇到了糟糕的路由问题。我们通常的做法是将它们从网络组合中删除并更新BGP，直到提供商有机会解决问题。执行这个相当小的BGP更新在边界路由器上造成了一个问题，它停止了转发流量。这不应该发生。再次升级问题，我们能够确定这个失败的原因与jflow有关，特别是发送数据包（1到1）进行分析。意味着每个包都被镜像并转发到传感器服务器。Juniper他的建议是要么降低采样率，这样1000个数据包中就有1个可以被分析，要么安装一个线路卡（MS-DPC），它只处理镜像流量，以便分析，并从设备本身卸载该服务。另一种解决方案是将jflow进程转移到核心路由器，而不是边缘/边界路由器，因为它们有更大的硬件容量，10月29日-当前状态更新这将带我们到今天和网络的当前状态。我们暂时禁用了jflow，并将使用内部监控进行DDoS检测和预防，导致在美国东部时间凌晨4点左右发生的DDoS攻击期间，响应时间比正常情况更长。我们安排了一次与Juniper工程师的现场会议，讨论整个网络拓扑结构和所有配置。我们正在对Juniper齿轮进行诊断以排除故障的可能性硬件。十月第30次现场会议Juniper&TorreyPoint工程师明天将在我们的办公室与Juniper和TorreyPoint的工程师进行现场会议，以审查整个网络堆栈。这意味着对物理设备进行审查，以确保未装运任何故障设备，审查网络拓扑结构，并对从边界/边缘路由器到核心的所有配置进行全面同行审查，到机架顶部开关，十月31-计划维护我们计划在星期四晚上进行网络维护，这将在我们明天的会议后给我们额外的24小时时间，以便再次检查整个网络拓扑结构并检查所有建议的更改。维护的目标是将冗余核心路由器重新启用到网络中，使其恢复到最初预期的冗余状态设置。什么首先，我们将不再对任何地区的核心设备进行网络升级。取而代之的是，我们将采用一种pod架构，它允许我们为"x"个机架指定运行网络的硬件。当我们建造这些机架时，我们将提供第二个机架，它将为下一个"x"机架提供服务。然后我们将在其上建立一个独立的网络，允许这些机架与每个机架进行通信其他。这个这意味着我们不需要对现有部署进行升级，而是在增加部署时添加其他部署容量。英寸过去，我们提出的每一个新区域都经过配置、测试，大数据入门，然后打开生产。因此，我们没有遇到任何问题。这就是为什么到目前为止，NY2非常稳定，因为所有的网络设备都是在该地区开放供公众使用之前安装和测试的。在我们的新吊舱里也是如此布局。其次，我们将改善与客户和公众的沟通。我们在这方面当然失败了，因为我们正在向打开票证的客户提供更新，同时还在我们的状态页面上创建更新(https://www.digitaloceanst