Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 06 Feb 2012 12:43:14 +0100
From:      Damien Fleuriot <ml@my.gd>
To:        freebsd-fs@freebsd.org
Subject:   Re: HAST considarations
Message-ID:  <4F2FBCD2.6000603@my.gd>
In-Reply-To: <FAE6B79D-6791-4B1F-8E0D-79BEB2765B3B@digsys.bg>
References:  <CA%2BdUSypg_3uNYMtU2tnvrvAPFw8MjM596tDZ=R_eqpE=GL1-=A@mail.gmail.com> <FAE6B79D-6791-4B1F-8E0D-79BEB2765B3B@digsys.bg>

next in thread | previous in thread | raw e-mail | index | archive | help
This issue is due to a bug in OpenBSD 3.8's implementation of CARP.

It triggers if you have net.inet.carp.preempt=1 on the node.

If the sysctl is set, the interface assumes MASTERship immediately upon
being brought up, then yields in the presence of a better master.



The patch for this issue was commited by Gleb to 8-STABLE a long while
ago, as well as 9.0-RELEASE and 8.3-RELEASE when it gets out.

In the meantime, if you're not runing 8-STABLE or 9.0-RELEASE, you can
still patch manually.

Details + patch in my original PR here:
	http://www.freebsd.org/cgi/query-pr.cgi?pr=161123
Commit 226367 to HEAD:
	http://freshbsd.org/commit/freebsd/r226367


We've been running with the patched version for over 6 months now and
have yet to encounter any problem.


On 2/6/12 12:37 PM, Daniel Kalchev wrote:
> My only issue with this setup is that on reboot, CARP becomes mater for a moment, then hears the other (real) master and switched to backup mode. This will however trigger the devd scripts. It can be fixed by more checks in the scripts, but really, CARP should not start as master.
> 
> Otherwise, I have beaten it a lot and it seems to work ok.
> 
> Daniel
> 
> On Feb 6, 2012, at 12:54 PM, George Kontostanos wrote:
> 
>> Greetings list,
>>
>> I have been experimenting with HAST on a raidz ZFS pool and I have
>> stumbled upon some issues. So, any suggestions are highly appreciated
>> :)
>>
>> My testing environment is consisted of a Linux KVM machine with an
>> Intel Core2Duo and 4G RAM with 2 SATA drives striped (for performance)
>> since I don't have the metal to experiment.
>>
>> When someone is considering to use a HA solution for storage then I am
>> quite sure that their set up would include redundant switches and
>> NICs. For best performance the HAST synchronization should be
>> independent from the CARP interfaces, possibly consisting with more
>> than 1 NIC with lag. At least that's what I think.
>>
>> The first problem appeared when trying to setup the resources. It
>> seems that the resource name is tight up with the machines hostname.
>> My hast.conf looks like this:
>>
>> resource disk1 {
>>        on hast1 {
>>                local /dev/da0
>>                remote hast2
>>        }
>>        on hast2 {
>>                local /dev/da0
>>                remote hast1
>>        }
>> }
>>
>> resource disk2 {
>>        on hast1 {
>>                local /dev/da1
>>                remote hast2
>>        }
>>        on hast2 {
>>                local /dev/da1
>>                remote hast1
>>        }
>> }
>>
>> However, the hostnames are storage1 and storage2 with storage being
>> the shared CARP IP. Both hast1 & hast2 resolve in /etc/hosts and are
>> connected to a different private vlan but when trying to create the
>> first resource the system complained that only hast1 is an acceptable
>> resource name.
>>
>> After changing both machines hostnames I was able to create the
>> resources and a zpool mirror consisted upon /dev/hast/disk1 &
>> /dev/hast/disk2
>>
>> Manual failover also worked by exporting the pool from the master,
>> switching roles and then importing the pool on the slave. Yet, looking
>> at the example scripts I realized that there is a lot of work to be
>> done since automatic failover is based upon the CARP device and is
>> limited to one resource. I replicated the resources at the script
>> level in order to switch roles for all the devices. Still it looks
>> very basic and crapy.
>> Also, I added the NIC witch is being used for HAST replication to the
>> /etc/devd.conf besides CARP
>>
>> I see this being at an early stage but I was wondering if anyone has
>> to share some success (or not) stories. Also, does anyone else share
>> my point regarding separating CARP and HAST replication? If yes I
>> would be very interesting to know how this was done.
>>
>> Regards
>>
>> -- 
>> George Kontostanos
>> Aicom telecoms ltd
>> http://www.aisecure.net
>> _______________________________________________
>> freebsd-fs@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
> 
> _______________________________________________
> freebsd-fs@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F2FBCD2.6000603>