ceph存储 ceph集群监视器设置

监视器配置参考

了解如何配置Ceph的监视器是建立一个可靠的Ceph的存储集群的重要组成部分。所有Ceph的存储集群中至少有一个监视器。监视器配置通常是一致的，但你可以添加，删除或替换集群中的一个监视器。获取更多详细信息，请参阅Adding/Removing a Monitor 和 Add/Remove a Monitor (ceph-deploy) 

背景

Ceph的监视器保持在集群映射中的“主复本”，这意味着只需通过连接到一个Ceph的监视器和检索当前集群映射，一个Ceph的客户端可以决定Ceph的所有监视器位置，Ceph的OSD守护进程和Ceph的元数据服务器。在Ceph的客户端可以读取或写入ceph的OSD守护或Ceph的元数据服务器之前，它们必须连接到一个Ceph的监视器。Ceph的客户端可以使用集群映射的当前副本和CRUSH算法来计算出任何对象的位置。计算对象位置的能力允许Ceph的客户直接与Ceph的OSD守护进程通讯，这是一个对于Ceph的高可扩展性和性能非常重要的方面。 更多详细信息，请参阅eScalability and High Availability 。

Ceph的监视器的主要作用是维持集群映射的主副本。Ceph的监视器还提供了身份验证和日志记录服务。Ceph的监视器记录在监视器服务所有更改到一个单一的Paxos的实例，并且Paxos为了一致性记录一个键/值的存储变化。Ceph的监视器在同步操作时可以查询大多数最新版本的集群映射。Ceph的监视器利用的键/值存储的快照和迭代器（使用leveldb），执行全局存储的同步。

已过时因为版本: 0.58

在Ceph的0.58或更早版本时，Ceph的监视器为每个服务使用Paxos的实例并且作为一个文件存储集群。

集群映射

 

群集映射是一个复合的映射，包括监视器的映射，OSD的映射，配置组映射和元数据服务器映射。集群映射跟踪一些重要的事情：在Ceph的存储集群中有哪些进程，Ceph的存储集群中哪些进程是up状态并且在运行或是down状态，配置组是否是有效或无效，干净，或在某些其他真实反映群集的当前状态的状态，比如总的存储空间量，以及使用的存储量。

当集群状态有一个显着的变化，比如，Ceph的OSD守护停止，安置组变成退化的状态等，集群映射被更新以反映当前的集群状态。此外，Ceph的监视器也保存了集群之前状态的历史。OSD映射，监控映射，配置组映射和元数据服务器映射各自保持自己的映射版本的历史。我们把每一个版本的称之为一个“epoch”。

当操作你的Ceph存储集群时，保持跟踪这些状态是你的系统管理任务的重要组成部分。获取更多详细信息，请参阅 Monitoring a Cluster和 Monitoring OSDs and PGs 。

集群的额定数量

 

我们的入门部分提供了一个简单的Ceph的配置文件，在测试集群中提供了一台监视器。在使用单个监视器的情况下，群集将会运行得很好；然而，单一一台监视器是一个单点故障。为了确保在生产中Ceph存储集群的高可用性，你应该使用多监视器运行Ceph为了一个单点故障不会带来整个群集的崩溃。

当Ceph的存储集群为了高可用性运行多个Ceph的监视器时，Ceph的监视器使用Paxos建立主群集映射一致性。一个一致性需要许多正在运行的监视器需建立一个额定数量来保持群集映射的一致性（比如1；3个中选2；5个中选3个；6个中选4个等）

一致性

 

当你在你的Ceph的配置文件中添加监视器的设置时，你需要知道CEPH监视器的一些架构方面。Ceph严格的规定Ceph监视器一致性要求当在集群中发现另一个Ceph的监视器。因此，Ceph的客户端和其他Ceph的守护进程使用Ceph的配置文件发现监视器，监视器使用监视器映射（monmap），而不是Ceph的配置文件互相发现对方。

当在Ceph的存储集群中发现其他的Ceph监视器时，一个Ceph的监视器总是引用monmap的本地副本。使用monmap，而不是Ceph的配置文件避免可能破坏集群的错误（如当指定监视器的地址或端口时，在ceph.conf输入）。因为监视器使用monmap为了发现并且他们与客户端和其他的Ceph守护共享monmap，monmap提供监视与严格的保证，所以他们的一致性是有效的。

严格的一致性，也适用于更新monmap。随着Ceph的监视器上任何其他的更新，monmap的改变通过称为Paxos分布式一致性算法。Ceph的监视器必须与每次更新的monmap保持一致性，如添加或删除一个Ceph的监视器，确保在额定数量中的每个监视器具有相同版本的monmap。更新对于monmap是增加的为的是使Ceph的监视器保持一致的最新版本，以及一组以前的版本。保存历史记录使有一个旧版本的monmap的Ceph监视器，变成与Ceph的存储集群的当前状态一样。

如果Ceph的监视器通过Ceph的配置文件发现对方，而不是通过monmap，将会引入额外风险，因为Ceph的配置文件不会自动更新和分布。Ceph的监视器可能会在无意中使用较旧版本的Ceph的配置文件，没有发现Ceph的监视器超出额定数量，或发现paxos是不能够准确地确定系统的当前状态的情况。

引导监视器

 

在大多数配置和部署的情况下，部署Ceph的工具可以通过为你生成监视映射帮助引导Ceph监视器（例如，mkcephfs, ceph-deploy等）。Ceph的监视器需要一些明确的设置：

Filesystem ID: 文件系统ID：FSID是对象存储的唯一标识符。既然你可以在同一硬件上运行多个集群，引导监视器时，你必须指定对象存储的唯一ID。部署工具通常都这样做(比如, mkcephfs 或ceph-deploy 能调用类似 uuidgen的工具), 但你也可以手动指定 FSID
Monitor ID: 监视器ID是分配给集群内的每个监视器一个唯一的ID。它是一个字母数字值，并按照规定，标识符通常跟着一个字母增量(比如, a, b,等). 这可以被设置在Ceph的配置文件中 (比如, [mon.a], [mon.b]``,等),通过配置工具，或使用 ceph 命令行.
Keys: 监视器必须有秘钥。类似mkcephfs 或 ceph-deploy 的部署工具通常为了做了这些，但你也可以静态的自己执行这些。获取更多详细信息，请参阅 Monitor Keyrings
获取更多关于 bootstrapping的详细信息，请参阅 Bootstrapping a Monitor.

配置监控器

要应用配置设置到整个集群，进入配置设置下的 [global]。要配置设置应用于您的集群中的所有监视器, 进入配置设置下的[mon]. 要配置设置应用于指定的监视器，指定监视的实例(比如, [mon.a]). 按照惯例，监视器实例名称用字母符号。

[global]
[mon]
[mon.a]
[mon.b]
[mon.c]

最低配置

 

在Ceph的配置文件中的Ceph的监控器最低限度监控器设置，包括每个监控器的主机名和地址。您可以在 [mon]或整个特定的监视器下配置。

[mon] mon host = hostname1,hostname2,hostname3 mon addr = 10.0.0.10:6789,10.0.0.11:6789,10.0.0.12:6789
[mon.a] host = hostname1 mon addr = 10.0.0.10:6789

获取更多详细信息，请参阅 Network Configuration Reference

注意:这个监控器最低配置假定一个部署工具生成 fsid 和 mon。你需要自己生成秘钥

一旦你部署Ceph的集群，你不应该改变监控器的IP地址。但是，如果你决定改变监控器的IP地址，则必须遵循特定的程序。获取更多详细信息，请参阅 Changing a Monitor’s IP Address 。

集群ID

 

每个Ceph的存储集群都有一个唯一的标识符 (fsid)。如果指定的话，它通常出现 [global] 部分的配置文件下。部署工具生成的FSID并将其存储在监视器映射上，所以值可能不会出现在配置文件中。FSID使得它在同一硬件上的多个集群可以运行守护程序。

fsid

描述: The cluster ID. One per cluster.
类型: UUID
是否必须: Yes.
默认: N/A. May be generated by a deployment tool if not specified.
注意:如果你使用部署工具为你设置这个值，不要再设置这个值了。

初始成员

 

我们建议运行生产Ceph的存储集群至少有三个Ceph的监视器，以确保高可用性。当你运行多个监视器时，你可以指定初始监控器必须是集群的成员，为了建立额定数量。这可能会减少群集上线所花费的时间。

[mon] mon initial members = a,b,c
mon initial members

描述 在集群启动过程中的初始监视器的ID。如果已指定，Ceph的监视器需要一个奇数，以形成初始的额定数量 (比如, 3).
类型: String
默认: 无

注意:你的集群上的许多监视器必须能相互通讯为了建立一个额定数量。你可以减少监视器初始成员的数量来使用这个设置建立一个额定数量。

数据

Ceph提供了一个Ceph监控器存储数据默认的路径。为了使Ceph存储集群在生产环境下获得最佳性能,我们推荐在单独的主机运行Ceph监视器并且与Ceph OSD守护进程分开。Ceph监视器做大量的 fsync()工作,它可以减少Ceph OSD守护进程的工作负载。

在Ceph0.58和更早的版本中,Ceph监控器在文件中存储数据。这种方法允许用户用常见的工具如ls和cat检查监控数据。然而,它不提供强有力的一致性。

在Ceph0.59和之后的版本中,Ceph监控器存储数据作为键/值对。Ceph监视器需要ACID事务。使用一个数据存储防止监控器通过Paxos运行损坏的版本中恢复,它能够在一个单一的atomic batch使用多个修改操作等优点。
一般来说,我们不建议改变默认的数据位置。如果你修改默认位置,我们建议你通过设置在 [mon]部分的配置文件让它与Ceph监视器。

mon data

描述: 监视器数据的位置
类型: String
默认: /var/lib/ceph/mon/$cluster-$id

存储容量

当Ceph的存储集群接近其最大容量时 (比如, mon osdfull ratio), Ceph通过Ceph的OSD守护阻止你写入或读取程序作为一种安全措施，以防止数据丢失。因此，让生产环境下的Ceph的存储集群充分发挥其使用率不是一个好的做法，因为它牺牲高可用性。默认的全部使用率是0.95，或95％的产能。这是一个为拥有少数的OSD测试群集非常积极的设置。

建议:当监视你的集群时，出现将近满 使用率的警告。 这意味着如一个或多个的OSD失败，部分的OSD的故障可能会导致在一个临时的服务中断。考虑增加更多的OSD来增加存储容量。

一个常见的测试集群情况涉及系统管理员从Ceph的存储集群中删除Ceph的OSD守护为了监视集群从新平衡;然后，移除另一个Ceph的OSD守护程序等，直到Ceph的存储集群达到满使用率并且锁定。我们建议做一点容量规划，甚至是测试群集。规划使您能够衡量你将需要多少备用容量，以维持高可用性。理想情况下，你要计划Ceph的OSD守护故障集群可以恢复到一个 active + clean 状态同时没有立即取代那些Ceph的OSD守护。您可以运行一个集群在一个active + degraded 状态，但在正常工作条件下，这是不理想的。

下图描述了一个简单的含有33个Ceph的节点，每台主机上有Ceph的OSD的守护程序，每个Ceph的OSD守护程序读取和写入到3TB硬盘中。因此，这个示范Ceph的存储集群有一个最大的实际容量99TB。使用0.95的 mon osd full ratio, 如果Ceph存储集群下降到5TB的剩余容量，集群将不会允许Ceph的客户端读取和写入数据。所以Ceph的存储集群的操作能力是95TB，不是99TB。

一个或两个OSD失败，这是正常的在这样一个集群。一个那么频繁,但合理的情况包括机架的路由器或供电失败,这同时毁坏多个OSD。 (比如, OSDs 7-12). 在这种情况下,如果这意味着在短期内添加一些主机与额外OSD，你应该仍然在努力争取一个可以保持操作,甚至实现一个active + clean 状态的集群。如果你的性能利用率太高,你可能不会丢失数据,但你仍然可以牺牲数据可用性而解决停机故障域内如果集群的性能利用率超过完整的使用率。出于这个原因,我们建议至少一些粗略的性能计划。

分辩你的集群中的两个成员:

1.OSD数量
2.集群的总体能力

如果你以在你的集群中OSD的数量划分你的集群的总体性能，你会发现在OSD集群中的平均值容量.考虑用OSD的数量乘你预计的这个数字，这将会在正常操作中同时失效(一个相对小的数字)。. 最后乘以集群性能完全使用率到达最大操作能力;然后,从你预期的OSD减去数据量未能得出一个合理的完整率。重复上述过程具有更高数量的OSD失败 (比如, a rack of OSDs) 为了得出一个合理的数字接近充分比率

[global] mon osd full ratio = .80 mon osd nearfull ratio = .70

mon osd full ratio

描述: 在一个OSD满之前使用的磁盘空间的百分比
类型: Float
默认: .95

mon osd nearfull ratio

描述: 在一个OSD将要满之前使用的磁盘空间的百分比
类型: Float
默认: .85

建议:如果一些OSD将要满了，不过其他的有大量的性能。你可能在将要满的OSD上有一个关于CRUSH负载的问题。

HEARTBEAT

 

Ceph监视器通过要求每个OSD、其他相邻OSD的状态的报告了解集群,Ceph为监控/OSD交互提供合理的默认设置;然而,您可以根据需要修改它们。获取详细信息，请参阅 Monitor/OSD Interaction 。

 

监视器同步存储

 

当你在生产环境上运行多个监视器集群（推荐），每个监视器检查邻近的监视器，看是否有最新版本的集群映射（例如，一个在邻近的监视器映射与一个或多个EPOCH数字高于最当前EPOCH的映射即时监控）。每隔一段时间，在集群中的一台监视器可能落后于其他监视器的点，这导致它必须先离开额定数量，同步检索有关群集的最新信息，然后重新加入额定数量。对于同步的目的，监视器可能担任下列三种角色之一：

Leader: 第一台实现集群映射最近Paxos版监视器
Provider: 具有最新版本的集群映射是监视器，但不是第一个实现的最新版本。
Requester: 一台已经落后leader，必须同步以检索有关群集的最新信息，才可以重新加入额定数量的监视器
这些角色使leader委派同步职责至provider，这防止leader超载来提高性能的同步请求。在下面的图中，requester了解到它已经落后于其他监视器。并且要求leader需要同步，leader告诉requester与provider同步。

同步总是发生在一个新的监视器加入集群时。在运行操作过程中，监视器可能在不同的时间会收到更新的集群映射。这意味着leader和provider的角色，可能从一台监视器迁移到另一个。如果发生这种情况，而同步（例如，provider落后于leader），provider可以终止同步请求者。

同步完成后，Ceph的需要修剪整个集群。修剪需要配置组处于 active + clean的状态

mon sync trim timeout

描述:
类型: Double
默认: 30.0

mon sync heartbeat timeout

描述:
类型: Double
默认: 30.0

mon sync heartbeat interval

描述:
类型: Double
默认: 5.0

mon sync backoff timeout

描述:
类型: Double
默认: 30.0

mon sync timeout

描述:
类型: Double
默认: 30.0

mon sync max retries

描述:
类型: Integer
默认: 5

mon sync max payload size

描述: 同步负载的最大量
类型: 32-bit Integer
默认: 1045676

mon accept timeout

描述 Leader会等待Requester接收Paxos更新的秒数。 它也可以用来在Paxos的用于类似目的的恢复阶段
类型: Float
默认: 10.0

paxos propose interval

描述: 提出映射更新前收集更新时间间隔。
类型: Double
默认: 1.0

paxos min wait

描述: 在一段时间的闲置后收集更新的最短的时间。
类型: Double
默认: 0.05

paxos trim tolerance

描述: 修整之前容许额外的提议数
类型: Integer
默认: 30

paxos trim disabled max versions

描述: 允许不被修剪通过的最大版本数。
类型: Integer
默认: 100

mon lease

描述: 监视器的版本的租用长度（以秒计算）
类型: Float
默认: 5

mon lease renew interval

描述: 其他监视器的租用leader的时间间隔（以秒计算）。
类型: Float
默认: 3

mon lease ack timeout

描述: leader将提供provider租用扩展等待的秒数。the lease extension.
类型: Float
默认: 10.0

mon min osdmap epochs

描述: 一直保存最小OSD映射epochs的数字
类型: 32-bit Integer
默认: 500

mon max pgmap epochs

描述: 监视器应该保存PG 映射epochs的最大数.
类型: 32-bit Integer
默认: 500

mon max log epochs

描述: 监视器应该保存PG 映射epochs日志的最大数
类型: 32-bit Integer
默认: 500

SLURP

在Ceph0.58和更早版本，当一个Paxos的服务的移动超越给定数量的版本，Ceph触发slurp机制，建立连接与额定数量leader和获得leader拥有的已移动每一项版本。在CEPH 0.59及更高版本中， slurp将无法工作，因为有一个所有服务单Paxos的实例。

废弃了，因为0.58版本。
paxos max join drift

描述: 迭代之前，我们必须首先同步监控数据存储最大parox数。
类型: Integer
默认: 10

mon slurp timeout

描述: 在进程中止并且监视器重启前，监视器使用slurp的恢复的秒数。
类型: Double
默认: 10.0

mon slurp bytes

描述: slurp 的消息限制到指定的字节数.
类型: 32-bit Integer
默认: 256 * 1024

CLOCK

clock offset

描述: 多少抵消系统时钟。为了获取细节，请参阅见 Clock.cc
类型: Double
默认: 0
废弃了，因为0.58版本。

mon tick interval

描述: 监视器的刻度间隔（以秒为单位）。.
类型: 32-bit Integer
默认: 5

mon clock drift allowed

描述: 允许监视器之间的时钟漂移的秒数。
类型: Float
默认: .050

mon clock drift warn backoff

描述: 退避时钟漂移警告的指数
类型: Float
默认: 5

mon timecheck interval

描述: 检查的时间间隔（时钟漂移检查）的leader，以秒为单位。
类型: Float
默认: 300.0

CLIENT

mon client hung interval

描述: 客户端每N秒将尝试一种新的监视器，直至它建立了一个连接。
类型: Double
默认: 3.0

mon client ping interval

描述: 客户端每N秒将ping监视器
类型: Double
默认: 10.0

mon client max log entries per message

描述: 监视器将产生每个客户端的消息最大的日志条目数
类型: Integer
默认: 1000

mon client bytes

描述: 允许在存储器中（以字节为单位）的客户端消息的数据的量。
类型: 64-bit Integer Unsigned
默认: 100ul << 20

杂项

mon max osd

描述: 集群中允许的最大数量的OSD。
类型: 32-bit Integer
默认: 10000

mon globalid prealloc

描述: 预分配给集群中的客户端和守护的全局ID。
类型: 32-bit Integer
默认: 100

mon sync fs threshold

描述: 写入指定数量的对象时，与文件系统同步。将它设置为0来禁用它。
类型: 32-bit Integer
默认: 5

mon subscribe interval

描述: 刷新间隔（秒）订阅。订阅机制能够获得集群映射和日志信息。
类型: Double
默认: 300

mon stat smooth intervals

描述: Ceph在最后N个PG映射的平滑统计。
类型: Integer
默认: 2

mon probe timeout

描述: 在找同等引导之前监视器将等待的秒数。
类型: Double
默认: 2.0

mon daemon bytes

描述: 消息的元数据服务器和OSD信息（字节）的内存容量。
类型: 64-bit Integer Unsigned
默认: 400ul << 20

mon max log entries per event

描述: 每个事件日志条目的最大数量。
类型: Integer
默认: 4096