2 node cluster with SLES12 SP1. No resources added at this point, fresh cluster that is online. We have an existing apache 2.4.x webserver on a cluster node. It has a number of websites, php, SSL and reverse proxy. The other node of the cluster has apache installed along with the php modules. Hawk is up and running so we can use that if needed to add the existing apache resource. My question is, how exactly do i add the existing apache resource to the cluster?
Hi carnold6,
https://www.suse.com/documentation/sle-ha-12/singlehtml/book_sleha/book_sleha.html#sec.ha.config.hawk.wizard shows that the Hawk wizard has support for setting up a web server resource - I’ve never used this wizard, but you might ha ve a look and see if it helps.
You description seems to imply that you want to have the web server being able to run on both nodes (alternatively) - how will you replicate the configuration and site data, and in case the wizard does not take care of this, how do you intend to make the server(s) reachable? (Two approaches to this: move a dedicated web server IP along with the active httpd resource, or use an external balancer. In both such scenarios, it might be easier to just run web server instances on both nodes in parallel and just have the requests hit either one - via that moving IP address or a load balancer).
Oh, and how will you handle split-brain situations? A two-node cluster may be the most common setup, but it is the most problematic as well…
Regards,
Jens
[QUOTE=jmozdzen;31537]Hi carnold6,
https://www.suse.com/documentation/sle-ha-12/singlehtml/book_sleha/book_sleha.html#sec.ha.config.hawk.wizard shows that the Hawk wizard has support for setting up a web server resource - I’ve never used this wizard, but you might ha ve a look and see if it helps.[/quote]
Thanks for your reply jmozden! Thats one resource i am attempting to follow. However, we seem to hawk2 running and therefore some things are different (1 main thing that may not be do to different versions, there are no templates listed). Another thing i am not sure about is, we have an existing apache webserver on a node and this is the webserver we need highly available. So i am guessing that i need to create the resource on that server?
[quote]You description seems to imply that you want to have the web server being able to run on both nodes (alternatively) - how will you replicate the configuration and site data, and in case the wizard does not take care of this, how do you intend to make the server(s) reachable? (Two approaches to this: move a dedicated web server IP along with the active httpd resource, or use an external balancer. In both such scenarios, it might be easier to just run web server instances on both nodes in parallel and just have the requests hit either one - via that moving IP address or a load balancer).
Oh, and how will you handle split-brain situations? A two-node cluster may be the most common setup, but it is the most problematic as well…[/QUOTE]
My description must have been misleading… We only want to have some existing resources highly available. I think this is a basic kinda setup. 1 server goes down, we want the resource to continue running
So i tried to create a resource and get the following error:
I get the same error with hawk. STONITH is enabled
I’m not sure if i am on the right path here. So we do NOT have shared storage so i disabled STONITH (i know support for non-STONITH cluster does not exist). We just want the existing apache webserver to be highly available. Do we need shared storage for this to work? When creating the apache resource on the cluster, how to do tell the cluster to use the existing apache webserver?
Hi carnold6,
We just want the existing apache webserver to be highly available.
let me begin with saying that “high availability” probably is more than you’re currently reading into it. Much more. You need to design that.
So in case of your web server, I see the following approach (as one of many possible) to the design:
-
what is HA to you? Reduced downtime? How much “reduced”?
-
either way, you’ll need to provide the service with some redundancy. IOW, you need more than a single server (httpd) and you need a reliable way to distribute requests to those servers, i.e. in some “cold/hot standby” fashion.
-
assuming “hot standby”, you can just run multiple httpd servers (on multiple machines) - this per se does not require Pacemaker, but other parts will (see below).
-
concerning your redundant httpds, you’ll need to make sure that each instance is monitored (IOW you notice when it goes down and cannot be restarted), and you need to make sure each instance serves identical updates.
** If you try to solve “serves the same content” with “shared storage”… how do you handle that storage going away… or becoming corrupt? Or inconsistent during copying new content? That’s when your HA server is gone, despite redundant httpds
** If you keep copies of the “content” on each server: how consistent does this need to be? You’ll need an update process: I.e. update the content on the standby server(s) first, then fail-over your active server (so requests go to an updated server) and then apply the updates to that formerly active server. -
You’ll need some form of request distribution - IOW make requests go to an active instance. How about “state” - do you run into trouble if part of the requests go to a different server, for example because the httpds need to track login sessions? You’ll have to handle that.
-
request distribution in its simplest form works by assigning the target IP address to only one machine running httpd. The other instances simply won’t get any request. So the resource you need to make “HA” is the IP address. A different approach is to run a load balancer or i.e. ipvs, which will distribute the requests to the available servers… you can read up on this on the net. An external request distributer will again need to be “HA”, to avoid a new single point of failure.
-
things will get more complicated if you’re aiming for active/active clustering, because you then require request distribution.
-
HA means to incorporate all parts of the infrastructure: Is the network access path to your httpds somehow redundant? Having HA servers behind a single switch is… funny. Running httpds with CMS against a single, non-HA database is equally “funny”. And so on.
Concerning STONITH / “no shared storage”: If you’re working with moving IPs (the “server IP” is on the node running the serving httpd), then you can run into trouble alike: In case of a split brain, both nodes may become primary and activate the same server IP address at the same time, which will likely get you into trouble. IOW: Always look at all resources and ask yourself: what will happen if both nodes feel like being the only active one and start all resources, so you end up with some or every resource running twice?
Running with STONITH in a two-node cluster can be equally hazardous… STONITH war (both nodes killing each other) is a likely possibility.
Don’t get me wrong, getting a “more available httpd” up & running is not that dramatic using HAE - but you’re not doing HA, you’ve only started the first minor steps in that direction.
how to do tell the cluster to use the existing apache webserver?
By using the proper resource agent, which will start your existing Apache web server. Actually, Pacemaker is mostly doing that: Starting and stopping existing services for you. No magic involved.
Best regards,
Jens
[QUOTE=jmozdzen;31543]Hi carnold6,
We just want the existing apache webserver to be highly available.
let me begin with saying that “high availability” probably is more than you’re currently reading into it. Much more. You need to design that.
So in case of your web server, I see the following approach (as one of many possible) to the design:
- what is HA to you? Reduced downtime? How much “reduced”?[/quote]
Yes, when 1 server either goes down for whatever reason, the other node(s) serve the content
[quote]- either way, you’ll need to provide the service with some redundancy. IOW, you need more than a single server (httpd) and you need a reliable way to distribute requests to those servers, i.e. in some “cold/hot standby” fashion.
- assuming “hot standby”, you can just run multiple httpd servers (on multiple machines) - this per se does not require Pacemaker, but other parts will (see below).[/quote]
We do have 2 servers both with apache. I have copied the existing config to the new server along with the websites
[quote]- concerning your redundant httpds, you’ll need to make sure that each instance is monitored (IOW you notice when it goes down and cannot be restarted), and you need to make sure each instance serves identical updates.
** If you try to solve “serves the same content” with “shared storage”… how do you handle that storage going away… or becoming corrupt? Or inconsistent during copying new content? That’s when your HA server is gone, despite redundant httpds[/quote]
We are not using shared storage at the moment
This is the exact setup we are looking for
We dont need this
We dont need this
This is already working as we have other clusters working from that other OS
[quote]Concerning STONITH / “no shared storage”: If you’re working with moving IPs (the “server IP” is on the node running the serving httpd), then you can run into trouble alike: In case of a split brain, both nodes may become primary and activate the same server IP address at the same time, which will likely get you into trouble. IOW: Always look at all resources and ask yourself: what will happen if both nodes feel like being the only active one and start all resources, so you end up with some or every resource running twice?
Running with STONITH in a two-node cluster can be equally hazardous… STONITH war (both nodes killing each other) is a likely possibility.[/quote]
We are NOT using STONITH
Seems like it is 
If its not HA than what is it?
[quote]> how to do tell the cluster to use the existing apache webserver?
By using the proper resource agent, which will start your existing Apache web server. Actually, Pacemaker is mostly doing that: Starting and stopping existing services for you. No magic involved.[/QUOTE]
I have OCF on the apache resource now. Should that be pacemaker?
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 :D), 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.)
Regards,
Jens