[Pacemaker] principal questions to a two-node cluster - Reply on ClusterLabs, not here (my bad)

[Digimer]

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?