SharePoint on Windows Azure – Part 2: Storage

SharePoint
This entry is part 1 of 4 in the series SharePoint on Windows Azure

In Part 1 of “SharePoint on Windows Azure” we gave a brief introduction and set up our basic tools to communicate with Windows Azure. There’s one more we’ll use that deals specifically with storage so let’s set that up now.

Storage Account Setup

First we need a storage account in Windows Azure. One may have been created when you signed up so let’s check first and if not, we’ll create one.

  1. In the Windows Azure management portal, click on “Storage” to see if a Storage Account exists. If one exists, skip to step # 6. Otherwise continue to step #2.
  2. To create a new Storage Account, click the New button at the bottom of the screen and click Data Services.
  3. Select Storage and Quick Create. Fill in a unique name for the URL.
  4. The Affinity Group may be blank, don’t worry if it is. Also, uncheck “Enable Geo-replication” if you want. We don’t need that for Dev/Test farms.
  5. Click Create Storage Account.
  6. Now we need to copy the key. Click on the Storage Account to get to the dashboard view.
  7. At the bottom, click “Manage Keys” and copy the Account Name and Primary Access Key somewhere temporary (like Notepad or OneNote). We’ll use these coming up soon.

Viewing Storage

There are several tools you can use to view Windows Azure Storage, I’ve put a link to a list of tools to explore Windows Azure storage in the resources section at the end. For now, we’ll use ClumsyLeaf CloudXPlorer (http://clumsyleaf.com/products/cloudxplorer), we’ll be using the freeware version, version 1). After you’ve downloaded and installed CloudXPlorer, we need to add a new account:

  1. Open CloudXPlorer and click File…, Accounts…, New…, Windows Azure account.
  2. Type in the Account Name you copied down in Step #7 of the earlier procedure.
  3. For Secret Key, type in the Primary Access Key you copied down in Step #7 of the earlier procedure.
  4. Check “Use SSL/TLS” and click OK. The account has been added, so close the Manage Accounts window if it’s still open.

Back in CloudXPlorer, you’ll see your account in a tree view. It’s probably empty now but you should have one container called “vhds.” This is where we can place our images and disks. Before we continue, we should spend a minute understanding the difference between an image and a disk.

Image vs. Disk

A disk is a vhd of a virtual machine that may or may not contain an operating system. When you attach this to a virtual machine in Windows Azure, it boots and expects everything to be ready. In contrast, an image is a vhd of virtual machine that has been sysprepped. It means, the machine will get a new SID (security identifier), new product key, and new Administrator credentials. This type of vhd can be used to deploy virtual machines, whereas a disk cannot.

What’s confusing is when researching how to upload a vhd, many people come to this article: https://www.windowsazure.com/en-us/manage/windows/common-tasks/upload-a-vhd/. In my opinion both the URL and the tile are inaccurately named, “Creating and Uploading a Virtual Hard Disk that Contains the Windows Server Operating System.” The instructions are good if you want to create an “image,” but not if you want to create a “disk” in Windows Azure. Windows Azure treats them differently. I uploaded a non-sysprepped vhd and attached it to a new VM. It tried to provision endlessly. In any case, that article *should* be titled “Creating and Uploading a Virtual Hard Disk that Contains the Windows Server Operating System as an Image,” and should link to another article for people that just want to upload a vhd as a disk.

Working with disks

Next, we’re going to upload a vhd. Unfortunately, there’s no support for vmdk’s or iso files (yet) so if you want your files in Windows Azure, you need to create a vhd. Let’s take a break and go over a few notes about vhd’s in Windows Azure. For a vhd to “work” it must meet these guidelines:

  • No dynamic disks. The vhd must be a fixed disk.
  • Maximum size must be under 127 GB.
  • No support for vhdx (need to verify this one)
  • Must be uploaded as a page blob (rather than a block blob).

If you create a vhd in Hyper-V for use in Windows Azure, make sure it’s a fixed disk and smaller than 127 GB. If you have existing dynamic disks you want to upload, you can use the “Edit Disk” feature in Hyper-V to convert it to a fixed disk. With that, let’s look at two upload tools.

The first is GUI-based, CloudXPlorer. To upload a vhd using CloudXplorer, DON’T CLICK THE UPLOAD BUTTON. If you look carefully, this is for block blobs. Also when you right-click, you’ll see an “Upload” link in the context menu – again for block blobs and as stated, we need to upload page blobs. The only way to upload a page blob is to right-click in a container or folder and click on “Upload page blob,” that’s the right option we want. I’ve pasted a link in the resources section called “Understanding Block blobs and Page blobs” if you want to read up on it. Once you click “Upload page blob,” you just select your .vhd file and away it goes.

The second tool is a called “CSUpload,” a command-line program included as part of the Windows Azure SDK that you downloaded in Part 1. I believe csupload has one major advantage, it’s multi-threaded so your uploads will go faster. CloudXPlorer is only muti-threaded for block blobs. To upload a .vhd using csupload:

  1. Open Windows Azure Command Prompt (in your Start Menu or Start Screen)
  2. Type in:

    csupload add-disk -destination “https://<storage account name>.blob.core.windows.net/vhds/MyDemoDisk.vhd” -Label “MyDemoDisk” -LiteralPath “<path to>\MyDemoDisk.vhd”

    Where <storage account name> is your Storage Account name, MyDemoDisk.vhd is the name of your vhd file and <path to> is the full path to the location of the vhd file.

    Note: “csupload add-disk” uploads the vhd, converts dynamic to fixed disks on the fly, and adds your disk to the repository. In contrast, the Windows Azure PowerShell version, “Add-AzureDisk” only adds the disk to the repository, after is uploaded. It doesn’t upload or convert dynamic disks to fixed disks.

  3. As stated earlier, the “-” character can get messed up when you copy and paste, so re-type it if it doesn’t work. For a 40GB file on a fast connection (5Mbps), I saw about 30 minute upload times.

You can use CloudXplorer to add containers and folders if you want to better organize your vhds. Just click on the parent object and then right-click in the content pane. Select “New” container or folder. In my screenshot, I’m in the “vhds” container so only New Folders are available. If I click on my account “wahids acct,” I’d see the New Container option.

Note: Windows Azure Management Portal doesn’t show tree views. So, all your disks will appear in one single view. The folders you create will all show up as “$$$.$$$”

 

 

OS Disks vs. Data Disks

In Windows Azure, OS Disks are those that contain a bootable operating system. A Data Disk is a non-bootable disk usually created to hold data (such as database files). In addition, all Windows Azure virtual machines get a “Temporary Storage” disk. The volumes are usually represented as follows:

Drive Letter

Type

Best Used For

C

OS Disk, System Drive

OS only

D

Temporary Storage, non-persistent drive

Pagefile, TempDB

E

Data Disk, not created by default or automatically

Databases, Program Files

 

When creating disks (or adding them) in Windows Azure, there’s two ways to specify that a disk is an OS Disk.

  1. First, in the Windows Azure management portal on the “Create Disk” dialog box you’ll put a check mark on the box “The VHD contains an operating system” and select the OS from the drop down box.
  2. If you’re using PowerShell, you’ll just specify the –OS parameter followed by either “Windows” or “Linux” during the Add-AzureDisk command.

By default, disks (either kind) in Windows Azure use caching to increase performance. This is great for the OS Disks because it leads to really fast boot times. However, on Data Disks, this isn’t ideal. We want to be assured our data is written immediately so we want to disable caching. We can do this by using the Set-AzureDataDisk –HostCaching “None” command for existing disks or as part of Add-AzureDataDisk when we’re creating new data disks.

Note: Changing the cache on a running VM will reboot the VM.

 

Some Best Practices

For the type of machines we’ll be using, I’m including some best practices I learned from a presentation by Corey Sanders (@CoreySandersWA) and included a link to his Channel 9 videos in the resources section.

SQL Servers: For the TempDB data and logs, keep them on the D: drive (the temporary, non-persistent disk) that Windows Azure gives us automatically. That drive is optimized for these kind of temporary data stores. Keep your actual database files on a separate data disk, even on multiple data disks. As those disks get used more often, Windows Azure optimizes performance. You may even get better performance by using separate storage accounts, just make sure they’re in the same region/Affinity Group as your VM.

Domain Controllers: Like any other applications we host, we shouldn’t put the database on the C: drive. If you’re setting up a DC from scratch, create a data disk and use that to store the Active Directory databases and folders when asked during dcpromo.

SharePoint: The same pattern applies here. Keep the data separate, install SharePoint on a data disk.

Finally, not really a best practice but just a note on storage costs. You pay for what you use, so creating a 700 GB data disk won’t cost you 700 GB worth of storage costs. As the drive fills up, you’ll pay for what you’re using. However, there is no “trim” functionality as of this writing. That means, even if you delete files, your costs won’t be reduced. One workaround that you can use in rare cases, such as if you know the data won’t grow again to fill up the space is to create a second disk and copy the data over. Use your new disk and delete the old one.

Conclusion

I’ll talk about creating a VM from scratch later in the series. For our purposes, I’m going to assume you have created a domain controller and SQL Server (and possible SharePoint servers) outside of Windows Azure (in Hyper-V). Upload all your vhds using csupload (you can write a batch file).

If you want to create your VMs from scratch in Windows Azure, you can still follow along in Part 3.

Next time, we’ll start building out our virtual network in Windows Azure. We won’t need our disks initially, but will want at least our domain controller to be ready.

Resources:

Series NavigationSharePoint on Windows Azure – Part 3: Networking
0 comments… add one

Leave a Reply