Refreshing Data on all Azure Instances

Question

What is the best way to refresh the data in all my Azure instances?

I have several instances each running the same web role. On role startup data is read from blob storage into local store. Intermittently there will be a new update to data used by the site. I want to be able to notify each instance programmatically to get the updated data from blob storage into the instance's local storage so that each instance becomes refreshed.

One idea is to write a custom client program to call a web-service on the web role, passing in a role ID to update. If the endpoint is the Role ID then the instance refreshes itself. If not the client tries again until all instances report that they are refreshed. Is this a good approach or is there a built in method in Azure for doing this?

I have considered a separate thread which intermittently checks for an refresh flag, though I'm worried my instances will become out of sync.

There is not a huge amount of data so I could put it in the Azure cache. However, I am concerned about the network latency with using the cache. Does the Azure cache handle this well?

Another idea is to just reboot the instances one after another (with the refresh operation being performed on the role start up).

Answer 1

I think one possible way you could do this is to use a setting (e.g. a timestamp) in a configuration setting - you can then programmatically update the configuration and use the RoleEnvironment.Changing event to do monitor for the change on all your instances - http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleenvironment.changing.aspx

If you do this make sure you intercept the event in all your roles - and make sure you parse the changes (looking for Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironmentConfigurationSettingChange) and return false to the Cancel parameter to prevent your instances from being rebooted.

Answer 2

Adding to Stuart's answer, let me address your proposed techniques:

• I don't think the client-calling-web-service technique is practical, as you've now added a web service as well as a client driver to call it, and you have no ability to contact individual web role instances - the load balancer hides the individual instances from you.
• You can store data in the cache, but the only way to update your data "now" is to expire items in the cache. If you have all of your data in a single cache item with a well-known key, then it's easy to expire. If it's across multiple keys, then you have a more complex task, and you won't be able to expire the items atomically (unless you clear the entire cache). Plus, cache expires on its own anyway - you'd have to deal with re-loading if that occurs.
• You can use a background thread on your role instances, that looks for a blob (maybe with a single zip file), and copy the zip down to local storage when its id changes (you can store a unique id in the blob's metadata, for instance). Then you could just check this periodically (maybe every minute?).
• The reboot idea has a good side and a bad side. On the good side, you're going to avoid side-effects caused by changing local content while your role instance is still running. The bad side is that the role instance will be offline for a few minutes during reboot.

Stuart's suggestion of using a configuration setting is a good one. Just be sure you can update your files without breaking your app. If this cannot be done safely, don't handle the Changing event - just let the role instance recycle.