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: [email protected]
AN!Whitepapers: http://alteeve.com
Node Assassin: http://nodeassassin.org
--
Linux-cluster mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-cluster
