I previously asked a question about this topic but now I prefer to rewrite it from scratch because I was very confused back then.

I currently have a Linux XS VM Role in Azure. I basically want to create a self-managed and evoluted hosting service using VMs rather than Azure's more-expensive Web Roles. I also want to take advantage of load balancing (between VM Roles) and geo-replication (of Storage Roles), making sure that the "web files" of customers are located in a defined and manageable place.

One way I found to "mount" a drive in Linux VM is described here and involves mounting a VHD onto the virtual machine. From what I could learn, the VHD is reliably-stored in a storage role, and is exclusively locked by the VM that uses it. Once the VM Role has its drive I can format the partition to any size I want. I don't want that!!

I would like each hosted site to have its own blob directory, then each replicated/load-balanced VM Role to rw mount like in NFS that blob directory to read HTML and script files. The database is obviously courtesy of Microsoft :)

My question is

Is it possible to actually mount a blob storage into a directory in the Linux FS? Is it possible in Windows Server 2008?

3 Answers
3

Your linux instances are considered Virtual Machines. These are different from the existing VM Role. The former is a vhd you manage in your storage account, and supports several OS variants. The latter is something you create locally, upload to Windows Azure (into storage not managed by you), then spawn one or more instances of that VM Role (which works similarly to web/worker roles). Just wanted to clarify, as you refer to your linux VM as "VM Role."

Web roles (or worker roles, or VM Roles), are not more expensive than Virtual Machines. They all get metered at an hourly rate, per core, at a list price of $0.12 / hour (or $0.02 / hour for XS).

Storage is a service, not a role. Web / worker / vm "roles" are essentially templates (or scaffolding) for the code that runs in the virtual machine instances, aside from the code you deploy. Storage is a REST-accessible service.

Ok, having said all that: The instructions you found about mounting a drive to a linux Virtual Machine show how to do things via the portal (and you can do the same thing with command-line scripts). You can mount up to 16 total drives (2 per core, and 1 on an XS). Each mounted drive is treated like an entire file system.

If you wanted each Virtual Machine to have its own drive, you can mount the appropriate drive(s) to each (again, up to 16 per Virtual Machine). Once a drive is mounted, that Virtual Machine has exclusive write access to the drive (no drive-sharing). This is independent of OS: Same restriction in Win28K, Linux, or even a web/worker/vm role. So: In the model where each Virtual Machine serves only one website, this helps. In the model where each Virtual Machine serves all websites, this doesn't really help with what you're trying to do. So...

If you're load-balancing traffic between two Virtual Machines, and they both need to access the same static content (e.g. website content), one thing to consider: Store static content directly in a blob (as a zip/tar) or series of blobs in a container. Then, upon bootup (or some type of signal), have the Virtual Machine(s) download said blob(s) to local storage. This method provides a central place for you to store your web content. You could also store them in an Azure drive, but I don't really see the value in doing so: You'd have to then worry about taking read-only snapshots of the drive, then mounting the snapshot. Seems like lots of extra work, vs just grabbing files from blob storage.

By the way: The copy operations are going to be throttled by Virtual Machine size. Network bandwidth on the Virtual Machine is 100Mbps per core, but for XS, only 5Mbps. Depending on how much data you'd be copying from blob storage to local disk, this could seem a bit slow with XS. Oh, and bandwidth between blob storage and your Virtual Machine is free within the same data center.