I agree that for the web-tier (apache), network directors (ultramonkey, localdirector, CSM) is the best way to go.&nbsp; It requires extra hardware, but they can be really small boxes.&nbsp; These devices sit between the client and your apache servers and hold the IP bound to your DNS entry (this is the way I&#39;ve implemented them; there are other ways).&nbsp; Then it basically proxies your request to one of the web servers based on a set of rules (round-robin, load balancing, failover, content).&nbsp; In this case, each of the web servers would be running apache and would have a webroot shared with the others.&nbsp; Normally for performance it&#39;s something like an rsync&#39;d local filesystem.&nbsp; If you plan on updating the files a lot you could either design the release process to act against all of the systems at once, or used a shared filesystem.&nbsp; A shared filesystem would be something like NFS, OpenAFS, or some kind of clustered filesystem (gpfs, vxCFS, etc).<br>
<br>For the data tier (mysql), you would want to either use an HA failover cluster, or the built-in MYSQL clustering.&nbsp; My experience with the MYSQL clustering is dated, and back then it required extra hardware, so let&#39;s go with HA clustering for now.<br>
<br>You need to have an NIC cabled into the same segment (or VLAN) on each of the boxes you want to cluster.&nbsp; This NIC will hold the IP of the mysql server.&nbsp; The IP will be one of the resources that fails over with the cluster.&nbsp; You will also need shared storage.&nbsp; That&#39;s where drbd comes in.&nbsp; You could use SAN or some kind of iSCSI implementation, but that requires additional infrastructure.&nbsp; Put your MYSQL server data in its own logical volume and then mirror that volume active/passive with drbd to all of the nodes in the cluster.&nbsp; Active/passive simply means that only 1 box will use the data at once.&nbsp; The other boxes COULD access it, but won&#39;t until the cluster fails to them.&nbsp; That&#39;s where your HA cluster comes in.<br>
<br>I recommend running pacemaker with heartbeat if you&#39;re on Suse.&nbsp; For this you&#39;ll need at least 2 keepalives (I won&#39;t call them heartbeats because of the name of the app) for the cluster.&nbsp; That&#39;s normally a serial null-modem daisy chain, a dedicated ether-NIC, or a disk-ping.&nbsp; For disk ping you&#39;ll need shared storage (see drbd8).&nbsp; Or you could just use 2 ether-NIC&#39;s and hope you never turn on your firewall without any rules :)&nbsp; Add the IP from the above paragraph, the mysql init script (it&#39;ll default to using /etc/init.d/mysql if you don&#39;t give it any other options) and the shared storage (to mount up the shared storage unless you&#39;re using raw devices) to a single group.&nbsp; This group means the IP, mysql server, and active drbd will always sit on the same box (except in split-brain, see the 2 ether-NIC and firewall thing above).&nbsp; If you tweak it well enough it will even monitor itself.<br>
<br>Note*&nbsp; The mysql configs will be in /etc, normally and will not fail over, so any time you update the mysql config, you&#39;ll need to replicate that to the other nodes.&nbsp; OR you can link it to files that you are sharing in your cluster.<br>
<br>You could do the same kind of HA cluster with apache.&nbsp; You&#39;d always have 1 apache server up, but you&#39;d also only ever have 1 up :)&nbsp; Aka, you couldn&#39;t split the load over multiple machines.<br><br>Anyway, that&#39;s just my opinion.&nbsp; Linux HA has a problem with split-brain because of it&#39;s lack of decent fencing, but that (and STONITH) are another conversation.&nbsp; As is app-tier.<br clear="all">
<br>-- <br>James McPhee<br><a href="mailto:jmcphe@gmail.com">jmcphe@gmail.com</a>