自建存储与使用微软Azure、七牛等第三方云存储综合考察分析

 http://www.cnblogs.com/sennly/p/4136734.html 

各类云服务这两年炒的火热，加之能够下降成本，公司想先在部分业务上尝试使用下，恰好最近有个项目有大量小文件须要存储，借着这个机会，研究分析下自建存储与使用第三方云存储，若是小规模试用后满意的话，会将更多的业务迁移到公有云上去。

通常而言存储功能咱们会关注方案的功能可靠性及综合使用成本两大方面。

功能可靠性包含：

Ø 服务稳定性

Ø 服务性能

Ø 服务可扩展性

Ø 数据安全性

综合使用成本包含：

Ø 存储设备费用

Ø 带宽费用

Ø 额外备份费用

Ø 后期维护费用

咱们下面从几个主要关注点来分析。

 

1. 自建存储的性能分析与预估

目前分布式文件系统用的较多的有MFS、TFS、FastDFS等，，TFS对运维同窗的要求比较高，须要对TFS自己有较多了解，且淘宝对外开源的版本不太稳定，这一方面咱们踩过坑。在咱们以往的项目中，MFS使用的较多，简单，方便，可经过Fuse直接挂载到系统中，对于不是很是大量的小文件存储很合适，有不足的地方就是其较轻量级，应付不了很密集的访问。

 

1.1. 测试环境

测试环境有5台机器作存储服务，1台Master，3台客户端，经过1000Mbps网卡相连。

名称	CPU	内存	硬盘
Master	8核 HT	32G	15K Raid5
Trunk	8核 HT	32G	15K Raid5
Trunk	8核 HT	32G	15K Raid5
Trunk	8核 HT	32G	15K Raid5
Trunk	8核 HT	32G	15K Raid5
Trunk	8核 HT	32G	15K Raid5
Client	8核 HT	32G	15K Raid5
Client	8核 HT	32G	15K Raid5
Client	8核 HT	32G	15K Raid5

 

1.2. 业务场景相关数值估算

Ø 上传图片用户数

咱们这个子项目目标用户量是2000万，所以以2000万为用户基数。因为没有有效的历史数据，所以在活跃用户估算、上传图片用户估算过程当中，咱们普遍使用80/20法则，以这种方法，估算出日活跃用户、上传图片用户数。

日活跃用户数：2000万X 0.2 = 400万

上传图片用户数：400万 X 0.2 = 80万

Ø 上传图片大小

咱们假设用户上传原图大小为2M

Ø 活跃时间分布

一样使用80/20法则，天天24小时中有大概16个小时是人的活动时间，咱们假设其中的20%时间用户发送图片且均衡分布，那么咱们计算出活跃时间为：16 x 0.2 =3.2小时。

1.3. 内存预估

在官方文档中咱们查到2500万个文件大概要占用Master Server 8G内存，由于MFS的技术架构全部文件的meta信息只能存储在Master Server中，所以不能平行扩展。业务上线初期，咱们计划子项目的存储系统须知足正常状况下1个月的需求，上传图片的活跃用户数为80万，每人天天上传1张图片，所需存储文件总数为：80万 X 30 = 2400万。

每用户天天平均上传1张图片内存预估

活跃用户/万	单用户天天上传图片数	时间区间/月	总文件数/万	内存/G
80	1	1	2400	8
80	1	2	4800	16
80	1	3	7200	24
80	1	6	14400	48
80	1	12	28800	96

若是咱们假设用户天天平均上传2张图片呢？将会有以下数据：

每用户天天平均上传2张图片内存预估

活跃用户/万	单用户天天上传图片数	时间区间/月	总文件数/万	内存/G
80	2	1	4800	16
80	2	2	9600	32
80	2	3	14400	48
80	2	6	28800	96
80	2	12	57600	192

即，咱们现有的32G内存的服务器，大概能够支撑前3个月。随着时间延长，所需内存愈来愈多，若是平均每活跃用户天天上传2张图片，那么1年以内须要一台256G内在的服务器。除可纵向增大服务器内存外，更靠谱的方式是进行业务拆分。

1.4. 存储预估

在这里，咱们一样以用户天天上传图片数及时间区间为变量分别计算。

活跃用户/万	单用户天天上传图片数	时间区间/月	文件大小	文件备份数	总文件个数	磁盘空间/T
80	1	1	2	3	2400	14.4
80	1	2	2	3	4800	28.8
80	1	3	2	3	7200	43.2
80	1	6	2	3	14400	86.4
80	1	12	2	3	28800	172.8
活跃用户/万	单用户天天上传图片数	时间区间/月	文件大小	文件备份数	总文件个数/万	磁盘空间/T
80	2	1	2	3	4800	28.8
80	2	2	2	3	9600	57.6
80	2	3	2	3	14400	86.4
80	2	6	2	3	28800	172.8
80	2	12	2	3	57600	345.6

 

1.5. 并发量预估

Ø 上传文件数每秒并发量

计算公式为：上传图片活跃用户数X天天上传图片数/天天活跃时长X3600

800000X1/3.2X3600 = 69.4

800000X2/3.2X3600 = 138.8

若活跃用户数天天上传1张图片，图片上传接口须知足至少每秒上传69.4个文件

若活跃用户数天天上传2张图片，图片上传接口须知足至少每秒上传138.8个文件

Ø 上传流量每秒并发量

计算公式为：上传文件数每秒并发量X图片平均大小

使用上面得出的上传文件数每秒并发量，图片平均大小为2，得出如下结果：

69.2X2M = 138.8M

138.8*2M = 277.6M

若活跃用户数天天上传1张图片，图片上传接口须知足至少每秒上传138.8M流量

若活跃用户数天天上传2张图片，图片上传接口须知足至少每秒上传277.6M流量

 

1.6. MFS性能测试

在咱们的测试环境中，5台Trunk Server，3台Client，千兆的交换网络，测试出如下结果。

双机并发测试

大小/M	个数	文件总大小	花费时间	速率个/秒	速率M/S
0.25	80000	20000	456	175	44
0.5	40000	20000	332	120	60
1	20000	20000	258.5	77	77
2	10000	20000	247	40	81

 

三机并发测试

大小/M	个数	文件总大小	花费时间	速率个/秒	速率M/S
0.125	240000	30000	1106	217	27
1	30000	30000	367	82	82
2	15000	30000	343	44	87

 

测试结果总结以下：

Ø 文件上传个数的速率与上传文件大小成反比，文件越小，每秒钟上传个数越多。

Ø 文件上传流量的速率与上传文件大小成正比，文件越大，每秒钟上传流量速率越大。

 

1.7. 理论数据与实验数据的对比

如今让咱们将上面理论估算出来的值与测试环境中所得结果作一对比，主要看每秒钟上传文件个数与流量速率。

Ø 每秒钟上传文件个数

天天上传1张图片理论需求：69.4

天天上传2张图片理论需求：138.8

实际能力：44

Ø 每秒钟流量速率

天天上传1张图片理论需求：138.8MB

天天上传2张图片理论需求：277.6MB

实际能力：87MB

注意：

以上只是单纯的上传测试，在实际生产环境，是读/写混合操做，读的数量会大大多于写操做，所以以上所获得的值为理论极大值。实际业务不会是平均分布，每每会有大的短时并发。

 

1.8. 业务解决方案

MFS具备简单易用的优势，但因其较轻量级，存在着一些缺陷。经过以上的估算及测试，咱们会发现单一的MFS彷佛不能知足咱们基本业务须要，若是条件容许，则须要对业务进行切分，每一个集群只应对一块业务，以减缩业务量，而切分的依据则可根据本文中得出的相关数据。

 

2. 自建MFS存储的测试数据

2.1. 1MB文件写入

1M文件写入，4台客户端执行，共12GB数据，数据备份数为3

客户端 花费时间

192.168.1.159 145

192.168.1.111 150

192.168.1.167 147

192.168.1.66 141

结果：每秒写入速率为82m/s，写入文件个数速率为：82pcs。

2.2. 128KB小文件写入

128KB文件写入，4台客户端执行，共12GB数据，数据备份数为3

客户端 花费时间

192.168.1.159 271

192.168.1.111 309

192.168.1.167 339

192.168.1.66 386

结果：每秒写入速率为37.7m/s，写入文件个数速率为：294pcs。

2.3. 1m文件读取

1m文件读取，4台客户端执行，共12GB数据

客户端 花费时间

192.168.1.159 61

192.168.1.111 157

192.168.1.167 113

192.168.1.66 137

结果：每秒读取速率为105m/s，读取文件个数速率为：105pcs。

 

2.4. 长时稳定性测试

1M文件写入，4台客户端执行，连续写入测试 14.5小时 写入文件4T 速度为 80.35m/s

3. 自建存储系统的成本估算

如下以使用MFS自建存储服务为例，核算其使用成本。假设将来业务的规范以下：

Ø 平均文件大小 2MB

Ø 文件数量 1000万

Ø 每日上传数量 100万

 

3.1. 需求计算

Ø 存储需求

存储大概须要2T空间，若是使用3份冗余的话，则须要6T空间。

Ø 带宽需求

根据2/8原则，将全天访问量的80%（100万X2X0.8），分布于20%的时间（24X0.2=4.8小时），所以计算出带宽需求为：93MB/S。

 

3.2. 自建存储服务器的预计成本

Ø 服务器及硬件

包含三台存储服务器，1台Web服务器（兼图片处理及视频处理），此处未作服务器的高可用及单独的计算模组，最低综合成本为：2万X4=8万

Ø 服务器托管费

以BGP机房的通常价格8000元/年/台，计算，则一年期的服务器托管费为：8000X4=3.2万

Ø 带宽费用

因为需求计算中所需带宽为93MB/S，所以咱们至少须要1G带宽，以每100元/Mb/月价格计算，则一年期带宽费用为100X1000X12=120万

Ø 人力及维护成本

以维护人员薪资8000/月计，此人员每一年平均使用20%的精力维护此组服务，则整年人力及维护成本为：8000X12X0.2=2.4万

经综合计算，自建存储服务器最低成本为：8万+3.2万+120万+2.4万=133.6万 ，由于不能按需使用，所以只能按照规划容量购买资源。

还有一种方式为使用普通机房的带宽（如东莞的资源），带宽便宜，20元/Mb/月，外加CDN加速，因为带宽主要仍是在CDN上，而CDN价格通常在100元/Mb/月，所以价格不会少，反而可能会多。

 

4. 使用第三方云存储方案对比

目前在国内市场作云主机的基本都有专门的存储系统，在本方案中，只侧重于存储方面，而不涉及云主机及其它服务。咱们以前在挑选存储合做伙伴时，作了一个对比表格：

其实在通过技术指数对比后感受七牛云比较适合咱们的应用，专门作存储，支持功能多，文档清晰价格也还能够。但后来经朋友介绍，了解到微软Azure已经在中国大陆运营，运营方是鼎鼎大名的世纪互联，所以又分配了些人力对微软Azure的云存储作了调研，综合分析后得出结论：微软的云存储更适合咱们。

4.1. 成本对比

七牛云收费的大头在流量，而存储自己占用的比例很小，只有10%左右；微软Azure的存储使用成本与七牛云不一样，其带宽成本低，每月前20T流量免费，而存储自己成本高，1T的存储每月须要1000元左右，若是将这个项目的所有数据放在Azure上的话，费用很是吓人，但与运营的同事咨询后得知咱们这个项目所上传的文件在一小段时间后是能够删除的，存储的文件最多也是2T，每个月存储成本在2000元左右。通过咱们计算在控制文件存储数量的状况下，微软Azure的使用成本会更低。

4.2. 资源优点对比

Windows Azure由世纪互联运营，拥有北京、上海的顶级骨干机房，咱们有作长期监控测试，网络质量很是好，再加上微软的技术实力及大规模的运营团队来作服务保障，服务质量可以获得保障。而七牛云，虽然其功能完整且使用也方便，但其各项网络及硬件资源可能没法与世纪互联相比，所以为了保障业务后续的稳定性，咱们更倾向于使用Windows Azure的存储。

4.3. 七牛云的SLA服务质量保证

咱们特地查看了七牛云的服务条款，对于SLA服务质量有以下描述，感受服务质量级别不高。

Ø 数据安全

您了解七牛云存储没法保证其所提供的服务毫无瑕疵（如七牛云存储安全产品并不能保证您的硬件或软件的绝对安全），同时七牛云存储承诺不断提高服务质量与服务水平。因此您赞成：即便七牛云存储提供的服务存在瑕疵，但上述瑕疵是当时行业技术水平所没法避免的，其将不被视为七牛云存储违约。您赞成和七牛云存储一同合做解决上述瑕疵问题。

数据备份系您的义务和责任，七牛云系统具备数据备份功能不意味着数据备份是七牛云存储的义务。七牛云存储不保证彻底备份用户数据，亦不对用户数据备份工做或结果承担任何责任。

您理解并充分承认，虽然七牛云存储已经创建（并将根据技术的发展不断完善）必要的技术措施来防护包括计算机病毒、网络入侵和攻击破坏（包括但不限于DDoS）等危害网络安全事项或行为（如下统称该等行为），但鉴于网络安全技术的局限性、相对性以及该等行为的不可预见性，所以如因您网站遭遇该等行为而给七牛云存储或者七牛云存储的其余用户的网络或服务器（包括但不限于本地及外地和国际的网络、服务器等）带来危害，或影响七牛云存储与国际互联网或者七牛云存储与特定网络、服务器及七牛云存储内部的通畅联系，七牛云存储可决定暂停或终止服务。

Ø 终止协议

七牛云存储可提早30天在七牛官网上通告、给您发网站内通知以及邮件通知的方式终止本协议。届时七牛云存储将您已支付但未消费的款项退还您指定的银行帐户或其它可收款帐户。

Ø 服务质量及赔偿

您理解，鉴于计算机、互联网的特殊性，下述状况不属于七牛云存储违约：七牛云存储在进行服务器配置、维护时，须要短期中断服务；因为互联网上的通路阻塞形成您网站访问速度降低；

若是因七牛云存储缘由形成您不能正常使用七牛云存储服务的，七牛云存储以小时为单位向您赔偿损失，即连续达1小时不能正常提供服务的，延长一小时的服务期（以此类推）。若是因七牛云存储缘由形成您连续72小时不能正常使用服务的，或因七牛云硬件故障而给您形成损失（非因七牛云存储过错形成的故障除外），您能够终止接受服务并能够要求赔偿损失，但非七牛云存储控制以内的缘由引发的除外。

在任何状况下，七牛云存储均不对任何间接性、后果性、惩戒性、偶然性、特殊性的损害，包括您使用七牛云存储服务而遭受的利润损失承担责任（即便您已被告知该等损失的可能性）。

在任何状况下，七牛云存储对本协议所承担的违约赔偿责任总额不超过向您收取的违约所涉服务之年服务费总额的25%。

 

4.4. 微软Azure的SLA服务质量保证

咱们保证至少在 99.9% 的时间，咱们将成功地处理请求以便读取来自读取访问地域冗余存储 (RA-GRS) 账户的数据，只要在辅助区域上重试从主区域读取数据的失败尝试。 咱们保证至少在 99.9% 的时间成功地处理请求以便从本地冗余存储 (LRS)、区域冗余存储 (ZRS) 和地域冗余存储 (GRS) 账户读取数据。 咱们保证至少在 99.9% 的时间成功地处理请求以便将数据写入本地冗余存储 (LRS)、区域冗余存储 (ZRS) 和地域冗余存储 (GRS) 账户，以及读取访问地域冗余存储 (RA-GRS) 账户。

咱们在网络上找寻了一些资料，有以下描述：

Microsoft Azure在全球从没有丢失过数据，在中国提供3*2的备份，在上海和北京两地各三份备份。第二是微软的云计算有混合的优点，不管是私有云、公有云等，微软均可以提供无缝的对接，包括开发环境、框架、安全、身份认证等。第三是承诺，微软有技术、大规模运营的经验，了解中国对标准政策的法律法规，花费很长时间储备、创建研发团队，寻找合做伙伴，建设数据中心，要作到无缝的运营、保证较高的稳定性和质量是很难的。由世纪互联运营的Microsoft Azure提供99.95%的企业级服务等级协议（SLA）保证，每一年停机检修时间不超过4.38小时，用户能够放心构建和运行高可用的应用程序，而没必要担忧将经历放在基础架构上。

 

5. 咱们的选择

使用自建存储服务器，因为不能弹性使用且没法合理预估使用量，所以签合同时通常状况下只能按较大需求来购买资源，一年的使用成本为133万左右，且须要熟悉分布式存储的成熟的运维团队来维护，自如建的成本更高。而使用第三方的云存储，则须要考虑的方面更多些，除了要考虑功能性是否知足外，更重要的是稳定性、安全性以及品牌成熟度，毕竟管理层一般会认为大品牌的产品质量更有保证些。经过此次考查及分析，咱们认为微软Azure的云存储会更适合咱们，虽然在咱们这个子项目活跃用户数达到1000万之后其花费花更多一些。所谓合适，其实就是某种程度上的折衷，适合咱们的才是最好的。

http://www.cnblogs.com/sennly/p/4136734.html