生产架构指南

本指南将帮助您配置 Kolla 以满足生产需求。旨在解答 Kolla 所需的基本配置选项的一些问题。本文档还包含其他有用的指针。

节点类型和在其上运行的服务

基本的 Kolla 库存由几种类型的节点组成，在 Ansible 中称为 groups。

  • 控制 - 云控制器节点，托管控制服务，如 API 和数据库。该组应具有奇数个节点以实现仲裁。

  • 网络 - 网络节点托管 Neutron 代理以及 haproxy / keepalived。这些节点将在 kolla_internal_vip_address 中定义一个浮动 IP。

  • 计算 - 用于计算服务的计算节点。这是虚拟机驻留的地方。

  • 存储 - 用于 cinder-volume、LVM 的存储节点。

  • 监控 - 托管监控服务的监控节点。

网络配置

接口配置

在 Kolla 中，操作员应配置以下网络接口

  • network_interface - 虽然它本身不使用，但它为以下其他接口提供了所需的默认值。

  • api_interface - 此接口用于管理网络。管理网络是 OpenStack 服务用于相互通信以及与数据库的网络。这里存在已知的安全风险，因此建议使此网络为内部网络，不可从外部访问。默认为 network_interface。

  • kolla_external_vip_interface - 这是面向公众的接口。当您希望 HAProxy 公共端点暴露在与内部端点不同的网络中时，它才会被使用。当 kolla_enable_tls_external 设置为 yes 时，必须设置此选项。默认为 network_interface。

  • tunnel_interface - 此接口由 Neutron 用于通过隧道网络（如 VxLan）的虚拟机间流量。默认为 network_interface。

  • neutron_external_interface - 这是 Neutron 所必需的接口。Neutron 将 br-ex 放在其上。它将用于平面网络以及标记的 VLAN 网络。必须单独设置。

  • dns_interface - 这是 Designate 和 Bind9 所必需的接口。用于面向公众的 DNS 请求以及对 bind9 和 designate mDNS 服务的查询。默认为 network_interface。

  • bifrost_network_interface - 这是 Bifrost 所必需的接口。用于配置裸机云主机，需要与裸机云主机具有 L2 连接才能提供带有 PXE 启动选项的 DHCP 租约。默认为 network_interface。

地址族配置 (IPv4/IPv6)

从 Train 版本开始，Kolla Ansible 允许操作员使用 IPv6 代替 IPv4 部署控制平面。每个 Kolla Ansible 网络（如接口所示）都提供了两种地址族的选项。内部和外部 VIP 地址都可以使用 IPv6 地址配置。IPv6 在所有受支持的平台上都经过测试。

警告

虽然 Kolla Ansible Train 需要 Ansible 2.6 或更高版本，但 IPv6 支持需要 Ansible 2.8 或更高版本，因为存在一个错误：https://github.com/ansible/ansible/issues/63227

注意

目前没有双栈支持。IPv4 只能与 IPv6 在不同的网络上混合使用。这种限制源于服务需要通用的单个地址族寻址。

例如，network_address_family 接受 ipv4 或 ipv6 作为其值，并定义所有网络的默认地址族，就像 network_interface 定义默认接口一样。类似地，api_address_family 更改 API 网络的地址族。当前的网络列表可在 globals.yml 文件中找到。

注意

虽然 Train 中引入的 IPv6 支持很广泛，但已知某些服务尚未与 IPv6 协同工作或存在一些已知问题

Docker 配置

由于 Docker 是 Kolla 的核心依赖项，因此 Docker 的正确配置可以显著改变 Kolla 的体验。以下部分将重点介绍 Kolla 操作员相关的几个 Docker 配置细节。

存储驱动程序

虽然默认存储驱动程序对于大多数用户来说已经足够，但 Docker 提供了更多需要考虑的选项。有关详细信息，请参阅 Docker 文档。

卷

Kolla 将几乎所有持久数据都放在 Docker 卷中。这些卷是在 Docker 工作目录中创建的，默认情况下为 /var/lib/docker 目录。

我们建议确保此目录有足够的空间并放置在快速磁盘上，因为它会影响构建、部署以及数据库提交和 rabbitmq 的性能。

当 enable_central_logging 和 openstack_logging_debug 都设置为 true 时，这尤其重要，因为完全加载的 130 个节点集群每天产生 30-50GB 的日志。

高可用性 (HA) 和可扩展性

HA 是生产系统中的一个重要主题。HA 关注服务的冗余实例，以便在发生故障时，可以提供接近零中断的整体服务。可扩展性通常与 HA 协同工作，通过使用负载均衡器来提供负载共享。

OpenStack 服务

多节点 Kolla Ansible 部署为服务提供 HA 和可扩展性。OpenStack API 端点就是一个很好的例子：冗余的 haproxy 实例通过 keepalived 提供 HA，而后端也以冗余方式部署，以实现 HA 和负载均衡。

其他核心服务

大多数部署所需的非 OpenStack 核心组件：由 mariadb 提供的 SQL 数据库和由 rabbitmq 提供的消息队列也以 HA 方式部署。但是，需要注意的是，与先前描述的服务不同，这些服务具有更复杂的 HA 机制。原因是它们提供云信息的中央、持久存储，其他每个服务都假定该信息具有一致的状态（即完整性）。这种假设导致需要建立仲裁（有关更多信息，请查阅 CAP 定理）。

仲裁需要多数票，因此默认情况下部署 2 个实例并不能提供任何 HA，因为一个实例的故障会导致另一个实例的故障。因此，建议的实例数为 3，其中 1 个节点故障是可以接受的。为了扩展目的和更好的弹性，可以使用 5 个节点并接受 2 个故障。但是，请注意，由于仲裁成员之间以及通信介质发生故障的非零概率，更高的数字通常不会提供任何好处。