Using SAP with HP Virtualization and Partitioning

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.