云存储的起源,与云计算之间的关系.主要分三个方面也是入门吧.(云计算初识见上篇)
- 云存储的起源和概述
- 云存储的基本特性
- 云存储和其他存储系统
当下我们说的云存储主要是分布式存储系统. 底层是存储引擎. 分为多层,每一层都是一个复杂的系统 1.业务层 2.索引层 3.数据层.
更新: 之后会重新整理一下分布式的知识, 这篇主要参考腾讯云课堂, 可暂时忽略..
0x00.云存储概述
a.从云计算到云存储
云存储是云计算的一个分支,具有云计算的许多特性.简单说,就是把存储集群化,集中起来.采用分布式文件系统等功能去分发,然后对外对内提供数据存储和业务访问的系统.
时间线:
2004提出概念,2006年Amazon正式推出的S3划开了云存储服务.后续云存储的增长是非常明显的.
什么是非结构化数据? 什么是结构化数据
b.云存储的基本特征
云存储采用分布式并行扩展架构(基于网络分发资源). 通常为了节省成本,会直接购置服务器,而不是单独的磁盘阵列.也会采取多重数据冗余/容错技术.
云存储的数据安全性是非常重要的,特别是对于企业或者机关机构.所以传输过程需要加密,数据本身也需要加密,防止hacker入侵丢失重要数据.
资源共享性
- 不受限于硬件存储节点数
- 提供类似POSIX的传统文件访问
- 支持API接口
- 提供公共服务支撑功能
c. 云存储和其他存储系统
常见三种存储模式:
块存储 (DAS, 磁盘阵列)
DAS :直连存储是最简单的模式,就是服务器与存储直接连接
SAN: 磁盘阵列 ,将各种存储设备集中起来形成一个存储网络,以便于数据的集中管理 (不是NAS).需要购买专门的交换机(光纤卡,或者磁盘控制器,很贵)
文件存储
NAS: NAS是中小型最常用的一种存储方式,一般NAS可以支持FTP,NFS,CIFS多种网络文件传输协议
FTP服务器: 最传统的做法,这也是一种网络传输方式,不是存储方式.
NFS服务器: 对应是SMB(Win下) ,这不是一种存储方式,而是一种协议.
对象存储 (云存储常用)
兼具前面二者的优点,但是需要大量的服务器构建成集群,体系较大,
有单独的控制系统,那么对象存储到底是什么特点?
| 类别 | 功能对比 | 容量扩展 | 性能需求 | 数据共享 |
|---|---|---|---|---|
| 块存储 | 高性能计算,事务处理(Mysql/Oracle) | 最大值优先,扩容成本高 | 并发读写受限于单台设备的I/O | 很难实现多设备,系统的容量带宽共享 |
| 云存储 | 面相多种类型的网络在线存储服务(tomcat/网盘) | 线性性能,弹性扩展. | 吞吐能力受网络影响,但是多存储可并发访问.热点数据会有负载均衡 | 集群文件系统,灵活进行数据共享管理 |
0x01.云硬盘
云硬盘是云存储的一个很重要的应用场景,比如常见的各大网盘.
主要谈谈常见架构,如何组织数据,如何快速恢复以及迁移数据, 如何制作快照跟多副本的冗余. 最后就是如何持续的对数据进行保护/加密.
以三模块架构为例,一般是如图
client模块 ( 部署于虚拟机控制器上,主要两个功能)
负责磁盘的虚拟化
可以将存储池中抽象出来的volume也就是虚拟硬盘映射为一个本地磁盘.而存储池的卷,分步在下方的数据模块上由不同的块组成. client负责将这些块映射为一个统一的逻辑地址,使得用户在虚拟机中看到的就是一个本地磁盘
存储协议之间的转换
它可以将用户的I/O的请求,将固定的块大小进行拆分,然后将这些请求路由到不同的数据模块上,通过并发的I/O请求,可以进一步提高云硬盘的性能
master模块
路由信息推送到client
客户端到数据区的路由过程, 客户端如果接受到了路由信息,就自己分配不同请求到数据模块
监控data模块的状态(故障)
当发现数据区有任何节点down掉,或者掉速明显,进行下线&恢复和及时的数据迁移.
data 模块 (Chunk Server,存储数据)
三副本冗余存储策略
首先,数据模块是整个云硬盘的存储节点,负责管理分配数据块,保存真实数据. 每份数据冗余三份在不同节点上避免丢失.图中蓝色代表相同的数据快,红,绿,黄也是一样.
用户访问权限控制
负责用户数据之间的隔离,保证数据的安全性,对权限划分用用户卷的方式控制
2. 数据组织
以上面结构为例,显然技术层面核心在data模块. 也就是Chunk Server模块.简单看看它的实际数据是如何分布的. 如图所示
以一个data节点为例,它的数据区会被划分为多个分区,每个分区包含了若干的block(块).类似可以联想到学习GPT分区表的时候,中间的逻辑分区表和物理存储区的关系.
数据块是在云硬盘中空间分配 or 回收的基本单位.用户所看到的统一的逻辑卷空间 或者说用户所看到的硬盘,是由分布在不同CS(Chunk Server)上组成的. Master模块负责client向CS路由信息的管理,如果整个云硬盘的系统以数据块的方式进行管理,那么对master节点和client模块都会有巨大的压力. (e,g 如果CS上整个存储空间是PB级,那么路由信息可能达到GB级,那么master模块需要GB级的内存来管理路由信息.)
为了优化route,大部分分布式系统都会在块的物理视图上增加一个逻辑视图的管理层,这里就是Partition. 引入了Partition,就可以把路由信息从GB级别降到MB级别.大大提高Master使用效率.
3,一致性哈希(hash)
我们一般接触到hash还是挺多的,在Data Structure中,它本质就是一种利用桶排序作基层的原理,用空间换取O(1)的时间复杂度. 那么什么是一致性hash呢? 我们平常说的HashTable, HashMap 是一致性hash么?(常见都是不一致的)
首先,分布式系统好处很多,那么自然也有缺点,比如大量的磁盘容易出现节点故障的现象.那么一致性hash能很好的优化这种问题.关于什么是一致性hash,可看–> zhihu一致性Hash形象参考
作用:
原理:
为了让用户在访问数据能够比较均衡. 把原本的hash环,分为多个组(group).如上图中有3个分区组.不同的hash node可能对应相同的分区组.
在用户访问数据的时候,每块云盘对应都有一个唯一的disk id, 与用户请求发送的block id, 可以可以构成唯一的key,可以标识存储在CS上的某个数据块. 使用该key可以从hash环上定位到具体的hash node. 从而找到这个数据块属于的partition group. 包含了CS的IP,磁盘信息.
之前提到的数据块一般采用3副本存储到CS的不同3节点上. (2)中找到的这个数据块 包括了这3个数据块存储的CS ip跟磁盘信息,最后client 根据这些信息将I/O请求转发到指定的CS上,这样就实现了云硬盘的数据读取.
4.多副本冗余
这是云硬盘另一个关键技术,解决数据可靠性的问题.避免丢失损坏.底层为3副本存储,**要求3份数据严格一致.**那么如何保证呢? 这就要求分布式系统在写入的数据采用特定方案.
方案一:
比较好想的就是,像raid1的思路一样,把一份数据同时写到多份数据区,直接写延时低. 缺点: 网络压力大
方案二:
先把数据写到一块数据区,然后复制到其他两块. 把工作留给了后期.缺点是写延时比较高,毕竟等于是队列模式 (如图)
方案三: (推荐)
结合一与二的特点,折中考虑.可以让client跟主副本通信,然后由主副本同时向其他两个从复制.就像结合了Raid0+Raid1的感觉(只是说这种折中的方式.)如图.
5. 快速恢复
在整个分布式存储中,出现某个数据节点故障经常发生(多降级服务). 那么快速恢复的常见要求有:
- 不同数据故障场景需要采用不同的恢复策略 (因为全量恢复代价很高)
- 数据恢复的速度是衡量一个存储系统性能的重要标准.
常见问题:
- 底层硬件存储问题
- 网络问题
- 软件驱动问题
- 软件自身bug
比如一个服务器某一块4T的磁盘发生故障,考虑到网络与I/O平均速度,如果从副本复制是每秒50MB.都需要23h. 如果是整机都出现了故障,那时间就是23h*n(这台主机挂载的磁盘数)。 所以这基本是不可接受的。 很多软件或者网络的故障导致的问题,不需要全部替换。 而是采用增量恢复机制
增量恢复机制是指 : 某个节点出现故障的时候,我们可以对比主节点在故障发生与最近的一个时间节点的数据修改部分. (好比git可以看出当前版本与上一个版本的差别,可以简单理解为一次回滚.Kubernetes也采用了类似机制),这样做的优点不言而喻,时间成本极大降低.
增量恢复的策略: (如图)
之前提到过,一般分布式存储中最小的恢复单元是partition(包括很多底层物理block),每个数据块都有自己的序列号(block id.),在数据更新的时候,这个序列号也会自动增长.
如果这时候用户有新的写入请求,本来会写到3个副本.但是这时候如果有一个已经故障了,那么显然就不能再写到它的数据区了. 会先暂存在它的缓存区 Cache memory.(本身数据也是先经过缓存,才会写入磁盘).在进行数据恢复的时候,会由后台进程对比故障节点与主节点的序列号. 如果序列号相同就不用恢复.反之如果如图中所示,一个bid=3 ,另一个bid=4 ,这个时候就需要进行恢复.
6.数据迁移
有时候会出现不可抗力的因素或者不可逆的硬件故障,无法采用增量/快速恢复.这时候就要涉及数据迁移的问题了.更换物理设备时间太长.(就需要全量恢复)
7.快照
快照是容灾的一种非常重要的技术,就像win上做了个备份. 是恢复最快,最直接的一种容灾办法.
所以可知快照会占据部分空间,如何解决快照存储的问题.也涉及不同的方案.
方案一:
传统的思路,就在当前的存储区放快照. 缺点是,一旦整个区受到损伤,等于快照也丢失了.
方案二(推荐):
快照跟数据完全分离. 缺点是,又会增加一定时间跟带宽,恢复也比较慢,
快照创建的原理:
技术点: copy-on-write,多版本
在用户选择创建快照之后,会在后端启动一个进程,以块为单位,把用户的数据拷贝到快照单独的存储区.为了保证用户点击完创建快照,到实际创建完成的时间点一致.采用了下面的两个技术点.
用户只要创建了一次快照,用户的写入数据版本会自动增加,并且会分配新的数据块来进行保存,避免对原来的数据发生更改.从而保证时间点一致.由于快照进行分配也是以数据块为颗粒度. 而用户写不一定会覆盖整个数据块. 所以需要用户在第一次写操作的时候,将原来的数据块复制到新的数据块之后再实时进行修改.后台进程会负责把所有旧的数据块拷贝到快照存储区. 所以快照创建会显得很快.
快照恢复的原理:
通过bitmap检测当前写入块是否已经恢复,读写之前会先检查这个bitmap. 如果有冲突后台会阻塞用户当前I/O.
8. 持续数据保护
快照能在很短的时间内恢复到前一个时间点. 但是有个致命的缺点是在创建快照的时候,有个真空期(RPO窗口,这这期间是可能丢失数据的).那如果对高要求比如金融行业,为了避免这种问题.就需要引入CDP机制(Continuous Data Protection). 实现原理比较简单: 就是把所有用户请求同时发送到CDP系统.
接下来看看CDP系统的具体工作流程: (基于最初的图)
图中除了本身的存储系统备份,还引入了快照+CDP的冗余机制.(一般提供7days的精确时间点)
0x02.其他
运维+开发
对谁运维?
云存储 : 了解业务,对谁提供,了解用户的业务. 为内部业务提供(比如各种游戏,软件) 对外部业务提供,个人云盘存储等
需要了解这个业务在某段时间需要多少存储量,下个时间需要多少存储量,扩容缩容.视角要比较高,动态给业务的存储添加机器
需要足够的了解硬件,比如硬盘(转速,掉盘,乱盘,脏数据如何处理)
开发: 开发的东西是运维系统,专门用于调度,自动化收集日志,出现问题的时候
做成一个运维系统.上架下架.机器扩容.
建议巩固:
- OS(Linux)相关知识,存储相关原理
- python 与 shell 看得懂,要会写
- 硬件要足够了解 (硬盘,服务器)



















