Date: Tue, 21 Feb 2017 15:16:17 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= <Trond.Endrestol@fagskolen.gjovik.no> To: Tomoya Tabuchi <t@tomoyat1.com> Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC Project Involving the reimplementation of beadm(1) Message-ID: <alpine.BSF.2.20.1702211515060.97144@mail.fig.ol.no> In-Reply-To: <20170221141147.GB11545@tomoyat1.com> References: <20170220131509.GA31623@tomoyat1.com> <485A34F5-C747-498A-A0D1-04533603A54D@icloud.com> <20170221141147.GB11545@tomoyat1.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 21 Feb 2017 23:11+0900, Tomoya Tabuchi wrote: > On Mon, Feb 20, 2017 at 12:52:03PM -0800, Jordan Hubbard wrote: > > > > > On Feb 20, 2017, at 5:15 AM, Tomoya Tabuchi <t@tomoyat1.com <mailto:t@tomoyat1.com>> wrote: > > > > > > I would like to ask a few questions involving this. > > > First, is there a particular reason why this project is listed in the > > > ideas list? Aside the fact the current implementation in sh is rather > > > complicated, I was unable to come up with a reason to justify the > > > reimplementation. > > > > The current implementation of beadm is very slow and fragile - it writes to all previous boot environments when configuration changes are made which require the regeneration of config data, something which becomes slower as an O(n) property of the number of boot environments, and it does a poor job of handling any number of failure cases which can occur during this process. It provides also no “seat belts” for the pathological cases where the ZFS boot pool fills up or even approaches the 90% “storage cliff” where ZFS begins to exhibit pathological performance characteristics. > I did not know about such problems. As for the part regarding the > regeneration of config data. I'll look into the current > implementation and see if I could come up with a better way to do > things. Could beadm use ZFS user properties to distinguish between BE created by beadm, and those created manually or by other tools? > As for the zpool approaching the "storage cliff", or filling up, it seems straightforward that a doing a usage check before each BE creation, and aborting if limits are exceeded, should suffice. I figure it will be worth searching the existing implementation for any other edge cases in need of "seat belts". > > > > It also provides no API other than the beadm(1) command itself, which makes it harder to control from 3rd party tools like FreeNAS (which uses beadm extensively). > In order to provide an API to beadm, splitting the final product into > 1. an underlying library that does the heavy lifting > 2. an user-facing beadm(1) command that will make use of the library > could be a solution. IIRC this is sort of like what is done in libzfs and the > zfs commands. > > > > > It’s on our (iXsystems) own long-term list of things to rewrite from scratch, but we haven’t managed to find the time or resources. If someone else wanted to do so, we’d be enthusiastic co-conspirators! > Thank you! I'll do some more research, write a project proposal, and post it on this list when the time comes. I would appreciate it very much if I could then have feedback from you. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-hackers@freebsd.org Tue Feb 21 15:46:41 2017 Return-Path: <owner-freebsd-hackers@freebsd.org> Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3193FCE8B4E for <freebsd-hackers@mailman.ysv.freebsd.org>; Tue, 21 Feb 2017 15:46:41 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D533EFD0; Tue, 21 Feb 2017 15:46:40 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v1LFkdmi008296; Tue, 21 Feb 2017 07:46:39 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v1LFkdxA008295; Tue, 21 Feb 2017 07:46:39 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> Message-Id: <201702211546.v1LFkdxA008295@pdx.rh.CN85.dnsmgr.net> Subject: Re: FreeBSD CARP load balancing. In-Reply-To: <5b9f3663-c244-29c1-1771-d745fd0b0a98@freebsd.org> To: Allan Jude <allanjude@freebsd.org> Date: Tue, 21 Feb 2017 07:46:39 -0800 (PST) CC: freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Tue, 21 Feb 2017 16:59:40 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD <freebsd-hackers.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>; List-Post: <mailto:freebsd-hackers@freebsd.org> List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe> X-List-Received-Date: Tue, 21 Feb 2017 15:46:41 -0000 > On 2017-02-21 00:55, Gleb Popov wrote: > > On Mon, Feb 20, 2017 at 10:16 PM, Steven Hartland <killing@multiplay.co.uk> > > wrote: > > > >> On 20/02/2017 19:07, Gleb Popov wrote: > >> > >> > >> On Mon, Feb 20, 2017 at 12:01 PM, Steven Hartland <killing@multiplay.co.uk > >>> wrote: > >> > >>> Does LAGG do what you need? > >> > >> > >> Doesn't seem so. I need to balance incoming traffic between several hosts. > >> If I understood it correctly, lagg can be used to load-balance outgoing > >> traffic only. > >> > >> > >> LAGG does incoming and outgoing but only on a single host, so it does > >> sound like it won't help you. > >> > >> That said what your doing does sound quite out of the ordinary, > >> > > > > So, that *net.inet.carp.arpbalance *sysctl was out of ordinary feature? > > That probably explains it. > > > > is there a reason you're trying to copy the traffic to multiple hosts? > >> > > > > Not copy, but distribute. I just don't want to wait current CARP master die > > to make another computer become active, but to switch between them in some > > fashion (round-robin or whatever). > > > > > >> > >> Might be a good idea to explain exactly what your trying to achieve. > >> > >> Regards > >> Steve > >> > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > > I am not sure arpbalancing every worked very well. Without a hashing > algorithm or something, how would you actually make a TCP session work? 8.xish man page: ARP level load balancing The carp has limited abilities for load balancing the incoming connec- tions between hosts in Ethernet network. For load balancing operation, one needs several CARP interfaces that are configured to the same IP address, but to a different VHIDs. Once an ARP request is received, the CARP protocol will use a hashing function against the source IP address ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ in the ARP request to determine which VHID should this request belong to. If the corresponding CARP interface is in master state, the ARP request will be replied, otherwise it will be ignored. See the EXAMPLES section for a practical example of load balancing. There is your hash. -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1702211515060.97144>