Ceph配置——5.Ceph-MON设置

时间:2022-05-03 12:46:55

MONITOR CONFIG参考

了解如何配置Ceph的MON是建立一个可靠的Ceph的存储集群的重要组成部分。所有Ceph的存储集群至少有一MON。MON配置通常相当一致,但你可以添加,删除或替换集群中的一个MON。

BACKGROUND

Ceph的MON是一个集群映射图的“主副本”,Ceph的客户端可以掌握Ceph-MON、Ceph的OSD守护进程,和Ceph的元数据服务器的位置,它只需通过连接到一个Ceph的MON。 Ceph的客户端可以读取或写入Ceph-OSD守护或Ceph的元数据服务器,它们必须连接到一个Ceph的MON先。用集群的当前映射图和CRUSH算法, Ceph的客户端可以计算出任何对象的位置。计算对象位置的能力允许Ceph的客户直接对话Ceph的OSD守护进程,这是一个非常重要的方面,对Ceph的高可扩展性和性能来说。

Ceph的MON的主要作用是维持集群的主副本映射图。 Ceph的MON还提供了身份验证和日志记录服务。 Ceph的MON能把MON的所有更改写入到一个单一的Paxos实例中,然后Paxos把变化写入到一个键/值中,为了保持较强的存储一致性。 Ceph的MON,可以查询同步操作时的最新版本的映射图。 Ceph的MON利用的键/值存储快照和迭代器( leveldb ) ,执行OSD的同步。

 Ceph配置——5.Ceph-MON设置

已过时,因为版本版本:0.58

Ceph的0.58或更早版本, Ceph的MON为每个服务用Paxos的实例和把每个映射图存储为一个文件。

集群映射

集群映射是一个复合映射,包括MON映射,OSD的映射图,组映射和元数据服务器映射。集群地图跟踪一些重要的事情:哪些流程是Ceph的存储集群,他们在Ceph的存储集群中的过程是向上、运行或向下;组群是活跃或不活跃,清洁,或在某些其他状态;还有一些真实反映群集的当前状态,如总的存储空间量,使用的存储量。

当集群状态有一个显着的变化, Ceph的OSD守护挂掉,安置群组落入降级状态等,集群映射图被更新,以反映当前的集群状态。此外, Ceph的MON也保持了历史的集群前状态。 OSD的映射图,MON的映射图,安置组的映射图和元数据服务器映射,他们耶哦度各自保持自己的历史映射图。我们把每一个版本的“划时代”。

当操作Ceph的存储集群,跟踪这些状态是您的系统管理任务的重要组成部分。请参阅更多详细信息,监视群集和监测的OSD​​和PG 。

MONITOR法定数量

我们的入门部分提供了一个简单的Ceph的配置文件,在测试集群仅用了一台MON。群集将会运行得很好,但是一个MON,一个MON,就是一个单点故障。为了确保在生产Ceph的存储集群的高可用性,你应该使用多MON运行的Ceph,防止单一MON造成的失败毁了整个集群。

Ceph的存储集群,当运行多个高可用性Ceph的MON, Ceph-MON使用Paxos去建立一个关于主集群映射的共识。一个共识需要一个大量的MON运行达成共识在有关集群映射图方面(如1 2 3 3 5 4 6等),建立仲裁。

一致性

当您添加MON的设置到您的Ceph的配置文件,你需要知道CEPH-MON的一些结构方面的知识。 Ceph的实行严格的一致性要求,发现集群内的另外一个CEPH-MON时。然而, Ceph的客户和其他Ceph的守护进程使用Ceph的配置文件中发现MON,MON之间发现对方使用的是mon-map ,而不是Ceph的配置文件。

Ceph-MON总是指时monmap的本地副本,当发现Ceph的存储集群中的其他Ceph-MON时。 使用Ceph-Map,而不是Ceph的配置文件,这可以打破集群的错位(如错别字ceph.conf指定显示器的地址或端口时) 。因Monitors使用mon maps查找其他monitors的,他们与客户和其他的Ceph守护进程共享monmaps,提供给monitors的monmap必须有严格的保证,他们的共识是有效的。

严格的一致性,也适用于到更新monmap 。 Ceph的Monitors上对monmap的任何其他更新、改变始终通过运行称为Paxos分布式算法 达成共识的。 Ceph的MON必须同意每次更新的monmap ,如添加或删除一个Ceph的监视器monitor,确保合法数量的每个显示器具有相同的版本monmap。维护有一个旧版本monmap的CEPH-MON,必须Ceph的存储集群的当前状态。

Ceph-Monitor如果是用Ceph的配置文件,而不是通过通过monmap发现对方的 ,将会引入额外风险,因为Ceph的配置文件不会自动更新和分发。 Ceph-Monitor可能会在无意中使用较旧版本的Ceph的配置文件,没有找到Ceph的Monitor,达不到的Ceph的合法数量,或开发的情况下 Paxos 是不能够准确地确定系统的当前状态。

Bootstrapping Monitors

在大多数配置和部署的情况下,部署Ceph的工具,可以帮助引导Ceph的MON-Map为您生成监视(例如, mkcephfs ,Ceph-deploy等) 。 Ceph的MON需要一些明确的设置:

文件系统ID :这个FSID是对象存储的唯一标识符。既然你可以在同一硬件上运行多个集群,引导监视器MON时,您必须指定对象存储的唯一ID 。部署工具也可以做到这些(例如,可以调用mkcephfs或ceph-deploy的工具,如uuidgen ) ,但你可以手动指定FSID。
监视器ID :监视器ID是集群内的每个MON唯一标识。它是一个字母数字值,并按照约定,标识符通常遵循一个字母增量(例如,A,B等) 。这可以被设置在Ceph的配置文件(例如, mon.a ] ,[ mon.b ] ``等)。

键:显示器必须具有秘密密钥。部署工具,如mkcephfs或ceph-deploy 通常不适合你,但你可能手动执行此步骤。
对于引导其他细节,请参见自举监视器。

CONFIGURING MONITORS

要申请到整个集群的配置设置,进入配置设置[global]部分 。要配置设置应用于您的集群中的所有监视器,根据[问]输入的配置设置。要配置设置应用于指定的监视器MON,指定监视的实例(例如, [ mon.a ] )。按照惯例,监视器实例名称用字母符号。

[global]

[mon]

[mon.a]

[mon.b]

[mon.c]

MINIMUM CONFIGURATION  最低配置

最低限度MON为Ceph的MON通过Ceph的配置文件(包括每个显示器的主机名和IP地址)设置。您可以配置这些下[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
有关详细信息,请参阅网络配置参考。

注意:这种显示器的最低配置假定一个部署工具生成FSID与mon.key为您服务。
一旦你部署Ceph的集群,你不应该改变MON的IP地址。但是,如果你决定改变MON的IP地址,则必须遵循特定的程序。请参阅更改监视器的IP地址的详细信息。

CLUSTER ID   集群ID

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

FSID

说明:集群ID 。每个集群之一。
类型: UUID
需要:是的。
默认值: N / A如果未指定,由部署工具可能会产生。
注意:如果你使用部署工具,不要设置这个值。


初期成员

我们建议运行生产Ceph的存储集群至少有三个Ceph的监视器,以确保高可用性。当你运行多个监视器,您可以指定初始MON必须是集群的成员,以建立仲裁。这可能会减少为群集来网上所花费的时间。

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

描述:在集群启动过程中的初始MON的ID 。如果已指定, Ceph的MON需要一个奇数,以形成初始的法定数量(例如,3) 。
类型:字符串
默认值:无
注意监视集群中的大部分必须能够到达对方以建立仲裁。建立仲裁与此设置,您可以减少显示器的初始数目。

DATA

Ceph的Ceph的监控数据存储在默认路径。在生产Ceph的存储集群时,为了获得最佳性能,我们建议Ceph的OSD守护在不同的主机和驱动器运行Ceph的监视器。 Ceph的MON做大量的fsync( ) ,它可以干扰Ceph的OSD守护工作量。

Ceph的0.58或更早版本, Ceph的显示器将其数据存储在文件中。这种方法允许用户用常用的工具,如ls和cat的监测数据。然而,它并不提供强大的一致性。

在CEPH版本0.59和Ceph的显示器后,将其数据存储为键/值对。 Ceph的MON需要ACID事务。使用的数据存储,防止恢复Ceph的监视器通过Paxos的运行损坏的版本,它使在单一原子,其中多个修改操作等优点。

一般来说,我们不建议更改默认的数据位置。如果修改了默认的位置,我们建议您在CEPH-MON中,设置在[MON]部分的配置文件中。

mon data

Description: MON的数据位置
Type: String
Default: /var/lib/ceph/mon/$cluster-$id

存储容量

Ceph的存储集群,当接近其最大容量(即,MON-OSD比) , Ceph的防止写入或读取Ceph的OSD守护程序作为一种安全措施,以防止数据丢失。因此,让生产Ceph的存储集群的方法充分发挥其比率并不是一个好的做法,因为它牺牲高可用性。默认的full比为0.95 ,或95 %的产能。这是一个非常积极的少数的OSD​​设置测试群集。

提示当监视您的群集,是警惕警告的nearfull比。这意味着部分的OSD​​的故障可能会导致在一个临时的服务中断,如一个或多个的OSD​​失败。考虑增加更多的OSD​​来增加存储容量。
一个常见的场景测试集群涉及:系统管理员删除Ceph的OSD守护进程以确保Ceph的存储集群的平衡;然后,移出另一Ceph的OSD守护程序,依此类推,直到Ceph的存储集群达到满比、锁定。我们建议测试群集,容量规划,甚至有点,使您能够衡量你将需要多少备用容量,以维持高可用性。理想情况下,你要防范,当Ceph的OSD守护进程故障是,集群可以恢复到一个主动+清洁状态,如果没有立即取代那些Ceph的OSD守护进程。您可以运行一个集群在主动+降级状态,但在正常工作条件下,这是不理想的。

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

 Ceph配置——5.Ceph-MON设置

这样一个群集中一个或两个的OSD​​失败是正常的。一个不太频繁,但合理的方案涉及到一个机架的路由器或电源失败,同是带来了多重的OSD挂掉(例如, 7-12 OSDS ) 。在这种情况下,你还是应该争取一个集群,可以继续运行,实现主动+干净的状态,即使这意味着以一个最短的顺序增加了一些额外的OSD​​。如果你的产能利用率过高,你可能不会丢失数据,但你仍然可以牺牲数据可用性,同时解决停电的失败域内的集群,如果产能利用率超过满比例。出于这个原因,我们建议至少一些粗能力计划。

确定集群的两个数量:

1.OSD的数目。
2.群集的总容量
如果您用​​集群中的总容量除以您的群集的OSD数量,你会发现OSD集群内的平均容量。考虑用这一数字乘以OSD的数量,在正常操作期间​​您的预期将失败(一个相对较小的数字) 。最后乘以到达的最高工作能力比容量的集群,然后,减去一些无法到达合理的全比你期望的OSD​​数据量。重复上述过程,具有较高的OSD故障(例如,一个机架的OSD ​​)到达一个合理的数量接近满比。

[global]

mon osd full ratio = .80
mon osd nearfull ratio = .70

mon osd full ratio MON-OSD满比

说明:在被OSD进程使用之前一个硬盘的百分比​被认为是充分的。
类型:浮法
默认值: 0.95


mon osd nearfull ratio MON-OSD nearfull率

说明:在被OSD进程使用之前一个硬盘的百分比​被认为是近似充分的。
类型:浮法
默认值: 0.85

HEARTBEAT

Ceph的监视器要了解群集的信息需要每个OSD报告,并接收其周边的OSD​​状态的OSD​​报告。 Ceph对MON/ OSD相互作用提供了合理的默认设置,不过,您可以根据需要进行修改。见监视器/ OSD互动细节。

MONITOR STORE SYNCHRONIZATION

当你运行多个MON生产集群(推荐) ,每个监视器检查邻近的监视器,看是否有最新版本的集群地图(例如,一个带有一个或多个epoch数字的监视器,该数据高于当前epoch)。每隔一段时间,在集群中的一台监视器可能落后于其他显示器的同步,必须离开法定队列,同步检索有关群集的最新信息,然后重新归队。为了同步,显示器可能承担三种角色之一:

负责人:领导者是第一台显示器,实现集群地图最近期的Paxos版。
提供者:提供最新版本的集群地图的MON,但不是第一个实现的最新版本。
请求者:请求者是一台监视器,已经落后的领导,必须同步,以检索有关群集的最新信息,才可以归队。
这些角色使领导委派同步到提供者的职责,防止超载领导提高性能的同步请求。在下面的图中,请求方了解到,它已经落后于其他显示器。请求者同步,要求领导者和领导告诉请求者与供应商同步。

 Ceph配置——5.Ceph-MON设置

当一个新的显示器加入集群时同步总是在发生。在运行操作过程中,在不同的时间MON可能会收到更新的集群地图。这意味着领导者和提供者的角色,可能从一台监视器迁移到另一个。如果发生这种情况,而同步(例如,提供落后的领导者) ,提供者可以终止同步请求者。

同步完成后, Ceph的需要修剪整个集群。修剪需要安置组主动+清洁。

MON同步微调超时

说明:
类型:双
默认值:30.0


MON同步心跳超时

说明:
类型:双
默认值:30.0

MON同步心跳间隔

说明:
类型:双
默认值:5.0

MON同步退避超时

说明:
类型:双
默认值:30.0

MON同步超时

说明:
类型:双
默认值:30.0

MON同步最大试

说明:
类型:整型
默认值:5


MON同步最大有效载荷大小

说明:同步有效载荷的最大大小。
类型: 32位整数
默认: 1045676

MON接受超时

说明:秒数:*将等待接受一个Paxos的更新的请求者(S ) 。它也可以用来在Paxos用于类似目的的恢复阶段。
类型:浮法
默认值:10.0


Paxos的建议间隔

说明:收集更新时间间隔,然后提出了地图更新。
类型:双
默认值:1.0

Paxos等待时间

说明:最短的时间内收集闲置一段时间后更新。
类型:双
默认值: 0.05

Paxos的容忍间隔

说明:修剪前容忍额外的建议。
类型:整型
默认值:30


Paxos不能使用最大版本

说明: maximimum版本允许通过不修剪。
类型:整型
默认值:100

MON租赁期

说明:长度(秒)的租赁显示器的版本。
类型:浮法
默认值:5

MON租赁更新间隔

说明:其他显示器的租赁领袖续约的时间间隔(以秒计) 。
类型:浮法
默认值:3

MON租赁ACK超时

描述:*将等待的秒数提供商承认租赁扩展。
类型:浮法
默认值:10.0

MON最小osdmap Epoch

说明: OSD地图时代,在任何时候都保持最低数量。
类型: 32位整数
默认值: 500

MON最小osdmap Epoch

说明: OPG地图时代的最大数量应保持显示器。
类型: 32位整数
默认值: 500

MON max log epoch

说明:日志的最大数目的时期应保持显示器。
类型: 32位整数
默认值: 500


SLURP

Ceph的0.58版和更早的时候Ceph的一个Paxos的服务漂移、超越给定数量的版本,触发的的slurp机制,该机制建立连接与队列的发起者和获得发起者漂流的每一项服务。在CEPH 0.59及更高版本中,slurp将无法正常工作,因为有一个单Paxos的实例的所有服务(单例模式)。

废弃了,因为0.58版本。

Paxos的最大连接漂移

说明:先同步监控数据存储之前的最大Paxos迭代值。
类型:整型
默认值:10

mon slurp超时

说明:显示器有恢复使用前工序的咕噜咕噜的秒数中止,显示器白手起家的。
类型:双
默认值:10.0