| Title: | FDDI - The Next Generation |
| Moderator: | NETCAD::STEFANI |
| Created: | Thu Apr 27 1989 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2259 |
| Total number of notes: | 8590 |
Earlier today a few of us were discussing "disaster scenarios" in the
networks area in association with MDF VAXclusters - we're tasked with
delivering the user documentation.......
One particular topic was aired which we need help to resolve.
Imagine an FDDI ring linking 3 concentrators in separate buildings.
One of the buildings has a problem - lets say the power starts to fail with
the result that supply may "bounce" ie. on/off/on/off. FDDI components
are affected - concentrators etc.
This building houses systems which form part of an MDF VAXcluster.
At some stage the FDDI system senses the break in the ring due to the lost
concentrator and causes the two remaining concentrators to "wrap" the ring.
My understandings of FDDI are that the concentrator ports "nearest" to the
broken device are wrapped - thus enabling any attached devices on the good
concentrators to continue operation.
At this point the cluster reacts with state transitions etc. and causes the
affected site's systems to cluster "hang".
Now in order to ensure correct operation and behaviour of the cluster
as/when things recover, we want to further control the behaviour of the
FDDI devices and wish to DISABLE the "wrapped" ports on the "working"
concentrators (which link to the broken one) using DECmcc elm and the
device (concentrator) port control feature.
In this manner we can assure ourselves that the systems are ok to rejoin
the cluster and simply ENABLE the concentrator ports when we're ready.
If you're wondering how we can access the hung cluster systems to check
them out if we disable the FDDI connections, we have an extended ethernet
LAN which allows us to get to them via the "back door"...
Essentially the question is "can we DISABLE a wrapped port" ?
On a slight tangent but still related to the above....
We can use DECmcc to DISABLE a user "M" port on a concentrator so as to
isolate given devicces from the FDDI LAN. I've certainly done this with no
problems in the past. However, a colleague recently experienced some
considerable embarassment when he tried out this feature on a custome site
for himself.
He selected an unused "M" port on a concentrator to try it on, actioned the
DISABLE on it and .... OOPS !! All the MDF cluster members reported "loss
of connection" to each other and promptly went into a hung state with
Quorum lost. Fast thinking and ENABLING the selected concentrator port soon
had everything back in order, fortunately !
We were wondering if it is possible to DISABLE an unused/not connected "M"
port or is this another form of the symptoms exhibited in my first query
above.
We'd like to try it out again but for some reason the customer is reluctant
to let us ! :^)
Thanks in advance.
Rog
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 835.1 | Controlling cluster configuration with FDDI | MUDDY::WATERS | Wed Jan 20 1993 10:50 | 22 | |
Sorry to digress, but:
I found it interesting that you disable VMScluster communications
between the good sites and the bad site by turning off the whole
FDDI link. This forces you to use a parallel Ethernet LAN to manage
the bad site until the FDDI links are turned back on.
Just wanted to point out that with GIGAswitch, you can disable
VMScluster communications over FDDI without stopping LAT, IP (for
SNMP from DECmcc) or ISO routing (for CMIP from DECmcc). You can
set the ports to filter only the SCS protocol, or perhaps just
SCS' cluster configuration multicast address. So, when power is
restored to the faulty site, its FDDI links can come back on line
and provide remote management without letting the remote site rejoin
the cluster.
Taking that a step further, I wonder why VMS cannot provide an
option so that a system does a minimum boot by default following any
unplanned shutdown in an MDF environment. So no failed system will
rejoin its cluster until the operator pokes VMS to start its cluster
configurator. Why use the network hardware to manage the cluster
configuration rather than controlling it through VMS?
| |||||
| 835.2 | LARVAE::HARVEY | Baldly going into the unknown... | Thu Jan 21 1993 06:05 | 32 | |
Just to add that I'm a Networker not a Clusters man - I was just asking the
questions... However, I understand from my (VMS) collegue that this method
of control was discussed with the MDF product folks as an option of
"isolation" during a failure.
From the point of control of MDFs in a "creeping death" failure scenario I
can empathise with this idea while staff acquaint themselves with what's
happening, where, how, when and whether the cluster "lobe" is intact or
not. My concern is one of whether disabling a wrapped port is possible
without causing yet more troubles.... akin to the 2nd part of my original
note.
Installations I've been involved with have configured the FDDI as a network
backbone as well as MDF Cluster connect - hence the backup ethernets have
been a feature of overall disaster tolerance that we've built-in anyway.
The availability of such a link is valuable in the event of a total FDDI
outage/disconnect at a given location on the FDDI ring ie. loss of
concentrator etc. where NO connectivity via FDDI may be possible.
I like your ideas about the minimal re-boot and have passed it on for
consideration.... I dunno enough to comment :^)
I also like the details about the Gigaswitch - I think we have a winner
here ! However, it may still suffer from the above type of problems in the
event of a major problem, no matter how resilient we make the box, PSU etc.
Any ideas how long we have to wait before MDF support the Gigaswitch ?
Keep 'em coming.
Rog
| |||||
| 835.3 | Need a solution now - not 2 years | SCHOOL::LEKAS | From the Workstation of Tony Lekas | Mon Jan 25 1993 15:35 | 12 |
RE: .1 MDF is out there now. GIGAswitch is not and we cannot plan on all MDF customers having GIGAswitch. There is a very long lead time in getting changes into VMS. Also currently they are reluctant to make changes to support a low volume product, even if that product sells for a lot and sells a lot of iron along with it. There are other changes that we have asked for and they have responded with a flat NO. Tony | |||||