2.2 RADOS架构
RADOS系统主要由两个部分组成，如图2-2所示。
1）OSD：由数目可变的大规模OSD（Object Storage Devices）组成的集群，负责存储所有的Objects数据。
2）Monitor：由少量Monitors组成的强耦合、小规模集群，负责管理Cluster Map。其中，Cluster Map是整个RADOS系统的关键数据结构，管理集群中的所有成员、关系和属性等信息以及数据的分发。
图2-2 RADOS系统架构图示
对于RADOS系统，节点组织管理和数据分发策略均由内部的Mon全权负责，因此，从Client角度设计相对比较简单，它给应用提供存储接口。
2.2.1 Monitor介绍
正如其名，Ceph Monitor是负责监视整个群集的运行状况的，这些信息都是由维护集群成员的守护程序来提供的，如各个节点之间的状态、集群配置信息。Ceph monitor map包括OSD Map、PG Map、MDS Map和CRUSH等，这些Map被统称为集群Map。
1）Monitor Map。Monitor Map包括有关monitor节点端到端的信息，其中包括Ceph集群ID，监控主机名和IP地址和端口号，它还存储了当前版本信息以及最新更改信息，可以通过以下命令查看monitor map。
#ceph mon dump
2）OSD Map。OSD Map包括一些常用的信息，如集群ID，创建OSD Map的版本信息和最后修改信息，以及pool相关信息，pool的名字、pool的ID、类型，副本数目以及PGP，还包括OSD信息，如数量、状态、权重、最新的清洁间隔和OSD主机信息。可以通过执行以下命令查看集群的OSD Map。
#ceph osd dump
3）PG Map。PG Map包括当前PG版本、时间戳、最新的OSD Map的版本信息、空间使用比例，以及接近占满比例信息，同时，也包括每个PG ID、对象数目、状态、OSD的状态以及深度清理的详细信息，可以通过以下命令来查看PG Map。
#ceph pg dump
4）CRUSH Map。CRUSH Map包括集群存储设备信息，故障域层次结构和存储数据时定义失败域规则信息；可以通过以下命令查看CRUSH Map。
#ceph osd crush dump
5）MDS Map。MDS Map包括存储当前MDS Map的版本信息、创建当前Map的信息、修改时间、数据和元数据POOL ID、集群MDS数目和MDS状态，可通过以下命令查看集群MDS Map信息。
#ceph mds dump
Ceph的MON服务利用Paxos的实例，把每个映射图存储为一个文件。Ceph Monitor并未为客户提供数据存储服务，而是为Ceph集群维护着各类Map，并服务更新群集映射到客户机以及其他集群节点。客户端和其他群集节点定期检查并更新于Monitor的集群Map最新的副本。
Ceph Monitor是个轻量级的守护进程，通常情况下并不需要大量的系统资源，低成本、入门级的CPU，以及千兆网卡即可满足大多数的场景；与此同时，Monitor节点需要有足够的磁盘空间来存储集群日志，健康集群产生几MB到GB的日志；然而，如果存储的需求增加时，打开低等级的日志信息的话，可能需要几个GB的磁盘空间来存储日志。
一个典型的Ceph集群包含多个Monitor节点。一个多Monitor的Ceph的架构通过法定人数来选择leader，并在提供一致分布式决策时使用Paxos算法集群。在Ceph集群中有多个Monitor时，集群的Monitor应该是奇数；最起码的要求是一台监视器节点，这里推荐Monitor个数是3。由于Monitor工作在法定人数，一半以上的总监视器节点应该总是可用的，以应对死机等极端情况，这是Monitor节点为N（N>0）个且N为奇数的原因。所有集群Monitor节点，其中一个节点为Leader。如果Leader Monitor节点处于不可用状态，其他显示器节点有资格成为Leader。生产群集必须至少有N/2个监控节点提供高可用性。
2.2.2 Ceph OSD简介
Ceph OSD是Ceph存储集群最重要的组件，Ceph OSD将数据以对象的形式存储到集群中每个节点的物理磁盘上，完成存储用户数据的工作绝大多数都是由OSD deamon进程来实现的。
Ceph集群一般情况都包含多个OSD，对于任何读写操作请求，Client端从Ceph Monitor获取Cluster Map之后，Client将直接与OSD进行I/O操作的交互，而不再需要Ceph Monitor干预。这使得数据读写过程更为迅速，因为这些操作过程不像其他存储系统，它没有其他额外的层级数据处理。
Ceph的核心功能特性包括高可靠、自动平衡、自动恢复和一致性。对于Ceph OSD而言，基于配置的副本数，Ceph提供通过分布在多节点上的副本来实现，使得Ceph具有高可用性以及容错性。在OSD中的每个对象都有一个主副本，若干个从副本，这些副本默认情况下是分布在不同节点上的，这就是Ceph作为分布式存储系统的集中体现。每个OSD都可能作为某些对象的主OSD，与此同时，它也可能作为某些对象的从OSD，从OSD受到主OSD的控制，然而，从OSD在某些情况也可能成为主OSD。在磁盘故障时，Ceph OSD Deamon的智能对等机制将协同其他OSD执行恢复操作。在此期间，存储对象副本的从OSD将被提升为主OSD，与此同时，新的从副本将重新生成，这样就保证了Ceph的可靠和一致。
Ceph OSD架构实现由物理磁盘驱动器、在其之上的Linux文件系统以及Ceph OSD服务组成。对Ceph OSD Deamon而言，Linux文件系统显性地支持了其扩展属性；这些文件系统的扩展属性提供了关于对象状态、快照、元数据内部信息；而访问Ceph OSD Deamon的ACL则有助于数据管理，如图2-3所示。
Ceph OSD操作必须在一个有效的Linux分区的物理磁盘驱动器上，Linux分区可以是BTRFS、XFS或者EXT4分区，文件系统是对性能基准测试的主要标准之一，下面来逐一了解。
1）BTRFS：在BTRFS文件系统的OSD相比于XFS和EXT4提供了最好的性能。BTRFS的主要优点有以下4点。
扩展性（scalability）：BTRFS最重要的设计目标是应对大型机器对文件系统的扩展性要求。Extent、B-Tree和动态inode创建等特性保证了BTRFS在大型机器上仍有卓越的表现，其整体性能不会随着系统容量的增加而降低。
数据一致性（data integrity）：当系统面临不可预料的硬件故障时，BTRFS采用 COW事务技术来保证文件系统的一致性。BTRFS还支持校验和，避免了silent corrupt（未知错误）的出现。而传统文件系统无法做到这一点。
多设备管理相关的特性：BTRFS支持创建快照（snapshot）和克隆（clone）。BTRFS还能够方便地管理多个物理设备，使得传统的卷管理软件变得多余。
结合Ceph，BTRFS中的诸多优点中的快照，Journal of Parallel（并行日志）等优势在Ceph中表现得尤为突出，不幸的是，BTRFS还未能到达生产环境要求的健壮要求。暂不推荐用于Ceph集群的生产使用。
2）XFS：一种高性能的日志文件系统，XFS特别擅长处理大文件，同时提供平滑的数据传输。目前CentOS 7也将XFS+LVM作为默认的文件系统。XFS的主要优点如下。
分配组：XFS文件系统内部被分为多个“分配组”，它们是文件系统中的等长线性存储区。每个分配组各自管理自己的inode和剩余空间。文件和文件夹可以跨越分配组。这一机制为XFS提供了可伸缩性和并行特性——多个线程和进程可以同时在同一个文件系统上执行I/O操作。这种由分配组带来的内部分区机制在一个文件系统跨越多个物理设备时特别有用，使得优化对下级存储部件的吞吐量利用率成为可能。
条带化分配：在条带化RAID阵列上创建XFS文件系统时，可以指定一个“条带化数据单元”。这可以保证数据分配、inode分配，以及内部日志被对齐到该条带单元上，以此最大化吞吐量。
基于Extent的分配方式：XFS文件系统中的文件用到的块由变长Extent管理，每一个Extent描述了一个或多个连续的块。对那些把文件所有块都单独列出来的文件系统来说，Extent大幅缩短了列表。
有些文件系统用一个或多个面向块的位图管理空间分配——在XFS中，这种结构被由一对B+树组成的、面向Extent的结构替代了；每个文件系统分配组（AG）包含这样的一个结构。其中，一个B+树用于索引未被使用的Extent的长度，另一个索引这些Extent的起始块。这种双索引策略使得文件系统在定位剩余空间中的Extent时十分高效。
扩展属性：XFS通过实现扩展文件属性给文件提供了多个数据流，使文件可以被附加多个名/值对。文件名是一个最大长度为256字节的、以NULL字符结尾的可打印字符串，其他的关联值则可包含多达64KB的二进制数据。这些数据被进一步分入两个名字空间中，分别为root和user。保存在root名字空间中的扩展属性只能被超级用户修改，保存在user名字空间中的可以被任何对该文件拥有写权限的用户修改。扩展属性可以被添加到任意一种 XFS inode上，包括符号链接、设备节点和目录等。可以使用attr命令行程序操作这些扩展属性。xfsdump和xfsrestore工具在进行备份和恢复时会一同操作扩展属性，而其他的大多数备份系统则会忽略扩展属性。
XFS作为一款可靠、成熟的，并且非常稳定的文件系统，基于分配组、条带化分配、基于Extent的分配方式、扩展属性等优势非常契合Ceph OSD服务的需求。美中不足的是，XFS不能很好地处理Ceph写入过程的journal问题。
3）Ext4：第四代扩展文件系统，是Linux系统下的日志文件系统，是Ext3文件系统的后继版本。其主要特征如下。
大型文件系统：Ext4文件系统可支持最高1 Exbibyte的分区与最大16 Tebibyte的文件。
Extents：Ext4引进了Extent文件存储方式，以替换Ext2/3使用的块映射（block mapping）方式。Extent指的是一连串的连续实体块，这种方式可以增加大型文件的效率并减少分裂文件。
日志校验和：Ext4使用校验和特性来提高文件系统可靠性，因为日志是磁盘上被读取最频繁的部分之一。
快速文件系统检查：Ext4将未使用的区块标记在inode当中，这样可以使诸如e2fsck之类的工具在磁盘检查时将这些区块完全跳过，而节约大量的文件系统检查的时间。这个特性已经在2.6.24版本的Linux内核中实现。
Ceph OSD把底层文件系统的扩展属性用于表示各种形式的内部对象状态和元数据。XATTR是以key/value形式来存储xattr_name和xattr_value，并因此提供更多的标记对象元数据信息的方法。Ext4文件系统提供不足以满足XATTR，由于XATTR上存储的字节数的限制能力，从而使Ext4文件系统不那么受欢迎。然而，BTRFS和XFS有一个比较大的限制XATTR。
Ceph使用日志文件系统，如增加了BTRFS和XFS的OSD。在提交数据到后备存储器之前，Ceph首先将数据写入称为一个单独的存储区，该区域被称为journal，这是缓冲器分区在相同或单独磁盘作为OSD，一个单独的SSD磁盘或分区，甚至一个文件文件系统。在这种机制下，Ceph任何写入首先是日志，然后是后备存储，如图2-4所示。
图2-4 IO流向图
journal持续到后备存储同步，每隔5s。默认情况下。10GB是该jouranl的常用的大小，但journal空间越大越好。Ceph使用journal综合考虑了存储速度和数据的一致性。journal允许Ceph OSD功能很快做小的写操作；一个随机写入首先写入在上一个连续类型的journal，然后刷新到文件系统。这给了文件系统足够的时间来合并写入磁盘。使用SSD盘作为journal盘能获得相对较好的性能。在这种情况下，所有的客户端写操作都写入到超高速SSD日志，然后刷新到磁盘。所以，一般情况下，使用SSD作为OSD的journal可以有效缓冲突发负载。
与传统的分布式数据存储不同，RADOS最大的特点如下。
① 将文件映射到Object后，利用Cluster Map通过CRUSH计算而不是查找表方式定位文件数据到存储设备中的位置。优化了传统的文件到块的映射和BlockMap管理。
② RADOS充分利用了OSD的智能特点，将部分任务授权给OSD，最大程度地实现可扩展。
