大家好，我是讯享网，很高兴认识大家。



 

2_存储基础任 务 场 景 任务清单

清单列表

一、对象存储概念及实现

1.1 对象存储引入

1.2 对象存储实现-FastDFS 打卡要求

二、Ceph存储工作原理及实现

2.1 认识Ceph

2.2 ceph架构

2.3 Ceph存储数据方法(IO算法)

2.4 拓展名词

2.5 Ceph集群

2.5.1 集群基础组件

2.5.2 集群环境准备

2.5.3 集群部署过程

2.6 原生数据存取

2.6.1 创建pool

2.6.2 删除pool

2.6.3 原生数据存储过程

2.7 Ceph文件存储

2.7.1 创建文件存储并使用

2.7.2 删除文件存储

2.8 Ceph块存储

2.8.1 创建块存储并使用

2.8.2 块存储扩容与裁减

2.8.3 删除块存储

2.9 Ceph对象存储

2.9.1 测试ceph对象网关的连接

2.9.2 S3连接ceph对象网关

2.10 ceph dashboard

打卡要求任务总结

任务打卡任务订阅

 

 

 

 

波仔在学习文件存储、块存储及分布式存储后，能够明显感觉到以上存储的优缺点，优缺点我们在前面已有罗列，那 么针对以上存储的缺点我们有没有更合适的存储解决方案呢？答案是有，我们可以考虑使用对象存储解决，那么什么 是对象存储及其可用的实现方式有哪些呢？下面我们来学习。

 

 

 

清单列表

 

 

讯享网对象存储概念及实现

Ceph存储工作原理及实现

一、对象存储概念及实现

 

1.1 对象存储引入

为什么要有对象存储呢？必须先聊聊对象存储诞生之前的两大存储模型:文件存储和块存储。

文件存储

其立足于物理存储介质之上，是操作系统对数据管理操作的抽象，这些抽象最终汇总形成文件系统,例如NFS,Samba    等。一般我们提到的文件系统都遵循POSIX标准，而POSIX标准定义了操作系统应该为其上运行的应用程序提供的接 口标准。基于这套接口标准，我们可以非常方便的将数据以文件、文件夹方式进行管理，但是常见的文件系统都是按 目录树进行管理，在互联网数据爆炸时代，随着文件目录层级不断增加，亦或是文件数量达到海量以后，文件管理成 本会直线飙升，特别是一些遍历操作会变得非常低效，因此文件存储在面对海量数据的时候有些力不从心。

优点：便于共享

缺点：文件数量多，文件大的话，不便于传输或查找

块存储

其主要是将存储介质的空间整个映射给主机使用的，主机如果需要对这些空间进行读写IO操作，需要先进行分区和格 式化处理，形成可以**作系统识别的逻辑命名空间，之后主机才能通过操作系统对这些存储介质进行读写操作。常 见的块存储有磁盘，SSD，SAN等，这些物理设备都或多或少存在物理上的极限，比如存储空间、性能等都存在物理 极限。

优点：以块为单位，便于数据传输

缺点：不利于数据共享，不得于数据可视化对象存储

了解完文件存储和块存储以后，终于轮到对象存储出场，那对象存储又是如何克服块存储和文件存储的短板？在介绍 对象存储之前，需要我们特别注意的就是对象存储天生就带互联网基因，完美适配当前互联网场景下的各种爆炸式数 据需求,具体表现为：

扁平化的命名空间

将数据以对象(Object)形式存储在以桶(Bucket)为命名空间的两级结构中，通过新增Bucket方式来横向扩展命名 空间，同时通过在Bucket中不断新增Object方式来实现海量数据的存储，这种扁平化的数据管理模型克服了目 录树管理的不足，实现了海量数据简单有效的管理。需要注意的是Bucket的名称全局，通过桶名称(Bucket name)+对象的键名(Key name)来定位一个对象的最终存储路径。

分布式构架设计 借助扁平化的管理模型设计，使得整个对象存储系统可以按命名空间规则进行底层数据存储的分区，借助一些哈希算法最终将需要存储的数据按分区规则均匀分布到多个主机的多块磁盘上，从而实现数据 的分布式存储，从而解决了物理硬件的扩容及性能问题，为海量数据的存储铺平道路。

通用化的接口标准 在解决了海量数据管理和硬件短板的问题之后，对象存储还要克服一个关键的问题:如何实现通用接口标准？通用接口标准对一个对象存储系统来说至关重要，这个是整个系统与外围系统打交道的重要窗 口。如何兼容各种外围系统，去适配各种开发语言，形成一套围绕对象存储系统的生态标准？同样遵循“Simple   is best！”思想，互联网时代HTTP大行其道，到处都通行的RESTful风格被对象存储“一眼相中”，目前主流的对象存储在接口标准的实现上都提供RESTful风格的API，同时也衍生出各种语言的SDK，当然有些对象存储也实 现了RPC、SOAP等标准。

(非)结构化数据与对象存储之间的关系 什么是结构化数据和非结构化数据?

以大家熟知的关系型数据库场景为例： 将一个人的属性抽象出来，分为姓名(name),年龄(age),住址(address),邮箱(email)几个标签，之后将这些信息存储到数据库中，那么某个人将对应到数据库里的一条 记录。众所周知，我们现在熟知的数据库主要是关系型数据库，如果能够将数据按关系模型进行存储和管 理，那么这一类数据就是结构化数据。

与之相对立的就是非结构化数据。如果上面需要存储的数据新增了一个相片(photo)字段，用于存储用户的 相片数据，因为相片数据无法通过关系型数据进行描述，所以一般存储相片都是以二进制方式(非结构化方 式)存储在关系数据库中，但是传统数据库不是万能。当需要比较多张相片的相似度，并删除重复相片，特 别是需要管理海量相片的时候，传统的关系型数据库，会让你觉得异常痛苦。 对象存储正是为了弥补传统关系型数据库在管理非结构化数据方面的不足。在对象存储模型中，将每一条存储在其中的非结构化数据 抽象成一个“对象”，一个对象(Object)主要由下面四部分组成:

键名(Key):用于标识对象的名称，通过Bucket name+ Key的组合来确定对象最终存储路径。 键值(Value): 用于存储对象的内容数据。 访问控制列表(ACL):标识对象可以被哪些用户或者用户组访问。 元数据(Metadata):用于以key-value形式存储对象其他额外信息，比如对象内容的MD5校验值，对象的属主(owner），atime/ctime/mtime等。

1.2 对象存储实现-FastDFS

由于在Ceph中会涉及对象存储实现及应用，因此FastDFS将做为扩展。

打卡要求

 

1. 简述什么是对象存储？

二、Ceph存储工作原理及实现

 

 

2.1 认识Ceph

Ceph是一个能提供的文件存储,块存储和对象存储的分布式存储系统。它提供了一个可无限伸缩的Ceph存储集群。

2.2 ceph架构

中文参考官档: http://docs.ceph.org.cn/

官方网站：http://ceph.com

最底层是RADOS:    Ceph的高可靠、高可拓展、高性能、高自动化都是由这一层来提供的，用户数据的存储最终也都是通过这一层来进行存储的。

LIBRADOS是一个库，它允许应用程序通过访问该库来与RADOS系统进行交互，支持多种编程语言，比如Python,C,C++等.

RADOSGW是一套基于当前流行的RESTFUL协议的网关，并且兼容S3和Swift. RBD通过Linux内核客户端和QEMU/KVM驱动来提供一个分布式的块设备。CEPH FS通过Linux内核客户端和FUSE来提供一个兼容POSIX的文件系统。

2.3 Ceph存储数据方法(IO算法)

 

 

1. File用户需要读写的文件。File->Object映射：

a. ino (File的元数据，File的唯一id)。

b. ono(File切分产生的某个object的序号，默认以4M切分一个块大小)。

c. oid(object id: ino + ono)。

2. Object是RADOS需要的对象。Ceph指定一个静态hash函数计算oid的值，将oid映射成一个近似均匀分布的伪随机 值，然后和mask按位相与，得到pgid。Object->PG映射：

a. hash(oid) & mask-> pgid 。

b. mask = PG总数m(m为2的整数幂)-1 。

3. PG(Placement Group),用途是对object的存储进行组织和位置映射, (类似于redis cluster里面的slot的概念)  一个PG 里面会有很多object。采用CRUSH算法，将pgid代入其中，然后得到一组OSD。PG->OSD映射：

a. CRUSH(pgid)->(osd1,osd2,osd3) 。

4. CRUSH算法

CRUSH(Controlled Scalable Decentralized Placement of Replicated Data)算法为可控的、可扩展的、分布式的副本数据放置算法的简称。

PG到OSD的映射的过程算法叫做CRUSH 算法。(一个Object需要保存三个副本，也就是需要保存在三个osd上)。

CRUSH算法是一个伪随机的过程，他可以从所有的OSD中，随机性选择一个OSD集合，但是同一个PG每次随机选择 的结果是不变的，也就是映射的OSD集合是固定的。

2.4 拓展名词

RESTFUL:    RESTFUL是一种架构风格,提供了一组设计原则和约束条件,http就属于这种风格的典型应用。REST最大的几个特点为：资源、统一接口、URI和无状态。

资源: 网络上一个具体的信息: 一个文件,一张图片,一段视频都算是一种资源。

统一接口: 数据的元操作，即CRUD(create, read, update和delete)操作，分别对应于HTTP方法

GET（SELECT）： 从 服 务 器 取 出 资 源 ( 一 项 或 多 项 ) 。 POST（CREATE）： 在 服 务 器 新 建 一 个 资 源 。 PUT（UPDATE）：在服务器更新资源(客户端提供完整资源数据)。PATCH（UPDATE）：在服务器更新资源(客户端提供需要修改的资源数据)。DELETE（DELETE）：从服务器删除资源。

URI(统一资源定位符): 每个URI都对应一个特定的资源。要获取这个资源，访问它的URI就可以。最典型的URI即

URL

无状态: 一个资源的定位与其它资源无关，不受其它资源的影响。

S3 (Simple Storage Service 简单存储服务): 可以把S3看作是一个超大的硬盘, 里面存放数据资源(文件,图片,视频等), 这些资源统称为对象.这些对象存放在存储段里,在S3叫做bucket.

和硬盘做类比, 存储段(bucket)就相当于目录,对象就相当于文件。硬盘路径类似/root/file1.txt

S3的URI类似 //bucket_name/object_name

swift:    最初是由Rackspace公司开发的高可用分布式对象存储服务，并于2010年贡献给OpenStack开源社区作为其最初的核心子项目之一.

2.5 Ceph集群

2.5.1 集群基础组件

Ceph集群包括Ceph OSD,Ceph Monitor两种守护进程。

Ceph OSD(Object Storage Device): 功能是存储数据,处理数据的复制、恢复、回填、再均衡,并通过检查其他OSD守护进程的心跳来向Ceph Monitors提供一些监控信息。 Ceph Monitor: 是一个监视器,监视Ceph集群状态和维护集群中的各种关系。

Ceph存储集群至少需要一个Ceph Monitor和两个 OSD 守护进程。

2.5.2 集群环境准备

 

 

准备工作:

准备四台服务器，需要能上外网 (除client外每台加1个磁盘，大小1G就可以，不用分区); 1, 主机名和主机名绑定(所有节点都要绑定)

(注意:这里都全改成短主机名,方便后面实验。如果你坚持用类似vm1.cluster.com这种主机名,或者加别名的话,ceph

会在后面截取你的主机名vm1.cluster.com为vm1,造成不一致导致出错)

2, 关闭防火墙,selinux(使用iptables -F清一下规则)

3, 时间同步(启动ntpd服务并确认所有节点时间一致,使用rdate同步时间也会有一点小问题)

4, 配置yum源

(所有机器都要做,如果专门的客户端机器也要做,除了centos7默认的源外,还要加epel源与下面的aliyun的ceph源,官方ceph源网速慢)

特别说明: 因为网络的原因,即使换成了国内的yum源(如阿里源),网速仍然很慢。所以这里使用我这里已经下载并测试

OK的版本。

将共享的软件包上传到所有节点上,我这里目录为/ceph_soft

然后并配置本地ceph源

2.5.3 集群部署过程

第1步: 配置ssh免密

以node1为部署节点,在node1上配置ssh等效性(要求ssh node1,node2,node3都要免密码)

 

第2步: 在node1上安装部署工具

(其它节点不用安装)

第3步: 在node1上创建集群

建立一个集群配置目录，后面的大部分操作都会在此目录

 

创建一个ceph集群

 

第4步: 所有节点都安装ceph

前面准备环境时已经准备好了yum源,在这里所有节点(包括client)都安装以下软件

补充说明: 如果公网OK,并且网速好的话,可以用 ceph-deploy install node1 node2 node3 命令来安装,但网速不好的话会比较坑, 所以这里我们选择直接用准备好的本地ceph源,然后yum install ceph ceph-radosgw -y 安装即

可。

第5步: 创建mon(监控) 增加public网络用于监控

(这一步必须得做，否则后面加监控节点等操作都不能成功)

监控节点初始化,并同步配置到所有节点(node1,node2,node3,不包括client)

 

 

 

为了防止mon单点故障，你可以加多个mon节点(建议奇数个，因为有quorum仲裁投票)    回顾: 什么是quorum(仲裁,法定人数)?

查看mon各种状态

5

6 #查看 mon 的选举状态

7 [root@node1 ~]# ceph quorum_status

8 {"election_epoch":780,"quorum":[0,1,2],"quorum_names": ["node2","node1","node3"],"quorum_leader_name":"node2","monmap":

{"epoch":3,"fsid":"49046d3e-027a-4cc6-a602-f2375f49e584","modified":"2019-06-15 17:23:26.","created":"2019-06-15 17:15:10.","features":{"persistent": ["kraken","luminous","mimic","osdmap-prune"],"optional":[]},"mons":

[{"rank":0,"name":"node2","addr":"192.168.216.128:6789/0","public_addr":"192.168.216. 128:6789/0"},

{"rank":1,"name":"node1","addr":"192.168.216.129:6789/0","public_addr":"192.168.216.1 29:6789/0"},

{"rank":2,"name":"node3","addr":"192.168.216.130:6789/0","public_addr":"192.168.216.1 30:6789/0"}]}}

9

10

11

12 #查看 mon 映射信息

13 [root@node1 ~]# ceph mon dump

14 dumped monmap epoch 3

15 epoch 3

16 fsid 49046d3e-027a-4cc6-a602-f2375f49e584

17 last_changed 2019-06-15 17:23:26.

18 created 2019-06-15 17:15:10.

19 0: 192.168.216.128:6789/0 mon.node2

20 1: 192.168.216.129:6789/0 mon.node1

21 2: 192.168.216.130:6789/0 mon.node3

22

23

24 #查看 mon 详细状态

25 [root@node1 ~]# ceph daemon mon.node1 mon_status 26 {

27 "name": "node1",

28 "rank": 1,

29 "state": "peon",

30 "election_epoch": 780,

31 "quorum": [ 32 0,

33 1,

34 2

35 ],

36 "features": {

37 "required_con": "",

38 "required_mon": [

39 "kraken",

40 "luminous",

41 "mimic",

42 "osdmap-prune" 43 ],

44 "quorum_con": "",

45 "quorum_mon": [

46 "kraken",

47 "luminous",

48

49

50 ]

51 },

"mimic", "osdmap-prune"

52 "outside_quorum": [],

53 "extra_probe_peers": [],

54 "sync_provider": [],

55 "monmap": {

56 "epoch": 3,

57 "fsid": "49046d3e-027a-4cc6-a602-f2375f49e584",

58 "modified": "2019-06-15 17:23:26.",

59 "created": "2019-06-15 17:15:10.",

60 "features": {

61 "persistent": [

62 "kraken",

63 "luminous",

64 "mimic",

65 "osdmap-prune"

66 ],

67 "optional": [] 68 },

69 "mons": [ 70 {

71 "rank": 0,

72 "name": "node2",

73 "addr": "192.168.216.128:6789/0",

74 "public_addr": "192.168.216.128:6789/0"

75 },

76 {

77 "rank": 1,

78 "name": "node1",

79 "addr": "192.168.216.129:6789/0",

80 "public_addr": "192.168.216.129:6789/0"

81 },

82 {

83 "rank": 2,

84 "name": "node3",

85 "addr": "192.168.216.130:6789/0",

86 "public_addr": "192.168.216.130:6789/0"

87 }

88 ]

89 },

90 "feature_map": { 91 "mon": [

92 {

93 "features": "0x3ffddff8ffacfffb",

94 "release": "luminous",

95 "num": 1

96 }

97 ],

98 "osd": [

99 {

100 "features": "0x3ffddff8ffacfffb",

如果集群不健康,可能的错误与排错方法如下:

 

 

 

 

解决方法:

 

如果还不可以，尝试下面方法:

 

 

第6步: 创建mgr(管理)

ceph luminous版本中新增加了一个组件： Ceph Manager Daemon，简称ceph-mgr。 该组件的主要作用是分担和扩展monitor的部分功能，减轻monitor的负担，让更好地管理ceph存储系统。

创建一个mgr

 

添加多个mgr可以实现HA

 

第7步: 创建osd(存储盘)

列表所有节点的磁盘,都有sda和sdb两个盘,sdb为我们要加入分布式存储的盘

查看ceph osd各种状态

 

1 #查看 osd 运行状态

2 [root@node1 ~]# ceph osd stat

3 3 osds: 3 up, 3 in; epoch: e40

4 #e40表示osdmap的版本5

6 #查看 osd 映射信息

7 [root@node1 ~]# ceph osd dump

8 epoch 40

9 fsid 49046d3e-027a-4cc6-a602-f2375f49e584

10 created 2019-06-15 17:15:11.006438

11 modified 2019-06-16 07:17:52.

12 flags sortbitwise,recovery_deletes,purged_snapdirs

13 crush_version 7

14 full_ratio 0.95

15 backfillfull_ratio 0.9

16 nearfull_ratio 0.85

17 require_min_compat_client jewel

18 min_compat_client jewel

19 require_osd_release mimic

20 pool 4 'test_pool' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 128 pgp_num 128 last_change 38 flags hashpspool stripe_width 0

21 max_osd 3

22 osd.0 up in weight 1 up_from 30 up_thru 38 down_at 28 last_clean_interval [16,27) 192.168.216.129:6800/7318 192.168.216.129:6801/7318 192.168.216.129:6802/7318 192.168.216.129:6803/7318 exists,up d0a39465-cf7b-43ad-b887-681daa

23 osd.1 up in weight 1 up_from 30 up_thru 38 down_at 29 last_clean_interval [16,28) 192.168.216.128:6800/7316 192.168.216.128:6801/7316 192.168.216.128:6802/7316 192.168.216.128:6803/7316 exists,up b2e16b5a-48a3-4a60-8d93-c6fc0

24 osd.2 up in weight 1 up_from 32 up_thru 38 down_at 31 last_clean_interval [15,28) 192.168.216.130:6800/7317 192.168.216.130:6801/7317 192.168.216.130:6802/7317 192.168.216.130:6803/7317 exists,up 534a8f09-2dc0-4d68-8f5a-d9e095cce98d

25

26 #查看数据延迟

27 [root@node1 ~]# ceph osd perf

28 osd commit_latency(ms) apply_latency(ms) 29 2 0 0

30 1 0 0

31 0 0 0

32

33 #详细列出集群每块磁盘的使用情况

34 [root@node1 ~]# ceph osd df

35 ID CLASS WEIGHT REWEIGHT SIZE USE AVAIL %USE VAR PGS

2.6 原生数据存取

下面先用原生的object存取过程来演示一下：

要实现object存取需要创建一个pool,创建pool要先分配PG。

为了减少用户数据在OSD中的metadata数据量,  CEPH在用户数据和OSD之间加了一层Placement  Group(实际上是POOL, 逻辑划分), 即用户数据存在PG中, 而PG则存在POOL中, POOL则包含了一些OSD, 以及一些对象属性(如复制多少份)。

PG全称是placement     groups，它是ceph的逻辑存储单元。在数据存储到ceph时，先打散成一系列对象，再结合基于对象名的哈希操作、复制级别、PG数量，产生目标PG号。根据复制级别的不同，每个PG在不同的OSD上进行复制 和分发。

可以把PG想象成存储了多个对象的逻辑容器，这个容器映射到多个具体的OSD。

PG存在的意义是提高ceph存储系统的性能和扩展性。

2.6.1 创建pool

 

 

 

 

 

上传一个文件试试

注意

2.6.2 删除pool

 

 

2.6.3 原生数据存储过程

2.6.3.1 创建文件

2.6.3.2 创建存储池

2.6.3.3 上传文件

2.6.3.4 查看对象状态

2.6.3.5 查找存放数据的OSD及数据

2.6.3.6 查看PG状态

2.7 Ceph文件存储

要运行Ceph文件系统,你必须先装起至少带一个mds的Ceph存储集群.

Ceph MDS: 为Ceph文件存储类型存放元数据metadata(也就是说,Ceph块设备和Ceph 对象存储不使用MDS)。

2.7.1 创建文件存储并使用

第1步: 在node1部署节点上同步配置文件,并创建mds

第2步: 一个Ceph文件系统需要至少两个RADOS存储池，一个用于数据，一个用于元数据。所以我们创建它们。

第3步: 创建Ceph文件系统,并确认客户端访问的节点

第4步: 在node3(上面查看是node3为up状态)上创建客户端挂载需要的验证key文件,并传给客户端

ceph默认启用了cephx认证,要求客户端的挂载必须要用户名和密码验证

第5步: 在node1上部署client节点

第6步: 在客户端安装ceph-fuse,并使用node3产生的key文件进行挂载

第7步: 在客户端读写测试

练习: 请自行再加一个客户端挂载(也可以直接使用node3模拟客户端)，测试两个客户端是否能实现同读同写?

可能的问题:

 

 

解决方法: 在node1,node2,node3上重启osd服务

 

 

 

 

2.7.2 删除文件存储

第1步: 在客户端上删除数据,并umount所有挂载

第2步: 停掉所有节点的mds(只有停掉mds才能删除文件存储)

第3步: 回到OSD存储端删除

第4步: 可以将mds服务再次启动(可选项,如果以后还要用文件存储就需要启动)

2.8 Ceph块存储

2.8.1 创建块存储并使用

第1步: 在node1部署节点上同步文件到所有节点(包括client)

第2步:建立存储池,并初始化

第3步:创建一个存储卷(我这里卷名为volume1,大小为500M)

第4步: 将创建的卷映射成块设备

第5步: 块存储使用

2.8.2 块存储扩容与裁减

在线扩容

块存储裁减

不能在线裁减.裁减后需重新格式化再挂载，所以请提前备份好数据.

2.8.3 删除块存储

 

 

2.9 Ceph对象存储

2.9.1 测试ceph对象网关的连接

第1步: 在node1上创建rgw(对象存储网关)

第2步: 在客户端测试连接对象网关

安装python测试工具

编写一个python程序测试

2.9.2 S3连接ceph对象网关

AmazonS3是一种面向Internet的对象存储服务.我们这里可以使用s3工具连接ceph的对象存储进行操作 第1步: 客户端安装s3cmd工具,并编写ceph连接配置文件

第2步: 命令测试

2.10 ceph dashboard

通过ceph dashboard完成对ceph存储系统可视化监视。

第1步：查看mgr版本及集群状态

第2步：查看mgr module帮助及模块信息

 

"name": "influx", "can_run": false,

"error_string": "influxdb python module not found"

},

{

"name": "localpool", "can_run": true, "error_string": ""

},

{

"name": "prometheus", "can_run": true, "error_string": ""

},

{

"name": "selftest", "can_run": true, "error_string": ""

},

{

"name": "smart", "can_run": true, "error_string": ""

},

{

"name": "telegraf", "can_run": true, "error_string": ""

},

{

"name": "telemetry", "can_run": true, "error_string": ""

},

{

"name": "zabbix", "can_run": true, "error_string": ""

}

]

第3步：开启dashboard模块

5 {

6 "enabled_modules": [

7 "balancer",

8 "crash",

9 "dashboard",

10 "iostat",

11 "restful",

12 "status"

13 ],

14 "disabled_modules": [ 15 {

16 "name": "hello",

17 "can_run": true,

18 "error_string": "" 19 },

20 {

21 "name": "influx",

22 "can_run": false,

23 "error_string": "influxdb python module not found" 24 },

25 {

26 "name": "localpool",

27 "can_run": true,

28 "error_string": "" 29 },

30 {

31 "name": "prometheus",

32 "can_run": true,

33 "error_string": "" 34 },

35 {

36 "name": "selftest",

37 "can_run": true,

38 "error_string": "" 39 },

40 {

41 "name": "smart",

42 "can_run": true,

43 "error_string": "" 44 },

45 {

46 "name": "telegraf",

47 "can_run": true,

48 "error_string": "" 49 },

50 {

51 "name": "telemetry",

52 "can_run": true,

53 "error_string": "" 54 },

55 {

56 "name": "zabbix",

57 "can_run": true,

第4步：创建自签名证书

第5步：生成key pair，并配置给ceph mgr

第6步：在ceph active mgr节点上配置mgr services

使用dashboard服务，主要配置dashboard使用的IP及Port

第7步：设置访问web页面用户名和密码

第8步：若需通过外网访问，则在有外网IP的机器上配置nginx服务做https转发(不需要，可乎略)

第9步：通过本机或其它主机访问

打卡要求

 

1. 设计Ceph实验过程

 

1. 对象存储概念

2. Ceph工作原理及实现

 

1. 通过Xmind文档实现上述课程内容总结，并发送至@.com邮箱邮件标题：姓名-课程名称总结

邮件正文：可表达总结心得

邮件附件：将课程内容总结以附件形式发送

 

1. 通过Ceph官网学习更多Ceph相关技术及思想。