28

如此多的选项,而测试它们的时间却如此之少......我想知道是否有人对用于视频流和存储/编码的分布式文件系统有经验。

我有很多巨大的视频文件(50GB 到 250GB)需要存储在某个地方,能够将它们编码为 mp4 并从多个 Adob​​e FMS 服务器流式传输它们。处理这一切的唯一方法是使用分布式文件系统,但现在的问题是哪个?

到目前为止,我的研究告诉我:

  • Lustre:成熟成熟的解决方案,被很多大公司使用,最好是大于 10G 的文件是内核驱动程序。
  • Gluster:新的,不太成熟的,基于 FUSE 的,这意味着易于安装,但由于 FUSE 开销可能会更慢。更好地处理大量较小的文件 ~1GB
  • MogileFS : 似乎只适用于小文件~MB,使用 HTTP 访问??未来可能的 FUSE 绑定。

到目前为止,Lustre 似乎是赢家,但我想听听我所拥有的特定应用程序的真实体验。

Hadoop、Redhat GFS、Coda 和 Windows DFS 听起来也可以作为选项,因此欢迎任何体验。如果有人有基准,请分享。

经过一些实际经验,这是我学到的:

  • 光泽:
    • 性能:惊人的快!我可以断言 Lustre 可以提供大量流,并且编码速度不受通过 Lustre 访问文件的影响。
    • POXIS 兼容性:非常好!无需修改应用程序即可使用光泽。
    • 复制、负载平衡和故障转移:非常糟糕!对于复制负载平衡,我们和故障转移需要依赖其他软件,例如虚拟 IP 和 DRDB。
    • 安装:最糟糕的!普通人无法安装。需要内核、光泽补丁和调整的非常特定的组合才能使其正常工作。而当前的 luster 补丁通常适用于与新硬件/软件不兼容的旧内核。
  • MogileFS:
    • 性能:适用于小文件,但不适用于大中型文件。这主要是由于 HTTP 开销,因为所有文件都是通过 HTTP 请求发送/接收的,这些请求将所有数据编码为 base64,为每个文件增加了 33% 的开销。
    • POXIX 兼容性不存在。所有应用程序都需要修改为使用 mogilefs,这使得它无法用于流式传输/编码,因为大多数流式传输服务器和编码工具不理解 MogileFS 协议。
    • 通过一次访问多个跟踪器,可以在应用程序中实现开箱即用的复制和故障转移以及负载平衡。
    • 安装相对容易,大多数发行版中都存在现成的软件包。我发现的唯一困难是设置数据库主从以消除单点故障。
      • 光泽:
    • 性能:对流媒体非常不利。在 10Gbps 网络中,我无法达到超过几 Mbps。客户端和服务器 CPU 因大量写入而猛增。对于编码工作,因为 CPU 在网络和 I/O 之前就已经饱和。
    • POXIS:几乎兼容。我使用的工具可以将 gluster 挂载作为磁盘中的普通文件夹访问,但在某些边缘情况下,事情会开始导致问题。检查 gluster 邮件列表,你会发现有很多问题。
    • 复制、故障转移和负载平衡:最好的!如果他们真的工作。Gluster 是非常新的,它有很多错误和性能问题。
    • 安装太容易了。管理命令行非常棒,在多台服务器之间设置复制、条带化和分布式卷再简单不过了。

定论:

不幸的是,结论是“没有银弹”。

目前,我们将 Gluster3.2 中的媒体文件放在一个复制卷中,用于存储和转码。只要您没有很多服务器,就可以避免异地复制和条带卷。

当我们要流式传输媒体文件时,我们将它们复制到一个光泽卷,该卷通过 DR:DB 复制到第二个光泽卷。然后 wowza 服务器从 luster 卷中读取媒体文件。

最后,我们使用 MogileFS 在我们的 Web 应用程序服务器中提供缩略图。

4

5 回答 5

5

迄今为止,GlusterFS 对自己进行了很大改进。他们现在为大文件提供“粒度锁定”。请参阅此处:http ://www.gluster.org/community/documentation/index.php/WhatsNew3.3 此外,它也非常依赖于您应该工作的视频帧速率。如果您无法达到 4K 速率,Gluster 可以解决存储问题。如果对速度有巨大的需求,那么 Infiniband 可以发挥作用。

于 2012-10-02T12:36:16.243 回答
2

MogileFS 非常适合这类事情。客户端库的质量略有不同,但如果没有使用几乎任何语言访问它的大型生产站点,我会感到惊讶。

HTTP 实际上是一个很好的协议。谁没有功能丰富且高效的 HTTP 客户端?

于 2009-10-31T04:13:54.110 回答
2

查看 Hadoop 文件系统 (HDFS)。它的重点是非常大的文件和并行任务计算(使用 map/reduce),它具有高延迟但非常高的吞吐量。它目前用于 Facebook 和 amazon.com 等大型设施

于 2009-10-06T17:51:58.607 回答
1

Map-reduce 对 90/10 的写入/读取比率没有帮助!恒定的文件大小是一件好事,而且文件很小。因此,MogileFS 听起来是作为 Lustre/Gluster 的不错选择 - 缓存情况不合适。

于 2009-11-03T08:59:21.937 回答
1

在命名系统中,最合适的是 MoglieFS。

但也许你可以完全不使用任何特殊系统。假设您有 4 个 Adob​​eFMS 服务器:

{video0.exmple.com,video1.exmple.com,video2.exmple.com,video3.exmple.com}.

您可以使用简单的方案在这 4 个服务器之间分发所有视频,例如

    /*
     *  pseudo code
     */

    $server_id = get_server_id(filename);
    ...
    ...
    int function get_server_id(filename) 
    { 
       return hash(filename) mod 4;
    }

对视频进行编码后,您的应用会

$server_id = get_server_id(file_name)
copy file_name to /mnt/$server_id/

客户端将使用类似http://videoN.example.com/filename.mp4的方式访问视频,其中 N 是使用get_server_id().

Lustre/Gluster 真的不是你应该寻找的。Lustre FS比较成熟,但是开发者要求你把这种FS上的文件当作“缓存”,即随时可能丢失。

Lustre/Gluster 的目标是在 HPC 中使用,以允许快速访问大量数据,而没有单个存储服务器成为性能瓶颈。这些系统的另一点是它们符合 POSIX 标准。在 HPC/科学研究环境中,您通常没有时间重新编写应用程序,因为您安装了新的酷而快速的 FS。

于 2009-09-01T01:16:15.067 回答