{译}RedHat GFS最佳实践

本文翻译自:http://www.redhat.com/magazine/009jul05/features/gfs_practices/

原文作者:Matthew O’Keefe 马修奥基夫

译者:Timo

本文是一个GFS实践文档,教授大家如何部署GFS集群

• 导言

• NFS与RedHat GFS对比

• GFS的硬件的最佳实践

• 充分利用GFS的特点

• 摘要

• 关于作者

在本文中,我们讨论红帽全球文件系统( GFS )的最佳实践,其中包括何时使用GFS而不是NFS,配置基于硬件红帽GFS集群的小技巧,以及如何进行GFS磁盘配额和依据上下文的路径名称来简化系统管理。

导言

红帽GFS是一个集群文件系统为Red Hat企业版linux(RHEL),使多个服务器共享相同文件的一个存储区域网络。GFS利用自己的磁盘上的数据和先进的集群技术,使RHEL服务器直接访问共享存储设备,提供可扩展的存储性能和容量。它比网络文件系统( NFS )大大减轻了负载。在下一节中,我们概述GFS的与NFS的不同和如何使用这些技术。

NFS的与红帽GFS

前文RedHat GFS对比NFS :提高性能和可扩展性比较Red Hat GFS对NFS的基本类似的存储硬件。然而,重要的是要记住,GFS提供了直接连接服务器和共享存储设备,而NFS的议定规定,客户端访问存储设备必须通过一台服务器。NFS服务器层导致了额外的开销,并作为限制性能和可扩展性的一个瓶颈。与此相反,GFS可以使用快速存储区域网络( SAN )技术的光纤通道,以扩大存储带宽和每秒I / O操作。让我们比较标准的NFS C/S网络和使用GFS和一个SAN的Red Hat Enterprise Linux集群的几个相关的指标。

客户端可扩展性

RedHat GFS可以扩大到300或更多的客户机能够直接连接到SAN ,而一般的NFS可以实现为高达10至20的客户端的密集带宽应用,但可能30-50客户端则会降低密集I / O的工作负载。GFS从根本上比NFS更具有可扩展性,但需要一个SAN基础设施和先进的集群锁和运行于GFS客户端之间的成员协议。这些集群协议要求的客户端能能够完全同步处理网络,服务器和SAN故障在正常文件访问之前。

服务器的客户端之间的带宽

在RedHat GFS中, GFS机器和共享存储之间的带宽的只是被SAN基础架构和存储硬件限制。增加额外的带宽可通过添加更多的存储阵列和SAN网络端口来实现。与此相反,在NFS中, NFS服务器本身主要的瓶颈就是扩大存储和NFS客户端之间的带宽。最大带宽是由多少特定服务器所提供带宽来决定的。此外, NFS协议本身网络处理开销也是远远超过GFS,进一步限制NFS的带宽的可扩展性。

大型扩展的复杂性

大型RedHat企业Linux集群数十或数百台机器之家必须共享数据,通过GFS可以很容易做到。与此相反,在NFS中,多台NFS服务器扩展往往需要扩大I / O带宽和每秒操作数。不同的NFS服务器之间放置和同步数据是复杂的并会导致系统管理员的额外负担。

POSIX的语义

NFS的客户端可能会缓存写入几秒钟或更多时间的数据来提升性能。在V2和V3的NFS协议的版本,NFS服务器很可能不知道,在很短的时间内NFS服务器及客户端的文件数据可以不同步。这种行为不符合POSIX的文件存取语义,因此标准的UNIX应用程序一般不能运行访问一组NFS客户端如果该数据已经被其它文件共享使用。相比之下,红帽GFS文件读写访问遵循严格意义上的语义,因此,写入文件到GFS集群一台机器始终可见到另一台机器延后读取该文件。按照下列标准的POSIX语义,GFS允许标准的UNIX应用程序运行在集群之上。

这四个因素,GFS通过加上额外的硬件成本和严格的集群同步要求,给予以下GFS部署建议:

* 部署GFS当您有大量(超过10对带宽密集的I / O ,超过50为中等强度的I / O负载)的Red Hat Enterprise Linux的机器,必须访问,共享和经常改变一套共享数据。
* 部署GFS时,许多Red Hat Enterprise Linux的机器必须运行POSIX的应用程序共享数据。
* 部署GFS的数据,如果分区中的NFS服务器增加太多额外的复杂性和数据的重复。
* GFS部署时,网络处理负载和不精确语义的NFS是不能接受的。
* NFS部署时,您的性能要求低,几个客户机只能在松散耦合的方式下共享文件,成本低也是非常重要的。

我们现在考虑的一些方面的最佳实践顾及在GFS集群中的硬件部署。

GFS硬件的最佳实践

红帽GFS要求下面的硬件组件(除了标准的服务器和网络硬件)表示其正常运行:

1. 共享网络块存储对于所有GFS集群中的机器必须是可见的
2. 防护那些已不再通讯或连接到群集的硬件重置或重新启动GFS机器,

共享存储

块存储共享能实现在几个方面的开销和性能的交换。一般来说,大型GFS集群要求高存储区域网络端口显而易见需要更高的单位端口成本,因为大型光纤通道交换机每个端口需要更高的成本(称为总开关 ) 。

一个小型的GFS( 2-8台机器),例如,四机可以直接连接到4端口存储阵列不需要切换,从而大大降低成本。这种配置中显示图1 Small GFS Cluster。小型企业存储阵列最多到8个端口,也容易更换各种不同的存储供应商,对于这个数量的机器,无需交换机配置仍然是合理的。

small_cluster

图1 Small GFS Cluster

一个中型GFS集群( 9至32台)是最好的配置为基于光纤通道交换机的共享存储,并且交换机具有端口数多于机器的数量,加上一些存储阵列端口,另外还有3到4个端口一些最低限度的扩展。如果可能显著增加机器数量,小型和中型集群都应使用交换机,以适应更多的端口数量的增长。举一个例子,一个有10台服务器和四个存储端口的中等规模GFS集群的应该使用的是16端口的光纤通道交换机中显示图2 。 Medium GFS cluster。

medium_cluster
图2 Medium GFS cluster

大型GFS集群(超过32台)应使用大端口数光纤通道交换机(称为导向器级交换机),这种交换机提供重要的内部冗余控制风扇,电源和开关元件失灵。大型GFS集群总交换机故障的开销是巨大的,因为它需要立刻关闭大量的服务器。这是不能接受的,大多数企业的计算环境。 图3 。Large GFS clusters显示了一个大型140端口总交换机连接128台机器至8个存储阵列。

large_cluster

图3 Large GFS clusters

硬件屏蔽

硬件屏蔽是需要红帽GFS和红帽集群管理器,一个高可用性的应用程序故障的产品。当一台机器由于硬件或软件故障不能再与GFS集群的其他机器通讯,必须被屏蔽,以防止其访问共享存储。这种实现不是通过外部电源开关(如 APC 控制开关 )就是外部服务器管理界面,如HP iLO或戴尔远程辅助卡(DRAC) 。这些远程服务器管理工具让GFS集群重置或重新启动机器是作为可控的屏蔽过程的一部分,从一个组件错误中恢复过来的,并继续处理。这些其他品牌的管理技术的优势是:他们能够处理几乎所有错误情况和通常保证集群在故障发生后继续工作。

充分利用GFS的特点

在某种情况下GFS的某些功能可能会特别有用。在本节中,我们介绍一些这些功能及其用法。

GFS磁盘配额管理

RedHat GFS使用gfs_quota命令来为user和group提供一个有效的磁盘配额管理系统。. GFS磁盘配额的更新速度快,可扩展性是它重要的成就。文件系统进行磁盘配额是使用限制用户或组可以使用的文件系统空间。在GFS中一个用户或组除非做了设定否则就没有磁盘配额限制。GFS追踪每个用户和组空间使用,即使在空间上没做任何限制。GFS通过事务型方法来来更新磁盘配额信息,所以系统崩溃不需要重建磁盘配额使用。为了防止性能下降,一个GFS节点只会定期同步更新磁盘配额文件。 “软”磁盘配额被视为可以允许user或group略超过设定的限额。为了尽量减少这种情况,GFS动态缩短同步周期以接近“硬”配额限制。

每个用户ID (UID)或组ID ( GID)都有两种磁盘配额设置:硬限制和警告限制。硬限制的空间大小是都可以被使用的。文件系统将不会让用户或组使用超过这一数额的磁盘空间。一个值为0的硬限制值意味着没有任何限制。警告限制通常是一个小于硬盘限制的。达到限制时文件系统将通知用户或组的警告。一个值为0的警告限值意味着没有限制执行。限制设置使用使用gfs_quota命令。该命令只需要运行在一个已经GFS mount的单一节点上。

要设置硬限制用户或组,可使用以下命令:


gfs_quota limit -u  -l  -f
gfs_quota limit -g  -l  -f

给用户和组设置警告限制,可以使用以下命令:

gfs_quota warn -u  -l  -f

gfs_quota warn -g  -l  -f

<size>表明配额大小以MB为单位,而<mountpoint>指GFS文件系统所实际使用的目录。例如,要设置用户Bert硬限制1024MB(1GB )的/gfs文件系统下面的命令可使用:


gfs_quota limit -u Bert -l 1024 -f /gfs

要设置组号为21的警告限制50kb的/gfs文件系统使用下面的命令:


gfs_quota warn -g 21 -l 50 -k -f /gfs

上下文关联的路径名称( CDPN )

上下文关联的路径名称( CDPNs )允许符号链接创建指向根据不同的上下文来变化的目标文件或目录。这种变化解决了每次应用程序跟随符号链接实际文件或目录。这种方法得到的链接的值取决于某些机器或用户的属性。CDPN变量可以用于任何路径名称,而不仅仅是符号链接。然而, CDPN变量名称不能与其他字符组成一个实际目录或文件名称。CDPN变量必须是单独的完整路径的一部分。

在下面是符号链接操作:


 ln -s

<target>指定一个在现有的文件系统里应经存在的文件或目录、,而<linkname>指定一个链接名称链接到真正的文件或目录。

下面是变量符号链接的命令:


ln -s

<variable>指定了一个变量名单中的特殊保留的名字(请参阅表1 CDPN variable values )代表解决名称为多个现有的文件或目录。这个字符串的名称不是一个实际的文件或目录本身。(真正的文件或目录必须由一个单独的步骤:使用那些与变量使用类型相关的名字来创建。) <linkname>指定的名称将被应用程序视为和使用的将跟随得到一个或多个真正的文件或目录。当<linkname>被跟着,目的地取决于变量的类型和跟随链接的节点和用户。

Variable

Description

@hostname

解析为一个含有主机名的真正的文件或目录,这个主机名字符串由以下命令得到: uname -n

@mach

解析为一个含有机器类型的真正的文件或目录名称,这个机器类型的字符串由下面的命令输出: uname -m

@os

解析为含有操作系统名称字符串一个真正的文件或目录,这个操作系统字符串由下面的命令输出: uname -s

@sys

此变量解析为含有机器类型和操作系统版本类型字符串的一个真正的文件或目录,这个字符串由下面的命令产生: echo ‘uname -m’_’uname -s’

@uid

此变量解析为含有用户ID字符串的一个真正的文件或目录,这个字符串由下面的命令输出: id -u

@gid

此变量解析为含有group ID字符串的一个真正的文件或目录,曾格格字符串由下面的命令输出: id -g

表1 。 CDPN variable values

考虑一下,一个集群有三个机主机n01 , n02和n03 组成。每个节点上的应用程序使用目录/gfs/log/ ,但管理员要为每个节点创建单独的日志目录。要实现这一点,没有实际的日志目录创建,而是一个@hostname CDPN链接名创建日志。单独的目录/gfs/n01/ , /gfs/n02/和/gfs/n03/被创建,实际使用的目录为每一个节点的/gfs/log/ 。以下Linux命令序列输出有助于解释CDPN使用。

n01# cd /gfs
n01# mkdir n01 n02 n03
n01# ln -s @hostname log
n01# ls -l /gfs
lrwxrwxrwx 1 root root 9 Apr 25 14:04 log -> @hostname/
drwxr-xr-x 2 root root 3864 Apr 25 14:05 n01/
drwxr-xr-x 2 root root 3864 Apr 25 14:06 n02/
drwxr-xr-x 2 root root 3864 Apr 25 14:06 n03/

n01# touch /gfs/log/fileA
n02# touch /gfs/log/fileB
n03# touch /gfs/log/fileC
n01# ls /gfs/log/
fileA
n02# ls /gfs/log/
fileB
n03# ls /gfs/log/
fileC

摘要

红帽GFS提供快速,可扩展访问的共享存储。在本文中,我们提供了指导意见包含有:硬件配置,命令的使用,以及使用GFS与NFS。您可以了解到更多关于GFS在GFS 6.0 and GFS 6.1 Administrator’s Guides。 进一步的资料,创建和配置的SAN可以在参考由Josh Judd写的《Building SANs with Brocade Fabric Switches》一书。

欲了解更多关于红帽GFS ,请参阅以下文章:

* Red Hat GFS now supported with Oracle RAC
* Enterprise data sharing with Red Hat Global File System
* Red Hat GFS vs. NFS: Improving performance and scalability
译:RedHat GFS对比NFS:提高性能和可扩展性
* Red Hat GFS: Combining Fibre Channel and Gigabit Ethernet
* Data sharing with a GFS storage cluster

关于作者

从1990年至2000年月5,马修奥基夫是在明尼苏达大学教授和研究存储系统和并行仿真软件的一个电气和计算机工程学教授。他在2000年5月创立Sistina Software来为Linux开发存储架构软件,包括Global File System( GFS )和Linux逻辑卷管理器(LVM) 。 在2003年12月Sistina Software被Red Hat收购,马修奥基夫现在负责指导存储软件战略。

关于 Timo
XNIX SA & MYSQL DBA

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s

%d 博主赞过: