This presentation is targeted to for a less technical audience with the objective of explaining the power of IBM’s virtualization technologies
One or all of these topics are good reasons to do Virtualization. Some will say you can even lower your overall cost in head count. That is some what true but you need to have highly skilled UNIX talent for this. If you look at what a UNIX admin can support for physical servers maybe 50 systems and that is a lot. Compared to two UNIX admin who are trained and skilled with Virtualization. The pair can easily mange 4 595 class systems with a range of 350 to 400 LPARs on these systems, increasing the over all effectiveness of FTE (full time employee) staff.
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+
Micro partitioning allows for many more logical partitions to be created since you are no longer required to assign a full processor to a logical partition. Partitions can now more effectively be assigned enough CPU resources to do its workload allowing other partitions to use remaining CPU resources.
Here is the basic terminology.
The next few slides go into a little more detail. Use if audience is interested in knowing more.
Talk about the relationship between the physical CPU, the virtual CPU and the logical CPU.
Explain the concept of min, desired (or entitled) and maximum. Explain how the behavior of the hypervisor is controlled by the lpar definition
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.
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.
Explain how partitions were limited by the number of physical adapters in the system
The Integrated Virtual Ethernet adapter is a standard feature of every POWER6 processor-based server. You can select from different offerings according to the specific IBM System p server. At the time of writing, the IBM System p 570 is the first server to offer this feature. The IVE consists of a physical Ethernet adapter that is connected directly to the GX+ bus of a POWER6 processor-based server instead of being connected to a PCIe or PCI-X bus, either as an optional or integrated PCI adapter. This provides IVE with the high throughput and low latency of a bus imbedded in the I/O controller. IVE also includes special hardware features that provide logical Ethernet adapters. These adapters can communicate directly to logical partitions (LPARs), reducing the interaction with the POWER Hypervisor™ (PHYP). In addition to 10 Gbps speeds, the IVE can provide familiar 1 Gbps Ethernet connectivity common on POWER5 and POWER5+™ processor-based servers. Prior to IVE, virtual Ethernet provided a connection between LPARs. The use of an SEA and the Virtual I/O Server allowed connection to an external network. The IVE replaces the need for both the virtual Ethernet and the SEA. It provides most of the function of each. Therefore, this eliminates the need to move packets (using virtual Ethernet) between partitions and then through a shared Ethernet adapter (SEA) to an Ethernet port. LPARs can share IVE ports with improved performance.
A System WPAR presents an environment most similar to a standalone AIX 5L system. This WPAR type runs most of the system services that would be found in a standalone system and does not share writeable file systems with any other WPAR or the global system. An Application WPAR has all the process isolation that a system WPAR provides, except that it shares file system name space with the global system and any other application WPAR defined within the system. Other than the application itself, a typical Application WPAR only runs an additional light weight init process within the WPAR.
Note that the read only directories are the file systems provided by the global environment.
Application Mobility is an optional capability that will allow an administrator to move a running WPAR from one system to another using advanced checkpoint restart capabilities that will make the movement transparent to the end user.
The demo is a flash file viewed by using a browser that can not be started from within the presentation. Unzip the LAM_DB2_SAP_demo.zip file and open the html file to start the demo
Again it is necessary to leave the presentation to run the demo. Two choices, LPM with DB2 and network attached storage use the LPM_DB2_NAS_demo.zip or for LPM with DB2 and SAP use the LPM_DB2_SAP_demo.zip file. Either case, unzip the file locally and open the html file to start the demo.
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.
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
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.
Virtual real memory provides on capable Power Systems servers the ability to overcommit system’s memory, enabling better memory utilization and dynamic memory allocation across partitions in response to the partitions workload. Virtual real memory helps users reduce costs because they don’t have to dedicate memory to a particular logical partition. In doing so, they can reduce the total amount of memory in the system. It also allows users to “right-size” memory to their needs. Virtual Real Memory is the next step in resource virtualization evolution on POWER systems. The experiences gained in processor virtualization are applied to the virtualization of real memory to enable better memory utilization across partitions. The hypervisor manages a Virtual Real Memory Pool, which is just a portion of physical memory set aside to meet the memory residency requirements of a set of partitions defined as “shared memory partitions”. The hypervisor move page frames in and out of the system to a paging device as required to support overcommitment of physical memory. The OS collaborates with the hypervisor to reduce hypervisor paging. The most important aspect of the VRM function is the ability to overcommit the system’s memory. The virtualization of “real” main storage enables better memory utilization and dynamic memory allocation across partitions in response to partitions workload. The hypervisor distributes the physical memory in the pool among these partitions based on partition configuration parameters and dynamically changes a partition’s physical memory footprint based on workload demands. The hypervisor also coalesces common pages shared across shared memory partitions to reduce a partition’s cache foot print and free page frames.