【ceph】对象存储的目录文件夹概念

        春节假期ceph大佬发布了Nautilus版新功能的介绍，也想来尝尝鲜。于是编译了ceph-1401-3799-g4de85a5版本测试一番。这两天ceph1410正式发布了，又重新安装了写篇测试心得。

          在ceph13之前的各个版本,参数都是在配置文件中设置，如果更改参数需要向每个ceph节点推送新的配置文件，非常麻烦。麻烦倒是其次，一个不小心就会造成各个节点间配置文件不一致，后续如果出现问题排查会很糟心。到了13版本已经提供了ceph config命令，但是并不完善，很多配置依旧需要手动更改配置文件解决。到了14版本类似问题已经很少了。但是依然有一些需要在链接mon前就要确定的参数，依然需要在配置文件里指定，比如：osd_op_queue就得在配置文件里写明。下面对ceph config做一下说明。

             ceph config dump 会列出所有已经修改的参数列表：

            config set <who> <name> <value>指定组件或者全局设定参数：

            如：在集群层面限制rbd的iops最大为100

            ceph config set global rbd_qos_iops_limit 100

            也可以对具体的进程设置参数，

            如： 告诉osd0每天0时开始scrub

            ceph config set osd0 osd_scrub_begin_hour 0

            ceph config rm 删除被参数修改

            如：ceph config rm global rbd_qos_iops_limit

             ceph config log 列出历史上的参数修改记录,每条记录都有唯一标号，它记录了当时的所有配置参数。

            可以使用ceph config reset <int>命令将配置恢复到历史上的一个状态。

            如：ceph config reset 4

            这条命令将集群配置回滚到log id是4的状态。

              ceph config generate-minimal-conf产生一个最小配置的cephconf文件

              config help <key>列出参数的帮助说明

              config show-with-defaults <who> 显示一个或一类进程的默认配置

              config show <who> {<key>}显示一个或一类进程的特定参数的设置

有了这些方法就不用去一个一个推送配置文件了，一次修改全局生效。参数的动态修改更是省心了很多，再也不用麻烦的使用ceph tell osd config set之类的命令。

        msgr2支持加密，支持kerberos授权认证等，但是还需要等待一段时间现在还没发体验，但是已经可以使用ceph mon enable-msgr2启用msgr2。这对提高ceph集群的安全性非常有益处，非常期待。在之前的文档都介绍msgr2在3000端口启用，但是实际测试发现，是在3300端口启用，被叫做“IANA monitor port”。

在msgrh头文件里定义

#define CEPH_MON_PORT_IANA      3300  / IANA monitor port /

            在以往版本里ceph的pg_num只能调大不能调小，现在支持pg_num缩小了。这解决了ceph集群缩容时pg_num过大的问题。

            更重要的是1401-3799-g4de85a5开始支持pg_num自动调整，在1401时还没有。要启用这一功能必须启用mgr的pg_autoscaler模块。pg_autoscale模块将根据pool的实际容量调整pg_num数。

            使用ceph mgr module enable pg_autoscaler命令启用mgr的pg自动调整模块。

            ceph osd pool set <pool name> pg_autoscale_mode 指定池的pg自动调整模式。pg_autoscale_mode有on、off、warn三个模式。开发版如果不指定模式，将默认将进入warn模式，正式发布的1410必须指定一个模式。 ceph osd pool autoscale-status  显示当前pg_num以及将要调整的pg_num数，和相关参数。

这个功能使运维人员不必再为pg_num的调整而烦心，不过当数据量很大时，调整pg_num带来的集群抖动到底有多大还是未知数，还需要等待正式版出来后大量测试检验。

4、ceph report也是很全面的命令，会以json格式报告非常全面的集群运行数据

5、ceph rbd perf image counters 和ceph rbd perf image stats

        这是ceph14新增的两个命令，用来分析image的性能。要启用这个命令，首先要开启mgr的rbd_support模块。命令如下：

          ceph mgr module enable rbd_support

          counters会显示每个image的累计读写iops和累计读写量和平均读写延时。

            stats会显示每个image的即时iops和即时读写速率以及即时读写延时，延时单位是纳秒。

            在ceph14的开发版里有 ceph osd perf query add，ceph  osd perf query remove，ceph osd perf counters get 等命令，用于收集ceph14内定义的client_id,client_address，pool_id，namespace，osd_id，pg_id，object_name，snap_id这八类io数据。收集条件可以以正则表达式的形式注入，正式的ceph1410把这些命令删除了，但保留了rbd相关的命令。rbd性能分析就是通过object_name类型增加SUBKEYS_QUERY查询条件实现的。查询条件过滤了所有和image相关的几类rbd对象：rbd_header、rbd_object_map、rbd_data、rbd_id，实现对image的io数据统计。不过由于mgr里统计的数据并不持久化，一旦mgr崩溃所有的统计数据都会丢失，或者统计条件超时都会丢失统计数据。

6、 ceph progress

        用于显示恢复的进度，恢复过程终于可视化了，使运维人员心里踏实很多。

        ceph progress json回馈更详细的进度内容。

        ceph progress clear清除恢复进度。

7、ceph device

        这也是一个对于ceph运维至关重要的命令，磁盘的健康度直接影响着集群的运行安全，如果能提前预警是再好不过了，这条命令提供了一些帮助。这条命令依赖smartmontools包，之前ceph14的开发版并没有把这条依赖加上，所以要单独安装，正式版不存在这个问题。开发版和正式版的ceph14跟smartctl还不完全匹配或者还没有完全开发完毕，执行ceph device query-daemon-health-metrics osd13一直报错。

这条非常诱人的命令只能等待后续完善了。

8、ceph orchestrator

          这是大神着重提及的一个功能，主要是改善ceph的易用性的。目前它支持rook和ssh两个后端，由于对rook不熟悉，所以以ssh后端为例介绍。

            首先、执行ceph mgr module enable ssh开启mgr的ssh module。

            然后、执行ceph orchestrator set backend ssh开启orchestrator的ssh后端。

           现在就可以开始使用ceph orchestrator相关命令了。但是实际使用还是出错了，因该是mgr的ssh模块没有正确配置的原因。以后有空再深入，这里先跳过了。

9、ceph telemetry 命令用ceph mgr module enable telemetry启用，但是对telemetry不了解也跳过了。

    我们可以将较常使用的rpm安装包归到一个文件里面制作成一个可以被系统识别的yum仓库，通过配置yum仓库指向文件可以将它设置成本地的yum源也可以是通过>

问题一：当前主流分布式文件系统有哪些各有什么优缺点 目前几个主流的分布式文件系统除GPFS外，还有PVFS、Lustre、PanFS、GoogleFS等。

1PVFS(Parallel Virtual File System)项目是Clemson大学为了运行Linux集群而创建的一个开源项目,目前PVFS还存在以下不足：

1）单一管理节点:只有一个管理节点来管理元数据，当集群系统达到一定的规模之后，管理节点将可能出现过度繁忙的情况，这时管理节点将成为系统瓶颈;

2）对数据的存储缺乏容错机制:当某一I/O节点无法工作时，数据将出现不可用的情况;

3）静态配置:对PVFS的配置只能在启动前进行，一旦系统运行则不可再更改原先的配置。

2Lustre文件系统是一个基于对象存储的分布式文件系统，此项目于1999年在Carnegie Mellon University启动，Lustre也是一个开源项目。它只有两个元数据管理节点,同PVFS类似,当系统达到一定的规模之后，管理节点会成为Lustre系统中的瓶颈。

3PanFS(Panasas File System)是Panasas公司用于管理自己的集群存储系统的分布式文件系统。

4GoogleFS(Google File System)是Google公司为了满足公司内部的数据处理需要而设计的一套分布式文件系统。

5相对其它的文件系统，GPFS的主要优点有以下三点：

1)使用分布式锁管理和大数据块策略支持更大规模的集群系统,文件系统的令牌管理器为块、inode、属性和目录项建立细粒度的锁，第一个获得锁的客户将负责维护相应共享对象的一致性管理，这减少了元数据服务器的负担;

2)拥有多个元数据服务器,元数据也是分布式,使得元数据的管理不再是系统瓶颈;

3)令牌管理以字节作为锁的最小单位,也就是说除非两个请求访问的是同一文件的同一字节数据,对于数据的访问请求永远不会冲突

问题二：分布式存储是什么？选择什么样的分布式存储更好？ 分布式存储系统，是将数据分散存储在多 立的设备上。传统的网络存储系统采用集中的存储服务器存放所有数据，存储服务器成为系统性能的瓶颈，也是可靠性和安全性的焦点，不能满足大规模存储应用的需要。分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。

联想超融合ThinkCloud AIO超融合云一体机是联想针对企业级用户推出的核心产品。ThinkCloud AIO超融合云一体机实现了对云管理平台、计算、网络和存储系统的无缝集成，构建了云计算基础设施即服务的一站式解决方案，为用户提供了一个高度简化的一站式基础设施云平台。这不仅使得业务部署上线从周缩短到天，而且与企业应用软件、中间件及数据库软件完全解耦，能够有效提升企业IT基础设施运维管理的效率和关键应用的性能

问题三：什么是分布式存储系统？ 就是将数据分散存储在多 立的设备上

问题四：什么是分布式数据存储 定义：

分布式数据库是指利用高速计算机网络将物理上分散的多个数据存储单元连接起来组成一个逻辑上统一的数据库。分布式数据库的基本思想是将原来集中式数据库中的数据分散存储到多个通过网络连接的数据存储节点上，以获取更大的存储容量和更高的并发访问量。近年来，随着数据量的高速增长，分布式数据库技术也得到了快速的发展，传统的关系型数据库开始从集中式模型向分布式架构发展，基于关系型的分布式数据库在保留了传统数据库的数据模型和基本特征下，从集中式存储走向分布式存储，从集中式计算走向分布式计算。

特点：

1高可扩展性：分布式数据库必须具有高可扩展性，能够动态地增添存储节点以实现存储容量的线性扩展。

2 高并发性：分布式数据库必须及时响应大规模用户的读/写请求，能对海量数据进行随机读/写。

3 高可用性：分布式数据库必须提供容错机制，能够实现对数据的冗余备份，保证数据和服务的高度可靠性。

问题五：分布式文件系统有哪些主要的类别？ 分布式存储在大数据、云计算、虚拟化场景都有勇武之地，在大部分场景还至关重要。munityemc/message/655951 下面简要介绍nix平台下分布式文件系统的发展历史：

1、单机文件系统

用于 *** 作系统和应用程序的本地存储。

2、网络文件系统（简称：NAS）

基于现有以太网架构，实现不同服务器之间传统文件系统数据共享。

3、集群文件系统

在共享存储基础上，通过集群锁，实现不同服务器能够共用一个传统文件系统。

4、分布式文件系统

在传统文件系统上，通过额外模块实现数据跨服务器分布，并且自身集成raid保护功能，可以保证多台服务器同时访问、修改同一个文件系统。性能优越，扩展性很好，成本低廉。

问题六：分布式文件系统和分布式数据库有什么不同 分布式文件系统（dfs）和分布式数据库都支持存入，取出和删除。但是分布式文件系统比较暴力，可以当做key/value的存取。分布式数据库涉及精炼的数据，传统的分布式关系型数据库会定义数据元组的schema，存入取出删除的粒度较小。

分布式文件系统现在比较出名的有GFS（未开源），HDFS（Hadoop distributed file system）。分布式数据库现在出名的有Hbase，oceanbase。其中Hbase是基于HDFS，而oceanbase是自己内部实现的分布式文件系统，在此也可以说分布式数据库以分布式文件系统做基础存储。

问题七：分布式存储有哪些 华为的fusionstorage属于分布式 您好，很高兴能帮助您，首先，FusionDrive其实是一块1TB或3TB机械硬盘跟一块128GB三星830固态硬盘的组合。我们都知道，很多超极本同样采用了混合型硬盘，但是固态硬盘部分的容量大都只有8GB到32GB之间，这个区间无法作为系统盘来使用，只能作

问题八：linux下常用的分布式文件系统有哪些 这他妈不是腾讯今年的笔试题么

NFS（tldp/HOWTO/NFS-HOWTO/index）

网络文件系统是FreeBSD支持的文件系统中的一种，也被称为NFS。

NFS允许一个系统在网络上与它人共享目录和文件。通过使用NFS， 用户和程序可以象访问本地文件一样访问远端系统上的文件。它的好处是：

1、本地工作站使用更少的磁盘空间，因为通常的数据可以存放在一台机器上而且可以通过网络访问到。

2、用户不必在每个网络上机器里面都有一个home目录。home目录可以被放在NFS服务器上并且在网络上处处可用。

3、诸如软驱、CDROM、和ZIP之类的存储设备可以在网络上面被别的机器使用。可以减少整个网络上的可移动介质设备的数量。

开发语言c/c++,可跨平台运行。

OpenAFS（openafs）

OpenAFS是一套开放源代码的分布式文件系统，允许系统之间通过局域网和广域网来分享档案和资源。OpenAFS是围绕一组叫做cell的文件服务器组织的，每个服务器的标识通常是隐藏在文件系统中，从AFS客户机登陆的用户将分辨不出他们在那个服务器上运行，因为从用户的角度上看，他们想在有识别的Unix文件系统语义的单个系统上运行。

文件系统内容通常都是跨cell复制，一便一个硬盘的失效不会损害OpenAFS客户机上的运行。OpenAFS需要高达1GB的大容量客户机缓存，以允许访问经常使用的文件。它是一个十分安全的基于kerbero的系统，它使用访问控制列表(ACL）以便可以进行细粒度的访问，这不是基于通常的Linux和Unix安全模型。开发协议IBM Public，运行在linux下。

MooseFs（derfhomelinux）

Moose File System是一个具备容错功能的网路分布式文件统，它将数据分布在网络中的不同服务器上，MooseFs通过FUSE使之看起来就 是一个Unix的文件系统。但有一点问题，它还是不能解决单点故障的问题。开发语言perl,可跨平台 *** 作。

pNFS（pnfs）

网络文件系统(Network FileSystem,NFS)是大多数局域网(LAN）的重要的组成部分。但NFS不适用于高性能计算中苛刻的输入书橱密集型程序，至少以前是这样。NFS标准的罪行修改纳入了Parallel NFS(pNFS），它是文件共享的并行实现，将传输速率提高了几个数量级。

开发语言c/c++,运行在linu下。

googleFs

据说是一个比较不错的一个可扩展分布式文件系统，用于大型的，分布式的，对大量数据进行访问的应用。它运行于廉价的普通硬件上，但可以提供容错功能，它可以给大量的用户提供性能较高的服务。google自己开发的。

问题九：分布式存储都有哪些，并阐述其基本实现原理 神州云科 DCN NCS DFS2000（简称DFS2000）系列是面向大数据的存储系统，采用分布式架构，真正的分布式、全对称群集体系结构，将模块化存储节点与数据和存储管理软件相结合，跨节点的客户端连接负载均衡，自动平衡容量和性能，优化集群资源，3-144节点无缝扩展，容量、性能岁节点增加而线性增长，在 60 秒钟内添加一个节点以扩展性能和容量。

问题十：linux 分布式系统都有哪些？ 常见的分布式文件系统有，GFS、HDFS、Lustre 、Ceph 、GridFS 、mogileFS、TFS、FastDFS等。各自适用于不同的领域。它们都不是系统级的分布式文件系统，而是应用级的分布式文件存储服务。

GFS（Google File System）

--------------------------------------

Google公司为了满足本公司需求而开发的基于Linux的专有分布式文件系统。。尽管Google公布了该系统的一些技术细节，但Google并没有将该系统的软件部分作为开源软件发布。

下面分布式文件系统都是类 GFS的产品。

HDFS

--------------------------------------

Hadoop 实现了一个分布式文件系统（Hadoop Distributed File System），简称HDFS。 Hadoop是Apache Lucene创始人Doug Cutting开发的使用广泛的文本搜索库。它起源于Apache Nutch，后者是一个开源的网络搜索引擎，本身也是Luene项目的一部分。Aapche Hadoop架构是MapReduce算法的一种开源应用，是Google开创其帝国的重要基石。

Ceph

---------------------------------------

是加州大学圣克鲁兹分校的Sage weil攻读博士时开发的分布式文件系统。并使用Ceph完成了他的论文。

说 ceph 性能最高，C++编写的代码，支持Fuse，并且没有单点故障依赖， 于是下载安装， 由于 ceph 使用 btrfs 文件系统， 而btrfs 文件系统需要 Linux 2634 以上的内核才支持。

可是ceph太不成熟了，它基于的btrfs本身就不成熟，它的官方网站上也明确指出不要把ceph用在生产环境中。

Lustre

---------------------------------------

Lustre是一个大规模的、安全可靠的，具备高可用性的集群文件系统，它是由SUN公司开发和维护的。

该项目主要的目的就是开发下一代的集群文件系统，可以支持超过10000个节点，数以PB的数据量存储系统。

目前Lustre已经运用在一些领域，例如HP SFS产品等。

在传统分布式存储架构中，存储节点往往仅作为被动查询对象来使用，随着存储规模的增加，数据一致性的管理会出现很多问题。

而新型的存储架构倾向于将基本的块分配决策和安全保证等 *** 作交给存储节点来做，然后通过提倡客户端和存储节点直接交互来简化数据布局并减小io瓶颈。

RADOS就是这样一个可用于PB级规模数据存储集群的可伸缩的、可靠的对象存储服务。它包含两类节点：存储节点、管理节点。它通过利用存储设备的智能性，将诸如一致性数据访问、冗余存储、错误检测、错误恢复分布到包含了上千存储节点的集群中，而不是仅仅依靠少数管理节点来处理。

RADOS中的存储节点被称为OSD(object storage device)，它可以仅由很普通的组件来构成，只需要包含CPU、网卡、本地缓存和一个磁盘或者RAID，并将传统的块存储方式替换成面向对象的存储。

在PB级的存储规模下，存储系统一定是动态的：系统会随着新设备的部署和旧设备的淘汰而增长或收缩，系统内的设备会持续地崩溃和恢复，大量的数据被创建或者删除。RADOS通过 cluster map来实现这些，cluster map会被复制到集群中的所有部分（存储节点、控制节点，甚至是客户端），并且通过怠惰地传播小增量更新而更新。cluster map中存储了整个集群的数据的分布以及成员。

通过在每个存储节点存储完整的cluster map，存储设备可以表现的半自动化，通过peer-to-peer的方式（比如定义协议）来进行数据备份、更新，错误检测、数据迁移等等 *** 作。这无疑减轻了占少数的monitor cluster（管理节点组成的集群）的负担。

一个RADOS系统包含大量的OSDs 和 很少的用于管理OSD集群成员的monitors。OSD的组成如简介所说。而monitor是一些独立的进程，以及少量的本地存储，monitor之间通过一致性算法保证数据的一致性。

存储节点集群通过monitor集群 *** 作cluster map来实现成员的管理。cluster map 描述了哪些OSD被包含进存储集群以及所有数据在存储集群中的分布。

cluster map不仅存储在monitor节点，它被复制到集群中的每一个存储节点，以及和集群交互的client。

当因为一些原因，比如设备崩溃、数据迁移等，cluster map的内容需要改变时，cluster map的版本号被增加，map的版本号可以使通信的双方确认自己的map是否是最新的，版本旧的一方会先将map更新成对方的map，然后才会进行后续 *** 作。

首先，如下图，总体说下RADOS的存储层次，RADOS中基本的存储单位是对象，一般为2MB或4MB，当一个文件要存入RADOS时，首先会被切分成大小固定的对象（最后一个对象大小可能不同），然后将对象分配到一个PG（Placement Group）中，然后PG会复制几份，伪随机地派给不同的存储节点。当新的存储节点被加入集群，会在已有数据中随机抽取一部分数据迁移到新节点。这种概率平衡的分布方式可以保证设备在潜在的高负载下正常工作。更重要的是，数据的分布过程仅需要做几次随机映射，不需要大型的集中式分配表。

对于每个层次的详细说明：

2Object—— RADOS的基本存储单元。Object与上面提到的file的区别是，object的最大size由RADOS限定（通常为2MB或4MB），以便实现底层存储的组织管理。因此，当上层应用向RADOS存入size很大的file时，需要将file切分成统一大小的一系列object（最后一个的大小可以不同）进行存储。

各层次之间的映射关系：

前面的介绍中已经提到，由若干个monitor共同负责整个RADOS集群中所有OSD状态的发现与记录，并且共同形成cluster map的master版本，然后扩散至全体OSD以及client。OSD使用cluster map进行数据的维护，而client使用cluster map进行数据的寻址。

monitor并不主动轮询各个OSD的当前状态。相反，OSD需要向monitor上报状态信息。常见的上报有两种情况：一是新的OSD被加入集群，二是某个OSD发现自身或者其他OSD发生异常。在收到这些上报信息后，monitor将更新cluster map信息并加以扩散。其细节将在下文中加以介绍。

Cluster map的实际内容包括：

（1） Epoch，即版本号。cluster map的epoch是一个单调递增序列。epoch越大，则cluster map版本越新。因此，持有不同版本cluster map的OSD或client可以简单地通过比较epoch决定应该遵从谁手中的版本。而monitor手中必定有epoch最大、版本最新的cluster map。当任意两方在通信时发现彼此epoch值不同时，将默认先将cluster map同步至高版本一方的状态，再进行后续 *** 作。

（2）各个OSD的网络地址。

（3）各个OSD的状态。OSD状态的描述分为两个维度：up或者down（表明OSD是否正常工作），in或者out（表明OSD是否在至少一个PG中）。因此，对于任意一个OSD，共有四种可能的状态：

（4）CRUSH算法配置参数。表明了Ceph集群的物理层级关系（cluster hierarchy），位置映射规则（placement rules）。

根据cluster map的定义可以看出，其版本变化通常只会由（3）和（4）两项信息的变化触发。而这两者相比，（3）发生变化的概率更高一些。这可以通过下面对OSD工作状态变化过程的介绍加以反映。

一个新的OSD上线后，首先根据配置信息与monitor通信。Monitor将其加入cluster map，并设置为up且out状态，再将最新版本的cluster map发给这个新OSD。

收到monitor发来的cluster map之后，这个新OSD计算出自己所承载的PG（为简化讨论，此处我们假定这个新的OSD开始只承载一个PG），以及和自己承载同一个PG的其他OSD。然后，新OSD将与这些OSD取得联系。如果这个PG目前处于降级状态（即承载该PG的OSD个数少于正常值，如正常应该是3个，此时只有2个或1个。这种情况通常是OSD故障所致），则其他OSD将把这个PG内的所有对象和元数据复制给新OSD。数据复制完成后，新OSD被置为up且in状态。而cluster map内容也将据此更新。这事实上是一个自动化的failure recovery过程。当然，即便没有新的OSD加入，降级的PG也将计算出其他OSD实现failure recovery。

如果该PG目前一切正常，则这个新OSD将替换掉现有OSD中的一个（PG内将重新选出Primary OSD），并承担其数据。在数据复制完成后，新OSD被置为up且in状态，而被替换的OSD将退出该PG（但状态通常仍然为up且in，因为还要承载其他PG）。而cluster map内容也将据此更新。这事实上是一个自动化的数据re-balancing过程。

如果一个OSD发现和自己共同承载一个PG的另一个OSD无法联通，则会将这一情况上报monitor。此外，如果一个OSD deamon发现自身工作状态异常，也将把异常情况主动上报给monitor。在上述情况下，monitor将把出现问题的OSD的状态设为down且in。如果超过某一预订时间期限，该OSD仍然无法恢复正常，则其状态将被设置为down且out。反之，如果该OSD能够恢复正常，则其状态会恢复为up且in。在上述这些状态变化发生之后，monitor都将更新cluster map并进行扩散。这事实上是自动化的failure detection过程。

对于一个RADOS集群而言，即便由数千个甚至更多OSD组成，cluster map的数据结构大小也并不惊人。同时，cluster map的状态更新并不会频繁发生。即便如此，Ceph依然对cluster map信息的扩散机制进行了优化，以便减轻相关计算和通信压力：

基于上述机制，Ceph避免了由于cluster map版本更新而引起的广播风暴。这虽然是一种异步且lazy的机制，但根据论文中的结论，对于一个由n个OSD组成的Ceph集群，任何一次版本更新能够在O(log(n))时间复杂度内扩散到集群中的任何一个OSD上。

一个可能被问到的问题是：既然这是一种异步和lazy的扩散机制，则在版本扩散过程中，系统必定出现各个OSD看到的cluster map不一致的情况，这是否会导致问题？答案是：不会。事实上，如果一个client和它要访问的PG内部的各个OSD看到的cluster map状态一致，则访问 *** 作就可以正确进行。而如果这个client或者PG中的某个OSD和其他几方的cluster map不一致，则根据Ceph的机制设计，这几方将首先同步cluster map至最新状态，并进行必要的数据re-balancing *** 作，然后即可继续正常访问。

云和安全管理服务专家新钛云服 祝祥翻译

CEPFS支持快照功能，通常通过使用mkdir命令创建快照目录。注意这是一个隐藏的特殊目录，在目录列表中不可见。

通常情况下，快照正如起名：它们保存数据变化过程中的状态。需要注意的一点事，CEPFS快照的一些功能与您可能期望的有所不同：

默认情况下，新文件系统上会启用CEPFS快照功能。要在现有文件系统上启用它，请使用下面的命令。

启用快照后，CephFS中的所有目录都将有一个特殊的 snap 快照目录。（如果愿意，可以使用客户端snapdir设置配置其他名称）

要创建CephFS快照，请在 snap 下创建子目录。用你选择的名字创建快照。例如，要在目录“/1/2/3/”下创建快照，请使用 mkdir /1/2/3/snap/my-snapshot-name 命令。

客户端会将请求发送到MDS服务器，然后在服务器的Server::handle_client_mksnap（）中处理。它会从 SnapServer中分配一个 snapid，利用新的 SnapRealm创建并链接一个新的inode，然后将其提交到 MDlog，提交后会触发 MDCache::do_realm_invalidate_and_update_notify()，此函数将此 SnapRealm广播给所有对快照目录下任一文件有管辖权的客户端。客户端收到通知后，将同步更新本地 SanpRealm层级结构，并为新的SnapRealm结构生成新的 SnapContext，用于将快照数据写入 OSD 端。同时，快照的元数据会作为目录信息的一部分更新到OSD端（即sr_t）。整个过程是完全异步处理的。

如果删除快照，将执行类似的过程。如果将inode从其父SnapRealm中删除，重命名代码将为重命名的inode创建一个新的SnapRealm（如果SnapRealm不存在），将在原始父SnapRealm上有效的快照ID保存到新SnapRealm的父快照（past_parent_snaps）中，然后遵循与创建快照类似的过程。

RADOS SnapContext由一个快照序列ID（snapid）和一个包含所有快照ID对象组成。为了生成该列表，我们将与SnapRealm关联的SnapID与父快照中的所有有效SnapID结合起来。过时的SnapID由SnapClient缓存的有效快照过滤掉。

文件数据存储在RADOS“self-managed”快照中。在将文件数据写入OSD时，客户端会小心地使用正确的SnapContext。

快照的dentries（及其inode）作为快照时所在目录的一部分在线存储。所有dentries都包括第一个和最后一个有效的snapid。（非快照的dentries将最后设置为CEPH_NOSNAP）。

有大量代码可以有效地处理写回。当客户端收到MClientSnap消息时，它会更新本地SnapRealm表示及其到特定Inode的链接，并为Inode生成CapSnap。CapSnap作为功能写回的一部分被清除，如果存在脏数据，CapSnap将用于阻止新的数据写入，直到快照完全清除到OSD。 在MDS中，我们生成代表牙齿的快照，作为冲洗牙齿的常规过程的一部分。具有杰出CapSnap数据的假牙被固定并记录在日志中。

通过在快照的根目录“snap”中调用“rmdir”来删除快照。（尝试删除根快照将失败的目录；必须先删除快照。）一旦删除，它们将被输入到已删除快照的OSDMap列表中，文件数据将由OSD删除。当目录对象被读入并再次写回时，元数据会被清除。

具有多个硬链接的Inode被移动到一个虚拟全局SnapRealm。虚拟SnapRealm覆盖文件系统中的所有快照。inode的数据将为任何新快照保留。这些保留的数据将覆盖inode的任何链接上的快照。

需要注意的是，CephFS的快照和多个文件系统的交互是存在问题的——每个 MDS集群独立分配 snappid，如果多个文件系统共享一个池，快照会冲突。如果此时有客户删除一个快照，将会导致其他人丢失数据，并且这种情况不会提升异常，这也是 CephFS的快照不推荐使用的原因之一。

创建快照：

从快照中恢复文件：

自动快照

使用cephfs-snap自动创建和删除旧快照。

下载文件到 /usr/bin

配合cron 一起使用。{hourly,daily,weekly,monthly}

使用示例：

创建的 cron 文件必须设置为可执行

要验证配置的 cron 任务是否会正确执行，请手动运行上述步骤中创建的 cron 脚本

现在检查 snap 目录中是否创建了 cephfs 快照

如果 cron 没有按预期触发快照，请验证“/usr/bin/cephfs-snap”和“/etc/cron/cephfs-snap”文件是否可执行

参考文章：

说明： 多数据中心（multisite）功能oNest v61新增的功能，旨在实现异地双活，提供了备份容灾的能力。并且具有多个数据中心供用户选择，存放资源。

主节点在对外提供服务时，用户数据在主节点落盘后即向用户回应“写成功”应答，然后实时记录数据变化的相关日志信息。备节点则实时比较主备数据差异，并及时将差异化数据拉回备节点。异步复制技术适用于远距离的容灾方案，对系统性能影响较小。

一个realm代表了全局唯一的命名空间，这个命名空间由一个或者多个zonegroup，zonegroup可以包含一个或多个zone，zone包含了桶，桶里包依次存放了对象。

单个数据中心的配置一般由一个zonegroup组成，这个zonegroup包含一个zone和一个或者多个rgw实例。在这些rgw中可以平衡网关请求。

搭建realm前最好删除本地的pool，删除前请确认， 谨慎 *** 作 。若仍需保留这些数据，可以不作删除。

创建一个全局唯一的命名空间，realm有领域、王国的意思。为了便于管理，规定在这个realm里所有的元数据名称都是全局唯一的，无法创建同名的用户（指uid）和桶（bucket或container）。

执行节点：beiji1com

zonegroup是数据中心的概念。说到王国的概念，就不能缺少国王，或者我们中国古代的皇帝（master zone），所以这个zonegroup很特别，是zonegroup中的master。

执行节点：beiji1com

为了前向兼容，所以会存在默认的zonegroup，需要删除。

master zonegroup的master zone，或者说是王国中的国王。中央集权，权力较大，所有用户的创建、删除、修改都必须通过他进行，其他zone创建、删除或者修改桶级别的元数据的所有请求都需要转发给他。不通过他创建的用户，则无法创建桶。

执行节点：beiji1com

为了前向兼容，所以会存在默认的zone，需要删除。

各个zone拉取主主zone的数据中心结构都需要通过这个系统用户，需要获取他的AK和SK。系统用户就像一位总管。

在zonegroup中slave zone主要用于与master zone的数据异地同步备份。当master zone出现故障时，可以将slave zone切成master zone继续对外提供服务。待原master zone故障修复时，可以重新切回，不受数据丢失的影响。具体切换步骤请参照 Multisite结构调整 章节

执行节点：nanji1com

为了在同一realm中，需要拉取master zonegroup的master zone的配置，此配置包含realm的信息，已经创建zonegroup的信息。并将其设置为默认的realm和zonegroup

slave zonegroup也是一个数据中心，只是在slave zonegroup上创建的用户无法实现同步，需要master zonegroup的master zone直接创建，不能进行请求转发，但是各个用户创建、删除bucket可以在slave zonegroup的各个zone上进行，他会将这些请求转发到master zonegroupo的master zone进行日志登记，然后通知各个zone进行同步。

执行节点：nanji2com

执行节点：nanji2com

执行节点：beiji2com

同步状态查看

分别在zone所在的节点上执行以下命令查看状态

列出和获取节点的realm

列出realm的periods

列出和获取节点的zonegroup

获取zonegroup map

列出和获取节点的zone

通过命令行修改

通过配置文件修改

说明： 将在不同realm下的两个zonegroup组合成同一个realm，并且zonegroup中只含有master zone，不存在slave zone。

原拓扑结构

数据中心1（site1）

数据中心2（site2）

目标拓扑结构

说明： 如果一个zonegroup中主zone挂了，此时需要涉及到把从zone设置为主zone，待原主zone恢复后，需要切换回来。

将原从zone切换为主zone：

原主zone故障恢复后，将原主zone设置为主zone。

使用以下的步骤可以将使用默认的zonegroup和zone的数据中心迁移到多数据中心

ceph对象网关通过placement targets进行存 储桶 和 对象 的数据，通过placement target来指定桶和对象的存储池。如果不配置placement targets，桶和对象将会存到网关实例所在zone配置的默认存储池中。

存储策略给对象网关提供了一个获得存储策略的权限，比如，指定特殊的存储类型（SSDs，SAS drivers， SATA drivers）

说明： 本节主要涉及到zone和zonegroup关于placement的配置，以下 *** 作以配置纠删码（EC）存储池为例，说明多数据中心的placement配置规则和使用方法。

增加以下内容：（以单节点ceph集群为例）

设置修改后的crush map

以上就是关于【ceph】对象存储的目录/文件夹概念全部的内容，包括:【ceph】对象存储的目录/文件夹概念、Ceph高可用部署和主要组件介绍、ceph14.1.x的一下新功能（一）等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！