在Red Hat集群和存儲套件（RHCS）中，提供了針對不同的要求構建集群的套件，其中包括HA集群、Load balance（LVS）集群以及存儲集群套件。在存儲集群套件中比較著名的是GFS文件系統，能夠實現在HA和LVS集群環境中對共享存儲安全和高效訪問的要求，當然GFS目前在集群環境中使用也比較多。
不過在GFS之外，RHCS中還提供了一個稱為GNBD的東西。GNBD全稱為(Global Network Block Device) ，全局網路塊設備。該軟體提供了一個基於乙太網訪問塊設備也就是存儲設備的一種機制和功能。GNBD通常情況下會被部署在多台已經安裝GFS模塊的伺服器上，並且通過不同的配置，安裝gnbd的設備可以做gnbd客戶端也可以做gnbd伺服器。其區別取決於在他們上面所執行的操作——在GNBD伺服器上可以通過GNBD來導出自己的一個本地設備，相當於通過網路共享給其他主機，而其他主機可以像訪問本地設備一樣實現對gnbdserver導出設備的讀寫操作。
從剛才的描述中我們應該可以發現gnbd的功能類似於iscsi的iscsitarget和iscsiinitiator。這點沒錯，但是gnbd相比iscsi又有點不同：
首先gnbd在實現類似iscsi這樣功能的同時還帶有內置的fence功能，在通過網路對塊設備進行訪問的過程中能夠像電源fence那樣切斷主機和存儲之間的聯繫，當然這個fence肯定不是電源fence，而是中斷對存儲訪問來達到fence的目的；
其次gnbd可以結合device-mapper-multipath來實現對GFS文件系統的多路徑訪問以及線路冗餘，在這樣的要求下，可以使gnbdclient可以通過兩個gnbdserver來訪問其上的GFS，如果一個server斷連，只要另外一個server存在，他就還會通過網路提供GFS文件系統的訪問。儘管我們通過iscsi配置也能實現該功能，不過在這方面似乎沒有gnbd名頭響亮，因為其開發者特意在官方文檔中提到了gnbd的multipath功能，而沒有提到iscsi也能實現multipath；
最後一點不同就是和iscsi相比，gnbd的性能會差很多，以至於在未來RHEL系統中的RHCS里是否保留GNBD都是一個未知數，但是可以確認的是對GNBD的開發已經停止了。
既然明知道這是一個過氣的產品，為什麼還要寫在其基礎上進行操作的文檔？其實原因也很簡單：
儘管GNBD有諸多不好的地方，但是在RHEL中直到5u2版本才推出一個預覽版性質的iscsitarget實現工具，叫做tgtd和tgtadm。可見在此之前一直沒有官方認可的iscsitarget程序。所以如果客戶需要一個官方的解決方案，儘管這個東西性能差但還非他莫屬；同時他可以結合device-mapper-multipath實現多路徑的功能，在預算不太充足的情況下也是一些企業的權宜之計。所以也有必要試驗一些並寫點心得。
不過在結合device-mapper實現multipath試驗過程中才發現，這個東西其實噁心得還真不是一點半點，因為已經是過氣的產品，所以少有人關注也鮮有維護開發者，相應的文檔就更是鳳毛麟角。因此在實驗過程中碰到的釘子到最後都成了無頭公案，很多出現的問題即便解決了也並非能從根本上找到原因。所以這裡對於那些執迷不悟還繼續要使用或者有膽量使用gnbd的人先敲個警鐘——看看好了，但別真拿到生產環境中玩，否則我將以名譽保證以後將碰到更多形形色色的問題，當然如果有哪個無聊的冤大頭一定要玩的話，RHEL會在他的RHCS中提供更好的東西。
不過儘管如此，在整個試驗的過程中也要感謝jerry卡王和來自捷克的bmarzins兄提供的技術支持和大力幫助，尤其是bmarzins兄不顧六個小時的時差對於我的問題和求助給予非常具體和高屋建瓴的意見，以至於在好幾次我已經快絕望的時候又見到了曙光，儘管可能並沒有從根本上解決所遇到的問題，但是他的一些提示對這個試驗的繼續進行提供了重要的線索和支持，最終這個試驗能夠有一個相對滿意的結果。再次證明了bmarzins兄作為Red Hat資深存儲工程師的深厚功底和嚴謹態度。
所以為了對得起兩位高人，我將這次的試驗過程整理成文檔，以下是通過GNBD實現基於multipath上GFS訪問的完整記錄：
按照我寫文檔的慣例，首先是這個試驗的拓撲結構和相關說明：
如下圖所示，在該結構中有五台伺服器，全部使用RHEL5u2系統。其中一台通過安裝和配置scsi-target來實現iscsitarget伺服器，有兩台iscsiinitiator作為客戶端，並同時作為gnbdserver，另外兩台伺服器作為gnbdclient。每個gnbdclient都有兩條鏈路各自通過一個獨立的vmnet連接到相應的gnbdserver從而實現了一個多路徑的物理結構，當然這兩條鏈路儘管都是乙太網鏈路，但其實是用於scsi數據傳輸的。我用藍色表示連接到gnbdserver1的存儲鏈路，用綠色表示連接到gnbdserver2的存儲鏈路。用黑色表示從iscsiinitiator到scsitarget的iscsi存儲鏈路。最後由於整個的gnbdserver和gnbdclient都要在集群中，那麼需要一條獨立的心跳鏈路，就是紅色的192.168.10.0/24這條鏈路。
這個結構完全是在虛擬機vmware 6.0的版本上構建起來的。在vmware虛擬機上添加網卡和介面並指定哪個網卡橋接哪個vmnet的過程我想看圖就成，應該不用我再一一說了。
我的設想是這樣，我首先在兩台iscsiinitiator上實現對iscsitarget上共享存儲的訪問使其成為本地存儲，然後再在這兩台iscsiinitiator上部署gnbd並載入gnbd.ko模塊和開啟gnbdserver服務使其成為gnbdserver，然後在兩台gnbdserver上export出其載入過來的iscsitarget的存儲，使gnbdclient能夠import，之後在gnbdclient上配置multipath實現多路徑訪問。最後進行測試。
能夠實現的效果是，如果從gnbdclient1上向GFS寫入數據時候，如果將任何一條存儲線路斷開，gnbd內置的fence機制結合物理fence可以將相應的gnbdserver從集群中fence掉，成功之後數據還可以通過另外一條存儲線路傳輸，或者數據傳輸可以從失效鏈路切換到另外一條正常鏈路。
在整個試驗中，gnbdclient和gnbdserver都要作為HA集群中的一個節點。也就是說在配置multipath之前要構建一個四節點集群。
《解決方案》
現在開始配置：
首先是iscsitarget上的配置。這個伺服器上的基本情況和配置信息包括：
地址信息：
# ifconfig | grep inet
inet addr:172.16.1.10 Bcast:172.16.255.255 Mask:255.255.0.0
inet6 addr: fe80::20c:29ff:feb6:9605/64 Scope:Link
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
在該主機上添加一個8G的硬碟作為共享：
# fdisk -l
Disk /dev/sda: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 796 6289447+ 83 Linux
/dev/sda3 797 861 522112+ 82 Linux swap / Solaris
Disk /dev/sdb: 8589 MB, 8589934592 bytes
64 heads, 32 sectors/track, 8192 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
然後是所安裝的軟體包，尤其是前面的scsi-target-utils，該包提供了iscsi服務端tgtd和tgtadm
# rpm -qa | grep scsi
scsi-target-utils-0.0-0.20070620snap.el5
iscsi-initiator-utils-6.2.0.868-0.7.el5
# rpm -ql scsi-target-utils
/etc/rc.d/init.d/tgtd
/usr/sbin/tgtadm
/usr/sbin/tgtd
之後啟動scsitarget服務：
# service tgtd start
# chkconfig --level 345 tgtd on
並將共享設備規則寫入到/etc/rc.local中。沒辦法，這個產品還是預覽版本，所以只能將就了：
# cat /etc/rc.local
/usr/sbin/tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.2008-09.gnbd.storage.sdb
/usr/sbin/tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/sdb
/usr/sbin/tgtadm --lld iscsi --op bind --mode target --tid 1 -I 172.16.0.0/16
然後重啟tgtd服務：
# service tgtd restart
到此為止在iscsi-target上的配置基本完成。下面是iscsi-initiator上的配置：
首先是基本網路信息：
# hostname
gnbdserver1
# ifconfig | grep inet
inet addr:192.168.10.13 Bcast:192.168.10.255 Mask:255.255.255.0 eth0
inet6 addr: fe80::20c:29ff:fe82:237a/64 Scope:Link
inet addr:172.16.1.11 Bcast:172.16.1.255 Mask:255.255.255.0 eth1
inet6 addr: fe80::20c:29ff:fe82:2384/64 Scope:Link
inet addr:192.168.2.12 Bcast:192.168.2.255 Mask:255.255.255.0 eth2
inet6 addr: fe80::20c:29ff:fe82:238e/64 Scope:Link
然後實現配置iscsi-initiator，確保安裝了iscsi-initiator-utils包，然後執行下面的操作：
# service iscsi restart
# chkconfig --level 345 iscsi on
# iscsiadm --mode discovery --type sendtargets --portal 172.16.1.10
修改文件：/etc/iscsi/iscsi.conf，更改下面兩個參數為：
node.session.timeo.replacement_timeout = 12
node.session.initial_login_retry_max = 1
對於這兩個參數的解釋：
To specify the length of time to wait for session re-establishment before failing SCSI commands back to the application when running the Linux SCSI Layer error handler, edit the line.
The value is in seconds and the default is 120 seconds.
To speficy the number of times iscsiadm should retry a login to the target when we first login, modify the following line. The default is 4. Valid values are any integer value. This only affects the initial login. Setting it to a high value can slow down the iscsi service startup. Setting it to a low value can cause a session to not get logged into, if there are distuptions during startup or if the network is not ready at that time.
其實我修改這兩個值的目的完全是希望底層iscsi在探測到鏈路失效的時候驅動的反映能夠快一些，因為我在普通環境下以iscsi做multipath的試驗發現在iscsi網路上存儲線路failover太慢，要一分鐘之久。而這個值在結合gnbd的時候可能會出現一些問題。事實上根據其他工程師的反應，在光纖存儲控制器或者光纖交換機切換的周期根本沒有這麼長。不過我對此做的更改似乎沒有什麼太大的用處，如果在非cluster環境下做multipath，更改該值反而會使線路切換更加慢。所以我認為該值不改也行。
接著，就要通過iscsiadm命令來確認連接到iscsi存儲，並重啟服務：
# service iscsi restart
# iscsiadm --mode node
172.16.1.10:3260,1 iqn.2008-09.gnbd.storage.sdb
# fdisk -l
Disk /dev/sda: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 796 6289447+ 83 Linux
/dev/sda3 797 861 522112+ 82 Linux swap / Solaris
Disk /dev/sdb: 8589 MB, 8589934592 bytes
64 heads, 32 sectors/track, 8192 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 3816 3907568 83 Linux
到此為止在gnbdserver1上的配置已經完成。而gnbdserver2除了基本信息的改動之外iscsi的相關配置是一樣的，所以這裡只將gnbdserver2的基本信息列出來：
# hostname
gnbdserver2
# ifconfig | grep inet
inet addr:192.168.10.14 Bcast:192.168.10.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe8e:c855/64 Scope:Link
inet addr:172.16.1.12 Bcast:172.16.1.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe8e:c85f/64 Scope:Link
inet addr:192.168.3.12 Bcast:192.168.3.255 Mask:255.255.255.0
接著配置gnbdclient1和gnbdclient2的基本信息，做加入集群的準備工作：
# hostname
gnbdclient1
# ifconfig | grep inet
inet addr:192.168.10.11 Bcast:192.168.10.255 Mask:255.255.255.0 eth0
inet6 addr: fe80::20c:29ff:fe6e:4d82/64 Scope:Link
inet addr:192.168.3.13 Bcast:192.168.3.255 Mask:255.255.255.0 eth1
inet6 addr: fe80::20c:29ff:fe6e:4d8c/64 Scope:Link
inet addr:192.168.2.11 Bcast:192.168.2.255 Mask:255.255.255.0 eth2
inet6 addr: fe80::20c:29ff:fe6e:4d96/64 Scope:Link
# cat /etc/hosts
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
192.168.10.13 gnbdserver1
192.168.10.14 gnbdserver2
192.168.10.11 gnbdclient1
192.168.10.12 gnbdclient2
注意，該文件要同步到其他的gnbdservers和gnbdclients中。
然後確保以下軟體的安裝：
cman-2.0.84-2.el5
rgmanager-2.0.38-2.el5
system-config-cluster-1.0.52-1.1
kmod-gnbd-0.1.4-12.el5
gnbd-1.1.5-1.el5
gfs-utils-0.1.17-1.el5
kmod-gfs2-1.92-1.1.el5
gfs2-utils-0.1.44-1.el5
kmod-gfs-0.1.23-5.el5
上述這些包也要在其他的gnbdservers和gnbdclients中安裝。
完成之後兩台gnbdclients和gnbdservers都重啟以載入gnbd和gfs模塊。當然在重啟所有系統之前可以先在gnbdclients上安裝device-mapper-multipath，並啟動該服務：
# service multiapthd restart
# chkconfig –-level 345 multipathd on
# service multiapthd restart
# chkconfig –-level 345 multipathd on
這樣在client啟動的時候可以自動載入multipath模塊。
在重啟完成之後，下面就可以配置集群了，在任何一台gnbdservers和gnbdclients上進入圖形界面，然後執行system-config-cluster打開集群配置工具。基本步驟和部署一個普通集群無差別，只是我在這裡使用了manual_fence，因為確實沒有物理fence設備，並且分別為gnbdservers和gnbdclients建立一個failover domain。關於為什麼要使用manual_fence，官方文檔有相關解釋：
GNBD server nodes must be fenced using a fencing method that physically removes the nodes
from the network. To physically remove a GNBD server node, you can use any fencing device:
except the following: fence_brocade fence agent, fence_vixel fence agent, fence_mcdata
fence agent, fence_sanbox2 fence agent, fence_scsi fence agent. In addition, you cannot use
the GNBD fencing device (fence_gnbd fence agent) to fence a GNBD server node.
至於服務方面我沒有添加，因為該試驗的目的是測試gnbd和multipath的功能。完成之後將配置文件同步到其他主機，下面是我的配置文件：
# cat /etc/cluster/cluster.conf
然後在所有gnbdclients和gnbdservers上開啟集群服務並重啟所有系統：
# chkconfig --level 345 cman on
# chkconfig --level 345 rgmanager on
# chkconfig --level 345 gfs on
最後再次重啟所有系統。
在系統啟動之後，如果配置沒錯並且拓撲沒錯的話集群也就已經起來了。接著在gnbdservers上建立gfs文件系統，注意，這裡gfs文件系統要針對整個分區建立而不是lvm上建立，因為在lvm上構建GFS文件系統在後期gnbd export的時候會出錯。所以自然也就不需要啟動clvmd服務。
下面是建立gfs文件系統的步驟，可以在任何一台gnbdserver上建立gfs文件系統：
先用fdisk將共享盤劃分為整個一個單分區，然後執行gfs_mkfs命令：
# gfs_mkfs -t gnbd_clustre:gfs1 -p lock_dlm -j 2 /dev/sdb1
在另外一個節點上就不用再次執行gfs_mkfs了。
接著可以在gnbdservers和gnbdclients上部署gnbd。
首先是gnbdserver1上的配置步驟：
系統重啟之後手動執行modprobe命令載入gnbd.ko模塊並啟動gnbd服務，我可以將將這幾個步驟寫入到/etc/rc.local文件中：
# cat /etc/rc.local
/sbin/rmmod pcspkr
/sbin/modprobe gnbd
/sbin/gnbd_serv
/sbin/gnbd_export -d /dev/sdb1 -e gfs-1 -U -t 5
然後執行該文件：
# /etc/rc.local
完成之後查看：
# gnbd_export -l
Server : gfs-1
--------------------------
file : /dev/sdb1
sectors : 7815136
readonly : no
cached : no
timeout : 5
uid : GNBD-1-16465616462656166313a3100000000000000000000000000
官方文檔對該操作的部分解釋：
# gnbd_export Command to create, export and manage GNBDs on a GNBD server.
另外在使用gnbd實現multipath的時候有幾點需要注意：
For GNBD with device-mapper multipath, do not specify Linux page caching (the -c option of
the gnbd_export command). All GNBDs that are part of a logical volume must run with caching
disabled. Data corruption occurs if the GNBDs are run with caching enabled.
-U Command
Gets the UID command. The UID command is a command the gnbd_export command will run to get a Universal Identifier for the exported device. The UID is necessary to use device-mapper multipath with GNBD. The command must use the full path of any executeable that you wish to run. A command can contain the %M, %m or %n escape sequences. %M will be expanded to the major number of the exported device, %m will be expaned to the minor number of the exported device, and %n will be expanded to the sysfs name for the device. If no command is given, GNBD will use the default command /usr/sbin/gnbd_get_uid. This command will work for most SCSI devices.
1. A GNBD server node must have local access to all storage devices needed to mount a GFS
file system. The GNBD server node must not import (gnbd_import command) other GNBD
devices to run the file system.
2. The GNBD server must export all the GNBDs in uncached mode, and it must export the raw
devices, not logical volume devices.
3. GFS must be run on top of a logical volume device, not raw devices.
You may need to increase the timeout period on the exported GNBDs to accommodate reduced performance. The need to increase the timeout period depends on the quality of the hardware.
然後是gnbdserver2上的配置步驟和gnbdserver1一樣，稍有不同的是配置文件內容，所以我只給出配置文件，其他不再贅述。
# cat /etc/rc.local
/sbin/rmmod pcspkr
/sbin/modprobe gnbd
/sbin/gnbd_serv
/sbin/gnbd_export -d /dev/sdb1 -e gfs-2 -U -t 5
接著是在gnbdclient1上的配置：
和gnbdserver一樣，我將需要的配置寫入到/etc/rc.local中：
# cat /etc/rc.local
/sbin/rmmod pcspkr
/sbin/modprobe gnbd
/sbin/gnbd_import -i 192.168.2.12
/sbin/gnbd_import -i 192.168.3.12
並執行該腳本：
# /etc/rc.local
查看執行情況：
# gnbd_import -l
Device name : gfs-1
----------------------
Minor # : 0
sysfs name : /block/gnbd0
Server : 192.168.2.12
Port : 14567
State : Open Connected Clear
Readonly : No
Sectors : 7815136
Device name : gfs-2
----------------------
Minor # : 1
sysfs name : /block/gnbd1
Server : 192.168.3.12
Port : 14567
State : Open Connected Clear
Readonly : No
Sectors : 7815136
# gnbd_monitor
device # timeout state
1 5 normal
0 5 normal
當然在gnbdclient2上的配置和測試過程完全一樣，不再贅述。
到此為止gnbd在server和client上的配置都已經全部完成。
最後是在gnbdclients上部署multipath。剛才已經安裝了相關的multipath包，所以直接修改配置文件。除了修改blacklist之外，將原來的default段的內容修改如下：
# cat /etc/multipath.conf
blacklist {
devnode "sda"
}
defaults {
udev_dir /dev
polling_interval 5
selector "round-robin 0"
path_grouping_policy failover
prio_callout none
path_checker readsector0
rr_min_io 1000
rr_weight uniform
}
multipaths {
multipath {
wwid GNBD-1-16465616462656166313a3100000000000000000000000000
alias yellow
path_grouping_policy failover
path_checker readsector0
path_selector "round-robin 0"
failback manual
rr_weight priorities
no_path_retry 5
}
}
這是在jerry幫助下修改的一個實現的主備功能的multipath配置，完成之後保存並啟用服務：
# service multipathd restart
# chkconfig --level 345 multipathd on
# multipath -ll
yellow (GNBD-1-16465616462656166313a3100000000000000000000000000) dm-0 GNBD,GNBD
\_ round-robin 0
\_ #:#:#:# gnbd0 252:0
\_ round-robin 0
\_ #:#:#:# gnbd1 252:1
下面把配置文件multipath.conf同步到gnbdclient2上，然後按照同樣的步驟啟用服務，這樣整個的試驗結構就算全部完成。
《解決方案》
下面開始按照預先的設想去進行測試：
為了保證一個乾淨的環境，首先重啟全部節點並清空所有節點上的日誌：
# > /var/log/messages，
然後在gnbdclient1上掛載gfs文件系統：
# mount /dev/mpath/yellow /mnt/
# df -TH /mnt
Filesystem Type Size Used Avail Use% Mounted on
/dev/dm-0 gfs 3.8G 889M 2.9G 24% /mnt
# tail -f /var/log/messages
Oct 23 13:59:46 gnbdclient1 kernel: GFS 0.1.23-5.el5 (built Apr 30 2008 16:56:42) installed
Oct 23 13:59:46 gnbdclient1 kernel: Trying to join cluster "lock_dlm", "gnbd_cluster:gfs1"
Oct 23 13:59:46 gnbdclient1 kernel: Joined cluster. Now mounting FS...
Oct 23 13:59:46 gnbdclient1 kernel: GFS: fsid=gnbd_cluster:gfs1.0: jid=0: Trying to acquire journal lock...
Oct 23 13:59:46 gnbdclient1 kernel: GFS: fsid=gnbd_cluster:gfs1.0: jid=0: Looking at journal...
Oct 23 13:59:47 gnbdclient1 kernel: GFS: fsid=gnbd_cluster:gfs1.0: jid=0: Done
Oct 23 13:59:47 gnbdclient1 kernel: GFS: fsid=gnbd_cluster:gfs1.0: jid=1: Trying to acquire journal lock...
Oct 23 13:59:47 gnbdclient1 kernel: GFS: fsid=gnbd_cluster:gfs1.0: jid=1: Looking at journal...
Oct 23 13:59:47 gnbdclient1 kernel: GFS: fsid=gnbd_cluster:gfs1.0: jid=1: Done
同時在gnbdclient2上也同樣掛載該文件系統：
# mount /dev/mpath/yellow /mnt/
在gnbdclient2上監控/mnt:
# watch -n1 "ls -l /mnt"
然後在gnbdclient1上向GFS文件系統dd數據：
# dd if=/dev/zero of=test.img
在執行該命令的時候，我們會通過虛擬機網路介面發現數據流在vmnet3上，根據結構圖判斷，數據是在通過gnbdserver1走。然後我將gnbdclient1和gnbdserver1連接的鏈路在gnbdclient1上物理斷開。數據流將出現暫時的中斷。
然後在gnbdserver1上出現下面的報錯信息：
# cat /var/log/messages
Oct 23 14:05:26 gnbdserver1 openais: cman killed by node 3 because we were killed by cman_tool or other application
Oct 23 14:05:26 gnbdserver1 gfs_controld: groupd_dispatch error -1 errno 11
Oct 23 14:05:26 gnbdserver1 gfs_controld: groupd connection died
Oct 23 14:05:26 gnbdserver1 gfs_controld: cluster is down, exiting
Oct 23 14:05:26 gnbdserver1 dlm_controld: cluster is down, exiting
Oct 23 14:05:26 gnbdserver1 kernel: dlm: closing connection to node 4
Oct 23 14:05:26 gnbdserver1 kernel: dlm: closing connection to node 3
Oct 23 14:05:26 gnbdserver1 kernel: dlm: closing connection to node 2
Oct 23 14:05:26 gnbdserver1 kernel: dlm: closing connection to node 1
Oct 23 14:05:29 gnbdserver1 gnbd_clusterd: ERROR Bad poll result 0x11 from cluster
Oct 23 14:05:30 gnbdserver1 fenced: cluster is down, exiting
Oct 23 14:05:47 gnbdserver1 ccsd: Unable to connect to cluster infrastructure after 30 seconds.
而在gnbdserver2上認為gnbdserver1將被fence出集群：
# cat /var/log/messages
Oct 23 14:09:40 gnbdserver2 openais: entering GATHER state from 12.
Oct 23 14:09:44 gnbdserver2 openais: entering GATHER state from 11.
Oct 23 14:09:45 gnbdserver2 openais: Saving state aru 78 high seq received 78
Oct 23 14:09:45 gnbdserver2 openais: Storing new sequence id for ring 460
Oct 23 14:09:45 gnbdserver2 openais: entering COMMIT state.
Oct 23 14:09:45 gnbdserver2 openais: entering RECOVERY state.
Oct 23 14:09:45 gnbdserver2 openais: position member 192.168.10.11:
Oct 23 14:09:45 gnbdserver2 openais: previous ring seq 1116 rep 192.168.10.11
Oct 23 14:09:45 gnbdserver2 openais: aru 78 high delivered 78 received flag 1
Oct 23 14:09:45 gnbdserver2 openais: position member 192.168.10.12:
Oct 23 14:09:45 gnbdserver2 openais: previous ring seq 1116 rep 192.168.10.11
Oct 23 14:09:45 gnbdserver2 openais: aru 78 high delivered 78 received flag 1
Oct 23 14:09:45 gnbdserver2 openais: position member 192.168.10.14:
Oct 23 14:09:45 gnbdserver2 openais: previous ring seq 1116 rep 192.168.10.11
Oct 23 14:09:45 gnbdserver2 openais: aru 78 high delivered 78 received flag 1
Oct 23 14:09:45 gnbdserver2 openais: Did not need to originate any messages in recovery.
Oct 23 14:09:45 gnbdserver2 openais: CLM CONFIGURATION CHANGE
Oct 23 14:09:45 gnbdserver2 openais: New Configuration:
Oct 23 14:09:45 gnbdserver2 openais: r(0) ip(192.168.10.11)
Oct 23 14:09:45 gnbdserver2 openais: r(0) ip(192.168.10.12)
Oct 23 14:09:45 gnbdserver2 openais: r(0) ip(192.168.10.14)
Oct 23 14:09:45 gnbdserver2 kernel: dlm: closing connection to node 1
Oct 23 14:09:45 gnbdserver2 openais: Members Left:
Oct 23 14:09:45 gnbdserver2 openais: r(0) ip(192.168.10.13)
Oct 23 14:09:45 gnbdserver2 fenced: gnbdserver1 not a cluster member after 0 sec post_fail_delay
Oct 23 14:09:45 gnbdserver2 openais: Members Joined:
Oct 23 14:09:45 gnbdserver2 fenced: fencing node "gnbdserver1"
Oct 23 14:09:45 gnbdserver2 openais: CLM CONFIGURATION CHANGE
Oct 23 14:09:45 gnbdserver2 openais: New Configuration:
Oct 23 14:09:45 gnbdserver2 openais: r(0) ip(192.168.10.11)
Oct 23 14:09:45 gnbdserver2 openais: r(0) ip(192.168.10.12)
Oct 23 14:09:45 gnbdserver2 openais: r(0) ip(192.168.10.14)
Oct 23 14:09:45 gnbdserver2 fence_manual: Node gnbdserver1 needs to be reset before recovery can procede. Waiting for gnbdserver1 to rejoin the cluster or for manual acknowledgement that it has been reset (i.e. fence_ack_manual -n gnbdserver1)
Oct 23 14:09:45 gnbdserver2 openais: Members Left:
Oct 23 14:09:45 gnbdserver2 openais: Members Joined:
Oct 23 14:09:45 gnbdserver2 openais: This node is within the primary component and will provide service.
Oct 23 14:09:45 gnbdserver2 openais: entering OPERATIONAL state.
Oct 23 14:09:45 gnbdserver2 openais: got nodejoin message 192.168.10.11
Oct 23 14:09:45 gnbdserver2 openais: got nodejoin message 192.168.10.12
Oct 23 14:09:45 gnbdserver2 openais: got nodejoin message 192.168.10.14
Oct 23 14:09:45 gnbdserver2 openais: got joinlist message from node 2
Oct 23 14:09:45 gnbdserver2 openais: got joinlist message from node 3
Oct 23 14:09:45 gnbdserver2 openais: got joinlist message from node 4
現在我按照提示在gnbdserver2上執行命令來將gnbdserver1來fence掉：
# fence_ack_manual -n gnbdserver1
Warning: If the node "gnbdserver1" has not been manually fenced
(i.e. power cycled or disconnected from shared storage devices)
the GFS file system may become corrupted and all its data
unrecoverable! Please verify that the node shown above has
been reset or disconnected from storage.
Are you certain you want to continue? y
Done
命令執行成功之後，數據流將立刻切換到gnbdserver2上。如果我在gnbdclient1上終止dd進程能夠順利完成：
# dd if=/dev/zero of=test.img
163457+0 records in
163457+0 records out
83689984 bytes (84 MB) copied, 4.27649 seconds, 19.6 MB/s
# dd if=/dev/zero of=test.img
1653921+0 records in
1653921+0 records out
846807552 bytes (847 MB) copied, 158.782 seconds, 5.3 MB/s
這個時候監控gnbdserver2的後續的日誌：
Oct 23 14:10:57 gnbdserver2 fenced: fence "gnbdserver1" success
而在gnbdclient1上的整個日誌：
Oct 23 14:03:28 gnbdclient1 kernel: eth2: link down
Oct 23 14:03:38 gnbdclient1 kernel: gnbd (pid 5361: gnbd_recvd) got signal
Oct 23 14:03:38 gnbdclient1 kernel: gnbd0: Receive control failed (result -4)
Oct 23 14:03:38 gnbdclient1 kernel: gnbd0: shutting down socket
Oct 23 14:03:38 gnbdclient1 kernel: exiting GNBD_DO_IT ioctl
Oct 23 14:03:38 gnbdclient1 gnbd_recvd: client lost connection with 192.168.2.12 : Interrupted system call
Oct 23 14:03:38 gnbdclient1 gnbd_recvd: reconnecting
Oct 23 14:03:54 gnbdclient1 openais: The token was lost in the OPERATIONAL state.
Oct 23 14:03:54 gnbdclient1 openais: Receive multicast socket recv buffer size (288000 bytes).
Oct 23 14:03:54 gnbdclient1 openais: Transmit multicast socket send buffer size (219136 bytes).
Oct 23 14:03:54 gnbdclient1 openais: entering GATHER state from 2.
Oct 23 14:03:58 gnbdclient1 openais: entering GATHER state from 0.
Oct 23 14:03:58 gnbdclient1 openais: Creating commit token because I am the rep.
Oct 23 14:03:58 gnbdclient1 openais: Saving state aru 78 high seq received 78
Oct 23 14:03:58 gnbdclient1 openais: Storing new sequence id for ring 460
Oct 23 14:03:58 gnbdclient1 openais: entering COMMIT state.
Oct 23 14:03:59 gnbdclient1 openais: entering RECOVERY state.
Oct 23 14:03:59 gnbdclient1 openais: position member 192.168.10.11:
Oct 23 14:03:59 gnbdclient1 openais: previous ring seq 1116 rep 192.168.10.11
Oct 23 14:03:59 gnbdclient1 openais: aru 78 high delivered 78 received flag 1
Oct 23 14:03:59 gnbdclient1 openais: position member 192.168.10.12:
Oct 23 14:03:59 gnbdclient1 openais: previous ring seq 1116 rep 192.168.10.11
Oct 23 14:03:59 gnbdclient1 openais: aru 78 high delivered 78 received flag 1
Oct 23 14:03:59 gnbdclient1 openais: position member 192.168.10.14:
Oct 23 14:03:59 gnbdclient1 openais: previous ring seq 1116 rep 192.168.10.11
Oct 23 14:03:59 gnbdclient1 openais: aru 78 high delivered 78 received flag 1
Oct 23 14:03:59 gnbdclient1 openais: Did not need to originate any messages in recovery.
Oct 23 14:03:59 gnbdclient1 openais: Sending initial ORF token
Oct 23 14:03:59 gnbdclient1 openais: CLM CONFIGURATION CHANGE
Oct 23 14:03:59 gnbdclient1 openais: New Configuration:
Oct 23 14:03:59 gnbdclient1 openais: r(0) ip(192.168.10.11)
Oct 23 14:03:59 gnbdclient1 openais: r(0) ip(192.168.10.12)
Oct 23 14:03:59 gnbdclient1 openais: r(0) ip(192.168.10.14)
Oct 23 14:03:59 gnbdclient1 openais: Members Left:
Oct 23 14:03:59 gnbdclient1 openais: r(0) ip(192.168.10.13)
Oct 23 14:03:59 gnbdclient1 openais: Members Joined:
Oct 23 14:03:59 gnbdclient1 openais: CLM CONFIGURATION CHANGE
Oct 23 14:03:59 gnbdclient1 openais: New Configuration:
Oct 23 14:03:59 gnbdclient1 openais: r(0) ip(192.168.10.11)
Oct 23 14:03:59 gnbdclient1 openais: r(0) ip(192.168.10.12)
Oct 23 14:03:59 gnbdclient1 openais: r(0) ip(192.168.10.14)
Oct 23 14:03:59 gnbdclient1 openais: Members Left:
Oct 23 14:03:59 gnbdclient1 openais: Members Joined:
Oct 23 14:03:59 gnbdclient1 openais: This node is within the primary component and will provide service.
Oct 23 14:03:59 gnbdclient1 openais: entering OPERATIONAL state.
Oct 23 14:03:59 gnbdclient1 kernel: dlm: closing connection to node 1
Oct 23 14:03:59 gnbdclient1 openais: got nodejoin message 192.168.10.11
Oct 23 14:03:59 gnbdclient1 openais: got nodejoin message 192.168.10.12
Oct 23 14:03:59 gnbdclient1 openais: got nodejoin message 192.168.10.14
Oct 23 14:03:59 gnbdclient1 openais: got joinlist message from node 2
Oct 23 14:03:59 gnbdclient1 openais: got joinlist message from node 3
Oct 23 14:03:59 gnbdclient1 openais: got joinlist message from node 4
Oct 23 14:03:59 gnbdclient1 fenced: fencing deferred to gnbdserver2
Oct 23 14:04:26 gnbdclient1 gnbd_recvd: ERROR cannot connect to server 192.168.2.12 (-1) : No route to host
Oct 23 14:04:26 gnbdclient1 gnbd_recvd: reconnecting
Oct 23 14:04:34 gnbdclient1 gnbd_recvd: ERROR cannot connect to server 192.168.2.12 (-1) : No route to host
Oct 23 14:04:34 gnbdclient1 gnbd_recvd: reconnecting
Oct 23 14:04:35 gnbdclient1 multipathd: gnbd0: directio checker reports path is down
Oct 23 14:04:35 gnbdclient1 multipathd: checker failed path 252:0 in map yellow
Oct 23 14:04:35 gnbdclient1 multipathd: yellow: remaining active paths: 1
Oct 23 14:04:35 gnbdclient1 multipathd: dm-0: add map (uevent)
Oct 23 14:04:35 gnbdclient1 multipathd: dm-0: devmap already registered
Oct 23 14:04:35 gnbdclient1 kernel: device-mapper: multipath: Failing path 252:0.
Oct 23 14:04:41 gnbdclient1 multipathd: gnbd0: directio checker reports path is down
Oct 23 14:04:42 gnbdclient1 gnbd_recvd: ERROR cannot connect to server 192.168.2.12 (-1) : No route to host
Oct 23 14:04:42 gnbdclient1 gnbd_recvd: reconnecting
Oct 23 14:04:47 gnbdclient1 multipathd: gnbd0: directio checker reports path is down
Oct 23 14:04:50 gnbdclient1 gnbd_recvd: ERROR cannot connect to server 192.168.2.12 (-1) : No route to host
………………………………………………………………………………………………………………
Oct 23 14:04:58 gnbdclient1 gnbd_recvd: reconnecting
Oct 23 14:04:59 gnbdclient1 multipathd: gnbd0: directio checker reports path is down
Oct 23 14:05:05 gnbdclient1 multipathd: gnbd0: directio checker reports path is down
Oct 23 14:05:06 gnbdclient1 gnbd_recvd: ERROR cannot connect to server 192.168.2.12 (-1) : No route to host
Oct 23 14:05:06 gnbdclient1 gnbd_recvd: reconnecting
Oct 23 14:05:11 gnbdclient1 multipathd: gnbd0: directio checker reports path is down
Oct 23 14:05:14 gnbdclient1 kernel: gnbd_monitor 16518 called gnbd_end_request with an error
Oct 23 14:05:14 gnbdclient1 kernel: end_request: I/O error, dev gnbd0, sector 2759848
…………………………………………………………………………………………………………………
Oct 23 14:05:14 gnbdclient1 kernel: gnbd_monitor 16518 called gnbd_end_request with an error
Oct 23 14:05:14 gnbdclient1 kernel: end_request: I/O error, dev gnbd0, sector 3732744
Oct 23 14:05:16 gnbdclient1 multipathd: gnbd0: directio checker reports path is down
Oct 23 14:05:21 gnbdclient1 kernel: multipathd 4563 called gnbd_end_request with an error
Oct 23 14:05:21 gnbdclient1 kernel: end_request: I/O error, dev gnbd0, sector 0
…………………………………………………………………………………………………………
Oct 23 14:05:46 gnbdclient1 kernel: end_request: I/O error, dev gnbd0, sector 0
Oct 23 14:05:46 gnbdclient1 multipathd: gnbd0: directio checker reports path is down
Oct 23 14:05:51 gnbdclient1 kernel: multipathd 4563 called gnbd_end_request with an error
Oct 23 14:05:51 gnbdclient1 kernel: end_request: I/O error, dev gnbd0, sector 0
Oct 23 14:05:51 gnbdclient1 multipathd: gnbd0: directio checker reports path is down
而在gnbdclient2上的日誌信息:
Oct 23 13:56:25 gnbdclient2 kernel: gnbd (pid 5576: gnbd_recvd) got signal
Oct 23 13:56:25 gnbdclient2 kernel: gnbd0: Receive control failed (result -4)
Oct 23 13:56:25 gnbdclient2 kernel: gnbd0: shutting down socket
Oct 23 13:56:25 gnbdclient2 kernel: exiting GNBD_DO_IT ioctl
Oct 23 13:56:28 gnbdclient2 kernel: ls 15997 called gnbd_end_request with an error
Oct 23 13:56:28 gnbdclient2 kernel: end_request: I/O error, dev gnbd0, sector 208
Oct 23 13:56:28 gnbdclient2 kernel: device-mapper: multipath: Failing path 252:0.
Oct 23 13:56:28 gnbdclient2 multipathd: dm-0: add map (uevent)
Oct 23 13:56:28 gnbdclient2 multipathd: dm-0: devmap already registered
Oct 23 13:56:28 gnbdclient2 multipathd: 252:0: mark as failed
Oct 23 13:56:28 gnbdclient2 multipathd: yellow: remaining active paths: 1
………………………………………………………………………………………………………
Oct 23 13:57:05 gnbdclient2 kernel: end_request: I/O error, dev gnbd0, sector 0
Oct 23 13:57:05 gnbdclient2 multipathd: gnbd0: directio checker reports path is down
Oct 23 13:57:05 gnbdclient2 gnbd_recvd: gnbd_recvd started
Oct 23 13:57:05 gnbdclient2 kernel: resending requests
Oct 23 13:57:10 gnbdclient2 multipathd: gnbd0: directio checker reports path is up
Oct 23 13:57:10 gnbdclient2 multipathd: 252:0: reinstated
Oct 23 13:57:10 gnbdclient2 multipathd: yellow: remaining active paths: 2
Oct 23 13:57:10 gnbdclient2 multipathd: dm-0: add map (uevent)
Oct 23 13:57:10 gnbdclient2 multipathd: dm-0: devmap already registered
這樣證明斷線測試gnbd能夠觸發fence將失效gnbdserver踢出集群，這個時候multipath能夠正常工作。
第二部分的測試是模擬將整個的gnbdserver關閉掉。
其實我已經不用將任何輸出貼上來想必大家應該已經能夠猜到結果：如果還是像剛才那樣測試，在dd數據到GFS文件系統的時候將正在傳輸數據的vmnet3所連接的gnbdserver1整個關閉電源。這個時候dd的動作會停頓，在20s內，gnbdserver2上的日誌顯示gnbdserver1將被fence出集群，這個時候我繼續等待，待從中斷鏈路之後計算有一分鐘的時間，才去gnbdserver2上執行fence_ack_manual –n gnbdserver1命令。如果fence成功之後，隨後的數據流將全部通過vmnet4和gnbdserver2走。
整個試驗到此成功！
《解決方案》
在這個試驗當中最大的問題實際上是multipath和gnbdclient之間不能配合正常工作，我所面對的最多的現象就是在fence失效的gnbdserver之後，線路總是不能按照要求failover到其他的server上，而是不斷報告error信息，而且在GFS上的觀測顯示，的確沒有新的數據流寫入，這個時候不管終止dd進程還是cd到/mnt去看都將稱為z狀態進程，從而multipath不能發揮作用。
從我實際測試的情況看，如果在某個gnbdserver發出要fence另外一個gnbdserver的請求時，如果立即fence掉指定的節點，這個時候儘管fence成功但multipath不能正確failover線路；我將該情況歸結於使用iscsi作為共享存儲的時候，如果配置了多路徑其本身的切換速度就會比較慢，像剛才mar所說的那樣，從normal到timeout到failed到restarable這個過程完成之後multipath才能實現對線路的切換。但是如果從某個節點上向另外一個節點發送fence請求之後就立即將對方幹掉，這個時候iscsi的底層切換還沒有完成一次從normal到restarable的過程，所以這個時侯multipath將無法接管失效鏈路。
因此總結出來的方法也很簡單，我在斷掉某個鏈路做測試的時候開始計時，在十數秒之後其中一個gnbdserver會發出fence失效節點的請求，在該請求發出大概30s以上的時間，我可能會選擇一分鐘或更長時間才執行fence_ack_manual，這樣經過實際驗證大大提高了multipath切換鏈路的成功率。
另外還有一個地方值得注意，就是在gnbdclient上，每次啟動系統之後不管gnbd_import的內容是否正常都要進行一次檢查並將沒有正確import的鏈路再次import進來。由於這種import通常寫入到系統自動啟動腳本中，所以不需要太多關注內容是否正確，而需要關注的是務必手動重啟一次multipathd，或者可以將multipathd的啟動順序調整到一個比較靠後的位置，也就是確保每次正確import了所有共享鏈路之後再重啟multipathd服務。這樣也能夠保證multipathd切換鏈路的成功率。
《解決方案》
I finished reading part I, excellent! exactly what I am looking for.
There is something wrong here:
開發者特意在官方文檔中提到了gnbd的multipath功能，而沒有提到iscsi也能實現multipath
Changes to GFS 6.1 for RHEL4 U2
This release supports iSCSI and multipath iSCSI. That is, device mapper
multipath (dm-multipath) can use iSCSI.
This release prevents the activation of snapshots in a clustered volume
group.
Important Notes
Multipath GNBD is not available with this and previous releases of
Red Hat GFS 6.1. That is, device mapper multipath (dm-multipath)
cannot use GNBD. GNBD without multipath *is* available.
[ 本帖最後由 gl00ad 於 2008-10-25 06:52 編輯 ]
《解決方案》
好文:oops: :oops:
《解決方案》
贊一個！樓主太強大了
另外請問這種網路拓撲圖是拿什麼軟體畫的啊？
《解決方案》
原帖由 蟲蟲貓 於 2008-10-24 22:58 發表 http://linux.chinaunix.net/bbs/images/common/back.gif
贊一個！樓主太強大了
另外請問這種網路拓撲圖是拿什麼軟體畫的啊？
微軟的 visio。
《解決方案》
:lol: :lol: :lol: jerrywjl 佬大，又亮劍了，支持了
《解決方案》
原帖由 gl00ad 於 2008-10-24 10:49 發表 http://linux.chinaunix.net/bbs/images/common/back.gif
I finished reading part I, excellent! exactly what I am looking for.
There is something wrong here:
開發者特意在官方文檔中提到了gnbd的multipath功能，而沒有提到iscsi也能實現multipath
Chan ...
OK，這位哥們的官方文檔看得真是不錯！
不過遺憾的是，官方文檔只是說明能與不能，但並沒有說明原因。事實是我和開發者和一些存儲工程師了解這方面的問題，他們的答案和我實驗的結果一樣——即在很多時候在不同的產品上針對不同類型的設備和驅動會有比較大的結果差異，但並不是說這套原理在這套機制上行不通。但出於穩定和負責任的考慮，所以在官方文檔中給一個相對保守的定論，而並非百分百不行。
更何況我已經在我的文檔中說清楚了，如果我有硬體光纖存儲設備去實現multipath，有真實伺服器，你認為我會用vmware和iscsi去模擬環境嗎？所以在這裡我只是說明原理和方法步驟，而並不是說這樣一個環境就可以肯定在生產環境中穩定使用。
事實上由於gnbd本身是一個即將過期的產品，從性能上和管理上這其實並非一個好的選擇，但會有一些用戶因為現實的限制會考慮採用該方案，那麼這個時候就比較痛苦了，因為一沒有完整的文檔，二會因為協議和設備特性的問題不可避免地導致測試有誤，三是即便成功也出現很多性能方面的問題。
這篇文章的目的，第一是從理論和實踐上補充在實施文檔上的不足，第二告知使用這種方案可能出現的問題和風險，希望更多人在考慮該方案的時候有所參考，至於第三嘛，希望那些做實施的哥們別光想著算經濟帳，完全不考慮是否會給自己找太多麻煩。
[火星人 ] RHCS + GNBD實現基於multipath上的GFS文件系統已經有669次圍觀
