1. 为什么我选 ZStack 来搭私有云:先看看它和其他方案的差别
先说说我自己的情况。我之前负责过公司内部的一套测试环境,里面跑着各种开发分支、自动化测试的虚拟机,还有一堆临时性的数据库实例。最早用的是直接在物理机上装 VMware ESXi,几台机器各自为政,虚拟机到处乱放,资源闲置率很高,后来想统一纳管,又试过 OpenStack,结果被它的部署复杂度劝退了。最后之所以选定 ZStack,是因为它在这两个极端之间找到了一个特别务实的平衡点。
ZStack 的核心思路可以理解为"把复杂的东西包装成简单的样子"。它保留了虚拟化该有的能力——计算虚拟化、块存储、对象存储、网络虚拟化、VPC 隔离、多云管理——但底层不再要求你精通一堆互相独立的组件。整朵云可以理解成一个单元化架构:所有核心服务都集中在一套管理进程里,计算节点上只跑轻量的 Agent,管理节点挂了可以再有备用,数据不丢。相比 OpenStack 那种"一个模块一个服务、要单独装十几个组件"的玩法,ZStack 更像是一台"私有云一体机"。
我建议你在动手之前先想清楚一个现实问题:你搭这朵私有云,是为了解决什么?如果只是想在一台服务器上跑几个虚拟机,那确实没必要上 ZStack,用 KVM 或者 Proxmox VE 就够。但如果你要面对的是多台物理机、需要统一管理镜像和网络、希望开发环境和生产环境能隔离、并且不想被某个厂商的授权费用绑死,那 ZStack 就是很合适的选项。它有免费版,也有商业版,社区很活跃,中文文档做得也到位,遇到问题不至于没处问。
市面上类似的方案里,最容易拿来对比的是 VMware vSphere 和 OpenStack。VMware 的优势是稳定、生态成熟,但价格不便宜,而且对硬件兼容性有严格限制;OpenStack 的优势是开源、灵活,但运维门槛高,对小团队很不友好。ZStack 走的是中间路线,它更像是一个"开箱即用的企业管理平台",底层虽然是开源的 KVM、QEMU 这些技术,但你已经不需要直接去跟它们打交道。
如果你团队里只有一两个懂 Linux 基础的人,又想快速把云环境跑起来,那 ZStack 确实值得试试。
2. 部署前最容易踩的坑:硬件规划、系统选型和"超融合"到底怎么选
很多教程上来就让你下载镜像、点下一步,但实际踩过坑的人都知道,部署 ZStack 之前最关键的不是软件本身,而是硬件和架构规划。这一步没想清楚,后面你装好了也会发现 CPU 不够、存储盘位尴尬、网络拓扑没法改,到头来还得重新来过。
2.1 管理节点和计算节点,角色先分清楚
ZStack 的部署模式可以分成两类:一类是"一体化"部署,也就是管理节点和计算节点装在同一台物理机上,适合测试环境、边缘节点、或者中小型公司的起步阶段;另一类是"分离式"部署,管理节点单独一套机器,计算节点另外几台。分离式的好处是管理节点出问题不会连累虚拟机运行,适合生产环境。
先说管理节点的配置要求。ZStack 官方给的最低要求是双核 CPU、4GB 内存,但我要说的是,这只是"能跑起来"的底线。实际使用中,管理节点要承担 API 请求、调度、数据库、消息队列这些工作,如果虚拟机数量超过 50 台,建议至少 8GB 内存、四核 CPU,磁盘用 SSD,预留 100GB 以上空间。管理节点不用跑虚拟机,所以对 CPU 的主频要求不高,但内存和磁盘不能省。
计算节点才是真正跑虚拟机的地方。CPU 必须支持硬件虚拟化(Intel VT-x 或 AMD-V),这个大多数服务器都满足,但要注意 BIOS 里有没有开启。内存建议至少 16GB 起步,如果计划跑数据库类虚拟机,32GB 会更从容。磁盘方面,如果你的存储方案是"本地存储",那计算节点上要多配几块大容量硬盘,而且最好是 RAID 卡支持直通模式(JBOD),这样 ZStack 能直接管理物理磁盘,做本地存储池。
这里我要重点提一下"超融合"这个词。ZStack 的超融合模式指的是在计算节点本地多块盘上做 RAID 或者直通,然后通过软件把多台计算节点的本地盘聚合成一个分布式存储池。它和"管理节点 + 计算节点"分离式部署是两回事。超融合的好处是存储随计算线性扩展,不用单独买存储阵列,坏处是节点故障时数据恢复依赖网络和磁盘性能。我的建议是:测试环境直接用一体化部署 + 本地存储,生产环境优先考虑计算节点本地盘 + 分布式存储,管理节点独立出来。
2.2 网络规划是最容易忽略的环节
ZStack 对网络的要求其实不复杂,但很多人因为局域网里有多台交换机、VLAN 划分不清晰,导致后面创建网络时一脸懵。做规划时只需要明确三件事。
第一,网卡怎么分配。生产环境建议至少四块物理网卡:一块用于管理网络(管理节点和计算节点通信),一块用于云平台业务网络(虚拟机流量),另外两块做备用或者做网卡绑定。如果硬件有限,可以用两块的方案,但一定要把这俩网卡接到不同的交换机上,避免单点故障。测试环境一块网卡也能跑,就是性能和安全性差点意思。
第二,VLAN 和 IP 段怎么规划。ZStack 支持扁平网络和 VPC 网络,VPC 网络天然具备多租户隔离能力,用 VRouter 做 DHCP 和 SNAT,每个租户有自己独立的私网网段。这个设计对多部门共用一套云的环境特别友好。如果你的环境不涉及多租户,只是自己用,那扁平网络就足够,一个网段解决所有虚拟机通信问题。
第三,DNS 和网关地址要提前想好。ZStack 安装时会问你管理网络的 IP,这个 IP 不要跟 DHCP 自动分配的段重叠,最好固定在一个专门的 IP 段里。我之前见过有人把管理口 IP 设在 192.168.1.x 段,结果局域网里其他设备的 DHCP 正好也用了这个段,导致管理节点 IP 冲突,整个界面连不上。
2.3 镜像版本和系统版本的选择
ZStack 官方支持多种 Linux 发行版作为管理节点的宿主机,但我实测最省心的是 CentOS 7.9 和 Ubuntu 18.04 Server。原因有两个:一是 ZStack 的安装脚本对这些系统版本适配得最好,依赖包基本都能自动装好;二是社区里遇到问题的人大多也是用这两个版本,网上能搜到的排错经验最多。
另外要注意,ZStack 的安装包分为两种:一种是纯软件安装包,需要你自己先装好操作系统;另一种是"ISO 一体化镜像",里面直接集成了操作系统和 ZStack 安装程序。对于不想折腾系统安装的读者,我推荐用一体化镜像,省事很多。如果追求对系统的完全掌控,就先把系统装好,再跑纯软件安装包。
3. 管理节点的完整安装过程:从刻盘到初始化,一步步操作
环境规划好之后,就可以真正开始装了。我用一体化镜像来演示,这套流程在测试环境和生产环境里我都走过不止五遍,按下面步骤操作基本没有意外。
3.1 制作启动盘并安装操作系统
首先,去 ZStack 官网下载最新的 ISO 一体化安装镜像。下载完成后,用 UltraISO 或者 Rufus 把它写入 U 盘,这个过程和在 Windows 上做 PE 启动盘类似。服务器开机进入 BIOS,选择 U 盘启动,会进入 ZStack 的引导界面。
这里有一个细节值得注意:一体化镜像默认会把整块磁盘都占用来装系统,如果你的服务器上有其他想保留的分区,一定要提前备份或换机器。分区方案是自动的,默认是 LVM,把系统装好后,ZStack 相关服务全部跑在这块盘上。建议选择系统盘容量在 100GB 以上,后期日志和数据目录不会紧张。
安装过程中会自动创建用户,需要你设置 root 密码和一个用来登录平台的 admin 密码。这两个密码建议设强一点,尤其 admin 密码,因为 ZStack Web 登录界面会直接暴露在管理网络上。确认后系统开始安装,整个过程大概 5 到 10 分钟,取决于磁盘速度。安装完成后会提示你重启,并且会在屏幕上显示一个管理节点 IP。
如果你用的是"先装系统再装 ZStack"的方式,那么步骤就是在操作系统装好后,用 root 登录,把安装包上传到服务器上,执行安装脚本,脚本会自动检测硬件虚拟化和依赖包,然后给出一个管理节点 IP。两种方式殊途同归,最终都会进入同一个界面。
3.2 浏览器访问管理界面,完成基础初始化
管理节点 IP 拿到之后,用另一台能访问到这台 IP 的电脑打开浏览器,输入http://管理节点IP:5000,就能看到 ZStack 的登录页面。第一次进入会让你初始化,包括上传 License(免费版可以去官网申请试用 License)、设置云平台名称、选择时区。
初始化完成后,系统会进入一个向导式页面,引导你添加区域(Region)、添加计算节点、创建集群。ZStack 的区域概念可以理解成一个数据中心,一个区域里可以有多个集群,每个集群里有多台计算节点。初次安装时,如果管理节点本身也是计算节点(一体化部署),系统会自动把管理节点加进一个集群,你只需要确认信息无误并提交就行。
这一步最容易出现的问题是浏览器兼容性。ZStack Web 界面是基于 Java Web 的,老版本对 Chrome 的部分版本有兼容问题,表现为登录后页面空白或者按钮不响应。建议直接用新版的 Chrome 或者 Edge,关闭兼容模式,完全没问题。
3.3 验证管理节点服务状态
安装完成后,先别急着创建虚拟机。打开管理节点的终端,执行以下命令确认服务都活着:
systemctl status zstack-server systemctl status zstack-agent systemctl status zstack-database这三个服务分别是管理进程、计算节点代理(如果是重合部署)、数据库。如果哪个服务状态不是 running,用journalctl -u zstack-server -n 50查看日志。最常见的原因是内存不足或者磁盘空间不够,所以部署前检查配置是必须的。
确认无误后,在 Web 界面的"管理"菜单里能看到 CPU、内存、磁盘的汇总信息。到这里,管理节点部分就算完成了。
4. 添加计算节点和存储:把物理资源变成"云资源"的关键一步
管理节点跑起来只是搭了个架子,真正让云平台有意义的,是计算节点和存储这两块。我见过不少人卡在这一步,因为对"计算节点"和"存储"之间的关系没搞清楚。
4.1 一体化部署 vs 新增计算节点
如果你采用的是分体部署,在这时就需要把额外的计算节点加进来。在 Web 界面的"计算节点"页面点击"添加计算节点",输入 IP、root 账号密码,ZStack 会自动推送 Agent 到这个节点上并完成安装。这个过程中节点会自动检查 CPU 是否支持嵌套虚拟化等特性。
这里要注意一个现象:计算节点加入后,界面上可能显示"无状态"或者"不可用"。不要慌,多半是 SSH 端口或者密钥问题。ZStack 添加计算节点时用的是 SSH 方式,如果目标机器改了默认端口,你需要先在系统配置里把 SSH 端口改过来。另外,计算节点和 ZStack 之间通信走的是 7070 端口,防火墙必须放行。
4.2 本地存储和分布式存储的选择
添加完计算节点,下一步就是添加主存储。主存储是放虚拟机磁盘镜像的地方,ZStack 支持本地存储、NFS、Ceph、SAN 等类型。对于测试环境,最省事的就是"本地存储":每台计算节点把自己本地的一块磁盘贡献出来作为存储池。
本地存储的缺点是没有数据冗余,一旦某台计算节点的磁盘坏了,上面的虚拟机数据也跟着没了。所以生产环境建议用 Ceph 或者 NFS。
如果你有现成的存储阵列支持 NFS,那 ZStack 配置 NFS 主存储最简单:填入 IP 和共享路径,ZStack 会验证可写性并挂载,之后所有计算节点都能共享这一份存储池。Ceph 配置则复杂一些,需要你先在外部或者平台里创建 Ceph 集群,把监控节点 IP 和 key 填进去。ZStack 对 Ceph 的支持是可以直接用的一套方案,存储池的创建、块设备的挂载都由平台管理,你基本只需要提供一个可用的 Ceph 集群。
我的经验是:首次搭建不要一上来就搞 Ceph,先本地存储跑通,后面再考虑迁移。别的不说,排查 Ceph 网络问题会消耗你大量时间,本地存储至少能让你先看到虚拟机跑起来的样子,获得正向反馈。
4.3 备份存储和镜像仓库
ZStack 里还有个概念叫"备份存储",用来存放镜像文件、备份数据和虚拟机导出文件。通常可以用 NFS 或者本地存储来实现。管理节点上默认有一个二级存储,用于存放镜像模板。如果备份存储没配置,虚拟机的"导出"和"备份"功能会不可用。所以建议配置一个,路径只要服务端支持 NFS 就行。
我用一个简单的表格整理一下存储类型的选择,方便你对照:
| 存储类型 | 适用环境 | 优点 | 缺点 |
|---|---|---|---|
| 本地存储 | 测试、边缘节点 | 配置简单、无额外开销 | 无冗余,单点故障 |
| NFS | 中大型环境 | 集中管理、易扩容 | 依赖存储服务器,性能受网络影响 |
| Ceph | 生产环境 | 分布式、自动冗余 | 部署维护复杂,需要专门的网络规划 |
| SAN | 已有存储设备 | 稳定、性能好 | 硬件成本高,与 ZStack 集成需测试 |
我自己建议配置顺序是:本地存储先打通流程,NFS 保证备份,Ceph 留给后续优化使用。
5. 网络配置:扁平和 VPC 分别怎么玩,及关键避坑点
创建网络的时候要先决定用哪种模式。很多人第一次用 ZStack,会把网络配置想得很复杂,实际上你只需要理解两个关键点。
5.1 扁平网络和 VPC 网络的本质区别
扁平网络(Flat Network)是所有虚拟机都直接桥接在物理网络的某个网段里,虚拟机拿到的 IP 就是这个网段的真实 IP,和物理机在同一二层网络内。这种模式配置最简单:在"网络"页面点击"创建网络",选择物理网络,填入网段、网关、DNS、起始 IP 和结束 IP,然后关联到集群。虚拟机创建后会自动从这段 IP 池里取 IP。
VPC 网络的本质是每个租户拥有一个独立的虚拟私有网络,内部 IP 可以和别的租户重叠而不冲突。ZStack 用 VRouter 来实现,每个 VPC 有一个虚拟路由器,负责 DHCP、NAT、端口转发等功能。VPC 网络的配置过程是:先创建 VPC 网络,指定 CIDR(比如 10.0.0.0/16),再把该 VPC 挂到某个 L3 网络上(连接到底层物理网络),最后在 VRouter 上配置 SNAT 规则让虚拟机可以上网。
5.2 创建网络的完整操作路径
在 ZStack 界面里,网络创建的完整路径如下:
在"网络"菜单下,先创建"L2 网络",选择物理网络(对应计算节点上的物理网卡)。这里有需要特意说明的地方:所有计算节点的同名网卡会被归入同一个物理网络,所以网卡命名保持一致很重要。比如统一用 eth0 和 eth1,别这台机器叫 ens1f0、那台叫 p1p2,后面你会很难受。
在"L2 网络"之上创建"L3 网络",指定 CIDR、网关和 DHCP 的相关配置。如果这个 L3 网络是 VPC 网络的出口,则要在"虚拟路由器"里创建路由器并指定管理网络和公有网络。
创建"VPC 网络"并挂载到已有的 L3 网络上,最后把 VRouter 关联到集群。
实际操作中,ZStack 在创建 VPC 时会引导你把 VRouter 的管理 IP、公有 IP 都设置好,你只需按提示填。公网 IP 段需要有一个与物理网络直连的网段,这样才能让虚拟机通过 SNAT 访问到外部网络。
5.3 网络踩坑记:DHCP、路由和网卡绑定
我踩过最深的坑是 DHCP 不生效。现象是虚拟机创建后一直拿不到 IP,控制台里看只显示链路本地地址 169.254.x.x。排查了几个小时,最终发现问题是 VRouter 所在的计算节点那块网卡的物理网络选择错了,导致 VRouter 无法跟虚拟机通信。解决方法是重新创建 VRouter,并且确认 L2 物理网络选中的是真正连接虚机网络的网卡。
另一个坑是网卡绑定(bond)。生产环境里你很可能需要把两块网卡绑成一个 bond 来提高可用性,ZStack 支持在计算节点上做 bond。但我建议你在云平台建网络之前,先到计算节点上用cat /proc/net/bonding/bond0确认 bond 模式是否正确。如果 bond 模式配错(比如该用 4 却配成 0),虚拟机流量会时断时续,定位起来非常费劲。
6. 镜像管理和创建虚拟机:从导入模板到首台 VM 上云
网络和存储都就绪后,就可以创建第一台虚拟机了。很多人到了这一步反而会卡住,因为镜像模板的选择和导入方式没搞明白。
6.1 如何制作并导入一个云镜像
ZStack 支持导入多种格式的镜像,包括 qcow2、raw、vmdk 等。最稳妥的方式是直接下载官方提供的云镜像(比如 CentOS 7.9 的 qcow2 镜像),在"镜像"页面点击"创建镜像",选择该文件上传到备份存储。上传完成后 ZStack 会做格式识别,把镜像转换成平台内可用的模板。
如果你想把手头的物理机或者一台 VMware 虚拟机做成模板,可以用qemu-img convert命令,比如:
qemu-img convert -f vmdk -O qcow2 vm-disk.vmdk vm-disk.qcow2转换完之后,把它上传到 ZStack 的备份存储,再创建镜像。需要注意,云镜像默认开启了 DHCP,所以如果你的网络配置没有正确下发 IP,虚拟机启动后网络会不通。镜像里最好预先装好 cloud-init,这样 ZStack 创建虚拟机时能自动注入密码和主机名。
6.2 创建虚拟机的资源配置逻辑
在"虚拟机"页面点击"创建",选择镜像模板,指定 CPU、内存、磁盘大小。ZStack 的默认配置是按"物理机 CPU 超线程"来计算的,所以你在界面上填的 2 核,实际可能是物理机上 2 个超线程。如果你对性能敏感,务必先把 CPU 模式设置成 host-passthrough,否则虚拟机里看到的 CPU 型号是一颗很保守的虚拟 CPU,性能会有 20% 左右的折损。
创建虚拟机时还有一个关键选项是"计算规格",你可以预定义几套常用规格,比如 small(2C4G)、medium(4C8G)、large(8C16G)。我的习惯是预先把规格建好,后续创建虚拟机直接选,保持资源使用井然有序。
6.3 云主机创建的加速技巧:使用标签和调度策略
ZStack 支持用标签(Tag)来管理主机分组。可以在计算节点上打标签,比如"GPU节点""高频计算节点",然后在虚拟机创建时指定"调度标签"来限定这台机器只能跑在对应标签的节点上。这个功能对 GPU 虚拟化场景特别有用。我在实际项目中用标签把测试节点和生产节点分开,避免测试用的虚拟机不小心调度到生产节点上抢资源。
创建虚拟机时长按"业务系统名称"来命名,不要用一串无意义编号。后面排查问题和做备份恢复时,一个语义清晰的名字比找 IP 方便得多。
7. 运维日常:备份、升级和故障排查的经验清单
私有云搭起来之后,真正的考验才开始。很多人虚拟机都跑起来了,结果过了一个月发现磁盘日志满了、备份任务失败、升级之后服务起不来。我把自己实际积累的几条经验列出来。
7.1 备份策略:别只备份虚拟机磁盘
ZStack 的备份功能以"备份任务"为单位,可以把虚拟机连同磁盘、网络配置一起备份到备份存储。我在配置备份时发现最容易忽略的地方是数据库备份。ZStack 的云平台状态(所有虚拟机配置、网络配置、用户权限)都存在管理节点的数据库里,如果数据库坏了,就算你的虚拟机磁盘文件还在,也没法恢复平台状态。
建议做一个定时任务,把管理节点的数据库 dump 出来,定期拷贝到外部存储。ZStack 自带备份数据库的脚本,放在管理节点的/usr/local/zstack/下,直接执行就能生成一个 SQL 文件。我的备份策略是:
| 备份对象 | 方式 | 频率 |
|---|---|---|
| 虚拟机磁盘 | ZStack"备份磁盘"任务 | 每天一次 |
| 云平台数据库 | mysql dump 到本地 + 同步到外部 | 每天一次 |
| 镜像模板 | 导出镜像到 NFS 备份存储 | 每周一次 |
磁盘备份不会太占用空间,增量备份是默认开启的,所以放心配置也不会爆盘。
7.2 升级 ZStack 的正确姿势
ZStack 的升级有两种路径:一种是用官方提供的升级包在 Web 界面"系统升级"里上传;另一种是在管理节点上用脚本升级。我强烈建议在测试环境先升级一次,再动生产环境。升级前务必备份数据库快照,如果升级失败可以回滚。
升级后你会遇到一个小问题:管理节点上旧的 zstack-agent 可能在升级完成后没有自动重启,导致虚拟机的 QoS 或者监控数据异常。解决办法是升级完成后在所有计算节点上重启一下相关服务:
systemctl restart zstack-agent我升级时还遇到过界面里的升级按钮变灰的情况,那个多半是因为管理节点和计算节点的版本不一致。先到计算节点页面上看看有没有"需升级"提示,把所有节点的版本对齐后再操作。
7.3 最值得记住的排查命令
运维 ZStack 时,有几个命令是我几乎每天都会用到的。当虚拟机网络不通、平台界面打不开、存储池显示不可用时,按下面顺序排查效率最高。
# 查看管理节点服务状态 systemctl status zstack-server # 查看计算节点 agent 日志 tail -f /usr/local/zstack/apache-tomcat/logs/zstack-agent.log # 查看管理服务器日志 tail -f /usr/local/zstack/apache-tomcat/logs/management-server.log # 查看数据库连接池情况 ss -tan | grep 3306日志路径可能随版本不同有变化,但总体结构不变。当你看到 management-server.log 里大量报错时,优先看是不是数据库连接不上。这个数据库连接问题八成是磁盘满了,用df -h一眼就能确认。
7.4 域名和证书:为上生产做的准备
如果你的私有云要长期使用,我建议提前部署好 HTTPS 证书和自定义域名。ZStack Web 界面默认走 HTTP,但生产环境直接裸奔 HTTP 会有安全风险。ZStack 支持在系统设置里上传证书,配置后所有 API 和 Web 都走 HTTPS。证书要提前申请好,注意证书链的顺序,中间证书在前还是根证书在前不要搞反。
还有一个容易被忽略的点是管理节点 IP 的固定性。如果管理节点的 IP 变了,所有计算节点上的 agent 都要重新连接。所以给管理节点配置静态 IP 时,要确保和所有计算节点之间的路由是持久稳定的。我也见过有人把管理节点做成 DHCP 保留地址,但我不推荐,因为计算节点启动时是靠 DNS 或 /etc/hosts 去解析管理节点的,那个文件里有静态 IP 最保险。
8. 我对 ZStack 上生产环境的几点真实看法
最后说一点我个人的实际体会。ZStack 不是一个"装完就不用管"的产品,但它确实是当前开源私有云领域里投入产出比很高的方案。相比偶尔需要花一整天去排查 OpenStack 某个组件之间微妙的兼容性问题,ZStack 的排错路径要清楚得多。
如果你打算用它上生产,建议先小规模试运行一到两个月。这期间重点观察存储的性能曲线和虚拟机的调度稳定性。别一开始就导入上百台虚拟机,你做压力测试的时间和之后返工的时间对比,前者划算得多。
还要说的是,ZStack 的社区群和官方论坛能解决很多实际问题。遇到异常先搜索一下日志里报错的关键词,往往能找到同病相怜的案例。我自己很多坑都是这么趟出来的。
这套搭建流程,我前前后后在不同服务器上跑过七八遍,踩过的坑都写在上面了。照着做,你大概率能在半天内把一朵能用的私有云搭出来;即便中途出现意外,也基本都能在日志里找到答案。祝你顺利。