| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1039.1 | | KONING::KONING | Paul Koning, A-13683 | Tue Jul 27 1993 18:02 | 14 |
| That configuration is legal according to the topology rules.
On the other hand, I'd say that you should use it with caution. The "usual"
configurations all have the property that a failover still leaves you as part
of the same LAN as before. In the setup you've shown, a failover will move
you to another LAN. Depending on what other protocols you run, what other
LANs your friends are connected to, and how (if at all) those LANs are
interconnected, the results might not be what you want.
However, so long as you understand this, analyzed the consequences, and
convinced yourself that such failovers will still leave you with a topology
that has the right nodes reachable, go ahead.
paul
|
| 1039.2 | From the man himself.. | LARVAE::HARVEY | Baldly going into the unknown... | Tue Jul 27 1993 18:59 | 34 |
|
Thanks Paul, that's what I needed to hear. ;^)
In this context the FDDI "LANs" are purely to be used for cluster traffic
between the two cluster lobes - hence only SCS (or is it SCA ?) protocol
will be in use. This protocol can be run over multiple adapters with no (?)
problem.
From what I know, I believe DECnet will be in use on the "user" side of the
network and thus be well away from these FDDI adapters.
I believe that cluster software is clever enough to "load balance/share"
over multiple adapters as well, so this should make good use of the
additional bandwidth.
The only questions I have is in terms of failure scenarios.....
- If the live link of the bridge fails, then it swops over to the other PHY
and connects to the second CON channel.
How long does this take ?
Will it have any effect(s) on the bridge's node tables ?
If only SCS/SCA protocol is in use what will the bridges learn about ?
I need a basic handle of the above and how it may interact with a failure in
a node, where we're going to see a cluster state transition too.
At the end of the day the customer is getting a relatively high-performance,
segregated cluster on the cheap and I think it is our job to carify that
this system only goes so far in the resilience stakes. If he wants more,
he's going to have to dig deeper into his pockets...
Thanks again for your input.
Rog
|
| 1039.3 | the MTBF of your single point-of-failure | ASDS::LEVY | | Wed Jul 28 1993 15:42 | 5 |
| Don't know if this is an option, but...
Have you considered a DC500 instead of the DB520? The DC500's MTBF is
roughly twice as good as the DB5xx/6xx. They're both in the multi-year
range, but the DC500 is a more reliable device.
|
| 1039.4 | | KONING::KONING | Paul Koning, A-13683 | Wed Jul 28 1993 16:30 | 6 |
| I know SCA can handle multiple adapters and multiple LANs. But that's not the
same as saying that it deals readily with stations moving from one LAN to
another, which is what happens here. You should confirm with a cluster
protocol expert that this is in fact ok; I have no idea.
paul
|
| 1039.5 | A parallel activity... | LARVAE::HARVEY | Baldly going into the unknown... | Thu Jul 29 1993 13:05 | 10 |
| -1. Paul - I hope this is being looked at by the clusters man on the job,
but I'd best check it out anyway.
-2. John - Granted the CON is the more reliable, still need a bridge in
there though. So the customer sees it as additional expense (I did say he is
doing this on the cheap !)
thanx
Rog
|
| 1039.6 | VMScluster software should handle this | STAR::PARRIS | The SLED is dead, long live RAID | Fri Aug 06 1993 12:50 | 18 |
| As long as the adapters all use unique LAN addresses, the VMScluster software
should have no problem handling the failover. PEDRIVER sends out multicasts
from each adapter about every 3 seconds -- the receipt of these multicasts is
what causes channels to be formed and what keeps them alive in the absence of
other cluster traffic.
In the case of a failover of the bridge to the other LAN in your configuration,
it appears that PEDRIVER will just start seeing the multicasts from the quorum
VAX now being received on a different adapter than before, set up a channel for
that, and eventually time out the old channel that it had set up for traffic
through the old adapter. The virtual circuit should see no interruption as
long as the failover takes less than 8-9 seconds; failing that, the cluster
should survive as long as the failover takes less than RECXNINTERVAL plus 8-9
seconds.
If you try to take advantage of the fact that you have separate LANs and run
DECnet Phase IV (or LAT with /DECnet specified) on both adapters, so they have
the same LAN address, then all bets are off.
|