Virtual Dedicated Servers (VDS’s, sometimes called Virtual Private Servers, VPS’s) are an interesting alternative to leasing a dedicated server. With a VDS, you are leasing a complete, self-contained instance of a Linux or BSD installation, potentially running on the same machine or cluster of machines as a number of other such instances. This approach should have numerous advantages. The underlying machine is often much faster, with faster disks, than the low-end dedicated servers offered by most hosting vendors. When your “neighbors” on the machine are not busy, you will have a very powerful machine at a reasonable price.
Like any other shared resource, there are some obvious downsides. If all of the other virtual servers on the machine are recompiling linux kernals or mapping the human genome, then your server’s performance will be less than stellar. (Most vendors have safegaurds in place to manage these situations.) You are also likely to have a smaller memory allocation, and probably a much smaller disk space allocation, than you would with dedicated hardware. In spite of these problems, VDS’s low setup and monthly costs make them an attractive solution for some kinds of applications.
Based on several deployments of Java applications on VDS’s, there are a few additional wrinkles to consider. Before signing up, you might be able to save a headache or two by asking the following questions:
- Does the virtualization system properly account for memory usage by multi-threaded Java applications? Under Linux, each Java thread gets mapped to a native process. The application’s memory is shared by all of threads, but in the process status (
ps) data, the total application memory appears to be associated with each thread. Depending on the sophistication of the accounting mechanism used to determine when your virtual server has reached its memory limit, the Java VM may die with anOutOfMemoryExceptionwhen it opens its second or third thread.
- How is virtual memory allocated? (Are swap files supported?) Given that VDS’s typically have relatively low memory allocations, it would often be useful to trade disk space for additional virtual memory. This is particularly true of Java applications, which often want a fair bit of memory to sprawl out in. In practice, however, most VDS systems treat your memory allocation as a hard limit, killing off processes when your allocation is exceeded. A VDS system that, for example, supported swapfile creation (and activation using the
swaponcommand) would give you a flexible way to trade disk space for virtual memory, and allow your application to simply experience degraded performance (rather than sudden death) when memory gets tight.
- How often is the virtual server likely to be restarted? In an (admittedly unscientific) survey of several deployments on VDSs, having an unexpected and unannounced restart at least every few of days is not uncommon. For many applications this will not be a problem, for others it will be.
- How is processor allocation managed and accounted? Most VDS systems have sufficiently sophisticated scheduling mechanisms such that individual virtual servers are not “starved” for CPU both other virtual servers on the same machine. If you application is processing-intensive or has specific latency requirements, the details of how cycles will be distributed will be of particular signficance. Furthermore, you may wish to know how processor load is reported within the virtual server. For example, if the aggregate load (as reported by commands such as
uptimeortop) on the underlying machine is reported, you may encounter the situation where your server can still operate at reasonable speed, but other software on which you depend will misinterpret the system state. The popular (or perhaps more acurately, “widely used”) MTA sendmail, for example, will refuse to accept incoming mail delivery connections if it detects a load greater than 10.
- How are patches/upgrades handled? Some well-intentioned VDS vendors will automatically patch and upgrade virtual server instances, particularly when widely publicized security flaws appear. If your application has no dependencies on specific or custom versions of system libraries or other applications, this practice will be a feature. Otherwise it may be a bug. On a recent deployment, for example, an inexplicable failure was eventually traced to an upgrade of the Berkeley Database (Sleepycat) libraries, performed by the hosting service.
- How complete is the installed OS? Some VDS vendors omit otherwise common packages from the initial server images. Given the relatively small disk space allocations (compared to what you would normally get on even a low-end dedicated server), this is frequently a good thing. A common ommision is the X11 libraries. These are needed if your application uses an AWT classes, but installing a minimal subset of these libraries is generally sufficient. If your application requires other libraries or applications, finding out whether or not these are available will help you determine how much of your disk space you will need to sacrifice to get your application running.
Virtual Dedicated Servers are a great idea, but most vendors seem to be targetting users who need to deploy transactional systems, and Apache/PHP/MySQL systems in particular. The more closely your application resembles such systems, the better your results will be. Eventually, of course, demand for Java deployment capabilities should force resolution of some of the current glitches.