需求
调研Ceph一个多月了，大分部时间是在研究Ceph的架构以及原理。对于Ceph整体的架构，通过在Ceph官网上的学习以及自己的一些总结，也算是有了一个基本的理解。
正如上面说到的，学习的资料大都是来自于Ceph官网，其实官网上提供的资料已经是相当的详细和全面了。当然，还有Ceph中文社区提供的翻译资料，下面是相关链接：
Ceph官方文档
至于，为什么自己要做这样的一个翻译， 一是：想通过对这些文档的翻译，加深自己对Ceph架构的一些理解。二来呢：挺悲催的，过年没回家，一个人的北京，总之时间上来说，还算挺充裕的！
架构
Ceph 在同一平台上实现并且提供了包括对象、块设备、和文件的存储服务，拥有高可靠、易于管理、开源等特点。使用Ceph作为存储架构，能够使得公司的互联网基础设施架构和公司员工个人的才能得到很大的改造和提升，当然也表现在易于实现大量数据管理方面。Ceph有着极易扩展的特性–上千数量的客户端可同时访问perabytes到exabytes数量级的数据。一个Ceph节点包括存储硬件设备以及智能的守护进程，而一个ceph存储集群又包含着大量的节点，Ceph节点之间相互通讯，联系以实现动态的数据副本拷贝和数据重新分配。
Ceph集群架构
基于RADOS，使用Ceph作为存储架构，可实现一个极易扩展的Ceph存储集群。RADOS – A Scalable，Reliable，Storage Service For Petabyte-scale Storage Clusters
一个Ceph存储集群包含以下两种类型的进程：
- Ceph 监视器
- Ceph OSD 守护进程
Mon维护着一个集群索引图表的主要副本。一个集群的Mons实现集群的高可用，集群Mon守护进程不可以退出。存储集群的客户端通过Mon来检索，以拷贝得到最新的集群索引图表。
OSD守护进程会检查自身的运行状态和其它OSDs的状况，而后将检查情况汇报给Mons
存储集群客户端和每一个Ceph OSD 守护进程使用CRUSH算法来有效的计算数据的存储位置，而不是依赖于集中式的索引图表。较之于其它的存储架构，Ceph的显著特点在于，通过librados为Ceph存储提供了本地的存储实现接口，并且基于librados可定制许多应用服务接口。
数据存储
Ceph存储集群数据来自于Ceph客户端–无论是通过Ceph块设备存储、Ceph对象存储、Ceph文件存储还是基于librados，自己创建的客户端存储接口实现的数据存储，存储的数据都是以objects的形式存在的。每个object对应一个在文件系统上显示的file，存储在OSD中。Ceph OSD守护进程处理I对存储磁盘的读/写操作
Ceph OSD 守护进程将所有的数据按照objects的存储形式存储在一个扁平化的命名空间内（例如：一个没有层级关系的目录）。一个object拥有一个id，二进制数据以及元数据（包括一个多对name/vaule的集合）。语义（即：命名解析的格式）由Ceph客户端决定。例如：CephFS使用元数据存储file的属性如，file拥有者、创建的数据、最近修改的数据，等等。
注：一个Ceph object ID在整个存储集群中都是唯一的，不仅仅是在本地文件系统中。
可扩展和高可用性
在传统的架构中，客户端试图与集中式的组件（例如：网关、代理、API、facade代理等等）进行通讯，像是一个单点连接入复杂子系统。这就必然使得集群的性能和可靠性受到限制，导致了单点故障的产生（例如：中心组件出现故障，可能使得整个系统都崩溃）。
Ceph消除了中心网关，使得客户端能够直接连接OSD守护进程进行通讯。OSD进程在其他Ceph节点上实现副本的创建使得保护数据的安全合法和高可用性。Ceph同样也使用集群的Mons确保数据的高可用性。为消除集中化的管理，Ceph使用了CRUSH算法。
CRUSH算法
Ceph客户端和OSD守护进程使用CRUSH算法能实现更高效的计算object存储位置，而不是依赖于查找中心索引图表。较之于以前的管理，CRUSH提供了一个更好的数据管理机制，能够大规模比率的给在集群中的所有客户端和OSD守护进程分配计算任务。CRUSH使用智能的数据拷贝来确保resiliency，这更加适用于高密度的基金群存储。
集群索引图表
Ceph 依赖于客户端和OSD守护进程，拥有特殊的集群拓扑结构，包括5张索引图表组成了所谓的“集群索引图表”
Mon Map：包括集群的fsid、位置、命名地址和每个Mon端口号，同时还指示了当前的版本号，什么时候索引图表被创建，最近一次被修 改。查看Mon运行情况：ceph mon dump
OSD Map：包括集群的fsid，图表什么时候被创建和最近一次被修改，pools的列表，副本数，PG数量，OSDs及相应状态的列表。查看：ceph osd dump
PG Map：包含PG的版本信息，它的时间标识，最新的OSD索引图表版本，详尽的比率I/O信息，以及每一个放置组的详细信息如：PG ID、UP Set、Acting Set、PG的状态（例如：active + clean），以及每个pool的静态数据空间使用率。查看：ceph pg dump
CRUSHMap：包含存储设备，故障域层级（例如：设备、host、rack、row、room、等），以及实现数据存储时如何避免故障域的规则。查看CRUSH map 执行：ceph osd getcrushmap -o {filename}; 然后进行反编译执行：crushtool -d {comp-crushmap-filename} -o {demomp-crushmap-fielname}。之后就可以使用cat命令查看反编译出来的存放于指定文件的crushmap信息了。
MDS Map：包含当前最新的MDS索引图表版本、创建图表的时间、最近一次修改的时间。同时也包含元数据存放的容器pool的信息，元数据服务器状态列表信息。查看：ceph mds dump
每张索引图表维护着一特定Ceph集群组件迭代变化的操作记录。Mons维护着集群索引图表的主副本信息，包括：集群的成员、状态、变化化、以及整个Ceph存储集群的运行状态。
高可用Mons
在Ceph客户端读写数据之前，客户端必须通过连接Mon来获取最新的集群索引图表副本。Ceph存储集群在只有一个Mon下也能够正常工作，不过这样会导致单点故障。
为提升可用和容错性能，Ceph实现了集群多Mons。在有多个Mons的集群中，延迟（如：更新索引图表延迟）等诸多原因可能导致一个或多个Mon的状态更新落后于实际的集群环境。因此， Ceph Mons之间必须进行协商以更新到实际的集群环境。Ceph 通常是使用Mons多数原则（例如：1、2:3、3:5、4:6）和Paxos算法来选举一致认同的集群环境状态版本。
高可用认证技术
为识别用户和防范来自hacker的攻击，Ceph实现了cephx的认证系统用于识别用户和守护进程
注：cephx协议并不处理数据的加密数据—-在数据传输过程（例如：SSL/TLS)或是在数据在本地存放时
cephx使用共享的密钥用于认证，意味着双方客户端和集群Mon都有一份客户端的密钥。认证协议确保了双方能够通过使用密钥副本实现交互连接而不用暴露自己拥有的密钥。这就实现了彼此的认证，意味着集群确认了客户拥有密钥，同时客户端确认集群拥有密钥的副本。
一个Ceph KEY的可扩展特性表现在于，它避免了集中式的接口认证，Ceph客户端能够直接与OSDs连接。为了保护数据的安全合法，Ceph实现了cephx的认证系统，认证的用户可启动Ceph集群客户端运行模式。cephx协议操作方式与Kerberos（一种网络认证协议）有着相似之处
一个用户（以某种方式，主要是有I/O请求时）引起了Ceph客户端尝试连接一个Mon，不同于Kerberos的是，每一个Mon能认证用户和分发密钥，因而在使用cpehx时没有单点故障或性能瓶颈。集群Mon返回的一个认证数据结构体就如同Kerbero中的ticket，包含一个session key（可理解为中间或短期密钥）用于认证从而获取Ceph服务。这种session key本身是通过用户的永久密钥加密的，因而只有特定用户能够请求Ceph Mon服务。客户端使用session key请求获取需要的Ceph服务，Mon为用户提供一张ticket用于客户端与相应OSDs连接的认证。Mons和OSDs共用一个密钥，因此客户端可以使用由集群中Mon、OSD、MDS任意服务提供的ticket。与Kerberos相同的是，一旦cephx ticket过期了，hacker就不能使用过期的ticket或session key做出破坏性的行为。即，只要用户密钥在过期之前没有暴露，这种规范的认证就能够防御hacker通过伪造虚假的信息或是修改用户的合法信息实现与中间服务（如:信息中转或交易平台服务器）的连接通讯。
使用cephx，管理员首先须得创建用户。如下图示，client.admin 用户在命令行执行 ceph auth get-or-create-key 产生一个用户名及一个密钥。Ceph auth子系统产生的用户名和密钥，拷贝一份副本存储在Mons中，而后将用户的密钥传递回client.admin用户当中。这就意味客户端和Mon共用一个相同的密钥。
注：client.admin用户必须在安全模式下提供用户ID和密钥给用户
为实现与Mon的认证，客户端可使用用户名和Mon生成的seeion key（与用户名绑定且加密了的中间key）作为认证信息。然后，Mon将加密了的ticket交回给客户端，客户端再使用共享的密钥进行解密以检验得到的session key。session key 用于当前时间段用户身份的校验。客户端请求获取一张ticket代表签署了会话密钥的用户。Mon生成一张ticket，对其进行加密然后传递给客户端。最后，客户端对ticket进行解密并且使用它作为请求获取集群OSDs以及MDS服务的凭证。
cephx协议认证能实现客户端设备与Ceph服务的持续通讯。随着初始化认证后，每条传递在客户端和服务器之间的信息，可通过使用ticket充当认证Mon、OSDs、MDS的共享密钥。
这种认证的安全防护措施是适用于Ceph客户端和Ceph服务器之间的。还没用扩展到Ceph客户端之外的范围。如果用户是通过远程连接访问客户端，那么Ceph的认证机制并不适用于用户主机和客户端主机之间的安全连接。
超大规模智能守护进程实现
在很多集群架构当中，集群成员的主要目的是让一个中心组件接口知道哪些节点是能过连接的。然后，集中化的接口通过分发连接资源为客户端提供服务。使用这些架构作为存储解决方案，在数据处理规模达到perabyte到exabyte时，将出现巨大的性能瓶颈。
Ceph消除了上述的瓶颈：实现了OSDs守护与客户端交互的智能化。像Ceph客户端一样，每个OSDs知道集群中其它OSDs的状况。这就使得OSD守护进程能够直接与其它OSD守护进程与Mons直接通讯。除此之外，Ceph客户端也能实现直接与OSD守护进程交互。
实现了Ceph客户端、Mons、OSD三者之间任意交互意味着Ceph的守护进程能够使用任意节点的CPU和RAM内存资源完成甚至是超额的任务（如：数据I/O操作），这种智能化的实现使得有如下的几个好处：
实现OSDs服务直连客户端：任何的网络设备都有支持并发连接数量的限制，一个集中化的系统在可扩展性方面有着更小的物理限制。通过Ceph客户端直连OSD守护进程，消除了单点故障并且提高了性能以及总的系统容量。当有必要的时候，Ceph客户端能维持一个会话使用一个特殊的OSD守护进程胡不需要申请获取中心服务。
OSD成员和状态：OSD守护进程加入集群中并汇报自身的运行状态。在最低状态等级，OSD守护进程状态有up或down两种：服务是否运行或已经关闭。如果在集群中一个OSD守护进程是down和in，那么指示着OSD守护进程运行是失败。为什么指示是失败，因为如果一个OSD守护进程没有运行，那么OSD守护进程是无法将down状态汇报给Mon的。Mon能通过周期性的ping一个OSD守护进程来确保OSD守护进程是处于运行状态的。然而，Ceph同样授权OSD能够尝试去判定（OSDs间心跳检测）相邻的OSD运行状态是否为down，从而更好的更新crush索引图表以及汇报最新的状态给Mon。这就意味着Mon能够实现轻量级的进程。
数据清理：为了维护数据的一致性和合法，OSD守护进程实现了放置组object数据的擦除。即：OSD守护进程能够实现一个放置组内特定object元数据与不同放置组内的objec元数据副本的比较。擦除清理（周期通常一天）捕获漏洞和系统错误。OSD守护进程同样也进行深度的数据清理，实行数据位对位的对比校验数据的深度清理（周期通常一周）查找清理数据驱动盘上的坏扇区，一般普通清理是无法实现的。
副本：与Ceph客户端一样，OSD守护进程使用crush算法。不同的是，OSD守护进程使用算法计算集群objects副本数据存储位置，同时实现数据的均衡。如下图示：一个典型的数据write情景，一个客户端使用CRUSH算法计算出数据object的集群存储位置，而后将object映射到一个poo以及一个pg，然后查看CRUSH图表来确定主pg中的主OSD。
客户端向主OSD中指定的pg写入object，然后，主OSD根据拥有的CRUSH索引图表副本找到次OSD和第三个OSD。找到后，依次将主OSD中object的数据拷贝到次OSD和第三OSD中，最终完成了所有操作后，返回一个确认响应给客户端，告知客户端已完成write操作。
实现上述特殊的数据副本存储方式，在确保了数据安全和高可用性的同时，也减轻了Ceph客户端的操作任务。
集群动态管理
在实现集群的可扩展和高可用性能的过程中，其实就解释了Ceph如何使用CRUSH算法，集群的智能守护进程实现了扩展和维护着集群的高可用。Ceph设计的关键点就在于自动化、自修复、和智能OSD守护进程。下示内容的介绍，让我们更加深入了解CRUSH如何使得云存储基础架构方案真正的实现数据存储，动态智能的均衡集群数据负载和修复错误。
关于Pools：
Ceph存储系统引入了Pool的概念，表示集群实现存储object的逻辑分区。
Ceph客户端从Mon得到一份集群索引图表副本，根据图表将object写入Pools中。Pool的大小和Pool的副本数，由CRUSH规则和PG的数量决定。
Pools有至少如下的参数：
- 所有权/存取object的权限
- PG数量
- CRUSH规则集的使用（实现指定规则集使用方式）
映射：PGs –> OSDs
每个池的放置组的数量。CRUSH动态映射PGS至OSD。当CEPH的客户端存储对象时，CRUSH会映射每个对象到一个配置组。
映射对象至配置组在CEPH的OSD守护和CEPH的客户端之间创建了一个间接层。CEPH的存储集群必须是能够增长（或收缩）和平衡它的动态存储对象。如果CEPH的客户端“知道”哪个CEPH的OSD守护有哪些对象，这将创建CEPH的客户端和CEPH的OSD守护程序之间的紧密耦合。相反，CRUSH算法映射每个对象到配置组，然后映射每个配置组到一个或多个CEPH的OSD守护。当新的CEPH的OSD守护和底层的OSD设备联机时，这个间接层允许CEPH的动态平衡。下图描述了CRUSH如何映射对象至配置组，配置组至OSD。
利用CRUSH映射和CRUSH算法的副本，客户端可以在读出或写入一个特定的对象时准确地计算OSD。
计算PG的IDs
当Ceph的客户端绑定到一个CEPH监视器，它会撷取群集映射最新副本 。集群映射内，显示器的OSD和元数据服务器集群中的所有被客户端知道，但是，它不知道任何有关对象的位置。
通过计算得到的对象位置：
客户端唯一所需要的输入的是对象ID和池。原因很简单：Ceph的数据存储在被命名的池（例如，“liverpool”）。当一个客户端想存储命名的对象（如，“john”，“paul”，“george”，“ringo”，等等），使用对象名，一个哈希数的OSD集群和池名称计算出配置组。Ceph的客户端使用下列步骤来计算PG的ID。
- 客户端输入池ID和对象ID。（例如，池=“liverpool”和对象ID =“john”）
- CRUSH取得的对象ID和散列它。
- CRUSH计算散列模数的OSD。（例如，0x58）得到一个PG的ID。
- CRUSH得到池ID池的名称（如“liverpool”= 4）
- CRUSH预先考虑到PG ID对应池ID（例如，4.0x58）。
计算对象的位置的速度远远超过非正式会话执行对象的位置查询。CRUSH算法允许客户端计算对象存储，使客户端能够联系主OSD存储或检索对象。
对等操作与集
在前面的章节中，我们注意到，Ceph的OSD守护程序检查彼此的心跳和报告至Ceph的监视器。Ceph的OSD守护程序做的另一件事被称为“对等操作”，这是将存储所有的OSD存储布局组（PG）与所有对象（和它们的元数据）PG状态保持一致的过程。事实上，Ceph的OSD守护进程向Ceph的监控器报告对等操作失败。对等操作的问题通常会自行解决，但是，如果问题仍然存在，您可能需要参考“Troubleshooting Peering Failure ”部分。
注意：一致的状态并不意味着PG的最新内容。
Ceph的存储群集被设计用来存储至少一个对象的两个副本（即，大小 = 2），这是最低的数据安全性的要求。对于高可用性，Ceph的存储集群存储一个对象要（例如，大小=3和最小尺寸=2）两份以上的副本，以便它可以继续运行在 degraded状态，同时保持数据的安全性。
我们不明确地命名Ceph的OSD守护进程（例如，osd.0 osd.1等），而是称他们为初级，中级，等等。按照惯例，主要是第一OSD中的激活的设置，并负责协调每个配置组，它作为主要的对等过程，并且是唯一的OSD将接受客户端发起的写为对象给定的位置，它作为主要活动组。
当一个系列的OSD负责一个配置组，该系列的OSD，我们参考他们作为激活设置。一个激活设置可参考Ceph的OSD守护进程，目前负责配置组，或Ceph的的OSD守护，负责为特定的一些特别的现阶段配置组。
Ceph的OSD守护程序的一部分的代理设置可能并不总是up 。当在代理设置的OSD为up，它是up集的一部分 。up集是一个重要的特质，因为当一个OSD失败时，Ceph能再交换PG到其他Ceph OSD守护。
注意：在一个PG包含osd.25,osd.32和osd.61,第一个OSD，osd25，是主要的。如果那个OSD失败了，第二个，osd32，成为主要的，并且osd.25将会被移除UP集
重新均衡
当你添加一个CEPH的OSD守护进程到CEPH的存储集群，集群映射使用新的OSD得到更新。查看“计算PG的IDS”相关文档，这改变了集群映射。因此，它改变对了象的位置，因为它改变了一个计算的输入。下图描绘平衡过程（尽管相当粗暴，因为它的影响力大大低于大型集群），其中一些，但不是所有的PG从现有的OSD（OSD和OSD2）迁移到新的OSD（OSD3）。即使重新平衡，CRUSH是稳定的。许多配置组仍然在原来的配置，每个OSD得到一些额外的容量，所以在新的OSD上在重新平衡是完成后没有新的负载峰值。
数据一致性
作为保持数据的一致性和清理的一部分，Ceph的OSD也可以清除配置组内的对象。也就是说，Ceph的OSD可以比较放置在一个组对象元数据存储与在其他的OSD布置组及其副本。清理（通常每天执行）捕获OSD的错误或文件系统错误。OSD还可以通过比较对象中的数据比特位进行更深层次的清理。深度清理（通常每周执行）可以发现在平时清理中不会被发现的磁盘上的坏扇区。
纠删码
使用了纠错编码保护的Pool，实现了将每个存储object切分为K+M份数据块。Pool设置数据尺寸大小为K+M使得每份数据块能够存储在单独的一个OSD中。数据块的存储序列按照数据object的属性进行排列。
例如：纠删Pool数据存储使用到5个OSDs（K+M=5），其中两个维护数据编码OSDs
读写编码数据块
当object NYAN将数据ABCDEFGHI写入Pool时，纠删编码功能将内容数据分割到三个数据块中，数据分割成ABC、DEF、GHI三部分。如果数据不是按K的倍数分配，那么将额外填充一些数据。与此同时，也创建了两个编码数据块，第四，五块数据可为YXY，GQC。每个数据块都被存储在OSD活动集中的一个OSD中。存储在objects中的数据块都有同样的命名（如：NYAN），但是驻留在不同的OSDs中。除了命名之外，数据块创建的顺序必须被保留并且作为一种objects的属性（shard_t）。数据块1包含内容ABC并存储在OSD5中，同时数据块4包含YXY内容存储在OSD3 等。如下示：
若当object NYAN被读出纠删Pool时，解码读取三个数据块：包含数据ABC的数据块1、数据块3（GHI）、数据块4（YXY）。那么，将重构object的原始数据ABCDEFGHI。解码时将告知数据块2、5缺失（擦除）了。因为OSD4处于out，状态数据块5不能被读取。数据解码可称为只要三块数据块能被读取：OSD2是最慢的并且它的数据块不算数。
满写中断干扰
在一个纠删编码Pool中，主OSD若处于up状态将接受所有的写操作。负责K+M数据块的数据编码并将数据存储到其它的OSDs中，同时也负责维护更新PG日志。
如下示图标，一个纠删PG：K=2+M=1，即拥有3个OSDs组成，K为两个、M为一个。PG活动集包含OSD1、OSD2、OSD3。一个object编码并存储到一个OSD中：数据块D1v1（例如：资料数据块1，版本1）在OSD1中，D2v1在OSD2中，C1v1(例如：编码数据块1，版本1)在OSD3中。PG日志在每个OSD上都是一样的（如：1,1代表时间戳1，版本1）
OSD1是主OSD，负责接受来自客户端的完整写请求，意味着要实现将原来的数据全部替换而不是重写其中的一部分。object版本2的数据将重载object版本1数据。OSD1将有效负载（即合法有效数据）分成三部分：实现将D1v2存储在OSD1上，D2v2在OSD2上以及C1v2在OSD3上。每个数据块均被存储到目标OSD上，包括同时具有负责存储数据块、处理写请求操作、智能更新维护PG日志的OSD。当一个OSD收到写数据块的请求时，它就会在PG日志上创建一个新通道使得能随时反映出操作信息。例如，只要OSD3试图实现C1v2存储，就会为日志添加一个通道1、2（时间戳1、版本2）。Ceph集群OSDs工作方式是异步的，因此当一些数据块已经存储在了对应的磁盘上时，一些数据块可能还一直是处于迁徙的状态（如D2v2）。
如果整个集群运行状态良好，那么数据块能实现存储在活动集的各个OSD上并且日志的last_complate指针将从1,1日志版本指向1,2。
如下示（一般情况）：最后，用于存储object数据块的旧版本数据或文件将会被删除，删除后：D1v1在OSD1、D2v1在OSD2、C1v1在OSD3
特殊状况，OSD1处于down状态，而同时D2v2一直在迁徙，即object版本2部分实现写入。此时：OSD3已经拥有一个数据块，但是利用一个数据块不足以实现数据的编码恢复功能。失去了两个数据块：D1v2、D2v2。纠删编码参数K=2,M=1，意示着要实现重建第三块数据至少得使用到两个数据块的资源。OSD4成为了一个新的主OSD，up后得知last_complete指示1,1日志版本，便将该版本日志作为OSD4当前日志。
OSD3的当前日志1,2与主OSD4提供的日志版本不同，日志1,2是已经废弃的，它还保留有移除了的C1v2的相关信息。D1v1数据块能得以重现，依靠了纠删编码库提供的解码功能。D1v1数据块最终存储在主OSD4上。
分层缓存
实现一个缓存分层，能够使得支持存储分层的客户端子设备数据存储I/O性能更加完善。缓存分层涉及到创建一个基于比较高效且昂贵的存储设备（如Solid固态磁盘）的Pool，即将其做一些配置以充当一个缓存层，并为任一编码消磁了的或较为经济的存储设备（便宜的，如非Solid磁盘）做基本的性能支持或备用支持。Ceph对象操控到哪里防止object，而分层代理决定什么时候刷新实现将数据存储到支持存储层（即，物理磁盘）。可知，缓存层与支持存储层的数据操作实现或数据的流动过程对于Ceph客户端而言都是透明的。
集群扩展
扩展Ceph可通过创建共享对象类称为’Ceph类’。Ceph加载动态存储在osd class dir 目录（如：默认目录$libdir/rados-classes）下的.so类库。当实现了一个类的时候，就能够创建一个新的有能够在Ceph对象存储器调用本地方法的object方法，或通过利用函数库创建其它混合的类方法或全都有自己实现的构造方法。
写方面：Ceph类库调用本地或类方法，能实现对流入的数据自行地执行一系列的操作并生成一个写事务处理的结果。
读方面：Ceph类库能够调用本地或类方法，能实现对流出的数据执行一系列的操作并返回数据给客户端。
Ceph类实例
一个CEPH类的内容管理系统，提出一个特定的尺寸和长宽比的照片可以采取入站位图图像，裁剪到一个特定的纵横比，调整它的大小和嵌入一种无形的版权或水印，以帮助保护知识产权，保存位图图像到对象存储中。
摘要
Ceph存储集群就像有生命力的有机体一样能实现动态运作。Ceph能实现，但许多存储设备却不能充分利用一个典型的商用服务器的CPU和RAM。从心跳，对等，平衡群集或从故障中恢复，从客户端（通过Ceph的架构中不存在的集中化网关），使用OSD计算能力去执行工作。当提到“硬件建议”和“网络配置”参考文档时，上述概念的认识会帮助你去了解Ceph如何利用计算资源。
Ceph协议
Ceph客户端利用本地协议实现与Ceph存储集群的通讯交互。Ceph将这些功能打包到librados库当中，以便能够创建自己的Ceph客户端。如下示描述了基本的实现架构：
本地协议以及librados
现今的应用程序使用简单的对象存储接口实现异步通讯功能。Ceph存储集群就提供了一个简单的对象存储接口用以实现异步通讯功能。接口为实现集群的对象存储提供了直通，并行的通道
- Pool操作
- 快照以及写时克隆
- 读/写objects
- 创建/设置/移除XATTRs
- 创建/设置/移除key/value对
- 混合操作以及双重响应语义
- object类
对象监控/通知
客户端能利用一个对象注册持久的作用效果，进而实现保持一个会话的主节点OSD的开放状态。客户端可以发送通知消息以及有效数据负载给所有的观察者，与此同时客户端也可以收到来自观察者确认接收的通知。这使客户端可以使用任何对象同步/通信通道。
数据分段
存储设备有吞吐量的限制，从而影响性能和可伸缩性。因此，存储系统在跨多个存储设备往往支持连续块条带化存储信息，以提高吞吐量和性能。数据条带化的最常见的形式是 RAID。与CEPH的条带化的RAID类型最相似的是RAID 0，或“带区卷”。CEPH的条带化提供RAID 0条带，N路可靠的RAID镜像和更快的恢复。
CEPH的提供了三种客户端条带类型：CEPH的块设备，CEPH的文件系统，CEPH的对象存储。CEPH的客户端改变它的数据根据它在CEPH的存储集群提供给其用户的（块设备镜像，基于REST的对象，CEPHFS文件系统目录）至对象表示格式。
建议：存储在Ceph的存储集群的Ceph的对象都没有条带化。Ceph的对象存储，Ceph的块设备，Ceph的文件系统在多个Ceph的存储集群对象条带化他们的数据。Ceph的客户端直接写入Ceph的存储集群通过librados必须进行条带化（和并行I/O），为自己获得这些好处。
最简单的Ceph的条带化格式1对象涉及的条带计数。Ceph的客户端写入条带单元的Ceph的存储集群对象，直到对象是其最大容量，然后再创建另一个对象额外的数据条带。条带化的最简单的形式可能是足够小的块设备镜像，S3或Swift对象和CephFS的文件。然而，这种简单的形式没有利用Ceph的布置组之间分发数据的能力的最大优势，因此不会很大地改善性能。下图描述了条带化的最简单的形式：
如果预期大的镜像尺寸，大规模S3或Swift对象（如视频），或CephFS的目录，你可能会看到相当大的读/写性能方面的改进，通过客户端在多个对象内的对象集中的数据条带化。当客户端写入到其对应的对象平行条带单位，写入性能显着提高。由于对象映射到不同的布置组，并进一步映射到不同的OSD，发生在平行的每个写动作有最大写入速度。写入至单个磁盘会被磁头移动（例如，每寻道6ms）和一台设备（如100MB/s）的带宽限制。通过写入多个对象（映射到不同的配置组和OSD）的传播，Ceph可以减少每个驱动器的seek的数量，结合多个驱动器的吞吐量达到更快的写（或读）的速度。
意:条带化的是独立的对象副本。由于CRUSH经过OSD复制对象，条带自动被复制。
在下面的图中，客户端的数据得到整个对象集（在下面的图中的object set 1）包括4个对象，其中第一条条带单元是在 object 0中的 stripe unit 0 ，第四条条带单元在object 3中的 stripe unit 3。写第四条后，客户端决定是否该对象集是完整的。如果对象集是不完整的，客户端开始再一次在第一个对象中写入一个条带（下图中的object 0）。如果该对象组是完整的，在客户端创建一个新的对象组（在下面的图中的object set 2），开始在新的对象组设置 (在下面的图中的object 4 ).中的第一个对象写入一个条带至第一个对象（stripe unit 16）。
三个重要变量决定如何Ceph的条带数据：
对象的大小：在Ceph的对象存储集群有一个最大配置大小（例如，2MB，4MB，等）。对象的大小应该足够大，以容纳许多条带单元，应该是多个条带单元。
条带宽度：条带有一个可配置的单元大小（例如，64KB）。Ceph的客户端将数据将会写入到同样大小的条带单位的对象，除了最后一个条带单元。条带的宽度，应该是对象尺寸的一小部分以至于一个对象可能包含许多条带单位。
条带计数： Ceph的客户端写了一系列由条带计数决定的对象序列的条带单位。一系列对象被称为对象集。在Ceph的客户端写入的对象组中的最后一个对象后，它返回的对象组中的第一个对象。
重要：在把你的群集投入生产之前测试条带化配置的性能。在你条带化数据并且把它写入对象后，你不能改变这些条带化参数。
一旦Ceph的客户端有条带化单元的条带化数据并且映射条带化单元至对象，在对象被存储作为存储磁盘上的文件之前，Ceph的CRUSH算法映射和映射对象到配置组，并且配置组至Cep的OSD守护。
注意：由于客户端写入到一个池，条带化至对象的所有数据在同一池中映射到配置组。因此，他们使用相同的的CRUSH映射和相同的访问控制。
Ceph客户端
Ceph的客户端包括一些服务接口。这些包括：
区块装置：Ceph的块设备（又名RBD）服务提供了可调整大小，自动精简配置的块设备快照和克隆。Ceph的条带块设备跨集群的高性能。Ceph的支持两个内核对象（KO）和使用librbd直接避免为虚拟化系统的内核对象的开销QEMU虚拟机管理程序。
对象存储：Ceph的对象存储（又名，RGW）服务提供REST风格的API接口，兼容Amazon S3和OpenStack的swift。
文件系统：Ceph的文件系统（CephFS）服务提供了一个POSIX兼容的文件系统可安装或在用户空间（FUSE）作为文件系统
Ceph的可以运行的其他实例的OSD的MDS和监控器，可扩展性和高可用性。下图描绘了高层次的架构。
CEPH的对象存储
CEPH的对象存储守护进程，RADOSGW，是一个FASTCGI的服务，提供一个RESTFUL的 HTTP API存储对象和元数据。层顶部CEPH的存储集群与自己的数据格式，并保持自己的用户数据库身份验证和访问控制。RADOS网关采用一个统一的命名空间，这意味着你可以使用OPENSTACK的SWIFT兼容的API或亚马逊S3兼容的API。例如，你可以使用S3-COMPTABLE的一个应用程序的API写数据，然后使用SWIFT兼容的API与其他应用程序读取数据。
S3/Swift对象和存储群集对象比较
Ceph的对象存储使用的术语来形容它存储的数据对象。S3和Swift对象Ceph的写入与Ceph的存储集群的对象是不一样的。Ceph的对象存储对象映射到Ceph的存储集群对象。S3和Swift对象不一定对应于以1:1的方式存储在所述存储群集的对象。这是可能的一个S3或Swift对象映射到多个Ceph的对象。
Ceph块设备
一个Ceph的块设备在Ceph的存储集群中的多个对象条带化块设备镜像，其中每个对象被映射到一个配置组和被分发，配置组中的多个对象遍布整个集群。
重要：条带化允许RBD块设备比起单台服务器能做的有更好的表现
自动精简配置snapshottable Ceph的块设备是虚拟化和云计算的一个有吸引力的选择。在虚拟机的情况下，人们通常使用在QEMU/KVM中的rbd网络存储驱动部署Ceph的块设备，其中主机使用librbd给客户提供一个块设备服务。许多云计算堆栈使用libvirt的整合与虚拟机管理程序。您可以使用QEMU和libvirt的Ceph的块设备自动精简配置支持OpenStack和CloudStack其他云解决方案。
虽然我们在这个时候不提供librbd与其他虚拟机管理程序的支持，你也可以使用Ceph的块设备内核对象提供一个块设备到客户端。其他如Xen的虚拟化技术可以访问Ceph的块设备的内核对象（次）。这是通过命令行工具RBD实现的。
Ceph文件系统
Ceph的文件系统（CEPH FS）提供了一个与POSIX兼容的，基于对象的，Ceph存储集群之上分层的文件系统的一种服务。Ceph的FS文件映射到Ceph存储在Ceph存储集群的对象。Ceph的客户端挂载CephFS的文件系统作为一个内核对象，或作为一个文件系统在用户空间（FUSE）。
Ceph的文件系统服务包括Ceph的存储集群部署Ceph的元数据服务器（MDS）。MDS的目的是高可用性的Ceph元数据的元数据服务器驻留在内存中存储的所有文件系统元数据（目录，文件所有权，访问模式等）。使用MDS（称为ceph-mds的守护进程）的原因是简单的文件系统操作，如列出一个目录或改变一个目录（ls,cd命令）将使Ceph的OSD负担不必要的守护进程。所以从数据的元数据分离意味着Ceph的文件系统可以提供高性能的服务不给Ceph的存储集群增加负担。
Ceph的FS分离元数据从数据来看，MDS中存储元数据，文件数据存储在Ceph的存储集群的一个或多个对象。Ceph的文件系统的目的是与POSIX兼容。Cept MDS可以作为一个单一的过程中运行，或它可以分布到多个物理机器，亦或是对高可用性或可扩展性。
高可用性：额外的 ceph-mds实例可以待机，准备积极接管任何的 ceph-mds失败的职责。这是很容易的，因为所有的数据，包括日志，存储在RADOS。过渡是自动由cept-mon触发。
可扩展性：多个ceph MDS实例可以是活跃的，他们将分割目录树至子树（和一个单一的忙目录碎片），有效的平衡目录树中所有活动的服务器之间的负载平衡。
待机和活跃的组合是可能的，例如，按纺一标准运行3个活跃的ceph-mds实例，和一个备用高可用性实例。
1336
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
