多年来人们一直将存储视为完成集群设计后才要考虑的某种问题,但随着 HPCC 的发展及其在公司整体战略地位的提升,存储变得越来越重要,常常在集群设计之初就要加以考虑。对于简单的、较小的集群来说,存储也是很简单的;但较大或较复杂的系统,存储的复杂度不逊于集群的其他部分。

集群几乎都需要有共享文件系统,使节点可以“看到”同样的文件。这种允许节点读取同一文件和/或向同一文件写入内容(通过 NFS 让多个节点同时向同一文件写入内容是很危险的事,但是可以做到)。所以共享文件系统几乎是集群的必备部分。

HPCC 存储剖析

为了更好地讨论 HPCC 存储,让我们首先看一个 HPCC 存储系统基本组成的示意图。下图 1 是一个完整 HPCC 存储系统的基本布局图。


 
Storage Media 存储媒体
Data Server(IO nodes) 数据服务器(IO 节点)
Data server network 数据服务器网络
Storage Network 存储网络
Client Network 客户端网络
Client  客户端
Network 网络

图 1 从左到右,我们首先可以看到一个通过存储网络连接到数据服务器的真实存储媒体。这些数据服务器有时被称为 IO 节点,它们任务是把文件系统“献”给客户端。这些 IO 节点通过一个数据服务器网络连接到客户端网络。在几乎所有情况下,数据服务器网络和客户端网络是一样的。客户端是通过一个客户端网络连接到主网络的。大部分情况下,数据服务器网络和客户端网络是一样的。最后,并行文件系统在客户端和数据服务器(IO 节点)上运行。文件系统通过存储网络与存储媒体通信。

这幅示意图展示的是最极端的情况,即构成 HPCC 存储解决方案的大部分“组块”,很多解决方案只有这些组快的子集。让我们看一些可能的 HPCC 存储解决方案。

NFS

打造集群的先决条件之一就是 NFS(NetworkFileSystem,网络文件系统)。它是唯一的标准共享文件系统。它允许分配式计算机共享数据,从而使并行应用程序读取且向同一文件写入内容。因为它是一个标准,所以可令有不同操作系统或不同版本操作系统的系统都共享相同的数据。

以图 1 为参考,我们能让大家更容易明白 NFS 是什么。存储网络其实就是数据服务器中的 PCI 母线。换句话说,存在数据服务器内置或外挂驱动器。虽然并不总是这样,但这是最常见的配置。一个 NFS文件系统只有一个数据服务器,有时我们将其称为 filer head(文件管理器头)。主节点也可以是数据服务器。数据服务器连接到客户端网络。下图 2 是一个 NFS 结构。

 

图 2 - NFS 结构Storage 存储媒体

Data Server(Many times the master node) 数据服务器(大部分是主节点)
Data server network 数据服务器网络
Client Network 客户端网络
Client Network 客户端网络
Client  客户端


工作站、桌面、服务器和集群中使用 NFS 的历史已经很久了。它是人们众所周知的文件系统,每天都有很多人在用。NFS 原版 (NFSv2) 的发布时间在 1980 年左右。它使用 UDP 作为数据传输协议。NFSv2 自由配置版由加州大学伯克利分校发布;下一代 NFS、NFSv3 在 1995 年左右发布,增添了 TCP 作为 NFS 的协议;近年来,在 2003 年左右,NFSv4 增添了协议的安全性。

不过,NFS 仍有一些局限性,其中一个主要限制是 NFS 文件系统只有一个服务器,所有从计算节点出来的 IO 都必须经过这个服务器,从而形成了瓶颈。一般来说 NFS 服务器是通过一个类似于计算节点(如GigE、IB、Myri-10G)的链路连接到集群网络上的。如果 N 个计算节点全部向同一服务器写入内容,该服务器又同样连接到集群网络,也可能造成瓶颈。不过,大多数并行应用程序的 IO 模式不会苛刻到要求所有节点同时写入的地步。

还有一个人们经常会忘记的问题,即 NFS 难以支持多个客户端同时向同一文件写入内容。关于 NFS 的更多详细说明,请阅读以下链接

大多数并行程序都有一个所谓的“根”进程(优先级为 0 的进程)来执行该应用程序的所有 IO。这就意味着节点群中正在运行该应用程序的首个节点执行了所有 IO。所以真正向 NFS 服务器执行 IO 的节点数少于计算节点数。所以,NFS 是非常适合一定规模的集群使用的文件系统。“一定规模”的定义取决于很多因素,但是现在已有含 200 至 300 个节点的集群非常成功的运行 NFS 案例。但是经验法则告诉我们,NFS 对于节点数不超过 64 至 129 左右的集群来说非常合适。

分配式并行存储

不过也有需要使用并行文件系统的时候。这些情况包括:

  • 较大的集群
  • 集群运行的应用程序要求有大量共享 IO(通常是并行 IO)
  • 要求性能和容量的可扩展性都很大的解决方案

在这些情况下,一个 NFS 解决方案是不够的。在这些情况下,我们需要一个分布式并行存储系统。不过大致说来,这种系统的复杂性比 NFS大很多。

构成分布式并行存储系统不需要图 1 中的所有“组块”,具体需要哪些视解决方案而定。从 NFS 跃到分布式并行文件系统不是件简单的事。请您务必事先做好计划并部署测试系统,弄清所有问题,掌握调节最佳性能的办法。

有数种可用的分布式并行存储解决方案。我们可以把它们分成两组;传统基于块的存储和基于对象的存储。属于基于块存储的有:

  • IBRIX
  • GPFS
  • GFS
  • GlusterFS
  • Rapidscale
  • EMC Highroad (MPFSi)
  • SGI CXFS

属于基于对象文件系统的有:

  • Lustre
  • Panasas
  • PVFS

讨论每个解决方案的区别不在这篇介绍的范围内。如需了解更多情况请访问本网站,寻找关于 HPCC 的系列文章。

作为结语,建议您在做任何涉及技术或解决方案的决定之前,要问自己一些非常重要的问题:

  1. 我部署/使用并行文件系统的目的是什么?它能不能提升系统的性能或可扩展能力?它是不是一个多集群集中式存储解决方案?
  2. 我或其他运行这个系统的人有没有分布式并行存储解决方案方面的经验?
  3. 我要运行哪些应用程序,每个程序采用什么 IO 模式?
  4. 我希望初始容量多大?增长速度多快?
  5. 我想要什么类型的备份系统?我需不需要考虑一个无需备份的解决方案?
  6. 我需不需要或想不想把 HSM 纳入存储解决方案之中?
  7. 我对灾难恢复有何要求?
  8. 我可以派多少人来管理存储解决方案?
  9. 除了考虑解决方案的当前成本以外,我还要考虑以下问题:
    1. 初始成本是多少?有没有包括安装费和培训费?
    2. 增加存储要花多少钱?
    3. 每年维护成本要多少?这个价位可以维持多久?
  10. 我想要部署的是什么类型的网络?如何把存储装入该网络?
  11. 我有哪些异地要求?(紧急情况下的异地数据存储)
  12. 如何将现有数据传输到一个新的并行数据存储系统中?传输过程要多长时间?我可以支持传输多长时间?
  13. 系统有多少用户?他们将如何运行其应用程序?如何与存储系统进行交互?
  14. 需要限额么?
  15. 有哪些存储处理进程?
  16. 用户有没有归档要求?


这些问题的答案很多,这些答案能帮助您决定符合您要求的解决方案。但是我强烈建议您花点时间,抛开技术或方案,仔细想想这些问题。不幸的是,人们天生就容易迷恋新技术(我也不例外!)而不够重视现实。知道这些问题的答案,从长远看来,能让您的生活变得更加轻松(我知道有些人出于这样那样的理由迷恋上了某个解决方案,结果搞得一团糟,因为他们没有事先做好计划)。

在回答这些问题的前/后,您需要考虑应用程序。使用什么应用程序?它们如何工作?它们的 IO 模式如何?IO 如何影响性能?然后看看问题的大小。现在您的问题有多大?您觉得几年后这个问题又会有何变化?

了解您的应用程序和它们的 IO 要求之后,开始策划存储部署方案。您可以首先弄清参与存储系统管理的人员,谁有 HPCC 存储经验(不光是企业存储,因为二者是不同的)一定要弄清他们有哪些经验,有哪种技能。此外,务必确定您可以安排多少人专门进行存储管理?然后,查看您的进程(我知道,我也讨厌这个词儿,但这点很重要)。查看此时您为下列事务设定的过程:

  • 配额
  • 使用暂存空间
  • 备份
  • 旧文件的迁移
  • 数据恢复
  • 归档
  • 异地存储
  • 灾难恢复
  • 将数据从一个存储平台迁移到另一个存储平台上

作为过程审查的一部分,花点时间观察您的用户运行任务和使用存储的情况。务必要与用户交流,询问他们应用程序当前的运行情况,了解他们希望日后能以什么方式运行这些程序。

现在您已经掌握了所有数据,可以坐下来与各供应商洽谈,查看结果,制定 HPCC 存储策略。注意,至今还未提到关于技术或解决方案的事。没定好策略之前,不谈技术和解决方案。

是不是很落后?

首先考虑存储各方面唯独不谈技术,直到此时才开始考虑技术,看起来很落后对么?这样做的原因是当您开始考虑关于 HPCC 的并行分布式存储之后,事情很快就会变得复杂化。只要您不骨头里挑刺,NSF 存储是直接明了的,但当您开始既想要大量分布式存储又想不增加复杂度时,实际上就是想要以不正常的速度执行 IO,如果没有计划好,一切就会发展到不可收场的地步。

另一个导致 HPCC 存储可能变得复杂的原因是没有明确的 front Runner(注:是一个使得您的应用程序与微软最新技术相兼容的计划)。为了找到一个好的解决方案,您必须斟酌考虑多个供应商和多种技术——这是很费时很复杂的,还意味着您要考虑到在几年内可能需要把数据从一个存储解决方案转移到另一个上。

例如,如果您有一个 500TB 的存储,它使用的是一家供应商的硬件集,但您想要(或必须要)将其转移到另一家供应商的产品上,这时您就需要计划如何转移这 500TB 的数据。如果我们假设新旧存储之间的传输速度是 1GB/s,则全部转移完需要 139 小时 — 约 6 天。在此期间,用户不能使用存储,所以集群是无效的。此外,数据转移到新存储上以后,您该如何检查以确保新存储上得到的是正确的映像副本?这又要花时间。如果您想要把备份的数据转移到新的存储上而不是将其从现有存储复制过去,那么您就需要做好计划(务必考虑到可能至少有一个磁带是坏的,您就必须从现有存储进行复制的情况)。

有个问题您必须考虑,那就是一旦您开始与某家供应商合作,采用某种技术以后,您就会被这个技术套牢。这不是在说存储供应商的坏话,而是针对行业现状的客观陈述。现在还没有针对并行分布式存储的标准,每个供应商有自己的解决方案,各自为阵,但现在似乎出现了一个可能可以解决这个问题的方案——pNFS。

pNFS

目前很多供应商在研究 4.1 版 NFS 标准。NFSv4.1 最大的新增内容之一(链接 http://tools.ietf.org/wg/nfsv4/)叫做 pNFS 或并行 NFS。当人们第一次听说 pNFS 时,往往会认为它只是想将并行文件系统功能临时拼搭入 NFS 中,但事实并非如此。pNFS 是迈向 NFS 协议革命的一步,这场革命就是要采用计划周密的、经过测试的、能顺利执行的方法向 NFS 协议增添真正的并行文件系统。目标是在把文件系统做成一个标准(回想 NFS 是唯一一个真正共享的文件系统标准)的同时,提高性能和可扩展性。此外,这个标准就是用来与那些基于文件、块和对象的、希望能帮助消费者从供应商或技术手上“解套”的存储设备一起使用的。NFSv4.1 标准草案中含有一个正在制定和论证中的 pNFS 规范草案。很多供应商正在联手开发 pNFS。

pNFS 真正吸引人的功能之一就是它能避免供应商“套牢”和技术“套牢”,部分原因是 pNFS 是 NFSv4.1中的一个标准(若得到批准的话)。事实上它将成为唯一一个平行文件系统标准。这样,遵守此标准的供应商就能交互操作,这正是顾客想要的。所以从理论上讲,这是一个汇集了基于对象的存储、基于文件的存储和基于块的存储,并能让所有 pNFS 客户端都能访问此存储池的系统。它让身为客户的您可以选择任何供应商提供的任何存储,只要它有布局驱动。

那么,供应商为什么要支持 NFSv4.1 呢?答案很简单。有了 NFSv4.1,他们无需转移其整个软件堆栈就可以支持多个操作系统了。他们只需要为其硬件写一个驱动。虽然写驱动并不简单,但是这比转移整个软件堆栈到新操作系统上要容易得多。

并行 NFS 有望成为一种标准,目前正处于原型开发阶段,各参与方正在进行可互操作性测试。希望在 2008 年间它能被通过测试并成为新的 NFS 标准出现在大量操作系统中。有网站提供了关于 pNFS 的信息、链接和一些代码。

HPCC 存储总结

如您所见,HPCC 存储并非易事。事实上,完成一个好的集群设计的难点之一就是 HPCC 存储,但它对于充分利用集群,更重要的是,对于帮助您的用户来说,却是至关重要的。

如果您从这章内容中什么都没有学到,那么您要记住 NFS 是很简单的,除 NFS 以外的东西都很复杂。如果您确实需要了解“其他内容”,例如并行分布式存储等,那么您就需要花点时间认真收集信息,想想您在做什么,制定一个存储计划。不要在没有搞清楚您的要求、您希望怎么处理存储以及如何管理存储之前,单纯地迷恋技术或解决方案。

虽然以上说法可能会稍微吓到您(或揭露出我们中很多人内在的不理智),但我们也要看到地平线上现在已出现了一丝曙光——pNFS。