Thanks to:
Venkata, Raviprasad [ RVenkata_at_caiso.com]
Russ_Fish_at_idx.com
Jim Fitzmaurice [ jpfitz_at_fnal.gov]
Mullin, Stephen (CAP, ITS, US) [ Stephen.Mullin_at_gecits.ge.com]
North, Walter [ Wnorth_at_state.mt.us]
The best (for us) answers came from Jim and Russ and these are both things
we're looking into
(we had a pitch by Quest yesterday). Jim's solution certainly seems
implementable. My boss
liked that approach so much that now he's asking :"Why don't we just split
the existing cluster?".
I shudder at the thought of this, but will have to do further homework, I'll
summarize again if
I learn anything else pertinent (my preference would be to leave the cluster
intact and add a
single system at a remote site). Since there were so few responses to my
original query (at
the bottom of this note), they are all included here, except for Stephen's
"me too".
Jim wrote:
A T1 line is better security than a dial up connection. Instead of
trying to do load balancing on the remote DRP Site you might want to try
continuously replicating your database with the production server. Set your
replication to run on the DRP machine so that the primary load lies on that
machine and not your production box. Sync them on a slow weekend and if your
production machine ever goes down, just change the IP in your DNS and
quicker than a reboot, everyone is back up and running, and the won't even
know what happened. Of course this is overly simplified, but the basic idea
works. I have had the exact same scenario with Sybase. It makes Disaster
Recovery Testing a breeze, you halt replication, put a host file on a couple
of PC's, put a couple of users on them and test for functionality. Sure
beats lengthy restoring of backups and in the event of an actual Disaster,
losing the data since the last backup. Make something like this work and
you'll sleep a lot better at night.
Russ wrote:
We are looking at Quest's SharePlex product to produce the hot backup
instances, currently at the same site but hopefully remotely at some point.
I don't know how you're replicating data now, but Quest claims that for a
remote application, you may run into problems using Oracle's replication
products (at least on v7.3) even with a big network pipe. I will be
bringing a test copy of SharePlex online next week, so I can forward the
results if you're interested. BTW, my servers are in Boston, but I'm right
down the street from you in Seattle. Amazon is using Shareplex
to do all sorts of interesting things, so I think it will work in a
high-volume production environment.
Walter wrote:
We have been looking into a network disk system serving many boxes and we
found out things like this:Buy a couple right size EMC disk systems. These
will sync each other up between sites, by transferring only the changed data
thus keeping a mirror in the remote site. A benefit could be that you will
then be able to drop a mirror at the remote site and use it for testing.
That is the rolls royce solution, probably a couple million bucks.I think
Hitachi can do a similar thing for less. But if want no production down time
then the emc type solution is the best way to go, you can apparently put
your disaster recovery site halfway around the world. As I see it you can
probably do something similar using digatal equipment and periodically dump
data to the disaster site.Of course as you say, that would bring security
into play whereas emc and hitachi(i think) have some encryption capability.
have fun! Disaster Recovery planning is a real can of worms. Like, ok, you
are up; but can your users access the systems? Will they be getting new
pc's/whatever anytime soon? How about the network?
Raviprasad wrote:
You could do load balancing with a remote site, if all your users come
through the web by the use of Cisco's local director box, which does load
balancing by forwarding requests to systems based on their current load.
However, you would have to duplicate the entire configuration of systems to
work similarly. This option is more suited to a 3 tier c/s architecture.
If this is what you are likely to be looking for, I may be able to provide
you with a little more detail.
I originally wrote:
We're a 24X7 call center currently running Oracle on clustered 8200s.
I've been asked to investigate options for a remote site for disaster
recovery. Of our 2 current 8200s, one runs the production databases
and the other is essentially a hot spare, though it gets used for
development and some other tasks. There appear to be many options
and I'm looking for comments/suggestions/trade-offs from anyone
that has implemented or investigated this already. My preference
would be to do some sort of load-balancing with the remote site,
though this might not be the 'best thing' as far as coordinating oracle
databases. I searched the archives and saw a similar question
(
http://www.ornl.gov/its/archives/mailing-lists/alpha-osf-managers/1997/09/m
sg00012.html)
but didn't see a corresponding summary. We're thinking of linking
the 2 sites with a T1, which might introduce more security concerns.
Any comments/suggestions/concerns from someone that's already looked
into this? Thanks.
Jeff Beck
jbeck_at_carewiseinc.com
206.749.1878
CareWise Inc.
701 5th Ave.
Suite 2600
Seattle, WA 98104-7015
Received on Fri Apr 30 1999 - 16:29:50 NZST