CEPH集群操做入门--配置

时间 2019-11-19

原文原文链接

概述

Ceph存储集群是全部Ceph部署的基础。基于RADOS，Ceph存储集群由两种类型的守护进程组成：Ceph OSD守护进程（OSD）将数据做为对象存储在存储节点上; Ceph Monitor（MON）维护集群映射的主副本。 Ceph存储集群可能包含数千个存储节点。最小系统将至少有一个Ceph Monitor和两个Ceph OSD守护进程用于数据复制。

Ceph文件系统，Ceph对象存储和Ceph块设备从Ceph存储集群读取数据并将数据写入Ceph存储集群。

配置和部署

Ceph存储集群有一些必需的设置，但大多数配置设置都有默认值。典型部署使用部署工具来定义集群并引导监视器。有关ceph-deploy的详细信息，请参阅部署。

配置

存储设备

概述

有两个Ceph守护进程将数据存储在磁盘上：html

Ceph OSD（或Object Storage Daemons）是Ceph中存储大部分数据的地方。通常而言，每一个OSD都由单个存储设备支持，如传统硬盘（HDD）或固态硬盘（SSD）。 OSD还能够由多种设备组合支持，例如用于大多数数据的HDD和用于某些元数据的SSD（或SSD的分区）。集群中OSD的数量一般取决于将存储多少数据，每一个存储设备的大小以及冗余的级别和类型（复制或纠删码）。前端

Ceph Monitor守护程序管理集群状态，如集群成员和身份验证信息。对于较小的集群，只须要几GB，但对于较大的集群，监控数据库能够达到几十甚至几百GB。node

准备硬盘

Ceph 注重数据安全，就是说， Ceph 客户端收到数据已写入存储器的通知时，数据确实已写入硬盘。使用较老的内核（版本小于 2.6.33 ）时，若是日志在原始硬盘上，就要禁用写缓存；较新的内核没问题。算法

用 hdparm 禁用硬盘的写缓冲功能。shell

sudo hdparm -W 0 /dev/hda 0

在生产环境，咱们建议操做系统和OSD数据分别放到不一样的硬盘。若是必须把数据和系统放在同一硬盘里，最好给数据分配一个单独的分区。数据库

OSD后端

OSD能够经过两种方式管理它们存储的数据。从Luminous 12.2.z版本开始，新的默认（和推荐）后端是BlueStore。在Luminous以前，默认（也是惟一的选项）是FileStore。json

BLUESTORE

BlueStore是一种专用存储后端，专为管理Ceph OSD工做负载的磁盘数据而设计。在过去十年中，使用FileStore支持和管理OSD的经验激发了它的动力。关键的BlueStore功能包括：bootstrap

直接管理存储设备。 BlueStore使用原始块设备或分区。这避免了可能限制性能或增长复杂性的任何中间抽象层（例如XFS等本地文件系统）。
使用RocksDB进行元数据管理。咱们嵌入了RocksDB的键/值数据库，以便管理内部元数据，例如从对象名到磁盘上的块位置的映射。
完整数据和元数据校验和。默认状况下，写入BlueStore的全部数据和元数据都受一个或多个校验和的保护。在未经验证的状况下，不会从磁盘读取数据或元数据或将其返回给用户。
内联压缩。在写入磁盘以前，能够选择压缩写入的数据。
多设备元数据分层。 BlueStore容许将其内部日志（预写日志）写入单独的高速设备（如SSD，NVMe或NVDIMM）以提升性能。若是有大量更快的存储空间可用，内部元数据也能够存储在速度更快的设备上。
高效的写时复制。 RBD和CephFS快照依赖于在BlueStore中高效实现的写时复制克隆机制。这能为常规快照和erasure coded pools（依赖于克隆以实现有效的两阶段提交）实现更高效的IO。

FILESTORE

FileStore是在Ceph中存储对象的传统方法。它依赖于标准文件系统（一般为XFS）与键/值数据库（传统上为LevelDB，现为RocksDB）的组合，用于某些元数据。FileStore通过了充分测试并普遍用于生产，但因为其总体设计和依赖传统文件系统来存储对象数据而遭受许多性能缺陷。虽然FileStore一般可以在大多数POSIX兼容的文件系统（包括btrfs和ext4）上运行，但咱们只建议使用XFS。 btrfs和ext4都有已知的漏洞和缺陷，它们的使用可能会致使数据丢失。默认状况下，全部Ceph配置工具都将使用XFS。后端

OSD 守护进程有赖于底层文件系统的扩展属性（ XATTR ）存储各类内部对象状态和元数据。底层文件系统必须能为 XATTR 提供足够容量， btrfs 没有限制随文件的 xattr 元数据总量； xfs 的限制相对大（ 64KB ），多数部署都不会有瓶颈； ext4 的则过小而不可用。使用 ext4 文件系统时，必定要把下面的配置放于 ceph.conf 配置文件的 [osd] 段下；用 btrfs 和 xfs 时能够选填。api

filestore xattr use omap = true

配置Ceph

概述

你启动 Ceph 服务时，初始化进程会把一系列守护进程放到后台运行。 Ceph存储集群运行两种守护进程：

Ceph 监视器（ ceph-mon ）
Ceph OSD守护进程（ ceph-osd ）

要支持 Ceph 文件系统功能，它还须要运行至少一个 Ceph元数据服务器（ ceph-mds ）；支持 Ceph 对象存储功能的集群还要运行网关守护进程（ radosgw ）。为方便起见，各种守护进程都有一系列默认值（不少由 ceph/src/common/config_opts.h 配置），你能够用 Ceph 配置文件覆盖这些默认值。

选项名称

全部Ceph配置选项都有一个惟一的名称，由用小写字符组成的单词组成，并用下划线（_）字符链接。

在命令行中指定选项名称时，能够使用下划线（_）或短划线（ - ）字符进行互换（例如， - mon-host至关于--mon_host）。

当选项名称出如今配置文件中时，也能够使用空格代替下划线或短划线。

配置来源

每一个Ceph守护程序，进程和库将从如下列出的几个源中提取其配置。当二者都存在时，列表中稍后的源将覆盖列表中较早的源。

编译后的默认值
监视器集群的集中配置数据库
存储在本地主机上的配置文件
环境变量
命令行参数
由管理员设置的运行时覆盖

Ceph进程在启动时所作的第一件事就是解析经过命令行，环境和本地配置文件提供的配置选项。而后链接监视器集群，检测配置是否可用。一旦完成检测，若是配置可用，守护程序或进程启动就会继续。

BOOTSTRAP选项
因为某些配置选项会影响进程联系监视器，认证和恢复集群存储配置，所以可能须要将它们存储在本地节点上并设置在本地配置文件中。这些选项包括：

mon_host，集群的监视器列表
mon_dns_serv_name（默认值：ceph-mon），用于经过DNS检查以识别集群监视器的DNS SRV记录的名称
mon_data，osd_data，mds_data，mgr_data以及相似的选项用来定义守护程序存储其数据的本地目录
keying，ketfile，and/or key，可用于指定用于向监视器进行身份验证的身份验证凭据。请注意，在大多数状况下，默认密钥环位置位于上面指定的数据目录中。

在绝大多数状况下，这些的默认值是合适的，但mon_host选项除外，它标识了集群监视器的地址。当DNS用于识别监视器时，能够彻底避免本地ceph配置文件。任何进程能够经过选项--no-mon-config以跳过从集群监视器检索配置的步骤。这在配置彻底经过配置文件管理或监视器集群当前已关闭但须要执行某些维护活动的状况下很是有用。

配置

任何给定的进程或守护程序对每一个配置选项都有一个值。可是，选项的值可能会因不一样的守护程序类型而异，甚至是相同类型的守护程序也会有不一样的配置。Ceph选项存储在监视器配置数据库或本地配置文件中被分组为多个部分，以指示它们应用于哪些守护程序或客户端。

这些部分包括：

[global]

　　描述：全局下的设置会影响Ceph存储集群中的全部daemon和client。
　　示例：

log_file = /var/log/ceph/$cluster-$type.$id.log

[mon]

　　描述：mon下的设置会影响Ceph存储集群中的全部ceph-mon守护进程，并覆盖全局中的相同设置。
　　示例：mon_cluster_log_to_syslog = true

[mgr]

　　说明：mgr部分中的设置会影响Ceph存储群集中的全部ceph-mgr守护程序，并覆盖全局中的相同设置。
　　示例：mgr_stats_period = 10

[osd]

　　描述：osd下的设置会影响Ceph存储集群中的全部ceph-osd守护进程，并覆盖全局中的相同设置。
　　示例：osd_op_queue = wpq

[mds]

　　描述：mds部分中的设置会影响Ceph存储集群中的全部ceph-mds守护程序，并覆盖全局中的相同设置。
　　示例：mds_cache_size = 10G

[client]

　　描述：客户端下的设置会影响全部Ceph客户端（例如，挂载的Ceph文件系统，挂载的Ceph块设备等）以及Rados Gateway（RGW）守护程序。
　　示例：objecter_inflight_ops = 512

还能够指定单个守护程序或客户端名称。例如，mon.foo，osd.123和client.smith都是有效的节名。

任何给定的守护程序都将从全局部分，守护程序或客户端类型部分以及指定名称的部分中提取其设置。指定名称部分中的设置优先，例如，若是在同一源（即，在同一配置文件中）的global，mon和mon.foo中指定了相同的选项，则将使用mon.foo值。

请注意，本地配置文件中的值始终优先于监视器配置数据库中的值，而无论它们出如今哪一个部分。

元变量

元变量能够显着简化Ceph存储集群配置。当在配置值中设置元变量时，Ceph会在使用配置值时将元变量扩展为具体值。 Ceph元变量相似于Bash shell中的变量扩展。Ceph支持如下元变量：

$cluster

　　描述：扩展为Ceph存储群集名称。在同一硬件上运行多个Ceph存储集群时颇有用。
　　例如：

/etc/ceph/$cluster.keyring

　　默认值：CEPH

$type

　　描述：扩展为守护进程或进程类型（例如，mds，osd或mon）
　　例如：

/var/lib/ceph/$type

　　描述：扩展为守护程序或客户端标识符。对于osd.0，这将是0; 对于mds.a，它将是a。
　　例如：

/var/lib/ceph/$type/$cluster-$id

$host

　　描述：扩展为运行进程的主机名。

$name

　　描述：扩展为

$type.$id

　　例如：

/var/run/ceph/$cluster-$name.asok

$ pid

　　描述：扩展为守护进程pid。
　　例如：

/var/run/ceph/$cluster-$name-$pid.asok

配置文件

默认的 Ceph 配置文件位置相继排列以下：

$CEPH_CONF（CEPH_CONF环境变量所指示的路径）;
-c path / path（-c命令行参数）;
/etc/ceph/ceph.conf
〜/.ceph/配置
./ceph.conf（就是当前所在的工做路径。
仅限FreeBSD系统， /usr/local/etc/ceph/$cluster.conf

Ceph配置文件使用ini样式语法。您能够经过前面的注释添加注释，使用'＃'或';'。

监控配置数据库

监视器集群管理整个集群能够使用的配置选项数据库，从而为整个系统提供简化的中央配置管理。绝大多数配置选项能够而且应该存储在此处，以便于管理和透明。少数设置可能仍须要存储在本地配置文件中，由于它们会影响链接到监视器，验证和获取配置信息的能力。在大多数状况下，这仅限于mon_host选项，尽管经过使用DNS SRV记录也能够避免这种状况。

监视器存储的配置选项有全局部分，守护程序类型部分或特定守护程序部分中，就像配置文件中的选项同样。此外，选项还能够具备与其关联的掩码，以进一步限制该选项适用于哪些守护进程或客户端。掩码有两种形式：

类型:location：其中type是CRUSH属性，如rack或host，location是该属性的值。例如，host：foo将选项限制为在特定主机上运行的守护程序或客户端。
class:device-class ：其中device-class是CRUSH设备类的名称（例如，hdd或ssd）。例如，class：ssd会将选项仅限制为SSD支持的OSD。（此掩码对非OSD守护进程或客户端没有影响。）

设置配置选项时，能够是由斜杠（/）字符分隔的服务名称，掩码或二者的组合。例如，osd / rack：foo意味着foo机架中的全部OSD守护进程。查看配置选项时，服务名称和掩码一般分为单独的字段或列，以便于阅读。

命令

如下CLI命令用于配置集群：

ceph config dump

　　将转储集群的整个配置数据库。

ceph config get <who>

　　将转储特定守护程序或客户端（例如，mds.a）的配置，存储在监视器的配置数据库中。

ceph config set <who> <option> <value>

　　将在监视器的配置数据库中设置配置选项。

ceph config show <who>

　　将显示正在运行的守护程序的报告运行配置。若是还有正在使用的本地配置文件或者在命令行或运行时覆盖了选项，则这些设置可能与监视器存储的设置不一样。选项值的来源将做为输出的一部分进行报告。

ceph config assimilate-conf -i <input file> -o <output file>

　　将从输入文件中提取配置文件，并将任何有效选项移动到监视器的配置数据库中。任何没法识别，无效或没法由monitor控制的设置都将以存储在输出文件中的缩写配置文件的形式返回。此命令对于从旧配置文件转换为基于监视器的集中式配置很是有用。

help

您能够经过如下方式得到特定选项的帮助：

ceph config help <option>

请注意，这将使用已经编译到正在运行的监视器中的配置架构。若是您有一个混合版本的集群（例如，在升级期间），您可能还想从特定的运行守护程序中查询选项模式：

ceph daemon <name> config help [option]

例如

[root@node1 ~]# ceph config help log_file log_file - path to log file (std::string, basic) Default (non-daemon): Default (daemon): /var/log/ceph/$cluster-$name.log Can update at runtime: false See also: [log_to_stderr,err_to_stderr,log_to_syslog,err_to_syslog]

或

[root@node1 ~]# ceph config help log_file -f json-pretty { "name": "log_file", "type": "std::string", "level": "basic", "desc": "path to log file", "long_desc": "", "default": "", "daemon_default": "/var/log/ceph/$cluster-$name.log", "tags": [], "services": [], "see_also": [ "log_to_stderr", "err_to_stderr", "log_to_syslog", "err_to_syslog" ], "enum_values": [], "min": "", "max": "", "can_update_at_runtime": false }

level属性能够是basic，advanced或dev中的任何一个。开发选项供开发人员使用，一般用于测试目的，不建议操做员使用。

运行时修改

在大多数状况下，Ceph容许您在运行时更改守护程序的配置。此功能对于增长/减小日志记录输出，启用/禁用调试设置，甚至用于运行时优化很是有用。

通常来讲，配置选项能够经过ceph config set命令以一般的方式更新。例如，在特定OSD上启用调试日志级别：

ceph config set osd.123 debug_ms 20

请注意，若是在本地配置文件中也自定义了相同的选项，则将忽略监视器设置（其优先级低于本地配置文件）。

覆盖参数值

您还能够使用Ceph CLI上的tell或daemon接口临时设置选项。这些覆盖值是短暂的，由于它们只影响正在运行的进程，而且在守护进程或进程从新启动时被丢弃/丢失。

覆盖值能够经过两种方式设置：

1.从任何主机，咱们均可以经过网络向守护进程发送消息：

ceph tell osd.123 config set debug_osd 20

tell命令还能够接受守护程序标识符的通配符。例如，要调整全部OSD守护进程的调试级别：

ceph tell osd.* config set debug_osd 20

2.从进程运行的主机开始，咱们能够经过/ var / run / ceph中的套接字直接链接到进程：

ceph daemon <name> config set <option> <value>

例如

ceph daemon osd.4 config set debug_osd 20

请注意，在ceph config show命令输出中，这些临时值将显示为覆盖源。

查看运行参数值

您能够使用ceph config show命令查看为正在运行的守护程序设置的参数。例如：

ceph config show osd.0

将显示该守护进程的（非默认）选项。您还能够经过如下方式查看特定选项：

ceph config show osd.0 debug_osd

或查看全部选项（即便是那些具备默认值的选项）：

ceph config show-with-defaults osd.0

您还能够经过管理套接字从本地主机链接到该守护程序来观察正在运行的守护程序的设置。例如：

ceph daemon osd.0 config show

将转储全部当前设置：

ceph daemon osd.0 config diff

将仅显示非默认设置（以及值来自的位置：配置文件，监视器，覆盖等），以及：

ceph daemon osd.0 config get debug_osd

将报告单个选项的值。

经常使用设置

概述

单个Ceph节点能够运行多个守护进程。例如，具备多个驱动器的单个节点能够为每一个驱动器运行一个ceph-osd。理想状况下，某些节点只运行特定的daemon。例如，一些节点能够运行ceph-osd守护进程，其余节点能够运行ceph-mds守护进程，还有其余节点能够运行ceph-mon守护进程。

每一个节点都有一个由主机设置标识的名称。监视器还指定由addr设置标识的网络地址和端口（即域名或IP地址）。基本配置文件一般仅为每一个监视器守护程序实例指定最小设置。例如：

[global] mon_initial_members = ceph1 mon_host = 10.0.0.1

主机设置是节点的短名称（即，不是fqdn）。它也不是IP地址。在命令行中输入hostname -s以检索节点的名称。除非您手动部署Ceph，不然请勿将主机设置用于初始监视器之外的任何其余设置。在使用chef或ceph-deploy等部署工具时，您不能在各个守护程序下指定主机，这些工具将在集群映射中为您输入适当的值。

网络

有关配置与Ceph一块儿使用的网络的详细讨论，请参阅网络配置参考。

监控

Ceph生产集群一般使用至少3个Ceph Monitor守护程序进行部署，以确保监视器实例崩溃时的高可用性。至少三（3）个监视器确保Paxos算法能够肯定哪一个版本的Ceph Cluster Map是法定人数中大多数Ceph监视器的最新版本。

注意您能够使用单个监视器部署Ceph，但若是实例失败，则缺乏其余监视器可能会中断数据服务可用性。

Ceph监视器一般侦听端口6789.例如：

[mon.a] host = hostName mon addr = 150.140.130.120:6789

默认状况下，Ceph但愿您将如下列路径存储监视器的数据：

/var/lib/ceph/mon/$cluster-$id

您或部署工具（例如，ceph-deploy）必须建立相应的目录。在彻底表达元变量和名为“ceph”的集群的状况下，上述目录将评估为：

/var/lib/ceph/mon/ceph-a

有关其余详细信息，请参阅“监视器配置参考”。

认证

Bobtail版本的新功能：0.56

对于Bobtail（v 0.56）及更高版本，您应该在Ceph配置文件的[global]部分中明确启用或禁用身份验证。

auth cluster required = cephx auth service required = cephx auth client required = cephx

此外，您应该启用message signing（消息签名）。升级时，咱们建议先明确禁用身份验证，而后再执行升级。升级完成后，从新启用身份验证。有关详细信息，请参阅Cephx配置参考。

OSD

Ceph生产集群一般部署Ceph OSD守护进程，通常一个OSD守护进程运行在一个存储驱动器上。典型部署指定jorunal大小。例如：

[osd] osd journal size = 10000 [osd.0] host = {hostname} #manual deployments only.

默认状况下，Ceph但愿您使用如下路径存储Ceph OSD守护程序的数据：

/var/lib/ceph/osd/$cluster-$id

您或部署工具（例如，ceph-deploy）必须建立相应的目录。在彻底表达元变量和名为“ceph”的集群的状况下，上述目录将评估为：

/var/lib/ceph/osd/ceph-0

您能够使用osd数据设置覆盖此路径。咱们不建议更改默认位置。在OSD主机上建立默认目录。

ssh {osd-host} sudo mkdir /var/lib/ceph/osd/ceph-{osd-number}

osd数据路径理想地致使具备硬盘的安装点，该硬盘与存储和运行操做系统和守护进程的硬盘分开。若是OSD用于操做系统磁盘之外的磁盘，请准备与Ceph一块儿使用，并将其安装到刚刚建立的目录中：

ssh {new-osd-host} sudo mkfs -t {fstype} /dev/{disk} sudo mount -o user_xattr /dev/{hdd} /var/lib/ceph/osd/ceph-{osd-number}

咱们建议在运行mkfs时使用xfs文件系统。（不建议使用btrfs和ext4，再也不测试。）有关其余配置详细信息，请参阅OSD配置参考。

心跳

在运行时操做期间，Ceph OSD守护进程检查其余Ceph OSD守护进程并将其发现报告给Ceph Monitor。您没必要提供任何设置。可是，若是您遇到网络延迟问题，则可能但愿修改设置。

有关其余详细信息，请参阅配置Monitor / OSD Interaction。

日志/调试

有时您可能会遇到Ceph须要修改日志记录输出和使用Ceph调试的问题。有关日志轮换的详细信息，请参阅调试和日志记录。

ceph.conf示例

[global] fsid = {cluster-id} mon initial members = {hostname}[, {hostname}] mon host = {ip-address}[, {ip-address}] #All clusters have a front-side public network. #If you have two NICs, you can configure a back side cluster #network for OSD object replication, heart beats, backfilling, #recovery, etc. public network = {network}[, {network}] #cluster network = {network}[, {network}] #Clusters require authentication by default. auth cluster required = cephx auth service required = cephx auth client required = cephx #Choose reasonable numbers for your journals, number of replicas #and placement groups. osd journal size = {n} osd pool default size = {n}  # Write an object n times. osd pool default min size = {n} # Allow writing n copy in a degraded state. osd pool default pg num = {n} osd pool default pgp num = {n} #Choose a reasonable crush leaf type. #0 for a 1-node cluster. #1 for a multi node cluster in a single rack #2 for a multi node, multi chassis cluster with multiple hosts in a chassis #3 for a multi node cluster with hosts across racks, etc. osd crush chooseleaf type = {n}

运行多集群

使用Ceph，您能够在同一硬件上运行多个Ceph存储集群。与在具备不一样CRUSH规则的同一群集上使用不一样池相比，运行多个群集可提供更高级别的隔离。单独的群集将具备单独的监视器，OSD和元数据服务器进程。使用默认设置运行Ceph时，默认群集名称为ceph，这意味着您将在/ etc / ceph默认目录中保存Ceph配置文件，文件名为ceph.conf。

有关详细信息，请参阅ceph-deploy new。 .. _ceph-deploy new：../ ceph-deploy-new

运行多个群集时，必须为群集命名并使用群集名称保存Ceph配置文件。例如，名为openstack的集群将在/ etc / ceph缺省目录中具备文件名为openstack.conf的Ceph配置文件。

群集名称必须仅包含字母a-z和数字0-9。

单独的集群意味着单独的数据磁盘和日志，它们不在集群之间共享。 cluster元变量表明集群名称（即前面例子中的openstack）。各类设置使用cluster元变量，包括：

keyring
admin socket
log file
pid file
mon data
mon cluster log file
osd data
osd journal
mds data
rgw data

建立默认目录或文件时，应在路径中的适当位置使用群集名称。例如：

sudo mkdir /var/lib/ceph/osd/openstack-0
sudo mkdir /var/lib/ceph/mon/openstack-a

在同一主机上运行监视器时，应使用不一样的端口。默认状况下，监视器使用端口6789.若是已使用端口6789使用监视器，请为其余群集使用不一样的端口。

ceph -c {cluster-name}.conf health ceph -c openstack.conf health

网络设置

概述

网络配置对构建高性能 Ceph存储来讲至关重要。 Ceph 存储集群不会表明 Ceph客户端执行请求路由或调度，相反， Ceph 客户端（如块设备、 CephFS 、 REST 网关）直接向 OSD 请求，而后OSD为客户端执行数据复制，也就是说复制和其它因素会额外增长集群网的负载。

咱们的快速入门配置提供了一个简陋的 Ceph配置文件，其中只设置了监视器 IP 地址和守护进程所在的主机名。若是没有配置集群网，那么 Ceph 假设你只有一个“公共网”。只用一个网能够运行 Ceph ，可是在大型集群里用单独的“集群”网可显著地提高性能。

咱们建议用两个网络运营 Ceph 存储集群：一个公共网（前端）和一个集群网（后端）。为此，各节点得配备多个网卡

运营两个独立网络的考量主要有：

性能： OSD 为客户端处理数据复制，复制多份时 OSD 间的网络负载势必会影响到客户端和 Ceph 集群的通信，包括延时增长、产生性能问题；恢复和重均衡也会显著增长公共网延时。
安全：大多数人都是良民，不多的一撮人喜欢折腾拒绝服务攻击（ DoS ）。当 OSD 间的流量失控时，归置组不再能达到 active + clean 状态，这样用户就不能读写数据了。挫败此类攻击的一种好方法是维护一个彻底独立的集群网，使之不能直连互联网；另外，请考虑用消息签名防止欺骗攻击。

防火墙

守护进程默认会绑定到6800：7300间的端口，你能够更改此范围。更改防火墙配置前先检查下iptables配置。

sudo iptables -L

某些Linux发行版规矩拒绝除SSH以外全部网络接口的的全部入站请求。例如：

REJECT all -- anywhere anywhere reject-with icmp-host-prohibited

你得先删掉公共网和集群网对应的这些规则，而后再增长安全保护规则。

监视器默认监听6789端口，并且监视器老是运行在公共网。按下例增长规则时，要把{iface}替换为公共网接口（如eth0，eth1等等），{ip-address}替换为公共网IP，{netmask}替换为公共网掩码。

sudo iptables -A INPUT -i {iface} -p tcp -s {ip-address}/{netmask} --dport 6789 -j ACCEPT

MDS服务器会监听公共网6800以上的第一个可用端口。须要注意的是，这种行为是不肯定的，因此若是你在同一主机上运行多个OSD或MDS，或者在很短的时间内重启了多个守护进程，它们会绑定更高的端口号;因此说你应该预先打开整个6800-7300端口区间。按下例增长规则时，要把{iface}替换为公共网接口（如eth0 ，eth1等等），{ip-address}替换为公共网IP，{netmask}替换为公共网掩码。

sudo iptables -A INPUT -i {iface} -m multiport -p tcp -s {ip-address}/{netmask} --dports 6800:7300 -j ACCEPT

OSD守护进程默认绑定从6800起的第一个可用端口，须要注意的是，这种行为是不肯定的，因此若是你在同一主机上运行多个OSD或MDS，或者在很短的时间内重启了多个守护进程，它们会绑定更高的端口号。一主机上的各个OSD最多会用到4个端口：
　　1.一个用于和客户端，监视器通信;
　　2.一个用于发送数据到其余OSD;
　　3.两个用于各个网卡上的心跳;

当某个守护进程失败并重启时没释放端口，重启后的进程就会监听新端口。你应该打开整个6800-7300端口区间，以应对这种可能性。

若是你分开了公共网和集群网，必须分别为之设置防火墙，由于客户端会经过公共网链接，而其余OSD会经过集群网链接。按下例增长规则时，要把{iface}替换为网口（如eth0，eth1等等），{ip-address}替换为公共网或集群网IP，{netmask}替换为公共网或集群网掩码。例如：

sudo iptables -A INPUT -i {iface}  -m multiport -p tcp -s {ip-address}/{netmask} --dports 6800:7300 -j ACCEPT

若是你的元数据服务器和OSD在同一节点上，能够合并公共网配置。

Ceph网络

Ceph 的网络配置要放到 [global] 段下。前述的 5 分钟快速入门提供了一个简陋的 Ceph 配置文件，它假设服务器和客户端都位于同一网段， Ceph 能够很好地适应这种情形。然而 Ceph 容许配置更精细的公共网，包括多 IP 和多掩码；也能用单独的集群网处理 OSD 心跳、对象复制、和恢复流量。不要混淆你配置的 IP 地址和客户端用来访问存储服务的公共网地址。典型的内网经常是 192.168.0.0 或 10.0.0.0 。

若是你给公共网或集群网配置了多个 IP 地址及子网掩码，这些子网必须能互通。另外要确保在防火墙上为各 IP 和子网开放了必要的端口。Ceph用CIDR法表示子网，如10.0.0.0/24。

配置完几个网络后，能够重启集群或挨个重启守护进程.Ceph守护进程动态地绑定端口，因此更改网络配置后无需重启整个集群。

公共网络
要配置公共网络，请将如下选项添加到Ceph配置文件的[global]部分。

[global] # ... elided configuration public network = {public-network/netmask}

集群网络
若是声明群集网络，OSD将经过群集网络路由心跳，对象复制和恢复流量。与使用单个网络相比，这能够提升性能。要配置群集网络，请将如下选项添加到Ceph配置文件的[global]部分。

[global] # ... elided configuration cluster network = {cluster-network/netmask}

咱们但愿没法从公共网络或Internet访问群集网络以加强安全性。

Ceph Daemon

有一个网络配置是全部守护进程都要配的：各个守护进程都必须指定主机，Ceph也要求指定监视器IP地址及端口。一些部署工具（如ceph-deploy，Chef）会给你建立配置文件，若是它能胜任那就别设置这些值。主机选项是主机的短名，不是全资域名FQDN，也不是IP地址。在命令行下输入主机名-s获取主机名。

[mon.a] host = {hostname} mon addr = {ip-address}:6789 [osd.0] host = {hostname}

您没必要为守护程序设置主机IP地址。若是您具备静态IP配置而且公共和集群网络都在运行，则Ceph配置文件能够为每一个守护程序指定主机的IP地址。要为守护程序设置静态IP地址，如下选项应出如今ceph.conf文件的守护程序实例部分中。

[osd.0] public addr = {host-public-ip-address} cluster addr = {host-cluster-ip-address}

单网卡OSD，双网络集群

通常来讲，咱们不建议用单网卡OSD主机部署两个网络。然而这事能够实现，把公共地址选择配在[osd.n]段下便可强制OSD主机运行在公共网，其中n是其 OSD号。另外，公共网和集群网必须互通，考虑到安全因素咱们不建议这样作。

网络配置选项

网络配置选项不是必需的，Ceph假设全部主机都运行于公共网，除非你特地配置了一个集群网。

公共网

公共网配置用于明确地为公共网定义IP地址和子网。你能够分配静态IP或用public addr覆盖public network选项。

public network 描述:公共网（前端）的 IP 地址和掩码（如 192.168.0.0/24 ），置于 [global] 下。多个子网用逗号分隔。 类型:{ip-address}/{netmask} [, {ip-address}/{netmask}] 是否必需:No 默认值:N/A public addr 描述:用于公共网（前端）的 IP 地址。适用于各守护进程。 类型:IP 地址 是否必需:No 默认值:N/A

集群网

集群网配置用来声明一个集群网，并明确地定义其 IP 地址和子网。你能够配置静态 IP 或为某 OSD 守护进程配置 cluster addr 以覆盖 cluster network 选项。

cluster network 描述:集群网（后端）的 IP 地址及掩码（如 10.0.0.0/24 ），置于 [global] 下。多个子网用逗号分隔。 类型:{ip-address}/{netmask} [, {ip-address}/{netmask}] 是否必需:No 默认值:N/A cluster addr 描述:集群网（后端） IP 地址。置于各守护进程下。 类型:Address 是否必需:No 默认值:N/A

绑定

绑定选项用于设置 OSD 和 MDS 默认使用的端口范围，默认范围是 6800:7300 。确保防火墙开放了对应端口范围。

你也可让 Ceph 守护进程绑定到 IPv6 地址。

ms bind port min 描述:OSD 或 MDS 可绑定的最小端口号。 类型:32-bit Integer 默认值:6800 是否必需:No ms bind port max 描述:OSD 或 MDS 可绑定的最大端口号。 类型:32-bit Integer 默认值:7300 是否必需:No. ms bind ipv6 描述:容许 Ceph 守护进程绑定 IPv6 地址。 类型:Boolean 默认值:false 是否必需:No

主机

Ceph 配置文件里至少要写一个监视器、且每一个监视器下都要配置 mon addr 选项；每一个监视器、元数据服务器和 OSD 下都要配 host 选项。

mon addr 描述:{hostname}:{port} 条目列表，用以让客户端链接 Ceph 监视器。若是未设置， Ceph 查找 [mon.*] 段。 类型:String 是否必需:No 默认值:N/A host 描述:主机名。此选项用于特定守护进程，如 [osd.0] 。 类型:String 是否必需:Yes, for daemon instances. 默认值:localhost

不要用 localhost 。在命令行下执行 hostname -s 获取主机名（到第一个点，不是全资域名），并用于配置文件。用第三方部署工具时不要指定 host 选项，它会自行获取。

TCP

Ceph 默认禁用 TCP 缓冲。

ms tcp nodelay 描述:Ceph 用 ms tcp nodelay 使系统尽快（不缓冲）发送每一个请求。禁用 Nagle 算法可增长吞吐量，但会引进延时。若是你遇到大量小包，能够禁用 ms tcp nodelay 试试。 类型:Boolean 是否必需:No 默认值:true ms tcp rcvbuf 描述:网络套接字接收缓冲尺寸，默认禁用。 类型:32-bit Integer 是否必需:No 默认值:0 ms tcp read timeout 描述:若是一客户端或守护进程发送请求到另外一个 Ceph 守护进程，且没有断开再也不使用的链接，在 ms tcp read timeout 指定的秒数以后它将被标记为空闲。 类型:Unsigned 64-bit Integer 是否必需:No 默认值:900 15 minutes.

认证设置

概述

cephx协议已经默认开启。加密认证要耗费必定计算资源，但一般很低。若是您的客户端和服务器网络环境至关安全，并且认证的负面效应更大，你能够关闭它，一般不推荐您这么作。若是禁用了认证，就会有篡改客户端/服务器消息这样的中间人攻击风险，这会致使灾难性后果。

部署情景

部署Ceph集群有两种主要方案，这会影响您最初配置Cephx的方式。 Ceph用户大多数第一次使用ceph-deploy来建立集群（最简单）。对于使用其余部署工具（例如，Chef，Juju，Puppet等）的集群，您将须要使用手动过程或配置部署工具来引导您的监视器。

CEPH-DEPLOY

使用ceph-deploy部署集群时，您没必要手动引导监视器或建立client.admin用户或密钥环。您在Storage Cluster快速入门中执行的步骤将调用ceph-deploy为您执行此操做。

当您执行ceph-deploy new {initial-monitor（s）}时，Ceph将为您建立一个监视密钥环（仅用于引导监视器），它将为您生成一个初始Ceph配置文件，其中包含如下身份验证设置，代表Ceph默认启用身份验证：

auth_cluster_required = cephx auth_service_required = cephx auth_client_required = cephx

当您执行ceph-deploy mon create-initial时，Ceph将引导初始监视器，检索包含client.admin用户密钥的ceph.client.admin.keyring文件。此外，它还将检索密钥环，使ceph-deploy和ceph-volume实用程序可以准备和激活OSD和元数据服务器。

当您执行ceph-deploy admin {node-name}时（注意：首先必须安装Ceph），您将Ceph配置文件和ceph.client.admin.keyring推送到节点的/ etc / ceph目录。您将可以在该节点的命令行上以root身份执行Ceph管理功能。

手动部署

手动部署集群时，必须手动引导监视器并建立client.admin用户和密钥环。要引导监视器，请按照 Monitor Bootstrapping中的步骤操做。监视器引导的步骤是使用Chef，Puppet，Juju等第三方部署工具时必须执行的逻辑步骤。

启用/禁用CEPHX

为监视器，OSD和元数据服务器部署密钥时需启用Cephx。若是你只是打开/关闭Cephx，你没必要重复bootstrapping程序。

启用Cephx

启用cephx后，Ceph将在默认搜索路径（包括/etc/ceph/ceph.$name.keyring）里查找密钥环。你能够在Ceph配置文件的[global]段里添加keyring选项来修改，但不推荐。

在禁用了cephx的集群上执行下面的步骤来启用它，若是你（或者部署工具）已经生成了密钥，你能够跳过相关的步骤。

1.建立client.admin密钥，并为客户端保存此密钥的副本：

ceph auth get-or-create client.admin mon 'allow *' mds 'allow *' osd 'allow *' -o /etc/ceph/ceph.client.admin.keyring

警告：此命令会覆盖任何存在的/etc/ceph/client.admin.keyring文件，若是部署工具已经完成此步骤，千万别再执行此命令。多加当心！

2.建立监视器集群所需的密钥环，并给它们生成密钥。

ceph-authtool --create-keyring /tmp/ceph.mon.keyring --gen-key -n mon. --cap mon 'allow *'

3.把监视器密钥环复制到ceph.mon.keyring文件，再把此文件复制到各监视器的mon数据目录下。好比要把它复制给名为ceph集群的mon.a，用此命令：

cp /tmp/ceph.mon.keyring /var/lib/ceph/mon/ceph-a/keyring

4.为每一个MGR生成密钥，{$ id}是OSD编号：

ceph auth get-or-create mgr.{$id} mon 'allow profile mgr' mds 'allow *' osd 'allow *' -o /var/lib/ceph/mgr/ceph-{$id}/keyring

5.为每一个 OSD 生成密钥， {$id} 是 MDS 的标识字母：

ceph auth get-or-create osd.{$id} mon 'allow rwx' osd 'allow *' -o /var/lib/ceph/osd/ceph-{$id}/keyring

6.为每一个 MDS 生成密钥， {$id} 是 MDS 的标识字母：

ceph auth get-or-create mds.{$id} mon 'allow rwx' osd 'allow *' mds 'allow *' mgr 'allow profile mds' -o /var/lib/ceph/mds/ceph-{$id}/keyring

7.把如下配置加入 Ceph 配置文件的 [global] 段下以启用 cephx 认证：

auth cluster required = cephx auth service required = cephx auth client required = cephx

8.启动或重启Ceph集群

禁用Cephx

下述步骤描述了如何禁用Cephx。若是你的集群环境相对安全，你能够减免认证耗费的计算资源，然而咱们不推荐。可是临时禁用认证会使安装，和/或排障更简单。

1.把下列配置加入Ceph配置文件的[global]段下便可禁用cephx认证：

auth cluster required = none auth service required = none auth client required = none

2.启动或重启Ceph集群

配置选项

启动

auth cluster required 描述:若是启用了，集群守护进程（如 ceph-mon 、 ceph-osd 和 ceph-mds ）间必须相互认证。可用选项有 cephx 或 none 。 类型:String 是否必需:No 默认值:cephx. auth service required 描述:若是启用，客户端要访问 Ceph 服务的话，集群守护进程会要求它和集群认证。可用选项为 cephx 或 none 。 类型:String 是否必需:No 默认值:cephx. auth client required 描述:若是启用，客户端会要求 Ceph 集群和它认证。可用选项为 cephx 或 none 。 类型:String 是否必需:No 默认值:cephx.

密钥

若是你的集群启用了认证， ceph 管理命令和客户端得有密钥才能访问集群。

给 ceph 管理命令和客户端提供密钥的最经常使用方法就是把密钥环放到 /etc/ceph ，经过 ceph-deploy 部署的 Cuttlefish 及更高版本，其文件名一般是ceph.client.admin.keyring （或 $cluster.client.admin.keyring ）。若是你的密钥环位于 /etc/ceph 下，就不须要在 Ceph 配置文件里指定 keyring 选项了。

咱们建议把集群的密钥环复制到你执行管理命令的节点，它包含 client.admin 密钥。

你能够用 ceph-deploy admin 命令作此事，手动复制可执行此命令：

sudo scp {user}@{ceph-cluster-host}:/etc/ceph/ceph.client.admin.keyring /etc/ceph/ceph.client.admin.keyring

确保给客户端上的ceph.keyring设置合理的权限位（如chmod 644）。

你能够用 key 选项把密钥写在配置文件里（不推荐），或者用 keyfile 选项指定个路径。

keyring 描述:密钥环文件的路径。 类型:String 是否必需:No 默认值:/etc/ceph/$cluster.$name.keyring,/etc/ceph/$cluster.keyring,/etc/ceph/keyring,/etc/ceph/keyring.bin keyfile 描述:到密钥文件的路径，如一个只包含密钥的文件。 类型:String 是否必需:No 默认值:None key 描述:密钥（密钥文本），最好别这样作。 类型:String 是否必需:No 默认值:None

DAEMON KEYRINGS
管理用户或部署工具（例如，ceph-deploy）能够以与生成用户密钥环相同的方式生成守护进程密钥环。默认状况下，Ceph将守护进程密钥环存储在其数据目录中。默认密钥环位置以及守护程序运行所需的功能以下所示。

ceph-mon Location: $mon_data/keyring Capabilities: mon 'allow *' ceph-osd Location: $osd_data/keyring Capabilities: mgr 'allow profile osd' mon 'allow profile osd' osd 'allow *' ceph-mds Location: $mds_data/keyring Capabilities: mds 'allow' mgr 'allow profile mds' mon 'allow profile mds' osd 'allow rwx' ceph-mgr Location: $mgr_data/keyring Capabilities: mon 'allow profile mgr' mds 'allow *' osd 'allow *' radosgw Location: $rgw_data/keyring Capabilities: mon 'allow rwx' osd 'allow rwx'

监视器密钥环（即 mon. ）包含一个密钥，但没有能力，且不是集群 auth 数据库的一部分。

守护进程数据目录位置默认格式以下：

/var/lib/ceph/$type/$cluster-$id

例如， osd.12 的目录会是：

/var/lib/ceph/osd/ceph-12

你能够覆盖这些位置，但不推荐。

签名

在 Bobtail 及后续版本中， Ceph 会用开始认证时生成的会话密钥认证全部在线实体。然而 Argonaut 及以前版本不知道如何认证在线消息，为保持向后兼容性（如在同一个集群里运行 Bobtail 和 Argonaut ），消息签名默认是关闭的。若是你只运行 Bobtail 和后续版本，可让 Ceph 要求签名。

像 Ceph 认证的其余部分同样，客户端和集群间的消息签名也能作到细粒度控制；并且能启用或禁用 Ceph 守护进程间的签名。

cephx require signatures 描述:若设置为 true ， Ceph 集群会要求客户端签名全部消息，包括集群内其余守护进程间的。 类型:Boolean 是否必需:No 默认值:false cephx cluster require signatures 描述:若设置为 true ， Ceph 要求集群内全部守护进程签名相互之间的消息。 类型:Boolean 是否必需:No 默认值:false cephx service require signatures 描述:若设置为 true ， Ceph 要求签名全部客户端和集群间的消息。 类型:Boolean 是否必需:No 默认值:false 
cephx sign messages 描述:若是 Ceph 版本支持消息签名， Ceph 会签名全部消息以防欺骗。 类型:Boolean 默认值:true

生存期

auth service ticket ttl
描述:Ceph 存储集群发给客户端一个用于认证的票据时分配给这个票据的生存期。 类型:Double 默认值:60*60

Monitor设置

概述

理解如何配置Ceph监视器是构建可靠的Ceph存储集群的重要方面，任何Ceph集群都须要至少一个监视器。一个监视器一般至关一致，可是你能够增长，删除，或替换集群中的监视器

背景

监视器们维护着集群运行图的“主副本”，就是说客户端连到一个监视器并获取当前运行图就能肯定全部监视器、 OSD 和元数据服务器的位置。 Ceph 客户端读写 OSD 或元数据服务器前，必须先连到一个监视器，靠当前集群运行图的副本和 CRUSH 算法，客户端能计算出任何对象的位置，故此客户端有能力直接连到 OSD ，这对 Ceph 的高伸缩性、高性能来讲很是重要。监视器的主要角色是维护集群运行图的主副本，它也提供认证和日志记录服务。 Ceph 监视器们把监视器服务的全部更改写入一个单独的 Paxos 例程，而后 Paxos 以键/值方式存储全部变动以实现高度一致性。同步期间， Ceph 监视器能查询集群运行图的近期版本，它们经过操做键/值存储快照和迭代器（用 leveldb ）来进行存储级同步

自0.58版以来已弃用
在0.58及更早版本中，Ceph监视器每一个服务用一个Paxos例程，并把运行图存储为文件。

CLUSTER MAPS

集群运行图是多个图的组合，包括监视器图、 OSD 图、归置组图和元数据服务器图。集群运行图追踪几个重要事件：哪些进程在集群里（ in ）；哪些进程在集群里（ in ）是 up 且在运行、或 down ；归置组状态是 active 或 inactive 、 clean 或其余状态；和其余反映当前集群状态的信息，像总存储容量、和使用量。

当集群状态有明显变动时，如一 OSD 挂了、一归置组降级了等等，集群运行图会被更新以反映集群当前状态。另外，监视器也维护着集群的主要状态历史。监视器图、 OSD 图、归置组图和元数据服务器图各自维护着它们的运行图版本。咱们把各图的版本称为一个 epoch 。

运营集群时，跟踪这些状态是系统管理任务的重要部分。

MONITOR QUORUM

本文入门部分提供了一个简陋的 Ceph 配置文件，它提供了一个监视器用于测试。只用一个监视器集群能够良好地运行，然而单监视器是一个单故障点，生产集群要实现高可用性的话得配置多个监视器，这样单个监视器的失效才不会影响整个集群。

集群用多个监视器实现高可用性时，多个监视器用 Paxos 算法对主集群运行图达成一致，这里的一致要求大多数监视器都在运行且够成法定人数（如 1 个、 3 之 2 在运行、 5 之 3 、 6 之 4 等等）。

mon force quorum join 描述：强制监视器加入仲裁，即便它先前已从MAP中删除 类型：Boolean 默认值：false

一致性

你把监视器加进 Ceph 配置文件时，得注意一些架构问题， Ceph 发现集群内的其余监视器时对其有着严格的一致性要求。尽管如此， Ceph 客户端和其余 Ceph 守护进程用配置文件发现监视器，监视器却用监视器图（ monmap ）相互发现而非配置文件。

一个监视器发现集群内的其余监视器时老是参考 monmap 的本地副本，用 monmap 而非 Ceph 配置文件避免了可能损坏集群的错误（如 ceph.conf 中指定地址或端口的拼写错误）。正由于监视器把 monmap 用于发现、并共享于客户端和其余 Ceph 守护进程间， monmap可严格地保证监视器的一致性是可靠的。

严格的一致性也适用于 monmap 的更新，由于关于监视器的任何更新、关于 monmap 的变动都是经过称为 Paxos 的分布式一致性算法传递的。监视器们必须就 monmap 的每次更新达成一致，以确保法定人数里的每一个监视器 monmap 版本相同，如增长、删除一个监视器。 monmap 的更新是增量的，因此监视器们都有最新的一致版本，以及一系列以前版本。历史版本的存在容许一个落后的监视器跟上集群当前状态。

若是监视器经过配置文件而非 monmap 相互发现，这会引进其余风险，由于 Ceph 配置文件不是自动更新并分发的，监视器有可能不当心用了较老的配置文件，以至于不认识某监视器、放弃法定人数、或者产生一种 Paxos 不能肯定当前系统状态的情形

初始化监视器

在大多数配置和部署案例中，部署 Ceph 的工具能够帮你生成一个监视器图来初始化监视器（如 ceph-deploy 等），一个监视器须要的选项：

文件系统标识符： fsid 是对象存储的惟一标识符。由于你能够在一套硬件上运行多个集群，因此在初始化监视器时必须指定对象存储的惟一标识符。部署工具一般可替你完成（如 ceph-deploy 会调用相似 uuidgen 的程序），可是你也能够手动指定 fsid 。
监视器标识符：监视器标识符是分配给集群内各监视器的惟一 ID ，它是一个字母数字组合，为方便起见，标识符一般以字母顺序结尾（如 a 、 b 等等），能够设置于 Ceph 配置文件（如 [mon.a] 、 [mon.b] 等等）、部署工具、或 ceph 命令行工具。
密钥：监视器必须有密钥。像 ceph-deploy 这样的部署工具一般会自动生成，也能够手动完成。

配置

要把配置应用到整个集群，把它们放到 [global] 下；要用于全部监视器，置于 [mon] 下；要用于某监视器，指定监视器例程，如 [mon.a] ）。按惯例，监视器例程用字母命名。

[global]

[mon]

[mon.a]

[mon.b]

[mon.c]

最小配置

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

这里的监视器最简配置假设部署工具会自动给你生成 fsid 和 mon. 密钥。一旦部署了 Ceph 集群，监视器 IP 地址不该该更改。然而，若是你决意要改，必须严格按照更改监视器 IP 地址来改。

客户端也能够使用DNS SRV记录找到监视器

集群 ID

每一个 Ceph 存储集群都有一个惟一标识符（ fsid ）。若是指定了，它应该出如今配置文件的 [global] 段下。部署工具一般会生成 fsid 并存于监视器图，因此不必定会写入配置文件， fsid 使得在一套硬件上运行多个集群成为可能。

fsid
描述:集群 ID ，一集群一个。 
类型:UUID 
是否必需:Yes. 
默认值:无。若未指定，部署工具会生成。

若是你用部署工具就不能设置

初始成员

咱们建议在生产环境下最少部署 3 个监视器，以确保高可用性。运行多个监视器时，你能够指定为造成法定人数成员所需的初始监视器，这能减少集群上线时间。

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

mon initial members 描述:集群启动时初始监视器的 ID ，若指定， Ceph 须要奇数个监视器来肯定最初法定人数（如 3 ）。 类型:String 默认值:None

数据

Ceph提供Ceph监视器存储数据的默认路径。为了在生产Ceph存储集群中得到最佳性能，咱们建议在Ceph OSD守护进程和Ceph Monitor在不一样主机和驱动器上运行。因为leveldb使用mmap（）来编写数据，Ceph Monitors常常将内存中的数据刷新到磁盘，若是数据存储与OSD守护进程共存，则可能会干扰Ceph OSD守护进程工做负载。

在Ceph版本0.58及更早版本中，Ceph Monitors将其数据存储在文件中。这种方法容许用户使用ls和cat等经常使用工具检查监控数据。可是，它没有提供强大的一致性。

在 Ceph 0.59 及后续版本中，监视器以键/值对存储数据。监视器须要 ACID 事务，数据存储的使用可防止监视器用损坏的版本进行恢复，除此以外，它容许在一个原子批量操做中进行多个修改操做。

通常来讲咱们不建议更改默认数据位置，若是要改，咱们建议全部监视器统一配置，加到配置文件的 [mon] 下。

mon data 描述：监视器的数据位置。 类型：String 默认值：/var/lib/ceph/mon/$cluster-$id mon data size warn 描述：当监视器的数据存储超过15GB时，在群集日志中发出HEALTH_WARN。 类型：整型 默认值：15 * 1024 * 1024 * 1024 * mon data avail warn 描述：当监视器数据存储的可用磁盘空间小于或等于此百分比时，在群集日志中发出HEALTH_WARN。 类型：整型 默认值：30 mon data avail crit 描述：当监视器数据存储的可用磁盘空间小于或等于此百分比时，在群集日志中发出HEALTH_ERR。 类型：整型 默认值：5 mon warn on cache pools without hit sets 描述：若是缓存池未配置hit_set_type值，则在集群日志中发出HEALTH_WARN。有关详细信息，请参阅hit_set_type。 类型：Boolean 默认值：true mon warn on crush straw calc version zero 描述：若是CRUSH的straw_calc_version为零，则在集群日志中发出HEALTH_WARN。有关详细信息，请参阅CRUSH map tunables。 类型：Boolean 默认值：true mon warn on legacy crush tunables 描述：若是CRUSH可调参数太旧（早于mon_min_crush_required_version），则在集群日志中发出HEALTH_WARN 类型：Boolean 默认值：true mon crush min required version 描述：群集所需的最小可调参数版本。有关详细信息，请参阅CRUSH map tunables。 类型：String 默认值：firefly mon warn on osd down out interval zero 描述：if mon osd down out interval is zero，则在集群日志中发出HEALTH_WARN。在leader上将此选项设置为零的行为与noout标志很是类似。在没有设置noout标志的状况下很难弄清楚集群出了什么问题可是现象差很少，因此咱们在这种状况下报告一个警告。 类型：Boolean 默认值：true mon cache target full warn ratio 描述：cache_target_full和target_max_object之间，咱们开始警告 类型：float 默认值：0.66 mon health data update interval 描述：仲裁中的监视器与其对等方共享其健康状态的频率（以秒为单位）。 （负数禁用它） 类型：float 默认值：60 mon health to clog 描述：按期启用向群集日志发送运行情况摘要。 类型：Boolean 默认值：true mon health to clog tick interval 描述：监视器将健康摘要发送到群集日志的频率（以秒为单位）（非正数禁用它）。 若是当前运行情况摘要为空或与上次相同，则监视器不会将其发送到群集日志。 类型：整型 默认值：3600 mon health to clog interval 描述：监视器将健康摘要发送到群集日志的频率（以秒为单位）（非正数禁用它）。 不管摘要是否更改，Monitor都将始终将摘要发送到群集日志。 类型：整型 默认值：60

存储容量

Ceph 存储集群利用率接近最大容量时（即 mon osd full ratio ），做为防止数据丢失的安全措施，它会阻止你读写 OSD 。所以，让生产集群用满可不是好事，由于牺牲了高可用性。 full ratio 默认值是 .95 或容量的 95% 。对小型测试集群来讲这是很是激进的设置。

Tip:监控集群时，要警戒和 nearfull 相关的警告。这意味着一些 OSD 的失败会致使临时服务中断，应该增长一些 OSD 来扩展存储容量。

在测试集群时，一个常见场景是：系统管理员从集群删除一个 OSD 、接着观察重均衡；而后继续删除其余 OSD ，直到集群达到占满率并锁死。咱们建议，即便在测试集群里也要规划一点空闲容量用于保证高可用性。理想状况下，要作好这样的预案：一系列 OSD 失败后，短期内不更换它们仍能恢复到 active + clean 状态。你也能够在 active + degraded 状态运行集群，但对正常使用来讲并很差。

下图描述了一个简化的 Ceph 集群，它包含 33 个节点、每主机一个 OSD 、每 OSD 3TB 容量，因此这个小白鼠集群有 99TB 的实际容量，其 mon osd full ratio 为 .95 。若是它只剩余 5TB 容量，集群就不容许客户端再读写数据，因此它的运行容量是 95TB ，而非 99TB 。

在这样的集群里，坏一或两个 OSD 很日常；一种罕见但可能发生的情形是一个机架的路由器或电源挂了，这会致使多个 OSD 同时离线（如 OSD 7-12 ），在这种状况下，你仍要力争保持集群可运行并达到 active + clean 状态，即便这意味着你得在短时间内额外增长一些 OSD 及主机。若是集群利用率过高，在解决故障域期间也许不会丢数据，但极可能牺牲数据可用性，由于利用率超过了 full ratio 。故此，咱们建议至少要粗略地规划下容量。

肯定群集的两个数字：OSD的数量和集群的总容量

若是将群集的总容量除以群集中的OSD数，则能够找到群集中OSD的平均平均容量。考虑将该数字乘以您指望在正常操做期间同时失败的OSD数量（相对较小的数量）。最后将群集的容量乘以所有比率，以达到最大运行容量; 而后，减去那些预期会故障的OSD从而计算出合理的full ratio。用更多数量的OSD故障（例如，一组OSD）重复上述过程，以获得合理的near full ratio。

如下设置仅适用于群集建立，而后存储在OSDMap中。

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

mon osd full ratio 描述：OSD被视为已满以前使用的磁盘空间百分比。 类型：float 默认值：0.95 mon osd backfillfull ratio 说明：在OSD被认为太满而没法backfill以前使用的磁盘空间百分比。 类型：float 默认值：0.90 mon osd nearfull ratio 描述：在OSD被认为接近满以前使用的磁盘空间百分比。 类型：float 默认值：0.85

若是一些 OSD 快满了，但其余的仍有足够空间，你可能配错 CRUSH 权重了。

这些设置仅适用于群集建立期间。以后须要使用ceph osd set-almostfull-ratio和ceph osd set-full-ratio在OSDMap中进行更改

心跳

Ceph 监视器要求各 OSD 向它报告、并接收 OSD 们的邻居状态报告，以此来掌握集群。 Ceph 提供了监视器与 OSD 交互的合理默认值，然而你能够按需修改

监视器存储同步

当你用多个监视器支撑一个生产集群时，各监视器都要检查邻居是否有集群运行图的最新版本（如，邻居监视器的图有一或多个 epoch 版本高于当前监视器的最高版 epoch ），过一段时间，集群里的某个监视器可能落后于其它监视器太多而不得不离开法定人数，而后同步到集群当前状态，并重回法定人数。为了同步，监视器可能承担三种中的一种角色：
　　1.Leader: Leader 是实现最新 Paxos 版本的第一个监视器。
　　2.Provider: Provider 有最新集群运行图的监视器，但不是第一个实现最新版。
　　3.Requester: Requester 落后于 leader ，重回法定人数前，必须同步以获取关于集群的最新信息。

有了这些角色区分， leader就能够给 provider 委派同步任务，这会避免同步请求压垮 leader 、影响性能。在下面的图示中， requester 已经知道它落后于其它监视器，而后向 leader 请求同步， leader 让它去和 provider 同步。

新监视器加入集群时有必要进行同步。在运行中，监视器会不定时收到集群运行图的更新，这就意味着 leader 和 provider 角色可能在监视器间变幻。若是这事发生在同步期间（如 provider 落后于 leader ）， provider 能终结和 requester 间的同步。

一旦同步完成， 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 描述: Number of seconds the monitor will wait for the next update message from its sync provider before it gives up and bootstrap again. 类型: Double 默认： 60.0
 mon sync max retries 描述: 类型: Integer 默认： 5
 mon sync max payload size 描述: The maximum size for a sync payload (in bytes). 类型: 32-bit Integer 默认： 1045676
 paxos max join drift 描述: 在咱们必须首先同步监控数据存储以前的最大Paxos迭代。 当监视器发现其对等体远远超过它时，它将首先与数据存储同步，而后再继续。 类型: Integer 默认： 10
 paxos stash full interval 描述: 多久（在提交中）存储PaxosService状态的完整副本。 当前此设置仅影响mds，mon，auth和mgr PaxosServices。 类型: Integer 默认： 25
 paxos propose interval 描述: Gather updates for this time interval before proposing a map update. 类型: Double 默认： 1.0
 paxos min 描述: The minimum number of paxos states to keep around 类型: Integer 默认： 500
 paxos min wait 描述: The minimum amount of time to gather updates after a period of inactivity. 类型: Double 默认： 0.05
 paxos trim min 描述: Number of extra proposals tolerated before trimming 类型: Integer 默认： 250
 paxos trim max 描述: The maximum number of extra proposals to trim at a time 类型: Integer 默认： 500
 paxos service trim min 描述: The minimum amount of versions to trigger a trim (0 disables it) 类型: Integer 默认： 250
 paxos service trim max 描述: The maximum amount of versions to trim during a single proposal (0 disables it) 类型: Integer 默认： 500
 mon max log epochs 描述: The maximum amount of log epochs to trim during a single proposal 类型: Integer 默认： 500
 mon max pgmap epochs 描述: The maximum amount of pgmap epochs to trim during a single proposal 类型: Integer 默认： 500
 mon mds force trim to 描述: Force monitor to trim mdsmaps to this point (0 disables it. dangerous, use with care) 类型: Integer 默认： 0
 mon osd force trim to 描述: Force monitor to trim osdmaps to this point, even if there is PGs not clean at the specified epoch (0 disables it. dangerous, use with care) 类型: Integer 默认： 0
 mon osd cache size 描述: The size of osdmaps cache, not to rely on underlying store’s cache 类型: Integer 默认： 10
 mon election timeout 描述: On election proposer, maximum waiting time for all ACKs in seconds. 类型: Float 默认： 5
 mon lease 描述: The length (in seconds) of the lease on the monitor’s versions. 类型: Float 默认： 5
 mon lease renew interval factor 描述: mon lease * mon lease renew interval factor will be the interval for the Leader to renew the other monitor’s leases. The factor should be less than 1.0. 类型: Float 默认： 0.6
 mon lease ack timeout factor 描述: The Leader will wait mon lease * mon lease ack timeout factor for the Providers to acknowledge the lease extension. 类型: Float 默认： 2.0
 mon accept timeout factor 描述: The Leader will wait mon lease * mon accept timeout factor for the Requester(s) to accept a Paxos update. 
　　　　　　　　　　It is also used during the Paxos recovery phase for similar purposes. 类型: Float 默认： 2.0
 mon min osdmap epochs 描述: Minimum number of OSD map epochs to keep at all times. 类型: 32-bit Integer 默认： 500
 mon max pgmap epochs 描述: Maximum number of PG map epochs the monitor should keep. 类型: 32-bit Integer 默认： 500

mon max log epochs 描述: Maximum number of Log epochs the monitor should keep. 类型: 32-bit Integer 默认： 500

时钟

Ceph守护进程将关键消息传递给彼此，必须在守护进程达到超时阈值以前处理这些消息。若是Ceph监视器中的时钟不一样步，则可能致使许多异常。例如：

1.守护进程忽略收到的消息（例如，时间戳过期）
2.当没有及时收到消息时，超时/延迟触发超时。

你应该在全部监视器主机上安装 NTP 以确保监视器集群的时钟同步。

时钟漂移即便还没有形成损坏也能被 NTP 感知， Ceph 的时钟漂移或时钟误差警告即便在 NTP 同步水平合理时也会被触发。提升时钟漂移值有时候尚可容忍，然而不少因素（像载荷、网络延时、覆盖默认超时值和监控器存储同步选项）都能在不下降 Paxos 保证级别的状况下影响可接受的时钟漂移水平。

Ceph 提供了下列这些可调选项，让你本身琢磨可接受的值。

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 mon timecheck skew interval 描述: 当leader存在skew时间时，以秒为单位的时间检查间隔（时钟漂移检查）。 类型: Float 默认： 30.0

客户端

mon client hunt 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

pool设置

从版本v0.94开始，支持池标志，容许或禁止对池进行更改。

若是以这种方式配置，监视器也能够禁止删除池。

mon allow pool delete 描述: If the monitors should allow pools to be removed. Regardless of what the pool flags say. 类型: Boolean 默认： false osd pool default flag hashpspool 描述: 在新池上设置hashpspool标志 类型: Boolean 默认： true osd pool default flag nodelete 描述: 在新池上设置nodelete标志。 防止以任何方式删除使用此标志的池。 类型: Boolean 默认： false osd pool default flag nopgchange 描述: 在新池上设置nopgchange标志。 不容许为池更改PG的数量。 类型: Boolean 默认： false osd pool default flag nosizechange 描述: 在新池上设置nosizechange标志。 不容许更改池的大小。 类型: Boolean 默认： false

杂项

mon max osd 描述: 集群容许的最大 OSD 数量。 类型: 32-bit Integer 默认： 10000 mon globalid prealloc 描述: 为集群和客户端预分配的全局 ID 数量。 类型: 32-bit Integer 默认： 100 mon subscribe interval 描述: 同步的刷新间隔（秒），同步机制容许获取集群运行图和日志信息。 类型: Double 默认： 86400 mon stat smooth intervals 描述: Ceph将平滑最后N个PG地图的统计数据。 类型: Integer 默认： 2 mon probe timeout 描述: 监视器在bootstrapping以前等待查找peers对等体的秒数。 类型: Double 默认： 2.0 mon daemon bytes 描述: 给mds和 OSD 的消息使用的内存空间（字节）。 类型: 64-bit Integer Unsigned 默认： 400ul << 20 mon max log entries per event 描述: 每一个事件容许的最大日志条数。 类型: Integer 默认： 4096 mon osd prime pg temp 描述: Enables or disable priming the PGMap with the previous OSDs when an out OSD comes back into the cluster.
With the true setting the clients will continue to use the previous OSDs until the newly in OSDs as that PG peered. 类型: Boolean 默认： true mon osd prime pg temp max time 描述: 当OSD返回集群时，监视器应花费多少时间尝试填充PGMap。 类型: Float 默认： 0.5 mon osd prime pg temp max time estimate 描述: Maximum estimate of time spent on each PG before we prime all PGs in parallel. 类型: Float 默认： 0.25 mon osd allow primary affinity 描述: 容许在osdmap中设置primary_affinity。 类型: Boolean 默认： False mon osd pool ec fast read 描述: 是否打开池上的快速读取。若是在建立时未指定fast_read，它将用做新建立的erasure pool的默认设置。 类型: Boolean 默认： False mon mds skip sanity 描述: Skip safety assertions on FSMap (in case of bugs where we want to continue anyway).
Monitor terminates if the FSMap sanity check fails, but we can disable it by enabling this option. 类型: Boolean 默认： False mon max mdsmap epochs 描述: The maximum amount of mdsmap epochs to trim during a single proposal. 类型: Integer 默认： 500 mon config key max entry size 描述: config-key条目的最大大小（以字节为单位）
类型: Integer 默认： 4096 mon scrub interval 描述: How often (in seconds) the monitor scrub its store by comparing the stored checksums with the computed ones of all the stored keys. 类型: Integer 默认： 3600*24 mon scrub max keys 描述: The maximum number of keys to scrub each time. 类型: Integer 默认： 100 mon compact on start 描述: Compact the database used as Ceph Monitor store on ceph-mon start.
A manual compaction helps to shrink the monitor database and improve the performance of it if the regular compaction fails to work. 类型: Boolean 默认： False mon compact on bootstrap 描述: Compact the database used as Ceph Monitor store on on bootstrap.
Monitor starts probing each other for creating a quorum after bootstrap. If it times out before joining the quorum, it will start over and bootstrap itself again. 类型: Boolean 默认： False mon compact on trim 描述: Compact a certain prefix (including paxos) when we trim its old states. 类型: Boolean 默认： True mon cpu threads 描述: Number of threads for performing CPU intensive work on monitor. 类型: Boolean 默认： True mon osd mapping pgs per chunk 描述: We calculate the mapping from placement group to OSDs in chunks. This option specifies the number of placement groups per chunk. 类型: Integer 默认： 4096 mon osd max split count 描述: Largest number of PGs per “involved” OSD to let split create.
When we increase the pg_num of a pool, the placement groups will be split on all OSDs serving that pool. We want to avoid extreme multipliers on PG splits. 类型: Integer 默认： 300 mon session timeout 描述: Monitor will terminate inactive sessions stay idle over this time limit. 类型: Integer 默认： 300

经过DNS查看操做监视器

从版本11.0.0开始，RADOS支持经过DNS查找监视器。

这样，守护进程和客户端在其ceph.conf配置文件中不须要mon主机配置指令。

使用DNS SRV TCP记录客户端能够查找监视器。

这容许在客户端和监视器上进行较少的配置。使用DNS更新能够使客户端和守护程序了解监视器拓扑中的更改。

默认状况下，客户端和守护程序将查找名为ceph-mon的TCP服务，该服务由mon_dns_srv_name配置指令配置。

mon dns srv name 描述: the service name used querying the DNS for the monitor hosts/addresses 类型: String 默认： ceph-mon

心跳设置

概述

完成初始Ceph配置后，您能够部署并运行Ceph。当您执行诸如ceph health或ceph -s之类的命令时，Ceph Monitor会报告Ceph存储集群的当前状态。 Ceph Monitor经过每一个Ceph OSD守护进程本身的报告，以及从Ceph OSD Daemons接收有关其相邻Ceph OSD守护进程状态的报告，了解Ceph存储群集。若是Ceph Monitor没有收到报告，或者它收到Ceph存储集群中的更改报告，Ceph Monitor会更新Ceph集群映射的状态。

Ceph为Ceph Monitor / Ceph OSD Daemon交互提供合理的默认设置。可是，您能够覆盖默认值。如下部分描述了Ceph监视器和Ceph OSD守护进程如何交互以监视Ceph存储群集。

心跳验证

各 OSD 每 6 秒会与其余 OSD 进行心跳检查，用 [osd] 下的 osd heartbeat interval 可更改此间隔、或运行时更改。若是一个 OSD 20 秒都没有心跳，集群就认为它 down 了，用 [osd] 下的 osd heartbeat grace 可更改宽限期、或者运行时更改。

死亡OSD上报

默认状况下，在Ceph监视器确认报告的Ceph OSD守护进程已关闭以前，须要来自不一样主机的两个Ceph OSD守护进程向Ceph监视器报告另外一个Ceph OSD守护进程已关闭。可是，全部报告故障的OSD都有可能存放在机架中，而且链接到另外一个OSD时出现问题。为了不这种误报，咱们认为报告失败的对等体是整个群集中潜在的“子群集”的代理，一样具备相似的滞后性。显然不是全部状况都是这样，但有时会帮助咱们优雅校订错误。 mon osd报告子树级别用于经过CRUSH映射中的共同祖先类型将对等体分组到“子集群”中。默认状况下，只须要来自不一样子树的两个报告来报告另外一个Ceph OSD守护进程。你能够经过在ceph配置文件里的[mon]部分下添加mon osd min down reporter和mon osd reporter subtree level设置或在运行时设置值。

报告互连失败

若是一OSD守护进程不能和配置文件中定义的任何OSD创建链接，它会每30秒向监视器索要一次最新集群运行图，你能够在[osd]下设置osd mon heartbeat interval来更改这个心跳间隔，或者运行时更改

报告本身的状态

若是一 OSD 在 mon osd report timeout 时间内没向监视器报告过，监视器就认为它 down 了。OSD 守护进程会向监视器报告某些事件，如某次操做失败、归置组状态变动、 up_thru 变动、或它将在 5 秒内启动。你能够设置 [osd] 下的 osd mon report interval min 来更改最小报告间隔，或在运行时更改。 OSD 守护进程每 120 秒会向监视器报告其状态，不管是否有值得报告的事件。在 [osd] 段下设置 osd mon report interval max 可更改OSD报告间隔，或运行时更改。

配置

心跳选项应该置于配置文件的 [global] 段下。

监视器选项

mon osd min up ratio 描述: 在把 OSD 标记为 down 前，保持处于 up 状态的 OSD 最小比例。 类型: Double 默认： .3 mon osd min in ratio 描述: 在把 OSD 标记为 out 前，保持处于 in 状态的 OSD 最小比例 类型: Double 默认： .75 mon osd laggy halflife 描述: The number of seconds laggy estimates will decay. 类型: Integer 默认： 60*60 mon osd laggy weight 描述: The weight for new samples in laggy estimation decay. 类型: Double 默认： 0.3 mon osd laggy max interval 描述: Maximum value of laggy_interval in laggy estimations (in seconds). 
Monitor uses an adaptive approach to evaluate the laggy_interval of a certain OSD. This value will be used to calculate the grace time for that OSD. 类型: Integer 默认： 300 mon osd adjust heartbeat grace 描述: If set to true, Ceph will scale based on laggy estimations. 类型: Boolean 默认： true mon osd adjust down out interval 描述: If set to true, Ceph will scaled based on laggy estimations. 类型: Boolean 默认： true mon osd auto mark in 描述: Ceph 将把任何启动中的 OSD 标记为在集群中（ in ）。 类型: Boolean 默认： false mon osd auto mark auto out in 描述: 把正在启动、且被自动标记为 out 状态的 OSD 标记为 in 类型: Boolean 默认： true mon osd auto mark new in 描述: 把正在启动的新 OSD 标记为 in 。 类型: Boolean 默认： true mon osd down out interval 描述: 在 OSD 中止响应多少秒后把它标记为 down 且 out 。 类型: 32-bit Integer 默认： 600 mon osd down out subtree limit 描述: Ceph不会自动标记的最小CRUSH单位类型。例如，若是设置为host，若是host的全部OSD都关闭，Ceph将不会自动标记这些OSD。
类型: String 默认： rack mon osd report timeout 描述: 在声明无响应的Ceph OSD守护进程down以前的宽限期（以秒为单位）。 类型: 32-bit Integer 默认： 900 mon osd min down reporters 描述: 报告Ceph OSD守护进程down所需的最小Ceph OSD守护进程数。 类型: 32-bit Integer 默认： 2 mon osd reporter subtree level 描述: In which level of parent bucket the reporters are counted. 
The OSDs send failure reports to monitor if they find its peer is not responsive. And monitor mark the reported OSD out and then down after a grace period. 类型: String 默认： host

OSD选项

osd heartbeat address 描述: OSD 用于心跳的网络地址 类型: Address 默认： The host address. osd heartbeat interval 描述: 一个OSD探测它的邻居的间隔时间（秒） 类型: 32-bit Integer 默认： 6 osd heartbeat grace 描述: Ceph OSD守护进程没有显示Ceph存储集群认为它已关闭的心跳所通过的时间。 必须在[mon]和[osd]或[global]部分中设置此设置，以便MON和OSD守护程序均可以读取它。 类型: 32-bit Integer 默认： 20 osd mon heartbeat interval 描述: OSD 没有邻居时多久探测一次监视器 类型: 32-bit Integer 默认： 30 osd mon report interval 描述: 监视器容许 OSD 报告的最大间隔，超时将认为 OSD 挂了（ down ）。 类型: 32-bit Integer 默认： 5 osd mon ack timeout 描述: 等待Ceph Monitor确认统计请求的秒数。 类型: 32-bit Integer 默认： 30

OSD设置

概述

你能够经过配置文件调整 OSD ，仅靠默认值和极少的配置 OSD 守护进程就能运行。最简 OSD 配置需设置 osd journal size 和 host ，其余几乎都能用默认值。

Ceph 的 OSD 守护进程用递增的数字做标识，按惯例以 0 开始，以下：

osd.0 osd.1 osd.2

在配置文件里， [osd] 段下的配置适用于全部 OSD ；要添加针对特定 OSD 的选项（如 host ），把它放到那个 OSD 段下便可，如

[osd] osd journal size = 5120 [osd.0] host = osd-host-a [osd.1] host = osd-host-b

常规配置

下列选项可配置一 OSD 的惟一标识符、以及数据和日志的路径。 Ceph 部署脚本一般会自动生成 UUID 。咱们不建议更改数据和日志的默认路径，由于这样会增长后续的排障难度。

日志尺寸应该大于指望的驱动器速度和 filestore max sync interval 之乘积的两倍；最多见的方法是为日志驱动器（一般是 SSD ）分区并挂载好，这样 Ceph 就能够用整个分区作日志。

osd uuid 描述: OSD 的全局惟一标识符（ UUID ）。 类型: UUID 默认： The UUID. Note: osd uuid 适用于单个 OSD ， fsid 适用于整个集群。
 osd data 描述: OSD 数据存储位置，你得建立并把数据盘挂载到其下。咱们不推荐更改默认值。 类型: String 默认： /var/lib/ceph/osd/$cluster-$id osd max write size 描述: 一次写入的最大尺寸，MB。 类型: 32-bit Integer 默认： 90 osd max object size 描述: 一个object最大大小（字节）bytes. 类型: 32-bit Unsigned Integer 默认： 128MB osd client message size cap 描述: 内存里容许的最大客户端数据消息。 类型: 64-bit Unsigned Integer 默认： 500MB default. 500*1024L*1024L osd class dir 描述: RADOS 类插件的路径。 类型: String 默认： $libdir/rados-classes

文件系统选项

Ceph构建并安装文件系统用于Ceph OSD

osd mkfs options {fs-type} 描述: 为 OSD 新建 {fs-type} 类型的文件系统时使用的选项。 类型: String Default for xfs: -f -i 2048 Default for other file systems: {empty string} For example:: osd mkfs options xfs = -f -d agcount=24 osd mount options {fs-type} 描述: 挂载 {fs-type} 类型的文件系统做为 OSD 数据目录时所用的选项。 类型: String Default for xfs: rw,noatime,inode64 Default for other file systems: rw, noatime For example:: osd mount options xfs = rw, noatime, inode64, logbufs=8

日志选项

默认状况下，Ceph指望你把OSD日志存入如下路径

/var/lib/ceph/osd/$cluster-$id/journal

使用单一设备类型（例如，旋转驱动器）时，应该共同使用日志：逻辑卷（或分区）应与数据逻辑卷位于同一设备中。

当使用快速（SSD，NVMe）设备与较慢设备（如旋转驱动器）的混合时，将日志放在更快的设备上是有意义的，而数据彻底占用较慢的设备。

默认的osd日志大小值是5120（5GB），但它能够更大，在这种状况下须要在ceph.conf文件中设置：

osd journal 描述: OSD 日志路径，能够是一个文件或块设备（ SSD 的一个分区）的路径。若是是文件，要先建立相应目录。咱们建议用 osd data 之外的独立驱动器。 类型: String 默认： /var/lib/ceph/osd/$cluster-$id/journal osd journal size 描述: 日志大小（MB） 类型: 32-bit Integer 默认： 5120

监视器OSD交互

Ceph OSD守护进程检查对方的心跳并按期向监视器报告。在许多状况下，Ceph能够使用默认值。可是，若是您的网络存在延迟问题，则可能须要采用更长的时间间隔。有关心跳的详细讨论，请参阅心跳。

数据放置

有关详细信息，请参见Pool＆PG Config Reference。

SCRUBBING

除了为对象复制多个副本外，Ceph还要洗刷归置组确认数据完整性。这种洗刷相似对象存储层的fsck，对每一个归置组，Ceph生成一个全部对象的目录，并比对每一个主对象及其副本以确保没有对象丢失或错配。轻微洗刷（天天）检查对象尺寸和属性，深层洗刷（每周）会读出数据并用校验和方法确认数据完整性。

洗刷对维护数据完整性很重要，但会影响性能;你能够用下列选项来增长或减小洗刷操做。

osd max scrubs 描述: Ceph OSD守护进程的最大同步清理操做数。 类型: 32-bit Int 默认： 1 osd scrub begin hour 描述: 清理的下限时间 类型: Integer in the range of 0 to 24 默认： 0 osd scrub end hour 描述: 能够执行预约清理时的上限时间。 与osd scrub begin hour一块儿定义了一个时间窗口，能够在其中进行擦洗。 可是，不管时间窗口是否容许，只要放置组的擦洗间隔超过osd scrub max interval都将进行擦洗。 默认： 24 osd scrub during recovery 描述: 在恢复期间容许擦洗。 将此设置为false将禁用在有活动恢复时安排新的清理（和深度清理）。 若是已经开始将继续执行。 这有助于减轻集群繁忙时上的负载。 类型: Boolean 默认： true osd scrub thread timeout 描述: The maximum time in seconds before timing out a scrub thread. 类型: 32-bit Integer 默认： 60 osd scrub finalize thread timeout 描述: The maximum time in seconds before timing out a scrub finalize thread. 类型: 32-bit Integer 默认： 60*10 osd scrub load threshold 描述: 标准化的最大负载。 当系统负载（由getloadavg（）/online cpu numbers）高于此数字时，Ceph不会擦除。  类型: Float 默认： 0.5 osd scrub min interval 描述: 当Ceph存储集群负载较低时，擦除Ceph OSD守护程序的最小间隔（秒）。 类型: Float 默认： Once per day. 60*60*24 osd scrub max interval 描述: 不管群集负载如何，擦除Ceph OSD守护进程的最大间隔（秒）。 类型: Float 默认： Once per week. 7*60*60*24 osd scrub chunk min 描述: 在单个操做期间要擦除的最小数量的对象存储块。 Ceph在擦洗期间阻止写入单个块。 类型: 32-bit Integer 默认： 5 osd scrub chunk max 描述: 单个操做期间要擦除的最大对象存储块数。 类型: 32-bit Integer 默认： 25 osd scrub sleep 描述: 在擦洗下一组块以前休眠的时间。 增长此值将减慢整个清理操做，同时客户端操做受影响较小 类型: Float 默认： 0 osd deep scrub interval 描述: 深度”清理的间隔（彻底读取全部数据）。 osd scrub load threshold不会影响此设置。 类型: Float 默认： Once per week. 60*60*24*7 osd scrub interval randomize ratio 描述: 在给某一归置组调度下一个洗刷做业时，给 osd scrub min interval 增长个随机延时，这个延时是个小于 osd scrub min interval * osd scrub interval randomized ratio 的随机值。
　　　　 因此在实践中，这个默认设置会把洗刷操做随机地散布到容许的时间窗口内，即 [1, 1.5] * osd scrub min interval 。 类型: Float 默认： 0.5 osd deep scrub stride 描述: 深层洗刷时的读取尺寸 类型: 32-bit Integer 默认： 512 KB. 524288

操做选项

osd op queue 描述：这设置了用于在OSD中优先化操做的队列类型。全部队列都具备严格的子队列，该队列在正常队列以前出列。 原始的PrioritizedQueue（prio）使用令牌桶系统，当有足够的令牌时，它将首先使高优先级队列出列。若是没有足够的令牌可用，则队列将从低优先级出列到高优先级。 WeightedPriorityQueue（wpq）将全部优先级与其优先级相关联，以防止任何队列出现饥饿。若是少数OSD比其余OSD更加过载，WPQ应该会有所帮助。 新的基于OpClassQueue（mclock_opclass）的mClock根据它们所属的类（recovery, scrub, snaptrim, client op, osd subop）对操做进行优先级排序。 而且，基于ClientQueue（mclock_client）的mClock还包含客户端标识符，以促进客户端之间的公平性。参阅QoS Based on mClock。须要重启。 类型：String 有效选择：prio，wpq，mclock_opclass，mclock_client 默认值：PRIO osd op queue cut off 描述：这将选择将哪些优先级操做发送到严格队列和普通队列。 设置为low将全部replication操做和更高级别的操做发送到strict队列，而设置为high将replication acknowledgement操做和更高级别的操做发送到strict队列。 若是群集中的一些OSD很是繁忙，将此设置为高，并将osd op queue设置中与wpq结合使用时，应该会有所帮助。 处理复制流量很是繁忙的OSD可能会在没有这些设置的状况下使主要客户端流量在这些OSD上匮乏。须要重启。 类型：String 有效选择: low, high 默认值: low osd client op priority 描述：为客户端操做设置的优先级。它与osd recovery op priority关联。 类型：32位整数 默认值：63 有效范围：1-63 osd recovery op priority 描述：为恢复操做设置的优先级。它与osd client op priority关联。 类型：32位整数 默认值：3 有效范围：1-63 osd scrub priority 描述：为清理操做设置的优先级。它与 osd client op priority相关。 类型：32位整数 默认值：5 有效范围：1-63 osd snap trim priority 描述：为snap trim操做设置的优先级。它与osd client op priority相关。 类型：32位整数 默认值：5 有效范围：1-63 osd op thread timeout 描述：Ceph OSD守护进程操做线程超时（秒）。 类型：32位整数 默认值：15 osd op complaint time 描述：在指定的秒数事后，操做becomes complaint worthy。 类型：float 默认值：30 osd disk threads 描述：磁盘线程数，用于执行后台磁盘密集型OSD操做，例如scrubbing 和snap trimming。 类型：32位整数 默认值：1 osd disk thread ioprio class 描述：警告：仅当osd disk thread ioprio class和osd disk thread ioprio priority都设置为非默认值时才会使用它。 ioprio_set(2) I/O scheduling class设置磁盘线程。 可接受的值是空字符串，be或rt。空闲类意味着磁盘线程的优先级低于OSD中的任何其余线程。这对于在忙于处理客户端操做的OSD上减慢擦除很是有用。 be是默认值，与OSD中的全部其余线程具备相同的优先级。 rt表示磁盘线程优先于OSD中的全部其余线程。 注意：仅适用于Linux内核CFQ调度程序。从Jewel版本开始磁盘iothread再也不执行擦除，请参阅osd priority options。 类型：String 默认值：空字符串 osd disk thread ioprio priority 说明：警告：仅当osd disk thread ioprio class和osd disk thread ioprio priority都设置为非默认值时才会使用它。 它设置磁盘线程的ioprio_set(2) I/O scheduling priority，范围从0（最高）到7（最低）。 若是给定主机上的全部OSD都处于空闲状态而且竞争I / O（即因为控制器拥塞），则能够使用它将一个OSD的磁盘线程优先级下降到7，以便优先级为0的另外一个OSD能够具备优先级。 注意：仅适用于Linux内核CFQ调度程序。 类型：整数，范围为0到7，若是不使用为-1。 默认值：-1 osd op history size 描述：跟踪已完成操做的最大数量。 键入：32位无符号整数 默认值：20 osd op history duration 描述：最先完成的操做跟踪。 键入：32位无符号整数 默认值：600 osd op log threshold 描述：一次显示多少个操做日志。 类型：32位整数 默认值：5

基于MCLOCK的QOS

Ceph对mClock的使用目前正处于试验阶段。

核心概念

Ceph的QoS支持使用基于dmClock算法的排队调度器来实现。该算法按权重比例分配Ceph集群的I / O资源，并实施最小预留和最大限制的约束，使服务能够公平地竞争资源。目前，mclock_opclass操做队列将涉及I / O资源的Ceph服务划分为如下几类：

client op：客户端发出的iops
osd subop：主OSD发布的iops
snap trim：快照修剪相关请求
pg recovery：与恢复相关的请求
pg scrub：与擦洗相关的请求

并使用如下三组标记对资源进行分区。换句话说，每种服务类型的由三个标签控制：

reservation：为服务分配的最小IOPS。
limitation：为服务分配的最大IOPS。
weight：若是额外容量或系统超额订购，则按比例分配容量。

在Ceph运营中，评级为“cost”。而且为这些“成本”消耗分配用于服务各类服务的资源。所以，例如，只要须要，服务的预留越多，保证拥有的资源就越多。假设有两种服务：恢复和客户端操做：

恢复：（r：1，l：5，w：1）
客户操做：（r：2，l：0，w：9）

上述设置确保恢复每秒服务的请求数不会超过5个，即便它须要服务，而且没有其余服务与之竞争。可是，若是客户端开始发出大量I / O请求，它们也不会耗尽全部I / O资源。只要有任何此类请求，就始终为恢复做业分配每秒1个请求。所以，即便在高负载的群集中，恢复做业也不会匮乏。与此同时，客户端操做系统能够享受更大部分的I / O资源，由于它的权重为“9”，而其竞争对手为“1”。对于客户端操做，它不受limit setting设置限制，所以若是没有正在进行恢复，它能够利用全部资源。

与mclock_opclass一块儿，另外一个名为mclock_client的mclock operation queue可用。它根据类别划分操做，但也根据发出请求的客户端对它们进行划分。这不只有助于管理在不一样类别的操做上花费的资源分配，还有助于确保客户之间的公平性。

当前实现注意：当前的实验实现不强制执行限制值。做为第一个近似值，咱们决定不阻止进入操做序列器的操做。

MCLOCK的细节

reservation 和limit 值具备每秒请求单位。然而，weight在技术上不具备单元而且weight是相对的。所以，若是一类请求的权重为1而权重为9，那么后一类请求应该以9比1的比率执行。

即便权重没有单位，算法为请求分配权重，所以必须谨慎选择其值。若是权重为W，则对于给定类别的请求，下一个请求将具备1 / W的权重标记加上先前的权重标记或当前时间，以较大者为准。这意味着若是W太大而1 / W过小，则可能永远不会分配计算的标签，由于它将得到当前时间的值。最终的教训是重量值不该该太大。它们应该在每秒预期服务的请求数量之下。

CAVEATS

有一些因素能够减小Ceph中mClock操做队列的影响。首先，对OSD的请求按其放置组标识符进行分片。每一个分片都有本身的mClock队列，这些队列既不会交互也不会在它们之间共享信息。能够使用配置选项osd_op_num_shards，osd_op_num_shards_hdd和osd_op_num_shards_ssd来控制分片数。较少数量的分片会增长mClock队列的影响，但可能会产生其余有害影响。

其次，请求从操做队列传输到操做序列器，在操做序列器中执行真正的处理。操做队列是mClock所在的位置，mClock肯定要传输到操做序列器的下一个操做。操做序列器中容许的操做数是一个复杂的问题。通常来讲，咱们但愿在序列器中保留足够的操做数，以便在等待磁盘和网络访问完成其余操做时，老是在某些操做上完成工做。另外一方面，一旦操做转移到操做序列器，mClock就再也不能控制它。所以，为了最大化mClock的影响，咱们但愿尽量少地在操做序列器中进行操做。

影响操做序列器中操做数的配置选项为bluestore_throttle_bytes，bluestore_throttle_deferred_bytes，bluestore_throttle_cost_per_io，bluestore_throttle_cost_per_io_hdd和bluestore_throttle_cost_per_io_ssd。

影响mClock算法影响的第三个因素是咱们正在使用分布式系统，其中对多个OSD进行请求，而且每一个OSD具备（能够具备）多个分片。然而，咱们目前正在使用的mClock算法不是分布式的（dmClock是mClock的分布式版本）。

目前，各类组织和我的正在尝试使用mClock，咱们但愿您能在ceph-devel邮件列表中分享您对mClock和dmClock实验的体验。

osd push per object cost 描述：服务一个push操做的开销 类型：无符号整数 默认值：1000 osd recovery max chunk 描述：恢复操做能够携带的数据块的最大大小。 类型：无符号整数 默认值：8 MiB osd op queue mclock client op res 描述: 客户端操做的reservation 类型：float 默认值：1000.0 osd op queue mclock client op wgt 描述：客户端操做的权重。 类型：float 默认值：500.0 osd op queue mclock client op lim 描述：客户端操做的limit。 类型：float 默认值：1000.0 osd op queue mclock osd subop res 描述：osd subop的保留。 类型：float 默认值：1000.0 osd op queue mclock osd subop wgt 描述：osd subop的权重。 类型：float 默认值：500.0 osd op queue mclock osd subop lim 描述：osd subop的限制。 类型：float 默认值：0.0 osd op queue mclock snap res 描述：snap trimming的reservation 。 类型：float 默认值：0.0 osd op queue mclock snap wgt 描述：snap trimming的权重。 类型：float 默认值：1.0 osd op queue mclock snap lim 描述：snap trimming的限制。 类型：float 默认值：0.001 osd op queue mclock recov res 描述： the reservation of recovery. 类型: Float 默认值: 0.0 osd op queue mclock recov wgt 描述： the weight of recovery. 类型: Float 默认值: 1.0 osd op queue mclock recov lim 描述： the limit of recovery. 类型: Float 默认值: 0.001 osd op queue mclock scrub res 描述： the reservation of scrub jobs. 类型: Float 默认值: 0.0 osd op queue mclock scrub wgt 描述： the weight of scrub jobs. 类型: Float 默认值: 1.0 osd op queue mclock scrub lim 描述： the limit of scrub jobs. 类型: Float 默认值: 0.001

BACKFILLING

当集群新增或移除 OSD 时，按照 CRUSH 算法应该从新均衡集群，它会把一些归置组移出或移入多个 OSD 以回到均衡状态。归置组和对象的迁移会致使集群运营性能显著下降，为维持运营性能， Ceph 用 backfilling 来执行此迁移，它能够使得 Ceph 的回填操做优先级低于用户读写请求。

osd max backfills 描述： 每一个OSD容许的最大回填数 类型： 64-bit Unsigned Integer 默认值： 1 osd backfill scan min 描述： 每次回填的最小对象数目 类型： 32-bit Integer 默认值： 64 osd backfill scan max 描述： 每次回填的最大对象数目 类型： 32-bit Integer 默认值： 512 osd backfill retry interval 描述： 回填重试请求间隔 类型： Double 默认值： 10.0

OSD MAP

OSD映射反映了在群集中运行的OSD守护进程。随着时间的推移， map epochs的数量增长。 Ceph提供了一些设置，以确保Ceph在OSD MAP变大时表现良好。

osd map dedup 描述： 启用删除OSD映射中的重复项。 类型： Boolean 默认值： true osd map cache size 描述： 缓存中保存的OSD map数目 类型： 32-bit Integer 默认值： 500 osd map cache bl size 描述： OSD守护进程中内存中OSD map缓存的大小。 类型： 32-bit Integer 默认值： 50 osd map cache bl inc size 描述： OSD守护进程中内存中OSD映射缓存增量尺寸。 类型： 32-bit Integer 默认值： 100 osd map message max 描述： 每一个 MOSDMap 图消息容许的最大条目数量。 类型： 32-bit Integer 默认值： 100

RECOVERY

当集群启动、或某 OSD 守护进程崩溃后重启时，此 OSD 开始与其它 OSD 们创建链接，这样才能正常工做。

若是某 OSD 崩溃并重生，一般会落后于其余 OSD ，也就是没有同归置组内最新版本的对象。这时， OSD 守护进程进入恢复模式并检索最新数据副本，并更新运行图。根据 OSD 挂的时间长短， OSD 的对象和归置组可能落后得厉害，另外，若是挂的是一个失效域（如一个机柜），多个 OSD 会同时重生，这样恢复时间更长、更耗资源。

为保持运营性能， Ceph 进行恢复时会限制恢复请求数、线程数、对象块尺寸，这样在降级状态下也能保持良好的性能

osd recovery delay start 描述： 对等关系创建完毕后， Ceph 开始对象恢复前等待的时间（秒）。 类型： Float 默认值： 0 osd recovery max active 描述： 每一个 OSD 一次处理的活跃恢复请求数量，增大此值能加速恢复，但它们会增长集群负载。 类型： 32-bit Integer 默认值： 3 osd recovery max chunk 描述： 一次推送的数据块的最大尺寸。 类型： 64-bit Unsigned Integer 默认值： 8 << 20 osd recovery max single start 描述： OSD恢复时将从新启动的每一个OSD的最大恢复操做数。 类型： 64-bit Unsigned Integer 默认值： 1 osd recovery thread timeout 描述： 恢复现成超时时间 类型： 32-bit Integer 默认值： 30 osd recover clone overlap 描述： Preserves clone overlap during recovery. Should always be set to true. 类型： Boolean 默认值： true osd recovery sleep 描述： 下次恢复或回填操做前的睡眠时间（以秒为单位）。增长此值将减慢恢复操做，同时客户端操做受影响较小。 类型： Float 默认值： 0 osd recovery sleep hdd 描述： 下次恢复或硬盘回填操做以前的休眠时间（以秒为单位）。 类型： Float 默认值： 0.1 osd recovery sleep ssd 描述： 下次恢复以前或回填SSD休眠的时间（以秒为单位）。 类型： Float 默认值： 0 osd recovery sleep hybrid 描述： 当osd数据在HDD上而且osd日志在SSD上时，下一次恢复或回填操做以前的休眠时间（以秒为单位）。 类型： Float 默认值： 0.025

TIERING

osd agent max ops 描述：高速模式下每一个分层代理的最大同时刷新操做数。 类型：32位整数 默认值：4 osd agent max low ops 描述：低速模式下每一个分层代理的最大同时刷新操做数。 类型：32位整数 默认值：2

杂项

osd snap trim thread timeout 描述： snap trim线程超时时间 类型： 32-bit Integer 默认值： 60*60*1 osd backlog thread timeout 描述： backlog线程超时时间 类型： 32-bit Integer 默认值： 60*60*1 osd default notify timeout 描述： OSD默认通知超时（以秒为单位）。 类型： 32-bit Unsigned Integer 默认值： 30 osd check for log corruption 描述： 检查日志文件是否损坏。计算消耗大。 类型： Boolean 默认值： false osd remove thread timeout 描述： remove OSD thread超时时间 类型： 32-bit Integer 默认值： 60*60 osd command thread timeout 描述： command thread超时时间 类型： 32-bit Integer 默认值： 10*60 osd command max records 描述： Limits the number of lost objects to return. 类型： 32-bit Integer 默认值： 256 osd fast fail on connection refused 描述： 若是启用此选项，则链接的对等设备和MON会当即标记崩溃的OSD（假设已崩溃的OSD主机存活）。禁用restore，代价是在I / O操做中OSD崩溃时可能存在长I / O停顿。 类型： Boolean 默认值： true

BlueStore设置

设备

BlueStore管理一个，两个或（在某些状况下）三个存储设备。

在最简单的状况下，BlueStore使用单个（主）存储设备。存储设备一般做为一个总体使用，BlueStore直接占用完整设备。该主设备一般由数据目录中的块符号连接标识。

数据目录挂载成一个tmpfs，它将填充（在启动时或ceph-volume激活它时）全部经常使用的OSD文件，其中包含有关OSD的信息，例如：其标识符，它所属的集群，以及它的私钥。

还能够使用两个额外的设备部署BlueStore：

WAL设备（在数据目录中标识为block.wal）可用于BlueStore的内部日志或预写日志。只有设备比主设备快（例如，当它在SSD上而且主设备是HDD时），使用WAL设备是有用的。
数据库设备（在数据目录中标识为block.db）可用于存储BlueStore的内部元数据。 BlueStore（或者更确切地说，嵌入式RocksDB）将在数据库设备上放置尽量多的元数据以提升性能。若是数据库设备填满，元数据将写到主设备。一样，数据库设备要比主设备更快，则提供数据库设备是有帮助的。

若是只有少许快速存储可用（例如，小于1GB），咱们建议将其用做WAL设备。若是还有更多，配置数据库设备会更有意义。 BlueStore日志将始终放在可用的最快设备上，所以使用数据库设备将提供与WAL设备相同的优点，同时还容许在其中存储其余元数据。

单个设备上配置bluestore

ceph-volume lvm prepare --bluestore --data <device>

指定WAL设备和/或数据库设备，

ceph-volume lvm prepare --bluestore --data <device> --block.wal <wal-device> --block.db <db-device>

注意 - data 能够是使用vg / lv表示法的逻辑卷。其余设备能够是现有逻辑卷或GPT分区

部署

虽然有多种方法能够部署Bluestore OSD，但这里有两个常见的用例，能够帮助阐明初始部署策略：

BLOCK (DATA) ONLY

若是全部设备都是相同的类型，例如全部设备都是HDD，而且没有快速设备来组合这些设备，那么仅使用此方法部署而且不将block.db或block.wal分开是有意义的。对单个/ dev / sda设备的lvm调用以下所示：

ceph-volume lvm create --bluestore --data /dev/sda

若是已经为每一个设备建立了逻辑卷（1个LV使用100％的设备），则对名为ceph-vg / block-lv的lv的lvm调用以下所示：

ceph-volume lvm create --bluestore --data ceph-vg/block-lv

BLOCK AND BLOCK.DB

若是混合使用快速和慢速设备（旋转和固态），建议将block.db放在速度更快的设备上，而块（数据）则放在较慢的设备上（旋转驱动器）。 block.db的大小应该尽量大，以免性能损失。 ceph-volume工具目前没法自动建立，所以须要手动建立卷组和逻辑卷。

对于下面的示例，假设有4个旋转驱动器（sda，sdb，sdc和sdd）和1个固态驱动器（sdx）。首先建立卷组：

$ vgcreate ceph-block-0 /dev/sda $ vgcreate ceph-block-1 /dev/sdb $ vgcreate ceph-block-2 /dev/sdc $ vgcreate ceph-block-3 /dev/sdd

如今建立逻辑卷：

$ lvcreate -l 100%FREE -n block-0 ceph-block-0 $ lvcreate -l 100%FREE -n block-1 ceph-block-1 $ lvcreate -l 100%FREE -n block-2 ceph-block-2 $ lvcreate -l 100%FREE -n block-3 ceph-block-3

咱们正在为四个慢速旋转设备建立4个OSD，所以假设/ dev / sdx中有200GB SSD，咱们将建立4个逻辑卷，每一个50GB：

$ vgcreate ceph-db-0 /dev/sdx $ lvcreate -L 50GB -n db-0 ceph-db-0 $ lvcreate -L 50GB -n db-1 ceph-db-0 $ lvcreate -L 50GB -n db-2 ceph-db-0 $ lvcreate -L 50GB -n db-3 ceph-db-0

最后，使用ceph-volume建立4个OSD：

$ ceph-volume lvm create --bluestore --data ceph-block-0/block-0 --block.db ceph-db-0/db-0 $ ceph-volume lvm create --bluestore --data ceph-block-1/block-1 --block.db ceph-db-0/db-1 $ ceph-volume lvm create --bluestore --data ceph-block-2/block-2 --block.db ceph-db-0/db-2 $ ceph-volume lvm create --bluestore --data ceph-block-3/block-3 --block.db ceph-db-0/db-3

使用混合旋转和固态驱动器设置时，为Bluestore建立足够大的block.db逻辑卷很是重要。一般，block.db应具备尽量大的逻辑卷。

建议block.db大小不小于块的4％。例如，若是块大小为1TB，则block.db不该小于40GB。

若是不使用快速和慢速设备的混合，则不须要为block.db（或block.wal）建立单独的逻辑卷。 Bluestore将在块空间内自动管理这些内容。

缓存自动调节

当tc_malloc配置为内存分配器而且启用了bluestore_cache_autotune设置时，能够将Bluestore配置为自动调整其缓存大小。

默认状况下，此选项当前已启用。 Bluestore将尝试经过osd_memory_target配置选项将OSD堆内存使用量保持在指定的目标大小。这是一种尽力而为的算法，缓存的收缩率不会小于osd_memory_cache_min指定的数量。高速缓存比率基于优先级的层次来选择。若是不提供优先级信息，则将bluestore_cache_meta_ratio和bluestore_cache_kv_ratio选项用做回退。

bluestore_cache_autotune 描述： 在遵循最小值的同时自动调整分配给不一样bluestore缓存的比率。 类型： Boolean 是否必须： Yes 默认值 True osd_memory_target 描述： 当tcmalloc可用且启用了缓存自动调整时，将尝试将这么多字节映射到内存中。 注意：这可能与进程的RSS内存使用不彻底匹配。虽然进程映射的堆内存总量一般应该接近此目标，但没法保证内核实际上将回收未映射的内存。 在最初的开发过程当中，发现一些内核致使OSD的RSS内存超过映射内存高达20％。 然而，假设当存在大量内存压力时，内核一般可能更积极地回收未映射的内存。 类型： Unsigned Integer 是否必须： Yes 默认值 4294967296 bluestore_cache_autotune_chunk_size 描述： 启用高速缓存自动调节时分配给高速缓存的块大小（以字节为单位）。当autotuner将内存分配给不一样的缓存时，它将以chunk的形式分配内存。
这样作是为了不在堆大小或自动调整的高速缓存比率有轻微波动时evictions 类型： Unsigned Integer 是否必须： No 默认值 33554432 bluestore_cache_autotune_interval 描述： 启用高速缓存自动调节后从新平衡的的间隔。将间隔设置得过小会致使CPU使用率太高和性能降低。 类型： Float 是否必须： No 默认值 5 osd_memory_base 描述： 启用tcmalloc和缓存自动调整时，估计OSD所需的最小内存量（以字节为单位）。这用于帮助自动调整器估计高速缓存的预期聚合内存消耗。 类型： Unsigned Interger 是否必须： No 默认值 805306368 osd_memory_expected_fragmentation 描述： 启用tcmalloc和缓存自动调整时，估计内存碎片的百分比。这用于帮助自动调整器估计高速缓存的预期聚合内存消耗。 类型： Float 是否必须： No 默认值 0.15 osd_memory_cache_min 描述： 启用tcmalloc和缓存自动调整时，设置用于缓存的最小内存量。注意：将此值设置得过低会致使明显的缓存抖动。 类型： Unsigned Integer 是否必须： No 默认值 134217728 osd_memory_cache_resize_interval 描述： 启用tcmalloc和缓存自动调整时，调整缓存大小间隔（秒）。此设置更改bluestore可用于缓存的总内存量。注意：将间隔设置得过小会致使内存分配器抖动并下降性能。 类型： Float 是否必须： No 默认值 1

手动调节缓存

BlueStore缓存的每一个OSD消耗的内存量由bluestore_cache_size配置选项决定。若是未设置该配置选项（即，保持为0），则根据是否将HDD或SSD用于主设备（由bluestore_cache_size_ssd和bluestore_cache_size_hdd配置选项设置），使用不一样的默认值。

BlueStore和Ceph OSD的其他部分目前最好可以地严格预算内存。除了配置的高速缓存大小以外，还有OSD自己消耗的内存，而且一般因为内存碎片和其余分配器开销而产生一些开销。

配置的高速缓存内存预算能够经过几种不一样的方式使用：

Key/Value 元数据（即RocksDB的内部缓存）
BlueStore元数据
BlueStore数据（即最近读取或写入的对象数据）

高速缓存内存使用状况由如下选项控制：bluestore_cache_meta_ratio，bluestore_cache_kv_ratio和bluestore_cache_kv_max。专用于数据的缓存部分是1.0减去meta和kv比率。专用于kv元数据的内存（RocksDB缓存）由bluestore_cache_kv_max限制。

bluestore_cache_size 描述： BlueStore将用于其缓存的内存量。若是为零，则将使用bluestore_cache_size_hdd或bluestore_cache_size_ssd。 类型： Unsigned Integer 是否必须： Yes 默认值 0 bluestore_cache_size_hdd 描述： 当由HDD支持时，BlueStore将用于其缓存的默认内存量。 类型： Unsigned Integer 是否必须： Yes 默认值 1 * 1024 * 1024 * 1024 (1 GB) bluestore_cache_size_ssd 描述： 当SSD支持时，BlueStore将用于其缓存的默认内存量。 类型： Unsigned Integer 是否必须： Yes 默认值 3 * 1024 * 1024 * 1024 (3 GB) bluestore_cache_meta_ratio 描述： 专用于元数据的缓存比率。 类型： Floating point 是否必须： Yes 默认值 .01 bluestore_cache_kv_ratio 描述： 专用于键/值数据的缓存比率（rocksdb）。 类型： Floating point 是否必须： Yes 默认值 .99 bluestore_cache_kv_max 描述： 用于键/值数据（rocksdb）的最大缓存量。 类型： Unsigned Integer 是否必须： Yes 默认值 512 * 1024*1024 (512 MB)

校验

BlueStore校验全部写入磁盘的元数据和数据。元数据校验和由RocksDB处理并使用crc32c。数据校验和由BlueStore完成，能够使用crc32c，xxhash32或xxhash64。默认值为crc32c，取值适合大多数用途。

完整数据校验和确实增长了BlueStore必须存储和管理的元数据量。在可能的状况下，例如，当客户端指示数据被顺序写入和读取时，BlueStore将校验更大的块，但在许多状况下，它必须为每4千字节数据块存储校验和值（一般为4个字节）。

经过将校验和截断为两个或一个字节，能够使用较小的校验和值，从而减小元数据开销。权衡的是，随着校验和越小，检测不到随机错误的几率越高，从大约32位（4字节）校验的四十亿分之一到16位（ 2字节）校验的1/65536，和8位（1字节）校验的1/256。经过选择crc32c_16或crc32c_8做为校验和算法，能够使用较小的校验和值。

校验和算法能够经过每一个池的csum_type属性或global config选项设置。例如

ceph osd pool set <pool-name> csum_type <algorithm>

bluestore_csum_type
描述：要使用的默认校验和算法。
类型：String
要求：有
有效设置：none，crc32c，crc32c_16，crc32c_8，xxhash32，xxhash64
默认值：crc32c

内联压缩

BlueStore内联压缩支持snappy，zlib和lz4。lz4压缩插件在官方发行版中不是分布式版本。

BlueStore中的数据是否被压缩是由压缩模式和与写入操做相关的任何提示的组合决定的。压缩模式能够是：

none：从不压缩数据。
passive：除非写入操做具备可压缩的提示集，不然不要压缩数据。
aggressive：压缩数据，除非写入操做具备不可压缩的提示集。
force：尝试压缩数据，不管如何。

有关可压缩和不可压缩IO提示的更多信息，请参阅rados_set_alloc_hint().

请注意，不管模式如何，若是数据块的大小未充分减少，则不会使用它，而且将存储未压缩的原始数据。例如，若是bluestore compression required ratio设置为.7，则压缩数据必须是原始大小（或更小）的70％。

compression mode, compression algorithm, compression required ratio, min blob size, and max blob size能够经过每一个存储池属性或global config选项设置。池属性能够设置为：

ceph osd pool set <pool-name> compression_algorithm <algorithm> ceph osd pool set <pool-name> compression_mode <mode> ceph osd pool set <pool-name> compression_required_ratio <ratio> ceph osd pool set <pool-name> compression_min_blob_size <size> ceph osd pool set <pool-name> compression_max_blob_size <size>

bluestore compression algorithm 描述： 若是未设置每一个存储池的compression_algorithm属性，则使用默认压缩（若是有）。因为在压缩少许数据时CPU负担较高，所以不建议对bluestore使用zstd。 类型： String 是否必须： No 有效值： lz4, snappy, zlib, zstd 默认值 snappy bluestore compression mode 描述： 若是池的compression_mode属性未设置，将使用默认模式 类型： String 是否必须： No 有效值： none, passive, aggressive, force 默认值 none bluestore compression required ratio 描述： 压缩比率必须达到这个值才进行压缩 类型： Floating point 是否必须： No 默认值 .875 bluestore compression min blob size 描述： 比这个还小的chunk不进行压缩.池设置compression_min_blob_size覆盖这个值. 类型： Unsigned Integer 是否必须： No 默认值 0 bluestore compression min blob size hdd 描述： 旋转设备最小blob大小 类型： Unsigned Integer 是否必须： No 默认值 128K bluestore compression min blob size ssd 描述： SSD最小blob大小 类型： Unsigned Integer 是否必须： No 默认值 8K bluestore compression max blob size 描述： 大于此尺寸的chunk会被分割成小块再尽心压缩，池属性 compression_max_blob_size设置覆盖此值 类型： Unsigned Integer 是否必须： No 默认值 0 bluestore compression max blob size hdd 描述： 旋转设备最大blob尺寸 类型： Unsigned Integer 是否必须： No 默认值 512K bluestore compression max blob size ssd 描述： SSD最大blob尺寸 类型： Unsigned Integer 是否必须： No 默认值 64K

SPDK使用

若是要将NVME SSD用于SPDK驱动程序，则须要准备好系统。有关详细信息，请参阅SPDK document。

SPDK提供了一个自动配置设备的脚本。用户能够以root身份运行脚本：

$ sudo src/spdk/scripts/setup.sh

而后，您须要在此指定NVMe设备的设备选择器，并为bluestore_block_path指定“spdk：”前缀。例如，用户能够找到Intel PCIe SSD的设备选择器：

$ lspci -mm -n -D -d 8086:0953

设备选择器的形式为DDDD:BB:DD.FF 或 DDDD.BB.DD.FF，而后设置：

bluestore block path = spdk:0000:01:00.0

其中0000:01:00.0是上面lspci命令输出中找到的设备选择器。

若是要为每一个节点运行多个SPDK实例，则必须指定每一个实例将使用的dpdk内存大小（以MB为单位），以确保每一个实例使用本身的dpdk内存

在大多数状况下，咱们只须要一个设备用做data，db，db wal。咱们须要确认如下配置：

bluestore_block_db_path = "" bluestore_block_db_size = 0 bluestore_block_wal_path = "" bluestore_block_wal_size = 0

不然，当前实现将符号文件设置为内核文件系统位置，并使用内核驱动程序发出DB/WAL IO。

FileStore设置

filestore debug omap check 描述:　　 打开对同步检查过程的调试。代价很高，仅用于调试。 类型:　　 Boolean 是否必需: No 默认值:　　0

扩展属性

扩展属性（ XATTR ）是配置里的重要部分。一些文件系统对 XATTR 字节数有限制，另外在某些状况下文件系统存储 XATTR 的速度不如其余方法。下面的选项让你用独立于文件系统的存储方法，或许能提高性能。

Ceph 扩展属性用底层文件系统的 XATTR （若是没有尺寸限制）存储为 inline xattr 。若是有限制，如 ext4 限制为 4KB ，达到 filestore max inline xattr size 或 filestore max inline xattrs 阀值时一些 XATTR 将存储为键/值数据库（也叫 omap ）。

filestore max inline xattr size 描述： 每一个对象存储在文件系统中的XATTR的最大大小（即XFS，btrfs，ext4等）。不该该大于文件系统能够处理的大小。默认值0表示使用特定于底层文件系统的值。 类型： Unsigned 32-bit Integer 是否必须： No 默认值： 0 filestore max inline xattr size xfs 描述： 存储在XFS文件系统中的XATTR的最大大小。仅在filestore max inline xattr size == 0时使用 类型： Unsigned 32-bit Integer 是否必须： No 默认值： 65536 filestore max inline xattr size btrfs 描述： 存储在btrfs文件系统中的XATTR的最大大小。仅在filestore max inline xattr size == 0时使用。 类型： Unsigned 32-bit Integer 是否必须： No 默认值： 2048 filestore max inline xattr size other 描述： 存储在其余文件系统中的XATTR的最大大小。仅在filestore max inline xattr size == 0时使用。 类型： Unsigned 32-bit Integer 是否必须： No 默认值： 512 filestore max inline xattrs 描述： 每一个对象的文件系统中存储的最大XATTR数。默认值0表示使用特定于底层文件系统的值。 类型： 32-bit Integer 是否必须： No 默认值： 0 filestore max inline xattrs xfs 描述： 每一个对象存储在XFS文件系统中的最大XATTR数。仅在filestore max inline xattrs == 0时使用。 类型： 32-bit Integer 是否必须： No 默认值： 10 filestore max inline xattrs btrfs 描述： 每一个对象存储在btrfs文件系统中的最大XATTR数。仅在filestore max inline xattrs == 0时使用。 类型： 32-bit Integer 是否必须： No 默认值： 10 filestore max inline xattrs other 描述： 每一个对象存储在其余文件系统中的最大XATTR数。仅在filestore max inline xattrs == 0时使用。 类型： 32-bit Integer 是否必须： No 默认值： 2

同步间隔

filestore 须要周期性地静默写入、同步文件系统，这建立了一个提交点，而后就能释放相应的日志条目了。较大的同步频率可减少执行同步的时间及保存在日志里的数据量；较小的频率使得后端的文件系统能优化归并较小的数据和元数据写入，所以可能使同步更有效。

filestore max sync interval 描述: 同步 filestore 的最大间隔秒数。 类型: Double 是否必需: No 默认值: 5 filestore min sync interval 描述: 同步 filestore 的最小间隔秒数。 类型: Double 是否必需: No 默认值: .01

回写器

filestore 回写器强制使用 sync file range 来写出大块数据，这样处理有望减少最终同步的代价。实践中，禁用“ filestore 回写器”有时候能提高性能。

filestore flusher 描述:启用 filestore 回写器。 类型:Boolean 是否必需:No 默认值:false Deprecated since version v.65. filestore flusher max fds 描述:设置回写器的最大文件描述符数量。 类型:Integer 是否必需:No 默认值:512 Deprecated since version v.65. filestore sync flush 描述:启用同步回写器。 类型:Boolean 是否必需:No 默认值:false Deprecated since version v.65. filestore fsync flushes journal data 描述:文件系统同步时也回写日志数据。 类型:Boolean 是否必需:No 默认值:false

队列

filestore queue max ops 描述： 文件存储操做接受的最大并发数，超过此设置的请求会被阻塞。 类型： Integer 是否必须： No. 对性能影响最小 默认值： 50 filestore queue max bytes 描述： 一次操做的最大字节数 类型： Integer 是否必须： No 默认值： 100 << 20

超时

filestore op threads 描述： 容许并行操做文件系统的最大线程数 类型： Integer 是否必须： No 默认值： 2 filestore op thread timeout 描述： 文件系统操做线程超时 (秒). 类型： Integer 是否必须： No 默认值： 60 filestore op thread suicide timeout 描述： commit操做超时时间（秒），超时将取消提交  类型： Integer 是否必须： No 默认值： 180

B-TREE FILESYSTEM

filestore btrfs snap 描述： 对 btrfs filestore 启用快照功能。 类型： Boolean 是否必须： No. Only used for btrfs. 默认值： true filestore btrfs clone range 描述： 容许 btrfs filestore 克隆操做排队。 类型： Boolean 是否必须： No. Only used for btrfs. 默认值： true

日志

filestore journal parallel 描述： 容许并行记日志，对 btrfs 默认开。 类型： Boolean 是否必须： No 默认值： false filestore journal writeahead 描述： 容许预写日志，对 xfs 默认开。 类型： Boolean 是否必须： No 默认值： false

杂项

filestore merge threshold 描述： 并入父目录前，子目录内的最小文件数。注：负值表示禁用子目录合并功能。 类型： Integer 是否必须： No 默认值： -10 filestore split multiple 描述： (filestore_split_multiple * abs(filestore_merge_threshold) + (rand() % filestore_split_rand_factor)) * 16是分割为子目录前某目录内的最大文件数 类型： Integer 是否必须： No 默认值： 2 filestore split rand factor 描述： 添加到拆分阈值的随机因子，以免一次发生太多文件存储拆分。有关详细信息，请参阅filestore split multiple。
这只能在现有的osd离线时经过ceph-objectstore-tool的apply-layout-settings命令更改。 类型： Unsigned 32-bit Integer 是否必须： No 默认值： 20 filestore update to 描述： 限制文件存储自动升级到指定版本。 类型： Integer 是否必须： No 默认值： 1000 filestore blackhole 描述： 丢弃任何讨论中的事务。 类型： Boolean 是否必须： No 默认值： false filestore dump file 描述： 存储事务转储的文件。 类型： Boolean 是否必须： No 默认值： false filestore kill at 描述： 在第n次机会后注入失败 类型： String 是否必须： No 默认值： false filestore fail eio 描述： eio失败/崩溃。 类型： Boolean 是否必须： No 默认值： true

日志设置

Ceph 的 OSD 使用日志的缘由有二：速度和一致性。

速度：日志使得 OSD 能够快速地提交小块数据的写入， Ceph 把小片、随机 IO 依次写入日志，这样，后端文件系统就有可能归并写入动做，并最终提高并发承载力。所以，使用 OSD 日志能展示出优秀的突发写性能，实际上数据尚未写入 OSD ，由于文件系统把它们捕捉到了日志。
一致性： Ceph 的 OSD 守护进程须要一个能保证原子操做的文件系统接口。 OSD 把一个操做的描述写入日志，而后把操做应用到文件系统，这使得原子更新一个对象（例如归置组元数据）。每隔一段 filestore max sync interval 和 filestore min sync interval 之间的时间， OSD 中止写入、把日志同步到文件系统，这样容许 OSD 修整日志里的操做并重用空间。若失败， OSD 从上个同步点开始重放日志。

OSD 守护进程支持下面的日志选项：

journal dio 描述： 启用direct i/o。须要将journal block align设置为true。 类型： Boolean 是否必须： Yes when using aio. 默认值： true journal aio Changed in version 0.61: Cuttlefish 描述： 使用libaio异步写日志. Requires journal dio 设为 true. 类型： Boolean 是否必须： No. 默认值： Version 0.61 and later, true. Version 0.60 and earlier, false. journal block align 描述： 块对齐写. dio and aio须要. 类型： Boolean 是否必须： Yes when using dio and aio. 默认值： true journal max write bytes 描述： 一次写入日志的最大尺寸 类型： Integer 是否必须： No 默认值： 10 << 20 journal max write entries 描述： 一次写入日志的最大条目 类型： Integer 是否必须： No 默认值： 100 journal queue max ops 描述： 队列里容许的最大操做数 类型： Integer 是否必须： No 默认值： 500 journal queue max bytes 描述： 队列一次操做容许的最大尺寸 类型： Integer 是否必须： No 默认值： 10 << 20 journal align min size 描述： 当负载大于指定最小值时对齐 类型： Integer 是否必须： No 默认值： 64 << 10 journal zero on create 描述： 文件存储在mkfs期间用0填充整个日志。 类型： Boolean 是否必须： No 默认值： false

Pool，PG和CRUSH设置

当你建立存储池并给它设置归置组数量时若是你没指定，Ceph 就用默认值。咱们建议更改某些默认值，特别是存储池的副本数和默认归置组数量，能够在运行 pool 命令的时候设置这些值。你也能够把配置写入 Ceph 配置文件的 [global] 段来覆盖默认值。

[global] # By default, Ceph makes 3 replicas of objects. If you want to make four # copies of an object the default value--a primary copy and three replica # copies--reset the default values as shown in 'osd pool default size'. # If you want to allow Ceph to write a lesser number of copies in a degraded # state, set 'osd pool default min size' to a number less than the # 'osd pool default size' value. osd pool default size = 3  # Write an object 3 times. osd pool default min size = 2 # Allow writing two copies in a degraded state. # Ensure you have a realistic number of placement groups. We recommend # approximately 100 per OSD. E.g., total number of OSDs multiplied by 100 # divided by the number of replicas (i.e., osd pool default size). So for # 10 OSDs and osd pool default size = 4, we'd recommend approximately
    # (100 * 10) / 4 = 250. osd pool default pg num = 250 osd pool default pgp num = 250

mon max pool pg num 描述： 每一个池的最大放置组数。 类型： Integer 默认： 65536 mon pg create interval 描述： 在同一个Ceph OSD守护进程中建立PG间隔秒数。 类型： Float 默认： 30.0 mon pg stuck threshold 描述： 多长时间无响应的 PG 才认为它卡住了 类型： 32-bit Integer 默认： 300 mon pg min inactive 描述： 若是PG的数量保持非活动状态超过mon_pg_stuck_threshold设置，则在群集日志中发出HEALTH_ERR。非正数意味着禁用，永远不会进入ERR。 类型： Integer 默认： 1 mon pg warn min per osd 描述： 若是每一个（in）OSD的平均PG数低于此数，则在群集日志中发出HEALTH_WARN。 （非正数会禁用此功能） 类型： Integer 默认： 30 mon pg warn max per osd 描述： 若是每一个（in）OSD的平均PG数高于此数，则在群集日志中发出HEALTH_WARN。 （非正数会禁用此功能） 类型： Integer 默认： 300 mon pg warn min objects 描述： 若是集群中的对象总数低于此数量时不警告 类型： Integer 默认： 1000 mon pg warn min pool objects 描述： 存储池对象数目低于此数量时不警告 类型： Integer 默认： 1000 mon pg check down all threshold 描述： 当检查全部PG的时候，down OSD的比例不低于这个比例 类型： Float 默认： 0.5 mon pg warn max object skew 描述： 若是某个池的平均对象数目大于mon pg warn max object skew乘以整个池的平均对象数目，则在集群日志中发出HEALTH_WARN。 （非正数会禁用此功能） 类型： Float 默认： 10 mon delta reset interval 描述： 在咱们将pg delta重置为0以前不活动的秒数。咱们跟踪每一个池的已用空间的增量，例如，这会让咱们更容易理解恢复的进度或缓存的性能层。可是，若是某个池没有报告任何活动，咱们只需重置该池的增量历史记录。 类型： Integer 默认： 10 mon osd max op age 描述： 在咱们get concerned以前的最大操做时间（使其成为2的幂）。若是请求被阻止超过此限制，将发出HEALTH_WARN。 类型： Float 默认： 32.0 osd pg bits 描述： 每一个Ceph OSD守护进程给PG的bit数。 类型： 32-bit Integer 默认： 6 osd pgp bits 描述： 每一个Ceph OSD守护进程给PGPs的bit数。 类型： 32-bit Integer 默认： 6 osd crush chooseleaf type 描述： CRUSH规则中用于chooseleaf的存储桶类型。使用序数排名而不是名称。 类型： 32-bit Integer 默认： 1. 一般是包含一个或多个Ceph OSD守护进程的host osd crush initial weight 描述： 新添加的osds进入crushmap的初始权重 类型： Double 默认： 以TB为单位的容量大小为权重 osd pool default crush rule 描述： 建立复制池时使用的默认CRUSH规则。 类型： 8-bit Integer 默认： -1表示“选择具备最低数字ID的规则并使用该规则”。这是为了在没有规则0的状况下使池建立工做。 osd pool erasure code stripe unit 描述： 设置纠删池的对象条带块的默认大小（以字节为单位）。大小为S的每一个对象将被存储为N个条带，每一个数据块接收条带单元字节。 每一个条带将被单独编码/解码。纠删配置文件中的stripe_unit设置能够覆盖此选项。 类型： Unsigned 32-bit Integer 默认： 4096 osd pool default size 描述： 设置池中对象的副本数。默认值一样用于ceph osd pool set {pool-name} size {size} 类型： 32-bit Integer 默认： 3 osd pool default min size 描述： 设置池中对象的最小写入副本数，以确认对客户端的写入操做。若是不知足最小值，Ceph将不会确认写入客户端。此设置指示降级模式下运行时最少有多少副本数量。 类型： 32-bit Integer 默认： 0表示没有特定的最小值。若是为0，则最小值为 size - (size / 2). osd pool default pg num 描述： 池的默认PG数 类型： 32-bit Integer 默认： 8 osd pool default pgp num 描述： 池的放置的默认pgp数。 PG和PGP应该相等。 类型： 32-bit Integer 默认： 8 osd pool default flags 描述： 新池的默认标志。 类型： 32-bit Integer 默认： 0 osd max pgls 描述： The maximum number of placement groups to list. A client requesting a large number can tie up the Ceph OSD Daemon. 类型： Unsigned 64-bit Integer 默认： 1024 Note: 默认就好 osd min pg log entries 描述： 修剪日志文件时要维护的最小放置组日志数。 类型： 32-bit Int Unsigned 默认： 1000 osd default data pool replay window 描述： OSD等待客户端重放请求的时间（以秒为单位） 类型： 32-bit Integer 默认： 45 osd max pg per osd hard ratio 描述： 在OSD拒绝建立新PG以前，群集容许的每一个OSD的PG数量的比率。若是服务的PG数超过osd max pg per osd hard ratio * mon max pg per osd，OSD将中止建立新的PG。 类型： Float 默认： 2

消息设置

通用设置

ms tcp nodelay 描述： 在messenger tcp会话上禁用nagle算法。 类型： Boolean 是否必须： No 默认： true ms initial backoff 描述： 出错时重连的初始等待时间 类型： Double 是否必须： No 默认： .2 ms max backoff 描述： 出错重连时等待的最大时间 类型： Double 是否必须： No 默认： 15.0 ms nocrc 描述： 禁用网络消息的 crc 校验， CPU 不足时可提高性能 类型： Boolean 是否必须： No 默认： false ms die on bad msg 描述： 调试选项，无需配置 类型： Boolean 是否必须： No 默认： false ms dispatch throttle bytes 描述： Throttles等待分派的消息的阈值。 类型： 64-bit Unsigned Integer 是否必须： No 默认： 100 << 20 ms bind ipv6 描述： 若是想让守护进程绑定到 IPv6 地址而非 IPv4 就得启用（若是你指定了守护进程或集群 IP 就没必要要了） 类型： Boolean 是否必须： No 默认： false ms rwthread stack bytes 描述： 堆栈尺寸调试选项，不要配置. 类型： 64-bit Unsigned Integer 是否必须： No 默认： 1024 << 10 ms tcp read timeout 描述： 控制信使在关闭空闲链接以前等待的时间（以秒为单位）。 类型： 64-bit Unsigned Integer 是否必须： No 默认： 900 ms inject socket failures 描述： 调试选项，无需配置 类型： 64-bit Unsigned Integer 是否必须： No 默认： 0

ASYNC MESSENGER OPTIONS

ms async transport type 描述： Async Messenger使用的传输类型。能够是posix，dpdk或rdma。 Posix使用标准TCP / IP网络，是默认设置。其余运输多是实验性的，支持可能有限。 类型： String 是否必须： No 默认： posix ms async op threads 描述： 每一个Async Messenger实例使用的初始工做线程数。应该至少等于副本的最大数，但若是您的CPU核心数量不足和/或您在单个服务器上托管了大量OSD，则能够减小它。 类型： 64-bit Unsigned Integer 是否必须： No 默认： 3 ms async max op threads 描述： 每一个Async Messenger实例使用的最大工做线程数。当机器具备有限的CPU数量时设置为较低的值，而当CPU未充分利用时设置为较高的值（即，在I / O操做期间，一个或多个CPU始终处于100％负载状态） 类型： 64-bit Unsigned Integer 是否必须： No 默认： 5 ms async set affinity 描述： 设置为true以将Async Messenger工做程序绑定到特定CPU核心。 类型： Boolean 是否必须： No 默认： true ms async affinity cores 描述： 当ms async set affinity为true时，此字符串指定Async Messenger工做程序如何绑定到CPU核心。
例如，"0,2"将workers ＃1和＃2分别绑定到CPU核心＃0和＃2。注意：手动设置关联时，请确保不将workers 分配给做为超线程或相似技术的效果而建立的虚拟CPU处理器，由于它们比常规CPU核心慢。 类型： String 是否必须： No 默认： (empty) ms async send inline 描述： 直接从生成消息的线程发送消息，而不是从Async Messenger线程排队和发送。已知此选项会下降具备大量CPU内核的系统的性能，所以默认状况下禁用此选项。 类型： Boolean 是否必须： No 默认： false

常规设置

fsid 描述： 文件系统 ID，每集群一个。 类型： UUID 是否必须： No. 默认： N/A. 一般由部署工具生成。 admin socket 描述： 在某个守护进程上执行管理命令的套接字，无论 Ceph 监视器团体是否已创建。 类型： String 是否必须： No 默认： /var/run/ceph/$cluster-$name.asok pid file 描述： mon、osd、mds 将把它们的 PID 写入此文件，其名为 /var/run/$cluster/$type.$id.pid 。
如名为Ceph的集群，其 ID为a的mon进程将建立 /var/run/ceph/mon.a.pid 。若是是正常中止的，pid file 就会被守护进程删除；若是进程未进入后台运行（即启动时加了 -f 或 -d 选项），它就不会建立 pid file 。 类型： String 是否必须： No 默认： No chdir 描述： Ceph 进程一旦启动、运行就进入这个目录，默认推荐 / 类型： String 是否必须： No 默认： / max open files 描述： 若是设置了， Ceph 存储集群启动时会设置操做系统的 max open fds （即文件描述符最大容许值），这有助于防止耗尽文件描述符。 类型： 64-bit Integer 是否必须： No 默认： 0 fatal signal handlers 描述： 若是设置了，将安装 SEGV 、 ABRT 、 BUS 、 ILL 、 FPE 、 XCPU 、 XFSZ 、 SYS 信号处理器，用于产生有用的日志信息。 类型： Boolean 默认： true