Along the way, I've learned some interesting info that might help others looking at this option.
What You Get
A set of 4 IP addresses for each server, and a shared set of 4 IP addresses that support load balancing and failover on ports 21 (FTP), 80 (http), and 443 (HTTPS, aka SSL). The load balancer will automatically direct incoming traffic between the two servers, and do all the network translation correctly (so your web logs don't get messed up). If one of the servers goes down, all requests go to the remaining server.
If you are serving static HTML, files or images, load balnacing and failover is easy. Just keep synchronized copies of each site on both servers.
If you have scripted applications using PHP or Perl that use a database, or allow users to upload files to the server, things will get more complicated. There are a couple of solutions:
Load Balancing with MySQL (but no fail-over)
Install all your databases on server A. Configure applications on server A to use the local machine. Configure server B with the same applications, but tell them to use the database on server A (instead of locally). You should use the private network for this purpose.
Pros: For CPU intensive applications, you will have two servers to cut through the code, and configuration is a snap. More powerful, responsive, and reliable than a single server.
Cons: If the server running the database goes down, then the application will probably fail. In this case you should have defined a default 404 page so those database errors won't look embarrasing.
Load Balancing with MySQL (and fail-over)
You can configure each database on each server in replication mode -- one server is the 'master' and the other is the 'slave'. The two servers replicate over the local private network. Your applications will only be able to write to the master server, but can read from either server. Most off-the-shelf applications will not work this way, you will just have to tell them to use the master server.
You could also have a failover monitoring script that can change the master database on the fly. For more information about all this madness, you might want to read about MySQL Replication, or just find a smart db tech to help you set it up right.
Pros: Truly redundant and fail-safe for database applications. When was the last time you got such high-level IT infrastructure at this price?
Cons: Tricky to set up, applications may need to be customized.
Load Balancing Filesystems (with fail-over)
If you need to keep two servers in a mirrored set-up, you might consider using rsync (which is built into RedHat) or Unison. Since you have a private network, you can keep things syncing often, either through a cron job, or just as a script the repeats forever, sleeping a bit between runs. You could also cross-mount drives between servers (over the private network), so you could share data that way.
Pros: Easy to set up and effective sharing of resources
Cons: Rsync is really just master/slave, you will need something like Unison to do two-way file replication and keep things in sync.
Conclusions
Even if you choose not to use load-balancing and fail-over features, you can benefit from having two server connected by a private network. It makes backups easy, and is a perfect solution for developers that need a production / testing environment that are identical.
EV1 has indicated that they can have some configuration changes they can make that will fix some of the more common sharing issues (like a potential PHP shopping-cart problem: php sessions are written to disk, but the user jumps to the other server while in HTTPS secure mode, and gets logged out).
Unanswered Questions
I'm still working though the details and options, and running into questions as I go along. The possiblities are really endless.
For starters, I'd like to see some of these issues addressed in the documentation and product information areas --
- The second-level server package says '1400 GB Monthly Transfer per server', but after signing up, I see 700GB/month as the limit for each server.
- There are two 80GB hard drives in each server (for the 2nd and 3rd level packages). Would it be possible to run these drives in mirrored RAID-0 configuration? This could be done with software, but it would most certainly require use of the KVM switch rental to manage the reboots and reinstalls. And what about the RedHat enterpise CD
- The remote console service over SSH is cool, but what good is it for? I tried rebooting my server while I was connected to the console serial port, and although I stayed connected, I could not really do anything. I guess if you need to get into single user mode, this would be very helpful. EV1 mentions system monitoring, so I guess you could have stats of some kind dumped to a com port and collected remotely?
- How does the RedHat's update service work and for how long? Will I have to pay $349 per server/per year for access to the RedHat services past the first year? What (if any) RedHat support or access is included with Enterprise ES?
- How well do the control panel apps (like Ensim and Plesk) really deal with these types of configurations? What other types of tools come with RedHat Enterprise to help with managing the cluster?
- How do the Urchin licenses work with clusters? One per server?
Overall, this is a unique service that I'm looking forward to working with. I've dealt with dual-server setups before (usually co-location custom configs), but never as dedicated rentals, and never at this price! You can leave so much of the infrastructure and network issues for somebody else, it's a big value add.
Thanks, EV1!