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

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,具有一线开发与交付经验.

（编辑：宁德站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!