Multiple SAP Dialog Instances on Redhat Linux server?

[Former Member]

Does anyone on here have any insights and/or experiences to share on installing and deploying multiple SAP dialog instances or application servers on a single Redhat Linux server host?

We're looking to possibly move to a mixed or homogeneous SAP system environment, with our DB/CI on big IBM AIX P-series frames, but the app servers on  Dell Intel X86_64 servers running Redhat Linux 5.7.

Given the much more affordable scale of Dell Linux servers, and the high licensing costs of virtualization using VMWare (for example), we'd like to keep things there on a 'bare metal' or physical server level (with absolutely no virtualization).

We remember back in the day before virtualization - having multiple SAP instances and even systems --- also known as 'SAP stacking' ---- on single servers was pretty common. Some projects would have their entire R/3 landscape (Development, QA and sometimes even Production) on a SINGLE physical server, like an HP G-series box or a Sun 10000.

SAP stacking then became less popular with the advent of virtualization.

Now it seems maybe we've come full circle once again with the return of a bare-metal approach to SAP servers. Not surprising, given one medium-sized Dell server, loaded and with the latest Intel E5 processors, could cost less than $10K, or < 10% of the cost of a comparable UNIX server running on RISC processors.

So anyway, back to the point: does anyone on here have any experiences and information to share with regard to installing and deploying multiple SAP dialog instances or application servers on a single Redhat Linux server host?

Are your SAP app servers as such stable? Did you encounter any performance or stability issues?

Any information from anyone on here would be highly appreciated.

Thanks!!

[Former Member · Accepted solution]

We have very similar installations like the one you are planning. DB/ASCS on HP-UX and application servers on SLES linux. Because the linux blades were to big, we put two application servers on each, of course not from the same SID, one for P01 and one for P02.

The systems are very stable, i think we had about two outages for the 8 linux blaces in the last two years and the performance is very good.

If you have noticed, we don't run a CI on the central host, only a SCS instance (message  and enqeue server). This way, you don't have workprocesses on two different platforms.

Cheers Michael

[Former Member · Accepted solution]

Hi, Michael - Thank you very much for the reply!!  How do your multiple SAP instances on the same server handle sharing the same swap space tho, or the same virtual memory areas on disk?

Anyway, we're definitely looking forward to transitioning our SAP app servers to Linux as it's certainly a lot cheaper, and the new Intel E5 processors are incredibly fast!   ( Check them out if you haven't already ... the E5 SandyBridge CPUs are faster than any RISC processor at this point ... at least by our own testing).   We'd like to install multiple app servers on each Redhat Linux server. HOWEVER, our situation is complicated by the fact that we're using SAP CRM 7 --- and as such, leveraging the SAP Virtual Machine Container (VMC) functions rather heavily.

According to SAP KB Article/OSS NOTE# 1674325 [ DEV/SHM directory is used by mulitple instances and prevents startup ] , there are possible risks when using:

• 64 bit Linux
• multiple SAP instances on the same server
• es/implementation=STD (or the 64-bit memory management impllemention for 64-bit Linux, per SAP OSS Note
• multiple Virtual Machine Containers (VMC's) due to having multiple SAP instances on the server (and the fact that SAP CRM WebUI does use VMC pretty heavily)

Has anyone ever run into this sort of situation --- of using multiple SAP instances on the same server, and such 'stacking' not working out too well due to VMC memory issues?

Link to Note # 1674325: http://tinyurl.com/7y2hv5r

[Former Member · Accepted solution]

The swap space is kind of shared, but you don't want to swap out physical memory at any time. On 64-bit systems you will use es/implementation = STD (MAP was implemented only for 32-bit systems).

You have to make sure to have sufficient phyiscal memory and you configure the memory parameters accordingly so that there is no swapping out.

We only use the vmc only on a few systems (not the installation we are talking about here). Thus i am not an expert on vmc, but i think you configure a memory pool (vmcj/option/ps) for it. So this should just be another value you add into your overall memory calculation.

Here is an example (abap stack only):

(SID1 EM 12gb) + (SID1 Heap 8gb) + (SID1 buffers 2gb) + (SID1 vmc 4gb) = 26gb for SID1

If SID2 uses the same configuration we need 52gb for two SAP systems, then add another 10-20% for the operating system. So we end up buying a 64gb box, or as memory is cheap and we want some room for further "tuning" go for 72/96gb. DON'T try to save a few hundred bucks on memory, it's not worth it.

Cheers Michael

[Former Member · Accepted solution]

Hi Ramon,

besides technical operation please consider other service operation topics, such as change or incident management.

If you want to upgrade one of your instances to a new release, it may be needed to update os components as well. This may conflict with the other (old versioned) instance in the same os environment.

Same for incident management - if one instance needs a server reboot due to os buffers full / too many locks / filesystem problems, both instances have to be put offline then. You won't have problems like these when separating os  into several vm instances.

Not to be misunderstood, I follow your approach to save money, but it's important for you to be aware of these things. They should just be considered when planning such a setup.

Regards,

Peter

[Former Member · Accepted solution]

Thank you for all your input and responses, everyone!

We actually met with Redhat Linux representatives and they informed us that OSS Note 1674325 would soon be rendered obsolete and invalid (my suspicions about its inherent contradictions turned out to be correct).

They also told us that while they had SAP customers who were using the 'stacked' approach on bare-metal servers, those customers only did so in NON-PRODUCTION. They were hard put to think of a customer who's actually using SAP application server stacking in a PRODUCTION environment.

[Former Member]

Hello,

We have 8 VMware ESXi hosts (the same concept of the Redhat Hosts) and we have installed SAP systems (ERP, EP, SRM, PI, and BI) in these hosts as a high available installation (not distributed installation). With high available instllation, each DB, ASCS/SCS, and DIs instance is installed in a different VM (RHEL5 + latest update). The performance is grate as well as the availability. W are using it for 1 year with no major problem at all from the SAP level or OS level.

During a stage of hardware upgrading this year, we run ERP, EP, SRM and PI production systems in one host and the proformance was more than enough.

For your information, our hosts servers are HP Blade 460 CG6 with 2 CPUs (6 cores - 2.9 Ghz) and the RAM is 96 MB.

Regards,

Bassel Alkharraz

[Former Member]

Hi,

We have multiple SAP instances on single machine but usage is very minimal and only during the failovers.

In our scenario - we have dialog instance on one of our cluster node and CI+DB comes up on same machine during failovers (During failovers CI+DB and DI runs on same server). Performance problems will be here during failover but based on earlier experiences and other sources (Other DIAs) we don't consider because we have different profiles for normal usage (DIA) and failover usage (CI+DB&DI).

Regards,

Nick Loy