Best practice implementation example at a customer site
In the document “Banking IT Service Center running in a fully virtualized IBM PowerVM SAP environment”, a very efficient way of implementing a POWER-based SAP landscape is described in detail. You can get it here:
The customer is using PowerVM technology since 2005 for the SAP landscape, which consists of roughly 90 SAP systems (all defined as 2-tier systems, DB, and CI). The four POWER systems are located in two data centers in a campus setup (distance roughly two kilometers). The overall average processor utilization of the physical systems was around 60% to 70%. The various applications were running each in their own SPLPAR and balanced each other out to achieve a high consolidation factor.
The lessons learned from this implementation can be summarized by the following few principles:
•For processor assignment: All LPARs are defined as shared and uncapped (an LPAR attribute that is configured on the HMC / Systems Director to allow the LPAR to grow up to the physical limit of the shared processor pool). The processor entitlement of the SPLPARs is defined as relatively small to allow headroom for the various SPLPARs that the POWER hypervisor manages.
•Virtual I/O servers (VIOS): Defined always in pairs, for load balancing and high availability reasons, running within the shared processor pool. Both virtual Ethernet and virtual disk I/O of all SPLPARs must use the VIO servers. For details, refer to Chapter 5, “Virtual I/O Server” on page 37.
•Memory: Because the memory is not assigned as flexibly as processor resources, there needs to be enough memory for each LPAR when it is expanded to its maximum. Expressed in popular scientific terminology, if the LPAR breathes in, it needs enough memory to process the increased workload properly. This is valid for systems, which do not use Active Memory Expansion (8.5, “Active Memory Expansion for SAP systems” on page 84) yet.
•Combination of workloads: The best consolidation effect can be achieved if everything is mixed and matched. That means that production, non-production, and different applications (for example, ERP, BI, CRM, SCM or Portal, and so on) are mixed on the same physical system, separated by individual LPARs for each SAP instance. The more and the smaller the SAP systems are, and the more varied their workload, the better the possible consolidation. The utilization peaks, as they are typically very short (“microspikes”), happen in the different systems at different times, which helps even more with the possible benefit of overall increased utilization.
Frequently, the question arises: If non-production and production systems are using the same shared processor pool, how do we ensure that the production systems do not get cannibalized by development, quality assurance, or sand-box systems? Our recommendation is to use the uncapped weight attribute of an LPAR. Give the VIO servers the highest weight. When the resources get tight, the VIOS still needs to serve all of the other LPARs on the system. Give the next weight level to the LPARs with the production systems, and then all the other LPARs. It does not make sense to use a too complex scheme of weight factors in one physical system. Three or four levels are sufficient for most cases.
You can get a good explanation of the weighting in the IBM Redpaper:
IBM System p Advanced POWER Virtualization (PowerVM) Best Practices, REDP-4194
In the remaining chapters, we provide more detailed recommendations and examples of hands-on activities for building a flexible and efficient landscape for an SAP IT environment.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.