在本章中，我们将介绍以下秘籍：
在这一点上，我相信您对 Ceph 集群的部署、配置和监控很有信心。在本章中，我们将介绍标准主题，例如 Ceph 服务管理。我们还将介绍高级主题，例如通过添加 OSD 和使用ceph-ansible扩展您的集群span> MON 节点，最后升级 Ceph 集群，然后进行一些维护操作。< /span>
Ceph 的每个组件，无论是 MON、OSD、MDS 还是 RGW，都在底层操作系统之上作为服务运行。作为 Ceph 存储管理员，您应该了解 Ceph 服务以及如何操作它们。根据基于 Red Hat 的发行版，Ceph 守护程序作为传统的 systemd 管理器服务 进行管理。每次您启动,重新启动，然后 stop Ceph 守护进程（或您的整个集群），您必须至少指定一个选项和一个命令。您还可以指定守护程序类型或守护程序实例。一般语法如下：
systemctl [选项...] 命令 [服务名称...]
systemctl 选项包括：
systemctl 命令包括以下内容：
systemctl 可以针对以下 Ceph 服务类型：
如果您管理的是大型集群，最好使用有关集群 MON 的信息更新您的集群配置文件 (/etc/ceph/ceph.conf)， OSD、MDS 和 RGW 节点。有了这些条目，您就可以从单个节点管理所有集群服务。
ceph-ansible 管理我们将用于更新集群配置的 ceph 配置文件的所有方面。为了实现这一点，我们将使用 /etc/ansible/group_vars/all.yml 文件的 ceph_conf_overrides 部分更新 Ceph 配置文件，并将添加所有 MON、OSD 和 MDS 节点的详细信息。 Ansible 支持与 Ceph 配置文件相同的部分：[global]、[mon]、[osd]、[mds] 、[rgw] 等等。
由于我们有三个监控节点，请将它们的详细信息添加到 all.yml 文件的 ceph_conf_overrides 部分：
就像在监视器中一样，让我们从 ceph-node1 将 MDS 节点详细信息添加到 /etc/ceph/ceph.conf 文件中 使用 Ansible：
现在，让我们将 OSD 节点详细信息添加到 /etc/ceph/ceph.conf 文件ceph-node1 使用 Ansible：
Ceph 进程管理是通过 systemd 服务完成的。 Systemd 是 UNIX System V 系统 (SYSVINIT) 的替代品。使用 systemd 管理 Ceph 守护进程的一般语法是 systemctl [options] {command} {service/target}。
让我们详细了解使用 systemd 管理 Ceph 守护进程：
要启动或停止所有 Ceph 守护进程，请执行以下命令集。
让我们看看如何启动和停止所有 Ceph 守护进程：
要列出 Ceph 节点上的 Ceph systemd 单元，请执行以下命令集。
让我们看看如何确定哪些 Ceph 服务正在特定节点上运行。这有助于确定哪些 OSD 或 MON 服务在某个节点上运行的位置：
要检查 osd.1 问题的状态：
要按类型启动或停止所有 Ceph 守护进程，请执行以下命令集：
按类型启动守护进程：
按类型停止守护进程：
要启动或停止特定的 Ceph 守护进程，请执行以下命令集：
通过实例启动特定的守护进程：
要在本地主机上启动特定守护程序，请使用 start 命令执行 systemd 管理器，然后使用 {daemon_type}@{id/hostname}，例如：
通过实例停止特定的守护进程：
要停止本地主机上的特定守护进程，请使用 stop 命令执行 systemd 管理器，后跟 {daemon_type}@{id/hostname}，例如：
在构建存储基础架构时，可扩展性是最重要的设计方面之一。您为基础架构选择的存储解决方案应该具有足够的可扩展性，可以满足您未来的数据需求。通常，存储系统从小容量到中容量开始，逐渐发展为大型存储解决方案。
传统的存储系统是基于扩展设计的，并且受到一定存储容量的限制。如果您尝试将这些存储系统扩展超过某个限制，您可能需要牺牲性能、可靠性和可用性。存储的纵向扩展设计方法涉及向现有控制器系统添加磁盘资源，当它达到一定水平时，这将成为性能、容量和可管理性的瓶颈。
另一方面，横向扩展设计侧重于将包含磁盘、CPU、内存和其他资源的全新设备添加到现有存储集群中。使用这种类型的设计，您不会面临放大设计中遇到的挑战；它反而受益于线性性能改进。下图解释了存储系统的纵向扩展和横向扩展设计：
Ceph 是一个基于横向扩展设计的无缝可扩展存储系统，您可以在其中将带有一堆磁盘的计算节点添加到现有的 Ceph 集群中 并将您的存储系统扩展到更大的存储容量。
从一开始，Ceph 就被设计为从几个节点增长到数百个节点，并且它应该可以在不停机的情况下动态扩展。在本秘籍中，我们将通过添加 MON、OSD、MDS 和 RGW 节点深入研究 Ceph 横向扩展功能。
随着对增加集群容量的需求不断增长，扩展 Ceph 集群非常重要。让我们逐步扩展 Ceph 集群的几个区域：
向 Ceph 集群添加 OSD 节点是一个在线过程。为了证明这一点，我们需要一个名为 ceph-node4 的新虚拟机，其中包含三个充当 OSD 的磁盘。然后这个新节点将被添加到我们现有的 Ceph 集群中。
从 ceph-node1 运行以下命令，除非从任何其他节点另行指定：
刚才，我们学习了如何向现有的 Ceph 集群添加新节点。现在是了解随着 OSD 数量的增加，为 PG 选择正确的值变得更加重要的好时机，因为它对集群的行为有重大影响。在大型集群上增加 PG 计数可能是一项昂贵的操作。我鼓励你看看 http://docs.ceph.com/docs/master/rados/operations/placement-groups/#choosing-the-number-of-placement-groups span> 了解关于放置组（PGs）的任何更新信息。
在部署了大型 Ceph 集群的环境中，您可能希望增加监视器数量。就像在 OSD 中一样，向 Ceph 集群添加新监视器是一个在线过程。在这个秘籍中，我们将配置 ceph-node4 作为监控节点。
由于这是一个测试 Ceph 集群，我们将添加 ceph-node4 作为第四个监控节点。但是，在生产设置中，您的 Ceph 集群中应该始终有一个 奇数 监控节点为了形成一个法定人数：
对于对象存储用例，您必须使用 Ansible 部署 Ceph RGW 组件，为了使您的对象存储服务具有高可用性和高性能，您应该部署多个 Ceph 实例RGW。使用 Ansible，Ceph 对象存储服务可以轻松地从 RGW 的一个节点扩展到多个节点。
下图显示了如何部署和扩展多个 RGW 实例以提供 High -可用性（HA）对象存储服务：
扩展 RGW 与使用 Ansible 添加额外的 RGW 节点相同；请参阅 安装 Rados 网关 配方/a>第 4 章 ，使用 Ceph 对象存储，将更多 RGW 节点添加到您的 Ceph 环境。
存储系统最重要的特性之一是它的灵活性。一个好的存储解决方案应该足够灵活，以支持其扩展和缩减，而不会导致服务停机。传统存储系统灵活性有限；此类系统的扩展和缩减是一项艰巨的工作。有时，您会感到存储容量被锁定，无法根据需要进行更改。
Ceph 是一个绝对灵活的存储系统，支持动态更改存储容量，无论是扩展还是缩减。在上一个秘籍中，我们了解了扩展 Ceph 集群是多么容易。在这个秘籍中，我们将通过从 Ceph 集群中移除 ceph-node4 来缩减 Ceph 集群，而不会对数据可访问性产生任何影响。
由于 ceph-ansible 目前不支持删除 OSD 节点，让我们按照下一组步骤手动执行此操作。
在继续缩减集群大小、缩小规模或移除 OSD 节点之前，请确保集群有足够的可用空间来容纳您计划移出的节点上的所有数据。集群不应处于其完整比率，即 OSD 中已用磁盘空间的百分比。因此，作为最佳实践，不要删除 OSD 或 OSD 节点而不考虑对完整比率的影响。在撰写本书时，Ceph-Ansible 不支持缩减集群中的 Ceph OSD 节点，这必须手动完成。
在这里，您可以看到集群处于恢复模式，但同时正在向客户端提供数据。您可以使用以下命令观察恢复过程：
一旦 OSD 关闭，检查 OSD 树；您会观察到 OSD 关闭并退出：
删除 Ceph MON 通常不是一项非常频繁的任务。当您从集群中删除监视器时，请考虑 Ceph 监视器使用 PAXOS 算法来建立关于主集群映射的共识。您必须有足够数量的监视器来建立在集群映射上达成共识的法定人数。在这个秘籍中，我们将学习如何从 Ceph 集群中移除 ceph-node4 监视器。 在撰写本书时，ceph-ansible 不支持缩减集群中的 Ceph MON 节点，这必须手动完成。
一个 Ceph 集群可以由 10 到数千个为集群提供存储容量的物理磁盘组成。随着 Ceph 集群的物理磁盘数量增加，磁盘故障的频率也会增加。因此，更换发生故障的磁盘驱动器可能会成为 Ceph 存储管理员的重复性任务。在这个秘籍中，我们将了解 Ceph 集群的磁盘更换过程。
这些步骤将引导您完成 Ceph OSD 的正确更换过程：
以下屏幕截图将是您的输出：
您还会注意到 osd.0 已关闭。但是，在 ceph osd 树 中，它的权重仍为 1.00000，这意味着它仍被标记为 IN。只要其状态标记为 IN，Ceph 集群就不会触发该驱动器的数据恢复。进一步查看 ceph -s 可以看到 osdmap 有 9 个 osd： 8 up< /kbd>，9 in。默认情况下，Ceph 集群需要 300 秒将停机磁盘标记为 OUT，然后触发数据恢复。此超时的原因是为了避免由于短期中断（例如服务器重新启动）而导致不必要的数据移动。如果您愿意，可以增加甚至减少此超时值。
由于我们是在虚拟机上模拟这个，我们需要关闭虚拟机，添加一个新磁盘，然后重新启动虚拟机。插入磁盘后，记下其操作系统设备 ID：
ceph-disk prepare 命令完成了创建 OSD、OSD 密钥、身份验证、将 OSD 放入 CRUSH 映射等所有手动工作：
Ceph伟大的几个原因之一是Ceph集群上的几乎所有操作都可以在线执行，这意味着您的Ceph集群处于生产状态并为客户端提供服务，您可以在不停机的情况下在集群上执行管理任务。其中一项操作是升级 Ceph 集群版本。
从第一章开始，我们就一直在使用 Ceph 的 Jewel 版本。我们将演示使用 /usr/share/ceph-ansible/infrastructure-playbooks 目录中的 Ansible rolling_update.yml playbook 将 Ceph 集群版本从 Jewel 升级到 Kraken . rolling_update.yml playbook 完全自动化了 Ceph 集群升级过程。
Ansible 按以下顺序升级 Ceph 节点，一次一个：
在升级过程中，Ansible 还会在集群上设置 noout、noscrub 和 nodeep-scrub 标志，以防止在集群上进行任何不必要的数据移动。集群和擦洗的开销。 Ansible 在升级过程中还具有内置检查功能，它将检查集群 PG 状态，如果集群遇到问题，将不会继续前进。
在这个秘籍中，我们将在 Jewel 版本 (10.2.9) 上运行的 Ceph 集群升级到最新的稳定 Kraken (11.2.1) 版本：< /span>
作为 Ceph 存储管理员，维护 Ceph 集群将是您的首要任务之一。 Ceph 是一个分布式系统，旨在从几十个 OSD 增长到几千个。维护 Ceph 集群所需的关键事项之一是管理其 OSD。在这个秘籍中，我们将介绍 OSD 和 PG 的 Ceph 子命令，这将在集群维护和故障排除期间为您提供帮助。
为了更好地理解对这些命令的需求，让我们假设您要向生产 Ceph 集群添加一个新节点的场景。一种方法是简单地将带有多个磁盘的新节点添加到 Ceph 集群，集群将开始回填并将数据混洗到新节点上。这对于测试集群来说很好。
但是，当涉及到生产设置时，情况变得非常危急，您应该使用一些 ceph osd 子命令/标志，如下所述，在集群中添加新节点之前，如noin、nobackfill 等等。这样做是为了在新节点进入时您的集群不会立即开始回填过程。然后您可以在非高峰时段取消设置这些标志，并且集群将花时间重新平衡：
这些标志的使用就像设置和取消设置一样简单。例如，要设置标志，请使用以下命令行：
我们现在将了解这些标志是什么以及为什么使用它们：
如果您想在生产高峰时间或非高峰时间添加新的 OSD 节点，并且希望与 Ceph 数据重新平衡相比对客户端 IO 的影响最小 - 由于新的 OSD 新的恢复和回填 IO。您可以借助以下命令来限制回填和恢复：
在 Ceph 的 Jewel 版本中，当在 Jewel 上安装 Ceph 集群时，默认启用两个附加标志。如果集群是从 Jewel 之前的版本（例如 Hammer）升级而来的，则可以启用这些标志：
除了这些标志，你还可以使用以下命令修复OSD和PG：
Ceph CLI 对于端到端集群管理非常强大。您可以在 http://docs.ceph.com/docs/master/ 获得更多信息rados/man/.
d 经理服务。每次您启动,重新启动，然后 stop Ceph 守护进程（或您的整个集群），您必须至少指定一个选项和一个命令。您还可以指定守护程序类型或守护程序实例。一般语法如下：
systemctl [选项...] 命令 [服务名称...]
systemctl 选项包括：
systemctl 命令包括以下内容：
systemctl 可以针对以下 Ceph 服务类型：