I don't get it. Pacemaker + Corosync is providing me so much of
functionality.
For e.g. if we leave out the condition of split-brain for a while, then it
provides:
1) Discovery and cluster formation
2) Synchronization of data
3) Heartbeat mechanism
4) Swift failover of the resource
5) Guarantee
Hmm. I will then work towards bringing this in. Thanks for your input.
On Wed, Jun 22, 2016 at 10:44 AM, Digimer wrote:
> On 22/06/16 01:07 AM, Nikhil Utane wrote:
> > I don't get it. Pacemaker + Corosync is providing me so much of
> > functionality.
> > For e.g. if we leave
On 22/06/16 01:09 AM, Nikhil Utane wrote:
> We are not using virtual IP. There is a separate discovery mechanism
> between the server and client. The client will reach out to new server
> only if it is incommunicado with the old one.
That's fine, but it really doesn't change anything. Whether
On 2016-06-20 17:19, Digimer wrote:
Nikhil indicated that they could switch where traffic went up-stream
without issue, if I understood properly.
They have some interesting setup, but that notwithstanding: if split
brain happens some clients will connect to "old master" and some: to
"new
On 06/17/2016 07:05 AM, Vladislav Bogdanov wrote:
> 03.05.2016 01:14, Ken Gaillot wrote:
>> On 04/19/2016 10:47 AM, Vladislav Bogdanov wrote:
>>> Hi,
>>>
>>> Just found an issue with node is silently unfenced.
>>>
>>> That is quite large setup (2 cluster nodes and 8 remote ones) with
>>> a plenty
On 21/06/16 12:19 PM, Ken Gaillot wrote:
> On 06/17/2016 07:05 AM, Vladislav Bogdanov wrote:
>> 03.05.2016 01:14, Ken Gaillot wrote:
>>> On 04/19/2016 10:47 AM, Vladislav Bogdanov wrote:
Hi,
Just found an issue with node is silently unfenced.
That is quite large setup (2
On 21/06/16 10:57 AM, Dmitri Maziuk wrote:
> On 2016-06-20 17:19, Digimer wrote:
>
>> Nikhil indicated that they could switch where traffic went up-stream
>> without issue, if I understood properly.
>
> They have some interesting setup, but that notwithstanding: if split
> brain happens some
On 06/21/2016 11:47 AM, Digimer wrote:
> If you don't need to coordinate services/access, you don't need HA.
>
> If you do need to coordinate services/access, you need fencing.
So what you're saying is we *cannot* run a pacemaker cluster without a
tiebreaker node *and* a network-controlled
21.06.2016 20:05, Dimitri Maziuk пишет:
> On 06/21/2016 11:47 AM, Digimer wrote:
>
>> If you don't need to coordinate services/access, you don't need HA.
>>
>> If you do need to coordinate services/access, you need fencing.
>
> So what you're saying is we *cannot* run a pacemaker cluster without
On 06/20/2016 11:33 PM, Nikhil Utane wrote:
> Let me give the full picture about our solution. It will then make it
> easy to have the discussion.
>
> We are looking at providing N + 1 Redundancy to our application servers,
> i.e. 1 standby for upto N active (currently N<=5). Each server will
On 21/06/16 01:27 PM, Dimitri Maziuk wrote:
> On 06/21/2016 12:13 PM, Andrei Borzenkov wrote:
>
>> You should not run pacemaker without some sort of fencing. This need not
>> be network-controlled power socket (and tiebreaker is not directly
>> related to fencing).
>
> Yes it can be
ClusterLabs is proud to announce the latest release of the Pacemaker
cluster resource manager, version 1.1.15. The source code is available at:
https://github.com/ClusterLabs/pacemaker/releases/tag/Pacemaker-1.1.15
The most significant enhancements since version 1.1.14 are:
* A new "alerts"
12 matches
Mail list logo