1.1分布式集群介绍

最新推荐文章于 2024-09-13 12:31:52 发布

奋斗的松鼠

最新推荐文章于 2024-09-13 12:31:52 发布

阅读量151

点赞数

分类专栏： ceph实战之路文章标签：分布式 ceph

本文链接：https://blog.csdn.net/strugglesquirrel/article/details/141963073

版权

ceph实战之路专栏收录该内容

5 篇文章 0 订阅

订阅专栏

ceph是分布式存储系统

分布式是相对集中式而言。

集中式存储在计算机发展史上持续了很长时间，在数据急剧膨胀的时代背景下，集中式存储显然已经无法满足日益增长的存储需求

分布式存储的最大优点是规模，通过节点之间的分布式协议和算法，大量的节点组成集群，共同协作完成一项存储任务，同时利用特定的策略保证数据的可靠性和完整性，这种集群模式可以针对需求进行规模的增加和缩减，在实际生产应用中具有重要意义。

存储方式	优点	缺点
集中式存储	久经考验，成熟稳定，运维难度较低，管理方便	单点故障，扩展性差，性能瓶颈明显
	与现有业务匹配度高
	低延迟，低成本
分布式存储	高可用，高可靠，易于跨地域灾备设计	系统复杂，学习成本高，有木桶效应
	规模大，扩展性强，调度灵活
	应用类型丰富，可支持云原生

分布式存储的出现使得传统的计算机体系结构发生了变化，传统意义上存储通常指的是一系列的存储介质，比如磁盘、磁盘阵列、网络磁盘等，其担任的角色往往只是系统的附属组成部份，分布式存储除了提供存储功能，还将存储本身抽象为服务，提供如对象存储、文件存储、块存储的访问接口，使得存储服务真正成为一个重要的基础设施。

Ceph的主要组件及总体架构

ceph作为分布式存储系统，由以下几个重要的组件组成：
在这里插入图片描述

Monitors: 
monitor是集群部署的时候，所部署的第一个服务，我们初始化集群，实际上就是初始化monitor，以及集群的其他key，作为集群的管理者，负责维护集群的所有运行图map，包括monitor map，osd map，crush map，mds map，pg map，mgr map，这些map对集群的正常运行起着至关重要的作用。

法定人数：多个monitor之间将通过选举的方式产生一个主monitor，通常是ip地址最小的那个monitor会成为主，其余的monitor作为备，当主monitor失效后，剩余的备重新选举产生新主，继续维持集群工作。monitor之间的选举通过特定算法进行，为了保证选举能够确实地产生一个主，集群monitor的数量一般是奇数，在生产实践中，OSD规模在3000个OSD以内的集群，monitor的数量一般是3个或者5个。

Managers: 
即Ceph Manager daemon (ceph-mgr)，负责跟踪运行时指标和Ceph集群的当前状态，包括存储利用率、当前性能指标和系统负载。Ceph mgr服务还托管基于Python的模块，用于管理和导出Ceph集群信息，提供基于Web的Ceph仪表板和REST API。通常每一个monitor服务，我们都会对象的去部署一个MGR服务，从图中我们也可以看到，monitor跟MGR非常的类似。
mgr最早设计出来是为了分担monitor的部份任务，随着集群复杂度的增加，mgr独立承担的事情越来越多，mgr服务最常用的就是数据导出和pg管理，数据导出是指mgr负责将集群的相关指标以特定形式提供给外部的监控系统采集数据，以达到监控集群的目的；pg管理指的是集群pg状态、存储池状态、pg分布调整等内容。

Ceph OSDs: 
即Object Storage Daemon (Ceph OSD, ceph-osd)，是集群实际存储数据的组件
集群的存储能力通常指OSD的总容量，一个OSD服务对应的往往是一个物理硬盘，可以是一块大容量(如16TiB)的机械磁盘，也可以是一块高速的SSD硬盘，若干OSD会被编成组，并基于组创建存储池进行管理。

Ceph MDSs: 
即Ceph Metadata Server (MDS, ceph-mds)，当集群使用分布式文件存储系统cephfs时，需要创建mds，它负责文件系统的元数据管理，cephfs提供了类似NFS的POSIX文件系统接口。

在一个ceph集群中，至少需要部署一个monitor，一个mgr，3个以上的osd

在这里插入图片描述

ceph的架构图上图所示

不管数据是通过哪个协议进入集群，最终都会落到rados中，而rados层操作的就是存储池pool，在该形式上，看到的实际上就是对象存在于pool中，而pool借助PG这个逻辑结构对数据和磁盘进行映射，产生确定的映射规则，实现数据的落盘
在这里插入图片描述

ceph实际存放数据，使用的方式是元数据与数据的分离，这样做的好处是可以针对不同的需求进行硬件层面的定制，比方说，针对数据部分，通常使用hdd磁盘来存放，因为hdd磁盘虽然性能差一些，但是单位容量成本比ssd低很多，而元数据部分因为其数量大，单个元数据体积小，对存储介质的IOPS有很高的要求，因此更适合存放在高速的ssd磁盘中

在这里插入图片描述

Ceph集群的map

ceph对集群的状态感知和管理，很大程度是使用多种集群map来实现的，具体来说

1.The Monitor Map: 
monitor之间使用monitor map来保存各个实例的关键数据，通常情况下我们不需要改动它
当我们给集群增加、删除monitor时，集群会自动修改monitor map，使得新加入或者删除的monitor可以继续正常工作
另外，当我们修改集群ip的时候，需要手工修改monitor map的相关内容，使得monitor之间可以使用新的ip地址
ceph mon dump可以查看当前集群的monitor map

2.The OSD Map: 
osd map包含的信息非常丰富，它是集群很多重要功能的载体，monitor感知到集群发生变化后，如某个osd服务down了，则会修改osdmap并分发给集群的其他组件，从而使集群其他成员感知到集群的变化。
有一点值得注意，只有monitor能够修改osdmap，其他组件无条件信任osdmap的内容，组件的很多行为都依赖osdmap进行，这也就意味着，当osdmap异常时（如其内容出错），集群会受到影响，尽管概率很低，但生产实践上确实有可能遇到。
ceph osd dump可以查看当前集群的osd map

3.The PG Map: 
PGmap详细记录了集群所有pg的信息，包括pg的状态、映射规则，时间戳等等。
pgmap对pg状态机的转变影响很大，通常情况下我们使用pgmap来查询pg的相关信息，无法也务必要对其进行修改
ceph pg dump可以查看当前集群的pg map

4.The CRUSH Map: 
crushmap详细定义了存储设备列表、故障域层级（例如设备、主机、机架、行、机房）以及存储数据时遍历层级的规则，这些规则对集群的资源架构和存储池的分布、运行有非常关键的作用。
ceph osd getcrushmap -o crushmap
crushtool -d crushmap -o txtcrushmap
可以查看当前集群的crushmap

5.The MDS Map: 
mds map记录了文件存储系统的详细信息以及mds的ip/port相关信息
ceph fs dump可以查看当前集群的mds map

集群map在实际写入流程中的作用例子：

在这里插入图片描述

ceph版本

ceph开源后，从A版本0.48开始，经过十几年的发展，目前最新的版本已经迭代到了R版本的18.2.0，发展非常迅猛，其中12.2 Luminous开始，整个ceph的改变非常大，最重要的是默认引擎从原来的filestore改为了bluestore，全新架构，性能大幅提高，而且EC也开始推荐应用，可以说焕然一新

版本号	代号	类别
0.48	Argonaut	LTS
0.56	Bobtail	LTS
0.61	Cuttlefish	Stable
0.67	Dumpling	LTS
0.72	Emperor	Stable
0.80	Firefly	LTS
0.87	Giant	Stable
0.94	Hammer	LTS
9.2	Infernalis	Stable
10.2	Jewel	LTS
11.2	Kraken	Stable
12.2	Luminous	LTS
13.2	Mimic	Stable
14.2	Nautilus	LTS
15.2	Octopus	Stable
16.2	Pacific	LTS
17.2	Quincy	Stable
18.2	Reef	LTS

松鼠哥建议，应谨慎使用高版本及容器化部署

1.组件耦合导致的排查链过长

容器引入的组件使得集群复杂度有所增加，在规模化管理的集群中，我们建议尽可能地对组件解耦，然而将ceph的组件放入容器中运行，必然会加大集群的运维难度，设想一个场景，当某个osd进入down状态时，我们首先要排查一遍容器的网络问题、防火墙问题、其他硬件问题等，确保不是osd自身问题，才开始对该osd进一步排查，这显著上延长了排查链，对运维人员的经验和技术栈要求更高，因而，容器化部署虽然方便(实际上也未必方便)，但并不是当前生产环境的推荐方案，尤其是数百个节点成千上万个磁盘组成的大规模集群，使用容器化的运维管理难度可想而知。