Don't worry about this question. I've already found the answer in google ...
16.07.2012 8:31, Andrew Beekhof пишет:
On Fri, Jul 13, 2012 at 6:19 PM, Виталий Давудов
vitaliy.davu...@vts24.ru wrote:
Hi!
Some time ago I upgraded my cluster installation: migrate pacemaker from
1.0.12 to 1.1.5
It is not.
Pacemaker may just be quicker to promote now,
or in your setup other things may have changed
which also changed the timing behaviour.
But what you are trying to do has always been broken,
and will always be broken.
Hello Lars,
You were right, fixing configuration indeed
I'm designing a cluster to run both iSCSI targets and initiators to
ultimately provide block devices to virtual machines. I'm considering
the case of a target failure, and how to handle that as gracefully as
possible. Ideally, IO may be paused until the target recovers, but VMs
do not restart
On 07/16/2012 01:14 PM, Digimer wrote:
On 07/16/2012 12:08 PM, Phil Frost wrote:
I'm designing a cluster to run both iSCSI targets and initiators to
ultimately provide block devices to virtual machines. I'm considering
the case of a target failure, and how to handle that as gracefully as
On 07/16/2012 12:08 PM, Phil Frost wrote:
I'm designing a cluster to run both iSCSI targets and initiators to
ultimately provide block devices to virtual machines. I'm considering
the case of a target failure, and how to handle that as gracefully as
possible. Ideally, IO may be paused until
On 07/16/2012 01:14 PM, Digimer wrote:
I've only tested this a little, so please take it as a general
suggestion rather than strong advice.
I created a two-node cluster, using red hat's high-availability add-on,
using DRBD to keep the data replicated between the two SAN nodes and
tgtd to export
Hello,
The last couple of months I've been busy on setting up highly available iSCSI
targets and using the iSCSI luns in a KVM virtualisation cluster.
The iSCSI targets are setup using pacemaker, drbd, stgt and CentOS 6.
Unfortunately I have not had the time to compile and test LIO
On 07/16/2012 01:34 PM, Phil Frost wrote:
I've been doing some study of the iscsi RA since my first post, and it
seems to me now that the failure in the monitor action isn't
actually in the monitor action at all. Rather, it appears that for
*all* actions, the RA does a discovery step, and
