RADOS
A Scalable, Reliable Storage Service for Petabyte-scale Storage Clusters
想了解一下Ceph的原理，没想到书上全是如何部署的教程，网上能查到的只有论文和论文译文，说实话，译文看不懂啊，有些像是机器翻译，不像人话，每当这个时候都不得不自己看原文。
读论文很痛苦，中文的也看不懂，英文的也看不懂，只能中英文一起看了。边看边增加了自己的理解。
Ceph论文阅读分三节，RADOS关于数据存储分布，CRUSH关于伪随机算法，最后一个是最重要的ceph系统。感觉回到了读研的岁月，为什么不读博的我还是要看论文？好吧，至少不用写sci了，心里还是有点安慰的~~
RADOS 想解决什么问题？
在存储基础知识一中，讲到了对象存储，对象存储结合了文件存储可共享以及块存储快的优点，其设计方案是通过管理节点又叫元数据服务器（装有对象存储管理软件的服务器）来存对象的属性，可以理解为一个数据分布表-索引表，数据存在分布式服务器OSD上。用户首先访问元数据服务器，了解了数据分布情况之后再去相应的位置获取数据。此时，多台OSD同时对外传输数据，实现加速。
由此可见，OSD只是很多块通过网络连接的存储设备，客户端需要首先问管理节点数据在哪些OSD上，再访问OSD，这样的话，管理节点集群承担的任务比较中，当OSD数量成千上万时，管理节点集群的负载就吃不消了。那OSD本身能不能分担一些管理节点集群的任务呢？人们一直想将块分配策略（block allocation）和安全强制措施分布到OSD上，让OSD获得一定的智能（这边我理解的智能是类似于操作系统的调度管理，可以实现一些任务分配的自动化）从而让客户端可以直接访问OSD上的data，简化了数据分布，消除了IO瓶颈。（这边我的理解是这种智能的增加像是RAID的进化一样，在存储设备上集成一定类似于操作系统，文件系统的功能，实现数据的自动分配，减少人为设定）
所以在OSD上集成CPU,网络接口，本地缓存，基础的磁盘或者RAID（希望OSD变得更智能）。但是采用这种结构的大规模系统无法利用设备的智能，即使OSD已经具有智能分配的能力，但设备本身还是被动的执行读写命令。因此，当存储集群增长到数千节点或更多时，数据迁移的一致性管理，错误检测，错误恢复将给客户端，控制器以及元数据目录目录节点带来压力，限制可扩展性。
RADOS是一个可靠的自动的分布式对象存储，利用OSD设备本身的智能，来解决集群中存在的数据一致性访问，冗余存储，错误检测和数据恢复等问题。使得数据和负载动态地分布在不均匀的存储集群上。
存储系统是动态变化的，包括扩建，更替。设备出错和恢复都是基于连续数据的基础上，使大量数据被建立/删除。RADOS确保数据分布对系统的一致性，基于cluster map的对象读写的一致性。cluster map被复制到所有节点上，包括客户端，并被Lazy propagation的增量更新。
存储节点上有完整的数据在系统中的分布信息，使得设备可以半自治地通过类似点对点的协议来自我管理数据复制，一致和安全过程更新，参与错误检测以及响应错误和数据对象赋值迁移带来的数据分布变化。这得益于OSD本身的智能潜力，减轻了管理cluster map主副本的小型管理集群上的压力，从而使存储集群可以扩展到数千节点。
我的理解：原生对象存储是有几台管理节点，管理其他几台OSD，OSD本身并不需要智能，只是存储设备，被动的执行读写命令，关于数据迁移，错误检测等等工作都在管理节点上，所以当OSD节点非常多时，管理节点就不够用了，管理压力很大；而RADOS的方案，时OSD本身增加一些任务处理的能力，因此可以承担起原来需要在管理节点上才能完成的任务
RADOS 可扩展的集群管理
RADOS系统包括大量OSD节点（包括一个CPU、一些易失性内存、一个网络接口、本地磁盘或RAID）和规模小的负责管理的monitor（有单机进程并且需要少量的本地内存 ）集合。
Cluster Map
Monitor集群管理维护Cluster map。Cluster map描述了数据在系统中的分布情况。客户端提供一个简单的接口把整个存储集群虚拟成一个单一的逻辑对象存储。
在非常大的集群中，节点上千，OSD的出错和恢复都是比较平常的，因此，Cluser map的变动会很频繁。Cluster map的改变会触发map epoch的递增。Cluster map的更新以incremental maps的形式来进行分布，即用samll message来表示两个map epoch间的差异。很多更新被集中捆绑，以便描述间隔较长的map版本（看着有点像日志）。
数据的放置
RADOS使用CRUSH伪随机算法，将数据伪随机地分布到设备上，当新设备增加，一个随机的现存数据的副本迁移到新设备上用以实现负载均衡。这个过程涉及到两个方面：1.计算正确的对象存储位置，2.不需要维护一个大型的集中分配表。
对象先被映射到PG组（placement group），PG组表示逻辑上的对象集合，每个对象的PG由以下公式来计算得到：pgid=(r,hash(o)&m)，r表示数据主从复制的等级，hash(o)表示对象名为o的键值，m表示控制PG总数的位掩码。
PG组根据cluster map来映射到OSD节点上。每个PG被映射到有序的包含r个OSD节点的链表中。该映射通过CRUSH算法来实现（一个PG往一组设备OSD上映射）。CRUSH算法和hash算法的相似之处在于其PG值是确定的，但却是伪随机分布的；但不同的是，CRUSH是未定的，当一个或多个设备加入或离开集群时，PGs保持不变，CRUSH负责转移足够的数据来维护一个均衡的分布，HASH则更倾向于强制重新映射。
Map传播（Map Propagation）
由于ODS的数据很多，所以以广播的形式来更新所有的map是不合适的。但不同的map epochs之间的差异是很明显的，所以，当两个通信的OSD（或者客户端和OSD）不同时，map才会更新。这种方式可以使得RADOS对map的更新延迟，有效地将分布的负载转移到OSD上。
OSD 智能存储设备
上面我们提到了再RADOS当中，OSD拥有智能，减少了管理节点集群的负担，那么，接下来，我们就看一下OSD具体可以实现哪些任务
复制
RADOS实现三种不同的复制策略：
1.Primary copy:读和写都在第一个OSD上，然后并行地更新副本到其他OSD上
2.Chain:写在第一个OSD上，读在最后一个OSD上
3.splay replication:hybrid方法，从最后一个OSD开始读，写先写在第一个OSD上，然后并行地更新副本到其他OSD上。
强一致性
…是我智商有问题么？这一小段读了好久好久…本来想愉快的跳过，不知为何，强迫症逼着我非想读懂不可。
首先，RADOS中的所有信息都携带发送方的map epoch，这是前提条件。
1.如果一个发送方由于data map过期，定位到错误的OSD，该OSD会返回给它一个增量保证他更新之后重新定位到正确的OSD。
2.如果cluster map的主拷贝更新了一个特定的PG中的成员，其他老成员依然可以处理更新；如果这个更新先被一个PG副本节点接收，这个change就会被立刻发现，当住OSD转发更新消息到这个节点时，这个副本节点就会返回map增量给主OSD。因为任何一个新负责一个PG的OSD都需要与原来负责的OSD进行联系（工作交接），来保证PG内容的正确。
3.当新的OSD要负责一个PG时（工作交接），该组内所有老OSD都要被通知到，已确认自己的角色（类似于一个组换领导了，组内成员都得被通知一遍）。所以需要周期性地发送报文。这样为了保证主OSD故障时数据不可用的时间很短。（文章建议设定两秒）
内心os:真心感觉架构师不是什么人都能做的，那得是高考数学能做出最后一道大题的大神才能挑战的事情，真是方方面面事无巨细。如果data map过期怎么办？如果主拷贝map最先更新，那整体更新进展如何进行？如果副拷贝先更新，那整体更新进展如何进行？如果PG内副本OSD出现故障怎么办？如果PG内主本OSD出现故障，数据不可用，工作需要交接怎么办？呃。。。。。。好吧，大神负责create，我只能负责study了。
故障检测
RADOS 采用一种异步的，有序的，点对点的消息传递方式进行通信。OSD会与自己的对端（共享同一PG data的OSD）交换周期性报文，这样，如果一个OSD出现故障，几次连接都失败后会报告给管理集群，集群将报文周期性发送，OSD发现自己被标记为down后，会同步硬盘数据，然后挂掉自己来保证系统的一致性。
数据迁移和故障恢复
RADOS数据迁移和故障恢复完全是由Cluster map的更新和PG到OSD的映射驱动的。新的CRUSH策略会使所有数据重新分布。
分层复制（declustered replication）能够进行并行的故障恢复。
通过观察I/O读是否被限制来触发RADOS的recovery。
RADOS中PG的恢复由primary OSD协调，可将任何对象推送到replia OSD，保证每个拷贝对象只读一次。
MONITORS监视器
Monitors是一个小的管理集群，通过春初Cluster Map的主拷贝，并周期性更新配置和OSD状态，管理整个存储系统。这个集群基于Paxos part-time parliament算法，保证数据一致性以及更新的延迟性。
monitors集群的工作负载比较小，大部分map 的分配是由OSD承担的，monitors需要承担的时候是当设备状态出现变化的时候，比如设备故障了，但是通常这种状态变化是不经常发生的。
monitors集群采用租约机制，允许任何monitor可以从OSD或Client请求Cluster map的拷贝。通常情况下，OSD很少发起更新请求，因为通常在此之前，map更新已经被共享了。而对于Client发起更新请求的情况也比较少，通常在OSD操作超时，或发生错误的时候。
对Map update的请求会被转发给Monitors集群的当前leader。Leader汇集这些请求到一个Map Update。最坏的情况下Leader的负载情况如何？当大量OSD在一个短时间内同时发生故障，比如一个OSD中放了u个PG，有f个OSD发生故障，那么，最多会有uf个错误报告。当f比较大时，消息会非常多，OSD会在伪随机时间间隔发送报文，以保证这些错误被陆续检测，压制和分别报告。非leader的monitor对一个报错转发一次，因此，leader的请求负载为fm，m为集群中monitor的数量。
我的感觉就是RADOS这个分发系统，通过OSD增加任务承担能力，减轻monitor的工作量。关键词是存储系统动态变化，集群扩建，更替，数据迁移，数据恢复。为了保证集群数据的一致性和可访问性引入Cluster map等机制，为ceph提供实现的基础。
再次内心os:读大神的论文都这么心累么？我怎么又看到了掉头发的未来。。。[/闭嘴]
