OpenStack 作为一套开源的云计算管理平台其运维工作远不止于简单的启停服务。一个典型的 OpenStack 运维日是监控、排障、变更、优化与安全加固的复合体。本文将以一个虚构但高度真实的“运维人员的一天”为主线带你演练从晨间巡检到深夜变更的完整流程涵盖日常命令、故障诊断、性能调优及自动化脚本编写等核心技能。无论你是刚接触 OpenStack 的运维新人还是希望系统化梳理工作流的老手都能通过本文构建起一套可复现、可排查的实战操作手册。我们将基于一个典型的 OpenStack Stein 或更高版本的生产环境使用 Kolla-Ansible 部署进行演示。文中所有命令、检查点和故障场景均来源于真实运维经验并会解释其背后的原理与风险。1. 晨间巡检用系统化检查清单启动一天运维工作始于对集群全局健康状态的清晰认知。盲目登录服务器逐个查看是低效的我们需要一个系统化的检查清单。1.1 第一站全局概览与核心服务状态首先通过 OpenStack 命令行客户端获取云平台的宏观状态。确保已 source 正确的openrc文件。# 检查核心服务的 API 端点状态 openstack endpoint list --service compute --interface public openstack endpoint list --service image --interface public openstack endpoint list --service network --interface public # 检查所有 Nova 计算节点的状态 openstack compute service list # 关注 State 列是否为 upStatus 列是否为 enabled # 检查 Cinder 卷服务状态 openstack volume service list # 检查 Neutron 网络代理状态 openstack network agent list # 重点关注 L3 Agent、DHCP Agent 和 Open vSwitch Agent 的状态关键解释State为down通常表示服务进程异常Status为disabled可能是管理员手动禁用。两者需区分处理。1.2 第二站基础设施层深度检查OpenStack 运行在虚拟化层和操作系统之上。我们需要检查底层基础设施。检查计算节点资源通过 Nova 调度器视角和直接登录节点两种方式。# 从 OpenStack 视角看资源使用率 openstack hypervisor stats show openstack hypervisor list --long # 查看每个 Hypervisor 的详细资源 # 登录到某个计算节点例如 node-compute-01进行底层检查 ssh rootnode-compute-01 # 检查 CPU、内存、磁盘基础负载 top -bn1 | head -20 free -h df -h | grep -E (cinder|nova|glance|var) # 查看关键分区使用率 # 检查虚拟化相关进程与服务以 Libvirt 为例 systemctl status libvirtd virsh list --all # 列出该节点上所有虚拟机实例检查存储后端如果使用 Ceph 作为统一后端Glance、Cinder、Nova。# 在部署了 Ceph Mon 的节点上执行 ceph -s # 查看集群整体健康状态 ceph osd stat # 查看 OSD 状态 ceph df # 查看存储池使用情况 # 重点关注 health 状态HEALTH_WARN 或 HEALTH_ERR 需要立即处理。检查网络状态Neutron 的异常往往体现在虚拟网络不通。# 检查 Neutron 的底层网络命名空间和端口 ip netns list # 列出所有网络命名空间Router, DHCP, etc. # 进入一个路由器命名空间检查路由和 IP sudo ip netns exec qrouter-router-id ip addr show sudo ip netns exec qrouter-router-id ping -c 4 8.8.8.8 # 测试外部网络连通性1.3 第三站告警与日志初步筛查在完成主动检查后需要查看监控系统如 Prometheus/Grafana Alertmanager是否有未恢复的告警。如果没有集中监控则需手动检查关键日志。# 在控制节点检查关键服务日志的最后错误信息 tail -100 /var/log/kolla/nova/nova-api.log | grep -E \ERROR|CRITICAL\ tail -100 /var/log/kolla/neutron/neutron-server.log | grep -E \ERROR|CRITICAL\ tail -100 /var/log/kolla/placement/placement-api.log | grep -E \ERROR|CRITICAL\ # Placement 服务异常会影响调度 # 使用 journalctl 查看系统服务状态适用于 systemd 管理的非容器化部署 journalctl -u nova-compute --since \today 06:00\ --no-pager | tail -50注意巡检的目的不是深入分析每一个 Warning而是快速发现需要立即介入的ERROR、CRITICAL级别日志或down状态的服务。将非紧急问题记录到工单系统安排后续处理。2. 故障诊断实战应对突发虚拟机创建失败假设在巡检后收到开发团队反馈“创建中型规格4C8G的虚拟机失败报错No valid host was found”。这是 OpenStack 运维中最常见的故障之一。2.1 第一步复现问题并收集基础信息首先尝试复现问题并收集请求的详细信息。# 尝试创建虚拟机并记录返回的错误ID如果有 openstack server create --flavor m1.medium --image cirros --network private-net test-vm-fail # 假设返回错误\NoValidHost: No valid host was found.\ # 获取失败请求的调度详情需要启用 Nova 调度器调试日志或通过以下命令间接查看 openstack --debug server create --flavor m1.medium --image cirros --network private-net test-vm-fail 21 | grep -A 10 -B 10 \Filtering\ # 但生产环境通常不会开 debug。更实际的方法是检查 Nova 的调度日志。2.2 第二步分析调度器过滤与称重过程No valid host的根本原因是所有计算节点在调度过滤Filter或称重Weighing阶段被排除了。我们需要按顺序排查。1. 检查资源是否真的不足openstack hypervisor list --long # 查看每个节点的 vCPUs、Memory_MB、Disk 的 Used/Total。确认是否有节点满足 4C8G 的资源要求。2. 检查 Aggregate 和 Availability Zone 限制创建请求或镜像可能限定了 AZ。# 查看 flavor 的额外规格extra_specs openstack flavor show m1.medium -c properties -f json # 输出可能类似{\properties\: \aggregate_instance_extra_specs:storagessd\} # 这意味着 flavor 要求主机在具有 storagessd 标签的 Aggregate 中。 # 查看计算节点所在的 Aggregate 及标签 openstack aggregate list openstack aggregate show aggregate-id3. 检查网络与安全组网络资源不足也可能导致调度失败。# 检查目标网络的子网 IP 使用情况 openstack subnet show private-subnet-id -c allocation_pools -c used_ips -c total_ips # 如果 used_ips 接近 total_ips可能是 DHCP 地址池耗尽。4. 深入计算节点状态节点可能被disabled或处于drain状态。openstack compute service list # 如果某个计算节点的状态是 disabled需要查明原因可能是手动维护。 nova service-list # 旧版命令有时信息更详细2.3 第三步登录计算节点排查具体原因如果宏观资源充足问题可能出在某个具体的计算节点上。我们需要检查候选节点的详细状态。检查 Nova-Compute 日志# 登录到一个资源充足但调度失败的计算节点 ssh rootnode-compute-02 tail -200 /var/log/kolla/nova/nova-compute.log # 查找关键词 \Filtering\, \Weighing\, \Failed to claim resources\, \No valid host\ # 常见错误ResourceProvider: No inventory检查 Placement API从 Nova Stein 版本开始资源调度严重依赖 Placement 服务。# 在控制节点检查 Placement 资源清单 openstack resource provider list openstack resource provider inventory list resource-provider-uuid # 确认 VCPU、MEMORY_MB、DISK_GB 的 total 和 allocation_ratio 设置合理。 # 检查是否有资源被过度分配overcommit导致调度器误判。检查主机聚合Host Aggregate与标签Traits# 在控制节点查看资源提供者的 Traits特性 openstack resource provider trait list resource-provider-uuid # Placement 使用 Traits 来匹配 flavor 的 extra_specs。如果 flavor 要求 CUSTOM_SSD但节点没有此 Trait则会被过滤。2.4 第四步常见根因与解决方案根据上述排查我们汇总常见原因及处理方案问题现象可能原因检查命令/位置解决方案资源不足计算节点 CPU/内存/磁盘已满openstack hypervisor list --long扩容节点或迁移实例调度过滤Flavor 的extra_specs与主机 Aggregate 标签不匹配openstack flavor show/openstack aggregate show修改 flavor 或为主机添加对应标签Placement 资源问题资源清单inventory未正确上报或比例allocation_ratio设置过低openstack resource provider inventory list更新 inventory 或调整 allocation_ratio网络资源不足子网 IP 池耗尽或网络配额不足openstack subnet show/openstack quota show扩展子网 IP 池或调整配额计算节点服务异常nova-compute 服务 down 或 disabledopenstack compute service list重启服务或启用节点镜像问题镜像状态非active或格式不被 Hypervisor 支持openstack image show重新激活或转换镜像格式安全组/端口限制安全组规则阻止了实例与元数据服务器通信Neutron 安全组日志检查并修正安全组规则对于我们的案例假设最终发现是m1.mediumflavor 设置了aggregate_instance_extra_specs:storagessd但所有满足资源条件的计算节点都未被打上storagessd标签。解决方案有二修改 Flavor移除或修改 flavor 的额外规格要求。openstack flavor unset --property aggregate_instance_extra_specs:storage m1.medium修改主机将符合条件的计算节点加入对应 Aggregate 并设置标签。openstack aggregate add host ssd-aggregate-id node-compute-02 # 标签通常在创建 Aggregate 时设置或通过 openstack aggregate set --property storagessd aggregate-id3. 日常变更操作安全地扩容计算节点下午计划向集群添加一台新的计算节点。这是一个标准但高风险的操作必须遵循严格的流程。3.1 变更前准备检查清单与备份信息收集确认新节点的硬件配置CPU、内存、磁盘、网卡、IP地址、主机名。环境检查确保新节点与现有集群网络互通管理网、存储网、业务网时间同步NTP以及基础依赖如特定版本内核、QEMU/KVM一致。备份配置备份部署工具如 Kolla-Ansible的清单文件 (inventory) 和全局配置 (globals.yml)。cd /etc/kolla cp -a inventory inventory.bak.$(date %Y%m%d) cp -a globals.yml globals.yml.bak.$(date %Y%m%d)通知在变更窗口开始前通知相关用户可能存在的服务影响。3.2 节点预配置系统与依赖假设我们使用 Kolla-Ansible 部署新节点需要预先满足一些条件。# 1. 在新节点上配置主机名和 hosts 文件 hostnamectl set-hostname node-compute-new echo \management_ip node-compute-new\ /etc/hosts # 2. 安装基础依赖根据 Kolla-Ansible 要求 # 例如对于 CentOS 7 yum install -y python3-devel libffi-devel gcc openssl-devel python3-libselinux # 3. 配置免密 SSH从部署机到新节点 # 在部署机上执行 ssh-copy-id rootnode-compute-new # 4. 检查虚拟化支持必须 egrep -c (vmx|svm) /proc/cpuinfo # 输出大于0 lsmod | grep kvm # 应看到 kvm_intel 或 kvm_amd3.3 修改部署清单与执行扩容更新 Ansible 清单文件将新节点添加到[compute]组并可能添加到特定的[hypervisor:children]组。# /etc/kolla/inventory [compute] node-compute-01 node-compute-02 node-compute-new # 新增行 [hypervisor:children] compute运行预检查Kolla-Ansible 提供了强大的预检查功能。kolla-ansible -i inventory prechecks --tags nova注意必须解决所有prechecks报错否则部署极有可能失败。执行扩容部署使用--limit参数仅对新节点进行操作避免影响现有集群。kolla-ansible -i inventory deploy --limit node-compute-new --tags nova这个命令会在新节点上部署nova-compute、neutron-openvswitch-agent等必要服务。验证服务状态# 部署完成后在控制节点验证 openstack compute service list # 应看到 node-compute-new 上的 nova-compute 服务状态为 up 和 enabled。 openstack hypervisor list # 应看到新节点并且其状态为 up。3.4 变更后验证与监控功能测试在新节点上创建测试虚拟机。openstack server create --flavor m1.tiny --image cirros --network private-net --availability-zone nova:node-compute-new test-vm-new-node openstack server show test-vm-new-node -c status -c host # 确认状态为 ACTIVE主机为 node-compute-new。网络测试登录测试虚拟机验证内外网连通性。监控接入将新节点纳入监控系统如 Prometheus node_exporter并确认告警规则生效。文档更新更新内部运维文档记录新节点的信息、加入时间和配置特点。4. 性能调优与自动化脚本编写在日常运维中除了应对故障和变更还需要主动进行性能优化并将重复性工作自动化。4.1 识别性能瓶颈关键指标监控性能问题往往表现为用户投诉“虚拟机卡顿”、“磁盘 IO 慢”。我们需要从监控数据入手。CPU 与内存监控项计算节点CPU steal timesteal。如果虚拟机steal时间过高说明物理 CPU 资源竞争激烈可能由于过度超售或邻居虚拟机负载过高。检查命令在计算节点上使用top或virsh。# 查看节点上所有虚拟机的 CPU 时间统计 virsh list virsh domstats vm-id | grep cpu.time调优建议调整 flavor 的 CPU 绑定策略如使用hw:cpu_policydedicated或降低节点的 CPU 超售比cpu_allocation_ratio。磁盘 I/O监控项Ceph OSD 的latency或计算节点磁盘的await通过iostat -x 1查看。常见场景所有虚拟机磁盘性能同时下降很可能问题在共享存储后端如 Ceph。调优建议为不同性能要求的磁盘配置不同的 Ceph 存储池如ssd-pool和hdd-pool。在 Cinder volume type 中指定对应的存储池。在计算节点对本地盘或 Ceph RBD 缓存进行分区和调度器优化如使用deadline或noop调度器。网络监控项Neutron 代理的丢包率、OVS 流表数量、网络命名空间内的 TCP 重传。检查命令# 检查 OVS 流表数量过多可能影响性能 sudo ovs-ofctl dump-flows br-int | wc -l # 检查网络命名空间内的连接状态 sudo ip netns exec qrouter-id netstat -s | grep -E \segments retransmited|retrans\调优建议定期清理无效的流表调整 Neutron 的dhcp_lease_duration以减少 DHCP 流量对于高吞吐场景考虑使用 SR-IOV。4.2 编写自动化运维脚本将日常巡检和简单修复操作脚本化是提升效率的关键。以下是一个结合了上述检查点的 Bash 脚本示例。#!/bin/bash # filename: openstack_daily_check.sh # 功能OpenStack 日常健康检查脚本 # 使用在控制节点运行需提前 source openrc 文件 set -euo pipefail LOG_FILE/var/log/openstack_daily_check_$(date %Y%m%d).log exec (tee -a $LOG_FILE) 21 echo OpenStack 日常检查开始 $(date) # 1. 检查核心服务状态 echo ### 1. 核心服务状态 ### openstack compute service list | grep -v \^\\|^ID\ | while read line; do if echo $line | grep -q \down\\|disabled\; then echo \[WARNING] 服务异常: $line\ fi done openstack network agent list | grep -v \^\\|^ID\ | while read line; do if echo $line | grep -q \xxx\; then # 这里 xxx 代表 down 等状态需根据实际输出调整 echo \[WARNING] 网络代理异常: $line\ fi done # 2. 检查资源使用率 echo \\\n### 2. 计算节点资源概览 ###\ openstack hypervisor stats show echo \\\n### 3. Ceph 集群健康状态 (如果使用) ###\ if command -v ceph /dev/null; then ceph -s | head -5 else echo \Ceph 命令未找到跳过。\ fi # 3. 检查关键错误日志最近10分钟 echo \\\n### 4. 关键错误日志检查 (最近10分钟) ###\ for service in nova-api neutron-server placement-api; do log_path\/var/log/kolla/${service}/${service}.log\ if [ -f \$log_path\ ]; then echo \检查 $service 日志\ grep -E \ERROR|CRITICAL\ \$log_path\ | grep \$(date --date\-10 minutes\ %Y-%m-%d %H:%M)\ | tail -5 fi done echo \\\n 日常检查结束 $(date) \脚本编写注意事项安全第一脚本中避免硬编码密码使用openrc文件或 Keystone 应用凭证。错误处理使用set -euo pipefail让脚本在遇到错误时及时退出。日志记录所有操作记录日志便于追溯。温和操作巡检脚本应为只读操作避免在脚本中执行重启、删除等危险命令。可配置化将检查项、阈值等提取为配置文件或命令行参数。4.3 生产环境运维最佳实践清单基于一天的演练我们总结出以下生产环境运维的核心实践类别最佳实践说明变更管理任何变更前必须备份配置文件、数据库如必要和虚拟机关键数据。使用版本控制系统如 Git管理 Ansible Playbook 和配置。监控告警建立覆盖物理机、OpenStack 服务层、业务虚拟机三层的监控。核心指标服务状态、API 响应时间、资源使用率、存储/网络错误率。容量规划设置资源使用率预警阈值如 CPU 85%内存 80%并定期进行容量评审。避免资源耗尽导致的级联故障。日志管理集中收集所有节点的 OpenStack 组件日志、系统日志和审计日志。使用 ELK 或 Loki 等工具便于关联分析和历史查询。安全加固定期更新 CVE最小化 Keystone 令牌有效期使用 TLS 加密 API 端点定期审计安全组规则。遵循 OpenStack 安全指南。备份策略制定并定期测试备份恢复流程包括数据库MariaDB/Galera、配置、Glance 镜像、Cinder 卷快照。区分全量和增量备份明确 RTO 和 RPO。文档与演练维护实时更新的运维手册、应急预案和故障排查树。定期进行故障演练。确保在紧急情况下任何值班人员都能按步骤操作。OpenStack 运维的深度在于对复杂系统联动关系的理解。从一次简单的虚拟机创建失败可以追溯到 Placement 的资源模型、Neutron 的网络配置、Ceph 的存储健康乃至底层操作系统的内核参数。高效的运维不是被动救火而是通过系统化的巡检、自动化的工具、严谨的变更流程和深度的性能分析将不可控的风险转化为可预测、可管理的日常工作。建议读者在理解本文流程的基础上搭建自己的实验环境亲手复现每一个故障场景并尝试编写更贴合自身环境的自动化脚本这才是从“知道”到“做到”的关键。