AZ-303 - Module 4 - Implement VMs for Windows and Linux

Required resources for IaaS Virtual Machines

Start with the network Name the VM Decide the location for the VM Determine the size of the VM Understanding the pricing model Storage for the VM Select an operating system

VM Required Resources

1. The VM itself 2. Storage account for the disks 3. Virtual network (shared with other VMs and services) 4. Network interface to communicate on the network 5. Network Security Group(s) to secure the network traffic 6. Public Internet address (optional) Azure will create all of these resources if necessary, or you can supply existing ones as part of the deployment process. Each resource needs a name that will be used to identify it. If Azure creates the resource, it will use the VM name to generate a resource name - another reason to be very consistent with your VM names!

Fault domains

A fault domain is a logical group of underlying hardware that share a common power source and network switch, similar to a rack within an on-premises datacenter.

Azure Dedicated Hosts - Groups, hosts, and VMs

A host group is a resource that represents a collection of dedicated hosts. You create a host group in a region and an availability zone, and add hosts to it. A host is a resource, mapped to a physical server in an Azure data center. The physical server is allocated when the host is created. A host is created within a host group. A host has a SKU describing which VM sizes can be created. Each host can host multiple VMs, of different sizes, as long as they are from the same size series.

Resource Groups and Virtual Machines

A resource group is a logical container that holds related Azure resources. In general, group resources based on their lifetime and who will manage them. Place closely associated resources that share the same lifecycle into the same resource group. Resource groups allow you to deploy and monitor resources as a group and track billing costs by resource group. You can also delete resources as a set, which is useful for test deployments. Assign meaningful resource names to simplify locating a specific resource and understanding its role.

IaaS Virtual Machines - Segregate the network

After deciding the virtual network address space(s), you can create one or more subnets for your virtual network. You do this to break up your network into more manageable sections. For example, you might assign 10.1.0.0 to VMs, 10.2.0.0 to back-end services, and 10.3.0.0 to SQL Server VMs.

Storage for the VM

All Azure virtual machines will have at least two virtual hard disks (VHDs). The first disk stores the operating system, and the second is used as temporary storage. You can add additional disks to store application data; the maximum number is determined by the VM size selection (typically two per CPU). It's common to create one or more data disks, particularly since the OS disk tends to be quite small. Also, separating out the data to different VHDs allows you to manage the security, reliability, and performance of the disk independently. The data for each VHD is held in Azure Storage as page blobs, which allows Azure to allocate space only for the storage you use. It's also how your storage cost is measured; you pay for the storage you are consuming.

Scale Set Benefits

All VM instances are created from the same base OS image and configuration. This approach lets you easily manage hundreds of VMs without additional configuration tasks or network management. Scale sets support the use of the Azure load balancer for basic layer-4 traffic distribution, and Azure Application Gateway for more advanced layer-7 traffic distribution and SSL termination. Scale sets are used to run multiple instances of your application. If one of these VM instances has a problem, customers continue to access your application through one of the other VM instances with minimal interruption. Customer demand for your application may change throughout the day or week. To match customer demand, scale sets can automatically increase the number of VM instances as application demand increases, then reduce the number of VM instances as demand decreases. This is known as autoscale. Scale sets support up to 1,000 VM instances. If you create and upload your own custom VM images, the limit is 600 Custom VM instances.

Availability Sets

An availability set is a logical grouping of VMs within a datacenter that allows Azure to understand how your application is built to provide for redundancy and availability. It is recommended that two or more VMs are created within an availability set to provide for a highly available application and to meet the 99.95% Azure SLA. There is no cost for the Availability Set itself, you only pay for each VM instance that you create. In an availability set, VMs are automatically distributed across these fault domains. This approach limits the impact of potential physical hardware failures, network outages, or power interruptions.

Update domains

An update domain is a logical group of underlying hardware that can undergo maintenance or be rebooted at the same time. This approach ensures that at least one instance of your application always remains running as the Azure platform undergoes periodic maintenance. The order of update domains being rebooted may not proceed sequentially during maintenance, but only one update domain is rebooted at a time.

Availability Zones

Availability zones expand the level of control you have to maintain the availability of the applications and data on your VMs. An Availability Zone is a physically separate zone, within an Azure region. There are three Availability Zones per supported Azure region. Each Availability Zone has a distinct power source, network, and cooling. By architecting your solutions to use replicated VMs in zones, you can protect your apps and data from the loss of a datacenter. If one zone is compromised, then replicated apps and data are instantly available in another zone.

Azure Dedicated Hosts

Azure Dedicated Host is a service that provides physical servers - able to host one or more virtual machines - dedicated to one Azure subscription. Dedicated hosts are the same physical servers used in our data centers, provided as a resource. You can provision dedicated hosts within a region, availability zone, and fault domain. Then, you can place VMs directly into your provisioned hosts, in whatever configuration best meets your needs. ✔️Note: Virtual machine scale sets are not currently supported on dedicated hosts.

Azure Disk Encryption

Azure Disk Encryption (ADE) is managed by the VM owner. It controls the encryption of Windows and Linux VM-controlled disks, using BitLocker on Windows VMs and DM-Crypt on Linux VMs. BitLocker Drive Encryption is a data protection feature that integrates with the operating system, and addresses the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned computers. Similarly, DM-Crypt encrypts data at rest for Linux before writing to storage. ADE ensures that all data on VM disks are encrypted at rest in Azure storage, and ADE is required for VMs backed up to the Recovery Vault. With ADE, VMs boot under customer-controlled keys and policies. ADE is integrated with Azure Key Vault for the management of these disk-encryption keys and secrets. ✔️Note: ADE does not support the encryption of Basic tier VMs, and you cannot use an on-premises Key Management Service (KMS) with ADE. Azure Disk Encryption is not available on Basic, A-series VMs, or on virtual machines with a less than 2 GB of memory. Azure Disk Encryption is not available on Generation 2 VMs and Lsv2-series VMs. See: https://docs.microsoft.com/en-us/azure/virtual-machines/windows/disk-encryption-overview

Storage Service Encryption

Azure Storage Service Encryption (SSE) is an encryption service built into Azure used to protect data at rest. The Azure storage platform automatically encrypts data before it's stored to several storage services, including Azure Managed Disks. Encryption is enabled by default using 256-bit AES encryption, and is managed by the storage account administrator. Storage Service Encryption is enabled for all new and existing storage accounts and cannot be disabled. Your data is secured by default; you don't need to modify your code or applications to take advantage of Storage Service Encryption. Storage Service Encryption does not affect the performance of Azure storage services.

What is Azure Storage?

Azure Storage is Microsoft's cloud-based data storage solution. It supports almost any type of data and provides security, redundancy, and scalable access to the stored data. A storage account provides access to objects in Azure Storage for a specific subscription. VMs always have one or more storage accounts to hold each attached virtual disk. Virtual disks can be backed by either Standard or Premium Storage accounts. Azure Premium Storage leverages solid-state drives (SSDs) to enable high performance and low latency for VMs running I/O-intensive workloads. Use Azure Premium Storage for production workloads, especially those that are sensitive to performance variations or are I/O intensive. For development or testing, Standard storage is fine.

What if my VM size needs change?

Azure allows you to change the VM size when the existing size no longer meets your needs. You can upgrade or downgrade the VM - as long as your current hardware configuration is allowed in the new size. This provides a fully agile and elastic approach to VM management. The VM size can be changed while the VM is running, as long as the new size is available in the current hardware cluster the VM is running on. The Azure portal makes this obvious by only showing you available size choices. The command line tools will report an error if you attempt to resize a VM to an unavailable size. Changing a running VM size will automatically reboot the machine to complete the request. If you stop and deallocate the VM, you can then select any size available in your region since this removes your VM from the cluster it was running on.

Decide the Location for the VM

Azure has datacenters all over the world filled with servers and disks. These datacenters are grouped into geographic regions ('West US', 'North Europe', 'Southeast Asia', etc.) to provide redundancy and availability. When you create and deploy a virtual machine, you must select a region where you want the resources (CPU, storage, etc.) to be allocated. This lets you place your VMs as close as possible to your users to improve performance and to meet any legal, compliance, or tax requirements. Two other things to think about regarding the location choice. First, the location can limit your available options. Each region has different hardware available and some configurations are not available in all regions. Second, there are price differences between locations. If your workload isn't bound to a specific location, it can be very cost effective to check your required configuration in multiple regions to find the lowest price.

VM - Select an Operating System

Azure provides a variety of OS images that you can install into the VM, including several versions of Windows and flavors of Linux. As mentioned earlier, the choice of OS will influence your hourly compute pricing as Azure bundles the cost of the OS license into the price. If you are looking for more than just base OS images, you can search the Azure Marketplace for more sophisticated install images that include the OS and popular software tools installed for specific scenarios. For example, if you needed a new WordPress site, the standard technology stack would consist of a Linux server, Apache web server, a MySQL database, and PHP. Instead of setting up and configuring each component, you can leverage a Marketplace image and install the entire stack all at once. Finally, if you can't find a suitable OS image, you can create your disk image with what you need, upload it to Azure storage, and use it to create an Azure VM. Keep in mind that Azure only supports 64-bit operating systems.

Virtual Machines 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. Scale sets provide high availability to your applications, and allow you to centrally manage, configure, and update many VMs. We recommended that two or more VMs are created within a scale set to provide for a highly available application and to meet the 99.95% Azure SLA. There is no cost for the scale set itself, you only pay for each VM instance that you create. When a single VM is using Azure premium SSDs, the Azure SLA applies for unplanned maintenance events. Virtual machines in a scale set can be deployed across multiple update domains and fault domains to maximize availability and resilience to outages due to data center outages, and planned or unplanned maintenance events.

Implementing Scale Sets

Below are considerations for implementing Scale Sets. Initial instance count. Number of virtual machines in the scale set (0 to 1000). Instance size. The size of each virtual machine in the scale set. Azure spot instance. Low-priority VMs are allocated from Microsoft Azure's excess compute capacity, enabling several types of workloads to run for a significantly reduced cost. Use managed disks. Managed disks hide the underlying storage accounts and instead shows the abstraction of a disk. Unmanaged disks expose the underlying storage accounts and VHD blobs. Enable scaling beyond 100 instances. If No, the scale set will be limited to 1 placement group and can have a max capacity of 100. If Yes, the scale set can span multiple placement groups. This allows for capacity to be up to 1,000 but changes the availability characteristics of the scale set. Spreading algorithm. We recommend deploying with max spreading for most workloads, as this approach provides the best spreading in most cases.

IaaS Virtual Machines - Secure the network

By default, there is no security boundary between subnets, so services in each of these subnets can talk to one another. However, you can set up Network Security Groups (NSGs), which allow you to control the traffic flow to and from subnets and to and from VMs. NSGs act as software firewalls, applying custom rules to each inbound or outbound request at the network interface and subnet level. This allows you to fully control every network request coming in or out of the VM.

Deciding When to use Encryption

Computer data is at risk when in transit (transmitted across the Internet or other network), and at rest (saved to a storage device). The at-rest scenario is the primary concern when protecting data on Azure VM disks. For example, someone might download the Virtual Hard Disk (VHD) file associated with an Azure VM, and save it on their laptop. If the VHD is not encrypted, the contents of the VHD are potentially accessible to anyone who can mount the VHD file on their computer. For operating system (OS) disks, data such as passwords are encrypted automatically, so even if the VHD is not itself encrypted, it's not easy for information to be accessed. Applications may also automatically encrypt their own data. However, even with protections, if someone were to gain access to a data disk, and the disk was unencrypted, they might then be able to exploit weaknesses in that application's data protection. With disk encryption in place, such exploits are not possible. Storage Service Encryption (SSE) is part of Azure itself, and there should be no noticeable performance impact on the VM disk IO when using SSE. Managed disks with SSE is the default. Azure Disk Encryption (ADE) makes use of VM operating system tools (BitLocker and DM-Crypt), so the VM must do some work when encryption or decryption on VM disks is being performed. The impact of this additional VM CPU activity is minimal, except in certain situations. For example, if you have a CPU-intensive application, there may be a case for leaving the OS disk unencrypted to maximize performance. Azure provides two complementary encryption technologies that are used to secure Azure VM disks. These technologies, SSE and ADE, encrypt at different layers, and serve different purposes. Both use AES 256-bit encryption. Using both technologies provides a defense-in-depth protection against unauthorized access to your Azure storage, and to specific VHDs.

Create a VM Scale Set in the Azure Portal

Create a public load balancer using the portal. The name and public IP address you create are automatically configured as the load balancer's front end. 1. In the search box, type load balancer. Under Marketplace in the search results, pick Load balancer. 2. In the Basics tab of the Create load balancer page, enter or select the following information: Subscription Select your subscription. Resource group Select Create new and type myVMSSResourceGroup in the text box. Name myLoadBalancer Region Select East US. Type Select Public. SKU Select Standard. Public IP address Select Create new. Public IP address name MyPip Assignment Static 3. Select Review + create. 4. Select Create. Create virtual machine scale set You can deploy a scale set with a Windows Server image or Linux image such as RHEL, CentOS, Ubuntu, or SLES. 1. Type Scale set in the search box. In the results, under Marketplace, select Virtual machine scale sets. The Create a virtual machine scale set page will open. 2. In the Basics tab, under Project details, make sure the correct subscription is selected and then choose Create new resource group. Type myVMSSResourceGroup for the name and then select OK . 3. Type myScaleSet as the name for your scale set. 4. In Region, select a region that is close to your area. 5. Leave the default value of ScaleSet VMs for Orchestrator. 6. Select a marketplace image for Image. In this example, we have chosen Ubuntu Server 18.04 LTS. 7. Enter your desired username, and select which authentication type you prefer. A Password must be at least 12 characters long and meet three out of the four following complexity requirements: one lower case character, one upper case character, one number, and one special character. If you select a Linux OS disk image, you can instead choose SSH public key. Only provide your public key, such as ~/.ssh/id_rsa.pub. You can use the Azure Cloud Shell from the portal to create and use SSH keys. 8. Select Next to move the the other pages. 9. Leave the defaults for the Instance and Disks pages. 10. On the Networking page, under Load balancing, select Yes to put the scale set instances behind a load balancer. 11. In Load balancing options, select Azure load balancer. 12. In Select a load balancer, select myLoadBalancer that you created earlier. 13. For Select a backend pool, select Create new, type myBackendPool, and select Create. 14. Select Review + create. 15. Select Create to deploy the scale set.

Naming the VM - Conventions

Element Environment Example dev, prod, QA Notes Identifies the environment for the resource Element Location Example uw (US West), ue (US East) Notes Identifies the region into which the resource is deployed Element Instance Example 01, 02 Notes For resources that have more than one named instance (web servers, etc.) Element Product or Service Example service Notes Identifies the product, application, or service that the resource supports Element Role Example sql, web, messaging Notes Identifies the role of the associated resource

Scaling Concepts - Horizontal Scaling

Horizontal scaling, also referred to as scale out and scale in, where the number of VMs is altered depending on the workload. In this case, there is a increase (scale out) or decrease (scale in) in the number of virtual machine instances.

Availability Sets - Managed Disk Considerations

For VMs using Azure Managed Disks, VMs are aligned with managed disk fault domains when using a managed availability set. This alignment ensures that all the managed disks attached to a VM are within the same managed disk fault domain. Only VMs with managed disks can be created in a managed availability set. The number of managed disk fault domains varies by region - either two or three managed disk fault domains per region.

Azure Dedicated Hosts - High Availability Considerations

For high availability, you should deploy multiple VMs, spread across multiple hosts (minimum of 2). With Azure Dedicated Hosts, you have several options to provision your infrastructure to shape your fault isolation boundaries. Use Availability Zones for fault isolation Availability zones are unique physical locations within an Azure region. Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking. A host group is created in a single availability zone. Once created, all hosts will be placed within that zone. To achieve high availability across zones, you need to create multiple host groups (one per zone) and spread your hosts accordingly. If you assign a host group to an availability zone, all VMs created on that host must be created in the same zone. Use Fault Domains for fault isolation A host can be created in a specific fault domain. Just like VM in a scale set or availability set, hosts in different fault domains will be placed on different physical racks in the data center. When you create a host group, you are required to specify the fault domain count. When creating hosts within the host group, you assign fault domain for each host. The VMs do not require any fault domain assignment. VMs deployed to hosts with different fault domains, will have their underlying managed disks services on multiple storage stamps, to increase the fault isolation protection. Using Availability Zones and Fault Domains You can use both capabilities together to achieve even more fault isolation. In this case, you will specify the availability zone and fault domain count in for each host group, assign a fault domain to each of your hosts in the group, and assign an availability zone to each of your VMs

Virtual Machine Sizes (Windows and Linux)

General purpose B, Dsv3, Dv3, Dasv4, Dav4, DSv2, Dv2, Av2, DC, DCv2, Dv4, Dsv4, Ddv4, Ddsv4 Balanced CPU-to-memory ratio. Ideal for testing and development, small to medium databases, and low to medium traffic web servers. Compute optimized Fsv2 High CPU-to-memory ratio. Good for medium traffic web servers, network appliances, batch processes, and application servers. Memory optimized Esv3, Ev3, Easv4, Eav4, Ev4, Esv4, Edv4, Edsv4, Mv2, M, DSv2, Dv2 High memory-to-CPU ratio. Great for relational database servers, medium to large caches, and in-memory analytics. Storage optimized Lsv2 High disk throughput and IO ideal for Big Data, SQL, NoSQL databases, data warehousing and large transactional databases. GPU NC, NCv2, NCv3, ND, NDv2 (Preview), NV, NVv3, NVv4 Specialized virtual machines targeted for heavy graphic rendering and video editing, as well as model training and inferencing (ND) with deep learning. Available with single or multiple GPUs. High performance compute HB, HBv2, HC, H Our fastest and most powerful CPU virtual machines with optional high-throughput network interfaces (RDMA). Confidential compute DCsv2-Series Supports a larger range of deployment capabilities, have 2x the Enclave Page Cache (EPC) and a larger selection of sizes compared to the DC-Series VMs.

VM Workload Options

General purpose General-purpose VMs are designed to have a balanced CPU-to-memory ratio. Ideal for testing and development, small to medium databases, and low to medium traffic web servers. Compute optimized Compute optimized VMs are designed to have a high CPU-to-memory ratio. Suitable for medium traffic web servers, network appliances, batch processes, and application servers. Memory optimized Memory optimized VMs are designed to have a high memory-to-CPU ratio. Great for relational database servers, medium to large caches, and in-memory analytics. Storage optimized Storage optimized VMs are designed to have high disk throughput and IO. Ideal for VMs running databases. GPU GPU VMs are specialized virtual machines targeted for heavy graphics rendering and video editing. These VMs are ideal options for model training and inferencing with deep learning. High performance computes High performance compute is the fastest and most powerful CPU virtual machines with optional high-throughput network interfaces. Confidential compute Designed to protect the confidentiality and the integrity of data and code while it's processed in the cloud.

Azure Dedicated Hosts Capacity

Once a dedicated host is provisioned, Azure assigns it to physical server. This guarantees the availability of the capacity when you need to provision your VM. Azure uses the entire capacity in the region (or zone) to pick a physical server for your host.

IaaS Virtual Machines - Plan each VM deployment

Once you have mapped out your communication and network requirements, you can start thinking about the VMs you want to create. A good plan is to select a server and take an inventory: - Which ports are open? - Which OS is used? - How much disk space is in use? - What kind of data does this use? Are there restrictions (legal or otherwise) with not having it on-premises? - What sort of CPU, memory, and disk I/O load does the server have? Is there burst traffic to account for? We can then start to answer some of the questions Azure will have for a new virtual machine.

Naming the VM

One piece of information people often don't put much thought into is the name of the VM. The VM name is used as the computer name, which is configured as part of the operating system. You can specify a name of up to 15 characters on a Windows VM and 64 characters on a Linux VM.

VM - The Pricing Model Options

Pay as you go With the pay-as-you-go option, you pay for compute capacity by the second, with no long-term commitment or upfront payments. You're able to increase or decrease compute capacity on demand as well as start or stop at any time. Prefer this option if you run applications with short-term or unpredictable workloads that cannot be interrupted. For example, if you are doing a quick test, or developing an app in a VM, this would be the appropriate option. Reserved Virtual Machine Instances The Reserved Virtual Machine Instances (RI) option is an advance purchase of a virtual machine for one or three years in a specified region. The commitment is made up front, and in return, you get up to 72% price savings compared to pay-as-you-go pricing. RIs are flexible and can easily be exchanged or returned for an early termination fee. Prefer this option if the VM has to run continuously, or you need budget predictability, and you can commit to using the VM for at least a year. Spot Pricing Purchase unused compute capacity at a discount. Spot VMs are for workloads that can be interrupted, providing scalability while reducing costs. Run workloads on Virtual Machines or Virtual Machine Scale Sets. Azure Hybrid Benefit For customers who have licenses with Software Assurance, which helps maximize the value of existing on-premises Windows Server and/or SQL Server license investments when migrating to Azure.

Azure Dedicated Hosts - Benefits

Reserving the entire host provides the following benefits: Hardware isolation at the physical server level. No other VMs will be placed on your hosts. Dedicated hosts are deployed in the same data centers and share the same network and underlying storage infrastructure as other, non-isolated hosts. Control over maintenance events initiated by the Azure platform. While the majority of maintenance events have little to no impact on your virtual machines, there are some sensitive workloads where each second of pause can have an impact. With dedicated hosts, you can opt-in to a maintenance window to reduce the impact to your service.

Azure Encryption Technologies

The primary encryption-based disk protection technologies for Azure VMs are: - Storage Service Encryption (SSE) - Azure Disk Encryption (ADE) Storage Service Encryption is performed on the physical disks in the data center. If someone were to directly access the physical disk the data would be encrypted. When the data is accessed from the disk, it is decrypted and loaded into memory. Azure Disk Encryption encrypts the virtual machine's virtual hard disks (VHDs). If VHD is protected with ADE, the disk image will only be accessible by the virtual machine that owns the disk. It's possible to use both services to protect your data.

VM - The Pricing Model

There are two separate costs the subscription will be charged for every VM: compute and storage. By separating these costs, you scale them independently and only pay for what you need. Compute costs - Compute expenses are priced on a per-hour basis but billed on a per-second basis. For example, you are only charged for 455 seconds of usage if the VM is deployed for 455 seconds. You are not charged for compute capacity if you stop and deallocate the VM since this releases the hardware. The hourly price varies based on the VM size and OS you select. The cost for a VM includes the charge for the Windows operating system. Linux-based instances are cheaper because there is no operating system license charge. Storage costs - You are charged separately for the storage the VM uses. The status of the VM has no relation to the storage charges that will be incurred; even if the VM is stopped/deallocated and you aren't billed for the running VM, you will be charged for the storage used by the disks.

Azure Dedicated Hosts - Quotas

There is a default quota limit of 3000 vCPUs for dedicated hosts, per region. But, the number of hosts you can deploy is also limited by the quota for the VM size family used for the host. For example, a Pay-as-you-go subscription may only have a quota of 10 vCPUs available for the Dsv3 size series, in the East US region. In this case, you need to request a quota increase to at least 64 vCPUs before you can deploy a dedicated host. Select the Request increase button in the upper right corner to file a request if needed.

Deploy VMs to Dedicated Hosts

This topic guides you through how to create and deploy an Azure dedicated host to virtual machines. Limitations Virtual machine scale sets are not currently supported on dedicated hosts. The sizes and hardware types available for dedicated hosts vary by region. Create a host group You can use one or both of the following options with your dedicated hosts: Span across multiple availability zones. In this case, you are required to have a host group in each of the zones you wish to use. Span across multiple fault domains which are mapped to physical racks. Create a host group Below is a procedure for creating a host group using 1 availability zone and 2 fault domains. 1. Open the Azure portal. 2. Select Create a resource in the upper left corner. 3. Search for Host group and then select Host Groups from the results. 4. In the Host Groups page, select Create. 5. Select the subscription you would like to use, and then select Create new. 6. Type myDedicatedHostsRG as the Name and then select OK. 7. For Host group name, type myHostGroup. 8. For Location, select East US. 9. For Availability Zone, select 1. 10. For Fault domain count, select 2. 11. Select Review + create. 12. Select Create. Create a dedicated host 1. Select Create a resource in the upper left corner. 2. Search for Dedicated host and then select Dedicated hosts from the results. 3. In the Dedicated Hosts page, select Create. 4. Select the subscription you would like to use. 5. Select myDedicatedHostsRG as the Resource group. 6. In Instance details, type myHost for the Name and select East US for the location. 7. In Hardware profile, select Standard Es3 family - Type 1 for the Size family, select myHostGroup for the Host group and then select 1 for the Fault domain. Leave the defaults for the remaining fields. 8. Select Review + create. 9. Select Create. Create a VM 1. Choose Create a resource in the upper left-hand corner of the Azure portal. 2. In the New page, under Popular, select Windows Server 2016 Datacenter. 3. In the Basics tab, under Project details, make sure the correct subscription is selected and then select myDedicatedHostsRG as the Resource group. 4. Under Instance details, type myVM for the Virtual machine name and choose East US for your Location. 5. In Availability options select Availability zone, select 1 from the drop-down. 6. For the size, select Change size. In the list of available sizes, choose one from the Esv3 series, like Standard E2s v3. 7. Under Administrator account, provide a username, such as azureuser and a password. 8. Under Inbound port rules, choose Allow selected ports and then select RDP (3389) from the drop-down. 9. At the top of the page, select the Advanced tab and in the Host section, select myHostGroup for Host group and myHost for the Host. 10. Select Review + create. 11. Select Create.

Two options for managing the relationship between the storage account and each VHD

Unmanaged disks With unmanaged disks, you are responsible for the storage accounts that are used to hold the VHDs that correspond to your VM disks. You pay the storage account rates for the amount of space you use. A single storage account has a fixed-rate limit of 20,000 I/O operations/sec. This means that a storage account is capable of supporting 40 standard virtual hard disks at full utilization. If you need to scale out with more disks, then you'll need more storage accounts, which can get complicated. Managed disks Managed disks are the newer and recommended disk storage model. They elegantly solve this complexity by putting the burden of managing the storage accounts onto Azure. You specify the size of the disk, up to 4 TB, and Azure creates and manages both the disk and the storage. You don't have to worry about storage account limits, which makes managed disks easier to scale out.

Azure Dedicated Hosts - Pricing

Users are charged per dedicated host, regardless how many VMs are deployed. In your monthly statement you will see a new billable resource type of hosts. The VMs on a dedicated host will still be shown in your statement, but will carry a price of 0. The host price is set based on VM family, type (hardware size), and region. A host price is relative to the largest VM size supported on the host. Software licensing, storage and network usage are billed separately from the host and VMs. There is no change to those billable items.

Scaling Concepts - Considerations

Vertical scaling generally has more limitations. It's dependent on the availability of larger hardware, which quickly hits an upper limit and can vary by region. Vertical scaling also usually requires a virtual machine to stop and restart. Horizontal scaling is generally more flexible in a cloud situation as it allows you to run potentially thousands of virtual machines to handle load. Reprovisioning means removing an existing virtual machine and replacing it with a new one. Do you need to retain your data?

Scaling Concepts - Vertical scaling

Vertical scaling, also known as scale up and scale down, means increasing or decreasing virtual machine sizes in response to a workload. Vertical scaling makes the virtual machines more (scale up) or less (scale down) powerful. Vertical scaling can be useful when: A service built on virtual machines is under-utilized (for example at weekends). Reducing the virtual machine size can reduce monthly costs. Increasing virtual machine size to cope with larger demand without creating additional virtual machines.

Auto-Scaling (VMSS)

Virtual machine 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. So, as demand goes up more virtual machine instances can be added, and as demand goes down virtual machines instances can be removed. The process can be manual or automated or a combination of both.

Virtual Machines Scale Sets - Fault domains and update domains

Virtual machine scale sets simplify designing for high availability by aligning fault domains and update domains. You will only have to define fault domains count for the scale set. The number of fault domains available to the scale sets may vary by region.

IaaS Virtual Machines - Start with the Network

When you set up a virtual network, you specify the available address spaces, subnets, and security. If the VNet will be connected to other VNets, you must select address ranges that are not overlapping. This is the range of private addresses that the VMs and services in your network can use. You can use unrouteable IP addresses such as 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16, or define your own range. Azure will treat any address range as part of the private VNet IP address space if it is only reachable within the VNet, within interconnected VNets, and from your on-premises location. If someone else is responsible for the internal networks, you should work with that person before selecting your address space to make sure there is no overlap and to let them know what space you want to use, so they don't try to use the same range of IP addresses.