> Well, one machine is enough most of the time. > It only slows down > sometimes, due to high trafic. That's why this cluster would be fine > enough, letting us enough time to restart the failling machine. > > Is this configuration still possible ?
Sure. There's several possible ways you could try handling this. * if the load for the web server is similar to the load created by the database server, things are easy: you split your resources between the two nodes, i.e you run your db server on one node and the web server on the other node in normal setup and run both on the same node in case of failover. You could use heartbeat as the cluster manager. To allow failover of database and web server you'll need to make sure that identical filesystem content is available on both nodes; again several options: - shared scsi or fc storage, active node mounts the volume. - drbd (storage replicated over network, somewhat similar raid1); operates at the block device level so works just fine with all kindes of databases (mysql/postgres/oracle...) - for a webserver with infrequent changes rsync might be an option. I generally uses heartbeat+ drbd for this kind of setup, with webserver content on one drbd volumne and database on another volume (for independant failover). * if most on your load is on the webserver: Run webserver on both nodes, and have the database server + loadbalancer as a high availability servive. Again you can use heartbeat with the "ldirectord" resource that controls/manages load balancing via LVS / ipvsadm. You could put in a weighting factor for the load balancer to put fewer requests on the machine that also runs the database server. Hope this gives you some ideas on how you might continue. Bye, Martin -- [email protected] mailing list
