Video 光泽、胶粘色或胶粘色？？用于视频存储、编码和流媒体

这么多的选择和这么少的时间来测试他们所有。。。我想知道是否有人对用于视频流和存储/编码的分布式文件系统有经验

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

到目前为止，我的研究告诉我：

• Lustre：许多大公司都使用成熟的经验证的解决方案，最好使用>10G文件的是内核驱动程序
• Gluster：新的、不太成熟的、基于保险丝的，这意味着易于安装，但可能由于保险丝的开销而较慢。更好地处理大量较小的文件~1GB
• MogileFS：似乎只适用于~MB的小文件，使用HTTP进行访问？？未来可能的保险丝绑定

到目前为止，Lustre似乎是赢家，但我希望听到我在特定应用中的真实体验

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

经过一些实际经验，我学到了以下几点：

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

最后结论：

不幸的是，结论是“没有一颗银弹”

目前，我们在Gluster3.2中的媒体文件位于一个复制卷中，用于存储和转码。只要你没有太多的服务器，就要避免地理复制和条带卷，一切正常

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

---

最后，我们使用MogileFS在我们的web应用服务器中提供缩略图。

从命名系统中，最合适的是MogileFS

但是，也许你可以通过任何特殊的系统。假设您有4台AdobeFMS服务器：

{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/

客户端将使用类似的方式访问视频，其中N是使用

get\u server\u id（）

从文件名计算出来的

Luster/Gluster确实不是您应该寻找的。Luster FS更为成熟，但开发人员要求您将此类FS上的文件视为“缓存”，即它们随时可能丢失

---

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

查看Hadoop文件系统（HDFS）。它的重点是非常大的文件和并行任务计算（使用map/reduce），它有很高的延迟，但吞吐量非常高。它目前被用于Facebook和amazon.com这样的大型安装上

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

---

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

Map reduce在90/10的写/读比率方面没有帮助！ 恒定的文件大小