Pattern - Dedicated Server Cluster

This is the classic model of a server cluster dedicated of machines with well-known roles.

Features

• Separate machines are given separate roles: the database, the application server.
• Some machines may be shared across multiple web sites (e.g. the DNS server, the authentication server)
• Applications are written to take hostnames for the different machine roles.

Advantages

• Possible to manually configure the machines.
• Total control over the machine
• No resource conflict with other machines: if you buy a fast server, you get a fast service.
• Load balancing and redundancy can achieve high availability.

Disadvantages

• Manual configuration and management costs increase with the number of hosts.
• The applications need to be configured with the hostnames/URLs of the different machines that make up the cluster.
• There is the bootstrap problem: which order should services come up in?
• To achieve high availability, redundant servers are needed
• Resource utilization can be very low.
• Even when idling, power consumption, hardware depreciation and datacenter space rental costs keep the systems high.
• To scale up takes money and time.
• The more machines you have, the more your system management costs increase alongside the capital, hardware and datacenter costs.

With physical machines, the cost of entry into the service is high, -you need the capital to buy multiple servers-, and so the service is not cost effective with a certain minimal load. If you expect to be popular, you have to invest upfront, or be able to buy new boxes in a hurry. If a service is unpopular, its capital costs are fixed; there is no sharing across different services or easy way to repurpose the systems other than a complete rebuild and possibly network restructuring.

SmartFrog support

SmartFrog is ideal for configuring the applications running on the dedicated machines, passing down the hostnames for the different services. It can also choreograph the bootstrapping of the entire cluster, bringing up the application server after the database is live, for example.

By using SmartFrog to configure the entire cluster, it becomes possible to roll out new configurations on demand. This has a number of benefits.

1. It makes it easier to manage update/reboot cycles.
2. You can tune aspects of the system (JVM properties and the like), and roll back to previous configurations.
3. You can repurpose machines based on load/reliability.

We have also found it invaluable to use Anubis to share information between nodes in the cluster, even if the number of servers is fixed. Why? Because the number of physical machines in the cluster is actually a maximum, on a regular basis the number of actual machines is less. Anubis can be used to track the liveness of other machines in the cluster, and a way of queueing work to live systems.