We have recently announced the GA for our Backup & Site Recovery (OMS) in Azure Resource Manager, and I would like to use this opportunity to level set on what we are bringing, as well as give you some context and a real kick-start into deploying these resources.
Context
Microsoft Operations Management Suite (OMS) made its entry as a Management-as-a-Service offering, delivered entirely from the cloud as a SaaS solution, helping organizations to gain insight into their operations across clouds.
With insight, we got a holistic view of the entire operations from a Windows/Linux point of view, security, identity, malware, updates, configuration changes and much more – regardless of clouds.
This was an important and strategic move for us – knowing that organizations aren’t running entirely from a single datacenter anymore and that the cloud cadence had definitively been forming the landscape and the new demand for management in an entirely new way.
It was about time to reduce the complexity of doing cloud management.
Let us start this blog post by doing a breakdown of Microsoft OMS in the context of Microsoft Azure.
Microsoft Azure
First thing first, we need to emphasize that OMS is a constellation of some first-class citizens in Microsoft Azure.
This is important to know and be aware of, as you will bring this into consideration when you are later planning to deploy OMS into your organization, or behalf of customers if you are a Service Provider.
Microsoft Azure has been undergoing huge changes over the last 14-16 months with the release of Azure Resource Manager (ARM) API – and the new portal (portal.azure.com) that is built upon the new ARM model. For those of you who have been using Azure for a while, you know that the ‘previous’ Azure, also referred to as Service Management API and classic is still there, it is still available, and you can deploy and manage your resources into that model as well.
However, moving forward you will likely focus entirely on Azure in the context of Azure Resource Manager, which also brings consistency ‘down to earth’ with Microsoft Azure Stack.
The reason why I am bringing all this up is to give you a better understanding of where we are coming from and where we are going with OMS in all of this.
OMS is a set of Azure services and during its birth, it was based on the following services in Classic Azure:
- Operational Insight
- Azure Automation
- Azure Site Recovery
- Azure Backup
These were the services you got when you started with OMS.
They would surface into the OMS Workspace and gave you a consolidated view of what was going on.
However, most of the configuration had to take place on the actual resource level in the Azure portal.
In Azure now, they are referred to as:
- Log Analytics (formerly known as Operational Insight)
- Azure Automation (same name, but new capabilities, features and Resource Provider)
- Backup and Site Recovery (formerly known as Azure Backup and Azure Site Recovery, are now sharing the same Resource Provider within ARM)
What does this really mean?
Since these services has reached ARM, this gives us plenty of more opportunities!
In regards to deployment, operations, management, RBAC and much more, we can leverage ARM templates to literally instantiate whatever we need in Azure.
In other words, we can treat our OMS resources just as any first class citizen in Azure.
Each of these Resource Providers have their unique namespace with different resource types.
Log Analytics: “Microsoft.OperationalInsights/workspaces”
Azure Automation: “Microsoft.Automation/automationAccounts”
Azure Recovery Vault: “Microsoft.RecoveryServices/vaults”
Since they are now within ARM, we can take advantage of built-in RBAC capabilities, Tags, policies, resource locks and much more.
It’s also worth mentioning that OMS will likely pull on other Azure services as well, such as Storage Accounts when you want to enable diagnostics on services and ingest this into Log Analytics for further analysis and research, and also globally or locally redundant storage for backup and replication scenarios.
Backup and Site Recovery (OMS)
Historically, there hasn’t been a clear distinguish between backup and disaster recovery for most customers and this has in some situations lead to confusion – while that’s the last thing you need when you are running into a situation where you need to perform either restore or a DR failover.
We want to make this as simple as possible so that you have a one stop solution when you need to manage your backup and recovery scenarios regardless of clouds, locations and workloads with Backup and Site Recovery (OMS).
Let us have a look at the new Resource Provider for Backup and Site Recovery (OMS) within Azure Resource Manager to point out some of the changes we are bringing.
Deployment
For deploying Backup and Site Recovery (OMS), you can use your preferred method whether this is through PowerShell cmdlets, ARM templates or the portal directly.
Portal Experience
- Login to https://portal.azure.com
- Click ‘New’ and search for OMS
- Select ‘Backup and Site Recovery (OMS)’ and click create
- Assign a name to the resource, select Azure region where you want to create the vault and a Resource Group
That’s it! You have now created your Backup and Site Recovery (OMS) vault!
Azure Resource Manager (ARM) template
Simply click on this URL and you will be sent to the Azure Portal where you can specify the input parameters:
PowerShell
- Login to your Azure subscription using Login-AzureRmAccount –credential (get-credential)
- Run the following cmdlet to create a new vault in an existing resource group:
New-AzureRmRecoveryServicesVault -Name MyRecoveryVault -ResourceGroupName OMSRecovery -Location westeurope -Verbose
Or, you can deploy the template from GitHub using PowerShell:
Once deployed, you will be able to use your vault to configure the following scenarios – all from a single pane of glass!
With Site Recovery as part of the Resource Provider, you can now easily configure and setup your DR scenario(s), whether this is protection of HyperV/VMM environments to Azure or between your own datacenters, or VMware/physical. We have invested in the user experience to make it as simple as possible, where we guide you through the correct workflow depending on the scenario you are configuring for.
When you’re in the portal, you can look under ‘All Settings’ for the ‘Getting Started’ section.
If you click on ‘Site Recovery’, we will ask you the right questions to help you configure your Site Recovery scenario.
Here’s a screenshot that shows the applicable steps for configuring protection of Hyper-V virtual machines on-prem to Azure
If you select anything different than showed above, the blades will update and reflect those changes so that you are confident to configure it correctly.
For backup scenarios, we are doing exactly the same, asking you where your workload is running and what you want to protect.
Once you have configured your scenarios, you can manage them later from the same location.
Summary
With all the core components of OMS available within Azure Resource Manager, we can now deploy and manage these resources in a declarative way just as we would do with any other resource in Azure.
Since combining both backup and site recovery in the same resource provider, we believe we have made it much simpler to configure and orchestrate the operations to ensure business continuity for our customers, regardless of clouds, locations and workloads.
You now have a one stop solution for all of this – and we encourage you to get started using the examples provided above to see how Backup and Site Recovery (OMS) can help you to an effective solution for your business continuity plans.
Kristian Nese, Senior Program Manager ECG CAT
(Feel free to join the conversation on twitter, by pinging me at @KristianNese )
Leave a Reply