简介基于OpenStack的企业私有云设计与部署完整方案面向云计算架构师、运维工程师及高校相关专业学生针对传统数据中心采购服务器、网络、存储等大量设备导致资源利用率低、自动化程度不高等痛点提供从规划设计到落地部署的参考路径。压缩包内包含1个doc文档大小2.23MB内容围绕云计算与虚拟化技术、OpenStack核心组件Nova、Swift、Neutron、Keystone展开系统讲解私有云平台的总体架构和构建流程。文档重点覆盖ceph存储后端集成、网络架构设计、负载均衡、虚拟机动态迁移、数据库备份计划等企业落地关键环节并给出完整的设计思路、部署过程及对私有云发展的建议。文档还包含中英文摘要、关键词和清晰章节安排适合按模块学习。目前已有262人学习可作为企业私有云入门、技术选型及项目实施前的参考资料。1. 基于 OpenStack 的私有云方案从论文到真机的落地边界毕业论文里那套基于 OpenStack 企业私有云的设计与部署方案答辩现场看着天衣无缝真拉到真机上照着敲前两周基本都是翻车现场。镜像上传了却起不来实例、数据库集群莫名其妙脑裂、虚拟机一迁移就直接卡死这些都是我当年在 Ceph 对接和三节点高可用上踩过的坑。这份资源的价值在于把 OpenStack 云平台搭建从能用推到可用三控制节点做高可用、Ceph 做统一存储后端、Neutron 管租户网络、HAProxy 扛流量入口最后落到热迁移和数据库备份的验证上。它适合两类人一是做私有云毕设的学生需要一套能写进论文又能跑通的完整架构二是企业里想用开源方案替代商业虚拟化、又不想一上来就上 K8s 的运维这份方案能帮你把边界摸清楚少走弯路。2. 选型与网络拓扑为什么是三控制节点加 Ceph2.1 为什么是 OpenStack 而不是 CloudStack私有云的技术选型市面上主流是 OpenStack 和 VMware 两条线。VMware 的虚拟化稳定性和生态工具确实领先动态迁移和高可用都是开箱即用但商业授权的成本对小团队不友好。OpenStack 是 IaaS 开源方案里社区最活跃的华为、深信服的公有云都有基于它二次开发的影子这意味着招人容易、踩坑资料多、遇到问题能搜到同类案例。CloudStack 虽然部署更轻但组件划分不如 OpenStack 清晰存储后端对接这块也明显偏弱。对于企业私有云这个场景选 OpenStack 长远看投入产出比更划算这也是这份方案选择它的核心理由。2.2 节点角色与硬件资源预算这套方案一共用了 7 台虚拟机角色分配非常明确如表 2-1 所示。控制节点要跑数据库、消息队列和各种 API 服务内存和磁盘不能省计算节点跑实例CPU 资源要留足存储节点单独部署 Ceph MON 和 MGR不掺和计算业务。如果你只是实验环境可以把存储节点合并到控制节点上但生产环境别这么干Ceph 的 MON 和 OSD 混布会互相抢资源出问题的时候排障特别被动。表 2-1 节点角色与建议配置节点角色数量网卡部署组件建议配置控制节点3三张MariaDB Galera、HAProxy、Keystone、Glance、Nova、Neutron、Horizon、Cinder8C/16G/200G计算节点3双网卡nova-compute、neutron-ovs-agent、ceph-osd16C/32G/500G存储节点1双网卡ceph-mon、ceph-mgr4C/8G/200G组件版本要提前锁死OpenStack Rocky、Ceph Luminous 12.2.12、CentOS 7.7.1908 这套组合我在部署时验证过能正常对接。版本混搭是大忌比如你用 Train 版 OpenStack 去对接 Luminous 的 CephRBD 的兼容性就会出幺蛾子。另外三台控制节点如果计划用 virtualization 跑CPU 一定要开同型号透传否则后面热迁移会直接翻车这个细节我后面会专门讲。2.3 网络规划管理网、租户网、外部网三网分离网络设计是整个私有云的地基三张网各司其职不要图省事合并。管理网走 Keystone、Nova 等组件的 API 通信租户网走 vxlan 或 gre 隧道让虚拟机互访外部网负责让租户访问 Internet。表 2-2 是这套方案的网段规划你直接用或者按自己机房网段改都行。表 2-2 网段规划网络用途网段说明管理网192.168.10.0/24集群内部 API、数据库同步、消息队列通信租户网10.10.10.0/24虚拟机间数据通信vxlan/gre 隧道外部网192.168.15.0/24提供外网访问能力浮动 IP 池管理网我建议你单独划 VLAN别跟办公网混在一起。之前有人把管理网直接丢在办公网段里Keystone 的共享服务端口被扫描爆破数据库被删了两次最后只恢复了一半。这不是玄学是安全边界没守住。2.4 环境初始化hosts、SSH 免密与时间同步的先后顺序初始化环境的顺序应该是 hosts → SSH 免密 → 时间同步先后搞反了后面每步都别扭。hosts 文件把所有节点的 IP 和主机名对应关系写好这样 OpenStack 各服务间通信解析主机名时不会走 DNS减少一层故障点。# 在所有节点上编辑 /etc/hosts追加以下内容 vim /etc/hosts 192.168.10.21 controller1 192.168.10.22 controller2 192.168.10.23 controller3 192.168.10.20 VirtualIP 192.168.10.24 mon01 192.168.10.19 computer1 192.168.10.18 computer2 192.168.10.17 computer3hosts 写完先 ping 一轮主机名确认能通再进行下一步。注意 VirtualIP 也要写进 hosts因为 HAProxy 的 VIP 后面要作为 Keystone 的 endpoint 地址主机名解析不一致会导致认证请求偶发性 502。# 在 controller1 上生成密钥并分发到所有节点 ssh-keygen -t rsa -N -f /root/.ssh/id_rsa ssh-copy-id controller1 ssh-copy-id controller2 ssh-copy-id controller3 ssh-copy-id mon01 ssh-copy-id computer1 ssh-copy-id computer2 ssh-copy-id computer3这里有个参数细节-N 表示空口令-f指定生成的密钥文件路径。如果改成带口令的密钥后续所有自动化脚本执行时都要交互输密码操作系统定时任务和 OpenStack 服务间的远程调用会被卡住集群高可用等于白搭。# 安装 chrony 并配置时间同步在 controller1 上执行 yum install chrony -y cat /etc/chrony.conf EOF server 192.168.10.21 iburst allow 192.168.10.0/24 local stratum 10 EOF systemctl enable chronyd --now # 其余节点把 server 指向 controller1时间同步必须放在部署 OpenStack 之前做完因为 Keystone 的 token 有效期依赖时间戳节点间时间偏差超过两分钟认证服务就会间歇性报 401。我见过最隐蔽的情况是只有个别节点慢了几十秒管理网里 API 请求成功率在 80% 左右波动查了两小时才定位到是时钟漂移。common 做法是让控制节点做时间源其他节点同步它生产环境最好再对一层公网 NTP。3. 高可用基础层Galera 集群与 HAProxy 的部署顺序3.1 为什么先搭数据库和负载均衡OpenStack 所有组件的状态都写在数据库里数据库一挂控制面全线瘫痪。单节点 MariaDB 在后端 API 并发上来时扛不住而且存在单点故障所以这套方案用了 MariaDB Galera 集群做多主同步复制。多个节点都能读写任何一个节点宕机不影响其他节点继续服务。Galera 的同步复制机制听着很美好但配置顺序有讲究先起第一个节点初始化集群再依次加入其他节点顺序反了会把整个集群搞成脑裂。3.2 MariaDB Galera 集群安装配置三个控制节点都要装装完后第一个节点先启动初始化。Galera 底层的认证还是走 MySQL 用户体系所以需要先把 root 用户密码和同步用户准备好。# 三个控制节点都执行安装内核依赖与 MariaDB yum install -y mariadb-server mariadb-client galera pymysql # 配置 /etc/my.cnf.d/galera.cnf vim /etc/my.cnf.d/galera.cnf[mysqld] binlog_formatROW default-storage-engineinnodb innodb_autoinc_lock_mode2 innodb_flush_log_at_trx_commit0 query_cache_size0 query_cache_type0 bind-address0.0.0.0 wsrep_provider/usr/lib64/galera/libgalera_smm.so wsrep_cluster_addressgcomm://192.168.10.21,192.168.10.22,192.168.10.23 wsrep_cluster_nameopenstack_cluster wsrep_node_namecontroller1 wsrep_node_address192.168.10.21 wsrep_sst_methodrsyncbinlog_formatROW是硬性要求Galera 只有基于行复制才能保证多主写入不冲突。innodb_autoinc_lock_mode2是为了避免多节点并发插入时自增主键的锁竞争。wsrep_sst_methodrsync表示节点加入时通过 rsync 做全量同步小集群够用。第一个节点启动时要用galera_new_cluster后续节点用systemctl start mariadb正常加入即可这一点特别容易记混。# 节点1初始化集群 galera_new_cluster # 节点2、节点3正常启动即可 systemctl start mariadb systemctl enable mariadb3.3 HAProxy 配置VIP、健康检查与后端池数据库集群就绪后OpenStack 各种 API 的入口还需要一个统一负载均衡。HAProxy 部署在三个控制节点上提供一个 192.168.10.20 的虚拟 IP前端用 VIP 接请求后端把流量分发到三个节点的对应服务端口。核心配置段如下vim /etc/haproxy/haproxy.cfgfrontend openstack_api bind 192.168.10.20:5000 default_backend keystone_servers backend keystone_servers balance roundrobin option httpchk GET /v3 server controller1 192.168.10.21:5000 check inter 3s fall 3 rise 2 server controller2 192.168.10.22:5000 check inter 3s fall 3 rise 2 server controller3 192.168.10.23:5000 check inter 3s fall 3 rise 2 listen mysql_cluster bind 192.168.10.20:3306 mode tcp balance leastconn server controller1 192.168.10.21:3306 check inter 5s server controller2 192.168.10.22:3306 check inter 5s server controller3 192.168.10.23:3306 check inter 5shttpchk GET /v3是让 HAProxy 用 HTTP 探活 Keystone 的 API 版本端点比 TCP 四层检测更真实。fall 3 rise 2表示连续 3 次失败判定宕机连续 2 次成功判定恢复这个参数不要调得太灵敏否则网络抖动会把节点误杀出池反过来频繁切换也会让 API 服务端日志刷屏。mysql 走mode tcp四层转发因为 MySQL 协议 HTTP 探活不适用这里用端口连通性判断就够了。3.4 验证 Galera 集群同步状态集群搭完先别急着往下走登录任意节点查一下同步状态确认数据复制真正生效再继续。mysql -uroot -p -e SHOW STATUS LIKE wsrep%\G重点看三个值wsrep_cluster_size是否为 3wsrep_local_state_comment是否为 Syncedwsrep_connected是否为 ON。如果大小不是 3说明有节点没加入成功去对应机器看/var/lib/mysql目录里有没有*.err日志。这里还有个小坑当初我在节点 2 上反复启动失败看日志是 SST 认证失败原因是节点 1 上没创建 SST 用的数据库用户手动补上后重试才解决。4. 核心服务部署Keystone、Glance、Nova、Neutron 的衔接细节4.1 Keystone认证服务的三个关键步骤Keystone 是整个 OpenStack 的注册表和认证中心其他组件所有请求都先过它这一关。部署要点是建库、装包、生成配置、初始化数据、建域和项目。先建库和用户# 在控制节点上用 root 进入数据库创建 keystone 库 mysql -uroot -p CREATE DATABASE keystone; GRANT ALL PRIVILEGES ON keystone.* TO keystonelocalhost IDENTIFIED BY keystone_pwd; GRANT ALL PRIVILEGES ON keystone.* TO keystone% IDENTIFIED BY keystone_pwd;创建域、项目、用户和角色才是真正决定认证链路是否通的关键。openstack domain create --description Default Domain default openstack project create --domain default --description Service Project service openstack user create --domain default --password glance_pwd glance openstack role add --project service --user glance admin openstack service create --name glance --description OpenStack Image image openstack endpoint create --region RegionOne image public http://192.168.10.20:9292 openstack endpoint create --region RegionOne image internal http://192.168.10.20:9292 openstack endpoint create --region RegionOne image admin http://192.168.10.20:9292注意所有 endpoint 的地址都用 VIP 192.168.10.20而不是某个具体控制节点。你如果写成了 controller1 的地址HAProxy 漂移时客户端缓存的老地址全失效只能清浏览器缓存和 OpenStack client 的 token 重来这个后悔药不好吃。4.2 Glance镜像服务与本地后端配置Glance 负责管理镜像控制节点装openstack-glance-api和openstack-glance-registry。配置文件是/etc/glance/glance-api.conf重点改[database]和[glance_store]段。[database] connection mysqlpymysql://glance:glance_pwd192.168.10.20/glance [glance_store] stores file,http default_store file filesystem_store_datadir /var/lib/glance/images/default_storefile表示镜像先存在本地磁盘等后面 Ceph 集群就绪后再切到 RBD 后端。我自己实践时是先把文件后端跑通再逐步迁移到 Ceph这样能减少变量排错范围更小。配好后初始化数据库并上传一个测试镜像su -s /bin/sh -c glance-manage db_sync glance systemctl enable openstack-glance-api openstack-glance-registry systemctl restart openstack-glance-api openstack-glance-registry # 下载最小化测试镜像并上传 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 qcow2是云主机的镜像格式--container-format bare表示镜像文件本身就是裸的磁盘镜像没有用容器格式打包。上传后务必执行openstack image list确认状态是 active不要急着创建实例等 Nova 就绪再联调。4.3 Nova控制节点与计算节点的分工Nova 组件分两层控制节点跑nova-api、nova-scheduler、nova-conductor负责接收请求、调度、写数据库计算节点只跑nova-compute真正干活。控制节点的/etc/nova/nova.conf关键配置如下[DEFAULT] transport_url rabbit://openstack:rabbit_pwd192.168.10.20 my_ip 192.168.10.21 use_neutron True firewall_driver nova.virt.firewall.NoopFirewallDriver [api_database] connection mysqlpymysql://nova:novapwd192.168.10.20/nova_api [database] connection mysqlpymysql://nova:nova_pwd192.168.10.20/nova [vnc] enabled true novncproxy_base_url http://192.168.10.20:6080/vnc_auto.html [libvirt] virt_type kvm cpu_mode host-modeltransport_url里 192.168.10.20 是 RabbitMQ 的 VIP三条队列通信都走它。cpu_modehost-model这个参数必须钉死它让虚拟机继承物理机 CPU 型号特性否则热迁移到另一台物理机时指令集不兼容虚拟机会直接启动失败或者运行到一半报非法指令直接崩溃。firewall_driver设成 NoopFirewallDriver 是因为安全组规则由 Neutron 的 OVS 来实施Nova 这边不再叠加一层 iptables避免规则冲突。计算节点的nova.conf只需要配数据库连接、消息队列和my_ip指向自己再启动 nova-compute 服务即可。这里容易忽略的是计算节点上要装openstack-nova-compute和libvirt装完确认/dev/kvm存在否则 nova-compute 起不来。可以用下面的命令验证计算节点是否注册成功openstack compute service list状态列必须是 enabled 和 up对应计算节点出现在列表中才说明 Nova 集群健康。4.4 Neutron网络服务与 OVS agent 的配合Neutron 负责给虚拟机和租户提供网络能力控制节点装openstack-neutron-server计算节点装openstack-neutron-openvswitch-agent。控制节点配置 ML2 插件租户网络类型用 vxlan配置文件/etc/neutron/plugins/ml2/ml2_conf.ini[ml2] type_drivers flat,vlan,vxlan tenant_network_types vxlan mechanism_drivers openvswitch,l2population [ml2_type_vxlan] vni_ranges 1001:2000tenant_network_typesvxlan表示租户网络用 VXLAN 隧道隔离vni_ranges 是隧道 ID 段同一物理网络里不能和其他集群冲突。mechanism_drivers里加上l2population可以在计算节点间建立直连 ARP 表项避免广播风暴。计算节点的 OVS agent 需要把本地 IP 隧道端点配置正确vim /etc/neutron/plugins/ml2/openvswitch_agent.ini[ovs] local_ip 192.168.10.19 bridge_mappings external:br-ex [agent] tunnel_types vxlanlocal_ip填的是计算节点自己的管理网 IPVXLAN 隧道用这个 IP 进行封装和解封装。bridge_mappings只在需要桥接外部网络的节点上配置纯计算节点可以不写这一段。我遇到的一个典型翻车是 local_ip 写成了租户网段地址结果控制节点 ping 不通隧道端点的 UDP 4789 端口所有跨节点的虚拟机之间通信全部超时排查到 OVS 的 tunnel 端口一直是 DOWN。4.5 Horizon 与 CinderWeb 入口与块存储Horizon 是给用户和管理员用的 Web 界面安装很简单装完直接访问http://192.168.10.20/dashboard配置里指定 Keystone 的 VIP 即可。Cinder 负责块存储控制节点装openstack-cinder-api、openstack-cinder-scheduler存储节点或计算节点装openstack-cinder-volume。Cinder 这层我们下面接入 Ceph 后统一讲存储对接这里先不展开。5. 部署避坑与常见问题五条血泪踩坑记录5.1 实例创建一直卡在 BUILD 状态现象用后台创建虚拟机状态永远是 BUILD几分钟后直接 ERROR。 原因排错时第一反应是查 Nova 日志发现 nova-compute 报 libvirt 连接失败。实际原因是计算节点的 libvirtd 没有启动或者/dev/kvm设备不存在。在虚拟机套虚拟机的嵌套场景里KVM 嵌套没开libvirt 就会退化为 QEMU 模拟性能差且部分实例规格会创建失败。 解决先检查systemctl status libvirtd再查看/dev/kvm如果是嵌套虚拟机在宿主机 CPU 虚拟化设置里勾选向客户机操作系统公开硬件辅助虚拟化。这个问题最容易在 OpenStack 云平台搭建的早期阶段出现因为大家都在自己的笔记本上用 VMware 或 VirtualBox 跑实验环境。5.2 热迁移后虚拟机内部网络卡死现象执行openstack server migrate之后虚拟机 ping 不通了但控制台能登录看起来系统还在运行。 原因两个计算节点的 CPU 型号不一致虚拟机的 CPU 特性在迁移后丢失了一部分导致 guest 内核里的 vmxnet3 或 virtio-net 驱动异常。更深层的原因是 nova.conf 里没配cpu_modehost-model默认用的none模式。 解决把源和目的计算节点的 libvirt cpu_mode 统一改成 host-model并保证两台物理机的 CPU 微码版本不要差太多。改完后要systemctl restart libvirtd和nova-compute然后把原虚拟机冷迁移过去重新拉起。这个坑我在三节点集群里反复踩后来凡是涉及热迁移的节点装系统前先比对了/proc/cpuinfo的 flags。5.3 Keystone 偶发 401 认证失败现象命令行执行openstack token issue偶尔能通偶尔报 401 Unauthorized且报错时间完全无规律。 原因检查各控制节点的时间发现 controller2 的系统时间比 controller1 慢了 40 多秒。Keystone token 的有效期是以签发节点的系统时间为准校验节点时间差太大token 直接被判定过期。 解决把全部节点的 chrony 配置重做一遍所有节点统一指向 controller1 作为时间源并增加maxdistance参数限制时钟漂移范围。从那以后我每次排查 OpenStack 认证问题第一步永远是date对比所有控制节点时间这已经成肌肉记忆了。5.4 Cinder 创建卷报 no valid backend 错误现象Horizon 里创建卷一直报no valid cinder service is available或者直接提示后端不可用。 原因cinder-volume 进程没有正常注册到 cinder-scheduler最常见的原因是存储节点上 cinder.conf 里enabled_backends配置错了名字跟[lvm]或者[ceph]段的段名对不上。 解决先执行openstack volume service list看 cinder-volume 在不在列表里不在就检查日志/var/log/cinder/cinder-volume.log重点看enabled_backends和配置段的对应关系。我排查过一次类似问题最后发现是存储节点 hosts 里没配 mon01 的主机名解析cinder-volume 连数据库都连不上更别提上报状态了。这类存储后端相关的问题往往不是组件本身坏而是网络解析和配置名对不上黑匣子式的排障只会让人更绝望还是按日志一层层来。5.5 Horizon 能登录但看不到任何项目信息现象浏览器能打开登录页也能通过认证但进入后所有资源列表都是空的切换项目也看不到。 原因不是服务挂了是 keystone 的 role 分配不对。用域名登录时用户没有被加入到 default 域下的 demo 项目或者角色不对。 解决执行openstack role add --project demo --user admin admin把用户绑定到项目和角色上绑定完在 Horizon 右上角切换项目。这类问题在文档化的设计里往往被省略但实际部署时它直接决定了 Web 界面能不能看到资源排查时比看日志更快的方法是直接查 keystone 的 assignment。6. 平台验证清单从创建实例到热迁移的完整验收部署完成不等于平台可用要按生产标准完整走一遍验收流程。先创建租户网络、子网和路由器再拉起两台实例验证东西向流量最后做热迁移和故障切换测试。# 创建租户网络与子网 openstack network create demo-net openstack subnet create --network demo-net --subnet-range 10.10.10.0/24 --gateway 10.10.10.1 demo-subnet # 创建路由并接入外部网络 openstack router create demo-router openstack router set --external-gateway public demo-router openstack router add subnet demo-router demo-subnet # 创建两台测试实例 openstack server create --flavor m1.small --image cirros --network demo-net --key-name mykey server-1 openstack server create --flavor m1.small --image cirros --network demo-net --key-name mykey server-2 # 验证热迁移 openstack server migrate server-1 --live openstack server show server-1 openstack server list --host computer2 --long热迁移执行后检查虚拟机状态是否回落到 ACTIVE然后从迁移前的源计算节点和迁移后的目标计算节点分别 ping 虚拟机 IP。迁移过程中网络中断时间如果能控制在 2 秒内说明网络配置没问题。接着做高可用切换验证在其中一个控制节点上执行systemctl stop haproxy和systemctl stop mariadb然后持续调用openstack server list正常情况下 API 仍能响应只是请求延迟会略有上升。表 6-1 验收项与通过标准验收项通过标准创建实例3 分钟内完成 BUILD 到 ACTIVE跨节点虚拟机互访ping 通延迟小于 2ms热迁移虚拟机 IP 不中断内部服务不重启控制节点故障切换API 请求持续可用数据库备份恢复从备份恢复到新库可正常读写这套验证做完私有云才算真正可以交给业务方使用。我在这个项目里最深的教训是任何一步都要留记录从数据库的备份计划到每台机器的 hosts 变更日志全都要落在文档里。OpenStack 这种多组件系统出问题时信息熵太高没有记录就只能靠猜那是最痛苦的排障方式。从那以后我每次部署新环境都会强制走一遍这个验收清单先把测试结果拍照存档再开始调优。希望这份设计和部署笔记能帮你在搭建私有云的路上少摔几跤。本文还有配套的精品资源点击获取