Skip to content

Latest commit

 

History

History
125 lines (118 loc) · 7.33 KB

2.6.2. Azure Site Recovery Service.md

File metadata and controls

125 lines (118 loc) · 7.33 KB
Raw

Azure Site Recovery Service

  • DRaaS: Disaster Recovery as a Service
  • Tool for VM replication and migration from anywhere to Azure
  • Containerization of existing applications and infrastructure.
  • Modernization options for apps and databases.
  • Can automatically replicate to Azure or from Azure
    • Supports Hyper-V, VMWare, Windows, Linux VMs
  • Pre-, post scripting with Azure Automation
    • Safeguard complex workloads against outage with
  • Use-cases
    • Use Azure as a secondary site for conducting business during outages.
    • Continuous health monitoring remotely from Azure.
    • Lifting and shifting of servers, apps, databases, and data.
      • Lift and shift: A strategy for moving an application or operation from one environment to another without redesigning the application.
  • Pricing
    • First 31 days free then to Azure (25$), to on-prem(15$) per month for single instance
    • Storage always costs
    • Azure Compute Charges for recovered VMs (if fail-over / migration is done)
    • Outbound data transfer (egress charges, when failing back)
  • *Azure Backup vs Azure Site Recovery
    • You need to have both to have a full business continuity plan.
    • Azure Backup: Copy of data to restore business back to a specific period of time

Azure Site Recovery Deployment Planner

  • A command line tool that gives an excel file
  • Includes on-premises summary, recommendations, VM storage placement, compatible + incompatible VMs, on-premises storage requirement, initial replication batching, cost estimation

Setting up site Recovery

  • Prerequisites:
    • 📝 Minimum permissions: Virtual Machine Contributor, Site Recovery Contributor, write to selected storage account.
    • Create storage account to store replicated VMs
    • Create VNet
    • Plan with Azure Site Recovery Deployment Planner
  • 📝 Steps:
    1. Set up Recovery Services vault
      • Create a resource -> Management Tools -> Backup and Site Recovery
      • It stores your back-ups and recovery points.
      • Backups are protected with Azure Backup (prevention, alerting)
      • 💡 Create or manage a Recovery Services vault in the context of the target service.
      • Central monitoring: Azure VMs + on prem, RBAC
      • Azure Recovery Services vs Back-up Vault
        • You can no longer create Backup vaults, and all existing Backup vaults have been upgraded to Recovery Services vaults.
    2. Set up target environment in Azure
      • Select storage, recovery vault and network
      • LRS or GRS storage is recommended, so the data is resilient if a regional outage occurs, or if the primary region cannot be recovered.
    3. Select a replication goal (protection goal)
      • Recovery Services vaults > vault > Recovery > Prepare Infrastructure > Protection goal
      • Select what you want to migrate e.g.
        • VMware: Select To Azure > Yes, with VMWare vSphere Hypervisor.
        • Physical machine: Select To Azure > Not virtualized/Other.
        • Hyper-V: Select To Azure > Yes, with Hyper-V. If Hyper-V VMs are managed by VMM, select Yes.
    4. Set up the source environment
      • Download and import ASR configuration server and process server into vCenter Server
    5. Replicate the VMs that you want to migrate to Azure
      • You can create replication policy
        • You set how often recovery points will be created.
        • Recovery Services vault -> Site Recovery infrastructure > Replication Policies > +Replication Policy.
      • Enable replication directly
        • In the vault, click +Replicate.
        • Select VMs
      • Everything is copied in storage.
        • 💡 Paging files have a lot of churn and will generate a lot of replication events.
          • You can optimize via:
            • Split the single virtual disk into two virtual disks. One virtual disk has the operating system, and the other has the paging file.
            • Exclude the paging file disk from replication.
          • Pagingfile: a pagefile is a reserved portion of a hard disk that is used as an extension of random access memory (RAM) for data in RAM that hasn't been used recently.
    6. Run test failover: it's no impact migration testing.
    7. Switch production environment to Azure
      • Create a recovery plan
        • Recovery plan describes the way migration will work in the event of a disaster.
        • In recovery plan, you can:
          • Change order of VM starts.
          • Customize fail-over
            • Run scripts via Azure Automation
              • Azure Automation
                • Runs runbooks (piece of script of NodeJs, PowerShell, Python)
                • Has support for modules.
            • Select order
              • Create groups
                • VMs in same group are shut down and booted in the same time
                • Across groups they're booted & shut down sequentially, without groups at the same time
            • Choose VM size and customize other settings by c licking on "replicate items" in recovery plan.
          • Set the target IP address.
            • 💡 If you don't provide an address, the failed-over machine uses DHCP.
          • You can use Hybrid Use Benefit (up to 40% cut for existing Windows Server licenses)
      • Failover to azure on recovery plan
        • Settings > Replicated items -> Click the machine > Failover.
        • Failover & Failback
          • The failover operation is the process of switching production to a backup facility (normally your recovery site)
          • Failover isn't automatic but a manual process.
          • Unplanned failover
            • E.g. natural or IT disaster.
            • Done from latest point with minimal data loss
          • Planned failover
            • You choose the point, zero data loss
            • A failback operation is the process of returning production to its original location after a disaster or a scheduled maintenance period.
              • Failback is a planned failover from Azure to on-premises
            • Flow: Go to vault -> Click on "planned failover" -> choose data synchronization -> Choose between a full download (quicker) or synchronization of delta changes (lesser downtime)
              • Two ways to synchronize data:
                • Full download: A full download is faster but requires the VM to be shutdown which couses more downtime.
                • Minimize downtime: More time to synchronize the changes, but the VM is not shut down so less downtime.
      • After failover, Commit migration for production
        • Choose VMs for fully migration, click on "Complete migration" on recovery plan.

From on-premises to Azure

  1. Set up an Azure storage account
  2. Create a vault
  3. Select a protection goal: To Azure > Not virtualized/Other
    • 💡In Azure Backup it's called Backup Goal
  4. Set up the source environment
    • Recovery > Prepare Infrastructure > Source > +Configuration server > Add Server
    • Download the vault registration key
    • Download & install the Site Recovery Unified Setup installation file.
  5. Set up the target environment: Prepare infrastructure > Target
  6. Create a replication policy to choose when (how often) to replicate
    • Site Recovery infrastructure > Replication Policies > +Replication Policy.
  7. Enable replication
    • ❗ Limitations:
    • 64 bit only.
    • Max disk size: 4TB
    • Max OS size: 2TB but for generation 2 hyper-v it's 200GB