图解Ceph - 实践

Ceph就是什么

Ceph 是一个开源的分布式存储系统，具有以下特点：

统一存储平台：同时支撑对象存储、块设备、文件系统
高可用性：无单点故障
高扩展性：可扩展至 PB 级别
自动化管理：自动数据分布和恢复

核心特性

特性	说明
统一存储	一套平台支持块、文件、对象三种存储
去中心化	没有中央元数据服务器，启用 CRUSH 算法
高可用	数据多副本或纠删码，自动故障转移
横向扩展	线性扩展性能与容量
自动修复	自动检测并修复信息错误
企业级特性	支撑快照、克隆、精简部署等高级特性

应用场景

云计算平台

OpenStack Cinder（块存储）
OpenStack Glance（镜像存储）
OpenStack Swift 替代（对象存储）

虚拟化平台

KVM/QEMU 虚拟机磁盘
VMware 替代方案
容器持久化存储（Kubernetes）

大数据平台

Hadoop/Spark 内容存储
数据湖构建
机器学习数据集存储

备份归档

企业级备份架构
视频监控存储
日志归档

核心架构

flowchart TD
    subgraph Interface Layer
        A1[LibRADOS API]
        A2[RADOS Gateway
(S3 / Swift)]
        A3[RBD Block Device]
        A4[CephFS Filesystem]
    end
    subgraph RADOS Core
        B1[Cluster Map]
        B2[CRUSH Algorithm]
        B3[Placement Groups]
        B4[Data Replication
 & Healing]
    end
    subgraph Storage Layer
        C1[OSD Daemons]
        C2[HDD / SSD]
        C3[Network Fabric]
    end
    A1 --> B1
    A2 --> B1
    A3 --> B1
    A4 --> B1
    B1 --> B2 --> B3 --> C1 --> C2
    C1 --> B4
    B4 --> B1
    C3 --- C1

架构层次说明

接口层
- LibRADOS：原生对象存储 API
- RADOSGW：S3/Swift 兼容的对象存储网关
- RBD：块设备接口
- CephFS：POSIX 兼容的分布式文件系统
RADOS 核心层
- 可靠、自动化、分布式的对象存储
- 实现数据存储、复制、检测、恢复
- 采用 CRUSH 算法实现数据分布
存储层
- 底层物理存储设备（HDD/SSD）
- OSD 守护进程管理
- 数据持久化位置

核心组件详解

MON（Monitor）监视器

功能职责

集群状态维护：维护整体健康状态
Map 管理：管理 MON Map、OSD Map、PG Map、CRUSH Map、MDS Map
认证服务：供应 Cephx 认证
仲裁服务：使用 Paxos 算法保证一致性

部署建议

数量：生产环境至少 3 个（推荐 5 个）
部署位置：分散在不同物理主机
硬件要求：CPU 2-4 核、内存 4-8 GB、SSD 50-100 GB、千兆及以上网络

高可用机制

经过多副本和 Paxos 仲裁构建

OSD（Object Storage Daemon）

功能职责

数据存储：负责对象实际材料落盘
数据复制：主 OSD 负责副本同步
数据恢复：故障后自动恢复数据
心跳检测：OSD 之间互相监控存活
素材平衡：参与素材重平衡

图解：略

存储后端对比

特性	FileStore（旧）	BlueStore（新）
文件系统	依赖 XFS/EXT4	直接管理裸设备
性能	较低	更高，减少一层抽象
双写问题	存在	解决
元数据管理	运用文件系统	使用 RocksDB
推荐度	已弃用	推荐

部署建议

磁盘配比：
- Journal/WAL：SSD，容量为数据盘的 1%-2%
- 数据盘：HDD 或 SSD
- 1 块 SSD 可支持 4-6 块 HDD 的 Journal
硬件要求：
- CPU：每个 OSD 0.5-1 核
- 内存：每个 OSD 2-4 GB（BlueStore 需要更多）
- 网络：万兆网络（10 GbE+）

MDS（Metadata Server）

功能职责

仅 CephFS 需要（块存储和对象存储不使用 MDS）
元数据管理：维护目录结构、文件属性
权限控制：负责记录权限验证
缓存管理：提升元资料访问性能

部署建议

生产环境至少 2 个（主备）
拥护 Active-Active 多活
建议 8 GB 以上内存

RGW（RADOS Gateway）

功能职责

提供 RESTful API
兼容 Amazon S3 API
兼容 OpenStack Swift API
支持多租户、桶版本控制、生命周期管理

数据存储机制

核心概念

Pool（存储池）
- 逻辑存储分区，类似命名空间
- 属性：PG 数量、副本数（或纠删码）、CRUSH 规则、应用类型（rbd、rgw、cephfs）
PG（Placement Group，归置组）
- 对象与 OSD 之间的逻辑映射层
- 作用：简化数据管理、达成负载均衡、提高故障恢复效率
Object（对象）
- Ceph 存储的基本单元
- 默认大小 4 MB（可配置）
- 组成：对象数据、对象元信息、对象 ID

内容映射关系

详细流程

文件分片
- 例如 100 MB 文件 -> 25 个对象（每个 4 MB）
对象映射到 PG
- object_id -> hash -> PG_id
- PG_id = hash(object_id) % pg_num
PG 映射到 OSD
- CRUSH(PG_id, cluster_map) -> [OSD.1, OSD.5, OSD.9]
- 第一个为主、副本跟随

数据读取流程

数据写入流程

Ceph 元数据保存方式

对象元数据以 key-value 形式存储，分为两种实现：xattrs 和 omap
可选后端包括 FileStore、KVStore、MemStore，目前主要采用 BlueStore（基于 RocksDB）

xattrs（扩展属性）

元资料保存在对象对应文件的扩展属性中，要求底层文件系统（如 XFS）支持扩展属性

omap（Object Map）

将元资料保存在独立的 key-value 存储中
FileStore 利用 LevelDB，BlueStore 使用 RocksDB
FileStore 需格式化 XFS，存在性能与可靠性问题，BlueStore 为主流方案

FileStore 与 LevelDB

Ceph 早期 FileStore 使用 Google LevelDB 保存元数据
LevelDB 为持久化 KV 框架，将数据存储于磁盘
FileStore 将内容保存在 POSIX 兼容文件系统（Btrfs、XFS、Ext4）
存在性能限制及对象属性映射限制

图解：略

FileStore 数据写入过程

FileStore 日志的三个阶段

CRUSH 算法

CRUSH（Controlled Replication Under Scalable Hashing）是一种可控、可复制、可伸缩的一致性哈希算法，是 Ceph 智能数据分发机制的核心。

伪随机：确定性算法，相同输入产出一致
分布式：客户端独立计算，无需中心查表
层次化：支持艰难故障域定义
可配置：通过 CRUSH Map 自定义规则

工作原理概述

直接将对象映射到 OSD 会导致耦合，当 OSD 变化大时影响全局
Ceph 将映射拆分为两步：对象 -> PG -> OSD
全过程通过实时计算完成，无需中心化元数据服务
客户端使用 CRUSH 查找并直接与 OSD 通信
CRUSH 拥护灵活的拓扑和故障域配置，实现高效扩展

posted @ 2025-12-08 13:39 yangykaifa 阅读(16) 评论(0) 收藏举报

刷新页面返回顶部