ovms 8.4 3Par remote copy between storages

[Edgar Ulloa]

Hi Guys

mi question is

If someone tried to make a 3PAR Remote Copy (licence used) for replay with other 3par

acl´s not lost? or the file structure is not necessary to rebuild?

$set file  */attr= xxxxxxxxx

[Hoff]

ACLs are stored in the file header, as well as other tools.  If the tool you are using propagates all of the OpenVMS RMS and XQP-level file metadata, you'll be fine.  

Preserving metadata and a consistent copy of the file data usually requires a quiescent source of disk data, and typically then involves raw copy, zip "-V" or BACKUP to get the copy.

It's also likely that at least some online snapshot backup operations — controller-level level backups — can potentially be questionable, and can potentially leave you with inconsistent data — each generation of storage engineer has seemingly been re-learning that block copies are easy to implement and can be easy to sell to folks with the ability to quiesce their source disk data and flush any write caches from the host and the controller out to disk, but can be very hard to make work with not-quiescent environments short of detailed insight into and coordination with what the host operating system and host application is doing.  This because the file access is asychronous to what the storage is doing, I/O operations tend to be interleaved across multiple processes and the operating system, because application and system and controller caching is asynchronous.  This is not an easy problem, particularly without application and operaring system assistance.

In short, the particular snapshot copy of the storage may or may not get a complete and consistent copy when the disk data is consistent.   If not, then you get part of the last operation(s) that were performed (zero or more parallel writes, often with multiple block I/O operations involved with a single application transaction, and quite possibly with multiple parallel transactions outstanding.   That usually means you get a consistent copy sometimes, and one or more partial copies — too little or too much data — for other cases.

Even in the worst case, that's certainly better than nothing, but if you can't deal with one or more incomplete or otherwise corrupted last transactions, you might have some problems with the restoration.

If you can't quiesce your environment, try your copies.  Preferably under heavy load.  Verify that the results are restorable, and preferably that the target disk is consistent.  Changes are, it won't be — consistent copies involve an offline BACKUP or BACKUP /IMAGE, or quiescing and splitting off a host-based shadowset volume, or — when you're interested in just a specific application — an application-integrated backup such as a database backup tool.

In general, host-based volume shadowing can be preferable to remote replication than does controller-level replication, and it means that the remote OpenVMS server(s) have shared write access to the same shared data.    You still have issues with incomplete transactions with some host or application crashes, but you're probably already contending with those, and you probably already either quiesce to get backups (possibly removing a host-based volume shadowing member volume from the volume set, as a source for the backup) or using database-level transactional processing and a database backup.

TL;DR: try it.  See if it works.

[Dennis Handly]

>controller-level level backups - can potentially be questionable

3PAR handles this by running Recovery Managers on the host.  These are suppose to have in depth knowledge of the OS and application.

But I'm not sure any exist for OpenVMS?

[Hoff]

---

@Dennis Handly wrote:

>controller-level level backups - can potentially be questionable

3PAR handles this by running Recovery Managers on the host.  These are suppose to have in depth knowledge of the OS and application.

But I'm not sure any exist for OpenVMS?

---

AFAIK, there is very little support for 3PAR on OpenVMS.  Here's an example of what is apparently offered, and there is no indication from that of host-level integration nor coordination, nor of anything that you can get beyond what HBVS and/or clustering provides, and using the latter tools you can arguably get a better and more robust solution — active-active, distributed, multi-site — than what is offered with this 3PAR configuration.  If you need a (relatively) "simple" remote-replicated disk and can provide the necessary coordination, then 3PAR is an option.  But so is slinging your OpenVMS backups around via SFTP, for that matter.

Beyond the OS-level integration, I'd expect parts of those "recovery managers" would have to be embedded into the applications.  This to capture all of the state that can be involved.  (This is the same sort of problem with "live" backups of OpenVMS RMS files and the BACKUP /IGNORE=INTERLOCK mess — there's no application-level coordination available.)   If the coordination is at the database level as would be typical for an add-on solution — and one of the more common databases on OpeVMS, RMS, does not AFAIK offer anything toward this goal — then the system manager can perform the backups and then transfer the database backup files somewhere else — this if the particular database itself is not already replicated.

But then if I had application-level coordination, then something like ZFS — unfortunately not available on OpenVMS — or HBVS can manage the storage and the controllers "downward", rather than having the storage controllers manage "upward" into the OS.

It'll be interesting to see whether somebody does solve this, but application state — from outside the application — is a very difficult problem.   Quiesce a VM, snapshot it, that's a (relatively) "easy" case.   It's the folks with the gonzo loads, gonzo activity and gonzo caching — these are the folks that really want something here — that are the most of the cases to get a good copy, too.