Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Tue, Jan 25, 2011 at 12:27:51PM -0700, Nick Couchman wrote:
> > These steps may or may not work, I hope DRBD isn't smarter than is good
> > for itself ;-)
> >
> > ip addr add 10.213.0.1/30 dev eth1
> > ip addr add 10.213.0.2/30 dev eth1
> > echo -e '10.213.0.1\tselfA' >> /etc/hosts
> > echo -e '10.213.0.2\tselfB' >> /etc/hosts
> >
> > Then use selfA and selfB as peers in your DRBD configuration.
> >
> > All of this is untested, but I hope you get the general idea. Yes, the
> > addresses are arbitrary.
> >
> > HTH,
> > Felix
>
> I will give this a shot. Some initial tests I did late last week,
> however, showed that DRBD expects one of the peers in the config file
> for a resource to be the actual hostname of the machine that it's
> running on. But maybe I can trick it into working...
No. To actually pull this off, you'd need to do it with two resources,
simply use two resource sections, both using the local hostname (what
uname -n reports), and some "non-existant-peer" hostname, then connect
those to each other.
I really doubt that this would be useful, though, and I'm not sure about
deadlock potential due to "unexpected sharing" of e.g. memory pools.
But feel free to try.
resource to-be-used-as-primary {
on self { # (what uname -n reports)
address 127.0.0.1:8000;
disk ... # your local device here
}
on other { # arbitrary
address 127.0.0.1:8001; # only value actually used on "self"
... nonsense values
}
}
resource to-be-used-as-secondary, never to be made primary {
on self {
address 127.0.0.1:8001; # what is above in "on other"
disk ... # your iscsi device here
}
on other {
address 127.0.0.1:8000; # what is above in "on self"
... nonsense values
}
}
Regardless of what replication technology you use, you better make
absolutely sure that is the only entity ever modifying your disk images
on the iSCSI target host. Not even "read-only loop mount" that stuff,
typically even read-only mounts first replay the journal...
much less start a VM directly from those images. Or the replication
will lose track of blocks in need for resynchronisation.
In other words: if you scramble your data, don't blame technology.
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
__
please don't Cc me, but send to list -- I'm subscribed