On 04/17/2017 01:50 PM, Digimer wrote:
> That sounds like a use-case where a full HA cluster is overkill already.
> In any case, it would be a tiny fraction of installs and would be
> tangential to the 2v3+ node debate that this thread started with.
A web server with a "master/development" host:
On 04/17/2017 01:26 PM, Eric Robinson wrote:
> I'm guessing the surviving node broadcasts a gratuitous arp reply.
You have to fence one node by physically removing power at which point
you don't have a split brain anymore. In a split brain scenario: two
nodes are up, assuming they both send
On 17/04/17 02:21 PM, Dimitri Maziuk wrote:
> On 04/17/2017 01:12 PM, Ian wrote:
>>
>> No, I don't understand how it's relevant to the specific topic of avoiding
>> split-brains, either.
>
>>> Take a simple example of shared-nothing read-only cluster: all you need
>>> to know is that the daemon
> In shred-nothing cluster "split brain" means whichever MAC address
> is in ARP cache of the border router is the one that gets the traffic.
> How does the existing code figure this one out?
I'm guessing the surviving node broadcasts a gratuitous arp reply.
--
Eric Robinson
> This isn't the first time this has come up, so I decided
> to elaborate on this email by writing an article on the topic.
> It's a first-draft so there are likely spelling/grammar
> mistakes. However, the body is done.
> https://www.alteeve.com/w/The_2-Node_Myth
It looks like my question
On 04/17/2017 01:12 PM, Ian wrote:
>
> No, I don't understand how it's relevant to the specific topic of avoiding
> split-brains, either.
>> Take a simple example of shared-nothing read-only cluster: all you need
>> to know is that the daemon is bound to '*' and the floating ip is bound
>> to
On 17/04/17 02:12 PM, Ian wrote:
>> maybe I need another coffee?
>
> No, I don't understand how it's relevant to the specific topic of
> avoiding split-brains, either. I suppose it's possible that I also need
> coffee.
I'm trying to make the connection still, honestly, but I am still lost...
> maybe I need another coffee?
No, I don't understand how it's relevant to the specific topic of avoiding
split-brains, either. I suppose it's possible that I also need coffee.
On Mon, Apr 17, 2017 at 1:45 PM, Dimitri Maziuk
wrote:
> On 04/17/2017 11:58 AM, Digimer
On 04/17/2017 11:58 AM, Digimer wrote:
> ... Unless I am misunderstanding, your comment is related to
> serviceability of clusters in general. I'm failing to link the contexts.
> Similarly, I'm not sure how this relates to "new" vs. "best"...
You can't know if *a* customer can access the
On 04/17/2017 11:03 AM, Digimer wrote:
> On 17/04/17 11:15 AM, Dmitri Maziuk wrote:
>> What you want to know is whether the customer can access the service.
>> Adding more nodes does not answer that question, but since Andrew is
>> writing cluster software, not providing services, that's not his
On 17/04/17 11:15 AM, Dmitri Maziuk wrote:
> On 2017-04-16 15:04, Eric Robinson wrote:
>
>>> On 16/04/17 01:53 PM, Eric Robinson wrote:
I was reading in "Clusters from Scratch" where Beekhof states, "Some
>>> would argue that two-node clusters are always pointless, but that is an
>>>
On 04/13/2017 01:11 PM, Scott Greenlese wrote:
> Hi,
>
> I need to remove some nodes from my existing pacemaker cluster which are
> currently unbootable / unreachable.
>
> Referenced
>
On 04/13/2017 11:11 AM, Ferenc Wágner wrote:
> Hi,
>
> I encountered several (old) statements on various forums along the lines
> of: "the CIB is not a transactional database and shouldn't be used as
> one" or "resource parameters should only uniquely identify a resource,
> not configure it" and
On 2017-04-16 15:04, Eric Robinson wrote:
On 16/04/17 01:53 PM, Eric Robinson wrote:
I was reading in "Clusters from Scratch" where Beekhof states, "Some
would argue that two-node clusters are always pointless, but that is an
argument for another time."
What you want to know is whether the
On 04/13/2017 10:40 AM, Radoslaw Garbacz wrote:
> Hi,
>
> I have a question regarding building CIB nodes scope and specifically
> assignment to node IDs.
> It seems like the preexisting scope is not honored and nodes can get
> replaced based on check-in order.
>
> I pre-create the nodes scope
On 04/13/2017 03:01 AM, Jaco van Niekerk wrote:
>
> Hi
>
> I am having endless problems with ocf::heartbeat:VirtualDomain when
> failing over to second node. The virtualdomain goes into a stopped state
>
> virtdom_compact (ocf::heartbeat:VirtualDomain): Stopped
>
> * virtdom_compact_start_0 on
16 matches
Mail list logo