Hi carnold6,

thanks for putting answers to my list, even if it was more of a rethorical collection

> We are NOT using STONITH

You might run into a split-brain situation with both servers having your "service IP" active. I think this is something you should rather avoid, so try to set up some three-node solution. Even adding a "standby" HA node would help, if you cannot justify a full third node.

> If its not HA than what is it?

a "more available httpd" Or maybe "a way to automatically start/stop resources". HA is a philosophy. But as I've been in your situation before, I feel that your approach is a good start into the issue - just be prepared that the deeper you look, the more questions will glimpse back at you.

> I have OCF on the apache resource now. Should that be pacemaker?

no, that's all right - I used the term "Pacemaker" as that software part which provides the LRM (local resource manager), which in turn controls the actual resources via i.e. OCF scripts (I used the term "resource agent"). Sorry for the confusing wording!

To sum it up:

- You have two main resources in your cluster, the "web server" and the "IP address". While you could configure both to be up on a single node only (and co-located, so you're not running httpd on one and the IP on the other node ), I'd run the httpd resource cloned on all nodes simultaniously, and the IP on a single node only (obviously).

- That way, you have only one server instance actively used - later going towards load balancing would require additional components.

- I do recommend to set up stonith, and to expand the cluster in some fashion to make it more than two nodes. You can do without, I've outlined the risk in case of split-brain.

- to update web server content, you start at the node(s) that don't have the IP resource active, and in a last step migrate the IP to one of the updated nodes, so you can update the content of the last node. If you add a constraint (only activate the IP on nodes where httpd is active) you can on top stop the web server on a passive node before the actual content update - that way, even in case of the unlikely failure of the active node, the cluster won't switch the IP to a partially updated node. (If you stick with the two node setup, reconsider that a partially updated node may be better than no active node at all. But *you* have to decide on that, depending on the requirements.)