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/sunmanagersReceived 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