Kloxo updation system finally brings a relief to administrators who are suffering from updating and maintaining large number of machines. The master-slave model makes sure that all the slaves are updated at the same time when the master is made up-to-date. Updating kloxo consists of two steps.

1. The master checks for latest release and updates itself.
2. The master gets the list of slave servers and then communicates each of them individually and upgrades them.

This, at first glance, would seem to be sufficient to make sure the full updation. But it isn't. It is quite possible that some of the slave servers could be down when the master was doing its updation, and this can leave the network in an inconsistent state. Kloxo's default policy is to expect the worst, that is to make sure that even in the worst case scenario, kloxo will work fine.

Kloxo goes much more into making sure that both the master and slave are kept 100% in sync. In every connection to the slave, the master also sends its version information, which the slave compares to its own (this version checking actually induces 0 overhead; it is only a matter of an extra 13-15 characters being sent across) and if the master has a higher version, slave automatically starts a process to make sure that it has the exact version number of the master. So even if the slave was down at the time of master's upgradation, every communication makes sure that they are in sync.

Thus the kloxo clustered environment not only allows you to distributed the load and thus achieve maximum utilization of your hardware, it also completely makes managing all the servers painless. You can now manage the properly distributed load with just a click of a button. In place of many servers which were inefficiently handling same processes, you have a single server system which is more efficient and also easier to manage.