Authors

Santiago Cánepa – Premier Field Engineer – Microsoft
Hugo Salcedo – Premier Field Engineer – Microsoft

Hugo and I presented a session a few months ago about Azure limits and unlimited scalability. The session went very well, and we had a blast doing it.

Introduction

Azure promises unlimited scalability, but the documentation does not exactly tell you how to achieve it. Continuing in the spirit of our previous posts to provide guidance, we thought we’d shed some light into what it means to be unlimitedly scalable:

The word “limit” and its derivatives are a bit funny, since they appear in the text above, but also in the text below:

Turns out we offer unlimited servers and storage, with limits on servers and storage… Somewhat confusing, to say the least!

You see, these two excerpts from the Azure website are referring to different things, so they are really not contradictory.

The first one is referring to the ability to create unlimitedly scalable applications, whereas the second is referring to the implementation details of Azure, which you need to bear in mind, to be able to avoid scalability pitfalls, hindering your scalability potential.

Although in our presentation we discussed the concept of scalability, scale units, and some of the most popular and important patterns of scalability, we wanted to focus this blog entry on the more practical topics, more specifically Azure limits, how they interact, and how to plan for large deployments.

Limits

Let’s take a look at the currently existing limits. These are publicly published and are refreshed fairly often, when changes are introduced. This is great, since when we started with Azure, there was no single place to look these limits up, leaving it to each individual to keep a list and maintain it!

https://azure.microsoft.com/en-us/documentation/articles/azure-subscription-service-limits/

We are going to focus our analysis on IaaS virtual machines, but you must consider that the same principles apply to any type of resource in Azure.

Soft Limits vs. (almost) hard Limits

You have probably noticed that when limits are published, there are two types of limits: Default and Maximum.

The default limit are those enforced when a subscription is created. They prevent excessive consumption of resources, which helps both the subscriber and Azure. From the subscriber point of view, it helps prevent excessive consumption of resources, and requires explicitly extending the limits (by means of a support ticket) if needed. From the Azure perspective, it helps ensure that there is no single customer trying to consume too many resources (e.g. trying to exhaust Azure resources on purpose).

The default limits are considered soft limits when there is a higher maximum limit.

Now notice that the maximum (hard) limit, is a number which we have seen adjust up as new capabilities and capacity are added to the datacenters. Although strictly speaking, these are not hard limits, at any point in time we consider them hard limits because we can’t request more resources than those maximum limits at the time of the request.

Resources

When we create these virtual machines, we have to properly size them. Selecting a particular VM size, not only determines the number of cores and memory size, but it also determines how many data disks you can attach, the size of the temporary storage (D: Drive), and the bandwidth associated. Notice that for PaaS VMs, the size of the temporary storage is larger than that of IaaS, but also depends on the size. Another important aspect is whether they can be associated to load balanced endpoints, which is determined by the service tier.

Cores

A subscription has an associated number of cores that they can allocate. This is an aggregate of all the VMs (PaaS and IaaS) for the subscription. Although shared cores are cheaper from a billing standpoint, they count as one core towards this limit.

Considering that the current default limit on cores is 20 cores per subscription, the largest machine combination we could create is one 16 core VM and one 4 core VM. Also, we could have 20 VMs with either shared cores or one core.

If we increase the limit of cores for the subscription to its maximum of 10,000, things get a bit more interesting. Could we create 10,000 VMs, with one core each? It depends. Before we jump to create this many machines, we have to consider other details:

· Do the machines need to “talk” to each other via a private network connection (as opposed to accessing each other via a public endpoint)?

· Do the machines need any extra storage attached?

· How many endpoints must each have?

· What public names (and associated VIPs) are required?

Depending on the answers to these questions, each subscription will be able to host more or less resources.

Cloud Services

Let’s take the case where we need to create a large number of VMs. Considering the connectivity (or isolation) requirements, the number of computers that a subscription can host will vary greatly.

Say we want all machines to connect to each other. We could leverage the implicit networking features of cloud services. We get connectivity and even name resolution with very low effort.

Now, if we consider limits in cloud services, we’ll see that we can create 50 VMs per cloud service. For PaaS, the concept of “deployments” comes into play. This effectively splits the amount of VMs that can communicate among each other to 25 (still 50 per cloud service).

If you consider the default number of 20 cloud services, you will be able to have 20 sets of 50 connected computers, totaling 1,000 VMs. Increase the limit of cloud services to its maximum of 200, and you’ll get 200 sets of 50 computers, totaling, 10,000 VMs. Now remember, if you get to this point, these can only be shared or one core VMs. As you can see, there are “limit interactions” that you have to consider at all times.

Networking

Now, let’s imagine that all those computers we need to create must have connectivity among each other. For this, we would need to rely on virtual networking.

We can create a virtual network and try to provision all the VMs to that virtual network. However, there are limits at the virtual network level as well. If you looked closely at the limits, you might have noticed that virtual network have an associated limit of 2,048 virtual machines. What this means is that although technically, you can have 10,000 single core VMs, you can’t just network them using one single virtual network.

So how can we create a set of more than 2,048 computers with connectivity among them? Well, in order to do that, you’ll need to create a set of virtual networks and link them with VPN connections.

Like everything else, virtual networks are not free of limits. You can only have 10 VPN connections per virtual network. So let’s say you create 10 virtual networks and connect each with all others, you would have 10 Virtual networks * 2,048 VMs, yielding a total of 20,480 VMs.

Not so fast!

At this point, you will have hit the 10,000 core per subscription limit, so at this point, you would not be able to implement the above scenario… at least not in a single subscription.

The nice thing is that when you manage an Azure account, you will be able to have an unlimited number of subscriptions associated to that account. This opens things up to the promise of unlimited compute power. Of course, the physical limit of the data center will be a next limit (or rather, the amount of money you would have to cough up in order to pay for the usage of all those resources).

With some careful networking and resource planning, you could have an arbitrarily big compute setup that could satisfy almost any need.

Storage

Compute and Networking are two of the Azure services that depend on each other. The third service mandatory of consideration is Storage.

The reason this service is of special importance is that it is used as backing for the virtual hard disks of the VMs that are created.

Just like any other service, storage has many capabilities and many associated limits. The first important limit is the size to which a single storage account can grow. The importance of this limit is that the aggregate size of the disks associated to a VM (OS or data disks) cannot exceed the limit for the storage account.

Another important limit is the level of sustained performance that a single blob and the storage account as a whole can provide. These are expressed in IOPS and, at the time of writing, a single blob will have a target of 500 IOPS, with 20,000 IOPS at the storage account level. A quick calculation shows that a single storage account can host up to 40 virtual disks which could have simultaneous bursts without being throttled. Notice that we can store a much higher number of virtual disks in one single storage account, but we are using 40 as a best practice to ensure that the maximum performance can be achieved for every virtual hard disk in the storage account.

Now, this adds another important piece of information: considering that we can have 100 storage accounts, and that each could have 40 virtual hard disks (for maximum performance), then we could have, at most, 4,000 single-disk VMs (this number would decrease linearly, as the number of virtual hard disks increases per VM).

Limit interaction

As described in the previous sections, there are interactions across the different limits that must be considered when designing an Azure implementation:

We could have 10 VMs with 2,048 VMs each totaling 20,480 VMs in a subscription…

But we can only have 10,000 cores or 10,000 single-core computers in a subscription (remember that shared cores count as one core towards resource accounting)…

And even if we could have more cores, we still can only have 200 cloud services hosting a maximum of 50 VMs each, totaling 10,000 VMs…

But for them to be performing, we can only have 100 storage accounts hosting 40 virtual disks, totaling 4,000 single disk VMs.

Fortunately, we can have as many subscriptions as we want.

Other Limits

Remember that the limits mentioned above are not the only limits to consider. For instance, if we are deploying many machines to a virtual network, ensure that the subnets in which you are placing the VMs have enough free addresses for each computer.

Other services

Among the 4 big categories of services: Compute, Networking, Data, and Application, there are many services in Azure.

All these have different limits, and each will have different ways to measure what they do, how well they do it, and how they are constrained by limits. Likewise, their approach to scalability depends on the specific metaphor they present. It is well beyond the scope of this post to discuss those, but if you are planning of using other services, you should be familiar with the specific scalability capabilities.

In closing

There are many things to consider when planning a large scale architecture. We can’t possibly mention all the limits and their interaction, so we wanted to just focus on a few to get you thinking about the topic. These are the ones we see customers hit the most quickly, and struggle to overcome them. We hope that this post helps you reach your limitless self.

Authors

This article was moved as-is to the official Azure documentation. After several updates at that location, it was split into several articles, a couple of which are:

• https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-infrastructure-subscription-accounts-guidelines/
• https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-infrastructure-naming-guidelines/

Other parts of the document have been merged into several other documentation articles, and some other parts are obsolete. Please refer to the official Azure documentation for the latest best practices, at https://azure.microsoft.com/en-us/documentation/articles/?term=Best+Practices

1 - Introduction

The Windows Azure Technical Documentation Library does an excellent job at describing each resource in the Azure infrastructure, but there exists little guidance on how to put the pieces together.

This document describes several areas where good planning goes a long way to ensure that the infrastructure built on top of Microsoft Azure can withstand the needs to make changes without affecting the manageability of the solutions.

2 - Implementation Guidance Overview

This guidance focuses on planning of a variety of resources that are involved in most of Azure implementations. The following diagram illustrates those resources:

Figure 1 - Implementation Guidance Overview

Although it is not a big secret that planning is key to a successful implementation of any solution, we have seen that many customers start using Azure without a complete view of the final product. This may be due to a variety of reasons, some of which are:

·         Learning – Customers start using Azure as they learn about it, and with very little effort, they achieve satisfactory use of the platform. Unfortunately, they rush to call their work “production-grade” which limits the flexibility to make changes to what has been implemented.

·         Ease of Use – Like many Microsoft products, Azure seems “easy enough” to use, and they, again, move to implement production workloads, without clear understanding of future growth.

·         Proof of Concepts – Azure represents an excellent platform to implement proof of concept exercises, since it requires very little investment to test a particular approach to implementation of solutions. Many times, customers incorrectly label these proof-of-concept exercises as baseline for a full implementation of the solution, and many decisions that they took lightly, with the intent of further research, are involuntarily pushed as permanent.

This guidance identifies many areas for which planning is key to the success of the Azure implementation.

In addition, it helps the implementation of solutions on the Azure platform by providing an order to the creation of the necessary resources. Although there is some flexibility, we suggest following a methodic order to minimize the need for rework.

v Naming Conventions

Ø Accounts

§ Subscriptions

Ø Affinity Groups

Ø Storage

Ø Virtual Networks

§ Subnets

§ Site Connectivity

Ø Azure Building Blocks

Ø Cloud Services

§ Virtual Machines

§ PaaS Deployments

For example, let us consider a fictitious application that the IT operations of Contoso is trying to implement on Azure. The application is a calculation engine for advanced financial operations. This application exposes a front end, implemented as a set of IIS web services, running on Microsoft Azure IaaS. These servers consume web services hosted on several application servers, which also expose a load balanced web service API. At the same time, these consume information from a database. The following diagram conceptually depicts the application’s infrastructure:

Figure 2 – Design of Contoso’s fictitious Financial Calculation Engine

The implementation plan for Microsoft Azure is to create two cloud services under the same subscription: one cloud service to host the web servers, and another cloud service to host both the application servers and the database server.

If the default settings were to be used when creating one of the front servers, Microsoft Azure would use many default values. The following screen shows how one of the IIS Web servers where created for the front end:

Figure 3 - New Virtual Machine created using Quick Create

When Microsoft Azure creates a virtual machine this way, the resulting resources are as follows:

Figure 4 - Resources associated to a Quick Created VM

Figure 5 - Detail of the virtual machine

Several issues become evident in the above configuration:

·         The virtual machine name is the same as the cloud service name, which will make it confusing when managing the solution.

·         The storage account name is automatically generated using the string “portalvhds”, plus a set of random characters to make it unique.

·         The system disk name associated to the virtual machine is a combination of the cloud service name, the virtual machine name, the LUN number, and the date of its creation. When the number of disks increases, these names become difficult to identify, especially since the cloud service name coincides with one of the virtual machines name.

·         The vhd associated to the disk uses the same name as the disk with a “.vhd” extension. As with disks,

Establishing a good naming convention, as well as following a specific, systematic order to create the resources in Azure immensely reduces administrative burden and increases the chances of success for any implementation project.

3 - Guidance Areas

3.1 - Naming Conventions

A good naming convention should be in place before creating any artifact in an azure account. A naming convention ensures that all the resources will have a predictable name, which helps lower the administrative burden associated with management of those resources.

Each customer may choose to follow a specific set of naming conventions defined for the customer as a whole, for a particular Azure account, or for an Azure subscription.

It is easy for individuals to establish implicit rules when working with Azure resources. However, when a team needs to work on a project on Azure, that model does not scale well.

The important point is that the customers agree upon the set of naming conventions up front.

3.1.1 - General Considerations

There are some considerations regarding naming conventions that cut across the sets of rules that make up those conventions. The following sections describe these considerations.

3.1.1.1 - Affixes

When creating certain resources, Microsoft Azure will use some defaults to simplify management of the resources associated to these resources. For instance, when creating the first virtual machine for a new cloud service, Azure will suggest using the virtual machine’s name as the name for the cloud service.

Although this will not present problems, it may be beneficial to identify types of resources that need an affix to identify that type. In addition, clearly specify whether the affix will be at the beginning of the name (prefix) or at the end (suffix).

For instance, here are two possible names for a service hosting a calculation engine:

·         SvcCalculationEngine (prefix)

·         CalculationEngineSvc (suffix)

Affixes can refer to different aspects that describe the particular resources. The following table shows some examples typically used.

Make sure that the naming conventions clearly state which affixes to use for each type of resource, and in which position (prefix vs suffix).

3.1.1.2 - Dates

Many times, it is important to determine from the name of an resource, the date of creation. We recommend specifying dates in the YYYYMMDD 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.

3.1.2 - Naming Resources

Customers must define each type of resource in the naming convention, which should have rules that define how to assign names to each resource created. These rules should apply to all types of resources, for instance:

·         Accounts

·         Subscriptions

·         Affinity Groups

·         Storage Accounts

·         Virtual Networks

·         Subnets

·         Availability Sets

·         Cloud Services

·         Virtual Machines

·         Endpoints

·         Roles

·         Etc.

3.1.2.1 – Descriptive Names

Names should be as descriptive as possible, to ensure that the name can provide enough information to determine to which resource it refers.

3.1.3 - Computer Names

When administrators create a virtual machine from the gallery, Microsoft Azure will require them to provide a virtual machine name. Microsoft Azure will use the virtual machine name as the Azure virtual machine resource name. Azure will use the same name as the computer name for the operating system installed in the virtual machine. However, these names may not always be the same. In cases in which a virtual machine is created from a .vhd file that already contains an operating system, the virtual machine name in Microsoft Azure may differ from the virtual machine’s OS computer name. This situation may add a degree of difficulty to virtual machine management and we discourage it. Always ensure that the Azure virtual machine resource name is the same name as the computer name as assigned to the operating system of that virtual machine.

We recommend that the Azure Virtual Machine name be the same as the underlying OS computer name. Because of this, follow the NetBios naming rules as described in this article: https://support.microsoft.com/kb/188997.

3.1.4 – Storage Account Names

Storage accounts have special rules governing their names. In general, they are lower case names, and the assigned name, concatenated to the service (blob, table, or queue) and the default domain (core.windows.net) should render a valid, unique DNS name. For instance, if the storage account is called mystorageaccount, the following resulting URLs should be valid, unique DNS names[1]:

·         mystorageaccount.blob.core.windows.net

·         mystorageaccount.table.core.windows.net

·         mystorageaccount.queue.core.windows.net

In addition, storage accounts may take advantage of containers. These must adhere to the naming conventions as described in Naming and Referencing Containers, Blobs, and Metadata.

3.2 - Account Management

In order to work with Azure, customers need subscriptions. Resources, like cloud services or virtual machines, exist in the context of those subscriptions.

Enterprise customers typically have an Enterprise Enrollment, which is the top-most resource in the hierarchy, and is associated to one or more accounts.

For consumers and customers without an Enterprise Enrollment, the top-most resource is the Account.

Subscriptions are associated to accounts, and there can be one or more subscriptions per account. Azure records billing information at the subscription level.

Due to the limit of two hierarchy levels on the Account/Subscription relationship, it is important to align the naming convention of accounts and subscriptions to the billing needs. For instance, if a global company uses Azure, they may choose to have one account per region, and have subscriptions managed at the region level.

Figure 6 - Simple Account/Subscription Hierarchy

For instance, a company may use the following structure:

Figure 7 - Example of a simple account/subscription hierarchy

Following the same example, if a region decides to have more than one subscription associated to a particular group, then the naming convention should incorporate a way to encode the extra on either the account or the subscription name. This organization allows massaging billing data to generate the new levels of hierarchy during billing reports. This is shown below:

Figure 8 - Complex account/subscription hierarchy, with subscription used to encode two levels

This way, the organization could look as follows[2]:

Figure 9 - Example of a complex account/subscription hierarchy

At the time of writing, Microsoft provides detailed billing via a downloadable file, typically for a single account, or for all accounts in an enterprise agreement. Customers can process this file, for example, using Excel. This process would ingest the data, partition the resources that encode more than one level of the hierarchy into separate columns, and use a pivot table or PowerPivot to provide dynamic reporting capabilities.

3.3 - Affinity Groups

Affinity groups are the way to group the services in your Microsoft Azure subscription that need to work together in order to achieve optimal performance.  It is very important that affinity groups be part of the solution design to guarantee the highest performance possible within the data center.

When customers create certain resources in an Azure subscription, they can specify to which affinity group the resource will belong. This ensures that all resources created within the same affinity group will be physically near in the data center, which increases the performance in their communications.

Customers should define the affinity groups ahead of time, following the naming convention.

For example, the following command creates the affinity group AgCalculationEnginePd for Contoso’s calculation engine application[3]:

To read more about affinity groups, please see: TechNet: Importance of Windows Azure Affinity Groups

3.4 – Storage Layout

Storage is an integral part of any Azure solution, since not only does it provide application level services, but it is also part of the infrastructure supporting virtual machines.

Things to bear in mind is that storage accounts are bound to scalability targets. At the time of writing, the highest scalability targets are for accounts created after June 7, 2012. These targets were published in the Windows Azure Storage Blog:

v Capacity – Up to 200 TBs

Ø Maximum size per blob – 1 TB

v Transactions – Up to 20,000 entities/messages/blobs per second

v Bandwidth for a Geo Redundant storage account

Ø Ingress - up to 5 gigabits per second

Ø Egress - up to 10 gigabits per second

v Bandwidth for a Locally Redundant storage account

Ø Ingress - up to 10 gigabits per second

Ø Egress - up to 15 gigabits per second

v Throughput for a single blob – up to 60 Mbytes/sec

When creating new virtual machines, Azure creates them with an operating system disk and a temporary disk. The operating system disk is blob-backed, whereas the temporary disk is backed by storage local to the node where the machine lives. This makes the temporary disk unfit for data that must persist during a system recycle, since the machine may silently be migrated from one node to another, losing any data in that disk.

Operating System disks and Data disks have a maximum size of 1 TB since the maximum size of a blob is 1 TB. Customers can implement disk striping in Windows to surpass this limit.

3.4.1 – Striped Disks

Besides providing the ability to create disks larger than 1 TB, in many instances, using stripped disks for data disks will enhance performance by allowing multiple blobs to back the storage for a single volume. This parallelizes the IO required to write and read data from a single disk.

Note that Azure imposes limits on the amount of data disks and bandwidth available, depending on the virtual machine size:

Table 1 - Bandwidth and Disks for Virtual Machine sizes

3.4.2 - Multiple Storage Accounts

Using multiple storage accounts to back the disks associated to many virtual machines ensures that the aggregated IO of those disks is well below the scalability targets for each one of those storage accounts.

3.4.3 – Storage layout design

In order to implement these strategies to keep the disk subsystem of the virtual machines with good performance, the solution will take advantage of many storage accounts. These will host many vhd blobs. In some instances, more than one blob is associated to one single volume in a virtual machine.

This situation can add complexity to the management tasks. Designing a sound strategy for storage, including appropriate naming for the underlying disks and associated vhd blobs is key.

For example, for Contoso’s Calculation Engine application, two storage accounts are created, one for OS disks and another one for data disks. Note that this distinction is purely arbitrary to show the usage of two accounts. However, many other criteria for multiple storage accounts may be used.

3.5 - Virtual Networking

The next logical step is to create the virtual networks necessary to support the communications across the virtual machines in the solution.

Cloud services provide a communication boundary among computers within that cloud service. These computers can use IP Addresses or the Azure-provided DNS service to communicate with each other using the computer name.

Virtual networks also create a communication boundary, so that virtual machines within the same virtual network can access other computers within the same virtual network, regardless of to which cloud service they belong. Within the virtual network, this communication remains private, without the need for the communication to go through the public endpoints. This communication can occur via IP address, or by name, using a DNS service installed in the virtual network, or on premises, if the virtual machine is connected to the corporate network via a Site-to-Site connection. The Azure-provided DNS service will not aid in name resolution across cloud services, even if they belong to the same virtual network.

3.6 – Subnets

Subnets in Azure virtual networks do not impose communication boundaries, since a virtual network is able to bridge communications across subnets within the same virtual network.

However, subnets can offer a great way to organize resources that are related, either logically (e.g. one subnet for virtual machines associated to the same application, or physically (e.g. one subnet per cloud service.

Customers should design subnets with the same conceptual ideas that they use for on premise resources. Like all other named resources in Azure, subnets should adhere to the naming conventions.

In the Calculation Engine example, a virtual network is defined with the following schema:

The schema is applied by running the following command:

3.7 – Site Connectivity

If virtual networks require connectivity to on premise resources, customers can establish a VPN connection that extends the virtual network’s reach to the corporate network via the VPN tunnel.

After creating a virtual network and defining its subnets, customers can establish Site-to-Site and/or Point-to-Site connectivity if required.

3.8 - Azure Building Blocks

Azure Building Blocks are application level services that Azure offers, typically to those applications taking advantage of PaaS features, although IaaS resources may leverage some, like Azure SQL, Traffic Manager, and others.

These services rely on an array of artifacts that are created and/or registered in Azure. These also need to be considered in the naming convention.

3.9 - Availability Sets

In Azure PaaS, cloud services contain one or more roles that execute application code. Roles can have one or more virtual machine instances that the fabric automatically provisions. At any given time, Azure may update the instances in these roles, but because they are part of the same role, Azure knows not to update all at the same time to prevent a service outage for the role.

In Azure IaaS, the concept of role is not significant, since each IaaS virtual machine represents a role with a single instance. In order to hint Azure not to bring down two or more associated machines at the same time (e.g. for OS updates of the node where they reside), the concept of Availability Sets was introduced. An availability set tells Azure not to bring down all the machines in the same availability set at the same time to prevent a service outage.

Availability sets must be part of the high-availability planning of the solution, and must exist before the creation of cloud services and virtual machines.

In the example of Contoso’s Calculation Engine application, both front-end servers should be part of one availability set, and should be the application servers.

As with all other resources in an Azure deployment, availability sets must follow the naming convention.

3.10 - Cloud Services

Cloud services are a fundamental building block in Azure, both for PaaS and IaaS services.

For PaaS, cloud services represent an association of roles whose instances can communicate among each other. Cloud services are associated to a public virtual IP and a load balancer, which takes incoming traffic and load balances it to the roles configured to receive that traffic.

In the case of IaaS, cloud services offer similar functionality, although in most cases, the load balancer functionality is used to forward ports from the public endpoints to the many virtual machines within that cloud service.

Cloud service names are especially important in IaaS since they Azure uses them as part of the default naming convention for disks.

An important point to remember is that Microsoft Azure exposes the cloud service names, since they are associated to the public virtual IP, in the domain “cloudapp.net”. For better user experience of the application, a vanity name should be configured as needed to replace the fully qualified cloud service name.

In addition, the naming convention used for cloud services may need to tolerate exceptions since the cloud service names should be unique among all other Microsoft Azure cloud services, regardless of the Microsoft Azure tenant.

As discussed, the Contoso Calculation Engine application will use two cloud services: one for the front-end web servers and another one for the application and database servers:

3.11 - Virtual Machines

In Azure PaaS, Azure manages virtual machines and their associated disks. Customers have the ability to define and name roles, and Azure will create instances associated to those roles.

In the case of Azure IaaS, it is up to the customers to provide names for the cloud services, virtual machines, and associated disks.

To reduce administrative burden, the Azure Management Portal will use the computer name as a suggestion for the default name for the associated cloud service (in the case the customer chooses to create a new cloud service as part of the virtual machine creation wizard).

In addition, Azure names disks and their supporting vhd blobs using a combination of the cloud service name, the computer name, and the creation date.

In general, the number of disks will be much greater than the amount of virtual machines. Customers should be careful when manipulating virtual machines to prevent orphaning disks. Also, disks can be erased without deleting the supporting blob. If this is the case, the blob will remain in the storage account until manually erased.

These issues support the need to control the naming conventions for blobs supporting disks, disks, and virtual machines.

For in the example of Contoso, the virtual machines could be created using the following script:

Customers should ensure that they can track vhd blobs and disks back to the virtual machine for which they were created. For this, naming conventions must have clear rules regarding how names help tie these resources together.

4 - Conclusion

Starting with a naming convention and staying consistent to it goes a long way in keeping the Azure as manageable as possible, while setting up the stage for a long-lasting and reliable infrastructure.

In addition, following the right order in the creation of Azure resources, reduces the amount of re-work and refactoring, while increasing the chances of success.

5 - Glossary[4]

affinity group. A named grouping that is in a single data center. It can include all the components associated with an application, such as storage, Microsoft Azure SQL Database instances, and roles.

cloud. A set of interconnected servers located in one or more data centers.

hosted service. See Cloud Service.

Infrastructure as a Service (IaaS). A collection of infrastructure services such as storage, computing resources, and network that you can rent from an external partner.

Microsoft Azure. Microsoft's platform for cloud-based computing. It is provided as a service over the Internet using either the PaaS or IaaS approaches. It includes a computing environment, the ability to run virtual machines, Microsoft Azure storage, and management services.

Microsoft Azure Cloud Services. Web and worker roles in the Microsoft Azure environment that enable you to adopt the PaaS approach.

Microsoft Azure Management Portal. A web-based administrative console for creating and managing your Microsoft Azure hosted services, including Cloud Services, SQL Database, storage, Virtual Machines, Virtual Networks, and Web Sites.

Microsoft Azure SQL Database. A relational database management system (RDBMS) in the cloud. Microsoft Azure SQL Database is independent of the storage that is a part of Microsoft Azure. It is based on SQL Server and can store structured, semi-structured, and unstructured data.

Microsoft Azure storage. Consists of blobs, tables, and queues. It is accessible with HTTP/HTTPS requests. It is distinct from Microsoft Azure SQL Database.

Microsoft Azure Virtual Machine. Virtual machines in the Microsoft Azure environment that enable you to adopt the IaaS approach.

Microsoft Azure Virtual Network. Microsoft Azure service that enables you to create secure site-to-site connectivity, as well as protected private virtual networks in the cloud.

Microsoft Azure Web Sites. A Microsoft Azure service that enables you to quickly and easily deploy web sites that use both client and server side scripting, and a database to the cloud.

Platform as a Service (Paas). A collection of platform services that you can rent from an external partner that enable you to deploy and run your application without the need to manage any infrastructure.

web role. An interactive application that runs in the cloud. A web role can be implemented with any technology that works with Internet Information Services (IIS) 7.

worker role. Performs batch processes and background tasks. Worker roles can make outbound calls and open endpoints for incoming calls. Worker roles typically use queues to communicate with Web roles.

6 - Appendix – Sample naming convention for Contoso’s Calculation Engine

The examples throughout this document follow this sample naming convention for Contoso’s Calculation Engine application:

I tried running the sample, but I would get the following error:

“CurrentStorageAccountName is not accessible. Ensure the current storage account is accessible and in the same location or affinity group as your cloud service.”

Since I was not working with my default storage account, but rather specifying where the disks were to be created, I didn’t pay attention to the current storage account. Instead, I Bing’ed the error message and found Ross Bradbrook’s blog entry: New-AzureVM: CurrentStorageAccount is not Accessible.

It basically states that if you are creating a VM, and its cloud service already exists, you can’t specify a location or affinity group, or else you’ll get the error.

I completely forgot about that detail (I curse you, PowerShell tab completion!) and provided values to both. I thought “that’s easy enough”, removed the affinity group parameter and retried.

To my surprise, the command returned the same error:

Since I was out of ideas, I decided to turn on verbose debugging by setting the $DebugPreference variable to “Continue”.

When I retried the attempt, I got the following (partial) result. Note the white boxes highlighting the error:

The portalvhdsg87rhb7rnqrbl storage account was not found. I remembered that before starting to write the code sample, I completely cleaned up my Azure subscription, and had removed the account.

As a test, I re-created the storage account using the same name, retried the operation… and voilà! Everything worked like a charm.

I could have as well selected one of the other storage accounts as my current storage account and it would have worked also.

It is interesting, though, that there is a requirement that a valid current storage account exist, even if you are not using that storage account for the creation of the VM.

When they logged on to their management portal, their Virtual Networks resource manager was in an error state as shown below:

A quick communication with support shed some light into a known problem: white spaces.

Turns out that there is an unfortunate “feature” in the portal, which allows you to create local networks or DNS servers with a space in their names.

This will cause Azure to display the error icon on the Networks option on the left navigation bar. When you click on Networks, Azure will not update the screen and the UI for network management will not be available.

Although inconvenient, this is not too problematic, with a simple solution.

Since the virtual networks configuration is not available from the portal, we can resort to PowerShell to solve the problem.

We first export the configuration using the command Get-AzureVNetConfig as follows (ensure that the path for the file exists):

   Get-AzureVNetConfig –ExportToFile C:\Temp\AzureVNetConfig.netcfg

Open the file created by PowerShell in notepad:

  NotePad C:\Temp\AzureVNetConfig.netcfg

The file will look like:

<?xml version="1.0" encoding="utf-8"?>
  <NetworkConfiguration xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns="https://schemas.microsoft.com/ServiceHosting/2011/07/NetworkConfiguration">
    <VirtualNetworkConfiguration>
      <Dns>
        <DnsServers>
          <DnsServer name="Contoso" IPAddress="10.0.0.4" />
          <DnsServer name="Fabrikam" IPAddress="10.0.0.6" />
        </DnsServers>
      </Dns>
      <LocalNetworkSites>
        <LocalNetworkSite name="My Test">
          <AddressSpace>
            <AddressPrefix>10.1.0.1/8</AddressPrefix>
          </AddressSpace>
          <VPNGatewayAddress>10.0.0.1</VPNGatewayAddress>
        </LocalNetworkSite>
        .
        .
        .

Notice the highlighted name. In my case, I had created a local network called “My Test”.

Remove the space or rename the local network (or DNS server) with a valid name and save the file. Import the network configuration using the following command:

   Set-AzureVNetConfig –ConfigurationPath C:\Temp\AzureVNetConfig.netcfg

Go back to the management portal and you will see that the Network option is back to its sweet normal self.