... simple dependencies

Some facts about running datacenters and web services

Today I would like you to "start from the scratch" when looking at your datacenter services!

Starting from the upper endpoint, the end-user of your service, I will go down and list the dependencies of the service from one step to the next.

Please notice that those dependencies are also true for any type of Cloud Computing services!


Dependencies:

• End-user (Person)

A "Person" requests services via a client program (web-broswer, mail-program, ftp-client etc.) The Request itself is "Software".

• The Request (Software)

The Request goes to an IP-address (or hostname) and port-number (may further depends on DNS resolving)

• IP-address and Port (Software)

The IP-address and open port depends on a running operating system. Furthermore the operating system also needs to take care of running a server-program "behind" the IP-address and port number to actually "serve" the client (for a webserver e.g. with the reply to a GET request). All this dependencies are "just" based on Software.

• Operating System (Software)

The operating system needs "hardware" to run on. Of course nowadays many operating systems are running within Virtual Machines, a great advantage and start to actually made the service "hardware-independent". A Virtual Machine is still "Software" only.

• A Virtual Machine (Software)
  

A simple fact: Virtual Machines needs physical system to run on!

• Physical Systems (physical Hardware!)

The actual running Virtual Machine still fully depends on physical hardware!


Conclusion:

• Datacenter services should be high-availabe.

• The actual service is "software" only.
  

• The service sadly still depends on "hardware" (even if virtualized).

• ... and hardware will break at some point in time

Lessons learnt:

If any kind of the service configuration and/or data is "stored" locally on the physical systems (the Virtualization host) a failure of the hardware will also cause a failure (and possible outage) of the service.


About "physical hardware" in our Universe:

Everything (i really mean everything) in this Universe is constantly changing. The only thing which is not changing is that everything IS changing. This means every physical system will break at some point in time!

... or lets rephrase it via Murphy's law:

Rule 1) Don't trust faulty hardware.

Rule 2) All hardware is faulty.

Solution:

Very easy!

Make absolutely sure that no bit of data belonging to the service is stored locally on physical systems (Virtualization Hosts). Avoid binding any of your services (software only) to physical server (hardware)!

Enjoy,

Matt

openQRM 4.9 released - Cloud Zones, native VMware ESX support and more

With Cloud Zones, native VMware vSphere/ESX support and lots of improvements to the base system and plugins, openQRM 4.9 opens up new dimensions in professional datacenter management.

---

These are the highlights of the new version:

• Cloud Zones
  Implement Cloud Computing services across multiple datacenter locations, each running their own openQRM infrastructure - seamlessly managed with a new infrastructure layer on top of it all.
• Rewritten VMware vSphere/ESX support
  openQRM now natively manages VMware ESX(i) hosts and guests, using the latest and greatest features the VMware vSphere/ESX API has to offer.
• Comprehensive, automatic Linux and Windows installation
  Seamlessly attach existing Cobbler, FAI, LinuxCOE and/or Opsi environments to your openQRM infrastructure and forget about initial provisioning hassle.

For more details please have a look at the Changelog.

The new openQRM 4.9 release is now freely available under GPLv2 license for download at https://sourceforge.net/projects/openqrm/files/

The project's subversion repository got updated with the 4.9 release code.

Thanks for this release are especially going to the openQRM Enterprise team for sponsoring new features and contributing a lot of development and QA effort. Many thanks go to everybody in the openQRM community, as well, for providing us with useful feedback and bug reports.

Matt Rechenburg
Project Manager openQRM, on behalf of the openQRM Team