From: Tim <tim@connectlive.com>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] has anyone used LVM in a HA cluster?
Date: Mon May 13 11:28:01 2002 [thread overview]
Message-ID: <20020513112912.G31182@connectlive.com> (raw)
In-Reply-To: <3CDFE39B.1080903@lausch.at>; from mla@lausch.at on Mon, May 13, 2002 at 06:02:35PM +0200
> > We're going that route.
> >
>
> which may backfire, if both nodes think the other one is down (split
> brain again) and start the shutdown procedure. okay, this is a very rare
> situation, and may happen only under strange load and scheduling
> parameters, but it will happen as any other "very rare situation"
> happens ;-). especially in HA environments they seem to happen much more
> often then in simple single point of failure environments ;-) you won'�t
> loosew your filesystem, but the service is unavailable.
Probably possible, unlikely in practice, however. In any event, we have
constructed a load-sharing off-site node that recieves redirected
traffic via GSLB if the main node dies, so we have some time to wander
over to the datacenter and kick one of the HA nodes. Writes can't
happen for a few minutes, but we're not recording financial transactions
directly, and email notices of any pending purchases just queue up in
the meantime. This solution was not really what I had initially
planned, but it was a stipulation of a large contract we bid on (and
won), so we just went ahead and built it. Better to hobble along for a
while during a problem, than to just fall over dead. Meanwhile, the
issue of incremental backups (eg. to recover from user errors) is, at
least in my environment, fairly well handled by using CVS for code and
nightly rsync's for so-called 'static' files (a misnomer, but 'static'
in the sense that we only keep one revision kicking around :-)).
I've seen an awful lot of high-availability systems in production, and
the one I liked most (because it never seemed to cause problems) was the
IBM HACMP cluster(s) at IBM Microelectronics. Until that becomes a
reasonable possibility for Linux, I guess we'll just stick to multiple
levels of redundancy and failover, the good old 'two safety nets are
better than one' theory...
The HACMP guys were the ones who suggested STONITH for Linux; while your
split-brain scenario could lead to both nodes losing power, this is not
as big of an issue (with journaled filesystems) as would be corruption.
--
"The most valuable piece of equipment in the darkroom
is the trash can."
--Ansel Adams
prev parent reply other threads:[~2002-05-13 11:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-09 11:53 [linux-lvm] has anyone used LVM in a HA cluster? Au, Richard
2002-05-09 12:14 ` Tim
2002-05-09 14:38 ` Chad Walstrom
2002-05-09 14:46 ` Goetz Bock
2002-07-13 7:12 ` Wichert Akkerman
2002-05-10 2:24 ` Patrick Caulfield
2002-05-10 17:51 ` Austin Gonyou
2002-05-10 19:45 ` Steven Lembark
2002-05-11 14:26 ` Luca Berra
2002-05-13 4:15 ` Michael Lausch
2002-05-13 6:54 ` Luca Berra
2002-05-13 7:33 ` Tim
2002-05-13 10:59 ` Michael Lausch
2002-05-13 11:23 ` Steven Lembark
2002-05-13 11:28 ` Tim [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020513112912.G31182@connectlive.com \
--to=tim@connectlive.com \
--cc=linux-lvm@sistina.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.