Dela via

How Operational Management Suite keeps Customers sticky on Azure - (Site Recovery & Automation)

  • Artikel

In my last post, I spent some time providing an overview of Operational Management Suite (OMS) and talked about the advantages of it from the perspective of truly feeling comfortable with the operational management & monitoring of Infrastructure as a Service (IaaS) within Azure. I also spent some time talking about one of the four services that make up the suite, specifically the Azure Backup service and how it can keep customers sticky within Azure and why that is a great thing.

 

In this post I want to continue the conversation about the different services within the suite, specifically the Site Recovery and Automation services, and how they will add not only to the stickiness for Azure Public Cloud customers but Hybrid Customers as well.

 

Site Recovery

The Site Recovery service is a great way for customers to start leveraging the Cloud while still being very thoughtful about that first foray into the Cloud. Maybe the customer currently has their own Data Center or are using a Co-Lo facility for management of all their infrastructure. The Site Recovery service can provide replication and disaster recovery for Servers or VMs that exist in one place, but may need to be made available someplace else. Originally, this meant that the Servers or VMs had to exist in one physical Data Center and then be replicated or Failed-Over to another Data Center, but now the Site Recovery service can provide this same level of functionality from a Data Center to the Cloud and very soon from one Cloud region to another.

 

What exactly am I talking about here? Let’s go back to my customer example that has a Data Center of their own or they are leveraging a Co-Lo facility. As much as we would love for all Customers to move all of their systems into the Public Cloud, there will always be a need for some systems to remain On-Prem or in a Private Cloud environment.

 

In either instance, this is a single point of failure with respect to a disaster recovery scenario. If that Data Center were to go offline, for whatever reason, all of the customers systems would be down and the company would be unable to function. The Site Recovery service provides Disaster Recovery as a Service (DRaaS) by allowing you to setup a Recovery Plan, such that each VM or Server can be monitored and imaged in such a way that it will be quick and easy to spin up a complete replica of the entire Data Center in either another facility or in the Cloud while keeping all data and configurations of the systems being replicated.

 

Unfortunately, this isn’t a service within Azure that I could easily provide you with a beautiful screenshot, so let me at least provide you with a solid list of features available within the service:

 

  • Can protect Hyper-V, VMware and physical servers
  • <Coordinates and manages the ongoing replication of data by integrating with existing technologies including System Center and SQL Server AlwaysOn
  • Recovery Plans can be as simple or as advanced as necessary based on application requirements, including the execution of custom Windows PowerShell scripts and Azure Automation Runbooks, and pauses for manual interventions
  • Applications can be Migrated to Azure with just a few clicks, or burst to Azure temporarily when you encounter a surge in demand
  • Site Recovery monitors the state of your protected instances continuously and remotely from Azure with all monitoring traffic being encrypted

 

Looking at this Service and all of its available features, not only is this Service a great way for customers to introduce themselves to the Cloud and Azure, but it is also another way for Hybrid Cloud customers to provide a disaster recovery solution for their On-Prem needs while also maintaining infrastructure within the Public Cloud. For further information about this specific service, please take a look at the following documentation and site materials: https://azure.microsoft.com/en-us/services/site-recovery/ & https://azure.microsoft.com/en-us/documentation/services/site-recovery/

 

Automation Runbooks and DSC

As much as we would love them to, Applications, Servers and VMs are rarely able to take care of themselves. There is continual upkeep and tasks that need to be performed over time and there is also the need to make sure that each Server or VM of a specific type is configured in just the right way for the Application(s) to function properly. That is where Azure Automation comes into play and just like the two previous Services that I discussed, it can be used for both your Azure Public Cloud Services as well as your On-Prem environment.

 

Runbooks

If you are or have ever been a Windows System Administrator, then you probably have one or more PowerShell scripts that you are using either through the Windows Scheduler service or you are running them from your own workstations to perform regularly scheduled tasks against your Windows Servers. Even though your Servers may now be in Azure as well, this does not mean that those PowerShell scripts are not relevant. Matter of fact, there are probably some additional scripts that you will need to automate tasks within the Cloud itself and PowerShell is definitely a way to go.

 

Here are just a few of the features that you get from Azure Automation Runbooks:

 

  • Windows PowerShell scripts and workflows—known as Runbooks—help you work smarter by handling the creation, deployment, monitoring, and maintenance of Azure resources and third-party applications
  • Automation Runbook Gallery puts samples, utilities, and scenario runbooks right at your fingertips, so that you can get up and running quickly with your automation tasks
  • Automation Runbooks work with Web Apps in Azure App Service, Azure Virtual Machines, Azure Storage, Azure SQL Database, and other popular Azure services
  • PowerShell parameters, credentials, certificates, and custom modules can all be saved and managed centrally for use within one or many different Runbooks
  • With the availability of Webhooks, the same PowerShell Runbooks that can be triggered manually or through a scheduled job, can be called from outside Azure Automation by other services
  • Hybrid Runbook Worker feature of Azure Automation allows you to run runbooks on machines located in your data center in order to manage local resources
  • Runbooks can be imported, created, or edited through either a Textual or Graphical editor and then tested while all Runbook code is maintained in source code control

 

[caption id="attachment_1263" align="aligncenter" width="300"]Azure Automation Account Summary Azure Automation Account Summary[/caption]

 

[caption id="attachment_1273" align="aligncenter" width="300"]Runbook Graphical Editor Runbook Graphical Editor[/caption]

 

Desired State Configuration (DSC)

The last area to bring all of this together is Configuration Management. There are many ways to provide this type of functionality with both On-Prem and Cloud based environments, but to provide a single location that can provide Configuration Management as well as all of the other services that we have been talking about can only be done through Azure and specifically Azure Automation DSC.

 

With DSC, you put together a PowerShell script that defines what configurations, services, and software should be installed within a given Server or VM and this can be applied to both Windows and Linux VMs alike. However, over time the requirements for the VMs will change and will you want to manage and audit that all VMs have had their configurations applied properly. For example, the following few lines of code will make sure that a Windows Server has IIS installed and that .NET 4.5.1 is installed on top:

WindowsFeature IIS { Name = "Web-Server"      Ensure = "Present" } WindowsFeature InstallDotNet45 {      Name = "Web-Asp-Net45"      Ensure = "Present" }

Without Azure Automation DSC you are required to configure each VM individually with the DSC script and then audit each of those servers manually. With Azure Automation DSC, we provide you with a single interface where you can upload and compile the DSC script for use, configure the VMs with the specific Configuration that should be applied, define a frequency for how often the server should check for changes to the script as well as a central place to audit and validate that the server has all of the correct configurations applied to it.

 

[caption id="attachment_1264" align="aligncenter" width="300"]Automation DSC Node Audit Automation DSC Node Audit[/caption]

 

For more detailed information about all of the capabilities with both Azure Automation Runbooks and DSC, please take a look at the following documentation: https://azure.microsoft.com/en-us/documentation/services/automation/

 

Finally

Now that I have covered three of the four services, I hope that you can see how Azure has made the use of IaaS to be very sticky within our Cloud environment, but also how we can provide you almost all of the standard operational management capabilities that you might need and you won’t need to buy additional software or manage additional VMs that are only being used for maintenance purposes. We can provide you with a single point to manage all of your infrastructure whether it is in Azure or in your own On-Prem environment.

 

In my final post, I will cover the last and in my opinion, the best of the four services within OMS, Log Analytics, which brings everything together by providing a tremendously rich monitoring platform for your IaaS.