Summary: Where to install Apache for HA Apache

From: Ivan Fetch <ifetch_at_du.edu>
Date: Thu Jun 22 2006 - 12:27:35 EDT
Hello Sun managers,


    I received three responses, which I'll include below.  Thanks to all 
for getting back with me.

    We have chosen to install packages on each node, and have Apache 
configs and web data live on shared storage.




(In email addresses below, I've transposed period and at signs)


    Karl Vogel <vogelke.pobox@com> wrote:

I> 4. Compile Apache2 and it's dependencies (how many of it's dependencies,
I> even OpenSSL?) from source and have everything live in global storage.
I> Upgrading will involve recompilation of one or more things from source -
I> this deviates from our goal of having everything maintained as a
I> package.

    I'd vote for compiling from source, because you have complete control
    over what goes in and what stays out.  You can create your own package
    by following the directions below:

    http://www.ibiblio.org/pub/solaris/sparc/html/creating.solaris.packages.html



    Dana Hudes <hudesd.hra@nyc@gov> wrote:

- I recommend separate application binaries. You have to have shared
storage.
- configuration counts as data and belongs in shared storage. Yes you
have to have everything on the same path this way
- just because you build from source doesn't mean you can't build a
package
-  If you want optimal performance you should rebuild whatever is in the
loop that you have performance concerns. You should do so with the Sun
Studio 11 compiler or the Cool Tools gcc for SPARC
(http://cooltools.sunsource.net/gcc/). It is up to you to decide 32 vs.
64 bit application build based on your needs but you should certainly
target your specific CPU to take advantage of its features.



    Our Sean Kennedy <skenne26.du@edu> wrote:

Here's what I usually recommend.

Install Apache locally on each box, and have the conf files point to /httpd
htdocs.
o /httpd is a failover service.  If you want apache scalable, the
interconnects need to be planned for appropriately.
o This allows for rolling apache upgrades without any 100% cluster outage.
o Apache binaries and conf files are organized well so mis-configuration
issues minimized.
o This is more painful for global changes - Each node needs to have the
confs copied and consistent.
o Don't use the OS Installed version of Apache.





    My initial question was:

Date: Fri, 9 Jun 2006 14:52:33 -0600 (MDT)
From: Ivan Fetch <ifetch@du.edu>
To: sunmanagers@sunmanagers.org
Subject: Where to install Apache for HA Apache

Hello,


    We are building a cluster with HA Apache - I'm looking at this article:

http://docs.sun.com/app/docs/doc/817-6998?a=expand


    The clusters we currently have (Iplanet Messaging Server, Oracle) have the 
application software located on global storage, instead of being installed on 
each node.  We're discussing pros and cons of doing this with Apache, andI'd 
like to hear from this list as to how others install and maintain their HA 
Apache cluster nodes.


    Here are some of the things that folks in our group are tossing around:

    1. Go with the Apache that comes with Solaris 9, and cluster it.

    2. Install Sunfreeware, Blastwave, Etc Apache2 (we'd prefer to have Apache2) 
packages on each node.  When upgrading, we'll need to upgrade the application 
the same way, on each node.  This could be nice when we want to test a new 
version of something on one node, and have the option of failing back to the 
other node if things go particularly badly.  On the other hand, we sometimes 
have trouble keeping things standardized, and we'd like each node to run the 
identical binaries and configs 99% of the time.

    3. Same as #2 above, except that we try relocating the packages' files to 
global storage, instead of say /usr/local or /opt/csw, Etc.  The package will 
be installed technically on one node (E.G. package database), but the other 
node will be able to see everything from global storage.  Upgrading the 
packages would really only be possible from the node they were installed on; if 
that node were down, upgrading would be difficult because the other node would 
not have these packages in it's package DB.

    4. Compile Apache2 and it's dependencies (how many of it's dependencies, 
even OpenSSL?) from source and have everything live in global storage. 
Upgrading will involve recompilation of one or more things from source - this 
deviates from our goal of having everything maintained as a package.


Thanks for your thoughts,

Ivan Fetch.
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
Received on Thu Jun 22 12:35:45 2006

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:59 EST