Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
I'll try to include all of the responses I got so far in this response. Thank you all for your help.
---- From: Eugene Istomin
> We had the same problems, upgrade kernel- and userside to 8.4.4 resolved this issue.
We are planning to upgrade to kernel 3.0.101 and DRBD 8.4.4.
---- From: Philip Gaw
> Why are you using broadcast mode? We have the same configuration with balance-rr and 3 NICs which works great.
We thought since we had cross-over cables (with no switches or routers in between - direct connection between the two servers) that it would add more fault tolerance, especially when dealing with such sensitive keep-alive scheme (of DRDB). Are there reasons not to use this mode (in this configuration or others)?
---- From: Alexandr A. Alexandrov
> MAC address mismatch or wrong cabling.
In our case, we have cross-over cabled the two servers, seating one on top of the other (with no way of mixing them). With regard to the MAC addresses, since we are using broadcast mode then the two NIC cards would exhibit different MAC addresses as shown in the configuration file I attached (see below). Could this cause an issue if a ping packet is sent over one NIC and the response received on the other one? I remember reading somewhere that DRBD enforces MAC address checking (but I'm not 100% sure).
Thank you again to all.
Regards,
Youssef
-----Original Message-----
From: drbd-user-bounces at lists.linbit.com [mailto:drbd-user-bounces at lists.linbit.com] On Behalf Of drbd-user-request at lists.linbit.com
Sent: Friday, March 07, 2014 10:53 AM
To: drbd-user at lists.linbit.com
Subject: drbd-user Digest, Vol 116, Issue 6
Send drbd-user mailing list submissions to
drbd-user at lists.linbit.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.linbit.com/mailman/listinfo/drbd-user
or, via email, send a message with subject or body 'help' to
drbd-user-request at lists.linbit.com
You can reach the person managing the list at
drbd-user-owner at lists.linbit.com
When replying, please edit your Subject line so it is more specific than "Re: Contents of drbd-user digest..."
Today's Topics:
1. Re: "PingAck timeout" in a dual active/passive configuration
(philip gaw)
2. Re: "PingAck timeout" in a dual active/passive configuration
(Eugene Istomin)
----------------------------------------------------------------------
Message: 1
Date: Fri, 07 Mar 2014 11:03:00 +0000
From: philip gaw <pgaw at darktech.org.uk>
Subject: Re: [DRBD-user] "PingAck timeout" in a dual active/passive
configuration
To: drbd-user at lists.linbit.com
Message-ID: <5319A764.2030005 at darktech.org.uk>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 06/03/2014 13:59, Latrous, Youssef wrote:
>
> Hi Alexandr,
>
> Thank you for the response. I checked our bonding setup and I didn't
> see any issues (see below for details). We use the "broadcast" mode
> over cross cables, with no switches in between - direct connection
> between the two servers, seating side by side, connecting 2 NICs from
> one node to the other node's NIC cards. Is the broadcast mode the
> right choice in this configuration? I don't understand the MAC address
> reference in this context. Does DRBD check this info for Acks? That is
> if it sends on one NIC and receives on the other NIC it would drop the
> packet?
>
Why are you using broadcast mode? We have the same configuration with balance-rr and 3 NICs which works great.
> Also, given that DRBD uses TCP with built-in retransmits, over these
> cross cables, I really don't see how we could lose packets within the
> 6 seconds window? Please note that we monitor this network and report
> any issues (we use pacemaker). We didn't see any issues so far with
> this network.
>
> As you can notice, I'm a bit lost here J
>
> Thank you,
>
> Youssef
>
> PS. Here is our bond setup for this HA network.
>
> --
>
> Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
>
> Bonding Mode: fault-tolerance (broadcast)
>
> MII Status: up
>
> MII Polling Interval (ms): 100
>
> Up Delay (ms): 0
>
> Down Delay (ms): 0
>
> Slave Interface: eth0
>
> MII Status: up
>
> Speed: 1000 Mbps
>
> Duplex: full
>
> Link Failure Count: 0
>
> Permanent HW addr: c8:0a:a9:f1:a9:82
>
> Slave queue ID: 0
>
> Slave Interface: eth4
>
> MII Status: up
>
> Speed: 1000 Mbps
>
> Duplex: full
>
> Link Failure Count: 0
>
> Permanent HW addr: c8:0a:a9:f1:a9:84
>
> Slave queue ID: 0
>
> Youssef,
>
> Check your bonding mode!
> It apperes that you loose packets, this can be because the mode is
> wrong or MAC addresses wrong.
>
> Best regards,
> Alexandr A. Alexandrov
>
>
> 2014-03-06 0:38 GMT+04:00 Latrous, Youssef <YLatrous at broadviewnet.com <http://lists.linbit.com/mailman/listinfo/drbd-user>>:
>
> >/ Hello,/
> >/ /
> >/ /
> >/ /
> >/ We are currently experiencing a weird "PingAck" timeout on a
> >system with/ / two nodes, and an active/passive configuration. The
> >two nodes are using a/ / cross-cabled connection in a bonded two
> >Giga NIC cards. This network never/ / goes down and used only for
> >DRDB and CRM cluster data exchange. It's barely/ / used (very light
> >load). We are running SLES 11 SP2, DRBD release 8.4.2, and/ /
> >pacemaker 1.1.7./ / / / / / / / We couldn't find a DRBD
> >configuration option to setup the number of/ / retries before giving
> >up./ / / / / / / / Our concern is that we do not understand how a
> >PingAck can timeout over/ / such a reliable media? Any insight into
> >this would be much appreciated./ / / / / / / / On the same note,
> >are there any guards against it? Any best practices/ / (setups) we
> >could use to avoid this situation?/ / / / / / / / Thanks for any
> >help,/ / / / / / / / Youssef/ / / / / / / /
> >_______________________________________________/
> >/ drbd-user mailing list/
> >/ drbd-user at lists.linbit.com
> ><http://lists.linbit.com/mailman/listinfo/drbd-user>/
> >/ http://lists.linbit.com/mailman/listinfo/drbd-user/
> >/ /
> >/ /
>
>
> --
> ? ?????????, ???.
> -------------- next part -------------- An HTML attachment was
> scrubbed...
> URL:
> <http://lists.linbit.com/pipermail/drbd-user/attachments/20140306/2544
> fc77/attachment.htm>
>
>
>
> _______________________________________________
> drbd-user mailing list
> drbd-user at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20140307/45bdcc38/attachment-0001.htm>
------------------------------
Message: 2
Date: Fri, 07 Mar 2014 17:45:54 +0200
From: Eugene Istomin <E.Istomin at edss.ee>
Subject: Re: [DRBD-user] "PingAck timeout" in a dual active/passive
configuration
To: drbd-user at lists.linbit.com
Message-ID: <2057920.MHikleqZ3m at evis>
Content-Type: text/plain; charset="utf-8"
Hello,
We had the same problems, upgrade kernel- and userside to 8.4.4 resolved this issue.
/---/
*/Best regards,/*
/Eugene Istomin/
On 06/03/2014 13:59, Latrous, Youssef wrote:
Hi Alexandr,
Thank you for the response. I checked our bonding setup and I didn?t see
any issues (see below for details). We use the ?broadcast? mode over
cross cables, with no switches in between - direct connection between the
two servers, seating side by side, connecting 2 NICs from one node to the
other node?s NIC cards. Is the broadcast mode the right choice in this
configuration? I don?t understand the MAC address reference in this
context. Does DRBD check this info for Acks? That is if it sends on one NIC
and receives on the other NIC it would drop the packet?
Why are you using broadcast mode? We have the same configuration with
balance-rr and 3 NICs which works great.
Also, given that DRBD uses TCP with built-in retransmits, over these cross
cables, I really don?t see how we could lose packets within the 6 seconds
window? Please note that we monitor this network and report any issues
(we use pacemaker). We didn?t see any issues so far with this network.
As you can notice, I?m a bit lost here J
Thank you,
Youssef
PS. Here is our bond setup for this HA network.
--
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Bonding Mode: fault-tolerance (broadcast)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: c8:0a:a9:f1:a9:82
Slave queue ID: 0
Slave Interface: eth4
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: c8:0a:a9:f1:a9:84
Slave queue ID: 0
Youssef,
Check your bonding mode!
It apperes that you loose packets, this can be because the mode is wrong
or
MAC addresses wrong.
Best regards,
Alexandr A. Alexandrov
2014-03-06 0:38 GMT+04:00 Latrous, Youssef <YLatrous at
broadviewnet.com[1]>:
>/ Hello,/
>/ /
>/ /
>/ /
>/ We are currently experiencing a weird ?PingAck? timeout on a system
with/
>/ two nodes, and an active/passive configuration. The two nodes are
using a/
>/ cross-cabled connection in a bonded two Giga NIC cards. This network
never/
>/ goes down and used only for DRDB and CRM cluster data exchange. It?s
barely/
>/ used (very light load). We are running SLES 11 SP2, DRBD release 8.4.2,
and/
>/ pacemaker 1.1.7./
>/ /
>/ /
>/ /
>/ We couldn?t find a DRBD configuration option to setup the number of/
>/ retries before giving up./
>/ /
>/ /
>/ /
>/ Our concern is that we do not understand how a PingAck can timeout
over/
>/ such a reliable media? Any insight into this would be much appreciated./
>/ /
>/ /
>/ /
>/ On the same note, are there any guards against it? Any best practices/
>/ (setups) we could use to avoid this situation?/
>/ /
>/ /
>/ /
>/ Thanks for any help,/
>/ /
>/ /
>/ /
>/ Youssef/
>/ /
>/ /
>/ /
>/ _______________________________________________/
>/ drbd-user mailing list/
>/ _drbd-user at lists.linbit.com_/
>/ /_/http://lists.linbit.com/mailman/listinfo/drbd-user/_
>/ /
>/ /
--
? ?????????, ???.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20140306/2544fc77/attachment.htm[2]>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20140307/68e343e5/attachment.htm>
------------------------------
_______________________________________________
drbd-user mailing list
drbd-user at lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user
End of drbd-user Digest, Vol 116, Issue 6
*****************************************