| Added by Nicolette, last edited by Nicolette on May 18, 2007 (view change) | |
Micro-Partitioning Overview
- Mainframe inspired technology
- Virtualized resources shared by multiple partitions
- Benefits
- Finer grained resource allocation
- More partitions (Up to 254)
- Higher resource utilization
- New partitioning model
- POWER Hypervisor
- Virtual processors
- Fractional processor capacity partitions
- Operating system optimized for Micro-Partitioning exploitation
- Virtual I/O
Micro-partitioning is a mainframe-inspired technology that is based on two major advances in the area of server virtualization. Physical processors and I/O devices have been virtualized, enabling these resources to be shared by multiple partitions. There are several advantages associated with this technology, including finer grained resource allocations, more partitions, and higher resource utilization.
The virtualization of processors requires a new partitioning model, since it is fundamentally different from the partitioning model used on POWER4 processor-based servers, where whole processors are assigned to partitions. These processors are owned by the partition and are not easily shared with other partitions. They may be assigned through manual dynamic logical partitioning (LPAR) procedures. In the new micro-partitioning model, physical processors are abstracted into virtual processors, which are assigned to partitions. These virtual processor objects cannot be shared, but the underlying physical processors are shared, since they are used to actualize virtual processors at the platform level. This sharing is the primary feature of this new partitioning model, and it happens automatically.
Note that the virtual processor abstraction is implemented in the hardware and the POWER Hypervisor, a component of firmware. From an operating system perspective, a virtual processor is indistinguishable from a physical processor, unless the operating system had been enhanced to be made aware of the difference. The key benefit of implementing partitioning in the hardware/firmware is to allow any operating system to run on POWER5 technology with little or no changes. Optionally, for optimal performance, the operating system can be enhanced to exploit micro-partitioning more in-depth, for example, by voluntarily relinquishing CPU cycles to the POWER Hypervisor, when they are not needed. AIX 5L V5.3 is the first version of AIX 5L that includes such enhancements.
The system administrator defines the number of virtual processors that may be utilized by a partition as well as the actual physical processor capacity that should be applied to actualize those virtual processors. The system administrator may specify that a fraction of a physical processor be applied to a partition enabling fractional processor capacity partitions to be created.
 |
|---|
The diagram in this chart shows the relationship and new concepts regarding Micro-Partitioning processor terminology used in this presentation.
Virtual processors
These are the whole number of concurrent operations that the operating system can use on a partition. The processing power can be conceptualized as being spread equally across these virtual processors. Selecting the optimal number of virtual processors depends on the workload in the partition. Some partitions benefit from greater concurrence, where other partitions require greater power. The maximum number of virtual processors per partition is 64.
Dedicated processors
Dedicated processors are whole processors that are assigned to a single partition. If you choose to assign dedicated processors to a logical partition, you must assign at least one processor to that partition.
By default, a powered-off logical partition using dedicated processors will have its processors available to the shared processing pool. When the processors are in the shared processing pool, an uncapped partition that needs more processing power can use the idle processing resources. However, when you power on the dedicated partition while the uncapped partition is using the processors, the activated partition will regain all of its processing resources. If you want to prevent dedicated processors from being used in the shared processing pool, you can disable this function using the logical partition profile properties panels on the Hardware Management Console.
Shared processor pool
The POWER Hypervisor schedules shared processor partitions from a set of physical processors that is called the shared processor pool. By definition, these processors are not associated with dedicated partitions.
Deconfigured processor
This is a failing processor left outside the system's configuration after a dynamic processor deallocation has occurred.
Shared-processor partitions
- Micro-Partitioning allows for multiple partitions to share one physical processor
- Up to 10 partitions per physical processor
- Up to 254 partitions active at the same time
- Partition's resource definition
- Minimum, desired, and maximum values for each resource
- Processor capacity
- Virtual processors
- Capped or uncapped
- Capacity weight
- Dedicated memory
- Minimum of 128 MB and 16 MB increments
- Physical or virtual I/O resources
Micro-partitioning allows for multiple partitions to share one physical processor.
A partition may be defined with a processor capacity as small as 10 processor units. This represents 1/10 of a physical processor. Each processor can be shared by up to 10 shared processor partitions. The shared processor partitions are dispatched and time-sliced on the physical processors under control of the POWER Hypervisor.
Micro-partitioning is supported across the entire POWER5 product line from the entry to the high-end systems.
Shared processor partitions still need dedicated memory, but the partitions I/O requirements can be supported through Virtual Ethernet and Virtual SCSI Server. Utilizing all virtualization features support for up to 254 shared processor partitions is possible.
The shared processor partitions are created and managed by the HMC. When you start creating a partition, you have to choose between a shared processor partition and a dedicated processor partition.
When setting up a partition, you have to define the resources that belong to the partition like memory and IO resources. For shared processor partitions, you have to specify the following partition attributes that are used to define the dimensions and performance characteristics of shared partitions:
- Minimum, desired, and maximum processor capacity
- Minimum, desired, and maximum number of virtual processors
- Capped or uncapped
- Variable capacity weight
 |
|---|
Understanding min/max/desired resource values
- The desired value for a resource is given to a partition if enough resource is available.
- If there is not enough resource to meet the desired value, then a lower amount is allocated.
- If there is not enough resource to meet the min value, the partition will not start.
- The maximum value is only used as an upper limit for dynamic partitioning operations.
Partition capacity entitlement
- Processing units
- 1.0 processing unit represents one physical processor
- Entitled processor capacity
- Commitment of capacity that is reserved for the partition
- Set upper limit of processor utilization for capped partitions
- Each virtual processor must be granted at least 1/10 of a processing unit of entitlement
- Shared processor capacity is always delivered in terms of whole physical processors
Processor capacity attributes are specified in terms of processing units. 1.0 processing unit represents one physical processor. 1.5 processing units is equivalent to one and a half physical processors. For example, a shared processor partition with 2.2 processing units has the equivalent power of 2.2 physical processors. Processor units are also used; they represent the processor percentage allocated to a partition. One processor unit represents one percent of one physical processor. One hundred processor units is equivalent to one physical processor.
Shared processor partitions may be defined with a processor capacity as small as 1/10 of a physical processor. A maximum of 10 partitions may be started for each physical processor in the platform. A maximum of 254 partitions may be active at the same time.
When a partition is started, the system chooses the partition's entitled processor capacity from the specified capacity range. The value that is chosen represents a commitment of capacity that is reserved for the partition. This capacity cannot be used to start another shared partition; otherwise, capacity could be overcommitted. Preference is given to the desired value, but these values cannot always be used, because there may not be enough unassigned capacity in the system. In that event, a different value is chosen, which must be greater than or equal to the minimum capacity attribute. Otherwise, the partition cannot be started.
The same basic process applies for selecting the number of online virtual processors with the extra restriction that each virtual processor must be granted at least 1/10 of a processing unit of entitlement. In this way, the entitled processor capacity may affect the number of virtual processors that are automatically brought online by the system during boot. The maximum number of virtual processors per partition is 64.
The POWER Hypervisor saves and restores all necessary processor states, when preempting or dispatching virtual processors, which for simultaneous multi-threading-enabled processors means two active thread contexts. The result for shared processors is that two of the logical CPUs will always be scheduled in a physical sense together. These sibling threads are always scheduled in the same partition.
 |
|---|
Capped and uncapped partitions
- Capped partition
- Not allowed to exceed its entitlement
- Uncapped partition
- Is allowed to exceed its entitlement
- Capacity weight
- Used for prioritizing uncapped partitions
- Value 0-255
- Value of 0 referred to as a "soft cap"
A capped partition is not allowed to exceed it capacity entitlement, while an uncapped partition is. In fact, it may exceed its maximum processor capacity. An uncapped partition is only limited in its ability to consume cycles by the lack of online virtual processors and its variable capacity weight attribute.
The variable capacity weight attribute is a number between 0-255, which represents the relative share of extra capacity that the partition is eligible to receive. This parameter applies only to uncapped partitions. A partition's share is computed by dividing its variable capacity weight by the sum of the variable capacity weights for all uncapped partitions. Therefore, a value of 0 may be used to prevent a partition from receiving extra capacity. This is sometimes referred to as a "soft cap".
There is overhead associated with the maintenance of online virtual processors, so clients should carefully consider their capacity requirements before choosing values for these attributes. In general, the value of the minimum, desired, and maximum virtual processor attributes should parallel those of the minimum, desired, and maximum capacity attributes in some fashion. A special allowance should be made for uncapped partitions, since they are allowed to consume more than their entitlement. If the partition is uncapped, then the administrator may want to define the desired and maximum virtual processor attributes x% above the corresponding entitlement attributes. The exact percentage is installation specific, but 25-50% seems like a reasonable number.
Partition capacity entitlement example
- Shared pool has 2.0 processing units available
- LPARs activated in sequence
- Partition 1 activated
- Min = 1.0, max = 2.0, desired = 1.5
- Starts with 1.5 allocated processing units
- Partition 2 activated
- Min = 1.0, max = 2.0, desired = 1.0
- Does not start
- Partition 3 activated
- Min = 0.1, max = 1.0, desired = 0.8
- Starts with 0.5 allocated processing units
 |
|---|
Understanding capacity allocation - An example
- A workload is run under different configurations.
- The size of the shared pool (number of physical processors) is fixed at 16.
- The capacity entitlement for the partition is fixed at 9.5.
- No other partitions are active.
The following sequence of charts shows the relationship between the different parameters used for controlling processor capacity attributes for a partition.
In the example, the size of the shared pool is fixed - as is the capacity entitlement for the partition in which the workload is running.
No other partitions are active - this allows the example workload to use all available resource and means that we are ignoring the effects of Capacity Weights.
Uncapped - 16 virtual processors
- 16 virtual processors.
- Uncapped.
- Can use all available resource.
- The workload requires 26 minutes to complete.
This is the baseline for our example. The partition is configured to have 16 virtual processors and is uncapped. Assuming, as we are, that there are no other partitions active, then this workload can use all 16 real processors in the pool.
Note that the partition could have more than 16 virtual processors allocated. If that were the case, then all virtual processors would be scheduled and would be time-sliced across the available real processors. We'll discuss scheduling in detail later.
The dark area shows the number of available virtual processors. The lighter area shows the total amount of CPU resource being consumed.
The workload completes in 26 minutes.
 |
|---|
Uncapped - 12 virtual processors
- 12 virtual processors.
- Even though the partition is uncapped, it can only use 12 processing units.
- The workload now requires 27 minutes to complete.
This is exactly the same workload as before and uses exactly the same total amount of CPU resource. However, the number of virtual processors has been reduced to 12. Consequently, the workload is limited to using the equivalent of 12 real processor's worth of power, that is, a virtual processor cannot use more than one real processor's worth of power.
Because of the reduced amount of CPU power available within any given time interval, the workload now requires 27 minutes to complete.
 |
|---|
Capped
- The partition is now capped and resource utilization is limited to the capacity entitlement of 9.5.
- Capping limits the amount of time each virtual processor is scheduled.
- The workload now requires 28 minutes to complete.
Exactly the same workload as before. Now, however, the partition is capped. For the first time, the capacity entitlement becomes effective and the total amount of resource available within any given time interval (actually, every 10 ms) is limited to 9.5 processing units, that is, the equivalent of having 9.5 real processor's worth of power.
Note that all 12 of the virtual processors are being dispatched, but the scheduling algorithm in the POWER Hypervisor limits the amount of time each can be executing.
The workload now requires 28 minutes to complete.
 |
|---|
Dynamic partitioning operations
- Add, move, or remove processor capacity
- Remove, move, or add entitled shared processor capacity
- Change between capped and uncapped processing
- Change the weight of an uncapped partition
- Add and remove virtual processors
- Provided CE / VP > 0.1
- Add, move, or remove memory
- 16 MB logical memory block
- Add, move, or remove physical I/O adapter slots
- Add or remove virtual I/O adapter slots
- Min/max values defined for LPARs set the bounds within which DLPAR can work
One of the advantages of the shared processor architecture is that processor capacity can be changed without impacting applications or middleware. This is accomplished by modifying the entitled capacity or the variable capacity weight of the partition; however, the ability of the partition to utilize this extra capacity is restricted by the number of online virtual processors, so the user may have to increase this number in some cases to take advantage of the extra capacity. The main restriction here is that the CE per VP must remain greater than 0.1.
The variable capacity weight parameter applies to uncapped partitions. It controls the ability of the partition to receive cycles beyond its entitlement, which is dependent on there being unutilized capacity at the platform level. The client may want to modify this parameter, if a partition is getting too much processing capacity or not enough.
Real processors can, of course, only be added or removed from the shared pool itself. If you recall the discussion on defining a partition, you will realize that removal of a processor from the shared pool may mean that the POWER Hypervisor can longer guarantee CE for all active partitions. Before the DLPAR operation can be honored then, it may be necessary to reduce the CE for some, or all, of the active partitions.
Dynamic memory addition and removal is also supported. The only change in this area is that the size of the logical memory block (LMB) has changed. It has been reduced from 256 MB to 16 MB to allow for thinner partitions. There is no impact associated with these changes. The new LMB size applies to dedicated partition also. The size of the LMB can be set at the service console.
Notification of changes to these parameters will be provided so that applications, such as license managers, performance analysis tools, and high level schedulers, can monitor and control the allocation and use of system resources in shared processor partitions. This may be accomplished through scripts, APIs, or kernel services.
Other DLPAR operations perform as expected.
 |
|---|
- Allocate processors, memory and I/O to create virtual servers
- Minimum 128 MB memory, one CPU, one PCI-X adapter slot
- All resources can be allocated independently
- Resources can be moved between live partitions
- Applications notified of configuration changes
- Movement can be automated using Partition Load Manager
- Works with AIX 5.2+ or Linux 2.4+
Comentarios
Publicar un comentario