The term MODUS stands for "Managed On-Demand
UNIX Servers", which means that our server boxes come with management
and can be generated just-in-time, at the push of a button.
These servers are based on our enhanced
implementation of the FreeBSD "jail" mechanism, which adds important
compatibility features like proper support of SysV IPC (for PostgreSQL
etc.), raw IP sockets (ping, traceroute etc.), per box filesystem quotas
and more. Also, all boxes on all machines are NTP synchronized, so time
stamps in log files etc. can be compared at a sub-second granularity.
For the multilayer system architecture outlined
below we developed our own version of the UNION filesystem which we would
like to stress does not suffer from the stability and performance issues
of FreeBSD's original (broken) implementation. The underlying
filesystems that contain the actual data are plain UFS (plus soft
updates), for a maximum of speed and compatibility with applications.
|
|
|
In order to make our unique setup resource efficient,
and therefore affordable
to the customer, the filesystem is comprised of two sections. The actual
user filesystem contains only data owned by an individual box while
the major part of the UNIX system resides in a system container shared
by all boxes. The user container is mounted as an overlay to this
system container. Here is an illustration of how this works:
From the user's perspective this separation is invisible. As long as
he keeps accessing files in read-only mode (executing programs implies
read-only access) he (unknowingly) shares them with all other box
users. As soon as the box user opens a shared file for writing,
though, the system copies it into the user container, and from thereon
the user works on his personal copy of the file. This mechanism is
common in UNIX and is called "lazy-copy", or just "copy-on-write".
Note that timestamp, permission and ownership changes qualify as
writing to the file too. This personal copy can of course be removed
again at the user's discretion.
What this multilayer system architecture means
with regard to maintenance and security of our server boxes is that
we can do updates of the software living in the system container centrally
and on the fly, making servers with application level management (incl.
'root' access!) available at a price that would not be possible with
a conventional setup.
|
|
|
Users can customize the preinstalled software,
since modified config and data files automatically become private copies,
as outlined above. In order to avoid "collateral damage" when we upgrade
centrally maintained software packages we employ a number of strategies:
-
If the differences between software revisions are minor we tweak
the config and data files for those users who happen to have private
copies of them, in order to retain compatibility. Most of the time
this is not even necessary, though.
-
In case of more sweeping changes we install the new version in
parallel, if this is possible, and make the new version the default
for newly generated boxes.
-
If installing the new version in parallel is not possible we move
the entire current application into its own directory hierarchy and
deploy path redirections in all affected boxes, by means of symlinks.
Then we install the new revision. This way the upgraded version
becomes the default for newly generated boxes, while already existing
boxes keep using the old version. We provide upgrade docs and also a
script that effectively removes the symlinks, so each user can upgrade
at his convenience.
This methodology is key to years of undisrupted
server operation, without having to compromise on software maintenance.
The vast majority of upgrades takes place in the background and without
noticeable downtimes.
|
|
|
We found that due to insufficient insight into the
different underlying concepts, people frequently mix up our MODUS
system with conventional virtual
servers ("VS" for short), inadvertently comparing apples and oranges.
We would therefore like to shed some light on the main differences
between our solution and the majority of the VS offered elsewhere.
-
A MODUS box already comes with most of the application software
preinstalled that you would need on an Internet server.
This might be true for some VS boxes, too, but the majority is initially
equipped with just the basic OS installation.
-
Due to its special system architecture, maintenance of all the preinstalled
application software, as well as the OS utilities, is built-in in
a MODUS box. Since it is an integral part of the system it does not
cost extra. Still, despite this management feature you have 'root'
access. For VS boxes you would have to take care of maintenance
yourself, or else buy it as consulting, which is expensive if done in
a proper and timely fashion (basically the same as with dedicated
servers). Also, conventional server management rules out 'root'
permissions for the customer. In short, with a MODUS box you get the
convenience of a homepage account, combined with the flexibility of a
dedicated server.
-
Not only is there a lot of software preinstalled, it is also carefully
preconfigured, which means that when you move in you just need to add
your domain name(s) in a single location and start using the box,
right away. Try this with a conventional VS box!
-
Since the majority of customers make use of the preinstalled
software in MODUS boxes and bring only a few individual
add-on packages, if at all, the resource sharing in the base
machine's system memory, and
therefore the savings that are typically achieved, are tremendous,
which means that almost all of the system memory is available for
individual user data. Therefore, running relatively memory hungry
applications like an SQL database, a Java virtual machine etc. is
no problem in this environment. VS boxes, on the other hand, usually
have a much less efficient memory management, since they do resource
sharing for the OS utilities at most, which is negligible with regard
to memory consumption. Therefore, there have to be stricter resource
limits imposed on a VS box, which are likely to make it unsuited for
professional use.
-
The precise accounting of resources each MODUS box consumes enables us
to do a ranking of these boxes, showing us in time which one needs to
be migrated to a less utilized base machine. VS boxes usually lack
a sophisticated resource accounting, so load management is naturally
less effective.
To wrap it up, about the only thing our MODUS
system and conventional VS have in common is that there
are several boxes running on a base server machine. Concept,
implementation and also usefulness for the customer differ
substantially, though. While our MODUS boxes have been developed with
professional use in mind (IT outsourcing, server consolidation etc.),
conventional VS more often than not are just meant as a means to offer
bare-bones servers for even less than low-budget dedicated servers.
Certainly quite different objectives.
|
|
|
|
