CEPH集群操作入门--配置

时间:2022-07-06 23:52:53
 
 

概述

Ceph存储集群是所有Ceph部署的基础。 基于RADOS,Ceph存储集群由两种类型的守护进程组成:Ceph OSD守护进程(OSD)将数据作为对象存储在存储节点上; Ceph Monitor(MON)维护集群映射的主副本。 Ceph存储集群可能包含数千个存储节点。 最小系统将至少有一个Ceph Monitor和两个Ceph OSD守护进程用于数据复制。
 
Ceph文件系统,Ceph对象存储和Ceph块设备从Ceph存储集群读取数据并将数据写入Ceph存储集群。
 
配置和部署
Ceph存储集群有一些必需的设置,但大多数配置设置都有默认值。 典型部署使用部署工具来定义集群并引导监视器。 有关ceph-deploy的详细信息,请参阅部署。
 

配置

存储设备

概述

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

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

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

准备硬盘

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

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

sudo hdparm -W 0 /dev/hda 0

在生产环境,我们建议操作系统和OSD数据分别放到不同的硬盘。如果必须把数据和系统放在同一硬盘里,最好给数据分配一个单独的分区。

OSD后端

OSD可以通过两种方式管理它们存储的数据。从Luminous 12.2.z版本开始,新的默认(和推荐)后端是BlueStore。在Luminous之前,默认(也是唯一的选项)是FileStore。

BLUESTORE

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

  • 直接管理存储设备。 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] 段下;用 btrfsxfs 时可以选填。

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
  • $id

  描述:扩展为守护程序或客户端标识符。 对于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 配置文件位置相继排列如下:

  1. $CEPH_CONF(CEPH_CONF环境变量所指示的路径);
  2. -c path / path(-c命令行参数);
  3. /etc/ceph/ceph.conf
  4. 〜/.ceph/配置
  5. ./ceph.conf(就是当前所在的工作路径。
  6. 仅限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. debug_ms 

请注意,如果在本地配置文件中也自定义了相同的选项,则将忽略监视器设置(其优先级低于本地配置文件)。

覆盖参数值

您还可以使用Ceph CLI上的tell或daemon接口临时设置选项。 这些覆盖值是短暂的,因为它们只影响正在运行的进程,并且在守护进程或进程重新启动时被丢弃/丢失。

覆盖值可以通过两种方式设置:

1.从任何主机,我们都可以通过网络向守护进程发送消息:

ceph tell osd. config set debug_osd 

tell命令还可以接受守护程序标识符的通配符。 例如,要调整所有OSD守护进程的调试级别:

ceph tell osd.* config set debug_osd 

2.从进程运行的主机开始,我们可以通过/ var / run / ceph中的套接字直接连接到进程:

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

例如

ceph daemon osd. config set debug_osd 

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

查看运行参数值

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

ceph config show osd.

将显示该守护进程的(非默认)选项。 您还可以通过以下方式查看特定选项:

ceph config show osd. debug_osd

或查看所有选项(即使是那些具有默认值的选项):

ceph config show-with-defaults osd.

您还可以通过管理套接字从本地主机连接到该守护程序来观察正在运行的守护程序的设置。 例如:

ceph daemon osd. config show

将转储所有当前设置:

ceph daemon osd. config diff

将仅显示非默认设置(以及值来自的位置:配置文件,监视器,覆盖等),以及:

ceph daemon osd. 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:

默认情况下,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 = [osd.]
host = {hostname} #manual deployments only.

默认情况下,Ceph希望您使用以下路径存储Ceph OSD守护程序的数据:

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

您或部署工具(例如,ceph-deploy)必须创建相应的目录。 在完全表达元变量和名为“ceph”的集群的情况下,上述目录将评估为:

/var/lib/ceph/osd/ceph-

您可以使用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.
# for a -node cluster.
# for a multi node cluster in a single rack
# for a multi node, multi chassis cluster with multiple hosts in a chassis
# 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-
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 存储集群:一个公共网(前端)和一个集群网(后端)。为此,各节点得配备多个网卡

CEPH集群操作入门--配置

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

  1. 性能: OSD 为客户端处理数据复制,复制多份时 OSD 间的网络负载势必会影响到客户端和 Ceph 集群的通讯,包括延时增加、产生性能问题;恢复和重均衡也会显著增加公共网延时。
  2. 安全: 大多数人都是良民,很少的一撮人喜欢折腾拒绝服务攻击( 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  -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 : -j ACCEPT

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

CEPH集群操作入门--配置

当某个守护进程失败并重启时没释放端口,重启后的进程就会监听新端口。你应该打开整个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 : -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}: [osd.]
host = {hostname}

您不必为守护程序设置主机IP地址。 如果您具有静态IP配置并且公共和集群网络都在运行,则Ceph配置文件可以为每个守护程序指定主机的IP地址。 要为守护程序设置静态IP地址,以下选项应出现在ceph.conf文件的守护程序实例部分中。

[osd.]
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/ ),置于 [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/ ),置于 [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 可绑定的最小端口号。
类型:-bit Integer
默认值:
是否必需:No ms bind port max
描述:OSD 或 MDS 可绑定的最大端口号。
类型:-bit Integer
默认值:
是否必需: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.] 。
类型: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
描述:网络套接字接收缓冲尺寸,默认禁用。
类型:-bit Integer
是否必需:No
默认值: ms tcp read timeout
描述:如果一客户端或守护进程发送请求到另一个 Ceph 守护进程,且没有断开不再使用的连接,在 ms tcp read timeout 指定的秒数之后它将被标记为空闲。
类型:Unsigned -bit Integer
是否必需:No
默认值: 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-

你可以覆盖这些位置,但不推荐。

签名

在 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
默认值:*

Monitor设置

概述

理解如何配置Ceph监视器是构建可靠的Ceph存储集群的重要方面,任何Ceph集群都需要至少一个监视器。一个监视器通常相当一致,但是你可以增加,删除,或替换集群中的监视器

背景

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

CEPH集群操作入门--配置

自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:,10.0.0.11:,10.0.0.12:
[mon.a]
host = hostname1
mon addr = 10.0.0.10:

这里的监视器最简配置假设部署工具会自动给你生成 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 需要奇数个监视器来确定最初法定人数(如 )。
类型: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。
类型:整型
默认值: * * * * mon data avail warn
描述:当监视器数据存储的可用磁盘空间小于或等于此百分比时,在群集日志中发出HEALTH_WARN。
类型:整型
默认值: mon data avail crit
描述:当监视器数据存储的可用磁盘空间小于或等于此百分比时,在群集日志中发出HEALTH_ERR。
类型:整型
默认值: 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
默认值: mon health to clog
描述:定期启用向群集日志发送运行状况摘要。
类型:Boolean
默认值:true mon health to clog tick interval
描述:监视器将健康摘要发送到群集日志的频率(以秒为单位)(非正数禁用它)。 如果当前运行状况摘要为空或与上次相同,则监视器不会将其发送到群集日志。
类型:整型
默认值: mon health to clog interval
描述:监视器将健康摘要发送到群集日志的频率(以秒为单位)(非正数禁用它)。 无论摘要是否更改,Monitor都将始终将摘要发送到群集日志。
类型:整型
默认值:

存储容量

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 。

CEPH集群操作入门--配置

在这样的集群里,坏一或两个 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 = .
mon osd backfillfull ratio = .
mon osd nearfull ratio = .
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 同步。

CEPH集群操作入门--配置

新监视器加入集群时有必要进行同步。在运行中,监视器会不定时收到集群运行图的更新,这就意味着 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).
类型: -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 ( disables it)
类型: Integer
默认: 250
paxos service trim max
描述: The maximum amount of versions to trim during a single proposal ( 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 ( 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 ( 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.
类型: -bit Integer
默认: 500
mon max pgmap epochs
描述: Maximum number of PG map epochs the monitor should keep.
类型: -bit Integer
默认: 500 mon max log epochs
描述: Maximum number of Log epochs the monitor should keep.
类型: -bit Integer
默认:

时钟

Ceph守护进程将关键消息传递给彼此,必须在守护进程达到超时阈值之前处理这些消息。 如果Ceph监视器中的时钟不同步,则可能导致许多异常。 例如:

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

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

时钟漂移即使尚未造成损坏也能被 NTP 感知, Ceph 的时钟漂移或时钟偏差警告即使在 NTP 同步水平合理时也会被触发。提高时钟漂移值有时候尚可容忍, 然而很多因素(像载荷、网络延时、覆盖默认超时值和监控器存储同步选项)都能在不降低 Paxos 保证级别的情况下影响可接受的时钟漂移水平。

Ceph 提供了下列这些可调选项,让你自己琢磨可接受的值。

clock offset
描述: 时钟可以漂移多少,详情见 Clock.cc 。
类型: Double
默认:
自0.58版以来已弃用。 mon tick interval
描述: 监视器的心跳间隔,单位为秒。
类型: -bit Integer
默认: mon clock drift allowed
描述: 监视器间允许的时钟漂移量
类型: Float
默认: . mon clock drift warn backoff
描述: 时钟偏移警告的退避指数。
类型: Float
默认: 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
默认: mon client bytes
描述: 内存中允许存留的客户端消息数量(字节数)。
类型: -bit Integer Unsigned
默认: 100ul <<

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 数量。
类型: -bit Integer
默认: mon globalid prealloc
描述: 为集群和客户端预分配的全局 ID 数量。
类型: -bit Integer
默认: mon subscribe interval
描述: 同步的刷新间隔(秒),同步机制允许获取集群运行图和日志信息。
类型: Double
默认: mon stat smooth intervals
描述: Ceph将平滑最后N个PG地图的统计数据。
类型: Integer
默认: mon probe timeout
描述: 监视器在bootstrapping之前等待查找peers对等体的秒数。
类型: Double
默认: 2.0 mon daemon bytes
描述: 给mds和 OSD 的消息使用的内存空间(字节)。
类型: -bit Integer Unsigned
默认: 400ul << mon max log entries per event
描述: 每个事件允许的最大日志条数。
类型: Integer
默认: 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
默认: mon config key max entry size
描述: config-key条目的最大大小(以字节为单位)
类型: Integer
默认: 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
默认: * mon scrub max keys
描述: The maximum number of keys to scrub each time.
类型: Integer
默认: 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
默认: 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
默认: mon session timeout
描述: Monitor will terminate inactive sessions stay idle over this time limit.
类型: Integer
默认:

通过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 可更改宽限期、或者运行时更改。

CEPH集群操作入门--配置

死亡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设置或在运行时设置值。

CEPH集群操作入门--配置

报告互连失败

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

CEPH集群操作入门--配置

报告自己的状态

如果一 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报告间隔,或运行时更改。

CEPH集群操作入门--配置

配置

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

监视器选项

mon osd min up ratio
描述: 在把 OSD 标记为 down 前,保持处于 up 状态的 OSD 最小比例。
类型: Double
默认: . mon osd min in ratio
描述: 在把 OSD 标记为 out 前,保持处于 in 状态的 OSD 最小比例
类型: Double
默认: . mon osd laggy halflife
描述: The number of seconds laggy estimates will decay.
类型: Integer
默认: * 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
默认: 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 停止响应多少秒后把它标记为 downout
类型: -bit Integer
默认: mon osd down out subtree limit
描述: Ceph不会自动标记的最小CRUSH单位类型。例如,如果设置为host,如果host的所有OSD都关闭,Ceph将不会自动标记这些OSD。
类型: String
默认: rack mon osd report timeout
描述: 在声明无响应的Ceph OSD守护进程down之前的宽限期(以秒为单位)。
类型: -bit Integer
默认: mon osd min down reporters
描述: 报告Ceph OSD守护进程down所需的最小Ceph OSD守护进程数。
类型: -bit Integer
默认: 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探测它的邻居的间隔时间(秒)
类型: -bit Integer
默认: osd heartbeat grace
描述: Ceph OSD守护进程没有显示Ceph存储集群认为它已关闭的心跳所经过的时间。 必须在[mon]和[osd]或[global]部分中设置此设置,以便MON和OSD守护程序都可以读取它。
类型: -bit Integer
默认: osd mon heartbeat interval
描述: OSD 没有邻居时多久探测一次监视器
类型: -bit Integer
默认: osd mon report interval
描述: 监视器允许 OSD 报告的最大间隔,超时将认为 OSD 挂了( down )。
类型: -bit Integer
默认: osd mon ack timeout
描述: 等待Ceph Monitor确认统计请求的秒数。
类型: -bit Integer
默认:

OSD设置

概述

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

Ceph 的 OSD 守护进程用递增的数字作标识,按惯例以 0 开始,如下:

osd.
osd.
osd.

在配置文件里, [osd] 段下的配置适用于所有 OSD ;要添加针对特定 OSD 的选项(如 host ),把它放到那个 OSD 段下即可,如

[osd]
osd journal size = [osd.]
host = osd-host-a [osd.]
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。
类型: -bit Integer
默认: osd max object size
描述: 一个object最大大小(字节)bytes.
类型: -bit Unsigned Integer
默认: 128MB osd client message size cap
描述: 内存里允许的最大客户端数据消息。
类型: -bit Unsigned Integer
默认: 500MB default. *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
Default for other file systems:
{empty string}
For example::
osd mkfs options xfs = -f -d agcount= 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=

日志选项

默认情况下,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)
类型: -bit Integer
默认:

监视器OSD交互

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

数据放置

有关详细信息,请参见Pool&PG Config Reference。

SCRUBBING

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

洗刷对维护数据完整性很重要,但会影响性能;你可以用下列选项来增加或减少洗刷操作。

osd max scrubs
描述: Ceph OSD守护进程的最大同步清理操作数。
类型: -bit Int
默认: osd scrub begin hour
描述: 清理的下限时间
类型: Integer in the range of to
默认: osd scrub end hour
描述: 可以执行预定清理时的上限时间。 与osd scrub begin hour一起定义了一个时间窗口,可以在其中进行擦洗。 但是,无论时间窗口是否允许,只要放置组的擦洗间隔超过osd scrub max interval都将进行擦洗。
默认: osd scrub during recovery
描述: 在恢复期间允许擦洗。 将此设置为false将禁用在有活动恢复时安排新的清理(和深度清理)。 如果已经开始将继续执行。 这有助于减轻集群繁忙时上的负载。
类型: Boolean
默认: true osd scrub thread timeout
描述: The maximum time in seconds before timing out a scrub thread.
类型: -bit Integer
默认: osd scrub finalize thread timeout
描述: The maximum time in seconds before timing out a scrub finalize thread.
类型: -bit Integer
默认: * osd scrub load threshold
描述: 标准化的最大负载。 当系统负载(由getloadavg()/online cpu numbers)高于此数字时,Ceph不会擦除。
类型: Float
默认: 0.5 osd scrub min interval
描述: 当Ceph存储集群负载较低时,擦除Ceph OSD守护程序的最小间隔(秒)。
类型: Float
默认: Once per day. ** osd scrub max interval
描述: 无论群集负载如何,擦除Ceph OSD守护进程的最大间隔(秒)。
类型: Float
默认: Once per week. *** osd scrub chunk min
描述: 在单个操作期间要擦除的最小数量的对象存储块。 Ceph在擦洗期间阻止写入单个块。
类型: -bit Integer
默认: osd scrub chunk max
描述: 单个操作期间要擦除的最大对象存储块数。
类型: -bit Integer
默认: osd scrub sleep
描述: 在擦洗下一组块之前休眠的时间。 增加此值将减慢整个清理操作,同时客户端操作受影响较小
类型: Float
默认: osd deep scrub interval
描述: 深度”清理的间隔(完全读取所有数据)。 osd scrub load threshold不会影响此设置。
类型: Float
默认: Once per week. *** 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
描述: 深层洗刷时的读取尺寸
类型: -bit Integer
默认: KB.

操作选项

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位整数
默认值:
有效范围:- osd recovery op priority
描述:为恢复操作设置的优先级。它与osd client op priority关联。
类型:32位整数
默认值:
有效范围:- osd scrub priority
描述:为清理操作设置的优先级。它与 osd client op priority相关。
类型:32位整数
默认值:
有效范围:- osd snap trim priority
描述:为snap trim操作设置的优先级。它与osd client op priority相关。
类型:32位整数
默认值:
有效范围:- osd op thread timeout
描述:Ceph OSD守护进程操作线程超时(秒)。
类型:32位整数
默认值: osd op complaint time
描述:在指定的秒数过后,操作becomes complaint worthy。
类型:float
默认值: osd disk threads
描述:磁盘线程数,用于执行后台磁盘密集型OSD操作,例如scrubbing 和snap trimming。
类型:32位整数
默认值: osd disk thread ioprio class
描述:警告:仅当osd disk thread ioprio class和osd disk thread ioprio priority都设置为非默认值时才会使用它。
ioprio_set() 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() I/O scheduling priority,范围从0(最高)到7(最低)。
如果给定主机上的所有OSD都处于空闲状态并且竞争I / O(即由于控制器拥塞),则可以使用它将一个OSD的磁盘线程优先级降低到7,以便优先级为0的另一个OSD可以具有优先级。
注意:仅适用于Linux内核CFQ调度程序。
类型:整数,范围为0到7,如果不使用为-。
默认值:- osd op history size
描述:跟踪已完成操作的最大数量。
键入:32位无符号整数
默认值: osd op history duration
描述:最早完成的操作跟踪。
键入:32位无符号整数
默认值: osd op log threshold
描述:一次显示多少个操作日志。
类型:32位整数
默认值:

基于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操作的开销
类型:无符号整数
默认值: osd recovery max chunk
描述:恢复操作可以携带的数据块的最大大小。
类型:无符号整数
默认值: 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允许的最大回填数
类型: -bit Unsigned Integer
默认值: osd backfill scan min
描述: 每次回填的最小对象数目
类型: -bit Integer
默认值: osd backfill scan max
描述: 每次回填的最大对象数目
类型: -bit Integer
默认值: 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数目
类型: -bit Integer
默认值: osd map cache bl size
描述: OSD守护进程中内存中OSD map缓存的大小。
类型: -bit Integer
默认值: osd map cache bl inc size
描述: OSD守护进程中内存中OSD映射缓存增量尺寸。
类型: -bit Integer
默认值: osd map message max
描述: 每个 MOSDMap 图消息允许的最大条目数量。
类型: -bit Integer
默认值:

RECOVERY

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

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

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

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

TIERING

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

杂项

osd snap trim thread timeout
描述: snap trim线程超时时间
类型: -bit Integer
默认值: ** osd backlog thread timeout
描述: backlog线程超时时间
类型: -bit Integer
默认值: ** osd default notify timeout
描述: OSD默认通知超时(以秒为单位)。
类型: -bit Unsigned Integer
默认值: osd check for log corruption
描述: 检查日志文件是否损坏。计算消耗大。
类型: Boolean
默认值: false osd remove thread timeout
描述: remove OSD thread超时时间
类型: -bit Integer
默认值: * osd command thread timeout
描述: command thread超时时间
类型: -bit Integer
默认值: * osd command max records
描述: Limits the number of lost objects to return.
类型: -bit Integer
默认值: 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- /dev/sda
$ vgcreate ceph-block- /dev/sdb
$ vgcreate ceph-block- /dev/sdc
$ vgcreate ceph-block- /dev/sdd

现在创建逻辑卷:

$ lvcreate -l %FREE -n block- ceph-block-
$ lvcreate -l %FREE -n block- ceph-block-
$ lvcreate -l %FREE -n block- ceph-block-
$ lvcreate -l %FREE -n block- ceph-block-

我们正在为四个慢速旋转设备创建4个OSD,因此假设/ dev / sdx中有200GB SSD,我们将创建4个逻辑卷,每个50GB:

$ vgcreate ceph-db- /dev/sdx
$ lvcreate -L 50GB -n db- ceph-db-
$ lvcreate -L 50GB -n db- ceph-db-
$ lvcreate -L 50GB -n db- ceph-db-
$ lvcreate -L 50GB -n db- ceph-db-

最后,使用ceph-volume创建4个OSD:

$ ceph-volume lvm create --bluestore --data ceph-block-/block- --block.db ceph-db-/db-
$ ceph-volume lvm create --bluestore --data ceph-block-/block- --block.db ceph-db-/db-
$ ceph-volume lvm create --bluestore --data ceph-block-/block- --block.db ceph-db-/db-
$ ceph-volume lvm create --bluestore --data ceph-block-/block- --block.db ceph-db-/db-

使用混合旋转和固态驱动器设置时,为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
默认值 bluestore_cache_autotune_chunk_size
描述: 启用高速缓存自动调节时分配给高速缓存的块大小(以字节为单位)。当autotuner将内存分配给不同的缓存时,它将以chunk的形式分配内存。
这样做是为了避免在堆大小或自动调整的高速缓存比率有轻微波动时evictions
类型: Unsigned Integer
是否必须: No
默认值 bluestore_cache_autotune_interval
描述: 启用高速缓存自动调节后重新平衡的的间隔。将间隔设置得太小会导致CPU使用率过高和性能下降。
类型: Float
是否必须: No
默认值 osd_memory_base
描述: 启用tcmalloc和缓存自动调整时,估计OSD所需的最小内存量(以字节为单位)。这用于帮助自动调整器估计高速缓存的预期聚合内存消耗。
类型: Unsigned Interger
是否必须: No
默认值 osd_memory_expected_fragmentation
描述: 启用tcmalloc和缓存自动调整时,估计内存碎片的百分比。这用于帮助自动调整器估计高速缓存的预期聚合内存消耗。
类型: Float
是否必须: No
默认值 0.15 osd_memory_cache_min
描述: 启用tcmalloc和缓存自动调整时,设置用于缓存的最小内存量。注意:将此值设置得太低会导致明显的缓存抖动。
类型: Unsigned Integer
是否必须: No
默认值 osd_memory_cache_resize_interval
描述: 启用tcmalloc和缓存自动调整时,调整缓存大小间隔(秒)。此设置更改bluestore可用于缓存的总内存量。注意:将间隔设置得太小会导致内存分配器抖动并降低性能。
类型: Float
是否必须: No
默认值

手动调节缓存

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
默认值 bluestore_cache_size_hdd
描述: 当由HDD支持时,BlueStore将用于其缓存的默认内存量。
类型: Unsigned Integer
是否必须: Yes
默认值 * * * ( GB) bluestore_cache_size_ssd
描述: 当SSD支持时,BlueStore将用于其缓存的默认内存量。
类型: Unsigned Integer
是否必须: Yes
默认值 * * * ( GB) bluestore_cache_meta_ratio
描述: 专用于元数据的缓存比率。
类型: Floating point
是否必须: Yes
默认值 . bluestore_cache_kv_ratio
描述: 专用于键/值数据的缓存比率(rocksdb)。
类型: Floating point
是否必须: Yes
默认值 . bluestore_cache_kv_max
描述: 用于键/值数据(rocksdb)的最大缓存量。
类型: Unsigned Integer
是否必须: Yes
默认值 * * ( 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
默认值 . bluestore compression min blob size
描述: 比这个还小的chunk不进行压缩.池设置compression_min_blob_size覆盖这个值.
类型: Unsigned Integer
是否必须: No
默认值 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
默认值 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 :

设备选择器的形式为DDDD:BB:DD.FF 或 DDDD.BB.DD.FF,然后设置:

bluestore block path = spdk:::00.0

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

如果要为每个节点运行多个SPDK实例,则必须指定每个实例将使用的dpdk内存大小(以MB为单位),以确保每个实例使用自己的dpdk内存

在大多数情况下,我们只需要一个设备用作data,db,db wal。 我们需要确认以下配置:

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

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

FileStore设置

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

扩展属性

扩展属性( 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 -bit Integer
是否必须: No
默认值: filestore max inline xattr size xfs
描述: 存储在XFS文件系统中的XATTR的最大大小。仅在filestore max inline xattr size == 0时使用
类型: Unsigned -bit Integer
是否必须: No
默认值: filestore max inline xattr size btrfs
描述: 存储在btrfs文件系统中的XATTR的最大大小。仅在filestore max inline xattr size == 0时使用。
类型: Unsigned -bit Integer
是否必须: No
默认值: filestore max inline xattr size other
描述: 存储在其他文件系统中的XATTR的最大大小。仅在filestore max inline xattr size == 0时使用。
类型: Unsigned -bit Integer
是否必须: No
默认值: filestore max inline xattrs
描述: 每个对象的文件系统中存储的最大XATTR数。默认值0表示使用特定于底层文件系统的值。
类型: -bit Integer
是否必须: No
默认值: filestore max inline xattrs xfs
描述: 每个对象存储在XFS文件系统中的最大XATTR数。仅在filestore max inline xattrs == 0时使用。
类型: -bit Integer
是否必须: No
默认值: filestore max inline xattrs btrfs
描述: 每个对象存储在btrfs文件系统中的最大XATTR数。仅在filestore max inline xattrs == 0时使用。
类型: -bit Integer
是否必须: No
默认值: filestore max inline xattrs other
描述: 每个对象存储在其他文件系统中的最大XATTR数。仅在filestore max inline xattrs == 0时使用。
类型: -bit Integer
是否必须: No
默认值:

同步间隔

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

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

回写器

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

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

队列

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

超时

filestore op threads
描述: 允许并行操作文件系统的最大线程数
类型: Integer
是否必须: No
默认值: filestore op thread timeout
描述: 文件系统操作线程超时 (秒).
类型: Integer
是否必须: No
默认值: filestore op thread suicide timeout
描述: commit操作超时时间(秒),超时将取消提交
类型: Integer
是否必须: No
默认值:

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
默认值: - filestore split multiple
描述: (filestore_split_multiple * abs(filestore_merge_threshold) + (rand() % filestore_split_rand_factor)) * 16是分割为子目录前某目录内的最大文件数
类型: Integer
是否必须: No
默认值: filestore split rand factor
描述: 添加到拆分阈值的随机因子,以避免一次发生太多文件存储拆分。有关详细信息,请参阅filestore split multiple。
这只能在现有的osd离线时通过ceph-objectstore-tool的apply-layout-settings命令更改。
类型: Unsigned -bit Integer
是否必须: No
默认值: filestore update to
描述: 限制文件存储自动升级到指定版本。
类型: Integer
是否必须: No
默认值: 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
默认值: << journal max write entries
描述: 一次写入日志的最大条目
类型: Integer
是否必须: No
默认值: journal queue max ops
描述: 队列里允许的最大操作数
类型: Integer
是否必须: No
默认值: journal queue max bytes
描述: 队列一次操作允许的最大尺寸
类型: Integer
是否必须: No
默认值: << journal align min size
描述: 当负载大于指定最小值时对齐
类型: Integer
是否必须: No
默认值: << journal zero on create
描述: 文件存储在mkfs期间用0填充整个日志。
类型: Boolean
是否必须: No
默认值: false

Pool,PG和CRUSH设置

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

[global]

    # By default, Ceph makes  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 = # Write an object times.
osd pool default min size = # Allow writing two copies in a degraded state. # Ensure you have a realistic number of placement groups. We recommend
# approximately per OSD. E.g., total number of OSDs multiplied by
# divided by the number of replicas (i.e., osd pool default size). So for
# OSDs and osd pool default size = , we'd recommend approximately
# ( * ) / = . osd pool default pg num =
osd pool default pgp num =
mon max pool pg num
描述: 每个池的最大放置组数。
类型: Integer
默认: mon pg create interval
描述: 在同一个Ceph OSD守护进程中创建PG间隔秒数。
类型: Float
默认: 30.0 mon pg stuck threshold
描述: 多长时间无响应的 PG 才认为它卡住了
类型: -bit Integer
默认: mon pg min inactive
描述: 如果PG的数量保持非活动状态超过mon_pg_stuck_threshold设置,则在群集日志中发出HEALTH_ERR。非正数意味着禁用,永远不会进入ERR。
类型: Integer
默认: mon pg warn min per osd
描述: 如果每个(in)OSD的平均PG数低于此数,则在群集日志中发出HEALTH_WARN。 (非正数会禁用此功能)
类型: Integer
默认: mon pg warn max per osd
描述: 如果每个(in)OSD的平均PG数高于此数,则在群集日志中发出HEALTH_WARN。 (非正数会禁用此功能)
类型: Integer
默认: mon pg warn min objects
描述: 如果集群中的对象总数低于此数量时不警告
类型: Integer
默认: mon pg warn min pool objects
描述: 存储池对象数目低于此数量时不警告
类型: Integer
默认: 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
默认: mon delta reset interval
描述: 在我们将pg delta重置为0之前不活动的秒数。我们跟踪每个池的已用空间的增量,例如,这会让我们更容易理解恢复的进度或缓存的性能层。但是,如果某个池没有报告任何活动,我们只需重置该池的增量历史记录。
类型: Integer
默认: mon osd max op age
描述: 在我们get concerned之前的最大操作时间(使其成为2的幂)。如果请求被阻止超过此限制,将发出HEALTH_WARN。
类型: Float
默认: 32.0 osd pg bits
描述: 每个Ceph OSD守护进程给PG的bit数。
类型: -bit Integer
默认: osd pgp bits
描述: 每个Ceph OSD守护进程给PGPs的bit数。
类型: -bit Integer
默认: osd crush chooseleaf type
描述: CRUSH规则中用于chooseleaf的存储桶类型。使用序数排名而不是名称。
类型: -bit Integer
默认: . 通常是包含一个或多个Ceph OSD守护进程的host osd crush initial weight
描述: 新添加的osds进入crushmap的初始权重
类型: Double
默认: 以TB为单位的容量大小为权重 osd pool default crush rule
描述: 创建复制池时使用的默认CRUSH规则。
类型: -bit Integer
默认: -1表示“选择具有最低数字ID的规则并使用该规则”。这是为了在没有规则0的情况下使池创建工作。 osd pool erasure code stripe unit
描述: 设置纠删池的对象条带块的默认大小(以字节为单位)。大小为S的每个对象将被存储为N个条带,每个数据块接收条带单元字节。 每个条带将被单独编码/解码。纠删配置文件中的stripe_unit设置可以覆盖此选项。
类型: Unsigned -bit Integer
默认: osd pool default size
描述: 设置池中对象的副本数。默认值同样用于ceph osd pool set {pool-name} size {size}
类型: -bit Integer
默认: osd pool default min size
描述: 设置池中对象的最小写入副本数,以确认对客户端的写入操作。如果不满足最小值,Ceph将不会确认写入客户端。此设置指示降级模式下运行时最少有多少副本数量。
类型: -bit Integer
默认: 0表示没有特定的最小值。如果为0,则最小值为 size - (size / ). osd pool default pg num
描述: 池的默认PG数
类型: -bit Integer
默认: osd pool default pgp num
描述: 池的放置的默认pgp数。 PG和PGP应该相等。
类型: -bit Integer
默认: osd pool default flags
描述: 新池的默认标志。
类型: -bit Integer
默认: 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 -bit Integer
默认:
Note: 默认就好 osd min pg log entries
描述: 修剪日志文件时要维护的最小放置组日志数。
类型: -bit Int Unsigned
默认: osd default data pool replay window
描述: OSD等待客户端重放请求的时间(以秒为单位)
类型: -bit Integer
默认: 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
默认:

消息设置

通用设置

ms tcp nodelay
描述: 在messenger tcp会话上禁用nagle算法。
类型: Boolean
是否必须: No
默认: true ms initial backoff
描述: 出错时重连的初始等待时间
类型: Double
是否必须: No
默认: . 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等待分派的消息的阈值。
类型: -bit Unsigned Integer
是否必须: No
默认: << ms bind ipv6
描述: 如果想让守护进程绑定到 IPv6 地址而非 IPv4 就得启用(如果你指定了守护进程或集群 IP 就不必要了)
类型: Boolean
是否必须: No
默认: false ms rwthread stack bytes
描述: 堆栈尺寸调试选项,不要配置.
类型: -bit Unsigned Integer
是否必须: No
默认: << ms tcp read timeout
描述: 控制信使在关闭空闲连接之前等待的时间(以秒为单位)。
类型: -bit Unsigned Integer
是否必须: No
默认: ms inject socket failures
描述: 调试选项,无需配置
类型: -bit Unsigned Integer
是否必须: No
默认:

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,则可以减少它。
类型: -bit Unsigned Integer
是否必须: No
默认: ms async max op threads
描述: 每个Async Messenger实例使用的最大工作线程数。当机器具有有限的CPU数量时设置为较低的值,而当CPU未充分利用时设置为较高的值(即,在I / O操作期间,一个或多个CPU始终处于100%负载状态)
类型: -bit Unsigned Integer
是否必须: No
默认: ms async set affinity
描述: 设置为true以将Async Messenger工作程序绑定到特定CPU核心。
类型: Boolean
是否必须: No
默认: true ms async affinity cores
描述: 当ms async set affinity为true时,此字符串指定Async Messenger工作程序如何绑定到CPU核心。
例如,",2"将workers #1和#2分别绑定到CPU核心#0和#。注意:手动设置关联时,请确保不将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 (即文件描述符最大允许值),这有助于防止耗尽文件描述符。
类型: -bit Integer
是否必须: No
默认: fatal signal handlers
描述: 如果设置了,将安装 SEGV 、 ABRT 、 BUS 、 ILL 、 FPE 、 XCPU 、 XFSZ 、 SYS 信号处理器,用于产生有用的日志信息。
类型: Boolean
默认: true

CEPH集群操作入门--配置的更多相关文章

  1. CEPH集群操作入门--部署和运维

    部署 预检和安装Ceph 参考 虚拟机使用ceph-deploy安装ceph 创建群集 添加/删除监视器 密钥管理 添加/删除OSD 添加/删除MDS 清除主机 管理任务   运维 操作群集 健康检查 ...

  2. Ceph集群搭建及Kubernetes上实现动态存储(StorageClass)

    集群准备 ceph集群配置说明   节点名称 IP地址 配置 作用 ceph-moni-0 10.10.3.150 centos7.5 4C,16G,200Disk 管理节点,监视器 monitor ...

  3. 理解 OpenStack &plus; Ceph (1):Ceph &plus; OpenStack 集群部署和配置

    本系列文章会深入研究 Ceph 以及 Ceph 和 OpenStack 的集成: (1)安装和部署 (2)Ceph RBD 接口和工具 (3)Ceph 物理和逻辑结构 (4)Ceph 的基础数据结构 ...

  4. 配置Ceph集群为OpenStack后端存储

    配置Ceph存储为OpenStack的后端存储 1  前期配置 Ceph官网提供的配置Ceph块存储为OpenStack后端存储的文档说明链接地址:http://docs.ceph.com/docs/ ...

  5. 基于Docker UI 配置ceph集群

    前言 前一篇介绍了docker在命令行下面进行的ceph部署,本篇用docker的UI进行ceph的部署,目前来说市面上还没有一款能够比较简单就能直接在OS上面去部署Ceph的管理平台,这是因为OS的 ...

  6. Ubuntu 14&period;04 部署 CEPH集群

    注:下文的所有操作都在admin节点进行 1.准备三台虚拟机,其中一台作为admin节点,另外两台作为osd节点,并相应地用hostname命令将主机名修改为admin,osd0,osd1,最后修改/ ...

  7. 使用虚拟机CentOS7部署CEPH集群

    第1章   CEPH部署 1.1  简单介绍 Ceph的部署模式下主要包含以下几个类型的节点 Ø CephOSDs: A Ceph OSD 进程主要用来存储数据,处理数据的replication,恢复 ...

  8. ceph集群搭建

    CEPH 1.组成部分 1.1 monitor admin节点安装ceph-deploy工具 admin节点安装ceph-deploy 添加源信息 rm -f /etc/yum.repos.d/* w ...

  9. Ceph 集群整体迁移方案&lpar;转&rpar;

    场景介绍:在我们的IDC中,存在着运行了3-6年的Ceph集群的服务器,这些服务器性能和容量等都已经无法满足当前业务的需求,在购入一批高性能机器后,希望将旧机器上的集群整体迁移到新机器上,当然,是保证 ...

随机推荐

  1. PDO运用

  2. SQL Server 汉字转拼音

    IF OBJECT_ID('Fn_GetQuanPin','Fn') IS NOT NULL DROP FUNCTION fn_GetQuanPin go )) ) as begin ),) decl ...

  3. Python标准库:内置函数hasattr&lpar;object&comma; name&rpar;

    Python标准库:内置函数hasattr(object, name) 本函数是用来判断对象object的属性(name表示)是否存在.如果属性(name表示)存在,则返回True,否则返回False ...

  4. iOS&colon;项目中用到的Cookie

    1.介绍: 做了这么长时间开发,Cookie真是用的不多,可是现在不一样了,这次的项目我用到了Cookie.其实,Cookie的使用在项目中愈加的频繁,一般情况下,提供的接口是用Cookie来识别用户 ...

  5. Baxter机器人---Hello&lowbar;baster(二)

    原创博文,转载请标明出处:--周学伟http://www.cnblogs.com/zxouxuewei/ Step 1: Setup ROS Environment root@zxwubuntu-As ...

  6. Spring 事务中 readOnly 的解释

      spring 中事务的PROPAGATION_REQUIRED,Readonly的解释  (2012-11-21 16:29:38) 转载▼ 标签:  杂谈                  一. ...

  7. C&num;反射Assembly 具体说明

    1.对C#反射机制的理解 2.概念理解后,必须找到方法去完毕,给出管理的主要语法 3.终于给出有用的样例,反射出来dll中的方法 反射是一个程序集发现及执行的过程,通过反射能够得到*.exe或*.dl ...

  8. 从源码安装go 1&period;2&period;2

    获取代码 以下命令会创建一个go目录.切换到相应目录,并且确保当前位置不存在go目录,运行命令: hg clone -r release https://go.googlecode.com/hg/ g ...

  9. 从Linux内核角度看中间人攻击(ARP欺骗)并利用Python scapy实现

    邻居子系统与ARP协议 邻居子系统的作用就是将IP地址,转换为MAC地址,类似操作系统中的MMU(内存管理单元),将虚拟地址,转换为物理地址. 其中邻居子系统相当于地址解析协议(IPv4的ARP协议, ...

  10. Linux基础&lpar;二&rpar;centOS7密码重置

    之前安装linux的时候,为了安全起见,起了一个非常特别的,长的密码.然后,就不记得了密码. 下面通过进入单用户模式,就行挽救. 1>重启系统,在系统菜单选择页按 [上下方向键],使界面停在该界 ...