从集中到分布，解读网络视频IT架构变迁(下) - 业界

从集中到分布，化解存储瓶颈
接上篇：从集中到分布，解读网络视频IT架构变迁(下)。集中式存储已经拥有了诸多优势，那么为何这家视频网站最终却选择了其他的存储架构呢？该视频网站究竟在运营过程中遭遇到了什么样的阻碍呢？经过我们对整个网站存储结构的分析，原来，NAS头成为整个存储环境的瓶颈……

NAS成为系统瓶颈

传统集中式存储的瓶颈

从以上两幅图中，我们可以看到传统的集中存储方案中，存在如下问题：

 I/O瓶颈
 容量扩展性差
 性能不可扩展
 专业高端NAS成本高昂
 单点故障

随着数据量的增加，存储压力也变得越来越集中，NAS已不足以支撑现有的应用，无法更好的应对未来的挑战。既而，该网站从集中式的存储方式转向了采用分布式的存储方式。

分布式存储系统架构

图中，每台服务器上都提供文件共享服务，由应用层来实现媒体资源数据在各个服务器集群之间的迁移，从而比较好的解决了集中存储的IO瓶颈问题，但是问题也随之而来。

分布式的存储没有负载均衡，例如：发生热点的时候、部分流媒体服务器忙或部分闲置

分布式存储利用相对较低率，重复数据大量存在，且份数多

无法实现集中的高Raid 级别保护

快照、备份、恢复、远程容灾比集中存储实现成本高

需要在应用层对存储层过多关注。管理复杂度程几何级增长，整体系统维护工作越来越复杂、繁重。以管理Mount点为例：同样的服务器数，需管理Mount点的数量为48 [M*(N+F)+W*N]个，即上图中的48根红线，远大于集中存储结构。这仅仅是Mount点一项，还不包括各个点存储数据的维护，在实际应用中相关的工作量是相当惊人，管理员疲于奔命。

集中VS.分布？还是分布式的集中？

既然传统的集中和分布都存在不同的问题，怎么样去解决？在给出答案之前，我们重新归纳前面分析的视频网站对存储的需求：

1. 各种服务器集群之间有视频传递的需求，需要上传服务器、流媒体服务器、在线录制服务器和转换服务器之间的视频文件是互相可见的，翻译成存储的语言则需要文件级共享的存储。

2. 各种应用服务器可能使用着不同的操作系统平台，都需要无差异的访问到存储空间，而翻译成存储的语言则需要跨平台共享的存储。

3. 多台流媒体服务器之间的存储容量需要共享，从而提高存储空间的利用率。如采用传统SAN上面划分独立的存储空间，给每台服务器的类似做法显然是不可接受的，并且需要视频内容合理的分布在各个存储设备上，翻译成存储的语言则需要存储容量的负载均衡。

4. 单台存储设备的存储速度始终是有限的，需要多个存储设备的聚合才能满足视频内容访问量的爆炸式的增长，翻译成存储的语言则需要多台存储设备间的存储速度的聚合，从而实现存储速度的负载均衡。

5. 新增视频内容的不断添加会导致存储容量的不断扩大，在添加设备扩展容量的时，能够不影响原有系统，且平滑扩展，能够实现在线的扩展业务系统不停机，翻译成存储的语言则需要容量线性可扩展，能够实现在线扩容。

6. 随着用户访问量增长和视频清晰度提高带来的带宽增长等诸多增长因素的影响，对存储带宽的增长需求，要求存储系统实现带宽随容量呈线性增长。

7. 合理的成本控制是一个恒久的话题，需要存储系统的总体拥有成本随容量的扩展而合理的扩展，不能出现突变式的增长。

8. 稳定性自然不用说，需要存储系统采用冗余结构以提高系统的稳定性。

为了满足上述需求，当我们面对“集中VS.分布”这个艰难抉择的时候，技术的不断进步，涌现出：分布式的集中存储结构——集群存储技术，其核心技术是集群文件系统。

集群存储系统满足视频行业服务需求
目前，广为流行的集群文件系统的典型代表主要有：

 Google 的GFS （Google File System）
 国内中科院研发的BWFS（Blue Whale File System）
 Panasas 的PanFS （PanFS File System）
 IBM 的 GPFS （General Parallel File System)
 CFS 的 Lustre （Lustre File System）

这五种集群文件系统各有特点和优势，一般而言，分布式集中存储相对于传统存储系统来说拥有如下优点：采用统一的全局命名空间，支持文件级共享，且采用分布式存储结构，能实现高聚合I/O带宽，并且跨Linux平台和Windows平台的文件共享，还能够线性扩展I/O带宽，拥有良好的系统负载平稳性，并能够动态扩展存储容量，实现成本可控。