拓冰网站定制 
先说结论这篇东西适合两类人看。一类是刚接手公司“老旧小”机房、被领导安排搭一套内部虚拟化环境运维兄弟另一类是准备考云计算认证的学生。OpenStack 在圈里口碑两极分化有人觉得它重、慢、难维护有人觉得它灵活、可控、不吃“云厂商绑定”的亏。我的态度比较务实在 CentOS 7 还是主流系统的那些年OpenStack Train 基本是生产环境里被验证最多、坑最透明、网上资料也最全的一套组合。哪怕放到现在你手头只有几台普通 x86 服务器又不想花钱买商业虚拟化软件这个组合依然能打。我这次要复盘的不是理论是我从零开始部署一套 OpenStack Train 全流程的实操记录包括节点规划、组件配置、镜像制作、租户管理、虚拟机全生命周期维护还有我踩过的那些文档里不会明说的坑。整个过程你可以理解成在 CentOS 7 上用一堆开源组件拼出一个属于自己的“小阿里云”虽然规模不大但 IaaS 该有的东西一个不少。1. 项目背景与架构设计思路1.1 为什么是 CentOS 7 加 OpenStack Train先聊个经常被新人问的问题都什么年代了为什么还要用 CentOS 7 和 Train我的回答是架构稳定、踩坑成本低、生命周期匹配。CentOS 7 基于 RHEL 7内核版本 3.10本身不算新但胜在稳定。OpenStack 在 RHEL 7 系列上做过大量认证和优化尤其是 KVM/QEMU 的兼容性很多参数组合在 RHEL 7 上是被验证过的。Train 是最后一个官方完整支持 CentOS 7 的 OpenStack 版本这就有个天然优势你装的每个组件阿里云、腾讯云、华为云早期跑过的坑社区都有记录。网上搜“OpenStack Train 错误”基本能找到原题答案。还有一个非常现实的点CentOS 7 对硬件要求低。我用的三台物理机每台是 32GB 内存、8 核 CPU、1TB 机械盘放在今天已经算“电子垃圾”但跑 OpenStack Train 加十几个云主机依旧很流畅。如果你手头是 16GB 内存的机器做单节点 all-in-one 也一样能跑起来只是不能部署太大规格的云主机而已。再说说为什么不适合直接用更新的版本比如 Yoga、Wallaby。新版本组件更多、依赖更新CentOS 7 的基础库带不动强行装会频繁遇到 Python 版本不匹配、pip 安装包冲突的问题。Train 的依赖基本都是 CentOS 7 自带源里有的安装时很少需要手动编译对新手极度友好。1.2 整体架构与节点规划私有云部署不是把软件装上就完事节点规划直接决定后续能不能扩展、好不好排错。我这次用的是经典的三节点架构控制节点controller、计算节点compute1、网络节点network。如果机器少也可以把网络节点角色合并到控制节点小规模场景完全够用。先看我给每个节点分配的角色节点角色核心组件controller控制节点Keystone、Glance、Nova 控制面、Neutron 控制面、Horizon、MariaDB、RabbitMQ、Memcachedcompute1计算节点Nova-compute、KVM/libvirt、Neutron 的 Linux Bridge agentnetwork网络节点Neutron 的 DHCP agent、L3 agent、Metadata agent、外部网络网关网络规划上我给每个节点设计了三个网卡。管理网Management用于组件内部 API 通信数据网Data用于虚拟机流量外部网External用于浮动 IP 和出外网访问。这里有个设计细节我想特别强调管理网和数据网即便在测试环境也建议分开。原因是 Neutron 的 Open vSwitch 或 Linux Bridge 在数据网上会创建大量虚拟网卡如果混在同一网段很容易把管理流量挤爆排错时你会被各种间歇性断连整疯。IP 规划大概是这样controller 管理网192.168.10.11数据网 10.10.20.11外部网 192.168.30.11compute1 管理网192.168.10.12数据网 10.10.20.12network 管理网192.168.10.13数据网 10.10.20.13外部网 192.168.30.13主机名我也习惯按规范来controller、compute1、network不搞花里胡哨。后续配置文件里主机名写错排查起来要命。1.3 网络方案与虚拟化选型Neutron 网络是 OpenStack 里最复杂的部分也是新手最容易栽的地方。Train 版本主流有两种选择使用 Open vSwitchOVS或使用 Linux Bridge。我这次用的是 Linux Bridge原因很简单配置简单、排查直观、性能在小规模场景下没差多少。底层虚拟化用 KVM 加 libvirt。因为所有计算节点 CPU 型号一致我在 nova.conf 里直接设置了 CPU 模式为 host-passthrough这样创建的云主机能看到宿主机的完整 CPU 指令集跑机器学习或编译任务时性能损失很小。如果你的是异构 CPU 的机器混用建议改成默认的 qemu64不然 nova 调度时可能碰见“CPU 特性不匹配”导致迁移失败。外部网络的网关我放在了 network 节点上通过 Linux Bridge 把物理外部网卡桥接过去浮动 IP 池直接用机房给的公网网段中的一段。这种做法和大多数企业生产一致虚拟机和外部世界通信时流量会从 network 节点走 NAT 或路由不需要在物理交换机上做额外配置。2. 部署前环境准备与基础配置2.1 虚拟机创建与系统初始化虽然生产环境推荐直接装裸机但我这次为了演示和回滚方便是用 VMware vSphere 先创建三台 CentOS 7.9 虚拟机。如果你手头没有 vSphere也可以用 VirtualBox 或 KVM 自己套娃注意开启 CPU 的虚拟化嵌套VT-x/AMD-V就行。系统安装时我选择的是 CentOS 7.9 Minimal ISO安装选项里只勾选了基础开发工具和网络工具。图形界面完全不需要OpenStack 组件跑在纯命令行的环境下更稳省内存也省心。磁盘分区上我建议使用 LVM这是后期扩容的关键。我当时的分配方案是/boot1GBswap8GB/剩余全部空间使用 LVM 逻辑卷安装完成后的第一件事是设置静态 IP、主机名和 hostname 解析。CentOS 7 默认用 NetworkManager但 OpenStack 各组件对网络配置文件很敏感我直接禁用了 NetworkManager改用 network 服务管理网卡。具体操作是把/etc/sysconfig/network-scripts/ifcfg-eth0里的NM_CONTROLLEDno加上再设置BOOTPROTOstatic。然后修改/etc/hosts加入三台机器的解析192.168.10.11 controller 192.168.10.12 compute1 192.168.10.13 network这一步不能省。OpenStack 组件之间通信时用主机名互相找如果解析不了你会在日志里看到大量 “Connection refused” 或 “Name or service not known” 的错误。2.2 YUM 源配置与 OpenStack 仓库的坑CentOS 7 默认的官方源在国内访问要么慢要么老是连不上我直接换成阿里云镜像源。操作不复杂备份原 repo 文件下载阿里云的 CentOS-7.repo 和 epel-7.repo。这里有个容易踩的坑OpenStack Train 依赖的不少包在 EPEL 源里比如 python2-PyMySQL、python2-qpid-proton 这些所以 EPEL 必须配好否则后面执行 yum install 时一堆依赖报错光排查就够你喝一壶。OpenStack 仓库的安装方法是yum install -y centos-release-openstack-train这个包会帮你把 OpenStack 的 yum 源和相关 GPG 密钥配置好。装完后注意yum repolist检查一下确认 OpenStack Train 仓库已经启用。我遇到过装完这个包后仓库列表里没有自动启用的情况需要手动在/etc/yum.repos.d/CentOS-OpenStack-train.repo里把 enabled 改成 1。配好源后执行一次全量升级把系统内所有软件包更新到当前仓库最新版yum update -y升级过程比较久建议放到最后部署前统一做免得中途改动太大把环境搞乱。2.3 时间同步、SELinux 与防火墙的取舍基础准备里我强烈建议把时间同步先做掉。OpenStack 内部对时间非常敏感Keystone 的 token 有有效期Nova 和 Neutron 组件之间通信如果时间偏差超过一定范围就会出现 token 验证失败、虚拟机状态异常这类看似莫名其妙的问题。我先在三台机上装了 chronycontroller 充当 NTP 服务端其他节点向它同步。配置大概是这样# controller 上 /etc/chrony.conf allow 192.168.10.0/24 local stratum 10其余节点配置server controller iburst。装完后执行systemctl enable chronyd和systemctl start chronyd然后用chronyc sources -v确认同步状态。SELinux 我直接设为 permissive而不是 disabled。原因是 OpenStack 的很多组件在 CentOS 7 上还没有完全适配 SELinux 的策略disabled 虽然能跑但后期如果要做安全加固再启用会非常麻烦。permissive 模式既能让你看到哪些操作被 SELinux 拦截日志里会有记录又不会真正阻断服务运行。防火墙方面因为我用的是一台独立机器做测试直接把 firewalld 停了。生产环境建议按官方文档放行对应端口管理面端口 8774Nova API、5000Keystone、9696Neutron、9292Glance、6080VNC这些要开放同时数据网之间的流量要完全放行否则虚拟机之间的通信会出问题。3. OpenStack 核心组件部署与配置实践3.1 部署方式选择Packstack 还是手动逐组件部署OpenStack 部署有两种路线用 Packstack 自动化一键部署或手动逐一安装配置每个组件。Packstack 适合快速做验证环境一条命令就能把整个 OpenStack 拉起来yum install -y openstack-packstack packstack --allinone但 Packstack 的问题也很明显它生成配置非常“黑盒”出了错很难定位而且默认参数不一定适合你的物理环境。我这次选择手动部署因为既然是做“全流程实践”了解每个组件的工作原理比图省事更重要。手动部署虽然慢但每装一个组件你都能清楚它依赖什么、数据流向哪里、出错了去哪看日志。手动部署的大致顺序是数据库MariaDB→ 消息队列RabbitMQ→ 缓存Memcached→ Keystone → Glance → Nova → Neutron → Horizon。这个顺序不是随便排的底层服务不先起好上层组件启动时大概率报错。3.2 Keystone 身份认证服务搭建Keystone 是 OpenStack 的“门卫”所有请求进来先过它这一关。它管理的核心概念有Project项目/租户、User用户、Role角色、Service服务、Endpoint端点。安装 Keystone 前我需要先在 MariaDB 里建好对应的数据库和账号CREATE DATABASE keystone; GRANT ALL PRIVILEGES ON keystone.* TO keystonelocalhost IDENTIFIED BY keystone_pass; GRANT ALL PRIVILEGES ON keystone.* TO keystone% IDENTIFIED BY keystone_pass;安装包yum install -y openstack-keystone httpd python2-mod_wsgiTrain 版本里 Keystone 的配置文件和旧版相比已经不依赖 paste.ini 太多主要改/etc/keystone/keystone.conf。核心配置就是数据库连接、token 提供方式和缓存后端。我在生产环境中用的是 Fernet token配置如下[database] connection mysqlpymysql://keystone:keystone_passcontroller/keystone [token] provider fernet [cache] backend dogpile.cache.memcached memcached_servers controller:11211然后初始化 Fernet key、同步数据库、创建 admin 项目、admin 用户、admin 角色和服务端点。这里有个记忆技巧每次创建一个新服务都逃不过三步——建数据库、建服务实体service create、建三个端点public、internal、admin。Keystone 做完后我顺手导入了几个环境变量脚本方便之后所有命令行操作都带上身份认证信息。脚本内容就是大家常见的 admin-openrcexport OS_PROJECT_DOMAIN_NAMEDefault export OS_USER_DOMAIN_NAMEDefault export OS_PROJECT_NAMEadmin export OS_USERNAMEadmin export OS_PASSWORDadmin_pass export OS_AUTH_URLhttp://controller:5000/v3 export OS_IDENTITY_API_VERSION3 export OS_IMAGE_API_VERSION2之后敲openstack token issue能拿到 token说明 Keystone 工作正常。3.3 Glance 镜像服务搭建Glance 负责管理镜像。虚拟机要能创建控制节点上必须先有可用的镜像。装 Glance 的步骤和 Keystone 大同小异建库、装包、改配置、注册服务。安装包yum install -y openstack-glance配置主要在/etc/glance/glance-api.conf重点是四块内容数据库连接、存储后端、认证信息、映像格式。存储后端我用的是本地文件系统file简单可靠后续想换成 Ceph 也容易只要改一下配置即可。我准备了一个测试镜像直接下载官方 cirros 小镜像wget http://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img openstack image create cirros --file cirros-0.4.0-x86_64-disk.img --disk-format qcow2 --container-format bare --public这里有个细节容易忽略--disk-format和--container-format必须写否则 Glance 报格式错误。--public表示公开给所有项目使用--protected可以防止镜像被误删。上传完成后用openstack image list查看状态显示 active 就是正常。如果一直卡在 saving多半是 keystone 认证配置有问题或者 glances 到数据库的连接断了去/var/log/glance/glance-api.log里能看到具体原因。3.4 Nova 计算服务的完整部署Nova 是 OpenStack 的核心计算服务组件多、角色多也是排错最耗时的部分。控制节点上有 nova-api、nova-scheduler、nova-conductor、nova-novncproxy计算节点上有 nova-compute。每台机器都要装对应的包。控制节点上执行yum install -y openstack-nova-api openstack-nova-scheduler openstack-nova-conductor openstack-nova-novncproxy openstack-nova-placement-api计算节点上执行yum install -y openstack-nova-compute先说计算节点上的/etc/nova/nova.conf。关键配置有几个数据库连接、RabbitMQ 连接、认证配置、VNC 配置和宿主机虚拟化配置。重点提示 VNC 配置因为这是你之后打开虚拟机控制台的通道[vnc] enabled True novncproxy_base_url http://controller:6080/vnc_auto.html server_listen 0.0.0.0 server_proxyclient_address 192.168.10.12server_proxyclient_address坑很多必须写计算节点的管理网 IP不能写 controller。否则你在控制台上打开 VNC会连接失败或一直转圈。接着是 CPU 模式的配置[libvirt] virt_type kvm cpu_mode host-passthrough确定宿主机支持 KVM用egrep -c (vmx|svm) /proc/cpuinfo检查返回大于 0 即可。如果服务器没有开嵌套虚拟化virt_type 会被默认降级为 qemu性能差非常多。控制节点上的配置在计算节点基础上增加了 scheduler、conductor 和 rabbitmq 相关设置配置完成后统一同步数据库su -s /bin/sh -c nova-manage api_db sync nova su -s /bin/sh -c nova-manage cell_v2 map_cell0 nova su -s /bin/sh -c nova-manage cell_v2 create_cell --name cell1 --transport-url rabbit://openstack:openstackcontroller:5672 nova su -s /bin/sh -c nova-manage db sync nova很多新手挂在这一步数据库同步时报 “No such cell” 或 “DBError”。大多数情况是 cell 创建顺序不对或者 rabbitmq 账号密码写错。建议按上面顺序一步一步来每执行完一条命令确认输出没有报错再继续。Nova 全部启动后执行openstack compute service list应该能看到所有服务都是 up 状态。如果某个服务变成 down大概率是 RabbitMQ 连接问题去对应节点的日志里搜 “Connection refused” 看是连的哪个 IP。3.5 Neutron 网络服务的部署与配置Neutron 是 OpenStack 网络服务也是配置最繁琐、最考验耐心的部分。它的组件包括控制节点上的 neutron-server网络节点上的 DHCP agent、L3 agent、Metadata agent以及计算节点上的 Linux Bridge agent。控制节点装包yum install -y openstack-neutron openstack-neutron-linuxbridge openstack-neutron-ml2网络节点装包yum install -y openstack-neutron openstack-neutron-linuxbridge openstack-neutron-l3 openstack-neutron-dhcp openstack-neutron-metadata-agent计算节点只需要安装 linuxbridge agent。Neutron 的核心配置在/etc/neutron/neutron.conf需要配置数据库、RabbitMQ、认证以及指定使用 ML2 插件。ML2 的配置文件/etc/neutron/plugins/ml2/ml2_conf.ini里我选了 VXLAN 作为租户网络的类型驱动[ml2] type_drivers flat,vlan,vxlan tenant_network_types vxlan mechanism_drivers linuxbridge,l2population [ml2_type_vxlan] vni_ranges 1:1000用 VXLAN 的好处是虚拟机网络不依赖物理交换机的 VLAN 配置overlay 网络跑在 UDP 上适合现有网络不好改动的场景。L2 population 是为了减少广播流量多计算节点时推荐开启。外部网络配置在 Linux Bridge agent 的/etc/neutron/plugins/ml2/linuxbridge_agent.ini里。关键是要给外部网络指定物理网卡映射关系[linux_bridge] physical_interface_mappings physnet1:eth2 [vxlan] enable_vxlan True local_ip 10.10.20.13 l2_population True这里的physnet1:eth2意思是逻辑网络 physnet1 对应物理网卡 eth2也就是外部网卡。如果名字对不上创建外部网络时选了 physnet1 但实际要桥接的网卡不是 eth2虚拟机拿到浮动 IP 也出不了网。网络节点上的 DHCP agent 和 L3 agent 也要配置L3 agent 负责路由和 NATDHCP agent 负责给虚拟机分配 IP。配置完成后在控制节点创建网络资源创建外部网络openstack network create external --external --provider-physical-network physnet1 --provider-network-type flat创建路由器openstack router create router1设置外部网关openstack router set router1 --external-gateway external创建租户网络和子网并把子网接上路由器这一步做完才算是真正有了一个可以通外网的云网络环境。3.6 Horizon 仪表板部署Horizon 是一个 Web 管理界面虽然日常运维我习惯用命令行但给领导和同事演示、或者让不懂命令的同事自助开虚拟机Horizon 是刚需。安装很简单yum install -y openstack-horizon配置文件在/etc/openstack-dashboard/local_settings。重点修改的是ALLOWED_HOSTS和OPENSTACK_HOST把ALLOWED_HOSTS改成[*]方便测试生产环境必须写具体的域名或 IP。然后修改/etc/httpd/conf.d/openstack-dashboard.conf确认 WSGI 配置没问题。重启 httpd 后浏览器输入http://controller/dashboard就能看到登录页。用 admin 账号登录首页右上角能切换项目左侧菜单可以管理实例、镜像、网络、路由、卷等资源。我个人建议镜像上传、网络创建这些操作用命令行更清晰但实例创建、VNC 登录这些在界面上点一点就行效率高很多。4. 私有云运维实践与日常管理4.1 命令行管理的高频操作清单搭建只是开始真正考验功底的是运维。我日常维护这套私有云90% 的时间都在用openstack命令。整理几个高频操作查看整体资源使用情况openstack hypervisor list openstack hypervisor show compute1 openstack host list查看项目配额和调整配额openstack quota show admin openstack quota set --instances 20 --vcpus 40 --ram 65536 --volumes 10 --gigabytes 200 admin查看计费或资源用量其实 OpenStack 没有内置计费但可以用 ceilometer 或 gnocchi 做监控采集openstack usage list这个命令能看到每个项目的 CPU、内存、磁盘使用时长做成本核算和资源回收判断很有用。管理云主机生命周期openstack server list openstack server show vm1 openstack server stop vm1 openstack server start vm1 openstack server reboot vm1 openstack server delete vm1创建云主机的完整命令是openstack server create --flavor m1.small --image cirros --network private --security-group default vm1这里有个经验生产环境创建主机时一定加--wait参数它会阻塞等待实例状态变成 ACTIVE 再返回方便你第一时间知道是否创建成功openstack server create --wait --flavor m1.small --image cirros --network private vm14.2 镜像管理与云主机实例调度镜像管理不只是上传下载那么简单。生产环境里最常用的镜像是 CentOS、Ubuntu 和 Windows。CentOS 镜像可以从官方 cloud 镜像仓库下载装完自带 cloud-init可以自动注入密码和 SSH 密钥。制作自定义镜像是我运维时的重要操作。流程是先创建一个基础云主机手动安装 JDK、Python、监控 agent 这些业务依赖然后清理日志、清空主机 SSH 指纹、关闭机器最后用openstack image create从卷快照做镜像。openstack server stop template-centos7 openstack image create --volume template-vol centos7-jdk8-template --public这样做出来的镜像下次创建云主机时直接选它业务从启动到可用只需要 1 分钟省去了每次手工装环境的痛苦。实例调度也有讲究。OpenStack 的 Nova scheduler 默认是 “filter scheduler”它会根据 CPU、内存、磁盘的可用量过滤掉不满足条件的计算节点再按权重打分排序。如果一台机器上了很多虚拟机导致负载高你可以手工把某个实例迁移到其他节点openstack server migrate vm1 --live-migration --block-migration openstack server resize vm1 --flavor m1.large --confirm冷迁移要先关机热迁移live migration可以做到不中断业务。但热迁移对 CPU 型号一致性要求高这也是我之前强调所有节点统一 CPU 模式的原因。4.3 项目、用户与资源配额管理私有云不能只有一个 admin得给不同部门建独立项目。比如给测试部建 test-project给研发部建 dev-project这样资源隔离、互不干扰费用如果接入计费系统也容易分摊。创建项目openstack project create --domain default --description Test Project test-project创建用户并绑定角色openstack user create --domain default --password test123 testuser openstack role add --project test-project --user testuser member这里角色分配我一般用 member 而不是 adminmember 权限足够用户在项目内创建虚拟机、管理网络但不能操作全局配置。配额管理是资源管控的关键。如果不设配额某个项目可以把整个私有云资源吃光。我的习惯是给每个新项目按部门人数和用途估算先给一个保守值后续不够再上调openstack quota set --instances 20 --vcpus 40 --ram 65536 --volumes 10 --gigabytes 200 test-project用户密码忘了用openstack user set --password重置即可。用户离职了先删掉 token 再禁用账号openstack token revoke token-id openstack user set --disable username4.4 日志体系与监控告警OpenStack 组件太多每个组件都有自己的日志文件一旦出问题如果没有日志收集机制你只能在各台机器之间来回翻文件。我的做法是部署一套简单的 ELK 或 Loki 日志集中平台把所有节点的/var/log/keystone、/var/log/nova、/var/log/neutron、/var/log/glance日志收集到一起统一搜索。如果你不想上大而全的 ELK也可以用最基本的 rsyslog 把日志转发到一台集中日志服务器# 在每台节点上配置 *.* logserver:514监控方面最轻量的是用ceilometer配合gnocchi做资源使用率采集UI 上用 Grafana 展示。不想折腾的话直接在每台机器上装 Prometheus node_exporter再配合openstack-exporter抓取 OpenStack 的 API 指标维护成本低很多。告警规则我通常会设置这么几个CPU 使用率超 80%、内存剩余低于 10%、磁盘使用率超 85%、虚拟机关机状态超过 10 分钟、OpenStack 任意 API 服务端口探活失败。这些告警规则看着简单但真出了问题能救命。有一次凌晨某个计算节点磁盘写满我还没接到业务反馈Prometheus 的告警已经发到钉钉了我远程过去清理临时日志业务几乎无感知。5. 常见故障排查与经验教训5.1 云主机无法创建或停留在 BUILD 状态这是新手遇到最多的故障。排错流程我一般是这样先看控制节点的 nova-api 日志确认 API 请求有没有进来再看 nova-scheduler 日志确认调度有没有把请求发到计算节点最后看计算节点的 nova-compute 日志确认是不是底层创建虚拟机失败。一步到位的方法是同时开三个终端实时 tail 日志tail -f /var/log/nova/nova-api.log tail -f /var/log/nova/nova-scheduler.log tail -f /var/log/nova/nova-compute.log然后重新执行创建命令看日志输出停在哪一步。常见的报错有这么几个No valid host was found调度器找不到满足资源条件的物理机查计算节点的可用资源或者看 CPU/内存配额是否用满。libvirtError: internal error: process exited while connecting to monitor计算节点的 libvirt 或 QEMU 出问题重启一下 libvirtd 服务试试。NeutronError: Failed to create port创建端口时网络没有就绪去 neutron-server 日志看具体原因多半是 DHCP agent 或 Linux Bridge agent 没起来。BuildAbortException: Instance is in ERROR state创建过程中某一步异常虚拟机被置为 ERROR需要先删除这个实例再排查原因。5.2 云主机无法获得 IP 或网络不通虚拟机起来但ip addr看不到 IP或者能看到 IP 却 ping 不通外网这类问题十有八九出在 Neutron。先排查 DHCP 是否正常。在能访问租户网络的物理机上抓包tcpdump -i brqbridge-id udp port 67如果有 DHCP 请求但没人应答去 network 节点看 neutron-dhcp-agent 日志确认 DHCP 命名空间是否创建成功ip netns list如果 DNS 解析有问题检查子网的 DNS 设置openstack subnet set --dns-nameserver 223.5.5.5 --dns-nameserver 114.114.114.114 private-subnet虚拟机通了内网但不能访问外网最常见原因是安全组没放行或浮动 IP 没绑定。安全组这块我吃过亏默认安全组只放行了 ICMP 和 SSH如果云主机里跑的是 Web 服务外部访问 80 端口会被挡住。解决办法openstack security group rule create --protocol tcp --dst-port 80:80 default openstack security group rule create --protocol tcp --dst-port 443:443 default浮动 IP 的绑定命令openstack floating ip create external openstack server add floating ip vm1 floating-ip这里再说一个经常被忽略的细节浮动 IP 绑定后虚拟机内部还需要配置好默认路由。cirros 镜像默认做好了但自己用 cloud image 装系统时如果没有配置好 metadata 服务虚拟机可能拿不到网关和 DNS 信息网络自然就不通。5.3 磁盘空间不足与 LVM 扩容私有云跑久了最大的敌人不是 OpenStack 本身而是磁盘空间。控制节点的日志、数据库、镜像文件每时每刻都在增长一不小心就会把根分区撑爆。我遇到过控制节点的/var/lib/mysql目录占满导致数据库崩溃、OpenStack 所有 API 接口全部 500 的严重事故。排查思路是df -h du -h --max-depth1 /var/lib/mysql如果是数据库太大考虑清理旧数据或给 MySQL 的 datadir 迁移到大容量磁盘。如果只是日志膨胀配置 logrotate 定期清理# /etc/logrotate.d/openstack /var/log/nova/*.log /var/log/neutron/*.log /var/log/keystone/*.log { daily rotate 14 compress missingok notifempty copytruncate }LVM 扩容的思路也要掌握。假设根分区所在的逻辑卷是/dev/mapper/centos-root新加了一块物理磁盘/dev/sdb扩容步骤是pvcreate /dev/sdb vgextend centos /dev/sdb lvextend -l 100%FREE /dev/mapper/centos-root xfs_growfs /注意 CentOS 7 默认文件系统是 xfs扩容命令用xfs_growfs如果用 resize2fs 会报错。如果是 ext4 文件系统才用 resize2fs。5.4 数据库与消息队列的常见故障MariaDB 和 RabbitMQ 是 OpenStack 的底层依赖它们出问题整个云平台都会瘫。我的体验是大多数连接类故障都是因为密码变化、主机名解析不了、端口被防火墙拦截这三个原因。RabbitMQ 最常见的故障是集群节点掉线或连接数耗尽。状态检查rabbitmqctl cluster_status rabbitmqctl list_connections集群节点之间如果网络抖动导致分区partition消息队列会出现脑裂OpenStack 各组件的状态会变得非常奇怪。预防手段是设置合理的分区处理策略rabbitmqctl set_policy ha-all ^(?!amq\.).* {ha-mode:all,ha-sync-mode:automatic}MariaDB 的问题主要集中在连接数超限和主从复制中断。查看连接数SHOW STATUS LIKE Threads_connected; SHOW VARIABLES LIKE max_connections;如果连接数总是打满在/etc/my.cnf.d/openstack.cnf里调大max_connections并启用慢查询日志找出哪些 SQL 拖慢了数据库。主从复制监控用SHOW SLAVE STATUS\G看到Slave_IO_Running: Yes和Slave_SQL_Running: Yes才是正常。如果 SQL 线程停了多半是某个 SQL 执行出错需要跳过错误或手动修复数据。我以前写过一段脚本定时把复制异常信息发到钉钉告警群这样不用每天盯服务器看。5.5 实用排错技巧与避坑指南最后整理几条我后来总结出来的排错经验每一条都是从事故里换来的看日志永远比猜问题靠谱。OpenStack 每个组件的日志文件路径基本固定出错先tail -n 100对应日志比漫无目的搜博客高效十倍。日志路径忘了就查/etc/openstack-debug.log关联的配置。改配置前先备份原文件。我习惯把每个配置文件的原始版本复制一份存到/root/backup目录命名加上日期。上线前如果改了配置文件先用openstack-config工具校验openstack-config --validate /etc/nova/nova.conf权限问题别忽略。修改配置文件后如果服务起不来检查文件属主和权限。很多服务要求配置文件属主是对应用户比如 nova.conf 属于 nova:nova权限通常是 640。曾有人把 keystone.conf 的属主改成 root 导致 httpd 启动失败。升级或补丁前先拍快照。在虚拟化环境里给虚拟机做快照的成本很低升级系统补丁前最好打一个快照出了问题一键回滚。定时巡检不能省。我维护这套私有云后写了一个 shell 脚本每周自动跑一遍检查节点离线状态、检查磁盘空间、检查 RabbitMQ 连接数、检查关键 API 端口生成报告发邮件。虽然 OpenStack 本身有健康检查命令openstack-status但只覆盖系统层业务层的巡检还是得靠自定义脚本。写在最后如果你问我现在还推荐不推荐搭 OpenStack我的回答是看场景。如果只是想跑几个虚拟机KVM 直接裸管理更轻量如果想体验最真实的 IaaS 平台工作原理、或者企业内部有资源隔离和多租户需求OpenStack 仍然是几乎不可替代的开源选择。我个人在反复搭建和运维这套 CentOS 7 OpenStack Train 环境的过程中最大的体会是它不是一个装完就完事的软件而是一套需要长期运维、持续调优的系统。你要花时间理解各组件之间的依赖关系善于从日志中挖掘问题更要建立自己的监控和巡检机制。每踩过一个坑你对这套系统的理解就更深一层。最后再分享一个小技巧任何配置文件修改后务必记住用对应组件的命令做校验比如 nova 用nova-manage --versionkeystone 用keystone-manage fernet_rotateneutron 用neutron-db-manage current。虽然这些命令不直接改配置但能在启动服务前先暴露出配置错误省得你反复重启服务才知道问题在哪。这套方法我用到现在一直很管用。 CentOS 7上OpenStack Train私有云部署与运维实战
先说结论这篇东西适合两类人看。一类是刚接手公司“老旧小”机房、被领导安排搭一套内部虚拟化环境运维兄弟另一类是准备考云计算认证的学生。OpenStack 在圈里口碑两极分化有人觉得它重、慢、难维护有人觉得它灵活、可控、不吃“云厂商绑定”的亏。我的态度比较务实在 CentOS 7 还是主流系统的那些年OpenStack Train 基本是生产环境里被验证最多、坑最透明、网上资料也最全的一套组合。哪怕放到现在你手头只有几台普通 x86 服务器又不想花钱买商业虚拟化软件这个组合依然能打。我这次要复盘的不是理论是我从零开始部署一套 OpenStack Train 全流程的实操记录包括节点规划、组件配置、镜像制作、租户管理、虚拟机全生命周期维护还有我踩过的那些文档里不会明说的坑。整个过程你可以理解成在 CentOS 7 上用一堆开源组件拼出一个属于自己的“小阿里云”虽然规模不大但 IaaS 该有的东西一个不少。1. 项目背景与架构设计思路1.1 为什么是 CentOS 7 加 OpenStack Train先聊个经常被新人问的问题都什么年代了为什么还要用 CentOS 7 和 Train我的回答是架构稳定、踩坑成本低、生命周期匹配。CentOS 7 基于 RHEL 7内核版本 3.10本身不算新但胜在稳定。OpenStack 在 RHEL 7 系列上做过大量认证和优化尤其是 KVM/QEMU 的兼容性很多参数组合在 RHEL 7 上是被验证过的。Train 是最后一个官方完整支持 CentOS 7 的 OpenStack 版本这就有个天然优势你装的每个组件阿里云、腾讯云、华为云早期跑过的坑社区都有记录。网上搜“OpenStack Train 错误”基本能找到原题答案。还有一个非常现实的点CentOS 7 对硬件要求低。我用的三台物理机每台是 32GB 内存、8 核 CPU、1TB 机械盘放在今天已经算“电子垃圾”但跑 OpenStack Train 加十几个云主机依旧很流畅。如果你手头是 16GB 内存的机器做单节点 all-in-one 也一样能跑起来只是不能部署太大规格的云主机而已。再说说为什么不适合直接用更新的版本比如 Yoga、Wallaby。新版本组件更多、依赖更新CentOS 7 的基础库带不动强行装会频繁遇到 Python 版本不匹配、pip 安装包冲突的问题。Train 的依赖基本都是 CentOS 7 自带源里有的安装时很少需要手动编译对新手极度友好。1.2 整体架构与节点规划私有云部署不是把软件装上就完事节点规划直接决定后续能不能扩展、好不好排错。我这次用的是经典的三节点架构控制节点controller、计算节点compute1、网络节点network。如果机器少也可以把网络节点角色合并到控制节点小规模场景完全够用。先看我给每个节点分配的角色节点角色核心组件controller控制节点Keystone、Glance、Nova 控制面、Neutron 控制面、Horizon、MariaDB、RabbitMQ、Memcachedcompute1计算节点Nova-compute、KVM/libvirt、Neutron 的 Linux Bridge agentnetwork网络节点Neutron 的 DHCP agent、L3 agent、Metadata agent、外部网络网关网络规划上我给每个节点设计了三个网卡。管理网Management用于组件内部 API 通信数据网Data用于虚拟机流量外部网External用于浮动 IP 和出外网访问。这里有个设计细节我想特别强调管理网和数据网即便在测试环境也建议分开。原因是 Neutron 的 Open vSwitch 或 Linux Bridge 在数据网上会创建大量虚拟网卡如果混在同一网段很容易把管理流量挤爆排错时你会被各种间歇性断连整疯。IP 规划大概是这样controller 管理网192.168.10.11数据网 10.10.20.11外部网 192.168.30.11compute1 管理网192.168.10.12数据网 10.10.20.12network 管理网192.168.10.13数据网 10.10.20.13外部网 192.168.30.13主机名我也习惯按规范来controller、compute1、network不搞花里胡哨。后续配置文件里主机名写错排查起来要命。1.3 网络方案与虚拟化选型Neutron 网络是 OpenStack 里最复杂的部分也是新手最容易栽的地方。Train 版本主流有两种选择使用 Open vSwitchOVS或使用 Linux Bridge。我这次用的是 Linux Bridge原因很简单配置简单、排查直观、性能在小规模场景下没差多少。底层虚拟化用 KVM 加 libvirt。因为所有计算节点 CPU 型号一致我在 nova.conf 里直接设置了 CPU 模式为 host-passthrough这样创建的云主机能看到宿主机的完整 CPU 指令集跑机器学习或编译任务时性能损失很小。如果你的是异构 CPU 的机器混用建议改成默认的 qemu64不然 nova 调度时可能碰见“CPU 特性不匹配”导致迁移失败。外部网络的网关我放在了 network 节点上通过 Linux Bridge 把物理外部网卡桥接过去浮动 IP 池直接用机房给的公网网段中的一段。这种做法和大多数企业生产一致虚拟机和外部世界通信时流量会从 network 节点走 NAT 或路由不需要在物理交换机上做额外配置。2. 部署前环境准备与基础配置2.1 虚拟机创建与系统初始化虽然生产环境推荐直接装裸机但我这次为了演示和回滚方便是用 VMware vSphere 先创建三台 CentOS 7.9 虚拟机。如果你手头没有 vSphere也可以用 VirtualBox 或 KVM 自己套娃注意开启 CPU 的虚拟化嵌套VT-x/AMD-V就行。系统安装时我选择的是 CentOS 7.9 Minimal ISO安装选项里只勾选了基础开发工具和网络工具。图形界面完全不需要OpenStack 组件跑在纯命令行的环境下更稳省内存也省心。磁盘分区上我建议使用 LVM这是后期扩容的关键。我当时的分配方案是/boot1GBswap8GB/剩余全部空间使用 LVM 逻辑卷安装完成后的第一件事是设置静态 IP、主机名和 hostname 解析。CentOS 7 默认用 NetworkManager但 OpenStack 各组件对网络配置文件很敏感我直接禁用了 NetworkManager改用 network 服务管理网卡。具体操作是把/etc/sysconfig/network-scripts/ifcfg-eth0里的NM_CONTROLLEDno加上再设置BOOTPROTOstatic。然后修改/etc/hosts加入三台机器的解析192.168.10.11 controller 192.168.10.12 compute1 192.168.10.13 network这一步不能省。OpenStack 组件之间通信时用主机名互相找如果解析不了你会在日志里看到大量 “Connection refused” 或 “Name or service not known” 的错误。2.2 YUM 源配置与 OpenStack 仓库的坑CentOS 7 默认的官方源在国内访问要么慢要么老是连不上我直接换成阿里云镜像源。操作不复杂备份原 repo 文件下载阿里云的 CentOS-7.repo 和 epel-7.repo。这里有个容易踩的坑OpenStack Train 依赖的不少包在 EPEL 源里比如 python2-PyMySQL、python2-qpid-proton 这些所以 EPEL 必须配好否则后面执行 yum install 时一堆依赖报错光排查就够你喝一壶。OpenStack 仓库的安装方法是yum install -y centos-release-openstack-train这个包会帮你把 OpenStack 的 yum 源和相关 GPG 密钥配置好。装完后注意yum repolist检查一下确认 OpenStack Train 仓库已经启用。我遇到过装完这个包后仓库列表里没有自动启用的情况需要手动在/etc/yum.repos.d/CentOS-OpenStack-train.repo里把 enabled 改成 1。配好源后执行一次全量升级把系统内所有软件包更新到当前仓库最新版yum update -y升级过程比较久建议放到最后部署前统一做免得中途改动太大把环境搞乱。2.3 时间同步、SELinux 与防火墙的取舍基础准备里我强烈建议把时间同步先做掉。OpenStack 内部对时间非常敏感Keystone 的 token 有有效期Nova 和 Neutron 组件之间通信如果时间偏差超过一定范围就会出现 token 验证失败、虚拟机状态异常这类看似莫名其妙的问题。我先在三台机上装了 chronycontroller 充当 NTP 服务端其他节点向它同步。配置大概是这样# controller 上 /etc/chrony.conf allow 192.168.10.0/24 local stratum 10其余节点配置server controller iburst。装完后执行systemctl enable chronyd和systemctl start chronyd然后用chronyc sources -v确认同步状态。SELinux 我直接设为 permissive而不是 disabled。原因是 OpenStack 的很多组件在 CentOS 7 上还没有完全适配 SELinux 的策略disabled 虽然能跑但后期如果要做安全加固再启用会非常麻烦。permissive 模式既能让你看到哪些操作被 SELinux 拦截日志里会有记录又不会真正阻断服务运行。防火墙方面因为我用的是一台独立机器做测试直接把 firewalld 停了。生产环境建议按官方文档放行对应端口管理面端口 8774Nova API、5000Keystone、9696Neutron、9292Glance、6080VNC这些要开放同时数据网之间的流量要完全放行否则虚拟机之间的通信会出问题。3. OpenStack 核心组件部署与配置实践3.1 部署方式选择Packstack 还是手动逐组件部署OpenStack 部署有两种路线用 Packstack 自动化一键部署或手动逐一安装配置每个组件。Packstack 适合快速做验证环境一条命令就能把整个 OpenStack 拉起来yum install -y openstack-packstack packstack --allinone但 Packstack 的问题也很明显它生成配置非常“黑盒”出了错很难定位而且默认参数不一定适合你的物理环境。我这次选择手动部署因为既然是做“全流程实践”了解每个组件的工作原理比图省事更重要。手动部署虽然慢但每装一个组件你都能清楚它依赖什么、数据流向哪里、出错了去哪看日志。手动部署的大致顺序是数据库MariaDB→ 消息队列RabbitMQ→ 缓存Memcached→ Keystone → Glance → Nova → Neutron → Horizon。这个顺序不是随便排的底层服务不先起好上层组件启动时大概率报错。3.2 Keystone 身份认证服务搭建Keystone 是 OpenStack 的“门卫”所有请求进来先过它这一关。它管理的核心概念有Project项目/租户、User用户、Role角色、Service服务、Endpoint端点。安装 Keystone 前我需要先在 MariaDB 里建好对应的数据库和账号CREATE DATABASE keystone; GRANT ALL PRIVILEGES ON keystone.* TO keystonelocalhost IDENTIFIED BY keystone_pass; GRANT ALL PRIVILEGES ON keystone.* TO keystone% IDENTIFIED BY keystone_pass;安装包yum install -y openstack-keystone httpd python2-mod_wsgiTrain 版本里 Keystone 的配置文件和旧版相比已经不依赖 paste.ini 太多主要改/etc/keystone/keystone.conf。核心配置就是数据库连接、token 提供方式和缓存后端。我在生产环境中用的是 Fernet token配置如下[database] connection mysqlpymysql://keystone:keystone_passcontroller/keystone [token] provider fernet [cache] backend dogpile.cache.memcached memcached_servers controller:11211然后初始化 Fernet key、同步数据库、创建 admin 项目、admin 用户、admin 角色和服务端点。这里有个记忆技巧每次创建一个新服务都逃不过三步——建数据库、建服务实体service create、建三个端点public、internal、admin。Keystone 做完后我顺手导入了几个环境变量脚本方便之后所有命令行操作都带上身份认证信息。脚本内容就是大家常见的 admin-openrcexport OS_PROJECT_DOMAIN_NAMEDefault export OS_USER_DOMAIN_NAMEDefault export OS_PROJECT_NAMEadmin export OS_USERNAMEadmin export OS_PASSWORDadmin_pass export OS_AUTH_URLhttp://controller:5000/v3 export OS_IDENTITY_API_VERSION3 export OS_IMAGE_API_VERSION2之后敲openstack token issue能拿到 token说明 Keystone 工作正常。3.3 Glance 镜像服务搭建Glance 负责管理镜像。虚拟机要能创建控制节点上必须先有可用的镜像。装 Glance 的步骤和 Keystone 大同小异建库、装包、改配置、注册服务。安装包yum install -y openstack-glance配置主要在/etc/glance/glance-api.conf重点是四块内容数据库连接、存储后端、认证信息、映像格式。存储后端我用的是本地文件系统file简单可靠后续想换成 Ceph 也容易只要改一下配置即可。我准备了一个测试镜像直接下载官方 cirros 小镜像wget http://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img openstack image create cirros --file cirros-0.4.0-x86_64-disk.img --disk-format qcow2 --container-format bare --public这里有个细节容易忽略--disk-format和--container-format必须写否则 Glance 报格式错误。--public表示公开给所有项目使用--protected可以防止镜像被误删。上传完成后用openstack image list查看状态显示 active 就是正常。如果一直卡在 saving多半是 keystone 认证配置有问题或者 glances 到数据库的连接断了去/var/log/glance/glance-api.log里能看到具体原因。3.4 Nova 计算服务的完整部署Nova 是 OpenStack 的核心计算服务组件多、角色多也是排错最耗时的部分。控制节点上有 nova-api、nova-scheduler、nova-conductor、nova-novncproxy计算节点上有 nova-compute。每台机器都要装对应的包。控制节点上执行yum install -y openstack-nova-api openstack-nova-scheduler openstack-nova-conductor openstack-nova-novncproxy openstack-nova-placement-api计算节点上执行yum install -y openstack-nova-compute先说计算节点上的/etc/nova/nova.conf。关键配置有几个数据库连接、RabbitMQ 连接、认证配置、VNC 配置和宿主机虚拟化配置。重点提示 VNC 配置因为这是你之后打开虚拟机控制台的通道[vnc] enabled True novncproxy_base_url http://controller:6080/vnc_auto.html server_listen 0.0.0.0 server_proxyclient_address 192.168.10.12server_proxyclient_address坑很多必须写计算节点的管理网 IP不能写 controller。否则你在控制台上打开 VNC会连接失败或一直转圈。接着是 CPU 模式的配置[libvirt] virt_type kvm cpu_mode host-passthrough确定宿主机支持 KVM用egrep -c (vmx|svm) /proc/cpuinfo检查返回大于 0 即可。如果服务器没有开嵌套虚拟化virt_type 会被默认降级为 qemu性能差非常多。控制节点上的配置在计算节点基础上增加了 scheduler、conductor 和 rabbitmq 相关设置配置完成后统一同步数据库su -s /bin/sh -c nova-manage api_db sync nova su -s /bin/sh -c nova-manage cell_v2 map_cell0 nova su -s /bin/sh -c nova-manage cell_v2 create_cell --name cell1 --transport-url rabbit://openstack:openstackcontroller:5672 nova su -s /bin/sh -c nova-manage db sync nova很多新手挂在这一步数据库同步时报 “No such cell” 或 “DBError”。大多数情况是 cell 创建顺序不对或者 rabbitmq 账号密码写错。建议按上面顺序一步一步来每执行完一条命令确认输出没有报错再继续。Nova 全部启动后执行openstack compute service list应该能看到所有服务都是 up 状态。如果某个服务变成 down大概率是 RabbitMQ 连接问题去对应节点的日志里搜 “Connection refused” 看是连的哪个 IP。3.5 Neutron 网络服务的部署与配置Neutron 是 OpenStack 网络服务也是配置最繁琐、最考验耐心的部分。它的组件包括控制节点上的 neutron-server网络节点上的 DHCP agent、L3 agent、Metadata agent以及计算节点上的 Linux Bridge agent。控制节点装包yum install -y openstack-neutron openstack-neutron-linuxbridge openstack-neutron-ml2网络节点装包yum install -y openstack-neutron openstack-neutron-linuxbridge openstack-neutron-l3 openstack-neutron-dhcp openstack-neutron-metadata-agent计算节点只需要安装 linuxbridge agent。Neutron 的核心配置在/etc/neutron/neutron.conf需要配置数据库、RabbitMQ、认证以及指定使用 ML2 插件。ML2 的配置文件/etc/neutron/plugins/ml2/ml2_conf.ini里我选了 VXLAN 作为租户网络的类型驱动[ml2] type_drivers flat,vlan,vxlan tenant_network_types vxlan mechanism_drivers linuxbridge,l2population [ml2_type_vxlan] vni_ranges 1:1000用 VXLAN 的好处是虚拟机网络不依赖物理交换机的 VLAN 配置overlay 网络跑在 UDP 上适合现有网络不好改动的场景。L2 population 是为了减少广播流量多计算节点时推荐开启。外部网络配置在 Linux Bridge agent 的/etc/neutron/plugins/ml2/linuxbridge_agent.ini里。关键是要给外部网络指定物理网卡映射关系[linux_bridge] physical_interface_mappings physnet1:eth2 [vxlan] enable_vxlan True local_ip 10.10.20.13 l2_population True这里的physnet1:eth2意思是逻辑网络 physnet1 对应物理网卡 eth2也就是外部网卡。如果名字对不上创建外部网络时选了 physnet1 但实际要桥接的网卡不是 eth2虚拟机拿到浮动 IP 也出不了网。网络节点上的 DHCP agent 和 L3 agent 也要配置L3 agent 负责路由和 NATDHCP agent 负责给虚拟机分配 IP。配置完成后在控制节点创建网络资源创建外部网络openstack network create external --external --provider-physical-network physnet1 --provider-network-type flat创建路由器openstack router create router1设置外部网关openstack router set router1 --external-gateway external创建租户网络和子网并把子网接上路由器这一步做完才算是真正有了一个可以通外网的云网络环境。3.6 Horizon 仪表板部署Horizon 是一个 Web 管理界面虽然日常运维我习惯用命令行但给领导和同事演示、或者让不懂命令的同事自助开虚拟机Horizon 是刚需。安装很简单yum install -y openstack-horizon配置文件在/etc/openstack-dashboard/local_settings。重点修改的是ALLOWED_HOSTS和OPENSTACK_HOST把ALLOWED_HOSTS改成[*]方便测试生产环境必须写具体的域名或 IP。然后修改/etc/httpd/conf.d/openstack-dashboard.conf确认 WSGI 配置没问题。重启 httpd 后浏览器输入http://controller/dashboard就能看到登录页。用 admin 账号登录首页右上角能切换项目左侧菜单可以管理实例、镜像、网络、路由、卷等资源。我个人建议镜像上传、网络创建这些操作用命令行更清晰但实例创建、VNC 登录这些在界面上点一点就行效率高很多。4. 私有云运维实践与日常管理4.1 命令行管理的高频操作清单搭建只是开始真正考验功底的是运维。我日常维护这套私有云90% 的时间都在用openstack命令。整理几个高频操作查看整体资源使用情况openstack hypervisor list openstack hypervisor show compute1 openstack host list查看项目配额和调整配额openstack quota show admin openstack quota set --instances 20 --vcpus 40 --ram 65536 --volumes 10 --gigabytes 200 admin查看计费或资源用量其实 OpenStack 没有内置计费但可以用 ceilometer 或 gnocchi 做监控采集openstack usage list这个命令能看到每个项目的 CPU、内存、磁盘使用时长做成本核算和资源回收判断很有用。管理云主机生命周期openstack server list openstack server show vm1 openstack server stop vm1 openstack server start vm1 openstack server reboot vm1 openstack server delete vm1创建云主机的完整命令是openstack server create --flavor m1.small --image cirros --network private --security-group default vm1这里有个经验生产环境创建主机时一定加--wait参数它会阻塞等待实例状态变成 ACTIVE 再返回方便你第一时间知道是否创建成功openstack server create --wait --flavor m1.small --image cirros --network private vm14.2 镜像管理与云主机实例调度镜像管理不只是上传下载那么简单。生产环境里最常用的镜像是 CentOS、Ubuntu 和 Windows。CentOS 镜像可以从官方 cloud 镜像仓库下载装完自带 cloud-init可以自动注入密码和 SSH 密钥。制作自定义镜像是我运维时的重要操作。流程是先创建一个基础云主机手动安装 JDK、Python、监控 agent 这些业务依赖然后清理日志、清空主机 SSH 指纹、关闭机器最后用openstack image create从卷快照做镜像。openstack server stop template-centos7 openstack image create --volume template-vol centos7-jdk8-template --public这样做出来的镜像下次创建云主机时直接选它业务从启动到可用只需要 1 分钟省去了每次手工装环境的痛苦。实例调度也有讲究。OpenStack 的 Nova scheduler 默认是 “filter scheduler”它会根据 CPU、内存、磁盘的可用量过滤掉不满足条件的计算节点再按权重打分排序。如果一台机器上了很多虚拟机导致负载高你可以手工把某个实例迁移到其他节点openstack server migrate vm1 --live-migration --block-migration openstack server resize vm1 --flavor m1.large --confirm冷迁移要先关机热迁移live migration可以做到不中断业务。但热迁移对 CPU 型号一致性要求高这也是我之前强调所有节点统一 CPU 模式的原因。4.3 项目、用户与资源配额管理私有云不能只有一个 admin得给不同部门建独立项目。比如给测试部建 test-project给研发部建 dev-project这样资源隔离、互不干扰费用如果接入计费系统也容易分摊。创建项目openstack project create --domain default --description Test Project test-project创建用户并绑定角色openstack user create --domain default --password test123 testuser openstack role add --project test-project --user testuser member这里角色分配我一般用 member 而不是 adminmember 权限足够用户在项目内创建虚拟机、管理网络但不能操作全局配置。配额管理是资源管控的关键。如果不设配额某个项目可以把整个私有云资源吃光。我的习惯是给每个新项目按部门人数和用途估算先给一个保守值后续不够再上调openstack quota set --instances 20 --vcpus 40 --ram 65536 --volumes 10 --gigabytes 200 test-project用户密码忘了用openstack user set --password重置即可。用户离职了先删掉 token 再禁用账号openstack token revoke token-id openstack user set --disable username4.4 日志体系与监控告警OpenStack 组件太多每个组件都有自己的日志文件一旦出问题如果没有日志收集机制你只能在各台机器之间来回翻文件。我的做法是部署一套简单的 ELK 或 Loki 日志集中平台把所有节点的/var/log/keystone、/var/log/nova、/var/log/neutron、/var/log/glance日志收集到一起统一搜索。如果你不想上大而全的 ELK也可以用最基本的 rsyslog 把日志转发到一台集中日志服务器# 在每台节点上配置 *.* logserver:514监控方面最轻量的是用ceilometer配合gnocchi做资源使用率采集UI 上用 Grafana 展示。不想折腾的话直接在每台机器上装 Prometheus node_exporter再配合openstack-exporter抓取 OpenStack 的 API 指标维护成本低很多。告警规则我通常会设置这么几个CPU 使用率超 80%、内存剩余低于 10%、磁盘使用率超 85%、虚拟机关机状态超过 10 分钟、OpenStack 任意 API 服务端口探活失败。这些告警规则看着简单但真出了问题能救命。有一次凌晨某个计算节点磁盘写满我还没接到业务反馈Prometheus 的告警已经发到钉钉了我远程过去清理临时日志业务几乎无感知。5. 常见故障排查与经验教训5.1 云主机无法创建或停留在 BUILD 状态这是新手遇到最多的故障。排错流程我一般是这样先看控制节点的 nova-api 日志确认 API 请求有没有进来再看 nova-scheduler 日志确认调度有没有把请求发到计算节点最后看计算节点的 nova-compute 日志确认是不是底层创建虚拟机失败。一步到位的方法是同时开三个终端实时 tail 日志tail -f /var/log/nova/nova-api.log tail -f /var/log/nova/nova-scheduler.log tail -f /var/log/nova/nova-compute.log然后重新执行创建命令看日志输出停在哪一步。常见的报错有这么几个No valid host was found调度器找不到满足资源条件的物理机查计算节点的可用资源或者看 CPU/内存配额是否用满。libvirtError: internal error: process exited while connecting to monitor计算节点的 libvirt 或 QEMU 出问题重启一下 libvirtd 服务试试。NeutronError: Failed to create port创建端口时网络没有就绪去 neutron-server 日志看具体原因多半是 DHCP agent 或 Linux Bridge agent 没起来。BuildAbortException: Instance is in ERROR state创建过程中某一步异常虚拟机被置为 ERROR需要先删除这个实例再排查原因。5.2 云主机无法获得 IP 或网络不通虚拟机起来但ip addr看不到 IP或者能看到 IP 却 ping 不通外网这类问题十有八九出在 Neutron。先排查 DHCP 是否正常。在能访问租户网络的物理机上抓包tcpdump -i brqbridge-id udp port 67如果有 DHCP 请求但没人应答去 network 节点看 neutron-dhcp-agent 日志确认 DHCP 命名空间是否创建成功ip netns list如果 DNS 解析有问题检查子网的 DNS 设置openstack subnet set --dns-nameserver 223.5.5.5 --dns-nameserver 114.114.114.114 private-subnet虚拟机通了内网但不能访问外网最常见原因是安全组没放行或浮动 IP 没绑定。安全组这块我吃过亏默认安全组只放行了 ICMP 和 SSH如果云主机里跑的是 Web 服务外部访问 80 端口会被挡住。解决办法openstack security group rule create --protocol tcp --dst-port 80:80 default openstack security group rule create --protocol tcp --dst-port 443:443 default浮动 IP 的绑定命令openstack floating ip create external openstack server add floating ip vm1 floating-ip这里再说一个经常被忽略的细节浮动 IP 绑定后虚拟机内部还需要配置好默认路由。cirros 镜像默认做好了但自己用 cloud image 装系统时如果没有配置好 metadata 服务虚拟机可能拿不到网关和 DNS 信息网络自然就不通。5.3 磁盘空间不足与 LVM 扩容私有云跑久了最大的敌人不是 OpenStack 本身而是磁盘空间。控制节点的日志、数据库、镜像文件每时每刻都在增长一不小心就会把根分区撑爆。我遇到过控制节点的/var/lib/mysql目录占满导致数据库崩溃、OpenStack 所有 API 接口全部 500 的严重事故。排查思路是df -h du -h --max-depth1 /var/lib/mysql如果是数据库太大考虑清理旧数据或给 MySQL 的 datadir 迁移到大容量磁盘。如果只是日志膨胀配置 logrotate 定期清理# /etc/logrotate.d/openstack /var/log/nova/*.log /var/log/neutron/*.log /var/log/keystone/*.log { daily rotate 14 compress missingok notifempty copytruncate }LVM 扩容的思路也要掌握。假设根分区所在的逻辑卷是/dev/mapper/centos-root新加了一块物理磁盘/dev/sdb扩容步骤是pvcreate /dev/sdb vgextend centos /dev/sdb lvextend -l 100%FREE /dev/mapper/centos-root xfs_growfs /注意 CentOS 7 默认文件系统是 xfs扩容命令用xfs_growfs如果用 resize2fs 会报错。如果是 ext4 文件系统才用 resize2fs。5.4 数据库与消息队列的常见故障MariaDB 和 RabbitMQ 是 OpenStack 的底层依赖它们出问题整个云平台都会瘫。我的体验是大多数连接类故障都是因为密码变化、主机名解析不了、端口被防火墙拦截这三个原因。RabbitMQ 最常见的故障是集群节点掉线或连接数耗尽。状态检查rabbitmqctl cluster_status rabbitmqctl list_connections集群节点之间如果网络抖动导致分区partition消息队列会出现脑裂OpenStack 各组件的状态会变得非常奇怪。预防手段是设置合理的分区处理策略rabbitmqctl set_policy ha-all ^(?!amq\.).* {ha-mode:all,ha-sync-mode:automatic}MariaDB 的问题主要集中在连接数超限和主从复制中断。查看连接数SHOW STATUS LIKE Threads_connected; SHOW VARIABLES LIKE max_connections;如果连接数总是打满在/etc/my.cnf.d/openstack.cnf里调大max_connections并启用慢查询日志找出哪些 SQL 拖慢了数据库。主从复制监控用SHOW SLAVE STATUS\G看到Slave_IO_Running: Yes和Slave_SQL_Running: Yes才是正常。如果 SQL 线程停了多半是某个 SQL 执行出错需要跳过错误或手动修复数据。我以前写过一段脚本定时把复制异常信息发到钉钉告警群这样不用每天盯服务器看。5.5 实用排错技巧与避坑指南最后整理几条我后来总结出来的排错经验每一条都是从事故里换来的看日志永远比猜问题靠谱。OpenStack 每个组件的日志文件路径基本固定出错先tail -n 100对应日志比漫无目的搜博客高效十倍。日志路径忘了就查/etc/openstack-debug.log关联的配置。改配置前先备份原文件。我习惯把每个配置文件的原始版本复制一份存到/root/backup目录命名加上日期。上线前如果改了配置文件先用openstack-config工具校验openstack-config --validate /etc/nova/nova.conf权限问题别忽略。修改配置文件后如果服务起不来检查文件属主和权限。很多服务要求配置文件属主是对应用户比如 nova.conf 属于 nova:nova权限通常是 640。曾有人把 keystone.conf 的属主改成 root 导致 httpd 启动失败。升级或补丁前先拍快照。在虚拟化环境里给虚拟机做快照的成本很低升级系统补丁前最好打一个快照出了问题一键回滚。定时巡检不能省。我维护这套私有云后写了一个 shell 脚本每周自动跑一遍检查节点离线状态、检查磁盘空间、检查 RabbitMQ 连接数、检查关键 API 端口生成报告发邮件。虽然 OpenStack 本身有健康检查命令openstack-status但只覆盖系统层业务层的巡检还是得靠自定义脚本。写在最后如果你问我现在还推荐不推荐搭 OpenStack我的回答是看场景。如果只是想跑几个虚拟机KVM 直接裸管理更轻量如果想体验最真实的 IaaS 平台工作原理、或者企业内部有资源隔离和多租户需求OpenStack 仍然是几乎不可替代的开源选择。我个人在反复搭建和运维这套 CentOS 7 OpenStack Train 环境的过程中最大的体会是它不是一个装完就完事的软件而是一套需要长期运维、持续调优的系统。你要花时间理解各组件之间的依赖关系善于从日志中挖掘问题更要建立自己的监控和巡检机制。每踩过一个坑你对这套系统的理解就更深一层。最后再分享一个小技巧任何配置文件修改后务必记住用对应组件的命令做校验比如 nova 用nova-manage --versionkeystone 用keystone-manage fernet_rotateneutron 用neutron-db-manage current。虽然这些命令不直接改配置但能在启动服务前先暴露出配置错误省得你反复重启服务才知道问题在哪。这套方法我用到现在一直很管用。