Re: 306GB drives!
From: Keith Parris (keithparris_NOSPAM_at_yahoo.com)
Date: 08/22/03
- Next message: Larry Kilgallen: "Re: DCL Raise error"
- Previous message: Paul Sture: "Re: Unicode client as Open VMS terminal."
- In reply to: Michael Austin: "Re: 306GB drives!"
- Next in thread: Larry Kilgallen: "Re: 306GB drives!"
- Reply: Larry Kilgallen: "Re: 306GB drives!"
- Reply: David McKenzie: "Re: 306GB drives!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 22 Aug 2003 11:32:30 -0700
Michael Austin <maustin@no-more-spam.firstdbasource.com> wrote in message news:<Gxc1b.1132$Ct.799318088@newssvr30.news.prodigy.com>...
> Keith Parris wrote:
> > This strategy works fine until the controller [pair] fails, or the
> > datacenter in which the EVA is located is destroyed by a disaster.
>
> unless your redundant controller is in another building up to
> 30-50Kilometers away in another city along with an entirely redundant
> cluster.. So in essence, you have 4 controllers (2 controller pairs).
> The question is really "how much $$$ is your data worth?".
>
> EVA's have the ability to replicate itself to an entirely different
> controller over a Wide-area SAN using dark-fibre.
As do HSG, XP, etc. controllers.
Controller-based data replication is certainly an appropriate solution
for disaster tolerance in many cases. Often it's the ONLY option for
any sort of disaster-tolerance for platforms with poor cluster
support. And it's very popular for disaster recovery, where Recovery
Time Objectives are less-stringent.
But more commonly in the OpenVMS Cluster world, HBVS tends to be
preferred in disaster-tolerant clusters, for the following reasons:
1) With controller-based replication, failover between sites is not
automatic, and is difficult to automate (at best, one typically sees
pre-written scripts for failover that get initiated manually), so it's
only appropriate if your Recovery Time Objective is loose enough to
allow the time for this failover to take place. HBVS allows faster,
and fully-automated, failover, without requiring application downtime.
2) With controller-based replication, data is typically accessible
from only one site at a time (at best, read-only access is available
at the remote site). All I/Os (both reads and writes) to the
mirrorset from systems at the remote site must be done remotely, and
suffer the inter-site latency. With HBVS, reads can be directed to
the shadowset member disks at the same site; only writes to the remote
shadowset members must go remotely.
3) Inter-site links are expensive, particularly at 30-50 km distances.
With a VMS cluster, you need an SCS interconnet between sites. To use
controller-based replication, you need an additional interconnect that
can carry Fibre Channel traffic (or conversion boxes to allow FC
traffic to share the bridged interconnect used for SCS). Using HBVS,
you have the choice of MSCP-serving remote I/Os over the same SCS
interconnect, and/or using access to disks through a FC-capable
interconnect.
4) VMS Clusters have a Quorum scheme to prevent uncoordinated access
to the multiple copies of the data that mirrorset members at different
sites represents. With controller-based data replication, you must
basically use humans to replace the Quorum Scheme and the HBVS
Generation Number algorithms, keeping track of (through failure
events) which copy of the data is the most up-to-date and only
allowing user access and updates to that copy at any given point in
time.
There are disaster-tolerant VMS clusters in place which actually have
3 datacenters (plus a quorum node in a 4th site), where each of the 3
sites has a valid copy of the data, and the cluster can continue
operating despite loss of any 2 of those 3 datacenters without data
loss or downtime, thanks to HBVS.
- Next message: Larry Kilgallen: "Re: DCL Raise error"
- Previous message: Paul Sture: "Re: Unicode client as Open VMS terminal."
- In reply to: Michael Austin: "Re: 306GB drives!"
- Next in thread: Larry Kilgallen: "Re: 306GB drives!"
- Reply: Larry Kilgallen: "Re: 306GB drives!"
- Reply: David McKenzie: "Re: 306GB drives!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|