简介这是一份面向OpenStack初学者及云计算运维人员的安装部署手册围绕Havana版本梳理了从环境准备到核心组件配置的完整流程适合需要快速搭建IaaS平台的读者参考。资源为单个docx文档大小约519KB内容按项目式目录组织涵盖网卡配置、主机名修改、MySQL数据库安装以及Keystone、Glance、Nova、Swift、Cinder、Neutron等组件的整体结构与部署要点。其中Keystone认证服务的配置占据较大篇幅包括数据库连接、授权令牌、密钥证书、用户租户与角色定义等关键操作既可作为课堂学习笔记也可作为实际部署的对照清单。目前已有369人浏览学习文档将理论与命令步骤相结合能帮助读者减少踩坑、提升部署效率。1. OpenStack 安装部署的第一步先选对部署方式和版本OpenStack 的安装部署让很多人止步的第一道坎不是命令有多复杂而是它根本不是一个可以“一条命令装完”的单体软件。它由身份认证Keystone、计算Nova、网络Neutron、镜像Glance、存储Cinder/Swift、仪表盘Horizon等十几个独立服务组成彼此通过消息队列和数据库通信安装顺序稍有不慎后边会被一堆隐晦的报错追着跑。部署方式也分三派面向开发者的 DevStack、面向中小规模的 Packstack、面向生产环境的 Kolla-Ansible选错方向的成本比装错版本还高。对大多数做技术验证、内部云平台试用或中小规模交付的团队来说先用 Packstack 快速拉通再逐步改关键参数是一条投入产出比最高的路径。下面按这个思路把节点规划、环境准备、核心服务搭建、参数调优和安装后的验证串成一条完整链路。2. 安装部署前的节点规划与基础环境准备2.1 控制节点、计算节点、网络节点的角色与资源划分OpenStack 的节点规划决定后续扩展的余地。常见的最小部署是单节点控制计算网络合在一台机器和三节点控制、计算、存储分离。我一般建议即使是测试环境至少把控制节点和计算节点分开因为 Nova Compute 的 CPU 超分会直接挤压控制面服务的响应。规划时可以按下面的表格做初版配置再根据现网流量调整。节点角色承载服务最低配置参考关键考量控制节点Keystone、Nova API/Scheduler、Neutron Server、Glance、Horizon8C16G、100G 系统盘数据库和 RabbitMQ 一般也在这内存不足时调度响应明显变慢计算节点Nova Compute、Neutron OVS Agent16C32G、数据盘按实例量规划CPU 和内存超分都发生在这层决定可跑多少虚机网络节点Neutron L3 Agent、DHCP Agent、Metadata Agent4C8G、至少两张物理网卡小规模可并入控制节点但路由和 DHCP 流量大时会抢 API 响应存储节点Cinder Volume、Swift按 IOPS 和容量规划生产环境建议从控制节点剥离避免磁盘 IO 互相干扰除了角色划分网络规划比 CPU 内存更敏感。管理网、租户网、外部网浮动 IP 网建议使用独立网段租户网用 VXLAN 时不容易撞 MTU 问题。工作里遇到最多的一类安装部署失败是管理网和租户网共用一张网卡还开了默认防火墙策略导致 Neutron Agent 之间通信偶发超时。另一个容易踩的点是磁盘分区控制节点的数据库和镜像存储目录 /var/lib/glance/images 建议单独挂数据盘避免系统盘写满后整个控制面服务不可用。2.2 版本选型发行版、OpenStack Release 与部署工具的对应关系版本选型先决定发行版再定 OpenStack Release。常见做法是 Rocky Linux / CentOS Stream 搭档 Yoga 或更高版本Ubuntu Server 偏好用 Kolla-Ansible 的容器化部署。我不建议新手直接混搭不同系列的版本号比如在 CentOS 7 上装 Train 之后的版本依赖冲突会非常头疼。追求最快跑通且不依赖容器环境用 CentOS Stream Packstack生产化部署、后面要滚动升级直接上 Kolla-Ansible它把每个 OpenStack 服务封装成容器升级只是换镜像版本。选版本时还要确认发行版的原生软件源里是否带 openstack-release 包。Rocky Linux 9 系列对应 OpenStack Antelope 以后的版本CentOS Stream 9 对 Yoga 之后也都有现成仓库。把 release 包和部署工具绑定确认好能避免装到一半发现 Python 依赖冲突。Packstack 依赖 Puppet 执行部署脚本Puppet 版本与 OpenStack release 的兼容性由 release 包指定所以不要手动升级系统里的 Puppet 组件否则跑起来会看到大量 catalog 编译报错。2.3 基础环境准备的最小命令集在动手执行安装脚本之前有三类前置工作必须落地主机名解析、时钟同步、防火墙端口放行。这一步经常被当成“小事”略过实际是后续所有报错的源头。下面的命令在多台机器上都要执行IP 按实际规划改。# 设置主机名并写入 hosts确保各节点能互相解析 hostnamectl set-hostname controller cat /etc/hosts EOF 192.168.10.11 controller 192.168.10.12 compute01 EOF # 安装并启动 chrony避免 Keystone token 因时间偏差校验失败 yum install -y chrony systemctl enable --now chronyd chronyc makestep # 防火墙放行必要端口测试环境可直接禁用 firewalld systemctl stop firewalld systemctl disable firewalld这段脚本的核心逻辑是先把节点间名字解析做对因为 OpenStack 各服务的配置里大量使用主机名而不是 IPKeystone 创建的 endpoint 默认也是主机名形式。时间同步直接影响 Keystone token 的签发和校验时间偏差超过 5 分钟会出现偶发的 401 认证失败。防火墙在测试环境直接关掉可以少踩很多坑生产环境则按服务端口白名单放行这里用 stop 是明确测试环境的取舍。另一个容易被忽略的准备项是 systemd 的默认 ulimit 和网卡命名策略。使用多个网卡时建议通过 biosdevname 或 net.ifnames 参数固定网卡命名的确定性否则重启后 eth0/eth1 顺序变化Neutron 绑定网卡的配置会失效。这个可以在 /etc/default/grub 的 GRUB_CMDLINE_LINUX 里追加 net.ifnames0更新 grub 后重启生效。注意Packstack 部署过程会在控制节点安装并启动 MariaDB 和 RabbitMQ。如果系统里之前已经装了 MySQL 或服务占用了 3306/5672 端口先停掉旧服务否则部署脚本会在数据库初始化那一步失败。3. 用 Packstack 搭建 OpenStack 核心服务的参数与流程3.1 为什么中小规模场景先用 Packstack 而不是直接上 KollaKolla-Ansible 的容器化部署确实更接近生产但它的前提是 Docker、Ansible、Python 虚拟环境、镜像构建网络都要提前准备利落整套初始化脚本的复杂度对第一次接触 OpenStack 的新手并不友好。Packstack 走的是 Puppet 一站式编排一个 answer-file 把要启用哪些服务、各服务的管理员密码、网络类型都预先定好执行 packstack 命令后自动完成安装、配置、启动三步。它的优势就是快和确定性高适合内部 Demo、功能验证、以及作为理解 OpenStack 服务依赖关系的活教材。后续迁移到 Kolla-Ansible 时已经积累的节点规划经验和镜像配置仍然可以复用。社区对 Packstack 的维护节奏是跟随每个 release 更新它本身不支持三控制节点的高可用架构。所以如果一开始就知道要上 HA 场景直接走 Kolla-Ansible 或者手工拆分部署会更合适。Packstack 的意义在于让人快速得到一个功能完整的 OpenStack 环境把精力优先放在理解服务依赖、网络拓扑和调参上而不是在 Puppet 模块的坑里挣扎。3.2 生成 answer file 并调整关键参数Packstack 的核心操作围绕 answer file 展开。先生成默认模板再按环境修改最后执行部署。以下命令在控制节点执行yum install -y centos-release-openstack-yoga yum install -y openstack-packstack packstack --gen-answer-file/root/answers.txt # 修改关键参数 sed -i s/^CONFIG_NTP_SERVERS.*/CONFIG_NTP_SERVERSntp.aliyun.com/ /root/answers.txt sed -i s/^CONFIG_KEYSTONE_ADMIN_PW.*/CONFIG_KEYSTONE_ADMIN_PWAdmin123456/ /root/answers.txt sed -i s/^CONFIG_NEUTRON_ML2_TYPE_DRIVERS.*/CONFIG_NEUTRON_ML2_TYPE_DRIVERSvxlan,flat/ /root/answers.txt sed -i s/^CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS.*/CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGSphysnet1:br-ex/ /root/answers.txt packstack --answer-file/root/answers.txt 21 | tee /root/packstack.log第一段命令安装 release 包和 packstack 本体release 包会把 Packstack 依赖的 Puppet 模块版本一起锁定。生成 answer file 后用 sed 做定向替换比手动编辑更不容易漏掉行尾格式。NTP 服务指定为内网或公网时钟源保证所有装出来的服务节点共用同一时间基准。管理员密码是后续所有 openstack 命令的入口凭证。ML2 类型驱动保留 vxlan 和 flat 两种vxlan 用于租户网络隔离flat 用于对接外部物理网络。br-ex 网桥名要和后续网络节点的 OVS 网桥配置保持一致。3.2.1 answer file 中必须人工确认的字段执行部署之前回答文件里有一批字段建议逐个确认而不是全部依赖默认值。用 grep 过滤出当前值比翻文件更快grep -E ^CONFIG_(KEYSTONE_ADMIN_PW|NTP_SERVERS|NEUTRON_ML2_TYPE_DRIVERS) /root/answers.txt如果 KEYSTONE_ADMIN_PW 为空或包含默认的弱密码后续创建租户和分配配额时很容易被安全策略拦下来。CONFIG_NEUTRON_OVS_BRIDGE_IFACES 这一项决定 br-ex 绑定哪张物理网卡填错了外部网络能创建但实例出不去。还有 CONFIG_PROVISION_DEMO 字段它控制是否自动生成 demo 租户和测试网络如果是纯生产用途建议设为 n减少后续清理的工作量。3.3 多节点部署必须显式指定的配置项Packstack 默认把全部服务装在本机多节点部署需要修改 answer file 中的主机地址字段。核心是把控制节点地址和计算节点地址分开以下是几个常见配置项。answer file 参数单节点默认值多节点推荐值作用CONFIG_CONTROLLER_HOST本机 IP控制节点管理 IP指定 Keystone、Nova API 等控制服务所在主机CONFIG_COMPUTE_HOSTS本机 IP控制节点,计算节点1,计算节点2指定运行 Nova Compute 的节点列表CONFIG_NETWORK_HOSTS本机 IP控制节点网络服务默认随控制节点也可独立拆分CONFIG_STORAGE_HOST本机 IP控制节点或独立存储节点Cinder 服务所在主机多节点执行时控制节点先跑 Packstack计算节点不需要单独安装 Packstack它会被 Puppet 脚本远程写入配置。前提是控制节点能免密 SSH 到所有计算节点的 root。如果执行中出现 SSH 权限报错优先检查 ~/.ssh/authorized_keys 是否写入正确、SELinux 是否拦截了 sshd 的 authorized_keys 写入。检查命令如下ssh-copy-id rootcompute01 ssh rootcompute01 hostname部署过程本身耗时取决于计算节点数量和仓库下载速度通常 15 到 40 分钟。中途日志会逐项输出 Running Puppet看到某一步长时间卡住且 CPU 占用不高多半是网络下载超时或 YUM 源不可达可以 CtrlC 中止后重新跑。Packstack 在一定程度上支持失败后重新执行重复执行时建议保留原 answer file它内部会识别已经完成的服务模块。注意不要同时跑两个 packstack 实例操作同一台控制节点Puppet 的锁机制会让你白等一个很长的超时时间。在 tmux 会话里跑部署脚本是个好习惯SSH 断线不影响部署进程。4. OpenStack 计算与网络服务的必调参数及安装失败排查4.1 计算节点的内存超分与 CPU 绑定策略Nova 是安装部署完成后最先需要调优的组件。默认配置下计算节点的内存超分比是 1.5即物理内存 256GB 的节点最多能调度出 384GB 的实例内存。对跑轻量 Web 虚机的场景够用但如果上面跑数据库或 Java 应用建议把超分比降到 1.0 到 1.2。修改内存超分的方式是调整 nova.conf 的 ram_allocation_ratio# /etc/nova/nova.conf 中的 [DEFAULT] 段 [DEFAULT] ram_allocation_ratio 1.2 cpu_allocation_ratio 8.0# 修改后重启 nova-compute 服务 systemctl restart openstack-nova-computecpu_allocation_ratio 控制 vCPU 与物理核的比值8.0 意味着单核跑 8 个 vCPU适合 CPU 密集型程度低的内部测试环境。生产环境建议设为 2.0 到 4.0 并配合 cgroup 的 cpu.shares 做权重控制。4.1.1 内存超分与 CPU 绑定的边界超分不是无限度的。ram_allocation_ratio 调到 2.0 以上时实例内存页的交换会显著增加表现为虚机卡顿和宿主机 load average 居高不下。另一个常见调优点是 CPU 绑定在 libvirt 层面开启 vCPU pinning 能减少上下文切换但需要先确认 CPU 拓扑支持并预留一个物理核给宿主机系统本身。镜像格式对计算节点也有直接影响。qcow2 是通用选择支持快照和按需分配但要留意转换成 raw 格式的实例 IO 性能更好适合数据库类负载。创建镜像时用 glance image-create 指定 disk-formatqcow2 和 container-formatbare 是最稳的组合容器格式不要随意填其他值否则 Nova 在调度时候无法正确识别后端存储驱动。4.2 网络节点与 Neutron 的 MTU 兼容性配置网络是安装部署完成之后最容易被误用的一层。Packstack 默认使用 Open vSwitch 加 VXLAN租户网络通过 VXLAN 隧道封装理论上不受物理网络 VLAN 数量限制。但 VXLAN 的封装头是 50 字节默认虚拟网卡的 MTU 1500 在隧道里会出现分片。正确做法是把虚机网卡 MTU 统一改成 1450同时物理交换机端口启用 jumbo frame 支持。很多用户遇到虚机网络忽通忽断检查 MTU 是最先要看的点。# 在 network 节点 OpenStack 侧的配置 openstack network create --mtu 1450 --provider-network-type vxlan test-net openstack subnet create --network test-net --subnet-range 192.168.100.0/24 --dhcp test-subnetFlat 模式则用于外部网络直通将物理网卡直接映射到 br-ex 网桥。修改 /etc/neutron/plugins/ml2/openvswitch_agent.ini 里的 bridge_mappings 和 tunnel_type[ovs] bridge_mappings physnet1:br-ex tunnel_type vxlan [agent] tunnel_types vxlan enable_distributed_routing False参数说明bridge_mappings 左侧是物理网络名称右侧是 OVS 网桥名称这里的 physnet1 要与创建外部网络时指定的 physical_network 同名名称不一致会导致外部网络无法创建端口。tunnel_type 选择 vxlan 后租户网络才能使用 VXLAN 分段。enable_distributed_routing 默认关闭开启后 DVR 模式允许计算节点直接转发外部流量但需要额外配置 L3 agent 并且对控制平面的依赖反而变多建议先保持关闭跑通后再验证开启避免一开始排错范围变大。4.3 安装部署日志的定位与三条排查命令安装部署中排错第一步是看日志但 OpenStack 日志分散在多处容易找错方向。常用到的日志位置是 /var/log/keystone、/var/log/nova、/var/log/neutron 三个目录。按时间筛选错误是最有效的启动方式以 Neutron 为例grep -i ERROR\|Traceback /var/log/neutron/server.log | tail -50 journalctl -u openstack-nova-compute --since 10 minutes ago openstack-service statusopenstack-service status 是安装部署之后最高频使用的体检命令它会把宿主机上所有 OpenStack 相关服务进程逐一检查并输出启停状态。配合 systemctl list-units 可以快速定位哪个服务挂掉。以下是线上环境最常遇到的几类安装失败表现表现大概率原因优先检查方向Keystone 认证 401系统时间偏差超过 5 分钟chronyc tracking 查看时间源Nova 调度失败计算节点没有可用内存或元数据不匹配openstack hypervisor show 节点状态Neutron 端口创建失败bridge_mappings 名称不一致或网卡未加入网桥ovs-vsctl show 查网桥端口Cinder 卷无法附加存储节点 iscsi 服务未启动systemctl status iscsid注意排错时先看服务状态再看应用日志最后才动配置文件。很多人一看 500 错误就改配置结果把原本正常的参数改坏了。手上有 openstack-service status 的输出能节省一半的排查时间。5. 安装完成后的验证路径与一键体检命令安装部署完成不代表服务可用验证要分成基础设施、认证与安全、业务链路三层。先把 admin 环境变量加载进来然后按下面的顺序执行source /root/keystonerc_admin openstack endpoint list openstack service list openstack image list openstack network list openstack hypervisor listendpoint list 的输出能确认四个核心服务的 API 地址都是可解析的主机名hypervisor list 能看到计算节点状态。接着创建一张测试镜像和一台最小规格虚拟机验证从镜像到网络再到控制台的全链路wget http://download.cirros-cloud.net/0.6.1/cirros-0.6.1-x86_64-disk.img openstack image create --file cirros-0.6.1-x86_64-disk.img --disk-format qcow2 --container-format bare --public cirros openstack server create --flavor m1.tiny \ --image cirros --network test-net \ --key-name mykey cirros-test openstack server list如果 server list 里的实例 STATUS 从 BUILD 变成 ACTIVE并且 POWER STATE 是 Running说明 Nova 调度、镜像下载、网络端口创建全部成功。最后一步是验证访问路径通过安全组规则放行 SSH或直接在计算节点上 ping 实例的内网 IP。很多情况下实例状态是 ACTIVE 但网络不通问题都出在安全组默认规则上而不是安装部署环节。验证完成后收尾的做法是把 keystonerc_admin 文件备份到安全位置并修改默认密码。这里有一个值得记住的技巧OpenStack 在安装部署时生成的所有密码都记录在 answer file 里但脚本不会自动更新密码哈希。可以用以下命令快速确认实际生效的服务状态并把它写成一行别名方便以后反复体检alias oschecksource /root/keystonerc_admin openstack-service status openstack endpoint list oscheck把 oscheck 写入 /root/.bashrc后续巡检只需要敲一个命令就能拿到服务活体状态和最核心的 endpoint 信息运维接手时的第一手信息都在这里。本文还有配套的精品资源点击获取
OpenStack安装部署实战：Packstack从节点规划到参数调优
简介这是一份面向OpenStack初学者及云计算运维人员的安装部署手册围绕Havana版本梳理了从环境准备到核心组件配置的完整流程适合需要快速搭建IaaS平台的读者参考。资源为单个docx文档大小约519KB内容按项目式目录组织涵盖网卡配置、主机名修改、MySQL数据库安装以及Keystone、Glance、Nova、Swift、Cinder、Neutron等组件的整体结构与部署要点。其中Keystone认证服务的配置占据较大篇幅包括数据库连接、授权令牌、密钥证书、用户租户与角色定义等关键操作既可作为课堂学习笔记也可作为实际部署的对照清单。目前已有369人浏览学习文档将理论与命令步骤相结合能帮助读者减少踩坑、提升部署效率。1. OpenStack 安装部署的第一步先选对部署方式和版本OpenStack 的安装部署让很多人止步的第一道坎不是命令有多复杂而是它根本不是一个可以“一条命令装完”的单体软件。它由身份认证Keystone、计算Nova、网络Neutron、镜像Glance、存储Cinder/Swift、仪表盘Horizon等十几个独立服务组成彼此通过消息队列和数据库通信安装顺序稍有不慎后边会被一堆隐晦的报错追着跑。部署方式也分三派面向开发者的 DevStack、面向中小规模的 Packstack、面向生产环境的 Kolla-Ansible选错方向的成本比装错版本还高。对大多数做技术验证、内部云平台试用或中小规模交付的团队来说先用 Packstack 快速拉通再逐步改关键参数是一条投入产出比最高的路径。下面按这个思路把节点规划、环境准备、核心服务搭建、参数调优和安装后的验证串成一条完整链路。2. 安装部署前的节点规划与基础环境准备2.1 控制节点、计算节点、网络节点的角色与资源划分OpenStack 的节点规划决定后续扩展的余地。常见的最小部署是单节点控制计算网络合在一台机器和三节点控制、计算、存储分离。我一般建议即使是测试环境至少把控制节点和计算节点分开因为 Nova Compute 的 CPU 超分会直接挤压控制面服务的响应。规划时可以按下面的表格做初版配置再根据现网流量调整。节点角色承载服务最低配置参考关键考量控制节点Keystone、Nova API/Scheduler、Neutron Server、Glance、Horizon8C16G、100G 系统盘数据库和 RabbitMQ 一般也在这内存不足时调度响应明显变慢计算节点Nova Compute、Neutron OVS Agent16C32G、数据盘按实例量规划CPU 和内存超分都发生在这层决定可跑多少虚机网络节点Neutron L3 Agent、DHCP Agent、Metadata Agent4C8G、至少两张物理网卡小规模可并入控制节点但路由和 DHCP 流量大时会抢 API 响应存储节点Cinder Volume、Swift按 IOPS 和容量规划生产环境建议从控制节点剥离避免磁盘 IO 互相干扰除了角色划分网络规划比 CPU 内存更敏感。管理网、租户网、外部网浮动 IP 网建议使用独立网段租户网用 VXLAN 时不容易撞 MTU 问题。工作里遇到最多的一类安装部署失败是管理网和租户网共用一张网卡还开了默认防火墙策略导致 Neutron Agent 之间通信偶发超时。另一个容易踩的点是磁盘分区控制节点的数据库和镜像存储目录 /var/lib/glance/images 建议单独挂数据盘避免系统盘写满后整个控制面服务不可用。2.2 版本选型发行版、OpenStack Release 与部署工具的对应关系版本选型先决定发行版再定 OpenStack Release。常见做法是 Rocky Linux / CentOS Stream 搭档 Yoga 或更高版本Ubuntu Server 偏好用 Kolla-Ansible 的容器化部署。我不建议新手直接混搭不同系列的版本号比如在 CentOS 7 上装 Train 之后的版本依赖冲突会非常头疼。追求最快跑通且不依赖容器环境用 CentOS Stream Packstack生产化部署、后面要滚动升级直接上 Kolla-Ansible它把每个 OpenStack 服务封装成容器升级只是换镜像版本。选版本时还要确认发行版的原生软件源里是否带 openstack-release 包。Rocky Linux 9 系列对应 OpenStack Antelope 以后的版本CentOS Stream 9 对 Yoga 之后也都有现成仓库。把 release 包和部署工具绑定确认好能避免装到一半发现 Python 依赖冲突。Packstack 依赖 Puppet 执行部署脚本Puppet 版本与 OpenStack release 的兼容性由 release 包指定所以不要手动升级系统里的 Puppet 组件否则跑起来会看到大量 catalog 编译报错。2.3 基础环境准备的最小命令集在动手执行安装脚本之前有三类前置工作必须落地主机名解析、时钟同步、防火墙端口放行。这一步经常被当成“小事”略过实际是后续所有报错的源头。下面的命令在多台机器上都要执行IP 按实际规划改。# 设置主机名并写入 hosts确保各节点能互相解析 hostnamectl set-hostname controller cat /etc/hosts EOF 192.168.10.11 controller 192.168.10.12 compute01 EOF # 安装并启动 chrony避免 Keystone token 因时间偏差校验失败 yum install -y chrony systemctl enable --now chronyd chronyc makestep # 防火墙放行必要端口测试环境可直接禁用 firewalld systemctl stop firewalld systemctl disable firewalld这段脚本的核心逻辑是先把节点间名字解析做对因为 OpenStack 各服务的配置里大量使用主机名而不是 IPKeystone 创建的 endpoint 默认也是主机名形式。时间同步直接影响 Keystone token 的签发和校验时间偏差超过 5 分钟会出现偶发的 401 认证失败。防火墙在测试环境直接关掉可以少踩很多坑生产环境则按服务端口白名单放行这里用 stop 是明确测试环境的取舍。另一个容易被忽略的准备项是 systemd 的默认 ulimit 和网卡命名策略。使用多个网卡时建议通过 biosdevname 或 net.ifnames 参数固定网卡命名的确定性否则重启后 eth0/eth1 顺序变化Neutron 绑定网卡的配置会失效。这个可以在 /etc/default/grub 的 GRUB_CMDLINE_LINUX 里追加 net.ifnames0更新 grub 后重启生效。注意Packstack 部署过程会在控制节点安装并启动 MariaDB 和 RabbitMQ。如果系统里之前已经装了 MySQL 或服务占用了 3306/5672 端口先停掉旧服务否则部署脚本会在数据库初始化那一步失败。3. 用 Packstack 搭建 OpenStack 核心服务的参数与流程3.1 为什么中小规模场景先用 Packstack 而不是直接上 KollaKolla-Ansible 的容器化部署确实更接近生产但它的前提是 Docker、Ansible、Python 虚拟环境、镜像构建网络都要提前准备利落整套初始化脚本的复杂度对第一次接触 OpenStack 的新手并不友好。Packstack 走的是 Puppet 一站式编排一个 answer-file 把要启用哪些服务、各服务的管理员密码、网络类型都预先定好执行 packstack 命令后自动完成安装、配置、启动三步。它的优势就是快和确定性高适合内部 Demo、功能验证、以及作为理解 OpenStack 服务依赖关系的活教材。后续迁移到 Kolla-Ansible 时已经积累的节点规划经验和镜像配置仍然可以复用。社区对 Packstack 的维护节奏是跟随每个 release 更新它本身不支持三控制节点的高可用架构。所以如果一开始就知道要上 HA 场景直接走 Kolla-Ansible 或者手工拆分部署会更合适。Packstack 的意义在于让人快速得到一个功能完整的 OpenStack 环境把精力优先放在理解服务依赖、网络拓扑和调参上而不是在 Puppet 模块的坑里挣扎。3.2 生成 answer file 并调整关键参数Packstack 的核心操作围绕 answer file 展开。先生成默认模板再按环境修改最后执行部署。以下命令在控制节点执行yum install -y centos-release-openstack-yoga yum install -y openstack-packstack packstack --gen-answer-file/root/answers.txt # 修改关键参数 sed -i s/^CONFIG_NTP_SERVERS.*/CONFIG_NTP_SERVERSntp.aliyun.com/ /root/answers.txt sed -i s/^CONFIG_KEYSTONE_ADMIN_PW.*/CONFIG_KEYSTONE_ADMIN_PWAdmin123456/ /root/answers.txt sed -i s/^CONFIG_NEUTRON_ML2_TYPE_DRIVERS.*/CONFIG_NEUTRON_ML2_TYPE_DRIVERSvxlan,flat/ /root/answers.txt sed -i s/^CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS.*/CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGSphysnet1:br-ex/ /root/answers.txt packstack --answer-file/root/answers.txt 21 | tee /root/packstack.log第一段命令安装 release 包和 packstack 本体release 包会把 Packstack 依赖的 Puppet 模块版本一起锁定。生成 answer file 后用 sed 做定向替换比手动编辑更不容易漏掉行尾格式。NTP 服务指定为内网或公网时钟源保证所有装出来的服务节点共用同一时间基准。管理员密码是后续所有 openstack 命令的入口凭证。ML2 类型驱动保留 vxlan 和 flat 两种vxlan 用于租户网络隔离flat 用于对接外部物理网络。br-ex 网桥名要和后续网络节点的 OVS 网桥配置保持一致。3.2.1 answer file 中必须人工确认的字段执行部署之前回答文件里有一批字段建议逐个确认而不是全部依赖默认值。用 grep 过滤出当前值比翻文件更快grep -E ^CONFIG_(KEYSTONE_ADMIN_PW|NTP_SERVERS|NEUTRON_ML2_TYPE_DRIVERS) /root/answers.txt如果 KEYSTONE_ADMIN_PW 为空或包含默认的弱密码后续创建租户和分配配额时很容易被安全策略拦下来。CONFIG_NEUTRON_OVS_BRIDGE_IFACES 这一项决定 br-ex 绑定哪张物理网卡填错了外部网络能创建但实例出不去。还有 CONFIG_PROVISION_DEMO 字段它控制是否自动生成 demo 租户和测试网络如果是纯生产用途建议设为 n减少后续清理的工作量。3.3 多节点部署必须显式指定的配置项Packstack 默认把全部服务装在本机多节点部署需要修改 answer file 中的主机地址字段。核心是把控制节点地址和计算节点地址分开以下是几个常见配置项。answer file 参数单节点默认值多节点推荐值作用CONFIG_CONTROLLER_HOST本机 IP控制节点管理 IP指定 Keystone、Nova API 等控制服务所在主机CONFIG_COMPUTE_HOSTS本机 IP控制节点,计算节点1,计算节点2指定运行 Nova Compute 的节点列表CONFIG_NETWORK_HOSTS本机 IP控制节点网络服务默认随控制节点也可独立拆分CONFIG_STORAGE_HOST本机 IP控制节点或独立存储节点Cinder 服务所在主机多节点执行时控制节点先跑 Packstack计算节点不需要单独安装 Packstack它会被 Puppet 脚本远程写入配置。前提是控制节点能免密 SSH 到所有计算节点的 root。如果执行中出现 SSH 权限报错优先检查 ~/.ssh/authorized_keys 是否写入正确、SELinux 是否拦截了 sshd 的 authorized_keys 写入。检查命令如下ssh-copy-id rootcompute01 ssh rootcompute01 hostname部署过程本身耗时取决于计算节点数量和仓库下载速度通常 15 到 40 分钟。中途日志会逐项输出 Running Puppet看到某一步长时间卡住且 CPU 占用不高多半是网络下载超时或 YUM 源不可达可以 CtrlC 中止后重新跑。Packstack 在一定程度上支持失败后重新执行重复执行时建议保留原 answer file它内部会识别已经完成的服务模块。注意不要同时跑两个 packstack 实例操作同一台控制节点Puppet 的锁机制会让你白等一个很长的超时时间。在 tmux 会话里跑部署脚本是个好习惯SSH 断线不影响部署进程。4. OpenStack 计算与网络服务的必调参数及安装失败排查4.1 计算节点的内存超分与 CPU 绑定策略Nova 是安装部署完成后最先需要调优的组件。默认配置下计算节点的内存超分比是 1.5即物理内存 256GB 的节点最多能调度出 384GB 的实例内存。对跑轻量 Web 虚机的场景够用但如果上面跑数据库或 Java 应用建议把超分比降到 1.0 到 1.2。修改内存超分的方式是调整 nova.conf 的 ram_allocation_ratio# /etc/nova/nova.conf 中的 [DEFAULT] 段 [DEFAULT] ram_allocation_ratio 1.2 cpu_allocation_ratio 8.0# 修改后重启 nova-compute 服务 systemctl restart openstack-nova-computecpu_allocation_ratio 控制 vCPU 与物理核的比值8.0 意味着单核跑 8 个 vCPU适合 CPU 密集型程度低的内部测试环境。生产环境建议设为 2.0 到 4.0 并配合 cgroup 的 cpu.shares 做权重控制。4.1.1 内存超分与 CPU 绑定的边界超分不是无限度的。ram_allocation_ratio 调到 2.0 以上时实例内存页的交换会显著增加表现为虚机卡顿和宿主机 load average 居高不下。另一个常见调优点是 CPU 绑定在 libvirt 层面开启 vCPU pinning 能减少上下文切换但需要先确认 CPU 拓扑支持并预留一个物理核给宿主机系统本身。镜像格式对计算节点也有直接影响。qcow2 是通用选择支持快照和按需分配但要留意转换成 raw 格式的实例 IO 性能更好适合数据库类负载。创建镜像时用 glance image-create 指定 disk-formatqcow2 和 container-formatbare 是最稳的组合容器格式不要随意填其他值否则 Nova 在调度时候无法正确识别后端存储驱动。4.2 网络节点与 Neutron 的 MTU 兼容性配置网络是安装部署完成之后最容易被误用的一层。Packstack 默认使用 Open vSwitch 加 VXLAN租户网络通过 VXLAN 隧道封装理论上不受物理网络 VLAN 数量限制。但 VXLAN 的封装头是 50 字节默认虚拟网卡的 MTU 1500 在隧道里会出现分片。正确做法是把虚机网卡 MTU 统一改成 1450同时物理交换机端口启用 jumbo frame 支持。很多用户遇到虚机网络忽通忽断检查 MTU 是最先要看的点。# 在 network 节点 OpenStack 侧的配置 openstack network create --mtu 1450 --provider-network-type vxlan test-net openstack subnet create --network test-net --subnet-range 192.168.100.0/24 --dhcp test-subnetFlat 模式则用于外部网络直通将物理网卡直接映射到 br-ex 网桥。修改 /etc/neutron/plugins/ml2/openvswitch_agent.ini 里的 bridge_mappings 和 tunnel_type[ovs] bridge_mappings physnet1:br-ex tunnel_type vxlan [agent] tunnel_types vxlan enable_distributed_routing False参数说明bridge_mappings 左侧是物理网络名称右侧是 OVS 网桥名称这里的 physnet1 要与创建外部网络时指定的 physical_network 同名名称不一致会导致外部网络无法创建端口。tunnel_type 选择 vxlan 后租户网络才能使用 VXLAN 分段。enable_distributed_routing 默认关闭开启后 DVR 模式允许计算节点直接转发外部流量但需要额外配置 L3 agent 并且对控制平面的依赖反而变多建议先保持关闭跑通后再验证开启避免一开始排错范围变大。4.3 安装部署日志的定位与三条排查命令安装部署中排错第一步是看日志但 OpenStack 日志分散在多处容易找错方向。常用到的日志位置是 /var/log/keystone、/var/log/nova、/var/log/neutron 三个目录。按时间筛选错误是最有效的启动方式以 Neutron 为例grep -i ERROR\|Traceback /var/log/neutron/server.log | tail -50 journalctl -u openstack-nova-compute --since 10 minutes ago openstack-service statusopenstack-service status 是安装部署之后最高频使用的体检命令它会把宿主机上所有 OpenStack 相关服务进程逐一检查并输出启停状态。配合 systemctl list-units 可以快速定位哪个服务挂掉。以下是线上环境最常遇到的几类安装失败表现表现大概率原因优先检查方向Keystone 认证 401系统时间偏差超过 5 分钟chronyc tracking 查看时间源Nova 调度失败计算节点没有可用内存或元数据不匹配openstack hypervisor show 节点状态Neutron 端口创建失败bridge_mappings 名称不一致或网卡未加入网桥ovs-vsctl show 查网桥端口Cinder 卷无法附加存储节点 iscsi 服务未启动systemctl status iscsid注意排错时先看服务状态再看应用日志最后才动配置文件。很多人一看 500 错误就改配置结果把原本正常的参数改坏了。手上有 openstack-service status 的输出能节省一半的排查时间。5. 安装完成后的验证路径与一键体检命令安装部署完成不代表服务可用验证要分成基础设施、认证与安全、业务链路三层。先把 admin 环境变量加载进来然后按下面的顺序执行source /root/keystonerc_admin openstack endpoint list openstack service list openstack image list openstack network list openstack hypervisor listendpoint list 的输出能确认四个核心服务的 API 地址都是可解析的主机名hypervisor list 能看到计算节点状态。接着创建一张测试镜像和一台最小规格虚拟机验证从镜像到网络再到控制台的全链路wget http://download.cirros-cloud.net/0.6.1/cirros-0.6.1-x86_64-disk.img openstack image create --file cirros-0.6.1-x86_64-disk.img --disk-format qcow2 --container-format bare --public cirros openstack server create --flavor m1.tiny \ --image cirros --network test-net \ --key-name mykey cirros-test openstack server list如果 server list 里的实例 STATUS 从 BUILD 变成 ACTIVE并且 POWER STATE 是 Running说明 Nova 调度、镜像下载、网络端口创建全部成功。最后一步是验证访问路径通过安全组规则放行 SSH或直接在计算节点上 ping 实例的内网 IP。很多情况下实例状态是 ACTIVE 但网络不通问题都出在安全组默认规则上而不是安装部署环节。验证完成后收尾的做法是把 keystonerc_admin 文件备份到安全位置并修改默认密码。这里有一个值得记住的技巧OpenStack 在安装部署时生成的所有密码都记录在 answer file 里但脚本不会自动更新密码哈希。可以用以下命令快速确认实际生效的服务状态并把它写成一行别名方便以后反复体检alias oschecksource /root/keystonerc_admin openstack-service status openstack endpoint list oscheck把 oscheck 写入 /root/.bashrc后续巡检只需要敲一个命令就能拿到服务活体状态和最核心的 endpoint 信息运维接手时的第一手信息都在这里。本文还有配套的精品资源点击获取
