On 24/06/14 16:47, Digimer wrote:
On 24/06/14 03:55 AM, Christine Caulfield wrote:
On 23/06/14 15:49, Digimer wrote:
Hi Kostya,
I'm having a little trouble understanding your question, sorry.
On boot, the node will not start anything, so after booting it, you
log in, check that it can t
Digimer,
Yes, wait_for_all is a part of votequorum in Corosync v2.
Thank you,
Kostya
On Tue, Jun 24, 2014 at 6:47 PM, Digimer wrote:
> On 24/06/14 03:55 AM, Christine Caulfield wrote:
>
>> On 23/06/14 15:49, Digimer wrote:
>>
>>> Hi Kostya,
>>>
>>>I'm having a little trouble understanding
On 24/06/14 03:55 AM, Christine Caulfield wrote:
On 23/06/14 15:49, Digimer wrote:
Hi Kostya,
I'm having a little trouble understanding your question, sorry.
On boot, the node will not start anything, so after booting it, you
log in, check that it can talk to the peer node (a simple ping
Chrissie,
I don't wont to reinvent a quorum disk =)
I know about its complexity.
That's why I think that the most reasonable decision for me is to wait till
Corosync 2 gets quorum disk :)
But meanwhile I need to deal somehow with my situation.
So, the possible solution for me is creating a daemon,
On 24/06/14 09:36, Kostiantyn Ponomarenko wrote:
Hi Chrissie,
But wait_for_all doesn't help when there is no connection between the nodes.
Because in case I need to reboot the remaining working node I won't get
working cluster after that - both nodes will be waiting connection
between them.
That
On 24/06/14 09:36, Kostiantyn Ponomarenko wrote:
Hi Chrissie,
But wait_for_all doesn't help when there is no connection between the nodes.
Because in case I need to reboot the remaining working node I won't get
working cluster after that - both nodes will be waiting connection
between them.
That
Hi Chrissie,
But wait_for_all doesn't help when there is no connection between the nodes.
Because in case I need to reboot the remaining working node I won't get
working cluster after that - both nodes will be waiting connection between
them.
That's why I am looking for the solution which could he
On 23/06/14 15:49, Digimer wrote:
Hi Kostya,
I'm having a little trouble understanding your question, sorry.
On boot, the node will not start anything, so after booting it, you
log in, check that it can talk to the peer node (a simple ping is
generally enough), then start the cluster. It
On 23/06/14 12:50 PM, Kostiantyn Ponomarenko wrote:
Digimer,
I am using Debian as OS and Corosync + Pacemaker as cluster stack.
I understand your suggestion.
I don't have any questions about it.
My main question is how to do it automatically?
So that it could work without human interruption for
Digimer,
I am using Debian as OS and Corosync + Pacemaker as cluster stack.
I understand your suggestion.
I don't have any questions about it.
My main question is how to do it automatically?
So that it could work without human interruption for a while (nodes could
be rebooted, but not repaired).
Hi Kostya,
I'm having a little trouble understanding your question, sorry.
On boot, the node will not start anything, so after booting it, you
log in, check that it can talk to the peer node (a simple ping is
generally enough), then start the cluster. It will join the peer's
existing clus
Hi Digimer,
Suppose I disabled to cluster on start up, but what about remaining node,
if I need to reboot it?
So, even in case of connection lost between these two nodes I need to have
one node working and providing resources.
How did you solve this situation?
Should it be a separate daemon which
On 23/06/14 09:11 AM, Kostiantyn Ponomarenko wrote:
Hi guys,
I want to gather all possible configuration variants for 2-node cluster,
because it has a lot of pitfalls and there are not a lot of information
across the internet about it. And also I have some questions about
configurations and their
13 matches
Mail list logo
