ceph
相关链接
- http://docs.ceph.com/docs/master/start/
- http://docs.ceph.com/docs/master/start/quick-start-preflight/
- http://download.ceph.com/tarballs/
简介
Ceph is a unified, distributed storage system designed for excellent performance, reliability and scalability.
Linux持续不断进军可扩展计算空间，特别是可扩展存储空间。Ceph 最近加入到 Linux 中令人印象深刻的文件系统备选行列，它是一个分布式文件系统，能够在维护 POSIX 兼容性的同时加入了复制和容错功能。
| 外文名 | Ceph |
| 性 质 | 分布式文件系统 |
| 属 于 | Linux PB 级 |
| 最 初 | 关于存储系统的 PhD 研究项目 |
Ceph是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式文件系统。
其命名和UCSC（Ceph 的诞生地）的吉祥物有关，这个吉祥物是 “Sammy”，一个香蕉色的蛞蝓，就是头足类中无壳的软体动物。这些有多触角的头足类动物，是对一个分布式文件系统高度并行的形象比喻。
Ceph 最初是一项关于存储系统的 PhD 研究项目，由 Sage Weil 在 University of California, SantaCruz（UCSC）实施。
开发目标
简单定义为以下3项：
-
可轻松扩展到数 PB 容量
-
支持多种工作负载的高性能（每秒输入/输出操作[IOPS]和带宽）
-
高可靠性
但是，这些目标之间会互相竞争（例如，可扩展性会降低或者抑制性能或者影响可靠性）。Ceph 的设计还包括保护单一点故障的容错功能，它假设大规模（PB 级存储）存储故障是常见现象而不是例外情况。
它的设计并没有假设某种特殊工作负载，但包括了适应变化的工作负载，并提供最佳性能的能力。它利用 POSIX 的兼容性完成所有这些任务，允许它对当前依赖 POSIX 语义（通过以 Ceph 为目标的改进）的应用进行透明的部署。
系统架构
Ceph 生态系统架构可以划分为四部分：
-
Clients：客户端（数据用户）
-
cmds：Metadata server cluster，元数据服务器（缓存和同步分布式元数据）
-
cosd：Object storage cluster，对象存储集群（将数据和元数据作为对象存储，执行其他关键职能）
-
cmon：Cluster monitors，集群监视器（执行监视功能）
作为分布式文件系统，其能够在维护 POSIX 兼容性的同时加入了复制和容错功能。从 2010 年 3 月底，您可以在Linux 内核（从2.6.34版开始）中找到 Ceph 的身影，作为Linux的文件系统备选之一，Ceph.ko已经集成入Linux内核之中。虽然目前Ceph 可能还不适用于生产环境，但它对测试目的还是非常有用的。
Ceph 不仅仅是一个文件系统，还是一个有企业级功能的对象存储生态环境。
现在，Ceph已经被集成在主线 Linux 内核中，但只是被标识为实验性的。在这种状态下的文件系统对测试是有用的，但是对生产环境没有做好准备。但是考虑到Ceph 加入到 Linux 内核的行列，不久的将来，它应该就能用于解决海量存储的需要了。
一些开源的云计算项目已经开始支持Ceph，事实上Ceph是目前OpenStack生态系统中呼声最高的开源存储解决方案。这些项目都支持通过libvirt调用Ceph作为块设备进行读写访问。
分布式文件系统
分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。分布式文件系统的设计基于客户机/服务器模式。一个典型的网络可能包括多个供多用户访问的服务器。另外，对等特性允许一些系统扮演客户机和服务器的双重角色。例如，用户可以“发表”一个允许其他客户机访问的目录，一旦被访问，这个目录对客户机来说就像使用本地驱动器一样，下面是三个基本的分布式文件系统。
计算机通过文件系统管理、存储数据，而信息爆炸时代中人们可以获取的数据成指数倍的增长，单纯通过增加硬盘个数来扩展计算机文件系统的存储容量的方式，在容量大小、容量增长速度、数据备份、数据安全等方面的表现都差强人意。分布式文件系统可以有效解决数据的存储和管理难题：将固定于某个地点的某个文件系统，扩展到任意多个地点/多个文件系统，众多的节点组成一个文件系统网络。每个节点可以分布在不同的地点，通过网络进行节点间的通信和数据传输。人们在使用分布式文件系统时，无需关心数据是存储在哪个节点上、或者是从哪个节点从获取的，只需要像使用本地文件系统一样管理和存储文件系统中的数据。
文件系统最初设计时，仅仅是为局域网内的本地数据服务的。而分布式文件系统将服务范围扩展到了整个网络。不仅改变了数据的存储和管理方式，也拥有了本地文件系统所无法具备的数据备份、数据安全等优点。判断一个分布式文件系统是否优秀，取决于以下三个因素：
-
数据的存储方式，例如有1000万个数据文件，可以在一个节点存储全部数据文件，在其他N个节点上每个节点存储1000/N万个数据文件作为备份；或者平均分配到N个节点上存储，每个节点上存储1000/N万个数据文件。无论采取何种存储方式，目的都是为了保证数据的存储安全和方便获取。
-
数据的读取速率，包括响应用户读取数据文件的请求、定位数据文件所在的节点、读取实际硬盘中数据文件的时间、不同节点间的数据传输时间以及一部分处理器的处理时间等。各种因素决定了分布式文件系统的用户体验。即分布式文件系统中数据的读取速率不能与本地文件系统中数据的读取速率相差太大，否则在本地文件系统中打开一个文件需要2秒，而在分布式文件系统中各种因素的影响下用时超过10秒，就会严重影响用户的使用体验。
-
数据的安全机制，由于数据分散在各个节点中，必须要采取冗余、备份、镜像等方式保证节点出现故障的情况下，能够进行数据的恢复，确保数据安全。
系统分类
网络文件系统
(NFS) 最早由Sun微系统公司作为TCP/IP网上的文件共享系统开发。Sun公司估计大约有超过310万个系统在运行NFS，大到大型计算机、小至PC机，其中至少有80%的系统是非Sun平台。
Andrew系统
(AFS) 结构与NFS相似，由卡内基·梅隆大学信息技术中心(ITC)开发、现由前ITC职员组成的Transarc公司负责开发和销售。AFS较NFS有所增强。
KASS系统
KASS File System（简称KFS）是开始软件自主研发基于JAVA的纯分布式文件系统，功能类似于DFS、GFS、Hadoop，通过HTTP WEB为企业的各种信息系统提供底层文件存储及访问服务，搭建企业私有云存储服务平台。
DFS系统
(DFS) 是AFS的一个版本，作为开放软件基金会(OSF)的分布分布式文件系统
分布式文件系统式计算环境(DCE)中的文件系统部分。
如果文件的访问仅限于一个用户，那么分布式文件系统就很容易实现。可惜的是，在许多网络环境中这种限制是不现实的，必须采取并发控制来实现文件的多用户访问，表现为如下几个形式：
-
只读共享 任何客户机只能访问文件，而不能修改它，这实现起来很简单。
-
受控写操作 采用这种方法，可有多个用户打开一个文件，但只有一个用户进行写修改。而该用户所作的修改并不一定出现在其它已打开此文件的用户的屏幕上。
-
并发写操作 这种方法允许多个用户同时读写一个文件。但这需要操作系统作大量的监控工作以防止文件重写，并保证用户能够看到最新信息。这种方法即使实现得很好，许多环境中的处理要求和网络通信量也可能使它变得不可接受。
NFS和AFS的区别
NFS和AFS的区别在于对并发写操作的处理方法上。当一个客户机向服务器请求一个文件(或数据库记录)，文件被放在客户工作站的高速缓存中，若另一个用户也请求同一文件，则它也会被放入那个客户工作站的高速缓存中。当两个客户都对文件进行修改时，从技术上而言就存在着该文件的三个版本(每个客户机一个，再加上服务器上的一个)。有两种方法可以在这些版本之间保持同步：
无状态系统 在这个系统中，服务器并不保存其客户机正在缓存的文件的信息。因此，客户机必须协同服务器定期检查是否有其他客户改变了自己正在缓存的文件。这种方法在大的环境中会产生额外的LAN通信开销，但对小型LAN来说，这是一种令人满意的方法。NFS就是个无状态系统。
回呼(Callback)系统 在这种方法中，服务器记录它的那些客户机的所作所为，并保留它们正在缓存的文件信息。服务器在一个客户机改变了一个文件时使用一种叫回叫应答(callbackpromise)的技术通知其它客户机。这种方法减少了大量网络通信。AFS(及OSFDCE的DFS)就是回叫系统。客户机改变文件时，持有这些文件拷贝的其它客户机就被回叫并通知这些改变。
无状态操作在运行性能上有其长处，但AFS通过保证不会被回叫应答充斥也达到了这一点。方法是在一定时间后取消回叫。客户机检查回叫应答中的时间期限以保证回叫应答是当前有效的。回叫应答的另一个有趣的特征是向用户保证了文件的当前有效性。换句话说，若一个被缓存的文件有一个回叫应答，则客户机就认为文件是当前有效的，除非服务器呼叫指出服务器上的该文件已改变了。
发表评论