This course covers the Design a management, monitoring, and business continuity strategy part of the 70-534 exam, which is worth 20–25% of the exam. The intent of the course is to help fill in an knowledge gaps that you might have, and help to prepare you for the exam.
Welcome back. In this lesson, we're gonna be talking about hybrid and Azure-hosted architectures for System Center deployment.
Now, system center is, as you probably already know, a suite of products that will help with data center management for on-prem and hybrid-cloud environments. The products inside include Configuration Manager, which will allow you to deploy software, protect data, monitor health, and enforce compliance across devices. So this is a product that'll really help with those bring-your-own-device type of scenarios.
System Center also includes Operations Manager, which allows you to monitor the health, capacity, and usage across different applications, workloads, and infrastructures. There's also Virtual Machine Manager, the Data Protection Manager, the Orchestrator, among others.
Now, we're gonna be talking about some of these as we go through the course. If you're running systems on-premises, then you probably already know, about SCOM, which is the abbreviated name for System Center Operations Manager. So SCOM allows us to monitor our systems.
However, if we're going to start adding Azure into the mix, then we need to start thinking about how we're gonna set things up. Now, SCOM could live anywhere, on-prem or in Azure. And because we can host SCOM on-prem or in Azure, we have the flexibility to run it wherever it makes the most sense for our use cases.
At a certain point, you may have more servers running in Azure than on-prem, so it may start to make sense to run SCOM in Azure at that point. However, no matter where you choose to run it, you'll need to consider things such as bandwidth, whether or not you'll be using a VPN, and how you're going to authenticate these servers.
And the answers to each of these questions is going to lead to additional questions. We could go through a lot of potential scenarios. However, since the typical setups that I'm seeing are to run SCOM on-prem, that'll be the base for our discussions.
Just keep in mind, running SCOM on-prem is not a requirement. Let's run through a couple of scenarios where we may need to monitor servers and workloads running in Azure from our on-prem SCOM servers. In the first scenario, we're a company similar to YouTube.
We allow users to upload videos, and other users can consume that content. Now, we have everything running on-prem, except for our analytic SQL database, which is running as an IaaS VM. If we want to monitor this with our SCOM server, we could set up a site-to-site VPN, and then use the SCOM agent on that IaaS VM, and the VM would be domain-joined, which makes authentication easy.
Now, this works really well, because we have just the one IaaS VM that we're monitoring. We do have the additional overhead of setting up a VPN, though that gives us easy conductivity between the on-prem and Azure networks.
This solution will work well since we have that VPN tunnel and makes it simple to start adding any new IaaS servers that we may need to monitor.
Now, you may recall that we pay for and with on egress, which means data leaving Azure, so if you have a lot of servers in Azure being monitored, you're gonna wanna consider the cost. In that scenario, we're using domain authentication.
Now, if that wasn't an option for some reason, what would we do? Let's look at another scenario. In this scenario, where a test company called Test It, a company that allows developers to run their code in a sandboxed environment and have it automatically fuzzed with a proprietary fuzzing tool.
We have an on-prem SCOM server, and our testing servers are running as an IaaS VM. As an additional layer of security, we don't wanna have all these servers as part of our company domain.
However, we still need to monitor them. This is where we can use a SCOM gateway. The SCOM gateway allows us to have a single point of contact between the management server and our agents. It works by allowing the agents to communicate with the gateway, and then the gateway will communicate with the management server.
Now, because we're not using domain authentication, we'll need to use X509 certificates to authenticate the gateway to the management server. As you probably noticed, we have a bit more work to do here because we need to manage those certificates. However, this isn't an uncommon architecture.
While these are the only two scenarios that we're gonna dive into, there are certainly others that we could talk about. Just imagine it, you could use SCOM on-prem to monitor some platform as a service products, as well as using SCOM on-prem to serve as a sort of APM, or application performance monitor.
The reality is that SCOM is a very versatile tool, and knowing what it's capable of and the types of things you'll need to monitor, will help you to understand how best to deploy and configure SCOM for your use case.
Okay, that's gonna wrap up this lesson. In our next lesson, we'll be talking about monitoring more in depth. So we'll be talking about SCOM a bit more in depth, as well as other's monitoring solutions. All right, if you're ready, let's get started.
About the Author
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.