Ceph与Gluster之开源存储的对比
一、Ceph与Gluster之开源存储的对比
一、Ceph与Gluster的原理对比
Ceph和Gluster是Red Hat旗下的成熟的开源存储产品,Ceph与Gluster在原理上有着本质上的不同。
1、Ceph
Ceph基于一个名为RADOS的对象存储系统,使用一系列API将数据以块(block)、文件(file)和对象(object)的形式展现。Ceph存储系统的拓扑结构围绕着副本与信息分布,这使得该系统能够有效保障数据的完整性。
2、Gluster
Gluster描述为Scale-out NAS和对象存储系统。它使用一个Hash算法来计算数据在存储池中的存放位置,这点跟Ceph很类似。在Gluster中,所有的存储服务器使用Hash算法完成对特定数据实体的定位。于是数据可以很容易的复制,并且没有中心元数据分布式存储无单点故障且不易造成访问瓶颈,这种单点在早期Hadoop上出现,对性能和可靠性造成较大影响。
二、Ceph文件系统架构
RADOS(Reliable, Autonomic、Distributed Object Store)是Ceph系统的基础,这一层本身就是一个完整的对象存储系统,包括Cehp的基础服务(MDS,OSD,Monitor),所有存储在Ceph系统中的用户数据事实上最终都是由这一层来存储的。而Ceph的高可靠、高可扩展、高性能、高自动化等等特性本质上也是由这一层所提供的。
RADOS在物理形态上由大量的存储设备节点组成,每个节点拥有自己的硬件资源(CPU、内存、硬盘、网络),并运行着操作系统和文件系统。基础库librados是对RADOS进行抽象和封装,并向上层提供不同API,以便直接基于RADOS进行原生对象或上层对象、块和文件应用开发。特别要注意的是,RADOS是一个对象存储系统,因此,基于librados实现的API也只是针对对象存储功能的。
RADOS所提供的原生librados API包括C和C++两种。Librados在部署上和基于其上开发的应用位于同一台机器。应用调用本机上的librados API,再由后者通过Socket与RADOS集群中的节点通信并完成各种操作。
这一层包括了RADOS GW(RADOS Gateway)、 RBD(Reliable Block Device)和Ceph FS(Ceph File System)三个高层存储应用接口,其作用是在librados库的基础上提供抽象层次更高、更便于应用或客户端使用的上层接口。
RADOS GW是一个提供与Amazon S3和Swift兼容的RESTful API的Gateway,以供相应的对象存储应用开发使用。RADOS GW提供的API抽象层次更高,但功能则不如librados强大。因此,开发者应针对自己的需求选择使用。
RBD则提供了一个标准的块设备接口,常用于在虚拟化的场景下为虚拟机创建Volume。如前所述,Red Hat已经将RBD驱动集成在KVM/QEMU中,以提高虚拟机访问性能。
CephFS是一个POSIX兼容的分布式文件系统。目前还处在开发状态,因而Ceph官网并不推荐将其用于生产环境中。
Ceph Client是基于Fuse层(User SpacE)和VFS文件系统开发,兼容Posix接口标准。在Ceph存储系统中,Ceph Metadata Daemon 提供了元数据服务器,而Ceph Object Storage Daemon 提供了数据和元数据的实际存储。
Ceph对DFS、Block和Object数据写入和读取,都需Client利用Crush算法(负责集群中的数据放置和检索的算法)完成存储位置计算和数据组装。Ceph架构详细介绍请参考“Ceph存储架构深度分析”文章。
三、Gluster FS系统架构
Gluster FS由Brick Server、Client和NAS网关组成(用来访问存储服务,但是Client只支持Linux,其他系统需要NAS网关提供存储服务),三者可以部署到同一个物理服务器上。NAS网关通过启动GLFS Client提供存储服务。
每个文件通过一定策略分不到不同的Brick Server上,每个Brick Server通过运行不同进程处理数据请求,文件以原始格式以EXT、XFS和ZFS文件系统的保存在本地。
卷(Block)通过位于Client或NAS网关上的卷管理器来提供服务,由卷管理器管理集群中的多个Brick Server。存储节点(Brick Server)对外提供的服务目录称作Brick,一个Brick对应一个本地文件系统,Gluster FS以Brick为单位管理存储。
GlusterFS采用模块化、堆栈式的架构,可通过灵活的配置支持高度定制化的应用环境,比如大文件存储、海量小文件存储、云存储、多传输协议应用等。每个功能以模块形式实现,然后以积木方式进行简单的组合,即可实现复杂的功能。比如,Replicate模块可实现RAID1,Stripe模块可实现RAID0,通过两者的组合可实现RAID10和RAID01,同时获得高性能和高可靠性。
各个功能模块就是一个Xlator(translator),不同的xlator在初始化后形成树,每个xlator为这棵树中的节点动态加载,同一个xlaror可以同时在Client/Brick Server上加载。GlusterFS系统详细架构请参看“Gluster FS分布式文件系统”文章。
四、GlusterFS和Ceph对比
1、GlusterFS和Ceph的简单对比
GlusterFS和Ceph是两个灵活的存储系统,有着相似的数据分布能力,在云环境中表现非常出色。在尝试了解GlusterFS与Ceph架构之后,我们来看看两者之间的简单对比。
2、GlusterFS和Ceph的共同点
纵向扩展和横向扩展:在云环境中,必须可以很容易地向服务器添加更多存储空间以及扩展可用存储池。Ceph和GlusterFS都可以通过将新存储设备集成到现有存储产品中,满足扩充性能和容量的要求。
高可用性:GlusterFS和Ceph的复制是同时将数据写入不同的存储节点。这样做的结果是,访问时间增加,数据可用性也提高。在Ceph中,默认情况下将数据复制到三个不同的节点,以此确保备份始终可用性。
商品化硬件:GlusterFS和Ceph是在Linux操作系统之上开发的。因此,对硬件唯一的要求是这些产品具有能够运行Linux的硬件。任何商品化硬件都可以运行Linux操作系统,结果是使用这些技术的公司可以大大减少在硬件上的投资——如果他们这样做的话。然而,实际上,许多公司正在投资专门用于运行GlusterFS或Ceph的硬件,因为更快的硬件可以更快地访问存储。
去中心化:在云环境中,永远不应该有中心点故障。对于存储,这意味着不应该用一个中央位置存储元数据。GlusterFS和Ceph实现了元数据访问去中心化的解决方案,从而降低了存储访问的可用性和冗余性。
3、GlusterFS与Ceph的差异
GlusterFS是来自Linux世界的文件系统,并且遵守所有Portable Operating System Interface标准。尽管你可以将GlusterFS轻松集成到面向Linux的环境中,但在Windows环境中集成GlusterFS很难。
Ceph是一种全新的存储方法,对应于Swift对象存储。在对象存储中,应用程序不会写入文件系统,而是使用存储中的直接API访问写入存储。因此,应用程序能够绕过操作系统的功能和限制。如果已经开发了一个应用程序来写入Ceph存储,那么使用哪个操作系统无关紧要。结果表明Ceph存储在Windows环境中像在Linux环境中一样容易集成。
基于API的存储访问并不是应用程序可以访问Ceph的唯一方式。为了最佳的集成,还有一个Ceph块设备,它可以在Linux环境中用作常规块设备,使你可以像访问常规Linux硬盘一样来使用Ceph。Ceph还有CephFS,它是针对Linux环境编写的Ceph文件系统。
4、GlusterFS与Ceph的速度对比
GlusterFS存储算法更快,并且由于GlusterFS以砖组织存储的方式实现了更多的分层,这在某些场景下(尤其是使用非优化Ceph)可能导致更快的速度。另一方面,Ceph提供了足够的定制功能来使其与GlusterFS一样快。
5、GlusterFS与Ceph的应用
Ceph访问存储的不同方法使其成为更流行的技术。更多的公司正在考虑Ceph技术而不是GlusterFS,而且GlusterFS仍然与Red Hat密切相关。例如,SUSE还没有GlusterFS的商业实施,而Ceph已经被开源社区广泛采用,市场上有各种不同的产品。在某种意义上来说,Ceph确实已经胜过GlusterFS。
Ceph与Gluster之开源存储的对比的更多相关文章
- Gluster vs Ceph:开源存储领域的正面较量
https://www.oschina.net/news/49048/gluster-vs-ceph 引言:开源存储软件Ceph和Gluster能够提供相似的特性并且能够为用户节省不小的开支.那么谁更 ...
- 两大主流开源分布式存储的对比:GlusterFS vs. Ceph
两大主流开源分布式存储的对比:GlusterFS vs. Ceph 存储世界最近发生了很大变化.十年前,光纤通道SAN管理器是企业存储的绝对标准,但现在的存储必须足够敏捷,才能适应在新的基础架构即服务 ...
- Atitit 硬件 软件 的开源工作 差异对比
Atitit 硬件 软件 的开源工作 差异对比 1.1. 模块化,标准化,以及修改的便捷性1 1.2. 生产和发布成本 1 1.3. 3. 入行门槛搞2 1.4. 在软件业极度发达的今天,任何具 ...
- 你需要知道的MySQL开源存储引擎TokuDB
在四月份的Percona Live MySQL会议上, TokuDB庆祝自己成为开源存储引擎整一周年.我现在仍能记得一年前它刚创建时的官方声明与对它的期望.当时的情况非常有意思,因为它拥有帮助MySQ ...
- MySQL存储引擎对比
MySQL存储引擎对比 作者:尹正杰 版权声明:原创作品,谢绝转载!否则将追究法律责任. 一.MySQL的存储引擎 大家应该知道MySQL的存储引擎应该是表级别的概念,因为我们无法再创建databas ...
- 几种开源SIP协议栈对比
几种开源SIP协议栈对比 随着VoIP和NGN技术的发展,H.323时代即将过渡到SIP时代,在H.323的开源协议栈中,Openh323占统治地位,它把一个复杂而又先进的H.323协议栈展现在普通程 ...
- [转帖]InnoDB与MyISAM等存储引擎对比
InnoDB与MyISAM等存储引擎对比 https://blog.ouyangsihai.cn/innodb-yu-myisam-deng-cun-chu-yin-qing-dui-bi.html ...
- mysql学习--MySQL存储引擎对比总结
一.存储引擎是什么 存储引擎是数据库的核心,对于mysql来说,存储引擎是以插件的形式运行的.MySQL默认配置了许多不同的存储引擎,可以预先设置或者在MySQL服务器中启用.你可以选择适用于服务器. ...
- 开源存储之ceph
小记,曾经的很多单骑,赵子龙,杨再兴,..............为大将者所应用的胆识和气度,值得敬仰! 名师出高徒啊, 周侗北宋末年之武术大师,相传为三国姜维的传人(真实性ruiy哥就不考察了哈), ...
随机推荐
- .NET Core+NLog+存储配置 日志存入到数据库
nlog-config.xml 配置文件: <?xml version="1.0" encoding="utf-8" ?> <nlog xml ...
- SQL Server In-Memory OLTP Internals for SQL Server 2016
SQL Server In-Memory OLTP Internals for SQL Server 2016 这份白皮书是在上一份<SQL Server In-Memory OLTP Inte ...
- 10款WordPress的插件让你的网站的移动体验
随着科技的不断发展,需要改变营销策略的一个企业就变得非常重要.你不能指望用你的营销工具来留住你的客户.智能手机和平板电脑已经改变了消费者的行为方式.现在,人们甚至不想去他们的电脑或笔记本电脑,以检查产 ...
- 我们为什么要在Android中使用RxJava
本文翻译来自–>Why should we use RxJava on Android 另外: 微凉一季 再另外: 微凉一季 感觉RxJava近期风生水起,不学习一下都不好意思了.洒家也是初学R ...
- golang处理signal
signal一般用来实现优雅重启,或者重新加载配置文件等操作. 废话不多说,上表格 动作 号码 信号 golang kill pid 15 SIGTERM terminated kill -9 pid ...
- Maven项目:Malformed POM expected START_TAG or END_TAG ........
今天在执行maven命令 mvn assembly:assembly -Dmaven.test.skip=true的时候报了个错,大概是Malformed POM expected START_TAG ...
- 【转】WPF自定义控件与样式(11)-等待/忙/正在加载状态-控件实现
一.前言 申明:WPF自定义控件与样式是一个系列文章,前后是有些关联的,但大多是按照由简到繁的顺序逐步发布的等. 本文主要有三种实现方式: 简单忙碌状态控件BusyBox: Win8/win10效果忙 ...
- Mysql获取最大自增ID(auto_increment)的五种方式及其特点
在关系型数据库的表结构中,一般情况下,都会定义一个具有‘AUTO_INCREMENT’扩展属性的‘ID’字段,以确保数据表的每一条记录都有一个唯一标识. 而实际应用中,获取到最近最大的ID值是必修课之 ...
- iOS 之地图坐标体系和转换
一.坐标体系 首先我们要明白,开发者能接触到哪些坐标体系呢? 第一种分类: 1. GPS,WGS-84,原始坐标体系.一般用国际标准的GPS记录仪记录下来的坐标, 都是GPS的坐标.很可惜,在中国,任 ...
- Unity长连接
http://blog.csdn.net/claine/article/details/52374546