Ceph寻址

一个大规模分布式存储系统，必须要能够解决两个最基本的问题，即"我应该把数据写到什么地方”与“我之前把数据写到什么地方了” ，因此会涉及数据如何寻址的问题。Ceph寻址流程如图所示。

• File:此处的File就是用户需要存储或访问的文件。对于一个基于Ceph开发的对象存储应用而言，这个File也就对应于应用中的“对象” ，也就是用户直接操作的“对象”
• Object:Object是RADOS所看到的“对象” 。Object与File的区别是， Object的最大尺寸由RADOS限定(通常为2MB或4MB) ，以便实现底层存储的组织管理。因此，当上层应用向RADOS存入尺寸很大的File时，需要将File切分成统一大小的一系列Objet (最后一个的大小可以不同)进行存储。
• PG ( Placement Group ) :顾名思义， PG的用途是对Object的存储进行组织和位置映射的。具体而言，一个PG负责组织若干个Object，但一个Obiect只能被映射到一个PG中，即PG和Object之间是“一对多”的映射关系。同时，一个PG会被映射到n个OSD上，而每个OSD上都会承载大量的PG，即PG和OSD之间是“多对多”的映射关系。在实践当中，n至少为2，如果用于生产环境，则至少为3。一个OSD上的PG可达到数百个。事实上， PG数量的设置关系到数据分布的均匀性问题
• OSD: OSD的数量事实上也关系到系统的数据分布均匀性，因此不应该太少。在实践当中，至少也应该是数百个的量级才有助于Ceph系统发挥其应有的优势。

1. File->Object映射
   这次映射的目的是，将用户要操作的File映射为RADOS能够处理的Object，其十分简单，本质上就是按照Object的最大尺寸对File进行切分，相当于磁盘阵列中的条带化过程。这种切分的好处有两个:一是让大小不限的File变成具有一致的最大尺寸、可以被RADOS高效管理的Object;二是让对单一File实施的串行处理变为对多个Object实施的并行化处理。
   每一个切分后产生的Object将获得唯一的oid,即Object ID,其产生方式也是线性映射,极其简单。图7-5中, ino是待操作File的元数据,可以简单理解为该File的唯一ID. ono则是由该File切分产生的某个Object的序号。而oid就是将这个序号简单连缀在该File D之后得到的。举例而言,如果1个ID为filename的File被切分成了3个Object,则其Object序号依次为0、1和2,而最终得到的oid就依次为fiename0、Filename1和filename2.
   这里隐含的问题是, ino的唯一性必须得到保证,否则后续的映射将无法正确进行。

2. Object →PG映射
   在File被映射为1个或多个Object之后,就需要将每个Object独立地映射到1个PG中去。这个映射过程也很简单,如图所示,其计算公式如下:
   Hash(oid) & mask -> pgid
   由此可见,其计算由两步组成。首先,使用Ceph系统指定的一个静态哈希算法计算oid的哈希值,将oid映射为一个近似均匀分布的伪随机值。然后,将这个伪随机值和mask按位相与,得到最终的PG序号(pgid) 。根据RADOS的设计,给定PG的总数为m(m应该为2的整数幂),则mask的值为m-1。因此,哈希值计算和按位与操作的整体结果事实上是从所有m个PG中近似均匀地随机选择1个。基于这一机制,当有大量Object和大量PG时, RADOS能够保证Object和PG之间的近似均匀映射。又因为Object是由File切分而来的,大部分Object的尺寸相同,因此,这一映射最终保证了各个PG中存储的Object的总数据量近似均匀。
   这里反复强调了“大量” ,意思是只有当Object和PG的数量较多时,这种伪随机关系的近似均匀性才能成立, Ceph的数据存储均匀性才有保证。为保证“大量”的成立,一方面, Object的最大尺寸应该被合理配置,以使得同样数量的File能够被切分成更多的Object;另一方面, Ceph也推荐PG总数应该为OSD总数的数百倍,以保证有足够数量的PG可供映射。

3. PG→ OSD映射
   第3次映射就是将作为Object的逻辑组织单元的PG映射到数据的实际存储单元OSD上。如图所示, RADOS采用一个名为CRUSH的算法,将pgid代入其中,然后得到一组共n个OSD。这n个OSD共同负责存储和维护一个PG中的所有Objecto前面提到过, n的数值可以根据实际应用中对于可靠性的需求而配置,在生产环境下通常为3。具体到每个OSD,则由其上运行的OSD Daemon负责执行映射到本地的Object在本地文件系统中的存储、访问、元数据维护等操作。
   和“Object →PG"映射中采用的哈希算法不同, CRUSH算法的结果不是绝对不变的,而会受到其他因素的影响。其影响因素主要有两个。
   一是当前系统状态,也就是在前面有所提及的集群运行图。当系统中的OSD状态、数量发生变化时,集群运行图也可能发生变化,而这种变化将会影响到PG与OSD之间的映射关系。
   二是存储策略配置。这里的策略主要与安全相关。利用策略配置,系统管理员可以指定承载同一个PG的3个OSD分别位于数据中心的不同服务器或机架上,从而进一步改善存储的可靠性。
   因此,只有在系统状态和存储策略都不发生变化的时候, PG和OSD之间的映射关系才是固定不变的。在实际使用中,策略一经配置通常不会改变。而系统状态的改变或是因为设备损坏,或是因为存储集群规模扩大。好在Ceph本身提供了对这种变化的自动化支持,因而,即便PG与OSD之间的映射关系发生了变化,也并不会对应用产生影响。事实上, Ceph正是利用了CRUSH算法的动态特性,可以将一个PG根据需要动态迁移到不同的OSD组合上,从而自动化地实现高可靠性、数据分布再平衡等特性。
   之所以在此次映射中使用CRUSH算法,而不使用其他哈希算法,一方面原因是CRUSH算法具有上述可配置特性,可以根据管理员的配置参数决定OSD的物理位置映射策略;另一方面原因是CRUSH算法具有特殊的“稳定性" ,也即,当系统中加入新的OSD,导致系统规模增大时,大部分PG与OSD之间的映射关系不会发生改变,只有少部分PG的映射关系会发生变化并引发数据迁移。这种可配置性和稳定性都不是普通哈希算法所能提供的。因此, CRUSH算法的设计也是Ceph的核心内容之一。
   至此为止, Ceph通过3次映射,完成了从File到Object. Object到PG,PG再到OSD的整个映射过程。从整个过程可以看到,这里没有任何的全局性查表操作需求。至于唯一的全局性数据结构:集群运行图。它的维护和操作都是轻量级的,不会对系统的可扩展性、性能等因素造成影响。

接下来的一个问题是:为什么需要引人PG并在Object与OSD之间增加一层映射呢？
可以想象一下,如果没有PG这一层映射,又会怎么样呢?在这种情况下,一定需要采用某种算法,将Object直接映射到一组OSD上。如果这种算法是某种固定映射的哈希算法,则意味着一个Object将被固定映射在一组OSD上,当其中一个或多个OSD损坏时, Object无法被自动迁移至其他OSD上(因为映射函数不允许),当系统为了扩容新增了OSD时, Object也无法被再平衡到新的OSD上(同样因为映射函数不允许)。这些限制都违背了Ceph系统高可靠性、高自动化的设计初衷。
如果采用一个动态算法(如仍然采用CRUSH算法)来完成这一映射,似乎是可以避免由静态映射而导致的问题的。但是,其结果将是各个OSD所处理的本地元数据量暴增,由此带来的计算复杂度和维护工作量也是难以承受的。
例如,在Ceph的现有机制中,一个OSD平时需要和与其共同承载同一个PG的其他OSD交换信息,以确定各自是否工作正常,是否需要进行维护操作。由于一个OSD上大约承载数百个PG,每个PG内通常有3个OSD,因此,在一段时间内,一个OSD大约需要进行数百次至数千次OSD信息交换。
然而,如果没有PG的存在,则一个OSD需要和与其共同承载同一个Object的其他OSD交换信息。由于每个OSD上承载的Object可能高达数百万个,因此,同样长度的一段时间内,一个OSD大约需要进行的OSD间信息交换将暴涨至数百万次乃至数千万次。而这种状态维护成本显然过高。
综上所述,引入PG的好处至少有两方面:一方面实现了Object和OSD之间的动态映射,从而为Ceph的可靠性、自动化等特性的实现留下了空间;另一方面也有效简化了数据的存储组织,大大降低了系统的维护与管理成本。