《OpenStack高可用集群(下册):部署与运维》—11.2.2 OpenStack高可用部署生产环境架构

举报
华章计算机 发表于 2019/05/29 15:54:19 2019/05/29
【摘要】 本书摘自《OpenStack高可用集群(下册):部署与运维》一书中的第11章,第11.2.2节,作者是山金孝。

11.2.2 OpenStack高可用部署生产环境架构

对于开源软件的使用,没有任何固定的设计架构,尤其是像OpenStack这类“大帐篷”模式发展的开源社区软件。在云计算不断落地发展的现今,基于OpenStack的创业公司层出不穷,同时传统IT巨头也在借力OpenStack加速转型成为云计算公司,并且很多具有较强IT技术实力的企业也在基于OpenStack自建私有云,因此应用于生产环境中的OpenStack部署架构可以说是“百花齐放,百家争鸣”。在OpenStack高可用集群架构设计中,不同厂商均提出了自己的高可用设计架构,这其中以开源领导厂商RedHat和Pure Play OpenStack厂商Mirantis的高可用方案最为主流,而国内很多OpenStack创业公司初期的OpenStack高可用方案都源自RedHat OSP(OpenStack Platform)和Mirantis的Fuel系列OpenStack部署软件的定制化和二次开发,因此对于计划自建OpenStack高可用集群的用户而言,如果没有更好的高可用设计架构,则RedHat和Mirantis的高可用方案确实是非常值得借鉴的。图11-7所示为RedHat OSP系列的OpenStack高可用集群部署参考架构,关于RedHat OSP高可用架构的具体描述可以参考第2章中的相关部分。

从架构的整体设计上来看,RedHat提供的高可用架构充分考虑了企业级应用服务的高可用性,因此架构在设计和实现上都需要一定的技术实力和成本预算来支撑,对于有较多云计算人才和充分预算的企业,RedHat方案将是不错的选择。图11-8所示是Mirantis主导的OpenStack高可用架构设计方案之一。Mirantis是一家完全基于OpenStack的初创公司,其设计理论和方案以简单实用为主,在架构设计上不会显得冗余繁重,非常适合对云计算接触并不深入的年轻团队或者在成本预算上受到限制的部门或初创公司进行基于OpenStack的云计算建设参考。当然,除了Redhat和Mirantis的OpenStack高可用方案外,用户也可以综合各家所长实现自己的OpenStack高可用架构,只要整个架构的最终设计能够满足前期提出的IaaS服务需求分析即可。

image.png

图11-7 RedHat OSP高可用集群部署参考架构

对于生产环境而言,硬件服务器节点的拓扑情况通常根据OpenStack各个服务组件部署模式的不同选择而不同,由于OpenStack服务组件的部署具有极大的灵活性,因此在项目实施之初的设计阶段需要谨慎,以保证OpenStack集群在功能正常使用的同时,还应该具备高可靠性、高可用性和水平可扩展性。通常,为了保证生产环境的高可用,控制节点数目至少由3个物理服务器构成,而计算节点则根据实际的规划需求可以分为一期上线和后续二期扩容的形式来规划采购。对集群拓扑影响较大的可能是后端存储的采用,如果采用IBM、EMC、Netapp或华为等企业存储阵列,则OpenStack集群后端存储需要一个复杂的存储SAN网络支撑,图11-9所示即是比较典型的基于企业级高可用存储的OpenStack集群部署架构,OpenStack集群存储云盘由Cinder项目提供,Cinder后端可以使用LVM驱动或直接使用由特定存储厂商提供的存储驱动来使用底层存储。图11-9中,后端底层存储采用EMC VPLEX或IBM SVC存储异构虚拟化产品对底层不同存储厂商的存储阵列进行异构虚拟化封装,并统一由VPLEX或SVC作为Cinder的后端存储设备,而在Cinder的后端存储驱动矩阵中,用户可以轻易找到EMC和IBM提供的VPLEX和SVC驱动程序。

image.png

图11-8 Mirantis OpenStack高可用部署架构

在企业生产环境中,采用类似图11-9所示的OpenStack高可用集群有很多优势,首先冗余控制节点为OpenStack集群的控制层面提供了高可靠和可用性,同时将集群服务、负载均衡服务、消息队列服务、数据库服务和缓存服务等与计算无关的OpenStack基础服务与计算节点独立并集中到高可用控制节点统一部署管理。在以后的使用过程中,用户对集群的扩容仅限于计算和存储,而计算节点的扩容完全是Scale-out形式的,且独立于控制节点和后端存储阵列,计算节点扩容也仅需针对Nova-compute服务即可。此外,由于采用了传统企业级存储阵列,存储空间的扩容也变得极为简单,只需在线对存储阵列进行磁盘扩容即可,并且无须改变任何OpenStack集群配置。用户还可以利用VPLEX/SVC将数据同步到多个底层存储阵列,从而为关键数据提供更高层次的保护。采用类似图11-9所示的传统企业级存储架构的OpenStack高可用集群的不足之处在于成本较高,复杂的后端底层存储和SAN网络需要专门的存储管理员维护,并且多数存储阵列的扩容仍然是Scale-up形式(也有类似IBM XIV的Scale-out阵列)。在大容量扩容之后,有限的存储控制器处理能力和前后端带宽必然限制高并发用户对海量存储的访问,因此是否选用此类型的OpenStack高可用集群架构,需要用户根据自己的成本和业务慎重考虑。

image.png

图11-9 基于Cinder块存储的企业级OpenStack高可用私有云架构

与图11-9不同,图11-10采用的是基于分布式开源存储集群Ceph的OpenStack高可用架构。Ceph作为一种统一分布式存储集群,其在高可用、高可靠和故障自我愈合方面都有相当不错的表现,并且也是OpenStack中使用极为普遍的后端存储之一,目前其提供的文件系统存储CephFS、块存储RBD和对象存储RGW均为稳定版本。Ceph RBD不仅可以作为Cinder的块存储后端,还可以为Glance和Nova提供镜像存储和虚拟机临时磁盘空间。Ceph存储集群主要由Ceph监控节点和Ceph OSD节点组成,其中监控节点负责整个集群的健康检查并保存集群运行状态和提供集群数据恢复的依据;而OSD节点负责用户数据的存储。Ceph监控节点对整个Ceph集群的正常运行至关重要,可采用仲裁机制来保证监控节点的高可用,因此生产环境下建议监控节点数目最少为3个。图11-10中所示Ceph监控节点被放置到OpenStack控制节点上,当然用户可以使用独立的Ceph监控节点,或者将其部署到OSD节点上(为了实现控制与数据的分离,不建议OSD节点同时作为监控节点)。与传统企业级Scale-up扩容的存储阵列不同,Ceph OSD节点可以按需在线以Scale-out的形式扩容。从理论上讲,Ceph OSD节点越多,Ceph集群的可用性、可靠性和存储性能就越强大,因此Ceph存储集群并不存在理论上的容量极限,用户只需根据容量需求不断增加OSD节点用以存储数据,而不用担心Ceph客户端会受到影响。

image.png

图11-10 基于Ceph存储集群的企业级OpenStack高可用私有云架构

在生产环境中,采用基于Ceph存储集群的OpenStack高可用集群架构具有很多优势:首先,Ceph是一种开源分布式的存储集群软件,采用Ceph作为OpenStack集群的后端存储,在成本上相对传统企业级动辄上百万的存储阵列要实惠很多;其次,Ceph天生具备大规模集群高并发访问的优势,其节点越多优势越明显,非常适合大规模和海量数据存储的业务场景;Ceph存储集群完全采用Scale-out的形式扩容,避免了用户在存储扩容时性能瓶颈的顾虑;此外,Ceph提供的文件系统存储、块存储和对象存储可以同时满足用户不同的数据存储需求;其强壮的稳定性和数据自我恢复能力也是Ceph存储集群特有优势。不过,相对传统企业级存储阵列和SAN存储网络,Ceph依然很年轻,而且在Ceph较长一段时间的发展过程中,虽然其理论依据已经非常成熟,但是其科研院校的出身背景使得其在企业关键业务系统数据存储领域的使用却很少。正是OpenStack的出现带来了Ceph在企业应用中的普及,因此企业在使用Ceph存储集群为OpenStack提供后端存储时,需要投入相当多的人力对Ceph进行持续的研究跟进,方能解决突发的Ceph存储集群故障问题。


【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。