5种最常见的CEPH失败方案

Posted 2022-05-31 YoungerChina

       Ceph是一种广泛使用的存储解决方案，可在整个分布式集群中实现对象级，块级和文件级存储。Ceph是创建不围绕单个故障点进行扩展的高效存储系统的理想选择。但是，如果管理不当，Ceph可能很容易成为失败场景的雷区，这可能是一件难以完全避免的事情。本处，我们将探讨最常见的五种Ceph失败方案。

Monitor数目不正确

       在最新版本的Ceph中，至少需要三台运行Ceph Mon守护程序的服务器。这些可以是物理服务器（理想情况下）或者也可以是虚拟机。但是，如果您超出了Mon服务器的最小数量，则在Ceph构建中始终保持运行奇数个守护程序非常重要。这个奇数很重要，因为它允许系统正确地建立一个主机来控制CRUSH Map。在确定主服务器时，每台服务器都会“投票”认为最适合维护crush map的服务器。维护奇数个Ceph守护程序可确保永远不会出现投票平局的现象，并且始终会建立一个主服务器。如果没有维护奇数个守护程序，则可能会导致不稳定，并最终导致Ceph崩溃。

OSD数目不正确

       根据在Ceph集群中所设置的副本数，您将需要足够数量的硬盘（OSD——对象存储设备）。当您计划购买或升级当前Ceph中的OSD前，最重要的是要根据当前状况进行数据量预测，以匹配未来生产的数据量。通常，最好至少提前6到12个月进行估算，并将此存储量乘以所需的对象冗余量（即32TB数据* 3（副本数）= 96TB所需的存储空间）。通过适当的预测，您可以避免OSD过载，并保持CEPH环境正常运行。

RADOS网关冗余不足

       RADOS (「Reliable, Autonomic Distributed Object Store」) 是Ceph的核心之一，作为Ceph分布式文件系统的一个子项目，特别为Ceph的需求设计，能够在动态变化和异质结构的存储设备集群之上提供一种稳定、可扩展、高性能的单一逻辑对象(Object)存储接口和能够实现节点的自适应和自管理的存储系统。RADOS构成了Ceph集群的核心，并且与Ceph CRUSH Map结合使用时，可以使您在服务器的集群中保持数据一致且可安全的进行数据同步与复制。可以以多种不同方式访问Ceph数据。其中之一是通过称为RADOS网关的HTTP API前端进行的。RADOS网关公开了一个存储API，供外部人员调用。

       如果通过RADOS网关访问您的Ceph集群，那么促进API访问的前端服务器必须冗余且能够负载均衡，这一点非常重要。在理想的配置中，多个RADOS服务器将可用于接受请求，并且所有请求都应由一个冗余的负载均衡器进行管理。如果未进行正确配置，则非冗余RADOS网关服务器的故障将导致您完全失去对CEPH群集的API访问权限。您可以使用混合的解决方案，该混合解决方案会利用本地RADOS网关，当发生故障时则会回退到基于云的冗余网关上。这可以最大程度地减少额外的不必要转换，同时保持对存储解决方案的冗余和可靠访问。

硬件配置不足

       为CEPH集群维护硬件时，最重要的是要确保硬件配置满足实际需求，具体需要考虑的如下：

电源：

       确保主机的电源模块至少是双路冗余。还要确保每台CEPH服务器都有一个备用电源，该备用电源的功率足以完全满足服务器的需求。没有适当的冗余，您将面临不可挽回的数据丢失的风险。

CPU：

       最佳实践要求在所有CEPH服务器上使用相同型号相同配置的CPU。这有助于在整个ceph集群中保持一致性以及稳定性。

内存：

       与CPU相似，您使用的内存应在CEPH服务器之间平均分配。理想情况下，存储服务器的品牌和规格应该相同。此外，在发生硬件故障时，还应具有大量可用的冗余内存（备件）。

硬盘：

        建议将SAS磁盘用于OSD。如果有可能的话，使用故障率低于SAS盘的NVMe磁盘则会更为理想。

其他：

       如果有可能的话，可以提供一些冷备机器。当存储节点存现故障的时候，极端情况下可以直接进行备机更换（保留物理磁盘）。

CEPH专业知识

       通常，CEPH失败的原因是由于缺乏CEPH相关的专业知识。例如，所有CEPH群集中OSD节点都将利用硬盘直通模式来确保性能和可靠性。但是，如果改用RAID的话，则不仅是不推荐的，而且还会因为磁盘阵列故障而导致出现单点故障，最终可能引起大量数据丢失。这种错误很简单，但从长远来看，这样的错误代价高昂，并且可能需要更高级的ceph专家去解决相应的问题。

开发者涨薪指南 48位大咖的思考法则、工作方式、逻辑体系