From owner-freebsd-fs@FreeBSD.ORG Mon Feb 6 11:38:08 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 633B41065670 for ; Mon, 6 Feb 2012 11:38:08 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 0189E8FC08 for ; Mon, 6 Feb 2012 11:38:07 +0000 (UTC) Received: from [192.92.129.180] ([192.92.129.180]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.5/8.14.5) with ESMTP id q16Bbd0a034756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Feb 2012 13:37:45 +0200 (EET) (envelope-from daniel@digsys.bg) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Daniel Kalchev In-Reply-To: Date: Mon, 6 Feb 2012 13:37:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: George Kontostanos X-Mailer: Apple Mail (2.1257) Cc: freebsd-fs@freebsd.org Subject: Re: HAST considarations X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 11:38:08 -0000 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, >=20 > I have been experimenting with HAST on a raidz ZFS pool and I have > stumbled upon some issues. So, any suggestions are highly appreciated > :) >=20 > 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. >=20 > 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. >=20 > 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: >=20 > resource disk1 { > on hast1 { > local /dev/da0 > remote hast2 > } > on hast2 { > local /dev/da0 > remote hast1 > } > } >=20 > resource disk2 { > on hast1 { > local /dev/da1 > remote hast2 > } > on hast2 { > local /dev/da1 > remote hast1 > } > } >=20 > 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. >=20 > After changing both machines hostnames I was able to create the > resources and a zpool mirror consisted upon /dev/hast/disk1 & > /dev/hast/disk2 >=20 > 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 >=20 > 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. >=20 > Regards >=20 > --=20 > 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"