核心内容摘要
精品99视频：点燃你的视界，探索无限精彩
一案例背景在当今大数据时代数据存储和管理已成为企业IT架构中的关键环节。
分布式存储系统因其高可用性、高扩展性、低成本等优势逐渐成为企业数据存储的首选。
Ceph作为一款开源的分布式存储系统受到了越来越多企业和单位的关注和采用。
然而在享受Ceph带来的便利的同时如何应对因误操作等原因导致的数据丢失成为企业IT运维人员必须面对的问题。
二案例描述本文将介绍一个在OpenStack系统中使用KVM虚拟化和Ceph分布式存储服务器时因配置文件误删除且服务器没有备份容灾的情况下如何进行数据恢复的案例。
我们将详细阐述问题发生的原因、恢复过程以及预防措施为广大运维人员提供借鉴和参考。
系统环境
OpenStack版本Pike
KVM虚拟化
Ceph版本Luminous
存储服务器4台每台配置为32核CPU、128GB内存、8TB硬盘*8问题描述客户运维团队在对OpenStack平台进行日常维护时不慎误删了KVM虚拟化环境中Ceph分布式存储集群的一个关键配置文件。
这一突发状况立即引起了团队的警觉因为Ceph集群的配置文件包含了存储池的定义、OSD对象存储设备的映射、Ceph集群的osdmap、monmap、监控信息等核心数据删除后Ceph集群的部分存储池无法正常访问进而影响整个云服务业务的正常运行
总结起来有三点虚拟机无法启动KVM虚拟化的配置文件缺失将导致虚拟机无法启动或连接到正确的存储池。
存储节点故障Ceph的配置文件如果丢失可能导致存储节点之间无法正确通信影响数据的读写操作。
服务中断整个OpenStack云平台的服务可能因为配置文件的缺失而中断影响到业务的连续性。
三解决方案
应急响应客户联系我们以后我方技术团队面对这一紧急情况立即让客户的运维团队启动应急预案采取了以下措施
紧急停机首先为避免进一步的数据损坏立即停止了所有可能影响到Ceph集群的操作包括数据写入和读取。
环境评估对当前的Ceph分布式集群状态进行全面评估确认受影响的范围及程度包括哪些配置文件丢失是否已造成数据损坏等。
恢复挑战在服务器没有备份容灾的情况下进行数据恢复是极具挑战性的主要挑战包括无备份可用传统的恢复方式依赖于已有的备份而在没有备份的情况下需要通过日志文件、元数据和其他剩余数据来重建丢失的配置。
系统复杂性OpenStack平台与Ceph分布式存储的配置复杂恢复过程中稍有不慎就可能造成数据的永久性丢失。
时间紧迫在实际业务环境中服务的中断会带来巨大的损失因此需要快速而准确地进行恢复。
案例评估首先我们需要了解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个部分WALDBSLOW。
慢速(Slow)空间主要用于存储对象数据由BlueStore管理。
高速(DB)空间存储blufs和rocksdb产生的数据由BlueFS直接管理如果不存在或者DB设备空间不足则选择Slow类型设备空间。
超高速(WAL)空间主要存储RocksDB的WAL即.log文件由BlueFS直接管理如果不存在或者WAL设备空间不足则逐级降级选择DB、SLOW分区。
RocksdbBlueStore使用Rocksdb作为自己元数据存储的底层实现将各种元数据以kv型记录的方式存在数据库中。
写入机制任何元数据的写入都会先写到WAL然后再写入MemoryTable(Memtable)。
当一个Memtable写满了之后就会变成immutable的MemtableRocksDB在后台会通过一个flush线程将这个Memtableflush到磁盘生成一个SortedStringTable(SST)文件。
BlueFSBlueFS与通用文件系统不同是Bluestore专为Rocksdb所设计的精简文件系统。
BlueFS的文件和目录的元数据以日志事务的形式保存在日志文件中在上电过程中replay日志文件中的事务就可以加载所有的元数据到内存中。
在本案例中由于配置文件误删除导致部分OSD无法正常工作进而影响了存储池的访问。
我们还利用Ceph的日志文件进行了深入分析试图从日志中找到任何可能的线索比如配置文件的修改记录或异常操作。
虽然日志文件不能直接恢复丢失的配置文件但它提供了宝贵的参考信息帮助确认恢复操作的正确性和完整性。
恢复方案首先给大家梳理下Ceph分布式故障后常规处理的主要流程分为三大步骤感知集群状态Ceph集群分为MON集群和OSD集群两大部分。
其中MON集群由奇数个Monitor节点组成这些Monitor节点通过Paxos算法组成一个决策者集群共同作出关键集群事件的决策和广播。
“OSD节点离开”和“OSD节点加入”就是其中两个关键的集群事件。
MON集群管理着整个Ceph集群的成员状态将OSD节点的状态信息存放在OSDMap中OSD节点定期向MON和对等OSDPeer 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的更新。
确定受故障影响的数据Ceph中对象数据的维护由PGPlacement 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请求。
恢复受影响的数据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将无法正常进行。
为了保证恢复过程中不会中断正常的业务IOMON会分配PG Temp临时处理IO请求在数据恢复完成后再移除PG Temp。
同时在整个恢复过程中Ceph也允许用户通过配置文件调整恢复线程数同时进行的恢复操作数恢复数据网络传输优先级等相关参数来限制恢复的速度从而降低对正常业务的影响。
但是在本案例中因为涉及到了元数据的丢失所以以上常规的故障处理流程都不适用需使用专业Ceph数据恢复方案1备份当前Ceph集群状态为了防止在数据恢复过程中产生新的问题首先对当前Ceph集群状态进行备份# ceph tell mon.* backup2分析Ceph日志通过分析Ceph日志我们找到了误删除配置文件的详细过程。
由于Ceph的日志记录了详细的操作记录我们得以确定误操作的具体时间点。
3恢复元数据Ceph存储系统中保留的元数据可能包含原始配置文件的部分内容通过元数据的分析可以恢复部分关键配置。
4重建配置文件根据日志元数据和剩余配置文件我们手动重新编写配置文件尝试恢复了部分配置信息。
但是由于关键配置文件已删除部分信息无法完全恢复。
5手动扫描存储池为了找回丢失的数据针对ceph分布式的文件存储方式我们手动将服务器硬盘中的文件全部提取出来。
再分析文件的命名方式解析出文件磁盘卷的组合方式在同一组文件磁盘卷中文件的命名都存在同一ID例如5eB83240b4c1将所有文件将同一组文件磁盘卷的文件归类到统一文件夹并做好命名标记。
继续分析标记文件夹中文件在文件磁盘卷名称ID后存在文件排列顺序ID例如0000000000000000将标记文件夹文件以顺序ID排序发现文件顺序ID并不连续通过解析文件顺序ID之间相互的数据结构确定文件顺序ID丢失部分为文件磁盘卷中全为零的文件块手动将文件磁盘卷组合完成。
对组合完成的文件磁盘卷检验是否完整若有错误则继续上一步操作若无错误则手动提取恢复的数据。
6重新配置Ceph集群根据恢复的数据我们重新配置了Ceph集群。
在Ceph集群恢复正常后我们重新配置了KVM虚拟化确保虚拟机可以正常使用Ceph分布式存储。
7测试并验证在恢复完成后进行全面的测试确保所有虚拟机能够正常启动存储系统能够正常读写数据主要通过以下三个步骤配置检查使用Ceph提供的命令行工具检查集群的配置状态确保所有配置项均已正确恢复数据一致性校验运行数据一致性校验工具验证Ceph集群中的数据是否完整无损。
性能测试进行一系列的读写性能测试评估恢复后Ceph集群的性能是否满足业务需求。
经过验证存储池恢复正常业务运行未受影响。
四案例
总结经过紧张而有序的工作我方技术团队终于成功恢复了Ceph分布式存储服务器集群的配置文件并确保了整个系统环境的稳定运行。
此次事件虽然惊心动魄但也带来了宝贵的经验教训加强备份管理务必建立健全的备份机制定期备份Ceph集群关键配置文件和数据确保备份的完整性和可用性以防不测。
提高安全意识合理设置管理员权限加强运维人员的安全教育和培训提升自身的运维能力和数据保护水平降低人为错误的发生概率。
完善应急预案制定规范的操作流程不断完善和优化应急预案确保在紧急情况下能够迅速、有效地响应。
加强监控与日志分析开启日志审计功能记录管理员的所有操作便于追溯和排查问题充分利用监控系统和日志分析工具及时发现并处理潜在问题。
Ceph是当前非常流行的开源分布式存储系统具有高扩展性、高性能、高可靠性等优点同时提供块存储服务(rbd)、对象存储服务(rgw)以及文件系统存储服务(cephfs)。
目前也是OpenStack的主流后端存储和OpenStack亲如兄弟为OpenStack提供统一共享存储服务。
使用Ceph作为OpenStack后端存储具有如下优点所有的计算节点共享存储迁移时不需要拷贝根磁盘即使计算节点挂了也能立即在另一个计算节点启动虚拟机evacuate。
利用COWCopy On Write)特性创建虚拟机时只需要基于镜像clone即可不需要下载整个镜像而clone操作基本是0开销从而实现了秒级创建虚拟机。
Ceph RBD支持thin provisioning即按需分配空间有点类似Linux文件系统的sparse稀疏文件。
创建一个20GB的虚拟硬盘时最开始并不占用物理存储空间只有当写入数据时才按需分配存储空间。
OpenStack和KVM有什么区别OpenStack和KVM虽然都属于云计算技术领域的范畴但两者有着不同的概念。
简单来说OpenStack是一个开源的云计算管理平台项目由多个主要的组件构成可以用来部署和管理云计算平台中的各种资源而KVMKernel-based Virtual Machine是一种基于Linux内核实现的开源虚拟化技术可以将Linux内核转化为一个超级虚拟机监控器。
OpenStack和KVM的关系OpenStack是云管理平台其本身并不提供虚拟化功能真正的虚拟化能力是由底层的Hypervisor如KVM、Qemu、Xen等提供。
而OpenStack则可以管理KVM虚拟化环境。
KVM可帮助您将Linux转变为虚拟机监控程序使主机计算机能够运行多个隔离的虚拟环境即虚拟客户机或虚拟机VM。
它是目前比较热门的虚拟化方案例如许多国外主机都是基于KVM虚拟化的。
KVM这样的Hypervisor软件实际上是提供了一种虚拟化能力模拟CPU的运行更为底层。
但是它的用户交互并不良好不方便使用。
于是为了更好地管理虚拟机就需要OpenStack这样的云管理平台。
当数据发生丢失时海境超备研发团队深入研究各种服务器和系统设计思路认真对比故障类别攻克疑难恢复案例