ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Openstack Havana 安装部署实战:从手册到落地的避坑指南

Openstack Havana 安装部署实战:从手册到落地的避坑指南 简介这份《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 安装前的环境基线检查清单在动手装任何组件之前先把基线打牢。下面这张表是我每次部署前必过的检查项缺一项后面就会以奇怪的方式翻车。检查项要求不满足的后果主机名与 hosts控制/计算节点互相能解析Keystone 认证时 endpoint 解析失败时间同步两节点时间差小于 5 秒Token 频繁失效登录面板被踢SELinux设为 permissive 或关闭Neutron 端口被拦虚拟机拿不到 IP防火墙放行 5672/3306/9292/8774 等服务注册成功但调用超时MySQL 字符集utf8Keystone 建表报字段长度错误RabbitMQ允许 guest 远程或建专用用户Nova 与 Neutron 消息不通时间同步这条最容易被忽略。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 keystonelocalhost IDENTIFIED BY KEYSTONE_DBPASS; GRANT ALL PRIVILEGES ON keystone.* TO keystone% IDENTIFIED BY KEYSTONE_DBPASS; FLUSH PRIVILEGES; exit # 生成管理员 tokenHavana 用 PKI 或 UUID这里用 UUID 简单 export OS_SERVICE_TOKENADMIN_TOKEN export OS_SERVICE_ENDPOINThttp://控制节点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 adminOS_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.htmlmy_ip必须写本机真实 IP写 127.0.0.1 会导致计算节点注册到错误的地址。vncserver_proxyclient_address是 noVNC 代理访问计算节点的地址配错的现象是面板里点控制台打不开。计算节点的nova.conf里my_ip要写计算节点自己的 IPvncserver_listen写0.0.0.0让代理能连上。Nova 装完用nova service-list看各服务是否 upnova-manage db sync建表要在启动服务前执行。4. Neutron 网络与 Cinder 块存储的落地细节4.1 Neutron 三种网络模式的取舍Neutron 是 Havana 部署里最容易翻车的一环因为它同时管二层和三层还牵扯到内核网络命名空间。常见模式有 Flat、VLAN、GRE/VXLAN。Flat 最简单所有虚拟机在一个大二层里适合实验VLAN 需要交换机配合适合有网络团队的环境GRE 隧道不依赖交换机配置但性能有损耗适合纯软件环境。# /etc/neutron/plugins/ml2/ml2_conf.iniHavana 用 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.OVSHybridIptablesFirewallDrivertenant_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 tgtadmvolume_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 对应 9292Neutron 对应 9696Cinder 对应 8776Horizon 是 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 21 echo Keystone OK || { echo Keystone FAIL; exit 1; } # 2. Glance 能否列出镜像 glance image-list /dev/null 21 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 21 echo Neutron OK || { echo Neutron FAIL; exit 1; } # 5. Cinder 能否列出卷 cinder list /dev/null 21 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每次改完配置就跑一遍。再补一个更细的验证真正创建一台虚拟机从镜像启动绑定浮动 IPSSH 登进去。这一步能同时验证 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 手册的价值不在于命令多全而在于它给了一个固定顺序你按顺序走、每步验证就不会在组件依赖里绕晕。希望帮到你。本文还有配套的精品资源点击获取
返回列表