{"id":5645,"date":"2017-03-29T12:00:22","date_gmt":"2017-03-29T16:00:22","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/azuregov\/?p=5645"},"modified":"2017-03-29T12:00:22","modified_gmt":"2017-03-29T16:00:22","slug":"microsoft-azure-iaas-architecture-best-practices-for-arm","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/azuregov\/microsoft-azure-iaas-architecture-best-practices-for-arm\/","title":{"rendered":"Microsoft Azure IaaS Architecture Best Practices for ARM"},"content":{"rendered":"

How to design and build an enterprise infrastructure in Azure using the Azure Resource Manager portal<\/h3>\n

Getting started in Azure is easy to do, and you can have production workloads running in the cloud in very little time. However, there are some essential aspects of the Azure platform that require some forethought and planning. While it is easy to get up and running quickly, without the necessary planning in some areas, you could find it necessary to rebuild these workloads later if you haven\u2019t fully considered the bigger picture\u2014from an enterprise perspective. Let\u2019s avoid the necessity of having to redeploy or redesign your Azure architecture later by considering upfront those things that may become an issue later.<\/p>\n

Executive Summary<\/h3>\n

This post describes and demonstrates the best practices for implementing a consistent naming convention, Resource Group management strategy, and creating architectural designs for your Azure IaaS deployments. Your actual conventions and strategies will differ depending on your existing methodology, but this sample describes some of the key concepts for you to properly plan for your cloud assets. A video walkthrough guide of these principles in practice, is also available for a deeper understanding of the concepts presented here.<\/p>\n

This article builds upon the following blog post that was released previously, and describes similar concepts utilizing Azure Service Management (ASM or Classic) resources: Essential Considerations for Azure Architectural Planning<\/a><\/p>\n

Azure Subscriptions<\/u><\/h3>\n

The very top level container within an Azure enrollment is the subscription. An enrollment can contain many subscriptions\u2014each with their own administrative boundaries. This works well for separation of departments and agencies, as well as for separation of specific workloads such as production, staging, testing, and development. While this is great for establishing clean administrative boundaries, centrally managing many subscriptions can create additional overhead. For instance, a virtual network (VNET) cannot cross a subscription boundary, so if you are utilizing Site-to-Site VPNs for your hybrid connectivity, you will need to create multiple VPNs\u2014one for each VNET. If you are utilizing ExpressRoute (E\/R) for your connectivity, this makes it much easier to connect multiple VNETs to your on-premises network. It is also possible to utilize VNET peering<\/a> to share a single VPN connection as long your VPN edge device supports route-based (or dynamic) routing.<\/p>\n

Azure in Education has posted a great article about enterprise and subscription management. For more information, check out this article: Introduction to Azure Enterprise and Subscription Management<\/a>.<\/p>\n

Naming Conventions<\/u><\/h3>\n

Consistent naming conventions are critical to any government agency or commercial enterprise with numerous different departments, services, networks, and applications. If consistent naming is not applied from the very beginning, resources can quickly become hard to find or rapidly identify. As such, it is important to establish a standard convention that will be used throughout these various services. [Note: these are typical examples and will likely vary from your current established naming convention. Just keep in mind that you should have some mechanism in place to distinguish Azure based assets from on-premises based assets when you determine your actual naming convention.]<\/em><\/p>\n

Additional guidance on naming convention best practices is located here: Naming Conventions<\/a><\/p>\n

Resource Groups<\/u><\/h3>\n

Within a subscription, the Resource Group (RG) is the top-level container to keep similar workloads or items grouped together. Typically, these RGs are utilized to separate things like virtual machine workloads, network components, storage accounts, and other such items. That makes it easy to go directly to the desired area or workload to find or manage components within it.<\/p>\n

A typical resource group naming convention is like the following:\nRG-Region-Type-SubType\/Workload<\/strong><\/p>\n

Example: RG-West-VM-Identity<\/strong> where\nRG<\/strong> indicates it as a Resource Group\nWest<\/strong> indicates the WestUS region\nVM<\/strong> indicates that it contains virtual machines\nIdentity<\/strong> indicates the \u201cidentity\u201d workload<\/p>\n

Example: RG-West-Network<\/strong> where\nRG<\/strong> indicates it as a Resource Group\nWest<\/strong> indicates the WestUS region\nNetwork<\/strong> indicates that it contains the Vnet components<\/p>\n

Networking Components<\/u><\/h3>\n

A typical resource group naming convention is like the following:\nVnet-Region-Type-SubType\/Workload<\/strong><\/p>\n

Example: VNET-West<\/strong> where\nVNET<\/strong> indicates it as a virtual network component\nWest<\/strong> indicates the WestUS region<\/p>\n

Example: VNET-West-GW<\/strong> where\nVNET<\/strong> indicates it as a virtual network component\nWest<\/strong> indicates the WestUS region\nGW<\/strong> indicates that it is the gateway component<\/p>\n

Example: VNET-West-GW-IP<\/strong> where\nVNET<\/strong> indicates it as a virtual network component\nWest<\/strong> indicates the WestUS region\nGW<\/strong> indicates that it is the gateway component\nIP<\/strong> indicates that it is the IP address of the gateway<\/p>\n

Storage Accounts<\/u><\/h3>\n

Storage accounts use publicly accessible URLs, so they require a globally unique DNS name.<\/p>\n

A typical storage account naming convention is like the following:\n[Entity][Region][Type][Workload].*.core.windows.net (or for Azure Government [Entity][Region][Type][Workload].*.core.usgovcloudapi.net)<\/strong><\/p>\n

Example: spnwwusvmid<\/strong> (https:\/\/spnwwusvmid.blob.core.windows.net) where:\nspnw<\/strong> indicates the enterprise name\nwus<\/strong> indicates it is located in the WestUS region\nvm<\/strong> indicates it is for virtual machine disks\nid<\/strong> indicates that is for the identity workload<\/p>\n

Example: spnweussql<\/strong> (https:\/\/spnweussql.blob.core.windows.net) where:\nspnw<\/strong> indicates the enterprise name\neus<\/strong> indicates it is located in the EastUS region\nsql<\/strong> indicates it is for SQL data storage<\/p>\n

Virtual Machines<\/u><\/h3>\n

A typical storage account naming convention is like the following:\n[Region][Role][Number]<\/strong><\/p>\n

Example: wusdc01<\/strong> where:\nwus<\/strong> indicates the WestUS region\ndc<\/strong> indicates it is a domain controller\n01<\/strong> indicates it is the first domain controller<\/p>\n

Example: wusadfs02<\/strong> where:\nwus<\/strong> indicates the WestUS region\nadfs<\/strong> indicates it is an ADFS server\n02<\/strong> indicates it is the second server for this workload<\/p>\n

Workload Scenario<\/u><\/h3>\n

Let\u2019s build a sample scenario of an enterprise SharePoint farm in Azure. This scenario will include a highly available SharePoint farm that is deployed in the WestUS region, with a disaster recovery farm deployed in the EastUS region. They are connected via two on-premises Site-to-Site (S2S) VPNs (one to each region) as well as a VNET-to-VNET VPN that connects WestUS to EastUS. This last link is utilized for Domain Controller and SQL Always-on replication.<\/p>\n

\"azureiaasarmscenario\"<\/a><\/p>\n

Identity Workload:<\/u><\/strong> 6 servers in West Region\n(2) Domain Controllers\n(2) Load balanced ADFS servers\n(2) Load balanced Web Proxy servers<\/p>\n

SharePoint Workload:<\/u><\/strong> 6 servers in West Region\n(2) Load balanced SharePoint WFE servers\n(2) SharePoint APP servers\n(2) Load balanced SQL servers w\/always-on<\/p>\n

Disaster Recovery Workload:<\/u><\/strong> 4 servers in East Region\n(1) Domain Controller\n(1) SharePoint WFE server\n(1) SharePoint APP server\n(1) SQL Server w\/always-on<\/p>\n

Resource Groups<\/u><\/h3>\n

The RGs that we have defined for this scenario are as follows:<\/p>\n\n\n\n\n\n\n\n\n\n\n
RG-West-VM-Identity<\/td>\nContains identity VMs and their storage (DCs, ADFS, Proxy)<\/td>\n<\/tr>\n
RG-West-VM-SharePoint<\/td>\nContains SharePoint VMs (WFE, APP)<\/td>\n<\/tr>\n
RG-West-VM-Database<\/td>\nContains SQL database VMs (SQL)<\/td>\n<\/tr>\n
RG-West-Network<\/td>\nContains network related components (Vnet, S2S VPNs, public IPs, load balancers)<\/td>\n<\/tr>\n
RG-East-VM-Identity<\/td>\nContains identity VMs and their storage (DC)<\/td>\n<\/tr>\n
RG-East-VM-SharePoint<\/td>\nContains SharePoint VMs (WFE, APP)<\/td>\n<\/tr>\n
RG-East-VM-Database<\/td>\nContains SQL database VMs (SQL)<\/td>\n<\/tr>\n
RG-East-Network<\/td>\nContains network related components (Vnet, public IP, etc.)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Networking Components<\/u><\/h3>\n

The networking components defined for this scenario are as follows:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Vnet-West<\/td>\nThe virtual network configuration (IP ranges, subnets, etc.)<\/td>\n<\/tr>\n
Vnet-West-GW<\/td>\nThe virtual network gateway<\/td>\n<\/tr>\n
Vnet-West-GW-IP<\/td>\nThe public IP address of the gateway<\/td>\n<\/tr>\n
Vnet-West-GW-Local<\/td>\nThe local (on-premises) gateway configuration (IP address, connection type, etc.)<\/td>\n<\/tr>\n
Vnet-West-Vnet-East-Connection<\/td>\nThe S2S VPN connecting WestUS to EastUS<\/td>\n<\/tr>\n
Vnet-West-Local-Connection<\/td>\nThe S2S VPN connecting WestUS to on-premises<\/td>\n<\/tr>\n
PLB-West-ADFSProxy<\/td>\nThe public load balancer for the ADFS proxy servers<\/td>\n<\/tr>\n
PLB-West-ADFSProxy-IP<\/td>\nThe public IP address of the load balancer<\/td>\n<\/tr>\n
ILB-West-ADFS<\/td>\nThe internal load balancer for the ADFS servers<\/td>\n<\/tr>\n
PLB-West-SP<\/td>\nThe public load balancer for the SharePoint WFEs<\/td>\n<\/tr>\n
PLB-West-SP-IP<\/td>\nThe public IP address of the load balancer<\/td>\n<\/tr>\n
Vnet-East<\/td>\nThe virtual network configuration (IP ranges, subnets, etc.)<\/td>\n<\/tr>\n
Vnet- East -GW<\/td>\nThe virtual network gateway<\/td>\n<\/tr>\n
Vnet- East -GW-IP<\/td>\nThe public IP address of the gateway<\/td>\n<\/tr>\n
Vnet- East -GW-Local<\/td>\nThe local (on-premises) gateway configuration (IP address, connection type, etc.)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Storage Accounts<\/u><\/h3>\n

Storage accounts (S\/A) are publicly available locations where your virtual hard drives (and other data types) are stored. They are IOPS limited depending on the type of storage that is required. A standard S\/A has a limit of 20K IOPS and utilizes typical HDDs with a maximum IOPS limit of 500 per disk. A premium S\/A is limited to 100K IOPS and utilizes typical SSDs with a maximum IOPS limit of 5000 per disk. As such, it is recommended to split your VHDs into several S\/As so that your VMs can use their maximum potential data transfer speeds.<\/p>\n\n\n\n\n\n\n\n\n\n\n
spnwwusvmid<\/td>\nWest Identity VM S\/A<\/td>\n<\/tr>\n
spnwwusvmsp<\/td>\nWest SharePoint VM S\/A<\/td>\n<\/tr>\n
spnwwusvmdb<\/td>\nWest SQL data VM S\/A<\/td>\n<\/tr>\n
spnwwusvmdiag<\/td>\nWest VM diagnostics S\/A<\/td>\n<\/tr>\n
spnweusvmid<\/td>\nEast Identity VM S\/A<\/td>\n<\/tr>\n
spnweusvmsp<\/td>\nEast SharePoint VM S\/A<\/td>\n<\/tr>\n
spnweusvmdb<\/td>\nEast SQL data VM S\/A<\/td>\n<\/tr>\n
spnweusvmdiag<\/td>\nEast VM diagnostics S\/A<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Availability Sets<\/u><\/h3>\n

Availability sets group identical server workloads together to provide high availability in Azure. In order to provide a Service Level Agreement (SLA) for specific virtual machine workloads, each workload must contain at least two servers in an availability set, or single instance machines must utilize premium storage for their virtual hard disks. As such, the best practice is to include two servers running each critical workload. In addition, we will add load balancers to these workloads where required.<\/p>\n

For this scenario, the WestUS region is our primary location. The EastUS region will only be utilized if a disaster occurs in the WestUS region, so a few single instance VMs in the East would be fine in that scenario. If desired, a fully redundant and high performing infrastructure could be built in the East as well\u2014including the full ADFS resilient identity workload.<\/p>\n

The availability sets defined for this scenario are as follows:<\/p>\n\n\n\n\n\n\n\n\n
AS-DC<\/td>\nThe A\/S for the domain controllers<\/td>\n<\/tr>\n
AS-ADFS<\/td>\nThe A\/S for the ADFS servers<\/td>\n<\/tr>\n
AS-ADFSPXY<\/td>\nThe A\/S for the ADFS proxy servers<\/td>\n<\/tr>\n
AS-SPWFE<\/td>\nThe A\/S for the SharePoint web front end servers<\/td>\n<\/tr>\n
AS-SPAPP<\/td>\nThe A\/S for the SharePoint app servers<\/td>\n<\/tr>\n
AS-SPSQL<\/td>\nThe A\/S for the SharePoint SQL servers<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Virtual Machines<\/u><\/h3>\n

All of the virtual machine components are listed in the table following:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
VM<\/strong><\/td>\nIP<\/strong><\/td>\nSubnet<\/strong><\/td>\nL\/B<\/strong><\/td>\nAvail Set<\/strong><\/td>\nVM Size<\/strong><\/td>\nResource Group<\/strong><\/td>\nStorage Account<\/strong><\/td>\n<\/tr>\n
West Region<\/strong><\/td>\n<\/tr>\n
WUSDC01<\/td>\n10.20.1.11<\/td>\nIdentity<\/td>\nn\/a<\/td>\nAS-DC<\/td>\nStandard_A2<\/td>\nRG-West-VM-Identity<\/td>\nspnwwusvmid<\/td>\n<\/tr>\n
WUSDC02<\/td>\n10.20.1.12<\/td>\nIdentity<\/td>\nn\/a<\/td>\nAS-DC<\/td>\nStandard_A2<\/td>\nRG-West-VM-Identity<\/td>\nspnwwusvmid<\/td>\n<\/tr>\n
WUSADFS01<\/td>\n10.20.1.21<\/td>\nIdentity<\/td>\nILB-West-ADFS<\/td>\nAS-ADFS<\/td>\nStandard_A2<\/td>\nRG-West-VM-Identity<\/td>\nspnwwusvmid<\/td>\n<\/tr>\n
WUSADFS02<\/td>\n10.20.1.22<\/td>\nIdentity<\/td>\nILB-West-ADFS<\/td>\nAS-ADFS<\/td>\nStandard_A2<\/td>\nRG-West-VM-Identity<\/td>\nspnwwusvmid<\/td>\n<\/tr>\n
WUSADFSPXY01<\/td>\n10.20.0.11<\/td>\nDMZ<\/td>\nPLB-West-ADFSPXY<\/td>\nAS-ADFSPXY<\/td>\nStandard_A2<\/td>\nRG-West-VM-Identity<\/td>\nspnwwusvmid<\/td>\n<\/tr>\n
WUSADFSPXY02<\/td>\n10.20.0.12<\/td>\nDMZ<\/td>\nPLB-West-ADFSPXY<\/td>\nAS-ADFSPXY<\/td>\nStandard_A2<\/td>\nRG-West-VM-Identity<\/td>\nspnwwusvmid<\/td>\n<\/tr>\n
WUSSPWFE01<\/td>\n10.20.0.21<\/td>\nDMZ<\/td>\nPLB-West-SPWFE<\/td>\nAS-SPWFE<\/td>\nStandard_A3<\/td>\nRG-West-VM-SharePoint<\/td>\nspnwwusvmsp<\/td>\n<\/tr>\n
WUSSPWFE02<\/td>\n10.20.0.22<\/td>\nDMZ<\/td>\nPLB-West-SPWFE<\/td>\nAS-SPWFE<\/td>\nStandard_A3<\/td>\nRG-West-VM-SharePoint<\/td>\nspnwwusvmsp<\/td>\n<\/tr>\n
WUSSPAPP01<\/td>\n10.20.2.11<\/td>\nApps<\/td>\nn\/a<\/td>\nAS-SPAPP<\/td>\nStandard_A3<\/td>\nRG-West-VM-SharePoint<\/td>\nspnwwusvmsp<\/td>\n<\/tr>\n
WUSSPAPP02<\/td>\n10.20.2.12<\/td>\nApps<\/td>\nn\/a<\/td>\nAS-SPAPP<\/td>\nStandard_A3<\/td>\nRG-West-VM-SharePoint<\/td>\nspnwwusvmsp<\/td>\n<\/tr>\n
WUSSPSQL01<\/td>\n10.20.3.11<\/td>\nServers<\/td>\nILB-West-SPSQL<\/td>\nAS-SPSQL<\/td>\nStandard_DS3<\/td>\nRG-West-VM-Database<\/td>\nspnwwusvmdb<\/td>\n<\/tr>\n
WUSSPSQL02<\/td>\n10.20.3.12<\/td>\nServers<\/td>\nILB-West-SPSQL<\/td>\nAS-SPSQL<\/td>\nStandard_DS3<\/td>\nRG-West-VM-Database<\/td>\nspnwwusvmdb<\/td>\n<\/tr>\n
East Region<\/strong><\/td>\n<\/tr>\n
EUSDC03<\/td>\n10.30.1.13<\/td>\nIdentity<\/td>\nn\/a<\/td>\nn\/a<\/td>\nStandard_A2<\/td>\nRG-East-VM-Identity<\/td>\nspnweusvmid<\/td>\n<\/tr>\n
EUSSPWFE03<\/td>\n10.30.0.13<\/td>\nDMZ<\/td>\nn\/a<\/td>\nn\/a<\/td>\nStandard_A3<\/td>\nRG-East-VM-SharePoint<\/td>\nspnweusvmsp<\/td>\n<\/tr>\n
EUSSPAPP03<\/td>\n10.30.2.13<\/td>\nApps<\/td>\nn\/a<\/td>\nn\/a<\/td>\nStandard_A3<\/td>\nRG-East-VM-SharePoint<\/td>\nspnweusvmsp<\/td>\n<\/tr>\n
EUSSPSQL03<\/td>\n10.30.3.13<\/td>\nServers<\/td>\nn\/a<\/td>\nn\/a<\/td>\nStandard_DS3<\/td>\nRG-East-VM-Database<\/td>\nspnweusvmdb<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Video Learning Series<\/a><\/h3>\n

The build out of this scenario workload is fully recorded for your review. These videos highlight all the key components of this document so that you can understand how it all comes together in Azure.<\/p>\n

1)\u00a0\u00a0\u00a0\u00a0\u00a0 Using Consistent Naming Conventions to Create Resource Groups and Storage Accounts <\/a>(20 minutes)<\/p>\n

2)\u00a0\u00a0\u00a0\u00a0\u00a0 Creating Virtual Network and VPN Connections in ARM <\/a>(30 minutes)<\/p>\n

3)\u00a0\u00a0\u00a0\u00a0\u00a0 Creating Basic Virtual Machines in the Azure Portal <\/a>(23 minutes)<\/p>\n

4)\u00a0\u00a0\u00a0\u00a0\u00a0 Creating Advanced Virtual Machines in the Azure Portal <\/a>(16 minutes)<\/p>\n

5)\u00a0\u00a0\u00a0\u00a0\u00a0 Creating Load Balancers and Network Security Groups in the Azure Portal <\/a>(24 minutes)<\/p>\n

We welcome your comments and suggestions to help us continually improve your Azure Government experience. To stay up to date on all things Azure Government, be sure to subscribe to our RSS feed<\/a> and to receive emails, click \u201cSubscribe by Email!\u201d on the Azure Government Blog<\/a>. To experience the power of Azure Government for your organization, sign up for an Azure Government Trial<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

How to design and build an enterprise infrastructure in Azure using the Azure Resource Manager portal Getting started in Azure is easy to do, and you can have production workloads running in the cloud in very little time. However, there are some essential aspects of the Azure platform that require some forethought and planning. While […]<\/p>\n","protected":false},"author":1765,"featured_media":20423,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[36,5,21,25,34],"tags":[59,75,95,343],"class_list":["post-5645","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cloud-strategy","category-compute","category-onboarding","category-portalpreview","category-virtual-machines","tag-arm","tag-azure","tag-azure-government","tag-iaas"],"acf":[],"blog_post_summary":"

How to design and build an enterprise infrastructure in Azure using the Azure Resource Manager portal Getting started in Azure is easy to do, and you can have production workloads running in the cloud in very little time. However, there are some essential aspects of the Azure platform that require some forethought and planning. While […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/azuregov\/wp-json\/wp\/v2\/posts\/5645","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/azuregov\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/azuregov\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/azuregov\/wp-json\/wp\/v2\/users\/1765"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/azuregov\/wp-json\/wp\/v2\/comments?post=5645"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/azuregov\/wp-json\/wp\/v2\/posts\/5645\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/azuregov\/wp-json\/wp\/v2\/media\/20423"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/azuregov\/wp-json\/wp\/v2\/media?parent=5645"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/azuregov\/wp-json\/wp\/v2\/categories?post=5645"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/azuregov\/wp-json\/wp\/v2\/tags?post=5645"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}