1. 多区域部署到底解决的是什么问题单区域 OpenStack 集群跑久了迟早会遇到几个绕不开的瓶颈。最典型的是机房扩容业务从 A 机房扩展到 B 机房两个机房之间隔着几十毫秒的链路延迟如果还按单区域那套玩法把控制平面拉成一个大集群数据库和消息队列的跨机房同步延迟会直接把 API 响应拖垮。另一个场景是容灾隔离生产环境要求某个区域的故障不能波及另一个区域但又要统一管理、统一鉴权、统一镜像分发。这时候 multiRegion 就不是锦上添花而是不得不做。kolla-ansible 对 multiRegion 的支持本质上是把 OpenStack 的 region 概念落到部署层面。每个 region 拥有自己独立的控制平面Nova、Neutron、Keystone 后端、Glance 后端等但共享一套全局的 Keystone 认证入口和统一的 API 端点目录。用户拿着同一个 token可以跨 region 操作资源而底层各 region 的数据库、消息队列、存储都是物理隔离的。这个设计思路和公有云的多 region 架构是一致的只不过 kolla-ansible 把它做成了可编排的 Ansible 角色。我见过不少团队一开始图省事直接在一个 region 里堆机器等到要拆分的时候才发现 Keystone 的 endpoint 表、Nova 的 cell 映射、Neutron 的 agent 归属全都缠在一起拆起来比重装还痛苦。所以如果你现在正在规划多机房或者多可用区的 OpenStack最好在部署阶段就把 multiRegion 的骨架搭对后面扩容和隔离都会轻松很多。这篇文章面向的是已经用过 kolla-ansible 部署单区域、现在要往多区域演进的运维和架构同学。我会从 inventory 结构、globals 配置、Keystone 联邦、跨区域网络、镜像同步、验证方法这几个角度把整个流程拆开讲清楚中间会穿插我自己踩过的坑和实测有效的参数。2. 多区域 inventory 的目录结构与变量分层2.1 为什么不能只用一个 inventory 文件kolla-ansible 默认的 inventory 是单文件或者单目录所有主机、所有组都混在一起。到了 multiRegion如果你还把所有 region 的节点塞进同一个 inventory会出现两个问题一是kolla-ansible -i inventory执行时playbook 会尝试在所有主机上跑所有角色你没法只针对某个 region 做部署二是变量会互相覆盖比如 region A 的 VIP 和 region B 的 VIP 如果变量名相同后加载的会覆盖前面的。正确的做法是按 region 拆分 inventory 目录每个 region 一个独立的 inventory 文件同时共享一个公共的 group_vars。我实测下来比较稳的目录结构是这样的kolla-inventory/ ├── region-a │ ├── hosts │ └── group_vars/ │ └── all.yml ├── region-b │ ├── hosts │ └── group_vars/ │ └── all.yml └── common/ └── group_vars/ └── all.yml部署的时候用-i kolla-inventory/region-a指定区域Ansible 会自动加载该目录下的 group_vars同时你可以在 playbook 里通过include_vars把 common 目录的公共变量引进来。这样 region A 和 region B 的部署完全解耦互不干扰。2.2 region 名称与 Keystone 的对应关系每个 region 在 Keystone 里必须有一个唯一的 region 名称这个名称要和 inventory 里定义的openstack_region_name变量严格一致。我建议用有业务含义的命名比如region-hz、region-sh而不是region1、region2因为后面在 endpoint 列表和 horizon 下拉框里都会显示这个名字运维人员一眼就能看出是哪个机房。在group_vars/all.yml里每个 region 需要单独设置openstack_region_name: region-hz keystone_admin_url: https://keystone-hz.example.com:5000/v3 keystone_internal_url: https://keystone-hz.internal:5000/v3注意这里的keystone_admin_url指向的是该 region 自己的 Keystone 入口而不是全局的。multiRegion 下每个 region 都有独立的 Keystone 服务但它们的后端数据库可以共享也可以独立这个后面会细说。2.3 主机分组的最小集合一个 region 的 inventory 里至少要包含以下几类主机分组否则 playbook 跑到一半会报找不到主机control控制节点跑 Nova API、Neutron Server、Glance API 等network网络节点跑 Neutron L3 Agent、DHCP Agent、Metadata Agentcompute计算节点跑 Nova Compute、Neutron OVS Agentstorage存储节点跑 Cinder Volume、Ceph OSD 等monitoring监控节点跑 Prometheus、Grafana 等如果某个 region 规模很小可以把 control 和 network 合并但 compute 和 storage 建议独立避免资源争抢。我见过把 compute 和 control 混部的小集群Nova API 的响应延迟在业务高峰期能飙到秒级后来拆开就恢复正常了。3. globals.yml 里那些必须改的跨区域参数3.1 多区域开关与 region 标识kolla-ansible 从某个版本开始引入了enable_multi_region相关的配置项但不同版本行为有差异。在较新的版本里你需要在globals.yml里显式声明openstack_region_name: region-hz enable_keystone_federation: yesopenstack_region_name决定了该 region 所有服务注册到 Keystone 时使用的 region 字段。如果你在 region A 的 globals 里写了region-hz在 region B 里写了region-sh那么两个 region 的服务会分别注册到各自的 region 下Keystone 的 endpoint 表里就能看到两个 region 的条目。3.2 VIP 与 API 端点的隔离每个 region 必须有自己独立的 VIP不能共用。因为 VIP 通常绑定在 keepalived 或者 haproxy 上跨机房共用 VIP 会导致脑裂和路由混乱。在 globals 里kolla_internal_vip_address: 10.10.1.100 kolla_external_vip_address: 10.10.1.101region B 就用10.20.1.100和10.20.1.101。这两个网段之间要保证三层可达否则跨 region 的 API 调用会失败。3.3 数据库与消息队列的归属这是 multiRegion 里最容易搞错的地方。每个 region 的 Nova、Neutron、Cinder 等服务的数据库建议独立部署不要跨机房共享一个 MySQL 集群。原因很简单MySQL 的跨机房主从复制延迟在几十毫秒级别而 Nova 的数据库操作非常频繁延迟会直接体现在虚拟机创建和删除的耗时上。消息队列同理每个 region 独立部署 RabbitMQ 集群。如果你强行让两个 region 共用一个 RabbitMQ网络抖动时消息堆积和重复消费的问题会让你怀疑人生。在 globals 里数据库和 MQ 的地址要指向本 region 的节点database_address: 10.10.1.10 rabbitmq_address: 10.10.1.113.4 镜像与存储的跨区域策略Glance 镜像默认是每个 region 独立的。如果你希望 region A 上传的镜像能自动同步到 region B有两种方案一是用 Glance 的 multi-store 特性把后端存储指向同一个 Ceph 集群两个 region 的 Glance 共享同一个 pool二是用定时任务做镜像同步通过glance image-create加--copy-from参数跨区域复制。我实测下来如果两个机房之间的专线带宽足够比如 10Gbps 以上共享 Ceph 集群的方案更省心镜像只需要存一份。但如果专线带宽有限或者两个 region 要求完全物理隔离那就用同步脚本牺牲一点存储空间换隔离性。Cinder 的后端也是同理可以共享 Ceph 也可以独立。共享的话卷的跨区域挂载需要额外配置因为 Nova 在 region A 创建虚拟机时如果卷在 region B 的 Ceph 里需要确保计算节点能访问到那个 Ceph 集群。4. Keystone 联邦与跨区域认证的落地细节4.1 每个 region 独立 Keystone 还是共享这是 multiRegion 架构里第一个要做的决策。两种模式我都实际部署过各有适用场景。独立 Keystone 模式每个 region 部署一套完整的 Keystone包括自己的数据库。用户在每个 region 都需要单独创建账号或者通过 LDAP 统一认证。优点是 region 之间完全隔离一个 region 的 Keystone 挂了不影响另一个缺点是用户管理分散跨 region 操作需要切换认证。共享 Keystone 模式所有 region 共用一套 Keystone 服务但每个 region 的服务注册到同一个 Keystone 的不同 region 下。优点是统一认证、统一用户管理缺点是 Keystone 成为单点且跨机房调用 Keystone 的延迟会影响所有 region 的 API 响应。我个人的建议是如果两个 region 之间的专线延迟低于 5ms可以用共享 Keystone如果延迟高于 10ms强烈建议独立 Keystone然后通过 Keystone 的 federation 或者 LDAP 做统一用户源。4.2 共享 Keystone 时的 endpoint 注册如果选择共享 Keystone那么只需要在其中一个 region 部署 Keystone另一个 region 的 globals 里把keystone_admin_url指向那个共享的 Keystone 地址。然后在共享 Keystone 上为每个 region 注册服务端点openstack endpoint create --region region-hz nova public https://nova-hz.example.com:8774/v2.1 openstack endpoint create --region region-sh nova public https://nova-sh.example.com:8774/v2.1注意--region参数必须和 globals 里的openstack_region_name一致。注册完成后用openstack endpoint list可以看到两个 region 的端点。4.3 独立 Keystone 时的 federation 配置独立 Keystone 模式下跨 region 认证需要通过 federation。配置步骤稍微复杂一些在每个 region 的 Keystone 上创建 identity provider 和 mapping配置 SAML 或 OIDC 协议把另一个 region 的 Keystone 作为 trusted IdP在 Horizon 里配置多个 Keystone 端点让用户可以选择登录哪个 region这部分配置在 kolla-ansible 里没有现成的 playbook需要手动改 Keystone 的keystone.conf和federation相关配置。我建议先在测试环境跑通再上生产。4.4 跨区域 token 的有效性无论哪种模式都要注意 token 的有效期和刷新机制。共享 Keystone 时token 天然跨 region 有效独立 Keystone 时token 只在签发它的 region 有效跨 region 操作需要重新认证。如果你的业务系统需要跨 region 调用 API建议在应用层做 token 缓存和刷新而不是每次请求都重新认证。5. 跨区域网络打通与 Neutron 的配合5.1 管理网、API 网、租户网的划分multiRegion 下网络规划要比单区域更细致。我通常把网络分成三类管理网跑 Ansible、SSH、监控数据每个 region 独立网段通过路由器互通API 网跑 OpenStack 各服务的 API 流量每个 region 独立 VIP跨 region 调用走专线租户网跑虚拟机的东西向流量每个 region 独立 VXLAN 或 VLAN跨 region 通信通过 Neutron 的 L3 路由或者外部路由器管理网和 API 网必须跨 region 可达否则 kolla-ansible 的部署和 Keystone 的认证都会失败。租户网是否跨 region 打通取决于业务需求。如果业务要求虚拟机跨 region 通信那就需要在两个 region 的 Neutron 之间建立 VXLAN 隧道或者通过外部路由器做三层转发。5.2 Neutron 的 agent 归属与 region 绑定每个 region 的 Neutron agent 只能属于该 region不能跨 region 注册。在 globals 里neutron_agent_mode和neutron_bridge_name等参数每个 region 可以不同但openstack_region_name必须和该 region 一致。我踩过一个坑在 region B 的 compute 节点上Neutron OVS Agent 的配置文件里local_ip写成了 region A 的管理网 IP导致 agent 注册到了 region A 的 Neutron Server 上region B 的虚拟机网络直接不通。排查了半天才发现是 inventory 里主机变量覆盖的问题。所以部署前一定要检查每个节点的ansible_host和api_interface是否指向本 region 的网卡。5.3 跨区域安全组与防火墙规则跨 region 通信时安全组规则需要在两个 region 都放行。比如 region A 的虚拟机要访问 region B 的数据库那么 region A 的安全组要放行出方向region B 的安全组要放行入方向。如果中间还有物理防火墙也要同步放行。我建议在部署阶段就把跨 region 的通信矩阵列出来哪些服务需要跨 region 调用、走哪个网段、用什么端口然后统一配置安全组和防火墙。后期再补规则很容易漏掉某个端口导致业务中断。6. 部署顺序与验证方法6.1 先部署哪个 region如果两个 region 共享 Keystone那么先部署 Keystone 所在的 region再部署另一个。如果独立 Keystone顺序无所谓但建议先部署一个 region 并验证通过再部署第二个这样出问题时容易定位是哪个 region 的配置有误。部署命令和单区域一样kolla-ansible -i kolla-inventory/region-a prechecks kolla-ansible -i kolla-inventory/region-a deploy部署完成后用kolla-ansible -i kolla-inventory/region-a post-deploy做初始化包括创建 admin 账号、注册服务端点等。6.2 验证 region 注册是否成功部署完两个 region 后在任意一个控制节点上执行source /etc/kolla/admin-openrc.sh openstack region list应该能看到两个 region 名称。然后检查 endpointopenstack endpoint list --region region-hz openstack endpoint list --region region-sh每个 region 下应该有 nova、neutron、glance、cinder、keystone 等服务的端点。如果某个服务的端点缺失说明该服务在对应 region 的注册失败了需要检查该服务的日志。6.3 跨区域创建虚拟机的实测验证跨区域功能最直接的方法是在 region A 创建一台虚拟机然后在 region B 创建一台看两者是否能正常启动、网络是否通。我实测时发现如果两个 region 共享 Glance 后端镜像 ID 是相同的创建虚拟机时不需要额外指定镜像位置如果独立 Glance需要确保镜像在两个 region 都存在否则会报ImageNotFound。另外跨 region 的 flavor 也是独立的。如果你在 region A 创建了 flavorregion B 不会自动同步需要手动创建或者用脚本同步。这个在业务扩容时很容易忽略导致用户在新 region 创建虚拟机时找不到合适的规格。6.4 常见报错与排查路径部署 multiRegion 时最常见的报错有三类报错信息可能原因排查方法Could not find regionregion 名称拼写不一致检查 globals 和 Keystone 里的 region 名称Connection refused to keystoneKeystone 地址不可达检查网络和防火墙确认 VIP 是否正确Endpoint not found for service服务注册失败查看该服务的日志确认 region 参数是否传递我遇到最多的是第一类因为 region 名称在多个地方出现globals、inventory、Keystone 数据库、endpoint 注册命令任何一处不一致都会导致问题。建议用一个统一的变量文件管理 region 名称所有地方都引用这个变量。7. 运维阶段那些容易忽略的细节7.1 跨区域日志与监控的聚合两个 region 的日志如果各自独立排查跨区域问题时需要登录两台机器分别看效率很低。我建议用集中式日志方案比如在每个 region 部署 Filebeat 或 Fluentd把日志推到统一的 Elasticsearch 集群。监控同理Prometheus 可以用 federation 模式把两个 region 的指标聚合到一个 Grafana 里展示。7.2 配额与用户管理的同步如果两个 region 独立 Keystone用户的配额是分开管理的。同一个用户在 region A 有 100 核配额在 region B 可能只有 50 核。如果业务需要跨 region 调度配额管理会很麻烦。我的做法是用一个外部系统统一管理配额通过 OpenStack API 定期同步到两个 region。7.3 版本升级的注意事项kolla-ansible 升级时multiRegion 的升级顺序很重要。如果共享 Keystone先升级 Keystone 所在的 region再升级另一个如果独立 Keystone可以并行升级但要确保两个 region 的 kolla-ansible 版本一致否则 playbook 的变量和角色可能不兼容。升级前一定要备份每个 region 的数据库和配置文件尤其是 Keystone 的数据库一旦升级失败回滚的代价很大。7.4 跨区域故障切换的演练multiRegion 的一个重要价值是容灾。但容灾能力不是部署完就有的需要定期演练。我建议每季度做一次故障切换演练手动关闭 region A 的控制平面观察 region B 是否能正常接管业务用户是否能通过 region B 的 API 创建和管理资源。演练中发现的配置问题比真实故障时才发现要好得多。8. 我个人在 multiRegion 部署中的几点体会第一次做 multiRegion 部署时我最大的教训是低估了网络延迟对控制平面的影响。当时两个机房之间的延迟大约 8ms共享 Keystone 和 MySQL结果 Nova API 的 P99 延迟从单区域的 200ms 涨到了 1.5s。后来把 Keystone 和数据库拆到各自 region延迟立刻降回 300ms 以内。所以如果你的机房之间延迟超过 5ms不要犹豫控制平面一定要独立。第二个体会是变量管理要极度严格。multiRegion 下同一个变量名在不同 region 可能有不同的值如果 group_vars 的加载顺序不对很容易出现 region A 的配置被 region B 覆盖的情况。我的做法是每个 region 的 group_vars 里只放该 region 特有的变量公共变量放在 common 目录通过include_vars显式引入并且在 playbook 里打印出最终生效的变量值部署前人工核对一遍。第三个体会是文档要跟上。multiRegion 的配置项比单区域多得多而且很多是隐式依赖比如 region 名称、VIP、数据库地址、MQ 地址任何一个改动都可能影响另一个 region。我习惯在部署完成后把每个 region 的关键配置整理成一张表包括 region 名称、VIP、数据库地址、MQ 地址、Keystone 模式、Glance 后端等放在内部 Wiki 上后面扩容或者排障时直接查表比翻配置文件快得多。最后分享一个小技巧在验证跨区域功能时不要只测 API 是否通还要测实际业务场景。比如在 region A 创建虚拟机、挂载 region B 的卷、通过 region A 的 Horizon 管理 region B 的资源。这些组合场景才能真正暴露配置问题。我见过 API 测试全过、但实际创建虚拟机时因为 Glance 后端不通而失败的案例所以验证一定要贴近真实使用路径。