简介这份PDF面向云计算运维人员、OpenStack初学者及需要落地私有云的技术团队系统讲解基于OpenStack搭建私有云的完整实践过程帮助读者理解各核心组件的作用与配置方法。资源为单个PDF文件压缩包约1.64MB内容以图文步骤与配置说明为主便于按章节查阅。目录涵盖compute01节点的基础环境搭建、NTP时间同步、NOVA计算服务安装与YUM源修改、NEUTRON网络服务配置及Linux桥接代理设置并延伸至PackStack快速安装、CELL创建、页面登录与日志查看等环节同时涉及Cinder、Glance、Swift、Horizon等组件的部署思路以及安全监控、自动化运维与测试优化等进阶话题。目前已有890人学习下载适合希望从零掌握私有云部署流程、对照实践查漏补缺的读者参考。1. 私有云实践从一台物理机到 OpenStack 可用集群我踩过的坑比装过的包还多很多团队第一次动私有云的念头不是因为技术信仰而是被账单逼的——几台常年跑测试的云主机一年下来够买两台二手服务器。于是「基于 OpenStack 搭建私有云」就成了绕不开的选项。但真动手才发现OpenStack 不是装一个软件而是把认证、镜像、计算、网络、存储、面板七八个服务拼成一台能自洽运转的机器任何一个环节的版本、网卡、数据库权限对不上整个平台就卡在某个服务起不来的状态。这篇笔记面向的是手里有 2 到 4 台物理机或虚拟化环境、想搭一套能跑通创建实例全流程的 OpenStack 私有云、并且愿意为排错花时间的工程师。我会按「先想清楚架构 → 再选部署方式 → 落地最小可用集群 → 排掉高频故障 → 收一个可验证的进阶技巧」这条线走不堆概念只讲能复现的命令和参数。OpenStack 部署这件事玄学的地方不多翻车的地方很集中把那些集中点讲透比背架构图有用。2. 先定架构再动手OpenStack 私有云的最小可用拓扑怎么画2.1 为什么一上来就要砍掉「全功能集群」的幻想新手最容易犯的错是照着官方文档把 Keystone、Glance、Nova、Neutron、Cinder、Horizon 全塞进一台机器然后指望它稳定。单机 all-in-one 确实能跑起来但它把控制面和数据面压在同一套内核参数、同一块网卡、同一个 MySQL 上一旦你要加第二台计算节点网络和消息队列的配置立刻变成一团乱麻。我的建议是第一版私有云只做「1 控制 1 计算」两节点控制节点跑数据库、消息队列、Keystone、Glance、Nova API、Neutron Server、Horizon计算节点只跑 Nova Compute 和 Neutron Agent。这样拓扑清晰出问题能快速定位是控制面还是数据面。选型上操作系统用 Ubuntu 20.04 LTS 或 CentOS Stream 8 都行关键是内核版本要支持你打算用的 Neutron 网络方案。网络方案我强烈建议第一版用 provider network扁平网络不要碰 VXLAN 自服务网络。provider network 把实例直接桥到物理网段少一层封装少一堆 MTU 和隧道排错。存储先用本地 LVM 给 Cinder 做后端别急着上 CephCeph 本身就是一个需要单独排错的分布式系统两个坑叠在一起你分不清是谁的问题。提示控制节点内存至少 8 GB计算节点按你要跑的实例规格倒推一般 16 GB 起步。磁盘用 SSDOpenStack 的数据库和消息队列对随机 IO 很敏感。2.2 两节点拓扑的地址与角色分配表动手前先把地址和角色写死后面所有配置文件都从这里取值避免边装边改导致不一致。角色主机名管理网 IPProvider 网桥运行服务控制节点controller10.0.0.11无MySQL、RabbitMQ、Keystone、Glance、Nova API、Neutron Server、Horizon计算节点compute0110.0.0.21br-providerNova Compute、Neutron Linux Bridge Agent管理网段-10.0.0.0/24-服务间通信、API 访问Provider 网段-192.168.100.0/24-实例对外通信管理网和 Provider 网可以是同一块物理网卡的不同 VLAN也可以是两块网卡。第一版为了简单我用两块网卡ens33 走管理网ens34 走 Provider 网并桥接到 br-provider。计算节点的 br-provider 要挂到 ens34 上并且 ens34 本身不能配 IPIP 配在网桥上。2.3 部署方式选 Kolla-Ansible 还是手工装手工装能让你彻底理解每个服务的配置项但耗时以天计而且容易在数据库授权、消息队列用户、服务注册这些重复劳动上出错。Kolla-Ansible 用容器把每个服务封起来配置通过 globals.yml 和 inventory 统一注入适合想快速拿到可用集群的人。我的做法是第一遍用 Kolla-Ansible 把集群跑通理解服务之间的依赖和端口第二遍再挑一个服务手工装搞懂它的配置到底在干什么。这篇笔记的落地步骤以 Kolla-Ansible 为主线因为它可复现性最强参数集中排错时看容器日志就能定位。3. 用 Kolla-Ansible 落地两节点集群从裸机到创建第一台实例3.1 基础环境准备时间同步、内核参数与 Python 依赖三台机器如果你把控制节点和部署节点分开就是三台合在一起就是两台先做四件事时间同步、主机名解析、内核参数、Python 虚拟环境。时间不同步会让 Keystone 的 token 校验直接失败这个坑我见过太多次。# 在 controller 和 compute01 上分别执行 sudo hostnamectl set-hostname controller # compute01 上改成 compute01 sudo timedatectl set-timezone Asia/Shanghai sudo apt update sudo apt install -y chrony python3-dev python3-venv libffi-dev gcc libssl-dev # 配置 chrony 指向同一个内网时间源没有就互相指向 controller # /etc/chrony/chrony.conf 里加server controller iburst sudo systemctl restart chrony chronyc sources -v # 确认有 * 号选中的源 # 内核参数开启 IP 转发和桥接Neutron 需要 cat EOF | sudo tee /etc/sysctl.d/99-openstack.conf net.ipv4.ip_forward 1 net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 EOF sudo modprobe br_netfilter sudo sysctl -p /etc/sysctl.d/99-openstack.conf时间同步用 chronychronyc sources -v里出现^*才说明同步成功。内核参数里bridge-nf-call-iptables必须为 1否则 Linux Bridge 上的安全组规则不生效实例能通但防火墙形同虚设。br_netfilter模块要显式加载Ubuntu 默认不加载它sysctl -p会报找不到 bridge 相关键。3.2 部署节点上的 Kolla-Ansible 安装与 inventory 编写选一台机器作为部署节点通常就是 controller。在部署节点上建虚拟环境装 Kolla-Ansible版本要和你的 OpenStack 版本对应。这里以 Yoga 版本为例装的时候用 pip 指定版本避免拉到不兼容的最新版。python3 -m venv /opt/kolla-venv source /opt/kolla-venv/bin/activate pip install -U pip pip install kolla-ansible14.0.0 ansible5.10.0 # 初始化配置目录 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/multinode /etc/kolla/inventorykolla-ansible14.0.0对应 OpenStack Yogaansible5.10.0是它验证过的组合。inventory 用 multinode 模板因为我们是两节点。复制完先别急着改用kolla-genpwd生成密码文件所有服务的密码会写进/etc/kolla/passwords.yml后面配置里引用变量即可不要手写明文密码。kolla-genpwd # 编辑 /etc/kolla/inventory按下面结构改inventory 的关键段落长这样[control] controller ansible_host10.0.0.11 [network] controller ansible_host10.0.0.11 [compute] compute01 ansible_host10.0.0.21 [monitoring] controller ansible_host10.0.0.11 [storage] controller ansible_host10.0.0.11[control]和[network]都放 controller因为第一版网络服务和控制服务同机。[compute]只放 compute01。ansible_host写管理网 IPAnsible 通过 SSH 连过去所以部署节点要能免密 SSH 到这两台机器ssh-copy-id先做掉。3.3 globals.yml 里必须改的 8 个参数/etc/kolla/globals.yml是 Kolla 的总开关默认值大多不能用。下面这 8 个参数不改部署必挂或者部署完不能用。# /etc/kolla/globals.yml 关键片段 kolla_base_distro: ubuntu openstack_release: yoga kolla_internal_vip_address: 10.0.0.11 # 单控制节点就写控制节点管理 IP network_interface: ens33 # 管理网网卡 neutron_external_interface: ens34 # Provider 网网卡不能配 IP neutron_plugin_agent: linuxbridge # 第一版用 linuxbridge比 ovs 少一层 enable_neutron_provider_networks: yes # 允许创建 provider 网络 enable_cinder: yes cinder_volume_group: cinder-volumes # 计算节点上提前建好的 LVM 卷组kolla_internal_vip_address在单控制节点场景下直接写控制节点 IP不要用 keepalived 的 VIP否则 HAProxy 会起不来。neutron_external_interface是 Provider 网网卡它会被 Kolla 接管并桥接所以这块网卡在系统里不能有 IP有 IP 会导致网桥创建失败。cinder_volume_group要求计算节点上已经存在名为 cinder-volumes 的 LVM 卷组用vgs确认。3.4 执行部署与验证服务状态部署分两步bootstrap 装基础依赖deploy 拉容器起服务。bootstrap 会装 Docker、配置镜像加速、装一些 Python 包耗时几分钟。source /opt/kolla-venv/bin/activate kolla-ansible -i /etc/kolla/inventory bootstrap-servers kolla-ansible -i /etc/kolla/inventory prechecks kolla-ansible -i /etc/kolla/inventory deployprechecks会检查端口占用、磁盘空间、网卡配置任何一项不过都会明确报出来先解决再 deploy。deploy阶段如果卡在某个容器起不来用docker logs 容器名看日志常见的是数据库连接失败或消息队列认证失败多半是 passwords.yml 没生成或 inventory 主机名对不上。部署完成后生成 admin 凭据并验证kolla-ansible -i /etc/kolla/inventory post-deploy source /etc/kolla/admin-openrc.sh openstack token issue # 能返回 token 说明 Keystone 正常 openstack compute service list # 能看到 nova-compute 状态为 enabled/up openstack network agent list # 能看到 linuxbridge agent 为 aliveopenstack compute service list里 nova-compute 的 State 必须是 up如果是 down去 compute01 上看/var/log/kolla/nova/nova-compute.log八成是消息队列连不上或虚拟化不支持。openstack network agent list里 Linux bridge agent 的 Alive 为 True 才算网络就绪。3.5 创建第一台实例网络、镜像、规格、安全组四件套服务全绿之后按顺序创建 provider 网络、上传镜像、建规格、配安全组最后起实例。source /etc/kolla/admin-openrc.sh # 1. 创建 provider 网络对应 192.168.100.0/24 openstack network create --share --external \ --provider-physical-network physnet1 \ --provider-network-type flat provider openstack subnet create --network provider \ --allocation-pool start192.168.100.100,end192.168.100.200 \ --dns-nameserver 223.5.5.5 --gateway 192.168.100.1 \ --subnet-range 192.168.100.0/24 provider-subnet # 2. 上传 cirros 测试镜像 openstack image create --disk-format qcow2 --container-format bare \ --file cirros-0.5.2-x86_64-disk.img cirros # 3. 建规格 openstack flavor create --vcpus 1 --ram 512 --disk 5 m1.tiny # 4. 安全组放行 ICMP 和 SSH openstack security group rule create --proto icmp default openstack security group rule create --proto tcp --dst-port 22 default # 5. 起实例 openstack server create --flavor m1.tiny --image cirros \ --nic net-id$(openstack network show provider -f value -c id) \ --security-group default test-vm--provider-physical-network physnet1要和 Neutron 配置里的physical_network名字一致Kolla 默认就是 physnet1。--allocation-pool是实例能拿到的 IP 范围要和物理网段错开避免和物理机冲突。起完实例用openstack server list看状态ACTIVE 之后从同网段机器 ping 它的 IP通了就说明 provider 网络链路完整。4. 部署完就翻车OpenStack 私有云高频故障排查清单4.1 现象Horizon 能打开但登录报 500原因通常是 Keystone 连不上数据库或者 memcached 没起来。Keystone 的 token 存在 memcached 里memcached 容器挂了登录就会 500。解决docker ps | grep memcached确认容器在跑不在就docker start memcached再看/var/log/kolla/keystone/keystone.log如果是数据库连接错误检查passwords.yml里database_password和 MySQL 容器里的实际密码是否一致Kolla 部署后改过密码会导致不一致。4.2 现象实例创建成功但 ping 不通先确认实例是否真的拿到了 IPopenstack server show test-vm看 addresses 字段。如果没 IP是 DHCP agent 没工作openstack network agent list看 DHCP agent 是否 alive。如果有 IP 但 ping 不通检查计算节点上 br-provider 是否把 ens34 挂上去了brctl show看接口列表。另一个高频原因是安全组没放行 ICMP默认安全组只放行出站入站 ICMP 要手动加规则。4.3 现象nova-compute 状态 up 但创建实例报 NoValidHost这是调度器找不到合适计算节点。常见原因是计算节点上报的资源为 0openstack compute service list看 up 不代表资源可用要看openstack hypervisor show compute01里的 vcpus 和 memory_mb。如果都是 0说明 nova-compute 没正确识别虚拟化能力去 compute01 上egrep -c (vmx|svm) /proc/cpuinfo返回 0 说明 CPU 不支持硬件虚拟化或者你在虚拟机里嵌套部署但没开嵌套虚拟化。解决物理机进 BIOS 开 VT-x/AMD-V虚拟机里给 CPU 加vmx标志。4.4 现象Cinder 创建卷一直处于 creatingCinder 卷创建卡住九成是卷组不存在或权限不对。去计算节点vgs看有没有 cinder-volumes 卷组没有就pvcreatevgcreate建一个。有卷组还卡看/var/log/kolla/cinder/cinder-volume.log如果是Permission denied检查/dev/vg的属主Kolla 的 cinder-volume 容器以 cinder 用户跑需要能读写块设备。解决chown cinder:cinder /dev/vg或者把 cinder 用户加进 disk 组。4.5 现象部署到一半 Ansible 报 SSH 超时Kolla 部署过程中 Ansible 会反复 SSH 到各节点如果某台机器负载高或者 SSH 连接数打满就会超时。先确认部署节点到目标节点的免密 SSH 正常ssh compute01 echo ok能秒回。如果正常还超时调大 Ansible 的超时和重试在/etc/kolla/ansible.cfg里设timeout 60、gather_timeout 60并在 inventory 里给问题节点加ansible_ssh_common_args-o ConnectTimeout30。别小看这个我曾在低配虚拟机上因为 SSH 超时反复重跑 deploy浪费了一下午。5. 让私有云真正可用从能跑到能扛的验证与调优技巧集群跑通只是起点能不能扛住日常使用要看几个关键验证。第一个验证是重启后自愈把 compute01 重启等它起来后openstack compute service list里 nova-compute 应该自动恢复 up如果没恢复说明容器没设 restart policyKolla 默认是unless-stopped正常会自启没自启就查 Docker 服务本身是否 enabled。第二个验证是并发创建一次性起 5 台实例看调度是否均匀落到计算节点如果全挤在一台检查 Nova 的ram_weight_multiplier和cpu_weight_multiplier默认值在资源不均衡时会偏向某一台可以调成ram_weight_multiplier 1.0让内存权重更平滑。第三个验证是网络性能provider network 下实例到物理网关的延迟应该和物理机同网段延迟接近如果高出一截检查 br-provider 上是否误开了 STPbrctl showstp br-provider看 stateSTP 在简单拓扑里只会添乱关掉它。第四个验证是镜像上传速度Glance 默认后端是本地文件大镜像上传慢是正常的如果慢到不可接受把 Glance 后端换成 Ceph RBD 或者加 SSD但那是另一个坑第一版不建议动。调优上我一般会改两个地方。一是 MySQL 的innodb_buffer_pool_size控制节点内存 8 GB 的话给 2 GB默认值太小服务一多就频繁读盘。二是 RabbitMQ 的vm_memory_high_watermark默认 0.4内存紧张时消息队列会阻塞调到 0.6 并确保机器内存够。这两个参数在 Kolla 里通过/etc/kolla/config/下的服务专属配置文件覆盖改完kolla-ansible -i inventory reconfigure生效不用全量重部署。最后说一个我自己的习惯每次改完配置先跑kolla-ansible -i inventory prechecks再跑reconfigure最后用openstack token issue和openstack server list做冒烟测试。这套动作花不了两分钟但能挡住八成「改完就挂」的情况。私有云这东西稳定不是装出来的是每次变更后验证出来的。希望帮到你。本文还有配套的精品资源点击获取
OpenStack私有云实战：两节点集群部署与高频故障排查
简介这份PDF面向云计算运维人员、OpenStack初学者及需要落地私有云的技术团队系统讲解基于OpenStack搭建私有云的完整实践过程帮助读者理解各核心组件的作用与配置方法。资源为单个PDF文件压缩包约1.64MB内容以图文步骤与配置说明为主便于按章节查阅。目录涵盖compute01节点的基础环境搭建、NTP时间同步、NOVA计算服务安装与YUM源修改、NEUTRON网络服务配置及Linux桥接代理设置并延伸至PackStack快速安装、CELL创建、页面登录与日志查看等环节同时涉及Cinder、Glance、Swift、Horizon等组件的部署思路以及安全监控、自动化运维与测试优化等进阶话题。目前已有890人学习下载适合希望从零掌握私有云部署流程、对照实践查漏补缺的读者参考。1. 私有云实践从一台物理机到 OpenStack 可用集群我踩过的坑比装过的包还多很多团队第一次动私有云的念头不是因为技术信仰而是被账单逼的——几台常年跑测试的云主机一年下来够买两台二手服务器。于是「基于 OpenStack 搭建私有云」就成了绕不开的选项。但真动手才发现OpenStack 不是装一个软件而是把认证、镜像、计算、网络、存储、面板七八个服务拼成一台能自洽运转的机器任何一个环节的版本、网卡、数据库权限对不上整个平台就卡在某个服务起不来的状态。这篇笔记面向的是手里有 2 到 4 台物理机或虚拟化环境、想搭一套能跑通创建实例全流程的 OpenStack 私有云、并且愿意为排错花时间的工程师。我会按「先想清楚架构 → 再选部署方式 → 落地最小可用集群 → 排掉高频故障 → 收一个可验证的进阶技巧」这条线走不堆概念只讲能复现的命令和参数。OpenStack 部署这件事玄学的地方不多翻车的地方很集中把那些集中点讲透比背架构图有用。2. 先定架构再动手OpenStack 私有云的最小可用拓扑怎么画2.1 为什么一上来就要砍掉「全功能集群」的幻想新手最容易犯的错是照着官方文档把 Keystone、Glance、Nova、Neutron、Cinder、Horizon 全塞进一台机器然后指望它稳定。单机 all-in-one 确实能跑起来但它把控制面和数据面压在同一套内核参数、同一块网卡、同一个 MySQL 上一旦你要加第二台计算节点网络和消息队列的配置立刻变成一团乱麻。我的建议是第一版私有云只做「1 控制 1 计算」两节点控制节点跑数据库、消息队列、Keystone、Glance、Nova API、Neutron Server、Horizon计算节点只跑 Nova Compute 和 Neutron Agent。这样拓扑清晰出问题能快速定位是控制面还是数据面。选型上操作系统用 Ubuntu 20.04 LTS 或 CentOS Stream 8 都行关键是内核版本要支持你打算用的 Neutron 网络方案。网络方案我强烈建议第一版用 provider network扁平网络不要碰 VXLAN 自服务网络。provider network 把实例直接桥到物理网段少一层封装少一堆 MTU 和隧道排错。存储先用本地 LVM 给 Cinder 做后端别急着上 CephCeph 本身就是一个需要单独排错的分布式系统两个坑叠在一起你分不清是谁的问题。提示控制节点内存至少 8 GB计算节点按你要跑的实例规格倒推一般 16 GB 起步。磁盘用 SSDOpenStack 的数据库和消息队列对随机 IO 很敏感。2.2 两节点拓扑的地址与角色分配表动手前先把地址和角色写死后面所有配置文件都从这里取值避免边装边改导致不一致。角色主机名管理网 IPProvider 网桥运行服务控制节点controller10.0.0.11无MySQL、RabbitMQ、Keystone、Glance、Nova API、Neutron Server、Horizon计算节点compute0110.0.0.21br-providerNova Compute、Neutron Linux Bridge Agent管理网段-10.0.0.0/24-服务间通信、API 访问Provider 网段-192.168.100.0/24-实例对外通信管理网和 Provider 网可以是同一块物理网卡的不同 VLAN也可以是两块网卡。第一版为了简单我用两块网卡ens33 走管理网ens34 走 Provider 网并桥接到 br-provider。计算节点的 br-provider 要挂到 ens34 上并且 ens34 本身不能配 IPIP 配在网桥上。2.3 部署方式选 Kolla-Ansible 还是手工装手工装能让你彻底理解每个服务的配置项但耗时以天计而且容易在数据库授权、消息队列用户、服务注册这些重复劳动上出错。Kolla-Ansible 用容器把每个服务封起来配置通过 globals.yml 和 inventory 统一注入适合想快速拿到可用集群的人。我的做法是第一遍用 Kolla-Ansible 把集群跑通理解服务之间的依赖和端口第二遍再挑一个服务手工装搞懂它的配置到底在干什么。这篇笔记的落地步骤以 Kolla-Ansible 为主线因为它可复现性最强参数集中排错时看容器日志就能定位。3. 用 Kolla-Ansible 落地两节点集群从裸机到创建第一台实例3.1 基础环境准备时间同步、内核参数与 Python 依赖三台机器如果你把控制节点和部署节点分开就是三台合在一起就是两台先做四件事时间同步、主机名解析、内核参数、Python 虚拟环境。时间不同步会让 Keystone 的 token 校验直接失败这个坑我见过太多次。# 在 controller 和 compute01 上分别执行 sudo hostnamectl set-hostname controller # compute01 上改成 compute01 sudo timedatectl set-timezone Asia/Shanghai sudo apt update sudo apt install -y chrony python3-dev python3-venv libffi-dev gcc libssl-dev # 配置 chrony 指向同一个内网时间源没有就互相指向 controller # /etc/chrony/chrony.conf 里加server controller iburst sudo systemctl restart chrony chronyc sources -v # 确认有 * 号选中的源 # 内核参数开启 IP 转发和桥接Neutron 需要 cat EOF | sudo tee /etc/sysctl.d/99-openstack.conf net.ipv4.ip_forward 1 net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 EOF sudo modprobe br_netfilter sudo sysctl -p /etc/sysctl.d/99-openstack.conf时间同步用 chronychronyc sources -v里出现^*才说明同步成功。内核参数里bridge-nf-call-iptables必须为 1否则 Linux Bridge 上的安全组规则不生效实例能通但防火墙形同虚设。br_netfilter模块要显式加载Ubuntu 默认不加载它sysctl -p会报找不到 bridge 相关键。3.2 部署节点上的 Kolla-Ansible 安装与 inventory 编写选一台机器作为部署节点通常就是 controller。在部署节点上建虚拟环境装 Kolla-Ansible版本要和你的 OpenStack 版本对应。这里以 Yoga 版本为例装的时候用 pip 指定版本避免拉到不兼容的最新版。python3 -m venv /opt/kolla-venv source /opt/kolla-venv/bin/activate pip install -U pip pip install kolla-ansible14.0.0 ansible5.10.0 # 初始化配置目录 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/multinode /etc/kolla/inventorykolla-ansible14.0.0对应 OpenStack Yogaansible5.10.0是它验证过的组合。inventory 用 multinode 模板因为我们是两节点。复制完先别急着改用kolla-genpwd生成密码文件所有服务的密码会写进/etc/kolla/passwords.yml后面配置里引用变量即可不要手写明文密码。kolla-genpwd # 编辑 /etc/kolla/inventory按下面结构改inventory 的关键段落长这样[control] controller ansible_host10.0.0.11 [network] controller ansible_host10.0.0.11 [compute] compute01 ansible_host10.0.0.21 [monitoring] controller ansible_host10.0.0.11 [storage] controller ansible_host10.0.0.11[control]和[network]都放 controller因为第一版网络服务和控制服务同机。[compute]只放 compute01。ansible_host写管理网 IPAnsible 通过 SSH 连过去所以部署节点要能免密 SSH 到这两台机器ssh-copy-id先做掉。3.3 globals.yml 里必须改的 8 个参数/etc/kolla/globals.yml是 Kolla 的总开关默认值大多不能用。下面这 8 个参数不改部署必挂或者部署完不能用。# /etc/kolla/globals.yml 关键片段 kolla_base_distro: ubuntu openstack_release: yoga kolla_internal_vip_address: 10.0.0.11 # 单控制节点就写控制节点管理 IP network_interface: ens33 # 管理网网卡 neutron_external_interface: ens34 # Provider 网网卡不能配 IP neutron_plugin_agent: linuxbridge # 第一版用 linuxbridge比 ovs 少一层 enable_neutron_provider_networks: yes # 允许创建 provider 网络 enable_cinder: yes cinder_volume_group: cinder-volumes # 计算节点上提前建好的 LVM 卷组kolla_internal_vip_address在单控制节点场景下直接写控制节点 IP不要用 keepalived 的 VIP否则 HAProxy 会起不来。neutron_external_interface是 Provider 网网卡它会被 Kolla 接管并桥接所以这块网卡在系统里不能有 IP有 IP 会导致网桥创建失败。cinder_volume_group要求计算节点上已经存在名为 cinder-volumes 的 LVM 卷组用vgs确认。3.4 执行部署与验证服务状态部署分两步bootstrap 装基础依赖deploy 拉容器起服务。bootstrap 会装 Docker、配置镜像加速、装一些 Python 包耗时几分钟。source /opt/kolla-venv/bin/activate kolla-ansible -i /etc/kolla/inventory bootstrap-servers kolla-ansible -i /etc/kolla/inventory prechecks kolla-ansible -i /etc/kolla/inventory deployprechecks会检查端口占用、磁盘空间、网卡配置任何一项不过都会明确报出来先解决再 deploy。deploy阶段如果卡在某个容器起不来用docker logs 容器名看日志常见的是数据库连接失败或消息队列认证失败多半是 passwords.yml 没生成或 inventory 主机名对不上。部署完成后生成 admin 凭据并验证kolla-ansible -i /etc/kolla/inventory post-deploy source /etc/kolla/admin-openrc.sh openstack token issue # 能返回 token 说明 Keystone 正常 openstack compute service list # 能看到 nova-compute 状态为 enabled/up openstack network agent list # 能看到 linuxbridge agent 为 aliveopenstack compute service list里 nova-compute 的 State 必须是 up如果是 down去 compute01 上看/var/log/kolla/nova/nova-compute.log八成是消息队列连不上或虚拟化不支持。openstack network agent list里 Linux bridge agent 的 Alive 为 True 才算网络就绪。3.5 创建第一台实例网络、镜像、规格、安全组四件套服务全绿之后按顺序创建 provider 网络、上传镜像、建规格、配安全组最后起实例。source /etc/kolla/admin-openrc.sh # 1. 创建 provider 网络对应 192.168.100.0/24 openstack network create --share --external \ --provider-physical-network physnet1 \ --provider-network-type flat provider openstack subnet create --network provider \ --allocation-pool start192.168.100.100,end192.168.100.200 \ --dns-nameserver 223.5.5.5 --gateway 192.168.100.1 \ --subnet-range 192.168.100.0/24 provider-subnet # 2. 上传 cirros 测试镜像 openstack image create --disk-format qcow2 --container-format bare \ --file cirros-0.5.2-x86_64-disk.img cirros # 3. 建规格 openstack flavor create --vcpus 1 --ram 512 --disk 5 m1.tiny # 4. 安全组放行 ICMP 和 SSH openstack security group rule create --proto icmp default openstack security group rule create --proto tcp --dst-port 22 default # 5. 起实例 openstack server create --flavor m1.tiny --image cirros \ --nic net-id$(openstack network show provider -f value -c id) \ --security-group default test-vm--provider-physical-network physnet1要和 Neutron 配置里的physical_network名字一致Kolla 默认就是 physnet1。--allocation-pool是实例能拿到的 IP 范围要和物理网段错开避免和物理机冲突。起完实例用openstack server list看状态ACTIVE 之后从同网段机器 ping 它的 IP通了就说明 provider 网络链路完整。4. 部署完就翻车OpenStack 私有云高频故障排查清单4.1 现象Horizon 能打开但登录报 500原因通常是 Keystone 连不上数据库或者 memcached 没起来。Keystone 的 token 存在 memcached 里memcached 容器挂了登录就会 500。解决docker ps | grep memcached确认容器在跑不在就docker start memcached再看/var/log/kolla/keystone/keystone.log如果是数据库连接错误检查passwords.yml里database_password和 MySQL 容器里的实际密码是否一致Kolla 部署后改过密码会导致不一致。4.2 现象实例创建成功但 ping 不通先确认实例是否真的拿到了 IPopenstack server show test-vm看 addresses 字段。如果没 IP是 DHCP agent 没工作openstack network agent list看 DHCP agent 是否 alive。如果有 IP 但 ping 不通检查计算节点上 br-provider 是否把 ens34 挂上去了brctl show看接口列表。另一个高频原因是安全组没放行 ICMP默认安全组只放行出站入站 ICMP 要手动加规则。4.3 现象nova-compute 状态 up 但创建实例报 NoValidHost这是调度器找不到合适计算节点。常见原因是计算节点上报的资源为 0openstack compute service list看 up 不代表资源可用要看openstack hypervisor show compute01里的 vcpus 和 memory_mb。如果都是 0说明 nova-compute 没正确识别虚拟化能力去 compute01 上egrep -c (vmx|svm) /proc/cpuinfo返回 0 说明 CPU 不支持硬件虚拟化或者你在虚拟机里嵌套部署但没开嵌套虚拟化。解决物理机进 BIOS 开 VT-x/AMD-V虚拟机里给 CPU 加vmx标志。4.4 现象Cinder 创建卷一直处于 creatingCinder 卷创建卡住九成是卷组不存在或权限不对。去计算节点vgs看有没有 cinder-volumes 卷组没有就pvcreatevgcreate建一个。有卷组还卡看/var/log/kolla/cinder/cinder-volume.log如果是Permission denied检查/dev/vg的属主Kolla 的 cinder-volume 容器以 cinder 用户跑需要能读写块设备。解决chown cinder:cinder /dev/vg或者把 cinder 用户加进 disk 组。4.5 现象部署到一半 Ansible 报 SSH 超时Kolla 部署过程中 Ansible 会反复 SSH 到各节点如果某台机器负载高或者 SSH 连接数打满就会超时。先确认部署节点到目标节点的免密 SSH 正常ssh compute01 echo ok能秒回。如果正常还超时调大 Ansible 的超时和重试在/etc/kolla/ansible.cfg里设timeout 60、gather_timeout 60并在 inventory 里给问题节点加ansible_ssh_common_args-o ConnectTimeout30。别小看这个我曾在低配虚拟机上因为 SSH 超时反复重跑 deploy浪费了一下午。5. 让私有云真正可用从能跑到能扛的验证与调优技巧集群跑通只是起点能不能扛住日常使用要看几个关键验证。第一个验证是重启后自愈把 compute01 重启等它起来后openstack compute service list里 nova-compute 应该自动恢复 up如果没恢复说明容器没设 restart policyKolla 默认是unless-stopped正常会自启没自启就查 Docker 服务本身是否 enabled。第二个验证是并发创建一次性起 5 台实例看调度是否均匀落到计算节点如果全挤在一台检查 Nova 的ram_weight_multiplier和cpu_weight_multiplier默认值在资源不均衡时会偏向某一台可以调成ram_weight_multiplier 1.0让内存权重更平滑。第三个验证是网络性能provider network 下实例到物理网关的延迟应该和物理机同网段延迟接近如果高出一截检查 br-provider 上是否误开了 STPbrctl showstp br-provider看 stateSTP 在简单拓扑里只会添乱关掉它。第四个验证是镜像上传速度Glance 默认后端是本地文件大镜像上传慢是正常的如果慢到不可接受把 Glance 后端换成 Ceph RBD 或者加 SSD但那是另一个坑第一版不建议动。调优上我一般会改两个地方。一是 MySQL 的innodb_buffer_pool_size控制节点内存 8 GB 的话给 2 GB默认值太小服务一多就频繁读盘。二是 RabbitMQ 的vm_memory_high_watermark默认 0.4内存紧张时消息队列会阻塞调到 0.6 并确保机器内存够。这两个参数在 Kolla 里通过/etc/kolla/config/下的服务专属配置文件覆盖改完kolla-ansible -i inventory reconfigure生效不用全量重部署。最后说一个我自己的习惯每次改完配置先跑kolla-ansible -i inventory prechecks再跑reconfigure最后用openstack token issue和openstack server list做冒烟测试。这套动作花不了两分钟但能挡住八成「改完就挂」的情况。私有云这东西稳定不是装出来的是每次变更后验证出来的。希望帮到你。本文还有配套的精品资源点击获取
