A Cluster System to Achieve Scalability and High-Availability with Low TCO

The authors describe a commercialized version of the Linux Virtual Server.
Recovery from Failure

If a component fails, the configuration files stored in the floppy can be used to restore the system. The EMS station generates two types of configuration files, an EMS backup copy and a backup copy for the EDS unit. When the EMS station fails and a replacement unit is brought in, the EMS can be easily restored with the backup floppy for the central management station.

If the master EDS fails, a replacement unit can be booted with the EDS backup copy to restore it to an appropriate state. When the EDS backup copy does not exist but the EMS backup copy does exist, a set of configuration files are generated for the EDS unit using the EMS station.

When the EPS unit fails, a replacement EPS unit may not be configured or populated with the web contents. Therefore, as it boots up, it contacts the load balancer via DHCP to obtain its IP address and necessary configuration information. If its configuration file is older than that on the EDS or is nonexistent, the appropriate configuration files are copied to the EPS via HTTP. After receiving the configuration file, the web server configures itself automatically and mounts the web contents via the Coda server. Consequently, there is no need to explicitly configure the web server or to copy the web contents.


The boot-up process consists of two phases. In the first phase, a mini OS is booted, and in the second phase, the main OS is invoked. After the mini OS is booted, it locates the main OS to invoke. The mini OS is stored in a partition of the filesystem that is different from the main OS. This two-phased approach increases the chance of stability even if the main OS gets corrupted or is not available. This boot-up applies to all the EMS, EDS and EPS units in the cluster.

In the future, if the main OS is not available or is corrupted, the mini OS will locate an appropriate version from somewhere like EMS . The mini OS can be stored in a removable Flash memory which would protect the mini OS from corruption or deletion, as the mini OS would not be stored on the same medium as the main OS.

The boot-up feature can also be used for OS upgrades. An OS upgrade would be performed via the EMS unit. It would automatically push the necessary files to the EPS units. When the OS upgrade is required on an EPS unit, the mini OS is booted. The mini OS would then receive the new OS and install it on top of the old OS, completing the OS upgrade.


The main purpose of partitioning is to divide a physical server pool into smaller logical server clusters. One physical load balancer acts as multiple logical load balancers for these logical server clusters. In other words, a given physical server cluster can be partitioned into many logical server clusters. Each logical cluster can have one or more VIPs. Furthermore, each VIP can support one or more virtual domains.

Figure 3. Partitioning to Create Multiple Logical Clusters

In the example in Figure 3, six physical servers are partitioned into three logical clusters, A, B and C. Cluster A may be assigned two VIPs, and each VIP may support five virtual domains. In this way, ten virtual domains are supported in logical cluster A. Cluster B may be assigned four VIPs, and each VIP may support three virtual domains, resulting in twelve distinct domains. The cluster C may be assigned only one VIP and may support only one domain. As seen in this example, different domain requirements can be supported with this flexible partitioning. Some domains may require a dedicated server with large space requirements, while other domains may be packed with many other domains. More servers can be added into Cluster C if the customer in Cluster C requires better performance, a practice known as "Pay as you grow". For this implementation, each web server is configured with an appropriate VIP on its loopback interface, while the eth0 interface of EDS is configured with all the VIPs used in the cluster.


A Coda client, an FTP server and an LDAP server are installed on the EMS unit for content uploading. The FTP server uses the LDAP server for authentication. When a new virtual domain is added, a Coda volume will be created in the Coda server, and a web Master account for the virtual domain will be added on both the Coda and the LDAP servers. The web Master account owns the Coda volume, and the Coda volume will be mounted as the home directory of the virtual domain on all web servers in the cluster . The administrator of the virtual domain can use the web Master account to login to the FTP server on the EMS station. Once an FTP session is authenticated, the Coda client on the EMS station will be authenticated for write access to the Coda server. Since the web Master account owns the Coda volume, the FTP session can write to the home directory of the virtual domain. Without authentication by the Coda server, each Coda client only has read-only access to the virtual domain home directory.