Ignore this, I re-sent to ClusterLabs.
On 20/04/15 09:36 AM, Digimer wrote:
> On 20/04/15 08:29 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. 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. 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?
_______________________________________________
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org
