Newsgroups: comp.os.vms Distribution: world Followup-To: From: everhart@gce.com.gov (Glenn C. Everhart) Organization: Speaking for me...remove .gov to use address Subject: Re: Volume shadowing over long distance netw Keywords: Reply-To: Everhart@gce.com.gov References: <34d0f47b706a002@laurel.kp.org> Larry Robertson of Bear Computing (bearcomp.com) thought of a halfway sensible way to do this some time back. He has (& sells) a virtual disk driver that will write to a local and a remote member, but which will buffer the shadow traffic to a local file, so writes don't have to wait for the network as long as it can on average keep up. Recovery can mean getting this circular buffer file to finish remote update, depending on pattern, but on average the remote shadow volume is kept up to date. I have heard this works well, and have NEVER heard of any bugs or corruption due to his product. I HAVE heard of corruption due to his competition, and further that it was not all due to the VMS 6.2 dkdriver mods but due to other bugs. So I'd trust the Bear product if that is what you need. If you want to go for free, my free shadowing disk could be used to write to a journalling fddriver based volume and that used for remote-ing the whole thing. I did a variant of a remote virtual disk once that wrote to a local file first but periodically flushed written-to blocks across the net to a remote site, writing a local journal file, then flushing, then deleting the local journal. The idea was that if the system failed, either the remote disk would be a faithful copy of the local one (from at most 15 minutes ago) or the remote disk could be made so by playing back the journal to update the remote copy. (The logic could easily be changed to write the journal over net if you really wanted to.) The idea was also partly that if a disk block was written many times over that 15 minute period, it'd be necessary to copy only the last version across net. While you can intercept drivers, that logic in VMS is subject to change in the next version and has never been guaranteed to work in all cases. Using a separate driver on top is far safer, has worked for decades now... The Bear products do it the safe way, are pretty efficient from my experience with them, and well worth checking into if you want a commercial supplier. They're located in s. california... In article <34d0f47b706a002@laurel.kp.org> "Abernethy,Joe" wrote: > > Greetings, > > I'm looking for information on doing disk volume shadowing over a > network. I'm not sure of the what the "technical" terminalogy is, > however, I think I can describe what I'm trying to get at. Here it goes. > > Currently, we have 50 disks that are all 2 disk shadow sets. We are in a > process of moving our data center out of state (we are in Albany, NY and > are moving to Silver Spring, Maryland) and are trying to find a way to > rebuild our cluster down in maryland and get all the data down there > without having to shutdown all of our health centers. > It was mentioned that we could do volume shadowing across the network > that will be built between Albany and Silver Spring. Originally this > sounded like one of the best ideas. Sure, we might take a bit of a > performance hit while the disks shadow copied, but at the expense of > having to be shutdown we could endure. Now we have heard from other data > centers in the organization that have done similar moves and are saying > that the across network volume shadowing caused serious performance > degradation. We would only be doing this for (probably) a couple of > months at most while everything was tested out and the health centers > were phased into connecting to the Silver Spring systems instead of the > Albany systems. > > My question then is, does anyone done or do anything similar to this? If > so, how is the response time/performance? > > Also, for additional information, we are running OpenVMS 6.2-1h3 and have > a huge (150gig) DSM (version 6.6a) database running on our 3 node Alpha > cluster. > > Any information or suggestion on what we might want to do would be > greatly appreciated. > > Joseph Abernethy > REPLY TO: joe.abernethy@kp.org