System Landscape planning with Global and Local Zones – Part 2
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
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:
System Landscape 1
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
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.
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?
My idea is to make sure my landscape meets technical and operational requirements so that we achieve optimal business continuity.
… 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.
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…
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.
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
- One global zone for all
- Multiple global zones, one for each of the system lifecycle steps (DEV, QAS, PRD, TST and SND)
- Multiple global zones, one for each of our business systems (HR, Finance, Portal and so on) with all installations in it
- 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.
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
Multiple global zones divided by business system
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.