[ClusterLabs] principal questions to a two-node cluster

Lentes, Bernd bernd.lentes at helmholtz-muenchen.de
Mon Apr 20 17:23:26 UTC 2015


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.

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

> 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


More information about the Users mailing list