Ceph分布式存储

目录

一、Ceph概述

二、Ceph优势

三、Ceph架构

四、Ceph 核心组件

五、OSD 存储引擎

六、Ceph数据的存储过程

七、Ceph 集群部署

1.环境准备

2.部署 Ceph 集群

3.资源池 Pool 管理


一、Ceph概述

Ceph使用C++语言开发,是一个开放、自我修复和自我管理的开源分布式存储系统。具有高扩展性、高性能、高可靠性的优点。

Ceph目前已得到众多云计算厂商的支持并被广泛应用。RedHat及OpenStack,Kubernetes都可与Ceph整合以支持虚拟机镜像的后端存储。
粗略估计,我国70%—80%的云平台都将Ceph作为底层的存储平台,由此可见Ceph俨然成为了开源云平台的标配。目前国内使用Ceph搭建分布式存储系统较为成功的企业有华为、阿里、中兴、华三、浪潮、中国移动、网易、乐视、360、星辰天合存储、杉岩数据等。

二、Ceph优势

  • 高扩展性:去中心化,支持使用普通X86服务器,支持上千个存储节点的规模,支持TB到EB级的扩展。

  • 高可靠性:没有单点故障,多数据副本,自动管理,自动修复。
  • 高性能:摒弃了传统的集中式存储元数据寻址的方案,采用 CRUSH 算法,数据分布均衡,并行度高。
  • 功能强大:Ceph是个大一统的存储系统,集块存储接口(RBD)、文件存储接口(CephFS)、对象存储接口(RadosGW)于一身,因而适用于不同的应用场景。

三、Ceph架构

自下向上,可以将Ceph系统分为四个层次:

  • RADOS 基础存储系统(Reliab1e,Autonomic,Distributed object store,即可靠的、自动化的、分布式的对象存储)
    RADOS是Ceph最底层的功能模块,是一个无限可扩容的对象存储服务,能将文件拆解成无数个对象(碎片)存放在硬盘中,大大提高了数据的稳定性。它主要由OSD和Monitor两个组件组成,OSD和Monitor都可以部署在多台服务器中,这就是ceph分布式的由来,高扩展性的由来。
     
  • LIBRADOS 基础库
    Librados提供了与RADOS进行交互的方式,并向上层应用提供Ceph服务的API接口,因此上层的RBD、RGW和CephFS都是通过Librados访问的,目前提供PHP、Ruby、Java、Python、Go、C和C++支持,以便直接基于RADOS(而不是整个Ceph)进行客户端应用开发。
     
  • 高层应用接口:包括了三个部分
    1)对象存储接口 RGW(RADOS Gateway)
    网关接口,基于Librados开发的对象存储系统,提供S3和Swift兼容的RESTful API接口。

    2)块存储接口 RBD(Reliable Block Device)
    基于Librados提供块设备接口,主要用于Host/VM。

    3)文件存储接口 CephFS(Ceph File System)
    Ceph文件系统,提供了一个符合POSIX标准的文件系统,它使用Ceph存储集群在文件系统上存储用户数据。基于Librados提供的分布式文件系统接口。

  • 应用层:
    基于高层接口或者基础库Librados开发出来的各种APP,或者Host、VM等诸多客户端

四、Ceph 核心组件

Ceph是一个对象式存储系统,它把每一个待管理的数据流(如文件等数据)切分为一到多个固定大小(默认4兆)的对象数据(Object),并以其为原子单元(原子是构成元素的最小单元)完成数据的读写。

  • OSD(Object Storage Daemon,守护进程 ceph-osd)
    是负责物理存储的进程,一般配置成和磁盘一一对应,一块磁盘启动一个OSD进程。主要功能是存储数据、复制数据、平衡数据、恢复数据,以及与其它OSD间进行心跳检查,负责响应客户端请求返回具体数据的进程等。通常至少需要3个OSD来实现冗余和高可用性。
     
  • PG(Placement Group 归置组)
    PG 是一个虚拟的概念而已,物理上不真实存在。它在数据寻址时类似于数据库中的索引:Ceph 先将每个对象数据通过HASH算法固定映射到一个 PG 中,然后将 PG 通过 CRUSH 算法映射到 OSD。
     
  • Pool
    Pool 是存储对象的逻辑分区,它起到 namespace 的作用。每个 Pool 包含一定数量(可配置)的 PG。Pool 可以做故障隔离域,根据不同的用户场景统一进行隔离。

Pool中数据保存方式支持两种类型:

多副本(replicated):类似 raid1,一个对象数据默认保存 3 个副本,放在不同的 OSD。
纠删码(Erasure Code):类似 raid5,对 CPU 消耗稍大,但是节约磁盘空间,对象数据保存只有 1 个副本。由于Ceph部分功能不支持纠删码池,此类型存储池使用不多。

Pool、PG 和 OSD 的关系:

一个Pool里有很多个PG;一个PG里包含一堆对象,一个对象只能属于一个PG;PG有主从之分,一个PG分布在不同的OSD上(针对多副本类型)

  • Monitor(守护进程 ceph-mon)
    用来保存OSD的元数据。负责维护集群状态的映射视图(Cluster Map:OSD Map、Monitor Map、PG Map 和 CRUSH Map),维护展示集群状态的各种图表, 管理集群客户端认证与授权。一个Ceph集群通常至少需要 3 或 5 个(奇数个)Monitor 节点才能实现冗余和高可用性,它们通过 Paxos 协议实现节点间的同步数据。
     
  • Manager(守护进程 ceph-mgr)
    负责跟踪运行时指标和 Ceph 集群的当前状态,包括存储利用率、当前性能指标和系统负载。为外部监视和管理系统提供额外的监视和接口,例如 zabbix、prometheus、 cephmetrics 等。一个 Ceph 集群通常至少需要 2 个 mgr 节点实现高可用性,基于 raft 协议实现节点间的信息同步。
     
  • MDS(Metadata Server,守护进程 ceph-mds)
    是 CephFS 服务依赖的元数据服务。负责保存文件系统的元数据,管理目录结构。对象存储和块设备存储不需要元数据服务;如果不使用 CephFS 可以不安装。

五、OSD 存储引擎

OSD 有两种方式管理它们存储的数据。在 Luminous 12.2.z 及以后的发行版中,默认(也是推荐的)后端是 BlueStore。在 Luminous 发布之前, 默认是 FileStore, 也是唯一的选项。

  • Filestore

FileStore是在Ceph中存储对象的一个遗留方法。它依赖于一个标准文件系统(只能是XFS),并结合一个键/值数据库(传统上是LevelDB,现在BlueStore是RocksDB),用于保存和管理元数据。

FileStore经过了良好的测试,在生产中得到了广泛的应用。然而,由于它的总体设计和对传统文件系统的依赖,使得它在性能上存在许多不足。

  • Bluestore

从 Ceph 12.2.0(Luminous) 版本开始的。在 Luminous 版本中,BlueStore 被引入作为一种新的、高性能的 OSD 存储引擎,以替代旧的 FileStore 引擎。

在 Ceph 中,BlueStore 可以提供更快的响应时间和更高的数据吞吐量,同时也具有更好的可靠性和稳定性。相比之下,旧的 FileStore 存储引擎通常需要更多的 CPU 和

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值