[Info-vax] satellite with more than one boot server

[Phillip Helbig---undress to reply]

In article <kejc5q$p2j$1 at dont-email.me>, Stephen Hoffman
<seaohveh at hoffmanlabs.invalid> writes: 

> This is listed in the clustering manuals as boot servers and disk 
> servers.  They don't have to be the same.

OK, boot servers, disk servers and satellites.

> > Then the satellite requests a boot and any
> > node which is configured can boot it.  Except for the ethernet address
> > of the satellite, which of course is fixed, these configurations could
> > presumably be identical or completely different (SCSSYSTEMID, IP
> > address, ALLOCLASS, SYS$SPECIFIC).
> 
> Yes.  The fastest boot server wins.  The other boot servers usually get 
> a "line open" error logged, indicating there was a collision detected 
> on the network.
> 
> The downside is a disk or boot server that doesn't have local (fast) 
> access to the boot disk.  That overhead can clog even a gigabit 
> network, particularly if you've also got HBVS in play and start 
> slinging piles of blocks around for that.

Each "main" node in the cluster has its own system disk.  No more than 
one satellite at a time.  So, all potential boot servers and disk 
servers have direct access to their system disk.  (By definition, the 
satellite has only network access to its system disk.)

> > I'm not sure if I would prefer them
> > to be identical or different.  If I opt for different, the only
> > potential problem would be with TCPIP, and then only if I have common
> > TCPIP configuration files (i.e. for all system disks in the cluster).
> 
> It's extremely rare to have different boot configurations served in 
> parallel, by default.

The only reason I thought about it is that a while back I assigned each
machine a unique number.  This is used in SCSSYSTEMID, the TCPIP
address, ALLOCLASS, the volume label of the system disk and
SYS$SPECIFIC.  (It isn't used in the node name, though of course this
would be a 6th possibility.)  Thus, if a satellite boots from, say, 
machine 110 (i.e. SYS$SPECIFIC is [SYS110] (I know it's hex and thus a 
different number, but the purpose is to allow me to rembember them 
easily), TCPIP address ends in .110, SCSSYSTEMID is X+110, ALLOCLASS is 
110, volume label is ALPHASYS_110), then it would make sense for a 
satellite to have, say, 111.  However, that makes sense only if it boots 
from one system disk, which is a single point of failure.  Thus, maybe 
better would be to have identical configurations and use numbers below 
200 for nodes with their own system disks and above 200 for satellites.

> DECnet and IP tend to have the most examples of this.  But nothing 
> prevents you from having a dozen identical SYS$SPECIFIC configurations, 
> or a dozen different, either.  Where you're potentially headed — 
> different boxes booted from the same root — is painful however, not the 
> least because the available devices and the device names tend to differ 
> among different boxes.

I would never have different boxes booting from the same root.

A related question: for a satellite with 2 ethernet cards, would it be 
best to configure 2 identical virtual satellites, differing only in the 
ethernet address?  They would never be used at the same time.  (I'm 
assuming that one can't enter more than one ethernet address in the 
satellite config.)