Date: Fri, 10 Jan 2003 15:18:11 -0800 (PST) From: Thomas McIntyre <temac@yahoo.com> To: car@vitalit.com Cc: freebsd-cluster@FreeBSD.ORG Subject: Re: freebsd cluster target market Message-ID: <20030110231811.98794.qmail@web14207.mail.yahoo.com>
next in thread | raw e-mail | index | archive | help
Rouzer, Charles A (Chuck) said:
> Is it fair to say that FreeBSD Clustering may gain adoption more
quickly if designed for the hosting market as that seems to be its
target market?
<snip>
I'm not in that market, so I can't really say, but my interests
always come back to roughly the same thing. Something like a
cluster of web servers running over a clustered database.
Everything should be minimized, requires minimal servers, zero
specialized hardware, and runs without X windows.
The above specs might supply a general model for the business
motivations behind clustering. For everything to be attractive, it
needs to meet 2 core requirements:
1) Vips w/ load balancing.
2) Robust shared storage.
There's a third requirement that often gets a lot of jawboning:
3) Application state replication, preferably in memory.
But I think the first two are the key here. The third has an
somewhat higher cost/benifit ratio, is insufficiently general, and
often can faked by writing state to shared storage.
---
So, in context, here's requirements 1 and 2:
Two secured RELEASE machines running apache and mysql. The
entry point for both applications are vips. The front end is
active/active. The back end can be active/passive. I want to
later expand vertically (run only a single application per
machine) as well as horizontally (add more load balanced boxes).
I don't want any special Cisco or F5 hardware or detached
switched storage. I don't want to mount anything (particularly
databases) over NFS, and I don't want data living on a single
node.
Of the above, the shared nothing storage is the trickiest.
Something like a synchronous write, with a timeout that blows out
one node if it takes too long. Robust and configurable semantics
like software raid 1 on a single machine.
Otherwise, there's three obvious routes:
A) Buy a hardware load balancer with sticky sessions and a fibre
switch for detached storage. If we really want to waste $$$, we
go for a middleware server that hot replicates its internal
state.
b) On the cheap use something like two active/passive stovepipe
systems with application level replication and scripting to keep
data in two places.
c) Forget the clustering and use tape backups.
Nothing gets the grand prize, but it would be great if this project
could.
---
Apologies in advance if I'm behind the curve, or have only
repackaged prior threads.
Regards,
Tom McIntyre
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-cluster" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030110231811.98794.qmail>