《CentOS7 OpenStack Mitaka 全栈部署实战：双节点搭建全流程与典型故障排坑指南》

一路向北finish2026-08-27 13:01

CentOS7 OpenStack Mitaka全栈部署复盘：从Glance到云主机创建的踩坑实录

文章目录

  • [CentOS7 OpenStack Mitaka全栈部署复盘：从Glance到云主机创建的踩坑实录](#CentOS7 OpenStack Mitaka全栈部署复盘：从Glance到云主机创建的踩坑实录)
    • 一、实操概述
    • 二、部署实施一：Glance镜像服务
      • [2.1 核心配置文件修改](#2.1 核心配置文件修改)
      • [2.2 数据库初始化踩坑](#2.2 数据库初始化踩坑)
      • [2.3 服务启动与端口验证](#2.3 服务启动与端口验证)
      • [2.4 Keystone服务注册与端点创建](#2.4 Keystone服务注册与端点创建)
      • [2.5 镜像上传报错](#2.5 镜像上传报错)
    • 三、计算节点基础环境准备
      • [3.1 时间同步服务部署](#3.1 时间同步服务部署)
      • [3.2 硬件虚拟化支持验证](#3.2 硬件虚拟化支持验证)
      • [3.3 嵌套虚拟化验证](#3.3 嵌套虚拟化验证)
      • [3.4 网络连通与基础工具安装](#3.4 网络连通与基础工具安装)
    • 四、部署实施二：Nova计算服务
    • 五、部署实施三：Neutron网络服务
      • [5.1 数据库创建与Keystone注册](#5.1 数据库创建与Keystone注册)
      • [5.2 核心配置文件修改](#5.2 核心配置文件修改)
      • [5.3 数据库同步与服务启动](#5.3 数据库同步与服务启动)
      • [5.4 Compute端Neutron部署](#5.4 Compute端Neutron部署)
      • [5.5 全节点Agent验证](#5.5 全节点Agent验证)
      • [5.6 Provider扁平网络创建](#5.6 Provider扁平网络创建)
    • 六、功能验证：云主机全流程测试
      • [6.1 基础资源核查](#6.1 基础资源核查)
      • [6.2 云主机创建与状态验证](#6.2 云主机创建与状态验证)
      • [6.3 控制台与连通性测试](#6.3 控制台与连通性测试)
    • 七、部署实施四：Horizon仪表盘
      • [7.1 核心配置文件修改](#7.1 核心配置文件修改)
      • [7.2 httpd启动失败排错](#7.2 httpd启动失败排错)
      • [7.3 修复后启动验证](#7.3 修复后启动验证)
      • [7.4 登录验证与界面功能](#7.4 登录验证与界面功能)
    • 八、踩坑汇总与实操总结
      • [8.1 核心踩坑点汇总](#8.1 核心踩坑点汇总)
      • [8.2 实操心得](#8.2 实操心得)

一、实操概述

本次实操基于CentOS 7.9系统搭建OpenStack Mitaka版本云平台，采用controller+compute1双节点架构，依次完成Glance镜像服务、计算节点环境初始化、Nova计算服务、Neutron网络服务、云实例创建验证、Horizon仪表盘六大模块的部署。全程踩坑不少，从配置拼写、部署顺序到服务依赖问题，一步步排查解决，最终跑通了从镜像上传到云主机创建、Web界面管理的完整链路。

二、部署实施一：Glance镜像服务

Glance是OpenStack的镜像管理组件，负责云主机镜像的存储、查询和分发，是云平台的核心基础服务。

2.1 核心配置文件修改

首先在controller节点修改Glance的两个核心配置文件：glance-api.conf和glance-registry.conf，分别配置数据库连接、Keystone认证、镜像存储后端等核心参数。

bash 复制代码 
vim /etc/glance/glance-api.conf
vim /etc/glance/glance-registry.conf

过滤掉所有注释行后，核心有效配置如下：

ini 复制代码 
[database]
connection = mysql+pymysql://glance:glance@controller/glance

[glance_store]
stores = file,http
default_store = file
filesystem_store_datadir = /var/lib/glance/images/

[keystone_authtoken]
auth_uri = http://controller:5000
auth_url = http://controller:35357
memcached_servers = controller:11211
auth_type = password
project_domain_name = default
user_domain_name = default
project_name = service
username = glance
password = glance

其余配置段保持默认即可，主要是各类通用框架、消息队列和插件的空配置段。

2.2 数据库初始化踩坑

改完配置我直接登录MySQL，想查看Glance的表结构，执行use glance;时直接报错：ERROR 1049 (42000): Unknown database 'glance'。

这是新手很容易踩的顺序坑：必须先创建数据库和授权用户，再修改配置文件，最后执行数据库同步。我先写了配置却忘了建库，自然访问失败，后续补上了数据库创建步骤。

2.3 服务启动与端口验证

数据库和配置准备完毕后，设置Glance两个服务开机自启并启动，随后检查9292端口是否正常监听：

bash 复制代码 
systemctl enable openstack-glance-api.service openstack-glance-registry.service
systemctl start openstack-glance-api.service openstack-glance-registry.service
netstat -antlp | grep :9292

看到9292端口处于LISTEN状态，进程为python2，说明Glance API服务启动成功。

2.4 Keystone服务注册与端点创建

Glance需要注册到Keystone身份服务中，才能被其他组件调用。先加载管理员环境变量，创建image类型的服务实体，再依次创建public、internal两类访问端点：

bash 复制代码 
source admin-openrc
openstack service create --name glance --description "OpenStack Image service" image
openstack endpoint create --region RegionOne image public http://controller:9292
openstack endpoint create --region RegionOne image internal http://controller:9292

继续创建admin端点，完成后查看服务列表和端点列表验证注册结果，同时尝试上传镜像：

bash 复制代码 
openstack endpoint create --region RegionOne image admin http://controller:9292
openstack service list
openstack endpoint list | grep image
openstack image create "cirros" \
--file cirros-0.6.0-x86_64-disk.img \
--disk-format qcow2 --container-format bare \
--public

2.5 镜像上传报错

执行上传命令后直接报错：[Errno 2] No such file or directory: 'cirros-0.6.0-x86_64-disk.img'。

原因很简单：当前执行命令的目录下没有对应的镜像文件。要么提前把镜像下载到当前目录，要么命令里写绝对路径即可解决。

三、计算节点基础环境准备

完成控制节点Glance服务后，转向compute1计算节点，完成时间同步、硬件虚拟化、嵌套虚拟化、基础依赖安装等前置准备。

3.1 时间同步服务部署

多节点OpenStack必须保证时间一致，否则会出现认证失败、服务异常等问题。在compute1节点安装NTP时间同步服务：

bash 复制代码 
yum install -y ntp
systemctl enable ntpd
systemctl start ntpd

3.2 硬件虚拟化支持验证

计算节点需要CPU支持硬件虚拟化才能运行KVM虚拟机。执行命令查看CPU是否支持SVM（AMD平台虚拟化指令）：

bash 复制代码 
grep svm /proc/cpuinfo

输出的flags中包含svm字段，说明CPU支持硬件虚拟化。

安装虚拟化相关依赖包后，启动libvirtd服务，检查KVM内核模块是否加载：

bash 复制代码 
systemctl enable libvirtd
systemctl start libvirtd
lsmod | grep kvm

可以看到kvm和kvm_amd模块已正常加载。

3.3 嵌套虚拟化验证

由于是在虚拟机中部署OpenStack，必须开启嵌套虚拟化才能正常创建云主机。重启主机后验证嵌套虚拟化状态，输出1表示已成功开启：

bash 复制代码 
grep svm /proc/cpuinfo | head -1
lsmod | grep kvm
cat /sys/module/kvm_amd/parameters/nested

3.4 网络连通与基础工具安装

先验证compute1到controller节点的网络连通性，确保节点间通信正常：

bash 复制代码 
ping controller -c 3

随后安装OpenStack常用工具包crudini和openstack-utils，方便后续批量修改配置文件：

bash 复制代码 
yum install -y crudini openstack-utils

安装过程中提示centos-release-openstack-mitaka包不存在，是因为源已经提前配置完成，直接安装工具包即可。

四、部署实施二：Nova计算服务

Nova是OpenStack的核心计算组件，负责云主机的创建、调度、销毁等全生命周期管理，分为控制节点服务和计算节点服务两部分。

4.1 Controller端数据库创建

Nova需要两个独立数据库：nova_api存储API接口相关数据，nova存储计算核心业务数据。登录MySQL创建数据库并授权nova用户：

sql 复制代码 
CREATE DATABASE nova_api;
CREATE DATABASE nova;
GRANT ALL PRIVILEGES ON nova_api.* TO 'nova'@'localhost' IDENTIFIED BY '123456';
GRANT ALL PRIVILEGES ON nova_api.* TO 'nova'@'%' IDENTIFIED BY '123456';
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'localhost' IDENTIFIED BY '123456';
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'%' IDENTIFIED BY '123456';

4.2 Controller端Nova核心配置

修改/etc/nova/nova.conf主配置文件，按不同配置段逐一设置参数。

全局配置段

配置启用的API、消息队列后端、认证策略、本机IP、网络驱动等：

ini 复制代码 
[DEFAULT]
enabled_apis = osapi_compute, metadata
rpc_backend = rabbit
auth_strategy = keystone
my_ip = 192.168.241.171
use_neutron = True
firewall_driver = nova.virt.firewall.NoopFirewallDriver
数据库连接配置

分别配置API数据库和核心数据库的连接串：

ini 复制代码 
[api_database]
connection = mysql+pymysql://nova:123456@controller/nova_api
ini 复制代码 
[database]
connection = mysql+pymysql://nova:123456@controller/nova
消息队列配置

配置RabbitMQ消息队列连接信息，Nova各组件间通过消息队列通信：

ini 复制代码 
[oslo_messaging_rabbit]
rabbit_host = controller
rabbit_userid = openstack
rabbit_password = 123456
Keystone认证配置

配置Keystone认证地址和服务账号信息：

ini 复制代码 
[keystone_authtoken]
auth_uri = http://controller:5000
auth_url = http://controller:35357
memcached_servers = controller:11211
auth_type = password
project_domain_name = default
user_domain_name = default
project_name = service
username = nova
password = 123456
Glance与并发锁配置

指定Glance服务地址，设置进程锁文件存储路径：

ini 复制代码 
[glance]
api_servers = http://controller:9292
ini 复制代码 
[oslo_concurrency]
lock_path = /var/lib/nova/tmp

4.3 服务启动异常排查

配置完成后，启用并启动Nova控制节点的所有服务：

bash 复制代码 
systemctl enable openstack-nova-api.service openstack-nova-scheduler.service openstack-nova-conductor.service
systemctl start openstack-nova-api.service openstack-nova-scheduler.service openstack-nova-conductor.service
systemctl enable openstack-nova-novncproxy.service openstack-nova-consoleauth.service
systemctl start openstack-nova-novncproxy.service openstack-nova-consoleauth.service

执行openstack compute service list查看服务状态，结果调度器、导体服务的State都是down。

排查与解决

初步判断是消息队列连接异常，核对后发现RabbitMQ中openstack用户的实际密码，与Nova配置文件中填写的密码不一致，导致服务无法连接消息队列。

执行三步修复：

  1. 用crudini修正配置文件中的密码
  2. 同步修改RabbitMQ中openstack用户的密码
  3. 重置服务失败状态，重启所有Nova服务
bash 复制代码 
crudini --set /etc/nova/nova.conf oslo_messaging_rabbit rabbit_password 123456
rabbitmqctl change_password openstack 123456
systemctl reset-failed openstack-nova-scheduler.service
systemctl restart openstack-nova-api.service \
openstack-nova-scheduler.service \
openstack-nova-conductor.service \
openstack-nova-consoleauth.service

重启后再次查看计算服务列表，所有服务状态变为up，问题解决。

4.4 Compute端Nova配置

转到compute1计算节点，同样修改/etc/nova/nova.conf配置文件，大部分配置与控制节点一致，差异主要在本机IP和VNC控制台配置。

ini 复制代码 
[DEFAULT]
rpc_backend = rabbit
auth_strategy = keystone
my_ip = 192.168.241.172
use_neutron = True
firewall_driver = nova.virt.firewall.NoopFirewallDriver
ini 复制代码 
[oslo_messaging_rabbit]
rabbit_host = controller
rabbit_userid = openstack
rabbit_password = 123456
ini 复制代码 
[keystone_authtoken]
auth_uri = http://controller:5000
auth_url = http://controller:35357
memcached_servers = controller:11211
auth_type = password
project_domain_name = default
user_domain_name = default
project_name = service
username = nova
password = 123456
ini 复制代码 
[glance]
api_servers = http://controller:9292

额外添加VNC控制台配置，支持通过Web访问云主机桌面：

ini 复制代码 
[vnc]
enabled = True
vncserver_listen = 0.0.0.0
vncserver_proxyclient_address = $my_ip
novncproxy_base_url = http://controller:6080/vnc_auto.html

4.5 计算节点服务启动与验证

确认CPU虚拟化支持后，启用并启动libvirtd和nova-compute服务：

bash 复制代码 
egrep -c '(vmx|svm)' /proc/cpuinfo
systemctl enable libvirtd.service openstack-nova-compute.service
systemctl start libvirtd.service openstack-nova-compute.service

回到controller节点，再次查看计算服务列表，可以看到compute1节点的nova-compute服务已成功注册，状态为up。

五、部署实施三：Neutron网络服务

Neutron是OpenStack的网络核心组件，负责提供虚拟网络、子网、端口、安全组等网络资源。本次采用LinuxBridge插件+Flat扁平网络模式。

5.1 数据库创建与Keystone注册

创建Neutron数据库

登录MySQL创建neutron数据库并授权：

sql 复制代码 
CREATE DATABASE neutron;
GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'localhost' IDENTIFIED BY '123456';
GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'%' IDENTIFIED BY '123456';
Keystone身份注册

创建neutron系统用户，加入service项目的admin角色，然后创建network类型的服务与三个访问端点：

bash 复制代码 
source admin-openrc
openstack user create --domain default --password 123456 neutron
openstack role add --project service --user neutron admin
openstack service create --name neutron --description "OpenStack Networking" network

openstack endpoint create --region RegionOne network public http://controller:9696
openstack endpoint create --region RegionOne network internal http://controller:9696
openstack endpoint create --region RegionOne network admin http://controller:9696

5.2 核心配置文件修改

Controller节点需要修改Neutron主配置、ML2插件、LinuxBridge代理、DHCP代理、元数据代理共5个配置文件，同时还要在Nova配置中添加网络相关参数：

bash 复制代码 
vim /etc/neutron/neutron.conf
vim /etc/neutron/plugins/ml2/ml2_conf.ini
vim /etc/neutron/plugins/ml2/linuxbridge_agent.ini
vim /etc/neutron/dhcp_agent.ini
vim /etc/neutron/metadata_agent.ini
vim /etc/nova/nova.conf

5.3 数据库同步与服务启动

配置完成后，执行Neutron数据库迁移，生成所有网络数据表：

bash 复制代码 
su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf \
--config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron

迁移过程会输出一系列版本升级日志，最终显示OK代表同步成功。

同步完成后重启Nova API服务，然后启动所有Neutron服务并设置开机自启：

bash 复制代码 
systemctl restart openstack-nova-api.service
systemctl enable neutron-server.service \
neutron-linuxbridge-agent.service neutron-dhcp-agent.service \
neutron-metadata-agent.service
systemctl start neutron-server.service \
neutron-linuxbridge-agent.service neutron-dhcp-agent.service \
neutron-metadata-agent.service

启动后查看Agent列表，controller节点的DHCP代理、Metadata代理、LinuxBridge代理均正常运行：

bash 复制代码 
neutron agent-list

5.4 Compute端Neutron部署

在compute1节点安装Neutron LinuxBridge代理，修改对应配置文件，然后启动代理服务并重启Nova计算服务：

bash 复制代码 
vim /etc/neutron/neutron.conf
vim /etc/neutron/plugins/ml2/linuxbridge_agent.ini
vim /etc/nova/nova.conf

systemctl enable neutron-linuxbridge-agent.service
systemctl start neutron-linuxbridge-agent.service
systemctl restart openstack-nova-compute.service

5.5 全节点Agent验证

回到controller节点再次查询Agent列表，此时会新增compute1节点的LinuxBridge代理，所有四个Agent的alive状态均为True，说明全节点网络服务部署成功。

5.6 Provider扁平网络创建

创建一个Flat类型的提供商网络，与宿主机处于同一网段，云主机可以直接获取物理网段IP：

bash 复制代码 
neutron net-create --shared --provider:physical_network provider \
--provider:network_type flat provider

neutron subnet-create --name provider \
--allocation-pool start=192.168.241.101,end=192.168.241.150 \
--dns-nameserver 114.114.114.114 --gateway 192.168.241.2 \
provider 192.168.241.0/24

六、功能验证：云主机全流程测试

所有核心组件部署完成后，通过创建云主机来验证整个平台的功能链路是否通畅。

6.1 基础资源核查

先查看当前平台可用的规格、镜像、网络和安全组资源：

bash 复制代码 
openstack flavor list
openstack image list
openstack network list
openstack security group list

查询过程中镜像列表曾出现Service Unavailable (HTTP 503)报错，排查后是Glance服务异常，重启服务后恢复正常。

6.2 云主机创建与状态验证

使用cirros镜像、m1.tiny规格，连接provider网络，创建测试云主机：

bash 复制代码 
openstack server create --flavor m1.tiny --image cirros \
--nic net-id=00f1e3d6-2c24-44b8-bc22-8f184d6bbb59 \
--security-group default provider-instance

刚创建时云主机处于BUILD调度状态，等待30秒后再次查询，状态变为ACTIVE，并成功分配到IP地址192.168.241.102。

bash 复制代码 
sleep 30
openstack server list

6.3 控制台与连通性测试

获取VNC控制台地址：

bash 复制代码 
openstack console url show provider-instance

默认安全组禁止外部访问，先添加TCP 22端口的放行规则，再测试网络连通性：

bash 复制代码 
openstack security group rule create --proto tcp --dst-port 22 default
ping -c 4 192.168.241.102

数据包全部正常接收，随后通过SSH成功登录cirros系统，说明网络链路完全通畅。

七、部署实施四：Horizon仪表盘

Horizon是OpenStack的Web管理界面，基于Django框架开发，可以直观地管理平台所有资源。

7.1 核心配置文件修改

修改Dashboard的主配置文件/etc/openstack-dashboard/local_settings，配置Keystone地址、域名支持、时区、Neutron功能开关等参数：

python 复制代码 
import os
from django.utils.translation import ugettext_lazy as _

DEBUG = True
ALLOWED_HOSTS = ['*',]

OPENSTACK_HOST = "controller"
OPENSTACK_KEYSTONE_URL = "http://%s:5000/v3" % OPENSTACK_HOST
OPENSTACK_KEYSTONE_DEFAULT_ROLE = "user"
OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True

OPENSTACK_API_VERSIONS = {
    "identity": 3,
    "image": 2,
    "volume": 2,
}
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = "default"

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
        'LOCATION': 'controller:11211',
    }
}

OPENSTACK_NEUTRON_NETWORK = {
    'enable_router': False,
    'enable_quotas': False,
    'enable_ipv6': False,
    'enable_distributed_router': False,
    'enable_ha_router': False,
    'enable_lb': False,
    'enable_firewall': False,
    'enable_vpn': False,
    'enable_fip_topology_check': False,
    'default_ipv4_subnet_pool_label': None,
}

TIME_ZONE = "Asia/Shanghai"
WEBROOT = '/dashboard'

7.2 httpd启动失败排错

安装完Dashboard相关依赖包后，重启httpd和memcached服务，结果httpd直接启动失败。

通过systemctl status httpd查看详细报错，错误信息非常明确：IndentationError: unexpected indent，定位到配置文件中的字典项存在多余缩进。

这是部署Horizon的高频坑：配置文件是Python语法，对缩进极其敏感，复制粘贴时很容易带入多余空格，导致Django加载配置时语法报错，进而导致httpd启动失败。

7.3 修复后启动验证

修正配置文件的缩进问题后，再次重启服务，httpd成功启动，进程正常运行。

7.4 登录验证与界面功能

浏览器访问Dashboard地址，出现登录页面，选择域default，输入admin账号密码即可登录。

也可以通过curl命令验证Keystone V3接口是否正常：

bash 复制代码 
curl http://127.0.0.1:5000/v3/

登录后可以在界面中查看各类资源：身份管理页面的项目、用户列表。

资源概况的使用统计。

网络列表。

云实例详情。

以及网络拓扑可视化页面。

八、踩坑汇总与实操总结

8.1 核心踩坑点汇总

  1. 部署顺序颠倒：Glance部署时先改配置后建库，导致数据库不存在报错。正确顺序：建库建用户→写配置→同步数据库→启动服务。
  2. 文件路径错误：上传镜像时未注意当前工作目录，直接使用相对文件名导致找不到文件。
  3. 消息队列密码不匹配：Nova配置中的RabbitMQ密码与实际用户密码不一致，导致所有计算服务状态down。排错优先检查消息队列连通性。
  4. Python配置缩进错误：Horizon配置文件缩进错误直接导致httpd启动失败，Python格式的配置文件务必严格对齐缩进。
  5. 服务异常连锁反应：Glance服务异常会导致镜像列表返回503，排错时要从底层依赖服务往上逐层排查。

8.2 实操心得

OpenStack Mitaka的每个组件基本都遵循「建数据库→Keystone注册→改配置文件→同步数据库→启动服务→验证」的标准流程，但细节处容错率极低。一个参数拼写错误、一个密码不对应、一个顺序颠倒，都可能导致整个组件无法正常工作。

排错最有效的手段就是看服务状态和日志：systemctl status能快速定位启动失败原因，组件日志能给出更详细的错误信息。从数据库、消息队列、认证服务到组件本身，逐层排查，绝大多数问题都能快速定位。

这次完整走通四大核心组件的部署和云主机创建，不仅熟悉了OpenStack的组件协作逻辑，更积累了一套通用的排错思路，为后续更复杂的网络和存储组件部署打下了基础。

相关推荐
XUEYUAN521243 分钟前
代理日志分析与监控：代理池健康状态巡检与分级告警体系搭建（运维实战）
运维·网络·网络协议·tcp/ip·算法·架构
guo_wen_qiang1 小时前
mac中iTerm有没有类似xshell远程连接服务器的用户名密码方式，不用每次都要输入用户密码
运维·服务器·macos
往事只能回味味道1 小时前
MySQL创建数据库并授权指导用户与IP
数据库·tcp/ip·mysql
xzl041 小时前
Ubuntu24.04 生产环境 Docker（全国内源）
运维·docker·容器
lajidecrd1 小时前
Ubuntu 24.04 LTS安装
linux·运维·ubuntu
水月清辉1 小时前
MySQL 表分区详解
mysql
沫璃染墨1 小时前
《从零入门Linux系统篇（二十九）：文件篇·二——深入文件描述符：从文件描述符表到重定向，再到Shell实现》
linux·运维·服务器·c++·驱动开发·系统架构
陈年老古董2 小时前
Shell 脚本编程基础完整学习笔记
linux·sql·mysql
竣达技术2 小时前
守护变电站直流 “生命线”｜竣达 BMS‑PRO‑II 智能电池综合管理单元，让蓄电池运维看得见、管得牢
运维·监控系统·机房监控
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02GitHub 镜像站点032026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？04历年考研数学一、数学二、数学三真题试卷及答案PDF05微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新06Agnes AI 免费 API 接入指南：文本、生图、生视频，一套接口全免费07AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路08VSCode+CodeX扩展，无法启动092026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片10如何新建文件夹？ 电脑新建文件夹的4种方法