简介这份PDF面向云计算运维人员、OpenStack初学者及需要落地私有云的技术团队系统梳理基于OpenStack搭建私有云的完整实践路径帮助读者理解从基础环境准备到核心组件集成的关键环节。资源包共1个PDF文件大小约1.64MB内容以图文步骤与配置说明为主便于按章节查阅和对照实践。目录涵盖使用Rancher生成容器、NTP时间同步、修改YUM源并安装NOVA计算服务、部署NEUTRON网络服务及Linux桥接代理配置还涉及Cinder、Glance、Swift、Horizon等组件的安装思路以及安全监控、自动化部署和测试优化等运维要点。此外附有PackStack快速安装、创建Cell、页面登录与日志查看等实操记录可帮助读者建立组件协作的整体认知掌握私有云部署中的配置方法与排错方向。目前已有890人学习适合作为OpenStack私有云搭建的入门与查阅参考。1. 从一台裸机到能跑虚拟机的私有云OpenStack 搭建到底在搭什么很多团队第一次动私有云的念头往往不是因为预算多而是因为几台闲置的物理服务器和一堆“能不能自己搞个云”的追问。OpenStack 就是在这个场景下被反复提起的名字。它不是一个装完就能用的软件而是一组协同工作的服务集合负责把计算、存储、网络这三样东西从物理硬件里抽象出来再以 API 的形式交付给上层。你最终得到的是一个能创建虚拟机、能挂载卷、能划分租户网络的私有云平台。适合谁适合手里有 3 台以上物理机或性能足够的虚拟机、愿意花一个周末踩坑、并且后续有持续运维预期的团队。如果只是想跑几个容器Kubernetes 更直接但如果你的诉求是“像用公有云那样管理自己的硬件”OpenStack 仍然是绕不开的选项。这一章先把边界划清楚后面再动手。2. 部署选型为什么我最终选了 Kolla-Ansible 而不是 DevStack2.1 三种常见部署方式的真实差异OpenStack 的部署方式经过多年演化目前从业者主要面对三条路DevStack、手动逐服务安装、以及 Kolla-Ansible。DevStack 本质是给开发者做代码验证用的它把一切塞进一个目录重启后状态容易丢不适合任何有持久化预期的场景。手动安装能让你彻底理解每个服务的配置项但一个最小可用的多节点环境光 Neutron 的网络配置就能耗掉一整天而且版本间的配置差异极大网上搜到的教程经常对不上号。Kolla-Ansible 的思路是用容器把每个 OpenStack 服务打包通过 Ansible 编排部署到多台主机上。它的优势在于版本一致性好、升级路径清晰、社区维护活跃。我一般会推荐第一次搭建的人直接走 Kolla-Ansible把精力留给后续的运维和排错而不是消耗在安装本身。2.2 硬件与系统基线别在 4GB 内存的机器上试在动手之前先把基线定死。控制节点至少 8GB 内存、4 核 CPU、40GB 系统盘如果计算节点也要跑虚拟机内存按你要开的实例总内存再加 4GB 来算。系统我选 Ubuntu 22.04 LTS原因是 Kolla-Ansible 对它的支持最成熟社区里遇到问题也最容易搜到同环境的答案。网络方面至少需要两张网卡一张管理网用于 Ansible 通信和 API 访问一张业务网用于虚拟机流量。如果只有一张网卡可以用 VLAN 子接口但第一次搭建不建议这么干排错复杂度会翻倍。下面是我常用的基础环境准备命令每台节点都要执行。# 关闭 swapkubelet 和 OpenStack 服务都不喜欢它 sudo swapoff -a sudo sed -i /swap/s/^/#/ /etc/fstab # 加载必要的内核模块 sudo modprobe br_netfilter echo br_netfilter | sudo tee /etc/modules-load.d/openstack.conf # 调整内核参数让网桥流量能被 iptables 处理 sudo tee /etc/sysctl.d/99-openstack.conf EOF net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 net.ipv4.ip_forward 1 EOF sudo sysctl -p /etc/sysctl.d/99-openstack.conf这几条命令的逻辑是swap 关闭是为了避免服务被换出导致 API 超时br_netfilter 模块让网桥上的流量能走 iptables 规则Neutron 的安全组和浮动 IP 都依赖它ip_forward 打开是让节点具备路由能力。参数值不要改这三个是 OpenStack 网络功能的硬前提。执行完用lsmod | grep br_netfilter确认模块已加载用sysctl net.ipv4.ip_forward确认返回 1。2.3 用 Kolla-Ansible 跑通第一个 all-in-one 环境正式多节点之前我强烈建议先在一台机器上跑一个 all-in-one把流程走通。这样出问题时排查范围小也方便你理解各服务之间的依赖关系。先安装依赖和 Kolla-Ansible 本身。# 安装 Python 依赖和 Ansible sudo apt update sudo apt install -y python3-dev python3-venv libffi-dev gcc libssl-dev git # 创建虚拟环境避免污染系统 Python python3 -m venv /opt/kolla-venv source /opt/kolla-venv/bin/activate # 安装 Kolla-Ansible这里不指定版本号默认拉最新稳定版 pip install -U pip pip install kolla-ansible虚拟环境的作用是把 Kolla-Ansible 的依赖和系统隔离后续升级或卸载都干净。安装完成后用kolla-ansible --version确认命令可用。接下来准备配置文件Kolla-Ansible 自带了一套示例配置复制到/etc/kolla下再改。sudo mkdir -p /etc/kolla sudo chown $USER:$USER /etc/kolla cp -r /opt/kolla-venv/share/kolla-ansible/etc_examples/kolla/* /etc/kolla/ cp /opt/kolla-venv/share/kolla-ansible/ansible/inventory/all-in-one .globals.yml是核心配置文件下面这几项必须改其余可以先保持默认。# /etc/kolla/globals.yml 关键项 kolla_base_distro: ubuntu openstack_release: 2024.1 # 用当前稳定版不要追 master network_interface: eth0 # 管理网网卡名按实际改 neutron_external_interface: eth1 # 业务网网卡名按实际改 kolla_internal_vip_address: 10.0.0.100 # 管理网内一个未占用 IP enable_neutron_provider_networks: yesopenstack_release决定拉取哪个版本的容器镜像写具体版本号而不是 latest否则不同时间部署可能拿到不同版本出问题无法复现。kolla_internal_vip_address是 API 的访问入口必须是一个当前没被占用的 IP且和network_interface同网段。改完后执行引导和部署。# 生成密码文件里面包含各服务的随机密码 kolla-genpwd # 引导服务器安装 Docker 等基础组件 kolla-ansible -i all-in-one bootstrap-servers # 部署前检查这一步会拉取镜像耗时较长 kolla-ansible -i all-in-one prechecks # 正式部署 kolla-ansible -i all-in-one deploybootstrap-servers做的是装 Docker、配置 Python 环境、设置防火墙规则这些前置工作。prechecks会验证你的配置和硬件是否满足要求比如内存是否够、网卡是否存在、VIP 是否可达。如果 prechecks 报错不要跳过一定要解决否则 deploy 阶段会以更难看的方式失败。deploy 完成后用kolla-ansible -i all-in-one post-deploy生成 admin 的 openrc 文件然后source /etc/kolla/admin-openrc.sh执行openstack compute service list应该能看到 nova 相关服务处于 up 状态。3. 多节点扩展把计算和网络拆开之后要盯什么3.1 从 all-in-one 到三节点的配置改动all-in-one 跑通后多节点的改动其实不大核心是把 inventory 文件从单机改成多机分组。假设你有三台机器node1 做控制网络node2 和 node3 做计算。inventory 文件这样写。# inventory/multinode [control] node1 [network] node1 [compute] node2 node3 [monitoring] node1 [storage] node1控制节点和网络节点放在同一台是常见做法小规模环境没必要拆开。计算节点只跑 nova-compute 和 neutron-openvswitch-agent资源全留给虚拟机。改完 inventory 后globals.yml里需要额外指定neutron_external_interface所在网卡并确认所有节点的network_interface名称一致。然后对每台机器执行 bootstrap再跑 prechecks 和 deploy。注意多节点部署时控制节点的 VIP 必须可达计算节点要能通过管理网访问控制节点的 API 端口。3.2 Neutron 网络配置私有云能不能用八成看这里Neutron 是 OpenStack 里最容易让人翻车的组件。Kolla-Ansible 默认用 Open vSwitch 做二层转发配置集中在globals.yml和 Neutron 的 ML2 配置里。对于大多数私有云场景我建议先用 provider network 模式也就是虚拟机直接桥接到物理业务网不搞 overlay。这样网络路径短、排错简单缺点是 VLAN 数量受物理交换机限制。配置如下。# globals.yml 中与 Neutron 相关的项 enable_neutron_provider_networks: yes neutron_bridge_name: br-ex neutron_external_interface: eth1部署完成后需要手动创建一个 provider network 和子网虚拟机才能拿到 IP。source /etc/kolla/admin-openrc.sh # 创建 provider 网络指定 VLAN ID 和物理网卡映射 openstack network create --share --provider-physical-network physnet1 \ --provider-network-type vlan --provider-segment 100 provider-net # 创建子网网关按你物理网络的规划来 openstack subnet create --network provider-net \ --subnet-range 192.168.100.0/24 --gateway 192.168.100.1 \ --allocation-pool start192.168.100.10,end192.168.100.200 provider-subnet--provider-physical-network physnet1要和 Neutron 配置里的bridge_mappings对应Kolla-Ansible 默认会把physnet1映射到br-ex。--provider-segment 100是 VLAN ID必须和物理交换机上对应端口的 VLAN 配置一致否则虚拟机流量出不去。创建完用openstack network list和openstack subnet list确认。如果虚拟机能拿到 IP 但 ping 不通网关先检查物理交换机端口是不是 trunk 模式、VLAN 是否放行。3.3 镜像与实例第一次启动虚拟机的完整链路网络通了之后上传一个镜像并启动实例验证整条链路。我一般用 CirrOS 做测试体积小、启动快。# 下载 CirrOS 镜像 wget http://download.cirros-cloud.net/0.6.2/cirros-0.6.2-x86_64-disk.img # 上传镜像到 Glance openstack image create --disk-format qcow2 --container-format bare \ --file cirros-0.6.2-x86_64-disk.img cirros # 创建 flavor小规模测试用最小规格 openstack flavor create --vcpus 1 --ram 512 --disk 1 m1.tiny # 创建安全组规则允许 ping 和 ssh openstack security group rule create --proto icmp default openstack security group rule create --proto tcp --dst-port 22 default # 启动实例 openstack server create --image cirros --flavor m1.tiny \ --network provider-net --security-group default test-vm--disk-format qcow2要和镜像实际格式一致写错会导致实例无法启动。--network provider-net指定刚才创建的 provider 网络。启动后用openstack server list看状态从 ACTIVE 之后用openstack console log show test-vm看启动日志。如果卡在 booting from hard disk多半是镜像格式或启动项问题。能 ping 通、能 ssh 进去说明计算、网络、存储三条链路都通了。4. 避坑与排查那些让我重装三次的瞬间4.1 prechecks 报 “not enough memory” 但 free 看还有余量现象是 prechecks 阶段提示内存不足但free -h显示可用内存明明够。原因是 Kolla-Ansible 检查的是物理内存总量减去预留值而它默认预留了 4GB 给系统。如果你的控制节点只有 8GB实际可用就只剩 4GB跑多个服务容器就会触发阈值。解决办法是在globals.yml里调低预留值或者给控制节点加内存。我一般会把nova_reserved_host_memory_mb设为 1024同时确认没有其他大内存进程在跑。4.2 部署卡在 “Waiting for container to start” 超过十分钟某个服务容器一直起不来Ansible 卡在等待循环。原因通常是容器启动后内部进程崩溃但 Docker 的重启策略让它反复重启Ansible 看到的状态一直是 starting。解决方法是登录到对应节点用docker ps -a找到那个容器再用docker logs 容器名看具体报错。常见的有配置文件语法错误、端口被占用、依赖服务没起来。改完配置后用kolla-ansible -i inventory/multinode reconfigure -t 服务名单独重配那个服务不用全量重跑。4.3 虚拟机能拿到 IP 但访问不了外网现象是实例内ip a有地址ping 网关通但 ping 外网地址不通。原因是 provider network 只提供了二层连通三层路由和 NAT 需要物理网络设备配合。如果你的业务网网关没有做 SNAT虚拟机流量到了网关就被丢弃。解决办法有两个一是在物理网关上配置 SNAT 规则让虚拟机网段能出去二是改用 Neutron 的 router 加浮动 IP 方案但那样就引入了 overlay 网络复杂度上升。我一般推荐前者因为私有云内部东西向流量才是主要诉求南北向按需在网关处理。4.4 重启物理机后 OpenStack 服务没有自动恢复现象是物理机重启后openstack命令报连接超时。原因是 Kolla-Ansible 部署的容器默认没有设置开机自启Docker 服务起来了但容器没起来。解决办法是给关键容器加上 restart policy。Kolla-Ansible 在globals.yml里有docker_restart_policy选项默认是no改成always后重新 reconfigure。或者手动对每个容器执行docker update --restart always 容器名。我习惯在部署完成后统一改一遍避免每次重启都手动拉起。4.5 删除实例后卷没有释放存储空间越来越小现象是删了虚拟机但 Cinder 里的卷还在占着后端存储。原因是删除实例时如果勾选了“删除卷”才会一起删默认是不删的。这是设计如此防止误删数据。解决办法是定期用openstack volume list --status available找出无主卷确认后手动删除。更稳妥的做法是在创建实例时就规划好临时测试的实例直接带--delete-volumes-on-termination参数或者用openstack server delete --delete-volumes删实例。5. 进阶技巧用 Kolla-Ansible 的 reconfigure 做单服务调优Kolla-Ansible 最实用的能力之一是reconfigure它允许你只针对某个服务重新下发配置并重启容器不用全量 deploy。这在调优阶段非常省时间。比如你觉得 Nova 创建实例太慢想调整nova_conductor的 worker 数量只需要改globals.yml里的nova_conductor_workers然后执行下面这条命令。kolla-ansible -i inventory/multinode reconfigure -t nova-t nova限定只处理 nova 相关的容器Ansible 会重新渲染 nova 的配置文件、对比差异、重启受影响的容器。整个过程通常一两分钟比全量 deploy 快一个数量级。类似的调 Neutron 的neutron_openvswitch_agent日志级别、调 Cinder 的cinder_api_workers都可以用这种方式。参数值怎么定一个经验公式是API 类服务的 worker 数设为 CPU 核数的一半到两倍之间具体看并发量 conductor 类服务保持和 CPU 核数一致即可。改完用openstack compute service list和openstack network agent list确认服务状态正常。另一个值得掌握的技巧是备份和恢复 Kolla-Ansible 的配置。/etc/kolla目录里存着所有服务的密码和配置一旦丢失重建环境时无法恢复原有数据。我一般会在部署完成后立刻打包一份放到安全位置。# 备份关键配置和密码 sudo tar czf kolla-config-backup-$(date %Y%m%d).tar.gz /etc/kolla # 恢复时解压回原路径再执行 reconfigure sudo tar xzf kolla-config-backup-20250101.tar.gz -C / kolla-ansible -i inventory/multinode reconfigure注意/etc/kolla/passwords.yml里的密码如果丢了数据库和消息队列的认证会失败恢复起来极其麻烦。所以这个备份动作应该在每次修改配置后都做一次。我自己的习惯是在/etc/kolla下放一个CHANGELOG文件每次改了什么、为什么改、改完验证结果如何都记一行。这个习惯帮我省过好几次“上次到底改了啥”的后悔药。OpenStack 的复杂度决定了你不可能记住所有改动靠文档和备份才是正路。希望帮到你。本文还有配套的精品资源点击获取