Downloaded 23 times
!["name": "MyUbuntuVM",
"type": "Microsoft.Compute/virtualMachines",
"apiVersion": "2015-06-15",
"location": “eastus",
"properties": {
"hardwareProfile": {
"vmSize": "Standard_D2_v2“
},
"osProfile": {
"computerName": “AzureLabVM",
"adminUsername": "azureuser",
"adminPassword": "Azure4Research“
},
"storageProfile": {
"imageReference": {
"publisher": "Canonical",
"offer": "UbuntuServer",
"sku": "16.04-LTS",
"version": "latest“
},
"osDisk": {
"name": "osdisk",
"vhd": {
"uri": "https://vmlabstorage.blob.core.windows.net/vhds/myosdisk.vhd“
},
"caching": "ReadWrite",
"createOption": "FromImage“
}
},
"networkProfile": {
"networkInterfaces": [
{
"id": "[resourceId('Microsoft.Network/networkInterfaces/myVMNic'))]“
}
]
}
}](https://image.slidesharecdn.com/azurevirtualmachines-180505211127/85/Azure-virtual-machines-Terraform-11-320.jpg)
![ARM Template Format
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
},
"variables": {
},
"resources": [
],
"outputs": {
}](https://image.slidesharecdn.com/azurevirtualmachines-180505211127/85/Azure-virtual-machines-Terraform-12-320.jpg)
!["name": "MyUbuntuVM",
"type": "Microsoft.Compute/virtualMachines",
"apiVersion": "2015-06-15",
"location": “eastus",
"properties": {
"hardwareProfile": {
"vmSize": "Standard_D2_v2“
},
"osProfile": {
"computerName": “AzureLabVM",
"adminUsername": "azureuser",
"adminPassword": "Azure4Research“
},
"storageProfile": {
"imageReference": {
"publisher": "Canonical",
"offer": "UbuntuServer",
"sku": "16.04-LTS",
"version": "latest“
},
"osDisk": {
"name": "osdisk",
"vhd": {
"uri": "https://vmlabstorage.blob.core.windows.net/vhds/myosdisk.vhd“
},
"caching": "ReadWrite",
"createOption": "FromImage“
}
},
"networkProfile": {
"networkInterfaces": [
{
"id": "[resourceId('Microsoft.Network/networkInterfaces/myVMNic'))]“
}
]
}
}](https://image.slidesharecdn.com/azurevirtualmachines-180505211127/75/Azure-virtual-machines-Terraform-11-2048.jpg)
![ARM Template Format
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
},
"variables": {
},
"resources": [
],
"outputs": {
}](https://image.slidesharecdn.com/azurevirtualmachines-180505211127/75/Azure-virtual-machines-Terraform-12-2048.jpg)
More Related Content
Similar to Azure virtual machines & Terraform
Azure virtual machines & Terraform
- 1. Azure Virtual Machines &Terraform
- 2. Juan José Gazzola •Microsoft Certificated Profesional • Soy consultor de sistemas con más de 10 años de experiencia. • He desempeñado tareas de administrador, desarrolador y project mananger. • Participo de los foros de Microsoft Technet @Juanjo_gazzola
- 3. Topics Introduction Provisioning VMs Scalability &Reliability Additional Concepts
- 4. Azure Virtual MachineBenefits • Choice • Choose from thousands of pre-configured VM images or configure, capture, and upload your own custom images • Leverage VM Extensions to do custom post-deployment configuration • Scalability & Reliability • Select system profiles to best match your workload • Configure drives for size and performance • Leverage VM Scale Sets to scale from one to thousands of VM instances • Access & Security • Configure Azure networking to the topology you require • Extend your on-premises infrastructure into the Cloud
- 5.
- 6. Provisioning Steps Image • Selectan image from the VM Gallery • Upload your own Custom-Prepped Image • Use a Custom ARM Template Scale • General Purpose • Compute Optimized • Memory Optimized • GPU • High Performance Compute Boot • Create new disk in Storage • Boot the machine Easy as 1-2-3!
- 7. VM Gallery Images WindowsServer 2012 R2 Ubuntu Server 14.04 LTS CentOS 6.5 SUSE Linux Enterprise Server Oracle Linux 6.4.0.0.0 Windows 8.1 Enterprise SQL Server 2014 Standard Oracle Database 11g R2 BizTalk Server 2013 SharePoint Server Farm Microsoft Dynamics GP 2013 Zulu 8 SAP HANA Developer Edition Puppet Enterprise 3.2.3 Barracuda Web Application Oracle WebLogic Server 12.1.2 Visual Studio Ultimate 2013 openSUSE 13.1
- 9. CloudOn-Premises Custom Image Upload •Prepare the VHD • Optional – generalize the VHD by using SysPrep/waagent • Upload the VHD to Azure Storage • Prepare networking resources • Create the VM from uploaded generalized or specialized image VHD
- 10. Deployment with ARMTemplates • Declarative deployment • Maintain resources with the same lifecycle within a resource group • Configure parameters for input/output • Specify resources & dependencies • Leverage Quickstart Templates or export existing resources
- 11. "name": "MyUbuntuVM", "type": "Microsoft.Compute/virtualMachines", "apiVersion":"2015-06-15", "location": “eastus", "properties": { "hardwareProfile": { "vmSize": "Standard_D2_v2“ }, "osProfile": { "computerName": “AzureLabVM", "adminUsername": "azureuser", "adminPassword": "Azure4Research“ }, "storageProfile": { "imageReference": { "publisher": "Canonical", "offer": "UbuntuServer", "sku": "16.04-LTS", "version": "latest“ }, "osDisk": { "name": "osdisk", "vhd": { "uri": "https://vmlabstorage.blob.core.windows.net/vhds/myosdisk.vhd“ }, "caching": "ReadWrite", "createOption": "FromImage“ } }, "networkProfile": { "networkInterfaces": [ { "id": "[resourceId('Microsoft.Network/networkInterfaces/myVMNic'))]“ } ] } }
- 12. ARM Template Format "$schema":"https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": { }, "variables": { }, "resources": [ ], "outputs": { }
- 13. VM Extensions • Smallapplications that perform post-deployment configuration and automation tasks • Extensions are published by Microsoft & trusted 3rd party publishers • Can be added, updated, disabled, or removed at any time • Managed via Azure Portal, PowerShell, and Management APIs
- 14.
- 15. Choosing a VMSize General Purpose Compute Optimized Memory Optimized GPU High Performance Compute A0 – A5 Basic D1v2 – D5v2 D1 – D4 A0 – A7 Standard F1, F2, F4, F8, F16 D11v2 – D15v2 D11 – D14 G1 – G5 NV6, NV12, NV24 NC6, NC12, NC24, NC24r H8, H8m, H16, H16m, H16r, H16mr A8 – A11
- 16. Disks vs Images BaseOS image for new Virtual Machines Sys-Prepped/Generalized/Read Only Created by uploading or by capture Writable Disks for Virtual Machines Created during VM creation or during upload of existing VHDs.
- 17. Storage Disks Standard Storage •Cloud-scale reliable storage • Maximum 500 IOPS, 60 MB per second throughput per disk • Available in all VM Sizes Premium Storage • High-performance, low-latency disk support, ideal for I/O intensive workloads • Maximum 5000 IOPS, 200 MB per second throughput per disk • Only supported in “S” series VMS (DS, DSv2, GS, FS) • Locally redundant storage only • Mount Azure Storage as network share volumes • Can be accessed via SMB 3.0 or REST APIs • Up to 1000 IOPS, up to 60 MB/second throughput per share • Max share size = 5TB, Max file size = 1 TB. Azure File Storage
- 18. Azure Fault andUpdate Domains • Fault domains are groupings of VMs that share the same physical hardware (server rack, power connection, network switch.) • Update domains are groupings of VMs that can be rebooted at the same time. • Deploying your VMs into an Availability Set distributes them across Fault & Update Domains in order to help ensure uptime for your system.
- 19.
- 20. Availability Sets –Rack Failure
- 21. Availability Sets -Maintenance
- 22. Knowing Your 9’s Availability (%) DescriptionDowntime (Minutes) Practical Meaning FAA Rating Annual Quarterly Monthly 90 Unmanaged 52,596.00 13,149.00 4,383.00 Down 5 weeks per year 99 Managed 5,259.60 1,314,90 438.30 Down 4 days per year ROUTINE 99.9 Well-Managed 525.96 131.49 43.83 Down 9 hours per year ESSENTIAL 99.99 Fault-Tolerant 52.60 131.15 4.38 Down 1 hour per year 99.999 High Availability 5.26 1.31 .44 Down 5 minutes per year CRITICAL 99.9999 Very High Availability 0.53 0.13 0.04 Down 30 seconds per year 99.99999 Ultra Availability 0.05 0.01 -- Down 3 seconds per year SAFETY CRITICAL From Generic Requirements for Operation Systems Platform Reliability, Telcordia Technologies System Documentation,GR-2841-CORE and Federation Aviation Administration Handbook: Reliability, Maintainability, and Availability (RMA) Handbook, FAA-HDBK-006A, Jan 7, 2008.
- 23. Azure VM ServiceLevel Agreement • 99.95% for multiple role instances in an Availability Set • What’s Included • Computer hardware failure (disk, CPU, memory) • Data Center failures – network, power • Hardware upgrades, software maintenance, Host OS Updates • Not Included • VM Container crashes, Guest OS updates
- 24. VM Scale Sets •Easily deploy a set of VMs based on the same image • Implicitly balanced across Fault & Update Domains • VM Scale sets are implicitly an Availability Set (3 FD, 5 UD) • Manual or rule-based scaling for the Scale Set capacity • Use a Load Balancer or Application Gateway to distribute requests across the available VM’s in a Scale Set
- 25.
- 26. Azure DevTest Labs •Manage a set of VM’s or provide worry-free self-service for dev-test lab environments. • Use “Formulas” to create reusable VM configurations • Use “Artifacts” to create reusable VM configuration elements • Configure policies for auto-shutdown, auto-start • Role-based access for Owners, Contributors, Lab Users
- 28.
- 29. Was founded byMitchell Hashimoto and Armon Dadgar in 2012 with the goal of revolutionizing datacenter management: • Application development • Delivery • Maintenance.
- 30. It is anopen source tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned. What is Terraform?
- 32.
- 33. Repositorio Git https://github.com/juanjogazzola/BuenosAiresAzureBootCamp2018 Azure VirtualMachine Documentation https://docs.microsoft.com/en-us/azure/virtual-machines/windows/ Terraform Documentation https://www.terraform.io/docs/index.html Terraform Azure Provider https://www.terraform.io/docs/providers/azurerm/index.html
Editor's Notes
- #4 Objective: Discuss the agenda for the deck Notes: The deck is broken into 5 key sections that discuss: General introduction to Azure VM’s Process involved and options for provisioning a VM Concepts and tooling related to scalability and reliability in Azure VMs Networking infrastructure for use with Azure VMs Additional concepts or solutions that build on Azure VM’s
- #5 Objective: Introduce the advantages of VM offerings on the Azure Platform Notes: There are 3 key areas where Azure VM’s offer a significant advantage: Choice – Users can choose from a frequently-updated gallery of pre-configured VM images, or they can prepare and upload their own (and what they upload can either be an image – multiple VM’s get made from images – or a ready-to-run VM. On top of all that, VM Extensions can be used to run post-configuration setup steps. Scalability/Reliability – Users can choose VM configurations (CPU, RAM, HDD, etc) that matches their workloads. They can also configure attached storage as needed (and as the chosen VM tier permits), and then use VM Scale Sets to horizontally scale their images across multiple VM instances. Access/Security – Users can configure Azure networking to isolate their VM’s within the Azure network, and even extend that network topology to connect to their on-premises network or to other Azure networks.
- #6 Objective: This section will discuss the steps involved in and key options for provisioning VMs in Azure.
- #7 Objective: To illustrate typical straightforward processes for provisioning VMs Notes: The process of provisioning a VM usually follows 3 basic steps: Choose the VM Image, either from a pre-existing gallery of images, by preparing and uploading your own image, or via an ARM template (which references either a pre-existing image or one you uploaded) Choose the size and performance characteristics for your VM, depending on its intended purpose (general, compute-heavy, memory-intensive, requiring GPU processing, or HPC.) Boot the VM instance – generate a new VM disk instance in storage, then boot the machine.
- #8 Objective: To illustrate a sampling of the array of different kinds of VM images available in the VM Gallery. Notes: One of the ways a VM can be provisioned is by selecting a predefined image from the VM Gallery, which offers a wide variety of vendor/partner-provided pre-configured VM images that you can choose from. Examples include Windows Server versions/editions or Linux Servers SQL Server database or Oracle database MSDN subscribers also get access to Windows images pre-populated with Visual Studio and Windows Client OS versions for use in DevTest scenarios
- #9 Objective: To help foster the perception change about the “old” and “new” Microsoft, illustrating “open and inclusive”. Notes: Just because Azure comes from Microsoft doesn't mean it's Windows-centric. Azure loves Linux, and much of the ongoing development taking place in Azure today is designed to make it the best cloud platform in the world for hosting Linux and popular open-source tools that run on it. In fact > 30% (and growing) of VM’s in Azure today run Linux
- #10 Objective: To show another option for deploying VM’s – via uploading a custom image. Notes: One unique thing about Azure is its Hybrid nature – VM exchange isn’t strictly uni-directional, VHD’s can be moved from Azure to on-prem. A “generalized” image is one which is intended to be used to create multiple new VM’s - it has all personal information & state removed via SysPrep (Windows) or waagent (Linux) A “specialized” image is one which is intended to be used “as is” in Azure
- #11 Objective: To show another option for deploying VM’s – via ARM templates. Notes: Another deployment option is to use ARM Templates ARM Templates are declarative files that define the resources to deploy and the inter-relationships between deployed resources Specify input parameters and variables, use expressions Use Azure Quickstart templates, with source in GitHub Edit in Azure online editor, use Visual Studio tooling, use Visual Studio Code They can be checked into source control in order to simplify deployment management
- #12 Objective: To show an illustration of the VM-resource section of an ARM template involved in provisioning a VM and its related resources Notes: This is a section of a simple (no parameters, variables) ARM template used to provision an Ubuntu VM. Key notes include: Key attributes of name, type, apiVersion, location, and properties The OS profile describing the computer name, admin user, and password The image to use and where the VHD for the VM should be stored A NIC resource attached to the VM
- #13 Objective: To show an illustration of the core content/sections of an ARM template Notes: This simply shows the bare-bones key sections that each ARM template contains The key sections are : Schema – location of the schema file that describes the template language ContentVersion – Version of the template instance. Parameters – these are values that provided when deployment is executed in order to customize the deployment Variables – these are computed elements (often composed from Parameters) that can be reused by name throughout the template Resources – the definitions of the actual resources being deployed (or updated) Outputs – Values returned after deployment
- #14 Objective: Discuss the role of VM Extensions in realizing VM instances Notes: Extensions are units of code that can be run after the VM has been created to perform additional configuration. Typical extension functions include software installation, OS configuration Anti-virus configuration, which may be mandated by Compliance Custom Script configuration – run a custom script Chef, Puppet extensions – automated management at scale Symantec Endpoint protection Docker Visual Studio remote Debugger
- #15 Objective: This section will discuss the options for scaling VM’s (VM sizes and storage) and also the concepts of reliability via Availability Sets
- #16 Objective: Illustrate the many different possible VM hardware configurations, slotted by purpose. Notes: A key takeaway here is that part of provisioning your VM’s is determining the Family/Size that best addresses your needs. Information Source: https://azure.microsoft.com/en-us/pricing/details/virtual-machines/linux/ General: A0 – A4 Basic: 1-8 cores, .75-14 GB RAM. Entry-level, economical. Good for dev workloads, dev/test A0 – A7 Standard: 1-8 cores, .74-56 GB RAM. Entry-level, economical. Supports load-balancing, auto-scaling. Good for dev workloads, dev/test D1 – D4 (v1): 1 – 8 cores, 3.5 – 28 GB RAM. More powerful CPU than A, feature SSD’s. Also available in Ds (premium storage D1v2 – D5vs: 1 – 16 cores, 3.5 – 56 GB RAM. Newer-gen D-series, 35% faster CPU than D. Compute Optimized: F1 – F16: 1 – 16 cores, 2 – 32 GB RAM. Higher CPU to memory ratio Good for batch-processing, web servers, analytics, gaming. Memory Optimized: D11 – D14 (v1): 2 – 16 cores, 14 – 112 GB RAM. Ideal for memory-intensive enterprise applications. D11v2 – D15v2: 2 – 20 cores, 14 – 140 GB RAM. Ideal for memory-intensive enterprise applications. GPU NV6 - NV24: Good for high-end remote visualization, deep-learning, predictive analytics. V series focuses on visualization. NC6 - NC24/r: Good for high-end remote visualization, deep-learning, predictive analytics. C series focuses on compute. (24r is for tightly-coupled parallel computing workloads with 2nd low-latency, high-throughput NIC) HPC A8 – A11: A8 & A10 have 8 cores & 56 GB RAM, A9 & A11 have 16 cores & 112 GB RAM. Entry-level, economical. Good for dev workloads, dev/test H8, H16, m&r: 8, 16 cores, 56GB – 224 GB RAM. M = high memory, r = RDMA network. Good for risk modeling, seismic & reservoir simulation, molecular modeling, genomic research. COMING SOON L-Series: “Storage optimized”
- #17 Objective: To present the difference between an OS Image and a VM Disk Notes: Images are reference VHDs (almost like a template) for realizing OS Disks for VMs. VM’s typically have at least 2 disks: OS Disk (C on Windows), persistent content. SATA access Temp Storage (D on Windows), SATA access, NOT PERSISTENT (Temp storage only) (Good for TempDB on SQL images, for example) Additionally, VM’s can have 0->n (depends on characteristics of VM size chosen) data disks Drive-letter assigned on Windows, SCSI, Persistent Can be striped for performance Limit on # determined by VM family/size
- #18 Objective: To discuss the available different kinds of storage that can be used by VM disks Notes: Data disks have max capacity of 1 TB, but can be striped for larger sizes, up to 64 TB of storage per VM Azure imposes limits on the number of data disks and amount of bandwidth available, depending on the VM size. (eg F2S = max 4 data disks, F16S = max 32 data disks) Per-Disk (and Share) IOPS are 8KB operations Standard Storage IOPS and Throughput per disk above are for Standard, basic is lower Entire storage account (not just single disk) has max IOPS of 20,000 Premium Storage IOPS and Throughput per disk above are for P30, lower for P10, P20 With a GS5, supports up to 80,000 IOPS and 2000 MB/s throughput per VM Entire storage account has a max total throughput rate of 50 Gbps No Azure-imposed limit on the number of file shares that can be mounted, no limit on the number of VM’s that can simultaneously mount a File Storage share Can also be mounted by on-premises clients (Windows) - on prem mounting requires Windows 8 or newer (Server 2012+) and firewall cooperation No limit on # of files in a share (other than overall share size)
- #19 Objective: To introduce the concepts of Fault & Update domains in the context of discussing reliability Notes: For Fault Domains: Generally hardware-centric Think “single point of failure” Note that a Fault Domain can actually span multiple physical racks – you’re not too worried about that, but it just means that items in different Fault Domains are assured to be on different hardware Update Domains Update domains are largely related to patching the host OS A given Fault Domain can host multiple update domains, as long as not ALL update domains are on a given rack.
- #20 Objective: Part of a multiple slide sequence that illustrates the concept of Availability Sets and their relationship to Fault & Update domains Notes: Shows how VM’s in an Availability Set are laid out (striped) across FDs & UDs The animation will show 10 instances striped across racks in a FD, and also increasing US’s from 0-4, then repeating again.
- #21 Objective: Part of a multiple slide sequence that illustrates the concept of Availability Sets and their relationship to Fault & Update domains Notes: Illustrates what happens when a rack goes down The animation will (partially) show when the rack representing FD0 dies. When the Azure infrastructure realizes this rack is dead, it will work to stand up the missing VM’s in a new rack (not shown in animation.)
- #22 Objective: Part of a multiple slide sequence that illustrates the concept of Availability Sets and their relationship to Fault & Update domains Notes: Illustrates Azure managing downtime when performing scheduled maintenance (such as updating host machines) The animation will show an update propagating across each FD in turn. NOTE: Don’t count on update sequence being linear from UD 0 to UD4. It will do 1 UD at a time, but might follow a different sequence.
- #23 Objective: To introduce the concept of n-nines and show how it reflects uptime Notes: The concept of “n-nines” (three-nines, five nines, etc) is often used as a shorthand to discuss uptime in a system. There’s actually some standard naming around this concept. It’s also interesting to see exactly how many minutes of downtime each tier represents annually, quarterly, or monthly. The final column is the standard naming used by the FAA to describe key “nines” levels.
- #24 Objective: To present the concept of the Azure VM SLA. Notes: Discuss what an SLA is and is *NOT* - these are not always met, and there’s usually some form of compensation. However, the track record is actually pretty good. This SLA translates to ~4.38 hours of downtime per year Requires using VM’s that have 2 or more instances deployed in the same Availability Set, and measures/assures connectivity to at least one instance Source: https://azure.microsoft.com/en-us/support/legal/sla/virtual-machines/v1_2/
- #25 Objectives: To present the concept of VM Scale Sets (VMSS’s) Notes: Ideal for clusters/farms (cattle, not pets) Without VMSS, you have to manage scaling of VM’s with pre-provisioned images (bring online, stop as needed) Currently do *NOT* support data disks, but can mount Azure Storage File Shares (data drives in-preview, coming soon) The auto-scaling infrastructure even works with WebHooks, allowing you to receive notifications when scaling operations happen.
- #26 Objective: This section will present additional solutions built on top of the Azure VM infrastructure (namely, DevTest labs)
- #27 Objective: To discuss Azure DevTest Labs as an extension or a solution that builds on VM’s/IaaS Notes: Designed to allow dev-test lab setup, access, and management scenarios, but can be applied for other uses (classroom, etc.) VM “Formulas” allow you to select pre-existing or custom base images and size/configurations, as well as “artifacts to be applied to those images Artifacts are useful for pre-installing SW or running config scripts Install Chrome or Firefox browsers Install Git and retrieve a project from a repository Install VS Code, PowerShell, NodeJS, or other development & runtime tools Install Chocolatey / Apt-Get packages Run startup scripts (PowerShell (both Windows or Linux) or Bash (Linux)) Auto-shutdown: includes optional Webhook-based pre-shutdown notifications Auto-start: choose days of the week where this should apply (do not auto-start on weekends) Other – limit the available VM Marketplace images, VM sizes, Limit the available # of VM’s per user RBAC – Owners and Contributors can do everything, except contributors cannot add new users to the lab. Regular “users” can create new VM (instances) and formulas, and manage their own created VM instances (including applying artifacts), but cannot do much else.
- #29 Objective: Discuss the agenda for the deck Notes: The deck is broken into 5 key sections that discuss: General introduction about Hashicorp Talk about Terrafrom Show how code is structured Demo Links
- #30 HashiCorp was founded by Mitchell Hashimoto and Armon Dadgar in 2012 with the goal of revolutionizing datacenter management: application development, delivery, and maintenance. The datacenter of today is very different than the datacenter of yesterday, and we think the datacenter of tomorrow is just around the corner. We're writing software to take you all the way from yesterday to today, and then safely to tomorrow and beyond. Physical, virtual, containers. Private cloud, public cloud, hybrid cloud. IaaS, PaaS, SaaS. Windows, Linux, Mac. These are just some of the choices faced when architecting a datacenter of today. And the choice is not one or the other; instead, it is often a combination of many of these. HashiCorp builds tools to ease these decisions by presenting solutions that span the gaps. Our tools manage both physical machines and virtual machines, Windows, and Linux, SaaS and IaaS, etc. And we're committed to supporting next-generation technologies, as well. HashiCorp was founded and continues to be run by the primary authors of all our core technologies powering thousands of companies worldwide. We speak at conferences and write books related to application and infrastructure management. All our foundational technologies are open source and developed openly, and have been since 2010.