企业官网建设流程全解析

简介：这份《Openstack安装部署手册》面向云计算运维人员、OpenStack初学者及需要搭建私有云环境的技术人员，以Havana版本为基准，系统讲解从零部署IaaS平台的关键流程。资源包内含1个docx文档，大小约519KB，内容以文字步骤与配置说明为主，便于按章节查阅。手册覆盖环境准备、组件整体结构、OpenStack核心包安装、Keystone认证服务、Glance镜像服务等模块，具体涉及网卡配置、主机名修改、MySQL数据库安装、Messaging Server部署，以及Keystone与数据库连接、授权令牌定义、密钥与证书配置、用户租客与roles划分、服务与API endpoint创建等操作要点。读者可据此理清各组件间的依赖关系，掌握认证、镜像、计算、存储与网络服务的部署顺序，并对照配置项完成环境验证与问题排查。目前已有369人学习，适合作为搭建OpenStack云计算平台的实操参考。

1. 从一份 Openstack 安装部署手册说起：Havana 版本为什么至今还有人翻出来装

手里拿到一份《Openstack安装部署手册.docx》，多数人的第一反应是照着敲命令，但真到落地时才发现，手册里默认的网络、存储、认证三块只要有一块和现网对不上，整个云平台就起不来。Openstack 安装部署这件事，难的不是某一条命令，而是组件之间的依赖顺序和参数咬合。Havana 是 Openstack 早期一个被大量内部手册固化的版本，很多单位的内网云、教学实验平台至今还跑着它，原因很直接：组件少、依赖浅、一台控制节点加一台计算节点就能跑通全流程。这篇笔记面向两类人——第一次接触 Openstack 云平台搭建、需要一份能照着复现的落地路径的新手，以及手里有旧手册、想搞清楚每个参数为什么这么设、踩坑点在哪的运维。我会按「先立住原理和选型，再落到命令和配置，最后收在排错和验证」的顺序讲，把一份 docx 手册里最容易含糊过去的地方补厚。

2. Openstack Havana 安装部署的组件选型与最小拓扑

2.1 为什么 Havana 时代的最小架构是「控制+计算」两节点

Havana 版本的 Openstack 把服务拆得很细，但真正跑一个能创建虚拟机的云平台，核心只有六个：Keystone 做认证、Glance 做镜像、Nova 做计算调度、Neutron 做网络、Cinder 做块存储、Horizon 做面板。控制节点承载 Keystone、Glance、Nova 的 API 与调度、Neutron Server、Cinder API 和 Horizon；计算节点只跑 Nova Compute 和 Neutron 的 agent。这种拆分的好处是控制面集中、计算面可横向扩，坏处是所有服务都依赖消息队列和数据库，RabbitMQ 和 MySQL 一旦不稳，整个云平台就是黑匣子，报错信息还特别绕。

选 Havana 而不是更新版本，通常不是技术偏好，而是被现网约束逼的。老硬件的内核版本、Python 2.7 的运行环境、内网无法拉取新包，这些条件决定了只能用手册里那套固定版本。我一般会先确认三件事：操作系统是不是 CentOS 6.x 或 Ubuntu 12.04 这类老底子、Python 是不是 2.7、内网 yum 源里有没有 Havana 的仓库。这三条对不上，后面所有步骤都是白费。

2.2 安装前的环境基线检查清单

在动手装任何组件之前，先把基线打牢。下面这张表是我每次部署前必过的检查项，缺一项后面就会以奇怪的方式翻车。

时间同步这条最容易被忽略。Havana 的 Token 有有效期，两节点时间一漂移，计算节点向控制节点汇报状态时就被判为过期，现象是虚拟机一直卡在 spawning。我见过有人排查了一整天网络，最后发现是计算节点没配 NTP。

2.3 用 packstack 快速验证还是纯手工部署

热搜里常出现「基于 packstack 安装 openstack」，packstack 是 Red Hat 系的一键部署工具，适合快速验证概念，但它对 Havana 的支持有限，且会替你决定大量参数，出问题后不好定位。如果你的目标是产出一份可维护、可对照手册逐项核对的部署，我建议纯手工按组件顺序装。顺序是：先 MySQL 和 RabbitMQ，再 Keystone，然后 Glance、Nova、Neutron、Cinder，最后 Horizon。每装完一个组件就用命令行验证一次，不要攒到最后一起测。

# 以控制节点为例，先装基础依赖 yum install -y mysql-server rabbitmq-server ntp # 启动时间同步，这一步别省 service ntpd start chkconfig ntpd on # 启动消息队列与数据库 service rabbitmq-server start service mysqld start # 给 root 设密码并允许本地登录 mysqladmin -u root password 'openstack'

这段命令做的是打地基。ntpd负责时间同步，rabbitmq-server是组件间通信的总线，mysqld存所有服务的状态数据。参数上，MySQL 的 root 密码后面要写进每个服务的配置文件，建议统一用一个强密码并记牢，改来改去最容易漏改某一处导致服务起不来。RabbitMQ 默认 guest 用户只能本地登录，如果计算节点和控制节点分开，必须新建用户并授权，否则 Nova 在计算节点上连不上队列。

3. Keystone、Glance、Nova 的安装顺序与关键配置

3.1 Keystone 先行的理由与建库建用户命令

Keystone 是 Openstack 的认证入口，所有其他服务都要在它这里注册 endpoint 才能被找到。所以它必须第一个装，而且装完要立刻验证 token 能不能签发。建库、建用户、授权这三步在任何组件上都是固定套路，区别只是库名和用户名。

# 登录 MySQL 建 Keystone 库和用户 mysql -u root -p CREATE DATABASE keystone; GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'localhost' IDENTIFIED BY 'KEYSTONE_DBPASS'; GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'%' IDENTIFIED BY 'KEYSTONE_DBPASS'; FLUSH PRIVILEGES; exit # 生成管理员 token，Havana 用 PKI 或 UUID，这里用 UUID 简单 export OS_SERVICE_TOKEN=ADMIN_TOKEN export OS_SERVICE_ENDPOINT=http://控制节点IP:35357/v2.0 # 建管理员租户、用户、角色 keystone tenant-create --name admin --description "Admin Tenant" keystone user-create --name admin --pass ADMIN_PASS keystone role-create --name admin keystone user-role-add --user admin --tenant admin --role admin

OS_SERVICE_TOKEN是临时管理员令牌，用来在正式认证体系建好之前执行管理命令，装完 Keystone 后就可以弃用。OS_SERVICE_ENDPOINT指向 Keystone 的管理端口 35357。建租户和用户的顺序不能反，角色要最后绑。参数上，ADMIN_PASS后面登录 Horizon 要用，KEYSTONE_DBPASS要写进/etc/keystone/keystone.conf的connection字段。常见错误是%通配授权没做，计算节点上的服务连不上 Keystone 数据库。

3.2 Glance 镜像服务的后端存储选择

Glance 只管镜像的元数据和实际文件存放。后端存储有三种常见选择：本地文件系统、Swift 对象存储、Ceph。Havana 时代最省事的是本地文件系统，适合实验环境；如果要做多计算节点共享镜像，就得用 Swift 或 Ceph，否则每个计算节点都要单独传一份镜像，管理成本高。

# /etc/glance/glance-api.conf 关键片段 [DEFAULT] sql_connection = mysql://glance:GLANCE_DBPASS@控制节点IP/glance [keystone_authtoken] auth_uri = http://控制节点IP:5000 auth_host = 控制节点IP auth_port = 35357 auth_protocol = http admin_tenant_name = service admin_user = glance admin_password = GLANCE_PASS [paste_deploy] flavor = keystone [glance_store] default_store = file filesystem_store_datadir = /var/lib/glance/images/

sql_connection指向 Glance 自己的库，keystone_authtoken段是向 Keystone 证明身份，default_store = file表示镜像存本地磁盘。filesystem_store_datadir目录要提前建好并给 glance 用户写权限，否则上传镜像时报权限拒绝。上传镜像用glance image-create，注意--disk-format和--container-format要和镜像实际格式一致，qcow2 镜像写成 raw 会导致虚拟机起不来。

3.3 Nova 计算服务的数据库、队列与 API 配置

Nova 是组件最多的一块，控制节点上要装 nova-api、nova-scheduler、nova-conductor、nova-cert，计算节点上装 nova-compute。配置文件的公共段包括数据库连接、RabbitMQ 连接、Keystone 认证，计算节点额外要配vncserver_listen和虚拟化类型。

# /etc/nova/nova.conf 控制节点关键片段 [DEFAULT] sql_connection = mysql://nova:NOVA_DBPASS@控制节点IP/nova rabbit_host = 控制节点IP rabbit_userid = openstack rabbit_password = RABBIT_PASS auth_strategy = keystone my_ip = 控制节点IP vnc_enabled = True vncserver_listen = 0.0.0.0 vncserver_proxyclient_address = 控制节点IP novncproxy_base_url = http://控制节点IP:6080/vnc_auto.html

my_ip必须写本机真实 IP，写 127.0.0.1 会导致计算节点注册到错误的地址。vncserver_proxyclient_address是 noVNC 代理访问计算节点的地址，配错的现象是面板里点控制台打不开。计算节点的nova.conf里my_ip要写计算节点自己的 IP，vncserver_listen写0.0.0.0让代理能连上。Nova 装完用nova service-list看各服务是否 up，nova-manage db sync建表要在启动服务前执行。

4. Neutron 网络与 Cinder 块存储的落地细节

4.1 Neutron 三种网络模式的取舍

Neutron 是 Havana 部署里最容易翻车的一环，因为它同时管二层和三层，还牵扯到内核网络命名空间。常见模式有 Flat、VLAN、GRE/VXLAN。Flat 最简单，所有虚拟机在一个大二层里，适合实验；VLAN 需要交换机配合，适合有网络团队的环境；GRE 隧道不依赖交换机配置，但性能有损耗，适合纯软件环境。

# /etc/neutron/plugins/ml2/ml2_conf.ini（Havana 用 openvswitch 插件） [ml2] tenant_network_types = gre type_drivers = gre [ml2_type_gre] tunnel_id_ranges = 1:1000 [ovs] local_ip = 计算节点隧道IP tunnel_type = gre enable_tunneling = True [securitygroup] firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

tenant_network_types决定租户网络用什么隔离，tunnel_id_ranges是隧道 ID 池，local_ip是隧道端点地址，必须两节点互通。firewall_driver配错会导致安全组规则不生效，虚拟机端口全开或全封。Neutron 装完要建外部网络和租户网络，外部网络对应物理网卡，租户网络走隧道，最后建路由把两者连起来。

4.2 Cinder 块存储的 LVM 后端配置

Cinder 给虚拟机提供持久化磁盘。实验环境最常用 LVM 后端，因为不需要额外硬件。先在计算或存储节点上划一个卷组，比如cinder-volumes，然后配置 Cinder 使用它。

# 建物理卷和卷组 pvcreate /dev/sdb vgcreate cinder-volumes /dev/sdb # 配置 /etc/cinder/cinder.conf # [DEFAULT] # volume_group = cinder-volumes # volume_driver = cinder.volume.drivers.lvm.LVMISCSIDriver # iscsi_helper = tgtadm

volume_group要和实际卷组名一致，volume_driver指定 LVM 驱动，iscsi_helper在 Havana 上常用 tgtadm。Cinder 服务启动后，用cinder create --display-name test 1建一个 1G 卷，能建成功说明后端通了。挂载到虚拟机时如果卡住，先查 iSCSI 服务是否启动、防火墙是否放行 3260 端口。

4.3 组件注册与 endpoint 的对应关系

每个服务装完都要在 Keystone 里注册 service 和 endpoint，否则其他组件找不到它。注册时要注意 public、internal、admin 三个 URL 的区别：public 给外部访问，internal 给组件间调用，admin 给管理操作。实验环境三者可以都写控制节点 IP，但端口不能错。

# 以 Nova 为例注册 service 和 endpoint keystone service-create --name nova --type compute --description "OpenStack Compute" keystone endpoint-create \ --service-id $(keystone service-list | awk '/ compute / {print $2}') \ --publicurl http://控制节点IP:8774/v2/%\(tenant_id\)s \ --internalurl http://控制节点IP:8774/v2/%\(tenant_id\)s \ --adminurl http://控制节点IP:8774/v2/%\(tenant_id\)s

%\(tenant_id\)s是占位符，Keystone 会替换成实际租户 ID，写错会导致 API 调用 404。service-id用命令动态取，避免手抄出错。Glance 对应 9292，Neutron 对应 9696，Cinder 对应 8776，Horizon 是 80 或 443，端口对不上是 endpoint 注册最常见的错误。

5. Openstack 安装部署避坑：五条血泪排查记录

5.1 现象：Keystone 能启动但登录报 401

原因通常是数据库里没建表，或者keystone.conf里的connection密码和实际不符。Havana 的 Keystone 需要先keystone-manage db_sync建表，再启动服务。解决方法是停掉服务，确认数据库连接串，重新 sync，再启动。如果 sync 报字符集错误，检查 MySQL 建库时有没有指定 utf8。

5.2 现象：虚拟机一直卡在 spawning

先看nova service-list里 nova-compute 是不是 up。如果 down，多半是计算节点连不上 RabbitMQ 或 Keystone。检查计算节点nova.conf里的rabbit_host和auth_uri是否指向控制节点真实 IP，防火墙是否放行 5672 和 5000。如果服务 up 但虚拟机仍卡住，看/var/log/nova/nova-compute.log，常见是镜像格式不匹配或存储空间不足。

5.3 现象：虚拟机拿到 IP 但 ping 不通外网

这是 Neutron 路由和 NAT 没配好。检查租户路由有没有连到外部网络，外部网络的网关有没有设对，控制节点的ip_forward有没有开。Havana 用命名空间隔离路由，用ip netns list能看到 qrouter 命名空间，进去ip route看路由表。如果路由对但还不通，查 iptables 的 nat 表有没有 MASQUERADE 规则。

5.4 现象：Horizon 面板能登录但报内部错误

多半是local_settings.py里的 Keystone 地址或 memcached 配置不对。Havana 的 Horizon 依赖 memcached 存会话，memcached 没启动会导致登录后立刻掉线。检查/etc/openstack-dashboard/local_settings.py里的OPENSTACK_HOST和CACHES段，确认 memcached 服务在跑。

5.5 现象：Cinder 卷创建成功但挂载失败

先确认计算节点上的 iSCSI 发起端服务启动了，iscsiadm -m discovery能发现目标。如果发现不了，查存储节点的 tgtadm 服务是否启动、3260 端口是否放行。挂载失败还可能是卷组空间不足，vgs看剩余空间。Havana 的 Cinder 对并发挂载支持弱，同一卷挂两台虚拟机容易出问题，实验时避免这种操作。

6. 用一套验证脚本把 Havana 部署结果钉死

装完不等于装对，我习惯在最后跑一套验证脚本，把每个组件的关键接口都打一遍，避免交付后才发现某个服务是假活。下面这段脚本按顺序验证 Keystone、Glance、Nova、Neutron、Cinder，任何一步失败就停，方便定位。

#!/bin/bash # 加载管理员环境变量 source /root/admin-openrc.sh # 1. Keystone 能否签发 token keystone token-get > /dev/null 2>&1 && echo "Keystone OK" || { echo "Keystone FAIL"; exit 1; } # 2. Glance 能否列出镜像 glance image-list > /dev/null 2>&1 && echo "Glance OK" || { echo "Glance FAIL"; exit 1; } # 3. Nova 各服务是否 up nova service-list | grep -q "down" && { echo "Nova service DOWN"; exit 1; } || echo "Nova OK" # 4. Neutron 能否列出网络 neutron net-list > /dev/null 2>&1 && echo "Neutron OK" || { echo "Neutron FAIL"; exit 1; } # 5. Cinder 能否列出卷 cinder list > /dev/null 2>&1 && echo "Cinder OK" || { echo "Cinder FAIL"; exit 1; }

admin-openrc.sh里要设好OS_TENANT_NAME、OS_USERNAME、OS_PASSWORD、OS_AUTH_URL，这是所有命令的前提。脚本里用grep -q "down"判断 Nova 服务状态，是因为nova service-list即使有服务 down 也返回 0，必须看输出内容。这套脚本我一般放在/root/verify_openstack.sh，每次改完配置就跑一遍。

再补一个更细的验证：真正创建一台虚拟机，从镜像启动，绑定浮动 IP，SSH 登进去。这一步能同时验证 Glance、Nova、Neutron、Cinder 四条链路。命令是nova boot --flavor 1 --image 镜像ID --nic net-id=网络ID 测试机，然后nova list看状态，neutron floatingip-create绑浮动 IP。如果虚拟机起来但 SSH 不通，查安全组有没有放行 22 端口，这是新手最常漏的一步。

我自己的习惯是：每装完一个组件就在手册对应章节旁边打勾，并记下实际用的密码和 IP，因为 Havana 的配置文件分散在七八个目录，过一周再回来改，光找密码就能找半天。这份 docx 手册的价值不在于命令多全，而在于它给了一个固定顺序，你按顺序走、每步验证，就不会在组件依赖里绕晕。希望帮到你。

本文还有配套的精品资源，点击获取