[ClusterLabs] principal questions to a two-node cluster

[Digimer]

On 20/04/15 01:23 PM, Lentes, Bernd wrote:
> Digimer wrote:
>>
>> On 20/04/15 09:23 AM, Lentes, Bernd wrote:
>>
> 
> ...
> 
>>
>> You're trying to make your website HA, specifically?
>>
> 
> Yes. But also databases and virtual machines.
> 
>> 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.
> 
> I'm thinking about choosing #2.

It's what I do. Another benefit is that your one design can be used
everywhere, so less trouble maintaining it over time.

>> 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. If the host fails, the cluster simply reboots the server
>> on the backup, done. Being a VM, reboot times are (in my experience,
>> across many OSes) 30~90 seconds to get back to the OS login screen (plus
>> stack startup, but that is negligible for most web server stacks).
>>
>> Then you can create new servers on the same config (even OSes like MS
>> Windows) and they're magically HA as well, nothing more to do.
>>
>> If you prefer #1 though, that is OK as well. The question then becomes
>> more about your particular needs, as the setup will be customized per
>> environment. Generally speaking, you want to avoid active/active if you
>> can avoid it. The reason being that clustered file systems, by the very
>> nature of their locking needing to be coordinated and clustered, comes
>> at a performance cost.
> 
> How much is it ? 10% ? more ?

Depends entirely on the work load. The overhead is in the locking, so
the more times the cluster needs to give locks, the more it hurts
performance. So if you plan to have a small number of big files, it's
not too bad. If you plan to use a lot of small files that change often,
it's more of an issue.

>> People often think "well, I have two nodes, why
>> not double my performance?". It is sensible on the surface, until you
>> realize the complexity.
>>
>> If you can get away with it, I'd use active/passive. In this case, only one
>> node will have your LUN at a time, hosting a traditional FS ext4/xfs, and
>> the data for your HA stuff on the LUN. The node that is the current host
>> would:
>>
>> Connect the LUN -> mount the FS -> start the services -> take a
>> floating/virtual IP.
>>
>> Migrate the service is:
>>
>> Old Active; Take down the IP, stop the services -> dismount the FS ->
>> disconnect the LUN New Active; Connect the LUN -> mount the FS ->
>> start the services -> take a floating/virtual IP.
>>
>> (This is why having your service in an HA VM is better for migration; No
>> 'stop' needed, live-migration causes no interruption).
>>
>> Recovery from a crashed/failed active;
>>
>> Fence the lost node -> Connect the LUN -> mount the FS -> start the
>> services -> take a floating/virtual IP.
>>
>> To get into anything more specific, you will need to be more specific
>> about your priorities and the details of your setup.
>>
>> --
>> 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?
>>
>> _______________________________________________
>> Users mailing list: Users at clusterlabs.org
>> http://clusterlabs.org/mailman/listinfo/users
>>
>> Project Home: http://www.clusterlabs.org Getting started:
>> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>> Bugs: http://bugs.clusterlabs.org
> 
> Helmholtz Zentrum München
> Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH)
> Ingolstädter Landstr. 1
> 85764 Neuherberg
> www.helmholtz-muenchen.de
> Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe
> Geschäftsführer: Prof. Dr. Günther Wess, Dr. Nikolaus Blum, Dr. Alfons Enhsen
> Registergericht: Amtsgericht München HRB 6466
> USt-IdNr: DE 129521671
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/users
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
> 


-- 
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?