SAP Note 21960 - Several instances/systems on one UNIX computer

Symptom:

• You want to install several SAP systems or at least several SAP system components on a host.

• Apart from SAP software, you want to use software from another manufacturer on a host.

What must I bear in mind?

Other terms

Consolidation, application stacking, liveCache, APO optimizer, database, workload manager, logical partitioning, WLM, lpar

Reason and Prerequisites

It is technically possible to install and operate several SAP systems as well as third-party software on a single host. SAP provides guaranteed support for a configuration containing several SAP systems on the same system under the usual prerequisites. The following cases are typical:

1. Several instances of the same system on one server
You should be able to run several instances of a system on a single powerful host if you want, for example, to fully exploit the main memory. Where possible, you should use a 64-bit system to enable use of the available resources. In some cases it makes sense to install several SAP instances (for example, separation of applications on the instance level, setup of dedicated RFC instances, provision of additional spool work processes before Release 4). Several instances always place higher demands on resources than a single instance because, for example, the shared memory (PXA, Extended Pool) is created several times (possibly in different sizes each time).

2. Several central systems on a server
On large hosts, several small central SAP systems (in other words, database and central instance together) are to be operated.

3. liveCache, APO optimizer, ITS split the server with one or more components.

4. Third-party software is operated together with SAP software on one
server.

Installing different R/3 systems separately or even installing different system components on separate computers has the following advantages:

• simple administration of the individual servers

• high fail-safe

• high flexibility during the upgrade

• unique assignment of resource consumption and performance
  

In general, the following applies:

• A combination of test, consolidation and productive systems on the same host is not recommended because then you can no longer test OS patches or OS kernel parameter changes.

• Avoid a combination of 32-bit and 64-bit databases on the same host. This type of 'mixed' configuration is not provided for in the standard system. For further enquiries about this contact your database partner. Your database partner can tell you which database systems and versions can be installed together on one host.

• Release dependencies and patches: In general, the systems or instances can have different release levels. A restriction arises from the fact that the operating system version has to be compatible with the releases of all SAP systems or the third-party software. We cannot guarantee that different releases of the same or different SAP solutions are released on the same operating system version. Furthermore, we cannot exclude that different SAP solutions may require different, incompatible OS patches. The customer bears the full risk if systems have to run on different operating system versions or patch levels because the requirements for a component have changed.

• If several SAP systems are installed on a host system, they affect each other in terms of stability and performance. However, it is difficult to determine exactly how and when the different systems interact.

• As far as the technical implementation is concerned, simultaneous operation of several systems or instances on a single host is mainly a matter of sizing. This means that the hardware resources required must be planned accurately and adapted to the operating system, database and SAP parameters. These result from the individual demands of the individual user and his or her initial situation.

• The required hardware resources and system parameters must be accurately determined by the implementation partner (for example, the operating system partner, database partner or the SAP Basis adviser) together with the customer.

• Make sure you also read the installation guide for your particular release/operating system/database combination.

• This note does not claim to be complete.

Solution

1. Multiple SAP systems on one host
Using several SAP systems on one computer is particularly challenging in terms of the administration of such configurations. Above all, there will be side effects in terms of release dependencies and patches which are difficult to recognize. The analysis tools provided by SAP can no longer be used without modifications with the configuration of several systems on one host. Therefore, if you want to use proactive SAP services such as "Early Watch'" and "Going Live" for configurations of several SAP systems on one host, you should first inform SAP service about this combination.
If it turns out that performance problems are mainly caused by incorrect sizing during implementation (in other words, by inadequately assigning the individual server resources), SAP cannot be considered to be responsible.

2. Instance numbers
SAP instances are identified uniquely by the host name and the two-digit SAP system number (instance number). The instance numbers must therefore (also in the first case) be different. Instance numbers 98 and 99 are not allowed. With HP-UX 11.0, the port belonging to instance number 75 is already used by the operating system. See also Notes 29972 and 94783 (ERROR => DpShMCreate DpIPCInit).

3. CPU
The required total CPU power for several systems on one host can exceed the sum of the CPU power for the same systems on separate hosts. Ask your hardware partner or operating system partner about mechanisms in the operating system that limit the competing consumption of available CPU power among the individual SAP systems and the third-party software.

4. Main memory
The amount of required main memory (RAM) must be higher than the sum of the same systems on separate hosts.

5. .sapconf file for R3INST
Until Release 3.1, the installation is carried out with R3INST. The available RAM is given in file /usr/sap/trans/.sapconf (and the local copy /etc/sapconf). The sapconf file consists of three parts with the headers "SYSTEM", "INSTANCE" and "PROTOCOL". The storage space available for each SAP system is under "SYSTEM". Similarly, the storage space for each SAP instance is under "INSTANCE" (without database system). The entries are there for documentation purposes only. You do not have to maintain the values for system operation. If you still want to modify them, you should use the R3INST in EDIT mode.
As of Release 4.0, SAP systems are installed with the R3SETUP. The /usr/sap/trans/.sapconf file is no longer used.

6. Swap Space
You can determine the Swap Space requirement for every SAP system using the program SAPPFPAR. The sum of these values, the Swap space of the operating system and other programs gives you the required Swap space on the computer. Make sure you define sufficient Swap space. See Notes 38052, 97179, and 153641.

7. Instance profile
If a system which is already installed should use more or less main memory (RAM) than it does, then you must change the instance profile subsequently. For this, refer to Note 21636. As of Release 4.0, Note 107209 is available for this problem.
Refer to Note 88416 for information about the PHYS_MEMSIZE parameter.

8. Batch operation
Up to Release 3.1, one host was entered for batch processing. Two instances on one computer caused the symptoms described in Notes 110878 and 116082.
As of Release 4.0, the application server the batch job is running on is defined for job planning.

9. Operating system dependencies:

a) Memory management
All relevant SAP releases are (at least on Unix operating systems and Linux operating systems) available in a 64-bit version and should be operated as 64-bit. If you operate the SAP software as 32-bit, refer to the following notes for the operation system-dependent aspects during memory management:

HP-UX: 33576, 37537, 43427,106819, 100410, 113189
TRU-64: 32915, 30606
Windows NT: 28392
AIX: 37537, 78498, 95454
Linux: 386605

b) The SAP hardware partners have tested workload or resource management tools for use in SAP production environments.

c) The option of statically or dynamically partitioning software is also an alternative for the consolidated use of SAP software. Contact your hardware partner to request additional information about products and recommendations. SAP views these server partitions, which are running on one server and upon which several operating systems are running simultaneously using partitioning technology, as a standalone servers. Make sure that sufficient resources are available to the SAP software (see above). If you are dynamically adjusting the CPU and memory resources available to the SAP system, take the cautionary measures mentioned in section 1 of the solution, since certain SAP monitoring tools are not set up for this adjustment.

d) For all usage types, the platform partner or the implementation partner is responsible for the sizing of the integrated solution.
SAP advises against installing test, development and production systems on the same operating system.

10. Databases

a) Informix
Refer to Note 12825 for information about Informix under UNIX.

b) Oracle
If using SQL*NET V1, refer to Notes 37182 and 98252.

c) SAP DB
See Note 327578.

11. liveCache
See Note 392852.

12. APO Optimizer
The APO system uses optimizers in various modules (for example, PP/DS, SNP, ND). These are dedicated programs that have different hardware requirements depending on the release. Optimizers should be installed on dedicated servers.

13. ITS
ITS should be installed on a dedicated server.