Ceph入门教程

合集 - 云原生(4)

1.Ceph入门教程2024-05-14

2.云原生基础架构介绍2024-05-153.Calico 入门教程2024-05-204.Calico 组网（Networking）2024-05-20

收起

是什么？

Ceph 是存储的未来；在传统系统无法提供的领域，Ceph 的设计能够表现出色。通过可扩展、智能、可靠且高度可用的存储软件，利用您的数据做出更好的业务决策并实现卓越运营。 Ceph 支持对象、块和文件存储，所有这些都在一个统一的存储系统中。
凭借 Ceph 的适应性，无论您的解决方案是在本地、公有云、私有云还是容器本机中，您的集群都可以随时支持您现在和将来的所有应用程序和数据存储需求。

特点

1. 可扩展性
   Ceph 能够快速扩展，而无需其他解决方案所需的典型停机时间。使用先进的 CRUSH 算法，Ceph 克服了所有可扩展性挑战，引领了实现真正灵活、具有令人难以置信的弹性的大规模存储的道路。停止依赖昂贵的、特定于供应商的硬件和锁定合同。摆脱遗留限制。随着业务规模的扩大，存储集群呈指数级增长。 Ceph 是一种可扩展、经济高效的解决方案，可应对企业市场、学术机构等领域快速且不可预测的数据增长。

2. 可靠性
   数据是不可替代的，因此存储系统的可靠性和精细管理至关重要。使用 Ceph 实现安心； Ceph 具有自我管理和自我修复功能，可以在您意识到问题之前发现并纠正问题。在您的存储集群中，Ceph Monitor 和 Manager 守护进程进行协调，以提高互连系统之间的可靠性和数据可用性。 CRUSH 算法降低了单点故障、性能瓶颈和可扩展性限制的风险，创建了可靠且高性能的存储解决方案，适合不断增长的企业市场。

3. 高性能
   Ceph 的配置和部署可以完全根据您的需求进行定制，而不会影响性能。将 Ceph 应用到您现有的存储设置中，或者使用广泛可用的商用硬件创建新集群，以实现行业领先的可靠性和可扩展性，而无需花费传统的专有 ICT 基础设施。 传统存储系统面临着延迟、复杂的数据重复过程以及特定的、不灵活的物理基础设施的需求，而 Ceph 却能保持高性能和可扩展性。 作为软件定义的存储系统，Ceph 旨在最大限度地提高有效性和性能，无论其运行在何种基础设施上。

架构

Ceph 在单个统一系统中提供对象、块和文件存储

对象存储

Ceph RGW 对象存储服务提供业界领先的 S3 API 兼容性以及一组强大的安全性、分层和互操作性功能。使用 S3 或 Swift 对象存储的应用程序可以在单个数据中心内利用 Ceph 的可扩展性和性能，或者联合全球多个 Ceph 集群来创建具有广泛的复制、迁移和其他数据服务集的全局存储命名空间。

块存储

Ceph RBD（RADOS 块设备）块存储将虚拟磁盘条带化到 Ceph 存储集群内的对象上，将数据和工作负载分布到所有可用设备上，以实现极高的可扩展性和性能。 RBD磁盘镜像采用精简配置，同时支持只读快照和可写克隆，并且可以异步镜像到其他数据中心的远程Ceph集群以进行灾难恢复或备份，使Ceph RBD成为公共/私有云中块存储的首选和虚拟化环境。

文件系统

Ceph 文件系统 (CephFS) 是一个强大、功能齐全、符合 POSIX 标准的分布式文件系统即服务，具有快照、配额和多集群镜像功能。 CephFS 文件在 Ceph 存储的对象之间进行条带化，以实现极高的规模和性能。 Linux 系统可以通过基于 FUSE 的客户端或 NFSv4 网关本地挂载 CephFS 文件系统。

CRUSH算法

CRUSH（可扩展哈希下的受控复制）算法通过自动复制确保组织的数据安全和存储可扩展。使用 CRUSH 算法，Ceph 客户端和 Ceph OSD 守护进程能够跟踪存储对象的位置，避免依赖中央查找表的架构固有的问题。

可靠的自主分布式对象存储 (RADOS)

RADOS（可靠的自主分布式对象存储）旨在利用设备智能来分散由数千个存储设备组成的集群中的一致数据访问、冗余存储、故障检测和故障恢复的复杂性。 RADOS 专为 PB 级存储系统而设计：此类系统必然是动态的，因为它们随着新存储的部署和旧设备的退役而逐渐增长和收缩。 RADOS 确保数据分布有一致的视图，同时保持对数据对象的一致读写访问。

组件介绍

• 监视器：Ceph 监视器 (ceph-mon) 维护集群状态图，包括监视器图、管理器图、OSD 图、MDS 图和 CRUSH 图。这些映射是 Ceph 守护进程相互协调所需的关键集群状态。监视器还负责管理守护程序和客户端之间的身份验证。为了实现冗余和高可用性，通常需要至少三个监视器。
• 管理器：Ceph 管理器守护进程 (ceph-mgr) 负责跟踪运行时指标和 Ceph 集群的当前状态，包括存储利用率、当前性能指标和系统负载。 Ceph Manager 守护进程还托管基于 python 的模块来管理和公开 Ceph 集群信息，包括基于 Web 的 Ceph 仪表板和 REST API。通常至少需要两名管理器才能实现高可用性。
• Ceph OSD：对象存储守护进程（Ceph OSD、ceph-osd）存储数据，处理数据复制、恢复、重新平衡，并通过检查其他 Ceph OSD 守护进程的心跳来向 Ceph 监视器和管理器提供一些监视信息。通常至少需要三个 Ceph OSD 才能实现冗余和高可用性。
• MDS：Ceph 元数据服务器（MDS、ceph-mds）存储 Ceph 文件系统的元数据。 Ceph 元数据服务器允许 CephFS 用户运行基本命令（如 ls、find 等），而不会给 Ceph 存储集群带来负担。
  Ceph 将数据作为对象存储在逻辑存储池中。使用 CRUSH 算法，Ceph 计算哪个归置组 (PG) 应包含该对象，以及哪个 OSD 应存储该归置组。 CRUSH 算法使 Ceph 存储集群能够动态扩展、重新平衡和恢复。

部署要求

CPU

CephFS 元数据服务器 (MDS)

• 是 CPU 密集型的。
• 它们是单线程的，在高时钟频率 (GHz) 的 CPU 上性能最佳。
• MDS 服务器不需要大量 CPU 核心，除非它们还托管其他服务

在 Ceph 的早期版本中，我们会根据每个 OSD 的核心数量提出硬件建议，但是每个 osd 的核心数量指标不再像每个 IOP 的周期数和每个 OSD 的 IOPS 数量那样有用。例如，借助 NVMe OSD 驱动器，Ceph 可以轻松利用真实集群上的 5 个或 6 个内核，以及单个 OSD 上最多 14 个独立的内核。因此，每个 OSD 的核心数不再像以前那样紧迫。选择硬件时，请选择每个内核的 IOPS。（IOPS比核心数重要）

监视器节点和管理器节点对 CPU 的要求不高，只需要适度的处理器。如果您的主机除了 Ceph 守护进程之外还将运行 CPU 密集型进程，请确保您有足够的处理能力来运行 CPU 密集型进程和 Ceph 守护进程。 （OpenStack Nova 是 CPU 密集型进程的一个示例。）

我们建议您在单独的主机（即，不是您的 Monitor 和 Manager 节点的主机）上运行非 Ceph CPU 密集型进程，以避免资源争用。如果您的集群部署了 Ceph 对象网关，并且节点有足够的资源，RGW 守护进程可能会与您的 Mon 和 Manager 服务共存

MEM

一般来说，RAM 越大越好。对于中等规模的集群来说，Monitor/Manager 节点使用 64GB 就可以了；对于具有数百个 OSD 的较大集群，建议使用 128GB。
监视器和管理器守护程序内存使用量随着集群的大小而变化。请注意，在启动时以及拓扑更改和恢复期间，这些守护进程将需要比稳态操作期间更多的 RAM，因此请规划峰值使用情况。对于非常小的集群，32 GB 就足够了。对于最多 300 个 OSD 的集群，需要使用 64GB。对于使用（或将增长到）更多 OSD 构建的集群，您应该配置 128GB。您可能还需要考虑调整以下设置：

• mon_osd_cache_size
• rocksdb_cache_size

CephFS 元数据守护进程内存利用率取决于其缓存的配置大小。我们建议大多数系统至少使用 1 GB。请参阅 mds_cache_memory_limit。
不建议将 osd_memory_target 设置为低于 2GB。 Ceph 可能无法将内存消耗保持在 2GB 以下，并且性能可能会极其缓慢。 将内存目标设置在 2GB 到 4GB 之间通常可行，但可能会导致性能下降：除非活动数据集相对较小，否则可能需要在 IO 期间从磁盘读取元数据。 4GB 是 osd_memory_target 的当前默认值。此默认值是针对典型用例选择的，旨在平衡 RAM 成本和 OSD 性能。 当有许多（小）对象或处理大（256GB/OSD 或更多）数据集时，将 osd_memory_target 设置为高于 4GB 可以提高性能。对于快速 NVMe OSD 来说尤其如此。

数据存储

OSD 需要大量存储驱动器空间来存储 RADOS 数据。我们建议最小驱动器大小为 1 TB（磁盘大小）。远小于 1 TB 的 OSD 驱动器使用其元数据容量的很大一部分，而小于 100 GB 的驱动器根本不起作用。

强烈建议至少为 Ceph Monitor 和 Ceph Manager 主机以及 CephFS 元数据服务器元数据池和 Ceph 对象网关 (RGW) 索引池配置（企业级）SSD，即使 HDD 是为批量 OSD 数据进行配置。

仔细考虑较大磁盘的每 GB 成本优势。我们建议将磁盘驱动器的价格除以 GB 数，得出每 GB 成本，因为较大的驱动器可能会对每 GB 成本产生重大影响。例如，售价为 75.00 美元的 1 TB 硬盘每 GB 成本为 0.07 美元（即 75 美元/1024 = 0.0732）。相比之下，售价为 150.00 美元的 3 TB 磁盘的每 GB 成本为 0.05 美元（即 150 美元/3072 = 0.0488）。在前面的示例中，使用 1 TB 磁盘通常会使每 GB 成本增加 40%，从而大大降低集群的成本效率。

在单个 SAS / SATA HDD 上托管多个 OSD 并不是一个好主意。
在单个驱动器上托管带有监视器、管理器或 MDS 数据的 OSD 也不是一个好主意。
对于旋转磁盘，SATA 和 SAS 接口日益成为更大容量的瓶颈。另请参阅存储网络行业协会的总拥有成本计算器。

存储驱动器受到寻道时间、访问时间、读写时间以及总吞吐量的限制。这些物理限制会影响整体系统性能，尤其是在恢复期间。我们建议为操作系统和软件使用专用（最好是镜像）驱动器，并为主机上运行的每个 Ceph OSD 守护进程使用一个驱动器。许多“OSD 速度慢”问题（当它们不是由硬件故障引起时）是由于在同一驱动器上运行操作系统和多个 OSD 引起的。另请注意，当今的 22TB HDD 使用与十年前的 3TB HDD 相同的 SATA 接口：通过同一接口压缩的数据量是其七倍以上。因此，当使用 HDD 作为 OSD 时，大于 8TB 的驱动器可能最适合存储对性能完全不敏感的大文件/对象。

固态硬盘

使用固态硬盘 (SSD) 时，Ceph 性能会大大提高。这减少了随机访问时间并减少了延迟，同时提高了吞吐量。 SSD 每 GB 的成本比 HDD 更高，但 SSD 的访问时间通常至少比 HDD 快 100 倍。 SSD 避免了繁忙集群中的热点问题和瓶颈问题，并且在全面评估 TCO 时，它们可能会提供更好的经济效益。值得注意的是，对于给定的 IOPS 数量，SSD 的摊销驱动器成本比 HDD 低得多。 SSD 不会受到旋转或寻道延迟的影响，除了提高客户端性能之外，它们还大大提高了集群更改的速度和客户端影响，包括添加、删除 OSD 或监视器或发生故障时的重新平衡。 SSD 没有移动机械部件，因此不受 HDD 的许多限制。但 SSD 确实有很大的局限性。在评估SSD时，重要的是要考虑顺序和随机读写的性能。

我们建议探索使用 SSD 来提高性能。但是，在对 SSD 进行重大投资之前，我们强烈建议您查看 SSD 的性能指标并在测试配置中测试 SSD 以衡量性能。

相对便宜的 SSD 可能会吸引您的经济意识。谨慎使用。选择与 Ceph 配合使用的 SSD 时，可接受的 IOPS 并不是唯一要考虑的因素。廉价SSD往往是一种虚假经济：它们可能会经历“悬崖”，这意味着在最初的爆发之后，一旦有限的缓存被填满，持续性能就会大幅下降。还要考虑耐用性：额定为每天 0.3 次驱动器写入（DWPD 或同等）的驱动器对于专用于某些类型的顺序写入（主要是读取）数据的 OSD 来说可能没问题，但对于 Ceph Monitor 任务来说不是一个好的选择。企业级 SSD 最适合 Ceph：它们几乎总是具有断电保护 (PLP) 功能，并且不会遭受客户端（桌面）模型可能遇到的急剧断电的影响。

当使用单个（或镜像对）SSD 用于操作系统启动和 Ceph Monitor/Manager 目的时，建议最小容量为 256GB，并且建议至少为 480GB。建议采用额定值为 1+ DWPD（或 TBW（写入太字节）的等效值）的驱动器型号。但是，对于给定的写入工作负载，比技术要求更大的驱动器将提供更高的耐用性，因为它实际上具有更大的过度配置。我们强调企业级驱动器最适合生产使用，因为与适用于更轻和间歇性工作周期的客户端（桌面）SKU 相比，它们具有断电保护和更高的耐用性。

历史上，SSD 对于对象存储来说成本过高，但 QLC SSD 正在缩小差距，提供更高的密度、更低的功耗和更少的冷却功耗。此外，通过将 WAL+DB 卸载到 SSD 上，HDD OSD 的写入延迟可能会得到显著改善。许多 Ceph OSD 部署不需要耐用性高于 1 DWPD（又名“读取优化”）的 SSD。 3 DWPD 级别的“混合用途”SSD 通常对于此目的来说是多余的，并且成本要高得多。

将 SSD 与 Ceph 结合使用时，请确保分区正确对齐。不正确对齐的分区的数据传输速度比正确对齐的分区慢。有关正确分区对齐的更多信息以及展示如何正确对齐分区的示例命令，请参阅 Werner Fischer 关于分区对齐的博客文章。

Ceph 提高 CephFS 文件系统性能的一种方法是将 CephFS 元数据的存储与 CephFS 文件内容的存储分开。 Ceph 为 CephFS 元数据提供了默认的元数据池。您永远不必为 CephFS 元数据手动创建池，但可以为仅包含 SSD 存储介质的 CephFS 元数据池创建 CRUSH 映射层次结构。有关详细信息，请参阅 CRUSH 设备类。

您不需要 RoC（支持 RAID）HBA。 ZFS 或 Linux MD 软件镜像可以很好地提高启动卷的持久性。使用 SAS 或 SATA 数据驱动器时，放弃 HBA RAID 功能可以缩小 HDD 和 SSD 介质成本之间的差距。此外，使用 NVMe SSD 时，不需要任何 HBA。当考虑整个系统时，这还减少了 HDD 与 SSD 的成本差距。即使打折后，精美的 RAID HBA 加板载缓存加电池备份（BBU 或超级电容器）的初始成本也很容易超过 1000 美元 - 这一总和与 SSD 成本相当。如果购买年度维护合同或延长保修期，无 HBA 的系统每年的成本可能会减少数百美元。

The Ceph blog is often an excellent source of information on Ceph performance issues. See Ceph Write Throughput 1 and Ceph Write Throughput 2 for additional details.

Benchmark

BlueStore 使用 O_DIRECT 打开存储设备并频繁发出 fsync() 以确保数据安全地保存到介质上。您可以使用 fio 评估驱动器的低级写入性能。例如，4kB随机写入性能测量如下：

fio --name=/dev/sdX --ioengine=libaio --direct=1 --fsync=1 --readwrite=randwrite --blocksize=4k --runtime=300

企业级 SSD 和 HDD 通常包含断电保护功能，可确保运行时断电时的数据持久性，并使用多级缓存来加速直接或同步写入。这些设备可以在两种缓存模式之间切换——使用 fsync 刷新到持久介质的易失性缓存，或同步写入的非易失性缓存。 这两种模式可通过“启用”或“禁用”写入（易失性）缓存来选择。当启用易失性缓存时，Linux 使用“回写”模式的设备，当禁用时，它使用“直写”模式。 默认配置（通常：启用缓存）可能不是最佳的，并且通过禁用此写入缓存，OSD 性能可能会在增加 IOPS 和减少提交延迟方面得到显着提高。 因此，鼓励用户如前所述使用 fio 对其设备进行基准测试，并为其设备保留最佳缓存配置。

The cache configuration can be queried with hdparm, sdparm, smartctl or by reading the values in /sys/class/scsi_disk/*/cache_type, for example:
hdparm -W /dev/sda

/dev/sda: write-caching =  1 (on)# sdparm --get WCE /dev/sda
    /dev/sda: ATA       TOSHIBA MG07ACA1  0101WCE           1  [cha: y]# smartctl -g wcache /dev/sda
smartctl 7.1 2020-04-05 r5049 [x86_64-linux-4.18.0-305.19.1.el8_4.x86_64] (local build)Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.orgWrite cache is:   Enabled# cat /sys/class/scsi_disk/0\:0\:0\:0/cache_type
write back
The write cache can be disabled with those same tools:
hdparm -W0 /dev/sda

/dev/sda: setting drive write-caching to 0 (off) write-caching =  0 (off)sdparm --clear WCE /dev/sda
    /dev/sda: ATA       TOSHIBA MG07ACA1  0101smartctl -s wcache,off /dev/sda
smartctl 7.1 2020-04-05 r5049 [x86_64-linux-4.18.0-305.19.1.el8_4.x86_64] (local build)Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org=== START OF ENABLE/DISABLE COMMANDS SECTION ===Write cache disabled
In most cases, disabling this cache using hdparm, sdparm, or smartctl results in the cache_type changing automatically to “write through”. If this is not the case, you can try setting it directly as follows. (Users should ensure that setting cache_type also correctly persists the caching mode of the device until the next reboot as some drives require this to be repeated at every boot):
echo "write through"  /sys/class/scsi_disk/0\:0\:0\:0/cache_type

hdparm -W /dev/sda

/dev/sda: write-caching =  0 (off)

网络

在数据中心内配置至少 10 Gb/s 的网络，无论是在 Ceph 主机之间还是在客户端与 Ceph 集群之间。强烈建议跨单独的网络交换机进行网络链路主动/主动绑定，以提高吞吐量并容忍网络故障和维护。请注意您的绑定哈希策略会跨链接分配流量。

通过 1 Gb/s 网络复制 1 TB 数据需要三个小时，通过 1 Gb/s 网络复制 10 TB 数据需要三十个小时。但通过 10 Gb/s 网络复制 1 TB 只需要 20 分钟，通过 10 Gb/s 网络复制 10 TB 只需一小时。 请注意，40 Gb/s 网络链路实际上是四个并行的 10 Gb/s 通道，而 100 Gb/s 网络链路实际上是四个并行的 25 Gb/s 通道。因此，也许有点违反直觉，与 40 Gb/s 网络相比，25 Gb/s 网络上的单个数据包的延迟稍低。

一些部署工具使用 VLAN 来使硬件和网络布线更易于管理。使用 802.1q 协议的 VLAN 需要支持 VLAN 的网卡和交换机。该硬件增加的费用可以通过网络设置和维护方面的运营成本节省来抵消。当使用 VLAN 处理集群和计算堆栈（例如 OpenStack、CloudStack 等）之间的 VM 流量时，使用 10 Gb/s 以太网或更好的以太网具有额外的价值；截至 2022 年，40 Gb/s 或越来越多的 25/50/100 Gb/s 网络对于生产集群来说很常见。

架顶式 (TOR) 交换机还需要到核心/主干网络交换机或路由器的快速且冗余的上行链路，通常至少为 40 Gb/s。

您的服务器机箱应该有一个底板管理控制器 (BMC)。著名的例子有 iDRAC (戴尔)、CIMC (思科 UCS) 和 iLO (HPE)。管理和部署工具也可能广泛使用 BMC，尤其是通过 IPMI 或 Redfish，因此请考虑带外网络的安全性和管理的成本/效益权衡。虚拟机管理程序 SSH 访问、VM 映像上传、操作系统映像安装、管理套接字等可能会给网络带来巨大的负载。运行多个网络可能看起来有点大材小用，但每个流量路径都代表着潜在的容量、吞吐量和/或性能瓶颈，您在部署大规模数据集群之前应该仔细考虑这些瓶颈。

如果您正在使用单个存储驱动器运行 OSD 节点，请为 OSD 创建一个与包含操作系统的分区分开的分区。我们建议操作系统和 OSD 存储使用单独的驱动器。

系统要求

部署

Cephadm

是一个可用于安装和管理 Ceph 集群的工具。

• cephadm 仅支持 Octopus 和更新版本。
• cephadm 与编排 API 完全集成，并完全支持用于管理集群部署的 CLI 和仪表板功能。
• cephadm 需要容器支持（以 Podman 或 Docker 的形式）和 Python 3。

Rook

部署和管理在 Kubernetes 中运行的 Ceph 集群，同时还可以通过 Kubernetes API 管理存储资源和配置。
我们推荐 Rook 作为在 Kubernetes 中运行 Ceph 或将现有 Ceph 存储集群连接到 Kubernetes 的方式。

• Rook 仅支持 Nautilus 和更新版本的 Ceph。
• Rook 是在 Kubernetes 上运行 Ceph 或将 Kubernetes 集群连接到现有（外部）Ceph 集群的首选方法。
• Rook 支持 Orchestrator API。完全支持 CLI 和仪表板中的管理功能。

ceph-ansible

使用 Ansible 部署和管理 Ceph 集群。

• Ceph-ansible 得到了广泛部署。
• ceph-ansible 未与 Nautilus 和 Octopus 中引入的 Orchestrator API 集成，这意味着 Nautilus 和 Octopus 中引入的管理功能和仪表板集成在通过 ceph-ansible 部署的 Ceph 集群中不可用

ceph-deploy 没有得到积极维护。
它没有在比 Nautilus 新的 Ceph 版本上进行测试。
它不支持 RHEL8、CentOS 8 或更新的操作系统。

cephadm安装步骤

要求

• Python 3
• Systemd
• Podman or Docker for running containers
• Time synchronization (such as Chrony or the legacy ntpd)
• LVM2 for provisioning storage devices

安装cephadm

Cephadm 通过引导单个主机、扩展集群以包含任何其他主机，然后部署所需的服务来创建新的 Ceph 集群。

There are two ways to install cephadm:

1. a curl-based installation method
CEPH_RELEASE=18.2.0 # replace this with the active releasecurl --silent --remote-name --location https://download.ceph.com/rpm-${CEPH_RELEASE}/el9/noarch/cephadm
Ensure the cephadm file is executable:
chmod +x cephadm
This file can be run directly from the current directory:
./cephadm <arguments...>

2. distribution-specific installation methods

#In Ubuntu:
apt install -y cephadm
#In CentOS Stream:
dnf search release-ceph
dnf install --assumeyes centos-release-ceph-reef
dnf install --assumeyes cephadm
#In Fedora:
dnf -y install cephadm
#In SUSE:
zypper install -y cephadm

注意这两种方式是互斥的，不能在同一个集群中使用两种安装方式

更新cephadmin

./cephadm add-repo --release reef
./cephadm install
#Confirm that cephadm is now in your PATH by running which or command -v:
which cephadm
#A successful which cephadm command will return this:
/usr/sbin/cephadm

Bootstrap

创建新 Ceph 集群的第一步是在 Ceph 集群的第一台主机上运行 cephadm bootstrap 命令。在 Ceph 集群的第一台主机上运行 cephadm bootstrap 命令的行为会创建 Ceph 集群的第一个 Monitor 守护进程。您必须将 Ceph 集群第一台主机的 IP 地址传递给 ceph bootstrap 命令，因此您需要知道该主机的 IP 地址。

运行bootstrap命令：
cephadm bootstrap --mon-ip *<mon-ip>*

这个命令执行如下操作：

• 在本地主机上为新集群创建监视器和管理器守护程序。
• 为 Ceph 集群生成新的 SSH 密钥并将其添加到 root 用户的 /root/.ssh/authorized_keys 文件中。
• 将公钥的副本写入 /etc/ceph/ceph.pub。
• 将最小配置文件写入 /etc/ceph/ceph.conf。需要此文件与 Ceph 守护进程进行通信。
• 将 client.admin 管理（特权！）密钥的副本写入 /etc/ceph/ceph.client.admin.keyring。
• 将 _admin 标签添加到引导主机。默认情况下，任何具有此标签的主机都将（也）获得 /etc/ceph/ceph.conf 和 /etc/ceph/ceph.client.admin.keyring 的副本。

更多关于bootstrap的信息：

• 默认情况下，Ceph 守护进程将其日志输出发送到 stdout/stderr，该日志输出由容器运行时（docker 或 podman）拾取并（在大多数系统上）发送到 Journald。如果您希望 Ceph 将传统日志文件写入 /var/log/ceph/$fsid，请在引导期间使用 --log-to-file 选项。
• 当（Ceph 集群外部）公共网络流量与（Ceph 集群内部）集群流量分开时，较大的 Ceph 集群性能最佳。内部集群流量处理 OSD 守护进程之间的复制、恢复和心跳。您可以通过向 bootstrap 子命令提供 --cluster-network 选项来定义集群网络。此参数必须是采用 CIDR 表示法的子网（例如 10.90.90.0/24 或 fe80::/64）。
• cephadm bootstrap 写入访问新集群所需的 /etc/ceph 文件。这个中心位置使得安装在主机上的 Ceph 软件包（例如，可以访问 cephadm 命令行界面的软件包）可以找到这些文件。 然而，使用 cephadm 部署的守护进程容器根本不需要 /etc/ceph。使用 --output-dir 选项将它们放在不同的目录中（例如，.）。这可能有助于避免与同一主机上的现有 Ceph 配置（cephadm 或其他）发生冲突。
• 您可以将任何初始 Ceph 配置选项传递到新集群，方法是将它们放入标准 ini 样式配置文件中并使用 --config 选项。例如：

cat <<EOF > initial-ceph.conf
[global]
osd crush chooseleaf type = 0
EOF

$ ./cephadm bootstrap --config initial-ceph.conf ...

• --ssh-user 选项可以指定 cephadm 将使用哪个 SSH 用户连接到主机。关联的 SSH 密钥将添加到 /home//.ssh/authorized_keys。您使用此选项指定的用户必须具有无密码 sudo 访问权限。
• 如果您使用来自需要登录的注册表的容器映像，则可以添加参数：
  • --registry-json
    {"url":"REGISTRY_URL", "username":"REGISTRY_USERNAME", "password":"REGISTRY_PASSWORD"}

Cephadm 将尝试登录到此注册表，以便它可以拉取您的容器，然后将登录信息存储在其配置数据库中。添加到集群的其他主机也将能够使用经过身份验证的容器注册表。

ENABLE CEPH CLI

Cephadm 不需要在主机上安装任何 Ceph 软件包。但是，我们建议启用对 ceph 命令的轻松访问。做这件事有很多种方法：

• cephadm shell 命令在安装了所有 Ceph 软件包的容器中启动 bash shell。默认情况下，如果在主机上的 /etc/ceph 中找到配置和密钥环文件，它们将被传递到容器环境中，以便 shell 发挥完整功能。请注意，在 MON 主机上执行时，cephadm shell 将从 MON 容器推断配置，而不是使用默认配置。如果给出 --mount ，则主机 （文件或目录）将出现在容器内的 /mnt 下：
  cephadm shell
• 要执行 ceph 命令，您还可以运行如下命令：
  cephadm shell -- ceph -s
• 您可以安装 ceph-common 软件包，其中包含所有 ceph 命令，包括 ceph、rbd、mount.ceph（用于挂载 CephFS 文件系统）等：

cephadm add-repo --release reef
cephadm install ceph-common

• 确认 ceph 命令可通过以下方式访问：
  ceph -v
• 确认 ceph 命令可以连接到集群及其状态：

ceph status
Adding hosts

按照添加主机中的说明将所有主机添加到集群。 默认情况下，ceph.conf 文件和 client.admin 密钥环的副本保存在所有具有 _admin 标签的主机上的 /etc/ceph 中。该标签最初仅应用于引导主机。我们建议为一台或多台其他主机指定 _admin 标签，以便在多台主机上轻松访问 Ceph CLI（例如，通过 cephadm shell）。要将 _admin 标签添加到其他主机，请运行以下形式的命令：

ceph orch host label add *<host>* _admin

ADDING ADDITIONAL MONS

典型的 Ceph 集群具有三到五个分布在不同主机上的 Monitor 守护进程。如果集群中有五个或更多节点，我们建议部署五个监视器。大多数集群不会从七个或更多监视器中受益。 请按照部署其他监视器来部署其他 MON。

ADDING STORAGE

To add storage to the cluster, you can tell Ceph to consume any available and unused device(s):
ceph orch apply osd --all-available-devices

部署OSDS文档

ENABLING OSD MEMORY AUTOTUNING
默认情况下，cephadm 在引导程序上启用 osd_memory_target_autotune，并将 mgr/cephadm/autotune_memory_target_ratio 设置为总主机内存的 0.7。

请参阅自动调整 OSD 内存。

要使用 TripleO 部署超融合 Ceph，请参阅 TripleO 文档：场景：部署超融合
Ceph 在集群硬件并非由 Ceph（融合基础设施）专用的其他情况下，请减少 Ceph 的内存消耗，如下所示：

# converged only:
ceph config set mgr mgr/cephadm/autotune_memory_target_ratio 0.2

然后启用内存自动调整：
ceph config set osd osd_memory_target_autotune true

使用CEPH，至此ceph集群已经搭建好了，需要根据实际业务情况来启用不同的功能

• To use the Ceph Filesystem, follow Deploy CephFS.
• To use the Ceph Object Gateway, follow Deploy RGWs.
• To use NFS, follow NFS Service
• To use iSCSI, follow Deploying iSCSI

文章中很多参见链接在从其他文档复制过来的时候丢了，建议参考官网文档对照。
完整的安装步骤可以参考其他博文