Ceph基础知识简单介绍-2

Posted 2022-12-11 涛子GE哥

Ceph对象存储 Ceph是一个分布式对象存储系统，通过它的对象网关（object gateway），也就是RADOS网关（radosgw）提供对象存储接口。RADOS网关利用librgw（RADOS网关库）和librgw这些库，允许应用程序根ceph对象建立连接。Ceph通过RESTful API提供可访问且最稳定的多租户对象存储解决方案之一。 对象存储不能像文件系统的磁盘那样被操作系统直接访问，相反，它只能通过API在应用层面被访问。Ceph是一个分布式对象存储系统，该系统通过建立在Ceph RADOS层之上的Ceph对象网关（也被称为RADOS网关RGW接口）提供对象存储接口，RGW使用librgw（RADOS网关库）和librados，允许应用程序与Ceph对象存储建立连接。该RGW为应用提供了RESTful S3/Swift兼容的API接口，以在Ceph集群中存储对象格式的数据。Ceph还支持多租户对象存储，通过RESTful API存取。除此之外，RGW还支持Ceph Admin API，他们用于通过原生API调用来管理Ceph存储集群。 librados软件库非常灵活，允许用户应用程序通过C、C++、Java、Python和php绑定（bindings）直接访问Ceph存储集群。Ceph对象存储还具有多站点功能，也就是说，提供了灾难恢复解决方案。
要访问Ceph的对象存储系统，也可以绕开RADOS网关层，这样更灵活并且速度更快。librados软件库允许用户的应用程序通过C、C++、java、python、php直接访问ceph对象存储。如下图：

Ceph对象网关 Ceph对象网关，也称作RADOS网关，它是一个代理，可以将HTTP请求转换为RADOS，同时也可以把RADOS请求转换为HTTP请求，从而提供RESTful对象存储，兼容S3和Swift。Ceph对象存储使用Ceph对象网关守护进程（radosgw）和librgw、librados（即Ceph集群）交互。
RADOS特点 1、将文件映射到Object后，利用Cluster Map通过CRUSH计算而不是查找表方式定位文件数据到存储设备中的位置。优化了传统的文件到块和映射和BlockMap管理 2、RADOS充分利用了OSD的只能特点，将部分任务授权给OSD，最大程度地实现可扩展。
RADOS由两部分组成：OSD、Monitor OSD：由数目可变的大规模OSD组成的集群，负责存储所有地Objects数据。 Monitor：由少量Monitor组成的强耦合、小规模集群，负责管理Cluster Map。Cluster Map是整个RADOS系统的关键数据结构，管理集群中的所有成员、关系和属性等信息以及数据的分发。 Ceph Monitor负责监视整个集群的运行状况，这些信息都是由维护集群成员的守护程序来提供的，如各个节点之间的状态、集群配置信息。Mmonitor Map、OSD Map、PG Map、MDS Map、CURSH Map统称为集群Map。
RADOS与LIBRADOS LIBRADOS模块是客户端用来访问RADOS对象存储设备的。Ceph存储集群提供了消息传递层协议，用于客户端与Ceph Monitor与OSD交互，LIBRADOS以库形式为Ceph Client提供了这个功能，LIBRADOS就是操作RADOS对象存储接口。所以Ceph客户端可以用LIBRADOS或者LIBRADOS里封装的相同功能和对象存储交互。LIBRBD和LIBCEPHFS就利用了此功能。你可以利用LIBRADOS直接和Ceph交互（如Ceph兼容的应用程序、Ceph接口等）。
librados librados是一个本地C语言库，通过它允许应用程序直接与RADOS通讯，这样就可以绕过其他接口层与Ceph集群进行交互。librados是RADOS的一个库，他提供了丰富的API支持，这样就允许应用程序直接、并行地访问集群，而没有HTTP开销。应用程序可以扩展他们的本地协议以便通过直接连接librados来访问RADOS。
Ceph OSD Ceph的OSD由一个已经存在linux文件系统的物理磁盘驱动器和OSD服务组成。 Ceph 的OSD是Ceph存储集群中最重要的一个基础组件，它负责将实际的数据以对象的形式存储在每一个集群节点的物理磁盘驱动器中。Ceph集群中的大部分工作是由OSD守护进程完成的。 Ceph的核心特性（比如可靠性、自平衡、自恢复和一致性）都始于OSD。在磁盘发生故障的时候，Ceph的OSD守护进程会自动与其他的OSD通信，从而开始执行恢复操作。在这期间，存放故障磁盘对象的辅OSD就会被提升为主OSD，同时，在恢复期间会为对象生成新的辅副本，整个过程对于用户是透明的，这保证了Ceph集群的可靠性和一致性。 linux文件系统对于OSD守护进程而言是相当重要的，因为他决定了支持那些扩展属性（XATTR）。这些文件系统扩展属性能够为OSD守护进程提供内部对象的状态、快照、元数据和ACL等信息，这有助于管理数据。OSD在拥有有效Linux分区的物理磁盘驱动器上进行操作。 Linux分区可以是Btrfs（B树文件系统）、XFS或ext4。 Btrfs ：与使用XFS和ext4文件系统的OSD相比较，使用Btrfs文件系统额OSD能够提供更加的性能。最主要的一个优点是支持写时复制和可写的快照，这对于虚拟机的部署和克隆非常有用。在文件系统中它还支持透明的压缩、普遍的校验和和多设备的统一管理。Btrfs还支持高效的XATTR、对于小文件的合并，还有SSD上所熟知的集成卷管理，并支持在线fsck特性。尽管有如此多特性，Btrfs目前还不具备应用于生产系统条件。 XFS ：这是一个可靠、成熟、且非常稳定的文件系统，因此我们推荐在Ceph生产环节用使用。XFS是最常用的文件系统，也是Ceph默认的文件系统。XFS在元数据的扩展性上存在性能问题。XFS也是一种日志文件系统，也就是说，每次客户端发送数据写入Ceph集群时，首先写入日志空间，然后再写入XFS文件系统。这样的两次写入操作增加了开销，从而使得XFS的性能不如Btrfs，Btrfs没有使用日志。 ext4 ：ext4文件系统也是一种日志文件系统，是一个适合生产环境下Ceph OSD使用的文件系统，它的受欢迎程度不如XFS，性能不如Btrfs。ext4文件系统因为限制了XATTR的存储容量使得其不具备提供足够的XATTR信息的能力，这也是它并不流行的一个选择。
Ceph集群的一次读写操作 两层映射：Object--->PG--->OSD set #每一次映射都是与其他对象无关的，充分体现了CRUSH的独立性（充分分散）和确定性（可确定的存储位置） 客户端首先联系Ceph monitor并获取一个集群map 副本（包含mon map 、osd map、pg map、mds map），集群map 帮助客户获取集群的状态和配置信息。client端从Ceph Monitor获取Cluster Map之后，client将直接与OSD进行I/O操作交互，不在需要Ceph monitor干预（这使得数据读写过程更为迅速）。 使用对象和池名/ID将数据转换为对象，然后将对象和PG（placement groups 归置组）数一起经过散列来生成其在Ceph池中最后存放在哪一个PG，然后计算好的PG经过CRUSH查找来确定存储和获取数据所需的主OSD位置。计算完准确主OSD ID之后，客户端直接联系OSD来存取数据。所有的这些操作都由客户端执行，不会影响集群性能。主OSD所在节点将执行CRUSH查找操作并计算辅助归置组和OSD的位置来实现数据复制，进而实现高可用性。 Ceph任何写入首先是日志（journal），然后是后备存储 。journal持续到后备存储同步，每隔5s。默认情况下，10GB是该journal的常用大小，但journal越大越好。 Ceph使用journal综合考虑了存储速度和数据的一致性 。journal允许Ceph OSD功能很快做小的写操作；一个随机写入首先写入在上一个连续类型的journal，然后刷新到文件系统。这给了文件系统足够的时间来合并写入磁盘。 使用SSD盘作为journal盘能获得相对较好的性能（可以有效缓冲突发负载） 。 如果日志的速度低于备用存储的速度，这对你的集群性能而言将会是一个限制因素。按照建议，在使用额外的SSD来做日志的时候，每个SSD磁盘最多给4或者5个OSD做日志，一旦超过这个数目的OSD的日志盘子同一个SSD磁盘上，这将是几群的性能瓶颈。 同样，如果采用XFS或者ext4文件系统的多个OSD日志在同一个磁盘上，一旦这个盘出现错误，你将失去你的OSD及其数据，这就是Btrfs的优势：如果发生日志错误的OSD盘使用的Btrfs-based文件系统，他将能够回滚到过去，这样只会导致最小的数据丢失或者没有数据丢失。Btrfs是一个写时复制文件系统，也就是说，如果一个块的内容发生了变化，而针对这个块的写是独立进行的，因此能够保留旧的块。对于这样一个场景下的损坏，数据依然可用，因为旧的内容依然可用。

Ceph monitor Ceph monitor负责监控整个集群健康状态。他们以守护进程的形式存在，这些守护进程通过存储几群的关键信息来维护集群成员状态、对等节点状态，以及集群配置信息。Ceph monitor通过维护整个集群状态的主副本来完成它的任务。集群map包括monitor、OSD、PG、CRUSH、MDS map。所有这些map统称为集群map。 Ceph monitor不为客户端存储和提供数据，相反，它为客户端以及集群内其他节点提供更新集群map的服务。客户和其他集群节点定期与monitor确认自己持有的是否是集群最新map。 monitor map ：它维护monitor节点间端到端的信息，其中包括Ceph集群ID、monitor主机名、IP地址及端口号。它还存储着当前map的创建版本和最后一次修改的信息 #检查集群monitor map：ceph mon dump OSD map ：它存储着一些常见的信息，如集群ID、OSD map创建版本和最后一次修改信息，以及与池相关的信息（如池名字、池ID、类型、副本数和归置组）。它还存储着OSD的一些信息，如数目、状态、权重、最近处于clean状态的间隔以及OSD主机等信息。 #获取OSD map：ceph osd dump PG map ：它存储这归置组的版本、时间戳、最新的OSD map版本、容量充满的比例以及容量接近充满的比例等信息。它同时也跟踪每个归置组的ID、对象数、状态时间戳、OSD的up集合、OSD的acting集合，最后还有清洗等信息。 #检查集群PG map：ceph pg dump CRUSH map：它存储着集群的存储设备信息、故障域层次结构以及在故障域中定义如何存储数据的规则。 #查看CRUSH map：ceph osd crush dump MDS map：它存储着当前MDS map的版本，map的创建和修改时间，数据和元数据池ID，集群中MDS的数目以及MDS的状态 #查看MDS map：ceph mds dump 查看mon的状态以及mon的选举状态 ceph daemon mon.bj-ceph37 mon_status ceph quorum_status