Managed disk on Azure

You probably already saw this when you are creating a Virtual Machine on Azure. After you insert the basic information like Name of the VM, choose the size, then comes the time to define and configure the settings of that VM. One of the first thing is the Use of managed disk.

But what is managed disks? How they work? What are the implication of using the Managed disks?

So, first thing, Managed Disk allow you to abstract the storage accounts where you will use on your virtual machine (see pictures below). When you select that you want to use managed disk, you don’t have to setup or choose the storage account where those disks will be stored.

When you don’t want to use Managed disks, you have to select the storage account.

With Managed disk, you only have to specify the size of the disk, and Azure manage for you. That allows you more granular access control. You don’t have to care with the storage account limits and you will gain higher scalability, meaning that you can create up to 10000 disks per region per subscription.

Managed disk will increase your resilience for your availability sets, by making sure that the disk will belong to a storage unit that is on a different fault domain. In my experience, when you create storage account, it’s not guarantee that your storage account will be on a different fault domain. That scenario, even if you use availability sets on the setup, doesn’t avoid a single point of failure.

But if you are thinking, that you prefer to use storage accounts, to control the access to the VHDs, with managed disks you can use RBAC as well, to assign the permissions for a managed disk to one or more users. In this scenario, you have to managed disk by disk, and not to the entire storage account. That means more granular access control. You can prevent, for example, a user of copy that vhd, but still use the virtual machine.

The integration with Azure Backup is great. You can use Azure Backup Service with managed disk to create a backup job that will easy your VM restoration. Managed disks although, only support the Locally Redundant Storage (LRS) as a replication option, this mean that 3 copies of the vhd within the region.

To resume, here are the benefits of managed disks:

  • Simple and scalable VM deployment
  • Better reliability for Availability Sets
  • Granular Access control
  • Azure Backup service support

Cheers,

Marcos Nogueira
Azure MVP

azurecentric.com
Twitter: @mdnoga

Azure Site Recovery Planning Considerations – Part 3 – For Hyper-V Virtual Machines in SCVMM clouds

On these post series, I want to cover some of the planning considerations that I usually use, when I’m designing/planning with my costumers, an ASR deployment/infrastructure. I broke down in several posts so I can cover and make easy to find the considerations that you are looking for. In this post, I will cover additional considerations when you need to configure Azure-based protection of Hyper-V virtual machines based on System Center Virtual Machine Manager (SCVMM) Clouds. The general considerations you can find here.

When you are configuring Azure-based protection of Hyper-V virtual machines located in VMM clouds, the following additional considerations apply:

  • You must create virtual machine networks in your VMM environment. You associate virtual machine networks with VMM logical networks, which, in turn, link to private clouds containing protected virtual machines. Once you create virtual machine networks, you must map them to the corresponding Azure virtual networks. This ensures that, following a failover, the network configuration in Azure matches the one that exists in your on-premises environment. By mapping networks, you ensure that replicas of protected virtual machines, which reside on the same on-premises network, also reside on the same Azure virtual network. You can map multiple virtual machine networks to a single Azure virtual network.
  • You have the option to select individual VMM clouds that will appear in the Azure portal. You can choose this option if you want to ensure that the Azure Site Recovery Provider running on the VMM server does not upload all of your cloud metadata to the Recovery Services vault.
  • If you want to ensure that Site Recovery attaches a replica of a protected virtual machine to a specific subnet, then name the Azure virtual network subnet the same as the virtual machine network subnet.
  • The Azure Site Recovery Provider running on the VMM server must have outbound connectivity to Azure via TCP port 443. The Azure Site Recovery Services agent running on each Hyper-V server that is hosting the virtual machines that you want to protect also must have outbound connectivity to Azure via TCP port 443. You must allow access to the following URLs from the VMM server and Hyper-V servers:
    • *.accesscontrol.windows.net
    • *.backup.windowsazure.com
    • *.hypervrecoverymanager.windowsazure.com
    • *.store.core.windows.net
    • *.blob.core.windows.net
    • https://www.msftncsi.com/ncsi.txt
  • Depending on the outcome of your capacity planning, you have the option of adjusting the bandwidth available to the Hyper-V replication traffic on individual Hyper-V hosts. For details regarding this option, refer to the Azure Site Recovery Planning Considerations – Part 1 post.

Cheers,

Marcos Nogueira
azurecentric.com
Twitter: @mdnoga

New version of Azure Backup Server introduces Modern Backup Storage technology

WOW! What a day for me! Microsoft Azure just announces new and improved features on the new version Azure Backup Server. Let’s start!

They announce with Azure Backup Server v2 (MABSv2) you can protect your VMWARE and Windows Server 2016 environment. That is really important feature (in my opinion). Now I don’t need to rely on third party backup software vendors to backup the workloads into Azure, special if the workload is running on ESXi.

Microsoft introduces now thought MABSv2 the Modern Backup Storage technology, based on the features available o Windows Server 2016.

With Windows Server 2016 broth enormous enhancements like ReFS cloning. MABSv2, now leverage these modern technologies, like ReFS cloning and Dynamic VHDX to reduce the overall TCO of backup. MABSv2 also introduces workload infinity technology, that helps to optimize storage utilization.

One of the features that Windows Server 2016 intruded was resilience change checking that improved virtual machine backup resiliency. MABSv2 are now resilient with Resilient Check Technology (RCT) and organizations don’t need to go with painful consistency checks scenarios like virtual machine storage migrations.

MABSv2 can detect and protect VMs that are store on Storage Spaces Direct (S2D), ReFS based cluster seemly without any manual steps. Windows Server 2016 VMs are more secure with shield VM technology and MABSv2 can protect and recovery them securely.

Windows Server 2012 R2 cluster can be upgraded to Windows Server 2016 using rolling cluster upgrade technology without bring down the production environment. MABSv2 will continue to backup the VMs and so there no miss of the SLA while the cluster upgrade is in progress.

You can also auto protect SQL workloads and VMware VMs to cloud using MABSv2. MABSv2, now also comes with the support to protect SQL 2016, SharePoint 2016 and Exchange 2016 workloads as well.

MABSv2 can protect VMware VMs, although the support is in test for MABSv2 running on Windows Server 2016.

MABSv1 deployments can be upgraded to MABSv2 with a few simple steps. MABSv2 will continue to backup data sources without rebooting production servers. So, you don’t need to worry about rebooting production servers or backup interruption with the upgrade to MABSv2.

Cheers,

Marcos Nogueira
azurecentric.com
Twitter: @mdnoga

How to implement Azure Site Recovery

On the previous posts, I did an overview of the Azure Site Recovery service (see here) and talk about the way that I design a disaster recovery solution with ASR (see here). For this post, I want to demonstrate how easy is to implement ASR.

Implementing Azure Site Recovery is a relatively involved process. The implementation steps obviously depend on the design, which in turn is determined by the recovery scenario that you chose as the most suitable for your organization’s business continuity needs.

For example, consider the traditional Azure Site Recovery deployment with the primary site running in an on-premises Virtual Machine Manager environment and a secondary site hosted in Azure. In such a case, your implementation would consist of the following tasks:

  1. Creating one or more Azure virtual networks in your Azure subscription in the Azure region that meets your disaster recovery objectives.
  2. Creating an Azure storage account in the same subscription and the same region as the Azure virtual network.
  3. Creating a Recovery Services vault in the same subscription and the same region as the storage account and the virtual network.
  4. Preparing for the mapping of on-premises virtual machine networks to the Azure virtual networks. You need to make sure that all virtual machines that you intend to protect are connected to the virtual networks that you will be mapping to the Azure virtual networks.
  5. Specifying the protection goal of your implementation. When using the Azure portal, this is the first task in Step 1: Prepare Infrastructure of the GETTING STARTED Wizard. It involves answering the following four questions:
    1. Where do you want to replicate your machines? Select To Azure.
    2. Are your machines virtualized? Select Yes, with Hyper-V.
    3. Are you using System Center VMM to manage your Hyper-V hosts? Select Yes.
    4. Are you managing the recovery site with another System Center VMM? Select No.
  6. Setting up the source environment. This consists of the following steps:
    1. Adding a System Center VMM server entry representing your on-premises VMM environment and selecting the VMM cloud that is hosting the virtual machines that you intend to protect.
    2. Downloading the Azure Site Recovery Provider setup file and Recovery Services vault registration key to the VMM server. Run the installation by using the newly downloaded setup file and, when you receive a prompt, provide the vault registration key. You will also receive a prompt to accept or modify a Secure Sockets Layer (SSL) certificate for encryption of disks uploaded to the Recovery Services vault. Finally, you will have the option to enable synchronization of cloud metadata for all VMM clouds. Optionally, you can select individual VMM clouds that you want to be visible in the Azure portal.
    3. Downloading the setup file for the Azure Recovery Services agent and installing it on each Hyper-V host in the VMM cloud that is associated with the virtual machine network you will be mapping to the Azure virtual network.
  7. Setting up the target environment. As part of this step, you must specify the post-failover deployment model. In this walkthrough, you will choose Resource Manager, but Site Recovery also supports the classic deployment model. At this point, you will also have a chance to verify that you can use the virtual network and the storage account you created earlier to host replicas of protected virtual machines and their disks. You have the option to create the virtual network and the storage account if this is not the case. Finally, you must also configure network mapping between virtual machine networks and the Azure virtual network.
  8. Setting up replication settings. This step involves configuring a replication policy and associating it with the VMM cloud you selected in step 6a. The policy includes settings such as copy frequency, recovery point retention, app-consistent snapshot frequency, and initial replication start time.
  9. Confirming that you have run the Capacity Planner. The wizard will include a drop-down list from which you need to select Yes, I have done it to successfully complete the Preparing infrastructure step.
  10. Selecting the VMM cloud and enabling its replication. This is part of Step 2: Replicate Applications in the GETTING STARTED Wizard. You will need to specify the VMM cloud that you selected in step 6a. You also will need to select the Azure virtual network and the storage account that you want to use to host replicas of protected virtual machines and their disks. You also have the option to choose the target subnet. In addition, this step involves assigning the name to the target virtual machine and choosing its operating system. Finally, you also must choose a replication policy that you want to take effect in this case.

For full details about each of these steps, refer to Replicate Hyper-V virtual machines in VMM clouds to Azure using the Azure portal. Azure online documentation provides detailed guidance regarding other implementation scenarios.

After you configure protection of virtual machines, you should create a recovery plan, which can control the failover sequence by dividing protected virtual machines into groups and by ordering the groups. Virtual machines in the same group fail over in parallel while those in different groups fail over according to their group number. This allows you to account for virtual machine dependencies.

You can use recovery plans to specify the scope of planned, unplanned, and test failovers. Additionally, you can further extend and automate recovery plans by incorporating Windows PowerShell scripts or Azure Automation runbooks.

Cheers,

Marcos Nogueira
azurecentric.com
Twitter: @mdnoga

 

Azure Site Recovery

Azure Site Recovery (ASR) is by far one of the Azure features that I always like to play with. The improvement along the time is above extraordinaire! When I’m talking about Azure and Cloud to costumers I always ask what is their disaster recovery plan. I got a lot of different options. So far, as my best knowledge, I didn’t find any compelling solution then ASR. So what is ASR?

Azure Site Recovery is a disaster recovery and business continuity service that provides two types of functionality: replication and orchestration. Replication handles synchronization of designated systems between a primary site that hosts your production workloads and a secondary site that activates if a disaster occurs. Orchestration provides orderly failover and failback between these two locations.

Most commonly, the primary site is an on-premises location. The secondary site can be another on-premises location or you can implement it in Azure. If you implement the secondary site in Azure, you will use Azure Storage to host disks with content that replicates from computers in the primary site. You also have the option of using Site Recovery in scenarios in which each site represents a cloud-based location, although this applies to migration, not recovery scenarios.

For example, you can migrate virtual machines from a non-Microsoft cloud-hosting provider by setting up Site Recovery with the secondary site in Azure. After you establish the replication between virtual machines in both clouds, you perform a failover. At that point, all the virtual machines will be running in Azure.

In general, Site Recovery allows you to implement solutions that provide protection of both physical and virtual machines, including support for Hyper-V and VMware virtualization platforms. The details of these solutions depend on several factors, including the:

  • Location of the recovery site (on-premises versus Azure).
  • Type of computer to protect (physical versus virtual).
  • Virtualization platform (Microsoft Hyper-V versus VMware vSphere).
  • Virtualization management software (Microsoft System Center Virtual Machine Manager [VMM] versus VMware vCenter).
  • Replication mechanism (Site Recovery–based versus storage area network [SAN]–based replication).

In particular, with Site Recovery, it is possible to implement the following scenarios:

  • Disaster recovery of Hyper-V virtual machines managed by VMM from one on-premises location to another with Site Recovery–based replication.
  • Disaster recovery of Hyper-V virtual machines managed by VMM from one on-premises location to another with SAN-based replication.
  • Disaster recovery of Hyper-V virtual machines managed by VMM from an on-premises location to Azure with Site Recovery–based replication.
  • Disaster recovery of Hyper-V virtual machines not managed by VMM from an on-premises location to Azure with Site Recovery–based replication.
  • Disaster recovery of VMware virtual machines from one on-premises location to another with Site Recovery–based replication.
  • Disaster recovery of VMware virtual machines from an on-premises location to Azure with Site Recovery–based replication.
  • Disaster recovery of physical servers running the Windows and Linux operating systems from an on-premises location to Azure with Site Recovery–based replication.
  • Disaster recovery of physical servers running the Windows and Linux operating systems from one on-premises location to another with Site Recovery–based replication.
  • Migration of virtual machines from one Azure region to another with Site Recovery–based replication.
  • Migration of virtual machines from a non-Microsoft cloud-hosting provider to Azure with Site Recovery–based replication.

Site Recovery–based replication of Hyper-V virtual machines across two on-premises sites takes advantage of Hyper-V Replica, which is a component of the Windows Server operating system that runs on Hyper-V hosts. When replicating Hyper-V virtual machines in cross-premises scenarios, Site Recovery utilizes the Azure Site Recovery Services agent. The agent is a Site Recovery component that you must install on Hyper-V servers that are hosting protected virtual machines.

For replication of physical servers and VMware virtual machines, Site Recovery relies on InMage Scout Unified Agent, which is a Site Recovery component that you must install directly on computers that you want to protect. SAN-based replication is the option that requires non-Microsoft SAN arrays that integrate with the VMM infrastructure. After you implement this integration, you can use SAN-specific capabilities to replicate SAN-resident virtual machine disks between the primary and the secondary sites.

Site Recovery provides a number of capabilities that help you reach your business continuity goals. These capabilities include support for:

  • Storage replication. As the “Overview of Site Recovery scenarios” topic explained briefly, storage replication maintains the synchronization of disks between your production and disaster recovery computers. Hyper-V Replica and the Azure Site Recovery Services agent offer replication frequency in 30-second, 15-minute, or 30-minute intervals. With the VMware InMage Scout agent, replication is continuous. SAN-based replication is also continuous, but you can also to configure it as asynchronous or synchronous. As part of storage replication, it is also possible to generate application-consistent snapshots for single-tier apps or multiple-tier apps.
  • Orchestration of planned failover and failback. With planned failover and failback, orchestration delivers an orderly transition process between your production and disaster recovery environments without any data loss.
  • Orchestration of unplanned failover and failback. In this case, orchestration also allows you to enforce the sequence of individual steps during failover and failback. However, with unplanned failover and failback, there is a potential for data loss.
  • Orchestration of test failover. Test failover typically takes place in an isolated network, making it possible to evaluate your disaster recovery approach without affecting the production environment.

Recovery plan

To implement failover and failback, you must create a recovery plan. A recovery plan identifies protected physical machines and virtual machines, and dictates the order in which Site Recovery performs individual steps during failover and failback. Recovery plans support Azure Automation scripts and workflows in addition to manual steps. This provides a sufficient level of flexibility for more complex disaster recovery scenarios and also helps you achieve your RTO.

Cheers,

Marcos Nogueira
azurecentric.com
Twitter: @mdnoga