TripleO Routed Networks Deployment (Spine-and-Leaf Clos)¶
https://blueprints.launchpad.net/tripleo/+spec/tripleo-routed-networks-deployment
TripleO 目前使用共享的 L2 网络，因此每个节点都连接到配置网络，以及任何其他共享网络。这大大降低了在裸机上部署的复杂性，因为 DHCP 和 PXE 启动只需通过共享广播域即可完成。这也使得网络交换机配置变得简单，因为只需要配置 VLAN 和端口，而无需动态路由在所有交换机之间增加复杂性。
然而，这种设计存在局限性，并且在达到一定规模后会变得笨拙。随着节点数量的增加，广播、单播和组播 (BUM) 流量也会增加。这种设计还需要所有机架顶端交换机将 VLAN 汇聚到核心交换机，从而将第三层网关集中化，通常位于单个核心交换机上。这会产生在 Clos 架构中不存在的瓶颈。
本规范是对整个问题集的详细描述，并适用于主蓝图。各种实现项的子蓝图也有其各自相关的规范。
问题描述¶
在可能的情况下，现代高性能数据中心网络通常使用路由网络来提高可扩展性和降低故障域。使用路由网络可以优化 Clos（也称为“Spine-and-Leaf”）架构的可扩展性
,=========. ,=========.
| spine 1 |__ __| spine 2 |
'==|\=====\_ \__________________/ _/=====/|=='
| \_ \___ / \ ___/ _/ | ^
| \___ / \ _______ / \ ___/ | |-- Dynamic routing (BGP, OSPF,
| / \ / \ / \ | v EIGRP)
,------. ,------ ,------. ,------.
|leaf 1|....|leaf 2| |leaf 3|....|leaf 4| ======== Layer 2/3 boundary
'------' '------' '------' '------'
| | | |
| | | |
|-[serv-A1]=-| |-[serv-B1]=-|
|-[serv-A2]=-| |-[serv-B2]=-|
|-[serv-A3]=-| |-[serv-B3]=-|
Rack A Rack B
在上面的图中，每个服务器都通过以太网绑定连接到两个机架顶端 Leaf 交换机，这些交换机被集群化并配置为虚拟交换机底板。每个 Leaf 交换机都连接到每个 Spine 交换机。在每个机架内，所有服务器共享一个第二层域。子网是本地的机架，默认网关是机架顶端的虚拟交换机对。Leaf 交换机和 Spine 交换机之间的动态路由允许机架之间的东西向流量。
这只是一个路由网络架构的示例。第三层路由也可以只在 Spine 交换机上完成，或者甚至可能存在位于机架顶端交换机和路由核心之间的分布层交换机。我们试图实现的主要特点是将本地系统隔离在第二层域内，并在域之间进行路由。
在共享的第二层架构中，Spine 交换机通常必须以主动/被动模式运行，才能充当单个共享 VLAN 的第三层网关。所有 Leaf 交换机必须连接到活动交换机，并且南北带宽的上限是与活动交换机的连接，因此可扩展性存在上限。Clos 拓扑受到青睐，因为它提供了水平可扩展性。可以添加额外的 Spine 交换机以增加东西向和南北向带宽。交换机之间的等成本多路径路由可确保所有链路同时利用。如果 Spine 交换机上的所有端口都已满，可以添加一个额外的层级来连接额外的 Spine，每个 Spine 都有其自己的一组 Leaf 交换机，从而提供超大规模的可扩展性。
每个网络设备都可以为维护而从服务中移除，而不会使整个网络离线。这种拓扑结构还允许在没有物理环路或生成树的情况下配置交换机，因为冗余链路是通过绑定或通过具有相等度量的多个第三层上行链路提供的。使用这种架构的优点包括
广播、未知单播和组播 (BUM) 流量的域减少。
故障域减少。
地理分离。
IP 地址和机架位置之间的关联。
通过第三层路由使用等成本多路径转发 (ECMP) 而不是专有的“fabric”实现更好的跨厂商多路径转发支持。
这种拓扑结构与 TripleO 目前采用的共享一切方法有很大不同。
问题描述¶
由于这是一个复杂的主题，将问题分解为组成部分会更容易，基于它们影响 TripleO 的哪个部分
问题 #1：TripleO 在 Undercloud 配置网络 (ctlplane) 上使用 DHCP/PXE。
Undercloud 上的 Neutron 目前不支持 DHCP 中继和多个 L2 子网，因为它直接在配置网络上执行 DHCP/PXE。
可能的解决方案、想法或方法
修改 Ironic 和/或 Neutron 以支持 dnsmasq 配置中的多个 DHCP 范围，使用运行在机架顶端交换机上的 DHCP 中继，接收 DHCP 请求并将其转发到 Undercloud 上的 dnsmasq。目前有一个补丁正在进行中以支持这一点 [11]。
修改 Neutron 以支持 DHCP 中继。目前有一个补丁正在进行中以支持这一点 [10]。
当前，如果向网络添加一个子网，Neutron DHCP 代理将拾取更改并在 dnsmasq 中正确配置单独的子网。例如，在将第二个子网添加到 ctlplane 网络后，Neutron 的 dnsmasq 实例的启动命令如下
dnsmasq --no-hosts --no-resolv --strict-order --except-interface=lo \
--pid-file=/var/lib/neutron/dhcp/aae53442-204e-4c8e-8a84-55baaeb496cf/pid \
--dhcp-hostsfile=/var/lib/neutron/dhcp/aae53442-204e-4c8e-8a84-55baaeb496cf/host \
--addn-hosts=/var/lib/neutron/dhcp/aae53442-204e-4c8e-8a84-55baaeb496cf/addn_hosts \
--dhcp-optsfile=/var/lib/neutron/dhcp/aae53442-204e-4c8e-8a84-55baaeb496cf/opts \
--dhcp-leasefile=/var/lib/neutron/dhcp/aae53442-204e-4c8e-8a84-55baaeb496cf/leases \
--dhcp-match=set:ipxe,175 --bind-interfaces --interface=tap4ccef953-e0 \
--dhcp-range=set:tag0,172.19.0.0,static,86400s \
--dhcp-range=set:tag1,172.20.0.0,static,86400s \
--dhcp-option-force=option:mtu,1500 --dhcp-lease-max=512 \
--conf-file=/etc/dnsmasq-ironic.conf --domain=openstacklocal
路由器信息被放入 dhcp-optsfile 中，以下是 /var/lib/neutron/dhcp/aae53442-204e-4c8e-8a84-55baaeb496cf/opts 的内容
tag:tag0,option:classless-static-route,172.20.0.0/24,0.0.0.0,0.0.0.0/0,172.19.0.254
tag:tag0,249,172.20.0.0/24,0.0.0.0,0.0.0.0/0,172.19.0.254
tag:tag0,option:router,172.19.0.254
tag:tag1,option:classless-static-route,169.254.169.254/32,172.20.0.1,172.19.0.0/24,0.0.0.0,0.0.0.0/0,172.20.0.254
tag:tag1,249,169.254.169.254/32,172.20.0.1,172.19.0.0/24,0.0.0.0,0.0.0.0/0,172.20.0.254
tag:tag1,option:router,172.20.0.254
以上选项文件将导致为单独的 IP 子网提供单独的路由器。此外，Neutron 似乎在同一网络的其他子网的路由方面“做正确的事情”。我们可以看到提供了“classless-static-route”选项，指向默认路由和同一 Neutron 网络上的其他子网。
为了修改 Ironic-Inspector 以使用多个子网，我们需要扩展 instack-undercloud 以支持网络段。目前有一个补丁正在审核中，以支持 instack undercloud 中的段 [0]。
潜在的解决方法
一种可能性是使用替代方法进行 DHCP/PXE 启动，例如直接在路由器上使用 DHCP 配置，或者配置远程网络上的主机提供 DHCP 和 PXE URL，然后将路由作为 DHCP 响应的一部分提供给 ironic-conductor 和元数据服务器。
对于进行测试或开发的小组来说，配置交换机上的 DHCP 中继并不总是可行的。对于 Spine-and-Leaf 的概念验证实现，我们可能希望将所有配置网络汇聚回 Undercloud。这将允许 Undercloud 为所有网络提供 DHCP，而无需特殊的交换机配置。在这种情况下，Undercloud 将充当子网/VLAN 之间的路由器。这应被视为一个小规模解决方案，因为它不如 DHCP 中继可扩展。dnsmasq 的配置文件无论所有子网都是本地的还是远程的都是相同的，但 dnsmasq 可能需要侦听多个接口（今天它只侦听 tap-XXX）。dnsmasq 进程当前以 --bind-interface=tap-XXX 运行，但该进程需要以绑定到多个接口或使用 --except-interface=lo 和绑定到命名空间的多个接口来运行。
对于概念验证部署以及测试环境，在 Undercloud 上运行 DHCP 中继并汇聚所有配置 VLAN 回到 Undercloud 可能会有意义。这将允许 dnsmasq 侦听 tap 接口，并将 DHCP 请求转发到 tap 接口。这种方法的缺点是 Undercloud 需要在每个汇聚接口上拥有 IP 地址。
另一种选择是配置专用的主机或 VM 用作多个 VLAN 上的 DHCP 中继和路由器，所有这些都汇聚到中继/路由器主机，从而像路由交换机一样运行。
问题 #2：Neutron 用于跨多个 L2 域分割网络的模型使用段对象来允许将多个子网分配给同一网络。此功能需要集成到 Undercloud 中。
可能的解决方案、想法或方法
在 undercloud 上实现 Neutron 段。
Neutron 段规范 [1] 提供了一个我们可以用来建模路由网络的模式。通过实现对网络段的支持，我们可以为路由子网分配 Ironic 节点。这允许我们继续使用 Neutron 进行 IP 地址管理，因为端口由 Neutron 分配并在 Undercloud 上的 Neutron 数据库中跟踪。请参阅下面的方法 #1。
多个 Neutron 网络（每机架 1 套），以模拟所有 L2 段。
通过在每个机架中使用不同的网络集，我们可以灵活地在每个机架的基础上使用不同的网络架构。每个机架可以拥有自己的一组网络，我们不再需要在所有机架中提供所有网络。此外，分割数据中心架构自然会在每个站点拥有不同的网络集，因此这种方法是有意义的。这在下面的方法 #2 中详细说明。
每个 Neutron 网络上的多个子网。
这可能是配置的最佳方法，因为 Neutron 已经能够使用多个子网处理 DHCP 中继作为同一网络的一部分。此外，这允许在配置和过云网络之间进行清晰的分离（例如，两个不同数据中心的外部网络）。这在下面的方法 #3 中更详细地介绍。
使用另一个系统进行 IPAM，而不是 Neutron。
虽然我们可以使用数据库、平面文件或其他方法来跟踪 IP 地址，但 Neutron 作为 IPAM 后端提供了许多集成优势。Neutron 集成了 DHCP、硬件交换机端口配置（通过插件）、Ironic 中的集成以及 IPv6 支持等其他功能。由于需要替换 Neutron 和 Neutron DHCP 服务器 (dnsmasq) 的工作量太大，因此这被认为不可行。
问题 #2 的方法
方法 1（在 Undercloud 上实现 Neutron 段）
Neutron 段模型提供了一个在 Neutron 中允许我们建模路由网络的模式。使用多个子网提供了我们所需的灵活性，而无需创建指数级的更多资源。我们将创建今天所做的相同的配置网络，但使用与不同的路由子网关联的多个段。此方法的缺点是，它不可能用多个 IP 子网表示网络 VLAN（Neutron 在技术上支持每个端口多个子网）。目前 TripleO 仅支持每个隔离网络一个子网，因此这不应该成为问题。
方法 2（多个 Neutron 网络（每机架 1 套），以模拟所有 L2 段）
我们将使用多个网络来表示多个 L2 域中的隔离网络。一个难点是，虽然 Neutron 将为给定网络中的多个子网配置多个路由，但我们需要能够配置静态 IP 和路由，并且能够在初始部署后通过添加额外的子网来扩展网络。
由于我们使用 Heat 模板和 os-net-config 的组合来控制主机节点上的地址和路由，因此可以使用静态路由到超网来提供 L2 邻接。这种方法仅适用于非配置网络，因为我们依赖 Neutron DHCP 服务器提供到相邻子网的路由以进行配置网络。
示例：假设为 Internal API 网络提供 2 个子网：172.19.1.0/24 和 172.19.2.0/24。我们希望所有 Internal API 流量都遍历控制器和远程计算节点上的 Internal API VLAN。Internal API 网络在两个节点上使用不同的 VLAN，因此我们需要主机上的路由指向 Internal API 网关而不是默认网关。这可以通过指向每个子网上的本地网关（例如，分别为 172.19.1.1 和 172.19.2.1）的超网路由来提供。这可以在 os-net-config 中表示如下
-
type: interface
name: nic3
addresses:
-
ip_netmask: {get_param: InternalApiIpSubnet}
routes:
-
ip_netmask: {get_param: InternalApiSupernet}
next_hop: {get_param: InternalApiRouter}
其中 InternalApiIpSubnet 是本地子网上的 IP 地址，InternalApiSupernet 是‘172.19.0.0/16’，InternalApiRouter 是 172.19.1.1 或 172.19.2.1，具体取决于主机属于哪个本地子网。
最终结果是每个主机都有一组按功能隔离的 IP 地址和路由。为了使回程流量也按功能隔离，必须在两个主机上都存在类似的路由，指向本地子网上的本地网关，指向包含所有 Internal API 子网的更大的超网。
缺点是我们需要要求正确的超网，这可能会导致使用更大的 IP 地址块来提供充足的增长空间。例如，在上面的示例中，为 Internal API 网络预留了整个 /16 网络。如果本地子网的数量不会超过 64 个，则可以将其更改为更合理的空间，例如 /18 等。这对于本地 IPv6 来说问题较小，因为 IPv4 存在稀缺性。
方法 3（每个 Neutron 网络上的多个子网）
我们将用于配置网络的方法是在每个网络上使用多个子网，使用 Neutron 段。这将允许我们利用 Neutron 处理 DHCP 中继的能力。DHCP 服务器将通过 DHCP 提供必要的路由，直到节点配置了静态 IP 地址，然后进行部署。
问题 #3：Ironic 内省 DHCP 尚未支持 DHCP 中继
这使得在主机不在控制器相同的 L2 域中时进行内省变得困难。补丁已合并或正在审核中以支持 DHCP 中继。
可能的解决方案、想法或方法
已合并一个补丁，以支持 dnsmasq PXE 过滤器驱动程序。这将允许我们在使用 DHCP 中继时支持选择性 DHCP（数据包不是来自主机的 MAC，而是来自交换机的 MAC）[12]。
已合并一个补丁到 puppet-ironic，以支持 Ironic Inspector 的多个 DHCP 子网 [13]。
目前有一个补丁正在审核中，以在 instack-undercloud 脚本中添加对配置网络多个子网的支持 [14]。
有关解决方案的更多信息，请参阅 tripleo-routed-networks-ironic-inspector 蓝图 [5] 和规范 [6]。
问题 #4：配置网络的 IP 地址在生产环境中需要是静态 IP。
可能的解决方案、想法或方法
Dan Prince 在 Newton 中编写了一个补丁 [9]，用于在部署后将 ctlplane 网络地址转换为静态地址。这需要重构以支持路由器上的多个配置子网。
解决方案实施
这项工作已经完成并合并用于遗留用例。在初始部署期间，节点通过 DHCP 接收其 IP 地址，但在 Heat 部署期间会调用 os-net-config 脚本，该脚本为 NIC 写入具有静态 IP 的静态配置文件。
这项工作需要重构以支持从适当的子网分配 IP，但这项工作将是下面问题 #6 和 #7 中列出的 TripleO Heat 模板重构的一部分。
对于指定 IP 的部署模型（ips-from-pool-all.yaml），我们需要开发一个可以在多个部署子网上指定控制平面 IP 的模型。这可能发生在 TripleO 中启用路由网络工作的后续周期中。有关更多信息，请参阅 tripleo-predictable-ctlplane-ips 蓝图 [7] 和规范 [8]。
问题 #5：Heat 对路由网络的支持
Neutron 路由网络扩展仅在最近的版本中添加，并且存在对 TripleO Heat 模板的依赖关系。
可能的解决方案、想法或方法
将所需的对象添加到 Heat。至少，我们可能需要添加
OS::Neutron::Segment，它代表第二层段，OS::Neutron::Network将更新以支持l2-adjacency属性，OS::Neutron::Subnet和OS::Neutron:port将扩展以支持segment_id属性。
解决方案实施
Heat 现在支持 OS::Neutron::Segment 资源。例如
heat_template_version: 2015-04-30
...
resources:
...
the_resource:
type: OS::Neutron::Segment
properties:
description: String
name: String
network: String
network_type: String
physical_network: String
segmentation_id: Integer
这项工作已在 Heat 中完成，审查如下 [15]。
问题 #6：静态 IP 分配：从正确的子网选择静态 IP
某些角色，例如 Compute，可能可以放置在任何子网中，但我们需要将某些角色放置在相同的 L2 域内。例如，提供 Neutron 服务的任何角色都需要所有控制器位于相同的 L2 域内，才能使 VRRP 正常工作。
网络接口将使用创建 os-net-config 配置文件的模板进行配置。写入每个节点配置的 IP 地址需要位于每个主机的正确子网中。为了使 Heat 从正确的子网分配端口，我们需要一个主机到子网的映射。
可能的解决方案、想法或方法
这最简单的实现可能是角色/索引到一组子网的映射，以便 Heat 知道 Controller-1 在子网集 X 中，Compute-3 在子网集 Y 中。
我们可以将特定的子网与角色关联，然后每个 L2 域使用一个角色（例如，每个机架）。
角色和模板应该重构以允许在与角色关联的子网内动态 IP 分配。我们可能希望评估将路由子网存储在 Neutron 中，使用仍在开发中的路由网络扩展的可能性。这将提供额外的灵活性，但可能不需要在每个机架中实现单独的子网。
可扩展的长期解决方案是在内省期间映射主机所在的子网。如果我们可以识别每个接口的正确子网，那么我们可以将其与来自正确分配池的 IP 地址相关联。这将具有不需要静态角色到节点到子网映射的优势。为了做到这一点，需要在 Ironic 和 Neutron 之间进行额外的集成（使 Ironic 意识到每个网络上的多个子网，并能够在内省期间进行关联）。
解决方案实施
上述解决方案 1 和 2 已在“可组合角色”系列补丁中实现 [16]。初始实现使用不同的 L2 域的单独 Neutron 网络。这些模板负责分配用于数据平面和云平台控制平面的隔离 VLAN，但不解决配置网络。未来的工作可能会将非配置网络重构为使用段，但目前非配置网络必须使用不同的网络来区分不同的角色。
Ironic 自动发现可能允许我们确定每个节点所在的子网，而无需手动输入。需要更多的工作来自动化此过程。
问题 #7：隔离网络需要静态路由以确保使用正确的 VLAN
为了继续使用隔离网络模型，需要在每个节点上放置路由，以将流量引导到正确的 VLAN 接口。当 os-net-config 首次运行时会写入路由，但可能会更改。我们不能仅仅依赖于指向其他子网的特定路由，因为随着机架的添加或移除，子网的数量会增加或减少。与其试图处理不断变化的路由，我们应该使用不会更改的静态路由，以避免对正在运行的系统造成破坏。
可能的解决方案、想法或方法
要求使用超网用于各种网络组。例如，所有内部 API 子网都将是超网的一部分，例如可以使用 172.17.0.0/16，并分解为许多较小的子网，例如 /24。这将简化路由，因为只需要一个指向 172.17.0.0/16 的路由，指向位于 172.17.x.0/24 网络上的本地路由器。
修改 os-net-config，以便可以在不重启接口的情况下更新路由，然后在缩放发生时在所有节点上运行 os-net-config。已经考虑并放弃了此功能的审查 [3]。确定该补丁有可能导致不稳定。
os-net-config 为每个接口配置静态路由。如果我们可以保持路由简单（每个功能网络一个路由），那么我们将能够像今天一样将流量隔离到功能 VLAN 上。
让 os-net-config 在更新以及部署时运行将是对现有工作流程的更改，但如果这是一个非影响事件（接口不必重启），那可能没问题。
稍后，应考虑使用动态路由的可能性，因为它减少了用户错误的可能，并且更适合集中管理。SDN 解决方案是一种提供这种方法的方式，或者可以考虑其他方法，例如设置 OVS 隧道。
提议的变更¶
下面讨论了拟议的更改。
概述¶
为了为部署提供 spine-and-leaf 网络，必须对 TripleO 进行一些更改
替代方案¶
此处概述的方法非常规定，即必须提前知道网络，并且必须从适当的池中选择 IP 地址。这是由于对 Heat 提供的静态 IP 地址的依赖。
另一种方法是在所有接口上的所有主机上使用 DHCP 服务器分配 IP 地址。这将简化 Heat 模板和环境文件中的配置。不幸的是，这是 TripleO 的原始方法，它被最终用户认为不足，他们希望 IP 地址稳定，并且不想对 DHCP 有外部依赖性。
另一种方法是使用网络交换机基础设施中的 DHCP 服务器功能来 PXE 启动系统，然后在 PXE 启动完成后通过 DHCP 分配静态 IP 地址。这种方法仅解决部分要求：网络启动。它不能解决希望在每个网络上拥有静态 IP 地址的愿望。可以通过某种节点映射来做到这一点，但是这种方法不像以编程方式确定 IP 地址那样可扩展，因为它仅适用于固定数量的主机。我们希望保留使用 Neutron 作为 IP 地址管理 (IPAM) 后端的能力，理想情况下。
另一种考虑的方法是简单地将所有网络回传到 Undercloud，以便 dnsmasq 可以直接响应 DHCP 请求，而不是需要 DHCP 中继。不幸的是，一些大型运营商已经确定这不可接受，因为他们的网络架构大量使用路由器通过 L2 分段。这在 VLAN 之间存在地理隔离的情况下也无法正常工作，例如在拆分站点部署中。
安全影响¶
spine-and-leaf 与标准隔离网络之间的主要区别在于，各种子网通过路由器连接，而不是完全隔离。这意味着如果没有路由器上的适当 ACL，应该私有的网络可能会对外流量开放。
应该在文档中解决这个问题，并强调应实施 ACL 以防止不受欢迎的网络流量。例如，内部 API 网络是敏感的，因为数据库和消息队列服务在该网络上运行。它应该与外部连接隔离。如果使用超网，可以很容易地实现这一点，例如，如果所有内部 API 子网都是 172.19.0.0/16 超网的一部分，则 ACL 规则将仅允许内部 API IP 之间的流量（这是一个可以应用于任何内部 API VLAN 或作为全局 ACL 的简化示例）
allow traffic from 172.19.0.0/16 to 172.19.0.0/16
deny traffic from * to 172.19.0.0/16
其他最终用户影响¶
使用 spine-and-leaf 部署将需要额外的参数来提供路由信息和所需的多个子网。这将需要记录。此外，可能需要更新验证脚本以确保配置已验证，并且云平台主机之间存在适当的连接。
性能影响¶
与今天通过第二层进行的许多流量将在这种设计中跨越第三层路由边界。这会增加一些最小的延迟和开销，尽管在实践中，差异可能并不明显。一个重要的考虑因素是，路由器在其上行链路上的提交不能过多，并且必须监视路由器以确保它们不会成为瓶颈，尤其是在使用复杂的访问控制列表时。
其他部署者影响¶
spine-and-leaf 部署比仅使用一组 VLAN 的部署更难进行故障排除。部署者可能需要更多的网络专业知识，或者在某些情况下可能需要专门的网络工程师来进行故障排除。
开发人员影响¶
spine-and-leaf 在 virt 环境中不容易测试。这应该是可行的，但由于设置 libvirt 桥接和路由的复杂性，我们可能希望为虚拟环境提供 spine-and-leaf 的模拟。这可能涉及在 Undercloud 上构建多个 libvirt 桥接并在它们之间进行路由，或者可能涉及在 virt-host 上使用 DHCP 中继以及路由来模拟完整的路由交换机。需要制定开发和测试计划，因为不能期望每个开发人员都有一个路由环境来工作。由于初始工作将在裸机上完成，因此可能需要一些时间来开发路由虚拟环境。
实现¶
负责人¶
- 主要负责人
Dan Sneddon <dsneddon@redhat.com>
Approver(s)¶
- 主要审批人
Emilien Macchi <emacchi@redhat.com>
工作项¶
将静态 IP 分配添加到控制平面 [完成]
修改 Ironic Inspector
dnsmasq.conf生成以允许导出多个 DHCP 范围，如问题 #1 和问题 #3 中所述。评估 Neutron 中的路由网络工作，以确定它是否需要用于 spine-and-leaf，如问题 #2 中所述。
将 OS::Neutron::Segment 和 l2-adjacency 支持添加到 Heat，如问题 #5 中所述。这可能是 spine-and-leaf 的依赖项，也可能不是，具体取决于工作项 #3 的结果。
修改 Ironic-Inspector 服务以记录主机到子网的映射，可能在内省期间，以解决问题 #6。
将参数添加到 Heat 中的隔离网络模型，以支持单个子网的超网路由，如问题 #7 中所述。
修改 Heat 中的隔离网络模型以支持多个子网，如问题 #8 中所述。
添加对 os-net-config NIC 模板的支持，以设置超网路由，如问题 #2 的拟议解决方案中所述。
实施对控制器上 iptables 的支持，以减轻 API 潜在地可以通过远程路由访问。或者，记录使用路由器上的 ACL 进行缓解的程序。
记录测试程序。
修改 tripleo-docs 中的文档，以涵盖 spine-and-leaf 架构。
Implementation Details¶
工作流程
操作员配置 DHCP 网络和 IP 地址范围
操作员导入 baremetal instackenv.json
当进行内省或部署时，DHCP 服务器通过 DHCP 中继从裸机主机接收 DHCP 请求
如果节点尚未进行内省，则使用内省池中的 IP 地址*和 inspector PXE 启动镜像进行回复
如果节点已经过内省，则服务器假定这是一次部署尝试，并使用 Neutron 端口 IP 地址和 overcloud-full 部署镜像进行回复
Heat 模板将被处理，生成 os-net-config 模板，并运行 os-net-config 以从正确的子网分配静态 IP，以及通过路由器网关地址到其他子网的路由。
对于每个配置子网，内省池将不同。
在使用 spine-and-leaf 架构时，DHCP 服务器需要根据通过段路由器转发的 DHCP 中继数据包中包含的信息，在适当的子网上提供内省 IP 地址。dnsmasq 会自动将转发请求的路由器的网关地址 (GIADDR) 与接收到 DHCP 请求的子网匹配，并使用适合该子网的 IP 和网关进行回复。
上述 DHCP 服务器工作流程应允许在多个子网上配置 IP。
依赖项¶
可能存在对 Neutron 路由网络的依赖。在全面评估是否仅使用每个网络的多个子网来表示 spine-and-leaf 架构之前，这一点尚不清楚。
对于生产环境中的 spine-and-leaf 部署，将依赖于执行 DHCP 中继服务的路由交换机。
测试¶
为了正确测试此框架，我们需要建立至少一个部署 spine-and-leaf 的 CI 测试。如本规范中所讨论的，为了测试此功能，不必拥有完整的路由裸机环境，尽管在虚拟环境（如 OVB）中使其工作需要一些工作。
对于裸机测试，将所有 VLAN 中继回 Undercloud 即可，然后在 Undercloud 上运行 DHCP 代理以接收所有请求并将其转发到 br-ctlplane，dnsmasq 在其中侦听。这将替代运行 DHCP 中继的路由器。对于 Neutron DHCP，可能需要对 iptables 规则进行一些修改，以确保从 overcloud 节点的所有 DHCP 请求都由 DHCP 代理和/或在 dhcp-agent 命名空间中运行的 Neutron dnsmasq 进程接收。
文档影响¶
需要记录设置开发环境的步骤，并且有一项工作项目提到了此要求。
TripleO 文档需要更新，以包含在 spine-and-leaf 环境中部署的详细说明，包括环境设置。涵盖交换机配置的具体厂商实现超出本范围，但应包含所需配置选项的特定概述，例如启用 DHCP 中继（也称为“helper-address”）并将 Undercloud 设置为接收 DHCP 请求的服务器。
TripleO 文档的更新还必须包含关于在部署之前要做的 IP 寻址选择的详细讨论。如果使用超网进行网络隔离，则需要一个良好的 IP 寻址计划，以确保未来的可扩展性。
