CEPH简介
CEPH简介
无论您是要向Cloud Platform提供Ceph对象存储和/或 Ceph块设备服务，部署Ceph文件系统还是将Ceph用于其他目的，所有 Ceph Storage Cluster部署都首先要设置每个 Ceph节点，您的网络和Ceph。存储集群。一个Ceph存储群集至少需要一个Ceph监视器，Ceph管理器和Ceph OSD（对象存储守护程序）。运行Ceph文件系统客户端时，也需要Ceph Metadata Server。
- 监视器：Ceph Monitor（ceph-mon）维护集群状态的映射，包括监视器映射，管理器映射，OSD映射和CRUSH映射。这些映射是Ceph守护程序相互协调所需的关键群集状态。监视器还负责管理守护程序和客户端之间的身份验证。通常至少需要三个监视器才能实现冗余和高可用性。
- 管理器：Ceph Manager守护进程（ceph-mgr）负责跟踪运行时指标和Ceph集群的当前状态，包括存储利用率，当前性能指标和系统负载。Ceph Manager守护进程还托管基于python的模块，以管理和公开Ceph集群信息，包括基于Web的Ceph仪表板和 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守护程序应存储该放置组。CRUSH算法使Ceph存储集群能够动态扩展，重新平衡和恢复。
硬件建议
Ceph被设计为在商品硬件上运行，这使得在经济上构建和维护PB级数据集群成为可能。在规划群集硬件时，您需要权衡许多注意事项，包括故障域和潜在的性能问题。硬件规划应包括在许多主机之间分发Ceph守护进程和其他使用Ceph的进程。通常，我们建议在为该类型的守护程序配置的主机上运行特定类型的Ceph守护程序。我们建议将其他主机用于利用您的数据集群的进程（例如，OpenStack，CloudStack等）。
小费
也可以查看Ceph博客。
CPU
Ceph元数据服务器动态地重新分配其负载，这会占用大量CPU。因此，您的元数据服务器应具有强大的处理能力（例如，四核或更好的CPU）。Ceph OSD运行RADOS服务，使用CRUSH计算数据放置，复制数据并维护自己的集群图副本。因此，OSD应具有合理数量的处理能力（例如，双核处理器）。监控器仅维护集群映射的主副本，因此它们不占用大量CPU。您还必须考虑主机除Ceph守护程序外是否还将运行CPU密集型进程。例如，如果您的主机将运行计算VM（例如，OpenStack Nova），则需要确保这些其他进程为Ceph守护程序留有足够的处理能力。我们建议在单独的主机上运行其他占用大量CPU的进程。
RAM
通常，内存越多越好。
监视器和管理器（CEPH-MON和CEPH-MGR）
监视程序和管理程序守护程序的内存使用量通常随群集的大小而扩展。对于小型群集，通常1-2 GB就足够了。对于大型群集，您应该提供更多（5-10 GB）。您可能还需要考虑调整设置，例如mon_osd_cache_size或 rocksdb_cache_size。
元数据服务器（CEPH-MDS）
元数据守护程序的内存利用率取决于其缓存配置为消耗多少内存。对于大多数系统，我们建议最小为1 GB。请参阅 mds_cache_memory。
OSD（CEPH-OSD）
默认情况下，使用BlueStore后端的OSD需要3-5 GB的RAM。您可以osd_memory_target在使用BlueStore时通过配置选项来调整OSD占用的内存量。使用旧版FileStore后端时，操作系统页面缓存用于缓存数据，因此通常不需要进行调整，并且OSD内存消耗通常与系统中每个守护程序的PG数量有关。
数据存储
仔细计划数据存储配置。在计划数据存储时，需要考虑大量的成本和性能折衷。同时执行OS操作，以及从多个守护程序同时请求对单个驱动器的读写操作，可能会大大降低性能。
重要
由于Ceph必须先将所有数据写入日志，然后才能发送ACK（至少对于XFS），因此平衡日志和OSD性能非常重要！
硬盘驱动器
OSD应该具有足够的硬盘驱动器空间来存储对象数据。我们建议最小硬盘驱动器大小为1 TB。考虑更大磁盘的每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％，从而使群集的成本效率大大降低。而且，存储驱动器容量越大，每个Ceph OSD守护程序所需的内存更多，尤其是在重新平衡，回填和恢复期间。一般的经验法则是1TB的存储空间需要约1GB的RAM。
小费
在单个磁盘上运行多个OSD（与分区无关） 不是一个好主意。
小费
运行OSD和监视器或对单个磁盘，无论元数据服务器的分区，是不是一个好主意，无论是。
存储驱动器受到查找时间，访问时间，读写时间以及总吞吐量的限制。这些物理限制会影响整个系统的性能，尤其是在恢复过程中。我们建议为操作系统和软件使用专用的驱动器，并为主机上运行的每个Ceph OSD守护程序使用一个驱动器。大多数“ OSD慢”问题是由于在同一驱动器上运行操作系统，多个OSD和/或多个日志而引起的。由于对小型群集上的性能问题进行故障排除的成本可能超出了额外磁盘驱动器的成本，因此您可以避免对OSD存储驱动器施加过多负担的诱惑，从而加快群集设计计划。
您可以在每个硬盘驱动器上运行多个Ceph OSD守护程序，但这可能会导致资源争用并降低整体吞吐量。您可以将日志和对象数据存储在同一驱动器上，但这可能会增加将写和ACK日志记录到客户端所需的时间。Ceph必须先写入日志，然后才能确认写入。
Ceph最佳实践规定您应在单独的驱动器上运行操作系统，OSD数据和OSD日志。
固态硬盘
一种提高性能的机会是使用固态驱动器（SSD）来减少随机访问时间和读取延迟，同时加快吞吐量。与硬盘驱动器相比，SSD的每千兆字节价格通常高出10倍以上，但是SSD的访问时间通常比硬盘驱动器快至少100倍。
SSD没有可移动的机械部件，因此它们不一定受到与硬盘驱动器相同类型的限制。SSD确实有很大的局限性。在评估SSD时，重要的是要考虑顺序读取和写入的性能。当存储多个OSD的多个日志时，具有400MB / s顺序写入吞吐量的SSD可能比具有120MB / s顺序写入吞吐量的SSD更好。
重要
我们建议探索使用SSD来提高性能。但是，在对SSD进行大量投资之前，我们强烈建议您既检查SSD的性能指标，又在测试配置中测试SSD以评估性能。
由于SSD没有移动的机械零件，因此在不占用大量存储空间（例如日志）的Ceph区域中使用它们是有意义的。相对便宜的SSD可能会吸引您的经济感觉。谨慎使用。选择用于Ceph的SSD时，可接受的IOPS不够。对于期刊和SSD，有一些重要的性能注意事项：
- 写密集型语义：日志记录涉及写密集型语义，因此在写数据时，应确保选择部署的SSD的性能等于或优于硬盘驱动器。廉价的SSD可能会增加写入延迟，即使它们加快了访问时间，因为有时高性能硬盘的写入速度可能比市场上某些更经济的SSD快或快！
- 顺序写入：在SSD上存储多个日志时，还必须考虑SSD的顺序写入限制，因为它们可能正在处理同时写入多个OSD日志的请求。
- 分区对齐： SSD性能的一个常见问题是人们喜欢对驱动器进行分区，这是最佳做法，但是他们通常忽略了与SSD进行正确的分区对齐，这可能导致SSD传输数据的速度变慢得多。确保SSD分区正确对齐。
尽管SSD禁止对象存储成本，但OSD可能会通过将OSD的日志存储在SSD上以及将OSD的对象数据存储在单独的硬盘驱动器上而获得显着的性能提升。所述配置设置默认为。您可以将此路径安装到SSD或SSD分区，以便它不仅仅是与对象数据在同一磁盘上的文件。osd journal/var/lib/ceph/osd/$cluster-$id/journal
Ceph加速CephFS文件系统性能的一种方法是将CephFS元数据的存储与CephFS文件内容的存储区分开。Ceph metadata为CephFS元数据提供了一个默认池。您将不必为CephFS元数据创建池，但可以为CephFS元数据池创建仅指向主机的SSD存储介质的CRUSH映射层次结构。有关详细信息，请参见将 池映射到不同类型的OSD。
控制器
磁盘控制器对写入吞吐量也有重大影响。仔细考虑您选择的磁盘控制器，以确保它们不会造成性能瓶颈。
小费
该Ceph的博客往往是对头孢性能问题的信息的极好来源。有关更多详细信息，请参见Ceph写吞吐量1和Ceph写吞吐量2。
其他注意事项
您可以在每个主机上运行多个OSD，但应确保OSD硬盘的总吞吐量之和不超过满足客户端读取或写入数据所需的网络带宽。您还应该考虑群集在每个主机上存储的全部数据的百分比。如果特定主机上的百分比很大且主机发生故障，则可能导致诸如超过的问题，这会导致Ceph停止操作，这是一种安全预防措施，可防止数据丢失。full ratio
当每个主机运行多个OSD时，还需要确保内核是最新的。请参阅操作系统建议，以获取注释，glibc并 syncfs(2)确保每个主机运行多个OSD时硬件能够按预期运行。
网络
我们建议每个主机至少有两个1Gbps网络接口控制器（NIC）。由于大多数商用硬盘驱动器的吞吐量约为100MB /秒，因此您的NIC应该能够处理主机上OSD磁盘的流量。我们建议至少使用两个NIC来说明一个公共（前端）网络和一个群集（后端）网络。群集网络（最好不连接到Internet）可以处理数据复制的额外负载，并有助于阻止拒绝服务攻击，从而阻止群集实现active + cleanOSD在整个群集中复制数据时，放置组的状态。考虑从机架中的10Gbps网络开始。跨1Gbps网络复制1TB数据需要3个小时，而3TB（典型的驱动器配置）则需要9个小时。相反，对于10Gbps网络，复制时间分别为20分钟和1小时。在PB级群集中，OSD磁盘故障应该是一种期望，而不是例外。系统管理员将欣赏PG从degraded状态恢复到正常 状态的过程。active + clean在考虑价格/性能折衷的情况下尽可能快地进行陈述。此外，某些部署工具（例如Dell的Crowbar）可部署五个不同的网络，但使用VLAN使硬件和网络布线更易于管理。使用802.1q协议的VLAN需要具有VLAN功能的NIC和交换机。增加的硬件支出可能会因网络设置和维护的运营成本节省而被抵销。当使用VLAN处理群集和计算堆栈（例如OpenStack，CloudStack等）之间的VM通信时，还值得考虑使用10G以太网。每个网络的架顶式路由器还需要能够与吞吐量甚至更高（例如40Gbps至100Gbps）的主干路由器通信。
您的服务器硬件应具有基板管理控制器（BMC）。管理和部署工具也可能会广泛使用BMC，因此请考虑带外网络进行管理的成本/收益之间的权衡。系统管理程序SSH访问，VM映像上传，OS映像安装，管理套接字等可能会对网络造成很大的负担。运行三个网络似乎有些过头，但是每个流量路径都代表一个潜在的容量，吞吐量和/或性能瓶颈，您在部署大规模数据集群之前应仔细考虑。
失败域
故障域是阻止访问一个或多个OSD的任何故障。那可能是主机上停止的守护程序。硬盘故障，操作系统崩溃，网卡故障，电源故障，网络中断，电源中断等。在计划硬件需求时，您必须权衡诱惑以降低成本，方法是将过多的职责分配到过少的故障域中，以及增加隔离每个潜在故障域的成本。
最低硬件建议
Ceph可以在廉价的商品硬件上运行。小型生产集群和开发集群可以使用适度的硬件成功运行。
| 处理 |
标准 |
最低推荐 |
| ceph-osd |
处理器 |
|
| 内存 |
每个守护程序1TB的存储空间约为1GB |
|
| 卷存储 |
每个守护程序1个存储驱动器 |
|
| 日志 |
每个守护程序1个SSD分区（可选） |
|
| 网络 |
2个1GB以太网NIC |
|
| ceph-mon |
处理器 |
|
| 内存 |
每个守护程序1 GB |
|
| 磁盘空间 |
每个守护程序10 GB |
|
| 网络 |
2个1GB以太网NIC |
|
| ceph-mds |
处理器 |
|
| 内存 |
每个守护程序至少1 GB |
|
| 磁盘空间 |
每个守护程序1 MB |
|
| 网络 |
2个1GB以太网NIC |
小费
如果使用单个磁盘运行OSD，请为卷存储创建一个分区，该分区与包含OS的分区分开。通常，我们建议为操作系统和卷存储使用单独的磁盘。
生产集群的例子
用于PB级数据存储的生产集群也可以使用商用硬件，但应具有更多的内存，处理能力和数据存储以应对繁重的流量负载。
戴尔示例
最近（2012年）的Ceph集群项目正在为Ceph OSD使用两个相当健壮的硬件配置，为显示器使用一个较轻的配置。
| 组态 |
标准 |
最低推荐 |
| 戴尔PE R510 |
处理器 |
2个64位四核Xeon CPU |
| 内存 |
16 GB |
|
| 卷存储 |
8个2TB驱动器。1个操作系统，7个存储 |
|
| 客户网络 |
2个1GB以太网NIC |
|
| OSD网络 |
2个1GB以太网NIC |
|
| MGMT。网络 |
2个1GB以太网NIC |
|
| 戴尔PE R515 |
处理器 |
1个六核Opteron CPU |
| 内存 |
16 GB |
|
| 卷存储 |
12个3TB驱动器。存储 |
|
| 操作系统存储 |
1个500GB驱动器。操作系统。 |
|
| 客户网络 |
2个1GB以太网NIC |
|
| OSD网络 |
2个1GB以太网NIC |
|
| MGMT。网络 |
2个1GB以太网NIC |
OS建议
头孢依赖
通常，我们建议在较新版本的Linux上部署Ceph。我们还建议在具有长期支持的版本上进行部署。
LINUX内核
- Ceph内核客户端
如果您使用内核客户端映射RBD块设备或挂载CephFS，则一般建议是使用http://kernel.org或您的Linux发行版在任何客户端上提供的“稳定”或“长期维护”内核系列。主机。
对于RBD，如果您选择跟踪长期内核，我们目前建议使用基于4.x的“长期维护”内核系列：
-
- 4.19.z
- 4.14.z
对于CephFS，请参阅CephFS最佳做法以获取内核版本指导。
较旧的内核客户端版本可能不支持您的CRUSH可调参数配置文件或Ceph群集的其他较新功能，因此需要在禁用这些功能的情况下配置存储群集。
平台
下图显示了Ceph的要求如何映射到各种Linux平台上。一般而言，除了内核和系统初始化程序包（即sysvinit，upstart，systemd）以外，对特定发行版的依赖性很小。
鹦鹉螺（14.2.Z）
| 发行 |
发布 |
代码名称 |
核心 |
笔记 |
测试 |
| CentOS的 |
7 |
N / A |
Linux的3.10.0 |
3 |
B，我，C |
| Debian的 |
8 |
杰西 |
Linux的3.16.0 |
一二 |
B，我 |
| Debian的 |
9 |
伸展 |
Linux的4.9 |
一二 |
B，我 |
| RHEL |
7 |
迈波 |
Linux的3.10.0 |
B，我 |
|
| Ubuntu的 |
14.04 |
可信赖的塔尔 |
Linux的3.13.0 |
B，我，C |
|
| Ubuntu的 |
16.04 |
Xenial Xerus |
Linux的4.4.0 |
3 |
B，我，C |
| Ubuntu的 |
18.04 |
仿生海狸 |
Linux的4.15 |
3 |
B，我，C |
| openSUSE的 |
15.1 |
飞跃 |
Linux的4.12 |
||
| openSUSE的 |
滚草 |
Linux的5.1.7 |
发光的（12.2.Z）
| 发行 |
发布 |
代码名称 |
核心 |
笔记 |
测试 |
| CentOS的 |
7 |
N / A |
Linux的3.10.0 |
3 |
B，我，C |
| Debian的 |
8 |
杰西 |
Linux的3.16.0 |
一二 |
B，我 |
| Debian的 |
9 |
伸展 |
Linux的4.9 |
一二 |
B，我 |
| Fedora的 |
22 |
N / A |
Linux的3.14.0 |
B，我 |
|
| RHEL |
7 |
迈波 |
Linux的3.10.0 |
B，我 |
|
| Ubuntu的 |
14.04 |
可信赖的塔尔 |
Linux的3.13.0 |
B，我，C |
|
| Ubuntu的 |
16.04 |
Xenial Xerus |
Linux的4.4.0 |
3 |
B，我，C |
注释
- 1：默认内核具有较旧的版本btrfs，我们不建议将其用于ceph-osd存储节点。我们建议使用XFS。
- 2：默认内核具有旧的Ceph客户端，我们不建议将其用于内核客户端（内核RBD或Ceph文件系统）。升级到推荐的内核。
- 3：btrfs 使用文件系统时，默认内核通常会在质量检查中失败。我们不建议将其btrfs用于备份Ceph OSD。
测试
- B：我们为此平台构建发行包。对于其中一些平台，我们还可能会不断构建所有ceph分支并进行基本的单元测试。
- I：我们对该平台上的发行版进行基本的安装和功能测试。
- C：我们在该平台上连续运行一个综合的功能，回归和压力测试套件。这包括开发分支，预发布和发布的代码。
参与CEPH社区！
在Ceph社区，这是令人兴奋的时刻！参与其中！
| 渠道 |
描述 |
联络资料 |
| 博客 |
定期检查Ceph 博客，以跟踪Ceph的进度和重要的公告。 |
http://ceph.com/community/blog/ |
| Ceph星球 |
查看Planet Ceph上的博客聚合，以获取社区中有趣的故事，信息和经验。 |
https://ceph.com/category/planet/ |
| 维基 |
查看Ceph Wiki，可获取更多与社区和开发相关的主题。您可以在此处找到有关蓝图，聚会，Ceph开发者峰会等的信息。 |
http://wiki.ceph.com/ |
| IRC |
当您深入研究Ceph时，您可能会对Ceph开发团队有疑问或反馈。Ceph开发人员通常可以在#ceph IRC频道上使用，特别是在美国太平洋标准时区的白天。虽然#ceph是集群运营商和用户一个很好的起点，也有 #ceph-devel和#ceph-dashboard 专用的头孢开发。 |
irc.oftc.net
#ceph， #ceph-devel， #ceph-dashboard |
| 用户清单 |
通过订阅电子邮件列表ceph-users @ ceph来询问和回答与用户有关的问题 。com。您可以随时取消订阅，退出电子邮件列表。只需一封简单的电子邮件！如果您想查看档案，请转到Gmane。 |
|
| 开发清单 |
通过订阅电子邮件列表ceph -devel @ vger与开发人员保持联系 。内核。org。您可以随时取消订阅，退出电子邮件列表。只需一封简单的电子邮件！如果您想查看档案，请转到Gmane。 |
|
| 提交清单 |
订阅ceph-commit @ ceph 。com通过电子邮件获取提交通知。您可以随时取消订阅，退出电子邮件列表。只需一封简单的电子邮件！ |
|
| 质量检查清单 |
对于质量保证（QA），相关活动订阅此列表。您可以随时取消订阅，退出电子邮件列表。只需一封简单的电子邮件！ |
|
| 社区清单 |
对于与Ceph用户委员会和其他社区主题有关的所有讨论。您可以随时取消订阅，退出电子邮件列表。只需一封简单的电子邮件！ |
|
| 错误追踪 |
您可以通过记录和跟踪错误以及使用Bug Tracker提供功能请求来帮助保持Ceph产品的价值。 |
http://tracker.ceph.com/projects/ceph |
| 源代码 |
如果您想参与开发，错误修复，或者只想要Ceph的最新代码，可以在http://github.com上获得。有关 从github进行克隆的详细信息，请参见Ceph源代码。 |
|