本文将介绍一些常用的物理存储架构以及群集和分布式文件系统。希望这能让你们对这类技术有一个初步的认识，以便更好地满足高使用率存储的需求。

　　建立集群和使用率高的数据存储解决方案有很多选择，但是要想弄清每种选择的优劣则要花点时间进行研究。存储架构和文件系统的选择至关重要，因为大部分的存储解决方案都有严格的限制条件，需要仔细设计工作环境。

　　基础架构

　　有些读者也许希望装配一组可以并行访问同一个文件系统的服务器，而另一些读者可能想复制存储器并提供并行访问和冗余。有两种方法可以实现多服务器访问同一个磁盘，一种方法是让那些服务器都可以看到那个磁盘，另一种方法则是通过复制。

　　共享磁盘结构在光纤通道SAN和iSCSI领域是最常见的结构。配置存储系统相当简单，这样多个服务器就可以看到同一个逻辑块设备或LUN，但是如果没有群集文件系统，那么当多个服务器同时想使用那个逻辑块设备时就会出现混乱。 这个问题与使用群集文件系统有关，我们将在下文中详细介绍。

　　一般而言，共享磁盘系统有个弱点，那就是存储系统。但是情况也并非总是如此，因为利用现在的技术是很难理解共享盘的概念的。SAN、NAS设备和基于Linux系统的商品硬件可以将所有的基础磁盘实时复制到另一个存储节点，从而提供一个模拟共享盘环境。基础模块设备被复制之后，那些节点就可以访问相同的数据，也可以运行同一个群集文件系统了，但是这种复制超出了传统共享盘的定义。

　　相反，不共享才是共享盘的问题所在。连接着不同存储设备的节点会在每个模块被写入数据时将变化通知给主服务器。 现在，不共享架构仍存在于Hadoop那样的文件系统之中，那些文件系统可以在许多节点故意建立多个数据副本，从而提高性能和冗余。而且，在不同存储设备或节点之间利用自己的存储设备进行复制的群集也可以做到不共享。

　　设计选择

　　正如我们所说的，你不能通过多个服务器访问同一个模块设备。你听说过文件系统锁定，因此普通的文件系统并不能实现这一点就有些奇怪了。

　　在文件系统级别上，文件系统本身会将文件锁定以保证数据不会出错。但是在操作系统级别上，文件系统启动程序完全可以访问基础模块设备，它们可以在基层模块设备之间自由的漫游。大部分文件系统都会认为它们被分配了一个模块设备，而且那个模块设备也只是它们自己所有。

　　为了解决这个问题，集群文件系统采用了一种并行控制机制。有些集群文件系统将把元数据保存在共享设备的一个分区里，另一些集群文件系统则会使用集中式元数据服务器来保存元数据。 不管采用哪种方案，集群中的所有节点都可以看到文件系统的状态，从而保证安全的并行访问。然而，如果你想保证系统的高利用率和消除单点故障问题，那么采用集中式元数据服务器的解决方案就要略逊一筹了。

　　另一个注意事项：集群文件系统要求在节点发生故障时迅速做出反应。如果某个节点写入错误数据或由于某种原因停止关于元数据变化的通信，其他节点必须能够将它隔离出去。隔离可以通过多种方式来实现，最常用的方法是利用断电管理来实现。健康的节点可以在发现问题时第一时间关闭另一个节点电源(STONITH)以保全数据。

　　GFS：全局文件系统

　　GFS是应用最广泛的集群文件系统。它是由红帽公司开发出来的，允许所有集群节点并行访问。元数据通常会保存在共享存储设备或复制存储设备的一个分区里。

　　OCFS:甲骨文集群文件系统

　　从概念上来说，OCFS与GFS非常相似，现在OCFS 2已经被应用于Linux系统之中。

　　VMFS:VMware的虚拟计算机文件系统

　　VMFS是ESX服务器用来允许多个服务器访问同一个共享存储设备的集群文件系统。这样就可以实现虚拟机在不同服务器之间的无缝迁移，因为源服务器和目标服务器都可以访问同一个存储设备。日志是分布式的，ESX服务器之间也不会出现单节点故障。

　　Lustre：Sun的集群分布式文件系统

　　Lustre是专门用于包含数千个节点的大型集群的分布式文件系统。Lustre已经支持Linux系统，但是高速计算环境之外的应用程序是有限的。

　　Hadoop:一个象谷歌那样使用的分布式文件系统

　　这不是一个集群文件系统，但是却是一个分布式文件系统。我们将Hadoop收录进来是因为它的应用越来越广泛，而且利用Hadoop的存储架构设计决策的组合很多。但是默认配置下，你会在3个不同的节点上拥有3个数据副本。一旦数据发生变化，每个数据副本都会更新，因此，从某种意义上来说，它也可以被看做是集群文件系统。然而，Hadoop存在一个故障点隐患，即跟踪记录所有文件系统级数据的命名节点。

　　做出最好选择

　　有太多选择并不是坏事。你可以根据执行目标选择使用合适的集群或分布式文件系统以及存储架构。 只要有计划地使用，所有这些文件系统都可以发挥出应有的作用。