Core Compute Services Flashcards
Virtual Machines
-Full control and access to the OS, files, configuration, and logs
-Ability to install applications, deploy files, or make changes required for apps
-Can be considerably simpler to migrate (lift-and-shift) existing workloads
-Helps reduce upfront spend, provides additional features, more agile, etc
Architecture
1- Create a Virtual Machine: Parent configuration resource, including name, region, sizing.
-VM Family: Influences the size/resourcing, as well as limits for storage and networking. (General Purpose, Compute/Memory/Storage Optimized, High Performance Compute, and GPU)
–The region you pick is going to influence the sizes you can use
-Fees and Quotas: VMs are charged by the second (for PAYG) so long as the VM is not deallocated
–If your VM is deallocated, you will be charged on disks and public IP, and also it will count towards your “subscription quotas” (your subscription may have a limit on how many VMs of a certain sizes you can launch)
-Configuration and Changes: You cannot change a VMs name or VNet, but the OS disk contains most configuration
- Network: Requires at least on network interface (same region) when deployed
3.Storage: Requires an OS disk, but can also support additional data disks
VM Storage
Types of Disks
OS Disk:
-OS preinstalled to disk
-Can use marketplace image, uploaded VHDs, or custom images
-Disks can be resized, but this requires downtime (stop/deallocate VM)
-Cannot be added/deatached, but they can be swapped
Data Disks:
-Used for persistent storage for applications, files, and other data
-Disks can be resized without downtime (for some VM SKUs)
-You can add/detach data disks without downtime (but you should stop activity)
Temp Disk:
-Temporary storage made available through the hypervisor. Data can be lost
-Temporary fast storage
-Mounted by deafult for both Windows (D drive) and Linux (/dev/sdb1)
-Considered ephemeral (data does not persist) and can be lost on restart
Not all VMs come with a temp disk; size/availability based on VM sku
-They all have to reside within the same region as the vm
-VMs runs on a hypervisor and to get access to the O.S and the data disks, these are stored by “blob storage” behind the scenes, by something called “page blobs”. (managed disks)7
Disk Performance
-Standard HDD: Cheap option supporting backup or non-critical workloads
-Standard SSD: Recommended for low-use enterprise applications, web servers, or dev/test
-Premium SSD: For production workloads that are performance-sensitive and require low latency, high IOPS and throughput
-Ultra Disk: Suits IO-intensive workloads, such as top tier databases, or other transaction-heavy workloads
Virtual Machine Networking
Configuration
- Virtual Machine: VM SKU influences network capabilities ((throughput)performance/limits (NICs))
- Network Interface (NIC): Standalone resource that belongs to a subnet in a VNet (same region)
-We can have multiple NICs on multiple subnets as long as they are in the same VNet - IP Configurations: Configuration of private IPv4/v6 address, and (if any) associated public IP address
-If you want to have multiple private IP addresses, you don’t need to have multiple NICs, just multiple ip configs
Considerations
-You can change IP addresses, and subnets associated with a network interface
-Changing virtual network is not possible. For this, a virtual machine must be recreated
-IPv6 addresses are supported, but must firstly be enabled for the correspoding vnet/subnet
You have two options for getting IP addressing in another subnet:
-You could have multiple network interface cards or you can turn off your VM and move your existing network interface card to another subnet
VM Images and the Compute Gallery
VM images are snapshots or templates of pre-configured virtual machines. They contain an operating system and additional software, allowing you to quickly deploy standardized computing environments.
Marketplace VM images are pre-configured images provided by third-party vendors, often with specialized software and configurations. Generic VM images are more basic and may require manual setup. Marketplace images can save time by offering specific solutions out-of-the-box.
Preparing Images
- Configuration: Configure the VM and operating system as desired (apps, config, data, etc)
- Generalize (or Specialize): Remove user/machine specific information by generalizing the machine
-Specialize is more for on-premise, maybe you have a machine that is configured the way you want to use it and you want to take it to Azure - Capture Image: Create either a Managed Image, or Compute Gallery Image (Enterprise capable functionalities)
-With the Image Gallery, you create an Image Gallery, so you create a definition called “Web Server” and then you get advanced functionality (multiple versions and build numbers for the image, automatic expiry, replication to other regions, etc).
VM Configuration Tools
When we think about how we deploy VMs, we also need to think over the long term, in terms of what tasks are available to us, to configure them, to track the configuration, to get that initial deployment the way we want.
We have spoken about VMs for the initial deployment, but there are additional tools at our disposal that we can help to track and manage configuration over the long term.
-Custom Script Extension: Is a tool (extension) that deploys and runs simple to complex scripts on VMs.
- Script: Stored script to be executed on the VM (e.g Bash, PowerShell, Python, etc).
- VM Extension: Downloads the script and executes a specified command (and arguments)
- Execution: Note that the script only runs once (unless settings have changed)
-Automation State Configuration: Is a platform for ongoing deployment and monitoring of standardize configuration. (track configuration of your VM over the long term)
- DSC Configuration: A declarative model that defines what configuration a device should have. (a text file, where you go and say, “here is what i want my machine to look like”)
- Azure Automation: A location for centralized monitoring and storage of DSC configuration
- VM Extension: DSC Extension orchestrates configuration and reporting using DSC
-Cloud-Init: Industry standard tool for initializing Linux machines across cloud providers.
- VM Provisioning: Cloud-init capabilities are associated with a VM at the time of provisioning
- Custom Data: Supported cloud-init data for configuration or scripting
-What about User Data? Within Azure, this is a newer version of custom data available via IMDS
Virtual Machine Scale Sets (VMSS)
Are a group of identical, load-balanced virtual machines that automatically scale based on demand or a defined schedule. Benefits include high availability, automatic scaling, and simplified management of VM instances in a distributed application.
Uniform Orchestration
1. Uniform VMSS Model: The parent configuration (imagem SKU, networking, upgrade policy, etc) (this is what i want my machine to look like)
2. VMSS Instances: Identical VMs that run within a VMSS based on the VMSS model
-They are VM scale set instances within the scale set
3. Autoscale Rules: Rules look at signals and casue scale-in/out events
Features
Upgrade Policy: “If i make a change to my VM scale set model, what do i want to happen, with out existing VM scale set instances, that are now going to be out of date”
-Automatic: Microsoft will take care of just going and upgrading all of those instances to match the updated model
-Rolling: Provides more control in saying “i want to just update some of these, and then i’ll update some more”
-Manual: Manually upgrade any of those instances
Automatic OS Updates: “If your VM has an update, what do you want to do”
Flexible Orchestration
1. Flexible Model: Used to manage elements of the VMSS, and model
2. Virtual Machines: VMs deployed per the VMSS model, or VMs created in the VMSS. (VMs associated with the scale set and they don’t necessarily match the VMSS model)
-VMs managed directly
-VMs have to be in the same region and resource group
3. Autoscale Rules: Flexible VMSS supports autoscaling, using the VMSS model for new instances
Autoscale Rules
- Metrics-Based Scaling: “If my VM scale set has really high CPU utilization, i want to add additional machines, so i can meet demant”
-Metrics Rules: The trigger for a scale activity (scale-out and scale-in rules)
-Instance Limits: Min/max and default instance count
–Default: Mean that if the system can’t read the metric, it will ensure that you have at least the amount that you put in
- Scheduled Scaling
-Instance Count: Number of instances to scale to
-Schedule: When the scaling should occur
Virtual Machine High Availability
Availability Sets (For Azure Infrastructure faults)
A logical grouping of virtual machines (VMs) within an Azure data center. It helps ensure that during maintenance or hardware failures, not all VMs in the set are affected simultaneously.
- Availability Sets: Logical container that redundant VMs can be created within (not moved to). (VMs that serve the same purpose and not the same infrastructure)
- Fault Domain: A group of physical devices that represent a single point of failure. (We don’t want our machines to all be hosted on the same single point of failure)
-Maximum of 3 - Update Domain: Requires an OS disk, but can also support additional data disks.
-Ensures that if Microsoft are running any platform updates, that is not going to result on our entire sulution going offline as well
-Maximum of 20
-Settings cannot be changed or VMs added
-When FD is set to 1, UD will be 1 also
-Managed Disks should be used (cannot mix)
-Regional VMSS (Implicit Availability Set): FD: 5 - UD: 5
Zone Deployments (For Availability Zone failure)
Proximity Placement Groups
Used to influence the placement of Azure resources such as virtual machines and storage to be close to each other within an Azure data center. (Require low latency connectivity)
- Placement Group: Indicates that datacenter colocation requirements within a region
- Virtual Machines: You can add/remove a mix of VMs, VM Scale Sets, and Availability Sets
- Intent: Specify the VM hardware type (and AZ) you intend to use
VM Encryption with Azure Disk Encryption
Azure Disk Encryption (ADE) is a feature in Azure that helps protect and safeguard your data at rest by encrypting the virtual machine’s OS and data disks.
-Occurs at the O.S layer
Implementation
- Disk(s): All types and tiers supported excluding Ultra disks and Basic VMs
- Volume Encryption: Encryption performed using BitLocker for Windows and d-crypt for Linux
- Azure Key Vault: Encryption secret(and optional key) is stored in Key Vault
-This is where Azure Disk Encryption stores disk encryption keys.
-Grant necessary permissions to the VM to access the Key Vault.
-The encryption secret is required to perform the encryption on the O.S
-The KV must be in the same region as the VM
-You can optionally use an encryption key, also stored within your KV, to go and wrap, or encrypt if you like, the encryption secret itself
Azure App Services
Is a fully managed platform-as-a-service (PaaS) offering, for building, deploying, and scaling web applications and APIs.
-if we want to access our app, we can easily deploy that and use one of Microsoft’s built in domains or use our own custom domains
-Support for SSL encryption
Web, Mobile, API Apps
-You can build web, mobile or API apps (Windows/Linux)
Container Apps
-You can deploy using only code, but if your solution is containerized, you do get support for Docker containers (Windows/Linux).
Static Web
-You can deploy Static Web to keep costs low
-You can use the products “Static Websites” or “Static Web Apps”
Other Apps:
-App Service Environment (ASE) is a special type of app service that you can deploy very isolated to your own VNet
-You can deploy Function Apps to App Service, using the consumption plan, which makes it serverless
-You can deploy Logic Apps to a App Service Environment
Key Considerations
-Reduced overheads (OS admin, security, runtime configuration, etc)
-Managed web hosting platform with supporting features & capabilities
-Supports CI/CD for packaged or containerized solutions
-Simplified auth capabilities (EasyAuth) supporting Azure AD and others
Architecture
Resource Hierarchy
- App Service Plan: The resources, operating system, and features available to your app
-The underlying infrastructure to host your apps
-If you want features like custom domains, SSL, auto scale, all that can be influenced by the Plan you choose - App(s): Runtime environment for your app (container or language/runtime)
-Not all languages and runtimes are supported across all O.S
-You can run multiple apps on a App Service Plan
Azure App Deployments
We need to be careful with how we perform these deployments or it might bring our application offline.
Deployments
- Source: The source code for your app can be stored in a variety of locations
- Build: Source code must be compiled (ideally also tested, etc)
-In a format that can be used by App Service - Deploy: Deploy with Kudu/FTP/WebDeploy. Uses storage available to instances
Deployment Slots
Is the feature that can help us to overcome the issue of potentially causing outages based on updates that we might be performing to our applications
-You need a supported plan to use this feature
- Production Slot: By default, your app is deployed to a “Production” deployment slow
- Additional Slot(s): You can optionally add extra slots to use for development and testing
-To access other slots (staging), it’s going to use the standard DNS entry for azurewebsites.net (app-staging.azure) - Slot Features
-Traffic: Split traffic by a percentage
-Swap: Swap slots forward/back
App Service Networking
Inbound Connectivity
-We can get Service Endpoints > Public Endpoint
-We can get Private Endpoints > Private IPs
-Resource Firewalls talk about inbound access
Outbound Connectivity
When the app service wants to access some resources from that app that exist inside a VNet. We would need outbound access from our app service
VNet Integration:
Providing access directly through our VNet
-We configure it for a subnet
-Easy to enable, if your app is running on the same region as your VNet
-If it’s not in the same region as your VNet, you can still configure it. You’ll have to use a mode called “VNet integration gateway required”, this means that a VPN gateway will have to be deployed to provide
that access
-The App could access on-premises resources through the VNet, but ExpressRoute is not supported
Hybrid Connections
Getting access to on-premises resources or resources that exist in some other network, such as, AWS, GCP, etc.
-It’s using Azure Relay behind the scene
-You’ll have to deploy the “Relay Agent” on-premises
-The agent will use an outbound 443 connection to the Azure Relay service
-You only require outbound connectivity
Plans and Features (SKUs)
Free/Shared - Shared Compute
-Doesn’t support VNet Integration
-Doesn’t support Hybrid Connections
Basic - Dedicated Compute
-Newer deployments support VNet Integration
-Supports Hybrid Connections
Standard - Dedicated Compute
-Newer deployments support VNet Integration
-Supports Hybrid Connections
Premium - Dedicated Compute
-Supports VNet Integration
-Supports Hybrid Connections
App Service Autoscaling
The ability to scale IN or OUT, based on the demand on our solution
-Uses Azure Monitor behind the scenes
Autoscaling Rules
- Metrics-Based Scaling: “If my VM scale set has really high CPU utilization, i want to add additional machines, so i can meet demand”
-Metrics Rules: The trigger for a scale activity (scale-out and scale-in rules)
-Instance Limits: Min/max and default instance count
–Default: Mean that if the system can’t read the metric, it will ensure that you have at least the amount that you put in
- Scheduled Scaling
-Instance Count: Number of instances to scale to
-Schedule: When the scaling should occur
Considerations
-When combined with Applications Insights, additional useful metrics can be used for autoscaling
-It is possible to develop and report upon your own custom metrics from within your application
-You may wish to use metrics from other resources that your solutions uses/relies upon
App Service Security
Encryption
-We can configure SSL for our custom domain (built in domain has SSL preconfigured)
-If you do use a custom domain, you can upload your own certificates and use those
-You can use certificates for outbound connectivity (Your app needs to access an API that’s on-prem or out on the internet)
-Certificates can be used for encrypting the traffic and for authentication to outbound services
Secure Data Storage
-Use Azure KeyVault to store secret information
Network Security
-Use a Web Application Firewall to protect your publicly web app (You’ll be using something like an App Gateway, Azure Front Door Service or Azure CDN)
-Protect agaisnt attacks, such as, SQL Injection or Cross-site scripting
Azure App Service Environment
Azure Functions
