On 12/29/2010 02:33 PM, Digimer wrote: > On 12/29/2010 02:02 PM, Stefan Lesicnik wrote: >> Hi all, >> >> I am running RHCS 5 and have a two node cluster with a shared qdisk. I have a bonded network bond0 and a back to back crossover eth1. >> >> Currently I have multicast cluster communication over the crossover, but was wondering if it was possible to use bond0 as an alternative / failover. So if eth1 was down, it could still communicate? >> >> I havent been able to find anything in the FAQ / documentation that would suggest this, so I thought I would ask. >> >> Thanks alot and I hope everyone has a great new year :) >> >> Stefan > > From: http://wiki.alteeve.com/index.php/Openais.conf > I forgot to mention that there are the redundant ring options as well. ------------------------------------ ### Redundant Ring Protocol options are below. These are ignored if ### only one 'interface' directive is defined. # This is used to control how the Redundant Ring Protocol is used. If # you only have one 'interface' directive, the default is 'none'. If # you have two, then please set 'active' or 'passive'. The trade off # is that, when the network is degraded, 'active' provides lower # latency from transmit to delivery and 'passive' may nearly double the # speed of the totem protocol when not CPU bound. # Valid options: none, active, passive. rrp_mode: passive # The next three variables are relevant depending on which mode # 'rrp_mode' is set to. Both modes use 'rrp_problem_count_threshold' # but only 'active' uses 'rrp_problem_count_timeout' and # 'rrp_token_expired_timeout'. # # - In 'active' mode: # If a token doesn't arrive in 'rrp_token_expired_timeout' milliseconds # an internal counter called 'problem_count' is incremented by 1. If a # token arrives within 'rrp_problem_count_timeout' however, the # internal decreases by '1'. If the internal counter equals or exceeds # the 'rrp_problem_count_threshold' at any time, the effected interface # will be flagged as faulty and it will no longer be used. # # - In 'passive' mode: # The two interfaces have internal counters called 'token_recv_count' # and 'mcast_recv_count' that are incremented by 1 each time a token # or multicast message is received, respectively. These counts for each # interface is counted and if the counts should differ by more than # 'rrp_problem_count_threshold', then the interface with the lower # count is flagged as faulty and it will no longer be used. # # If an interface is flagged as faulty, an administrator will need to # manually re-enable it. # The default problem count timeout is '1000' milliseconds. rrp_problem_count_timeout: 1000 # The default problem count threshold is '20'. rrp_problem_count_threshold: 20 # This is the time in milliseconds to wait before incrementing the # internal problem counter. Normally, this variable is automatically # calculated by openais and, thus, should not be defined here without # fully understanding the effects of doing so. # # In short; The should always be at least 'rrp_problem_count_timeout' # minus 50 milliseconds with the result being divided by # 'rrp_problem_count_threshold' or else a reconfiguration can occur. # Using the default values then, the default is (1000 - 50)/20=47.5, # rounded down to '47'. #rrp_token_expired_timeout: 47 ------------------------------------ Cheers -- Digimer E-Mail: digimer@xxxxxxxxxxx AN!Whitepapers: http://alteeve.com Node Assassin: http://nodeassassin.org -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
