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的同步。
已过时，因为版本版本：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
mon initial members = a,b,c
描述：在集群启动过程中的初始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 。
这样一个群集中一个或两个的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，但不是第一个实现的最新版本。
请求者：请求者是一台监视器，已经落后的领导，必须同步，以检索有关群集的最新信息，才可以归队。
这些角色使领导委派同步到提供者的职责，防止超载领导提高性能的同步请求。在下面的图中，请求方了解到，它已经落后于其他显示器。请求者同步，要求领导者和领导告诉请求者与供应商同步。
当一个新的显示器加入集群时同步总是在发生。在运行操作过程中，在不同的时间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