[Sunhelp] mirroring/clustering/failover

James Lockwood james at foonly.com
Fri May 12 19:39:44 CDT 2000


On Fri, 12 May 2000 beemern at telecom.ksu.edu wrote:

> the servlet engine runs some stuff that talks to our Oracle, which is on
> ANOTHER system.

So you do have dynamic content coming through the servlets.

> basically, we are wanting to have two machines that are "mirrored",
> and we could simply do a DNS round robin so that one client request for
> www.foo.bar
> will goto server1, the next to server2, the next to server1, etc etc.
> 
> so.. basically the machine "mirroring" is the only real task at hand.

Generally speaking, you do not want to "mirror" entire systems across a
network in real time if you can avoid it.  You didn't mention whether or
not your updates are pushed out from a test/beta environment to
production, but if so then the recommendation I can make is to simply
change your push procedures/scripts to sync both production servers to
beta.

In order to make updates largely transparent, you probably want to have a
synchronization script that looks something like:

down server A
push out beta => A
bring up server A
down server B
push out beta => B
bring up server B

This fits nicely into environments that believe in change control and
tracking.

If you must mirror, you can either try synchronous mirroring or periodic
mirroring.  Periodic mirroring is simply done with something like rsync
and has its own share of weaknesses, varying with how frequently you
synchronize.  Synchronous mirroring is frequently done with a shared disk
array and NFS, failing the disk array over when a heartbeat signal between
the two systems is lost.  This doubles your chances of system failure
(only one disk array to die instead of two) and can slow access down
considerably.

Making all static data read-only on your frontline machines (which sounds
feasable for your environment) and pushing updates out from another system
is the best of all possible worlds if you can swing it.  This requires no
software changes except in your update procedure.  It's also by far the
most scalable solution.

-James






More information about the SunHELP mailing list