Skip to Content

In my System Landscape planning with Global and Local Zones – Part 1 blog post on the topic of “System Landscape Planning“, I started with the differences in System Virtual Machines and Zoning (aka Partitioning, aka Domains). In this part of the blog, I will now dive into thoughts about how to separate the individual systems and instances that make a SAP Business Suite 7 landscape.

 

System Landscape setup

Components

I will first introduce the individual components that our fictional system landscape is comprised of. Let us assume we have to deal with the following lines of business systems:

 

business landscape
 
There is a finance oriented system, an HR system, a reporting system (which could be a BW, maybe with BO), a central portal (with which the users can logon and make use of different business scenarios as provided by the other systems), an integration bus like PI, that acts as a SOA middleware and the all necessary support system (that is Solution Manager).
 
 
Now, of course these systems are really not single installations, but essentailly a whole bunch of systems. In the SAP world we typically find a 3 system landscape for each of the named business systems and we should also have at least a 2 system landscape for the support systems.
 
That means, we have at least a DEV (development), a QAS (test and qualification – sometimes also referred to as validation) and a PRD (productiv) system. We usually also find a lot of further test and sandbox systems where individual groups, mostly within IT itself, do their integration and development tests. I call those systems TST (test) for SAP Basis and SND (sandbox) for application development.
 
 
So with these systems added, regardless of a real need, we would get a landscape that could look like this:
 

System Landscape 1

image

 

I can hear it, and yes, you are absolutely right – that’s rubbish. Nobody would create a 5 system landscape for each of the business systems, let alone for support systems or simple reporting installations. So let’s see how a more realistic landscape could be setup:

 

System Landscape 2

image

 

I stripped some of the systems where I’d say, there is no need for – like QAS SolMan or a TST and SND reporting installation. I also changed the setup for the integration system (PI). 

We are nearly there, but now we probably have to add some extra components, like application servers for the java portal, dialog instances for the business systems. One system should definately be put in it’s own instance and that is the global, central System Landscape Directory (SLD).

 

For my scenario I decided to add an additional productive portal and the mentioned central SLD. With these two additional components we finally come up with the landscape as shown below.

 

System Landscape 3

image

 

As you can see, we now have

  • a 5 system landscape with test and sandbox systems for Finance and HR
  • a 3 system landscape for reporting based on BW
  • a 4 system landscape for the central login portal plus a second productive instance
  • a 2 system landscape for the PI installation together with an independent sandbox system for special tests and tryouts
  • a 2 system landscape for the Solution Manager
  • one central productive SLD (other components may host their own SLDs)

 

If you ask me, that is a quite common example of a typical, although rather small, SAP system landscape. If you like you can also add CRM, SCM or SRM systems to this scenario. Those would probably also setup in a 4 or maybe even 5 system landscape. and would therefor not really add up to this (already quite complex) scenario.

 

Why separation at all?

In regards to Markus’ post (see below), I think I should give a little more explanation before diving deeper into dividing my landscape.

My idea is to make sure my landscape meets technical and operational requirements so that we achieve optimal business continuity.

 

Technical

… is about hardware resources. On the one side, we want to make sure that we do not waste too much resources of any kind, while on the other side we need to make sure, that our systems are not overly competing for the resources like CPU, RAM and bandwidth.

Operational

Every computer system needs maintenance. The OS kernel might need to be patched, or a specific version of a shared library might need to be supplied. When doing so, it might be necessary to reboot the system.
 

Business continuity

Separating lines of business systems gives us the opportunity to deal with different development cycles within our SAP systems. In line with the above two points, we can also make sure, that maintenance in one line is not affecting our other systems.

 

I hope we achieved a common understainding of why separation might be a good idea – although I will point out some more later on..

 

Hardware VS. Virtualization/Zoning

Given the above layout, let’s think about separating those instances. Of course, you could simply go on and put each of those systems on a single dedicated server – maybe a blade system with Windows or Linux on it. But, does that make sense?I’d say no.

 

Just think about the waste on CPU, RAM and bandwidth in such a scenario. Each of those colored squares (there are 29 of those), would resemble in a single hardware box – that would count up to at least 29 servers. That’s 29 times power, cooling, operating system and and and …

 

I think you get it. It would be an incredible waste on energy and on manpower to run 29 individual boxes for all these systems within our business suite landscape.

 

If we want to avoid having shelves full of systems that most of their time are idling into the day, we should make use of a virtualization concept like System Virtual Machine or Zoning –  I use the name Zoning as a common name, for Domain, Logical Partition or other tradenames, that more less all refer to the same technology. Again see, my System Landscape planning with Global and Local Zones – Part 1 about this.

 

Zoning vs. System VM?

This is an important question. As you’ve seen, you can choose between System Virtualization or Zoning. So we have to decide on an architectural pattern wich allows us to separate the systems involved. As mentioned in my previous System Landscape planning with Global and Local Zones – Part 1blog post, both scenarios have their pros and cons.

 

If you go for System Virtual Machines, you can provide different hardware and/or OS types to different systems. Question is just, do you need this?

Drawback of course is an increased demand for computing resources.

A pro on the other hand could be the relative easy setup of such a system – believe me, VMWare ESX is pretty easy as opposed to logical partitions (LPARS) in, say, AIX, at least for a Linux guy like me 😉

 

If you go for zoning, your OS and hardware type is fixed on what you have actually installed in the global zone. Is this a problem for you? I don’t think so.

 

Of course the above discussion is mostly pure academic in nature. Usually we are not in a green field situation where we can start from scratch. Not all operation systems and/or hardware installations in use support both patterns and we are very rarely in the good situation where we are allowed to throw out all the old stuff and start up from scratch.

 

That said, let’ go for…

 

Zoning

Anyway of your particular taste, I’d like to point out some possibilities of using zoning as the separation concept. I do so partly because of personal taste but partly also because it can be applied to commodity and Unix-hardware alike and there is a big installation base out there that is not on Windows or Linux, but on one of the classical Unixes like Solaris, AIX or even HP-UX.

 

Basis for my example is a Solaris 10 installation on a Primepower 1500 which supports hardware partitioning – but you can also adapt that concept to other OS’ or hardware, as I keep it general enough – I hope.

 

 

Remember the idea behind zoning was to provide individual computing environments that can share specific services or inherit things like the base OS installation from their respective global zone.
 

 

Possible Scenarios

Basically I’d like to show you four possibilities or scenarios on how to layout your global zone with the individual local zones for our business systems

  1. One global zone for all
  2. Multiple global zones, one for each of the system lifecycle steps (DEV, QAS, PRD, TST and SND)
  3. Multiple global zones, one for each of our business systems (HR, Finance, Portal and so on) with all installations in it
  4. a combination of the above two

Single global zone concept

In this first layout there is only one global zone which hosts all local zones for the SAP installations.

image

 

In this setup all systems share the same hardware ressources and inherit the OS patch level of the global zone.

 

This layout has a serious drawback to it. If there is work done on the global zone, say implement a patch in the OS kernel, all local zones are affected at once. That means, you could end up with your whole SAP landscape being shutdown. There is also no possibility to test certain scenarios as all our systems are instantly affected by changes on the global zone.

 

It, on the other hand is probably the easiest to setup and maintain and we do not have to think about hardware ressources being split across our landscape. That means, we do not waste resources with systems, that are just idling around – as Markus points out in his comment below.

But I’d say, on the other hand, we can’t make sure, that serious performance issues within our development environment won’t affect our productive systems, for example!

 

Multiple global zones divided by technical usage

To circumvent the last point, usage of hardware ressources in our development environment have a negative effect on our productive landscape, you could separate your global zones with a pure technical view.
 
image
 
 
Here we create multiple global zones. There is one global zone for all DEV systems, one for all QAS systems, for all PRD systems and so on…
 
 
This would give us the opportunity to do changes to the underlying OS, say in the test environment without affecting our other systems. This is good, as it gives us the chance to test OS patches (for example) first, before actually rolling them out in our landscape.
 
 
We can also make sure, by pinning certain global zones to system boards, that a runaway process within one of our development system, won’t affect our productive environment.
 
 
Sounds good, doesn’t it? Well, I’d say there is still a drawback to it. We are dealing with different systems for different business cases here and who says, that HR und finance system do have the same necessities, with regard to the underlying OS? It might also end u, that we do waste too much of our precious hardware resources and that’s not good as well.

 

Multiple global zones divided by business system

If we want to make sure, that we can provide individual environments to our different business systems, maybe we could/should setup our layout according to this?
 
image
 
Here we have different global zones, one for each of our business systems, again with all the installations in that specific landscape in it. With this setup we can make sure, that every line of business is happily isolated from each other.
 
This setup gives us the opportunity to do all sort of maintanance within one line of business without affecting the other lines.
 
But wait, that brings us back to the problems we faced with one global zone. Now we can’t make sure that say DEV HR is not affecting PRD HR – grrh!
 
 

 

Multiple global zones, divided by technical and business need

You probably already knew right from the start, it’s a combination of both above layouts that seems to be the most promising.

We are dividing the hardware system into multiple global zones by technical, operational and business needs. 

image  
 
As you can see, we create one global zone for all the DEV systems. Next we create a second global zone for all test and sandbox systems and finally we create individual global zones for the QAS and PRD installationof each business system.
 
 
You might ask yourself, why did I choose exactly this layout? Why did I not, for example, choose to create even more global zones? Now, each global zone hosts an individual global OS installation and that takes up some ressources, so I want to reduce the overhead on the one side, while still making sure, that my business functions are siloed as much as possible.
 
 
Of course there are endless ways of how to create a setup and your individual needs will differ. First of all, you could aim for a more easy setup, or, second you could also put a different weighting on the technical or operational requirements. Anyway, this is our setup and it works for us.
 
 
I hope some of the information in this blog post was helpful to you and gave you a bit of a head start  into the whole zoning concept and what you can do with it.
 

Kind regards,

 

    Christian Günther

 

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Markus Doehr
    …although I have made the best experiences mixing PRD, QA, Test and sandbox system on a global zone. Otherwise you’ll end in a PRD system with heaps of load and QA and Test system with few or almost no load.

    This enables us to almost even distribute the load across the boxes.

    Used together with Sun Cluster (>= 3.2) you can even “move” the zones between different physical machines if you need to.

    Btw: we use x86_64 hardware for this.

    Markus

    (0) 
    1. Christian Günther Post author
      Hi Markus,

      thank you very much for your reply and sharing your thoughts. I incorporated your remarks into an update to my post.

      I have a question however, you said, your running on Solaris for X86_64 – do you use LDOMS?

      Kind regards,

         Christian

      (0) 

Leave a Reply