Windows Azure SQL Database Marketplace
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:
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:
Here is a summary of a few key high level points about using a Windows Azure Drive:
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