Pattern - Multihomed Server

Multi-homed applications (such as the web server) can be used to provide the appearance of many different hosts to outside callers.

Features

• Multiple DNS entries are set up to point to the same IP address, that of the single host.
• Applications recognise callers asking for a specific 'machine', either in the protocol or by the TCP port used.

Advantages

• Saves on IP addresses.
• Ideal way for very-low-load services, such as parked web servers.
• Can change DNS entries to redirect work to different machines in future.
• Lower hardware cost than fully virtualized machines.
• Significantly lower management costs than for than fully virtualized machines, because there is only one OS/Application server to maintain.

Disadvantages

• Underlying Protocol needs to be multihome-enabled. HTTP 1.1 is (the full URL is sent in the request, including hostname). Other, existing protocols may not be so well designed.
• Client programs that use IP Addr for some of their logic (storing in hash tables, uniquely differentiating remote systems, etc.) break. You cannot assume that different remote servers have different IP addresses.
• Servers are more vulnerable to DDOS attacks; any attack on one address will take down them all; you can't edit upstream router settings to drop all packets to a specific IP address, and while changing DNS entries does help, it can take a long time for the change to propagate.
• Enumeration of the DNS address space can identify servers that route to the same system. This is a potential security risk.
• Every application running on the server has to have exactly the same underlying OS configuration as all the others; the same versions of every application on the path. This makes it more brittle than virtualized solutions.
• Vulnerable to security exploits. If any account holder in a multi-homed web server has an remotely exploitable security hole, and that exploit can be used to gain root access, your site/machine is owned, even if you keep your machine secure.
• No easy way to throttle bandwidth/CPU load across hostnames, unless per-user quotas are built into the OS.
• Reverse DNS lookup doesn't always pick the correct hostname. This confused SPF records, amongst other things.
• If the IP address is blacklisted by a remote site (for spam or other security issues), everyone on the site is blacklisted.

Multi-homing is invaluable for very low-cost hosting of web sites. Many of the low-cost ISPs still host this way, because it is more affordable than virtual machine hosting, as do any of the blog-hosting sites that give every blog a separate hostname. It may not offer the ability to customise the machine, but for many users, that is not what they want.

Multi-homing has also been used for reducing Application As A Service costs, where an ASP is trying to offer a service -such as an outsourced Microsoft Exchange server or an SAP system. Trying to do this pre-virtualisation was always hard, as the underlying protocols -Exchange uses a binary RPC protocol- were not multi-homing friendly. Virtualization makes such complex installations much easier to host.

SmartFrog support

We can configure Apache httpd to work in multihomed mode; the [sf-dns] package can configure bind.

Multi-homing is currently a bit out of fashion as virtual machines appear to offer superior flexibility. Which they do, at a price. That price is every indepent VM image needs to be maintained, to be configured and kept up to date. Unless automation tools are used to do so, Virtualisation management costs can be very steep.

SmartFrog itself is not multihomed, because Java RMI is not multi-homed. To run multiple versions of SmartFrog on the same host, one needs to configure SmartFrog to listen on a different port. Once this is done. a different daemon with a completely different login and security settings can be brought up.