Information Technology Reference
In-Depth Information
hardware failure from affecting more than one virtual environment (VE). Software
isolation prevents a software failure from affecting multiple environments; it also
provides separate namespaces for files, users, and processes. Security isolation
permits separate security contexts (with separate user identities, roles, and au-
thentication and authorization mechanisms) for each virtual environment, which
means that intrusion into one environment does not make it easier to penetrate
a different one on the same system. Although security isolation often focuses on
web-facing workloads exposed to public networks and on systems housing sensi-
tive financial, medical, or government data, it is important to secure all environ-
ments in a computing infrastructure to prevent attacks on the weakest link. It is
best to architect and integrate security on a systematic basis, rather than reserv-
ing it for “high-value” targets.
System features providing the most isolation can add to the costs of a system.
Nevertheless, business-critical workloads have the strongest need for compre-
hensive isolation and can often justify the extra expense of supporting inde-
pendent VEs. Any additional expenses may be offset by the savings provided by
consolidation.
Different forms of virtualization offer differing levels of software compatibility.
With some approaches, there are few or no incompatibilities: Software runs essen-
tially the same in a virtualized environment as in a non-virtualized system, except
potentially in terms of some differences in timing. With others, the virtualization
infrastructure performs some operations on behalf of a VE that are implemented
differently than on non-virtualized systems, or functionality is limited in some
way. These considerations were discussed in previous chapters and will be re-
capped later in this chapter as needed. Where applicable, incompatibilities should
be analyzed and software retested.
Recertification of software products, if necessary, should be performed by the
software vendor. In such cases, in-house testing should be minimal. Software de-
veloped in-house should be analyzed or retested if it is to be used on the types of
virtualization that affect program behavior.
Most forms of virtualization create performance overhead. This overhead is
caused by modification of the application code that is running, lengthening the
code path, or virtualization software using CPU cycles. The amount of overhead
depends on the type of virtualization and on the workload. CPU-intensive work-
loads are the least affected because they make the least use of state-changing
operations that require intervention from virtualization technology. In the sim-
plest cases, a VE gets a time slice on a CPU without needing assistance from
the virtualization technology. By comparison, I/O-intensive workloads experience
performance overhead in some virtualization solutions due to resource contention
and increased number of state-changing operations, especially when I/O devices
are shared.
Search WWH ::
Custom Search