新钛云服已为您服务1020天

文档说明

HDFS的缩放限制。我们描述Ceph及其元素，并提供安装可与Hadoop一起使用的演示系统的说明。

Hadoop已经成为一个非常流行的大规模数据分析平台。这种流行对Hadoop的可伸缩性和功能提出了更高的要求，并揭示了其底层文件系统的一个重要架构限制：HDFS只提供一个名称节点，该节点必须将整个文件系统名称空间存储在主内存中。这就对HDFS可以存储的元数据的数量，特别是文件的数量有了严格的限制。

在Hadoop用户和开发人员社区中，单名称节点的限制是公认的。大型集群经常在名称节点上耗尽容量来跟踪新文件，即使数据节点上有足够的存储容量。对于需要相对大量的元数据操作（如打开和关闭文件）的工作负载，单名称节点还会造成单点故障和潜在的性能瓶颈。

ceph特性

Ceph是一个基于对象的并行文件系统，具有许多特性，使其成为Hadoop的理想候选存储系统：

• Ceph的可伸缩元数据服务器可以分布在数百个节点上，同时使用动态子树分区提供一致、可靠、高性能的元数据服务，具有近乎线性的可伸缩性。

• 每个文件都可以指定自己的条带化策略和对象大小。灵活的条带化策略和对象大小是Hadoop工作负载的重要调整参数

• 数据存储在多达10000个节点上，这些节点导出具有对象ID的平坦命名空间的单个可靠对象服务,这与亚马逊的简单存储服务不同。存储集群大小的变化导致数据的自动（快速）故障恢复和重新平衡，而不中断服务和最小数据移动，使Ceph适合于非常大的部署。

• 由于计算出的数据放置与分配表相反，ing数据放置、故障节点和恢复状态具有非常紧凑的表示形式，并且在Ceph的每个部分中都是已知的。与HDFS一样，Hadoop的调度器可以利用这些信息将映射放置在数据所在的位置附近。

• Ceph是一个开源项目(ceph.newdream.net网站写在C++和C，作为一个博士研究项目在加州大学四年前开始，并一直处于严重发展至今。用于将Ceph集成到Hadoop中的Hadoop模块自0.12版以来一直在开发中，Hadoop还可以通过其POSIX I/O接口访问Ceph，使用ioctl调用获取数据位置信息。

• 由于Ceph被设计成一个通用文件系统（例如，它提供了一个Linux内核客户机，因此Ceph文件系统可以挂载），如果它能够很好地支持Hadoop工作负载，那么它也可以作为其他存储需求的通用解决方案。

Ceph

Ceph在2005年规定的以下目标：

• 一到数千个硬盘上的PB数据。

• TB/秒一到数千个硬盘上的总吞吐量尽可能快地输出数据。

• 数十亿个文件组织在每个目录中的一到数千个文件中。

• 文件大小从字节到兆字节不等。

• 元数据访问时间（微秒）。

• 从数千个客户机到。

• 不同目录中的不同文件。

• 同一目录下的不同文件。

• 同一文件。

• 中等性能本地数据访问。

• 广域通用通道

这种文件系统面临的挑战是，它需要能够处理巨大的文件和目录，协调数千个磁盘的活动，提供大规模元数据的并行访问，处理科学和通用工作负载，在规模上进行身份验证和加密，以及因频繁使用而动态增长或收缩设备停用、设备故障和群集扩展。不能因为磁盘故障或空间不足就关闭系统。

Ceph是一个基于对象的并行文件系统，其设计基于两个关键思想。第一个关键思想是基于对象的存储，它将传统的文件系统体系结构分为客户机组件和存储组件。

存储组件在本地管理磁盘调度和布局，使客户机和服务器不再需要低级别的每磁盘详细信息，并提高了可扩展性。这种设计允许客户机通过高级接口与存储节点通信，并以对象的形式管理数据，对象是比512字节块大得多的数据块。

SCSI对象存储设备（OSD）命令集的T10标准是对象接口规范的一个示例。Ceph使用并显著扩展了osd的概念。出于所有实际目的，请将Ceph OSD视为在集群节点上运行并使用本地文件系统存储数据对象的进程。

Ceph设计的第二个关键思想是数据和元数据的分离。数据的管理与元数据的管理有着根本的区别：文件数据存储的并行性很低，主要受网络基础设施的限制。元数据管理要复杂得多，因为层次目录结构带来了相互依赖性（例如，POSIX访问权限依赖于父目录），元数据服务器必须保持文件系统的一致性。

元数据服务器必须承受繁重的工作负载：所有文件系统操作中有30–80%涉及元数据，因此在许多小型元数据项上有大量事务遵循各种使用模式。因此，良好的元数据性能对整个系统性能至关重要。流行的文件和目录是常见的，并发访问可以压倒许多方案。

Ceph设计的三个独特方面是：

• 在单独的元数据服务器（MDS）集群中进行分布式元数据管理，该集群使用动态子树分区来避免元数据访问热点，并对非拜占庭故障具有鲁棒性；

• 计算伪随机数据放置，允许在整个系统中轻松共享非常紧凑的状态（压缩）

• 分布式对象存储，使用智能OSD集群，形成可自主智能操作的可靠对象存储（RADOS）

  

• 在单独的元数据服务器（MDS）集群中进行分布式元数据管理，该集群使用动态子树分区来避免元数据访问热点。

• 计算伪随机数据放置，允许在整个系统中轻松共享非常紧凑的状态（压缩）以及分布式对象存储，使用智能OSD集群，形成可自主智能操作的可靠对象存储（RADOS）。

Client

用户或应用程序通过客户端组件与Ceph交互。客户端公开了一个POSIX文件系统接口。该接口还支持用于高性能计算的POSIX I/O扩展的一个子集，包括POSIX open命令的Oïu LAZY标志，该标志允许注重性能的应用程序管理自己的一致性[15]。

Ceph有一个用户级客户端和一个内核客户端。用户级客户端要么直接链接到应用程序，要么通过FUSE使用。内核客户机现在可以在主线Linux内核中使用（从2.6.34开始），并允许装载Ceph文件系统。

对于客户端如何与Ceph系统的其余部分交互的一个简单示例，请考虑客户端打开一个文件/foo/bar进行读取：客户端向MDS发送一条“openforread”消息。MDS从适当的osd读取目录/foo（除非该目录已经缓存在内存中），并将读取“/foo/bar”的功能返回给客户端。

然后，客户机计算文件的数据对象的名称和位置，并从相应的OSD读取数据。最后，客户机通过向MDS放弃该功能来关闭文件。请记住，Ceph的这些不同组件之间的所有消息对应用程序都是不可见的：应用程序只需发出POSIX open、read和close命令。

客户机是Ceph中元数据与数据相遇的唯一地方：MDS返回的功能包含inode号、复制因子和有关文件分条策略的信息，这些信息可以是特定于文件的，并在文件创建时设置。条带化策略、inode编号和偏移量允许客户机派生对象标识符。一个简单的散列函数将对象标识符（OID）映射到一个放置组，一组存储对象及其所有副本的OSD。

对于存储任何给定OSD上存储的对象副本的OSD数量，有数量有限的放置组来创建上限。这个数字越高，多个节点的故障导致数据丢失的可能性就越高。例如，如果每个OSD与其他每个OSD都有副本关系，那么整个集群中只有三个节点发生故障，就可以清除存储在所有三个副本上的数据。放置组通过CRUSH映射到osd，CRUSH是一个一致的散列函数，它将以下参数作为参数：

（1）放置组ID；

（2）复制因子；

（3）当前集群映射（请参阅下面的RADOS部分）

（4）放置规则（请参阅下面的CRUSH部分）。CRUSH然后返回OSD id的有序列表，每个副本一个。客户机选择列表上的第一个OSD（“主”）作为对象的位置。

METADATA SERVICE (MDS)

Ceph提供了一组元数据服务器，这些服务器使用动态子树分区不断地负载自身平衡。管理命名空间层次结构的责任是在几十个甚至数百个元数据服务器之间自适应、智能地分布。MDS集群适应性的关键是Ceph元数据项非常小，并且可以快速移动。如果Ceph使用许多文件系统的方法，那么这是不可能的，在这种方法中，文件字节流使用分配表映射到磁盘块。

每个目录都存储为对象。Inodes嵌入目录中，并与相应的目录项（文件名）一起存储。这个组织优化了列出目录和检索每个文件的元数据的公共访问模式。嵌入式inodes使硬链接的管理变得复杂，但事实证明，硬链接很少见，并且显示有用的位置属性（大多数硬链接指的是同一个或并行目录中的条目）。

要启用故障恢复，MDS日志元数据将更新到OSD。日志跨大型对象进行条带化，从而导致高效、连续的写入。所有已更新和记录但未作为更新目录对象写入的内存元数据都会被标记为脏的，并固定到主内存，直到日记账中的相应条目必须从日志的尾部修剪。日志可以增长得非常大（数百兆字节）。

到需要修剪更新的时候，许多元数据更新已经被后续更新失效，并且可以合并为少量目录更新。通过这种方法，MDS充当智能元数据缓存，将小元数据项的随机更新转换为高效的数据I/O。

文件系统的命名空间沿目录子树跨MDS节点集群分区，如图3所示。这种动态子树分区确保子树的分布尽可能粗糙，以保持局部性（通常沿子树对齐），并且它不断地适应以保持MDS工作负载的平衡。

随着工作负载的变化，子树在MDSE之间迁移。为了缓解热点，在多个MDSE上复制大量读取的目录，以便可以限制了解特定副本的客户端数量。大目录或重写目录被分散以用于负载分配和存储。即使是极端工作负载变化，MDS的重新平衡通常在几秒钟内完成。客户机在与MDS通信时，都会收到相关分区更新的通知。

可靠的自主分布式对象存储（RADOS）

Ceph中的数据存储在一个分布式对象存储中，该存储可以从几十个对象存储设备（osd）扩展到几十万个对象存储设备（osd）。RADOS也可用作独立系统。事实上，Ceph发行版包括一个简单的网关，一个fastcgi守护进程，它实现了Amazon针对RADOS的s3api。

发起方在Ceph的例子中，客户机和MDS将对象存储集群视为一个具有扁平名称空间（称为RADOS）的单一逻辑对象存储。RADOS通过显著扩展t10scsi-OSD概念来实现其可伸缩性：t10osd只响应读写操作，而Ceph-OSD则积极地与对等机协作进行故障检测、数据复制和恢复。

为了引导请求，发起者使用从RADOS接收的集群映射。非常紧凑的集群映射包含有关参与osd的信息、它们的状态和CRUSH映射功能（参见下面的CRUSH部分）。集群映射的主副本由分布式监视服务管理，该服务由一组使用Paxos算法保持一致性的监视器组成。

当OSD向monitor服务发出新故障或集群扩展的警报时，monitor会用集群映射的更新版本进行响应，然后在整个集群中进行延迟传播。群集映射的总大小在兆字节范围内（取决于群集的大小）。通过只在集群映射版本之间通信增量并将它们与现有的inter-OSD消息相结合，可以减少传播开销。

与其他并行文件系统不同，复制由OSD而不是客户端管理，这将复制带宽开销转移到OSD集群，简化客户端协议，并在混合读/写工作负载中提供完全一致的语义。RADOS使用主拷贝复制的变体来管理数据的复制。

如上客户机部分所述，副本存储在放置组中。每个放置组都包含一个主OSD，它将所有请求序列化到放置组。在写操作的情况下，主进程将请求转发给放置组的其他osd。在其他副本应用它们的副本之后，主副本在本地应用写操作。只有这样，客户机才会收到来自主服务器的确认。

写入分两个阶段应用，如图4所示。这种两阶段方法将用于与其他客户机共享的写入与用于持久性的写入分离开来，并使共享数据非常快速。在所有副本的内存中复制数据之后，客户机从主服务器接收ack。

此时，客户机的缓冲区缓存中仍有数据。一旦数据提交到所有副本上的磁盘上，主副本就会向客户机发送一个提交，确认数据现在是持久的。然后，客户机可以从其缓冲区缓存中删除数据。

默认情况下，osd使用Btrfs作为本地文件系统（但ext3也可以）。使用“写时拷贝”异步写入数据，这样就可以完全回滚不成功的写入操作。每个OSD都维护其参与的每个放置组的对象版本日志。如果一个OSD失败，其余的OSD可以通过比较这些日志来快速识别过时或丢失的对象；间歇性失败的OSD可以快速恢复。

OSD使用心跳消息监视同一放置组中其他OSD的状态，心跳消息通常依赖于复制流量。发现无响应OSD的OSD会向监视服务发出警报，并接收一个新的群集映射，该映射将无响应OSD标记为关闭。

其他OSD暂时接管了无响应OSD可能拥有的任何主要角色。如果在配置的时间内OSD没有恢复，monitor服务将发出另一个集群映射，将其标记为out，其他一些OSD将被选为新的主OSD，并开始重新建立完整的副本。

总之，Ceph的故障检测和恢复是完全分布式的，monitor服务仅用于更新集群映射的主副本。监视服务不会将这些更新广播到群集。相反，集群映射更新是由osd使用具有有限开销的流行式传播进行通信的。此过程用于响应所有群集映射更新，无论是由于OSD故障、群集收缩还是扩展。osd总是协作实现最新集群映射中指定的数据分布，同时保持读写访问的一致性。

使用CRUSH进行数据分发

MDS中元数据项的小尺寸和RADOS中集群映射的紧凑性是通过CRUSH（可伸缩散列下的受控复制）实现的。Ceph使用这个散列函数来计算数据的位置，而不是使用分配表，分配表可能会变得非常庞大和笨拙。

CRUSH是集群映射的一部分，其行为类似于一个一致的散列函数，即节点的失败、移除和添加会导致接近最小的对象迁移，从而重新建立接近均匀的分布。如客户机部分所述，CRUSH使用层次结构的集群映射和放置规则作为附加输入，将放置组ID映射到osd的有序列表。OSD列表的长度取决于复制因子。列表中第一个可用的OSD是主OSD。

CRUSH输出的任何列表都满足放置规则指定的约束。这些规则是在集群映射上定义的，管理员可以根据故障域（例如机架或托架）分层结构（因为它们通常共享相同的电路或电源）。因此，放置规则可以防止将两个副本放置在同一故障域中。这种在数据放置期间对故障域的了解对于非常大的存储系统的总体数据安全至关重要，因为在这些存储系统中，相关故障很常见。

安装和配置Ceph

Ceph安装至少需要一个监视器、一个OSD和一个元数据服务器。这些节点可能都在同一个节点上，尽管使用其他节点可以获得更高的性能、健壮性和容量。这里，我们将介绍多节点Ceph安装的配置。对于单节点安装，调整此示例以在同一节点上启动每个守护进程中的一个。

我们假设的集群有10个节点，主机名为node0到node9。每个节点在/dev/sdb1和/dev/sdb2处都有一个未使用的原始分区。我们将按如下方式配置节点：

• 三台监视器，位于节点0–2上

• 三个MDSE，在节点0–2上

• 8个OSD，位于节点2–9

多节点集群可以使用更少的硬件。监视器的数量应该总是奇数。对于健壮性，两个mdse（活动和备用）就足够了。对于数据复制，两个osd就足够了。

我们使用一个名为setupuser的文件系统安装程序用户，由于需要格式化分区，该用户的公钥将访问权限授予所有节点上的setupuser和存储节点上的根帐户。这个密钥应该被密码锁定，并与SSH代理或等效的会话管理器一起使用它将只用于设置和拆除Ceph集群。但是，如果在以后的Hadoop设置中使用相同的帐户和密钥，则由于Hadoop的无密码SSH要求，该密钥不能有密码。

安装CEPH守护程序

首先，我们在每个节点上安装必备包。对于FedoraCore2或Ubuntu 9.10，运行以下命令：

#Ubuntu 9.10

apt get install AutoConfig automake libtool libboost dev libedit dev libssl dev

#Fedora12

yum install rpm build fuse-devel libtool libtool ltdl-devel boost devel libedit devel openssl devel gcc-c++btrfs progs

其次，我们配置和构建源代码。为了简单起见，我们假设您正在共享NFS目录中构建源，在所有节点上都可见。我们将在构建树中运行守护进程，而不安装。我们还将创建ceph.conf公司源树中的配置文件。

为了避免依赖NFS，您可以在每个节点上安装Ceph，或者使用Debian包安装Ceph，在这种情况下，您还需要部署ceph.conf至/etc/ceph/ceph.conf在每个节点上，而不是将其保留在源上。

cd<ceph directory>cxfrags=“-g”。/configure make

集群初始化脚本检测到这些文件何时耗尽本地目录而不是完全安装；因此无需在配置文件中设置Ceph可执行文件目录。如果您确实想在每个节点上安装本地设备，请运行sudo make install after make make make。这将Ceph二进制文件放入/usr/local/bin和/usr/local/sbin（必要时）。

Ceph的配置存储在一个文件ceph.conf中，在所有节点上都是相同的。在配置文件中，每个守护程序都有一个部分，每种类型的守护程序都有一个公共部分。例如，所有监视器的公共配置参数都放在[mon]部分，每个监视器的设置都放在[mon0]、[mon1]中，依此类推。

为了记录日志和其他本地数据，请在所有节点上创建一个本地目录/data，作为setupuser可读写。然后创建src/ceph。配置如下。

[global]  user = setupuser; where the mdses and osds keep their secret encryption keys  keyring = /data/keyring.$name
; monitors
[mon] ;Directory for monitor files  mon data = /data/mon$id
[mon0]  host = node0 mon addr = 192.168.0.100:6789
[mon1]  host = node1 mon addr = 192.168.0.101:6789
[mon2]   host = node2  mon addr = 192.168.0.102:6789
; metadata servers
[mds]
[mds0]  host = node0 [mds1]  host = node1 [mds2]  host = node2
; OSDs
[osd] ; osd data is where the btrfs volume will be mounted;; it will be created if absent  osd data = /data/osd$id ; osd journal is the regular file or device to be used for journaling osd journal = /dev/sdb2 ; The ‘btrfs devs’ partition will be formatted as btrfs.  btrfs devs = /dev/sdb1  host = node$id
[osd2] [osd3] [osd4]
[ . . .}
[osd9]

注意，通过设置host=node$id，并实例化osd2到9（跳过0和1），我们可以利用连续的主机名，避免显式地为每个OSD设置主机名。

OSD日志记录在原始分区上比在常规文件上更有效。如果使用原始分区，setupuser应该是osd上磁盘组的成员，这样它就可以对设备进行写访问。接下来，创建并启动文件系统，如下所示。-allhosts标志使每个命令在中指定的所有节点上工作ceph.conf公司，通过SSH；因此，应该为每个OSD配置无密码根SSH。根帐户在每个OSD上的授权密钥应具有setupuser的公钥。分发公钥后，运行以下命令：

./mkcephfs -c ceph.conf --allhosts --mkbtrfs
./init-ceph -c ceph.conf --allhosts start

-mkbtrfs将btrfs dev格式化为btrfs；如果希望改用其他文件系统或常规目录，请确保生成的文件系统或基础文件系统已启用扩展属性（ext3的用户\xattr）。

如果您需要停止（./init ceph-c）ceph.conf公司-所有主机停止）并重新启动Ceph服务，以前服务器会话中的日志目录可能会导致挂载失败。清除它们可以防止此问题。此时，Ceph与本地文件系统的任何其他部分一样可用。

Using Hadoop with Ceph

有两种方法可以将Ceph用作Hadoop的文件系统：

（1）如前一节末尾所述装入Ceph，并将其用作Hadoop中的本地文件系统（file:///mnt/Ceph）；

（2）使用Hadoop-6253 JIRA中提供的补丁修补Hadoop内核。这使用Ceph的用户级客户机。

启动Hadoop时，不要使用bin/start-全部.sh，因为这将启动HDFS。仅启动所需的守护程序（例如bin/Start)

总结

自从Ceph内核客户端被拉入Linux内核2.6.34以来，人们对Ceph的兴趣大大增加。Ceph是目前唯一的开放源码（LGPL许可）并行文件系统，它提供了一种分布式元数据服务，该服务可线性扩展到至少128个元数据服务节点，支持POSIX I/oapi和语义，并且能够在不中断服务的情况下以低开销进行扩展和收缩。

最后一点允许Ceph部署在虚拟环境中，比如Amazon的EC2云服务，在那里频繁而显著的集群大小变化是常态。总体来说，Ceph解决了HDFS的一些缺点，即HDFS有限的名称节点可伸缩性、心跳开销和高度专业化的文件访问语义。

在我们写这篇文章时，Ceph仍然是实验性的，还没有为生产环境做好准备。Sage-Weil、Yehuda-Sadeh和Gregory-Farnum正全天致力于Ceph的制作，每2到4周就会有新的版本发布。我们希望这篇文章能够鼓励人们参与到这项工作中来，用他们关心的工作负载试用Ceph，并报告任何bug、性能问题或bug/性能修复。

了解新钛云服

新钛云服荣膺第四届FMCG零售消费品行业CIO年会「年度数字化服务最值得信赖品牌奖」

新钛云服三周岁，公司月营收超600万元，定下百年新钛的发展目标

当IPFS遇见云服务|新钛云服与冰河分布式实验室达成战略协议

新钛云服正式获批工信部ISP/IDC(含互联网资源协作)牌照

深耕专业，矗立鳌头，新钛云服获千万Pre-A轮融资

新钛云服，打造最专业的Cloud MSP+，做企业业务和云之间的桥梁

新钛云服一周年，完成两轮融资，服务五十多家客户

上海某仓储物流电子商务公司混合云解决方案

往期技术干货

Kubernetes扩容到7,500节点的历程

低代码开发，全民开发，淘汰职业程序员！

国内主流公有云VPC使用对比及总结

万字长文：云架构设计原则|附PDF下载

刚刚，OpenStack 第 19 个版本来了，附28项特性详细解读！

Ceph OSD故障排除|万字经验总结

七个用于Docker和Kubernetes防护的安全工具

运维人的终身成长，从清单管理开始|万字长文！

OpenStack与ZStack深度对比：架构、部署、计算存储与网络、运维监控等

什么是云原生？

IT混合云战略：是什么、为什么，如何构建？

点????分享

戳????再看