This course covers the knowledge domain for designing a management, monitoring, and business continuity strategy in Azure in preparation for the 70-534 certification exam. The course will cover managing resources with systems center, on-premises monitoring, cloud-based virtual machines and applications, patching strategies, business continuity and disaster recovery, as well as a discussion of automation tools.
Welcome back, in this lesson we're going to 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 will really help with those bring your own device type of scenarios.
Now, 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 going to 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 going to 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. Now 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 connectivity between the On-Prem and Azure networks. This solution will work well since we have that VPN tunnel, it makes it simple to start adding any new IaaS servers that we may need to monitor.
Now, you may recall that we pay for bandwidth on egress which means data leaving Azure so if you have a lot of servers in Azure being monitored you're going to want to 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 we're a test company called Test It, a company that allows developers to run their code in a sandboxed environment and have it automatically fuzz 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 security we don't want to have all of 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 X.509 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 going to dive into there's certainly others that we could talk about. Just to mention 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 going to 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.