1.Ceph架构
Ceph底层核心是RADOS。Ceph架构图如图
·RADOS:RADOS具备自我修复等特性,提供了一个可靠、自动、智能的分布式存储。
·LIBRADOS:LIBRADOS库允许应用程序直接访问,支持C/C++、Java和Python等语言。
·RADOSGW:RADOSGW是一套基于当前流行的RESTful协议的网关,并且兼容S3和Swift。
·RBD:RBD通过Linux内核(Kernel)客户端和QEMU/KVM驱动,来提供一个完全分布式的块设备。
·Ceph FS:Ceph FS通过Linux内核(Kernel)客户端结合FUSE,来提供一个兼容POSIX的文件系统。
具体的RADOS细节以及RADOS的灵魂CRUSH(Controlled Replication Under Scalable Hashing,可扩展哈希算法的可控复制)算法
2.Ceph设计思想
Ceph是一个典型的起源于学术研究课题的开源项目。虽然学术研究生涯对于Sage而言只是其光辉事迹的短短一篇,但毕竟还是有几篇学术论文可供参考的。可以根据Sage的几篇论文分析Ceph的设计思想。
理解Ceph的设计思想,首先还是要了解Sage设计Ceph时所针对的应用场景,换句话说,Sage当初做Ceph的初衷的什么?
事实上,Ceph最初针对的应用场景,就是大规模的、分布式的存储系统。所谓“大规模”和“分布式”,至少是能够承载PB级别的数据和成千上万的存储节点组成的存储集群。
如今云计算、大数据在中国发展得如火如荼,PB容量单位早已经进入国内企业存储采购单,DT时代即将来临。Ceph项目起源于2004年,那是一个商用处理器以单核为主流,常见硬盘容量只有几十GB的年代。当时SSD也没有大规模商用,正因如此,Ceph之前版本对SSD的支持不是很好,发挥不了SSD的性能。如今Ceph高性能面临的最大挑战正是这些历史原因,目前社区和业界正在逐步解决这些性能上的限制。
在Sage的思想中,我们首先说一下Ceph的技术特性,总体表现在集群可靠性、集群扩展性、数据安全性、接口统一性4个方面。
·集群可靠性:所谓“可靠性”,首先从用户角度来说数据是第一位的,要尽可能保证数据不会丢失。其次,就是数据写入过程中的可靠性,在用户将数据写入Ceph存储系统的过程中,不会因为意外情况出现而造成数据丢失。最后,就是降低不可控物理因素的可靠性,避免因为机器断电等不可控物理因素而产生的数据丢失。
·集群可扩展性:这里的“可扩展”概念是广义的,既包括系统规模和存储容量的可扩展,也包括随着系统节点数增加的聚合数据访问带宽的线性扩展。
·数据安全性:所谓“数据安全性”,首先要保证由于服务器死机或者是偶然停电等自然因素的产生,数据不会丢失,并且支持数据自动恢复,自动重平衡等。总体而言,这一特性既保证了系统的高度可靠和数据绝对安全,又保证了在系统规模扩大之后,其运维难度仍能保持在一个相对较低的水平。
·接口统一性:所谓“接口统一”,本书开头就说到了Ceph可以同时支持3种存储,即块存储、对象存储和文件存储。Ceph支持市面上所有流行的存储类型。
根据上述技术特性以及Sage的论文,我们来分析一下Ceph的设计思路,概述为两点:充分发挥存储本身计算能力和去除所有的中心点。
·充分发挥存储设备自身的计算能力:其实就是采用廉价的设备和具有计算能力的设备(最简单的例子就是普通的服务器)作为存储系统的存储节点。Sage认为当前阶段只是将这些服务器当做功能简单的存储节点,从而产生资源过度浪费(如同虚拟化的思想一样,都是为了避免资源浪费)。而如果充分发挥节点上的计算能力,则可以实现前面提出的技术特性。这一点成为了Ceph系统设计的核心思想。
·去除所有的中心点:搞IT的最忌讳的就是单点故障,如果系统中出现中心点,一方面会引入单点故障,另一方面也必然面临着当系统规模扩大时的可扩展性和性能瓶颈。除此之外,如果中心点出现在数据访问的关键路径上,也必然导致数据访问的延迟增大。虽然在大多数存储软件实践中,单点故障点和性能瓶颈的问题可以通过为中心点增加HA或备份加以缓解,但Ceph系统最终采用Crush、Hash环等方法更彻底地解决了这个问题。很显然Sage的眼光和设想还是很超前的。