「精心整理」Ceph搭建硬件建议详解

Ceph是专为在商品硬件上运行而设计的，这使得构建和维护超大规模的数据集群在经济上是可行的。当规划出你的集群硬件时，你需要平衡一些考虑因素，包括故障域和潜在的性能问题。硬件规划应该包括将Ceph守护进程和其他使用Ceph的进程分布在许多主机上。一般来说，我们 建议在为该类型的守护进程配置的主机上运行特定的Ceph守护进程。我们建议使用其他主机来处理使用您的数据集群的进程（例如OpenStack、CloudStack）

Ceph元数据服务器会动态地重新分配负载，这对CPU来说是很有必要的。所以你的元数据处理器应该有相当大的处理能力（四核心或更高的CPU）。Ceph OSDs 运行RADOS服务，用CRUSH计算数据放置、复制数据，并维护自己的集群地图副本。因此，OSD应该有合理的处理能力（例如双核处理器）。监视器只是维护集群映射的主副本，所以监视器不需要CPU密集型的处理能力。

除了Ceph守护进程之外，你还必须考虑主机是否会运行CPU密集型进程，例如，如果您的主机将运行计算虚拟机（例如，OpenStack Nova)，您需要确保这些其他进程为Ceph守护进程留下足够的处理能力。我们建议在单独的主机上运行额外的CPU密集型进程。

一般来说，RAM越多越好

监视器和管理器守护进程的内存使用量一般会随着集群的大小而变化。

对于小型集群，一般来说，1-2GB就足够了。

对于大型集群，你应该提供更多（5-10GB）。

你可能还需要考虑调整设置，如mon_osd_cache_size或 rocksdb_cache_size

Bluestore使用自己的内存来缓存数据，而不是依赖操作系统的页面缓存。在BlueStore中，你可以通过osd_memory_target选项调整OSD_memory_target的内存量

•通常不建议将osd_memory_target设置为2GB以下，可能会将内存保持在2GB以下，同时也可能导致性能极慢。•将内存目标设置在2Gb和4Gb之间通常有效，但可能会导致性能下降，因为元数据可能在IO期间从磁盘读取，除非活动数据集相对较小。•4GB是目前默认的osd_memory_target大小，这样设置的目的是为了平衡内存需求和OSD的性能，以满足典型的使用情况•设置osd_memory_target高于4GB时，当有许多（小的）或大的（256GB/OSD)数据集被处理时，可能会提高性能。

重要：

OSD的内存自动调整是“尽力而为”。虽然OSD可能会解除内存映射，让内核回收内存，但不能保证内核会在任何特定的时间框架内实际回收释放的内存。这在旧版本的Ceph中尤其如此，因为透明的巨页会阻止内核从碎片化的巨页中回收内存。现代版本的Ceph在应用级禁用透明巨页以避免这种情况，但这仍然不能保证内核会立即回收未映射的内存。OSD有时仍然可能会超过它的内存目标。我们建议在系统中保留20%左右的额外内存，以防止OSD在临时高峰期或由于内核延迟回收空闲页而导致的OSD出现OOM。这个值可能会比需要的多或少取决于系统的具体配置。

在使用传统的FileStore后端时，页面缓存是用来缓存数据的，所以一般不需要调优，OSD的内存消耗一般与系统中每个守护进程的PG数量有关

仔细规划你的数据存储配置。在规划数据存储时，需要考虑重大的成本和性能权衡。同时进行操作系统操作，以及多个守护进程对单个驱动器同时请求读取和写入操作，会大大降低性能。

重要

由于Ceph在发送ACK之前必须先将所有数据写入日志（至少对XFS来说），所以日志和OSD的性能平衡真的很重要！在这里，Ceph的日志和OSD的性能是非常重要的。

OSD应该有足够的硬盘空间来存放对象数据。我们建议硬盘驱动器的最小容量为1T。考虑到较大磁盘的每GB的成本优势。我们建议将硬盘驱动器的价格除以千兆字节，得出每千兆字节的成本，因为较大的驱动器可能会对每千兆字节的成本有很大影响。例如，价格为75美元的1T硬盘，每千兆字节的成本为007美元。相比之下，价格为150美元的3T硬盘的成本为每千兆字节005美元。在上述例子中，使用1T硬盘通常会使每千兆字节的成本增加40%——使集群的成本效益大大降低。

Tips: 在一个磁盘上运行多个OSD，无论分区如何，都不是一个好主意

Tips: 在单一磁盘上运行OSD和显示器或者元数据服务器，无论分区如何，都不是一个好主意

存储驱动器在寻求时间、访问时间、读取和写入时间以及总吞吐量方面受到限制。这些物理限制会影响整体系统性能，特别是在恢复期间。我们建议为操作系统和软件使用一个专门驱动器，并且您在主机上运行的每个Ceph OSD daemon使用一个驱动器。大多数“慢OSD”问题的出现是由于在同一个驱动器上运行一个操作系统，多个OSD，或多个日志。由于在一个小型集群上排除性能问题的成本超过了额外的磁盘驱动器的成本，因此您可以通过避免过度消耗OSD存储驱动器的诱惑来优化您的集群设计规划。

您可以在每个硬盘驱动器上运行多个Ceph OSD Daemons，但这可能会导致资源征用，降低整体吞吐量。你可以在同一硬盘上存储日志和对象数据，但这可能会增加写日志和ACK到客户端所需要的时间。Ceph必须先写入到日志，然后再进行ACK写入。

ack写入：完成此类写入之后，将向客户端发送一个成功写入的ACK，所以称之为ACK写入

Ceph最佳实践规定，你应该在不同的驱动器上运行操作系统、OSD数据和OSD日志

提高性能的一个机会是使用固态硬盘来减少随机访问时间和读取延迟，同时加快吞吐量。与机械硬盘相比，固态硬盘每千兆字节的成本往往超过10倍以上，但固态硬盘的访问时间往往比机械硬盘至少快100倍。

固态硬盘没有活动的机械部件，所以他们不一定会受到与机械硬盘相同的限制。但固态硬盘确实有很大的局限性。在评估固态硬盘时，重要的是考虑顺序读取和写入的性能。当为多个OSD存储多个日志时，具有400MB/S顺序写入吞吐量的SSD可能比具有120MB/s顺序写入吞吐量的SSD性能要好的多。

重要

我们建议探索使用固态硬盘来提高性能。然而，在对SSD进行重大投资之前，我们强烈建议在审查SSD的性能指标和测试配置中测试SSD的性能

由于固态硬盘没有活动的机械部件，所以在Ceph中不需要使用大量存储空间的区域（如日志）使用固态硬盘是很有意义的。相对便宜的SSD可能会吸引你的经济意识。请谨慎使用。在选择使用Ceph的SSD时，仅有可接受的IOPS是不够的。日志和SSD有几个重要的性能注意事项：

•写入密集型语义：日志涉及到写密集型语义，因此您应该确保您选择部署的SSD在写入数据时的性能相当于或优于机械硬盘。廉价的固态硬盘在加速访问时间的同时，可能会引入写入延时，因为有时高性能硬盘的写入速度会比市场上一些更经济的固态硬盘快，因此，您应该确保您选择的固态硬盘在写入数据时的性能与机械硬盘相当或更好。•顺序写入：当您在SSD上存储多个日志时，您必须考虑到SSD的顺序写入限制，因为它们可能会同时处理对多个OSD日志的写入请求。•分区对齐：SSD性能的一个常见问题是，人们喜欢将硬盘分区作为最佳做法，但往往忽略了对SSD的正确分区对齐，这样会导致SSD的数据传输速度更慢。确保SSD分区正确对齐

虽然固态硬盘对于对象存储的成本较高，但通过将OSD的日志存储在固态硬盘上，并将OSD的对象存储存储在独立的机械硬盘上，可能会看到性能的显著提升。osd journal配置设置默认为/var/lib/ceph/osd/$cluster-id/journal。您可以将此路径挂载到SSD或者SSD分区，使其不只是与对象数据存储在同一硬盘上。

Ceph加速CephFS文件系统性能的一种方法是将CephFS元数据的存储与CephFS文件内容的存储隔离开来。Ceph为CephFS元数据提供了一个默认的元数据池。你永远不必为CephFS元数据创建一个池，但你可以为你的CephFS元数据池创建一个只指向主机的SSD存储介质的CRUSH映射层次结构。详情请参见将池映射到不同类型的OSDs。

•意思是可以将一个池的所有数据都存储到SSD类型的OSD

磁盘控制器对写入吞吐量也有很大影响。在选择磁盘控制器时要慎重考虑，确保不会造成性能瓶颈。

Tips：Ceph博客通常是对Ceph性能问题的一个很好的信息来源。更多详情请参加Ceph写吞吐量1和Ceph写吞吐量2

•http://cephcom/community/ceph-performance-part-1-disk-controller-write-throughput/•http://cephcom/community/ceph-performance-part-2-write-throughput-without-ssd-journals/

你可以在每台主机上运行多个OSD，但你应该确保你的OSD硬盘的总吞吐量之和不超过服务于客户端读取或写入所需的网络带宽。你还应该考虑集群在每台主机上存储的数据占整体数据的百分比。如果某个特定主机上的百分比很大，而该主机出现故障，可能会导致超过  full ratio 等问题，从而导致Ceph停止工作，作为防止数据丢失的安全规范措施。

当你在每个主机上运行多个OSD时，你还需要确保内核是最新的。请参阅OS建议中关于glibc和syncfs（2）的说明，以确保你的硬件在每个主机上运行多个OSD时，能按照预期的方式执行。

考虑从机架上的10Gbps+网络开始。在1Gbps网络上复制1TB的数据需要3个小时，而10TB需要30个小时！相比之下，使用10Gbps网络，复制时间分别需要20分钟和1小时。在petabyte规模的集群中，OSD磁盘的故障应该是一种预期，而不是例外。在考虑到价格/性能权衡的情况下，系统管理员会很欣赏PG能尽快从降级状态恢复到活动+清洁状态。此外，一些部署工具采用VLANS使硬件和网络布线更易于管理。使用8021q协议的运营成本节省所抵消。当使用VLAN来处理集群和计算堆栈（例如OpenStack、CloudStack等）之间的VM流量时，也值得考虑10G以太网。每个网络的架上路由器还需要能够与吞吐量更快的骨干路由器进行通信，例如40Gbps到100Gbps。

您的服务器硬件应该有一个底层管理控制器（BMC）。管理和部署工具也可能会大量使用BMC，因此要考虑带外网络的管理成本/收益权衡。Hypervisor SSH访问、VM镜像上传、操作系统镜像安装、管理套接字等都会给网络带来巨大的负载。运行三个网络可能看起来似乎矫枉过正，但每个流量路径都代表了潜在的容量、吞吐量和/或性能瓶颈，在部署大规模数据集群之前，您应该仔细考虑。

BMC：Baseboard Management Controller，基板管理控制器

带外网络：OOB，全程Out Of Band，一套与任何业务数据网络没有关联的独立网络，在任何时候——即便是业务网络终端的情况下，网络控制中心都可以通过带外网络连接到各个服务器或者网络设备的管理接口或者console

故障域是指任何阻止一个或多个OSD的故障。这可能是主机上的守护进程停止；硬盘故障、操作系统崩溃、网卡故障、电源故障、网络中断、断电等等。在规划硬件需求的时候，你必须平衡一下，把太多的责任放在太少的故障域中来降低成本，以及隔离每个潜在故障域所带来的额外成本

Ceph可以在廉价的商品硬件上运行。小型生产集群和开发集群可以用适中的硬件成功运行

进程类型硬件类型建议的最低标准

ceph-osd Processor最低一核

200-500MB/s 单核心

1000-3000IOPS 单核心

结果是复制之前的结果

结果可能会因为不同的CPU型号和Ceph功能而不同（纠删码池、压缩等）

ARM处理器可能会需要更多的核心

实际性能取决于许多因素，包括磁盘、网络、客户端吞吐量和延迟。我们强烈建议进行基准测试

RAM每个守护进程4GB以上（越多越好）

2-4GB 可以正常工作（可能会很慢）

低于2GB是不推荐的

Volume Storage每个守护进程对应一块硬盘

DB/WAL每个守护进程对应一个SSD分区（可选）

Network最少一块千兆以上的网卡（万兆网卡是被推荐的） ceph-mon Processor最低一核

RAM每个进程2GB以上的内存

Disk Space每进程10GB以上的硬盘空间

Network最少一块千兆以上的网卡 ceph-mds Processor最低一核

RAM每个进程2GB以上的内存

Disk Space每个进程1MB以上的硬盘空间

Network最少一块千兆以上的网卡

二楼说的很专业我来说个简单的：raid0就是把多个（最少2个）硬盘合并成1个逻辑盘使用，数据读写时对各硬盘同时操作，不同硬盘写入不同数据，速度快。raid1就是同时对2个硬盘读写（同样的数据）。强调数据的安全性。比较浪费。raid5也是把多个（最少3个）硬盘合并成1个逻辑盘使用，数据读写时会建立奇偶校验信息，并且奇偶校验信息和相对应的数据分别存储于不同的磁盘上。当RAID5的一个磁盘数据发生损坏后，利用剩下的数据和相应的奇偶校验信息去恢复被损坏的数据。相当于raid0和raid1的综合。raid10就是raid1+raid0，比较适合速度要求高，又要完全容错，当然￥也很多的时候。最少需要4块硬盘（注意：做raid10时要先作RAID1，再把数个RAID1做成RAID0，这样比先做raid0，再做raid1有更高的可靠性）

Ceph 最初是一项关于存储系统的 PhD 研究项目，由 Sage Weil 在 University of California, Santa Cruz（UCSC）实施。但是到了 2010 年 3 月底，您可以在主线 Linux 内核（从 2634 版开始）中找到 Ceph 的身影。虽然 Ceph 可能还不适用于生产环境，但它对测试目的还是非常有用的。本文探讨了 Ceph 文件系统及其独有的功能，这些功能让它成为可扩展分布式存储的最有吸引力的备选。

“Ceph” 对一个文件系统来说是个奇怪的名字，它打破了大多数人遵循的典型缩写趋势。这个名字和 UCSC（Ceph 的诞生地）的吉祥物有关，这个吉祥物是 “Sammy”，一个香蕉色的蛞蝓，就是头足类中无壳的软体动物。这些有多触角的头足类动物，提供了一个分布式文件系统的最形象比喻。

开发一个分布式文件系统需要多方努力，但是如果能准确地解决问题，它就是无价的。Ceph 的目标简单地定义为：

不幸的是，这些目标之间会互相竞争（例如，可扩展性会降低或者抑制性能或者影响可靠性）。Ceph 开发了一些非常有趣的概念（例如，动态元数据分区，数据分布和复制），这些概念在本文中只进行简短地探讨。Ceph 的设计还包括保护单一点故障的容错功能，它假设大规模（PB 级存储）存储故障是常见现象而不是例外情况。最后，它的设计并没有假设某种特殊工作负载，但是包括适应变化的工作负载，提供最佳性能的能力。它利用 POSIX 的兼容性完成所有这些任务，允许它对当前依赖 POSIX 语义（通过以 Ceph 为目标的改进）的应用进行透明的部署。最后，Ceph 是开源分布式存储，也是主线 Linux 内核（2634）的一部分。

现在，让我们探讨一下 Ceph 的架构以及高端的核心要素。然后我会拓展到另一层次，说明 Ceph 中一些关键的方面，提供更详细的探讨。

Ceph 生态系统可以大致划分为四部分（见图 1）：客户端（数据用户），元数据服务器（缓存和同步分布式元数据），一个对象存储集群（将数据和元数据作为对象存储，执行其他关键职能），以及最后的集群监视器（执行监视功能）。

如图 1 所示，客户使用元数据服务器，执行元数据操作（来确定数据位置）。元数据服务器管理数据位置，以及在何处存储新数据。值得注意的是，元数据存储在一个存储集群（标为 “元数据 I/O”）。实际的文件 I/O 发生在客户和对象存储集群之间。这样一来，更高层次的 POSIX 功能（例如，打开、关闭、重命名）就由元数据服务器管理，不过 POSIX 功能（例如读和写）则直接由对象存储集群管理。

另一个架构视图由图 2 提供。一系列服务器通过一个客户界面访问 Ceph 生态系统，这就明白了元数据服务器和对象级存储器之间的关系。分布式存储系统可以在一些层中查看，包括一个存储设备的格式（Extent and B-tree-based Object File System [EBOFS] 或者一个备选），还有一个设计用于管理数据复制，故障检测，恢复，以及随后的数据迁移的覆盖管理层，叫做 Reliable Autonomic Distributed Object Storage （RADOS）。最后，监视器用于识别组件故障，包括随后的通知。

了解了 Ceph 的概念架构之后，您可以挖掘到另一个层次，了解在 Ceph 中实现的主要组件。Ceph 和传统的文件系统之间的重要差异之一就是，它将智能都用在了生态环境而不是文件系统本身。

图 3 显示了一个简单的 Ceph 生态系统。Ceph Client 是 Ceph 文件系统的用户。Ceph Metadata Daemon 提供了元数据服务器，而 Ceph Object Storage Daemon 提供了实际存储（对数据和元数据两者）。最后，Ceph Monitor 提供了集群管理。要注意的是，Ceph 客户，对象存储端点，元数据服务器（根据文件系统的容量）可以有许多，而且至少有一对冗余的监视器。那么，这个文件系统是如何分布的呢？

早期版本的 Ceph 利用在 User SpacE（FUSE）的 Filesystems，它把文件系统推入到用户空间，还可以很大程度上简化其开发。但是今天，Ceph 已经被集成到主线内核，使其更快速，因为用户空间上下文交换机对文件系统 I/O 已经不再需要。

因为 Linux 显示文件系统的一个公共界面（通过虚拟文件系统交换机 [VFS]），Ceph 的用户透视图就是透明的。管理员的透视图肯定是不同的，考虑到很多服务器会包含存储系统这一潜在因素（要查看更多创建 Ceph 集群的信息，见 参考资料 部分）。从用户的角度看，他们访问大容量的存储系统，却不知道下面聚合成一个大容量的存储池的元数据服务器，监视器，还有独立的对象存储设备。用户只是简单地看到一个安装点，在这点上可以执行标准文件 I/O。

Ceph 文件系统 — 或者至少是客户端接口 — 在 Linux 内核中实现。值得注意的是，在大多数文件系统中，所有的控制和智能在内核的文件系统源本身中执行。但是，在 Ceph 中，文件系统的智能分布在节点上，这简化了客户端接口，并为 Ceph 提供了大规模（甚至动态）扩展能力。

Ceph 使用一个有趣的备选，而不是依赖分配列表（将磁盘上的块映射到指定文件的元数据）。Linux 透视图中的一个文件会分配到一个来自元数据服务器的 inode number（INO），对于文件这是一个唯一的标识符。然后文件被推入一些对象中（根据文件的大小）。使用 INO 和 object number（ONO），每个对象都分配到一个对象 ID（OID）。在 OID 上使用一个简单的哈希，每个对象都被分配到一个放置组。 放置组 （标识为 PGID）是一个对象的概念容器。最后，放置组到对象存储设备的映射是一个伪随机映射，使用一个叫做 Controlled Replication Under Scalable Hashing （CRUSH）的算法。这样一来，放置组（以及副本）到存储设备的映射就不用依赖任何元数据，而是依赖一个伪随机的映射函数。这种操作是理想的，因为它把存储的开销最小化，简化了分配和数据查询。

分配的最后组件是集群映射。 集群映射 是设备的有效表示，显示了存储集群。有了 PGID 和集群映射，您就可以定位任何对象。

元数据服务器（cmds）的工作就是管理文件系统的名称空间。虽然元数据和数据两者都存储在对象存储集群，但两者分别管理，支持可扩展性。事实上，元数据在一个元数据服务器集群上被进一步拆分，元数据服务器能够自适应地复制和分配名称空间，避免出现热点。如图 4 所示，元数据服务器管理名称空间部分，可以（为冗余和性能）进行重叠。元数据服务器到名称空间的映射在 Ceph 中使用动态子树逻辑分区执行，它允许 Ceph 对变化的工作负载进行调整（在元数据服务器之间迁移名称空间）同时保留性能的位置。

但是因为每个元数据服务器只是简单地管理客户端人口的名称空间，它的主要应用就是一个智能元数据缓存（因为实际的元数据最终存储在对象存储集群中）。进行写操作的元数据被缓存在一个短期的日志中，它最终还是被推入物理存储器中。这个动作允许元数据服务器将最近的元数据回馈给客户（这在元数据操作中很常见）。这个日志对故障恢复也很有用：如果元数据服务器发生故障，它的日志就会被重放，保证元数据安全存储在磁盘上。

元数据服务器管理 inode 空间，将文件名转变为元数据。元数据服务器将文件名转变为索引节点，文件大小，和 Ceph 客户端用于文件 I/O 的分段数据（布局）。

Ceph 包含实施集群映射管理的监视器，但是故障管理的一些要素是在对象存储本身中执行的。当对象存储设备发生故障或者新设备添加时，监视器就检测和维护一个有效的集群映射。这个功能按一种分布的方式执行，这种方式中映射升级可以和当前的流量通信。Ceph 使用 Paxos，它是一系列分布式共识算法。

和传统的对象存储类似，Ceph 存储节点不仅包括存储，还包括智能。传统的驱动是只响应来自启动者的命令的简单目标。但是对象存储设备是智能设备，它能作为目标和启动者，支持与其他对象存储设备的通信和合作。

从存储角度来看，Ceph 对象存储设备执行从对象到块的映射（在客户端的文件系统层中常常执行的任务）。这个动作允许本地实体以最佳方式决定怎样存储一个对象。Ceph 的早期版本在一个名为 EBOFS 的本地存储器上实现一个自定义低级文件系统。这个系统实现一个到底层存储的非标准接口，这个底层存储已针对对象语义和其他特性（例如对磁盘提交的异步通知）调优。今天，B-tree 文件系统（BTRFS）可以被用于存储节点，它已经实现了部分必要功能（例如嵌入式完整性）。

因为 Ceph 客户实现 CRUSH，而且对磁盘上的文件映射块一无所知，下面的存储设备就能安全地管理对象到块的映射。这允许存储节点复制数据（当发现一个设备出现故障时）。分配故障恢复也允许存储系统扩展，因为故障检测和恢复跨生态系统分配。Ceph 称其为 RADOS（见 图 3 ）。

如果文件系统的动态和自适应特性不够，Ceph 还执行一些用户可视的有趣功能。用户可以创建快照，例如，在 Ceph 的任何子目录上（包括所有内容）。文件和容量计算可以在子目录级别上执行，它报告一个给定子目录（以及其包含的内容）的存储大小和文件数量。

虽然 Ceph 现在被集成在主线 Linux 内核中，但只是标识为实验性的。在这种状态下的文件系统对测试是有用的，但是对生产环境没有做好准备。但是考虑到 Ceph 加入到 Linux 内核的行列，还有其创建人想继续研发的动机，不久之后它应该就能用于解决您的海量存储需要了。

Ceph 在分布式文件系统空间中并不是唯一的，但它在管理大容量存储生态环境的方法上是独一无二的。分布式文件系统的其他例子包括 Google File System（GFS），General Parallel File System（GPFS），还有 Lustre，这只提到了一部分。Ceph 背后的想法为分布式文件系统提供了一个有趣的未来，因为海量级别存储导致了海量存储问题的唯一挑战。

元数据管理系统的架构类型

元数据管理系统（Metadata Management System，简称MMS）的架构类型主要有三种：

集中式架构：在这种架构类型中，所有的元数据都存储在一个中央位置，例如数据库。这种架构类型易于管理，但容易受到单点故障的影响。

分布式架构：在这种架构类型中，元数据被分散存储在多个位置，通常是由不同的服务器或设备组成。这种架构类型具有较高的可用性和可扩展性，但管理起来较为复杂。

混合式架构：这种架构类型结合了集中式和分布式架构的优点。元数据的一部分存储在中央位置，另一部分分散存储在多个位置。这种架构类型可以提供更好的可用性和可扩展性，但仍然易于受到单点故障的影响。

根据实际需求和应用场景的不同，可以选择不同的架构类型来实现元数据管理系统。