Skip to content

Latest commit

 

History

History
72 lines (67 loc) · 3.43 KB

5.1. Compute - Virtual machines (VMs) - High Availability.md

File metadata and controls

72 lines (67 loc) · 3.43 KB
Raw

High Availability

  • High Availability = Redundancy
  • Layers of availability
    1. Hardware-level availability
      • Handled by Azure
    2. Server-level availability
      • Availability Sets
        • Ensures 99.95% SLA for VMs in availability set
        • Provides server level fault tolerance within a single data center within a single region.
        • Availability sets are containers/racks that's called Fault Domains.
        • 2 VMs in same Availability Sets = Azure places those in different availability sets.
        • Update domains are different domains in different availability sets (fault Domains) and your VMs are set in different update domains as well.
          • Protects availability against VM shutdowns because of update failures / hardware shutdowns.
        • ❗ Must assign availability set at VM deployment
        • ❗ Scaling (resizing) requires stopping all VMs in the availability set.
        • For single VM not in availability set you have 99.9% availability if you use premium storage.
    3. Datacenter-level
      • Availability Zones
        • Allows you to place redundant VMs in different regions.
        • Provides data center level tolerance.
        • Load balancers are availability zone aware on standard SKU
        • ❗ You have to use managed disks
    4. Region-level
      • You need recovery service vault (storage for back-ups/replications)
        • VM backup
          • Ad-hoc or scheduled
          • Includes all disks and configurations
        • Azure Site Recovery
          • Failover recovery
            • 15 minute RPO (recovery point objective)
            • Azure-to-Azure (A2A) ASR Architecture
              • Directly available in VM blade
              • All storage data, VMs, disks (managed and unmanaged), subnets etc.
                • Prepared and ready to go in another region.
                • In sync
                • ❗ May require configuration with IP addresses
                • You can failover to it and/or failback
            • Configure in VM blade -> Disaster recovery
              • Allows you to configure disaster recovery for single VM
                • For workloads including multiple VMs you should configure it directly from Site Recovery
              • You can choose to automate what happens using Automation runbooks.
              • You can then view recovery status in same blade
                • Replication health
                • Recovery points
                  • Crash-consistent:
                    • Least preferable
                    • As if VM is replicate while it was powered off, no guarantees
                  • App-consistent
                    • Preferable point to recover
                    • Data and OS back
                • Commit -> Finalizes the failover
                • Re-protected -> Creates new recovery environment from old recovery environment (which becomes source environment)
          • Migration to Azure
            • On-premises to Azure
            • AWS to Azure

Azure Advisor

  • Gives recommendation regarding high availability
  • E.g.:
    • Add more virtual machines for improved fault tolerance (medium impact)
    • Enable VM backup to protect your data from corruption and accidental deletion (medium impact)
    • Create an Azure service health alert (low impact)

VM Events

  • Planned maintenance events
  • Unexpected downtime events
  • Notification
    • In Azure support webpage, status webpage, twitter account
    • Administrators get e-mail notifications