Design Azure Compute Flashcards
Machine series
1) A-series VMs are designed for generic workloads
2) D-series VMs use solid-state drives (SSDs) for temporary storage, providing much faster IO operations
3) DS-Series VMs are designed for high I/O workloads. They use SSDs for both VM drives and a local drive cache
4) G series of VMs is one of the biggest on cloud with Xeon E5 V3 family processors
Temporary Disks
Both OS drives and data drives are virtual hard drives (VHDs) stored in Azure Blob Storage. Their data is automatically duplicated three times for reliability. However, the temporary drives reside on the hosting servers. If the host fails, your VM will be moved to a healthy host, but not the temporary drive. In this case, you’ll lose all temporary data.
Managing images
the Azure VM gallery, VM Depot, and custom images. You can use these images as foundations to create, deploy, and replicate your application run-time environments consistently for different purposes such as testing, staging, and production.
Capturing custom images
1) two types of images: generalized or specialized.
2) A generalized image doesn’t contain computer or user-specific settings. These images are ideal for use as standard templates to rollout preconfigured VMs to different customers or users. Before you can capture a generalized image, you need to run the System Preparation (Sysprep) tool in Windows, or use the waagent –deprovision command in Linux.
Capturing generalized images
Before you can capture a generalized image, you need to shut down the VM. After the VM is captured as an image, the original VM is automatically deleted.
Specialized images
Specialized images, conversely, retain all user settings. You can think of specialized images as snapshots of your VMs. These images are ideal for creating checkpoints of an environment so that it can be restored to a previously known good state. You don’t need to shut down a VM before you capture specialized images. Also, the original VM is unaffected after the images are captured.
Problems with Custom images
1) difficult to revise a custom image
2) difficult to track what has been changed on an image because of the manual customizations.
3) To deploy a new image version, the VM needs to be re-created, making upgrade a lengthy and complex proces
VM extension
1) a light-weight Azure Virtual Machine Agent (VM Agent) is installed on the VM by default.
2) to dynamically customize VMs to satisfy your application, configuration, and compliance needs
Custom Script Extension and DSC
Custom Script Extension downloads and runs scripts you’ve prepared on an Azure Blob storage container. You can upload Azure PowerShell scripts or Linux Shell scripts, along with any required files, to a storage container, and then instruct Custom Script Extension to download and run the scripts.
Azure Automation
monitor events in VMs as well as external services such as Azure App Service Web Apps, Azure Storage, and Azure SQL Server. Then, workflows can be triggered in response to these events.
Chef and Puppet
Both Chef and Puppet install agents on your VMs. These agents monitor your VM states and periodically check with a central server to download and apply updated cookbooks.
Runbook gallery
Automation’s cookbooks, called runbooks, are implemented as Azure PowerShell Workflows. To help you to author these runbooks, Azure has created an Azure Automation Runbook Gallery where you can download and share reusable runbooks
Infrastructure code
“infrastructure” indicates that it’s not business logics but instructions to configure the application runtime. Second “code” indicates that it’s not subject to human interpretation but can be consistently applied by an automation system.
Devops and infrastructure code
1) Infrastructure code is explicit and traceable, and it makes an application consistently deployable.
2) Consistently deployable applications are one of the key enabling technologies in the DevOps movement.
Azure Resource Template
1) JSON files that capture infrastructure as code. You can capture all the Azure resources your application needs in a single JSON document that you can consistently deploy to different environments.
2) All resources defined in an Azure Resource Template are provisioned within a Resource Group, which is a logical group for managing related Azure resources.
Containerization
1) consistently deploy applications by packaging them and all their required resources together as a self-contained unit.
2) check them in to a repository, manage their versions, and reconcile their differences just as how you would manage source code.
Containers agility
1) containers are much more light weight because containers use process isolation and file system virtualization
2) Containers running on the same VM share the same system core so that the system core is not packaged as part of the container.
3) Because starting a new container instance is essentially the same as starting a new process, you can start containers quickly—usually in time frames less than a second
Containers Compute Density
1) achieve much higher compute density in comparison to using VMs
2) can provide cheaper and more agile compute services to your customers
Decouple Compute and Resource
1) workloads running in them are not bound to specific physical servers or VMs.
2) With containers, servers are no longer assigned with specific roles. Instead, they form a cluster of CPUs, memory, and disks within which workloads can roam almost freely.
Container orchestration
1) Docker Swarm, CoreOS Fleet, Deis, and Mesospher
2) foundation of container-based PaaS offerings by providing services such as coordinated deployments, load balancing, and automated failover.
Container orchestration properties
1) ideal hosting environment for applications that use Microservices architecture.
2) can join multiple containers together to form a replica set for the service
Automate container
can automate container cluster provisioning by using a combination of Azure Resource Template, VM Extensions, Custom Script Extension, and scripts. The template describes the cluster topology, and VM extensions perform on-machine configurations. Finally, automated scripts in containers themselves can perform container-based configurations.
Scaling applications on VMs
1) Scale up
2) Scale out
Scaling-up
1) increasing the compute power of the hosting nodes.
2) increase the capacity of the servers by increasing memory, processing power, or drive spaces.
3) constrained by the number of hardware upgrades you can fit into the physical machines.
4) In the cloud, choose a bigger VM size.
5) constrained by what VM sizes are available.
scaling-out
1) brings in more hosting nodes to share the workload.
2) no theoretical limit
3) possible for an application to be scaled to very high capacity
3) preferable scaling method for cloud applications.
Internal Load Balancers (ILB)
1) for multitiered applications
2) to scale-out middle tiers that aren’t directly accessible from the Internet.
3) have a website as the presentation layer, and a number of VMs as the business layer.
4) don’t want to expose the business layer, and thus you made it accessible only by the presentation layer
Internal Load Balancers (ILB) properties
1) not publically accessible
2) can access them only by other roles in the same Cloud Services, or other VMs within the same virtual network.
3) ILB provides an ideal solution for scaling a protected middle tier without exposing the layer to the public.
Autoscale
1) VMs manually in a Cloud Service.
2) Can also set up autoscale rules to dynamically adjust the system capacity in response to average CPU usage or number of messages in a queue.
3) you need to add the VMs to an Availability Set.
Autoscale policy items
1) Edit Scale Settings For Schedule
2) Scale By Metric
3) Instance Range
4) Target CPU
5) Scale Up By
6) Scale Down By
Autoscaling after the First Hour
Because autoscaling uses the average value of the past hour, it’s not triggered as frequently as you might have expected.
