Today we are providing access to a beta release of Windows Azure Drive (announced as XDrive at PDC 2009).

Customers have told us that they want to take their already running Windows applications and run them in the cloud using the standard Windows NTFS APIs, and make sure that the data is durable. With Windows Azure Drive, your Windows Azure applications running in the cloud can use existing NTFS APIs to access a durable drive. This can significantly ease the migration of existing Windows applications to the cloud, enabling customers a more seamless migration experience while simultaneously reducing the amount of time it takes to move their applications from your own Windows environment to a Windows Azure environment. The Windows Azure application can read from or write to a drive letter (e.g., X:\) that represents a durable NTFS volume for storing and accessing data. The durable drive is implemented as a Windows Azure Page Blob containing an NTFS-formatted Virtual Hard Drive (VHD).

For the beta release of Windows Azure drive, customers will be billed only for the storage space used by the Page Blob and the read/write transactions to the Page Blob. This will be incorporated into the standard Windows Azure usage rates and there will not be a separate line item on the bill.

Let’s discuss some more of the technical details of the Windows Azure Drive feature. The Page Blob can be mounted as a drive only within the Windows Azure cloud, where all non-buffered/flushed NTFS writes are made durable to the drive (Page Blob).   If the application using the drive crashes, the data remains persistent via the Page Blob, and can be remounted when the application instance is restarted or remounted elsewhere for a different application instance to use.   Since the drive is an NTFS formatted Page Blob, you can also use the standard blob interfaces to upload and download your NTFS VHDs to the cloud.

Windows Azure Drive can optionally cache the drive data on a local disk on the virtual machine (VM). Caching the data on the local drive can reduce the read traffic to the page blob, which will lower the transaction cost. There is no additional charge for reads that are to the local disk cache. The transactions against the Page Blob will be counted towards billing. Note, even when the cache is enabled, all non-buffered and flushed writes are committed transactions to the Page Blob in durable storage.

Windows Azure Drive is accessible starting with the release of Windows Azure Guest OS 1.1. In addition, in order to mount a Windows Azure Drive you will need to use Feb 2010 version of the Windows Azure SDK. The SDK provides the following Windows Azure Drive APIs for your Windows Azure application to use:

  • Create Drive - Creates a Page Blob formatted as a single partition NTFS volume VHD.
  • Initialize Cache – Allows an application to specify the location and size of the local data cache for all Windows Azure Drives mounted for that VM instance.
  • Mount Drive – Takes a formatted Page Blob and mounts it to a drive letter for the Windows Azure application to start using.
  • Get Mounted Drives – Returns the list of mounted drives. It consists of a list of the drive letter and Page Blob URLs for each mounted drive.
  • Unmount Drive – Unmounts the drive and frees up the drive letter.
  • Snapshot Drive – Allows the client application to create a backup of the drive (Page Blob).
  • Copy Drive – Provides the ability to copy a drive or snapshot to another drive (Page Blob) name to be used as a read/writable drive.

The Windows Azure operating system has an OS driver that serves two primary functions. The first is to provide the client library operations described above for mounting and unmounting a drive. The second is performing I/O for all of the NTFS operations to the mounted drive. Here is a summary of how the drive works:

  • Mount – When mounting the drive, the OS Driver attempts to acquire an exclusive access lease on the Page Blob. If it can, then it will mount the drive to a free drive letter. If cache space is specified to be used, then local disk space will be reserved for the mounted drive to use as an on-disk cache.
  • Write – All non-buffered/flushed NTFS writes are sent to the OS driver, where the write is made durable in the Page Blob in the Windows Azure Blob service before sending success back to the application. This ensures that if application gets a success back for the write, and the drive is unmounted or the application crashes, the application knows that the write was persisted to the Page Blob.
  • Read – All reads to the drive that go through the OS Driver will read the data either from the local cache or the Page Blob in the Windows Azure Blob service. If the cache is being used, the driver will first look in the local disk cache, and if found there the results are returned to the application without talking to the blob service. If the data is not found in the local on-disk cache, then it will be retrieved from the blob service and returned to the application as well as being placed in the local on-disk cache.
  • Lease Renewal – While a drive is mounted and in use for an application instance, under the covers the OS driver continuously renews the lease on the Page Blob that is mounted as the drive, using the credentials passed in when mounting the drive.
    Unmount – When a drive is unmounted, the lease on the Page Blob is released (freed) and the drive letter is unallocated. Releasing the lease allows another VM/application to quickly mount the Page Blob as a drive if it chooses.

Here is a summary of a few key high level points about using a Windows Azure Drive:

  • A Drive is a Page Blob formatted as a Fixed NTFS VHD between 16 MB and 1TB.
  • A VM can dynamically mount up to 16 drives.
  • A Page Blob can only be mounted by one VM at a time for read/write access. A snapshot page blob can be mounted as read only by multiple different VMs at the same time.
  • The storage account used to store the Page Blob and the compute account used to run the application should be allocated in the same geo-location in the Windows Azure Developer Portal in order to get the best performance out of the drive.
  • Drives can be uploaded or downloaded via the Windows Azure Blob interface. The formatted Fixed NTFS VHDs can be uploaded as a Page Blob using the blob interface and then mounted as a drive. Similarly, a formatted Page Blob can be downloaded through the Page Blob interface and then the downloaded drive can be used as a VHD.
  • The OS driver provided by Windows Azure is only available within the Windows Azure VM instances in the Windows Azure cloud. No driver is distributed by Microsoft at this time to allow you to mount drives remotely. Even so, you can download a drive using GetBlob and mount the downloaded VHD drive where it is downloaded for use, but any updates to that downloaded version will not be sent to the Windows Azure Blob service.

Customers who are already using the February 2010 Windows Azure SDK should make sure they are running Guest OS 1.1 to start using the Windows Azure Drive. New customers should visit WindowsAzure.com to sign up for the February 2010 Windows Azure SDK in Guest OS 1.1 to also start using the Windows Azure Drive. And please send us your feedback!

More detailed information can be found in the technical white paper here: http://go.microsoft.com/?linkid=9710117

As well as in MSDN documentation here: http://msdn.microsoft.com/en-us/library/ee924681.aspx

As always, we appreciate any feedback you might have.

Brad Calder
Windows Azure Storage