无论您是想为云平台提供Ceph 对象存储和/或 Ceph 块设备服务、部署Ceph 文件系统还是将 Ceph 用于其他目的，所有 Ceph 存储集群部署都从设置每个 Ceph 节点、您的网络和 Ceph开始存储集群。一个 Ceph 存储集群至少需要一个 Ceph Monitor、Ceph Manager 和 Ceph OSD（对象存储守护进程）。运行 Ceph 文件系统客户端时也需要 Ceph 元数据服务器。
Monitors
Ceph Monitor ( ceph-mon) 维护集群状态的映射，包括监视器映射、管理器映射、OSD 映射、MDS 映射和 CRUSH 映射。这些映射是 Ceph 守护进程相互协调所需的关键集群状态。监视器还负责管理守护进程和客户端之间的身份验证。冗余和高可用性通常需要至少三个监视器。Managers
Ceph Manager守护进程 ( ceph-mgr) 负责跟踪运行时指标和 Ceph 集群的当前状态，包括存储利用率、当前性能指标和系统负载。Ceph Manager 守护进程还托管基于 python 的模块来管理和公开 Ceph 集群信息，包括基于 Web 的Ceph Dashboard和 REST API。高可用性通常需要至少两个管理器。Ceph OSD
一个Ceph OSD（对象存储守护进程 ceph-osd）存储数据、处理数据复制、恢复、重新平衡，并通过检查其他 Ceph OSD 守护进程的心跳来向 Ceph 监视器和管理器提供一些监视信息。冗余和高可用性通常需要至少 3 个 Ceph OSD。MDS
Ceph 元数据服务器(MDS ceph-mds) 代表Ceph 文件系统存储元数据（即 Ceph 块设备和 Ceph 对象存储不使用 MDS）。Ceph 元数据服务器允许 POSIX 文件系统用户执行基本命令（如 ls、find等），而不会给 Ceph 存储集群带来巨大负担。
Ceph 将数据作为对象存储在逻辑存储池中。使用 CRUSH算法，Ceph 计算出哪个归置组应该包含该对象，并进一步计算出哪个 Ceph OSD Daemon 应该存储该归置组。CRUSH 算法使 Ceph 存储集群能够动态扩展、重新平衡和恢复。
安装 CEPH有几种不同的方式来安装 Ceph。选择最适合您需要的方法。
推荐方法Cephadm使用容器和 systemd 安装和管理 Ceph 集群，并与 CLI 和仪表板 GUI 紧密集成。
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 未与 Nautlius 和 Octopus 中引入的新编排器 API 集成，这意味着更新的管理功能和仪表板集成不可用。
ceph-deploy是一个快速部署集群的工具。ceph-deploy 不再主动维护。它没有在比 Nautilus 更新的 Ceph 版本上进行测试。它不支持 RHEL8、CentOS 8 或更新的 *** 作系统。
ceph -salt使用 Salt 和 cephadm 安装 Ceph。 jaas.ai/ceph-mon使用 Juju 安装 Ceph。 github.com/openstack/puppet-ceph 通过 Puppet 安装 Ceph。 Ceph 也可以手动安装。 CEPH 存储集群Ceph 存储集群是所有 Ceph 部署的基础。基于RADOS，Ceph 存储集群由几种类型的守护进程组成：
Ceph OSD 守护进程(OSD) 将数据作为对象存储在存储节点上
Ceph Monitor (MON) 维护集群映射的主副本。
Ceph Manager 管理器 守护进程
一个 Ceph 存储集群可能包含数千个存储节点。一个最小的系统至少有一个 Ceph Monitor 和两个 Ceph OSD Daemons 用于数据复制。
Ceph 文件系统、Ceph 对象存储和 Ceph 块设备从 Ceph 存储集群读取数据并将数据写入到 Ceph 存储集群。
存储设备一个存储集群中有几个 Ceph 守护进程：
Ceph OSD（对象存储守护进程）将大部分数据存储在 Ceph 中。通常每个 OSD 都由一个存储设备支持。这可以是传统硬盘 (HDD) 或固态硬盘 (SSD)。OSD 也可以由设备组合支持：例如，用于大多数数据的 HDD 和用于某些元数据的 SSD（或 SSD 的分区）。集群中 OSD 的数量通常是要存储的数据量、每个存储设备的大小以及指定的冗余级别和类型（复制或纠删码）的函数。Ceph Monitor守护进程管理关键的集群状态。这包括集群成员和身份验证信息。小型集群只需要几 GB 的存储空间来保存监控数据库。然而，在大型集群中，监控数据库的大小可以达到数十 GB 到数百 GB。Ceph Manager守护进程与监视器守护进程一起运行，提供额外的监控并提供与外部监控和管理系统的接口。 OSD BACKENDS
OSD 有两种方式管理它们存储的数据。从 Luminous 12.2.z 版本开始，默认（和推荐的）后端是 BlueStore。在 Luminous 发布之前，默认（也是唯一的选项）是 Filestore。
BLUESTOREBlueStore 是一个专用存储后端，专为管理 Ceph OSD 工作负载的磁盘数据而设计。BlueStore 的设计基于十年来支持和管理 Filestore OSD 的经验。
BlueStore 的主要功能包括：
直接管理存储设备。BlueStore 使用原始块设备或分区。这避免了可能限制性能或增加复杂性的中间抽象层（例如 XFS 等本地文件系统）。使用 RocksDB 进行元数据管理。嵌入 RocksDB 的键/值数据库是为了管理内部元数据，包括将对象名称映射到磁盘上的块位置。完整的数据和元数据校验和。默认情况下，写入 BlueStore 的所有数据和元数据都受一个或多个校验和保护。未经验证，不会从磁盘读取数据或元数据或将数据或元数据返回给用户。内联压缩。在写入磁盘之前，可以选择压缩数据。多设备元数据分层。BlueStore 允许将其内部日志（预写日志）写入单独的高速设备（如 SSD、NVMe 或 NVDIMM）以提高性能。如果有大量更快的存储可用，则内部元数据可以存储在更快的设备上。高效的写时复制。RBD 和 CephFS 快照依赖于在 BlueStore 中高效实现的写时复制克隆机制。这为常规快照和纠删码池（依赖克隆来实现高效的两阶段提交）带来了高效的 I/O。 FILESTORE
FileStore 是在 Ceph 中存储对象的传统方法。它依赖于标准文件系统（通常是 XFS）和键/值数据库（传统上是 LevelDB，现在是 RocksDB）来获取一些元数据。
FileStore 经过良好测试并广泛用于生产。然而，由于其整体设计和依赖于传统文件系统进行对象数据存储，它存在许多性能缺陷。
尽管 FileStore 能够在大多数与 POSIX 兼容的文件系统（包括 btrfs 和 ext4）上运行，但我们建议仅将 XFS 文件系统与 Ceph 一起使用。btrfs 和 ext4 都有已知的错误和缺陷，使用它们可能会导致数据丢失。默认情况下，所有 Ceph 配置工具都使用 XFS。
网络网络配置对于构建高性能 Ceph 存储集群至关重要。Ceph 存储集群不代表Ceph 客户端执行请求路由或分派。相反，Ceph 客户端直接向 Ceph OSD 守护进程发出请求。Ceph OSD 守护进程代表 Ceph 客户端执行数据复制，这意味着复制和其他因素会给 Ceph 存储集群网络带来额外的负载。
我们的快速入门配置提供了一个简单的 Ceph 配置文件，它只设置监视器 IP 地址和守护程序主机名。除非您指定集群网络，否则 Ceph 会假定一个“公共”网络。Ceph 仅在公共网络上运行良好，但在大型集群中使用第二个“集群”网络可能会显着提高性能。
可以使用两个网络运行 Ceph 存储集群：公共（客户端，前端）网络和集群（私有，复制，后端）网络。但是，这种方法会使网络配置（硬件和软件）复杂化，并且通常不会对整体性能产生重大影响。出于这个原因，我们建议对于d性和容量双 NIC 系统，要么主动/主动绑定这些接口，要么实施第 3 层多路径策略，例如。FRR。
如果尽管很复杂，但仍希望使用两个网络，则每个 Ceph 节点都需要有多个网络接口或 VLAN。
每个 Ceph OSD 守护进程以小于每 6 秒的随机间隔检查其他 Ceph OSD 守护进程的心跳。如果相邻的 Ceph OSD 守护进程在 20 秒的宽限期内没有显示心跳，则 Ceph OSD 守护进程可能会考虑相邻的 Ceph OSD 守护进程down并将其报告给 Ceph 监视器，后者将更新 Ceph 集群映射。 您可以通过在 Ceph 配置文件的and or部分下添加设置或在运行时设置值来更改此宽限期。osd heartbeat grace [mon] [osd] [global]
默认情况下，来自不同主机的两个 Ceph OSD 守护进程必须向 Ceph 监视器报告另一个 Ceph OSD 守护进程down在 Ceph 监视器确认报告的 Ceph OSD 守护进程是down. 但是有可能所有报告故障的 OSD 都托管在一个带有坏交换机的机架中，该交换机无法连接到另一个 OSD。为了避免这种错误警报，我们将报告故障的对等节点视为整个集群上潜在“子集群”的代理，该集群同样滞后。这显然不是在所有情况下都是正确的，但有时会帮助我们将宽限校正定位到不满意的系统子集。mon osd reporter subtree level用于根据 CRUSH 图中的共同祖先类型将对等点分组到“子集群”中。默认情况下，只需要来自不同子树的两个报告来报告另一个 Ceph OSD 守护进程down。您可以通过在 Ceph 配置文件的部分下添加 和设置，或通过在运行时设置值来更改来自唯一子树的报告器数量和down向 Ceph 监视器报告 Ceph OSD 守护程序所需的公共祖先类型。mon osd min down reportersmon osd reporter subtree level[mon]
如果 Ceph OSD 守护进程无法与其 Ceph 配置文件（或集群映射）中定义的任何 Ceph OSD 守护进程对等，它将每 30 秒 ping 一次 Ceph 监视器以获取集群映射的最新副本。 您可以通过在 Ceph 配置文件的部分下添加设置或在运行时设置值来更改 Ceph Monitor 心跳间隔。osd mon heartbeat interval[osd]
OSD 报告其状态如果 Ceph OSD 守护进程没有向 Ceph 监视器报告，则 Ceph 监视器将down在 过去后考虑 Ceph OSD 守护进程。当一个可报告的事件（例如故障、归置组统计数据的变化、启动的变化 或在 5 秒内启动）等可报告事件时，Ceph OSD 守护进程会向 Ceph 监视器发送报告。 您可以通过在 Ceph 配置文件的部分下添加设置或在运行时设置值来更改 Ceph OSD 守护程序的最小报告间隔。Ceph OSD 守护进程每 120 秒向 Ceph Monitor 发送一个报告，无论是否发生任何显着变化。您可以通过在 Ceph 配置文件部分下添加设置或在运行时设置值来更改 Ceph Monitor 报告间隔。mon osd report timeoutup_thruosd mon report interval[osd]osd mon report interval max[osd]
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）