First I start with some basic stuff which is to be found on many good blogs. Just as an introduction. I won’t take a deep dive. So bear with me.
The Beginning
Security in OpsMgr is not an option. It is a requirement. The Management Servers need to authenticate themselves and the same rule applies to the monitored servers/workstations (AKA mutual authentication). In order to make it more secure, this authentication process is encrypted as well. In a forest, or another forest with a full trust in place with the forest where the OpsMgr Management Group resides, Kerberos takes care of it. This is an automated process which doesn’t need any real attention. Until now the only thing I bumped into was a time-skew which was more than the allowed 5 minutes. But when the Network Time Servers are set right AND functional that shouldn’t be a problem either.
So how to go about it when one wants to monitor servers/workstations residing in a non-trusted environment? Certificates are needed in order to take care of the authentication process. These certificates need to be rolled out to ALL workstations or one could install an OpsMgr Gateway Server in the non-trusted environment. Now only the Gateway Server (and the OpsMgr Management Server that it reports to of course) needs a Certificate instead of all servers/workstations. The servers/workstations use Kerberos and the Gateway Server uses its certificate when communicating with the OpsMgr Management Server it reports to.
So you end up with something like this: 
What? Yeah, I know about the tools AKA ‘Certification Generation Wizard’. With these two tools one can easily mass-obtain the needed certificates (tool number one, CertGenWizard.exe) and easily install the obtained certificates (tool number two, CertInstaller.exe) on the servers/workstations. But this posting isn’t about that. Its about OpsMgr Gateways! :)
So far so good.
The welcome side-effect: Compression
Even though the amount of data send directly from ,lets say 100 OpsMgr Agents, to a Management Server is the same as it is routed through an OpsMgr Gateway Server and then sent to an OpsMgr Management Server, the difference in rate of compression is staggering! When using an OpsMgr Gateway Server all data is routed through that single server. So the compression has much more bigger chunks of data to process and as we all know, compression works the best on bigger files. The same story happens here. The more OpsMgr Agents are reporting to a single OpsMgr Gateway Server, the bigger the rate of compression is. As stated in this posting, a R2 OpsMgr Gateway Server can handle 1500 Agents! So there is a big win to be found in such a situation!
How to use it to its fullest extend?
Even though most OpsMgr Gateway Servers are deployed to monitor many servers/workstations in non-trusted environments, these very same servers can also be used to save bandwidth of the WAN connection in trusted environments. So a Gateway Server can be deployed in the same trusted environment where the OpsMgr Management Group resides. In such a scenario certificates aren’t needed and Kerberos will kick in and do its job.
Suppose you have multiple sites residing in the same forest. But the sites are separated by WAN connections, the best way to go about it is to deploy the OpsMgr Management Group (RMS, MS and SQL server(s)) on one site. This will keep the performance of the OpsMgr Management Group in good order. The Management Servers can access directly the SQL server(s). And in the other sites where monitoring also needs to be done, Gateway Servers are deployed.
Now you end up with something like this: 
Of course, when a site contains many servers/workstations which need to be monitored ONE OpsMgr Gateway Servers introduces a SPOF (Single Point Of Failure). But gladly enough that issue can be addressed as well. Anders Bengtsson has written a very good posting about how to do just that.
Rounding up:
As you can see OpsMgr Gateway Servers can be used in different ways and scenarios. Try to use this server role to its best and you’ll be surprised about how flexible OpsMgr can be when implemented correctly.
No comments:
Post a Comment