Databases Reference
In-Depth Information
Why you might want to do this is a legitimate question for someone new to virtualization,
especially as in the physical world this kind of server administration was impossible. In fact, server
administrators receive many benei ts from being able to move running virtual servers off of a specii c
physical host server. If a specii c host requires patching, upgrading, or repairing, or perhaps has too
much load, then these issues can be resolved without affecting the availability of the applications and
services that the virtual servers support. Some or all of the virtual servers running on a host server can
transparently be migrated to another host, freeing up the host server for maintenance.
The basic concept behind online migration is readily understandable, but some complex operations
are needed to actually perform it. After the virtualization administrator identii es where the virtual
server should move from and to, the hypervisor logically “joins” the two host servers and they start
working together — to support not only the running of the virtual server but also its migration.
Each host server begins sharing the virtual server's data i les stored on the shared storage; the new
host server loads the virtual server's metadata, allocates it the physical hardware and network
resources it needs, such as vCPUs and memory, and, the i nal clever part, the hypervisor also sends
a snapshot of the virtual machine's memory from the original host server to the new host server over
the local area network.
Because changes are constantly being made to the memory, the process can't i nish here, so at this
point every memory change made on the original server needs to be copied to the new server. This
can't happen as quickly as the changes are being made, so a combination of virtual server activity
and network bandwidth determine how long this “synchronization” takes. As a consequence, you
may need to perform online migrations during quiet periods, although server hardware, hypervisor
technology, and 10GB Ethernet mean that these migrations are very quick these days. Before the last
few remaining memory changes are copied from the original host server to the new host server, the
hypervisor “pauses” the virtual server for literally a couple of milliseconds. In these few
milliseconds, the last remaining memory pages are copied along with the ARP network addresses
the virtual server uses and full read/write access to the data i les. Next, the virtual server is
“un-paused” and it carries on exactly what it was doing before it was migrated with the same CPU
instructions and memory addresses, and so on.
If you are thinking that this pause sounds dangerous or even potentially fatal to the virtual server,
in reality this technology has been tried and tested successfully — not only by the vendors themselves
but also by the industry. Online migrations have been performed routinely in large service provider
virtualization environments, and with such coni dence that the end customer never needed to be told
they were happening. Nor is this technology limited to virtual servers with low resource allocations;
Microsoft has written white papers and support articles demonstrating how its LiveMigration
feature can be used with servers running SQL Server. In fact, the SQLCat team has even released
a white paper downloadable on their website with advice about how to tune SQL Server to make
online migrations slicker and more efi cient.
However, while the technology is designed to make the migration as invisible to the virtual server
being migrated as possible, it is still possible for it to notice. The dropping of a few network packets
is typically the most visible effect, so client connections to SQL Server can be lost during the pro-
cess; or perhaps more critical, if you deploy Windows Failover Clustering on to virtual servers, the
cluster can detect a failover situation. Because of this, Windows Failover Clustering is not supported
for use with online migration features.
Search WWH ::
Custom Search