Guide to Windows Azure: Part 3 - How to configure local storage resources

<< Read the second part of this Windows Azure tutorial

This is the third article in our Windows Azure guide series, aimed at helping you understand the intricacies of Microsoft’s Windows Azure cloud platform. Subsequent to the Spring Update released in June 2012, the Windows Azure landscape has additional features available on preview, as shown in Figure 1.

Figure 1. Windows Azure landscape, Spring Update: June 7, 2012.

The Platform as a Service(PaaS) offering of the Windows Azure platform has been rebranded as “Cloud Services”, and enhanced with the latest version of the SDK – 1.7 (download link here). This installment of our Windows Azure learning series focuses on the use of local storage in the Azure Cloud Services. Other salient features and new additions will be discussed in subsequent installments.

Storage options

Designing and architecting an application for Cloud Services involves making it easily scalable and highly distributed. Accordingly, the data tier can be one of the following:

• SQL database: A relational database on the cloud, which is a cloud optimized version of SQL Server 2012. 
• Azure storage: Inexpensive and highly scalable storage which is REST enabled, available as Tables (first normal form or entity store), Blobs (binary large objects) and Queues (messaging).
• Local storage: Fastest storage access, such as file IO on local drive of the deployed server instance.
• On-premise / custom store: Connect to any data store on premise.

Local storage

Local storage is the fastest storage access and very similar to standard file I/O operations (such as .NET’s System.IO.FileStream). This is the storage available in the local drives of the virtual machines wherein the application is deployed. Each of the virtual machines has virtual hard drives (VHDs) connected to them where subdirectories associated with the VHDs can be accessed. The maximum amounts of local storage that can be consumed on VMs are as follows:

No Windows Azure tutorial will be complete without the key highlights that need to be taken note of when assigning a local storage (say “foo”) to an Azure “Web Role”:

• You can access this local directory space only with the abstract / logical name “foo”.
• If you have, say, five instances of this Web Role deployed, this means that you have five virtual machines being used, and each of these virtual machines will have a logical local storage called foo.
• You can control or write to the local storage ONLY programmatically in your Web Role project.
• Data of one instance is independent of the data stored in the other instances. You can programmatically synchronize these or keep them different. However, local storage available to a single instance is not automatically shared to the other instances.
• In essence, the conclusion that you can draw from the above points is that if you need to store persistent data that needs to be shared across instances and keep it durable, then other storage options would need to be considered.  

Usage scenarios for local storage

1. Local cache: For frequently used data that needs very fast access, configure local storage as a cache. If the instance dies, the local data will be lost, but the cache can be built again.
2. Diagnostics monitoring logs: Monitoring a deployed application in the Windows Azure platform is as critical and building the app itself. The various logs, traces, crash dumps, performance counters, and so on, can be stored in local storage before a scheduled transfer to persistent storage (such as Azure tables and blobs).
3. Scratchpad storage: There might be a need in your application to have quick access to some transient data that need not be saved (for instance, messages in a chat room without save history). Using local storage is highly recommended in such cases.
4. File IO during migration: In normal ASP.NET one can store some files with configuration settings or any other details in a virtual path on the Web server, which can then be accessed by “Server.MapPath(“logicalName”)”. During migration of such applications, the Windows Azure counterpart is usage of the local storage.

Configuring local storage in an application

Here is a step-by-step Windows Azure guide to configuring local storage in an application:

1. Define local storage:

a) Manual: In the service definition File, you can manually add any number of local storage virtual names under “local resources” as shown in Figure 2.

1. 

   Figure 2. Manual addition of local storage.

b) Wizard:  In the properties pane of the “Web/Worker” role, there is a section called local resources that can be used to configure local storage as shown in Figure 3.

1. 

   Figure 3. Local resources wizard.

   The “clean on role recycle” indicates that as and when the role instances are recycled, the data will be lost. This role recycle may happen because of a catastrophic failure of the server, upgrade to the application or the operating system environment by the fabric controller or when the role forces a recycle by executing “RoleEnvironment. RequestRecycle()” method. Hence, by default, the data is restored and persists, but durability of this data is not guaranteed.

2. Access local storage

In terms of APIs for .NET developers, the Web or Worker Role’s base class is the “RoleEnvironment”, which has a method called “GetLocalResource”, returning a reference to a named “LocalResource” object that represents a directory. Hence we can read or write to it using standard .NET I/O classes. LocalResource.RootPath will return the full path of the local storage.

The code snippet shown in Figure 4 uses the above classes and methods to access the local storage that was defined earlier to do some file write and read operations. The output will be a label (localStorelbl) with the contents specified. Similar methods are available for Java and PHP developers as well.

Figure 4. Accessing local storage.

Another example that demonstrates a File Upload that is saved into the local storage is shown in Figure 5.

Figure 5. File upload to local storage.

In conclusion of our Windows Azure guide to local storage, we would like to reiterate that local storage stores transient data that can be rapidly accessed and stored on a “per-instance” basis rather than synchronized across all the roles/instances. With the new updates of the spring launch, local storage has been further enhanced to create a “distributed caching” solution as a readily available service that uses local storage from all the instances to create a synchronized high speed cache, which is a free offering.