A “traditional” server is a dedicated centralized computer used by all other users on the network.  It can have a variety of functions from a simple file repository, mail server, database server, web server etc.  It runs a more stable server operating system and is usually installed on “server grade” hardware, with many redundancies built in to improve reliability. 

But even though you can have your server with redundant power supplies, hard drives and other components, there are still single points of failure, such as the mother board.  So if that server has a hardware fault, all your users are off line.

It gets worse: say the RAID controller that runs the redundant hard drive array dies, you may or may not necessarily be able to rebuild the drive array (I had that happen!).   The traditional answer was to add more redundant components to your server.  Which adds cost.  There’s no such thing a redundant mother board system, so you still have a single point of failure. You can keep a spare motherboard on hand in case it dies, but you still have server downtime while you troubleshoot and repair it.  The next step up is create a cluster server – even more $$$!  In this, you can use two servers, now called “nodes”, all with redundant power supplies, hard drives etc (those things with the highest expectancy for failure).  You can connect those to a Storage Area Network (SAN) device which is a big array of hard drives, again with redundant power supplies, hard drives, network cards and even redundant RAID controllers.  To link all this together so that you have fail-over (called “Fault Tolerance”), you need to have not just server software, but the Enterprise Edition (more $$$).   But you now have a system that can tolerate a failure of any component on the system without causing the “server” to be off line.  But what if you need more than one “server” and want the same degree of reliability out of that system too?  The traditional answer: ante up… 

Another aspect of the “traditional server” system is that if you were to analyze your server performance and utilization in detail, you may be surprised to realize that each server may be only utilizing 5 -20% of the CPU and memory resources. The remaining 80 -95% of system resources are idle most of the time.

A “traditional” server is a dedicated centralized computer used by all other users on the network.  It can have a variety of functions from a simple file repository, mail server, database server, web server etc.  It runs a more stable server operating system and is usually installed on “server grade” hardware, with many redundancies built in to improve reliability. 

But even though you can have your server with redundant power supplies, hard drives and other components, there are still single points of failure, such as the mother board.  So if that server has a hardware fault, all your users are off line.

It gets worse: say the RAID controller that runs the redundant hard drive array dies, you may or may not necessarily be able to rebuild the drive array (I had that happen!).   The traditional answer was to add more redundant components to your server.  Which adds cost.  There’s no such thing a redundant mother board system, so you still have a single point of failure. You can keep a spare motherboard on hand in case it dies, but you still have server downtime while you troubleshoot and repair it.  The next step up is create a cluster server – even more $$$!  In this, you can use two servers, now called “nodes”, all with redundant power supplies, hard drives etc (those things with the highest expectancy for failure).  You can connect those to a Storage Area Network (SAN) device which is a big array of hard drives, again with redundant power supplies, hard drives, network cards and even redundant RAID controllers.  To link all this together so that you have fail-over (called “Fault Tolerance”), you need to have not just server software, but the Enterprise Edition (more $$$).   But you now have a system that can tolerate a failure of any component on the system without causing the “server” to be off line.  But what if you need more than one “server” and want the same degree of reliability out of that system too?  The traditional answer: ante up… 

Another aspect of the “traditional server” system is that if you were to analyze your server performance and utilization in detail, you may be surprised to realize that each server may be only utilizing 5 -20% of the CPU and memory resources. The remaining 80 -95% of system resources are idle most of the time.

This can be a difficult concept to visualize.  Essentially, it is a method of taking a  physical entities, such as a server or workstation, and translating it into an independent logical entity that operates inside a larger, managed hardware environment, but where it is not dependent on that hardware to the same extent as it was on a physical computer.

Each virtualized server (or workstation) still has the appearance and functionality of the original computer in every way just as it did on the original dedicated machine.  You can log onto it, manage properties, reboot it etc.   Users on the network will not be able to see any difference, except it is now a “Virtual Machine”.

Once a server has been “virtualized”, it’s existence is now equivalent to just a file and can be relocated to almost any piece of hardware you please.  So if your “host machine” has a hardware failure, you can simply move the “Virtual Machine” to another host and users will not be the wiser – but for the small amount of down time needed to bring the VM up on an alternate host.

This can be a difficult concept to visualize.  Essentially, it is a method of taking a  physical entity, such as a server or workstation, and translating it into an independent logical entity that operates inside a larger, managed hardware environment, but where it is not dependent on that hardware to the same extent as it was on a physical computer.

Each virtualized server (or workstation) still has the appearance and functionality of the original computer in every way just as it did on the original dedicated machine.  You can log onto it, manage properties, reboot it etc.   Users on the network will not be able to see any difference, except it is now a “Virtual Machine”.

Once a server has been “virtualized”, it’s existence is now equivalent to just a file and can be relocated to almost any piece of hardware you please.  So if your “host machine” has a hardware failure, you can simply move the “Virtual Machine” to another host and users will not be the wiser – but for the small amount of down time needed to bring the VM up on an alternate host.

Once a server has been “virtualized”, it’s existence is now equivalent to just a file and can be relocated to almost any piece of hardware you please.  So if your “host machine” has a hardware failure, you can simply move the “Virtual Machine” to another host and users will not be the wiser – but for the small amount of down time needed to bring the VM up on an alternate host.    

Now however, if you take that über-server cluster we discussed earlier and used it as your virtual server host system,  all the VM’s running on it will benefit from the ultra-reliability of that impressive hardware array.  Down time can be completely eliminated for hardware failures if set up “Fault Tolerance” which automatically maintains the VM operation even if you lose an entire node, and users will be none the wiser. 

Once a server has been “virtualized”, it’s existence is now equivalent to just a file and can be relocated to almost any piece of hardware you please.  So if your “host machine” has a hardware failure, you can simply move the “Virtual Machine” to another host and users will not be the wiser – but for the small amount of down time needed to bring the VM up on an alternate host.    

Now however, if you take that über-server cluster we discussed earlier and used it as your virtual server host system,  all the VM’s running on it will benefit from the ultra-reliability of that impressive hardware array.  Down time can be completely eliminated for hardware failures if set up “Fault Tolerance” which automatically maintains the VM operation even if you lose an entire node, and users will be none the wiser.