注意

本文档适用于 Ceph 的开发版本。

Messenger v2

它是什么

Messenger v2 协议（或 msgr2）是 Ceph 在线协议的第二个主要修订版。它带来了几个关键功能：

  • 一种*安全*模式，可加密所有通过网络传输的数据

  • 改进了身份验证负载的封装，使得未来可以集成新的身份验证模式，如 Kerberos

  • 改进了早期的功能公告和协商，为未来的协议修订提供了可能性

Ceph 守护程序现在可以绑定到多个端口，允许传统的 Ceph 客户端和支持 v2 的新客户端连接到同一个集群。

默认情况下，监视器现在为新的 v2 协议绑定到新的 IANA 分配端口 3300 (ce4h 或 0xce4)，同时为传统的 v1 协议绑定到旧的默认端口 6789。

地址格式

在 Nautilus 之前，所有网络地址都以 1.2.3.4:567/89012 的形式呈现，其中包含 IP 地址、端口和用于唯一标识网络上客户端或守护程序的随机数。从 Nautilus 开始，我们现在有三种不同的地址类型：

  • v2: v2:1.2.3.4:578/89012 标识一个绑定到使用新 v2 协议的端口的守护程序

  • v1: v1:1.2.3.4:578/89012 标识一个绑定到使用传统 v1 协议的端口的守护程序。以前显示的没有任何前缀的地址现在都显示为 v1: 地址。

  • TYPE_ANY any:1.2.3.4:578/89012 标识一个可以讲任一版本协议的客户端。在 Nautilus 之前，客户端会显示为 1.2.3.4:0/123456，其中端口 0 表示它们是客户端且不接受传入连接。从 Nautilus 开始，这些客户端现在在内部由 TYPE_ANY 地址表示，并且仍然显示为没有前缀，因为它们可以根据守护程序使用的协议（v2 或 v1）连接到守护程序。

由于守护程序现在绑定到多个端口，因此它们现在由地址向量而非单个地址描述。例如，在 Nautilus 集群上转储监视器映射现在包括以下行：

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

方括号列表或地址向量意味着可以通过多个端口（和协议）访问同一个守护程序。连接到该守护程序的任何客户端或其他守护程序如果可能，将使用 v2 协议（首先列出）；否则它将回退到传统的 v1 协议。传统客户端将只看到 v1 地址，并继续像以前一样使用 v1 协议连接。

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

绑定配置选项

两个新的配置选项控制是否使用 v1 和/或 v2 协议

  • ms_bind_msgr1 [default: true] 控制守护程序是否绑定到使用 v1 协议的端口

  • ms_bind_msgr2 [default: true] 控制守护程序是否绑定到使用 v2 协议的端口

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

  • ms_bind_ipv4 [default: true] 控制守护程序是否绑定到 IPv4 地址

  • ms_bind_ipv6 [default: false] 控制守护程序是否绑定到 IPv6 地址

连接模式

v2 协议支持两种连接模式

  • crc 模式提供

    • 连接建立时的强初始身份验证（使用 cephx，对双方进行相互身份验证，防止中间人或窃听者攻击），以及

    • crc32c 完整性检查，以防止因硬件故障或宇宙射线引起的位翻转

    crc 模式*不*提供

    • 保密性（网络上的窃听者可以看到所有经过身份验证后的流量）或

    • 防止恶意中间人（他们可以故意修改流量，只要他们小心调整 crc32c 值以匹配）

  • secure 模式提供

    • 连接建立时的强初始身份验证（使用 cephx，对双方进行相互身份验证，防止中间人或窃听者攻击），以及

    • 对所有经过身份验证后的流量进行完全加密，包括加密完整性检查。

    在 Nautilus 中，安全模式使用 AES-GCM 流密码，这在现代处理器上通常非常快（例如，快于 SHA-256 加密哈希）。

连接模式配置选项

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

ms_cluster_mode

用于 Ceph 守护程序之间集群内通信的连接模式（或允许的模式）。如果列出多种模式，则优先使用首先列出的模式。

类型:

str

默认值:

crc secure

另请参阅:

ms_service_mode, ms_client_mode

ms_service_mode

客户端连接到集群时允许使用的模式列表。

类型:

str

默认值:

crc secure

另请参阅:

ms_cluster_mode, ms_client_mode

ms_client_mode

客户端在与 Ceph 集群通信时使用（或允许）的连接模式列表，按偏好顺序排列。

类型:

str

默认值:

crc secure

另请参阅:

ms_cluster_mode, ms_service_mode

有一组平行的选项专门应用于监视器，允许管理员对与监视器的通信设置不同的（通常更安全）要求。

ms_mon_cluster_mode

监视器之间使用的连接模式（或允许的模式）。

类型:

str

默认值:

secure crc

另请参阅:

ms_mon_service_mode, ms_mon_client_mode, ms_service_mode, ms_cluster_mode, ms_client_mode

ms_mon_service_mode

客户端或其他 Ceph 守护程序连接到监视器时允许使用的模式列表。

类型:

str

默认值:

secure crc

另请参阅:

ms_service_mode, ms_mon_cluster_mode, ms_mon_client_mode, ms_cluster_mode, ms_client_mode

ms_mon_client_mode

客户端或非监视器守护程序连接到监视器时使用的连接模式列表，按偏好顺序排列。

类型:

str

默认值:

secure crc

另请参阅:

ms_mon_service_mode, ms_mon_cluster_mode, ms_service_mode, ms_cluster_mode, ms_client_mode

压缩模式

v2 协议支持两种压缩模式

  • force 模式提供

    • 在多可用区部署中，压缩 OSD 之间的复制消息可以节省延迟。

    • 在公共云中，跨可用区通信费用昂贵。因此，最小化消息大小可以降低云提供商的网络成本。

    • 在 AWS（可能还有其他公共云）上使用实例存储时，具有 NVMe 的实例提供的网络带宽相对于设备带宽较低。在这种情况下，NW 压缩可以提高整体性能，因为这显然是瓶颈。

  • none 模式提供

    • 消息不经过压缩传输。

压缩模式配置选项

对于所有连接，有一个选项可以控制安全模式下的压缩使用

ms_compress_secure

结合加密和压缩会降低对等方之间消息的安全性。如果同时启用加密和压缩，压缩设置将被忽略，消息将不被压缩。可以使用此设置覆盖此行为。

类型:

bool

默认值:

false

另请参阅:

ms_osd_compress_mode

有一组平行的选项专门应用于 OSD，允许管理员对 OSD 之间的通信设置不同的要求。

ms_osd_compress_mode

在 Messenger 中用于与 OSD 通信的压缩策略

类型:

str

默认值:

none

有效选项:

  • none

  • force

另请参阅:

ms_compress_secure

ms_osd_compress_min_size

有资格进行在线压缩的最小消息大小

类型:

uint

默认值:

1Ki

另请参阅:

ms_osd_compress_mode

ms_osd_compression_algorithm

与 OSD 连接的压缩算法，按偏好顺序排列。尽管默认值设置为 snappy，但也可以接受列表（如 snappy zlib zstd 等）。

类型:

str

默认值:

snappy

另请参阅:

ms_osd_compress_mode

从仅 v1 迁移到 v2 加 v1

默认情况下，从 Nautilus 14.2.z 开始，ms_bind_msgr2 为 true。然而，在监视器开始使用 v2 之前，只有有限的服务会开始公告 v2 地址。

对于大多数用户来说，监视器绑定到 v1 协议的默认传统端口 6789。在这种情况下，启用 v2 就像这样简单

ceph mon enable-msgr2

如果监视器绑定到非标准端口，则需要显式指定一个额外的 v2 端口。例如，如果您的监视器 mon.a 绑定到 1.2.3.4:1111，并且您想在端口 1112 上添加 v2

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

一旦监视器绑定到 v2，每个守护程序将在下次重新启动时开始公告 v2 地址。

更新 ceph.conf 和 mon_host

在 Nautilus 之前，CLI 用户或守护程序通常通过 /etc/ceph/ceph.conf 中的 mon_host 选项发现监视器。从 Nautilus 开始，此选项的语法已扩展以支持新的方括号列表格式。例如，旧行如下

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

可以更改为

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），则可以省略它们

mon_host = 10.0.0.1,10.0.0.2,10.0.0.3

一旦在监视器上启用 v2，可能需要更新 ceph.conf，要么指定不带端口（这通常最简单），要么显式指定 v2 和 v1 地址。但是请注意，新的方括号语法只有 Nautilus 和更高版本才能理解，因此不要在尚未升级 ceph 包的主机上进行此更改。

在更新 ceph.conf 时，请注意新的 ceph config generate-minimal-conf 命令（它生成一个只有足够信息来访问监视器的最小配置D文件）和 ceph config assimilate-conf 命令（它将配置文件选项移入监视器的配置数据库）可能会有所帮助。例如，

# 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

协议

有关 v2 在线协议的详细描述，请参阅 msgr2 协议（msgr2.0 和 msgr2.1）。

由 Ceph 基金会为您呈现

Ceph 文档是由非营利性 Ceph 基金会 资助和托管的社区资源。如果您希望支持这项工作和我们的其他努力，请考虑 立即加入。