配置无状态服务

API 服务

负载均衡器

HAProxy

HAProxy 提供了一个快速可靠的 HTTP 反向代理和负载均衡器，适用于 TCP 或 HTTP 应用程序。它特别适合在非常高的负载下进行网络爬虫，同时需要持久性或第 7 层处理。在最新的硬件上，它能够实际支持数万个连接。

HAProxy 的每个实例将其前端配置为仅接受指向虚拟 IP (VIP) 地址的连接。HAProxy 后端（终止点）是用于负载均衡的所有实例 IP 地址的列表。

注意

确保您的 HAProxy 安装不是单点故障，建议运行多个 HAProxy 实例。

您还可以通过其他方式确保可用性，例如使用 Keepalived 或 Pacemaker。

或者，您可以使用商业负载均衡器，它可以是硬件或软件。我们建议使用硬件负载均衡器，因为它通常具有良好的性能。

有关在您的节点上安装 HAProxy 的详细说明，请参阅 HAProxy 官方文档。

配置 HAProxy

1. 重启 HAProxy 服务。

2. 在您的环境中，在每个 OpenStack 控制器上找到您的 HAProxy 实例。以下是一个示例 /etc/haproxy/haproxy.cfg 配置文件。使用以下配置文件配置您的实例，您需要在每个控制器节点上复制一份。

    global
     chroot  /var/lib/haproxy
     daemon
     group  haproxy
     maxconn  4000
     pidfile  /var/run/haproxy.pid
     user  haproxy
   
   defaults
     log  global
     maxconn  4000
     option  redispatch
     retries  3
     timeout  http-request 10s
     timeout  queue 1m
     timeout  connect 10s
     timeout  client 1m
     timeout  server 1m
     timeout  check 10s
   
    listen dashboard_cluster
     bind <Virtual IP>:443
     balance  source
     option  tcpka
     option  httpchk
     option  tcplog
     server controller1 10.0.0.12:443 check inter 2000 rise 2 fall 5
     server controller2 10.0.0.13:443 check inter 2000 rise 2 fall 5
     server controller3 10.0.0.14:443 check inter 2000 rise 2 fall 5
   
    listen galera_cluster
     bind <Virtual IP>:3306
     balance  source
     option  mysql-check
     server controller1 10.0.0.12:3306 check port 9200 inter 2000 rise 2 fall 5
     server controller2 10.0.0.13:3306 backup check port 9200 inter 2000 rise 2 fall 5
     server controller3 10.0.0.14:3306 backup check port 9200 inter 2000 rise 2 fall 5
   
    listen glance_api_cluster
     bind <Virtual IP>:9292
     balance  source
     option  tcpka
     option  httpchk
     option  tcplog
     server controller1 10.0.0.12:9292 check inter 2000 rise 2 fall 5
     server controller2 10.0.0.13:9292 check inter 2000 rise 2 fall 5
     server controller3 10.0.0.14:9292 check inter 2000 rise 2 fall 5
   
    listen glance_registry_cluster
     bind <Virtual IP>:9191
     balance  source
     option  tcpka
     option  tcplog
     server controller1 10.0.0.12:9191 check inter 2000 rise 2 fall 5
     server controller2 10.0.0.13:9191 check inter 2000 rise 2 fall 5
     server controller3 10.0.0.14:9191 check inter 2000 rise 2 fall 5
   
    listen keystone_admin_cluster
     bind <Virtual IP>:35357
     balance  source
     option  tcpka
     option  httpchk
     option  tcplog
     server controller1 10.0.0.12:35357 check inter 2000 rise 2 fall 5
     server controller2 10.0.0.13:35357 check inter 2000 rise 2 fall 5
     server controller3 10.0.0.14:35357 check inter 2000 rise 2 fall 5
   
    listen keystone_public_internal_cluster
     bind <Virtual IP>:5000
     balance  source
     option  tcpka
     option  httpchk
     option  tcplog
     server controller1 10.0.0.12:5000 check inter 2000 rise 2 fall 5
     server controller2 10.0.0.13:5000 check inter 2000 rise 2 fall 5
     server controller3 10.0.0.14:5000 check inter 2000 rise 2 fall 5
   
    listen nova_ec2_api_cluster
     bind <Virtual IP>:8773
     balance  source
     option  tcpka
     option  tcplog
     server controller1 10.0.0.12:8773 check inter 2000 rise 2 fall 5
     server controller2 10.0.0.13:8773 check inter 2000 rise 2 fall 5
     server controller3 10.0.0.14:8773 check inter 2000 rise 2 fall 5
   
    listen nova_compute_api_cluster
     bind <Virtual IP>:8774
     balance  source
     option  tcpka
     option  httpchk
     option  tcplog
     server controller1 10.0.0.12:8774 check inter 2000 rise 2 fall 5
     server controller2 10.0.0.13:8774 check inter 2000 rise 2 fall 5
     server controller3 10.0.0.14:8774 check inter 2000 rise 2 fall 5
   
    listen nova_metadata_api_cluster
     bind <Virtual IP>:8775
     balance  source
     option  tcpka
     option  tcplog
     server controller1 10.0.0.12:8775 check inter 2000 rise 2 fall 5
     server controller2 10.0.0.13:8775 check inter 2000 rise 2 fall 5
     server controller3 10.0.0.14:8775 check inter 2000 rise 2 fall 5
   
    listen cinder_api_cluster
     bind <Virtual IP>:8776
     balance  source
     option  tcpka
     option  httpchk
     option  tcplog
     server controller1 10.0.0.12:8776 check inter 2000 rise 2 fall 5
     server controller2 10.0.0.13:8776 check inter 2000 rise 2 fall 5
     server controller3 10.0.0.14:8776 check inter 2000 rise 2 fall 5
   
    listen ceilometer_api_cluster
     bind <Virtual IP>:8777
     balance  source
     option  tcpka
     option  tcplog
     server controller1 10.0.0.12:8777 check inter 2000 rise 2 fall 5
     server controller2 10.0.0.13:8777 check inter 2000 rise 2 fall 5
     server controller3 10.0.0.14:8777 check inter 2000 rise 2 fall 5
   
    listen nova_vncproxy_cluster
     bind <Virtual IP>:6080
     balance  source
     option  tcpka
     option  tcplog
     server controller1 10.0.0.12:6080 check inter 2000 rise 2 fall 5
     server controller2 10.0.0.13:6080 check inter 2000 rise 2 fall 5
     server controller3 10.0.0.14:6080 check inter 2000 rise 2 fall 5
   
    listen neutron_api_cluster
     bind <Virtual IP>:9696
     balance  source
     option  tcpka
     option  httpchk
     option  tcplog
     server controller1 10.0.0.12:9696 check inter 2000 rise 2 fall 5
     server controller2 10.0.0.13:9696 check inter 2000 rise 2 fall 5
     server controller3 10.0.0.14:9696 check inter 2000 rise 2 fall 5
   
    listen swift_proxy_cluster
     bind <Virtual IP>:8080
     balance  source
     option  tcplog
     option  tcpka
     server controller1 10.0.0.12:8080 check inter 2000 rise 2 fall 5
     server controller2 10.0.0.13:8080 check inter 2000 rise 2 fall 5
     server controller3 10.0.0.14:8080 check inter 2000 rise 2 fall 5
   

   注意

   Galera 集群配置指令 backup 指示三个控制器中的两个是待机节点。这确保了只有单个节点处理写入请求，因为 OpenStack 对多节点写入的支持尚未达到生产就绪状态。

   注意

   Telemetry API 服务配置没有 option httpchk 指令，因为它无法正确处理此检查。

1. 配置内核参数以允许非本地 IP 绑定。这允许运行 HAProxy 实例绑定到 VIP 以进行故障转移。将以下行添加到 /etc/sysctl.conf

   net.ipv4.ip_nonlocal_bind = 1
   

2. 重启主机，或者，要立即生效，请调用

   $ sysctl -p
   

3. 将 HAProxy 添加到集群，并确保 VIP 只能在运行 HAProxy 的机器上运行

   pcs

   $ pcs resource create lb-haproxy systemd:haproxy --clone
   $ pcs constraint order start vip then lb-haproxy-clone kind=Optional
   $ pcs constraint colocation add lb-haproxy-clone with vip
   

   crmsh

   $ crm cib new conf-haproxy
   $ crm configure primitive haproxy lsb:haproxy op monitor interval="1s"
   $ crm configure clone haproxy-clone haproxy
   $ crm configure colocation vip-with-haproxy inf: vip haproxy-clone
   $ crm configure order haproxy-after-vip mandatory: vip haproxy-clone
   

Pacemaker 与 systemd

Memcached

Memcached 是一个通用的分布式内存缓存系统。它用于通过在 RAM 中缓存数据和对象来加速动态数据库驱动的网站，从而减少必须读取外部数据源的次数。

Memcached 是一个内存缓存守护程序，可供大多数 OpenStack 服务用于存储临时数据，例如令牌。

由于复制访问目前处于实验状态，因此 HAProxy 不处理对 Memcached 的访问。相反，必须向 OpenStack 服务提供运行 Memcached 的所有主机列表。

Memcached 客户端实现哈希算法以在实例之间平衡对象。实例故障仅影响一定比例的对象，并且客户端会自动将其从实例列表中删除。SLA 为几分钟。

高可用性 API 服务

身份 API

请确保您已阅读 OpenStack Identity 服务入门文档。

将 OpenStack Identity 资源添加到 Pacemaker

以下部分详细介绍了如何在 SUSE 和 Red Hat 上将 Identity 服务添加到 Pacemaker。

SUSE

SUSE Enterprise Linux 和基于 SUSE 的发行版（例如 openSUSE）使用一组 OCF 代理来控制 OpenStack 服务。

1. 运行以下命令将 OpenStack Identity 资源下载到 Pacemaker

   # cd /usr/lib/ocf/resource.d
   # mkdir openstack
   # cd openstack
   # wget https://opendev.org/x/openstack-resource-agents/raw/branch/2025.2/ocf/keystone
   # chmod a+rx *
   

2. 通过运行以下命令连接到 Pacemaker 集群，添加 Pacemaker 配置以获取 OpenStack Identity 资源

   # crm configure
   

3. 添加以下集群资源

   clone p_keystone ocf:openstack:keystone \
   params config="/etc/keystone/keystone.conf" os_password="secretsecret" os_username="admin" os_tenant_name="admin" os_auth_url="http://10.0.0.11:5000/v2.0/" \
   op monitor interval="30s" timeout="30s"
   

   注意

   此配置创建了 p_keystone，一个用于管理 OpenStack Identity 服务的资源。

4. 使用以下命令从 crm configure 菜单提交您的配置更改

   # commit
   

   crm configure 支持批量输入。您可能需要将上述行复制并粘贴到您的实时 Pacemaker 配置中，然后根据需要进行更改。

   例如，您可以从 crm configure 菜单输入 edit p_ip_keystone 并编辑资源以匹配您首选的虚拟 IP 地址。

   Pacemaker 现在在您的所有节点上启动 OpenStack Identity 服务及其依赖资源。

Red Hat

对于 Red Hat Enterprise Linux 和基于 Red Hat 的 Linux 发行版，以下过程使用 Systemd 单元文件。

# pcs resource create openstack-keystone systemd:openstack-keystone --clone interleave=true

配置 OpenStack Identity 服务

1. 编辑 keystone.conf 文件以更改 bind(2) 参数的值

   bind_host = 10.0.0.12
   public_bind_host = 10.0.0.12
   admin_bind_host = 10.0.0.12
   

   admin_bind_host 参数允许您使用专用网络进行管理访问。

2. 为了确保所有数据都是高可用的，请确保所有内容都存储在 MySQL 数据库中（该数据库也是高可用的）

   [catalog]
   driver = keystone.catalog.backends.sql.Catalog
   # ...
   [identity]
   driver = keystone.identity.backends.sql.Identity
   # ...
   

3. 如果 Identity 服务将发送 ceilometer 通知，并且您的消息总线配置为高可用性，则需要确保 Identity 服务已正确配置为使用它。

配置 OpenStack 服务以使用高可用的 OpenStack Identity

您的 OpenStack 服务现在将 OpenStack Identity 配置指向高可用的虚拟集群 IP 地址。

1. 对于 OpenStack Compute 服务，（如果您的 OpenStack Identity 服务 IP 地址是 10.0.0.11），请在 api-paste.ini 文件中使用以下配置

auth_host = 10.0.0.11

1. 使用此 IP 地址创建 OpenStack Identity Endpoint。

   注意

   如果您同时使用私有和公共 IP 地址，请创建两个虚拟 IP 地址并定义端点。例如

   $ openstack endpoint create --region $KEYSTONE_REGION \
   $service-type public http://PUBLIC_VIP:5000/v2.0
   $ openstack endpoint create --region $KEYSTONE_REGION \
   $service-type admin http://10.0.0.11:35357/v2.0
   $ openstack endpoint create --region $KEYSTONE_REGION \
   $service-type internal http://10.0.0.11:5000/v2.0
   

2. 如果您正在使用 Dashboard (horizon)，请编辑 local_settings.py 文件以包含以下内容

   OPENSTACK_HOST = 10.0.0.11
   

Telemetry API

Telemetry 轮询代理可以配置为在多个代理之间分配其轮询工作负载。这可以实现高可用性 (HA)。

中央代理和计算代理都可以以高可用性部署运行。这意味着这些服务可以并行运行多个实例，并在这些运行实例之间分配工作负载。

Tooz 库提供服务实例组内的协调。它提供了一个高于几个后端 API，可用于构建分布式应用程序。

Tooz 支持 各种驱动程序，包括以下后端解决方案

• Zookeeper:

  Tooz 项目推荐的解决方案。

• Redis:

  Tooz 项目推荐的解决方案。

• Memcached:

  推荐用于测试。

您必须配置受支持的 Tooz 驱动程序才能进行 Telemetry 服务的高可用性部署。

有关在 ceilometer.conf 中设置的必需配置选项的信息，请参阅 OpenStack 配置参考 中的 协调 部分。

注意

如果未设置 backend_url 选项，则只能运行和正常运行中央和计算代理服务的一个实例。

实例的可用性检查由心跳消息提供。当与实例的连接丢失时，工作负载将在下一个轮询周期内重新分配到剩余实例中。

注意

Memcached 使用超时值，该值应始终设置为高于为 Telemetry 设置的心跳值的数值。

为了向后兼容并支持现有的部署，中央代理配置支持使用不同的配置文件。这是并行运行的服务实例组。要启用此配置，请在 OpenStack 配置参考 中的 ceilometer.conf 配置文件中的轮询部分中设置 partitioning_group_prefix 选项的值。

警告

对于中央代理池的每个子组，其 partitioning_group_prefix 相同，必须轮询不相交的米表子集，以避免样本丢失或重复。可以在 /etc/ceilometer/pipeline.yaml 配置文件中设置要轮询的米表列表。有关管道的更多信息，请参阅 数据处理和管道 部分。

要启用计算代理同时运行多个实例并进行工作负载分配，必须在 计算 部分的 ceilometer.conf 配置文件中将 workload_partitioning 选项设置为 True。