云存储产品浅析

云上存储产品主要有对象存储，块存储，网络文件系统(NAS)，还有最赚钱的CDN，我们将针对这些主流产品，讲讲他们产品特点，有云上存储时候知道如何选型，当然我们是技术型作者也会简单讲讲实现思路，出于信息安全，不可能完全阐述工业界方案。 工业界各大厂商很多上层存储产品都重度依赖底层文件系统，我们也捎带说说存储祖师爷DFS。

一、Linux IO STACK

云计算本质就是单机计算能力的无限扩展，我们先看看单机的文件及IO管理。 linux操作系统一个IO操作要经由文件系统vfs，调度算法，块设备层，最终落盘

其中vfs层有具体的NFS/smbfs 支持网络协议派生出来NAS产品

VFS还有一个fuse文件系统，可切换到用户态上下文。上层分布式存储只要适配了Libfuse接口，就可访问后端存储

在设备层，通过扩展ISCSI网络协议，衍生出了块存储

二、存储产品架构流派

1. 分层或平层

如hbase，底层基于hdfs文件系统，hbase不用考虑replication，专注于自身领域问题

特点：大大降低开发成本，稳定性依赖底层存储，底层不稳定，上层遭殃。

2. 竖井

自己做replication，自己做副本recover，自己做写时recover

master-slave体系架构

两层索引体系，解决lots of small file：

第一层，master维护一个路由表，通过fileurl找到对应slave location(ip+port)

第二层，slave单机索引体系，找到具体的location，读出raw data

DFS

3. 特点

丰富类posix语意，特点Append-only存储，不支持pwrite

4. 可能存在问题

Pb级别存储方案，非EB级别。 原因namenode集中式server，内存&qps瓶颈，bat体量公司需运维上百个集群

默认三副本，成本高

强一致写，慢节点问题

5. 演进

GFS2拆分了namenode，拆分成目录树，blockservice，外加ferdaration，但namespace集中式server缺陷依旧，同时切分image是要停服，水平扩展不是那么友好。

三、对象存储

1. 元数据管理

Blobstorage： blobid->[raw data]

Metastore，aws s3又称为keymap，本质上是个kv系统。存储内容file_url->[blobid list]

2. I/O 路径

httpserver收到muti-part form,收到固定大小raw data，切成K份等长条带

条带做EC，生成(N-K)份编码块，共得到N份shard。现在的问题变成了这N份数据存哪

客户端的代理继续向blobstorage申请一个全局的id，这个id代表了了后端实际node的地址，以及这个node管理的实际物理卷，我们的每个分片数据均等的存在这些物理卷上。

分发写N份数据，满足安全副本数即可返回写成功，写失败的可延时EC方式修复

httpserver将文件file及对应的分片列表以KV形式写入metastore。

3. 特点

基于http协议 ws服务，接口简单，put/get，延时高。 EB级别存储方案，适合云上产品形态。深度目录树变成两层目录结构(bucket+object)。

4. 缺点

posix语意接口太少，不提供append语意(其实是通过覆盖写提供)，更别说随机写。

四、块存储

1. iscsi模型

与后端交互的的部分在内核实现，后端target解析iscsi协议并将请求映射到后端分布式存储

2. 特点

绝大多数请求大小是4K对齐的blocksize. 块设备的使用一般上层文件系统，而大多数主流文件系统的块大小是4KB，文件最小操作粒度是块，因此绝大多数的IO请求是4KB对齐的。

强一致. 块设备必须提供强一致，即写返回后，能够读到写进去的数据。

支持随机写，延时要低 用户基于虚拟块设备构建文件系统(ext4)，对于文件编辑操作很频繁，所以需要支持随机写。 比NAS/Fuse类产品性能好，只hack块设备读写，上层dentry lookup还是走原来的IO path，没有像NAS/FUSE dentry的lookup发起多次rpc问题

产品层面需要预先购买容量，扩容需要重新挂载，跟NAS比容易浪费空间

3. 实现模型