Azure Service Discovery-Storage-local (localstorage) storage

Azure Service abstracts the entire service's requirements for storage into four objects, namely table storage, blob storage, queue (Queues) storage, and local temporary file storage (localstorage). where table storage and blob storage basically apply the most commonly used storage objects and are one of the key capabilities in a managed environment, it can be understood that both types of storage Azure platforms are billed and charged by traffic or size. Localstorage Storage and queue storage is also a capability that is often a tool and service offered to a scenario that is not billed because they are restricted and used for specific purposes, both in terms of architecture and design.

First of all, the local temporary file store for Azure service is localstorage.

Localstorage is a file system store that Azure service is free to use, and maybe in some scenarios you might want to store the file system way, like the scenario of the Sitemap example Jim Nakashima mentioned, which I think is just a technical FAQ, For example, before your ASP.net programming environment you are free to access the App_Data directory or even any directory, ASP. NET programming environment in Azure corresponds to the web role of the service or model, you can use a new function ... and so on.

A deeper consideration is that Azure service is hosted in the azure running environment, first it must follow Windows Azure trust policy, and secondly it needs to consider the changes in traditional programming style to cloud computing, because in azure In a running environment you may be faced with an instance of a bunch of numbered virtual machines, followed by a load balance, and you should establish the idea that all Azure service instances running in azure environments are load-balanced and, if it is a file system, So on different nodes, this file is not synchronized. So the existence of localstorage is destined to be a restricted function, by the above mentioned trust strategy and load balancing constraints, and later examples, we will see this.

It is convenient to use Localstorage first when writing Azure services. The steps are as follows:

First, in the service definition file Servicedefinition.csdef, define a localstorage reference, such as:

1: <localstorage name= "Myfilestorage/>"

Or

1: <localstorage name= "Myfilestorage" sizeinmb= "2"/>

SIZEINMB is an option that indicates how much space you want to allocate for this file storage. The service profile Serviceconfiguration.cscfg is not configured.

You can then use the Rolemanager.getlocalresource () method to get a reference to the file system path where the Azure runtime environment is assigned to succeed, and then manipulate it like an action file (more like we manipulate a resource file).

1:ilocalresource resource = Rolemanager.getlocalresource ("Mylocstorage");

2:

3:string Path = Path.Combine (resource. RootPath, "MessagesLogs.txt");

4:

5:using (FileStream stream = File.Open (path, FileMode.Open, FileAccess.Read, Fileshare.readwrite))

6:

7: ........

Through the code above, we see that the Azure Runtime environment will create the required file system storage for different roles based on the service configuration, the Azure runtime environment to manage the mappings between storage and file references, and a relative path provided to the developer, and we only operate on relative paths. This understanding is the same as Jim Nakashima example, it seems that Rolemanager.getlocalresource replaced the Server.MapPath function. Technically this is the case, but later we found that there are some differences.

With the above code, I made a small example as follows:

This example is an excerpt from the Azure Services training KIT-PDC Preview, which is like a message book, where you enter some text from the input box, and the send is then saved to the Localstorage file. Press Refresh to read the contents of the file from the Localstorage file.

When you run this simple example, you will find that when the instance in the Web role is set to more than 2 times (at present, the largest is 2, serviceconfiguration.cscfg files under <role name= "Webrole" >) <instances count= "2"/>), you will find that Localstorage is not shared in multiple tenats, you send new characters constantly, and then refresh finds that the contents of the file are changed/reduced, Because the request may be received by another instance (Tenats) and saved in a separate file.

Rule 1:localstorage file storage cannot be shared by multiple service instances/Tenats, and different service instances retain their own file system instances and stores, not shared among themselves. So localstorage is not suitable for saving requests (request)-related status and information

Rules 2:localstorage file storage cannot be shared among different roles of the same service. For example, between two Web role or a web role and a worker role.

You can download the code in my demo, and I redesigned the example, and I added a worker role, assuming that in addition to adding records in the foreground interface via send, you can also periodically add records by using the worker role in the background, This will allow you to see more records each time you refresh.

Of course, the worker role can also use localstorage, except that the location of the configuration is different from the web position above,

<webrole name= "Webrole" >

　

<localstorage name= "Mylocstorage"/>

　

</WebRole>

　

<workerrole name= "Worker" >

　

<localstorage name= "Mylocstorage"/>

　

</WorkerRole>

Adding worker role to a project is also very simple, just select your solution and then right-click, like this

Then add almost the same code as the Web role in the Worker role project, and you'll be able to run it, and when you're done, you'll notice that when you refresh the foreground interface, the contents of the two are inconsistent, and through the worker role background log, you find that the worker function is really working, But apparently it was saved to its own file.

Rule 3:localstorage is a non-persisted storage, that is, when Azure service/webrole/worker role is started, the Localstorage store exists, and when they are suspended and restarted, These stores are emptied, and when stopped, these files do not exist or are not available.

You download my example and you can quickly see this, so in a sense, localstorage is not only a locally restricted file store, but also a temporary one.

Keep in mind that localstorage and temporary, you can really use localstorage just right.