[Info-vax] Multi-site OpenVMS field upgrade options?

[Stephen Hoffman]

On 2019-04-12 12:57:29 +0000, Rod Regier said:

I'd flip this whole discussion around.

This discussion is as much or more about the app design and app 
features and app capabilities as about the OpenVMS dependency.  Because 
OpenVMS pushes all of these details and trade-offs into the apps, and 
with very few assists available.

Welcome to the cloud.  You're a cloud-hosting provider, with multiple 
and geographically distributed data centers.  And with an operating 
system dependency that really hasn't yet grokked remote management, 
server migration, disaster recovery and various marketing to the 
contrary, nor of spinning up guests, or other related techniques.

Pragmatically, this question is more about how easy your app and the 
data and customizations of your customers can be migrated, and rather 
less about OpenVMS itself.  And there's no information on this yet 
posted here.

Around how gnarly or not-gnarly the application environments might be.  
Around whether remote access to the apps might be feasible; whether 
hosting the apps and the data during the migration is feasible.

Maybe getting that data loaded onto another server, with ever-smaller 
windows as each hunk of data is transferred to the "remote" host.  Big 
hunks of data via courier, smaller hunks online as the configurations 
approach synchronization.  This can involve database and app logging, 
which may or may not exist in the current environment.

On how well the apps themselves are packaged.  Is your stuff using PCSI 
or some analog?  Scatter-shot and hand-installed configurations are far 
more prone to errors.  Are your site-specific customizations isolated 
and packaged?  What sort of database features and server configuration 
features might be available to shorten the transition window?  
Shadowing, for instance, where you shut down and split off a member 
volume and use that as either your data transfer, or as your backup and 
fallback.

These same issues and discussions tie into recovery from hardware 
failures and from disasters, too.  You've much more warning on this 
case, and more than a little time to plan for and execute the 
transition.  Take copious notes.  Make app updates. You might 
eventually need to execute this same or a very similar sequence on a 
deadline.

I've done these migrations with external arrays, and with disk spindle 
migrations, and with depot upgrades.  And with bespoke upgrades.  And 
with apps that can inherently migrate and routinely mirror themselves.  
The "best" approach depends on how gnarly the app is, on how tied into 
OpenVMS the app is, and on how much over-provisioning is available.  
Also around how much assistance and modifications can be involved 
within the app.  And around the tolerance for and costs of downtime, 
too.

Rolling out upgrades and patches has not been a strength of OpenVMS in 
recent decades.  Particularly not expediently.



> “Consultant approach”...

Classic bespoke upgrades.   Traditional.  Slow.   Error-prone.  Tedious.

For approaches such as this, works most cost-efficiently with remote 
access and with some over-provisioning of the servers involved.

Access to a local OpenVMS server with host-based InfoServer configured 
can be useful, particularly for remote access upgrades. Avoids having 
to reload kits.  The advanced iLO features on Integrity—the virtual KVM 
and virtual drive storage—might be interesting, though your mix of 
Itanium and AlphaServer servers won't help there.

I'll assume that remote console access is available.  I've done a 
number of remote upgrades using that.   Whether there are spare storage 
devices at each site, or that the available "spares" are tied up in the 
RAID arrays or some such?

> “Pseudo hardware upgrade approach”

Server migration.

OpenVMS utterly *stinks* at this approach.  There are other operating 
systems that quite commonly and effectively use this approach, 
migrating apps and data and customizations from the boot device or from 
the backups.

OpenVMS scatters its settings and customizations all over the place.  
As do many OpenVMS apps.  Host names get embedded all over the place.

Logical names do not help things here, as those get established and get 
embedded all over the place, and usually in files separate from the 
apps.

That grumbling aside, your apps can be much better about this.  Or much worse.

> “Drycleaner laundry approach”

A depot upgrade, with an on-site data transfer.






ps: Remember to migrate the ssh host keys, if you're using the ssh daemon.




-- 
Pure Personal Opinion | HoffmanLabs LLC