Storage

什么是对象存储 对象存储是一种以非结构化格式（称为对象），简单来说，对象存储是一种将文件存储为对象而不是数据块的存储架构。它是一种将非结构化数据存储在跨位置分布的结构化平面文件系统中的方法。在这种格式中，文件空间由元数据标签组成，支持简单的 API 来描述、读取、删除和定位对象。因此，您可以通过 API 协议直接访问任何设备上保存的数据。此类元数据标签包括有助于更好地识别和分类数据的唯一标识符。 这些元数据标签是高度可定制的，让您可以在需要时通过跟踪和索引文件来轻松组织、访问和检索所有数据。对象存储服务可以在设备级、系统级甚至接口级实现。作为对象存储的数据可确保数据可用性、可搜索性并增强数据安全性，因为它可以保护数据免遭意外删除或损坏。 什么是 CEPH 中的对象存储 在知道了对象存储不能作为文件系统磁盘由操作系统直接访问，只可以通过应用程序级别的 API 进行访问。Ceph是一个分布式对象存储系统，通过一个 “网关服务” 来提供对象存储接口，这个服务被称为 RADOS Gateway ( RGW )，RGW是构建在 Ceph RADOS 之上，通过在 librados 之构建出的一个库 librgw，实际上是一个 Civetweb 的服务，rados gateway 内嵌在里面，RGW 为应用程序提供兼容 RESTful 的 S3/Swift 的 API 接口，以在 Ceph 集群中以对象的形式存储数据。Ceph 还支持多租户对象存储，可通过 RESTful API 访问。除此之外，RGW 还支持 Ceph 管理 API，可用于使用本机 API 调用来管理 Ceph 存储集群。 librados 是一个构建在 RADOS 集群和 Ceph 集群的中间层，通过这个库，提供了允许用户应用程序通过C、C++、Java、Python 和 PHP绑定直接访问 Ceph 存储集群。Ceph 对象存储还具有多站点 (MultiSite) 能力，即提供灾难恢复的解决方案。 图：Ceph RGW Structure Source：https://docs.ceph.com/en/octopus/radosgw/ 安装rgw rgw 包 ceph-radosgw...

Ceph专门提供了文件系统接口CephFS。CephFS是略微不同于RBD的架构形式，在基础的RADOS Cluster存储集群的基础之上，需要额外运行一个守护进程MDS MetaDataServer 元数据服务器。 RADOS Cluster自己是一个对象存储服务，他无法管理传统文件系统上分离去管理元数据和数据的功能。（而且元数据还拥有权限、用户属组、时间戳等。）RADOS Cluster自身是无法实现这个功能的。MDS专用于模拟传统文件系统所应该具有的将数据和元数据分离存储的方式而专门提供的一个服务。MDS只用来管理元数据。 MDS需要工作一个守护进程，客户端必须通过套接字的方式，每一次访问文件时，先去联系到MDS，来获取文件的元数据信息，再到RADOS Cluster以对象方式，将对象模拟成传统文件系统的块，来加载文件数据。 如是挂在CephFS系统的客户端，需先联系到MDS，识别文件系统的各种信息。客户端向挂载目录路径下的任何一个读写操作就相当于由挂载时的内核驱动模块联系到对应的MDS，而后再由客户端之上的模块来联系到RADOS Cluster。为了能够支持CephFS文件系统，也需要内核级模块Ceph.ko模块。挂载过程机制为将内核模块作为文件系统内核的客户端，与文件系统的守护进程进行通讯，必要时将用户数据存取转为对应集群的存储操作。 对于Rados存储集群来讲，存储集群所有数据都会被放在存储池当中，而CephFS管理其数据和元数据分别放置在不同的存储池中。所有元数据都是由MDS管理的。MDS也是客户端，连入CephFS的的metadata，专门用于存储元数据的存储池。 cephfs逻辑 元数据是一类很密集的IO访问。对原数据存储池的操作是放置在存储池当中的，但在本地会使用内存（高速缓存）中完成，过断时间同步到metadata pool中。而数据直接写入data存储池中 meatdata pool只能对mds访问，其他任何客户端时不能被访问的。客户端对元数据的访问必须经由MDS来实现。 当客户端打开一个文本时，首先请求客户端的inode（传统文件系统采用inode来保存文件的元数据）。获得相应授权以后从mds中接收到inode，inode中标示文件的数据究竟放置在data pool的那些对象中。返回对象编号给客户端，客户端基于对象编号访问所有的对象，将数据加载到。 ceph mds stat mds: 2 up:standby 当没有文件系统时，无法进行选举，故所有的都为standby CephFS Client访问CephFS集群的方式 客户端挂载CephFS， 基于内核文件系统完成挂载ceph、libcephfs 用户空间文件系统（FUSE Filesystem in USErspace）：libcephfs与ceph集群进行交互。 ==激活CephFS步骤== 激活CephFS MDS，至少有一个节点运行ceph-mds守护进程 ceph-deploy命令完成的 创建存储池：metadata-pool、data-pool bash 1 2 ceph osd pool create cephfs_metadata 8 8 ceph osd pool create cephfs_data 8 8 激活文件系统： ceph fs new <name> {metadata-pool-name} {pool-name} ceph fs status {filesystem-name} ceph fs stat 获得必要授权，才能使用服务...

如果需要与osd打交道，需要通过mon检索集群运行图才能够访问的客户端，通常经由mon认证后才能访问ceph存储。Ceph本身实现了数据服务的认证访问和授权控制机制，CephX协议来实现 CephX Protocol CephX本身只负责认证和授权检测，不处理通讯过程是否加密。一般来讲需要与moniotr交互的客户端组件（OSD、RBD、RGW等）一般而言都经由CephX认证 CephX认证机制 Ceph使用cephx协议对客户端进行身份认证 每个MON都可以对客户端进行身份验正并分发密钥，不存在单点故障和性能瓶颈。（在集群模式下，任何一个monitor在实现认证时是无状态的，每个monitor都能完成身份检验的任务） MON会返回用于身份验正的数据结构，其包含获取Ceph服务时用到的session key session key通过客户端密钥进行加密，需事先有一个预共享秘钥存在 客户端使用session key向MON请求所需的服务。session key只是拿来做中间通讯使用。 MON向客户端提供一个ticket，用于向实际处理数据的OSD等验正客户端身份。 MON和OSD共享同一个secret，因此OSD会信任由MON发放的ticket ticket存在有效期限 注意： CephX身份验正功能仅限制Ceph的各组件之间，它不能扩展到其它非Ceph组件。 它并不解决数据传输加密的问题。 为了实现Cephx认证，Ceph服务器端一定会为每一个客户端事先生成一个密码 认证与授权 无论Ceph客户端时何类型，Ceph都会在存储池中将所有的数据存储为对象 Ceph用户需要拥有存储池访问权限才能读取和写入数据 Ceph用户必须拥有执行全年才能使用Ceph管理命令 相关概念 用户 用户是指个人或系统参与者（例如应用） 通过创建用户，可以控制谁（或哪个参与者）能够访问Ceph存储集群、以及可访问的存储池及存储池中的数据。 Ceph支持多种类型的用户，单可管理的用户都属于Client类型 区分用户种类的原因在于，mon、osd、mds等系统组件也使用cephx协议，但它们非为客户端 通过点号来分隔用户类型和用户名，格式为TYPE.ID，例如：client.admin等 授权 使能（Capabilities） Ceph基于"使能(caps)“来描述用户可针对MON、OSD或MDS使用的权限范围或级别。 通用语法格式：daemon-type'allow caps[...] MON使能 包括r、w、x和allow profile cap 例如：mon allow rwx，以及mon allow profile osd’等。 OSD使能 包括r、w、x、class-read、class-write和profile osd 此外，OSD使能还允许进行存储池和名称空间设置。如为指定表示对所有OSD所有存储池都获得相关授权 MDS使能 只需要allow，或留空 各使能的意义 allow 需先于守护进程的访问设置指定 仅对MDS表示rw之意，其它的表示字面意义 r：读取权限，访问MON以检索CRUSH时依赖此使能 w：对象写入权限 x：调用类方法（读取和写入）的能力，以及在MON上执行auth操作的能力。 class-read：x能力的子集，授予用户调用类读取方法的能力 class-write：x的子集，授予用户调用类写入方法的能力 ·*：授予用户对特定守护进程/存储池的读取、写入和执行权限，以及执行管理命令的能力。 profile osd 授予用户以某个OSD身份连接到其他OSD或监视器的权限 授予OSD权限，使OSD能够处理复制检测信号流量和状态报告 profile mds 授予用户以某个MDS身份连接到其他MDS或监视器的权限 profile bootstrap-osd...

初识Ceph Ceph 是一个开源分布式存储系统系统，它不是一种单一的存储，而是面向云提供一种统一存储平台，包含块存储 RBD, 文件存储 CephFS, 以及对象存储 RGW，这种存储的出现允许用户拜托供应商的绑定，它可以提供块存储到 “云平台”，也可以提供对象存储到 “应用”，并支持理论上的无限扩展性，数千客户端访问 PB 甚至 EB 级别的数据 SAN VS Ceph 与传统 SAN 存储相比，Ceph 客户端会计算他们所需的数据所在的位置，这消除了存储系统中需要在“中心化查找”的瓶颈。 这使得 Ceph 集群可以在不损失性能的情况下进行扩展。 Ceph 集群架构组成 Ceph 集群核心是 RADOS，而基于 RADOS，构建出多种类型存储，块存储, 文件系统, 对象存储，而一个基础的 Ceph 集群的组件由 “Ceph monitor” 与 “Ceph OSD Daemon” 组成 Ceph Monitor（进程名称为 ceph-mon，下文中以 ceph-mon 代表 Ceph Monitor） 维护集群映射的主副本。 ceph集群中的monitor，可确保 ceph-mon 守护进程在失败时的高可用性。客户端从 ceph-mon 检索集群映射的副本。 Ceph OSD Daemon 检查”自身“及”其他“ OSD 的状态并报告给 Monitor。 Ceph 中的常见术语 Application 用于使用 Ceph 集群的任何 Ceph 外部的应用程序 Block Device 也称为 “RADOS 块设备” 或 ”RBD“ ，协调基于块的数据存储的工具，Ceph块设备拆分基于块的应用程序数据 成“块”。 RADOS 将这些块存储为对象。 Ceph 块 设备协调这些对象的存储 存储集群。...

关于存储池 从某种意义上来讲，RADOS所提供的存储空间的管理接口，不应该将其放置在同一个平面当中，因此将其切割成多个不同的"逻辑存储空间"，称之为存储池。 RADOS存储集群提供的基础存储服务需要由"存储池（pool）“分割为逻辑存储区域，此类的逻辑区域亦是对象数据的名称空间。 实践中，管理员可以为特定的应用程序存储不同类型数据的需求分别创建专用的存储池，例如rbd存储池，rgw存储池等，也可以为某个项目或某个用户创建专有的存储池。 存储池还可以再进一步细分为一至多个名称空间（namespace）。同一个存储池内，无论属于哪个、哪些名称空间，数据都是被存储池中的PG进行存放，虽然处于不同名称空间，但可能处于同一个PG之上。 客户端(包括rbd和rgw等）存取数据时，需要事先指定存储池名称、用户名和密钥等信息完成认证，而后将一直维持与其指定的存储池的连接，于是也可以吧存储池看做是客户端的IO接口。 存储池类型 副本池（replicated）：任何一个数据对象存储在此类存储池中其冗余机制是通过创建多个数据对象副本来实现的，而副本数量是用户在创建存储池时指定。如，创建存储池时没指定类型，就是副本池，默认副本数量为3个（1主两从），统称副本数量。把每个对象在集群中存储为多个副本，其中存储于主OSD的为主副本，副本数量在创建存储池时由管理员指定；副本池类型为Ceph为默认的存储池类型。但是此存储池是非常浪费存储空间的。副本池对读IO有很好的附带表现 纠删码池（erasure code）：使用校验码可计算回数据。把各对象存储为N=K+M个块，其中，K为数据块数量，M为编码块数量，因此存储池的尺寸为K+M；纠删码块的数据就 是允许冗余的级别。如4+2，即允许最多两个数据块丢失。不是所有的应有都能支持纠删码池，如rbd必须使用副本池。radosGW可以使用纠删码池。 副本池IO 将一个数据对象存储为多副本 写入操作时，Ceph客户端使用CRUSH算法来计算对象的PG ID和Primary OSD 主OSD根据设定的副本教、对象的名称、存储池名称和集群运行图（Cluster Map）计算出PG的各铺助OSD，而后由主OSD将数据同步给这些辅助OSD。 对于有着三个副本的存储池来讲，任何一个PG都会选择三个OSD，因此，副本池所关联的OSD数量通常与冗余量相同。OSD，成为一个活动集。如图所示，其中一个OSD为主OSD负责读写操作，另外两个OSD负责从主OSD同步数据。当三个副本都存完，才能的到存储完成的消息的。客户的只需与主OSD通信，同步过程是OSD内部自行实现的。 纠删码池IO 纠删码是一种前向纠错码（FEC）代码 通过将K块的数据转换为N块，假设N=K+M，则其中的M代表纠删码算法添加的额外活冗余的块数量以提供冗余机制（即编码块），而N则表示在纠删码编码之后要创建的块的总数，其可以故障的块数为M（即N-K）个。 类似于RAID5 纠删码池减少了确保数据持久性所需的磁盘空间量，但计算量上却比副本存储池要更贵一些 RGW可以使用纠删码池，但RDB不支持。 例如，把包含数据ABCDEFGHI的对象NYAN保存到存储池中，假设纠删码算法会将内容分割为三个数据块：第一个包含ABC，第二个为DEF，最后一个为GHI，并为这三个数据块额外创建两个编码块：第四个YXY和第五个GQC，此时纠删码算法会通过计算哪家出GHI、和YXY 副本池所有从OSD没有次序之分，只有主和从两类角色之分，各个从没有次序。纠删码池是有次序的，这个顺序代表数据拼凑起来的数据。因此，每个分片应指定其在整个数据文件的偏移量是多少。 归置组 归置组（PlacementGroup）是用于跨OSD将数据存储在某个存储池中的内部数据结构。 相对于存储池来说，PG是一个虚拟组件，它是对象映射到存储池时使用的虚拟的层 出于规模伸缩及性能方面的考虑，Ceph将存储池细分为归置组，吧每个单独的对象映射到归置组，并将归置组分配给一个主OSD 存储池由一系列的归置组组成，而CRUSH算法则根据集群运行图和集群状态，将各PG均匀、伪随机地分布到急群众的OSD之上。 若某OSD失败或需要对集群进行重新平衡，Ceph则移动或复制整个归置组而无需单独寻址每个对象。 归置组在OSD守护进程和Ceph客户端之间生成了一个中间层，CRUSH算法负责将每个对象动态映射到一个归置组，然后再将每个归置组动态映射到一个或多个OSD守护进程，从而能够支持在新的OSD设备上线时动态进行数据重新平衡。 归置组作用 在存储池中存放100w数据对象，而使用100个归置组，一组内存放1w对象。归置组是从新平衡和恢复时的基本单元。使得数据单元不至于以文件或对象为单位。 归置组计数 归置组的数量有管理员在创建存储池是指定，而后由crush负责创建和使用 通常，PG的数量应该是数据的合理粒度的子集 例如，一个包含256个PG的存储池意味着每个PG包含大约1/256的存储池数据 当需要将PG从一个OSD移动到另一个OSD时，PG的数量会对性能产生影响 PG数量过少，Ceph将不得不同时移动相当数量的数据，其产生的网络负载将对集群的正常性能输出产生负面影响。 而在过多的PG数量场景中在移动极少量的数据时，Ceph将会占用过多的CPU和RAM，从而对集群的计算资源产生负面影响。 PG数量在集群分发数据和重新平衡时扮演着重要作用 在所有OSD之间进行数据持久存储及完成数据分布会需要较多的归置组，但是它们的数量应该减少到最大性能所需的最小数量值，以节省CPU和内存资源 一般说来，对于有着超过50个OSD的RADOS集群，建议每个OSD大约有50-100个PG以平衡资源使用，取的更好的数据持久性和数据分布，更大规模的集群中，每个OSD大约可持有100-200个PG 至少应该使用多少个PG，可通过下面的公式计算后，将其值以类似于四舍五入到最近的2的N次幂 (Total OSDs * PGPerOSD/Replication factor => Total PGs ) 可以使用的PG数量 = 总OSD数量* 每个OSD可以有多少个PG/复制因子（副本数量） 一个RADOS集群上可能会存在多个存储池，因此管理员还需要考虑所有存储池上的PG分布后每个OSD需要映射的PG数量 PG数量一定是2的N次方倍，这样进行hash计算时，速度才会更快。Ceph要求每一个OSD上最多不能超过256个PG 归置组状态 依据PG当前的工作特性活工作进程所阶段，它总是处于某个活某些个“状态中”，最常见的状态应该为active+clean PG的常见状态 Active 主OSD和各辅助OSD均处于就绪状态，可正常服务于客户端IO请求 一般Peering操作过程完成后即会转入Active状态 Clean 主OSD和各辅助OSD均处于就绪状态，所有对象的副本数量均符合期望，并且PG的活动集和上行集为同一组OSD。 活动集(Acting Set)：由PG当前的主OSD和所有的处于活动状态的辅助OSD组成，这组OSD负责执行此PG上数据对象的存取操作I/O 上行集(Up Set)，根据CRUSH的工作方式，集群拓扑架构的变动将可能导致PG相应的OSD变动活扩展至其他的OSD之上，这个新的OSD集也成为PG的“（Up Set）”，其映射到的新OSD集可能不分地与原有OSD集重合，也可能会完全不相干；上行集OSD需要从当前的活动集OSD上复制数据对象，在所有对象同步完成后，上行集便成为新的活动集，而PG也将转为“活动（active）”状态。 Peering 如数据不一致，需将数据复制过去，这个复制数据过程就称之为对等过程。 一个PG中的所有OSD必须就它们持有的数据对象状态达成一致，而“对等（Peering）”即为其OSD从不一致转为一致的过程。 Degraded 在某OSD标记为“down”时，所有映射到此OSD的PG即转入“降级（degraded）”状态 此OSD重新启动并完成Perring操作后，PG将重新转回clean 一旦OSD标记为down的时间超过5分钟，它将被标记出集群，而后Ceph将对降级状态的PG启动回复操作，直到所有因此而降级的PG重回clean状态 在其内部OSD上某对象不可用活悄然崩溃时，PG也会被标记为降级状态，知道对象从某个权威副本上正确恢复。 Stale 过期 每个OSD都要周期性的向RADOS集群中的监视器报告其作为主OSD所持有的所有PG的最新统计数据，因任何原因导致某个主OSD无法正常向监视器发送此类报告，或者由其他OSD报告某个OSD已经down掉，则所有以此OSD的PG将立刻被标记为stale状态。 Undersized PG中的副本数少于其存储池定义的个数时即转入undersized状态，回复和回填操作在随后会启动已修复其副本为期望值 Scrubbing 一致性保障的非常重要机制，文件完整性检查 各OSD还需要周期性的检查其所持有的数据对象的完整性，以确保所有对等OSD上的数据一致；处于此类检查过程中的PG便会被标记为scrubbing状态，这也通常被称作light scrubs、shallow scrubs或者simply scrubs。 另外，PG还需偶尔需要进行deep scrubs检查以确保同一对象在相关的各OSD上能按位匹配，此时PG将处于scrubbing+deep状态。 Recovering 恢复 添加一个新的OSD至存储集群中或某OSD宕掉时，PG则由可能会被CRUSH重新映射进而将持有与此不同的OSD集，而这些处于内部数据同步过程中的PG则被标记为recovering状态； Backfilling 回填 新OSD加入存储集群后，Ceph则会进入数据重新均衡的状态，即一些数据对象会在进程后台从现有OSD移到新的OSD之上，此操作过程为backfill。 CRUSH 把对象直接映射到OSD之上会导致二者之间的紧密耦合关系，变动底层OSD就会牵一发而动全身，因此在OSD设备变动时不可避免地对整个集群产生扰动...