PUBLIC MARKS with tags cluster & web

Quand un site web dynamique commence à avoir un trafic important, généralement on va essayer de multiplier les serveurs web qui hébergent les fichiers. Multiplier les serveurs web n’est pas le plus difficile, il suffit de faire une réplication des données à chaque mise à jour de votre site et de multiplier les sous-domaines. Les choses se compliquent lorsque vous souhaitez avoir plusieurs serveurs de base de données. La base de données que nous étudierons ici est MySQL. Nous ne parlerons pas de cluster MySQL dans cet article. Le but de l’article est de montrer comment séparer un serveur MySQL en trois serveurs distincts : 1 maitre et deux esclaves, avec un seul point d’entrée (le proxy MySQL). Le proxy devra envoyer les requêtes de lecture vers les serveurs esclaves et toutes les autres requêtes vers le serveur d’écriture.

This tutorial shows how to set up a two-node Apache web server cluster that provides high-availability. In front of the Apache cluster we create a load balancer that splits up incoming requests between the two Apache nodes. Because we do not want the load balancer to become another "Single Point Of Failure", we must provide high-availability for the load balancer, too. Therefore our load balancer will in fact consist out of two load balancer nodes that monitor each other using heartbeat, and if one load balancer fails, the other takes over silently.

how to set up a two-node Apache web server cluster that provides high-availability. In front of the Apache cluster we create a load balancer that splits up incoming requests between the two Apache nodes. Because we do not want the load balancer to become another "Single Point Of Failure", we must provide high-availability for the load balancer, too. Therefore our load balancer will in fact consist out of two load balancer nodes that monitor each other using heartbeat, and if one load balancer fails, the other takes over silently.

We have implemented a 2-node HA Xen cluster, which consists of two physical machines (hosts,) and runs several virtual servers (guests) each, for our company's internal services (mail, web applications, development, etc.) When one host gets down unexpectedly, the other host physically kills it (STONITH - power down or reset) and then takes over all the guests the failed host was running. When we want to shutdown a host machine for maintenance (to replace a fan, add disk or memory, etc.), we just type the usual shutdown command, and the guests are automatically live-migrated to the other host. Since the guest servers keep running throughout the migration process, except for the less than a second pause, users would never even notice the event.

Failover clusters are used to ensure high availability of system services and applications even through crashes, hardware failures, and environmental mishaps. In this article, I'll show you how to implement a rock-solid two-node high availability Apache cluster with the heartbeat application from The High-Availability Linux Project. I tested the cluster on Fedora Core 5, CentOS 4.3, and Ubuntu 6.06.1 LTS server distributions.

This tutorial shows how to set up a two-node Apache web server cluster that provides high-availability. In front of the Apache cluster we create a load balancer that splits up incoming requests between the two Apache nodes. Because we do not want the load balancer to become another "Single Point Of Failure", we must provide high-availability for the load balancer, too. Therefore our load balancer will in fact consist out of two load balancer nodes that monitor each other using heartbeat, and if one load balancer fails, the other takes over silently