Thanks for all your first responses but ...
I forgot to mention that it is a general case , not specifically with
drbd that I never used in my Pacemaker configuration.
And that I use to set two heartbeat networks in rrp mode , with at least
one of them completely dedicated to heartbeat,
so I don't think of any network overload here, but much more on "local"
overload on node.
Dejan, you spoke about corosync in higher priority, where can I check
that it is the case ?
Thanks
Alain
Le 02/10/2013 01:46, Arnold Krille a écrit :
On Tue, 01 Oct 2013 13:10:14 -0700 "C.Smith" <[email protected]>
wrote:
Not a ha expert, just an opinion.but what i did was to put my drbd
and corosync traffic on a private 10g network, i didnt want
client/downstream to interfere with cluster communications. Works
well for me, but dont know if its applicabe to you. There are
utilization rules you can use to prevent the log jam, but i have no
experience using them other than knowing they exist.
I only put the drbd traffic on the 10g network. Partly to keep it apart
from the corosync and the other traffic, partly because I have three
nodes and only the two drbd-nodes have that 10g connection.
I am planning in the near future to go back to two corosync
communication rings on two independent vlans on the two
1g-interfaces-per-node connected to two switches. Then corosync traffic
will be out of normal traffic again.
Currently all non-drbd shares the main active-passive link on each
node.
It is actually wise to put corosync and drbd on different networks and
preferably on different interfaces. drbd sends big data packets and
will benefit from large mtu, corosync sends small packets. And you want
neither to wait on the other in the send-queues.
Have fun,
Arnold
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
