OpenStack部署实战：核心组件、网络规划与Kolla-Ansible自动化

1. 部署前的规划与架构设计

1.1 节点划分与资源评估

很多人一上来就急着安装，结果装到一半发现磁盘不够、内存爆掉，或者网络配置一塌糊涂。OpenStack部署真正考验人的不是命令本身，而是前期规划。它就像装修房子，先把水电布局想清楚，再动工。

先算资源。一个最小的可用生产环境，至少需要三台节点：控制节点、计算节点、存储节点（也可以合并）。控制节点跑核心服务，比如认证、镜像、网络管理、调度等，内存至少16GB，推荐32GB；计算节点跑虚拟机实例，内存根据业务需求来，但最低8GB起步，CPU要支持虚拟化（VT-x/AMD-V）；存储节点提供块存储和对象存储，磁盘容量按业务数据量规划，建议至少SSD做缓存，HDD做存储。如果只是想测试，可以一台机器用虚拟化嵌套跑三个节点，但性能会打折。

磁盘分区也要提前设计。系统盘和数据盘分开，控制节点系统盘建议100GB，计算节点系统盘建议50GB，存储节点系统盘50GB，另加数据盘。分区时/boot给1GB，swap按内存大小给，/分区用LVM方便后续扩容。

网络规划上，我强烈建议至少配置两块网卡：一块管理网络（用于API通信、内部组件通信），一块数据网络（用于虚拟机流量、存储流量）。如果条件允许，再加一块外部网络网卡。千万不能用管理网去跑业务流量，不然只要虚拟机一多，管理API就卡成幻灯片。

1.2 网络方案选型

OpenStack网络是坑最多的模块，也是选型时最容易纠结的地方。常用的有几个方案：

• Flat网络：最简单，所有虚拟机都在一个共享L2网段，类似家里的路由器直接分IP。适合测试环境。
• VLAN网络：基于物理交换机上的VLAN隔离租户网络，需要交换机支持VLAN，但灵活性和扩展性够用，很多企业在用。
• OVS+GRE/VXLAN：通过隧道封装实现租户隔离，不依赖物理VLAN，适合多租户场景，但配置复杂，性能损耗相对较高。
• OVN：新一代虚拟网络方案，整合了Open vSwitch和OVN控制器，功能更完善，性能也更好，是社区主推的方向。

选型时问自己几个问题：租户数量多大？是否需要租户间隔离？底层网络基础设施是否支持VLAN？如果只是内部私有云，几十个租户以内，VLAN完全够用；如果想做公有云或大规模虚拟化，VXLAN/OVN更合适。我个人的建议是，生产环境优先考虑OVN，社区支持力度大，问题少一些。

1.3 环境准备与版本选择

版本选择直接决定你踩坑的深度。最忌讳用最新的版本做生产，也不建议用太老的版本（会有大量已知bug和不安全漏洞）。建议选择当前社区的稳定版本，比如最近的稳定版（具体版本号自己查官方文档，命名规则是字母排序）。在部署前，先去官网看该版本的release notes，了解新特性、废弃功能、已知问题。

操作系统方面，建议选用主流Linux发行版，比如基于Debian或RHEL体系的。需要注意的是，不同发行版对OpenStack的支持程度不同，有些发行版有官方源，有些要装第三方源。我推荐用发行版自带的包管理器安装，这样依赖关系好解决，后续升级也方便。不要自己从源码编译，除非你想深入开发。

时间同步一定要在安装前搞定，集群内所有节点统一使用NTP同步。控制节点可能还需要配置DNS，确保节点之间能通过主机名互相访问。主机名最好提前规划，比如controller、compute01、storage01，写成/etc/hosts，别用IP直接访问服务，否则后续证书和服务注册会有各种奇葩问题。

2. 核心组件的部署要点

2.1 认证服务Keystone：先搞定身份再谈别的

OpenStack所有组件之间的交互都要通过Keystone认证。部署顺序上，Keystone必须第一个装，因为其他组件启动时要向Keystone注册endpoint。

安装Keystone时，有几个关键点容易出错。第一，数据库初始化。需要建一个专门的数据库和用户，并授权。这里要注意密码策略，建议用强密码，但别用特殊字符太多，因为后续命令行中很多地方要填密码，特殊字符会带来转义问题。第二，Fernet key生成。Keystone使用Fernet key做token加密，需要生成一个key，并在所有节点上保持同步（如果你做多控制节点高可用，这个key必须复制到每个节点）。第三，服务注册。创建服务实体和API endpoint时，endpoint的URL要一致，建议用管理网域名，不要用IP，这样以后证书配置和负载均衡都好做。

验证Keystone是否正常，很简单：用admin用户请求一下token。常见错误是401 Unauthorized，多半是密码错误或Fernet key不一致。还有403 Forbidden，可能是role没有分配好。初次安装时，别忘了引导admin项目、admin用户、admin角色，以及创建service项目。

2.2 镜像服务Glance：上传镜像前先想好格式

Glance负责管理虚拟机镜像。安装很简单，主要是数据库、配置文件、注册endpoint。真正需要注意的环节在镜像格式和上传流程上。

支持的镜像格式有很多，但生产中最常用的是qcow2和raw。qcow2支持快照、压缩、COW（写时复制），上传快，使用方便；raw格式性能最好，但不支持快照。如果对性能有极致要求，可以用raw存存储，qcow2做镜像分发。还有一点，上传前要确认镜像是否支持virtio驱动，特别是Windows镜像，否则后面启动实例时网卡和磁盘认不到。

Glance的存储后端可以配置为本地目录、Ceph等。如果用了Ceph，需要导入Ceph的key并配置pools。这里我要提个醒：Glance存Ceph后，虚拟机启动时如果能直接通过Ceph克隆镜像到Cinder，会比先下载镜像再转换快得多。这也是我偏爱Ceph做后端的理由。

2.3 计算服务Nova：调度、虚机和状态的幕后管家

Nova是整个OpenStack里逻辑最复杂的组件。它由多个子服务组成：nova-api接收API请求，nova-scheduler决定把虚拟机放在哪个计算节点上，nova-compute在计算节点上真正创建和运行实例，nova-conductor负责数据库访问和协调。

部署Nova，配置项特别多，但核心配置就那么几块：

• 数据库连接：所有服务统一用数据库用户连接，注意字符集。
• 消息队列：Nova组件之间通过消息队列通信，常用RabbitMQ。如果消息队列挂了，整个Nova就瘫痪。生产环境一定要做消息队列的高可用。
• 认证方式：配置Keystone连接信息和管理用户。
• compute节点配置：设置虚拟化类型（默认KVM），配置vCPU、内存、磁盘的分配超卖比例。比如CPU超卖比设为4：1，内存设为1.5：1，但要监控好，避免物理资源耗尽。
• libvirt：Nova-compute依赖libvirt管理虚拟机。需要配置/etc/nova/nova-compute.conf中的libvirt类型，默认是kvm，但如果CPU不支持虚拟化，只能降级为qemu（性能差很多）。

一个常见的坑是，Nova-compute启动后，OpenStack里看不到可用计算资源。检查思路是：先看nova-compute日志，确认它是否注册成功；然后看nova-conductor有没有把compute信息同步到数据库；最后在控制节点执行openstack compute service list，看服务状态。如果是down，多半是时间不同步、消息队列连接失败或者配置文件权限问题。

2.4 网络服务Neutron：让虚拟机接入真实世界

Neutron是部署过程中最让人头疼的组件，也是虚拟机能否真正用起来的关键。它涉及多个Agent：neutron-server提供API，neutron-dhcp-agent分配IP，neutron-l3-agent做路由和NAT，neutron-metadata-agent处理元数据，还有Open vSwitch或者Linux Bridge的机制。

部署时，先配置数据库、认证、消息队列这些基础项。然后需要选择二层机制：如果之前选了OVS或OVN，要安装对应的Agent。控制节点上需要启动dhcp、l3、metadata agent；计算节点上至少要启动二层Agent（比如ovs-agent）。记得在每个节点上配置openvswitch，创建好br-int、br-ex等虚拟交换机。

网络配置里最容易出问题的有三个地方。

一是网卡混杂模式。计算节点上的数据网络网卡（比如eth1）要开启混杂模式，否则虚拟机流量过不了。用ip link set eth1 promisc on，但最好写进持久化配置，避免重启失效。

二是外网桥接。如果用provider网络，需要把外部网络网卡桥接到br-ex上。桥接时，物理网卡的IP要移到bridge上，如果直接配置错，外部网络就断了。我的办法是在一个维护窗口里，用临时脚本先配置br-ex，验证通了再写持久化。

三是DHCP命名空间。Neutron的DHCP默认绑在命名空间里，不同网络有不同命名空间。如果虚拟机拿不到IP，先看ip netns exec qdhcp-xxx ip a里有没有分配IP，再看dhcp-agent日志。

3. 自动化部署工具对比与选择

3.1 三个工具的真实差异

手把手手动部署OpenStack确实能学到很多东西，但效率太低，还容易出错。实际工作中，基本都是用自动化工具部署。常见的选择有：

我个人的建议是，测试和学习用DevStack，快速验证和POC用PackStack，生产环境用Kolla-Ansible。如果你想搭建一套能实际支撑业务的云平台，直接学Kolla-Ansible，它是目前社区最活跃的部署项目之一。

3.2 基于Kolla-Ansible的部署实操

下面是我部署时一个经过验证的流程，以三节点（controller + compute1 + compute2 ）为例。

准备阶段：

1. 在所有节点安装Python、Docker、Ansible。Ansible版本需要和Kolla-Ansible匹配，在官方文档里有明确版本对应表。
2. 在控制节点安装Kolla-Ansible，通过pip安装即可。
3. 准备目标节点清单文件，也就是inventory。我习惯放在/etc/kolla/inventory下，定义[control]和[compute]组，并填好节点IP、SSH用户名、sudo权限设置。
4. 编辑全局配置/etc/kolla/globals.yml。这里面要改的项目很多，我最关注几个：
   • kolla_base_distro：决定基础镜像是哪个发行版，建议选较新的稳定版。
   • kolla_internal_vip_address：虚拟IP，用于高可用，需要分配给控制节点所在的物理网络一个空闲IP。
   • network_interface：管理网络接口名。
   • neutron_external_interface：外部网络接口名。
   • openstack_release：要部署的OpenStack版本。
   • enable_haproxy: yes：如果想做控制节点高可用，就开HAProxy。
   • enable_ceph: yes：如果用Ceph做存储，还要配置Ceph相关项。

执行阶段：

1. 生成密码文件。使用kolla-genpwd工具自动生成所有服务的密码。也可以手动修改，注意一致性。
2. 通过kolla-ansible prechecks检查系统环境。这一步会检查网络、时间同步、内存、磁盘等。如果有问题，会直接报错。
3. 执行kolla-ansible deploy。这一步会拉取镜像，启动所有容器。耗时取决于网络和机器性能，首次部署可能需要20到60分钟。
4. 部署完成后，生成/etc/kolla/admin-openrc.sh，这是OpenStack管理员的认证文件。执行kolla-ansible post-deploy，然后在控制节点上安装OpenStack客户端命令。

验证阶段：

用openstack service list查看服务是否注册，用openstack compute service list查看计算服务是否正常，用openstack network list查看网络是否创建。如果启动一个测试虚拟机，还能成功SSH进去，说明部署基本成功。

3.3 容器内部组件日志怎么查

Kolla-Ansible把组件跑在容器里，排查问题的方式跟传统部署不太一样。常用的命令：

# 查看所有容器状态 docker ps -a # 查看某服务日志 docker logs nova_conductor 2>&1 | tail -100 # 进入容器执行命令 docker exec -it nova_api bash # 查看keystone容器里是否配置正确 docker exec -it keystone bash -c "openstack endpoint list"

日志默认存在/var/log/kolla/<service>/下，每个服务会按日志文件写入。排查问题时，优先看对应容器日志或宿主机上的日志文件。比如Nova创建虚拟机失败，就同时看nova-compute和nova-conductor的日志，很可能通过日志直接找到原因。

4. 常见问题与排查技巧实录

4.1 虚拟机拿不到IP地址

现象：用命令行创建实例后，状态为ACTIVE，但openstack console log show里看到网卡状态是DOWN，或者没有DHCP请求。

排查路径：

1. 看Neutron网络状态：openstack network list，确认网络、子网、端口都正常。
2. 在控制节点查看DHCP命名空间：ip netns exec qdhcp-XXXX ip a，确认DHCP地址池里的IP有没有被分配。
3. 看dhcp-agent日志：docker logs neutron_dhcp_agent，如果有“DHCP request received”就没问题。
4. 看计算节点的二层网络：执行ovs-vsctl show，确认数据网桥是否正常，物理网卡是否在桥上。

最常见的原因是混淆了“管理网络”和“数据网络”。如果计算节点没有把数据网络网卡桥接好，虚拟机网卡即使起来了，二层流量也无法到达DHCP服务。另外，检查安全组规则，如果没放行DHCP（UDP 67/68），也会导致拿不到IP。

4.2 实例创建超时或报错No valid host

现象：创建虚拟机卡在SCHEDULING阶段，或者提示“No valid host was found”。

排查思路：

1. openstack hypervisor list，看计算节点是否在列表中。如果为空，说明nova-compute没有正常上报。
2. 看nova-scheduler日志，通常会输出为什么没有可用主机。常见原因是计算节点的资源不足，比如内存、磁盘、CPU不满足flavor规格。检查一下宿主机可用内存和磁盘，不要只看配额。
3. 检查flavor参数，比如VCPU、内存、磁盘是否设置合理。默认flavor可能配置为内存512MB，但宿主机真的没有这么多内存。
4. 如果是在Kolla容器环境，还要确认nova_compute容器是否启动成功，以及它能否连接消息队列。

4.3 Dashboard登录后白屏或登不上

现象：打开Horizon页面，输入账号密码后，页面一直是空白或报错。

排查路径：

1. 看Dashboard容器日志，检查连接Keystone是否超时。
2. 确认浏览器能访问到Keystone的endpoint。在页面所在机器上执行curl http://<vip>:35357/v3，看能否返回JSON。
3. 检查Session存储，Horizon默认使用本地的文件或Memcached。如果配置了Memcached，确保Memcached服务正常。
4. 常见的是因为vip配置错误，Dashboard访问了不存在的IP。检查globals.yml中的kolla_internal_vip_address，并确保该IP在控制节点的网卡或者HAProxy上正常绑定。

4.4 Cinder块存储卷无法挂载

现象：创建了卷并挂载到实例，但实例内看不到块设备，或者看到设备但无法格式化。

原因很可能是卷的驱动程序配置错了。如果你用的是LVM作为Cinder后端，需要在存储节点上配置一个卷组名称，比如cinder-volumes。用vgcreate cinder-volumes /dev/sdb创建，然后修改cinder.conf里的volume_group = cinder-volumes。

还有一个容易被忽略的问题：Cinder做LVM后端时，lvm_type可能被设置为thin，而你并没有创建thin pool，导致卷创建失败。我的建议是如果没把握，就用普通卷组，不配thin。

如果卷创建成功但挂载后实例里需要重启才出现，通常是因为virtio驱动问题，或者实例操作系统没有安装好相应的块设备驱动。Windows实例尤其常见，请在镜像里预先安装virtio驱动。

5. 我个人沉淀的操作心得

部署过几套OpenStack之后，我最大的感受是，这个系统所有组件都是彼此关联的。网络不通，Nova调度会出错；Keystone认证慢，所有组件都跟着遭殃。所以在部署前，一定要把基础环境每个细节都验证好。

一个小技巧：部署完成后，先不要急着创建虚拟机。建议按顺序验证一遍：

• openstack endpoint list，确认所有服务的endpoint都是可达的。
• 在控制节点上直接curl每个endpoint，确认网络层是通的。
• 创建一个最简单的flavor（比如1VCPU/1G/10G），创建一个测试网络和子网，启动一个Cirros之类的轻量级镜像。
• 确认控制台能打开，然后SSH登录，测试外网连通性。
• 创建一块Cinder卷挂载上去，测试块存储的读写。

这一套走下来，平台才算是真正跑通了。之后再加业务虚拟机，遇到问题时也会更有把握。

另外，强烈建议把部署过程的每一步记录下来，包括配置文件的修改、密码的管理、网络的拓扑。OpenStack的配置非常分散，一旦出问题，没有文档就只能靠回忆。我每次部署完都会写一页简单的部署备忘，把每个组件的关键配置项和当时的拓扑图整理起来。后续排障时能省一半时间。

还有一点是关于升级和扩容。不要跳过任何一个版本的release notes。OpenStack组件之间的版本兼容性很强，跨版本升级如果没处理好网络层插件，可能会全盘崩溃。扩容计算节点相对简单，只要保证新节点的时间同步、网络、认证信息一致，然后再由Kolla-Ansible执行扩容部署即可，但一定要在业务低峰期做。

OpenStack部署没有一劳永逸的银弹，它需要你不断去理解其架构和组件交互。但只要用心把底层原理搞透，部署配置其实都是水到渠成的事。希望这篇总结能帮你少踩一些坑。