7 Things to Know About Windows Azure Capacity

Windows Azure platform defines and enforces policies so that applications running on virtualized infrastructure will play nicely with each  other. Awareness of these resource policies is important for assessing the capacity for successful operations and also for predicting the operational expenses for planning purposes.

Numbers courtesy of Hanu Kommalapati’s Blog and the Windows Azure Storage Abstractions and their Scalability Targets Blog entry

1. Network Bandwidth

Network bandwidth is based on the size of Compute instance you request. The table below provides the details of the Instance sizes and the bandwidth share to each.

2. CPU Allocation

As with Network bandwidth CPU resource policies are implemented implicitly based on the instance type. The specific number of CPU cores that come with each role is shown below.

3. Memory Allocation

Each instance is provisioned with a pre-configured amount of memory.  Role instances get their memory allocations based on the role type, from the remaining memory on the physical server, after the Root OS takes its share..

4. Instance Storage

Each Azure Instance gets an allocation of volatile disk storage. Depending on whether your application is stateless or not you need consider two key considerations. If the applications store information on this storage, if the cleanOnRoleRecycle configuration setting is not set to “false”, the storage is recycled during a instance reboot. Also storage does not persist if the instance has to be relocated to another physical server. This can occur is there is a an underlying issue with the physical server as Azure will maintain the instances your requested automatically.

For more information about these numbers read Hanu Kommalapati’s Blog

5. Windows Azure Storage

Unlike the Instance Storage mentioned earlier Windows Azure Storage persists. Windows Azure Storage provides four object Abstractions for data storage.

• Blobs – Provides a simple interface for storing named files along with metadata for the file.
• Tables – Provides massively scalable structured storage. A Table is a set of entities, which contain a set of properties. An application can manipulate the entities and query over any of the properties stored in a Table.
• Queues – Provide reliable storage and delivery of messages for an application to build loosely coupled and scalable workflow between the different parts (roles) of your application.
• Drives – Provides durable NTFS volumes for Windows Azure applications to use. This allows applications to use existing NTFS APIs to access a network attached durable drive. Each drive is a network attached Page Blob formatted as a single volume NTFS VHD. In this post, we do not focus on drives, since their scalability is that of a single blob.

6. In order to access any of the storage abstractions mentioned above you need a storage account.

When creating a storage account you can specify a location to place your storage account in. The six locations we currently offer are:

• US North Central
• US South Central
• Europe North
• Europe West
• Asia East
• Asia Southeast

As a best practice, you should choose the same location for your storage account and your instances.

7. Storage Capacities

A singe Storage Account can be up to 100TB in size. This is a hard limit. A single subscription can have 5 storage accounts. This limit is not fixed and more accounts can be requested via customer support.

• Blobs come in two flavours, Bock and Tables. A Block Blob can be up to 200GB in size. A Table Blob can be up to 1TB.
• A Table is a grouping of Entiries. A Entity is made up of Properties. A single  entity can hold up to 255 properties for which the combined size of all of the properties in an entity cannot exceed 1MB.
• A Queue contains Messages. There is no limit to the number of Messages a Queue can support beyond the limits of the Storage account. A message within a queue cannot exceed 8KB.
• Drives are handed as Page Blobs and so can be up to 1TB in size