Re: HAST, configuration, this actually looks insane

[Pete French]

I aalways found hast very easy to configure - I stopped using it a 
couple of weeks ago, but up until then we had used it heavily in 
production. Have found some old config files, which do work, as examples:


two machines - catbert-active, catbert-passive. catbert-active is 
192.168.10.3, passive is 192.168.10.4.


on catbert-active:

resource cbert0 {
replication memsync
local   /dev/gpt/catbert-active-hast-a
on  catbert-active  {
remote  tcp4://192.168.10.4
source  tcp4://192.168.10.3
}
on  catbert-passive {
remote  tcp4://192.168.10.3
source  tcp4://192.168.10.4
}
}

on catbert-passive:

resource cbert0 {
replication memsync
local   /dev/gpt/catbert-passive-hast-a
on  catbert-active  {
remote  tcp4://192.168.10.4
source  tcp4://192.168.10.3
}
on  catbert-passive {
remote  tcp4://192.168.10.3
source  tcp4://192.168.10.4
}
}

As you can see, its the same config file on both machines, just my gpt 
name is different. If I were using device names then it would be 
identical. I always fix both source and remote addresses as I was using 
a pair of dedicted cards to connect themmachines - they had other Ip 
addresse and could see each eother over a different LAN too.


I always put by 'local' outsid the 'on' definitionse, and had different 
config files on each machine. I havent tried it with 'local' inside, but 
your config does look OK to me, assumng that works. try adjusting it to 
have the soucre addess and local outside of th definition like I do 
though, as I do know that works.


-pete.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

HAST, configuration, this actually looks insane

[Eugene M. Zheganin]

Hi,

I'm trying to configure a HAST on FreeBSD, and suddenly it appears to be 
a mind-breaking procedure. I totally don't get it, thus it doesn't work, 
dumps cores and behaves weirdly. First of all, in an existing 
configuration files paradigm, used widely in the whole IT industry, the 
local view is usually described, and then remote mentioned. Here both 
local and remote views are described and the configuration file (and 
they aren't named explicitely local and remote since they are both 
"remote"), like I understand the handbook article, must be _the_same_ on 
both nodes. So, given that the sections are named arbitrarily, the local 
hostname isn't mentioned or linked anywhere - how do I configure it 
considering that I have _different_ GEOM providers of different machines ?


So, let's consider I have written this configutaion file:


resource hasta {
    on gw0 {
local /dev/ada2p3
remote 192.168.0.247
    }
    on gw1 {
local /dev/ada0p4
remote 192.168.0.248
    }
}

resource hastb {
    on gw0 {
local /dev/ada3p3
remote 192.168.0.247
    }
    on gw1 {
 local /dev/ada1p4
remote 192.168.0.248
    }
}

The main question which IP do I mention where ? As far as I understand I 
should mention "remote" IP in the "local" device block, and vice-versa, 
but first of all - this doesn't work (dumps cores, complains bout FIFOs, 
and so on ) - second of all - how the hastd itself finds who's local and 
who's remote ? Thank god I have a GEOM configuration which cannot be 
applied on both nodes, so only the correct node wouyld have the GEOM 
provider mentions - otherwise I suggest this would corrupt my data and 
make a total mess of it.



With thsi configuration file hastd doesn't work. "create" stage goes 
smoothly, but then on one node (the one with /dev/ada1p4 and 
/dev/ada0p4) hastd just loops crashing:


Mar 18 20:48:47 gw1 hastd[92215]: [hasta] (primary) Descriptor 7 is open 
(pipe or FIFO), but should be closed.
Mar 18 20:48:47 gw1 hastd[92215]: [hasta] (primary) Aborted at function 
descriptors_assert, file /usr/src/sbin/hastd/hastd.c, line 303.
Mar 18 20:48:47 gw1 kernel: pid 92215 (hastd), uid 0: exited on signal 6 
(core dumped)
Mar 18 20:48:52 gw1 hastd[92204]: [hasta] (primary) Worker process 
killed (pid=92215, signal=6).
Mar 18 20:48:53 gw1 hastd[9]: [hasta] (primary) Descriptor 7 is open 
(pipe or FIFO), but should be closed.
Mar 18 20:48:53 gw1 hastd[9]: [hasta] (primary) Aborted at function 
descriptors_assert, file /usr/src/sbin/hastd/hastd.c, line 303.
Mar 18 20:48:53 gw1 kernel: pid 9 (hastd), uid 0: exited on signal 6 
(core dumped)
Mar 18 20:48:58 gw1 hastd[92204]: [hasta] (primary) Worker process 
killed (pid=9, signal=6).
Mar 18 20:48:59 gw1 hastd[92223]: [hasta] (primary) Descriptor 7 is open 
(pipe or FIFO), but should be closed.
Mar 18 20:48:59 gw1 hastd[92223]: [hasta] (primary) Aborted at function 
descriptors_assert, file /usr/src/sbin/hastd/hastd.c, line 303.
Mar 18 20:48:59 gw1 kernel: pid 92223 (hastd), uid 0: exited on signal 6 
(core dumped)
Mar 18 20:49:01 gw1 hastd[92204]: [hasta] (primary) Worker process 
killed (pid=92223, signal=6).
Mar 18 20:49:02 gw1 hastd[92225]: [hasta] (primary) Descriptor 7 is open 
(pipe or FIFO), but should be closed.
Mar 18 20:49:02 gw1 hastd[92225]: [hasta] (primary) Aborted at function 
descriptors_assert, file /usr/src/sbin/hastd/hastd.c, line 303.
Mar 18 20:49:02 gw1 hastd[92204]: Unable to receive control header: 
Socket is not connected.
Mar 18 20:49:02 gw1 kernel: pid 92225 (hastd), uid 0: exited on signal 6 
(core dumped)
Mar 18 20:49:02 gw1 hastd[92204]: Unable to send control response: 
Broken pipe.
Mar 18 20:49:07 gw1 hastd[92204]: [hasta] (primary) Worker process 
killed (pid=92225, signal=6).
Mar 18 20:49:08 gw1 hastd[92230]: [hasta] (primary) Descriptor 7 is open 
(pipe or FIFO), but should be closed.
Mar 18 20:49:08 gw1 hastd[92230]: [hasta] (primary) Aborted at function 
descriptors_assert, file /usr/src/sbin/hastd/hastd.c, line 303.
Mar 18 20:49:08 gw1 kernel: pid 92230 (hastd), uid 0: exited on signal 6 
(core dumped)



Thanks.

Eugene.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"