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 回答