云存储平台产品浅析

 

云上存储产品主要有对象存储，块存储，网络文件系统（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，延时高。

总结