[Bug 211964] CTL HA interconnect issue - unknown oid 'kern.cam.ctl.ha_peer'

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211964

James StewartNewman <james.stewartnewman at sas.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|New                         |Closed

--- Comment #1 from James StewartNewman <james.stewartnewman at sas.com> ---
ok after applying r304737
and editing the /boot/loader.conf and /etc/sysctl.conf I now get the cluster
interconnect connection to establish 

Server 1 config (Primary Node) 
# cat /boot/loader.conf
geom_mirror_load="YES"
geom_label_load="YES"
hw.memtest.tests=0
geom_multipath_load="YES"
kern.geom.label.disk_ident.enable=0
kern.cam.ctl.ha_id=1
kern.cam.ctl.ha_mode=2

# cat /etc/sysctl.conf
# $FreeBSD: releng/10.3/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux $

kern.cam.ctl.debug=2
kern.cam.ctl.ha_peer="connect 172.16.1.3:7940" #directly connected cable no
switch between the nodes 
kern.cam.ctl.ha_role=0 # 0 is primary; 1 is secondary

# sysctl -a | grep ctl.ha
kern.cam.ctl.ha_peer: connect 172.16.1.3:7940
kern.cam.ctl.ha_role: 0
kern.cam.ctl.ha_link: 2
kern.cam.ctl.ha_id: 1
kern.cam.ctl.ha_mode: 2



Server 2 config (Secondary Node) 
# cat /boot/loader.conf
geom_mirror_load="YES"
geom_label_load="YES"
kern.geom.label.disk_ident.enable=0
hw.memtest.tests=0
geom_multipath_load="YES"
kern.cam.ctl.ha_id=2
kern.cam.ctl.ha_mode=2

# cat /etc/sysctl.conf
kern.cam.ctl.debug=2
kern.cam.ctl.ha_peer="listen 172.16.1.3:7940"
kern.cam.ctl.ha_role=1 # 0 is primary; 1 is secondary

# sysctl -a | grep ctl.ha
kern.cam.ctl.ha_peer: listen 172.16.1.3:7940
kern.cam.ctl.ha_role: 1
kern.cam.ctl.ha_link: 2
kern.cam.ctl.ha_id: 2
kern.cam.ctl.ha_mode: 2

So its connection is established in active/active proxy mode 
(netstat -a on both nodes also shows established connections) 

Server 1 
ctladm shows the ha ports 
# ctladm portlist
Port Online Frontend Name pp vp
0 YES tpc tpc 0 0
1 NO camsim camsim 0 0 naa.5000000acfe0eb02
2 YES ioctl ioctl 0 0
3 YES camtgt isp0 0 0 naa.2100000e1ecb9ed0
4 YES camtgt isp1 0 0 naa.2100000e1ecb9ed1
5 YES camtgt isp2 0 0 naa.2100000e1ecbafc0
6 YES camtgt isp3 0 0 naa.2100000e1ecbafc1
128 YES ha 2:tpc 0 0
129 YES ha 2:camsim 0 0 naa.5000000acfe0eb82
130 YES ha 2:ioctl 0 0
131 YES ha 2:isp0 0 0 naa.2100000e1ecb99b0
132 YES ha 2:isp1 0 0 naa.2100000e1ecb99b1
133 YES ha 2:isp2 0 0 naa.2100000e1ecbad40
134 YES ha 2:isp3 0 0 naa.2100000e1ecbad41

ctladm shows the initiatiors are logging into the ports on the other node 
# ctladm portlist -i
Port Online Frontend Name pp vp
0 YES tpc tpc 0 0
1 NO camsim camsim 0 0 naa.5000000acfe0eb02
Target: naa.5000000acfe0eb00
2 YES ioctl ioctl 0 0
3 YES camtgt isp0 0 0 naa.2100000e1ecb9ed0
Target: naa.2000000e1ecbafc1
Initiator 1: naa.10000090faa9eb37
4 YES camtgt isp1 0 0 naa.2100000e1ecb9ed1
Target: naa.2000000e1ecbafc1
Initiator 1: naa.10000090faa9e93b
5 YES camtgt isp2 0 0 naa.2100000e1ecbafc0
Target: naa.2000000e1ecbafc1
Initiator 1: naa.10000090faa9eb37
6 YES camtgt isp3 0 0 naa.2100000e1ecbafc1
Target: naa.2000000e1ecbafc1
Initiator 1: naa.10000090faa9e93b
128 YES ha 2:tpc 0 0
129 YES ha 2:camsim 0 0 naa.5000000acfe0eb82
Target: naa.5000000acfe0eb00
130 YES ha 2:ioctl 0 0
131 YES ha 2:isp0 0 0 naa.2100000e1ecb99b0
Target: naa.2000000e1ecb99b0
Initiator 1: naa.10000090faa9eb37
132 YES ha 2:isp1 0 0 naa.2100000e1ecb99b1
Target: naa.2000000e1ecb99b1
Initiator 1: naa.10000090faa9e93b
133 YES ha 2:isp2 0 0 naa.2100000e1ecbad40
Target: naa.2000000e1ecbad40
Initiator 1: naa.10000090faa9eb37
134 YES ha 2:isp3 0 0 naa.2100000e1ecbad41
Target: naa.2000000e1ecbad41
Initiator 1: naa.10000090faa9e93b

# ctladm portlist -l
Port Online Frontend Name pp vp
0 YES tpc tpc 0 0
All LUNs mapped
1 NO camsim camsim 0 0 naa.5000000acfe0eb02
All LUNs mapped
2 YES ioctl ioctl 0 0
All LUNs mapped
3 YES camtgt isp0 0 0 naa.2100000e1ecb9ed0
LUN 0: 0
LUN 1: 1
LUN 2: 2
LUN 3: 3
4 YES camtgt isp1 0 0 naa.2100000e1ecb9ed1
LUN 0: 0
LUN 1: 1
LUN 2: 2
LUN 3: 3
5 YES camtgt isp2 0 0 naa.2100000e1ecbafc0
LUN 0: 0
LUN 1: 1
LUN 2: 2
LUN 3: 3
6 YES camtgt isp3 0 0 naa.2100000e1ecbafc1
LUN 0: 0
LUN 1: 1
LUN 2: 2
LUN 3: 3
128 YES ha 2:tpc 0 0
All LUNs mapped
129 YES ha 2:camsim 0 0 naa.5000000acfe0eb82
All LUNs mapped
130 YES ha 2:ioctl 0 0
All LUNs mapped
131 YES ha 2:isp0 0 0 naa.2100000e1ecb99b0
All LUNs mapped
132 YES ha 2:isp1 0 0 naa.2100000e1ecb99b1
All LUNs mapped
133 YES ha 2:isp2 0 0 naa.2100000e1ecbad40
All LUNs mapped
134 YES ha 2:isp3 0 0 naa.2100000e1ecbad41
All LUNs mapped


So everything looks good ... but when I unplug the SAN connections on the
primary node server 1 What I expect to happen is that it will continue to
function by its connections to the secondary server and data move across the
cluster interconnect. What happens is that the client server loses all
connectivity to the LUNS. Tried this with same results on my FreeBSD array that
uses iSCSI as well. 

Ideas?

-- 
You are receiving this mail because:
You are the assignee for the bug.