云存储系统需求分析.doc

大数据存储需求
管理需求
l 动态添加删除用户
l 用户容量控制
l 用户流量，网速控制
l 用户副本灵活配置
性能需求
l 响应时间
l Iops指标
l 吞吐量指标
稳定性
l 24小时无故障服务
l 大数据量情况iops指标无明显变动
l 大数据量下吞吐量指标无明显变化
l 系统负载在一定阀值下服务
l 监控系统完善主要是对cpu，内存，网络，io
容错高可用
l 在无自然灾害性的真个机房出现故障的情况下24小时服务
l 系统奔溃后可恢复服务
l 容灾备份
可扩展性
l 支持在线横向扩容
l 支持在线纵向扩容
l 节点自动感知

数据格式支持
l 二进制小文件
l 图片文件
l 视频文件
l 大文件
l 大文件随机读
l 大文件随机写（不容易实现）
接口
l 大小文件支持类posix的接口
l 支持rest接口（前期不一定实现）
l 最好能支持读写分离的锁
测试
l 写测试
l 随机写测试
l 读测试
l 随机读测试
l 并发读写测试
l 上量读写测试
l 测试平台

分布式测试平台本质是一个必行任务系统，可以有多种的实现方式，原理如下如

由控制节点发出测试开始的指令，测试机根据挂载的测试任务，进行并发测试，结束后，将结果返回给任务分发机器，经过统计，返回给测试任务控制机
实现方式：
l 使用自动化测试框架（未使用过）
l 自写并行任务分发系统，进行测试
l 利用hadoop等开源软件进行测试，入mapreduce，可以再map中进行测试任务，由reduce汇总测试结果，reduce个数设置成1
整体框架
灰色表示第一版本不需要实现的部分，现在需要是先的部分部署的部分主要是在分布式存储和开放服务以及上层的接口

图片应用需求
l 创建用户
l 创建命名空间，即文件夹
l 创建操作员，该操作员只能操作指定的用户空间
l 上传，下载，删除，获取图片属性，清除缓存
l 图片类型识别，动态转换
l 设置图片特有格式 如http请求http：//
l 每一个命名空间可以有不同的格式限定
l 实时性保证 为支持如相册
实现方法
根据图片的特性和和应用，图片存储主要是得结构是如下

其中黑色线条表示在实现中可不必实现。例如，某张图片原图格式是jpeg，1024*768大小，在请求是的时候请求的是200*100的大小，请求图片存储时并没有需要的的大小，需要经过转换，缓存服务拿到原图，在图片处理服务处理后，将处理后的图片缓存在本地的缓存中，因为这类的请求，并不是持久性的请求，比如客户页面在更改，第一版按照200宽的等宽显示，两天后，客户页面修改，将缩略图改为300等宽，这样，如果存储到图片存储中，因为前端的修改，图片请求的格式在不断的变化，如果存储起来，会浪费很多存储空间，这种变化的可能会导致存储的数十倍的浪费

分布式系统
分布式系统是需要的，主要是两个方面，第一是自动进行冗余备份，其次是提供动态扩容的方便，选择合适的分布式系统是比较好重要的
前置机
在图片存储服务，甚至大部分的文件存储服务中，读写的差异很大，读写请求的数量差异也很大，一张图片，写次数屈指可数，读的次数多大千万次，读服务请求的数量也很多，读写请求的完成质量也有差异，写请求失败，数据很有可能丢失，或者造成一段时间内整体读服务不能完成。而读请求失败一次，影响却很小，可以通过其他节点，或者备份节点弥补，
所以在上面的架构体系统，将读写请求分开以前置机来出来。
方案
Tfs或者fastdfs
这个用作用图片存储的优点是这两个系统开发意图就是为了图片存储，也为图片存储做了大量的优化，对大量小图片的支持很好，访问速度，稳定性，数据一致性保证都很好。都不需要二次开发，直接可以使用，并且提供了nginx的模块，可以很容易配置http访问方式。
缺点是都不支持posix类接口，实质是属于key-value类型接口
在作为云端存储的时，需要在外围做大量的开发工作，维护user-namespace-pic的关系
使用如kv方式存储
底层是用大型的分布式文件系统，上层是用key-value存储存储文件的方式也可以对百亿级别的图片文件进行存储，但是文件需要经过切片进行存储，如果切片大小4k，常规图片的大小是20k左右，比如图片是21k，可以通过将图片文件切成4k固定的大小，分prefix+0-6的方式存入key-value存储中，并且将相应的图片数据存入对应的顺序的key中，在读取图片的时候，将6个key取出，按照顺序组个数据，即可还原图片。
Kv方式也可以是用bitcast方式存储文件，即图片存在文件里，kv只存储文件名到元数据的以及数据位置的索引，但是在合并时需要做额外很多的处理，比如图片的删除，需要从kv中删除，并且从数据文件中删除图片的那段数据，合并需要额外的调度，kv系统的自动合并并不能满足需求

大文件存储需求
l 副本数个性设置
l 多用户请求支持
l 随即读支持，支持客户端请求文件内任意位置任意长度的数据
l 断点续传功能
l 校验功能
大文件存储的几个问题
文件分块
支持文件分块，为随即读提供分块机制，可以多副本情况下，可以提供多机并行读取，副本可在集群中自动分配，并自我修复，如果出现某台服务器宕机，副本可以再其他机器复制副本，保证数据的安全和向外提供服务的性能
支持追加
对某些大文件，可能客户未必会一次性的将数据全部传送到服务器上，需要恢复上一次的传输状态，这样就需要一个端点续传，即追加功能的实现，对并行的断点续传暂时先不考虑
安全校验
因为要支持追加模式的存储，为了保证数据的完整性，要对文件的内容保证是完整的，通过对文件的md5或者sha1等校验方式，保证上传的文件与源文件的一致性
性能要求
为了使数据能及时达到前端的缓存，底层的文件系统，需要对性能有一定的要求，如果前端节点是100，那没上传一个文件，在相同的时间内，需要有将数据分发到一定数据节点的能力，甚至更高。因为中心存储，做数据持久化存储，前端缓存节点，可能会在一定周期内淘汰冷数据，比如说一个设置不当，某几个节点，在拿到5g的iso镜像文件后，一小时后从存储中淘汰，而两小时后又有用户请求从该节点请求文件，并且cdn调度该节点做缓存，该节点需要从中心存储中取出 文件，缓存。则中心节点，需要能应对这样的请求。
支持并发请求
同时的多客户端接入，必须支持多客户端同时相应请求，负责会有客户端饿死，处于性能的考虑，尽量让一个文件，分布在多个磁盘，server上，保证性能。Gluster比如是有两个副本，10个客户同时请求，每个请求的数据段也不同，因为gluster是按照源文件存储，对这种访问，存储服务器只能不断的根据请求的顺序，不同进行磁盘寻到，不能充分利用多磁盘带来的性能提升。即使是私有数据格式的文件分块方式，也存在这种问题，只能是尽量减少寻到次数，尽量降低寻道时间
文件大小限制
对没有私有数据格式的文件存储，文件按照原有的数据格式进行存储，这样的文件会有大小限制，受限于磁盘的大小，gluster现在是我们重点攻关的项目，在这方面就存在磁盘大小的限制
一些块存储系统，如hdfs等文件系统，则不会出现文件大小限制问题，因为本身hdfs不受制于磁盘大小的限制，受制于namenode节点内存的限制，如果文件很大，倒是内存存不下inode，会导致文件无法存下去。
文件大小限制并不是一个很棘手的问题，因为现阶段，服务器磁盘都是用2T的磁盘，单个磁盘容量已经足够大， 很少有能突破这个极限的大文件存在。
响应时间
对单个一个range请求，响应时间不宜过长，按照常规的说法，应该在10ms以内。
流量控制
对客户端做流量控制，如上海节点可能网络状况较好，一段时间内，请求大量数据，占用大带宽，导致新疆节点一直在排队请求，得不到数据，对新疆节点的服务造成影响。
测试

测试Gluster