On 17.05.2011 18:19, Herman wrote:
I made a change to IPTables, and did a "service iptables restart", and
next thing I knew, I had a split brain.
I would guess that the RHEL FW setup flushes the connection tracking
tables and has a default drop (or reject) rule.
This would cause DRBDs TC
Hi,
On 21.06.2011 17:36, Felix Frank wrote:
On 06/21/2011 05:15 PM, Noah Mehl wrote:
The results are the same :(
Sorry to hear it.
'dd' is probably not a good benchmark when throughput approaches the
1GByte/s range.
With 'dd' on a system with similar performance (8x15k SAS disks, LSI,
10
On 23.07.2011 06:30, Digimer wrote:
Any way to debug this? If it looks like a DRBD bug,
I don't think so. I have DRBD running with jumbo frames on several
machines and it just work (albeit with 0.8.10).
Check you networking.
Try "ping -c1 -Mdo -s 8192 ", that should tell you if you
get
On 23.07.2011 21:54, Digimer wrote:
Thanks for the reply Andy.
The hardware (Intel Pro1000/CT NICs[1] and a D-Link DGS-3100-24[2])
both support 9kb+ frames (and JFs are enabled in the switch). With the
MTU on either node's DRBD interface (eth1) set to 9000, I confirmed
that JFs worked using
On 09.08.2011 16:46, Herman wrote:
Also, right now I'm using "mode=active-backup". Would one of the
other modes allow higher throughput and still allow automatic failover
and transparency to DRBD?
Try round-robin in your situation, it is the only bonding mode that
gives higher throughput f
On 10.08.2011 19:04, Herman wrote:
If this is the case, maybe arp monitoring is more reliable for direct
connections since NIC failure (which may fail but still have link up) is
more likely than cable failure? Maybe I don't have a good understanding
of this.
With switches in between, ARP monit
On 06.09.2011 19:07, Lars Ellenberg wrote:
The basic problem: if the link goes away because of one node chaning its
IP, we cannot possibly do a dns lookup from kernel space...
Well, we could. But that would be a good reason to kick us out of the
kernel and never talk to us again ;)
Yes, if you d
On 21.10.2011 12:00, Nick Morrison wrote:
Am I mad? Should it work?
It does. We run DRBD + Pcmk + OCFS2 for testing. I would not use such a
setup in production though.
Will performance suck compared with running DRBD directly on the physical
machines? I understand I will probably have h
On 25.11.2011 17:08, John Lauro wrote:
What I’m not sure about from the examples… Can you then add more
GFS/OCFS2 nodes (ie: a 3^rd and 4^th node) that have no local disk as
part of the SAN cluster, but instead talk drbd to the first two nodes?
Or would you have to run a shared failover service
On 28.11.2011 21:26, Lars Ellenberg wrote:
On Fri, Nov 25, 2011 at 09:11:39PM +0100, Andreas Hofmeister wrote:
On 25.11.2011 17:08, John Lauro wrote:
@list: did anybody try such a thing ?
"dual-primary" iscsi targets for multipath: does not work.
iSCSI is a stateful protocol
On 29.11.2011 21:17, Florian Haas wrote:
On Mon, Nov 28, 2011 at 9:26 PM, Lars Ellenberg
As this sort of issue currently pops up on IRC every other day, I've
just posted this rant:
http://fghaas.wordpress.com/2011/11/29/dual-primary-drbd-iscsi-and-multipath-dont-do-that/
Yes Florian, I did
On 30.11.2011 00:15, John Lauro wrote:
The problem is that part of iSCSI is a client saying, I want exclusive
access to a certain block(s), and then no other client can access that
block.
Yes, that reservation stuff is something a cluster aware iSCSI target
would have to synchronize among the
On 30.11.2011 02:08, John Lauro wrote:
Andreas, what happens if you block your two nodes from talking directly
to each other, but allow the client to talk to both?
Mhh, it basically depends what exactly happens when the split occours.
If the writes on both nodes would succeed, the client wou
Hi all,
We use drbd 8.3.11 as a dual-primary in a pacemaker (1.0.x) cluster.
In our setup, we need a somewhat larger ping-timeout (2s) due to
interruptions during a firewall restart. That used to work well with
8.3.10 but caused crm resource stop/start sequences to fail since 8.3.11.
A git b
Hi,
We have drbd 8.3.11 or 8.3.13 dual-primary on a pacemaker cluster
running on kernel 3.0.41.
The cluster just does its work, nothing is stopped or started and then,
after a week or so, we get a drbsetup locking-up (associated with below
kernel trace) when we want to administer a resource
15 matches
Mail list logo
