云上存储产品主要有对象存储,块存储,网络文件系统(
NAS),还有最赚钱的CDN,我们将针对这些主流产品,讲讲他们产品特点,有云上存储时候知道如何选型,当然我们是技术型作者也会简单讲讲实现思路,出于信息安全,不可能完全阐述工业界方案。工业界各大厂商很多上层存储产品都重度依赖底层文件系统,我们也捎带说说存储祖师爷DFS。
Linux IO STACK
云计算本质就是单机计算能力的无限扩展,我们先看看单机的文件及 IO 管理。 linux 操作系统一个 IO 操作要经由文件系统 vfs ,调度算法,块设备层,最终落盘 :
( 1 ) 其中 vfs层有具体的NFS/smbfs 支持网络协议派生出来NAS产品
( 2 ) VFS还有一个fuse文件系统,可切换到用户态上下文。上层分布式存储只要适配了Libfuse接口,就可访问后端存储
( 3 ) 在设备层,通过扩展 ISCSI网络协议,衍生出了块存储
存储产品架构流派
分层或平层 :
如
hbase
,底层基于
hdfs
文件系统,
hbase
不用考虑
replication
,专注于自身领域问题
特点:大大降低开发成本,稳定性依赖底层存储,底层不稳定,上层遭殃。
竖井 :
自己做 replication ,自己做副本 recover ,自己做写时 recover master-slave 体系架构
两层索引体系,解决 lots of small file
第一层, master维护一个路由表,通过fileurl找到对应slave location(ip+port)
第二层, slave单机索引体系,找到具体的location,读出raw data DFS
特点 : 丰富类 posix语意,特点Append-only存储,不支持pwrite
可能存在问题 :
( 1 ) Pb级别存储方案,非EB级别。 原因namenode集中式server,内存&qps瓶颈,bat体量公司需运维上百个集群
( 2 ) 默认三副本,成本高
( 3 ) 强一致写,慢节点问题
演进 :
GFS2拆分了namenode,拆分成目录树,blockservice,外加ferdaration,但namespace集中式server缺陷依旧,同时切分image是要停服,水平扩展不是那么友好。
对象存储 :
元数据管理
Blobstorage: blobid->[raw data]
Metastore,aws s3又称为keymap,本质上是个kv系统。存储内容file_url->[blobid list]
I/O 路径
( 1 ) httpserver收到muti-part form,收到固定大小raw data,切成K份等长条带
( 2 ) 条带做 EC,生成(N-K)份编码块,共得到N份shard。现在的问题变成了这N份数据存哪
( 3 ) 客户端的代理继续向 blobstorage申请一个全局的id,这个id代表了了后端实际node的地址,以及这个node管理的实际物理卷,我们的每个分片数据均等的存在这些物理卷上。
( 4 ) 分发写 N份数据,满足安全副本数即可返回写成功,写失败的可延时EC方式修复
( 5 ) httpserver将文件file及对应的分片列表以KV形式写入metastore。
特点 :
基于 http 协议 ws 服务,接口简单, put/get ,延时高。 EB 级别存储方案,适合云上产品形态。深度目录树变成两层目录结构( bucket+object )。
缺点 :
posix 语意接口太少,不提供 append 语意(其实是通过覆盖写提供),更别说随机写。
iscsi模型
与后端交互的的部分在内核实现,后端 target 解析 iscsi 协议并将请求映射到后端分布式存储
特点:
( 1 ) 绝大多数请求大小是 4K 对齐的 blocksize. 块设备的使用一般上层文件系统,而大多数主流文件系统的块大小是 4KB ,文件最小操作粒度是块,因此绝大多数的 IO 请求是 4KB 对齐的。
( 2 ) 强一致 . 块设备必须提供强一致,即写返回后,能够读到写进去的数据。
( 3 ) 支持随机写,延时要低用户基于虚拟块设备构建文件系统( ext4 ),对于文件编辑操作很频繁,所以需要支持随机写。比 NAS/Fuse 类产品性能好,只 hack 块设备读写,上层 dentry lookup 还是走原来的 IO path ,没有像 NAS/FUSE dentry 的 lookup 发起多次 rpc 问题
( 4 ) 产品层面需要预先购买容量,扩容需要重新挂载,跟 NAS 比容易浪费空间
实现模型:
云盘逻辑卷按 block切分,为了便于recover,按1G切分,第一层路由由blockManager管理,按volumeid+offset 映射到逻辑block,逻辑block location在三台blockserver上。Blockserver预先创建一个1G文件(falloc,防止写过程中空间不够),称为物理block。对于逻辑卷这段区间所有的IO操作都会落到这个物理block文件上,很容易实现pwrite。当然也可以基于裸盘,在os看来是一个大文件,分割成不同的1G文件
IO路径:
块设备上层会有文件系统,经过 io调度算法,合并io操作,isici协议发出的IO请求的都是对扇区LBA的操作,所以可以简单抽象成对于卷id加上偏移的操作,我们简单讲讲EBS(Elastic Block Store)层IO路径
( 1 ) 网络发出来的 IO 请求是针对 volume+offerset 操作,假定是个写请求
( 2 ) 通过 blockManager 查找到逻辑 block
( 3 ) 在内存中找到 block 对应的物理地址( ip+port ), block 的 replicationGroup
( 4 ) 使用业界通用复制链方式如 raft 协议向 replicationGroup 发送 io 请求, raft 帮我们解决写时失败 tuncate 问题
( 5 ) 单节点接到 IO 请求,把 LBA 换算成真实的文件偏移, pwrite 写下去
优化
a、 可想而知,这种存储模型下,后端 node会有大量的随机写,吞吐肯定不高,有很大的优化空间 可以通过类似LSM引擎方式,将随机写变成顺序写,读者可深入思考,本文不详细探讨了。
b、 虚拟磁盘可以切条掉,相当于 raid盘思路,单块盘的IO变成多多块盘,增大吞吐。
NAS
用户通过
mount目录访问共享文件,mount点挂在的是一个NFS协议的文件系统,会通过tcp访问到NFS server。
NFS server是一个代理,通过libcfs最终会访问到我们后端的存储系统。
后端存储系统
DS包含管理inode的metastore和datastore,metastore
我们充分吸取业界 DFS缺点,解决Namenode集中式server瓶颈,充分考虑bigtable的各种优点。Metastore可基于分布式数据库(newsql),回想一下bigtable,一个用户的文件散落在多个tabletserver上,允许用户跨tabletserver rename操作,所以需要分布式事务完成上述保证,出于对DFS改进,我们把目录树持久化模仿linux fs dentry管理,映射规则如下两张表,dentry表和inode表,dentry表描述目录树,inode表描述文件block列表及atime,mtime,uid,gid等源信息,一般来讲硬链够用,该场景下dentry可以多份,共同指向一个inode。 dentry通过外健关联到inode表
比如 lookup 子节点
SELECT i.* FROM Dentry d, Inode i WHERE d.PARENT_DID=$PARENT_ID
datastore
特点:要求提供随机写,所以跟块存储 EBS设计思路是一样的,大文件切块,按块组织,dataserver上有真实的物理block文件,提供pwrite操作。
特点
弹性容量,不限容量,多机挂载并行读写, IO线性增长,支持随机写比块存储优势在于用多少花多少,不需要提前申请容量,真弹性
缺点
vfs层 dentry lookup每个层级目录会发起rpc,延时高。
总结
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。