Azure AZ 300 VMs Study Notes
Azure AZ 300 VMs Study Notes
Study notes for AZ 300 certification for the topic “VMs”
These are notes from: edx Course: Microsoft Azure Virtual Machines
MPIO, NLB. Multipath I/O and Network Load Balancing are not supported on Azure machines.
The smallest recommended virtual machine for a production environments is A1
Which of the following helps you to easily identify which SKU is most likely to satisfy your performance needs : ACU
A Standard_A7 virtual machine would be considered: General Purpose
ACU. The Azure Compute Unit (ACU) provides a way of comparing compute (CPU) performance across Azure SKUs. The ACU is currently standardized on a Small (Standard_A1) VM being 100 and all other SKUs then represent approximately how much faster that SKU can run a standard benchmark.
Ubantu: Enabling RDP
Set up Linux machine for RDP
sudo apt-get update sudo apt-get install lxde sudo apt-get install xrdp echo startlxde > ~/ .xsession sudo /etc/init.d/xrdp start
Enable RDP in Azure
Go to Settings/Networking, Add Inbound Rule: Custom/RDP/OK
Now you can use Windows RDP to remote into the Public IP of the Linux box
On- premises vs Azure VM
Availability set: Logical grouping of one or more vms. Has an Update Domain & an Fault Domain.
Availability Sets often used in conjunction with Scale Sets.
Update Domain: Separate Azure Infrastructure Groups grouped by update cycle
An update domain allows Azure to perform incremental or rolling upgrades across a deployment. Each update domain contains a set of virtual machines and associated physical hardware that can be updated and rebooted at the same time. During planned maintenance, only one update domain is rebooted at a time. By default there are five update domains, but you configure up to twenty update domains.
Fault Domain: Separate Azure Infrastructure groups grouped by hardware (example: server racks)
A fault domain defines a group of virtual machines that share a common set of hardware, switches, and more that share a single point of failure. For example, a server rack serviced by a set of power or networking switches. VMs in an availability set are placed in at least two fault domains. This mitigates against the effects of hardware failures, network outages, power interruptions, or software updates.
Assigning Availability Set to a VM
Scale Sets are an Azure Compute resource you can use to deploy and manage a set of identical VMs. With all VMs configured the same, VM scale sets are designed to support true auto-scale – no pre-provisioning of VMs is required – and as such makes it easier to build large-scale services targeting big compute, big data, and containerized workloads.
Scale set are often integrated with Azure Insight, Load Balancer and NAT rules. Azure Insight is used to measure when to scale up or scale down. The Load Balance and NAT rules work together to spread the workload over the available machines as they are added.
- You can create both Linux and Windows VM Scale Sets from the Azure Portal. These scale sets are automatically created with load balancer NAT rules to enable SSH or RDP connections.
- You can set the maximum, minimum and default number of VMs, and define triggers – action rules based on resource consumption.
- When you increase the number of virtual machines in a scale set, VMs are balanced across update and fault domains to ensure, maximum availability. Similarly when you scale in, VMs are removed with maximum availability in mind.
Rest API Browser
Azure Resource Explorer is a great tool to view and modify resources you have created in your subscription. The tool is web-based and uses your Azure portal logon credentials. The source for the Resource Explorer tool is available on GitHub, which provides a valuable reference if you need to implement similar behavior in your own applications.
This tool is particularly useful in viewing Azure scale sets. With the tool you can see the individual virtual machines and their properties.
Availability Sets Vs Scale Sets
An availability set consists of a set of discrete VMs which have their own names and individual properties, but are spread across fault domains, which means when you have more than one VM in a set it reduces the chances of losing all your VMs in event of a hardware failure in the host or rack.
A scale set consists of a set of identically configured VMs, also spread across fault domains (in fact a scale set is an implicit availability set with 5 fault domains). The main difference is scale sets, being identical, make it very easy to add or remove VMs from the set while preserving high availability, which in turn makes it easy to implement autoscale, and to perform operations on the whole set or a subset of VMs. There are also API calls that support re-imaging and upgrading VMs, allowing you to roll out an update while keeping the service running. They are useful for cloud architectures which require deploying large numbers of similar VMs, or need to be elastic. A typical architecture might use a scale set for agent or worker nodes, and an availability set for master or control nodes. See https://azure.microsoft.com/en-us/services/virtual-machine-scale-sets/ for more detail.
Virtual Machine Storage
Candidates for Standard Storage
Compute centric apps. Examples: Webservers, Domain Controllers
Candidates for Premium Storage
Read write centric apps: SQL Sever, File System writing systems, batch services
Better storage Resiliency with Managed Disks
Unmanaged Disks: If you create a VM availability set and assign it to a VM, that VM will need a storage account, and you need to set up a corresponding number of availability sets for disk storage. (You don’t want to put all VHDs from multiple VMs in a single storage account in a single availability set, as that is a single point of failure). Hence you need multiple storage accounts in multiple Availability Sets.
Managed Disks: Every single storage account is in the same Fault Domain as the VM
Storage Spaces is a technology in Windows and Windows Server that can help protect your data from drive failures. It is conceptually similar to RAID, implemented in software. You can use Storage Spaces to group three or more drives together into a storage pool and then use capacity from that pool to create Storage Spaces. These typically store extra copies of your data so if one of your drives fails, you still have an intact copy of your data. If you run low on capacity, just add more drives to the storage pool.
Create a Storage Pool (in VM Server Manager)
Create a Virtual Disk
Finally Create & Format the Volume
Now you have a new drive F which accumulates the individual disk storage on the Storage Space
Convert Unmanaged to Managed Disk
Deallocate the VM by using the Stop-AzVM cmdlet. The following example deallocates the VM named
myVMin the resource group named
$rgName = "myResourceGroup" $vmName = "myVM" Stop-AzVM -ResourceGroupName $rgName -Name $vmName -Force
Convert the VM to managed disks by using the ConvertTo-AzVMManagedDisk cmdlet. The following process converts the previous VM, including the OS disk and any data disks, and starts the Virtual Machine:
ConvertTo-AzVMManagedDisk -ResourceGroupName $rgName -VMName $vmName
Importing and Exporting Disks
Importing and Exporting Disks
If you want to move on-premises data to Azure Storage (or vice versa), there are a variety of ways to do this. One way is the Azure import and export service.
Azure Import/Export service is used to securely import large amounts of data to Azure Blob storage and Azure Files by shipping disk drives to an Azure datacenter. This service can also be used to transfer data from Azure Blob storage to disk drives and ship to your on-premises sites. Data from one or more disk drives can be imported either to Azure Blob storage or Azure Files.
Supply your own disk drives and transfer data with the Azure Import/Export service. You can also use disk drives supplied by Microsoft.
The Azure Import/Export Service allows you to:
- Import. Securely transfer large amounts of data to Azure blob storage by shipping hard disk drives to an Azure data center.
- Export.Transfer data from Azure blob storage to hard disk drives and ship to your on-premises site.
This service is suitable in situations where you want to transfer several TBs of data to or from Azure, but uploading or downloading over the network is not feasible due to limited bandwidth or high network costs. Scenarios where this would be useful include:
- Migrating data to the cloud. Move large amounts of data to Azure quickly and cost effectively.
- Content distribution. Quickly send data to your customer sites.
- Backup. Take backups of your on-premises data to store in Azure blob storage.
- Data recovery. Recover large amount of data stored in blob storage and have it delivered to your on-premises location.