Merge pull request #26820 from iainfoulds/windows-infra-breakout

Windows infrastructure guideline break-out

articles/virtual-machines/virtual-machines-windows-infrastructure-availability-sets-guidelines.md

@@ -0,0 +1,52 @@
+<properties
+	pageTitle="Availability Set Guidelines | Microsoft Azure"
+	description="Learn about the key design and implementation guidelines for deploying Availability Sets in Azure infrastructure services."
+	documentationCenter=""
+	services="virtual-machines-windows"
+	authors="iainfoulds"
+	manager="timlt"
+	editor=""
+	tags="azure-resource-manager"/>
+
+<tags
+	ms.service="virtual-machines-windows"
+	ms.workload="infrastructure-services"
+	ms.tgt_pltfrm="vm-windows"
+	ms.devlang="na"
+	ms.topic="article"
+	ms.date="06/30/2016"
+	ms.author="iainfou"/>
+
+# Availability sets guidelines
+
+[AZURE.INCLUDE [virtual-machines-windows-infrastructure-guidelines-intro](../../includes/virtual-machines-windows-infrastructure-guidelines-intro.md)] 
+
+This article focuses on understanding the required planning steps for availability sets to ensure your applications remains accessible during planned or unplanned events.
+
+## Implementation guidelines for availability sets
+
+Decisions:
+
+- How many availability sets do you need for the various roles and tiers in your application infrastructure?
+
+Tasks:
+
+- Define the number of VMs in each application tier you require.
+- Determine if you need to adjust the number of fault or update domains to be used for your application.
+- Define the required availability sets using your naming convention and what VMs will reside in them. A VM can only reside in one availability set. 
+
+## Availability sets
+
+In Azure, virtual machines (VMs) can be placed in to a logical grouping called an availability set. When you create VMs within an availability set, the Azure platform will distribute the placement of those VMs across the underlying infrastructure. Should there be a planned maintenance event to the Azure platform or an underlying hardware / infrastructure fault, the use of availability sets would ensure that at least one VM remains running.
+
+As a best practice, applications should not reside on a single VM. An availability set that contains a single VM doesn't gain any protection from planned or unplanned events within the Azure platform. The [Azure SLA](https://azure.microsoft.com/support/legal/sla/virtual-machines) requires two or more VMs within an availability set in order to allow the distribution of VMs across the underlying infrastructure.
+
+The underlying infrastructure in Azure is divided in to update domains and fault domains. These domains are defined by what hosts will share a common update cycle, or share similar physical infrastructure such as power and networking. Azure will automatically distribute your VMs within an availability set across domains to maintain availability and fault tolerance. Depending on the size of your application and the number of VMs within an availability set, you can adjust the number of domains you wish to use. You can read more about [managing availability and use of update and fault domains](virtual-machines-windows-manage-availability.md).
+
+When designing your application infrastructure, you should also plan out the application tiers that you will use. Group together VMs that serve the same purpose in to availability sets, such as an availability set for your front-end VMs running IIS. Create a separate availability set for your back-end VMs running SQL Server. The goal is to ensure that each component of your application is protected by an availability set and at least once instance will always remain running.
+
+Load balancers can be utilized in front of each application tier to work alongside an availability set and ensure traffic can always be routed to a running instance. Without a load balancer, your VMs may continue running throughout planned and unplanned maintenance events, but your end users may not be able to resolve them if the primary VM is unavailable.
+
+
+## Next steps
+[AZURE.INCLUDE [virtual-machines-windows-infrastructure-guidelines-next-steps](../../includes/virtual-machines-windows-infrastructure-guidelines-next-steps.md)] 

articles/virtual-machines/virtual-machines-windows-infrastructure-example.md

@@ -0,0 +1,133 @@
+<properties
+	pageTitle="Example Infrastructure Walkthrough | Microsoft Azure"
+	description="Learn about the key design and implementation guidelines for deploying an example infrastructure in Azure."
+	documentationCenter=""
+	services="virtual-machines-windows"
+	authors="iainfoulds"
+	manager="timlt"
+	editor=""
+	tags="azure-resource-manager"/>
+
+<tags
+	ms.service="virtual-machines-windows"
+	ms.workload="infrastructure-services"
+	ms.tgt_pltfrm="vm-windows"
+	ms.devlang="na"
+	ms.topic="article"
+	ms.date="07/01/2016"
+	ms.author="iainfou"/>
+
+# Example Azure infrastructure walkthrough
+
+[AZURE.INCLUDE [virtual-machines-windows-infrastructure-guidelines-intro](../../includes/virtual-machines-windows-infrastructure-guidelines-intro.md)] 
+
+This article walks through building out an example application infrastructure. We'll detail designing an infrastructure for a simple on-line store that brings together all of the guidelines and decisions around naming conventions, availability sets, virtual networks and load balancers, and actually deploying your virtual machines (VMs).
+
+
+## Example workload
+
+Adventure Works Cycles wants to build an on-line store application in Azure that consists of:
+
+- Two IIS servers running the client front-end in a web tier
+- Two IIS servers processing data and orders in an application tier
+- Two Microsoft SQL Server instances with AlwaysOn availability groups (two SQL Servers and a majority node witness) for storing product data and orders in a database tier
+- Two Active Directory domain controllers for customer accounts and suppliers in an authentication tier
+- All of the servers are located in two subnets:
+	- a front end subnet for the web servers 
+	- a back end subnet for the application servers, SQL cluster, and domain controllers
+
+![](./media/virtual-machines-common-infrastructure-service-guidelines/example-tiers.png)
+
+Incoming secure web traffic needs to be load-balanced among the web servers as customers browse the on-line store. Order processing traffic in the form of HTTP requests from the web servers needs to be balanced among the application servers. Additionally, the infrastructure must be designed for high availability.
+
+The resulting design must incorporate:
+
+- An Azure subscription and account
+- A single resource group
+- Storage accounts
+- A virtual network with two subnets
+- Availability sets for the VMs with a similar role
+- Virtual machines
+
+All of the above will follow these naming conventions:
+
+- Adventure Works Cycles uses **[IT workload]-[location]-[Azure resource]** as a prefix
+	- For this example, "**azos**" (Azure On-line Store) is the IT workload name and "**use**" (East US 2) is the location
+- Storage accounts use adventureazosusesa**[description]**
+	- Note that 'adventure' was added to the prefix to provide uniqueness, and storage account names do not support the use of hyphens.
+- Virtual networks use AZOS-USE-VN**[number]**
+- Availability sets use azos-use-as-**[role]**
+- Virtual machine names use azos-use-vm-**[vmname]**
+
+
+## Azure subscriptions and accounts
+
+Adventure Works Cycles is using their Enterprise subscription, named Adventure Works Enterprise Subscription, to provide billing for this IT workload.
+
+
+## Storage accounts
+
+Adventure Works Cycles determined that they needed two storage accounts:
+
+- **adventureazosusesawebapp** for the standard storage of the web servers, application servers, and domain controllers and their data disks.
+- **adventureazosusesasql** for the Premium storage of the SQL Server VMs and their data disks.
+
+
+## Virtual network and subnets
+
+Because the virtual network does not need ongoing connectivity to the Adventure Work Cycles on-premises network, they decided on a cloud-only virtual network.
+
+They created a cloud-only virtual network with the following settings using the Azure portal:
+
+- Name: AZOS-USE-VN01
+- Location: East US 2
+- Virtual network address space: 10.0.0.0/8
+- First subnet:
+	- Name: FrontEnd
+	- Address space: 10.0.1.0/24
+- Second subnet:
+	- Name: BackEnd
+	- Address space: 10.0.2.0/24
+
+
+## Availability sets
+
+To maintain high availability of all four tiers of their on-line store, Adventure Works Cycles decided on four availability sets:
+
+- **azos-use-as-web** for the web servers
+- **azos-use-as-app** for the application servers
+- **azos-use-as-sql** for the SQL Servers
+- **azos-use-as-dc** for the domain controllers
+
+
+## Virtual machines
+
+Adventure Works Cycles decided on the following names for their Azure VMs:
+
+- **azos-use-vm-web01** for the first web server
+- **azos-use-vm-web02** for the second web server
+- **azos-use-vm-app01** for the first application server
+- **azos-use-vm-app02** for the second application server
+- **azos-use-vm-sql01** for the first SQL Server server in the cluster
+- **azos-use-vm-sql02** for the second SQL Server server in the cluster
+- **azos-use-vm-dc01** for the first domain controller
+- **azos-use-vm-dc02** for the second domain controller
+
+Here is the resulting configuration.
+
+![](./media/virtual-machines-common-infrastructure-service-guidelines/example-config.png)
+
+This configuration incorporates:
+
+- A cloud-only virtual network with two subnets (FrontEnd and BackEnd)
+- Two storage accounts
+- Four availability sets, one for each tier of the on-line store
+- The virtual machines for the four tiers
+- An external load balanced set for HTTPS-based web traffic from the Internet to the web servers
+- An internal load balanced set for unencrypted web traffic from the web servers to the application servers
+- A single resource group
+
+
+## Next steps
+
+[AZURE.INCLUDE [virtual-machines-windows-infrastructure-guidelines-next-steps](../../includes/virtual-machines-windows-infrastructure-guidelines-next-steps.md)] 

articles/virtual-machines/virtual-machines-windows-infrastructure-naming-guidelines.md

@@ -0,0 +1,111 @@
+<properties
+	pageTitle="Infrastructure Naming Guidelines | Microsoft Azure"
+	description="Learn about the key design and implementation guidelines for naming in Azure infrastructure services."
+	documentationCenter=""
+	services="virtual-machines-windows"
+	authors="iainfoulds"
+	manager="timlt"
+	editor=""
+	tags="azure-resource-manager"/>
+
+<tags
+	ms.service="virtual-machines-windows"
+	ms.workload="infrastructure-services"
+	ms.tgt_pltfrm="vm-windows"
+	ms.devlang="na"
+	ms.topic="article"
+	ms.date="06/30/2016"
+	ms.author="iainfou"/>
+
+# Infrastructure naming guidelines
+
+[AZURE.INCLUDE [virtual-machines-windows-infrastructure-guidelines-intro](../../includes/virtual-machines-windows-infrastructure-guidelines-intro.md)] 
+
+This article focuses on understanding how to approach naming conventions for all your various Azure resources in order to build a logical and easily identifiable set of resources across your environment.
+
+## Implementation guidelines for naming conventions
+
+Decisions:
+
+- What are your naming conventions for Azure resources?
+
+Tasks:
+
+- Define the affixes that you will use across your resources to maintain consistency.
+- Define storage account names given the requirement for them to be globally unique.
+- Document the naming convention to be used and distribute to all parties involved to ensure consistency across deployments.
+
+## Naming conventions
+
+You should have a good naming convention in place before creating anything in Azure. A naming convention ensures that all the resources have a predictable name, which helps lower the administrative burden associated with managing those resources.
+
+You might choose to follow a specific set of naming conventions defined for your entire organization or for a specific Azure subscription or account. Although it is easy for individuals within organizations to establish implicit rules when working with Azure resources, when a team needs to work on a project on Azure, that model does not scale well.
+
+You should agree on a set of naming conventions up front. There are some considerations regarding naming conventions that cut across that sets of rules.
+
+## Affixes
+
+As you look to define a naming convention, one decision comes as to whether the affix will be at:
+
+- The beginning of the name (prefix)
+- The end of the name (suffix)
+
+For instance, here are two possible names for a Resource Group using the `rg` affix:
+
+- Rg-WebApp (prefix)
+- WebApp-Rg (suffix)
+
+Affixes can refer to different aspects that describe the particular resources. The following table shows some examples typically used.
+
+| Aspect                               | Examples                                                               | Notes                                                                                                      |
+|:-------------------------------------|:-----------------------------------------------------------------------|:-----------------------------------------------------------------------------------------------------------|
+| Environment                          | dev, stg, prod                                                         | Depending on the purpose and name of each environment.                                                     |
+| Location                             | usw (West US), use (East US 2)                                         | Depending on the region of the datacenter or the region of the organization.                               |
+| Azure component, service, or product | Rg for resource group, VNet for virtual network                        | Depending on the product for which the resource provides support.                                          |
+| Role                                 | sql, ora, sp, iis                                                      | Depending on the role of the virtual machine.                                                              |
+| Instance                             | 01, 02, 03, etc.                                                       | For resources that have more than one instance. For example, load balanced web servers in a cloud service. |
+
+
+When establishing your naming conventions, make sure that they clearly state which affixes to use for each type of resource, and in which position (prefix vs suffix).
+
+## Dates
+
+It is often important to determine the date of creation from the name of a resource. We recommend the YYYYMMDD date format. This format ensures that not only the full date is recorded, but also that two resources whose names differ only on the date will be sorted alphabetically and chronologically at the same time.
+
+## Naming resources
+
+You should define each type of resource in the naming convention, which should have rules that define how to assign names to each resource that is created. These rules should apply to all types of resources, for example:
+
+- Subscriptions
+- Accounts
+- Storage accounts
+- Virtual networks
+- Subnets
+- Availability sets
+- Resource groups
+- Virtual machines
+- Endpoints
+- Network security groups
+- Roles
+
+To ensure that the name provides enough information to determine to which resource it refers, you should use descriptive names.
+
+## Computer names
+
+When you create a virtual machine (VM), Microsoft Azure requires a VM name of up to 15 characters which is used for the resource name. Azure uses the same name for the operating system installed in the VM. However, these names might not always be the same.
+
+In case a VM is created from a .vhd image file that already contains an operating system, the VM name in Azure can differ from the VM's operating system computer name. This situation can add a degree of difficulty to VM management, which we therefore do not recommend. Assign the Azure VM resource the same name as the computer name that you assign to the operating system of that VM.
+
+We recommend that the Azure VM name be the same as the underlying operating system computer name.
+
+## Storage account names
+
+Storage accounts have special rules governing their names. You can only use lowercase letters and numbers. See [Create a storage account](../storage/storage-create-storage-account.md#create-a-storage-account) for more information. Additionally, the storage account name, in combination with core.windows.net, should be a globally valid, unique DNS name. For instance, if the storage account is called mystorageaccount, the following resulting DNS names should be unique:
+
+- mystorageaccount.blob.core.windows.net
+- mystorageaccount.table.core.windows.net
+- mystorageaccount.queue.core.windows.net
+
+
+## Next steps
+[AZURE.INCLUDE [virtual-machines-windows-infrastructure-guidelines-next-steps](../../includes/virtual-machines-windows-infrastructure-guidelines-next-steps.md)]