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

[Dave Froble]

On 4/15/2019 10:56 AM, Stephen Hoffman wrote:
> On 2019-04-15 12:16:46 +0000, Rod Regier said:
>
>> Floor for SFF SAS drive controllers is RX2660. Very few of those in my
>> installed installed base systems are running those.
>> Installed base unlikely to sustain pricing of whole sale upgrade of
>> DS10L, DS15 and RX2600 units to RX2600 units or beyond.
>> ...
>> The list for Nemonics alleged "new" drives is impressively long - over
>> 100+ different models spanning over a 15 years of product evolution.
>> Makes me skeptical they are "new" in the sense of an actual drive
>> SMART data reporting under 5000 hrs of actually spin time.
>
> There is seemingly some unfamiliarity with hardware availability, and
> the current necessity to compensate for the usual limitations of app
> software, and also with the associated limitations of OpenVMS.
>
> Unfortunately, modifications to the apps to ease these inevitable
> storage and server transitions are perceived as being far more difficult
> or more expensive than are these manual transitions.  Server replication
> is not commonly seen with OpenVMS apps, but it's common with other sorts
> of clustering.
>
> App developers on many platforms and for many apps seemingly have to be
> dragged into supporting upgrades and migrations.  Which doesn't help.
>
> SFF drives are serial SCSI (SAS, SATA), and those are readily
> available.  So not an issue here.
>
> New parallel SCSI SCA hard disk drives are available, and will work when
> internally mounted and configured with the proper parallel SCSI
> adapters.  "Cage-free" AlphaServer DS15 systems have several internal
> bays that can be used, for instance.
>
> Might want external shelves, if you're working with vendor storage cages
> and vendor-provided removable storage devices.   Storage upgrades are
> quite possible within the bricks of the ancient StorageWorks SBBs. Newer
> removable mountings, less feasible.  Which is where Nemonix provides
> adapters and firmware to allow newer storage to mimic the older
> storage.  Call'm and ask if they can offer new storage for these and
> similar storage replacements.  AFAIK, they can provide new storage here,
> and not refurbs. https://www.nemonix.com/pdfs/NxDatasheet_NXRZ_ST.pdf
> But for parallel SCSI configurations, SCA adapters will probably work
> for your needs, given somewhere to mount the SCA drives, and not-ancient
> OpenVMS versions.
>
> IIRC, Alpha never officially supported serial SCSI controllers, and
> Integrity didn't officially support serial SCSI controllers prior to the
> PCIe-enabled servers.  (SAS and SATA need the PCIe bus bandwidth, and
> particularly for the SSDs.)  So serial storage storage whether SSF or
> otherwise less interesting for the pre-PCIe server boxes.  And whether
> unsupported SAS/SATA PCI-X controller configurations can be gotten to
> work, there are still parallel SCSI drives with SCA available for the
> older server boxes.
>
> Beyond reworking the apps to make these swaps easier to deal with,
> establishing a server replacement cycle is another and overarching issue
> here.  The AlphaServer DS10L gets "toasty fun" when the thermal paste
> under the heat sink finally dries out and crumbles, for instance.
>
> This whole server migration mess is a slog of our own app development
> (mis)practices, unfortunately.  OpenVMS has never been good at this
> stuff, and clustering and the rest of OpenVMS are just plain bad at
> providing app development support—effectively none—for these app and
> server migrations.  OpenVMS allows and variously encourages scattering
> app files and data all over the place.  (macOS is vastly better at
> wholesale app migrations, for instance.)  Typical would be app-level
> shadowing of data across servers, whether using RabbitMQ or some other
> scheme.  https://www.rabbitmq.com/clustering.html  Etc.
>
> Yeah, retrofitting assistance for server migrations into apps gets
> gnarly.  But we're never not going to be migrating to newer servers, and
> we're headed for more migrations given the shorter replacement cycles
> expected with x86-64 servers.
>
> TL;DR: what has to happen for a server migration varies, and a server
> migration is as much dependent on the app (software) details as on the
> server (hardware) details.  If not more so.  The messes here are almost
> always of our own apps' doings and not-doings, too.

Basically you're saying "it's never done", and you are correct.

A similar thing occurs with those who build experimental aircraft.  Some 
have the opinion that it's done, and will never need to come apart. 
They are of course wrong, because everything in the aircraft is a 
consumable.  Fuel goes pretty fast, but everything wears, and in time 
will require inspection and maintenance.  So, it's never done.

The same applies to many things, and maybe more so to computer systems 
than most.  There will be HW failures.  There will be HW upgrades, for 
that software good enough to stick around for some time.

Thus it should be an integral part of the overall design of a "system" 
to recognize future activity and plan for it.  It seems that you feel 
most of this responsibility should be born by the OS.  True, some good 
tools can make things easier.  But ultimately, it is the designer(s) of 
the overall system who should bear the responsibility.  I'm pretty sure 
that you'd agree that even your beloved Macs can be screwed up.

Just sayin, don't be too quick to blame the tool (OS) for the errors of 
the workman (app system designers).

And also agreeing that better tools are and should be possible.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486