HP Virtual Partitions (vPars) allows the
hardware of a single server to be divided into separate entities, each
of which is capable of running a distinct operating system. This allows
the workloads on multiple servers, none of which are fully utilizing
their allocated hardware, to be combined to a single server and yet
retain their operating system isolation. Figure 1
is a diagram showing three traditional servers running separate
operating systems and workloads. Certainly the three workloads could be
combined on one server without vPars; however, it is common for
workloads to require some level of isolation. Operating system
isolation is commonly used to provide the workload separation.
Figure 2 provides a view of a server running vPars. One of the key differences in this diagram is the Virtual Partition Monitor
layer. This layer serves as an intermediary between the operating
systems and the firmware. The vPar monitor reads the configuration of
the Virtual Partitions from disk, loads the configuration into memory,
and allocates resources to the Virtual Partitions based on the
configuration. Using the vPar configuration information, the firmware
calls of each of the operating systems are intercepted and filtered by
the vPar monitor. For example, an operating system's firmware calls
requesting data for the CPUs and I/O devices in the hardware platform
will be filtered to return only the information for the assigned
hardware resources. Consequently, applications built to run in non-vPar
environments typically operate without modification because the
interfaces between the HP-UX operating system and the workloads have
remained unchanged.
Virtual
Partitions allow consolidation to a single server in order to increase
system utilization. In addition, vPars allow dynamic CPU migration. The
granularity and flexibility of vPars allow each workload to continue
operating in a highly customizable environment. Each vPar is running a
separate operating system, which means it can be patched and tuned
precisely to the needs of the workload. Additionally, the operating
system isolation results in protected workloads. An errant workload
consuming all of the file descriptors, for example, will not affect any
of the other vPars in the server. In addition, kernel panics and other
software faults will not affect the availability of any vPar other than
the one where the fault occurred.
Each vPar must consist of at least the following resources:
one bound CPU
sufficient memory to boot HP-UX and run a workload
I/O connectivity to bootable media
network connectivity (not required, but common)
Given
these minimum system requirements, a large SD64000 Superdome with 64
processors is capable of running a maximum of 64 distinct virtual
partitions. However, these virtual partitions cannot reside within a
single nPartition. There can be at most eight vPars within each
nPartition. To achieve the full 64 virtual partitions, the Superdome
would first need to be divided into eight nPartitions, and each of the
nPartitions can then be divided into eight virtual partitions. The
final requirement for a Virtual Partition configuration is all the
Virtual Partition kernels together must fit within the( lower 2GB of
address space and each kernel must reside in contiguous address space.
