Information Technology Reference
In-Depth Information
model, you can start VEs at a remote disaster recovery site, restoring critical ser-
vices hours or even minutes after a large-scale disaster occurs.
For some workloads, such as web servers with static contents, you can take
snapshots at infrequent intervals. Restoration is simple and quick in such circum-
stances, and the damaged environment can be retained for analysis of the bug or
attack.
For dynamic workloads that temporarily store state-related data, such as ap-
plication servers, you can regularly quiesce the workload, if necessary, and take a
snapshot of it. Any transactions being processed when the problem occurred may
be lost, but service can be restored very quickly. A transaction processing monitor
will minimize or prevent lost transactions. As with web servers, the damaged VE
will be retained on persistent storage, waiting for analysis.
Database servers can also be managed using this method. It is more likely that
the database must be quiesced, or in some cases even stopped, before taking the
snapshot. This practice ensures that the database on disk is self-consistent and
can be restored by simply booting the copy of the VE in the snapshot.
With virtual machines, you must restart the VE on an identical alternate com-
puter, or you must track the compatibility between computers very closely. The
organization that created the hypervisor will determine how similar the two must
be to safely restart a VE on a different system.
This kind of matching is rarely an issue for operating system virtualization
(OSV) because CPU architecture details matter much less, if they matter at all.
However, I/O device configuration must still be taken into consideration.
When it comes to migration, workloads running on hardware partitions can be
restored on a similar system with partitions or on separate systems. The separate
systems need not support partitioning at all. Although use of separate systems
will retain the isolation characteristics of individual partitions, it loses the flex-
ibility inherent in a partitioned system.
Another general caution concerns network identity. VEs typically have one or
more IP addresses and network names by which they are known. After a disaster,
the IP address must be accessible at the new location of the VE. Other computers,
including personal computers, may then use this address to regain access to ser-
vices they require. Whenever the VE is running properly on the original system,
however, any testing of the alternate system must not advertise the IP address of
that service.
VE migration is further complicated by the need for, and limitations of, shared
storage. The most common choices are network attached storage (NAS) and stor-
age area networks (SANs). NAS is typically simpler to configure and manage than
SANs, and this simplicity makes it easier to perform a migration. During the mi-
gration process, along with ensuring some coordination between the two systems,
the original system unmounts the file system, if necessary, and the destination
Search WWH ::
Custom Search