创新的Linux散布式存储系统——CephLinux中当前备受关注的开源散布式存储系统,除了我们之前提到的GlusterFS,当属Ceph。我们知道，GlusterFS最早被研讨于2003年（第Ⅰ次公开的时间是2007年)，那时的开源软件世界还没有能够承载PB级别的数据并且由成千上万的存储节点组成的大范围散布式存储系统，这方面的学术研讨是一个热点范畴,也是Ceph的作者Sage Weil攻读博士期间的研讨课题。Ceph项目发起于2004年，Sage随后在2006年的OSDI学术会议上发表了引见Ceph的论文，并在该论文的末尾提供了Ceph软件的下载链接，由此，Ceph开端广为人知。随着Ceph的热度不时增加，从2010年开端，来自Yahoo、Suse、Canonical、Intel等公司的一批开发者进入Ceph社区协作开发。Sage于2011年创建了Inktank 公司，主导了Ceph的开发和社区维护。2012年，Ceph被正式归入OpenStack体系，成为Cinder底层的存储完成，并随着OpenStack 的兴起而被普遍接受。2014年年中，Ceph的实践控制者Inktank 被RedHat 收购，成为RedHat旗下第2个重要的散布式存储产品(继续开源),往常Ceph曾经展开成为最普遍的开源软件定义存储项目。 下面说说Ceph的设计思想。在Ceph的设计中有如下两个亮点。
Ceph 整体提供了块存储RBD、散布式文件存储CephFS(相似于GlusterFS)及散布式对象存储RADOSGW三大存储功用,能够说是目前为数未几的集各种存储才干于一身的开源存储中间件。从如下所示的整体架构图能够看出，实践上RBD、CephFS 与RADOSGW只不外是系统顶层的一个“接口”，而Ceph真正的中心在于底层的RADOS(Reliable Autonomic DistributedObject Storage)存储子系统，让 Ceph成名的对象存储RADOSGW不外是基于RADOS完成的一个兼容Swift (OpenStack）和S3（亚马逊对象存储效劳）的REST 网关。  下面剖析一下RADOS的架构设计特性，如下所示是RADOS的组件图。  RADOS主要由一组OSD (Object Storage Device）组成存储集群，从上图能够看出，一个OSD其实就是一个运转了Ceph OSD守护进程的Linux X86效劳器（挂接很多硬盘的那种)，一组(几十到上千个）OSD节点组成了RADOS的存储集群。思索到散布式状况下集群中的某些OSD节点可能会宕机或者不可用，所以如何设计一个好的算法，能够将海量存储数据映射到大量的存储节点上，同时处置集群毛病问题所带来的影响，就成为RADOS需求处置的一个关键技术点。为此，Ceph 发明了特殊的CRUSH (Controlled Replication Under Scalable Hash)算法，能够把海量数据（Object）随机散布到上千个存储设备上，并保障散布平均、负载均衡及新旧数据混合在一同，在集群存储节点的扩缩容状况下仅仅发作少量的数据迁移。所以，CRUSH算法是Ceph的中心内容之一。与其他算法相比，CRUSH算法具有以下几个特性。
CRUSH算法里一个重要的概念就是PG(Placement Group)，PG是Ceph中十分重要的概念，能够将它看作分歧性哈希中的虚拟节点，在通常状况下，一个PG 会对应3个OSD以保障数据的高牢靠性存储请求。如下图所示，PG实线所指的OSD 为Primary OSD，虚线为两个副本OSD(Replicated OSD)，Primary PG担任该PG的对象写操作,读操作能够经过Replicated PG取得。经过引入 PG，CRUSH算法采用了二次映射的方式，完成了恣意Object到OSD 的定位才干。其基本思想是每个存入RADOS的数据单元（Object）都先经过Hash算法肯定归属于哪个PG，再从PG中找到对应的OSD设备。  CRUSH 算法在 Object存储过程中的作用如下。
下面以CephFS为例，看看RADOS是如何完成散布式文件存储功用的，下图显现了关键的过程。  首先,每个文件(File)都被依照一个特定的尺寸(默许是4MB)切分红若干个对象(Object),每一个Object 都有一个Object id (oid)，这种切分相当于RAID中的条带化过程。这样做的益处是:让大小不同的File变成最大size分歧并能够被RADOS高效管理的规范化 Object;能够完成大文件的并行IO读写才干。 其次，经过第1层哈希算法，得到某个Object对应PG的ID(pgid)，有了pgid之后，Client就得到PG对应的OSD列表（OSD1、OSD2、OSD3)，列表中的第1个OSD是 Primary OSD,剩下的都是副本OSD(好比在三副本方式下,两个副天职别为Secondary OSD和Tertiary OSD),随后Client 会向 Primary OSD 发起I/O央求。如下所示给出了某个Object对象写入Primary OSD的细致流程图。  Primary OSD在收到写央求后，分别向Secondary OSD和Tertiary OSD发起写入操作(见步骤2、3)，Secondary OSD和Tertiary OSD在各自完成写入操作后，将分别向Primary OSD 发送确认信息（步骤4、5)。Primary OSD在确认其他两个OSD的写入完成后，自己也完成数据写入，并向Client确认Object写入完成(步骤6)。在整个过程中，Client 只向 Primary OSD发起央求，而幕后的操作关于Client来说是透明的。RADOS这种高可用、多副本特性的代价就是文件写入时性能降低，但也能够经过大文件切分后的条带化并行写入才干及优化多副本的写入逻辑来弥补。 那么问题来了，RADOS 中的OSD节点信息、PG 信息、PG与OSD 映射的关系等信息被存储在哪里并且是如何被Client得到的呢?这就触及Ceph Monitor组件。Monitor的功用与ZooKeeper相似，作为RADOS集群的“大脑（元数据中心)”，Monitor担任维持RADOS集群的元数据、集群拓扑信息(Ceph Cluster Map）及集群状态信息并提供接口供Client调用。能够说，没有Monitor，Ceph就将无法执行一条简单的命令。有了Ceph Monitor，Ceph便能够容忍集群中某些OSD节点所发作的网络中缀、掉电、效劳器宕机、硬盘毛病等意外问题，并能够中止自动修复，以保障数据的牢靠性和系统可用性。 如下所示是Ceph Monitor的架构图。从这张图能够看到，Ceph Monitor维护了6个Map，分别是 Monitor Map、OSD Map、PG Map、Log Map、Auth Map及 MDS Map。其中 OSD Map和PG Map是最重要的两个 Map。OSD Map是Ceph集群中一切OSD的信息，一切OSD节点的改动如 OSD守护进程退出、新的OSD节点参与或者OSD节点权重发作变更等都会被反映到这张 Map上，岂但OSD Map会被 Monitor 控制，OSD节点和 Client也会从Monitor那里得到这张表。思索到OSD节点的数量可能十分多，因而Ceph Monitor并不主动与每个OSD节点通讯，而是由OSD主动汇报信息。此外，在OSD Map发作变更后，Monitor并不会发送OSD Map给一切Client，而是发送给那些需求了解变更的Client，好比若一个新的OSD 参与集群后招致某些PG发作迁移(PG对应的OSD Set需求改动)，那么这些PG的OSD都会得到通知。Ceph这种精心设计的音讯隔离广播机制能够说与网络中广播域的设计具有一定的相似性，都是为了尽可能减少无效的通讯，以顺应更大的集群范围。接下来说说PG Map。Monitor维护了每个Pool中一切PG 的信息，其中一个OSD 的角色会是Primary，其他OSD 的角色会是 Replicated。需求留意的是,每个OSD节点都会成为某些PG的Primary OSD,并成为其他PG的Replicated OSD,这个复杂的关系网就是PG Map。  我们看看Ceph Monitor完成的自动修复才干:当某个PG对应的Primary OSD被标记为down时，某个Replica就会成为新的Primary，并处置一切读写Object的央求，此时该PG的当前有效副本数是N-1，所以PG的状态被变更为Active+Degraded，过了M秒之后，假如还是无法衔接原来的 Primary OSD，则此OSD被标记为Out，Ceph 会重新计算PG到OSD Set的映射，以保障此PG的有效副本数一直是N。 Ceph Monitor还用到了Paxos 协议，缘由在于Ceph Monitor自身也是1个(3节点)集群，Paxos协议在这里有如下两个作用。
本文给大家解说的内容是架构解密从散布式到微效劳：深化解析散布式文件存储，创新的Linux散布式存储系统Ceph
|
万奢网手机版
