[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference spezko::cluster

Title:+ OpenVMS Clusters - The best clusters in the world! +
Notice:This conference is COMPANY CONFIDENTIAL. See #1.3
Moderator:PROXY::MOORE
Created:Fri Aug 26 1988
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:5320
Total number of notes:23384

5246.0. "Once again: cluster and multiple LANs" by UTOPIE::BRAUN_R () Fri Mar 07 1997 18:25

    Hi all,
    
    I've done a rather simple test installation:
    
    
       LAN 1    --------------------------------------
                      |          |             |
                     VAX 1      VAX 2          Quorum-VAX
                      |          |            
       LAN 2    ------------------------
    
    
    My test was with Ethernet-only, the customer's configuration will
    be with FDDI-only, but there should no real difference, as there
    are always equal interfaces.
    
    I know of NISCS_MAX_PKTSZ, total connectivity, LAVC$START_BUS,...
    but I still have the following question:
    
    1.)    Without any visible, remarkable load on the LAN, the LAVC-traffic
           between VAX1 and VAX2 changed from LAN1 to LAN2 (and vice versa), 
           sometimes even VAX1 sending via LAN1 (to VAX2) and
                          VAX2 sending via LAN2 (to VAX1)
    
           Between equally equipped adapters, any preferral of one 
           of them, at least after system startup (e.g. XQA0 primary
           XQB0 secondary) ?
    
    
    2.)    If the QUORUM-system is connected to only one of the LANs
           (as in the sketch above) or if one of the QUORUM's adapters
           fail --> any effect on path-choosing between VAX 1 and VAX2 ?
    
           My observation says NO.  Is this really true ?
    
    
    3.)    What about LAVC-independent (and heavy) load on the LANs:
    
                will there be a path change     
    
                       OR
    
    		bad performance for e.g. shadow merging, still using
                the LAN with heavy traffic (as long as least connectivity
                is guaranteed, e.g. HELLO-messages)  ??????
    
    
    
    
    Any help will be highly appreciated.
    
    Thanks,
    Ralph
    
    
             
    
    
    
    
    
    
    
    
     
    
    
    
    
T.RTitleUserPersonal
Name
DateLines
5246.1No; No; When Link Cost Goes Up...XDELTA::HOFFMANSteve, OpenVMS EngineeringFri Mar 07 1997 20:020
5246.2FDDI != EthernetUTOPIE::BRAUN_RMon Mar 10 1997 15:4013
    Hi,
    
    thanks!
    
    But there seem to be some differences between Ethernet (our test) and 
    FDDI (another customer installation):   FDDI seems to be more resistant
    staying on one particular adapter, not flapping like Ethernet (due to
    ongoing measurement of network performance)
    
    Could this be true ?
    
    Thanks,
    Ralph
5246.3Bigger Pipe, Same `Flapping' SchemeXDELTA::HOFFMANSteve, OpenVMS EngineeringMon Mar 10 1997 16:440
5246.4NI slower than FDDI, therefore more flapping...STAR::BOAENLANclusters/VMScluster Tech. OfficeTue Mar 25 1997 20:2420
re:-< FDDI != Ethernet >-

	VAXen will tend to switch preferred ethernet paths more often
than they will switch FDDI paths. VAXen measure time with 10ms granularity,
and ethernet under some load will tend to show up as a 10ms delay
more often than will FDDI under a similar load.
Thus making the ethernet preferred path look 'slower' than the other
ethernet path, resulting in more frequent path
switching. If one ethernet is consistently more heavily loaded than the
other, then the lighter loaded ethernet will get chosen and the load will
tend to stay there.

	So, bigger pipe implies less flapping until the load begins to
increase delays beyond ~10ms on one fddi path...

Look in the appendices to the V6.2 or V7.x 'VMScluster Systems for OpenVMS'
manuals for more details about how the LAVC protocols do things. Also,
there's more detail in other notes in this conference.
Verell