Distributed Service Architecture
We operate our services over a number of different servers. Doesn't sound very exciting, but it's a key difference when
it comes to providing you with a reliable service.
As you can see from the image below, we've set up our essential core services so that they operate on different pieces of hardware. In some cases
a service is provided from more than one server at the same time.
However, no matter how complex our set up us, the thing to remember is that all the complexity is hidden from you. Our services are user-friendly even
for the complete novice because that's where we excel - combining technical competence, complex infrastructure, and innovative services,
and wrapping them up in a user-friendly package that anyone can use.
Click image for larger view
What this means is that your web site could be supported by up to 20 physically different servers, with each server providing an essential
service to your web site. This has a number of benefits:
- If a server should fail it will only affect the service being provided by that server.
If a FTP server failed then only the FTP service running on that server would be affected. Your web sites would still run,
and your email and databases would work. The only thing you wouldn't be able to do is upload files to your web site during the downtime.
Compare this to most hosts where web sites, email, FTP, and databases, are all installed on the same server. If the server crashes then every
service stops - your web site, your email, and any other essential service that you rely upon.
- Performance of your web site is better.
When all these services have to operate on the same server they end up competing for limited hardware resources. This is even more important
when you consider that email and databases usually require lots of resources to run well. The result is that there are less resources available
for your web site and your web site may be slow and unresponsive: not a good thing if it's a web site for your business.
- Recovery is simpler and quicker
If a server fails we only need to recover a single service.
For instance, if a web server fails then all we need to do is recover the web sites
on that server. When backup is being used, we can usually re-create the sites on another server, copy the files from the backup, and have
the server up and running extremely quickly - often before you even notice there was a problem. A web site being unavailable is the last thing
that you want, but you know recovery will be quick and at least your email and other services would continue to work.
If the server ran a number of services and we also had to recover email files and accounts, FTP accounts, databases, and DNS settings,
then it would take longer - much longer - before everything was working again.
- It's more secure
Since each server has a specialised task it's easier to set-up and maintain security. This ability to create stricter security rules on each
server reduces the chance of any particular server being compromised, providing a more robust and reliable network of services.
- Redundancy is possible.
Since we aren't relying upon a single server to provide all essential services, we can build in redundancy. This means that even if a single
server should fail, the service being provided will continue to function without downtime or interruption.
In our installation we have a number of redundant services such as DNS, Monitoring, Backup, MS SQL 2005 Databases, and email backup,
where a single server failure has no effect on the ability to provide that service.
We also have some semi-redundant services such as email, where if a frontline email server should fail the backup servers would continue to
collect emails for you until the frontline server was back online. Since our frontline email servers are fully backed up, it won't
take us long to recover a crashed email server to different hardware and have everything up-and-running perfectly again.
- Additional servers can be "slotted in" when required.
With the type of architecture that we have, additional servers and services can be added at any time. For instance, if we feel that the FTP server is
overloaded, we can simply install an additional FTP server to take over some of the load. This is also true of almost every service such as
email, DNS, Databases, Backup, and Monitoring.
It means that we can increase our installed base depending upon load, and maintain peak performance at all times. This is impossible
in set-ups where all the services need to operate from a single server.
- Spare servers are always available.
We always keep spare servers installed in our racks. These servers are on standby and are able to "takeover" a service if another server should fail.
You won't have to wait for us to order parts in for a broken server, and you can be sure that within 5 minutes of a essential "core services" server
being "down" we'll be managing the set-up of one of our spare servers to take over the service.
As you can see, a Distributed Services Architecture provides lots and lots of benefits that give you peace of mind knowing
that performance will always be maintained, crashes will be recovered from quickly, and any failures that do occur will have the smallest amount
of impact possible.