免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
123下一页
最近访问板块 发新帖
查看: 19953 | 回复: 25

(原创)RHCS + GNBD实现基于multipath上的GFS文件系统 [复制链接]

论坛徽章:
0
发表于 2008-10-24 09:58 |显示全部楼层
在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之前要构建一个四节点集群。
GNBD_ARC_MOD3.PNG

论坛徽章:
0
发表于 2008-10-24 09:59 |显示全部楼层
现在开始配置:
首先是iscsitarget上的配置。这个服务器上的基本情况和配置信息包括:
地址信息:
[root@localhost ~]# 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的硬盘作为共享:
[root@localhost ~]# 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
[root@localhost ~]# rpm -qa | grep scsi
scsi-target-utils-0.0-0.20070620snap.el5
iscsi-initiator-utils-6.2.0.868-0.7.el5
[root@localhost ~]# rpm -ql scsi-target-utils
/etc/rc.d/init.d/tgtd
/usr/sbin/tgtadm
/usr/sbin/tgtd
之后启动scsitarget服务:
[root@localhost ~]# service tgtd start
[root@localhost ~]# chkconfig --level 345 tgtd on
并将共享设备规则写入到/etc/rc.local中。没办法,这个产品还是预览版本,所以只能将就了:
[root@localhost ~]# 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服务:
[root@localhost ~]# service tgtd restart

到此为止在iscsi-target上的配置基本完成。下面是iscsi-initiator上的配置:
首先是基本网络信息:
[root@gnbdserver1 ~]# hostname
gnbdserver1
[root@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包,然后执行下面的操作:
[root@gnbdserver1 ~]# service iscsi restart
[root@gnbdserver1 ~]# chkconfig --level 345 iscsi on
[root@gnbdserver1 ~]# 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存储,并重启服务:
[root@gnbdserver1 ~]# service iscsi restart
[root@gnbdserver1 ~]# iscsiadm --mode node
172.16.1.10:3260,1 iqn.2008-09.gnbd.storage.sdb
[root@gnbdserver1 ~]# 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的基本信息列出来:
[root@gnbdserver2 ~]# hostname
gnbdserver2
[root@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的基本信息,做加入集群的准备工作:
[root@gnbdclient1 ~]# hostname
gnbdclient1
[root@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
[root@gnbdclient1 ~]# 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,并启动该服务:
[root@gnbdclient1 ~]# service multiapthd restart
[root@gnbdclient1 ~]# chkconfig –-level 345 multipathd on
[root@gnbdclient2 ~]# service multiapthd restart
[root@gnbdclient2 ~]# 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的功能。完成之后将配置文件同步到其他主机,下面是我的配置文件:
[root@gnbdclient1 ~]# cat /etc/cluster/cluster.conf
<?xml version="1.0"?>
<cluster config_version="6" name="gnbd_cluster">
        <fence_daemon post_fail_delay="0" post_join_delay="3"/>
        <clusternodes>
                <clusternode name="gnbdserver1" nodeid="1" votes="1">
                        <fence>
                                <method name="1">
                                        <device name="mfence" nodename="gnbdserver1"/>
                                </method>
                        </fence>
                </clusternode>
                <clusternode name="gnbdserver2" nodeid="2" votes="1">
                        <fence>
                                <method name="1">
                                        <device name="mfence" nodename="gnbdserver2"/>
                                </method>
                        </fence>
                </clusternode>
                <clusternode name="gnbdclient1" nodeid="3" votes="1">
                        <fence>
                                <method name="1">
                                        <device name="mfence" nodename="gnbdclient1"/>
                                </method>
                        </fence>
                </clusternode>
                <clusternode name="gnbdclient2" nodeid="4" votes="1">
                        <fence>
                                <method name="1">
                                        <device name="mfence" nodename="gnbdclient2"/>
                                </method>
                        </fence>
                </clusternode>
        </clusternodes>
        <cman/>
        <fencedevices>
                <fencedevice agent="fence_manual" name="mfence"/>
        </fencedevices>
        <rm>
                <failoverdomains>
                        <failoverdomain name="server" ordered="1" restricted="1">
                                <failoverdomainnode name="gnbdserver1" priority="1"/>
                                <failoverdomainnode name="gnbdserver2" priority="1"/>
                        </failoverdomain>
                        <failoverdomain name="client" ordered="1" restricted="1">
                                <failoverdomainnode name="gnbdclient1" priority="1"/>
                                <failoverdomainnode name="gnbdclient2" priority="1"/>
                        </failoverdomain>
                </failoverdomains>
                <resources/>
        </rm>
</cluster>

然后在所有gnbdclients和gnbdservers上开启集群服务并重启所有系统:
[root@gnbdclient1 ~]# chkconfig --level 345 cman on
[root@gnbdclient1 ~]# chkconfig --level 345 rgmanager on
[root@gnbdclient1 ~]# chkconfig --level 345 gfs on
最后再次重启所有系统。

在系统启动之后,如果配置没错并且拓扑没错的话集群也就已经起来了。接着在gnbdservers上建立gfs文件系统,注意,这里gfs文件系统要针对整个分区建立而不是lvm上建立,因为在lvm上构建GFS文件系统在后期gnbd export的时候会出错。所以自然也就不需要启动clvmd服务。

下面是建立gfs文件系统的步骤,可以在任何一台gnbdserver上建立gfs文件系统:
先用fdisk将共享盘划分为整个一个单分区,然后执行gfs_mkfs命令:
[root@gnbdclient1 ~]# 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文件中:
[root@gnbdserver1 ~]# 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
然后执行该文件:
[root@gnbdserver1 ~]# /etc/rc.local
完成之后查看:
[root@gnbdserver1 ~]# gnbd_export -l
Server[1] : 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一样,稍有不同的是配置文件内容,所以我只给出配置文件,其他不再赘述。
[root@gnbdserver2 ~]# 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中:
[root@gnbdclient1 ~]# 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
并执行该脚本:
[root@gnbdserver1 ~]# /etc/rc.local
查看执行情况:
[root@gnbdclient1 ~]# 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

[root@gnbdclient1 ~]# gnbd_monitor
device #   timeout   state
       1         5   normal
       0         5   normal

当然在gnbdclient2上的配置和测试过程完全一样,不再赘述。

到此为止gnbd在server和client上的配置都已经全部完成。

最后是在gnbdclients上部署multipath。刚才已经安装了相关的multipath包,所以直接修改配置文件。除了修改blacklist之外,将原来的default段的内容修改如下:
[root@gnbdclient1 ~]# 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配置,完成之后保存并启用服务:

[root@gnbdclient1 ~]# service multipathd restart
[root@gnbdclient1 ~]# chkconfig --level 345 multipathd on
[root@gnbdclient1 ~]# multipath -ll
yellow (GNBD-1-16465616462656166313a3100000000000000000000000000) dm-0 GNBD,GNBD
[size=3.7G][features=1 queue_if_no_path][hwhandler=0]
\_ round-robin 0 [prio=1][active]
\_ #:#:#:# gnbd0 252:0 [active][ready]
\_ round-robin 0 [prio=1][enabled]
\_ #:#:#:# gnbd1 252:1 [active][ready]

下面把配置文件multipath.conf同步到gnbdclient2上,然后按照同样的步骤启用服务,这样整个的试验结构就算全部完成。

论坛徽章:
0
发表于 2008-10-24 10:01 |显示全部楼层
下面开始按照预先的设想去进行测试:
为了保证一个干净的环境,首先重启全部节点并清空所有节点上的日志:
# > /var/log/messages,
然后在gnbdclient1上挂载gfs文件系统:
[root@gnbdclient1 ~]# mount /dev/mpath/yellow /mnt/
[root@gnbdclient1 ~]# df -TH /mnt
Filesystem    Type     Size   Used  Avail Use% Mounted on
/dev/dm-0      gfs     3.8G   889M   2.9G  24% /mnt
[root@gnbdclient1 ~]# 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上也同样挂载该文件系统:
[root@gnbdclient2 ~]# mount /dev/mpath/yellow /mnt/
在gnbdclient2上监控/mnt:
[root@gnbdclient2 ~]# watch -n1 "ls -l /mnt"

然后在gnbdclient1上向GFS文件系统dd数据:
[root@gnbdclient1 mnt]# dd if=/dev/zero of=test.img
在执行该命令的时候,我们会通过虚拟机网络接口发现数据流在vmnet3上,根据结构图判断,数据是在通过gnbdserver1走。然后我将gnbdclient1和gnbdserver1连接的链路在gnbdclient1上物理断开。数据流将出现暂时的中断。
然后在gnbdserver1上出现下面的报错信息:
[root@gnbdserver1 ~]# cat /var/log/messages
Oct 23 14:05:26 gnbdserver1 openais[4857]: [CMAN ] cman killed by node 3 because we were killed by cman_tool or other application
Oct 23 14:05:26 gnbdserver1 gfs_controld[4885]: groupd_dispatch error -1 errno 11
Oct 23 14:05:26 gnbdserver1 gfs_controld[4885]: groupd connection died
Oct 23 14:05:26 gnbdserver1 gfs_controld[4885]: cluster is down, exiting
Oct 23 14:05:26 gnbdserver1 dlm_controld[4879]: 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[5672]: ERROR [gnbd_clusterd.c:72] Bad poll result 0x11 from cluster
Oct 23 14:05:30 gnbdserver1 fenced[4873]: cluster is down, exiting
Oct 23 14:05:47 gnbdserver1 ccsd[4817]: Unable to connect to cluster infrastructure after 30 seconds.
而在gnbdserver2上认为gnbdserver1将被fence出集群:
[root@gnbdserver2 ~]# cat /var/log/messages
Oct 23 14:09:40 gnbdserver2 openais[4832]: [TOTEM] entering GATHER state from 12.
Oct 23 14:09:44 gnbdserver2 openais[4832]: [TOTEM] entering GATHER state from 11.
Oct 23 14:09:45 gnbdserver2 openais[4832]: [TOTEM] Saving state aru 78 high seq received 78
Oct 23 14:09:45 gnbdserver2 openais[4832]: [TOTEM] Storing new sequence id for ring 460
Oct 23 14:09:45 gnbdserver2 openais[4832]: [TOTEM] entering COMMIT state.
Oct 23 14:09:45 gnbdserver2 openais[4832]: [TOTEM] entering RECOVERY state.
Oct 23 14:09:45 gnbdserver2 openais[4832]: [TOTEM] position [0] member 192.168.10.11:
Oct 23 14:09:45 gnbdserver2 openais[4832]: [TOTEM] previous ring seq 1116 rep 192.168.10.11
Oct 23 14:09:45 gnbdserver2 openais[4832]: [TOTEM] aru 78 high delivered 78 received flag 1
Oct 23 14:09:45 gnbdserver2 openais[4832]: [TOTEM] position [1] member 192.168.10.12:
Oct 23 14:09:45 gnbdserver2 openais[4832]: [TOTEM] previous ring seq 1116 rep 192.168.10.11
Oct 23 14:09:45 gnbdserver2 openais[4832]: [TOTEM] aru 78 high delivered 78 received flag 1
Oct 23 14:09:45 gnbdserver2 openais[4832]: [TOTEM] position [2] member 192.168.10.14:
Oct 23 14:09:45 gnbdserver2 openais[4832]: [TOTEM] previous ring seq 1116 rep 192.168.10.11
Oct 23 14:09:45 gnbdserver2 openais[4832]: [TOTEM] aru 78 high delivered 78 received flag 1
Oct 23 14:09:45 gnbdserver2 openais[4832]: [TOTEM] Did not need to originate any messages in recovery.
Oct 23 14:09:45 gnbdserver2 openais[4832]: [CLM  ] CLM CONFIGURATION CHANGE
Oct 23 14:09:45 gnbdserver2 openais[4832]: [CLM  ] New Configuration:
Oct 23 14:09:45 gnbdserver2 openais[4832]: [CLM  ]      r(0) ip(192.168.10.11)  
Oct 23 14:09:45 gnbdserver2 openais[4832]: [CLM  ]      r(0) ip(192.168.10.12)  
Oct 23 14:09:45 gnbdserver2 openais[4832]: [CLM  ]      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[4832]: [CLM  ] Members Left:
Oct 23 14:09:45 gnbdserver2 openais[4832]: [CLM  ]      r(0) ip(192.168.10.13)  
Oct 23 14:09:45 gnbdserver2 fenced[4848]: gnbdserver1 not a cluster member after 0 sec post_fail_delay
Oct 23 14:09:45 gnbdserver2 openais[4832]: [CLM  ] Members Joined:
Oct 23 14:09:45 gnbdserver2 fenced[4848]: fencing node "gnbdserver1"
Oct 23 14:09:45 gnbdserver2 openais[4832]: [CLM  ] CLM CONFIGURATION CHANGE
Oct 23 14:09:45 gnbdserver2 openais[4832]: [CLM  ] New Configuration:
Oct 23 14:09:45 gnbdserver2 openais[4832]: [CLM  ]      r(0) ip(192.168.10.11)  
Oct 23 14:09:45 gnbdserver2 openais[4832]: [CLM  ]      r(0) ip(192.168.10.12)  
Oct 23 14:09:45 gnbdserver2 openais[4832]: [CLM  ]      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[4832]: [CLM  ] Members Left:
Oct 23 14:09:45 gnbdserver2 openais[4832]: [CLM  ] Members Joined:
Oct 23 14:09:45 gnbdserver2 openais[4832]: [SYNC ] This node is within the primary component and will provide service.
Oct 23 14:09:45 gnbdserver2 openais[4832]: [TOTEM] entering OPERATIONAL state.
Oct 23 14:09:45 gnbdserver2 openais[4832]: [CLM  ] got nodejoin message 192.168.10.11
Oct 23 14:09:45 gnbdserver2 openais[4832]: [CLM  ] got nodejoin message 192.168.10.12
Oct 23 14:09:45 gnbdserver2 openais[4832]: [CLM  ] got nodejoin message 192.168.10.14
Oct 23 14:09:45 gnbdserver2 openais[4832]: [CPG  ] got joinlist message from node 2
Oct 23 14:09:45 gnbdserver2 openais[4832]: [CPG  ] got joinlist message from node 3
Oct 23 14:09:45 gnbdserver2 openais[4832]: [CPG  ] got joinlist message from node 4

现在我按照提示在gnbdserver2上执行命令来将gnbdserver1来fence掉:
[root@gnbdserver2 ~]# 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? [yN] y
Done
命令执行成功之后,数据流将立刻切换到gnbdserver2上。如果我在gnbdclient1上终止dd进程能够顺利完成:
[root@gnbdclient1 mnt]# 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

[root@gnbdclient1 mnt]# 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[4848]: 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[5361]: client lost connection with 192.168.2.12 : Interrupted system call
Oct 23 14:03:38 gnbdclient1 gnbd_recvd[5361]: reconnecting
Oct 23 14:03:54 gnbdclient1 openais[4711]: [TOTEM] The token was lost in the OPERATIONAL state.
Oct 23 14:03:54 gnbdclient1 openais[4711]: [TOTEM] Receive multicast socket recv buffer size (288000 bytes).
Oct 23 14:03:54 gnbdclient1 openais[4711]: [TOTEM] Transmit multicast socket send buffer size (219136 bytes).
Oct 23 14:03:54 gnbdclient1 openais[4711]: [TOTEM] entering GATHER state from 2.
Oct 23 14:03:58 gnbdclient1 openais[4711]: [TOTEM] entering GATHER state from 0.
Oct 23 14:03:58 gnbdclient1 openais[4711]: [TOTEM] Creating commit token because I am the rep.
Oct 23 14:03:58 gnbdclient1 openais[4711]: [TOTEM] Saving state aru 78 high seq received 78
Oct 23 14:03:58 gnbdclient1 openais[4711]: [TOTEM] Storing new sequence id for ring 460
Oct 23 14:03:58 gnbdclient1 openais[4711]: [TOTEM] entering COMMIT state.
Oct 23 14:03:59 gnbdclient1 openais[4711]: [TOTEM] entering RECOVERY state.
Oct 23 14:03:59 gnbdclient1 openais[4711]: [TOTEM] position [0] member 192.168.10.11:
Oct 23 14:03:59 gnbdclient1 openais[4711]: [TOTEM] previous ring seq 1116 rep 192.168.10.11
Oct 23 14:03:59 gnbdclient1 openais[4711]: [TOTEM] aru 78 high delivered 78 received flag 1
Oct 23 14:03:59 gnbdclient1 openais[4711]: [TOTEM] position [1] member 192.168.10.12:
Oct 23 14:03:59 gnbdclient1 openais[4711]: [TOTEM] previous ring seq 1116 rep 192.168.10.11
Oct 23 14:03:59 gnbdclient1 openais[4711]: [TOTEM] aru 78 high delivered 78 received flag 1
Oct 23 14:03:59 gnbdclient1 openais[4711]: [TOTEM] position [2] member 192.168.10.14:
Oct 23 14:03:59 gnbdclient1 openais[4711]: [TOTEM] previous ring seq 1116 rep 192.168.10.11
Oct 23 14:03:59 gnbdclient1 openais[4711]: [TOTEM] aru 78 high delivered 78 received flag 1
Oct 23 14:03:59 gnbdclient1 openais[4711]: [TOTEM] Did not need to originate any messages in recovery.
Oct 23 14:03:59 gnbdclient1 openais[4711]: [TOTEM] Sending initial ORF token
Oct 23 14:03:59 gnbdclient1 openais[4711]: [CLM  ] CLM CONFIGURATION CHANGE
Oct 23 14:03:59 gnbdclient1 openais[4711]: [CLM  ] New Configuration:
Oct 23 14:03:59 gnbdclient1 openais[4711]: [CLM  ]      r(0) ip(192.168.10.11)  
Oct 23 14:03:59 gnbdclient1 openais[4711]: [CLM  ]      r(0) ip(192.168.10.12)  
Oct 23 14:03:59 gnbdclient1 openais[4711]: [CLM  ]      r(0) ip(192.168.10.14)  
Oct 23 14:03:59 gnbdclient1 openais[4711]: [CLM  ] Members Left:
Oct 23 14:03:59 gnbdclient1 openais[4711]: [CLM  ]      r(0) ip(192.168.10.13)  
Oct 23 14:03:59 gnbdclient1 openais[4711]: [CLM  ] Members Joined:
Oct 23 14:03:59 gnbdclient1 openais[4711]: [CLM  ] CLM CONFIGURATION CHANGE
Oct 23 14:03:59 gnbdclient1 openais[4711]: [CLM  ] New Configuration:
Oct 23 14:03:59 gnbdclient1 openais[4711]: [CLM  ]      r(0) ip(192.168.10.11)  
Oct 23 14:03:59 gnbdclient1 openais[4711]: [CLM  ]      r(0) ip(192.168.10.12)  
Oct 23 14:03:59 gnbdclient1 openais[4711]: [CLM  ]      r(0) ip(192.168.10.14)  
Oct 23 14:03:59 gnbdclient1 openais[4711]: [CLM  ] Members Left:
Oct 23 14:03:59 gnbdclient1 openais[4711]: [CLM  ] Members Joined:
Oct 23 14:03:59 gnbdclient1 openais[4711]: [SYNC ] This node is within the primary component and will provide service.
Oct 23 14:03:59 gnbdclient1 openais[4711]: [TOTEM] entering OPERATIONAL state.
Oct 23 14:03:59 gnbdclient1 kernel: dlm: closing connection to node 1
Oct 23 14:03:59 gnbdclient1 openais[4711]: [CLM  ] got nodejoin message 192.168.10.11
Oct 23 14:03:59 gnbdclient1 openais[4711]: [CLM  ] got nodejoin message 192.168.10.12
Oct 23 14:03:59 gnbdclient1 openais[4711]: [CLM  ] got nodejoin message 192.168.10.14
Oct 23 14:03:59 gnbdclient1 openais[4711]: [CPG  ] got joinlist message from node 2
Oct 23 14:03:59 gnbdclient1 openais[4711]: [CPG  ] got joinlist message from node 3
Oct 23 14:03:59 gnbdclient1 openais[4711]: [CPG  ] got joinlist message from node 4
Oct 23 14:03:59 gnbdclient1 fenced[4727]: fencing deferred to gnbdserver2
Oct 23 14:04:26 gnbdclient1 gnbd_recvd[5361]: ERROR [gnbd_recvd.c:213] cannot connect to server 192.168.2.12 (-1) : No route to host
Oct 23 14:04:26 gnbdclient1 gnbd_recvd[5361]: reconnecting
Oct 23 14:04:34 gnbdclient1 gnbd_recvd[5361]: ERROR [gnbd_recvd.c:213] cannot connect to server 192.168.2.12 (-1) : No route to host
Oct 23 14:04:34 gnbdclient1 gnbd_recvd[5361]: 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[5361]: ERROR [gnbd_recvd.c:213] cannot connect to server 192.168.2.12 (-1) : No route to host
Oct 23 14:04:42 gnbdclient1 gnbd_recvd[5361]: reconnecting
Oct 23 14:04:47 gnbdclient1 multipathd: gnbd0: directio checker reports path is down
Oct 23 14:04:50 gnbdclient1 gnbd_recvd[5361]: ERROR [gnbd_recvd.c:213] cannot connect to server 192.168.2.12 (-1) : No route to host
………………………………………………………………………………………………………………
Oct 23 14:04:58 gnbdclient1 gnbd_recvd[5361]: 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[5361]: ERROR [gnbd_recvd.c:213] cannot connect to server 192.168.2.12 (-1) : No route to host
Oct 23 14:05:06 gnbdclient1 gnbd_recvd[5361]: 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[16027]: 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走。

整个试验到此成功!

论坛徽章:
0
发表于 2008-10-24 10:02 |显示全部楼层
在这个试验当中最大的问题实际上是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切换链路的成功率。

论坛徽章:
0
发表于 2008-10-24 10:49 |显示全部楼层

GNBD - no multipath support for it now

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 编辑 ]

论坛徽章:
0
发表于 2008-10-24 20:49 |显示全部楼层
好文

论坛徽章:
4
白银圣斗士
日期:2015-11-24 10:40:40技术图书徽章
日期:2015-11-26 13:47:47平安夜徽章
日期:2015-12-26 00:06:30技术图书徽章
日期:2016-07-19 13:54:03
发表于 2008-10-24 22:58 |显示全部楼层
赞一个!楼主太强大了
另外请问这种网络拓扑图是拿什么软件画的啊?

论坛徽章:
0
发表于 2008-10-24 23:33 |显示全部楼层
原帖由 虫虫猫 于 2008-10-24 22:58 发表
赞一个!楼主太强大了
另外请问这种网络拓扑图是拿什么软件画的啊?


微软的 visio。

论坛徽章:
4
IT运维版块每日发帖之星
日期:2015-09-01 06:20:00IT运维版块每日发帖之星
日期:2015-10-09 06:20:00操作系统版块每日发帖之星
日期:2015-10-20 06:20:00IT运维版块每日发帖之星
日期:2015-11-03 06:20:00
发表于 2008-10-25 00:03 |显示全部楼层
jerrywjl 佬大,又亮剑了,支持了

论坛徽章:
0
发表于 2008-10-25 12:27 |显示全部楼层
原帖由 gl00ad 于 2008-10-24 10:49 发表
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本身是一个即将过期的产品,从性能上和管理上这其实并非一个好的选择,但会有一些用户因为现实的限制会考虑采用该方案,那么这个时候就比较痛苦了,因为一没有完整的文档,二会因为协议和设备特性的问题不可避免地导致测试有误,三是即便成功也出现很多性能方面的问题。

这篇文章的目的,第一是从理论和实践上补充在实施文档上的不足,第二告知使用这种方案可能出现的问题和风险,希望更多人在考虑该方案的时候有所参考,至于第三嘛,希望那些做实施的哥们别光想着算经济帐,完全不考虑是否会给自己找太多麻烦。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP