Back to Subject

Unit 5 - Notes

INT327 13 min read

Unit 5: Cloud compute resources

1. Virtual Machines (VMs)

Virtual Machines are a foundational Infrastructure as a Service (IaaS) offering in Azure. They emulate a physical computer, providing a virtualized CPU, memory, storage, and networking resources, giving you total control over the operating system (OS) and installed software.

1.1 Core Components of an Azure VM

When you provision a VM, several resources are created and associated with it:

  • Compute:
    • VM Size: Determines the number of vCPUs, amount of RAM, and temporary storage size. Sizes are grouped into series optimized for different workloads (e.g., A-series for dev/test, D-series for general purpose, E-series for memory-intensive apps).
    • Operating System (OS): You can choose from a marketplace of images, including various versions of Windows Server and Linux distributions (Ubuntu, CentOS, etc.), or you can upload your own custom image.
  • Storage:
    • OS Disk: Every VM has one attached disk that contains the operating system. It has a maximum capacity of 4,095 GiB.
    • Temporary Disk: Provides short-term storage for applications and processes. Data on this disk is lost during a reboot, deallocation, or host migration. It is not persistent.
    • Data Disks: Optional persistent storage disks that can be attached to a VM to store application data. You can attach multiple data disks.
    • Managed Disks: The recommended type. Azure manages the storage accounts, providing better reliability, scalability, and security. You just specify the disk type (Standard HDD, Standard SSD, Premium SSD, Ultra Disk) and size.
  • Networking:
    • Virtual Network (VNet): The VM must be placed in a VNet, which provides a private, isolated network in the cloud.
    • Network Interface Card (NIC): A virtual NIC is created to enable the VM to communicate with other resources in the VNet and on the internet.
    • IP Address: The NIC is assigned a private IP address from the VNet's subnet. It can also be assigned a public IP address to be accessible from the internet.
    • Network Security Group (NSG): Acts as a virtual firewall, containing rules to allow or deny network traffic to the VM's NIC or its subnet.

1.2 Use Cases for VMs

  • Lift-and-Shift Migrations: Moving existing applications from an on-premises datacenter to the cloud without re-architecting them.
  • Development and Testing: Quickly provisioning and de-provisioning environments for testing applications.
  • Applications Requiring Total Control: When you need full control over the OS, runtime environment, and specific software installations.
  • Hosting Traditional Applications: Running legacy software or applications like databases (e.g., SQL Server, Oracle) that require a full OS.

2. Configure Virtual Machine Availability

Ensuring your applications remain running during planned maintenance or unplanned outages is critical. Azure provides several mechanisms to configure high availability for VMs.

2.1 Availability Sets

An Availability Set is a logical grouping of VMs within a single datacenter that protects against hardware failures within that datacenter.

  • How it works: Azure distributes the VMs in an Availability Set across multiple physical servers, compute racks, storage units, and network switches.
  • Fault Domains (FDs): A group of VMs that share a common power source and network switch. Spreading VMs across FDs protects against localized hardware failures (e.g., a rack power supply failure). Azure provides up to 3 FDs per region.
  • Update Domains (UDs): A group of VMs and underlying physical hardware that can be rebooted at the same time. Spreading VMs across UDs ensures that not all your VMs are rebooted simultaneously during planned Azure maintenance. You can configure up to 20 UDs.
  • SLA: When you place at least two VMs in an Availability Set, Azure provides a 99.95% uptime SLA.

2.2 Availability Zones

Availability Zones are physically separate datacenters within an Azure region, each with independent power, cooling, and networking. They provide a higher level of availability than Availability Sets.

  • How it works: You deploy your VMs across multiple Availability Zones (e.g., VM1 in Zone 1, VM2 in Zone 2). If one entire datacenter (zone) goes down, the VMs in the other zones remain unaffected.
  • Protection: Protects against datacenter-level failures (e.g., fire, flood, large-scale power outage).
  • SLA: When you deploy at least two VMs across two or more Availability Zones in the same region, Azure provides a 99.99% uptime SLA.
  • Requirement: Requires applications to have their own replication/failover logic (e.g., using a Load Balancer to distribute traffic, SQL Always On for database replication).

2.3 VM Scale Sets

Azure Virtual Machine Scale Sets let you create and manage a group of load-balanced VMs. The number of VM instances can automatically increase or decrease in response to demand or a defined schedule.

  • Purpose: Provides scalability and high availability for large-scale applications.
  • Autoscaling: You can define rules to automatically scale out (add VMs) during high load and scale in (remove VMs) during low load, optimizing for performance and cost.
  • Integration: Works with Availability Zones and Load Balancers to create highly available and scalable architectures.

3. Azure App Service Plans

An Azure App Service Plan represents the collection of physical resources (the "server farm") used to host your web apps, APIs, or mobile backends. It is a Platform as a Service (PaaS) offering.

  • Key Concept: You don't create individual servers. You define a plan with a specific pricing tier and size, and Azure manages the underlying VMs, OS, and patching. Multiple App Services can run on a single App Service Plan.
  • Analogy: An App Service Plan is like a house, and the App Services (your websites) are the people living in it. You pay for the house (the plan), and it can host one or more people (apps).

3.1 App Service Plan Tiers

The tier of an App Service Plan determines the features, performance (CPU/RAM), and cost.

  • Shared Tiers (Free, Shared):
    • Free: For development and testing. Very limited resources, cannot use custom domains.
    • Shared: Low-traffic sites. Runs on shared infrastructure with other customers. Supports custom domains.
  • Dedicated Tiers (Basic, Standard, Premium, PremiumV2, PremiumV3):
    • Provides dedicated compute resources for your apps.
    • Basic: For dev/test or low-traffic production apps. Lacks advanced features like autoscaling and deployment slots.
    • Standard: For production workloads. Adds features like autoscaling, deployment slots, and daily backups.
    • Premium (P1V2/P2V2/P3V2, P1V3/P2V3/P3V3): For high-traffic production apps. Offers more powerful instances, more deployment slots, and advanced networking features.
  • Isolated Tier (Isolated, IsolatedV2):
    • Runs your apps in a completely isolated and dedicated Azure Virtual Network.
    • Provides maximum security and network isolation.
    • Highest cost tier.

4. Configure Azure App Service

Azure App Service is the PaaS service for building, deploying, and scaling web apps and APIs.

4.1 Key Configuration Areas

  • Deployment Slots:
    • Live apps running with their own hostnames. They are not separate App Service instances but are "slots" within one App Service.
    • A common use case is a staging slot and a production slot.
    • Functionality: You can deploy a new version of your app to the staging slot, test it, and then "swap" it with the production slot. The swap operation is near-instantaneous and has zero downtime, as it only redirects traffic.
    • Availability: Available in Standard, Premium, and Isolated tiers.
  • Scaling:
    • Scale Up (Vertical Scaling): Increasing the resources of the App Service Plan itself (e.g., moving from a B1 to an S1 tier). This gives all apps on the plan more CPU, memory, and disk space.
    • Scale Out (Horizontal Scaling): Increasing the number of VM instances running your app (e.g., going from 1 instance to 3 instances). Traffic is automatically load-balanced across all instances.
    • Autoscaling: In Standard tiers and above, you can configure rules to automatically scale out/in based on metrics like CPU percentage, memory usage, or HTTP queue length.
  • Custom Domains & SSL:
    • By default, an app gets a *.azurewebsites.net URL.
    • You can map a custom domain (e.g., www.yourcompany.com) to your App Service.
    • You can secure your custom domain with an SSL/TLS certificate. You can upload your own certificate or use the free App Service Managed Certificate.
  • Deployment Center:
    • Integrates with source control providers like Azure Repos, GitHub, and Bitbucket for continuous integration and continuous deployment (CI/CD).
    • Also supports manual deployment methods like FTP, ZIP deploy, and local Git.

5. Configure Azure Container Instances (ACI)

Azure Container Instances is a serverless container runtime service. It is the fastest and simplest way to run a container in Azure without having to manage any virtual machines or adopt a higher-level orchestration service.

5.1 Key Concepts

  • Serverless: No VM or infrastructure management required. You are billed per-second for the vCPU and memory resources your container uses.
  • Single Container/Pod Focus: Ideal for simple applications, task automation, and build jobs that can run in a single container.
  • Contrast with Azure Kubernetes Service (AKS):
    • ACI: For simple, isolated containers or tasks. No orchestration capabilities.
    • AKS: A full-fledged managed Kubernetes service for orchestrating complex, multi-container applications, with features like service discovery, load balancing, and autoscaling.

5.2 Configuration Steps

When creating a container instance, you specify:

  1. Container Image: The public or private container image to run (e.g., from Docker Hub, Azure Container Registry).
  2. Resource Allocation: The number of vCPUs and the amount of memory (in GB) to allocate to the container.
  3. Networking:
    • Public IP Address: Optionally expose the container to the internet with a public IP and a DNS name label.
    • Ports: Specify which ports to open on the container.
    • VNet Integration (Advanced): Deploy the container instance into a subnet of an Azure Virtual Network for secure, private communication.
  4. Restart Policy: Define what happens if the container stops:
    • Always: (Default) The container is always restarted.
    • OnFailure: The container is restarted only if it exits with an error code.
    • Never: The container is never restarted.
  5. Environment Variables & Volumes: You can inject configuration data via environment variables and mount persistent storage using Azure File Shares.

6. Manage virtual machines with the Azure CLI

The Azure Command-Line Interface (CLI) is a powerful tool for managing Azure resources from the command line.

6.1 Common az vm Commands

  • Create a VM:

    • This is a basic example creating a Linux (Ubuntu LTS) VM.

    BASH
        # Create a resource group first
    az group create --name MyResourceGroup --location eastus

    # Create the VM
    az vm create \
      --resource-group MyResourceGroup \
      --name MyVM \
      --image UbuntuLTS \
      --admin-username azureuser \
      --generate-ssh-keys

  • List VMs:

    BASH
        # List all VMs in a resource group
    az vm list --resource-group MyResourceGroup --output table

    # List all VMs in your subscription
    az vm list --output table

  • Start a VM:

    BASH
        az vm start --resource-group MyResourceGroup --name MyVM

  • Stop a VM:

    • This stops the VM but does not deallocate it. The compute resources remain reserved, and you continue to be billed for them.

    BASH
        az vm stop --resource-group MyResourceGroup --name MyVM

  • Stop and Deallocate a VM:

    • This is the most common way to stop a VM to save costs. It releases the allocated compute resources (vCPU, memory). The public IP is also released unless it's a static IP.

    BASH
        az vm deallocate --resource-group MyResourceGroup --name MyVM

  • Restart a VM:

    BASH
        az vm restart --resource-group MyResourceGroup --name MyVM

  • Resize a VM:

    • Changes the VM size (e.g., to add more vCPU/RAM). The VM must be deallocated first for many size changes.

    BASH
        # See available sizes in a region
    az vm list-sizes --location eastus --output table

    # Resize the VM
    az vm resize --resource-group MyResourceGroup --name MyVM --size Standard_D4s_v3

  • Delete a VM:

    • By default, this deletes the VM resource but leaves the associated OS disk, data disks, and NIC. Use --delete-os-disk to clean up everything.

    BASH
        az vm delete --resource-group MyResourceGroup --name MyVM --yes --no-wait

7. Host a web application with Azure App Service

This is a step-by-step process outlining how to get a web application running on App Service.

  1. Create an App Service Plan:

    • Navigate to the Azure Portal or use the Azure CLI.
    • Choose a name, region, OS (Windows/Linux), and Pricing Tier (e.g., Standard S1 for production). This defines the underlying compute power.

  2. Create an App Service (Web App):

    • Associate this new Web App with the App Service Plan you just created.
    • Give it a globally unique name (e.g., my-unique-webapp-name), which becomes part of its default URL (my-unique-webapp-name.azurewebsites.net).
    • Select a runtime stack (e.g., .NET, Node.js, Python, Java).

  3. Configure Deployment:

    • Go to the "Deployment Center" in your App Service.
    • Choose a source: GitHub, Azure Repos, Bitbucket, etc.
    • Authorize Azure to access your repository and select the specific repository and branch to deploy from.
    • This sets up a CI/CD pipeline. Every git push to the configured branch will automatically trigger a build and deployment to your App Service.

  4. Deploy Code:

    • Push your application code to the configured repository branch.
    • Monitor the deployment status in the Deployment Center.

  5. Test the Application:

    • Once the deployment is successful, browse to the app's URL (*.azurewebsites.net) to see your live application.

  6. (Optional) Configure Custom Domain:

    • Go to the "Custom domains" section.
    • Add your custom domain and follow the validation steps, which typically involve creating CNAME or A records in your DNS provider's settings.
    • Add an SSL binding to secure traffic to your site.

8. Backup Vaults (Recovery Services Vault)

Azure Backup is a service that provides simple, secure, and cost-effective solutions to back up your data and recover it from the Azure cloud. A Recovery Services vault is the management entity that stores backup data for various Azure services, including Azure VMs.

8.1 How It Works

  1. Create a Recovery Services Vault: This is the first step. The vault is a storage entity in a specific Azure region that houses your backup data and recovery points. It also manages backup policies.

  2. Define a Backup Policy: A policy defines the backup schedule and retention duration.

    • Backup Frequency: How often backups are taken (e.g., daily, weekly).
    • Retention: How long recovery points are kept. You can define rules for daily, weekly, monthly, and yearly retention points (e.g., "keep daily backups for 30 days, keep weekly backups for 12 weeks").

  3. Enable Backup for a VM:

    • You associate a VM with a specific vault and a specific backup policy.
    • The first backup is a full backup. Subsequent backups are incremental, meaning they only transfer the blocks that have changed since the previous backup, which saves time and storage costs.

8.2 Key Concepts

  • Snapshots & Recovery Points: Azure Backup takes snapshots of the VM's disks. These snapshots are then transferred to the Recovery Services vault and stored as recovery points.
  • Consistency:
    • Crash-Consistent: The default. The snapshot captures the data on the disk as if the VM had crashed or the power cord was pulled. It doesn't guarantee data in memory is flushed to disk. Sufficient for non-database workloads.
    • Application-Consistent: Uses VSS (Volume Shadow Copy Service) on Windows or pre/post scripts on Linux to ensure that application data is in a consistent state before the snapshot is taken (e.g., transactions are completed, memory caches are flushed). This is critical for databases like SQL Server.
  • Restore Options:
    • Create a new VM: You can restore a backup as a brand-new VM. This is the most common method.
    • Restore Disks: You can restore the VM's disks (VHDs) to a storage account. You can then use these disks to create a custom VM.
    • File-Level Recovery: You can mount a recovery point as a drive and browse/copy individual files and folders without having to restore the entire VM. This is very fast and efficient for small-scale recoveries.
Previous
Unit 4
Next
Unit 6