开源分布式存储系统笔记
专业名词
缩写全称注释
SDS Software Defined Storag软件定义存储技术
RAID Redundant Array of Independent Disk磁盘阵列技术
DG Disk Group硬盘组
VD Virtual Disk虚拟磁盘（等效磁盘组）Mirroring--镜像技术，⼜称为复制技术
（Replication）
Striping---条带（可提供并⾏的数据吞吐能⼒）
Erasure Code ---纠删码（提供⾼可⽤性和⾼速读写能
⼒）
RADOS Reliable,Autonomic,Distributed Object
Store可靠的⾃主的分布式对象存储
OSD Object Storage Device对象存储设备
MDS Metadata Server元数据服务
MTTR Mean Time To Restoration平均恢复时间
块存储、⽂件存储、对象存储
块存储
就好⽐硬盘⼀样, 直接挂在到主机，⼀般⽤于主机的直接存储空间和数据库应⽤(如: mysql)的存储。
块存储（DAS/SAN）通常应⽤在某些专有的系统中，这类应⽤要求很⾼的随机读写性能和⾼可靠性，上⾯搭载的通常是Oracle/DB2这种传统数据库，连接通常是以FC光纤（8Gb/16Gb）为主，⾛光纤协议。如果要求稍低⼀些，也会出现基于千兆/万兆以太⽹的连接⽅式，MySQL这种数据库就可能会使⽤IP SAN，⾛iSCSI协议。
通常使⽤块存储的都是系统⽽⾮⽤户，并发访问不会很多，经常出现⼀套存储只服务⼀个应⽤系统，例如如交易系统，计费系统。典型⾏业如⾦融，制造，能源，电信等。
⽂件系统
⽂件存储（NAS）相对来说就更能兼顾多个应⽤和更多⽤户访问，同时提供⽅便的数据共享⼿段。
在PC时代，数据共享也⼤多是⽤⽂件的形式，⽐如常见的的FTP服务，NFS服务，Samba共享这些都是属于典型的⽂件存储。⼏⼗个⽤户甚⾄上百⽤户的⽂件存储共享访问都可以⽤NAS存储加以解决。
在中⼩企业市场，⼀两台NAS存储设备就能⽀撑整个IT部门了。CRM系统，SCM系统，OA系统，邮件系统都可以使⽤NAS存储统统搞定。甚⾄在公有云发展的早⼏年，⽤户规模没有上来时，云存储的底层硬件也有⽤⼏套NAS存储设备就解决的，甚⾄云主机的镜像也有放在NAS存储上的例⼦。
⽂件存储的⼴泛兼容性和易⽤性，是这类存储的突出特点。
但是从性能上来看，相对SAN就要低⼀些。NAS存储基本上是以太⽹访问模式，普通千兆⽹，⾛NFS/CIFS协议。
对象存储
前⾯说到的块存储和⽂件存储，基本上都还是在专有的局域⽹络内部使⽤，⽽对象存储的优势场景却是互联⽹或者公⽹，主要解决海量数据，海量并发访问的需求。
基于互联⽹的应⽤才是对象存储的主要适配（当然这个条件同样适⽤于云计算，基于互联⽹的
应⽤最容易迁移到云上），基本所有成熟的公有云都提供了对象存储产品，不管是国内还是国外。
对象存储常见的适配应⽤如⽹盘、媒体娱乐，医疗PACS，⽓象，归档等数据量超⼤⽽⼜相
对“冷数据”和⾮在线处理的应⽤类型。
这类应⽤单个数据⼤，总量也⼤，适合对象存储海量和易扩展的特点。
⽹盘类应⽤也差不多，数据总量很⼤，另外还有并发访问量也⼤，⽀持10万级⽤户访问这种需求就值得单列⼀个项⽬了。归档类应⽤只是数据量⼤的冷数据，并发访问的需求倒是不太突出。
另外基于移动端的⼀些新兴应⽤也是适合的，智能⼿机和移动互联⽹普及的情况下，所谓UGD（⽤户产⽣的数据，⼿机的照⽚视频）总量和⽤户数都是很⼤挑战。毕竟直接使⽤HTTP get/put就能直接实现数据存取，对移动应⽤来说还是有⼀定吸引⼒的。
对象存储的访问通常是在互联⽹，⾛HTTP协议，性能⽅⾯，单独看⼀个连接的是不⾼的（还要解决掉线断点续传之类的可靠性问题），主要强⼤的地⽅是⽀持的并发数量，聚合起来的性能带宽就⾮常可观了。
性能容量
性能容量类⽐
块存储就像超跑，根本不在意能不能多载⼏个⼈，要的就是极限速度和⾼速下的稳定性和可靠性，各⼤⼚商出新产品都要去纽北赛道刷个单圈最快纪录，千⽅百计就为提⾼⼀两秒。块存储容量也不⼤，TB这个数量级，⽀持的应⽤和适⽤的环境也⽐较专业（FC+Oracle），在乎的都是IOPS的性能值。
⽂件存储像集卡，普适各种场合，⼜能装数据（数百TB），⽽且兼容性好，只要你是⽂件，各种货物都能往⾥塞，在不超过性能载荷的前提下，能拉动常见的各种系统。标准POXIS接⼝，后车门打开就能装卸。卡车也不挑路，不像块存储⾮要上赛道才能开，普通的千兆公路就能畅通⽆阻。速度虽然没有块存储超跑那么块，但跑个80/100码还是稳稳当当。
对象存储就像海运货轮，应对的是"真·海量"，⼏⼗上百PB的数据，以集装
箱/container（桶/bucket）为单位码得整整齐齐，⾥⾯装满各种对象数据，⼗万客户发的货（数据），
⼀条船就都处理得过来，按照键值（KeyVaule）记得清清楚楚。海运速度慢是慢点，有时候遇到点⽹络风暴还不稳定，但⽀持断点续传，最终还是能安全送达的，对⼤宗货物尤其是⾮结构化数据，整体上来看是最快捷便利的。
访问⽅式
块存储通常都是通过光纤⽹络连接，服务器/⼩机上配置FC光纤HBA卡，通过光纤交换机连接存储（IP SAN可以通过千兆以太⽹，以iSCSI客户端连接存储），主机端以逻辑卷（Volume）的⽅式访问。连接成功后，应⽤访问存储是按起始地址，偏移量Offset的⽅法来访问的。
NAS⽂件存储通常只要是局域⽹内，千兆/百兆的以太⽹环境皆可。⽹线连上，服务器端通过操作系统内置的NAS客户端，如NFS/CIFS/FTP客户端挂载存储成为⼀个本地的⽂件夹后访问，只要符合POXIS标准，应⽤就可以⽤标准的open，seek, write/read,close这些⽅法对其访问操作。
对象存储不在乎⽹络，⽽且它的访问⽐较有特⾊，只能存取删（put/get/delete），不能打开修改存盘。只能取下来改好后上传，去覆盖原对象。
分布式
对象存储的定义就把元数据管理和数据存储访问分开在不同的节点上，多个节点应对多并发的访问，这
⾃然就是⼀个分布式的存储产品。
分布式⽂件系统就很多了，各种开源闭源的产品数得出⼏⼗个，在不同的领域各有应⽤。
分布式的块存储产品就⽐较少，也很难做好。
层次关系
块存储、⽂件存储、对象存储的层次关系
从底层往上看，最底层就是硬盘，多个硬盘可以做成RAID组，⽆论是单个硬盘还是RAID组，都可以做成PV，多个PV物理卷捏在⼀起构成VG卷组，这就做成⼀块⼤蛋糕了。
接下来，可以从蛋糕上切下很多块LV逻辑卷，这就到了存储⽤户最熟悉的卷这层。到这⼀层为⽌，数据⼀直都是以Block块的形式存在的，这时候提供出来的服务就是块存储服务。
你可以通过FC协议或者iSCSI协议对卷访问，映射到主机端本地，成为⼀个裸设备。在主机端可以直接在上⾯安装数据库，也可以格式化成⽂件系统后交给应⽤程序使⽤，这时候就是⼀个标准的SAN存储设备的访问模式，⽹络间传送的是块。
如果不急着访问，也可以在本地做⽂件系统，之后以NFS/CIFS协议挂载，映射到本地⽬录，直接以⽂件形式访问，这就成了NAS访问的模式，在⽹络间传送的是⽂件。
如果不⾛NAS，在本地⽂件系统上⾯部署OSD服务端，把整个设备做成⼀个OSD，这样的节点多来⼏个，再加上必要的MDS节点，互联⽹另⼀端的应⽤程序再通过HTTP协议直接进⾏访问，这就变成了对象存储的访问模式。当然对象存储通常不需要专业的存储设备，前⾯那些
LV/VG/PV层也可以统统不要，直接在硬盘上做本地⽂件系统，之后再做成OSD，这种才是对象存储的标准模式，对象存储的硬件设备通常就⽤⼤盘位的服务器。
系统层级上来说，这三种存储是按照块->⽂件->对象逐级向上的。⽂件⼀定是基于块上⾯去做，不管是远端还是本地。⽽对象存储的底层或者说后端存储通常是基于⼀个本地⽂件系统
（XFS/Ext4..）。
相关开源组件
⽬前⽐较流⾏的开源项⽬有：
Ceph
GlusterFS
Swift
开源oa系统源码
HDFS
FastDFS
Ambry
基本特性对⽐
存储系统Ceph GlusterFS Swift HDFS FastDFS Ambry
开发语⾔C++C Python Java C Java
开源协议LGPL GPL3Apache Apache GPL3Apache
Start数4667/25011626/6361759/9157558/4,7863011/9151073/206
存储⽅式对象/⽂件/块⽂件/块对象⽂件⽂件/块对象
在线扩容⽀持⽀持⽀持⽀持⽀持⽀持
冗余备份⽀持⽀持⽀持⽀持⽀持⽀持
单点故障不存在不存在不存在存在不存在不存在
易⽤性⼀般简单⼀般⼀般简单简单
跨集不⽀持⽀持不⽀持不⽀持不⽀持不⽀持
适⽤场景⼤中⼩⽂件⼤中⼩⽂件⼤中⼩⽂件⼤中⽂件中⼩⽂件⼤中⼩⽂件
Ceph
Ceph是个开源的分布式存储，底层是RADOS，这是个标准的对象存储。以RADOS为基
础，Ceph 能够提供⽂件，块和对象三种存储服务，旨在提供⼀个扩展性强⼤、性能优越且⽆单
点故障的分布式存储系统。
Ceph架构图
在Ceph存储中，包含了⼏个重要的核⼼组件，分别是Ceph OSD、Ceph Monitor和Ceph MDS。⼀个Ceph的存储集⾄少需要⼀个Ceph Monitor和⾄少两个Ceph的OSD。运⾏Ceph⽂件系统的客户端时，Ceph的元数据服务器（MDS）是必不可少的。
其中通过RBD提供出来的块存储是⽐较有价值的地⽅，毕竟因为市⾯上开源的分布式块存储少见。
当然它也通过CephFS模块和相应的私有Client提供了⽂件服务，这也是很多⼈认为Ceph是个⽂件系统的原因。
另外它⾃⼰原⽣的对象存储可以通过RadosGW存储⽹关模块向外提供对象存储服务，并且和对象存储的事实标准Amazon S3以及Swift兼容。所以能看出来这其实是个⼤⼀统解决⽅案，啥都齐全。
RADOS也是个标准对象存储，⾥⾯也有MDS的元数据管理和OSD的数据存储，⽽OSD本⾝是可以基于⼀个本地⽂件系统的，⽐如XFS/EXT4/Brtfs。
数据访问路径，如果看Ceph的⽂件接⼝，⾃底层向上，经过了硬盘（块）->⽂件->对象->⽂件的路径；如果看RBD的块存储服务，则经过了硬盘（块）->⽂件->对象->块，也可能是硬盘（块）->对象->块的路径；再看看对象接⼝（虽然⽤的不多），则是经过了硬盘（块）->⽂件->对象或者硬盘（块）->对象的路径。
GlusterFS
GlusterFS是Scale-Out存储解决⽅案Gluster的核⼼，它是⼀个开源的分布式⽂件系统，具有强⼤的横向扩展能⼒，通过扩展能够⽀持数PB存储容量和处理数千客户端。GlusterFS借助
TCP/IP或InfiniBand RDMA⽹络将物理分布的存储资源聚集在⼀起，使⽤单⼀全局命名空间来管理数据。GlusterFS基于可堆叠的⽤户空间设计，可为各种不同的数据负载提供优异的性能。架构与设计
它主要由存储服务器（Brick Server）、客户端以及NFS/Samba存储⽹关组成。不难发
现，GlusterFS架构中没有元数据服务器组件，这是其最⼤的设计这点，对于提升整个系统的性能、可靠性和稳定性都有着决定性的意义。GlusterFS⽀持TCP/IP和InfiniBand RDMA⾼速⽹络互联，客户端可通过原⽣Glusterfs协议访问数据，其他没有运⾏GlusterFS客户端的终端可通过NFS/CIFS标准协议通过存储⽹关访问数据。
GlusterFS是⼀个具有⾼扩展性、⾼性能、⾼可⽤性、可横向扩展的弹性分布式⽂件系统，在架构设计上⾮常有特点，⽐如⽆元数据服务器设计、堆栈式架构等。然⽽，存储应⽤问题是很复杂的，GlusterFS也不可能满⾜所有的存储需求，设计实现上也⼀定有考虑不⾜之处，下⾯我们作简要分析。
1.⽆元数据服务器 vs 元数据服务器
⽆元数据服务器设计的好处是没有单点故障和性能瓶颈问题，可提⾼系统扩展性、性能、可靠性和稳定性。对于海量⼩⽂件应⽤，这种设计能够有效解决元数据的难点问题。
它的负⾯影响是，数据⼀致问题更加复杂，⽂件⽬录遍历操作效率低下，缺乏全局监控管理功能。同时也导致客户端承担了更多的职能，⽐如⽂件定位、名字空间缓存、逻辑卷视图维护等等，这些都增加了客户端的负载，占⽤相当的CPU和内存。
2. ⽤户空间 vs 内核空间
⽤户空间实现起来相对要简单许多，对开发者技能要求较低，运⾏相对安全。⽤户空间效率低，数据需要多次与内核空间交换，另外GlusterFS借助FUSE来实现标准⽂件系统接⼝，性能上⼜有所损耗。
内核空间实现可以获得很⾼的数据吞吐量，缺点是实现和调试⾮常困难，程序出错经常会导致系统崩溃，安全性低。纵向扩展上，内核空间要优于⽤户空间，GlusterFS有横向扩展能⼒来弥补。
3. 堆栈式 vs ⾮堆栈式
GlusterFS堆栈式设计思想源⾃GNU/Hurd微内核操作系统，具有很强的系统扩展能⼒，系统设计实现复杂性降低很多，基本功能模块的堆栈式组合就可以实现强⼤的功能。查看GlusterFS卷配置⽂件我们可以发现，translator功能树通常深达10层以上，⼀层⼀层进⾏调⽤，效率可见⼀斑。
⾮堆栈式设计可看成类似Linux的单⼀内核设计，系统调⽤通过中断实现，⾮常⾼效。后者的问题是系统核⼼臃肿，实现和扩展复杂，出现问题调试困难。
4. 原始存储格式 vs 私有存储格式
GlusterFS使⽤原始格式存储⽂件或数据分⽚，可以直接使⽤各种标准的⼯具进⾏访问，数据互操作性好，迁移和数据管理⾮常⽅便。然⽽，数据安全成了问题，因为数据是以平凡的⽅式保存的，接触数据的⼈可以直接复制和查看。这对很多应⽤显然是不能接受的，⽐如云存储系统，⽤户特别关⼼数据安全，这也是影响公有云存储发展的⼀个重要原因。
私有存储格式可以保证数据的安全性，即使泄露也是不可知的。GlusterFS要实现⾃⼰的私有格式，在设计实现和数据管理上相对复杂⼀些，也会对性能产⽣⼀定影响。
5. ⼤⽂件 vs ⼩⽂件
弹性哈希算法和Stripe数据分布策略，移除了元数据依赖，优化了数据分布，提⾼数据访问并⾏性，能够⼤幅提⾼⼤⽂件存储的性能。
对于⼩⽂件，⽆元数据服务设计解决了元数据的问题。
但GlusterFS并没有在I/O⽅⾯作优化，在存储服务器底层⽂件系统上仍然是⼤量⼩⽂件，本地⽂件系统元数据访问是⼀个瓶颈，数据分布和并⾏性也⽆法充分发挥作⽤。
因此，GlusterFS适合存储⼤⽂件，⼩⽂件性能较差，还存在很⼤优化空间。
6. 可⽤性 vs 存储利⽤率
GlusterFS使⽤复制技术来提供数据⾼可⽤性，复制数量没有限制，⾃动修复功能基于复制来实现。
可⽤性与存储利⽤率是⼀个⽭盾体，可⽤性⾼存储利⽤率就低，反之亦然。
采⽤复制技术，存储利⽤率为1/复制数，镜像是50%，三路复制则只有33%。
其实，可以有⽅法来同时提⾼可⽤性和存储利⽤率，⽐如RAID5的利⽤率是(n-1)/n，RAID6是(n-2)/n，⽽纠删码技术可以提供更⾼的存储利⽤率。但是，鱼和熊掌不可得兼，它们都会对性能产⽣较⼤影响。
Swift
Swift 是OpenStack开源云计算项⽬的⼦项⽬之⼀，被称为对象存储，提供了强⼤的扩展性、冗余和持久性。构筑在⽐较便宜的标准硬件存储基础设施之上，⽆需采⽤ RAID（磁盘冗余阵列），通过在软件层
⾯引⼊⼀致性散列技术和数据冗余性，牺牲⼀定程度的数据⼀致性来达到⾼可⽤性和可伸缩性，⽀持多租户模式、容器和对象读写操作，适合解决互联⽹的应⽤场景下⾮结构化数据存储问题。
Swift系统架构
代理服务（Proxy Server）：对外提供对象服务 API，会根据环的信息来查服务地址并转发⽤户请求⾄相应的账户、容器或者对象服务；由于采⽤⽆状态的 REST 请求协议，可以进⾏横向扩展来均衡负载。
认证服务（Authentication Server）：验证访问⽤户的⾝份信息，并获得⼀个对象访问令牌（Token），在⼀定的时间内会⼀直有效；验证访问令牌的有效性并缓存下来直⾄过期时间。
缓存服务（Cache Server）：缓存的内容包括对象服务令牌，账户和容器的存在信息，但不会缓存对象本⾝的数据；缓存服务可采⽤ Memcached 集，Swift 会使⽤⼀致性散列算法来分配

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。