Databases Reference
In-Depth Information
While online migrations may seem like a good solution to virtual and host server availability,
keep in mind that they are on-demand services — that is, they have be manually initiated; and, most
important, both the original and the new servers involved have to be available and online in order
for the process to work. They also have to have the same type of CPU as well; otherwise, the differ-
ence in low level hardware calls would cause issues. You could script and then schedule an online
migration, but for the purpose of this chapter we'll still consider that a manual migration. In short,
while this feature is good for proactive and planned maintenance, it cannot be used to protect
against unplanned downtime and host server failures.
Highly Available Virtual Servers
Understanding how online migrations work will help you understand how some of the high-availability
features in hypervisors work. When comparing the high-availability features of the two most
prevalent server platform hypervisors, you can see a difference in their approach to providing high
availability. VMware's vSphere product has a specii c high-availability feature, vSphere HA, built-
in; whereas Microsoft's Hyper-V service utilizes the well-known services of Windows Failover
Clustering.
Both of these HA services use the same principle as online migration in that all the i les needed
to start and run a virtual server have to be kept on shared storage that is always accessible by several
physical host servers. This means a virtual server is not dependent on any specii c physical
server being available in order for it to run — other than the server on which it's currently running,
of course. However, whereas online migrations require user intervention following an administrator's
decision to begin the process, HA services themselves detect the failure conditions that require
action.
VMware and Microsoft's approach is ultimately the same, just implemented differently. Both
platforms constantly monitor the availability of a virtual server to ensure that it is currently being
hosted by a host server and the host server is running it correctly. However, running according to
the hypervisor's checks doesn't necessarily mean that anything “inside” the virtual server is
working; monitoring that is an option available in VMware's feature where it can respond to a
failure of the virtual server's operating system by re-starting it.
As an example, the hypervisor would detect a physical host server going ofl ine through unexpected
failure, causing all the virtual servers running on it to also go ofl ine — the virtual equivalent of
pulling the power cord out of the server while it's running, and then if coni gured to, re-start all
of the virtual servers on another host server.
In this situation, whatever processes were running on the virtual server are gone and whatever was in
its memory is lost; there is no preemptive memory snapshotting for this particular feature as there is
for online migrations. Instead, the best the hypervisor can do is automatically start the virtual server
on another physical host server when it notices the virtual server go ofl ine — this is the virtual
equivalent of powering up and cold booting the server. If the virtual server is running SQL Server,
then, when the virtual server is restarted, there may well be an initial performance degradation
while the plan and data catches build up, just like in the physical world.
What makes this feature exciting is the opportunity to bring some form of high availability to
virtual servers regardless of what operating system or application software is running inside
the virtual server. For example, you could have standalone installations of Windows and SQL Server
Search WWH ::
Custom Search