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
15 GNBD (Global Network Block Device)全局网络块设备
1> GNBD：
有服务端和客户端两部分组成,GNBD服务接点从自己的块存储设备中输出块级别存储到一个gfs接点.
注意：多路块设备映射机制不能用于GNBD,这里是针对red hat gfs6.1来说的.
IXDBA.NET技术社区
Multipath GNBD is not available with Red Hat GFS 6.1. That is, device mapper multipath (dm-multipath) cannot use GNBD. GNBD without multipath is available.我对这一段理解不是很明白，只好把原文附上.
2>两个主要模块：
. gnbd_serv . Implements the GNBD server.
It is a user-space daemon that allows a node to export local storage over a network.
实现GNBD服务端的功能，这就是在网络上把自己的存储设备输出到网络上的gfs接点上，它是一个用户态进程.
. gnbd.ko.Implements the GNBD device driver on GNBD clients (nodes using GNBD devices).
在客户端实现gnbd设备驱动
2> 配置GNBD的两个命令
<1> gnbd_export 在gnbd服务端创建，输出，管理gnbds
<2> gnbd_import 在客户端实现输入和管理gnbds
3>启动gnbd服务：
#gnbd_serv
启动成功后显示如下信息：
gnbd_serv: startup succeeded
3> gnbd_export使用方法：
gnbd_export -d pathname -e gnbdname [-c]
pathname：指定要输出的存储设备
gnbdname：要被客户端使用的设备名，在整个网络上必须是唯一的但是任意的
-o:以只读方式输出设备名
-c:能使用缓存，linux默认不使用
例：gnbd_export -d /dev/sdb2 -e delta -c
4> gnbd_import：使用方法：
<1>在使用该命令前，一定要保证gnbd.ko内核模块在接点上已经被加载了，另外，服务端已经要输出块设备.
<2>使用方法：
gnbd_import -i Server
server:要输入gnbds的主机名或ip地址
例：gnbd_import -i nodeA
16 ：Running GFS on a GNBD Server Node
在一个 gnbd服务接点上运行gfs
你可以在gnbd服务端接点上运行gfs，但性能将受到影响
且你必遵从下面的限制：
<1>你必须让gnbd服务接点上的所有设备都mount成gfs文件系统，且没有输出任何其他gnbd设备.
<2>gnbd服务接点必须一不能使用缓存的模式输出所有的gnbds，切必须是裸设备
<3>GFS must be run on top of a logical volume device, not raw devices.
必须在一个逻辑设备的顶部运行而不是在raw devices.上.
在redhat的网站有这样的描述，但是没有实现方法。我也有同样的问题！那位高手能给出实现的办法啊？
Another alternative configuration is given in Figure 7. GNBD serving using non-shared storage and mirroring in the cluster, which shows a GFS server attached to a group of GNBD servers where mirror volume pairs are maintained across sets of GNBD servers. These mirror pairs can be constructed using cluster volume mirroring software on the GFS servers. Notice in Figure 8. GNBD server or mirrored volume failures are tolerated how this configuration (non-shared storage devices that are mirrored across GNBD servers) allows both the GNBD server and storage device failures to occur without bringing the GFS cluster down. In this example, GNBD server B or storage device 2 has failed, so the mirror volume 2' for storage device 2 is accessed through GNBD server A. This example shows that non-shared storage can be attached to the GNBD server layer in such a way that both GNBD server and storage device failures can be tolerated, at the cost of mirroring all storage devices. Mirroring storage devices doubles the required storage hardware compared to the same capacity of non-mirrored storage. In addition, it increases the amount of storage traffic seen on the IP network (each disk block is written twice instead of just once).
