Hexo
0%

Posted on Edited on

什么是OSD blacklist，如何处理？

环境

Red Hat Ceph Storage

问题

我正在运行ceph osd dump命令，它确实列出了blacklist items：

1
2
3
# ceph osd dump
[...]
blacklist 10.37.192.139:0/1308721908 expires 2019-02-27 10:10:52.049084

这是什么意思，我该如何解决？

决议

尽管有一些控制命令可删除blacklist entries（例如ceph osd blacklist rm ADDRESS[:source_port]），但blacklists通常会自动维护，无需手动干预。因此，您无需采取任何措施。如有疑问，请联系Red Hat支持。

根本原因

blacklist最常用于CephFS场景中，以防止滞后的元数据服务器对OSD上的数据进行不良更改。

诊断步骤

1
2
3
# ceph osd blacklist ls
listed 1 entries
10.37.192.139:0/1308721908 2019-02-27 10:10:52.049084

该解决方案是Red Hat快速发布计划的一部分，提供了Red Hat工程师在为客户提供支持时创建的庞大解决方案库。 为了使您立即获得所需的知识，这些文章可能以未经编辑的原始形式出现。

CEPH FILESYSTEM CLIENT EVICTION（CEPH文件系统客户端驱逐）

当文件系统客户端无响应或行为异常时，可能有必要强制终止其对文件系统的访问。 此过程称为eviction（驱逐）。

驱逐CephFS客户端会阻止其与MDS daemons和OSD daemons进一步通信。 如果客户端正在对文件系统进行buffered IO，则所有未刷新的数据都将丢失。

客户端可以自动退出（如果无法及时与MDS通信），也可以手动退出（由系统管理员）。

客户端驱逐过程适用于各种客户端，包括FUSE mounts，kernel mounts，nfs-ganesha gateways以及任何使用libcephfs的进程。

AUTOMATIC CLIENT EVICTION（自动客户端逐出）

在三种情况下，可能会自动将客户驱逐：

  • 在active MDS daemon上，如果客户端在session_autoclose（文件系统变量）秒（默认为300秒）以上未与MDS通信，则它将自动被驱逐。

  • 在active MDS daemon上，如果客户端在mds_cap_revoke_eviction_timeout（配置选项）秒内未响应cap revoke messages。 默认情况下禁用。

  • 在MDS启动期间（包括故障转移时），MDS称为reconnect的状态。 在此状态期间，它将等待所有客户端连接到新的MDS daemon。 如果客户端未在时间窗口内这样做（mds_reconnect_timeout，默认为45秒），则将其驱逐。

如果出现以上任何一种情况，warning message将发送到cluster log。

MANUAL CLIENT EVICTION（手动客户端驱逐）

有时，管理员可能希望手动驱逐客户端。 如果客户端死亡，并且管理员不想等待其session超时；或者，如果客户端行为异常并且管理员无权访问客户端节点来卸载它。

首先检查客户列表：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
ceph tell mds.0 client ls

[
    {
        "id": 4305,
        "num_leases": 0,
        "num_caps": 3,
        "state": "open",
        "replay_requests": 0,
        "completed_requests": 0,
        "reconnecting": false,
        "inst": "client.4305 172.21.9.34:0/422650892",
        "client_metadata": {
            "ceph_sha1": "ae81e49d369875ac8b569ff3e3c456a31b8f3af5",
            "ceph_version": "ceph version 12.0.0-1934-gae81e49 (ae81e49d369875ac8b569ff3e3c456a31b8f3af5)",
            "entity_id": "0",
            "hostname": "senta04",
            "mount_point": "/tmp/tmpcMpF1b/mnt.0",
            "pid": "29377",
            "root": "/"
        }
    }
]

一旦识别出要逐出的客户机，就可以使用其唯一ID或各种其他属性来识别它：

1
2
3
# These all work
ceph tell mds.0 client evict id=4305
ceph tell mds.0 client evict client_metadata.=4305

ADVANCED: UN-BLACKLISTING A CLIENT（进阶：取消blacklist客户）

通常，列入blacklist的客户端可能无法重新连接到服务器：必须先将其unmount，然后再重新mount。

但是，在某些情况下，允许被驱逐的客户端尝试重新连接可能会很有用。

由于CephFS使用RADOS OSD blacklist控制客户端驱逐，因此可以通过从blacklist中删除CephFS客户端来重新连接它们：

1
2
3
4
5
6
$ ceph osd blacklist ls
listed 1 entries
127.0.0.1:0/3710147553 2018-03-19 11:32:24.716146

$ ceph osd blacklist rm 127.0.0.1:0/3710147553
un-blacklisting 127.0.0.1:0/3710147553

如果其他客户端访问了列入blacklist的客户端正在buffered IO的文件，则这样做可能会使数据完整性受到威胁。 也不能保证产生一个功能完备的客户端 — 在驱逐后恢复完全健康的客户端的最佳方法是unmount客户端并重新mount。

如果您尝试以这种方式重新连接客户端，则在FUSE客户端中将client_reconnect_stale设置为true，以提示客户端尝试重新连接。

ADVANCED: CONFIGURING BLACKLISTING（进阶：配置blacklist）

如果由于客户端主机速度慢或网络不可靠而频繁驱逐客户端，并且您无法解决根本问题，那么您可能希望要求MDS的严格性降低。

可以通过放弃其MDS sessions来响应慢速客户端，但允许他们重新打开sessions并允许他们继续与OSD对话。 要启用此模式，请在MDS节点上将mds_session_blacklist_on_timeout设置为false。

对于手动驱逐的等效行为，请将mds_session_blacklist_on_evict设置为false。

请注意，如果禁用了blacklist，则驱逐客户端只会对您发送命令的MDS产生影响。 在具有multiple active MDS daemons的系统上，您需要向每个active daemon发送驱逐命令。 启用blacklist（默认设置）后，仅将驱逐命令发送到单个MDS就足够了，因为blacklist会将其传播到其他MDS。

BACKGROUND: BLACKLISTING AND OSD EPOCH BARRIER（背景：blacklist和OSD epoch barrier）

在将客户端列入blacklist之后，有必要确保其他客户端和MDS daemons在尝试访问被列入blacklist的客户端可能已访问的任何数据对象之前，具有最新的OSDMap（包括blacklist entry）。

使用内部的”osdmap epoch barrier”机制可以确保这一点。

barrier的目的是确保当我们分发任何允许touching相同 RADOS objects的功能时，分发的客户端必须具有最新的 OSD map，不与已cancel的操作（来自 ENOSPC）或blacklist客户端（逐出）进行竞争。

更具体地说，设置epoch barrier的情况是：

  • Client eviction — 客户端驱逐（客户端被列入blacklist，其他客户端必须等待post-blacklist epoch后才能touch相同的objects）。
  • 客户端中的OSD map full flag handling（客户端可以从pre-full epoch取消某些OSD操作，因此其他客户端必须等到full epoch或更晚才能touching相同的objects）。
  • MDS启动，因为我们不持续维护barrier epoch，因此，必须假定重新启动后始终需要最新的OSD map。

请注意，这是简单的global value。 我们可以在每个inode的基础上进行维护。 但是我们没有，因为：

  • 它将更加复杂。
  • 每个inode将使用额外的4个字节的内存。
  • 因为几乎每个人都拥有最新的OSD map，所以效率不会更高。 而且，在大多数情况下，每个人都会轻而易举地克服这一barrier，而不是waiting。
  • 在极少数情况下遇到barrier，因此很少会看到每个inode粒度带来好处。

epoch barrier与所有capability messages一起发送，并指示message的接收者避免在看到OSD epoch之前向OSD发送更多的RADOS操作。 这主要适用于客户端（将其数据直接写到文件中），但也适用于MDS，因为诸如文件大小probing和文件删除之类的操作是直接从MDS完成的。

blacklist相关命令

1、从blacklist中添加（可选项，直到<expire>秒后）或删除<addr>，默认3600秒

1
osd blacklist add|rm <EntityAddr> {<float[0.0-]>}                   add (optionally until <expire> seconds from now) or remove <addr> from blacklist

实验1，添加删除blacklist测试

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[root@ceph3 ~]# ceph osd blacklist add 10.20.10.28
blacklisting 10.20.10.28:0/0 until 2019-11-13 12:55:53.700776 (3600 sec)
[root@ceph3 ~]# ceph osd blacklist add 10.20.10.13 6000
blacklisting 10.20.10.13:0/0 until 2019-11-13 13:36:16.575894 (6000 sec)

[root@ceph3 ~]# ceph osd blacklist ls
listed 2 entries
10.20.10.13:0/0 2019-11-13 13:36:16.575894
10.20.10.28:0/0 2019-11-13 12:55:53.700776


[root@ceph3 ~]# ceph osd blacklist ls
listed 1 entries
10.20.10.28:0/0 2019-11-13 10:23:00.029669

实验2，当client在blacklist中时，在client端尝试mount cephfs（ceph-client 10.20.10.2）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
1、将ceph-client加入blacklist
[root@ceph1 ~]# ceph osd blacklist add 10.20.10.2
[root@ceph1 ~]# ceph osd blacklist ls
listed 1 entries
10.20.10.2:0/0 2019-11-13 15:42:54.260358

2、ceph-client尝试mount cephfs
[root@ceph-client ~]# ceph-fuse /root/ceph-fuse/ --verbose
ceph-fuse[1664]: starting ceph client
2019-11-13 14:45:18.902688 7f8f3b0db0c0 -1 init, newargv = 0x55c15933c000 newargc=10
ceph-fuse[1664]: ceph mount failed with (1) Operation not permitted

3、将ceph-client从blacklist中删除
[root@ceph1 ~]# ceph osd blacklist rm 10.20.10.2
un-blacklisting 10.20.10.2:0/0

[root@ceph-client ~]# ceph-fuse /root/ceph-fuse/ 
ceph-fuse[1704]: starting ceph client
2019-11-13 14:49:16.400939 7f9326c7c0c0 -1 init, newargv = 0x557665de4ea0 newargc=9
ceph-fuse[1704]: starting fuse

[root@ceph-client ~]# df -Th
ceph-fuse      fuse.ceph-fuse   93G     0   93G   0% /root/ceph-fuse

2、清除所有列入blacklist的客户端

1
osd blacklist clear                   clear all blacklisted clients

实验1

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[root@ceph3 ~]# ceph osd blacklist add 10.20.10.28
blacklisting 10.20.10.28:0/0 until 2019-11-13 12:53:48.463948 (3600 sec)
[root@ceph3 ~]# ceph osd blacklist add 10.20.10.13
blacklisting 10.20.10.13:0/0 until 2019-11-13 12:53:56.846733 (3600 sec)

[root@ceph3 ~]# ceph osd blacklist ls
listed 2 entries
10.20.10.13:0/0 2019-11-13 12:53:56.846733
10.20.10.28:0/0 2019-11-13 12:53:48.463948

[root@ceph3 ~]# ceph osd blacklist clear
 removed all blacklist entries

[root@ceph3 ~]# ceph osd blacklist ls
listed 0 entries

3、显示列入blacklist的客户端

1
osd blacklist ls --format json                   show blacklisted clients

实验1

1
2
3
4
5
6
[root@ceph1 ~]# ceph osd blacklist ls --format json
listed 1 entries

[{"addr":"10.20.10.2:0/0","until":"2019-11-13 17:10:56.217959"}]

/0 表示：AsyncMessenger stuff approximately unique ID set by the Constructor for use in entity_addr_t

4、如果客户端在session_autoclose <value>秒（默认为300秒）以上未与MDS通信，则它将自动被驱逐。

1
fs set <fs_name> max_mds|max_file_size|allow_new_snaps|inline_data|cluster_down|allow_multimds|allow_dirfrags| balancer|standby_count_wanted|session_timeout|session_autoclose <val> {<confirm>}			set fs parameter <var> to <val>

实验1

1
[root@ceph1 ~]# ceph fs set cephfs session_autoclose 400

5、获取有关一个文件系统的信息

1
ceph fs get <fs_name> --format json

实验1

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
[root@ceph1 ~]# ceph fs get cephfs --format json
{
	"mdsmap": {
		"epoch": 19,
		"flags": 12,
		"ever_allowed_features": 0,
		"explicitly_allowed_features": 0,
		"created": "2019-11-11 11:16:05.316461",
		"modified": "2019-11-13 15:59:17.551876",
		"tableserver": 0,
		"root": 0,
		"session_timeout": 60,
		"session_autoclose": 400,
		"max_file_size": 1099511627776,
		"last_failure": 0,
		"last_failure_osd_epoch": 104,
		"compat": {
			"compat": {},
			"ro_compat": {},
			"incompat": {
				"feature_1": "base v0.20",
				"feature_2": "client writeable ranges",
				"feature_3": "default file layouts on dirs",
				"feature_4": "dir inode in separate object",
				"feature_5": "mds uses versioned encoding",
				"feature_6": "dirfrag is stored in omap",
				"feature_8": "no anchor table",
				"feature_9": "file layout v2"
			}
		},
		"max_mds": 1,
		"in": [0],
		"up": {
			"mds_0": 4335
		},
		"failed": [],
		"damaged": [],
		"stopped": [],
		"info": {
			"gid_4335": {
				"gid": 4335,
				"name": "ceph2",
				"rank": 0,
				"incarnation": 14,
				"state": "up:active",
				"state_seq": 41535,
				"addr": "10.20.10.13:6804/622620898",
				"standby_for_rank": 0,
				"standby_for_fscid": -1,
				"standby_for_name": "",
				"standby_replay": true,
				"export_targets": [],
				"features": 4611087853746454523
			},
			"gid_4456": {
				"gid": 4456,
				"name": "ceph3",
				"rank": 0,
				"incarnation": 0,
				"state": "up:standby-replay",
				"state_seq": 2,
				"addr": "10.20.10.25:6805/1639008809",
				"standby_for_rank": 0,
				"standby_for_fscid": -1,
				"standby_for_name": "",
				"standby_replay": true,
				"export_targets": [],
				"features": 4611087853746454523
			}
		},
		"data_pools": [6],
		"metadata_pool": 7,
		"enabled": true,
		"fs_name": "cephfs",
		"balancer": "",
		"standby_count_wanted": 1
	},
	"id": 1
}

blacklist相关配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
MON相关配置
	客户端blacklist entries保留在OSD map中的持续时间（以秒为单位）
    Option("mon_osd_blacklist_default_expire", Option::TYPE_FLOAT, Option::LEVEL_ADVANCED)
    .set_default(1_hr)
    .add_service("mon")
    .set_description("Duration in seconds that blacklist entries for clients remain in the OSD map"),

	MDS daemons的blacklist entries保留在OSD map中的持续时间（以秒为单位）
    Option("mon_mds_blacklist_interval", Option::TYPE_FLOAT, Option::LEVEL_DEV)
    .set_default(1_day)
    .set_min(1_hr)
    .add_service("mon")
    .set_description("Duration in seconds that blacklist entries for MDS daemons remain in the OSD map"),

RBD相关配置
	是否将损坏锁的客户端列入blacklist
    Option("rbd_blacklist_on_break_lock", Option::TYPE_BOOL, Option::LEVEL_ADVANCED)
    .set_default(true)
    .set_description("whether to blacklist clients whose lock was broken"),

	blacklist的秒数 - OSD 默认值为 0
    Option("rbd_blacklist_expire_seconds", Option::TYPE_UINT, Option::LEVEL_ADVANCED)
    .set_default(0)
    .set_description("number of seconds to blacklist - set to 0 for OSD default"),

MDS相关配置
	是否将sessions已过期的客户端列入blacklist
    Option("mds_session_blacklist_on_timeout", Option::TYPE_BOOL, Option::LEVEL_ADVANCED)
    .set_default(true)
    .set_description("blacklist clients whose sessions have become stale"),

	是否将被逐出的客户端列入blacklist
    Option("mds_session_blacklist_on_evict", Option::TYPE_BOOL, Option::LEVEL_ADVANCED)
    .set_default(true)
    .set_description("blacklist clients that have been evicted"),

	数秒后，没有响应MDS的“cap revoke messages”的客户端将被驱逐。（默认为0，表示关闭该功能）
    Option("mds_cap_revoke_eviction_timeout", Option::TYPE_FLOAT, Option::LEVEL_ADVANCED)
     .set_default(0)
     .set_description("number of seconds after which clients which have not responded to cap revoke messages by the MDS are evicted."),

	MDS重新连接恢复状态期间等待客户端重新连接的超时时间（以秒为单位）
    Option("mds_reconnect_timeout", Option::TYPE_FLOAT, Option::LEVEL_ADVANCED)
    .set_default(45)
    .set_description("timeout in seconds to wait for clients to reconnect during MDS reconnect recovery state"),

参考资料

【1】https://access.redhat.com/solutions/3944931

【2】https://docs.ceph.com/docs/mimic/cephfs/eviction/

接口（CLI后加–format json可以以json格式输出结果）

1、添加客户端到blacklist（add (optionally until <expire> seconds from now)<addr>from blacklist）

1
osd blacklist add <EntityAddr> {<float[0.0-]>}

2、从blacklist中删除客户端（remove <addr> from blacklist）

1
osd blacklist rm <EntityAddr>

3、清除所有列入blacklist的客户端（clear all blacklisted clients）

1
osd blacklist clear

4、显示列入blacklist的客户端（show blacklisted clients）

1
osd blacklist ls

5、设置session_autoclose，客户端在指定秒数未与MDS通信，则驱逐接口，加入blacklist（set fs parameter <var> to <val>）

1
fs set <fs_name> session_autoclose <val>

6、获取有关一个文件系统的session_autoclose信息

1
ceph fs get <fs_name>

Posted on Edited on

Linuxcast学习笔记，视频地址：https://www.youtube.com/watch?v=eV4InZop--0

udev是什么

udev是动态管理设备的机制（/dev/目录下的设备）。udev允许我们自己写一些rule配置文件来控制udev默认的行为动作。默认配置文件在/etc/udev/目录下，在/etc/udev/rules.d/下为默认rule。如70-persistent-net.rules文件，udev在工作时，每次检查/etc/udev/rules.d/目录下的配置文件，并且按照数字的顺序来加载并应用这些配置。

udev允许我们在一个设备连接到计算机的时候，或者已经连接上，或者卸载的时候执行一些特殊的动作。（设备连接时、设备连接上、设备断开时）

如何使用udev修改设备默认名称

如果我们想修改一个设备，那么我们需要唯一的定位一个设备，通过udevadm命令。通常serial（串号）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
[root@ceph2 ~]# udevadm info -a -n /dev/vdc

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/pci0000:00/0000:00:09.0/virtio4/block/vdc':
    KERNEL=="vdc"
    SUBSYSTEM=="block"
    DRIVER==""
    ATTR{ro}=="0"
    ATTR{size}=="104857600"
    ATTR{stat}=="    7223       11   474136    19244   400088    30660  1866945   871549        0   840441   872404"
    ATTR{cache_type}=="write back"
    ATTR{range}=="16"
    ATTR{discard_alignment}=="0"
    ATTR{ext_range}=="256"
    ATTR{serial}=="e850ae75-fcb2-4432-a"
    ATTR{alignment_offset}=="0"
    ATTR{inflight}=="       0        0"
    ATTR{removable}=="0"
    ATTR{capability}=="50"

  looking at parent device '/devices/pci0000:00/0000:00:09.0/virtio4':
    KERNELS=="virtio4"
    SUBSYSTEMS=="virtio"
    DRIVERS=="virtio_blk"
    ATTRS{device}=="0x0002"
    ATTRS{features}=="0010101001110000000000000000110010000000000000000000000000000000"
    ATTRS{status}=="0x0000000f"
    ATTRS{vendor}=="0x1af4"

  looking at parent device '/devices/pci0000:00/0000:00:09.0':
    KERNELS=="0000:00:09.0"
    SUBSYSTEMS=="pci"
    DRIVERS=="virtio-pci"
    ATTRS{irq}=="10"
    ATTRS{subsystem_vendor}=="0x1af4"
    ATTRS{broken_parity_status}=="0"
    ATTRS{class}=="0x010000"
    ATTRS{driver_override}=="(null)"
    ATTRS{consistent_dma_mask_bits}=="64"
    ATTRS{dma_mask_bits}=="64"
    ATTRS{local_cpus}=="f"
    ATTRS{device}=="0x1001"
    ATTRS{enable}=="1"
    ATTRS{msi_bus}==""
    ATTRS{local_cpulist}=="0-3"
    ATTRS{vendor}=="0x1af4"
    ATTRS{subsystem_device}=="0x0002"
    ATTRS{numa_node}=="-1"
    ATTRS{d3cold_allowed}=="0"

  looking at parent device '/devices/pci0000:00':
    KERNELS=="pci0000:00"
    SUBSYSTEMS==""
    DRIVERS==""

在/etc/udev/rules.d/下创建rule，99-linuxcast.rules，编辑规则。

1
KERNEL=="sd*", ATTR{serial}=="e850ae75-fcb2-4432-a", NAME="yujiangvdc%n"

KERNEL意思是内核识别出来这个设备是什么名字，两个等号==是做比较，一个等号=是赋值。

通过KERNEL与ATTR{serial}就可以唯一定位到一个设备，要把这个设备修改为其他名字用NAME，udev会自动把%n替换成分区号。

Posted on Edited on

官方原文

参考1

从Luminous之前的版本进行升级（比如jewel版本）

1
2
3
4
5
6
7
8
必须先升级到Luminous（12.2.z），然后再尝试升级到Nautilus。 另外，您的集群必须在运行Luminous的同时至少完成了所有PG的一次scrub，并在OSD map中设置了recovery_deletes和purged_snapdirs flags。

[root@ceph1 ~]# ceph osd dump | grep ^flags
flags sortbitwise,recovery_deletes,purged_snapdirs

recovery_deletes flags：Ceph现在在recovery过程中处理delete操作，而不是在peering过程中。以前，将down或out超过15分钟的OSD带回到群集中会导致placement group peering时间延长。peering过程需要很长时间才能完成，因为delete操作是在合并placement group日志作为peering过程的一部分时内联处理的。结果，对处于peering状态的placement group的操作被blocked。通过此更新，Ceph可以在正常recovery过程中而不是peering过程中处理delete操作。结果可以使peering过程更快完成，并且操作不再blocked。（This was fixed with the help of Red Hat Ceph Storage feature request #1452780 and this was released in 2.4 errata version 10.2.7-32.el7cp.）

purged_snapdirs flags：一旦snapsets全部转换，则设置purged_snapdirs OSDMap flags，这样可以更轻松地测试upgrade + conversion是否已完成。特别是，micim+将能够更简单地测试该flags，而无需等待完整的PG统计信息来知道升级到luminous以外的版本是否安全。

注意

1
2
3
1、在从Luminous升级到Nautilus的过程中，将monitors升级到Nautilus后，将无法使用Luminous ceph-osd daemon创建新的OSD。避免在升级过程中添加或替换任何OSD。
2、避免在升级过程中创建任何RADOS pools。
3、您可以使用ceph version(s)命令在每个阶段监视升级进度，该命令将告诉您每种ceph daemon正在运行的ceph版本。

自研管理平台用到的接口，对比输出是否有修改，以免影响前台功能

Ceph节点升级过程

1、确认OSD map包含recovery_deletes和purged_snapdirs flags（否则，将导致您的monitor daemons在启动时拒绝加入quorum，从而使其无法运行）

1
2
3
4
5
执行命令：ceph osd dump | grep ^flags
命令输出：flags sortbitwise,recovery_deletes,purged_snapdirs

如果没有recovery_deletes和purged_snapdirs flags需要手动触发pg scrub，并等待大约24-48小时（根据数据量评估）
执行命令：ceph pg dump pgs_brief | cut -d " " -f 1 | xargs -n1 ceph pg scrub

2、确保集群稳定，集群状态HEALTH_OK，没有down掉的OSD或无法恢复的OSD。

1
2
3
4
5
6
7
8
执行命令：ceph health detail
命令输出：HEALTH_OK

执行命令：ceph osd tree | grep down
命令输出：空

执行命令：ceph osd tree | grep out
命令输出：空

3、设置noout flags

1
2
3
4
5
6
7
执行命令：ceph osd set noout
命令输出：noout is set

执行命令：ceph health detail
命令输出：
HEALTH_WARN noout flag(s) set
OSDMAP_FLAGS noout flag(s) set

4、配置centos ceph 14 Luminous mirror

1

5、升级monitors（通过安装新ceph packages并重新启动monitor daemons来升级monitors）

在每个monitors主机上执行：

1
2
3
4
5
6
7
5.1、安装monitor packages
执行命令：yum install ceph-mon
命令输出：提示安装ceph-mon以及依赖

5.2、重启ceph monitor服务
执行命令：systemctl restart ceph-mon.target
命令输出：空

monitors启动之后，查找nautilus字符串来验证monitor升级是否完成。确保有min_mon_release 14 (nautilus)字样，如果没有说明尚未升级和重启monitor。

1
2
3
4
执行命令：ceph mon dump | grep min_mon_release
命令输出：
dumped monmap epoch 2
min_mon_release 14 (nautilus)

6、升级ceph-mgr（通过安装新ceph packages并重新启动ceph-mgr daemons来升级ceph-mgr）

如果使用Ceph Dashboard需要安装ceph-mgr-dashboard package。

在每个ceph-mgr主机上执行：

1
2
3
4
5
6
7
8
9
10
11
6.1、安装ceph-mgr packages
执行命令：yum install ceph-mgr
命令输出：提示安装ceph-mgr以及依赖

6.2、安装ceph-mgr-dashboard packages
执行命令：yum install ceph-mgr-dashboard
命令输出：提示安装ceph-mgr-dashboard以及依赖

6.3、重启ceph mgr服务
执行命令：systemctl restart ceph-mgr.target
命令输出：空

通过ceph -s验证ceph-mgr daemons是否正在运行（确保mgr状态active，standbys mgr加入）。

1
2
3
4
5
6
7
执行命令：ceph -s
命令输出：
...
  services:
    mon: 3 daemons, quorum community-ceph-2,community-ceph-3,community-ceph-1 (age 25m)
    mgr: community-ceph-2(active, since 3d), standbys: community-ceph-3, community-ceph-1
...

7、升级ceph-osd（通过安装新ceph packages并重新启动ceph-osd daemons来升级ceph-osd）

在每个ceph-osd主机上执行：

1
2
3
4
5
6
7
7.1、安装ceph-osd packages
执行命令：yum install ceph-osd
命令输出：提示安装ceph-osd以及依赖

7.2、重启ceph osd服务
执行命令：systemctl restart ceph-osd.target
命令输出：空

查看OSD升级的进度

1
2
3
4
5
6
执行命令：ceph osd versions
命令输出：
{
   "ceph version 12.2.x (...) luminous (stable)": 2,
   "ceph version 14.2.4 (...) nautilus (stable)": 4,
}

使用ceph-volume接管ceph-disk创建的OSD，在每个OSD主机上执行，执行前确保每个OSD都正在运行，无down或out的OSD：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
1、确保OSD运行正常
执行命令：ceph osd tree | grep down
命令输出：空
执行命令：ceph osd tree | grep out
命令输出：空

2、所有使用ceph-disk创建的并正在运行的OSDs，从OSD data partition或directory中捕获元数据
执行命令：ceph-volume simple scan
命令输出：

执行命令后，会生成类似/etc/ceph/osd/0-ab0a204a-42e3-4a47-ab4c-0888edf429cb.json文件，文件内容为：
{
    "active": "ok", 
    "block": {
        "path": "/dev/disk/by-partuuid/0818811f-d70e-4ff0-91c9-58cd701c9a19", 
        "uuid": "0818811f-d70e-4ff0-91c9-58cd701c9a19"
    }, 
    "block_uuid": "0818811f-d70e-4ff0-91c9-58cd701c9a19", 
    "bluefs": 1, 
    "ceph_fsid": "c4051efa-1997-43ef-8497-fb02bdf08233", 
    "cluster_name": "ceph", 
    "data": {
        "path": "/dev/vdc1", 
        "uuid": "ab0a204a-42e3-4a47-ab4c-0888edf429cb"
    }, 
    "fsid": "ab0a204a-42e3-4a47-ab4c-0888edf429cb", 
    "keyring": "AQB1FLFdXVHVARAARTKkxT1xgrDNU/QECUqdxA==", 
    "kv_backend": "rocksdb", 
    "magic": "ceph osd volume v026", 
    "mkfs_done": "yes", 
    "ready": "ready", 
    "systemd": "", 
    "type": "bluestore", 
    "whoami": 0
}

3、使systemd units可以mount已配置的devices，并启动Ceph OSD
执行命令：ceph-volume simple activate --all
命令输出：
--> activating OSD specified in /etc/ceph/osd/1-fe327306-54a4-4362-870d-92d28cf65e42.json
Running command: ln -snf /dev/vdc2 /var/lib/ceph/osd/ceph-1/block
Running command: chown -R ceph:ceph /dev/vdc2
Running command: systemctl enable ceph-volume@simple-1-fe327306-54a4-4362-870d-92d28cf65e42
Running command: ln -sf /dev/null /etc/systemd/system/ceph-disk@.service
--> All ceph-disk systemd units have been disabled to prevent OSDs getting triggered by UDEV events
Running command: systemctl enable --runtime ceph-osd@1
Running command: systemctl start ceph-osd@1
--> Successfully activated OSD 1 with FSID fe327306-54a4-4362-870d-92d28cf65e42

4、重启每个OSD主机，确认OSD是否开机自启
执行命令：reboot
命令输出：无

8、升级ceph-mds（通过安装新ceph packages并重新启动ceph-mds daemons来升级ceph-mds）

在每个ceph-mds主机上执行：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
记录rank数量，并将ranks数减少到1，通过ceph mds stat命令输出可以查看rank数量。
{0=ceph3=up:active}代表rank数为1，{0=ceph3=up:active,1=ceph2=up:active}代表rank数为2，以此类推。

8.1、查看当前rank数量
执行命令：ceph mds stat
命令输出：cephfs-1/1/1 up  {0=ceph3=up:active}, 2 up:standby
如果rank为2，命令输出为：cephfs-2/2/2 up  {0=ceph3=up:active,1=ceph2=up:active}, 1 up:standby

8.2、查看cephfs名称
执行命令：ceph fs ls
命令输出：name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]

8.3、将ranks数减少到1
执行命令：ceph fs set <fs_name> max_mds 1
命令输出：空

8.4、通过定期检查状态，等待集群停用所有non-zero ranks，当{0=ceph3=up:active}时为已停用所有non-zero ranks
执行命令：ceph status
命令输出：cephfs-1/1/1 up  {0=ceph3=up:active}, 2 up:standby

8.5、使用以下命令使所有standby MDS daemons在适当的主机offline
执行命令：systemctl stop ceph-mds@<daemon_name>
命令输出：空

8.6、确认只有一个MDS处于online，并且cephfs只有一个rank 0
执行命令：ceph status
命令输出：
...
    mds: cephfs-1/1/1 up  {0=ceph3=up:active}
...

8.7、通过安装新packages并重新启动daemon来升级MDS daemon（在每个mds节点上执行）
执行命令：yum install ceph-mds
命令输出：提示安装ceph-mds以及依赖

执行命令：systemctl restart ceph-mds.target
命令输出：空

8.8、重新启动所有已的offline standby MDS daemons
执行命令：systemctl restart ceph-mds.target
命令输出：空

8.9、恢复max_mds原始值
执行命令：ceph fs set <fs_name> max_mds <original_max_mds>
命令输出：空

9、升级ceph-radosgw（通过安装新ceph packages并重新启动ceph-radosgw daemons来升级ceph-radosgw）

在每个ceph-radosgw主机上执行：

1
2
3
4
5
6
7
5.1、安装radosgw packages
执行命令：yum install ceph-radosgw
命令输出：提示安装ceph-radosgw以及依赖

5.2、重启ceph radosgw服务
执行命令：systemctl restart ceph-radosgw.target
命令输出：空

10、启用所有Nautilus的新功能来完成升级

1
2
执行命令：ceph osd require-osd-release nautilus
命令输出：空

11、清除noout flags

1
2
执行命令：ceph osd unset noout
命令输出：noout is unset

12、启用新的 v2 network protocol

1
2
执行命令：ceph mon enable-msgr2
命令输出：空

Client节点升级过程

1、Client节点升级package

1
2
执行命令：yum install ceph-common librados2 librbd1 python-rbd python-rados -y
命令输出：提示安装ceph-common librados2 librbd1 python-rbd python-rados以及依赖

2、Client节点确认升级后的版本

1
2
执行命令：ceph --version
命令输出：ceph version 14.2.4 (75f4de193b3ea58512f204623e6c5a16e6c1e1ba) nautilus (stable)

Ceph端升级后修复

1、Legacy BlueStore stats reporting detected on 6 OSD(s)

问题描述：

​ 使用ceph -s命令查看集群状态时，出现Legacy BlueStore stats reporting detected on 6 OSD(s)

解决办法：

1
2
3
systemctl stop ceph-osd@$OSDID
ceph-bluestore-tool repair –path /var/lib/ceph/osd/ceph-$OSDID
systemctl start ceph-osd@$OSDID

参考资料：

【1】http://lists.ceph.com/pipermail/ceph-users-ceph.com/2019-July/036002.html

关于执行ceph-bluestore-tool repair报错问题确认：https://tracker.ceph.com/issues/42297

2、3 monitors have not enabled msgr2

问题描述：

​ 使用ceph -s命令查看集群状态时，出现 3 monitors have not enabled msgr2

解决办法：

1
2
ceph mon enable-msgr2
systemctl restart ceph-mon@ceph1.service

Posted on Edited on

系统环境

1
2
cat /etc/redhat-release 
CentOS Linux release 7.4.1708 (Core)

samba安装

安装samba

1
2
3
yum install -y samba

samba Version 4.9.1

Ceph KRBD使用samba

1、首先创建pool

1
ceph osd pool create rbd 8

2、在pool中创建rbd

1
2
3
4
5
6
7
8
9
10
11
rbd create --size 10G rbd/rbd-1

# rbd info rbd/rbd-1
rbd image 'rbd-1':
	size 10GiB in 2560 objects
	order 22 (4MiB objects)
	block_name_prefix: rbd_data.10c06b8b4567
	format: 2
	features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
	flags: 
	create_timestamp: Wed Oct 23 10:04:16 2019

3、在linux上创建挂载点

1
mkdir ceph-rbd-1-mountpoint

4、map pool中的rbd到linux

1
2
3
4
5
6
7
8
9
rbd map rbd/rbd-1

# lsmod | grep rbd
rbd                    83733  2 
libceph               306742  1 rbd

# sudo rbd showmapped
id pool image snap device    
0  rbd  rbd-1 -    /dev/rbd0

5、格式化文件系统

1
mkfs.xfs /dev/rbd/rbd/rbd-1

6、mount到挂载点

1
2
3
4
5
mount /dev/rbd/rbd/rbd-1 /root/ceph-rbd-1-mountpoint/

# df -Th
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/rbd0      xfs        10G   33M   10G   1% /root/ceph-rbd-1-mountpoint

7、samba预操作（关闭防火墙）

1
2
3
4
5
6
systemctl stop firewalld
setenforce 0

持久化关闭selinux
vim /etc/selinux/config
SELINUX=disabled

8、配置samba（samba默认会共享linux home目录，如果自定义需要自己配置），并重启服务

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
vim /etc/samba/smb.conf

[global]
        workgroup = SAMBA
        security = user
        passdb backend = tdbsam
        printing = cups
        printcap name = cups
        load printers = yes
        cups options = raw

[homes]
        comment = Home Directories
        valid users = %S, %D%w%S
        browseable = No
        read only = No
        inherit acls = Yes
        writable = Yes

[ceph]
        comment = ceph
        path = /root/ceph-rbd-1-mountpoint/
        valid users = %S, %D%w%S
        browseable = No
        read only = No
        inherit acls = Yes
        writable = Yes

[printers]
        comment = All Printers
        path = /var/tmp
        printable = Yes
        create mask = 0600
        browseable = No

[print$]
        comment = Printer Drivers
        path = /var/lib/samba/drivers
        write list = @printadmin root
        force group = @printadmin
        create mask = 0664
        directory mask = 0775

systemctl restart smb

9、为samba添加ceph用户

1
smbpasswd -a ceph

10、客户端访问samba

1
\\10.20.10.23\ceph

window清除samba连接，重新登录

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
C:\Users\JiangYu>net use
会记录新的网络连接。
状态       本地        远程                      网络
-------------------------------------------------------------------------------
OK                     \\10.20.10.23\IPC$        Microsoft Windows Network
命令成功完成。


C:\Users\JiangYu>net use \\10.20.10.23\IPC$ /del
\\10.20.10.23\IPC$ 已经删除。


C:\Users\JiangYu>net use
会记录新的网络连接。
列表是空的。

11、因为是使用root用户创建的ceph-rbd-1-mountpoint目录，所以ceph用户没有权限对这个目录进行写操作，需要修改目录所有者，修改后就可以对这个目录进行创建文件等写操作了

1
chown ceph:ceph ceph-rbd-1-mountpoint/

samba配置

1、查看配置文件帮助手册

1
man smb.conf 5

2、smb.conf配置文件语法

1
;或#开头为注释

3、检查配置文件语法命令

1
testparm /etc/samba/smb.conf

4、Security-Enhanced Linux (SELinux) Notes

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
启用samba_domain_controller Boolean以允许Samba PDC使用useradd和groupadd二进制。以root用户身份运行以下命令以启用此Boolean：
setsebool -P samba_domain_controller on

如果要通过Samba共享home directories，请打开samba_enable_home_dirs Boolean。以root用户身份运行以下命令以启用此Boolean：
setsebool -P samba_enable_home_dirs on

如果创建新directories，例如新的顶级directories，请使用samba_share_t对其进行标记，以便SELinux允许Samba对其进行读写。不要使用samba_share_t标记系统目录，例如/etc/和/home/，因为这样的目录应该已经具有SELinux label了。

运行"ls -ldZ /path/to/directory"命令以查看给定目录的当前SELinux label。

仅在创建的文件和目录上设置SELinux labels。使用chcon命令临时更改label：
chcon -t samba_share_t /path/to/directory

重新标记文件系统或运行诸如restorecon之类的命令时，通过chcon进行的更改将丢失。

使用samba_export_all_ro或samba_export_all_rw Boolean共享系统目录。 
要共享这样的目录并仅允许只读权限：
setsebool -P samba_export_all_ro on
要共享此类目录并允许读写权限：
setsebool -P samba_export_all_rw on

要运行脚本（preexec/root prexec/print command/...），请将它们复制到/var/lib/samba/scripts/目录中，以便SELinux允许smbd运行它们。
注意，如果将脚本移动到/var/lib/samba/scripts/，它们将保留其现有的SELinux labels，这些labels可能是SELinux不允许smbd运行的labels。复制脚本将得到正确的SELinux labels。
以root用户身份运行"restorecon -R -v /var/lib/samba/scripts"命令，以将正确的SELinux labels应用于这些文件。

5、配置文件段

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
#======================= Global Settings =====================================

[global]

# ----------------------- Network-Related Options -------------------------
#
# workgroup = Windows NT domain name 或 workgroup name, 例如, MYGROUP.
#
# server string = 等效于Windows NT Description字段（用于描述）.
#
# netbios name = 用于指定不与hostname绑定的server name，最多15个字符。
#
# interfaces = 用于将Samba配置为侦听多个network interfaces。如果您有多个interfaces，则可以使用"interfaces ="选项来配置Samba侦听哪些interface。 切勿忽略localhost interface (lo)。
#
# hosts allow = 允许连接的主机。This option can also be used on a per-share basis.
#
# hosts deny = 不允许主机连接。 This option can also be used on a per-share basis.
#
	workgroup = MYGROUP
	server string = Samba Server Version %v

;	netbios name = MYSERVER

;	interfaces = lo eth0 192.168.12.2/24 192.168.13.2/24
;	hosts allow = 127. 192.168.12. 192.168.13.

# --------------------------- Logging Options -----------------------------
#
# log file = 指定日志文件写入的位置以及它们的拆分方式。
#
# max log size = 指定允许的最大日志文件大小。 日志文件达到"max log size"指定的大小时，将对其进行rotated。
#

	# log files split per-machine:
	log file = /var/log/samba/log.%m
	# maximum size of 50KB per log file, then rotate:
	max log size = 50

# ----------------------- Standalone Server Options ------------------------
#
# security = Samba运行的模式。可以将其设置为user, share (不建议使用), 或 server (不建议使用).
#
# passdb backend = 用于存储用户信息的backend（后端）。新安装应使用tdbsam或ldapsam。tdbsam不需要其他配置。"smbpasswd"可用于向后兼容。
#

	security = user
	passdb backend = tdbsam


# ----------------------- Domain Members Options ------------------------
#
# security = 必须设置为 domain 或 ads.
#
# passdb backend = 用于存储用户信息的backend（后端）。新安装应使用tdbsam或ldapsam。tdbsam不需要其他配置。"smbpasswd"可用于向后兼容。
#
# realm = 当设置了"security = ads"选项时才会用到该选项。
#
# password server = 当设置了"security = server"选项或无法使用DNS定位Domain Controller时，才使用此选项。参数列表可以包括My_PDC_Name, [My_BDC_Name], 和[My_Next_BDC_Name]
#
# password server = My_PDC_Name [My_BDC_Name] [My_Next_BDC_Name]
#
# 使用 "password server = *" 自动定位 Domain Controllers.

;	security = domain
;	passdb backend = tdbsam
;	realm = MY_REALM

;	password server = <NT-Server-Name>

# ----------------------- Domain Controller Options ------------------------
#
# security = 必须将domain controllers设置为user。
#
# passdb backend = 用于存储用户信息的backend（后端）。新安装应使用tdbsam或ldapsam。tdbsam不需要其他配置。"smbpasswd"可用于向后兼容。
#
# domain master = 将Samba指定为Domain Master Browser，从而允许Samba整理subnets之间的browse lists。 如果您已经有Windows NT domain controller执行此任务，请不要使用"domain master"选项。
#
# domain logons = 允许Samba为Windows workstations提供网络登录服务。
#
# logon script = 指定在登录时在客户端上运行的脚本。 必须在名为NETLOGON的共享中提供这些脚本。
#
# logon path = 指定（使用UNC path）用户配置文件的存储位置。
#
#
;	security = user
;	passdb backend = tdbsam

;	domain master = yes
;	domain logons = yes

	# 以下登录脚本名称由machine name确定(%m):
;	logon script = %m.bat
	# 以下登录脚本名称由UNIX user确定:
;	logon script = %u.bat
;	logon path = \\%L\Profiles\%u
	# 使用empty path禁用profile support
;	logon path =

	# 可以在domain controller或独立machine上使用各种脚本来添加或删除相应的UNIX帐户：

;	add user script = /usr/sbin/useradd "%u" -n -g users
;	add group script = /usr/sbin/groupadd "%g"
;	add machine script = /usr/sbin/useradd -n -c "Workstation (%u)" -M -d /nohome -s /bin/false "%u"
;	delete user script = /usr/sbin/userdel "%u"
;	delete user from group script = /usr/sbin/userdel "%u" "%g"
;	delete group script = /usr/sbin/groupdel "%g"


# ----------------------- Browser Control Options ----------------------------
#
# local master = 设置为no时，Samba不会成为网络上的master browser。 设置为yes时，将应用常规election（选举） rules。
#
# os level = 确定服务器在master browser选举中的优先级。 默认值应该合理。
#
# preferred master = 设置为yes时，Samba会在启动时强制进行local browser选举（并使其赢得选举的几率略高）。
#
;	local master = no
;	os level = 33
;	preferred master = yes

#----------------------------- Name Resolution -------------------------------
#
# 本节详细介绍了对 Windows Internet Name Service (WINS) 的支持.
#
# 注意：Samba可以是WINS服务器，也可以是WINS客户端，但不能同时是两者。
#
# wins support = 设置为yes时，Samba的NMBD组件启用其WINS服务器。
#
# wins server = 告诉Samba的NMBD组件是WINS客户端。
#
# wins proxy = 设置为yes时，Samba代表不支持WINS的客户端回答name resolution查询。 为此，网络上至少必须有一个WINS服务器。 默认为no。
#
# dns proxy = 设置为yes时，Samba尝试通过DNS nslookups解析NetBIOS名称。

;	wins support = yes
;	wins server = w.x.y.z
;	wins proxy = yes

;	dns proxy = yes

# --------------------------- Printing Options -----------------------------
#
# 本部分中的选项使您可以配置non-default（非默认） printing system。
#
# load printers = 设置为yes时，将自动加载printers列表，而不是单独进行设置。
#
# cups options = 允许您将选项传递到CUPS库。 例如，将此选项设置为raw，则可以在Windows客户端上使用驱动程序。
#
# printcap name = 用于指定备用的printcap文件。
#

	load printers = yes
	cups options = raw

;	printcap name = /etc/printcap
	# 自动获取UNIX System V系统上的printers列表：
;	printcap name = lpstat
;	printing = cups

# --------------------------- File System Options ---------------------------
#
# 如果文件系统支持扩展属性，并且启用了这些属性（通常通过"user_xattr" mount选项），则可以取消注释本节中的选项。
# 这些选项允许管理员指定DOS属性存储在扩展属性中，并且还确保Samba不会更改permission bits。
#
# 注意：这些选项可以按per-share使用。 全局设置它们（在[global]部分中）使它们成为所有共享的默认值。

;	map archive = no
;	map hidden = no
;	map read only = no
;	map system = no
;	store dos attributes = yes


#============================ Share Definitions ==============================

[homes]
	comment = Home Directories
	browseable = no
	writable = yes
;	valid users = %S
;	valid users = MYDOMAIN\%S

[printers]
	comment = All Printers
	path = /var/spool/samba
	browseable = no
	guest ok = no
	writable = no
	printable = yes

# 取消注释以下内容，并为Domain Logons创建netlogon目录：
;	[netlogon]
;	comment = Network Logon Service
;	path = /var/lib/samba/netlogon
;	guest ok = yes
;	writable = no
;	share modes = no

# 取消注释以下内容以提供特定的roaming profile share。
# 默认为使用用户的home目录：
;	[Profiles]
;	path = /var/lib/samba/profiles
;	browseable = no
;	guest ok = yes

# 一个只读公共目录，但"staff" group中的用户（具有写权限）除外：
;	[public]
;	comment = Public Stuff
;	path = /home/samba
;	public = yes
;	writable = no
;	printable = no
;	write list = +staff

6、用户操作

1
2
3
4
smbpasswd -a 增加用户（linux系统用户）
smbpasswd -d 冻结用户
smbpasswd -e 解冻用户
smbpasswd -n 将用户的密码设置成空.

LinuxCast笔记

samba相关rpm

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
Name        : ctdb
Summary     : A Clustered Database based on Samba's Trivial Database (TDB)
Description : CTDB是Samba和其他项目用来存储临时数据的TDB数据库的集群实现。如果应用程序已经在使用TDB来存储临时数据，则很容易将该应用程序转换为群集感知型，而使用CTDB。

Name        : samba-client
Summary     : Samba client programs
Description : samba-client package提供了一些SMB/CIFS客户端，以补充Linux中内置的SMB/CIFS filesystem。这些客户端允许访问SMB/CIFS shares并打印到SMB/CIFS printers。

Name        : samba-devel
Summary     : Developer tools for Samba libraries
Description : samba-devel package包含开发Samba套件时的SMB，RPC和其他程序所需libraries的header files。

Name        : samba-vfs-glusterfs
Summary     : Samba VFS module for GlusterFS
Description : 包含GlusterFS集成Samba VFS的模块。

Name        : ctdb-tests
Summary     : CTDB clustered database test suite
Description : CTDB的测试套件。CTDB是Samba和其他项目用来存储临时数据的TDB数据库的集群实现。如果应用程序已经在使用TDB来存储临时数据，则很容易将该应用程序转换为群集感知型，而使用CTDB。

Name        : samba-client-libs
Summary     : Samba client libraries
Description : samba-client-libs package包含SMB/CIFS客户端所需的internal libraries。

Name        : samba-krb5-printing
Summary     : Samba CUPS backend for printing with Kerberos
Description : 如果您需要 Kerberos 进行print jobs，通过 SMB后端连接到printer cups，则需要安装该软件包。它将允许cups访问发出print job的用户的 Kerberos credentials cache。

Name        : samba-winbind
Summary     : Samba winbind
Description : samba-winbind package提供了winbind NSS library和一些客户端工具。 Winbind使Linux成为Windows domains中的正式成员，并在Linux上使用Windows user和group帐户。

Name        : libsmbclient
Summary     : The SMB client library
Description : libsmbclient包含来自Samba套件的SMB客户端library。

Name        : samba-common-libs
Summary     : Libraries used by both Samba servers and clients
Description : samba-common-libs package包含SMB/CIFS客户端所需的internal libraries。

Name        : samba-libs
Summary     : Samba libraries
Description : samba-libs package包含Samba套件的SMB，RPC和其他协议所需的libraries。

Name        : samba-winbind-clients
Summary     : Samba winbind clients
Description : samba-winbind-clients package提供wbinfo和ntlm_auth工具。

Name        : libsmbclient-devel
Summary     : Developer tools for the SMB client library
Description : libsmbclient-devel package包含开发相关Samba套件的SMB client library link所需的header files和libraries。

Name        : samba-common-tools
Summary     : Tools for Samba servers and clients
Description : samba-common-tools package包含用于Samba servers和SMB/CIFS clients的工具。

Name        : samba-python
Summary     : Samba Python libraries
Description : samba-python package包含Python程序中使用SMB，RPC和其他Samba提供的协议的程序所需的Python libraries。

Name        : samba-winbind-krb5-locator
Summary     : Samba winbind krb5 locator
Description : winbind krb5 locator是系统kerberos library的plugin，以允许本地kerberos library使用与samba和winbind相同的KDC。

Name        : libwbclient
Summary     : The winbind client library
Description : libwbclient package包含Samba套件中的winbind client library。

Name        : samba-dc
Summary     : Samba AD Domain Controller
Description : samba-dc package提供AD Domain Controller功能

Name        : samba-python-test
Summary     : Samba Python libraries
Description : samba-python-test package包含Samba test suite使用的Python libraries。 如果要运行全套Samba测试，则需要安装此package。

Name        : samba-winbind-modules
Summary     : Samba winbind modules
Description : samba-winbind-modules package提供了与Winbind Daemon通信所需的NSS library和PAM module。

Name        : libwbclient-devel
Summary     : Developer tools for the winbind library
Description : libwbclient-devel package为wbclient library提供了developer tools。

Name        : samba-dc-libs
Summary     : Samba AD Domain Controller Libraries
Description : samba-dc-libs package包含DC去链接SMB，RPC和其他协议所需的库。

Name        : samba-test
Summary     : Testing tools for Samba servers and clients
Description : samba-test为Samba的server和client packages提供测试工具。

Name        : samba
Summary     : Server and Client software to interoperate with Windows machines
Description : Samba is the standard Windows interoperability suite of programs
            : for Linux and Unix.

Name        : samba-debuginfo
Summary     : Debug information for package samba
Description : 该软件包提供了samba软件包的debug information。

Name        : samba-test-libs
Summary     : Libraries need by the testing tools for Samba servers and clients
Description : samba-test-libs提供测试工具所需的libraries。

Name        : samba-common
Summary     : Samba servers 和 clients使用的文件
Description : samba-common提供Samba的server和client packages所需的文件。

Name        : samba-pidl
Summary     : Perl IDL编译器
Description : samba-pidl package包含Samba和Wireshark用于解析IDL和类似协议的Perl IDL编译器

参考资料

【1】https://blog.csdn.net/skdkjzz/article/details/42101363

Posted on Edited on

DISKPREDICTION MODULE

磁盘预测模块支持两种模式：cloud mode和local mode。 在cloud mode下，磁盘和Ceph操作状态信息是从Ceph群集中收集的，并通过Internet发送到基于云的DiskPrediction服务器。 DiskPrediction服务器分析数据，并提供Ceph群集的性能和磁盘运行状况的分析和预测结果。

local mode不需要任何外部服务器即可进行数据分析和输出结果。 在local mode下，磁盘diskprediction module将内部predictor module用于磁盘预测服务，然后将磁盘预测结果返回给Ceph系统。

Local predictor: 70% 的准确性

Cloud predictor for free: 95% 的准确性

ENABLING

运行以下命令以在Ceph环境中启用磁盘预测模块：

1
2
ceph mgr module enable diskprediction_cloud
ceph mgr module enable diskprediction_local

选择预测模式：

1
ceph config set global device_failure_prediction_mode local

或

1
ceph config set global device_failure_prediction_mode cloud

要禁用预测，请执行以下操作：

1
ceph config set global device_failure_prediction_mode none

CONNECTION SETTINGS

connection settings用于Ceph和DiskPrediction服务器之间的连接。

LOCAL MODE

diskprediction module利用Ceph设备运行状况检查来收集磁盘运行状况指标，并使用内部predictor module来生成磁盘故障预测并返回Ceph。 因此，在local mode下不需要连接设置。 local predictor module至少需要六个设备健康状况数据集才能实施预测。

运行以下命令以使用本地预测变量预测设备的预期寿命。

1
2
3
4
ceph device predict-life-expectancy <device id>

[root@community-ceph-1 ~]# ceph device predict-life-expectancy 0d2a946c-413f-43f4-b
unknown

CLOUD MODE

在cloud mode下，需要用户注册。 用户必须在https://www.diskprophet.com/#/上注册其帐户，以接收以下DiskPrediction服务器信息以进行连接设置。

Certificate file path: 确认用户注册后，系统将发送一封确认电子邮件，其中包括证书文件下载链接。 下载证书文件并将其保存到Ceph系统。 运行以下命令来验证文件。 如果没有证书文件验证，则无法完成连接设置。

DiskPrediction server: DiskPrediction服务器名称。 如果需要，它可以是IP地址。

Connection account: 用于在Ceph和DiskPrediction服务器之间建立连接的帐户名

Connection password: 用于在Ceph和DiskPrediction服务器之间建立连接的密码

运行以下命令以完成连接设置。

1
ceph device set-cloud-prediction-config <diskprediction_server> <connection_account> <connection_password> <certificate file path>

您可以使用以下命令显示连接设置：

1
ceph device show-prediction-config

其他可选配置设置如下：

diskprediction_upload_metrics_interval: 指示定期将Ceph性能指标发送到DiskPrediction服务器的频率。 默认值为10分钟。

diskprediction_upload_smart_interval: 指示定期将Ceph物理设备信息发送到DiskPrediction服务器的频率。 默认值为12小时。

diskprediction_retrieve_prediction_interval: 指示Ceph有时会定期从DiskPrediction服务器检索物理设备预测数据。 默认值为12小时。

DISKPREDICTION DATA

diskprediction module主动向/从DiskPrediction服务器发送/检索以下数据。

METRICS DATA

  • Ceph cluster status
key Description
cluster_health Ceph health check status
num_mon Number of monitor node
num_mon_quorum Number of monitors in quorum
num_osd Total number of OSD
num_osd_up Number of OSDs that are up
num_osd_in Number of OSDs that are in cluster
osd_epoch Current epoch of OSD map
osd_bytes Total capacity of cluster in bytes
osd_bytes_used Number of used bytes on cluster
osd_bytes_avail Number of available bytes on cluster
num_pool Number of pools
num_pg Total number of placement groups
num_pg_active_clean Number of placement groups in active+clean state
num_pg_active Number of placement groups in active state
num_pg_peering Number of placement groups in peering state
num_object Total number of objects on cluster
num_object_degraded Number of degraded (missing replicas) objects
num_object_misplaced Number of misplaced (wrong location in the cluster) objects
num_object_unfound Number of unfound objects
num_bytes Total number of bytes of all objects
num_mds_up Number of MDSs that are up
num_mds_in Number of MDS that are in cluster
num_mds_failed Number of failed MDS
mds_epoch Current epoch of MDS map
  • Ceph mon/osd performance counts

Mon:

key Description
num_sessions Current number of opened monitor sessions
session_add Number of created monitor sessions
session_rm Number of remove_session calls in monitor
session_trim Number of trimed monitor sessions
num_elections Number of elections monitor took part in
election_call Number of elections started by monitor
election_win Number of elections won by monitor
election_lose Number of elections lost by monitor

Osd:

key Description
op_wip Replication operations currently being processed (primary)
op_in_bytes Client operations total write size
op_r Client read operations
op_out_bytes Client operations total read size
op_w Client write operations
op_latency Latency of client operations (including queue time)
op_process_latency Latency of client operations (excluding queue time)
op_r_latency Latency of read operation (including queue time)
op_r_process_latency Latency of read operation (excluding queue time)
op_w_in_bytes Client data written
op_w_latency Latency of write operation (including queue time)
op_w_process_latency Latency of write operation (excluding queue time)
op_rw Client read-modify-write operations
op_rw_in_bytes Client read-modify-write operations write in
op_rw_out_bytes Client read-modify-write operations read out
op_rw_latency Latency of read-modify-write operation (including queue time)
op_rw_process_latency Latency of read-modify-write operation (excluding queue time)
  • Ceph pool statistics
key Description
bytes_used Per pool bytes used
max_avail Max available number of bytes in the pool
objects Number of objects in the pool
wr_bytes Number of bytes written in the pool
dirty Number of bytes dirty in the pool
rd_bytes Number of bytes read in the pool
stored_raw Bytes used in pool including copies made
  • Ceph physical device metadata
key Description
disk_domain_id Physical device identify id
disk_name Device attachment name
disk_wwn Device wwn
model Device model name
serial_number Device serial number
size Device size
vendor Device vendor name
  • Ceph each objects correlation information
  • The module agent information
  • The module agent cluster information
  • The module agent host information

SMART DATA

  • Ceph physical device SMART data (provided by Ceph devicehealth module)

PREDICTION DATA

  • Ceph physical device prediction data

RECEIVING PREDICTED HEALTH STATUS FROM A CEPH OSD DISK DRIVE（从CEPH OSD磁盘驱动器中接收预期的健康状况）

您可以使用以下命令从Ceph OSD磁盘驱动器接收预测的健康状态。

1
ceph device get-predicted-status <device id>

get-predicted-status命令返回：

1
2
3
4
5
6
7
{
    "near_failure": "Good",
    "disk_wwn": "5000011111111111",
    "serial_number": "111111111",
    "predicted": "2018-05-30 18:33:12",
    "attachment": "sdb"
}
Attribute Description
near_failure The disk failure prediction state: Good/Warning/Bad/Unknown
disk_wwn Disk WWN number
serial_number Disk serial number
predicted Predicted date
attachment device name on the local system

磁盘故障预测状态的near_failure属性在下表中指示磁盘预期寿命。

near_failure Life expectancy (weeks)
Good > 6 weeks
Warning 2 weeks ~ 6 weeks
Bad < 2 weeks

DEBUGGING

如果要调试DiskPrediction module映射到Ceph日志记录级别，请使用以下命令。

1
2
3
[mgr]

    debug mgr = 20

将日志记录设置为管理器调试时，模块将打印出带有前缀mgr [diskprediction]的日志记录消息，以便于过滤。

Posted on Edited on

DEVICE MANAGEMENT

Ceph跟踪哪个daemons消耗了哪些hardware storage devices（例如HDD，SSD），并收集有关这些devices的运行状况指标，以提供预测和/或自动响应硬件故障的工具。

DEVICE TRACKING

您可以查询哪些存储设备正在使用：

1
2
3
4
5
6
7
8
9
ceph device ls

DEVICE               HOST:DEV                       DAEMONS LIFE EXPECTANCY 
0d2a946c-413f-43f4-b community-ceph-2.novalocal:vdc osd.0
451e48d6-913e-4f93-a community-ceph-1.novalocal:vdd osd.5
935b6018-1dfe-4cf9-8 community-ceph-1.novalocal:vdc osd.2
abe09d21-d950-47b0-9 community-ceph-2.novalocal:vdd osd.3
bf37729e-9d83-48e9-9 community-ceph-3.novalocal:vdc osd.1
d48dcf29-fe58-4e3e-a community-ceph-3.novalocal:vdd osd.4

您还可以按daemon或host列出devices：

1
2
3
4
5
6
7
8
9
10
11
ceph device ls-by-daemon <daemon>
ceph device ls-by-host <host>

[root@community-ceph-1 ~]# ceph device ls-by-daemon osd.0
DEVICE               HOST:DEV                       EXPECTED FAILURE 
0d2a946c-413f-43f4-b community-ceph-2.novalocal:vdc                  

[root@community-ceph-1 ~]# ceph device ls-by-host community-ceph-2.novalocal
DEVICE               DEV DAEMONS EXPECTED FAILURE 
0d2a946c-413f-43f4-b vdc osd.0                    
abe09d21-d950-47b0-9 vdd osd.3

对于任何单个设备，您可以通过以下方式查询有关其位置以及如何使用它的信息：

1
2
3
4
5
6
ceph device info <devid>

[root@community-ceph-1 ~]# ceph device info 0d2a946c-413f-43f4-b
device 0d2a946c-413f-43f4-b
attachment community-ceph-2.novalocal:vdc
daemons osd.0

ENABLING MONITORING

Ceph还可以监视与您的设备关联的健康指标。 例如，SATA硬盘实现了一个称为SMART的标准，该标准提供了有关设备使用情况和运行状况的内部指标，例如开机小时数，电源循环次数或不可恢复的读取错误。 其他设备类型（例如SAS和NVMe）实现了一组相似的指标（通过略有不同的标准）。 Ceph可以通过smartctl工具收集所有这些信息。

您可以通过以下方式启用或禁用运行状况监视：

1
ceph device monitoring on

或

1
ceph device monitoring off

SCRAPING

如果启用了监视，则将定期自动scraped指标。 该间隔可以配置为：

1
ceph config set mgr mgr/devicehealth/scrape_frequency <seconds>

默认值为每24小时scrape一次。

您可以使用以下方法手动触发所有设备的scrape：

1
ceph device scrape-health-metrics

单个设备可以用以下方式scraped：

1
ceph device scrape-health-metrics <device-id>

或单个daemon的设备可以通过以下方式进行scraped：

1
ceph device scrape-daemon-health-metrics <who>

可以使用以下命令检索设备的存储健康指标（可选地，用于特定时间戳）：

1
ceph device get-health-metrics <devid> [sample-timestamp]

FAILURE PREDICTION

Ceph可以根据其收集的健康指标预测预期寿命和设备故障。 共有三种模式：

  • none: 禁用设备故障预测。
  • local: 使用来自ceph-mgr daemon的预训练预测模型
  • cloud: 使用ProphetStor运行的外部云服务共享设备运行状况和性能指标，并使用其免费服务或付费服务进行更准确的预测

预测模式可以配置为：

1
ceph config set global device_failure_prediction_mode <mode>

预测通常在后台定期进行，因此填充预期寿命值可能需要一些时间。 您可以从以下输出中看到所有设备的预期寿命：

1
ceph device ls

您还可以使用以下方法查询特定设备的metadata：

1
ceph device info <devid>

您可以使用以下命令显式地强制预测设备的预期寿命：

1
ceph device predict-life-expectancy <devid>

如果您未使用Ceph的内部设备故障预测，但是拥有一些有关设备故障的外部信息源，则可以通过以下方式告知Ceph设备的预期寿命：

1
ceph device set-life-expectancy <devid> <from> [<to>]

预期寿命以时间间隔表示，因此不确定性可以以宽间隔的形式表示。 间隔结束也可以不指定。

HEALTH ALERTS

mgr/devicehealth/warn_threshold控制在生成运行状况警告之前，预期的设备故障必须多长时间。

可以使用以下方法检查所有设备的存储预期寿命，并生成任何适当的健康警报：

1
ceph device check-health

AUTOMATIC MITIGATION

如果启用了mgr/devicehealth/self_heal选项（默认情况下），则对于预计将很快发现故障的设备，模块将通过将设备标记为“out”来自动将数据迁移到这些设备之外。

mgr/devicehealth/mark_out_threshold控制在我们将osd自动标记为“out”之前，预期的设备故障必须多长时间。

原文：

https://docs.ceph.com/docs/master/rados/operations/devices/#devices

Posted on Edited on

V14.2.0 NAUTILUS MAJOR CHANGES FROM MIMIC

参考：

【1】https://docs.ceph.com/docs/master/releases/nautilus/

【2】https://blog.csdn.net/Z_Stand/article/details/89739908

这是Ceph Nautilus的第一个稳定版本。

  • Dashboard

    Ceph Dashboard增加了许多新功能：

    • Support for multiple users / roles
    • SSO (SAMLv2) for user authentication
    • Auditing support（审计支持）
    • New landing page, showing more metrics and health info
    • I18N support（国际化）
    • REST API documentation with Swagger API
    • Swagger 是一个规范和完整的框架，用于生成、描述、调用和可视化 RESTful 风格的 Web 服务。总体目标是使客户端和文件系统作为服务器以同样的速度来更新。文件的方法，参数和模型紧密集成到服务器端的代码，允许API来始终保持同步。作者：天马行空LQ
      链接：https://www.jianshu.com/p/66a14ea07622
      来源：简书
      著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

    Ceph management新功能：

    • OSD management (mark as down/out, change OSD settings, recovery profiles)
    • Cluster config settings editor
    • Ceph Pool management (create/modify/delete)
    • ECP management
    • RBD mirroring configuration
    • Embedded Grafana Dashboards (derived from Ceph Metrics)
    • CRUSH map viewer
    • NFS Ganesha management
    • iSCSI target management (via Ceph iSCSI Gateway)
    • RBD QoS configuration
    • Ceph Manager (ceph-mgr) module management
    • Prometheus alert Management

而且，Ceph Dashboard现在被拆分到ceph-mgr-dashboard的package。 如果您的package management software在安装ceph-mgr时失败，则可能需要单独安装ceph-mgr-dashboard。

  • RADOS

    • 现在可以随时减少每个pool的placement groups (PGs)数，并且可以根据群集利用率或管理员提示自动调整PG数。
    • 新的v2 wire protocol支持线路加密
    • 群集可以跟踪OSD和Monitor daemons消耗的物理存储设备以及运行状况指标（即SMART），并且群集可以通过预先训练的预测模型或者基于云预测服务来报告预测的HDD或SSD故障。
    • 可通过ceph osd numa-status命令轻松监视OSD daemons的NUMA节点，并通过osd_numa_node config选项进行配置。
    • 现在，当使用BlueStore OSD时，空间利用率将按object data，omap data和internal metadata，pool以及压缩前和压缩后的大小进行细分。
    • 在执行recovery和backfill时，OSD可以更有效地选择重要的PG和objects优先处理。
    • 在设备出现问题以后，像recovery这种长期运行在后台的进程，可以使用ceph status命令查看进度。
    • 增加了一个实验性的（耦合层） Coupled-Layer “Clay” erasure code plugin，该plugin可减少大多数recovery操作所需的网络带宽和IO。

  • RGW

    • S3 lifecycle可以在storage classes与tiering层之间转换
    • Beast取代了civetweb成为默认的web frontend，从而提高了整体性能。
    • 支持新的publish/subscribe基础架构，允许RGW将events推送至serverless frameworks如knative或data pipelies如Kafka。
    • 新增一系列身份验证功能，使用OAuth2和OpenID::connect的STS联合以及OPA（开放策略代理）身份验证委派原型。
    • 新的archive zone federation功能可将所有objects（包括历史记录）完全保留在一个单独的zone中。

  • CephFS

    • 对于具有large caches和large RAM并长期运行的客户端，MDS的稳定性已大大提高。Cache trimming（调整）和client capability recall现在受到限制，以防止MDS过载。
    • 现在可以在Rook管理的群集环境中通过NFS-Ganesha导出CephFS。Ceph负责管理集群并确保高可用性和可伸缩性。 入门演示。 预计在未来Nautilus的次要版本中实现此功能的更多自动化。
    • MDS mds_standby_for_*，mon_force_standby_active和mds_standby_replay配置选项已过时。 相反，操作者现在可以在CephFS文件系统上设置新的allow_standby_replay标志。 该设置会使文件系统由standbys变为standby-replay，并且任何可用的rank都会生效。（一个 rank 可看作是一个元数据分片）
    • MDS支持客户端释放缓存的同时释放自己的存储端缓存，这个过程可由MDS admin socket命令 cache drop来完成
    • 现在可以检查MDS中正在进行的scrub的进度。 此外，scrub可能会暂停或中止。 有关更多信息，请参见scrub文档。
    • 通过ceph volume command-line-interface提供了一个用于创建volumes的新interface。
    • 新的cephfs-shell工具可用于处理CephFS文件系统而无需mounting。
    • 为了简洁，清楚和有用，已重新格式化了来自ceph status与CephFS相关的输出。
    • Lazy IO已进行了改进。客户端可以使用ceph_open C/C++ API的新CEPH_O_LAZY flag将其打开或通过配置选项client_force_lazyio将其打开。（LazyIO放松了POSIX语义。 即使文件由多个客户端上的多个应用程序打开，也允许缓冲的读/写操作。 应用程序负责自己管理缓存的一致性。自Nautilus发行以来，Libcephfs支持LazyIO。）
    • 现在可以通过ceph fs fail命令快速关闭CephFS文件系统。有关更多信息，请参见 the administration page。

  • RBD

    • Images可以在尽量短的停机时间内迁移，以帮助在pool之间移动images或移动到新的layouts。
    • 新的rbd perf image iotop和rbd perf image iostat命令为所有RBD images提供了类似于iotop和iostat的IO监视器。
    • 现在，ceph-mgr Prometheus exporter新增一个用于所有RBD images的IO监视器。
    • 支持pool中的单独image namespaces，以便进行租户隔离。

  • Misc

    • Ceph 拥有一组新的orchestrator modules，可直接与外部orchestrators像ceph-ansible, DeepSea, Rook, or simply ssh通过一致的CLI interface(and, eventually, Dashboard) 进行交互。

V13.2.0 MIMIC MAJOR CHANGES FROM LUMINOUS

  • Dashboard

  • RADOS

    • 现在，配置选项可以由monitor集中存储和管理。
    • 进行recovery或rebalancing操作时，monitor daemon占用的disk space大大减少。
    • 当OSD从最近的故障中恢复时，异步恢复功能可减少请求的tail latency（少量响应的延迟高于均值，我们把这些响应称为尾延迟）。
    • scrub时OSD冲突请求抢占tail latency减少。

  • RGW

    • RGW可以将zone （或subset of buckets）复制到外部云存储服务（例如S3）。
    • RGW在versioned buckets功能上支持S3 multi-factor authentication API。
      • AWS Multi-Factor Authentication（MFA）它在用户名和密码的基础上增加了一层额外的保护。启用MFA后，当用户登录AWS网站时，系统将提示他们输入用户名和密码以及来自其AWS MFA设备的身份验证代码。这些因素综合在一起，为您的AWS账户设置和资源提供了更高的安全性。
    • 版本控制是在相同的存储桶中保留对象的多个变量的方法。对于 Amazon S3 桶中存储的每个对象，您可以使用版本控制功能来保存、检索和还原它们的各个版本。使用版本控制能够轻松从用户意外操作和应用程序故障中恢复数据。
    • Beast frontend不再进行实验，被认为是稳定的并可以使用。

  • CephFS

    • Snapshots与多个MDS daemons结合使用时，现在稳定。

  • RBD

    • Image clones不再需要明确的protect和unprotect步骤。
    • 可以将Images deep-copied（包括与parent image和associated snapshots的任何克隆链接）到新pool或修改data layouts。

  • Misc

    • 由于在Stretch中缺少GCC 8，我们已删除了Mimic的Debian构建。我们希望Debian的构建将在2019年初发布Buster后回归，并希望在Buster可用后构建最终的Luminous发行版（以及以后的Mimic point发行版）。

Posted on Edited on

AUTOSCALING PLACEMENT GROUPS

Placement groups (PGs)是ceph分布数据的内部实现。您可以通过启用pg-autoscaling允许根据集群的使用方式提出建议或自动调整PG。

系统中的每个pool都有一个pg_autoscale_mode属性，可以将其设置为off，on或warn。

要为已有的pool设置autoscaling mode，请执行以下操作：

1
ceph osd pool set <pool-name> pg_autoscale_mode <mode>

例如，要对池foo启用autoscaling，请执行以下操作：

1
ceph osd pool set foo pg_autoscale_mode on

您还可以使用以下命令配置默认pg_autoscale_mode，该默认pg_autoscale_mode应用于以后创建的任何pool：

1
ceph config set global osd_pool_default_pg_autoscale_mode <mode>

VIEWING PG SCALING RECOMMENDATIONS

您可以使用以下命令查看每个pool，pool的相对利用率以及对PG count的任何建议更改：

1
ceph osd pool autoscale-status

输出将类似于：

1
2
3
4
5
6
7
8
9
10
POOL                         SIZE  TARGET SIZE  RATE  RAW CAPACITY   RATIO  TARGET RATIO  BIAS  PG_NUM  NEW PG_NUM  AUTOSCALE 
cephfs_metadata             1540k                3.0        594.0G  0.0000                 4.0       8              warn      
default.rgw.meta            1536k                3.0        594.0G  0.0000                 1.0       8              warn      
cephfs_data                    0                 3.0        594.0G  0.0000                 1.0       8              warn      
default.rgw.buckets.index      0                 3.0        594.0G  0.0000                 1.0       8              warn      
default.rgw.control            0                 3.0        594.0G  0.0000                 1.0       8              warn      
yujiang                        0        553.2G   1.0        594.0G  0.9313                 1.0     512              on        
.rgw.root                   1344k                3.0        594.0G  0.0000                 1.0       8              warn      
rbd                        576.0k                3.0        594.0G  0.0000                 1.0       4              on        
default.rgw.log                0                 3.0        594.0G  0.0000                 1.0       8              warn

SIZE是存储在pool中的数据量。TARGET SIZE（如果存在）是管理员希望最终存储在该pool中的数据量。系统使用两个值中的较大者进行计算。

RATE是pool的multiplier（乘数或倍数），它确定要消耗多少raw（原始） storage capacity。例如，3个副本池的比率为3.0，而k=4，m=2擦除编码池的比率为1.5。

RAW CAPACITY是OSD上负责存储该pool（可能还有其他pool）数据的raw storage capacity的总量。RATIO是该pool消耗的总容量的比率（即ratio = size * rate / raw capacity）。

TARGET RATIO（如果存在）是管理员指定他们希望该pool使用的存储空间的比率。系统使用actual ratio和target ratio中的较大者进行计算。 如果同时指定了target size bytes和ratio ，则ratio优先。

PG_NUM是该pool的当前PG数。系统认为应将pool的pg_num更改为NEW PG_NUM（如果存在）。它始终是2的幂，并且仅在“理想”值与当前值的差异大于3倍时才存在。

最后一列，AUTOSCALE，是pool pg_autoscale_mode，on, off或warn。

AUTOMATED SCALING

最简单的方法是允许集群根据使用情况自动扩展PG。Ceph将查看可用的总存储量和整个系统的target PG数量，查看每个pool中存储了多少数据并尝试分配相应的PG。该系统的方法相对保守，只有当当前 PG （pg_num） 的数量比它认为的要小 3 倍以上时，才会对pool进行更改。

每个 OSD 的target PG 数基于可配置的 mon_target_pg_per_osd（默认值：100），可通过以下功能进行调整：

1
ceph config set global mon_target_pg_per_osd 100

autoscaler根据每个per-subtree分析pool并进行调整。由于每个pool可能映射到不同的 CRUSH rule，并且每个rule可以跨不同的设备分发数据，所以Ceph将考虑独立使用层次结构的每个subtree。例如，映射到ssd类的OSD的pool和映射到hdd类的OSD的pool将分别具有最佳PG counts，具体取决于这些相应设备类型的数量。

SPECIFYING EXPECTED POOL SIZE（指定预期的pool大小）

首次创建集群或pool时，它将占用集群总容量的一小部分，并在系统中显示只需要少量的placement groups。但是，在大多数情况下，集群管理员最好知道哪些pool会随着时间的推移消耗大部分系统容量。通过向ceph提供这些信息，可以从一开始就使用更适当数量的pg，从而防止pg-num中的后续更改以及在进行调整时与移动数据相关的开销。

pool的target size*可通过两种方式指定：按pool的绝对大小（即字节）或群集总容量的ratio（比率）指定。

例如：

1
ceph osd pool set mypool target_size_bytes 100T

会告诉系统mypool预计会占用100 TiB的空间。 或者：

1
ceph osd pool set mypool target_size_ratio .9

告诉系统mypool预计会消耗群集总容量的90％。

您还可以使用ceph osd pool create命令的可选--target-size-bytes <bytes>或--target-size-ratio <ratio>参数在创建时设置pool的target size。

请注意，如果指定了不可能的target size值（例如，容量大于整个群集的容量或ratio(s)之和大于1.0），则会引发health警告（POOL_TARET_SIZE_RATIO_OVERCOMMITTED或POOL_TARGET_SIZE_BYTES_OVERCOMMITTED）。https://www.mail-archive.com/ceph-users@lists.ceph.com/msg56416.html

SPECIFYING BOUNDS ON A POOL’S PGS（在pool的PGS上指定界限）

也可以为一个pool指定最小数量的PG。设置下限可防止Ceph将PG编号减少（或建议减少）到配置的编号以下。

您可以使用以下方法设置pool的最小PG数量：

1
ceph osd pool set <pool-name> pg_num_min <num>

您还可以使用ceph osd pool create命令的可选--pg-num-min <num>参数指定创建pool时的最小PG count。

A PRESELECTION OF PG_NUM

使用以下方法创建新pool时：

1
ceph osd pool create {pool-name} [pg_num]

选择pg_num的值是可选的。 如果您未指定pg_num，则集群可以（默认情况下）根据pool中存储的数据为您自动对其进行调整（请参见上文， Autoscaling placement groups）。

或者，可以显式提供pg_num。 但是，是否指定pg_num值并不影响群集是否自动调整该值。 要启用或禁用自动调整，请执行以下操作：

1
ceph osd pool set {pool-name} pg_autoscaler_mode (on|off|warn)

传统上，每个OSD PG的”rule of thumb”为100。使用balancer的附加功能（默认情况下也启用的），每个OSD大约50 PG可能是合理的。autoscaler通常为您提供：

  • 使每个pool中的PG与pool中的数据成比例
  • 考虑到每个PG在OSD上的replication或erasuring-coding，最终每个OSD会有50-100个PG

HOW ARE PLACEMENT GROUPS USED（如何使用PLACEMENT GROUPS）

placement group (PG)聚集pool中的objects，因为以每个object为基础跟踪object placement和object metadata在计算上是昂贵的，即，具有数百万个object的系统无法实际以每个object为基础跟踪placement。

Ceph客户端将计算object应位于哪个placement group中。它通过hashing object ID并根据定义的pool中PG的数量和pool ID进行操作来实现此目的。有关详细信息，请参见 Mapping PGs to OSDs。

placement group中object的内容存储在一组OSD中。 例如，在大小为2的replicated pool中，每个placement group将在两个OSD上存储objects，如下所示。

如果OSD #2失败，则将另一个分配给Placement Group #1，并用OSD #1中所有objects的副本填充。 如果pool大小从2更改为3，则会将一个额外的OSD分配给该placement group，并将接收该placement group中所有objects的副本。

Placement groups不拥有OSD； 他们与同一资源pool甚至其他资源pool中的其他placement groups共享它。 如果OSD #2失败，则Placement Group #2还必须使用OSD #3恢复objects的副本。

当placement groups的数量增加时，将为新的placement groups分配OSD。CRUSH函数的结果也将更改，并且先前placement groups中的某些objects将被复制到新的placement groups中，并从旧的placement groups中删除。

PLACEMENT GROUPS TRADEOFFS（权衡）

数据持久性以及所有OSD之间的均匀分配都需要更多的placement groups，但应将其数量减少到最少，以节省CPU和内存。

DATA DURABILITY（数据持久性）

OSD发生故障后，数据丢失的风险会增加，直到完全恢复其中包含的数据为止。 假设有一种情况会导致单个placement group中的数据永久丢失：

  • OSD失败，并且它包含的object的所有副本均丢失。对于placement group中的所有objects，副本的数量突然从3个减少到2个。
  • Ceph通过选择一个新的OSD重新创建所有objects的第三个副本，开始对该placement group的恢复。
  • 在同一placement group内的另一个OSD在新OSD完全填充第三份副本之前发生故障。 这样，某些objects将只有一个幸存副本。
  • Ceph选择了另一个OSD并保持复制objects以恢复所需的副本数。
  • 在同一placement group中的第三个OSD在恢复完成之前发生故障。 如果此OSD包含object的唯一剩余副本，则它将永久丢失。

在三个副本pool中包含10个OSD和512个placement groups的集群中，CRUSH将为每个placement groups提供三个OSD。 最后，每个OSD将托管(512 * 3) / 10 = ~150 Placement Groups。 当第一个OSD发生故障时，以上情况将同时启动所有150个placement groups的恢复。

恢复的150个placement groups可能均匀分布在剩余的9个OSD上。 因此，每个剩余的OSD可能会将objects的副本发送给所有其他objects，并且还可能会接收一些要存储的新objects，因为它们已成为新placement group的一部分。

完成恢复所需的时间完全取决于Ceph集群的架构。 假设每个OSD由一台机器上的1TB SSD托管，并且所有OSD都连接到10Gb/s交换机，并且单个OSD的恢复在M分钟内完成。 如果每台计算机使用不带SSD journal的spinners和1Gb/s交换机的两个OSD，则速度至少要慢一个数量级。

在这种大小的集群中，placement groups的数量几乎对数据持久性没有影响。 可能是128或8192，恢复速度不会变慢或变快。

但是，将相同的Ceph集群增加到20个OSD而不是10个OSD可能会加快恢复速度，从而显着提高数据的持久性。 现在，每个OSD只能参与约75个placement groups，而不是只有10个OSD时的约150个placement groups，并且仍然需要全部19个剩余OSD执行相同数量的object副本才能恢复。 但是，如果10个OSD必须每个复制大约100GB，则现在它们必须每个复制50GB。 如果网络是瓶颈，恢复将以两倍的速度进行。 换句话说，当OSD数量增加时，恢复速度会更快。

如果该群集增长到40个OSD，则每个OSD将仅托管约35个placement groups。 如果OSD死亡，则恢复将保持更快的速度，除非它被另一个瓶颈阻塞。 但是，如果该集群增长到200个OSD，则每个OSD将仅托管约7个placement groups。 如果OSD死亡，则将在这些placement groups中的最多约21 (7 * 3)个OSD之间进行恢复：恢复将比有40个OSD时花费的时间更长，这意味着应增加placement groups的数量。

无论恢复时间有多短，第二个OSD在进行过程中都有可能发生故障。 在上述10个OSD群集中，如果它们中的任何一个失败，则〜17个placement groups（即，正在恢复〜150/9个placement groups）将只有一个幸存副本。 并且如果剩余的8个OSD中的任何一个失败，则两个placement groups的最后一个objects很可能会丢失（即〜17/8个placement groups，仅恢复了一个剩余副本）。

当群集的大小增加到20个OSD时，丢失三个OSD损坏的Placement Groups的数量将减少。 第二个OSD丢失将降级〜4个（即恢复到约75个/ 19个Placement Groups），而不是〜17个，而第三个OSD丢失则仅在它是包含尚存副本的四个OSD之一时才丢失数据。 换句话说，如果在恢复时间范围内丢失一个OSD的概率为0.0001％，则它从具有10个OSD的群集中的17 * 10 * 0.0001％变为具有20个OSD的群集中的4 * 20 * 0.0001％。

简而言之，更多的OSD意味着恢复更快，较低的级联故障风险，从而导致Placement Group的永久丢失。 就数据持久性而言，在少于50个OSD的群集中，具有512或4096个Placement Group大致等效。

注意：向集群添加的新OSD可能需要很长时间才能分配有分配给它的placement groups。 但是，不会降低任何object的质量，也不会影响集群中包含的数据的持久性。

OBJECT DISTRIBUTION WITHIN A POOL（pool内的object分布）

理想情况下，object均匀地分布在每个placement group中。 由于CRUSH计算每个object的placement group，但实际上不知道该placement group内每个OSD中存储了多少数据，因此placement group数与OSD数之比可能会显着影响数据的分布。

例如，如果在三个副本pool中有一个用于十个OSD的placement group，则仅使用三个OSD，因为CRUSH别无选择。 当有更多的placement group可用时，object更有可能在其中均匀分布。 CRUSH还尽一切努力在所有现有的placement group中平均分配OSD。

只要Placement Groups比OSD多一个或两个数量级，则分布应该均匀。 例如，用于3个OSD的256个Placement Groups，用于10个OSD的512或1024个Placement Groups等。

数据分布不均可能是由OSD与placement groups之间的比率以外的因素引起的。 由于CRUSH未考虑object的大小，因此一些非常大的object可能会造成不平衡。 假设有100万个4K object（总计4GB）均匀分布在10个OSD的1024个placement groups中。 他们将在每个OSD上使用4GB / 10 = 400MB。 如果将一个400MB object添加到pool中，则支持放置object的placement groups的三个OSD将填充400MB + 400MB = 800MB，而其余七个将仅占据400MB。

MEMORY, CPU AND NETWORK USAGE（内存，CPU和网络使用情况）

对于每个placement group，OSD和MON始终需要内存，网络和CPU，并且在恢复期间甚至更多。 通过对placement group内的object进行聚类objects来共享此开销是它们存在的主要原因之一。

最小化placement groups的数量可以节省大量资源。

CHOOSING THE NUMBER OF PLACEMENT GROUPS（选择PLACEMENT GROUPS的数量）

如果您有超过50个OSD，我们建议每个OSD大约有50-100个placement groups，以平衡资源使用，数据持久性和分发。 如果OSD少于50个，则最好在上述preselection中进行选择。 对于单个objects pool，可以使用以下公式获取baseline：

1
2
3
             (OSDs * 100)
Total PGs =  ------------
              pool size

pool size是replicated pools的副本数或erasure coded pools的K + M总和（由ceph osd erasure-code-profile get返回）。

然后，您应该检查设计Ceph集群的方式，以最大程度地提高数据持久性，对象分配并最小化资源使用。

结果应始终四舍五入到最接近的2的幂。

只有2的幂可以平衡placement groups之间的objects数量。 其他值将导致OSD上的数据分布不均。

例如，对于具有200个OSD和3个副本的pool大小的集群，您可以按以下方式估计PG的数量：

1
2
3
(200 * 100)
----------- = 6667. Nearest power of 2: 8192
     3

当使用多个data pools存储objects时，需要确保在每个pool的placement groups数量与每个OSD的placement groups数量之间取得平衡，以便获得合理的placement groups总数，从而为每个OSD提供合理的低偏差而不会增加系统资源的负担或使对等进程太慢。

例如，一个10个pool的集群，每个pool在十个OSD上具有512个placement groups，则总共有5120个placement groups分布在十个OSD上，即每个OSD 512个placement groups。 那不会使用太多资源。 但是，如果创建了1000个pool，每个pool有512个placement groups，则OSD将分别处理约50,000个placement groups，这将需要更多的资源和时间来进行对等。

您可能会发现PGCalc工具很有帮助。

SET THE NUMBER OF PLACEMENT GROUPS（设置PLACEMENT GROUPS数）

要设置pool中的placement groups数量，必须在创建pool时指定placement groups的数量。有关详细信息，请参见Create a Pool。 即使在创建pool之后，您也可以使用以下方法更改placement groups的数量：

1
ceph osd pool set {pool-name} pg_num {pg_num}

增加placement groups的数量之后，还必须增加placement（pgp_num）的数量，然后集群才能重新平衡。 pgp_num将是CRUSH算法考虑placement的placement groups的数量。 pg_num的增加会拆分placement groups，但是数据将不会迁移到较新的placement groups，直到placement的placement groups为止。 pgp_num增加了。 pgp_num应该等于pg_num。 要增加用于placement的placement groups的数量，请执行以下操作：

1
ceph osd pool set {pool-name} pgp_num {pgp_num}

当减少PG的数量时，将自动为您调整pgp_num。

GET THE NUMBER OF PLACEMENT GROUPS（获取PLACEMENT GROUPS数）

要获取pool中的placement groups数，请执行以下操作：

1
ceph osd pool get {pool-name} pg_num

GET A CLUSTER’S PG STATISTICS（获取集群的PG统计信息）

要获取集群中placement groups的统计信息，请执行以下操作：

1
ceph pg dump [--format {format}]

有效格式为plain（默认）和json。

GET STATISTICS FOR STUCK PGS（获取STUCK PGS的统计信息）

要获取所有处于指定状态的placement groups的统计信息，请执行以下操作：

1
ceph pg dump_stuck inactive|unclean|stale|undersized|degraded [--format <format>] [-t|--threshold <seconds>]

Inactive Placement groups无法处理读写，因为它们正在等待OSD包含最新数据。

Unclean Placement groups包含的object未复制所需的次数。。 他们应该正在恢复。

Stale Placement groups处于未知状态—承载这些PG的OSD在一段时间内未向monitor报告（由mon_osd_report_timeout配置）。

有效格式为plain（默认）和json。 阈值定义placement group在将其包括在返回的统计信息之前卡住的最小秒数（默认为300秒）。

GET A PG MAP

要获取特placement group map，请执行以下操作：

1
ceph pg map {pg-id}

例如：

1
ceph pg map 1.6c

Ceph将返回placement group map，placement group和OSD状态：

1
osdmap e13 pg 1.6c (1.6c) -> up [1,0] acting [1,0]

GET A PGS STATISTICS（获取PGS统计信息）

要检索特定placement group的统计信息，请执行以下操作：

1
ceph pg {pg-id} query

SCRUB A PLACEMENT GROUP

要scrub a placement group，请执行以下操作：

1
ceph pg scrub {pg-id}

Ceph检查primary和任何replica nodes生成的placement group中所有objects的目录进行比较，以确保没有丢失或不匹配的objects，并且它们的内容一致。 假设所有副本都匹配，则扫描可确保所有与snapshot-related的object metadata都是一致的。 通过日志报告错误。

要清理特定pool中的所有placement groups，请执行以下操作：

1
ceph osd pool scrub {pool-name}

PRIORITIZE BACKFILL/RECOVERY OF A PLACEMENT GROUP(S)（优先考虑PLACEMENT GROUP的BACKFILL/RECOVERY）

您可能会遇到这样的情况，即一堆placement groups需要recovery和/或backfill，并且某些特定的groups保存的数据比其他的更为重要（例如，那些PG可能保存正在运行的机器使用的images的数据，而其他PG可能由不活动的机器使用/较少的相关数据）。 在这种情况下，您可能希望优先考虑恢复这些groups，以便更早恢复存储在这些groups上的数据的性能和/或可用性。 为此（在backfill或recovery期间将特定的placement group(s)标记为优先），请执行以下操作：

1
2
ceph pg force-recovery {pg-id} [{pg-id #2}] [{pg-id #3} ...]
ceph pg force-backfill {pg-id} [{pg-id #2}] [{pg-id #3} ...]

这将导致Ceph首先在其他placement groups之前对指定的placement groups执行recovery或backfill。 这不会中断当前正在进行的backfill或recovery，但会导致尽快处理指定的PG。 如果您改变主意或优先考虑wrong groups，请使用：

1
2
ceph pg cancel-force-recovery {pg-id} [{pg-id #2}] [{pg-id #3} ...]
ceph pg cancel-force-backfill {pg-id} [{pg-id #2}] [{pg-id #3} ...]

这将从这些PG中删除“force” flag，并将以默认顺序对其进行处理。 同样，这不会影响当前正在处理的placement groups，只会影响仍在排队的placement groups。

recovery或backfill group后，将自动清除“force” flag。

同样，您可以使用以下命令强制Ceph首先对指定pool中的所有placement groups执行recovery或backfill：

1
2
ceph osd pool force-recovery {pool-name}
ceph osd pool force-backfill {pool-name}

或

1
2
ceph osd pool cancel-force-recovery {pool-name}
ceph osd pool cancel-force-backfill {pool-name}

如果您改变主意，则可以恢复到默认的recovery或backfill优先级。

请注意，这些命令可能会破坏Ceph内部优先级计算的顺序，因此请谨慎使用！ 特别是，如果您有多个当前共享相同底层OSD的pool，并且某些特定pool中的数据比其他pool更重要，我们建议您使用以下命令以更好的顺序重新排列所有pool的recovery/backfill优先级：

1
ceph osd pool set {pool-name} recovery_priority {value}

例如，如果您有10个pool，则可以将最重要的一个优先级设置为10，下一个9，等等。或者您可以不理会大多数pool，而说3个重要的pool分别设置为优先级1或优先级3、2、1。

REVERT LOST（永不消失）

如果集群丢失了一个或多个object，并且您决定放弃对丢失数据的搜索，则必须将unfound的object标记为lost。

如果已查询所有可能的位置并且仍然丢失了objects，则可能必须放弃丢失的objects。

当前唯一受支持的选项是“revert”，它可以回滚到该object的先前版本，或者（如果是新object）则完全忘记它。 要将“unfound”的object标记为“lost”，请执行以下操作：

1
ceph pg {pg-id} mark_unfound_lost revert|delete

重要说明：请谨慎使用此功能，因为它可能会使期望object存在的应用程序感到困惑。

Posted on Edited on

问题列表

Ceph升级（L to N）引发的问题

问题ID 1
问题出现版本 pre-14.2.3
问题现象 …
POOLS:
POOL ID STORED OBJECTS USED %USED MAX AVAIL
data 0 63 TiB 44.59M 63 TiB 30.21 48 TiB
…
but when one OSD was updated it changed to
POOLS:
POOL ID STORED OBJECTS USED %USED MAX AVAIL
data 0 558 GiB 43.50M
1.7 TiB 1.22 45 TiB
问题触发条件 1、从nautilus之前的集群进行了升级
2、然后，您提供一个或多个新的BlueStore OSD，或在升级的OSD上运行“ceph-bluestore-tool repair”。
问题原因 根本原因是，从Nautilus开始，BlueStore维护了每个池的使用情况统计信息，但是它需要对磁盘上的格式进行少量更改。
除非您运行ceph-bluestore-tool修复，否则升级后的OSD不会拥有新的统计信息。
问题在于，一旦* any * OSD报告了er-pool统计信息，mon就开始使用新的统计信息（而不是等到* all * OSD都在这样做）。
问题解决办法 为避免此问题，可以
1、升级后不要置备新的BlueStore OSD
2、更新所有OSD，以保留新的每个池统计信息。现有的BlueStore OSD可以通过以下方式转换：
systemctl stop ceph-osd@$N
ceph-bluestore-tool repair –path /var/lib/ceph/osd/ceph-$N
systemctl start ceph-osd@$N
请注意，FileStore根本不支持新版每个池统计信息，因此，如果集群中有文FileStore OSD，则没有解决方法。无需将文件存储OSD替换为bluestore。
修复程序[1]正在通过QA检查，将在14.2.3中出现； 它不会在14.2.2完整发布。
ceph-users地址 http://lists.ceph.com/pipermail/ceph-users-ceph.com/2019-July/035889.html
https://github.com/ceph/ceph/pull/28978
https://tracker.ceph.com/versions/574
备注
实践修复
问题修复版本（社区计划） 14.2.3
问题ID 2
问题出现版本 14.2.2
问题现象 Legacy BlueStore stats reporting detected on 6 OSD(s)
问题触发条件 1、从nautilus之前的集群进行了升级
问题原因
问题解决办法 systemctl stop ceph-osd@$OSDID
ceph-bluestore-tool repair –path /var/lib/ceph/osd/ceph-$OSDID
systemctl start ceph-osd@$OSDID
ceph-users地址 http://lists.ceph.com/pipermail/ceph-users-ceph.com/2019-July/036010.html
备注 可以静默告警 bluestore warn on legacy statfs = false
实践修复 [root@ceph1 ~]# systemctl stop ceph-osd@1.service
[root@ceph1 ~]# ceph-bluestore-tool repair –path /var/lib/ceph/osd/ceph-1/
2019-10-14 15:39:53.940 7f87c8114f80 -1 bluestore(/var/lib/ceph/osd/ceph-1) fsck error: legacy statfs record found, removing
2019-10-14 15:39:53.940 7f87c8114f80 -1 bluestore(/var/lib/ceph/osd/ceph-1) fsck error: missing Pool StatFS record for pool 2
2019-10-14 15:39:53.940 7f87c8114f80 -1 bluestore(/var/lib/ceph/osd/ceph-1) fsck error: missing Pool StatFS record for pool ffffffffffffffff
repair success
[root@ceph1 ~]# systemctl start ceph-osd@1.service
问题修复版本（社区计划）
问题ID 3
问题出现版本 14.2.2
问题现象 Legacy BlueStore stats reporting detected on 6 OSD(s)
问题触发条件 1、从nautilus之前的集群进行了升级
问题原因
问题解决办法 systemctl stop ceph-osd@$OSDID
ceph-bluestore-tool repair –path /var/lib/ceph/osd/ceph-$OSDID
systemctl start ceph-osd@$OSDID
ceph-users地址 http://lists.ceph.com/pipermail/ceph-users-ceph.com/2019-July/036002.html
备注 可以静默告警 bluestore warn on legacy statfs = false
实践修复
问题修复版本（社区计划）
问题ID 4
问题出现版本 14.2.4
问题现象 3 monitors have not enabled msgr2告警
问题触发条件 1、从nautilus之前的集群进行了升级
问题原因 messenger v2 protocol（msgr2）是Ceph’s on-wire protocol第二次主要修订。
问题解决办法 ceph mon enable-msgr2
systemctl restart ceph-mon@ceph1.service
ceph-users地址
备注
实践修复 ceph mon enable-msgr2
systemctl restart ceph-mon@ceph1.service
问题修复版本（社区计划）
问题ID 5
问题出现版本
问题现象
问题触发条件
问题原因
问题解决办法
ceph-users地址
备注
实践修复
问题修复版本（社区计划）
问题ID
问题出现版本
问题现象
问题触发条件
问题原因
问题解决办法
ceph-users地址
备注
实践修复
问题修复版本（社区计划）
问题ID
问题出现版本
问题现象
问题触发条件
问题原因
问题解决办法
ceph-users地址
备注
实践修复
问题修复版本（社区计划）

Posted on Edited on

WHAT IS IT

messenger v2 protocol（msgr2）是Ceph’s on-wire protocol第二次主要修订。它具有几个关键功能：

  • 安全模式，对通过网络传递的所有数据进行加密
  • 改进了authentication payloads的封装，未来可以集成新的authentication模式（例如Kerberos）
  • 改进了早期的advertisement和negotiation（协商）功能，支持未来的protocol（协议）修订

Ceph daemons现在可以绑定到多个端口，从而允许旧版Ceph客户端和支持v2的新客户端连接到同一集群。

默认情况下，monitors现在绑定到新的v2协议的新IANA分配端口3300（ce4h或0xce4），同时还绑定到旧的默认端口6789（旧的v1协议）。

ADDRESS FORMATS

在nautilus之前，所有网络地址都呈现为1.2.3.4:567/89012，其中有一个IP地址，一个端口和一个随机数，以唯一地标识网络上的客户端或daemon 。 从nautilus开始，我们现在具有三种不同的地址类型：

  • v2：v2:1.2.3.4:578/89012标识daemon绑定到新v2协议的端口

  • v1：v1:1.2.3.4:578/89012标识绑定到旧版v1协议的端口的daemon。 以前使用任何前缀显示的任何地址现在都显示为v1: address。

  • TYPE_ANY地址标识表示客户端可以支持两种协议版本。 在nautilus之前，客户端将显示为1.2.3.4:0/123456，其中端口0表示它们是客户端，并且不接受连接。 从Nautilus开始，这些客户端现在在内部由TYPE_ANY address表示，并且仍显示为不带前缀，因为它们可能会使用v2或v1协议连接到daemons，具体取决于daemons使用的协议。

因为daemons现在绑定到多个端口，所以现在用地址向量而不是单个地址来描述它们。 例如，在Nautilus cluster上dump monitor map会有如下输出：

1
2
3
4
5
6
7
8
9
[root@ceph1 ~]# ceph mon dump
epoch 1
fsid 50fcf227-be32-4bcb-8b41-34ca8370bd16
last_changed 2019-02-25 11:10:46.700821
created 2019-02-25 11:10:46.700821
min_mon_release 14 (nautilus)
0: [v2:10.0.0.10:3300/0,v1:10.0.0.10:6789/0] mon.foo
1: [v2:10.0.0.11:3300/0,v1:10.0.0.11:6789/0] mon.bar
2: [v2:10.0.0.12:3300/0,v1:10.0.0.12:6789/0] mon.baz

方括号或地址向量表示可以在多个端口（和协议）上访问同一daemon。如果可能，任何连接到该daemon的客户端或其他daemon都将使用v2协议（listed first）； 否则，它将返回到旧版v1协议。 旧版客户端将仅看到v1地址，并且将继续使用v1协议进行连接。

从Nautilus开始，mon_host配置选项和-m <mon-host>命令行选项支持相同的带括号的地址向量语法。

BIND CONFIGURATION OPTIONS

两个新的配置选项控制是否使用v1 and/or v2协议：

  • ms_bind_msgr1 [default: true]控制daemon是否绑定到使用v1协议的端口
  • ms_bind_msgr2 [default: true]控制daemon是否绑定到使用v2协议的端口

同样，两个选项控制是否使用IPv4和IPv6地址：

  • ms_bind_ipv4 [默认值：true]控制daemon是否绑定到IPv4地址
  • ms_bind_ipv6 [默认值：false]控制daemon是否绑定到IPv6地址

CONNECTION MODES

v2协议支持两种连接模式：

  • crc模式提供：

    • 建立连接时进行强大的初始身份验证（通过cephx，双方相互认证，防止中间人或窃听者进入）
    • CRC32C完整性检查，以防止由于flaky hardware或cosmic rays引起的位翻转

    crc模式不提供：

    • 加密（网络上的窃听者可以看到所有经过身份验证后的流量）
    • 免受恶意中间人的攻击（只要他们调整crc32c的值以使其匹配，就可以故意修改流量）

  • secure模式提供：

    • 建立连接时进行强大的初始身份验证（通过cephx，双方相互认证，防止中间人或窃听者进入）
    • 对所有认证后流量完全加密，包括加密完整性检查。

    在Nautilus中，secure模式使用AES-GCM stream cipher，这在现代处理器上通常非常快（例如，比SHA-256 cryptographic hash更快）。

CONNECTION MODE CONFIGURATION OPTIONS

对于大多数连接，有一些选项可以控制使用哪种模式：

  • ms_cluster_mode用于Ceph daemons之间的集群内通信的连接模式（或允许的模式）。 如果列出了多个模式，则首选第一个列出的模式。
  • ms_service_mode是客户端连接到群集时允许使用的模式的列表。
  • ms_client_mode是按优先顺序排列的连接模式列表，供客户端在与Ceph群集通信时使用（或允许）。

有一组并行的选项专门适用于monitors，允许管理员设置与monitors通信的不同（通常更安全）要求。

  • ms_mon_cluster_mode是monitors之间使用的连接模式（或允许的模式）。
  • ms_mon_service_mode是客户端或其他Ceph daemons连接到monitors时允许使用的模式的列表。
  • ms_mon_client_mode是按优先顺序排列的连接模式列表，供客户端或non-monitor daemons在连接monitors时使用。

TRANSITIONING FROM V1-ONLY TO V2-PLUS-V1

默认情况下，从Nautilus 14.2.z开始，ms_bind_msgr2为true。 但是，在monitors开始使用v2之前，只有有限的服务可以使用v2地址。

对于大多数用户，monitors已绑定到v1协议的默认旧版端口6789。 在这种情况下，启用v2非常简单：

1
ceph mon enable-msgr2

如果monitors绑定到non-standard端口，则需要为v2明确指定其端口。例如，如果monitors mon.a绑定到1.2.3.4:1111，并且您想要在端口1112上添加v2，则：

1
ceph mon set-addrs a [v2:1.2.3.4:1112,v1:1.2.3.4:1111]

monitors绑定到v2后，每个daemon将在下一次重新启动时开始使用v2地址。

UPDATING CEPH.CONF AND MON_HOST

在Nautilus之前，CLI用户或daemon通常将通过/etc/ceph/ceph.conf中的mon_host选项发现monitors。 此选项的语法从Nautilus开始扩展，以允许支持新的方括号列表格式。 例如，像这样的旧行：

1
mon_host = 10.0.0.1:6789,10.0.0.2:6789,10.0.0.3:6789

可以更改为：

1
mon_host = [v2:10.0.0.1:3300/0,v1:10.0.0.1:6789/0],[v2:10.0.0.2:3300/0,v1:10.0.0.2:6789/0],[v2:10.0.0.3:3300/0,v1:10.0.0.3:6789/0]

但是，使用默认端口（3300和6789）时，可以将其省略：

1
mon_host = 10.0.0.1,10.0.0.2,10.0.0.3

一旦在monitors上启用了v2，可能需要更新ceph.conf以不指定任何端口（这通常是最简单的），或者显式指定v2和v1地址。 但是请注意，Nautilus和更高版本才能理解新的带括号语法，因此请不要在尚未升级其ceph packages的主机上进行此更改。

当更新ceph.conf时，请注意新的ceph config generate-minimal-conf命令（它生成一个简单的配置文件，其中包含足够的信息来访问monitors）而ceph config assimilate-conf（将配置文件选项移动到monitors’配置数据库中）可能会有所帮助。 例如，：

1
2
3
4
5
6
7
8
# ceph config assimilate-conf < /etc/ceph/ceph.conf
# ceph config generate-minimal-config > /etc/ceph/ceph.conf.new
# cat /etc/ceph/ceph.conf.new
# minimal ceph.conf for 0e5a806b-0ce5-4bc6-b949-aa6f68f5c2a3
[global]
        fsid = 0e5a806b-0ce5-4bc6-b949-aa6f68f5c2a3
        mon_host = [v2:10.0.0.1:3300/0,v1:10.0.0.1:6789/0]
# mv /etc/ceph/ceph.conf.new /etc/ceph/ceph.conf

PROTOCOL

有关v2 wire protocol的详细说明，请参见msgr2 protocol。