简介面向企业云平台架构师、OpenStack实施与运维人员的解决方案型案例围绕生产环境高可用集群的落地难点从部署规划到运维排障提供完整思路。文档基于企业私有云真实项目重点比较PXE LiveCD、定制系统安装盘与安装包脚本三种交付方式并给出应对复杂网络环境和客户流程的建议同时详解网络按管理、存储、租户、迁移等区域划分的方法涉及VLAN、tagged/untagged、SDN交换机与OpenDayLight集成以及NFV场景下的导流设计。存储层面结合分布式存储Ceph与Glusterfs讨论超融合部署和Nova同置优化高可用部分则围绕控制节点说明负载均衡、Pacemaker/Corosync等机制的选用。压缩包内仅含1个docx文档大小460KB已有157人学习。内容贴近实战涵盖硬件兼容性、VMware FT、万兆网络与InfiniBand要求等细节适合在私有云建设中作为参考手册也可为搭建OpenStack高可用环境提供避坑指南。1. OpenStack 高可用集群一次真实的企业实施拆解做 OpenStack 高可用集群部署这件事这几年被“5 分钟装完 IaaS”的说法带偏了不少人。真正到客户现场你会发现从服务器上架、改 BIOS、配 BMC/IPMI到网络划段、存储选型、HA 策略落地每一步都可能让工期翻倍。这篇文章拆解的是我们帮某企业部署 OpenStack 高可用集群的实际案例平台面向公网给部分部门提供虚拟化基础设施但仍属于私有云范畴。实施过程中借鉴了 oVirt、VMWare、Citrix 等项目的经验工具以开源为主方便后续集成或二次开发。适合正在做私有云交付的运维和架构师以及准备从单节点走向集群部署的团队。你会看到三类安装方式的取舍、网络和存储规划的逻辑以及控制节点 HA 的几种落地手段和对应的坑。2. 现场部署三板斧PXE、定制盘与脚本安装的选型逻辑2.1 为什么必须准备三种安装方式客户网络环境复杂这是所有 OpenStack 交付项目的第一道坎。我们的做法是去现场之前强制准备好三种安装方式避免到了现场发现某个环节卡住整个团队干等。第一种 PXE LiveCD在用户网络环境下用现场人员笔记本或客户服务器启动 PXE 服务把服务器 MAC 地址、网络配置、存储配置、对应的 OpenStack 模块与角色、定制包、系统微调与优化措施全部提前配好然后全自动安装。这个方案功能上和 Mirantis 类似但对网络要求低很多只需要二层可达就能跑起来。效率上我推荐这种方式因为现场零手工操作服务器通电后自动进入安装流程。第二种定制系统安装盘核心价值在驱动。我们需要把尽可能多的存储设备与网络设备驱动打进去以适配客户服务器和自带存储设备。很多客户的服务器型号老旧标准安装镜像大概率缺驱动导致认不到盘或者网卡起不来现场编译驱动会非常痛苦。第三种安装包与安装脚本是前两种方式的替补。某些客户环境中安装非标系统需要走很长的审批流程所以我们提前让客户准备好操作系统到现场直接装 OpenStack。如果客户准备的是 RHEL、SUSE 或者其他标准 Linux 系统问题不大但进厂之前必须把基本环境沟通清楚否则真遇到给你现编译的 Gentoo 甚至小机工期就直接失控了。这个方案也适合前两种安装方式失败后的兜底。2.2 网络规划VLAN 划分与 SDN 集成的实操建议网络规划是整个部署中优先级最高的一步必须在动手之前就按照功能区域划分好。我们的划分维度包括管理、网管、存储、租户、显示、迁移等但很多情况下没必要划太细。这里有个真实教训规划太细到配置阶段发现难以实现过度追求“一把梭”用户一上来就反馈卡顿。尺度把握取决于客户物理网络的实际形态。客户的物理网络主要以 VLAN 为主非核心层虚拟化场景下看到的多是 untagged 网络规划时要时刻留意网关与掩码。核心层虚拟化场景则可能拿到一堆 tagged 网络需要和客户商讨划分方案。网络硬件层面KVM 系列的要求不算高但 VMWare 的 FT 对网络要求苛刻万兆、IB 属于标配。如果涉及超融合万兆专用存储网络就是硬性要求了。应用层面涉及 Oracle 之类的场景需要使用网络设备透传也可以根据规划选择性地走 RDMA。这次项目里为了用上 Neutron 便利网管、实现 NFV 导流、Fabric Network、Packet Broken Network以及减少网络单点故障率我们给客户推荐了几台 SDN 交换机与 Neutron 主机集成。SDN 控制器选了 OpenDayLight开发了应用程序与 OpenStack Dashboard 结合管理界面直接呈现流表和网络状态。这样做的好处是把 Neutron 的网络能力和 OVS 的数据面能力充分释放出来坏处是引入了额外的控制器运维负担需要团队里有懂 SDN 的人。2.3 存储规划分布式存储选型与超融合的取舍存储规划的决策点在于客户有没有现成存储设备。有现成设备的好处是减少运维负担、关键时刻可以“甩锅”坏处是现有存储很可能限制平台能力存在兼容性风险。客户如果认为虚拟化层面的存储就该我们负责那就只能选通过兼容性测试的存储设备或者自己上分布式存储。分布式存储层面客户指定了 Ceph我个人更偏向 Glusterfs。两者大同小异成本比传统集中式存储低性能和功能覆盖绝大多数普通客户需求。但上分布式存储不能额外要几台服务器专用作存储节点于是采用了“超融合”架构管理组件跑在虚拟机中硬件仅作为功能性代理去操作硬盘同时把 Nova 与 Ceph 装在同一批机器里。这里的关键优化点在于对两者进程的运行时环境做隔离和调优尽量减小“此消彼长”的影响。实操时我们会用 cgroup 限制 Ceph 进程的内存和 CPU 占用给 nova-compute 留出足够的资源余量。软件配置方面绝大部分组件来自社区发布版本部分核心模块来自红帽企业版。原因很直接社区版踩坑几率更高而企业版经过了更充分的测试。OpenStack 部署范围仅涉及虚拟化及块存储相关组件没有包含容器部分因为客户选择了国产容器平台作为应用平台。这个环境下 OpenStack 只提供计算与存储能力同时保证一定的容器隔离性。3. HA 策略选型从控制节点到消息队列的落地组合3.1 五种 HA 方式的能力边界与适用场景HA 即高可用在关键服务上必须保证业务连续性。这次项目优先实现 OpenStack 控制节点的 HA。实际操作中我把 HA 的实现方式归纳为五类每类的适用边界完全不同。负载均衡严格讲很容易存在单点故障但在某些场景下也算一种 HA 方式比如 Neutron 的分布式路由可以用 VRRP 做冗余。共享存储是比较经典的方式类似 PaceMaker/KeepAlived 加 DRBD 的冗余组合适用范围很广控制节点的数据库和消息队列都可以跑在这上面。FT 即 Fault Tolerance两台机器的系统状态随时保持同步一台宕机后另一台快速接管业务可做到很高的业务连续性虚拟化平台里 VMWare 最为出名但 KVM 系列对 FT 的支持尚不稳定实际项目里不建议赌这个功能。迁移是 KVM 系列基本都有的 HA 措施缺点是物理机宕机后虚拟机虽然会在其他机器上重启但所有运行时的系统状态都会丢失业务连续性有损失而且同样依赖宿主机存储同步一般要配共享存储。虚拟管理节点方式叫 Self-Hosted把管理节点作为虚拟机跑借助迁移机制保证管理节点的高可用。OpenStack 社区不提供这个功能的直接支持这次我们用了 etcd 配合简单策略做了开发效果尚可。3.2 控制节点高可用的具体实现路径控制节点 HA 的实现我们采用了组合策略。MariaDB 数据库用 PaceMaker 加 DRBD 做共享存储冗余RabbitMQ 通过镜像模式部署Neutron 用 VRRP 做分布式路由冗余Keystone 和 Nova API 前面挂负载均衡。这套组合的好处是每一层都用最合适的方式做冗余而不是全都依赖同一套故障转移机制。这里有个容易忽略的细节不同组件的 HA 方式不能混为一谈。RabbitMQ 做 HA 除了 PaceMaker 方式也可以直接用它的镜像mirror部署而且后者在消息队列这种有状态场景下更自然。Neutron 做 HA 则用 VRRP 实现分布式路由和负载均衡的手法是两个维度。控制节点的 etcd 集群我们单独部署了三节点用于保存 Self-Hosted 控制节点的心跳和调度状态这样当控制节点所在物理机宕机时etcd 能快速感知并把控制节点虚拟机调度到其他计算节点重启。HA 策略的选型要灵活不同应用不同场景差别很大核心原则是一套机制解决一类问题不要试图用一个方案覆盖所有组件的 HA 需求。比如数据库这种强一致性的服务用 PaceMaker 加 DRBD 是稳妥的而消息队列这种可以容忍短暂脑裂的服务镜像模式反而更简单可靠。4. 无状态服务设计与备份恢复架构意识和兜底能力4.1 无状态设计的落地方法无状态服务这个概念理解起来简单落地时细节很多。通俗定义是系统重启前不需要保存状态的内容叫无状态比如各种可执行文件、库文件需要保存状态的叫有状态比如存储内容、配置文件。OpenStack 计算节点上无状态内容为系统本身加 nova 模块相关文件其他关键配置比如 network-interface、sysctl.conf、nova.conf 都有状态需要单独保存。基础设施的无状态在交换机这类嵌入式设备里很常见基本系统文件来自只读压缩分区类似 squashfs配置文件单独存放。这样设计的好处是设备出现意外最多配置文件丢失系统仍能正常工作。服务层面的无状态也类似服务本身的载体可以被随时替换容器平台和虚拟化平台都能实现但容器更轻量。无状态服务是一把双刃剑优点是易维护软件出问题重启机器就行缺点也是难维护因为无状态内容一旦损坏需要重制底包。以制作定制安装盘为例无状态内容必须在制作光盘时就确定下来后期补丁只能通过机制单独分发。我们一般会在 PXE 配置里把定制包的版本写死后续更新走单独的文件分发通道而不是每次重新刷底包。4.2 备份恢复策略快照优先与文件空洞的坑IaaS 平台的备份与恢复整体相对简单RTO 与 RPO 的指标容易做得很漂亮。备份策略上我按颗粒度分成三级。整机备份可以用 Converter 或者 virt-tools在备份功能之外它们也是很好的 PV 转换手段。存储域卷全备是把整个存储域备份依赖平台自身与下层存储的能力可以细化到虚拟机 OVF 级别但一般不能再细。快照备份是我个人最常用的方式把硬盘文件与快照文件单独备份第一次全量备份完成后后续只备份快照文件即可。这种方法不仅适用于裸镜像文件更适用于 Ceph RBD。OpenStack 原生的备份能力如果不依赖底层存储只能到镜像级别所以项目中我们直接从 API 定位到实例的镜像再对镜像与快照做单独备份恢复时也直接恢复到实例。这里有一个非常具体的坑通过网络备份或恢复传输镜像或快照文件时要注意文件空洞。镜像文件内部未写入数据的区域在文件系统里表现为空洞如果走普通网络传输这些空洞区域会被当作真实数据读出来传出去备份时间会成倍增加。我们的做法是用 qemu-img convert 先把镜像压缩转换成连续文件再传输或者使用支持 sparse 传输的工具比如 rsync 加 --sparse 参数。恢复时 OpenStack 大多数模块的恢复都相对容易数据、配置与数据库齐全就能恢复。有个细节容易被忽略如果备份的时候包含了进行中的任务恢复后需要清理这些任务状态否则会发现实例处于诡异的中间状态。虚拟机数量不多的情况下虚拟机或者存储目录直接导入也是一种可行方案。5. 避坑指南OpenStack 实施中的四个典型问题5.1 安装环节的时间预估偏差现象是所有计划都做得很满但现场几乎每个服务器从上电到开始装系统都会浪费大量时间。原因很简单很多“5 分钟装完 IaaS”的演示都不把服务器启动、改 BIOS、配 BMC/IPMI 的时间算进去。实际操作中这几项占用的人力和时间远超预期尤其是改 BIOS 启动顺序和配置带外管理一台台手工操作非常折磨。解决方式是把这些操作做成标准操作流程表分配专人处理同时提前跟客户确认 IPMI 账号权限是否已开通。从那以后我每次做项目计划都会在安装环节强制增加 30% 的缓冲时间。5.2 网络规划粒度失衡现象是网络规划做得过细把管理、存储、租户、迁移全部独立 VLAN 隔开结果配置阶段发现交换机端口和路由规则根本配不过来反而拖慢了交付进度。原因是规划时没有结合客户物理网络的实际复杂度想把所有理想化的设计一次性落地。解决的思路是区分核心层和非核心层场景非核心层虚拟化直接用 untagged 网络减少网关与掩码的配置量核心层再引入 tagged 网络但仍然保持最小可用原则能合并的网段尽量合并。规划太细发现配置难实现和一把梭规划导致用户喊卡这两个极端都要避免。5.3 Ceph 与 Nova 同置的资源争抢现象是超融合节点上 Ceph 和 nova-compute 的服务都正常但虚拟机磁盘写入延迟长期偏高存储性能不稳定。原因是 Ceph 的 OSD 进程和 nova-compute 的 QEMU 进程在同一批物理机上争抢 CPU 和内存资源Ceph 的写入延迟直接拖累了虚拟机 IO。解决方式是用 cgroup 做资源隔离限制 Ceph 进程的 CPU 配额和内存上限同时调整 Ceph 的线程池大小和 nova-compute 的 vCPU 超配比例。调整之后存储延迟明显下降计算侧的虚拟机性能损失也控制在可接受范围内。5.4 U-key 重定向后授权失效现象是 P2V 时已经把 USB Key 重定向到了虚拟机里应用能识别到设备但授权始终不生效。原因是部分软件的授权与机器硬件环境绑定检测到硬件变更后直接拒绝服务重定向的 U-key 白忙活一场。解决方式是在 P2V 之前先跟软件厂商确认授权策略是否绑定硬件指纹如果绑定需要提前申请重新授权或选择宿主机直通 USB 控制器。设备重定向的方案选择也有讲究有人喜欢走 TCP/IP有人喜欢走设备直通没有绝对优劣但授权与硬件绑定的应用场景必须严选方案。6. 自服务 API 对接的落地经验私有云项目里仅仅部署平台是不够的必须集成到客户的业务系统中把虚拟化作为正常的服务提供。核心工作在于平台 API 的完善程度自服务涉及主机选型、计费、审计、认证对接等流程相当一部分工作要在客户环境下才能完成。这次对接单点登录时我们遇到客户环境中的系统比较杂有些老系统甚至不能进行二次开发如果 API 不够灵活、扩展插件不丰富绕的弯子会很多。Keystone 的认证对接是第一步。我们在 Keystone 里配置了自定义认证插件通过 LDAP 或者 CAS 协议对接客户的统一认证映射 OpenStack 的角色和项目。这块的关键在于搞清楚客户的认证体系是标准 LDAP 还是 CAS再选对应的认证后端同时要在 Keystone 的 domain 和 project 层级设计上对齐客户的组织架构。计费数据的获取我们用 Ceilometer 采集资源使用数据把计量数据同步到客户的计费系统。有个细节是 Telemetry 模块默认采集的指标可能不满足客户计费要求需要自定义 meter比如针对某些高性能虚拟机额外统计 GPU 使用时长。审计方面CloudAudit 的 API 调用日志要保留足够长的时间同时注意日志的时区统一避免客户审计时发现时间对不上。自服务的完整落地往往需要一定二次开发工作。开源的自服务产品在使用时都会有定制空间关键是先跑通最小闭环认证、创建虚拟机、查看账单、销毁虚拟机。这个闭环验证之后再逐步接入客户已有的审批流或工单系统。OpenStack 的 API 本身已经足够完善大部分定制需求都能通过 API 层解决这也是我们很少去改 OpenStack 源码的原因。能通过配置和 API 扩展解决的问题尽量不要动源码否则后续升级会非常痛苦。希望这些经验能帮到你至少在遇到类似项目时能少走一段我们走过的弯路。本文还有配套的精品资源点击获取
