一：客户信息
内蒙古某警务云数据中心
二：案例背景
什么是分布式文件系统
分布式文件系统（DistributedFile System，DFS）是一种能够在多台计算机之间共享文件存储资源的系统。它将文件存储在多个节点上，这些节点通常是位于不同地理位置的服务器或计算机集群。分布式文件系统的核心目标是提高文件存储的可靠性、可扩展性和性能，同时为用户提供透明的文件访问体验，仿佛文件是存储在单一的本地文件系统中一样。
Ceph的三种存储结构
对象存储：Ceph 提供 S3 和 Swift 兼容的RESTful API，用于存储和检索对象数据。
块存储：Ceph 提供块设备接口，支持虚拟机的块存储，如 KVM、OpenStack 等虚拟化平台。
文件系统：Ceph 提供一个 POSIX 兼容的文件系统（CephFS），支持传统的文件存储需求。
三：案例描述
环境：客户基于3台存储节点构成的ceph分布式存储集群，搭配KVM虚拟机使用，系统内存有若干台虚拟机，每台节点64块硬盘，由2块480G系统盘+4块1TB的SSD闪存盘+64块8TB的物理盘构成。
故障原因：几个月前误删除一台虚拟机，已联系其他数据恢复公司，删除后的第一时间进行了硬盘镜像，但由于该ceph版本较新，没有任何软件能够支持恢复处理，故一直无法恢复虚拟机内存储的归档文件。
四：解决方案
1.应急响应
客户联系我们以后，我方技术团队面对这一紧急情况，立即让客户的运维团队启动应急预案，采取了以下措施：
1.紧急停机：首先，为避免进一步的数据损坏，立即停止了所有可能影响到Ceph集群的操作，包括数据写入和读取。
2.环境评估：对当前的Ceph分布式集群状态进行全面评估，确认受影响的范围及程度，包括哪些配置文件丢失，是否已造成数据损坏等。
2.恢复挑战
在服务器没有备份容灾的情况下进行数据恢复是极具挑战性的，主要挑战包括：
无备份可用：传统的恢复方式依赖于已有的备份，而在没有备份的情况下，需要通过日志文件、元数据和其他剩余数据来重建丢失的配置。
系统复杂性：KVM平台与Ceph分布式存储的配置复杂，恢复过程中稍有不慎就可能造成数据的永久性丢失。
时间紧迫：在实际业务环境中，服务的中断会带来巨大的损失，因此需要快速而准确地进行恢复。
3.案例评估
首先，我们需要了解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日志文件中的事务，就可以加载所有的元数据到内存中。
在本案例中，由于配置文件误删除，导致部分OSD无法正常工作，进而影响了存储池的访问。我们还利用Ceph的日志文件进行了深入分析，试图从日志中找到任何可能的线索，比如配置文件的修改记录或异常操作。虽然日志文件不能直接恢复丢失的配置文件，但它提供了宝贵的参考信息，帮助确认恢复操作的正确性和完整性。
4.恢复方案
首先给大家梳理下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数据恢复方案：
1.数据分析：
1.1：BlueStore架构
用winhex随机查看一块1TB的闪存盘和一块12TB的物理盘，查看关键扇区：得知该ceph分布式存储系统是基于bluestore架构构成的，采用的是ceph的块存储。
BlueStore是 Ceph 的一种存储引擎，设计用于直接管理原始块设备（如 HDD 或 SSD）而不是通过文件系统来存储数据。与传统的基于文件系统的存储引擎（如 Filestore）相比，BlueStore 提供了更高的性能和更高效的存储利用率。
由于我司对ceph数据存储的16进制结构十分了解，（可以使用winhex直接手动提取数据文件），并有多起类似的数据恢复的成功案例，故直接开始提取数据。
1.2分布式存储中元数据概述
提取之前，首先要科普1下元数据的作用，方便大家理解：
在分布式存储系统中，元数据是系统运转的关键，它不仅支撑了数据的存储、访问、复制和恢复，还在负载均衡、安全管理、去重等方面发挥了重要作用。由于分布式存储系统的复杂性和规模性，元数据的管理和优化对系统的性能、可靠性和可扩展性有着直接影响。
大概归类为：
数据定位与访问：
在分布式存储系统中，数据通常被拆分成多个块，并分布在不同的存储节点上。元数据用于记录每个数据块的位置、存储节点的地址、块的大小、复制数量等信息。
如：当客户端请求访问某一数据时，系统首先查找相关的元数据，以确定数据块所在的节点，然后从这些节点读取数据。比如我司曾处理过的HDFS分布式存储中，NameNode 负责管理元数据，记录文件的分块信息以及这些块所在的 DataNode。当用户请求文件时，NameNode 提供数据块的位置，客户端再从对应的 DataNode 中获取数据。
数据复制与一致性：
分布式存储系统为了确保数据的可靠性和可用性，通常会将数据复制到多个节点。元数据在这种场景中记录了每个数据块的副本数量、位置以及版本信息。
如：当一个数据文件被更新时，元数据会记录新的ID号，并触发其他数据文件的更新。如在本作的Ceph分布式存储系统中，Ceph Monitor 维护了集群的元数据，包括存储池、数据副本位置和状态等。
故障检测与恢复：
分布式存储系统需要处理节点故障、数据损坏等问题。元数据记录了哪些节点存储了哪些数据块，因此，当某个节点发生故障时，系统可以利用元数据来重新分配数据块，确保数据的完整性。
如：当某个节点不可用时，系统可以通过元数据识别丢失的数据块，并从其他副本中恢复这些数据。例如，在 Amazon S3云存储中，元数据会跟踪每个对象的存储位置和状态，如果某个存储节点失效，系统可以自动从其他节点恢复数据。
负载均衡与扩展：
为了保证系统的性能，需要对存储节点的负载进行均衡，并且系统可能需要随着数据量的增长进行扩展。元数据可以提供关于当前数据分布、节点负载的统计信息，以帮助系统做出负载均衡和扩展决策。
如：元数据帮助系统决定新数据应该存放在哪些节点上，以及何时将某些数据迁移到其他节点以平衡负载。比如在老版本的ceph分布式存储系统中，当时没有bluestore架构，元数据可以让系统决定将新数据写入哪个XFS分区中，以避免某些节点过载。
元数据总结：元数据=数据标签，分布式系统中的元数据大致等于（不限于）windows平台中NTFS文件系统中的MFT、linux平台中EXT4、XFS等多种文件系统中的index，只不过在分布式存储系统中我们称为”元数据”。
1.3提取元数据
提取元数据中我司内部定义的能够支持本次数据恢复提取的三种类型（仅代表我司内部拟定的统称，与外界同名的类型存在一定偏差），并创建数据库进行存储：
meta_chunk：元数据自身空间分布信息
meta_data：元数据本身
meta_id：元数据内部通信
1.3.1：获取12个SSD闪存盘的“OSD”位图：在当前ceph分布式存储系统中：除系统盘外，每个成员盘为1个OSD块。只不过这个块过于巨大（大块），即每个物理盘的数据位图，然后从12块闪存盘中分离出元数据存储在哪些小块内的meta_chunk信息。
在块存储的Ceph中，对于底层来说，OSD的含义和CephFS中差异较大，本案例为块存储案例，故加“”。
1.3.2：获取meta_data
根据获取的meta_chunk信息，提取出现有的完整的元数据，再根据现有元数据特征（多特征），获取所有能够提取的元数据，我们依据meta_data将元数据按记录的数据类型再次归类（本次案例只列出3种对本次恢复有关的类型：文件名、目录、osd空间分配）。
1.3.3.元数据整理
依据meta_data内的meta_id的信息记录，分离现有数据和丢失数据的meta_data（包含当前持久化之前的曾经存在过的瞬时状态的数据）。
1.3.4.计算数据地址
将元数据重组，解析meta_data内键值记录的字节流，获得数据的OSD小块ID，但由于元数据数量过于庞大，只能通过自建一个“元数据数据库”来存储和管理这些信息。
2.数据恢复提取
2.1：将meta_data与osd小块进行关联，获取meta_data内记录的存储结构，本次案例获取为4+2结构，即一份数据切割为4份存储，再配两份校验，即4+2，有些厂商对客户也称为“三副本”
这里小编也觉得奇怪，按理说三副本是指的三份文件副本1+1+1的方式，但是在实际遇到的有些客户说厂家给他们说的三副本，但其实小编看到是4+2。
2.2：从KVM的日志中获取虚拟机的唯一识别码，与meta_data关联，锁定所需恢复的虚拟机名。
2.3：通过自建的“元数据数据库”引导提取对应的每个osd小块，然后按照4+2组合成虚拟磁盘文件的碎片，再通过大量碎片的组合，最终形成完整的虚拟磁盘文件。
2.4：使用winhex或常见的数据恢复工具对虚拟磁盘文件进行展开，导出里面的数据或生成新的虚拟磁盘文件交付给客户。
五：案例总结
经过紧张而有序的工作，我方技术团队终于成功恢复了Ceph分布式存储服务器集群的配置文件，并确保了整个系统环境的稳定运行。此次事件虽然惊心动魄，但也带来了宝贵的经验教训：
1. 加强备份管理：务必建立健全的备份机制，定期备份Ceph集群关键配置文件和数据，确保备份的完整性和可用性，以防不测。
2. 提高安全意识：合理设置管理员权限，加强运维人员的安全教育和培训，提升自身的运维能力和数据保护水平，降低人为错误的发生概率。
3. 完善应急预案：制定规范的操作流程，不断完善和优化应急预案，确保在紧急情况下能够迅速、有效地响应。
4. 加强监控与日志分析：开启日志审计功能，记录管理员的所有操作，便于追溯和排查问题，充分利用监控系统和日志分析工具，及时发现并处理潜在问题。
Ceph是当前非常流行的开源分布式存储系统，具有高扩展性、高性能、高可靠性等优点，同时提供块存储服务(rbd)、对象存储服务(rgw)以及文件系统存储服务(cephfs)。目前也是OpenStack的主流后端存储，和OpenStack亲如兄弟，为OpenStack提供统一共享存储服务。使用Ceph作为OpenStack后端存储，具有如下优点：
所有的计算节点共享存储，迁移时不需要拷贝根磁盘，即使计算节点挂了，也能立即在另一个计算节点启动虚拟机（evacuate）。
利用COW（Copy On Write)特性，创建虚拟机时，只需要基于镜像clone即可，不需要下载整个镜像，而clone操作基本是0开销，从而实现了秒级创建虚拟机。
Ceph RBD支持thin provisioning，即按需分配空间，有点类似Linux文件系统的sparse稀疏文件。创建一个20GB的虚拟硬盘时，最开始并不占用物理存储空间，只有当写入数据时，才按需分配存储空间。
OpenStack和KVM有什么区别？OpenStack和KVM虽然都属于云计算技术领域的范畴，但两者有着不同的概念。简单来说，OpenStack是一个开源的云计算管理平台项目，由多个主要的组件构成，可以用来部署和管理云计算平台中的各种资源；而KVM（Kernel-based Virtual Machine）是一种基于Linux内核实现的开源虚拟化技术，可以将Linux内核转化为一个超级虚拟机监控器。
OpenStack和KVM的关系：OpenStack是云管理平台，其本身并不提供虚拟化功能，真正的虚拟化能力是由底层的Hypervisor（如KVM、Qemu、Xen等）提供。而OpenStack则可以管理KVM虚拟化环境。KVM可帮助您将Linux转变为虚拟机监控程序，使主机计算机能够运行多个隔离的虚拟环境，即虚拟客户机或虚拟机（VM）。它是目前比较热门的虚拟化方案，例如许多国外主机都是基于KVM虚拟化的。KVM这样的Hypervisor软件，实际上是提供了一种虚拟化能力，模拟CPU的运行，更为底层。但是它的用户交互并不良好，不方便使用。于是，为了更好地管理虚拟机，就需要OpenStack这样的云管理平台。
当数据发生丢失时，金海境科技研发团队深入研究各种服务器和系统设计思路，认真对比故障类别，攻克疑难恢复案例，总结成功恢复经验，拥有成功修复服务器数据库，虚拟化平台，分布式存储等数据中心相关的上万个疑难案例，并掌握了勒索病毒恢复核心技术，所有恢复的数据不丢记录，结构完整，直接使用，不报错。