1.2Ceph的三大存储及其应用

Ceph的三大存储及其应用

对于上层应用来说，使用ceph集群的方式有4种：

• 通过LIBRADOS访问集群
• 通过RADOSGW访问集群
• 通过RBD访问集群
• 通过CEPHFS访问集群

通过LIBRADOS访问集群

ceph提供了一系列接口用于操作集群，这些接口支持的开发语言包括python、java、c/c++、php，开发人员只需安装好对应的包，即可在自己开发的程序中调用librados接口访问集群，进行数据的上传、下载操作，在一些定制化业务场景中可以快速实现产品的开发。

通过RADOSGW访问集群

RADOSGW是ceph集群的S3网关程序，它实现了ceph集群的对象存储功能，使用基于HTTP的S3协议为S3客户端提供集群存储服务，对于应用来说，只需要将S3访问路径指向该网关，提供Access key和Secret key，即可访问对应用户的对象存储资源。

S3最早是Amazon平台提供的一种对象存储服务协议，它提供了一个可扩展的存储桶Bucket，用户可以通过S3客户端实现在Bucket上的数据写入、读取、修改等操作，操作粒度为对象。对象存储服务支持RESTful API，开发人员可以通过API以编程方式使用该服务。

对象存储的特点包括：

1. 可用性：对象存储的高可用性是通过在多个区域或设备上存储数据的冗余来提高数据的可靠性和持久性。
2. 可扩展性：对象存储存储桶可以按需扩展，可以根据用户的需求增加或减少存储资源。
3. 安全性：S3协议提供了安全控制，包括访问控制策略和数据加密等，以确保用户的数据安全。
4. 管理功能：S3协议提供了丰富的数据管理功能，如数据备份和恢复、日志记录等，以便用户更好地管理和保护数据。

ceph的RADOSGW服务实现的S3功能与amazon的S3功能保持统一，能够支持对象的上传、下载、修改、删除等操作，在开发接口上也没有区别。

通过RBD访问集群

RBD(Rados Block Device)是ceph集群实现的块存储功能，在集群创建RBD后，可以使用map的方式将该块设备直接映射到某台主机上，成为该主机的一个网络块设备，也可以通过一些块网关工具增加鉴权功能后将RBD导出，应用通过块网关映射即可得到集群的块设备，进而使用集群的块存储资源。

典型的便是linux上的KVM虚拟机的虚拟磁盘，将ceph的RBD映射到宿主机后，宿主机可以直接使用该块设备创建KVM虚拟机，如此依赖该虚拟机的数据将全部存储到ceph集群中，利用ceph集群的高稳定性、可靠性保障虚拟机的数据安全和运行安全。

通过CEPHFS访问集群

CEPHFS是ceph集群实现的文件存储功能，与RBD 类似，在集群创建fs后，可以使用mount的方式将ceph集群的fs挂载到目标主机上，成为该主机的一个网络文件系统目录，它是POSIX实现，与NFS在使用上几乎没有区别。

从ceph集群提供及实现功能的方式来看，上层应用不管通过何种访问使用集群资源，最终在使用资源上都是到达RADOS层，在RADOS层完成操作后就可以返回，ceph在RADOS上实现了统一的接口标准，其实现的本质是基于存储池对硬件资源的池化管理，不管上层应用的业务模式和访问协议，在RADOS上都统一为对象操作，这也是ceph被称为统一存储的原因。

Ceph的优缺点

任何系统设计及实施都有其优点和弊端，ceph的优点在于：

• 开源

  开源是非常重要的一个优点，尤其对于商用的环境，开源可以让商业性质的应用无需缴纳费用而对软件进行修改、运行，这对于盈利为目的的公司来说非常关键。

• 规模大

  ceph设计就是面向PB级别存储，在如今的大数据时代背景下，PB级别存储集群越来越常见，生产级别单块磁盘已经突破18TiB，高密度的30~36盘服务器机器在插满磁盘的情况下，3台组成的小集群裸存储容量就能轻松达到PiB级别，当集群规模增长到数十台甚至数百台，单个集群的容量便能达到数十PiB。

• 弹性好

  ceph设计为分布式系统，这意味着存储集群可通过增减节点、磁盘的方式实现容量的弹性控制，该特性在生产环境应用中非常重要，扩容理论上可以无限拓展，缩容也可以根据规划做到数据的高可靠性。

• 可靠性高

  高可靠性是ceph设计的亮点之一，其支持副本模式与纠删码模式为数据做可靠性冗余，且在故障处理方面，有很强的自愈能力，通过抽象底层实现，各类不同的硬件环境。

• 社区活跃

  使用开源软件最重要的一个参考点就是社区的活跃度，对于要用到生产环境，或者进行魔改再上生产环境的产品来说，开源社区的持续支持至关重要，同时，社区活跃意味着项目火爆，用的人多，那么发现的问题就会多，产品就更容易得到改进。

ceph的缺点在于：

• 复杂

  分布式系统本身就是复杂的，ceph复杂性除了分布式原理外，还有其为数据可靠性所设计的各种机制，且在新版本ceph使用Bluestore后，用户进程直接管理磁盘，使得原本就复杂的IO子系统提高了运维管理难度，大规模集群涉及的内容，如网络拓扑涉及、时钟同步、防火墙、负载均衡等，都给运维管理ceph集群的人员提出了很高的要求。

• 性能表现与商业存储有一定差距

  ceph的设计理念相当一部分是围绕数据的可靠性来设计的，如非常复杂的pg状态机，在机制上为了保证数据的可靠，就不得不在一定程度上牺牲读写性能，实际生产环境中，不少人认为，ceph集群使用了那么多的节点和磁盘，性能应该非常出色，其实不然，在吞吐性能上，由于使用了大量的磁盘，集群对存储资源抽象为存储池后，会有相当不错的表现，但是对于IOPS衡量的小块读写，却不台如人意，即使使用全闪存的集群，在实际性能表现上与其他的商用存储仍有差距。

• 木桶效应明显

  ceph通过存储池的方式，对存储资源，也就是磁盘，进行池化管理，通过使用PG的抽象，数据在读写时能够依靠算法，计算出具体的磁盘位置，然后进行读写，显然，当计算结果落到了故障的磁盘上(比如磁盘坏道引起的缓慢)，就无法避免读写的缓慢、阻塞甚至超时失败，而且，OSD磁盘发生故障并被处理后，集群为了保障数据的可靠性，将自动进行数据的回填恢复，这就会占用不小的集群IO资源，造成业务的感知。

作为面向大规模集群的分布式存储，ceph在设计上尽最大努力保障数据的可靠性、完整性，为此，ceph在数据冗余设计、故障检测与恢复、分布式事务一致性、集群弹性等方面做了非常多的努力，一定程度上牺牲了可用性和性能，这是一种有意义的取舍。