[ClusterLabs] principal questions to a two-node cluster

[Digimer]

On 20/04/15 11:54 PM, Andrei Borzenkov wrote:
> В Mon, 20 Apr 2015 09:37:24 -0400
> Digimer <lists at alteeve.ca> пишет:
> 
>> On 20/04/15 09:23 AM, Lentes, Bernd wrote:
>>> Hi,
>>>
>>> we'd like to create a two-node cluster for our services (web, database, virtual machines). We will have two servers and a shared fiberchannel SAN. What would you do e.g. with the content of the webpages we offer ? Put them on the SAN so we don't need to synchronize them between the two nodes ? Also the database and the vm's on the SAN ? Which fs would you recommend for the SAN volumes ? OCFS2 ? Can I mount the same volume on each node contemporarily ? Or do I have to use the ocfs2 as a resource managed by pacemaker, so that the volume is only mounted if it is necessary ?
>>>
>>> Thanks for any hint.
>>>
>>>
>>> Bernd
>>
>> You're trying to make your website HA, specifically?
>>
>> Assuming so, you have two main options;
>>
>> 1. Application level HA
>> 2. Server (VM) level HA
>>
>> The benefit of #1 is that failover and recovery is usually faster, but
>> the downside is complexity. The benefits of #2 are that the HA is
>> obfuscated away from the application, migrating the service between
>> nodes is seamless/no interruption and the HA setup is portable to other
>> apps without modification. If you never plan to create another HA
>> anything, then part of the benefit of #2 goes away.
>>
>> Personally, I am a big fan of keeping things as simple as possible. By
>> making the server HA, you need to change nothing about your application
>> stack.
> 
> TBH this is oversimplification. There are often hidden dependencies on
> host name scattered around applications and nobody knows they are there
> until someone tries to move installation to another host. In the past
> sometimes it was necessary to actually change host name on failover.

Bernd is new to HA, so simplification was in order at this stage.

That said, I've run 2-node clusters backing VMs exclusively since 2008
and the current host has never been a concern. In fact, if your VM needs
to know it's host, or be reconfigured on migration, there is a
fundamental design flaw.

The _only_ use-case I've seen for needing to worry about the current
host was one where a client has a fancy dashboard and wanted to be able
to display the host. This had zero impact on function though, and was
purely informational.

> Things did become better over time, so for common cases that are
> implemented often it is probably no more an issue.

I am curious of an example where this was a concern, and when this was a
concern.

-- 
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without
access to education?