SAP Solution Manager: Technical Monitoring architecture part one
There are a lot of questions and discussions around the Technical Architecture that should be used for Technical Monitoring so I decided to start write blog post series as requested by community members. I want to keep the blog reasonable in length so I’ll write up parts on Technical Monitoring.
A first reasonable question is, how many SAP Solution Manager systems do I need?
This blog represents my opinion. If you have a different opinion, feel free to share and discuss it with the community at large as it can be of interest to all of us so please feel free to comment.
How many SAP Solution Manager systems do I need?
One of the first questions in terms of architecture for Technical Monitoring is “How many SAP Solution Manager systems do I need?”. The answer can differ greatly depending on what your plans are, what you are trying to achieve and how large your landscape is.
A small customer with a small SAP landscape (one ERP system landscape) will often run a single SAP Solution Manager instance. When it comes to Technical Monitoring, it would mean that all systems get connected to this one SAP Solution Manager instance.
Having only one SAP Solution Manager system comes with typical advantages and disadvantages as you would have them in a traditional ERP landscape if you would only have a productive ERP system.
When it is time to update the SAP Solution Manager system, to avoid direct impact, you could clone or copy the SAP Solution Manager system and process the update on the clone or copy to test out the procedure before doing the actual update in a weekend for example (to avoid downtime / impact as much as possible).
Many customers only have two SAP Solution Manager systems so often I see DEV – PRD landscapes at customers as we have a good amount of medium sized customers. This is a very common configuration that I’ve seen.
The discussion starts here with two SAP Solution Manager instances, which SAP systems (talking ERP now), do I connect where? Do I connect all DEV and perhaps ACC systems to the DEV SAP Solution Manager and only PRD systems to the PRD SAP Solution Manager system?
Well, I’ve said this before and about to say it again. SAP Solution Manager wasn’t really designed to have this kind of split so I only connect SAP Solution Manager DEV to itself as well as one or more sandbox ERP systems.
All other systems (DEV, ACC, PREPROD, PRD, …) get connected to SAP Solution Manager PRD in order to benefit from having all that data in one place. One alert inbox for the support team, one single source of truth for reporting purposes, one single source of truth for specific scenario’s that require data and connectivity of all the systems that belong to a specific landscape.
The advantage of having a DEV SAP Solution Manager is that you have a place where you can try scenario’s out, perform support package stacks updates which makes it easier to minimize the impact on the PRD SAP Solution Manager.
You probably guessed I was going to say, large customers have three SAP Solution Manager systems but that’s not the general rule of thumb. It’s a SAP recommendation most likely but that doesn’t mean it’s really a necessity. It can make sense in case you are going heavy on custom development and want to invest in ITSM scenario’s where you really want to have a ACC system in place but what I see is that many SAP customers max out at two SAP Solution Manager instances (DEV, PRD) as their SAP Solution Manager landscape.
Larger customers can have larger landscapes (potentially scaled out). Some have a split landscape where they decide to go DEV1 – PRD1 for Technical Monitoring and DEV2 – PRD2 for IT Service Management and by doing it, separating out those scenario’s from running on the same SAP Solution Manager instance.
Why? Because they want to avoid impact of one scenario on the other scenario so they would like to patch DEV – PRD faster compared to DEV2 – PRD2 for example.
The drawing above shows an example of such a split landscape. You use one SAP Solution Manager landscape for Technical Monitoring purposes while you use a second SAP Solution Manager landscape for IT Service Management purposes. In the IT Service Management landscape, you don’t use diagnostics agent. You only connect the managed SAP systems through RFC connections thus you ignore some red traffic lights in managed SAP system setup. Thet second SAP Solution Manager landscape can be monitored by the first SAP Solution Manager landscape where Technical Monitoring is implemented.
SAP Solution Manager – Diagnostics Agent architecture guide
I haven’t gone into any kind of detail on agents or other elements yet here that make up the architecture. That might be content for a future blog post. In SAP note 1365123 – Installation of Diagnostics Agents there is a guide attached that provides you with insight on possible architectural options for Technical Monitoring. The PDF document goes through numerous possibilities and options whichventures outside of what I covered in this blog post.
I prefer to keep things simple in terms of not cross using elements as you can see in above “simplified” architecture schema’s. Why? Because complexity adds additional effort on multiple fronts, configuration, maintenance, support and troubleshooting to give some examples. The split landscape option translates into more maintenance effort but lower risks and it makes it easier to keep the SAP Solution Manager landscape up to date that is mostly used for technical scenario’s since you don’t impact ITSM processes that way.
Diagnostics agent on the fly as a default
At the moment, I advise to install Diagnostic Agents on the fly (as opposed to a regular, standalone Diagnostic Agent) as a default even if you only have a single SAP system per server because in SAP Solution Manager 7.1 SP12 it is a prerequisite to use automated reconfiguration .
Automated reconfiguration allows the system to reconfigure certain managed system setup steps and some other steps like automatically assigning new, default SAP templates in technical monitoring after the SAP product version has been updated.
If you haven’t seen or read about it yet, you can find a nice presentation on the SCN wiki: http://wiki.scn.sap.com/wiki/display/SMSETUP/Home
where you can also find the Sizing Toolkit which can help you calculate the need for scale-outs for example.
Under 7.1 SP12 (NEW) check out the presentation on Automatic Managed System Reconfiguration (PDF)