自建存储与使用微软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