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

[gezelter at rlgsc.com]

On Friday, April 12, 2019 at 10:56:00 AM UTC-4, geze... at rlgsc.com wrote:
> On Friday, April 12, 2019 at 8:57:31 AM UTC-4, Rod Regier wrote:
> > I’m investigating to see if I have missed out on a practical technical  alternative.
> > 
> > Background:
> > I have a North American multi-site installed base of Alpha and Integrity servers
> > running HPE OpenVMS to support the application package my organization supplies
> > for those customers.  The OpenVMS systems are supplied on a turnkey basis,
> > so my organization is responsible for providing remote OpenVMS first-tier support
> > from a central location.  The sites are usually provisioned with IT technical staff
> > who can provide limited hardware support.  My organization is responsible
> > for the rest of the hardware support.
> > 
> > One of the options I’m considering is upgrading all of those systems
> > from HPE to VSI OpenVMS.
> > 
> > Question:
> > 
> > Is there an approach I have missed in the following list to accomplish that goal:
> > 
> > “Consultant approach”
> > Fly in a consultant to perform an onsite upgrade at each separate site
> > Comments:
> > Very long outage
> > Very expensive in consulting hours and travel, lodging, meals charges
> > 
> > “Pseudo hardware upgrade approach”
> > Ship a second similar architecture system to the site
> > -	w/loaded and patches OS
> > -	w/networking client configuration preloaded
> > -	Migrate applications and client-specific data over LAN
> > Comments:
> > Shortest outage
> > Shipping costs
> > Needs float machine hardware pool for several different models
> > 
> > 
> > “Drycleaner laundry approach”
> > Make a backup of the client-specific data and applications.
> > Freeze client operations
> > Transfer over Internet to central support site
> > Create OS image at central site
> > Network configure the image to client site details
> > Load client-specific data into the image
> > Create bootable media with build system
> > Priority ship media to customer site
> > Walk client thru image load overwriting existing OS+data
> > Comments:
> > Lowest consulting costs
> > minimal shipping costs
> > intermediate outage
> > No float hardware required
> > Highest risk for unforeseen extended outage
> 
> Rod,
> 
> There are some other options possible.
> 
> Are the field deployed systems using shadowed system disks? What does the configuration look like? Are the OS files separated from the application files (different disk and/or directory)? What does the mass storage environment look like?
> 
> What I have done in a variety of situations is to create what is, in effect, a clone of the system disk offline, then do a reboot using the system disk clone. Then one continues operation using the new system disk (with the updated OS). 
> 
> There are more details to be sorted out, but it does generally avoid the need for someone to be physically present. It also minimizes downtime.
> 
> - Bob Gezelter, http://www.rlgsc.com

Rod,

To clarify, the first step in my suggestion is to split the application/data from the system disk. Then the system disk can be interchanged.

As to the local/remote IP issue for console access. This can often be resolved with a small PC-class platform (e.g., laptop or smaller) with secure external access and a separate Ethernet port for the local network. Some of these limited capability systems (sans keyboard/monitor/mouse) can be had very inexpensively.

- Bob Gezelter, http://www.rlgsc.com