Information Technology Reference
In-Depth Information
also be partitionable so that a failure there affects only the one partition using
that component. This isolation scheme is shown in Figure 1.17.
Figure 1.17 Failure Isolation of Hardware Partitions
1.2.1.2 Operating System
Separate hardware requires a distinct copy of an operating system for each parti-
tion. This arrangement reinforces the separation of the partitions and maintains
the benefits, and effort, of per-partition OS maintenance, such as OS installation
and patching. To maximize partition independence, a failure in one OS instance
must be prevented from affecting another partition.
Also, specialized software (such as HA clustering) that links two partitions
must prevent one failure from affecting both partitions. Some implementations
in the industry achieve this level of independence more effectively than others.
1.2.1.3 Flexibility and Granularity of Resource Configuration
Most hard-partitioning systems allow the partitions to be different sizes. A parti-
tion can usually be resized. With some types, this operation requires stopping
all software, including the operating system, that was using the resources being
reconfigured.
Changing the sizes of two partitions can be viewed as moving the barrier be-
tween them, as depicted in Figure 1.18 on the next page.
Most of these systems are large-scale systems (more than eight CPU sockets
per system) and contain multiple CPU sockets on each circuit board. If such a
system is configured with multiple partitions per CPU board, a hardware failure
on that CPU board can cause multiple partitions to fail. CPU failures affect only
the partition that was using that CPU. For that reason, where failure isolation
is the most important consideration, only one partition should be configured per
CPU board. In contrast, if partition density is the most important consideration,
multiple partitions per CPU board will be an important feature.
 
Search WWH ::




Custom Search