Re: Can a satellite survive the reboot of its boot server?

In article <45192232@xxxxxxxxxxxxxxxxxxx>, Hoff Hoffman
<hoff-remove-this@xxxxxx> writes:

Robert Deininger wrote:

If the satellite's system disk is in mount verification, the satellite
will just wait until the disk comes back, then resume normal operations.
Processes that don't need that disk will just continue running without
interruption.

Though if there are changes made to the satellite's system disk sans cluster
connectivity, I'd expect the satellite will become quite cranky and should
(will) exit the club.

That appears to be what happened.

Information on performing and operating rolling upgrades might be of interest
here (in general), and I'd look toward a shared interconnect of some sort.

I do rolling upgrades all the time (well, whenever I do an upgrade,
which is not that often), and just completed a rolling session of patch
application. When rebooting a VAX, I dismount the disks it serves from
an ALPHA. When it boots back in, some code in the startup checks
various cluster-wide logicals which cause it to wait until I have
performed a MINICOPY. With my rather slow hardware (several hours for a
shadow copy of a 9-GB disk), MINICOPY save a lot of time during which
performance would otherwise suffer. I was hoping for something similar
during an ALPHA reboot. Of course, the easy solution would be to have
more than one ALPHA in the cluster. Now that I have collected some
small ALPHAs in the summer, I might add one as a boot server with its
own system disk to the cluster. (I first have to make sure I have
enough BA356 boxes and appropriate cables, since I use 4-GB disks as
system disks for ALPHAs (2-GB for VAX) and all the ones I have need a
wide shelf.

Shared storage isn't an option where VAX is concerned (since I have no
such hardware), but again there is not really necessary. Maybe my ALPHA
controllers would support shared storage for an ALPHA system disk, but
it would be easier to just add another ALPHA node to the cluster and
then I could use MINICOPY when rebooting the other ALPHA.

.

Relevant Pages

  • Re: Creating a wide area VMS Cluster
    ... > My goal is to provide a disaster tolerant cluster for both OS and data. ... disrupting the balance of the effect of votes between sites A and B. ... You have the option of a single shadowed system disk between the ...
    (comp.os.vms)
  • Re: Creating a wide area VMS Cluster
    ... >My goal is to provide a disaster tolerant cluster for both OS and data. ... >system disk and be attached via SCSI. ... >I'm thinking that each site will have a copy of the system disk. ... So the disk containing SYSUAF et al. would be shadowed across multiple ...
    (comp.os.vms)
  • Re: Creating a wide area VMS Cluster
    ... > My goal is to provide a disaster tolerant cluster for both OS and data. ... > I'm thinking that each site will have a copy of the system disk. ... Look at the SET DEVICE /SITE settings. ...
    (comp.os.vms)
  • Re: Same system disk for multiple architectures ?
    ... The astute reader will note that the VAX and Alpha bootblock structures were designed with this in mind. ... The MBR and related structures of OpenVMS I64 are not compatible with the expectations of VAX and Alpha, ... The answer then was "get another disk", and I think you've heard a similar answer more recently. ...
    (comp.os.vms)
  • Re: VMS analogue of FBSD and linux hier(7) man pages
    ... A cluster could have one system disk for each node in the ... The Alpha and Integrity systems all boot ...
    (comp.os.vms)