Linux搭建Ceph集群详细教程

哈喽！今天心血来潮给大家带来了《Linux搭建Ceph集群教程》，想必大家应该对文章都不陌生吧，那么阅读本文就都不会很困难，以下内容主要涉及到，若是你正在学习文章，千万别错过这篇文章~希望能帮助到你！

Ceph分布式存储的核心组件包括Monitor (MON)、Object Storage Device (OSD)、Metadata Server (MDS)和RADOS Gateway (RGW)。1. Monitor负责维护集群状态和认证信息，至少需要三个节点形成仲裁；2. OSD负责实际数据存储与复制，是集群性能的基础；3. MDS专用于CephFS文件系统，管理元数据；4. RGW提供对象存储接口，兼容S3和Swift标准。所有组件运行在底层存储引擎RADOS之上，实现数据的高可用与自愈。

在Linux上搭建分布式存储系统，Ceph无疑是目前最成熟、功能最强大的开源选择之一。它能够将廉价的硬件资源整合起来，提供可伸缩、高可用的存储服务，无论是块存储、文件存储还是对象存储，它都能胜任。搭建过程需要细致的规划和逐步的实施，但一旦部署完成，其带来的灵活性和可靠性是传统存储难以比拟的。

解决方案

搭建一个基于Linux的Ceph分布式存储集群，通常我会推荐使用ceph-deploy工具，它能大大简化初始部署的复杂性。当然，手动部署也能实现，但对于初学者或追求效率的团队，ceph-deploy是更友好的选择。

第一步是环境准备。确保所有参与集群的节点都运行着相同版本的Linux发行版（比如Ubuntu Server或CentOS），并且内核版本相对较新。每个节点都需要配置好静态IP地址，并且所有节点之间能通过SSH无密码互访（这是ceph-deploy工作的核心）。我个人习惯为Ceph创建一个专门的用户（例如cephuser），并赋予其sudo权限，这样可以避免直接使用root账户带来的潜在风险。防火墙方面，我通常会先禁用它，或者只开放Ceph所需的端口（例如6379, 6789, 6800-7300等），这在生产环境中尤为重要。

接下来是安装ceph-deploy。在一个指定的部署节点（可以是集群中的任意一个节点，也可以是独立的管理节点）上安装ceph-deploy工具及其依赖。这通常通过添加Ceph的官方仓库然后使用包管理器安装完成。

# Ubuntu/Debian
sudo apt update
sudo apt install ca-certificates lsb-release gnupg
wget -qO- 'https://download.ceph.com/keys/release.asc' | sudo apt-key add -
echo deb https://download.ceph.com/debian-{ceph-release-name}/ $(lsb_release -sc) main | sudo tee /etc/apt/sources.list.d/ceph.list
sudo apt update
sudo apt install ceph-deploy

# CentOS/RHEL
sudo yum install -y yum-utils
sudo rpm --import 'https://download.ceph.com/keys/release.asc'
sudo yum-config-manager --add-repo https://download.ceph.com/rpm-{ceph-release-name}/el$(rpm -E %{rhel})/
sudo yum install -y ceph-deploy

注意将{ceph-release-name}替换为具体的Ceph版本名称，例如quincy或reef。

然后是集群初始化。在部署节点上，创建一个工作目录，然后使用ceph-deploy new命令来初始化集群。这个命令会生成一个ceph.conf配置文件和一些密钥文件。

mkdir mycephcluster
cd mycephcluster
ceph-deploy new node1 node2 node3 # 替换为你的monitor节点

这里node1等是你的监控器（Monitor）节点。

安装Ceph软件包到所有集群节点。

ceph-deploy install node1 node2 node3 node4 # 包含所有OSD、MDS、RGW节点

部署Monitor节点。

ceph-deploy mon create-initial

这会启动初始的Monitor服务，并生成集群的认证密钥。

添加OSD（Object Storage Device）节点。这是存储数据的核心。每个OSD通常对应一块独立的硬盘。在添加OSD之前，确保你的硬盘是裸盘，或者已经清空了所有分区。

ceph-deploy osd create node1:/dev/sdb node2:/dev/sdc node3:/dev/sdd # 示例

这里，/dev/sdb等是你要用作OSD的硬盘路径。如果你的硬盘有单独的WAL/DB盘（比如NVMe SSD），可以这样指定：

ceph-deploy osd create --data /dev/sdb --block-wal /dev/nvme0n1p1 node1

部署MDS（Metadata Server）和RGW（RADOS Gateway）（如果需要文件存储和对象存储）。

ceph-deploy mds create node1
ceph-deploy rgw create node1

最后，分发配置文件和密钥到所有节点，确保它们能够正常与集群通信。

ceph-deploy admin node1 node2 node3 node4

至此，一个基本的Ceph集群就搭建起来了。后续还需要创建存储池（Pool）、调整CRUSH Map等操作来优化和使用集群。整个过程下来，你会发现Ceph的灵活性和可配置性确实非常高，但也意味着初期投入的学习成本不低。

Ceph分布式存储的核心组件有哪些？

谈到Ceph，理解它的核心组件是构建和管理集群的基础。我个人觉得，这就像了解一支乐队里每个乐手的职责一样，只有清楚了每个部分的功能，才能让整个系统协调运转。Ceph主要由以下几个关键组件构成：

• Monitor (MON)：这是Ceph集群的“大脑”和“指挥中心”。它维护着集群的健康状态、拓扑结构（如哪些OSD在线、哪些下线）、认证信息以及关键配置。一个健康的Ceph集群至少需要三个Monitor节点来形成仲裁，以防止单点故障。它们之间通过Paxos算法保持数据一致性。如果Monitor都挂了，整个集群就无法进行任何操作了，所以它们的稳定性和冗余性至关重要。
• Object Storage Device (OSD)：这是Ceph集群的“苦力”，负责存储实际的数据。每个OSD通常对应一个物理硬盘（或逻辑卷），它管理着数据对象、处理数据的复制、恢复、再平衡等任务。当客户端写入数据时，数据会被切分成对象，然后根据CRUSH算法分布到不同的OSD上。OSD的数量越多，集群的存储容量和并发性能就越强。我常说，OSD是Ceph的基石，它们的性能直接决定了整个集群的I/O能力。
• Metadata Server (MDS)：这个组件是CephFS（Ceph文件系统）特有的。如果你只使用块存储（RBD）或对象存储（RGW），那么MDS就不是必需的。MDS负责存储和管理CephFS的文件系统元数据，比如目录结构、文件权限、文件名等。它不存储文件内容本身，内容依然由OSD存储。MDS的性能对文件系统的响应速度至关重要，尤其是在处理大量小文件或频繁进行目录操作时。
• RADOS Gateway (RGW)：这是Ceph集群的“网关”，提供兼容Amazon S3和OpenStack Swift的对象存储接口。通过RGW，用户可以使用标准的HTTP RESTful API来访问Ceph集群中的对象存储服务。它将HTTP请求翻译成RADOS操作，并负责用户认证、权限管理等。如果你需要提供云存储服务，或者为应用程序提供S3兼容的存储后端，RGW是不可或缺的。

除了这些核心组件，Ceph的底层存储引擎RADOS（Reliable Autonomic Distributed Object Store）才是真正的魔术师。它负责数据的存储、复制、一致性维护、故障检测和自愈。所有上层服务（RBD, CephFS, RGW）都是构建在RADOS之上的。理解这些组件之间的协同工作方式，能帮助你更好地规划、部署和维护Ceph集群。

在Linux上部署Ceph集群需要哪些前置准备？

部署Ceph集群，前期的准备工作往往决定了后期运维的顺畅程度。我个人在多次实践中发现，跳过或轻视任何一个准备步骤，都可能导致后续部署失败或集群性能不佳。

首先是硬件规划。这包括计算资源、存储介质和网络。

• 计算资源：Monitor节点对CPU和内存要求相对较低，但为了稳定，每个Monitor至少分配4GB内存。OSD节点则需要足够的CPU和内存来处理数据I/O，通常每个OSD进程建议分配2GB内存，所以如果一个节点跑多个OSD，内存需求会线性增长。CPU方面，现代多核处理器基本都能满足需求。
• 存储介质：这是重中之重。OSD节点需要大量的硬盘。对于数据盘，可以是HDD或SSD。如果追求极致性能，全SSD是理想选择，但成本高昂。一种折衷方案是，数据盘使用HDD，但将Ceph的WAL（Write-Ahead Log）和DB（BlueStore的元数据）放到单独的NVMe SSD上，这能显著提升HDD OSD的性能。我强烈建议为OSD节点配备多块独立的物理硬盘，而不是使用RAID，因为Ceph本身就提供了数据冗余和保护。
• 网络：这是Ceph性能的另一个瓶颈。我通常会建议为Ceph集群配置至少两张网卡：一张用于公共网络（Public Network），供客户端访问和Monitor通信；另一张用于集群内部通信（Cluster Network），即OSD之间的数据复制和心跳。这张集群内部网络的速度越快越好，10GbE是起步，25GbE甚至40GbE能带来更好的性能。网络延迟对Ceph性能影响很大，所以尽量保持网络拓扑扁平化。

其次是操作系统配置。

• NTP同步：所有节点必须保持时间同步。Ceph对时间漂移非常敏感，如果节点时间不一致，可能导致Monitor仲裁失败或数据一致性问题。配置NTP服务（如chrony或ntpd）并确保其正常工作是必选项。
• SSH无密码登录：ceph-deploy工具依赖SSH进行远程操作。因此，从部署节点到所有集群节点都需要配置SSH免密码登录。我一般会生成SSH密钥对，并将公钥分发到所有节点的~/.ssh/authorized_keys文件中。
• 用户和权限：创建一个非root用户（例如cephuser），并赋予其sudo权限，且配置sudo时无需密码。这能提高安全性，并方便ceph-deploy执行命令。
• 防火墙：在生产环境中，你需要精确开放Ceph所需的端口。但为了简化部署，我通常会在初始阶段暂时禁用防火墙（或设置为允许所有内部流量），待集群稳定后再逐步收紧规则。
• SELinux/AppArmor：这些安全增强模块可能会阻止Ceph进程正常运行。在CentOS/RHEL上，我通常会把SELinux设置为permissive模式，或直接禁用它（不推荐在生产环境禁用）。在Ubuntu上，类似地考虑AppArmor的影响。

最后是文件系统和分区。

• 裸盘：用于OSD的硬盘应该是裸盘，不包含任何分区或文件系统。Ceph的BlueStore存储引擎会直接管理这些裸设备。
• LVM（可选）：虽然Ceph可以直接使用裸盘，但在某些情况下，你可能需要使用LVM来管理OSD的底层设备，例如需要灵活调整OSD大小或共享物理卷。但这会增加一层复杂性。我个人倾向于直接使用裸盘，除非有特殊需求。

这些前置准备工作虽然繁琐，但它们是确保Ceph集群稳定、高效运行的基石。花时间把这些基础打牢，能让你在后续的部署和运维中省去很多麻烦。

如何为Ceph集群选择合适的存储介质和网络配置？

选择合适的存储介质和网络配置，对Ceph集群的性能和成本效益至关重要。这不仅仅是技术问题，更是一种资源和性能的权衡。我个人在为客户设计Ceph方案时，会非常重视这一环节，因为它直接影响到用户体验和后期扩展性。

存储介质的选择：

• OSD数据盘：

  • HDD (Hard Disk Drive)：如果你的主要需求是大容量存储和成本效益，并且对IOPS要求不高（例如冷数据存储、备份），HDD是经济实惠的选择。但要注意，HDD的随机读写性能是其短板，可能成为集群的性能瓶颈。为了缓解这个问题，我通常会建议将HDD OSD的WAL（Write-Ahead Log）和DB（BlueStore的元数据）分离到高速SSD上。
  • SSD (Solid State Drive)：对于需要高性能IOPS的应用（如虚拟机镜像、数据库），SSD是首选。全闪存Ceph集群能提供卓越的性能，但成本会显著增加。在预算允许的情况下，使用企业级NVMe SSD作为OSD数据盘能带来最佳的性能体验。
  • NVMe SSD：这是目前性能最好的SSD，尤其适合作为OSD的WAL/DB盘，或者直接作为高性能OSD数据盘。其低延迟和高吞吐量能极大提升Ceph的响应速度。

• WAL/DB盘分离策略：

  • 如果你使用HDD作为OSD数据盘，我强烈建议将BlueStore的WAL和DB（或者旧版FileStore的Journal）分离到独立的SSD或NVMe SSD上。WAL和DB是Ceph写入和元数据操作的瓶颈，将其放到高速存储上，能显著提升HDD OSD的随机写入性能和整体响应速度。通常一个高性能NVMe SSD可以承载多个HDD OSD的WAL/DB。

• 容量与性能的平衡：

  • 不要过度追求单盘容量，而牺牲了OSD的数量。Ceph的性能与OSD的数量呈正相关，更多的OSD意味着更多的并发I/O能力。所以，有时选择多块小容量的盘比少数几块大容量的盘更能提升集群性能。

网络配置的选择：

• 公共网络 (Public Network)：

  • 这是客户端访问Ceph服务的接口，也是Monitor节点之间通信的网络。对于大多数应用，1GbE以太网可能足够，但如果你的客户端数量庞大，或者需要高吞吐量，升级到10GbE甚至更高是明智之举。我通常会优先确保公共网络的带宽和稳定性。

• 集群网络 (Cluster Network)：

  • 这是Ceph OSD之间进行数据复制、心跳和恢复操作的网络。这是Ceph集群内部流量最大的地方，其带宽直接决定了数据复制的速度和集群的恢复能力。我个人经验是，集群网络的速度至少要达到10GbE，如果预算允许，25GbE或40GbE会带来质的飞跃，尤其是在大规模集群或故障恢复时。
  • 网络隔离：强烈建议将公共网络和集群网络进行物理隔离，使用独立的网卡和交换机。这能避免内部数据复制流量影响到客户端访问，同时也能提升安全性。
  • 巨型帧 (Jumbo Frames)：在集群网络中启用巨型帧（MTU设置为9000）可以减少CPU开销，提高网络吞吐量，因为每个数据包可以承载更多的数据。但需要确保所有网络设备（网卡、交换机）都支持并正确配置了巨型帧。

• 网卡绑定 (Bonding/Teaming)：

  • 为了提高网络的可用性和带宽，可以对公共网络和集群网络进行网卡绑定。常见的模式有Active-Backup（高可用）和LACP（负载均衡和高可用）。这能有效避免单网卡故障导致的网络中断，并能聚合带宽。

总结来说，存储介质和网络配置的选择是一个权衡的过程。没有一劳永逸的完美方案，只有最适合你当前需求和预算的方案。我的建议是，先评估你的I/O需求和数据增长预期，然后根据这些数据来选择合适的硬件，并且永远不要低估网络对分布式存储系统性能的影响。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Linux搭建Ceph集群详细教程》文章吧，也可关注golang学习网公众号了解相关技术文章。