帖子准备者：Alexander Virilin xscrew-作者，网络基础结构服务主管，Leonid Klyuyev-编辑
我们将继续让您熟悉
Yandex.Cloud的内部结构。 今天我们将讨论网络-我们将告诉您网络基础架构的工作原理，为何对数据中心使用不受欢迎的MPLS范式，在构建云网络的过程中我们还必须做出哪些其他复杂的决定，我们如何管理它以及使用哪种监控。
云中的网络由三层组成。 最底层是已经提到的基础结构。 这是数据中心内部，数据中心之间以及与外部网络连接的地方的物理“铁”网络。 虚拟网络建立在网络基础架构之上，而网络服务则建立在虚拟网络之上。 这种结构不是单块的：各层相交，虚拟网络和网络服务直接与网络基础结构交互。 由于虚拟网络通常称为覆盖，因此我们通常将网络基础结构称为底层。
现在，Cloud基础架构位于俄罗斯中部地区，包括三个访问区-即三个地理上分散的独立数据中心。 独立-在网络，工程和电气系统等方面彼此独立
关于特征。 数据中心位置的地理位置使得它们之间的往返时间的往返时间（RTT）始终为6–7 ms。 由于Yandex在区域之间拥有自己的光纤网络，因此这些信道的总容量已经超过10兆比特，并且还在不断增长。 由于我们不租用通信信道，因此我们可以快速增加DC之间的条带容量：每个DC使用频谱复用设备。
这是区域的最示意性表示：
反过来，实际情况略有不同：
这是该地区当前的Yandex骨干网。 所有Yandex服务都在其之上运行，部分网络供Cloud使用。 （这是内部使用的图片，因此，服务信息被故意隐藏。但是，可以估计节点和连接的数量。）使用骨干网络的决定是合乎逻辑的：我们无法发明任何东西，但是可以重复使用当前的基础架构，这些基础架构在多年的发展中“受挫”。
第一张图片和第二张图片有什么区别？ 首先，访问区域不直接相关：技术站点位于它们之间。 这些站点不包含服务器设备，仅在网络设备上放置用于确保连接的设备。 Yandex和Cloud与外界连接的存在点已连接到技术站点。 所有存在点都在整个区域工作。 顺便说一句，请务必注意，从Internet进行外部访问的观点来看，所有Cloud访问区域都是等效的。 换句话说，它们提供相同的连接性-即相同的速度和吞吐量以及同样低的延迟。
此外，存在点处的设备-如果存在本地资源并且希望通过云设施扩展本地基础架构，则客户可以通过有保障的渠道进行连接。 这可以在合作伙伴的帮助下完成，也可以自行完成。
云将核心网络用作MPLS传输。
MPLS协议
多协议标签交换是我们行业中广泛使用的技术。 例如，当数据包在访问区域之间或访问区域与Internet之间传输时，转接设备仅关注顶部标签，“不考虑”下面的内容。 这样，MPLS使您可以从传输层隐藏云的复杂性。 总的来说，我们在云端非常喜欢MPLS。 我们甚至将其作为较低级别的一部分，并直接在数据中心的交换工厂中使用它：
（实际上，Leaf开关和Spines之间有很多并行链接。）
为什么要使用MPLS？
没错，MPLS在数据中心网络中很少见。 通常使用完全不同的技术。
我们使用MPLS的原因有很多。 首先，我们发现方便统一控制平面和数据平面的技术。 也就是说，代替数据中心网络中的某些协议，核心网络中的其他协议以及这些协议的交界处-一个MPLS。 因此，我们统一了技术堆栈并降低了网络的复杂性。
其次，在Cloud中，我们使用各种网络设备，例如Cloud Gateway和Network Load Balancer。 他们需要相互通信，将流量发送到Internet，反之亦然。 这些网络设备可以随着负载的增加而水平扩展，并且由于Cloud是根据超融合模型构建的，因此从数据中心的网络角度来看，即在公共资源池中，它们几乎可以在任何地方启动。
因此，这些设备可以在服务器所在的机架式交换机的任何端口之后启动，并开始通过MPLS与基础架构的其余部分进行通信。 建立这种架构的唯一问题是警报。
闹铃
经典的MPLS协议栈非常复杂。 顺便说一下，这是MPLS在数据中心网络中不扩散的原因之一。
反过来，我们没有使用IGP（内部网关协议）或LDP（标签分发协议）或其他标签分发协议。 仅使用BGP（边界网关协议）标签单播。 例如，作为虚拟机运行的每个设备都在机架式Leaf交换机之前建立BGP会话。
BGP会话在已知地址处建立。 无需自动配置交换机即可运行每个设备。 所有交换机均已预先配置且一致。
在BGP会话中，每个设备都发送自己的环回，并接收与之交换流量的其余设备的环回。 这种设备的示例是几种类型的路由反射器，边界路由器和其他设备。 结果，有关如何相互到达的信息出现在设备上。 从Cloud Gateway到Leaf交换机，Spine交换机以及网络到边界路由器，构建了一个Label Switch Path。 交换机是行为类似于标签交换路由器的L3交换机，并且不了解其周围的复杂性。
MPLS在我们网络的各个级别上都使我们能够使用“吃自己的狗粮”的概念。
吃你自己的狗粮
从网络的角度来看，该概念意味着我们生活在与提供给用户相同的基础架构中。 这是辅助区域中的机架图：
云主机从用户那里承担负载，其中包含他的虚拟机。 从字面上看，机架中的相邻主机可以从网络角度承载基础结构负载，包括路由反射器，管理，监视服务器等。
为什么这样做？ 试图在单独的容错段中运行路由反射器和所有基础结构元素的诱惑。 然后，如果用户群在数据中心的某个位置发生故障，则基础结构服务器将继续管理整个网络基础结构。 但是这种方法对我们来说似乎是恶毒的-如果我们不信任自己的基础架构，那么我们如何才能将其提供给客户？ 毕竟，绝对所有的云，所有虚拟网络，用户和云服务都可以在其之上运行。
因此，我们放弃了一个单独的细分。 我们的基础架构元素在相同的网络拓扑和网络连接中运行。 自然，它们在三重实例中运行-就像我们的客户在云中启动服务一样。
IP / MPLS工厂
这是其中一个可用区的示例图：
在每个可用区域中，大约有五个模块，在每个模块中，大约有一百个机架。 叶子-机架安装式交换机，它们通过Spine级别在其模块内连接，并且通过网络互连提供模块间连接。 这是下一个级别，其中包括已经连接访问区域的所谓的“超级脊椎”和“边缘”交换机。 我们故意放弃了L2，我们只是在谈论L3 IP / MPLS连接。 BGP用于分发路由信息。
实际上，并行连接比图片中的要多得多。 如此大量的ECMP（等价多路径）连接提出了特殊的监视要求。 此外，乍看之下，设备存在一些意外限制，例如ECMP组的数量。
服务器连接
由于强大的投资，Yandex以一种服务器，服务器机架，模块甚至整个数据中心的故障永远不会导致服务完全停止的方式构建服务。 如果我们遇到任何类型的网络问题-假设机架安装交换机已损坏-外部用户将永远不会看到这种情况。
Yandex.Cloud是一个特例。 我们无法指示客户如何构建自己的服务，因此我们决定对这种可能的单点故障进行分级。 因此，云中的所有服务器都连接到两个机架式交换机。
我们也没有在L2级别使用任何冗余协议，而是出于协议统一的原因，立即开始仅将L3与BGP一起使用。 此连接为每个服务提供IPv4和IPv6连接：某些服务在IPv4上运行，而某些服务在IPv6上运行。
在物理上，每个服务器通过两个25千兆位接口连接。 这是数据中心的照片：
在这里，您将看到两个具有100千兆位端口的机架式交换机。 可见不同的分支电缆，将交换机的100 Gb端口划分为每个服务器25 Gb的4个端口。 我们称这些电缆为“ hydra”。
基础设施管理
云网络基础架构不包含任何专有的管理解决方案：所有系统都是针对云定制的开源或完全自写的。
如何管理此基础架构？ 云端并没有禁止这样做，但是强烈建议您不要使用网络设备进行任何调整。 存在系统的当前状态，我们需要应用更改：进入一些新的目标状态。 “遍历所有腺体运行脚本”，更改配置中的某些内容-您不应该这样做。 取而代之的是，我们对模板进行更改，对单个真实系统系统进行更改，然后将更改提交给版本控制系统。 这非常方便，因为您总是可以回滚，查看历史记录，找出谁负责提交等。
进行更改后，将生成配置，并将其部署到实验室测试拓扑。 从网络角度看，这是一个小型云，可以完全重复所有现有生产。 我们将立即查看所需的更改是否有所突破：首先是通过监视，其次是来自内部用户的反馈。
如果监视表明一切都平静，那么我们将继续推出-但仅将更改应用于部分拓扑（出于相同原因，两个或多个可访问性“无权”中断）。 此外，我们将继续密切监视监视情况。 这是一个相当复杂的过程，我们将在下面讨论。
确保一切正常后，我们将更改应用于整个产品。 您可以随时回滚并返回到网络的先前状态，以快速跟踪并解决问题。
监控方式
我们需要不同的监控。 最受欢迎的方法之一是监视端到端连接。 在任何给定时间，每个服务器都应该能够与任何其他服务器通信。 事实是，如果某个地方存在问题，那么我们希望尽早准确地找出位置（即哪些服务器相互访问有问题）。 确保端到端的连接是我们的首要考虑。
每个服务器列出了一组在任何给定时间都应该能够与之通信的服务器。 服务器采用此集合的随机子集，并将ICMP，TCP和UDP数据包发送到所有选定的计算机。 这将检查网络上是否有损耗，延迟是否增加等。整个网络在其中一个访问区域内以及它们之间被调用。 将结果发送到集中式系统，以便为我们可视化。
当一切都不尽如人意时，结果如下所示：
在这里，您可以看到哪个网段之间存在问题（在本例中为A和B），在哪里一切正常（A和D）。 可以在此处显示特定的服务器，机架式交换机，模块和整个可用性区域。 如果以上任何一个成为问题的根源，我们将实时看到它。
此外，还有事件监视。 我们密切监视所有连接，收发器上的信号电平，BGP会话等。假设从一个网段构建了三个BGP会话，其中一个在晚上中断。 如果我们设置监视以使一个BGP会话的中断对于我们而言并不重要，并且可以等到早晨，那么监视将不会唤醒网络工程师。 但是，如果三个会话中的第二个失败，则工程师会自动呼叫。
除了端到端和事件监视之外，我们还使用集中的日志收集，日志实时分析和后续分析。 您可以查看相关性，确定问题并找出网络设备上正在发生的事情。
监视主题足够大，还有很大的改进空间。 我想使系统实现更大的自动化和真正的自我修复。
接下来是什么？
我们有很多计划。 有必要改善控制系统，监视，交换IP / MPLS工厂等等。
我们还积极寻求白盒开关。 这是一个现成的“熨斗”设备，可以在其上滚动软件的开关。 首先，如果一切都正确完成，将有可能以与服务器相同的方式对交换机进行“处理”，构建一个真正方便的CI / CD流程，逐步推出配置等。
其次，如果存在任何问题，最好让一组工程师和开发人员来解决这些问题，而不是等待很长时间才能找到供应商的修复程序。
为了使所有工作顺利进行，工作在两个方向进行：
- 我们大大降低了IP / MPLS工厂的复杂性。 一方面，与此相反，虚拟网络和自动化工具的级别变得更加复杂。 另一方面，底层网络本身变得更容易。 换句话说，存在一定数量的复杂性无法节省。 它可以从一个级别“扔”到另一个级别-例如，在网络级别之间或从网络级别到应用程序级别。 您可以正确分配这种复杂性，我们正在尝试这样做。
- 当然，我们正在最后确定一套用于管理整个基础架构的工具。
这就是我们要谈论的网络基础架构的全部内容。
这是带有新闻和提示的Cloud Telegram频道
的链接 。