网络虚拟化功能云

设计模型

需求

组件框图

网络优先的云示例

一家组织设计了一个大规模的基于云的 Web 应用程序。该应用程序以爆发行为水平扩展，并产生大量的实例数量。该应用程序需要 SSL 连接以保护数据，并且不得丢失到单个服务器的连接状态。

下图描绘了此工作负载的示例设计。在此示例中，硬件负载均衡器提供 SSL 卸载功能，并连接到租户网络，以减少地址消耗。此负载均衡器链接到路由架构，因为它为应用程序提供 VIP 服务。路由器和负载均衡器使用应用程序的租户网络的 GRE 隧道 ID 以及租户子网内的 IP 地址，但位于地址池之外。这是为了确保负载均衡器无需消耗公共 IP 地址即可与应用程序的 HTTP 服务器进行通信。

由于会话在关闭之前一直存在，因此路由和交换架构提供高可用性。交换机与每个超visor 以及彼此网格连接，并提供 MLAG 实现，以确保 Layer-2 连接不会失败。路由器使用 VRRP 并与交换机完全网格连接，以确保 Layer-3 连接。由于 GRE 提供覆盖网络，因此存在 Networking 并使用 GRE 隧道模式下的 Open vSwitch 代理。这确保了所有设备都可以访问所有其他设备，并且您可以为私有寻址链接到负载均衡器创建租户网络。

../_images/Network_Web_Services1.png

Web 服务架构有很多选项和可选组件。因此，它可以适应大量的其他 OpenStack 设计。但是，需要到位几个关键组件来处理大多数 Web 规模工作负载的性质。您需要以下组件

  • OpenStack 控制器服务（镜像服务、身份服务、网络服务以及支持服务，如 MariaDB 和 RabbitMQ）

  • 运行 KVM hypervisor 的 OpenStack Compute

  • OpenStack 对象存储

  • 编排服务

  • 遥测服务

除了常规的身份服务、计算服务、镜像服务和对象存储组件之外，我们建议使用编排服务组件来处理工作负载的适当扩展，以适应需求。由于需要自动扩展，该设计包括遥测服务。Web 服务在负载方面往往是突发的，具有非常明确的峰值和低谷使用模式，并且因此可以从基于流量自动扩展实例中受益。在网络级别，分割网络配置与数据库驻留在私有租户网络上配合得很好，因为这些数据库不会发出大量的广播流量，并且可能需要与其他数据库互连以获取内容。

负载均衡

负载均衡跨多个实例分配请求。此工作负载可以很好地水平扩展到大量的实例。这使得实例无需使用公开路由的 IP 地址，而是依赖负载均衡器来提供全局可访问的服务。其中许多服务不需要直接服务器返回。这有助于规模化时的地址规划和利用，因为只有虚拟 IP (VIP) 必须是公开的。

覆盖网络

覆盖功能设计包括 OpenStack Networking 在 Open vSwitch GRE 隧道模式下。在这种情况下，Layer-3 外部路由器与 VRRP 配对，交换机与 MLAG 的实现配对，以确保您不会失去与上游路由基础设施的连接。

性能调优

此工作负载的网络级别调优很少。 服务质量 (QoS) 适用于这些工作负载，具体取决于现有策略，提供一个中间类选择器。它高于最佳努力队列，但低于 Expedited Forwarding 或 Assured Forwarding 队列。由于这种类型的应用程序生成具有较长持续时间连接的较大数据包，因此您可以优化长持续时间 TCP 的带宽利用率。正常的带宽规划适用于此处，涉及基准测试会话的使用量乘以预期并发会话数量以及开销。

网络功能

网络功能是一个广泛的类别，但涵盖了支持系统其余部分的网络的 workload。这些 workload 往往由大量的小数据包组成，这些数据包的生命周期很短，例如 DNS 查询或 SNMP 陷阱。这些消息需要快速到达，并且不能容忍数据包丢失，因为它们可能数量非常大。对于这种类型的 workload，需要考虑一些额外的因素，这可能会改变从 hypervisor 级别到配置。对于每个用户生成 10 个 TCP 会话，每个流的平均带宽为每秒 512 千字节，并且预计同时用户数为一万，预计带宽计划约为每秒 4.88 千兆位。

此配置的支持网络需要低延迟和均匀分布的可用性。此 workload 从服务消费者附近拥有本地服务中受益。同时采用多站点方法，并部署许多应用程序副本以尽可能接近消费者来处理负载。由于这些应用程序独立运行，因此不需要运行覆盖网络来互连租户网络。覆盖网络还具有在快速流设置方面表现不佳的缺点，并且可能因大量的小数据包而产生过多的开销，因此我们不建议使用它们。

对于某些 workload 来说，QoS 是可取的，以确保交付。DNS 对其他服务的加载时间有重大影响，需要可靠并提供快速响应。在上游设备中配置规则，以对 DNS 应用更高的类选择器，以确保更快的交付或在排队算法中获得更好的位置。

云存储

OpenStack 环境的另一个常见用例是提供基于云的文件存储和共享服务。您可能认为这是一个存储重点的用例，但其网络侧需求使其成为一个网络重点的用例。

例如，考虑一个云备份应用程序。此 workload 具有两个特定的行为会影响网络。由于此 workload 是一种面向外部的服务和内部复制应用程序，因此它同时具有 南北流量 和 东西流量 考虑因素

南北流量

当用户上传和存储内容时，该内容会移动到 OpenStack 安装中。当用户下载此内容时，该内容会从 OpenStack 安装中移动出去。由于此服务主要作为备份运行，因此大部分流量会向南进入环境。在这种情况下，配置网络以不对称向下游是有益的，因为进入 OpenStack 安装的流量大于离开安装的流量。

东西流量

可能完全对称。由于复制源自任何节点，并且可能根据算法将多个其他节点作为目标，因此流量在任何特定方向上具有更大体积的可能性较小。但是，此流量可能会干扰南北流量。

../_images/Network_Cloud_Storage2.png

此应用程序优先考虑南北流量而非东西流量：南北流量涉及面向客户的数据。

在这种情况下，网络设计不太依赖于可用性，而更多地依赖于能够处理高带宽。因此，以牺牲冗余链路为代价来绑定这些连接是有益的。这会增加可用带宽。此外，配置路径中的所有设备，包括 OpenStack，以生成和传递巨型帧也是有益的。