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.
Small size
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).
Medium size
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.
Large size
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)
Very good blog Tom. Interesting discussion. It will be great to have more people giving opinion here.
In my experience I have never seen a customer using 3 Solution Manager systems, even though this is one of the options recommended by SAP depending on the case.
I had only one customer that wanted to implement ChaRM and ITSM (named Service Desk at that moment, release 7.0) using only a productive Solution Manager where System Monitoring was already in place, despite my recommendation of using a Dev, but they had their reasons. You can imagine how much time I spent cleaning stuff after tests..
Having 2 separated SolMan landscapes, one for Technical Monitoring and another for ITSM would prevent the customer to have the nice feature of getting incidents created from alerts automatically in the same SolMan system. And brings more costs since 4 systems must be kept instead of 2 (specially for customers who pay for hosting). But I understand that in large customers it can be an option with some benefits.
Nice that you mentioned the link for the toolkit. This info is requested by every customer where I go.
Cheers,
Raquel
Hi Raquel
Thanks . I hope I get some more opinions and comments, would be interesting.
I don't directly recall any customer with 3 SAP Solution Manager systems either, most stick to a landscape with 2 SAP Solution Manager systems but I assume they are out there .
I know that some SolMan consulting firms advice three SAP Solution Manager systems and it's not necessarily a bad thing as it really seperates out the development / test & live environment but it represents more effort and more maintenance at the same time as well. Since SAP Solution Manager isn't your every day average SAP product but rather a special cause it's not always the best option. I haven't seen too many cases where I found it absolutely necessary to have three SAP Solution Managers so I've adviced against it from time to time.
Something which I didn't mention but what is probably pretty common is a second client on the DEV SAP Solution Manager system for testing purposes such as simiulation a CHARM (DEV, ACC & PRD) environment within SAP Solution Manager. We leverage it to "drink our own champagne" so we've setup incident management & change management (very lean though, not very restrictive) for ourselves and we register incidents regarding SAP Solution Manager and deploy our changes now within SAP Solution Manager through CHARM as well.
We also have some customers with a single productive SAP Solution Manager where parts of ITSM are active (for example Service Desk). The danger is always that if you change something you're doing that in production. Like you say, if you test and create test messages, you'll need to clean them up which brings additional effort along. For large changes (definitely for an upgrade let's say from 7.0 to 7.1) or new implementations we might still clone the system, perform the actions on the clone to ensure it doesn't generate to much impact (we can test) and then perform the configuration on the productive system.
Having two seperated SolMan landscapes indeed creates a gap in terms of interconnectivity of scenario's and applications on SolMan where ITSM crosses the technical realm. Those could still be configured and used but then it would require interfacing which is definitely an increased effort. I've only seen this at a very large customer though where they have a huge amount of SAP systems.
One example is a customer where they experienced issues with Technical Monitoring because of SP stack level of SAP Solution Manager being too low (although it was recently patched) they were missing out on new templates to support a recently patched database. Since they absolutely didn't want to touch CHARM (projects at full speed) a second landscape was created. You're right, it does bring in additional costs, hosting wise but also maintenance wise as you have to keep two SAP Solution Manager systems running and do rework as well since we moved Technical Monitoring from one landscape to the other. It's not a problem for me as long as the customer is aware and informed about this.
Thanks. The toolkit is interesting but it's not the absolute truth either. You often still have to tinker with the system settings / parameters for performance reasons afterwards but getting the initial sizing right helps of course . It depends largely on how intense the end-users use the system and scenario's.
Best regards
Tom
Hi Tom,
Nice article and this area of deciding on number of solution manager and the cost of supporting is always a point of discussion in many clients. And the best suitable option always i have seen is using a 2 Solution manager landscape one Dev & one PRD.
As this way it provides flexibility to integrate The BPM, Project management and ITSM services to get more effectively combined with Technical monitoring and reporting.
Also The on the diagnostic agent part the agent to be installed on fly is a very nice option which i have recently used to monitor non-sap apps in our client environment and the integration of it with solman monitoring.
And the toolkit is indeed a very intresting and helpful link and this was referred by the CA guys often while integration SAP and non-SAP apps.
Awaiting more on this topic as it will surely help basis guys to design and implement Solman in the client environment. Will wait for your next part of this topic.
Regards,
Ram
Until recently we had a 3 system Solman landscape - D->Q->P, but the Q system was nothing but an additional test for upgrade paths. More of an annoyance than anything and just slowed down upgrades, as it wasn't configured the same as the prod SM anyhow (single vs distributed). We would have been better served to build D to mirror P (distributed) and have an accurate representation of how upgrades would work.
We do also have a sandbox system where we can do initial POCs, then implement in D and transport as much as possible to P to keep all of the instances in synch.
D is also nice to have if your environment is segmented internally and you don't want to punch holes into the production environment for monitoring. It's slightly annoying to have to configure in two systems, but really not that much of a burden, especially when weighed against the pain of opening ports and fighting through firewall issues. 🙂
The toolkit was moderately useful to us. Pointed out that Enterprise Manager was the potential bottleneck and not our Solman instance as we had expected.
Bernie
Hi Bernie
Thanks for commenting and giving your opinion. Interesting story about the D -> Q -> P landscape that was changed due to low usage of Q 🙂 .
SolMan really wasn't build from the ground up with D -> Q -> P in mind so it makes it hard to really leverage it that way. Mirroring isn't easy either though because you would then have two pretty big instances I can imagine.
I understand what you're saying on the double configuration need from time to time. Not everything is transportable so it can indeed feel like a lot of additional effort from time to time.
The toolkit is interesting in my opinion. Like you mention, it gives an indication which can be helpful but in the end. It's not the one and only truth though, you still have to look at the actual situation and tune according to what you're seeing / experiencing.
Best regards
Tom
Hi Ram
Thanks for commenting and giving your opinion. Looks like we're getting more and more confirmation that two system landscape is the most common.
Interesting to hear about the usage of the on-the-fly agents for non SAP applications.
Best regards
Tom