Using SAP with HP Virtualization and Partitioning Introduction... 2 Overview of Virtualization and Partitioning Technologies... 2 Physical Servers... 2 Hard Partitions npars... 3 Virtual Partitions vpars... 3 Virtual Machines... 4 Secure Resource Partitions... 4 SAP and the mysap Business Suite... 4 SAP Systems for Select mysap Components... 4 mysap ERP... 4 mysap CRM... 5 mysap SCM... 5 Spectrum of the SAP System Landscape... 5 Training... 5 Evaluation... 5 Development... 6 Test and Q/A... 6 Production... 6 SAP Change and Transport System... 6 Matching Computing Technology to SAP Scenarios... 7 To partition or not to partition... 7 Computer Resources: Dedicated vs. Shared... 8 Dedicated vs. shared resources... 9 Isolation... 9 Example: Typical System Landscape Approach... 12 Deployment: Application Perspective...13 Tuning for SAP on HP s Partitioning Continuum... 13 For more information... 14
Introduction Today s choices in computer systems and hardware consolidation technologies provide a multitude of options when deploying robust business critical software solutions. Given all these choices for deploying various SAP systems, it is not necessarily trivial to match the right partitioning or virtualization technology to a given SAP system. In the following sections, recommendations and heuristics are provided to aid in choosing the right technology for SAP system deployments. Overview of Virtualization and Partitioning Technologies Physical Servers The traditional model for deploying software applications has been to use one or more stand-alone computer systems, each of which runs a single operating system. As the power and capacity of individual hardware components processing cores, network interfaces, and mass storage peripherals has increased, the actual utilization of these hardware components has, in many cases, decreased. An immediate result of this combination is the desire to consolidate more than one software application or workload on the physical server. This practice is generally referred to as hardware consolidation. To address this desire for efficiency, HP provides a broad spectrum of hardware partitioning and sharing technologies. Grouping hardware components of a physical computing configuration into subsystems or partitions is one approach to hardware consolidation. Because these partitions contain entire hardware components, they provide dedicated access to those components. Providing a means of sharing hardware components within a physical server or partition can be performed in many different ways. As part of its Virtual Server Environment (VSE) suite of products, HP provides a broad spectrum of solutions for hardware partitioning and sharing in its partitioning continuum as illustrated in Figure 1.
Figure 1. HP's Partitioning Continuum provides a broad spectrum of solutions for hardware consolidation Hard Partitions npars With electrical separation, hard partitions are isolated in hardware from each other, so hardware failures are confined to the partition in which they occur. Applications and operating environments execute in hard partitions that function as if they were separate physical servers. Moreover, the majority of hardware upgrades will require that only the affected hard partitions be brought down, not the entire system. The reconfiguration or rebooting of an individual hard partition does not require a reboot of the entire system. Hard partitions support multiple operating systems, including HP-UX 11i, Windows Server 2003, and Linux. Virtual Partitions vpars Created by software, each virtual partition runs its own operating-system image and can host its own applications, offering complete software isolation. Many virtual partitions can run within a hard partition or on the same physical server. Since processing cores allocated to a virtual partition can be allocated dynamically without requiring the partition to be rebooted, they offer tremendous flexibility. Processing cores may be moved from one virtual partition to another dynamically, allowing for load rebalancing to address changing data processing requirements.
Virtual Machines One important approach to hardware sharing is that of providing a layer between the physical hardware and the operating system(s) which virtualizes the hardware components. In doing so, a single hardware component may be associated with multiple virtual hardware components. These virtual hardware components may then be grouped together into a virtual computer system, or virtual machine. The Integrity Virtual Machines product from HP provides the capability to deploy multiple, virtual machines with separate operating systems and software each running with their individual configurations, versions, and patch levels on a single set of computer hardware components. Integrity VM supports virtual machines running HP-UX 11i, Windows Server 2003, and Linux operating systems. Sharing of processing cores, network interfaces, and mass storage units amongst multiple virtual machines is provided with Integrity VM. Secure Resource Partitions Another means of hardware sharing is to provide middleware within an operating system that provides shared access of hardware components. HP s Process Resource Manager (PRM) is an example of such a technology which provides a secure means of isolating software applications within a single operating system instance. PRM has been used extensively in consolidating SAP systems on a single computer system, proving to be a very efficient means of increasing hardware utilization. One drawback of PRM is that it shares an operating system amongst multiple workloads. Configuration, patch, and management issues may arise and prevent its usefulness. While PRM is an important tool in consolidating SAP systems, it will not be discussed in detail here as the focus of this white paper is on partitioning and virtualization technologies. SAP and the mysap Business Suite From its very beginning, SAP has focused on providing solutions to help customers modernize their back office business processes. The traditional SAP Enterprise Resource Planning (ERP) system provided transaction and reporting functionality for financial, logistics, and human resource applications. Building on this core competency, SAP developed its mysap Business Suite of applications to help manage and optimize individual business critical operations. Collectively, the suite s components provide a fully integrated, scalable system for managing the overall organization, adding value to every aspect of the value chain. SAP Systems for Select mysap Components There are a multitude of SAP systems, applications, and components. Here we will focus on the mysap components which rely on the SAP NetWeaver platform. SAP NetWeaver is a comprehensive integration and application platform serving as the technical foundation of mysap Business Suite applications as well as partner and custom-built applications. The mysap Business Suite contains several components, including ERP, Customer Relationship Management (CRM), and Supply Chain Management (SCM). mysap ERP The mysap ERP component, arguably the most important in the mysap Business Suite, provides solutions in key functional areas, including Financials, Operations, and Human Capital Management (HCM). The ERP Financials solution provides complete financial management solutions for accounting, reporting, analysis, financial supply chain, and treasury management. Typically, Financials modules have a relatively low computing resource utilization impact on the overall SAP system.
Modules for procurement and logistics execution, product development and manufacturing, as well as sales and service, are provided in the ERP Operations solution. Operations modules frequently require dedicated computer hardware to deliver acceptable response times for sales and service applications. Production planning processing usually places a significant load on the SAP system. The Human Capital Management (HCM) solution includes business processes for human resources (HR), personnel administration and deployment. HCM accommodates payroll functions and regulatory requirements for over 45 countries, making it ideal for global business operations. Because the regulations and laws are subject to frequent change in each of these countries, many enterprises deploy a dedicated HR system that is separate from the other systems to restrict the downtime necessary when implementing updates to the HR department. Normally, the processing requirements for HCM are quite low. mysap CRM SAP provides support for a wide range of customer contact scenarios with its Customer Relationship Management (CRM) solution. Fast response time is usually a necessary condition for Customer satisfaction. Hence, CRM processing often requires dedicated hardware. mysap SCM The mysap Supply Chain Management (SCM) now combines the SAP Advanced Planning & Optimization (SAP APO), SAP Event Management, and SAP Inventory Collaboration Hub (SAP ICH) solutions. All of these solutions can be installed on a single database and administered as a single system. APO frequently analyzes huge amounts of data and requires extremely fast access to data to enable complex real-time scheduling calculations. To accommodate this need, SAP developed a memory-based data structure optimized for APO, called livecache, which almost completely eliminates the need to copy data between mass storage and main memory during transaction processing. The livecache component s extensive memory demand usually requires a separate server with a large address space and memory fault-tolerance. Spectrum of the SAP System Landscape Every large scale software implementation moves through different phases beginning with its conception and transitioning into production. The same is true of SAP projects and involves several types of systems used for these phases. Training SAP users frequently need training on newly deployed SAP applications, gaining experience before using production systems. Most training systems need a minimal amount of processing power, usually addressed by small computing systems with small databases. However during introduction of new functionality to a large user community, or if a large number of new users have to be trained, these systems can be quite demanding. Especially in a training environment, users tinker a lot with the system and thus can generate a high load on that system. In general, all training systems have a very dynamic load pattern: very high during training sessions, close to zero when no training takes place. Evaluation New applications, components, and solutions require feasibility studies and proof-of-concept analysis. Such evaluation systems, like training scenarios, normally only require minimal systems with small databases. But sometimes customers want to check the feasibility of upgrades for their system. Often this process is evaluated using a copy of the production database. This is another example of extreme demand changes in non-production environments.
Development Customization of the mysap applications as well as development of new components and functionality rarely has large processing or database requirements. Such systems should, understandably, be isolated from production systems but the use of similar operating systems will aid in deployment. Similar to training systems, load patterns can be very dynamic on development systems over time. In small installations some of the development systems can have nearly zero utilization over several days, because there is no development activity. During phases of high development activity however, dozens of highly paid external consultants may use the system, thus the requirements to the development system are more like those of a production system during that phase. Test and Q/A System testing and formal quality assurance (QA) processes are needed before SAP upgrades, patches (operating system or application), or new applications are deployed on production systems. Functional testing for correctness can be accomplished with lower processing power and smaller databases than production. Stress tests, however, can require much more system capacity. In some rare cases customers use test systems that are identical to production, in order to be able to exactly predict the run time of large batch process chains. Again, load patterns on test systems are very dynamic over time. Formal Q/A certification will typically use data that is a copy of that on the production system. The hardware platform(s) must be capable of supporting the same operating system, database, and middleware as production systems. Processing power requirements will be smaller than production systems, but should be sufficiently powered so that production performance can be reliably predicted. Production As discussed in the overview of the mysap business suite, many of the solutions require a guaranteed amount of computing resources and large databases. There are a few exceptions, human resource applications for example, but a guaranteed amount of resources is needed to satisfy performance needs and expectations in most cases. SAP Change and Transport System The Change and Transport System (CTS) moves, or transports, configuration changes as well as upgrades, patches, and newly developed components in a controlled manner between the phases of the SAP project implementation. In some cases a separate integration system is used to consolidate the changes of multiple development teams. Figure 2. Typical example of various deployments in the spectrum of the SAP system landscape Development Formal Q/A Development Functional Test Production Training Evaluation CTS Host
Matching Computing Technology to SAP Scenarios Given all these choices for deploying various SAP systems, it is not necessarily trivial to match the right partitioning or virtualization technology to a given SAP system. In the following sections, recommendations and heuristics are provided to aid in choosing the right technology for SAP system deployments. In many cases, it may not be necessary to separate your SAP systems at all. Running the various mysap solutions on one operating system instance has been proven to be a viable solution in many deployments. To partition or not to partition As discussed above, various mysap components technically can be run together on one operating system instance. This is the easiest and cheapest approach, and proven at thousands of customer sites over a period of many years. There are, however, good reasons to separate mysap components on separate operating system (OS) instances and/or separate physical parts of the server, using various partitioning and virtualization techniques. These reasons include: Separation of production and non-production environments Highly critical production systems. If minimizing planned and unplanned downtime at any cost is a requirement, then it helps to have the system separated in a way that there are not dependencies with other systems (both from an operating system and hardware perspective). This enables one to make any changes - including hardware changes - at the critical system without impacting other systems. Vice versa, any changes at other systems will not affect the critical system. Separation of systems if the customer demands it. This is often the case in outsourcing projects, where the customer demands a contractual obligation that his system must be separate from systems of other customers Downtime periods for planned maintenance. Systems belonging to one mysap landscape most often can be taken down at the same time, because they depend on each other, so an outage of one of the systems will disturb the other systems anyway. However for systems belonging to different companies or business units which don t depend on other systems, or that serve users in different cultures or time zones, it is often very difficult to find a common downtime period. Systems based on non-standard SAP technology (e.g., not based on WebAS). These include MDM (Meta Data Management), TREX (Search Engine), or APO Optimizer. These are either not proven to run together very well, or have a restricted platform availability and thus might need a different operating system than the rest of the SAP landscape. Development environments managed by developers. This can happen simply because it is company culture to let the developers set up and manager their own environments, or with new SAP products that are so much in flux that frequent modifications on the OS level are required so the developers are allowed to do them. In all these cases it is beneficial to keep the system well in quarantine on a separate OS and/or separate partition. Development/evaluation systems for new SAP products. These are famous for needing frequent changes, patches and so forth, thus they often need to be rebooted during normal working hours. In order not to disturb other developers working on different systems, these should be kept separate. Formal QA systems, which must be identical or bug compatible with their corresponding production systems. They have to run on a separate OS instance each, to be able to have different patch levels for every QA system.
Computer Resources: Dedicated vs. Shared When considering a given partitioning or virtualization technology for any software deployment, the primary difference is whether the technology shares resources or has dedicated access to them. When an application shares resources then, by its very definition, these resources are divided and distributed to other applications for their use. The result is that the application performance is not likely to execute as fast as it might if the resources are dedicated to that application. By dedicated resources we don t mean statically, dedicated hardware here. It rather stands for providing the application with a certain guaranteed amount of resources at any time. That is, the access to resources does not need to be constant, it can change over time. By shared resources we mean having a pool of resources from which every application takes as much as it wants, thus not guaranteeing exclusive resource access to any application. Some heuristics for deciding whether a workload requires dedicated resources or is a good fit for resource sharing are: Application testing, especially with respect to correctness, rarely requires high processing power and is very well suited to resource sharing. The periodic nature and high levels of automation present in testing also make it a good candidate for resource sharing. More formal quality assurance (QA) testing may include response time feasibility or be constructed so that successful execution requires some level of sustained processing. In those scenarios, QA processing is probably better suited to dedicated resources. Otherwise, QA processing may also have short-term, periodic processing requirements that may lend it to efficiently sharing resources. Application development can benefit from the flexibility and rapid deployment inherent in resource sharing technologies such as virtual machines. The inherent ability in virtual machines to quickly deploy a system and provide OS configuration and patching capability to a development team makes it an excellent choice. Low utilization production workloads are among the best candidates for hardware consolidation, especially if these workloads do not have response-time requirements. Be aware that utilization is often provided as an average and there may be periodic (e.g., end of week or end of quarter) requirements for dedicated resources. High utilization workloads are usually better deployed on systems that can provide dedicated access to computer resources. Rarely are they appropriate for virtualized processing solutions. Workloads that are performance sensitive, having stringent Service Level Agreements (SLAs) with regard to completion time or response time are best deployed on platforms that provide dedicated processing power. Computer capacity is often a driver for deciding on whether to use shared hardware or dedicated hardware solutions. Workloads that require scores of mass storage units, network interfaces, or processing cores are almost always better suited for dedicated hardware solutions.
Figure 3. Virtualization Techniques revisited Now let s revisit the different virtualization techniques in light of these heuristics, and find the typical sweet spots for the different types of SAP systems. Dedicated vs. shared resources Both npars and vpars are technologies which provide dedicated resources to the application, as long as the administrator or workload management tools do not actively change the resource assignment. Both one OS (no partitioning at all) and Integrity VM inherently provide resource sharing between all applications. In both scenarios however workload management tool can take care that various degrees of resource dedication to applications are implemented. Isolation one OS of course provides no isolation at all Integrity VM provides OS isolation, but no hardware isolation Virtual partitions (vpars) provides a certain degree of HW isolation: the different operating systems run on a different part of the machine, but when HW changes force you to take down this part of the machine then all vpars have to be taken down, also faults in some HW components may cause all vpars to crash Hard partitions (npars) provides perfect HW isolation, with no dependencies whatsoever between different partitions
Figure 4. Sweet spots for production systems With these comparisons in mind, we discuss the various options to deploy production systems: Production, no isolation required represents for multiple production systems that can share one OS. Check the previous chapter to partition or not to partition. If you don t find a good reason to partition among your production systems, this is the sweet spot for your production systems. If you find a reason to partition, go to the next bullet. Medium/Large production, isolation required refers to systems that cannot be run on one OS for some reason. Virtual partitions (vpars) are fine for systems that don t require complete hardware isolation; npars are the technology of choice if complete isolation is required. However if your systems are very small, please consider the following. Small production, isolation required applies to systems that cannot be run on one OS, but for which vpars or npars are a waste of resources, and which don t need HW separation. Typically these are systems ranging from fractions of a processor core in resource consumption, up to about 2 cores. For these systems, Integrity VM provides several benefits: o automatic resource sharing optimizes resource usage o ability to allocate fractions of a processor core to a system prevents waste of resources, using vpars or npars in these cases will use many more processors in total o IO device sharing prevents an excessive count of adapters that would come with implementing a vpar or npar for every single small system
Figure 5. Sweet spots for non-production systems Having identified partitioning and virtualization options for production systems, consider the various alternatives for deploying non-production systems: Systems not requiring separate OS represents multiple non-production systems that can share one OS. Check the previous chapter to partition or not to partition. If you don t find a good reason to partition among your non-production systems, this is the sweet spot for your non-production systems. If you find a reason to partition for any of your systems (most probably you will!), go to the next bullet. Systems requiring separate OS are ideal candidates for Integrity VM. The nature of nonproduction systems, being normally small systems, in connection with very dynamic load patterns, makes them the ideal match for Integrity VM. Automatic resource sharing will optimize resource usage, and more than compensate for the performance overhead that comes with the virtualization layer. If however your systems exceed a capacity of 2 processor cores on a regular basis, or are performance sensitive, please go to the next bullet. Systems requiring separate OS, high capacity needs, performance sensitive are well suited to virtual partitions. Typical candidates here are QA systems doing stress tests or training systems for a large number of people. For these systems, vpars are the better alternative, providing higher scalability and better performance. If you find that you ll have several systems that are deployed best on Integrity VM, and only few others that are one OS candidates, you should think about running them all on Integrity VM. You ll need separate npars or separate servers to deploy both models, which might cause more cost than you save by running a few applications on one OS.
Example: Typical System Landscape Approach Building on the heuristics above, an understanding of the spectrum of SAP system deployments, and the various technologies offered by HP s VSE, a better vision of consolidation opportunities can be established. In reviewing the example of SAP systems illustrated in Figure 2, some conclusions may be drawn. For example, production SAP systems typically require dedicated resources, are likely to need more storage and network capacity than other systems, and will benefit from being isolated as much as possible from any potential interruptions caused by other workloads. HP s hard partitioning lends itself immediately to such workloads and can be co-located in the same cabinet as other hard partitions, minimizing data center resource needs and management overhead. Given the potential for dedicated hardware access by formal QA workloads and SAP s CTS host system they appear to be better suited for hardware partitioning. However, they are expected to have low average utilization with periodic peaks in processing power demand. As a result, these systems may be perfectly suited for deploying in HP s virtual partitions. This allows flexibility in allocating processing resources to the workloads while providing dedicated access to hardware components such as network interfaces. Systems with small processing requirements and minimal storage needs while not having stringent performance needs are excellent candidates for hardware sharing. Accordingly, SAP systems for evaluation, training, functional test, and development are well suited for virtual machines. A summary of the above example is shown in Figure 4. There will almost certainly be exceptions to the approach outlined here, but this example will be useful in initial deployments and lends itself to agility in configuration changes that may be required. Figure 4. Typical example of various deployments in the SAP system landscape using HP virtualization and partitioning Hard Partition Production Virtual Partitions Formal Q/A CTS Host Virtual Machines Evaluation Training Functional Test Development Development
Deployment: Application Perspective Generally speaking, deployment of SAP systems on virtualization or partitioning technologies based on the particular application to be used is not recommended. For example, determining that all ERP applications will be deployed on Virtual Partitions doesn t take into consideration the users developers, testers, or production or the historical resource utilization of a given ERP system. Deployment decisions based on what the system is to be used for, as outlined in the previous section, will typically be more efficient in matching virtualization and partitioning technologies to the SAP system being deployed. However, there are some exceptions to this heuristic. Production workloads that do not have stringent response-time characteristics and have a history of low resource utilization may be good candidates for deployment on shared hardware, i.e., virtual machines. Tuning for SAP on HP s Partitioning Continuum Configuration and tuning for SAP systems on any of HP s partitioning or virtualization technologies should be done just as it would be for a standalone server of the same architecture. If a SAP system requires a specific OS version, then install that version of the OS in the partition or virtual machine on which you plan to deploy that SAP system. In the case of Integrity VM, do not configure the underlying physical system s OS for the SAP system. The latter is configured for optimal performance of virtual machines. Apply the SAP system configuration and sizing to the virtual machine. Specifically, define the VM with the memory, processors, and storage required for that SAP system. Then install and configure the operating system and applications on the VM using those same SAP system requirements. For installation of firmware and software for the partitioning or virtualization technology you plan to use, consult the release notes for that technology.
For more information http://www.hp.com/go/vse http://www.hp.com/go/sap SAP Hardware Solutions, by M. Missbach and U. Hoffman, ISBN 0-13-028084-4 Hardware Consolidation with Integrity Virtual Machines, white paper, http://docs.hp.com Best Practices for Integrity Virtual Machines, white paper, http://docs.hp.com Using HP-UX Workload Manager with SAP, white paper available from Information Library section on http://www.hp.com/go/wlm/ 2007 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. SAP, mysap, SAP R/3, SAP NetWeaver, mysap Business Suite, mysap Customer Relationship Management (mysap CRM), mysap ERP, mysap Supply Chain Management (mysap SCM), mysap ERP Human Capital Management (mysap ERP HCM), mysap ERP Financials, mysap ERP Operations are trademarks of SAP AG in Germany and in several other countries. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Microsoft, Windows, and Windows Server 2003 are U.S. registered trademarks of Microsoft Corporation. 4AA1-1513ENW Version 3.0, August 2007