问题导读 1.Ceph 生态系统可分解为哪5部分？ Ceph 是一个符合 POSIX (Portable Operating System for UNIX®)、开源的分布式存储系统，依据 GNU 次通用公共许可而运行。该项目最初由 Sage Weill 于 2007 年开发，该项目的理念是提出一个没有任何单点故障的集群，确保能够跨集群节点进行永久数据复制。
与在任何经典的分布式文件系统中一样，放入集群中的文件是条带化的，依据一种称为 Ceph Controlled Replication Under Scalable Hashing (CRUSH) 的伪随机的数据分布算法放入集群节点中。
Ceph 是一种有趣的存储替代方案，这得益于它实现的一些概念，比如元数据分区，以及一种复制或放置组策略（将一系列对象聚合到一个分组中，然后将该分组映射到一系列对象存储后台进程 (OSD)）。
这些特性支持自动扩展、恢复和自主管理集群，因为他们使用以下绑定（在不同的级别上）提供了与您的 Ceph 集群的交互方式：
Reliable Autonomic Distributed Object Store (RADOS) 网关是一种 RESTful 接口，您的应用程序可与其通信，以便将对象直接存储在集群中。 librados 库是一种访问 RADOS 的便利方式，它支持 PHP、Ruby、Java™、Python 和 C/C++ 编程语言。 Ceph 的 RADOS 块设备 (RBD) 是一个完全分布式的块设备，它使用一个 Linux® 内核和一个 Quick EMUlator (QEMU)/基于内核的虚拟机 (KVM) 驱动程序。 原生 CephFS 是一个分布式文件系统，全面支持 Filesystem in Userspace (FUSE)。 如 图 1 中所示，Ceph 生态系统可分解为 5 个组成部分：
librados 库 RADOS 网关 RBD CephFS 集群中的各种节点 图 1. Ceph 生态系统
Ceph 生态系统原生支持许多与其交互的方式，这使得在已运行的基础架构中集成它变得既轻松又便捷，即使它执行的是一个在统一项目文件中提供块和对象存储功能的复杂任务。
接下来我们来看一下组成 Ceph 的各个部分以及它们在 Ceph 中分别扮演的角色。
RADOS 对象存储 图 1 表明 RADOS 对象存储是存储集群的基础。对于通过众多客户端或网关（RADOSGW、RBD 或 CephFS）执行的每个操作，数据会进入 RADOS 或者可以从中读取数据。图 2 显示了 RADOS 集群，它包含两个后台守护进程：Ceph 对象存储后台进程 (OSD) 和维护集群映射的主要副本的 Ceph 监视器。
图 2. The RADOS 对象存储
集群映射描述了对象块的物理位置，以及一个将设备聚合到物理位置的 “桶” 列表。该映射由 Ceph 的高级放置算法控制，该算法在物理位置上建模逻辑位置。图 3 描绘了集群内的 “池”，即存储对象的逻辑分区。每个池被动态映射到 OSD。
图 3. RADOS 位置分组
现在让我们看看第一组后台进程 OSD，然后再看看监视器，最后看看属于 CephFS 分布式文件系统的 Ceph 元数据服务器。
OSD OSD 是访问文件系统并向其中写入数据的后台进程，它提供了通过集群网络访问文件系统的能力。要让集群正常运行，Ceph 开发人员建议使用 XFS（Silicon Graphics 日志文件系统）或 B 树文件系统 (Btrfs) 作为用于对象存储的文件系统。也可使用第 4 代扩展文件系统 (ext4)，但它未提供 XFS 和 Btrfs 为 Ceph 提供的功能。
在本示例中，XFS 部署在所有存储节点上。图 4 演示了 Ceph OSD 如何与物理存储交互。
图 4. RADOS OSD 监视器 在 RADOS 集群中，Ceph 监视器后台进程 (ceph-mon) 位于 OSD 旁边。监视器是一些后台进程，客户端通过与这些后台进程进行通信来操作存储在集群中的数据。这是 Ceph 提出的一种创新方法：无需联系一个管理数据集群访问的集中的元数据服务器，这些轻量型后台进程向客户端提供集群映射，并处理与外部应用程序的所有通信。
ceph-mon 还管理集群中的数据一致性。监视器根据 Paxos 协商协议来进行操作，运行至少 3 个 ceph-mon 实例是您的集群设置的前提条件。
图 5 给出了客户端通过监视器后台进程与集群交互的图像。
元数据服务器 Ceph 使用的最后一个堆栈是 Ceph 元数据服务器，它通过 ceph-mds 后台进程公开，该后台进程存储了 CephFS 的元数据。
该元数据与您在其他文件系统中看到的元数据相同，这些元数据包括文件所有者、时间戳、权限等。元数据后台进程公开了一个符合 POSIX 的分布式文件系统，并将元数据存储在 RADOS 中。
请注意，元数据服务器本身并没有为客户端提供文件；这消除了集群中的任何单点故障。
图 6 显示了 ceph-mds 在使用 CephFS 时所扮演的角色。
CRUSH 算法 Ceph CRUSH（Controlled Replication Under Scalable Hashing）是一个负责集群中的数据放置和检索的算法。存储客户端和 OSD 都使用 CRUSH 算法来执行数据放置和分布计算，没有依赖于可能会在集群中引入单点故障的中央查找表。通过这种方式，CRUSH 减轻了集群工作负载，将工作分配给客户端和集群中的 OSD。
考虑到该算法的性质，数据位置可由客户端本身明确地计算，这能够消除维护集群对象的高度可用的位置映射的需求。换句话说，您的集群需要的负载比经典集群要少一些。
拓扑结构和基础架构感知是 CRUSH 的另一个创新功能。从逻辑上讲，OSD 嵌套在一个组件分层结构中，比如机架或交换机，这使得根据客户端亲和度来隔离故障硬件区域或分区成为可能。CRUSH 映射描述了 OSD 和客户端计算的对象位置；它由轻量型的节点监视器（ceph-mon 后台进程）维护，该进程的惟一工作就是在基础架构更改时调整和传播该映射。这种类型的可扩展模型与经典的数据集群模型是相反的：客户端通常仅请求数据，而集群执行所有复杂的位置计算。最后，元数据由元数据服务器处理并由客户端访问。
下一节提供在正运行的 OpenStack 云中的 CephFS 使用和集成的示例。第一部分介绍如何将 CephFS 部署为您实例的共享存储；第二部分介绍 Glance 镜像服务在 RADOS 中原生地放置和检索镜像的方式。
使用 CephFS 作为云中的共享实例存储 得益于 Ceph 的众多网关，您可以通过许多方式轻松地集成 Ceph 集群。例如：
您可以使用 Ceph 作为使用原生 CephFS 的实例目录的后端。 或者支持您的 Glance 镜像存储库（Ceph 现在集成为 Glance 的一个管道）。 甚至使用 Ceph 作为您的永久性卷后端的强大而又可靠的基础（也可以实现原生集成）。 Ceph 社区在该技术的透明集成上取得了巨大成就，这使得 Ceph 不仅能够保护您的云数据，还能够提供类似的管理解决方案，为管理员提供了设计创造性的实现的机会，但又不会牺牲性能和遇到潜在的不稳定性，因为 Ceph 的设计不允许出现单点故障。
本节描述了两种类型的实现：使用 CephFS 作为您的实例的后端以及 Ceph 与 Glance 的原生集成。对于本文，我假设您已有两个专用于 OpenStack 实例的服务器，并且两个服务器都能够挂载和同时访问 CephFS 磁盘。我还假设您已经有一个健康的、正在运行的 Ceph 集群。我的设置基于 Ubuntu Server Precise 12.04，但 CephFS 可用于许多 Linux 平台。
可在两个计算节点上运行以下命令，安装 CephFS 需要的组件如下：
sudo aptitude install ceph-fs-common ceph-fuse 复制代码 所有依赖包都已安装。您需要一个 Ceph 管理员密钥（用于测试之用途），我使用了管理员帐户，但在生产环境中应创建一个专门的用户。要获取密钥，可运行以下命令：
sudo ceph-authtool --print-key /etc/ceph/keyring.admin
AQDVGc5P0LXzIhAA5C020gbdrgypSFGUpG2cqQ 复制代码 要停止节点上的计算服务，可运行以下命令：
sudo service nova-compute stop; sudo service libvirt-bin stop 复制代码 将您的实例目录的内容复制到 CephFS 中，然后将它挂载到 nova-compute 所使用的位置：
sudo mount -t ceph «ip-of-ceph-mon1:6789,ip-of-ceph-mon-X:6789:/ \
/mnt/ -o name=admin,secret=AQDVGc5P0LXzIhAA5C020gbdrgypSFGUpG2cqQ== 复制代码 如果对基础镜像使用 QEMU Copy On Write (Qcow2) 格式，那么可以使用以下命令：
mkdir /mnt/_base && for i in $( ls /var/lib/nova/instances/_base/); \
do sudo qemu-img covert -O qcow2 $i /mnt/_base/$i; done
sudo cp -r /var/lib/nova/instances/instance-* /mnt 复制代码 现在可卸载 (/mnt) 并将 CephFS 卷重新挂载到正确的位置上：
sudo mount -t ceph «ip-of-ceph-mon1:6789,ip-of-ceph-mon-X:6789:/ \
/var/lib/nova/instances/ -o name=admin,secret=AQDVGc5P0LXzIhAA5C020gbdrgypSFGUpG2cqQ==
sudo chown nova. /var/lib/nova/instances; \
service libvirt-bin start; service nova-compute start 复制代码 瞧！您目前在两个计算节点之间已经拥有高度可用的共享存储，并且已经使得一些特性（比如迁移）或高可用性恢复场景成为可能。
下一节将介绍如何启动从第一个计算节点到第二个计算节点的迁移。
实时迁移您的实例 现在您已拥有实例的共享存储，可在节点之间启动一次实时迁移。如果希望减轻一个计算节点上的负载，迁移非常有用。一定要按照相关过程来启用实时迁移（请参见 参考资料，获取该信息的链接）。使用 Nova 列表获取您的实例 ID 并发起实时迁移：
nova live-migration 0a2419bf-9254-4e02-98d4-98ef66c43d43 compute-node-B 复制代码 经过一两秒后，这些实例应会在第二个计算节点上运行。
接下来看看您基础架构中的 Ceph 的另一个集成案例。
RADOS-Glance 集成 Glance 是一个镜像服务，能够对其镜像使用多个后端存储系统。编辑 /etc/glance/glance-api.conf 并更新以下配置选项，以便在 Glance 与 RADOS 之间实现集成：
default_store = rbd
rbd_store_user =
ceph-glance rbd_store_pool = glance-images 复制代码 接下来，创建一个 Ceph 池和用户：
sudo rados mkpool glance-images;
sudo ceph-authtool --create-keyring /etc/ceph/openstack/glance.keyring
sudo ceph-authtool --gen-key --name client.ceph-glance --cap mon 'allow r' \
--cap osd 'allow rwx pool=glance-images' /etc/ceph/openstack/glance.keyring
sudo ceph auth add client.ceph-glance -i /etc/ceph/openstack/rbd.keyring;
sudo chown glance:glance /etc/glance/rbd.keyring 复制代码 重新启动 Glance 服务：
cd /et/init.d; for i in $( ls glance-* ); do
sudo service $i restart; done 复制代码 您现在可以上传将在您的 Ceph 集群中直接分发和放置的镜像了！
结束语 我介绍了一个 Ceph 集群并描述了集群中的每个组件的作用。Ceph 提出的创新性方法不仅使建模高度可用并且可靠的存储架构成为可能，而且还支持轻松扩展您的基础架构。
Ceph 是一个活跃的项目，它已经非常成熟，被视为分布式存储解决方案的可靠选择。对于寻找高效而又完备的解决方案来管理数据的公司而言，该项目是一个创造性的答案：从保护到扩展存储产品，组织可以利用 Ceph 所公开的大量库和网关，为其客户提供新的产品和管理其数据的新方式。
/2 
京ICP备2020039040号
简书网举报电话：021-34700000
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡
