第 3 章 资源配置
资源配置是指为应用准备好随时可用的虚拟或物理资源的过程，包含人工操作组件(机架和连接设备)以及引导组件(配置资源如何引导到"就绪"状态)。资源配置发生在首次部署云的时候，即对资源进行初始化，但随着时间的推移，由于添加新资源、删除或者升级旧资源，配置的资源也会随之改变。
资源配置的目标是零接触(zero-touch)，由于硬件资源天然需要人工操作，因此是不可能的(我们稍后讨论分配虚拟资源的问题)。实际上，我们的目标是尽量减少物理连接设备之外所需配置步骤的数量和复杂性，请记住，我们需要配置的是从供应商那购买的商品硬件，而不是已经准备好的即插即用设备。
当我们从虚拟资源(例如，在商业云上实例化虚拟机)构建云时，"机架和连接"步骤是通过一系列 API 调用来完成的，而不需要技术人员亲自动手。当然，我们希望将激活虚拟基础设施所需的一系列调用都自动化，这就产生了被称为"基础设施即代码(Infrastructure-as-Code)"的方法，这是第二章中介绍的"配置即代码(Configuration-as-Code)"概念的特殊情况。一般想法是用一种可"执行"的声明式格式记录基础架构到底是什么样子的以及如何配置。我们使用 Terraform 作为"基础设施即代码"的开源方法。
当云由虚拟资源和物理资源组合构建(就像 Aether 这样的混合云)时，需要一种无缝的方式来容纳两者。为此，我们的方法是首先在硬件资源上覆盖一个逻辑结构(logical structure) ，使其大致相当于我们从商业云提供商获得的虚拟资源，这将产生类似图 11 所示的混合场景。我们使用 NetBox 作为我们的开源解决方案，在物理硬件上分层这个逻辑结构，NetBox 还帮助我们解决跟踪实物库存的需求。
图 11. 混合云中的资源配置，包括物理资源和虚拟资源。
注意，图 11 中右边显示的 Provisioning API 不是 NetBox API，Terraform 不直接与 NetBox 交互，而是与 3.1 节中介绍的硬件配置流程工件交互。考虑这一问题的方法是，将硬件引导到"就绪"状态的任务涉及安装和配置若干个共同构成云平台的子系统，Terraform 基于我们在 3.1 节末尾介绍的 API 与该平台交互。
本章从提供物理基础设施开始，介绍图 11 的两个方面。我们的方法是专注于初次配置整个站点的挑战。随着更多细节的出现，我们也将讨论更简单的增量配置单个资源的问题。
3.1 物理基础设施
将硬件设备放置到机架上的过程本质上是人力密集型的，需要考虑散热及电缆管理等因素，这些问题超出了本书范围。相反，我们关注的是"物理/虚拟"的边界，从布线规划开始，技术人员将其作为施工蓝图。这种规划的细节是高度特定于部署的，但我们使用图 12 所示示例帮助说明涉及的所有步骤。该示例通过在企业中部署 Aether 集群为例，有助于强调所需的专用性设施，通过大量规划指定适当的物料清单(BOM, Bill of Materials) ，其中包括了设备型号细节，但具体设备不在讨论范围之内。
图 12. 边缘集群布线规划示例。
图 12 所示蓝图实际上包括两个共享管理交换机和管理服务器的逻辑集群。上层集群对应生产部署，包含 5 台服务器和 2x2 叶脊交换结构。下层集群用于开发，包括两个服务器和一个交换机。这种硬件资源的逻辑分组并不是 Aether 独有的，我们也可以要求商业云提供商提供多个逻辑集群，因此能够对物理资源进行相同操作是很自然的需求。
除了遵循这个蓝图，技术人员还将物理基础设施的实际数据输入数据库中，以用于后续配置步骤，后面我们将详细介绍。
3.1.1 文档基础设施
在数据库中记录物理基础设施的逻辑结构是我们跨越物理到虚拟鸿沟的方式，涉及到为所收集的信息定义模型(该模型有效的表示了图 11 中所示逻辑结构)，以及输入关于物理设备的相应信息。无论这是更大规模自动化框架(如本书中描述的)的第一阶段，还只是简单记录分配给每个网络设备的 IP 地址，这个过程对于任何负责管理设备网络的人来说都很熟悉。
有几种开源工具可用于此任务，我们的选择是 NetBox。该工具支持 IPAM (IP 地址管理)，能记录关于设备类型及其安装位置的库存相关信息，维护集团和站点的基础设施架构，以及维护设备连接到控制台、网络和电源的信息。在 NetBox 网站上可以找到更多介绍。
延伸阅读:
NetBox: Information Resource Modeling Application.
NetBox 的关键特性之一是能够自定义用于组织收集到的所有信息的模型集。例如，运维人员可以定义机架(Rack) 和站点(Site) 这样的物理分组，也可以定义像组织(Organization) 和部署(Deployment) 这样的逻辑分组<sup>[1]</sup>。下面我们使用图 12 所示的 Aether 网络规划作为示例，重点关注配置单个 Aether 站点时发生的情况(但请记住，如第 2 章所述，Aether 可以跨越多个站点)。
[1] 在本节中，我们用斜体表示模型和模型字段(例如，Site, Address)，并将指定给模型实例的特定值作为常量(例如，
10.0.0.0/22)。
第一步是为准备的站点创建记录，记录该站点所有相关元数据，包括站点(Site)名称(Name) 和位置(Location) ，以及站点所属组织(Organization) 。一个组织(Organization) 可以有多个站点(Site) ，而一个站点(Site) 可以(a)跨越一个或多个机架(Rack) ，(b)托管一个或多个部署(Deployment) 。部署(Deployment) 是一个逻辑集群，例如Production、Staging和Development。图 12 所示的网络规划包括两个这样的部署。
这也是指定分配给特定边缘部署的 VLAN 和 IP 前缀的时间。由于维护 VLAN、IP 前缀和 DNS 域名(DNS 是自动生成的)之间的明确关系非常重要，因此浏览下面的具体示例很有帮助。我们从每个站点所需的最小 VLAN 集开始:
- ADMIN 1
- UPLINK 10
- MGMT 800
- FABRIC 801
这些都是 Aether 特有的，也说明了集群可能需要的一组 VLAN。至少，人们希望在任何集群中看到一个"管理"网络(本例中为 MGMT)和一个"数据"网络(本例中为 FABRIC)。同样针对 Aether(但具有通用性)，如果站点上有多个部署共享一个管理服务器，则会添加额外的 VLAN (MGMT/FABRIC 的 id 加 10)。例如，第二个Development部署可能定义为:
- DEVMGMT 810
- DEVFABRIC 811
然后，IP 前缀与 VLAN 相关联，所有边缘 IP 前缀都可以放入一个/22子网中，然后以与 DNS 域名管理一致的方式对该子网进行分区。例如，域名是通过将设备(Device) 名(见下文)的第一个<devname>组件与此后缀组合生成的。以10.0.0.0/22为例，有 4 个边缘前缀，目的如下:
- ADMIN 前缀为
10.0.0.0/25(用于 IPMI) - 有管理服务器和管理交换机
- 分配给 ADMIN 的 VLAN 为 1
- 域名设置为
admin.<deployment>.<site>.aetherproject.net - MGMT 前缀为
10.0.0.128/25(用于基础设施控制平面) - 有服务器管理平面、交换机管理平面
- 分配给 MGMT 的 VLAN 为 800
- 域名设置为
mgmt.<deployment>.<site>.aetherproject.net - FABRIC 前缀
10.0.1.0/25(用于基础设施数据平面) - 计算节点到 Fabric 交换机以及其他 Fabric 连接的设备(例如，eNB)
的qsfp0端口的 IP 地址 - 分配给 FABRIC 的 VLAN 为 801
- 域名设置为
fab1.<deployment>.<site>.aetherproject.net - FABRIC 前缀
10.0.1.128/25(用于基础设施数据平面) - 计算节点到 fabric 交换机的
qsfp1口 IP 地址 - 分配给 FABRIC 的 VLAN 为 801
- 域名设置为
fab2.<deployment>.<site>.aetherproject.net
Kubernetes 还使用其他不需要在 NetBox 中创建的边缘前缀。注意，本例中的qsfp0和qsfp1表示连接交换 fabric 的收发器端口，其中 QSFP 表示 Quad(4 通道) Small Form-factor Pluggable。
记录了站点范围内的信息后，下一步是安装并记录每个设备(Device) 。包括输入<devname>，随后用于为设备生成完全合格的域名: <devname>.<deployment>.<site>.aetherproject.net。创建设备时还需要填写以下字段:
- Site
- Rack & Rack Position
- Manufacturer
- Model
- Serial number
- Device Type
- MAC Addresses
注意，通常有一个主接口和一个管理接口(例如 BMC/IPMI)。Netbox 的一个便利特性是使用设备类型(Device Type) 作为模板，设置接口、电源连接和其他设备型号特定属性的默认命名。
最后，必须指定 Device 的虚拟接口，并将其 Label 字段设置为分配给它的物理网络接口。然后将 IP 地址分配给我们定义的物理和虚拟接口。管理服务器应该总是用每个前缀中的第一个 IP 地址，按照约定，按如下方式递增分配:
- 管理服务器(Management Server)
eno1- 站点提供的公网 IP 地址，如果由 DHCP 提供则为空eno2- 10.0.0.1/25 (ADMIN 的第一个)，设置为主 IPbmc- 10.0.0.2/25 (ADMIN 的下一个)mgmt800- 10.0.0.129/25 (MGMT 的第一个，在 VLAN 800 上)fab801- 10.0.1.1/25 (FABRIC 的第一个，在 VLAN 801 上)- 管理交换机(Management Switch)
gbe1- 10.0.0.3/25 (ADMIN 的下一个)，设置为主 IP- Fabric 交换机
eth0- 10.0.0.130/25 (MGMT 的下一个)，设置为主 IPbmc- 10.0.0.131/25- 计算服务器(Compute Server)
eth0- 10.0.0.132/25 (MGMT 的下一个)，设置为主 IPbmc- 10.0.0.4/25 (ADMIN 的下一个)qsfp0- 10.0.1.2/25 (FABRIC 的下一个)qsfp1- 10.0.1.3/25- 其他 Fabric 设备(eNB 等)
eth0或其他主接口 - 10.0.1.4/25 (FABRIC 的下一个)
一旦该数据输入到 NetBox 中，就可以用来生成如图 13 所示的机架图，对应于图 12 所示的布线图。请注意，图中显示了位于同一物理机架中的两个逻辑部署(Production和Development)。
图 13. NetBox 渲染机架配置。
还可以为部署生成其他有用的指标，帮助技术人员确认所记录的逻辑指标是否与实际物理表示相匹配。例如，图 14 显示了一组电缆，以及如何在我们的示例部署中连接硬件。
图 14. NetBox 电缆报告。
如果你觉得这些细节看起来过于冗长乏味，那你就了解到本节的要点了。云控制和管理自动化的一切都依赖于拥有相关资源的完整准确的数据，保持这些信息与物理基础设施的现实同步通常是此过程中最薄弱的环节。唯一可取之处是信息是高度结构化的，像 NetBox 这样的工具可以帮助我们维护这种结构。
3.1.2 配置和启动
在安装硬件并记录有关安装的相关事实之后，下一步是配置和引导硬件，以便为接下来的自动化过程做好准备。我们的目标是最小化图 12 所示物理基础设施所需的手动配置，但是零接触(zero-touch) 是一个很高的标准。为了说明这一点，完成示例部署的准备所需的引导步骤目前包括:
- 配置管理交换机，使其知道正在使用的 VLAN 集。
- 配置管理服务器，使其通过额外提供的 USB 密钥启动。
- 运行必要的 Ansible 角色和剧本，在管理服务器上完成配置。
- 配置计算服务器，从管理服务器(通过 iPXE)启动。
- 配置 Fabric 交换机，从管理服务器(通过 Nginx)启动。
- 配置 eNB(移动基站)，使它们知道自己的 IP 地址。
这些都是手动配置步骤，需要控制台访问或将信息输入到设备 web 界面，这样任何后续配置步骤都可以完全灵活的自动化完成。请注意，虽然这些步骤不能自动完成，但也不一定必须现场执行，可以提前将准备发送到远程站点的硬件准备好。还要注意的是，不要使用可以稍后完成的配置来覆盖这一步骤。例如，在物理安装 eNB 时，可以在 eNB 上设置各种无线电参数，不过一旦集群联机，这些参数将通过管理平台进行设置。
应该尽量减少在这个阶段所做的手动配置工作，大多数系统应该使用自动化的配置方法。例如，广泛使用 DHCP 和 MAC 预留来分配 IP 地址，而不是手工配置每个接口，从而允许管理零接触，并简化未来的重配置。
配置的自动化方面被实现为一组 Ansible 角色(role) 和剧本(playbook) ，按照第二章图 6 所示高层概要，对应于代表"零接触配置(系统)"的方框。换句话说，我们没有现成的 ZTP 解决方案可以使用(也就是说，必须有人编写剧本)，但是通过访问 NetBox 维护的所有配置参数，可以大大简化这一问题。
总体思路如下。对于每个需要配置的网络服务(如 DNS, DHCP, iPXE, Nginx)和每个设备子系统(如网络接口，Docker)，都有对应的 Ansible 角色和剧本<sup>[2]</sup>。一旦管理网络联机，上面总结的各阶段手动配置就将被应用于管理服务器。
[2] 我们将忽略 Ansible 中角色(role) 和剧本(playbook) 之间的区别，而将重点放在脚本(script) 这一概念上，并通过一组输入参数运行这个脚本。
Ansible 剧本在管理服务器上安装和配置网络服务。DNS 和 DHCP 的作用显而易见。至于 iPXE 和 Nginx，它们被用来引导其余的基础设施。计算服务器通过 DHCP/TFTP 方式下发 iPXE 配置，然后在 Nginx web 服务器上加载脚本安装操作系统。fabric 交换机从 Nginx 加载 Stratum OS 包。
在大部分情况下，剧本将使用从 NetBox 提取的参数，例如 VLAN、IP 地址、DNS 名称等。图 15 说明了这种方法，并填充了一些细节。例如，一个自制的 Python 程序(edgeconfig.py)使用 REST API 从 NetBox 提取数据，并输出一组相应的 YAML 文件，精心制作成 Ansible 的输入，这在管理和计算系统上创建了更多的配置。其中一个例子是 Netplan 文件，它在 Ubuntu 中用于管理网络接口。关于 Ansible 和 Netplan 的更多信息可以在它们各自的网站上找到。
延伸阅读:
Ansible: Automation Platform.
Netplan: Network Configuration Abstraction Renderer.
图 15. 使用 NetBox 数据配置网络服务和 OS 级子系统。
虽然图 15 强调了 Ansible 是如何与 Netplan 配对来配置内核级细节的，但也有一个 Ansible 剧本用于在每个计算服务器和 fabric 交换机上安装 Docker，然后启动 Docker 容器，运行"finalize"镜像。该镜像调用配置栈的下一层，有效表明集群正在运行并准备好接受进一步指令。现在我们准备介绍这一层。
