Azure Worker Role - attach a disk that can be re-used between deployments

Question

The files are Dlls that I need to link to dynamically, so can't use Azure Storage for this.

I can attach Disk to Azure virtual machine according to: http://www.windowsazure.com/en-us/manage/windows/how-to-guides/attach-a-disk/

But how can I do same for worker role?

The reasons are:

1. Store some files that all instances of Worker role can access at the same time. So don't have to duplicate/sync files to all local drives of each instance.

2. The files need to persist when I deploy new version of web role.

Answer 1

Do take a look at Azure Drives: http://go.microsoft.com/?linkid=9710117 . It is essentially a page blob (thus persistent storage), which contains an NTFS-formatted virtual hard drive (VHD). One catch with Azure Drive is that only one instance has write permission on an Azure Drive. All other instances only have read-only permission.

Answer 2

As Gaurav pointed out, you can have a vhd stored in a blob, and then attach to your instances. Just remember that, for additional instances, you'll need to make snapshots of the blob. As long as the vhd's content doesn't change, then the snapshots are tiny (really a bunch of pointers to blob pages). And... if you need to update one of the dll's, you need to do that through an instance that mounted the drive for writing.

Regarding criterion #1 above (not wanting to duplicate files to local drive for each instance): I'd suggest trying it out first, seeing how long it takes to copy the dll's from individual blobs (or a zip file in a single blob) to local storage during instance startup. Since the storage account and your compute instances will be (at least should be ) in the same data center, the copy should be very fast, and there's no bandwidth charges. You can do this easily via startup task. The upsides?

• Easier to update individual dll's (you can use any off-the-shelf blob management tool, PowerShell, etc.) - no need to even have an instance running when updating your dll's and other common files. If you store in a mounted drive, you'll be required to have an instance running if you want to maintain the file list, and you'll need to do all file management through that instance.
• No risk of losing access to the dll's if something were to cause the drive lease to break (not saying it would , but the local copy would be independent of blob storage).

It's not difficult to come up with a signaling scheme to let your instances know there's a software update for them (maybe a simple pub/sub service bus message?).