【服务器数据恢复】数据中心存储服务器Ceph分布式文件系统存储架构数据恢复解析

在当今大数据时代，数据存储和管理已成为企业IT架构中的关键环节。分布式存储系统因其高可用性、高扩展性、低成本等优势，逐渐成为企业数据存储的首选。Ceph作为一款开源的分布式存储系统，受到了越来越多企业和单位的关注和采用。然而，在享受Ceph带来的便利的同时，如何应对因误操作等原因导致的数据丢失，成为企业IT运维人员必须面对的问题。本文将详细介绍Ceph分布式文件系统的原理和特点，并解析其数据恢复的原理和方法。

分布式文件系统（Distributed File System，DFS）是一种能够在多台计算机之间共享文件存储资源的系统。它将文件存储在多个节点上，这些节点通常是位于不同地理位置的服务器或计算机集群。分布式文件系统的核心目标是提高文件存储的可靠性、可扩展性和性能，同时为用户提供透明的文件访问体验，仿佛文件是存储在单一的本地文件系统中一样。

主要特点包括：

1. 数据冗余与容错：通过将文件复制到多个节点上，分布式文件系统可以在某些节点发生故障时仍然保证数据的可用性。这种冗余机制增强了系统的容错能力。

2. 可扩展性：分布式文件系统可以轻松地增加或减少存储节点，以适应数据量的变化。系统可以横向扩展以处理更大的数据集和更多的用户请求。

3. 高性能：通过并行存取和分布式计算，分布式文件系统能够加快文件的读取和写入速度，特别是在处理大规模数据时表现尤为显著。

4. 透明性：用户和应用程序在使用分布式文件系统时，感知不到数据实际存储在何处，系统提供的统一接口使得文件操作如同在本地文件系统中操作一样简单。

5. 一致性：为了保证数据的一致性，分布式文件系统通常会实现某种形式的分布式锁或事务机制，确保在多个用户同时访问或修改数据时不会产生冲突或数据损坏。

典型应用场景：

大规模数据存储：如大数据处理框架中的Hadoop分布式文件系统（HDFS）。

云存储：如Amazon S3、Google Cloud Storage等。

企业级存储解决方案：如Ceph、GlusterFS等，用于构建高可用、高扩展的存储基础设施。

常见的分布式文件系统：

HDFS（Hadoop Distributed File System）：为Hadoop生态系统设计的分布式文件系统，擅长存储和处理海量数据。

Ceph：一个开源的分布式存储系统，支持对象存储、块存储和文件系统接口，具有高可靠性和灵活性。

GlusterFS：一个开源的分布式文件系统，擅长处理大量的小文件，并提供弹性和易扩展的存储解决方案。

vSAN：一种以VMware vSphere内核为基础进行开发、可扩展的分布式存储架构。

分布式文件系统的应用涵盖了从大数据处理、云存储到企业存储解决方案的广泛领域，适合需要高可靠性、高可用性和高性能存储的场景。

众所周知，Ceph是近年来最为炙手可热的开源分布式存储系统，跟其他分布式存储系统不一样的是，Ceph在称之为RADOS的核心对象存储架构之上，提供了块存储、文件存储以及对象存储的接口，因此Ceph可以称之为统一存储（Unified Storage）。Ceph主要由Monitors、Managers、OSDs三种类型的组件组成。其中，Monitors负责维护集群状态信息，Managers负责管理集群资源，OSDs负责存储数据。

Ceph的底层是RADOS(分布式对象存储系统)，RADOS由两部分组成：OSD和MON。MON负责监控整个集群，维护集群的健康状态，维护展示集群状态的各种图表，如OSDMap、MonitorMap、PGMap和CRUSHMap。OSD负责存储数据、复制数据、平衡数据、恢复数据，与其它OSD间进行心跳检查等。通常情况下一块硬盘对应一个OSD。

Ceph分布式数据的存储过程，无论使用哪种存储方式（对象、块、文件），存储的数据都会被切分成对象（Objects)。

存储池：不同用户因为不同的目的把对象存储在不同的存储池里，这些对象分布于OSD上。对象保存在不同的存储池（Pool）中，是对象存储的逻辑组，对应不同的用户。存储池管理着归置组数量、副本数量、和存储池规则集。

归置组：归置组（PGPlacementGroup）是对象池的片段，Ceph根据对象的Oid和一些其他信息做计算操作，映射到归置组，无数的对象被划分到不同的归置组。PG是一个逻辑概念，它在数据寻址时类似于数据库中的索引。每个对象都会固定映射进一个PG中，所以当我们要寻找一个对象时，只需要先找到对象所属的PG，然后遍历这个PG就可以了，无需遍历所有对象。而且在数据迁移时，也是以PG作为基本单位进行迁移。

OSD：最后PG会根据管理员设置的副本数量进行复制，然后通过crush算法存储到不同的OSD节点上，最终把PG中的所有对象存储到OSD节点上。

BlueStore：在新版本中，Ceph默认以Bluestore存储引擎，作为RADOS中OSD的ObjectStore存储底层实现BlueStore整体架构。

存储空间：BlueStore将整个存储空间分为3个部分：WAL，DB，SLOW。慢速(Slow)空间：主要用于存储对象数据，由BlueStore管理。高速(DB)空间：存储blufs和rocksdb产生的数据，由BlueFS直接管理，如果不存在或者DB设备空间不足，则选择Slow类型设备空间。超高速(WAL)空间：主要存储RocksDB的WAL（即.log）文件，由BlueFS直接管理，如果不存在或者WAL设备空间不足，则逐级降级选择DB、SLOW分区。

Rocksdb：BlueStore使用Rocksdb作为自己元数据存储的底层实现，将各种元数据以kv型记录的方式存在数据库中。写入机制：任何元数据的写入都会先写到WAL，然后再写入MemoryTable(Memtable)。当一个Memtable写满了之后，就会变成immutable的Memtable，RocksDB在后台会通过一个flush线程将这个Memtableflush到磁盘，生成一个SortedStringTable(SST)文件。

BlueFS：BlueFS与通用文件系统不同，是Bluestore专为Rocksdb所设计的精简文件系统。BlueFS的文件和目录的元数据以日志事务的形式保存在日志文件中，在上电过程中，replay日志文件中的事务，就可以加载所有的元数据到内存中。

不过和一般分布式系统一样的是，Ceph分布式同样使用多副本机制来保证数据的高可靠性，一份数据Ceph在后台会自动存储多份副本，从而使得在硬盘损毁、服务器故障、机柜停电等故障情况下，不会出现数据丢失，甚至数据仍能保持在线。不过在故障发生后，Ceph需要及时做故障恢复，将丢失的数据副本补全，以维系持续的数据高可靠性。

因此多副本机制是分布式存储系统的核心机制之一，它带来了数据高可靠性，也提高了数据可用性。然而事情是没有十全十美的，多副本机制同时带来了分布式系统的最大问题之一：数据一致性，保持数据一致性是故障恢复流程的难点之一。除此之外，Ceph分布式数据恢复（或者说分布式存储数据恢复）还有其他几个难点：

1.感知故障，并自动触发数据恢复。做到这点，能减轻运维压力，也使发现和处理故障更为及时；

2.尽量降低数据恢复过程中对集群资源的消耗。比如最为明显的，如何减少网络带宽的占用。Ceph恢复数据的时候，是拷贝整个4M对象，还是只恢复有差异的数据，这两种方式直接影响网络间传输的数据量；

3.数据恢复是否影响用户的线上业务，Ceph分布式是如何控制和降低这个影响的？

首先给大家梳理下Ceph分布式故障后，常规处理的主要流程，分为三大步骤：

1.感知集群状态

Ceph集群分为MON集群和OSD集群两大部分。其中MON集群由奇数个Monitor节点组成，这些Monitor节点通过Paxos算法组成一个决策者集群，共同作出关键集群事件的决策和广播。“OSD节点离开”和“OSD节点加入”就是其中两个关键的集群事件。

MON集群管理着整个Ceph集群的成员状态，将OSD节点的状态信息存放在OSDMap中，OSD节点定期向MON和对等OSD（Peer OSD）发送心跳包，声明自己处于在线状态。MON接收来自OSD的心跳消息确认OSD在线；同时，MON也接收来自OSD对于Peer OSD的故障检测。MON根据心跳间隔等信息判定OSD是否在线，同时更新OSDMap并向各个节点通告最新集群状态。比如某台服务器宕机，其上OSD节点和MON集群的心跳超时或是这些OSD的对等OSD发送的失败通告超过阈值后，这些OSD将被MON集群判定为离线。

判定OSD节点离线后，Ceph将最新的OSDMap通过消息机制随机分发给一个OSD，客户端（对等OSD）处理IO请求的时候发现自身的OSDMap版本过低，会向MON请求最新的OSDMap。每个OSD中PG的另外两个副本可能在集群任意OSD中，借此经过一段时间的传播，最终整个集群的OSD都会接收到OSDMap的更新。

2.确定受故障影响的数据

Ceph中对象数据的维护由PG（Placement Group）负责，PG作为Ceph中最小的数据管理单元，直接管理对象数据，每个OSD都会管理一定数量的PG。客户端对于对象数据的IO请求，会根据对象ID的Hash值均衡分布在各个PG中。PG中维护了一份PGLog，用来记录该PG的数据变化，这些记录会被持久化记录到后端存储中。

PGLog中记录了每次操作的数据和PG的版本，每次数据变更操作都会使PG的版本自增，PGLog中默认保存3000条记录，PG会定期触发Trim操作清理多余的PGLog。通常情况下，在同一个PG的不同副本中的PGLog应该是一致的，故障发生后，不同副本的PGLog可能会处于不一致的状态。

OSD在收到OSDMap更新消息后，会扫描该OSD下所有的PG，清理已经不存在的PG（已经被删除等情况），对PG进行初始化，如果该OSD上的PG是Primary PG的话，PG将进行Peering操作。在Peering的过程中，PG会根据PGLog检查多个副本的一致性，并尝试计算PG的不同副本的数据缺失，最后得到一份完整的对象缺失列表，用作后续进行Recovery操作时的依据。对于无法根据PGLog计算丢失数据的PG，需要通过Backfill操作拷贝整个PG的数据来恢复。需要注意的是，在这Peering过程完成前，PG的数据都是不可靠的，因此在Peering过程中PG会暂停所有客户端的IO请求。

3.恢复受影响的数据

Peering完成后，PG进入Active状态，并根据PG的副本状态将自己标记为Degraded/Undersized状态，在Degraded状态下，PGLog存储的日志数量默认会扩展到10000条记录，提供更多的数据记录便于副本节点上线后的数据恢复。进入Active状态后，PG可用并开始接受数据IO的请求，并根据Peering的信息决定是否进行Recovery和Backfill操作。

Primary PG将根据对象的缺失列表进行具体对象的数据拷贝，对于Replica PG缺失的数据Primary 会通过Push操作推送缺失数据，对于Primary PG缺失的数据会通过Pull操作从副本获取缺失数据。在恢复操作过程中，PG会传输完整4M大小的对象。对于无法依靠PGLog进行Recovery的，PG将进行Backfill操作，进行数据的全量拷贝。待各个副本的数据完全同步后，PG被标记为Clean状态，副本数据保持一致，数据恢复完成。

通过Ceph处理故障的流程，我们可以看到Ceph如何应对集群故障常见的问题。首先是减少对资源的消耗：在断电重启这类故障中，Ceph可以只恢复有变化的数据，从而减少数据恢复量；另一方面，MON不会主动向所有OSD推送集群状态，而是采用OSD主动获取最新OSDMap的方式防止大规模集群发生故障场景下产生突发流量。

另外，由于Ceph的IO流程必须要通过Primary PG进行，一旦Primary PG所在的OSD宕机，IO将无法正常进行。为了保证恢复过程中不会中断正常的业务IO，MON会分配PG Temp临时处理IO请求，在数据恢复完成后再移除PG Temp。同时在整个恢复过程中，Ceph也允许用户通过配置文件调整恢复线程数，同时进行的恢复操作数，恢复数据网络传输优先级等相关参数来限制恢复的速度，从而降低对正常业务的影响。

可以看出Ceph分布式在数据恢复方面，设计和细节做的都相当不错。但是，目前Ceph数据恢复的颗粒度仍然比较大，需要更多的IO消耗；并且，被动的OSDMap更新可能会导致PG不会及时恢复故障数据，在一段时间内数据可靠性会降低。同时，我们在Ceph分布式日常处理故障时需要注意以下细节：

1.PGLog是Ceph进行数据恢复的重要依据，但是记录的日志数量有限，所以在发生故障后，尽快让故障节点重新上线，尽量避免产生Backfill操作，能极大的缩短恢复时间。

2.PG在Peering阶段会阻塞客户端IO，所以要保证PG能快速进行Peering。

3.如果在故障过程中PGLog丢失，导致无法完成Peering，PG会进入Incomplete状态，这种情况下需要让故障节点上线帮助完成数据修复。

虽然Ceph分布式的Recovery操作能够避免很多不必要的对象数据恢复，但是使用的还是完全对象拷贝。如果需要进一步的优化，可以考虑在PGLog中记录操作对象的具体数据位置、或是利用类似rsync的机制，只恢复对象副本间的差异数据。本文通过简单梳理Ceph分布式对于集群故障的处理，帮助我们在日常应用中更好的维护Ceph分布式集群，保证业务数据持续可用。