您好，我叫 Kostya Kramlikh，是 Yandex.Cloud 虚拟私有云部门的首席开发人员。 我是一名虚拟网络人员，正如您可能猜到的那样，在本文中我将总体讨论虚拟私有云 (VPC) 设备，特别是虚拟网络。 您还将了解为什么我们（服务的开发人员）重视用户的反馈。 但首先要说的是。
什么是专有网络？
如今，部署服务有多种选择。 我确信有人仍然将服务器放在管理员办公桌下，尽管我希望这样的故事少一些。
现在服务都在尝试走向公有云，这就是它们与VPC发生冲突的地方。 VPC 是公共云的一部分，它将用户、基础设施、平台和其他功能连接在一起，无论它们位于我们的云中还是云外。 同时，VPC 允许您不必将这些容量暴露到 Internet，它们保留在您的隔离网络中。
从外部看，虚拟网络是什么样的？
对于VPC，我们主要指的是覆盖网络和网络服务，例如VPNaaS、NATaas、LBaas等。所有这些都工作在容错网络基础设施之上，该基础设施已经 在这里，关于哈布雷。
让我们仔细看看虚拟网络及其设备。
考虑两个可用区。 我们提供一个虚拟网络——我们称之为VPC。 事实上，它定义了“灰色”地址的唯一性空间。 在每个虚拟网络中，您可以完全控制可分配给计算资源的地址空间。
该网络是全球性的。 同时，它以称为子网的实体的形式投影到每个可用区域上。 对于每个子网，您分配一个大小为 16 或更小的 CIDR。 每个可用区中可以有多个这样的实体，并且它们之间始终存在透明路由。 这意味着同一 VPC 中的所有资源都可以相互“对话”，即使它们位于不同的可用区。 无需访问互联网，通过我们的内部渠道进行“交流”，“认为”他们在同一个专用网络内。
上图显示了一种典型情况：两个 VPC 在地址中的某处相交。 两者都可以是你的。 例如，一个用于开发，另一个用于测试。 可能只是有不同的用户 - 在这种情况下这并不重要。 每个 VPC 中插入一台虚拟机。
让我们让这个计划变得更糟。 您可以使一台虚拟机同时陷入多个子网。 不仅如此，而且在不同的虚拟网络中。
同时，如果需要将机器暴露到互联网上，可以通过API或UI来完成。 为此，您需要将“灰色”（内部地址）的 NAT 转换配置为“白色”（公共）。 您不能选择“白色”地址，它是从我们的地址池中随机分配的。 一旦您停止使用外部 IP，它就会返回到池中。 您只需为使用“白色”地址的时间付费。
还可以使用 NAT 实例让计算机访问 Internet。 您可以通过静态路由表将流量路由到实例。 我们提供了这样一个案例，因为用户有时需要它，我们也知道。 因此，我们的镜像目录包含一个专门配置的 NAT 镜像。
但即使有现成的 NAT 映像，设置也可能很棘手。 我们知道，对于某些用户来说，这不是最方便的选择，因此最终我们可以一键为所需子网启用 NAT。 此功能仍处于封闭预览访问状态，在社区成员的帮助下进行测试。
从内部看虚拟网络是如何安排的
用户如何与虚拟网络交互？ 网络通过其 API 向外看。 用户访问 API 并使用目标状态。 通过API，用户可以看到一切应该如何安排和配置，同时他可以看到状态，以及实际状态与期望状态的差异有多大。 这是用户的照片。 里面发生了什么？
我们将所需的状态写入 Yandex 数据库并配置 VPC 的不同部分。 Yandex.Cloud 中的覆盖网络基于 OpenContrail 的选定组件，最近被称为 Tungsten Fabric。 网络服务在单个 CloudGate 平台上实施。 在 CloudGate 中，我们还使用了许多开源组件：GoBGP（用于访问控制信息）以及 VPP（用于实现在 DPDK 之上运行的数据路径软件路由器）。
Tungsten Fabric 通过 GoBGP 与 CloudGate 进行通信。 告诉覆盖网络中发生了什么。 反过来，CloudGate 将覆盖网络相互连接并与互联网连接。
现在让我们看看虚拟网络如何解决可扩展性和可用性问题。 让我们考虑一个简单的情况。 可用区XNUMX个，其中创建XNUMX个VPC。 我们部署了一个 Tungsten Fabric 实例，它拉动了数万个网络。 网络与 CloudGate 通信。 正如我们已经说过的，CloudGate 确保它们之间以及与互联网的连接。
假设添加了第二个可用区。 它应该完全独立于第一个而失败。 因此，在第二个可用区中，我们必须安装一个单独的Tungsten Fabric实例。 这将是一个处理覆盖层的独立系统，并且对第一个系统知之甚少。 事实上，我们的虚拟网络的全球可见性创建了我们的 VPC API。 这是他的任务。
如果可用区B中有资源推送到VPC1，则VPC1映射到可用区B。 如果可用区 B 中没有来自 VPC2 的资源，我们不会在该可用区中物化 VPC2。 反过来，由于 VPC3 的资源仅存在于 B 区，因此 VPC3 不存在于 A 区。一切都很简单，符合逻辑。
让我们更深入地了解 Y.Cloud 中的特定主机是如何工作的。 我要注意的主要一点是所有主机的排列方式都是相同的。 我们确保只有必要的最少服务在硬件上运行，其余所有服务都在虚拟机上运行。 我们在基础设施服务的基础上构建高阶服务，同时也利用云来解决一些工程问题，比如在持续集成的框架内。
如果我们查看特定的主机，我们可以看到主机操作系统上运行着三个组件：
- 计算——负责在主机上分配计算资源的部分。
- VRouter 是 Tungsten Fabric 的一部分，用于组织覆盖层，也就是说，它通过底层隧道传输数据包。
- VDisk 是存储虚拟化块。
此外，在虚拟机中推出服务：云基础设施服务、平台服务和客户能力。 客户能力和平台服务始终通过VRouter进行叠加。
基础设施服务可以嵌入覆盖层，但基本上它们希望在底层工作。 在 SR-IOV 的帮助下，它们被插入垫层中。 事实上，我们把卡切割成虚拟网卡（虚拟功能），推入基础设施虚拟机中，这样就不会损失性能。 例如，相同的 CloudGate 作为这些基础设施虚拟机之一启动。
现在我们已经描述了虚拟网络的全局任务和云的基本组件的结构，让我们看看虚拟网络的不同部分到底是如何相互作用的。
我们在系统中区分了三个层：
- 配置平面 - 设置系统的目标状态。 这是用户通过 API 进行配置的内容。
- 控制平面 - 提供用户定义的语义，即将数据平面状态变为用户在配置平面中描述的状态。
- 数据平面——直接处理用户的数据包。
正如我上面所说，这一切都始于用户或内部平台服务来到 API 并描述某个目标状态这一事实。
该状态立即写入 Yandex 数据库，通过 API 返回异步操作 ID，并启动我们的内部机制以返回用户想要的状态。 配置任务转到 SDN 控制器并告诉 Tungsten Fabric 在覆盖层中做什么。 例如，它们保留端口、虚拟网络等。
Tungsten Fabric 中的配置平面将所需的状态发送到控制平面。 通过它，配置平面与主机进行通信，告诉它们很快将会运行什么。
现在让我们看看系统在主机上的样子。 虚拟机有一个插入 VRouter 的网络适配器。 VRouter 是一个核心 Tungsten Fabric 模块，用于查看数据包。 如果某个包已经存在流程，则模块将对其进行处理。 如果没有流量，模块会执行所谓的 punting，即将数据包发送到 usermod 进程。 该进程解析数据包并自行响应（如 DHCP 和 DNS），或者告诉 VRouter 如何处理它。 之后，VRouter 即可处理该数据包。
此外，同一虚拟网络内的虚拟机之间的流量是透明的，不会定向到 CloudGate。 部署虚拟机的主机之间直接通信。 它们对流量进行隧道传输并通过底层相互转发。
控制平面通过 BGP 在可用区域之间相互通信，就像与另一个路由器一样。 它们告诉哪些机器在哪里，以便一个区域中的虚拟机可以直接与其他虚拟机通信。
控制平面与 CloudGate 进行通信。 同样，它报告虚拟机在何处、哪些虚拟机被启动，以及它们拥有哪些地址。 这允许您将外部流量和来自平衡器的流量引导至它们。
离开 VPC 的流量到达 CloudGate，到达数据路径，带有我们插件的 VPP 很快就会被消耗殆尽。 然后，流量被发送到其他 VPC 或外部，发送到通过 CloudGate 本身的控制平面配置的边界路由器。
近期计划
如果我们用几句话总结上面所说的一切，我们可以说 Yandex.Cloud 中的 VPC 解决了两个重要任务：
- 提供不同客户端之间的隔离。
- 将资源、基础设施、平台服务、其他云和本地部署整合到一个网络中。
而为了很好地解决这些问题，就需要在内部架构层面提供可扩展性和容错能力，而VPC就是这么做的。
逐渐地，VPC 获得了功能，我们实现了新功能，我们尝试在用户便利性方面进行改进。 感谢我们社区的成员，一些想法得到了表达并被列入优先列表。
目前，我们近期的计划清单如下：
- VPN 即服务。
- 私有 DNS 实例是用于通过预配置的 DNS 服务器快速设置虚拟机的映像。
- DNS 即服务。
- 内部负载平衡器。
- 添加“白色”IP 地址而不重新创建虚拟机。
应用户的要求，平衡器和为已创建的虚拟机切换 IP 地址的功能已在此列表中。 老实说，如果没有明确的反馈，我们可能会稍后才承担这些功能。 所以我们已经在解决地址问题了。
最初，“白色”IP 地址只能在创建机器时添加。 如果用户忘记执行此操作，则必须重新创建虚拟机。 同样，如有必要，删除外部 IP。 很快就可以打开和关闭公共 IP，而无需重新创建机器。
随意表达您的 其他用户。 您帮助我们改进云并更快地获得重要且有用的功能！
来源： habr.com