OpenStack高可用集群案例实践分享

1. 规划与部署

本次分享提炼自我们在某企业部署OpenStack高可用集群的实际案例，初期平台面向公网给部分部门提供虚拟化基础设施，但仍属于私有云。其中我借鉴了以往操作比如oVirt（RHEV）、VMWare、Citrix等项目的经验。考虑到时间关系，本次内容将以方法为主，减少细节描述。还有本次涉及到的工具多以开源形式呈现，尽量不涉及到产品，以方便大家集成或开发。

架构简图可参考如下，稍后我们会就其中细节进行讲解。两个架构图的区别在于控制节点的高可用方式。

1.1. 基本环境

因为客户网络环境复杂，为了节省部署时间与减少返工率，我们需要在去现场之前准备好以下三种安装方式：

• PXE LiveCD
• 定制系统安装盘
• 安装包与安装脚本

第一种方式即在用户网络环境下使用现场人员笔记本或者客户服务器启动PXE服务，配置好系统架构（服务器MAC地址、网络配置、存储配置、对应的OpenStack模块与角色、定制包、系统微调与优化措施等），然后开始全自动安装，功能与Mirantis类似，但对网络要求低很多。

第二种方式既是采用定制的系统安装盘，里面需要准备尽可能多的存储设备与网络设备的驱动，以尽可能适配客户服务器与实施人员的自带存储设备。

第三种方式作为前两种方式的替补选项，主要是因为某些客户环境中安装非标系统需要走很多流程，我们提前让客户准备好操作系统，再到现场安装。如果给你准备的系统是RHEL、SUSE或者其他标准Linux系统的倒还好，如果他有情怀地花了一两天给你现编译上了Gentoo甚至给你准备了一台小机，那就没办法了（开玩笑，尚未遇到过这样的客户，在进厂之前要把基本环境沟通清楚）。另外，它也可以作为以上两种安装方式失败后的最佳选项。

这几种方式也不能说孰优孰劣，从效率上来说我推荐第一种，但针对难以定制的商业虚拟化我们就只能采取手动安装的方式了。

题外话：很多所谓“5分钟装完IaaS”的“神话”都不把服务器从启动到改BIOS配BMC/IPMI的时间算进去。

1.2. 网络规划

这一步骤优先级最高，我们必须在动手之前就按照功能区域把网络进行划分，包括管理、网管、存储、租户、显示、迁移等。当然，很多情况下没必要划分太细，因为我们要根据用户网络环境和软件特性对他们进行规划，规划太细发现最后配置难以实现，“一把梭”规划发现用户一上来就喊卡。

一般来说，客户的物理网络主要以VLAN为主，其他情况暂不讨论。对于非核心层的虚拟化而言，我们看到的多是untagged网络，所以规划时要时刻留意网关与掩码；而对于核心层的虚拟化，那么我们很有可能得到一堆tagged网络，都由我们自己与客户商讨规划。

在网络硬件上，仅就虚拟化层面而言，KVM系列的要求不高，而VMWare的FT则要求较为苛刻，万兆、IB等都是标配（题外话：KVM的FT功能尚不稳定）。如果涉及到下面要讲到的“超融合”，那么万兆专用存储网络真的是标配了。如果应用层面涉及到诸如Oracle之类的应用，那我们很可能就要使用网络设备透传了，也可看规划选择性地走RDMA。

当然，在现场时我们很有可能遇到交换机是全新并且客户网管也不太会配置的情况，虽然极少但也是有的。秉着专业事儿交给专业人来干的原则，咱们可以等，等网管把交换机配好（客户沟通妥善时自带网管技能也行）。

网络规划时，我们在最大限度保证带宽的同时，要给予整体充分的可扩展性。这次项目中，为了给予客户享受科技带来的便利，比如OpenStack Neutron便利网管、实现NFV导流、Fabric Network、Packet Broken Network、减少网络单点故障率等等，我给客户推荐了几台SDN交换机与其Neutron主机集成，然后可以在OpenDayLight里开发应用程序并与OpenStack Dashboard结合呈现出看起来高大上的界面和功能，最大限度地利用OVS。（这里要感谢上海同悦信息龙未来先生协助开发的应用）

1.3. 存储规划

如果用户那有现成的存储设备那就最好不过了，但也有利有弊。好处是减少了我们的运维负担，关键时刻也可以“甩锅”；坏处就是现有存储很可能限制我们平台的能力，也存在潜在的兼容性风险。

由于软件定义存储的风行，尤其是VMWare带来的业界领导作用，客户有可能想当然地认为虚拟化层面的存储就该我们自己负责。那没办法了，要么找个通过兼容性测试的存储设备，要么自己上。这时候，用户也是有选择权的，比如这次就要上Ceph，虽然我个人更偏向于Glusterfs。

这些分布式存储大同小异，与传统的集中式存储相比他们的成本低廉，性能与功能都尚可，能覆盖绝大多数普通客户的需求。但我们上分布式存储总不能再问客户要几台服务器专门搭存储吧，那就得部分“超融合”了。

“超融合”也是现在OpenStack厂商项目部署的主流做法，比如管理组件在虚拟机中，硬件仅仅充作当作功能性代理去操作硬盘。而本次项目中，我们也将Nova与Ceph装在同一批机器中，同时采用对两者进程的运行时环境进行了优化的系列措施，尽量减少“此消彼长”带来的影响。

1.4. 软件配置

绝大部分软件都来自社区发布版本，部分核心模块来自红帽企业版，因为就踩坑几率而言社区版本更高，况且我们作为国内一个小小的软件厂商，对红帽有一种执念，哈哈。

到宿主机层面的网管软件并没有额外采购，而是继承了客户原有系统；而到虚拟化层面，则额外配置了OpenDayLight结合OpenStack Dashboard进行管理。

由于主机的存储空间较多，所以本次也就存储多网关协议进行了一些拓展，类似于OpenMediaVault和FreeNAS的功能，以方便其他平台使用。

本次部署的OpenStack仅涉及到虚拟化以及块存储相关组件，并未涉及到容器部分，因为客户选择了一家国产厂商的容器平台作为应用平台。此种环境下的OpenStack平台仅仅提供计算与存储能力，且保证一定的容器隔离性。

题外话：针对平台软件开发的开源参考，个人认为首选OpenStack和oVirt这两者，前者走着公有云标准，后者紧跟VMWare脚步。对于基于Docker的PaaS平台开发，我觉得使用了Kubernetes的OpenShift是个不错的参考对象。还有OpenStack的那个容器模块，第一印象很差，就没再碰过了。

2. 最佳实践

2.1. HA策略

HA即高可用（High Availability），在某些关键性服务上需要实现HA已保证业务连续性，这次项目中先就OpenStack控制节点实现HA。总的来说实现应用的HA我总结有如下几种方式：

负载均衡：虽然严格讲负载均衡很容易存在单点故障，但某些情况下也是一种HA方式。

共享存储：也就是比较经典类似PaceMaker/KeepAlived+DRBD实现的冗余，适用范围很广。

FT：Fault Tolerance，两台机器的系统状态随时保持同步，一台宕机后另一台快速接业务，可以保证很高的业务连续性。虚拟化平台中以VMWare最为出名，其实也有可以单独购买的FTServer，但是成本稍贵。目前KVM系列支持不佳。

迁移：在很多虚拟化平台中，尤其KVM系列基本都有这一个HA措施，但缺点就是比如所在物理机宕机后，它会在其他机器上重启，所有运行时的系统状态都会丢失，业务连续性有一定损失。当然，它也需要宿主机的存储保持同步，一般选用共享存储。

虚拟管理节点：这种方式叫Self-Hosted（这个我翻译不好），它也是虚拟化平台中较为常见的HA方式，即是将管理节点作为虚拟机，同时借助于迁移来保证管理节点的高可用。目前OpenStack尚不提供社区支持，本次部署中我们使用etcd配合简单策略进行了开发，效果尚可。

其实针对不同应用不同场景HA策略仍有很多，比如实现RabbitMQ的高可用除了以上方式我们也可直接使用它的镜像（mirror）部署，实现Neutron的高可用可以使用VRRP实现分布式路由。总之HA方法太多了，需要灵活选型与搭配。

2.1. 自服务

在一些私有云项目里，仅仅部署平台是不够的，需要集成到客户的系统中将虚拟化作为正常的业务（服务）进行提供。那这个时候，我们就很看中平台所能提供的API完善度了。

比如自服务有主机选型、计费、审计、认证对接等流程，相当一部分的工作都要在客户环境下才能完成，虽然某些产品提供了不错的接口，但是这也正是它的缺点。比如这次对接单点登录时，发现客户环境中的系统繁多，有些老系统甚至不能进行再开发，对接难度比较大，如果不具备非常灵活的API与丰富的扩展插件，那么绕的弯子就比较多了，部署效率大大降低。

现在一些厂商有提供自服务的单独产品，开源的也有，但在使用时仍需要一定二次开发工作。

2.2. 无状态服务

这里给个比较通俗的定义吧：在系统重启前，不需要保存状态的称之为无状态内容，比如各种可执行文件、库文件等，需要保存状态的称之为有状态内容，比如存储内容、配置文件等。这里要讲的无状态包括基础设施和上层服务两部分。

基础设施的无状态在很多嵌入式设备、存储设备里都很常见，比如一些交换机设备，其基本系统文件来自一个只读的压缩分区（类似squashfs），配置文件另外单独存放，这样能保证交换机即便出现意外也最多是配置文件丢失，但系统仍能工作。当然，这只是软件系统设计上的保证，实际用的时候发现交换机其他坏的地方也挺多的。

服务的无状态也与之类似，即服务本身的载体可以被随时替换。容器平台与虚拟化平台都可以实现应用服务的无状态，但前者更加轻量。

无状态服务是一把双刃剑，优点在易维护，缺点也是难维护。比如软件出问题我们只要重启机器就行了，但如果涉及到无状态内容，除去较为完善的补丁机制，也有可能重制底包。

以OpenStack计算节点为例，你需要的无状态内容为系统本身+nova模块相关文件，其他关键配置比如network-interface、sysctl.conf、nova.conf等等都可以单独保持，在制作光盘时就需要确定的。

2.3. 备份与恢复

整体来说，很多IaaS平台的备份与恢复都相对简单，且RTO与RPO的指标都非常容易做的很漂亮。

备份方法太多，传统的软件备份厂商已经做了很多探索并且也有很好的产品了，所以这里只讲一些适用于虚拟化的备份策略。

整机备份：除去传统软件外，也有一些虚拟化提供的工具，比如Converter或者virt-tools。在备份功能之外，它们都可以作为很好的PV转换手段。

存储域（卷）全备：既是将整个存储域进行备份，很大程度上依赖平台自身与下层存储的能力。存储域备份也可以将颗粒度细化到虚拟机OVF，但一般不能更细。

快照备份：在备份KVM平台的虚拟机时，我们仍然可以将硬盘文件与快照文件单独备份，在第一次备份完成之后，以后只需要备份快照就行。这种方法不仅适用于裸镜像文件，更适用于Ceph RBD。

在这些备份策略里，我比较常用的快照备份。比如OpenStack平台，如果不依赖底层存储能力的话，它所能提供备份策略不酷（只到镜像级别），所以在一些项目中我们就直接从其API定位到实例的镜像再进行镜像与快照的单独备份。当然，恢复的时候也直接恢复到实例。需要注意的是，假如通过网络备份或恢复，传输镜像或快照文件的时候要注意文件空洞，否则会大大增加备份时间。

还有就是数据库、配置文件等有状态内容的备份，备份方法简单就不讨论了。

在恢复时，OpenStack大多数模块的恢复都比较容易，即数据、配置与数据库即可。如果备份的时候包括了进行中的任务，那么需要在恢复后对其进行清理。如果虚拟机数量不多，那么虚拟机或者存储目录直接导入也是一种方法。

2.4. 设备重定向

这个话题老生常谈了，主要是某些应用的U-key，以及高性能的需求，包括网卡、显卡、硬盘等。实现手段仁者见仁智者见智，有喜欢走TCP/IP的，有喜欢走设备直通的。大家随意选择。有一点要注意的是，某些机器你P2V了，U-key也重定向进去了，但是最后你发现这个授权与机器硬件环境挂钩，那就白忙活一场了。

2.5. vGPU

这个话题是我硬塞的吧，跟本次项目无关，我的书与随书视频都介绍了一些，这里我再说一些吧。

去年这时候KVMGT效果尚可，但难以产品化，再往前数的话就是靠着GPU透传去实现了。相比同时期的Citrix，KVM只能望其项背。

而就在上个月KVMGT与Mediated Device都被并入了4.10内核主分支与最近的Intel新独立显卡的发布，这可能是一个拐点，意味着KVM下即将拥有靠谱的vGPU方案了。

当然，如果nVidia不跳票的话，大家有兴趣可以去我的博客看看最近的一篇nVidia的PPT。

2.6. 部分运维事项

接下来OpenStack下的运维，这点我的经验不是很丰富，就讲一下某些环境里需要上的，比如CVE检测（漏洞检查）和报表服务。

CVE按理说应该属于企业网管部分，但我们的宿主机OS由于是高度定制化的，所以这部分的检测予以特别考虑，即使被列入了企业的白名单我们也应该有自己的检测机制，就是只修复已经经过测试的补丁。

还有一个就是报表服务，OpenStack本身可以选择安装Telemetry模块提供简单的报表服务，然后可以将其作为DataWareHouse的数据源之一以方便后期进行统计。领导就喜欢看报表嘛。

文章来自微信公众号：云技术社区

作者：蒋迪

云技术社区专家，资深虚拟化基础设施工程师，《KVM私有云架构设计与实践》作者，云技术社区专家，擅长KVM云平台架构解析与虚拟化POC，具有一线开发与交付经验。

本文链接：https://www.yunweipai.com/18062.html