VMSclusters and data replication
mb...@hotmail.com
Looking for ways to replicate lots of data across from London To New
York
Would any sort of SAN software do the job?
I guess having nodeA in NY and nodeB in London In a cluster just isn't
going to work?
What about host based raid or volume shadoing?
Any ideas about the network pipe you can get?
Richard B. Gilbert
Put it on an airplane and fly it across!
Seriously, you are talking about a minimum 3000 mile path and bandwidth
that would cost you a fortune if it were available which it probably is
not! The latency will almost certainly preclude volume shadowing even
if you could afford the bandwidth. And I hate to think about how a
cluster might perform with nodes 3000 miles apart.
OTOH, you can put a 300 GB disk in a FedEx (or equivalent) box and get
it across the pond for a fairly reasonable price and at a fairly
reasonable speed.
Colin Butcher
low-latency high-bandwidth networks are not cheap.
At those distances the latency will kill a cluster / and host-based volume
shadowing. The latency will kill array based synchronous data replication.
It's not just latency per se - it's also the variation of latency with
respect to time. Wildly varying latency is a very bad problem to deal with.
You're probably stuck with asynchronous data replication at array controller
level (if it's only a small amount of data that changes) or else you're
going to be intermittently copying files, or flying them across.
Just how much data do you need to shift and what kind of time lag can your
applications tolerate between sites?
In general it's best to minimise what you have to shift and devise some
cunning mechanism within the applications at each end that shifts the
absolute minimum you can get away with as quickly as you can afford.
Expecting to do it at system platform level with a load of COTS software
over the top isn't going to hack it.
If you need design help then I'm sure that several people here (including
me) would be prepared to assist.
--
Cheers, Colin.
Legacy = Stuff that works properly!
Michael Moroney
>Using OpenVMS 7.3-2
>Looking for ways to replicate lots of data across from London To New
>York
>Would any sort of SAN software do the job?
>I guess having nodeA in NY and nodeB in London In a cluster just isn't
>going to work?
>What about host based raid or volume shadoing?
Shadowing would work, but I suspect the data latency over such a distance
would be intolerable.
>Any ideas about the network pipe you can get?
I'm sure it's going to be expen$ive...
Does the data really need to be updated in realtime?
Bob Gezelter
I would in general agree with Colin, albeit with one qualification.
A cluster spread across the pond is probably not feasible, or for that
matter desirable. The latency for routine traffic would be prohibitive
in terms of performance. Additionally, the vulnerability of the
cluster to a loss of data path or bandwidth would most liklely be
unacceptable.
Remote shadowing on a significant scale is also an issue for the same
reasons.
However, long distance replication of a limited volume of data is a
far different story. A detailed review of what must actually be
synchronized (vs recovered in the event of a problem) must be done,
with a full inventory.
While I am a strong advocate of clustering, there are situations where
it may be more appropriate to have two clusters, one on each side of
the pond, with remote archiving of log data, rather than a single,
transoceanic cluster.
As always, the devil is in the details. This is a topic for a detailed
review, it is far too nuanced to generate a definitive answer in this
forum. (Disclosure: My firm, and Colin's consult in this area.)
- Bob Gezelter, http://www.rlgsc.com
David J Dachtera
Not enough info here to provide an intelligent response.
However, let me say this: for database applications, copying transaction logs
across by FTP, SCP, etc. may be an option worth looking into. If encyption can
be included in the process a dedicated link may not be necessary, just Internet
access over secure links.
As has been mentioned, a formal consultation would likely be a more productive
means of pursuing this question.
--
David J Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial OpenVMS Marketing Home Page
http://www.djesys.com/vms/market/
Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/
Unofficial OpenVMS-IA32 Home Page:
http://www.djesys.com/vms/ia32/
Unofficial OpenVMS Hobbyist Support Page:
http://www.djesys.com/vms/support/
Paul Raulerson
and a lot of times, that can be enough. It isn't that much more expensive
London to New York than New York to Austin.
The SAN systems can do this without the knowledge or assistance of the host
systems, which never even know it is going on.
-Paul
> -----Original Message-----
> From: Michael Moroney [mailto:mor...@world.std.spaamtrap.com]
> Sent: Monday, July 02, 2007 1:02 PM
> To: Info...@Mvb.Saic.Com
> Subject: Re: VMSclusters and data replication
>
> "mb...@hotmail.com" <mb...@hotmail.com> writes:
>
> >Using OpenVMS 7.3-2
>
> >Looking for ways to replicate lots of data across from London To New
> >York
> >Would any sort of SAN software do the job?
> >I guess having nodeA in NY and nodeB in London In a cluster just isn't
> >going to work?
> >What about host based raid or volume shadoing?
>
> Shadowing would work, but I suspect the data latency over such a
> distance
> would be intolerable.
>
> >Any ideas about the network pipe you can get?
>
bri...@encompasserve.org
A bit of Googling shows that you're looking at best case latencies in
the 70-80 ms neighborhood for New York to London.
Two transatlantic T1's that I have immediate access to are running
with uncongested ping times in the 80 ms range on the one and the
100 ms range on the other. Both of those circuits are between the
U.S. east coast (Newark, DE) and the London area (Maidstone).
By comparison, I get about 65 ms going from the U.S. east coast to
the U.S. west coast (Newark, DE to San Diego, CA).
Speed of light delays alone account for the bulk of those delays.
Nothing you can do about that, of course.
Bandwidth -- you can get as much bandwidth as you're willing to
pay for.
At a guess, I'd think that you're probably looking for a handoff that
is a fractional DS3 at each end. Maybe you could get by with NxT1
service using multilink PPP. Or maybe you can afford a full
45 Mbps DS3.
Your provider may be able to give you a dedicated virtual circuit. Or they
may be able to give you a better deal on a shared circuit. For instance,
my company currently has two dedicated transatlantic T1's. And we're
looking at changing to a carrier that provides a shared gateway
between its U.K. MPLS cloud and its U.S. MPLS cloud. We pump IP
traffic in on the one end and out it comes on the other.
JF Mezei
OUt of curiosity, how is/was teh Cantor Fitzgerald system setup on 9-11
? They had dana centres in WTC, in New jersey and in London.
Would reliable transaction router be able to send transactions to 2 far
away servers and await confirmation from both ?
Bob Koehler
>
> However, long distance replication of a limited volume of data is a
> far different story. A detailed review of what must actually be
> synchronized (vs recovered in the event of a problem) must be done,
> with a full inventory.
Yes, I've done enough data transfers across the pond to agree with
this approach. I've used DECnet Phase IV for this with no problem
and I suggest DECnet over IP as the most promising solution.
Other possibilities include naked IP (if you don't mind fixing up
file attributes); or DFS (DECnet File System?), a sort of NFS
analog for DECnet.
Bob Gezelter
Koehler) wrote:
> In article <1183399772.237201.114...@k29g2000hsd.googlegroups.com>, Bob Gezelter <gezel...@rlgsc.com> writes:
>
>
>
> > However, long distance replication of a limited volume of data is a
> > far different story. A detailed review of what must actually be
> > synchronized (vs recovered in the event of a problem) must be done,
> > with a full inventory.
>
> Yes, I've done enough data transfers across the pond to agree with
> this approach. I've used DECnet Phase IV for this with no problem
> and I suggest DECnet over IP as the most promising solution.
>
> Other possibilities include naked IP (if you don't mind fixing up
> file attributes); or DFS (DECnet File System?), a sort of NFS
> analog for DECnet.
Bob,
Yes. I should re-emphasize that while 9/11 is often cited as the
reason for concern, many do not realize the extent of the lessons
learned in the aftermath of the event.
While OpenVMS clusters is an extremely useful technology, it is not
magic nor is it the cure-all for all reasons. Speaking as an IT
professional, and not minimizing the loss of life in the Trade Center
attack, the far more disruptive event was the destruction of the AT&T
(if I recall correctly) switching center adjacent to the Trade Center,
which was a junction point for many data connections to/from
Manhattan. Many companies very far from Ground Zero was disrupted by
this event for a very extended period of time.
My concern is that trans-oceanic clusters make use of a limited set of
high speed circuits. In the event of a problem, bandwidth may be
reduced on these circuits with little warning. If these are mission
critical, then severe problems can result.
Thus my suggestion to carefully evaluate (and possibly retain a
consultant) the issues before going down this route. Archiving logs
remotely can survive with far less bandwidth than a cluster. If that
accomplishes the need, it is a better choice.
Note that transcontinental clusters do not necessarily suffer the same
problem, although verifying alternate communications paths is
important.
Main, Kerry
> From: mb...@hotmail.com [mailto:mb...@hotmail.com]
> Sent: July 2, 2007 12:56 PM
> To: Info...@Mvb.Saic.Com
> Subject: VMSclusters and data replication
>
> Using OpenVMS 7.3-2
>
> Looking for ways to replicate lots of data across from London To New
> York
> Would any sort of SAN software do the job?
> I guess having nodeA in NY and nodeB in London In a cluster just isn't
> going to work?
> What about host based raid or volume shadoing?
> Any ideas about the network pipe you can get?
Well, one option might be an active-active-passive (sync-sync-asynch)
multiple site solution. This is emerging as a good solution for large
enterprises which offers the benefits of local synch access between two
sites 25-50 miles apart while at the same time providing the ability to
go to a third site for critical business functions should some
catastrophic event take out the two local sites.
For anyone looking at cross Atlantic data replication, I suspect the HW
costs will not be the major concern as an hour or two of application
unavailability in prime time would likely pay for it all.
In view of recent events, I suspect more and more companies will be
looking at solutions like this. It certainly does come up a lot during
the discussions I have around DC consolidation.
And as someone else mentioned, the bandwidth costs have dropped
significantly across the pond. A number of providers beefed up cross
ocean delivery capabilities significantly during the Internet dot com
days - only to have the bottom drop out of that market. Get a number of
quotes, but also take into consideration the providers long term
stability as well.
Challenges in this area are that you typically have to get a long term
contract (2-3 years), so you need to do some sizing work before
contracting anything.
In some of the DC consolidation engagements like this, I would typically
recommend a local network simulator pilot project be implemented to test
all of the various bandwidth, latency, error rates, fail over scenarios.
Network simulators range from freeware to $30k+ appliances, so YMMV -
likely something in between is what you would need.
Regards
Kerry Main
Senior Consultant
HP Services Canada
Voice: 613-592-4660
Fax: 613-591-4477
kerryDOTmainAThpDOTcom
(remove the DOT's and AT)
OpenVMS - the secure, multi-site OS that just works.
Bob Koehler
>
> My concern is that trans-oceanic clusters make use of a limited set of
> high speed circuits. In the event of a problem, bandwidth may be
> reduced on these circuits with little warning. If these are mission
> critical, then severe problems can result.
I didn't say anything about clusters and I would not use VMScluster
in across-the-pond configurations.
Keith Parris
> Looking for ways to replicate lots of data across from London To New
> York
Looks like you've gotten a lot of good answers. I concur with Kerry that
the best way forward is to get a network emulator box like a Shunra
STORM or an Adtech Spirent box and test with that before procuring a
costly transatlantic circuit. You can rent one, buy one, or arrange to
use one in HP's labs.
Check the presentations with "Long Distance" in their title at
http://www2.openvms.org/kparris/ . You will also probably find helpful
the one comparing Continuous Access with Host-Based Volume Shadowing.
> Would any sort of SAN software do the job?
Take a look at Continuous Access asynchronous replication.
I know of a customer who was doing transatlantic replication with the
older Data Replication Manager (DRM) on HSG80s for a number of years, so
you certainly wouldn't be the first to try it.
> I guess having nodeA in NY and nodeB in London In a cluster just isn't
> going to work?
We know of one customer with a 3,000 mile site separation distance who
has had it since the VAX days and is presumably getting acceptable
performance for their particular needs. New York to London is a bit more
distance than that.
> What about host based raid or volume shadowing?
Host-Based RAID Software is used to form stripesets (RAID-0 arrays),
RAID-5 arrays, or RAID 0+1 arrays if used in conjunction with the RAID-1
of Volume Shadowing.
Volume Shadowing has been tested out to simulated distances of just over
60,000 miles and nothing breaks, it just slows down in linear proportion
to the distance, as one might expect.
> Any ideas about the network pipe you can get?
You've already gotten good answers on this.