1、CAP理论
1) CAP 理论给出了3个基本要素:
-
一致性 (Consistency) :任何一个读操作总是能读取到之前完成的写操作结果;
-
可用性 (Availability) :每一个操作总是能够在确定的时间内返回;
-
分区可容忍性 (Tolerance of networkPartition) :在出现网络分区的情况下,仍然能够满足一致性和可用性;
CAP 理论指出,三者不能同时满足。对这个理论有不少异议,但是它的参考价值依然巨大。
这个理论并不能为不满足这3个基本要求的设计提供借口,只是说明理论上3者不可绝对的满足,而且工程上从来不要求绝对的一致性或者可用性,但是必须寻求一种平衡和最优。
对于分布式数据系统,分区容忍性是基本要求。因此设计分布式数据系统,很多时候是在一致性和可用性(可靠性)之间寻求一个平衡。更多的系统性能和架构的讨论也是围绕一致性和可用性展开。
2) OpenStack、Swift与CAP的工程实践
对照CAP理论,OpenStack的分布式对象存储系统Swift满足了可用性和分区容忍性,没有保证一致性(可选的),只是实现了最终一致性。Swift如果GET操作没有在请求头中包含’X-Newest’头,那么这次读取有可能读到的不是最新的object,在一致性窗口时间内object没有被更新,那么后续GET操作读取的object将是最新的,保证了最终一致性;反之包含了’X-Newest’头,GET操作始终能读取到最新的obejct,就是一致的。
在OpenStack架构中,对于高可用性需要进行很多工作来保证。因此,下面将对OpenStack结构中的可用性进行讨论:
构建OpenStack的高可用性(HA,High Availability)
2、OpenStack的高可用性(OpenStack HA)
要弄清楚怎么实现高可用性,就需要知道哪些服务容易出现不可靠。首先了解一些OpenStack的大致结构。
OpenStack由5大组件组成(计算nova,身份管理keystone,镜像管理glance,前端管理dashboard和对象存储swift)。
nova是计算、控制的核心组件,它又包括nova-compute、nova-scheduler、nova-volume、nova-network和nova-api等服务。借用http://ken.people.info的以下这幅图了解OpenStack的5大组件和功能:
下面这幅图描述了各个组件的功能和服务结构:
同其它大部分分布式系统一样,OpenStack也分为控制节点和计算节点两种不同功能的节点。控制节点提供除nova-compute以外的服务。这些组件和服务都是可以独立安装的,可以选择组合。
nova-compute在每个计算节点运行,暂且假设它是可信任的;或者使用备份机来实现故障转移(不过每个计算节点配置备份的代价相比收益似乎太大)。
控制节点的高可靠性是主要问题,而且对于不同的组件都有自己的高可靠性需求和方案。
(1)由于CotrolNode只有1个,且负责整个系统的管理和控制,因此当Cotrol
Node不能提供正常服务时,怎么办?这就是常见的单节点故障(SPoF,single
point of failure)问题。
高可用性基本上是没办法通过一台来达到目标的,更多的时候是设计方案确保在出问题的时候尽快接管故障机器,当然这要付出更大的成本。
对于单点问题,解决的方案一般是采用冗余设备或者热备,因为硬件的错误或者人为的原因,总是有可能造成单个或多个节点的失效,有时做节点的维护或者升级,也需要暂时停止某些节点,所以一个可靠的系统必须能承受单个或多个节点的停止。
常见的部署模式有:Active-passive主备模式,Active-active双主动模式,集群模式。
(2)那么如何构建冗余的控制节点?或者什么其它方法实现高可靠的控制?
很多人可能想到实现active-passive模式,使用心跳机制或者类似的方法进行备份,通过故障转移来实现高可靠性。Openstack是没有多个控制节点的,Pacemaker需要多种服务各自实现这种备份、监听和切换。
仔细分析控制节点提供的服务,主要就是nova-api、nova-network、nova-schedule、nova-volume,以及glance、keysonte和数据库mysql等,这些服务是分开提供的。nova-api、nova-network、glance等可以分别在每个计算节点上工作,RabbitMQ可以工作在主备模式,mysql可以使用冗余的高可用集群。
下面分别介绍:
1)nova-api和nova-scheduler的高可靠性
每个计算节点可以运行自己的nova-api和nova-scheduler,提供负载均衡来保证这样正确工作。
这样当控制节点出现故障,计算节点的nova-api等服务都照常进行。
2)nova-volume的高可靠性
对于nova-volume目前没有完善的HA(high availability)方法,还需要做很多工作。
不过,nova-volume由iSCSI驱动,这个协议与DRBD结合,或者基于iSCSI的高可靠的硬件解决方案,可以实现高可靠。
3) 网络服务nova-network的高可靠性
OpenStack的网络已经存在多种高可靠的方案,常用的你只需要使用--multi_host
选项就可以让网络服务处于高可用模式(high
availability mode),具体介绍见Existing
High Availability Options for Networking。
方案1:Multi-host
多主机。每个计算节点上配置nova-network。这样,每个计算节点都会实现NAT,
DHCP和网关的功能,必然需要一定的开销,可以与hardware gateway方式结合,避免每个计算节点的网关功能。这样,每个计算节点都需要安装nova-compute外还要nova-network和nova-api,并且需要能连接外网。具体介绍见Nova Multi-host Mode against
SPoF。
方案2:Failover
故障转移。能够4秒转移到热备份上,详细介绍见https://lists.launchpad.net/openstack/msg02099.html。不足之处是,需要备份机,而且有4秒延迟。
方案3:Multi-nic
多网卡技术。把VM桥接到多个网络,VM就拥有2种传出路由,实现故障时切换。但是这需要监听多个网络,也需要设计切换策略。
方案4:Hardware gateway
硬件网关。需要配置外部网关。由于VLAN模式需要对每个网络有一个网关,而hardware gateway方式只能对所有实例使用一个网关,因此不能在VLAN模式下使用。
方案5:Quantum(OpenStack下一个版本Folsom中)
Quantum的目标是逐步实现功能完备的虚拟网络服务。它暂时会继续兼容旧的nova-network的功能如Flat、Flatdhcp等。但是实现了类似multi_host的功能,支持OpenStack工作在主备模式(active-backup这种高可用性模式)。
Quantum只需要一个nova-network的实例运行,因此不能与multi_host模式共同工作。
Quantum允许单个租户拥有多个私人专用L2网络,通过加强QoS,以后应该能使hadoop集群很好的在nova节点上工作。
对于Quantum的安装使用,这篇文章Quantum
Setup有介绍。
4) glance、keystone的高可靠性
OpenStack的镜像可以使用swift存储,glance可以运行在多个主机。IntegratingOpenStackImageService
(Glance) with Swift介绍了glance使用swift存储。
一般情况下,OpenStack的分布式对象存储系统Swift的HA是不需要自己添加的。因为,Swift设计时就是分布式(没有主控节点)、容错、冗余机制、数据恢复机制、可扩展和高可靠的。以下是Swift的部分优点,这也说明了这点。
Built-in Replication(N copies of accounts, container, objects)
3x+ data redundancy compared to 2x on RAID
内建冗余机制
RAID技术只做两个备份,而Swift最少有3个备份
|
High Availability
高可靠性
|
Easily add capacity unlike RAID resize
可以方便地进行存储扩容
|
Elastic data scaling with ease
方便的扩容能力
|
No central database
没有中心节点
|
Higher performance, No bottlenecks
高性能,无瓶颈限制
|
6) 消息队列服务RabbitMQ的高可靠性
RabbitMQ失效就会导致丢失消息,可以有多种HA机制:
-
publisher confirms方法可以在故障时通知什么写入了磁盘。
- 多机集群机制,但是节点失效容易导致队列失效。
- 主备模式(active-passive),能够实现故障时转移,但是启动备份机可能需要延迟甚至失效。
在容灾与可用性方面,RabbitMQ提供了可持久化的队列。能够在队列服务崩溃的时候,将未处理的消息持久化到磁盘上。为了避免因为发送消息到写入消息之间的延迟导致信息丢失,RabbitMQ引入了Publisher Confirm机制以确保消息被真正地写入到磁盘中。它对Cluster的支持提供了Active/Passive与Active/Active两种模式。例如,在Active/Passive模式下,一旦一个节点失败,Passive节点就会马上被激活,并迅速替代失败的Active节点,承担起消息传递的职责。如图所示:
图 Active/Passive Cluster(图片来自RabbitMQ官方网站)
active-passive模式存在所说的问题,因此,基于RabbitMQ集群引入了一种双主动集群机制(active-active)解决了这些问题。http://www.rabbitmq.com/ha.html这篇文章详细介绍了RabbitMQ的高可靠部署和原理。
7) 数据库mysql的高可靠性
集群并不就是高可靠,常用的构建高可靠的mysql的方法有Active-passive主备模式:使用DRBD实现主备机的灾容,Heartbeat或者Corosync做心跳监测、服务切换甚至failover,Pacemaker实现服务(资源)的切换及控制等;或者类似的机制。其中主要使用Pacemaker实现了mysql的active-passive高可用集群。
一个重要的技术是DRBD:(distributed replication block device)即分布式复制块设备,经常被用来代替共享磁盘。
它的工作原理是:在A主机上有对指定磁盘设备写请求时,数据发送给A主机的kernel,然后通过kernel中的一个模块,把相同的数据传送给B主机的kernel中一份,然后B主机再写入自己指定的磁盘设备,从而实现两主机数据的同步,也就实现了写操作高可用。DRBD一般是一主一从,并且所有的读写操作,挂载只能在主节点服务器上进行,,但是主从DRBD服务器之间是可以进行调换的。这里有对
DRBD 的介绍。
HAforNovaDB
- OpenStack介绍了只使用共享磁盘而没有使用DRBD,通过Pacemaker实现OpenStack的高可靠。
NovaZooKeeperHeartbeat介绍了使用ZooKeeper作心跳检测。
Galera是针对Mysql/InnoDB的同步的多master集群的开源项目,提供了很多的优点(如同步复制、读写到任意节点、自动成员控制、自动节点加入、较小延迟等),可以参考。
Pacemaker与DRBD、Mysql的工作模式可以参考下图:
其它的方案,根据 MySQLPerformance Blog 的说法,MySQL几种高可用解决方案能达到的可用性如下:
3、构建高可用性的OpenStack(High-availabilityOpenStack)
一般来说,高可用性也就是建立冗余备份,常用策略有:
- 集群工作模式。多机互备,这样模式是把每个实例备份多份,没有中心节点,比如分布式对象存储系统Swift、nova-network多主机模式。
- 自主模式。有时候,解决单点故障(SPoF)可以简单的使用每个节点自主工作,通过去主从关系来减少主控节点失效带来的问题,比如nova-api只负责自己所在节点。
- 主备模式。常见的模式active-passive,被动节点处于监听和备份模式,故障时及时切换,比如mysql高可用集群、glance、keystone使用Pacemaker和Heartbeat等来实现。
- 双主模式。这种模式互备互援,RabbitMQ就是active-active集群高可用性,集群中的节点可进行队列的复制。从架构上来说,这样就不用担心passive节点不能启动或者延迟太大了?
总之,对于OpenStack的优化和改进不断,对于OpenStack的部署和应用也在不断尝试和发展。需要实践调优。实践非常重要,好的设计和想法需要实践来验证。
上面分别对OpenStack的各个服务进行了说明,我纯属抛砖引玉。希望多实践(可参考前篇一键部署OpenStack),更希望有时间的朋友能够把一些高可靠性方案的部署添加到OneStack/HAStack。关于OpenStack高可用性的讨论和说明,大家可以多看看以下这些地方:
Kayven(Hily.Hoo@gmail.com)
分享到:
相关推荐
资源名称:OpenStack高可用集群(上册):原理与架构 内容简介:本书是一本理论与实战结合,并全面讲解OpenStack相关技术知识点的书籍。书中首先介绍了与OpenStack相关的基础架构软件,同时深入讲解和分析了...
openstack高可用配置文档,openstack高可用配置文档,openstack高可用配置文档,openstack高可用配置文档,openstack高可用配置文档
OpenStack高可用集群详细指南
资源名称:OpenStack高可用集群(下册):部署与运维内容简介:这是一部从原理、架构、部署、运维4个方面系统、深入讲解如何构建高可用OpenStack集群的著作,在理论和实践两个维度为构建构建高可用OpenStack集群提供...
这是一部从原理、架构、部署、运维4个方面系统、深入讲解如何构建高可用OpenStack集群的著作,在理论和实践两个维度为构建构建高可用OpenStack集群提供了完整的解决方案。本书从OpenStack终端用户的角色出发,以面向...
OpenStack HA 高可用性参考,如何配置OpenStack高可用系统
本文档是本人在京东时,梳理整理的Openstack是高可用的部署方案,
第 9 章OpenStack 高可用与容错机制唯有认识自我,方能超越极限!—阿尔伯特·爱因斯坦(Albert Einstein)到目前为止,相信你已经掌握了运行
Openstack各个组件的HA以及整体的HA 日志分析与错误排查
openstack-HA高可用部署
《OpenStack高可用集群(下册):部署与运维》
本书从OpenStack终端用户的角色出发,以面向生产系统的OpenStack高可用集群建设为主线,对部署OpenStack高可用集群所依赖的各个基础技术栈和OpenStack核心组件进行了详细的原理讲解,并以实战部署的形式演示了...
针对计算存储一体的场景下,整个 openstack平台由以下两种类型的节点组成。 openstack HA高可用规划与详细搭建步骤
RedHat HA cloud 云计算 架构 高可用 生产环境 云 IAAS RedHat HA cloud 云计算 架构 高可用 生产环境 云 IAAS
为保障云平台的稳定可靠运行,笔者通过分析高可用集群与负载均衡技术,设计了Pacemaker+Haproxy技术解决方案,并对OpenStack的核心组件数据库和镜像服务进行高可用部署,实现了OpenStack云平台的高可用性。实践证明,该高...
一个介绍Openstack的相关基础知识的文档,可以帮助想要了解云计算架构的,初学者。
摘要:对任何一个分布式系统,高可用HA都是最核心的设计目标之一,而OpenStack这样一个复杂系统,高可用更是涉及到多个层面,本文重点解析了OpenStack各层次的HA设计。【编者按】本文从OpenStack架构入手,剖析了...
OpenStack高可用集群(上册):原理与架构.part1.rar 电子书一共350MB 分成2部分上传,一部分180MB,另外一部分是170MB 下半部分名称是“OpenStack高可用集群(上册):原理与架构.part2”
A High Availability (HA) cluster is a set of servers (nodes) managed by clusterware to work together for minimizing application downtime as much as possible. Clusterware enables servers to ...