Azure-in-bullet-points

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.
       • Availabiliy sets are containers/racks that’s called Fault Domains.
       • 2 VM’s in same Availability Sets = Azure places those in different availability sets.
       • Update domains are different domains in different availability sets (fault Domains) and your VM’s are set in different update domains as well.
       • Microsoft automatically assigns Virtual Machines across 2 fault domains (physical servers) and 5 update domains to minimize uptime during planned and unplanned outages by default. The maximum number of FD is 3 and the maximum number of UD is 20.
         • 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 VM’s 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, VM’s, 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 VM’s you should configure it directly from Site Recovery
             • You can choose to automate what happens using Automation rubooks.
             • 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 enviroment (which becomes source nevironment)
         • 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 ccidental 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

This site is open source. Improve this page.