设计一个 OpenStack 网络

OpenStack 网络之所以需求复杂，有很多原因。一个主要因素是，许多组件在系统堆栈的不同层级进行交互。数据流也比较复杂。

在 OpenStack 云中，数据在实例之间通过网络流动（称为东西向流量），以及进出系统（称为南北向流量）。物理服务器节点具有与实例网络需求无关的网络需求，并且必须进行隔离以考虑可扩展性。我们建议出于安全目的隔离网络，并通过流量整形来调整性能。

在规划和设计 OpenStack 网络时，您必须考虑许多重要的技术和业务需求

  • 避免硬件或软件厂商锁定。设计不应依赖于厂商网络路由器或交换机的特定功能。

  • 大规模扩展生态系统以支持数百万最终用户。

  • 支持不确定种类的平台和应用程序。

  • 设计经济高效的运营，以利用大规模优势。

  • 确保云生态系统中没有单点故障。

  • 高可用性架构以满足客户 SLA 要求。

  • 能够容忍机架级故障。

  • 最大限度地提高灵活性，以架构未来的生产环境。

考虑到这些要求，我们建议如下

  • 设计三层网络架构，而不是二层网络架构。

  • 设计密集多路径网络核心，以支持多向扩展和灵活性。

  • 使用分层寻址，因为它是在网络生态系统中扩展的可行选择。

  • 使用虚拟网络将实例服务网络流量与管理和内部网络流量隔离。

  • 使用封装技术隔离虚拟网络。

  • 使用流量整形进行性能调整。

  • 使用外部边界网关协议 (eBGP) 连接到互联网上行链路。

  • 使用内部边界网关协议 (iBGP) 展平三层网格上的内部流量。

  • 确定块存储网络的有效配置。

其他网络设计注意事项

在设计以网络为重点的 OpenStack 云时，还有一些其他需要考虑的事项。

冗余网络

您应该进行高可用性风险分析，以确定是否使用冗余交换机，例如机架顶端 (ToR) 交换机。在大多数情况下，使用带有少量备用交换机的小型交换机来更换故障单元，比为整个数据中心配备冗余交换机更经济。由于网络和计算资源易于配置且丰富，应用程序应能容忍机架级中断而不影响正常运行。

研究表明，交换机的平均故障间隔时间 (MTBF) 在 100,000 到 200,000 小时之间。这个数字取决于数据中心中交换机的环境温度。如果冷却和维护得当，这意味着在故障前 11 到 22 年。即使在数据中心通风不良且环境温度高的情况下，MTBF 仍然是 2-3 年。

提供 IPv6 支持

当今最重要的网络主题之一是 IPv4 地址的耗尽。截至 2015 年底，ICANN 宣布最终的 IPv4 地址块已完全分配。因此，IPv6 协议已成为以网络为重点的应用程序的未来。IPv6 显着增加了地址空间，修复了 IPv4 协议中长期存在的问题，并将成为未来以网络为重点的应用程序所必需的。

配置后，OpenStack Networking 支持 IPv6。要启用 IPv6，请在 Networking 中创建一个 IPv6 子网，并在创建安全组时使用 IPv6 前缀。

优化网络性能

在设计支持以网络为重点的应用程序的环境时，分析应用程序对延迟和抖动的容忍度非常重要。某些应用程序，例如 VoIP，对延迟和抖动不太容忍。当延迟和抖动成为问题时，某些应用程序可能需要调整 QoS 参数和网络设备队列，以确保立即排队进行传输或保证最小带宽。由于 OpenStack 当前不支持这些功能，请仔细考虑您选择的网络插件。

服务的地理位置也可能影响应用程序或用户体验。如果应用程序向不同用户提供不同的内容，则必须正确地将连接定向到这些特定位置。在适当的情况下，对于这些情况，请使用多站点安装。

您可以以两种不同的方式实现网络。传统网络 (nova-network) 提供一个带有单个广播域的平面 DHCP 网络。此实现不支持租户隔离网络或高级插件，但它是当前使用多宿主配置实现分布式三层 (L3) 代理的唯一方法。Networking 服务 (neutron) 是官方网络实现，并提供了一个可插拔的架构，支持各种网络方法。其中一些包括仅限二层提供商网络模型、外部设备插件，甚至是 OpenFlow 控制器。

大规模网络成为一组边界问题。二层域的大小取决于域内的节点数量以及实例之间传递的广播流量量。中断二层边界可能需要实施叠加网络和隧道。此决定是在更小的开销或更小的域之间进行权衡。

在选择网络设备时，请注意，仅基于最大的端口密度做出决定通常会带来缺点。聚合交换机和路由器并非都跟上 ToR 交换机的步伐，并且可能导致南北向流量出现瓶颈。因此，大量的下游网络利用率可能会影响上游网络设备，从而影响云服务。由于 OpenStack 当前不提供流量整形或速率限制机制，因此有必要在网络硬件级别实施这些功能。

使用可调谐网络组件

在设计 OpenStack 架构时，当为包括 MTU 和 QoS 在内的网络密集型工作负载设计时，请考虑可配置的网络组件。由于传输大量数据，某些工作负载需要比正常更大的 MTU。在为视频流或存储复制等应用程序提供网络服务时，我们建议您尽可能在 OpenStack 硬件节点和支持网络设备上配置巨型帧。这允许更好地利用可用带宽。在数据包遍历的整个路径上配置巨型帧。如果网络组件无法处理巨型帧，则整个路径将恢复为默认 MTU。

服务质量 (QoS) 也对网络密集型工作负载产生巨大影响，因为它为由于网络性能不佳而具有较高优先级的包提供即时服务。在诸如 VoIP 之类的应用程序中，差异化服务码点是正常运行的近乎要求。您也可以相反地使用 QoS，为混合工作负载防止低优先级但高带宽应用程序（例如备份服务、视频会议或文件共享）阻止其他工作负载所需的带宽。可以将文件存储流量标记为较低的类别，例如尽力而为或拾荒者，以允许更高优先级的流量通过。在云内的区域在地理上分布的情况下，为了对抗延迟或丢包，也可能需要相应地计划实施 WAN 优化。

选择网络硬件

网络架构决定将使用哪些网络硬件。网络软件由所选网络硬件决定。

还有一些微妙的设计影响需要考虑。某些网络硬件（以及网络软件）的选择会影响可以使用哪些管理工具。虽然也有例外；开放网络软件的兴起支持各种网络硬件意味着网络硬件和网络软件之间的关系并非总是如此紧密。

在选择网络硬件时的一些关键考虑因素包括

端口计数

设计将需要具有所需端口计数的网络硬件。

端口密度

网络设计将受到提供所需端口计数所需的物理空间的影响。更高的端口密度是首选的，因为它为计算或存储组件留出了更多的机架空间。这也会导致对故障域和功率密度的考虑。高密度交换机更昂贵，因此不要过度设计网络很重要。

端口速度

网络硬件必须支持提议的网络速度，例如：1 GbE、10 GbE 或 40 GbE（甚至 100 GbE）。

冗余

用户对高可用性的要求和成本考虑因素会影响网络硬件冗余的级别。可以通过添加冗余电源或配对交换机来实现网络冗余。

注意

硬件必须支持网络冗余。

功耗要求

确保物理数据中心为所选网络硬件提供必要的电力。

注意

这对于机架顶端 (ToR) 交换机来说不是问题。这对于叶脊织物中的脊交换机或机房末端 (EoR) 交换机来说可能是一个问题。

协议支持

通过使用诸如 RDMA、SRP、iSER 和 SCST 之类的专用网络技术，可以从单个存储系统获得更高的性能。使用这些技术的具体细节超出了本书的范围。

支持 OpenStack 云的网络硬件架构没有单一的最佳实践。将对网络硬件选择产生重大影响的一些关键因素包括

连接性

OpenStack 云中的所有节点都需要网络连接。在某些情况下，节点需要访问多个网络段。设计必须包含足够的网络容量和带宽，以确保云内的所有通信，包括南北向和东西向流量，都具有足够的可用资源。

可扩展性

网络设计应包含物理和逻辑网络设计，这些设计可以轻松扩展。网络硬件应提供硬件节点所需的适当类型的接口和速度。

可用性

为了确保不会中断对云内节点的访问，我们建议网络架构识别任何单点故障，并提供一定程度的冗余或容错能力。网络基础设施通常涉及使用诸如 LACP、VRRP 或其他协议来实现高度可用的网络连接。同样重要的是要考虑网络对 API 可用性的影响。我们建议在网络架构中设计负载均衡解决方案，以确保云中的 API 和潜在的其他服务具有高度可用性。

选择网络软件

OpenStack Networking (neutron) 为实例提供各种网络服务。还有许多其他网络软件包在管理 OpenStack 组件时可能很有用。一些示例包括

  • 提供负载均衡的软件

  • 网络冗余协议

  • 路由守护程序。