Tuesday, January 18, 2011

A change from basic to dynamic disk

Here is a little history about what we (meaning the server team at the company I work at) have done in the past.  When we have a server with large SAN (Storage Area Network) attached drives (any size, including ones that are a Terabyte plus) we would attach that drive to the server as a basic disk.

Before I get into the “why” I am going to go over what a basic and dynamic disk is as it pertains to Windows 2003 and 2008.

Basic Disks:
  • These use a partition table to manage the partitions on a disk.  This type of disk is supported on all versions of Windows.  
  • A basic disk can contain basic volumes (a volume is a single accessible storage area with a single file system and may or not be a single partition on a hard disk) which includes primary partitions, extended partitions, and all logical partitions contained within an extended partition


Dynamic Disks:
  • Supported in Windows 2000 and later (with Windows XP it is only supported on Windows XP Pro).
  • They do not use a partition table.  In place of the table, they use a hidden database to track information about dynamic volumes.
  • A Dynamic volume can be a simple volume, a spanned volume, a striped volume, a mirrored volume, and a RAID-5 volume.
  • You can perform disk and volume management without restarting windows (the same can be said about basic volumes as well as you can use DISKPAR and extend the volume).


Granted, that is just the high-level information about each of the volume types, but it gives us a picture of what I am talking about.  

Now for the “why”.  Most of the Windows servers in our organization use Clariion storage as the backend.  Going back to the fact that we have been using basic disks as our standard, one would assume that we are using really large LUNs assigned from a single RAID group.  Luckily, that is not the case.  Why is that lucky?  Wel,l to put it simply spindles = performance.  A single RAID group on a Clariion usually only has 7 disks in a 6+1 RAID configuration.

So that we can provide these servers with more spindles (mostly used in large LUNs), we create LUNs across multiple RAID groups and “extend” a LUN to utilize all of these spindles.  When we present this expanded LUN to Windows and it only sees one disk.

Now that I am done with the “why”, that brings us to today.  We are in the process of installing a new NS480 (a Clariion with a Celerra Datamover from EMC).  This new NS480 is going to be using FAST2 technology from EMC.  What this means is that the whole idea of worrying about creating META LUNs to provide more storage is “out the window”.  

Why you might ask?  To utilize FAST2 we need to create pools of storage.  A pool is multiple RAID groups and disk types “pooled” together.  For example, I could have SATA, Fiber, and EFD (flash drives) in the same pool.  They will be grouped together on the backend just like before in RAID groups, but we (the admins) won’t have to worry about what kind of disk we want to provide to the user.  Granted, there is some configuration and monitoring we will have to do to ensure that proper type of disk is being given to the application when it is needed, but the point is we will just carve up a LUN and give it to the server.  When using pooled storage, you no longer use META LUNs.

That sounds great doesn’t it?  I just need to carve up a LUN, no matter the size, and present it and it has access to all those different types of drives and all those spindles if it needs it.  Well, lets stop and think about this.  I create a few really big LUNs and try to balance them by how big they are between the pools.  Easy enough.  However, lets say that one of those really big LUNs are getting pounded on because someone is running a SELECT * from Table to look for a name of a customer, and they do this ALL THE TIME.  Now I have one pool that is being utilized performance-wise a lot more than the other.  In essence, I will be stranding the remaining storage because if I keep adding hosts to that pool the performance will keep going down.  As you can guess, we don’t want that to happen (we know this all to well).

Okay, how do you fix this since I can’t use META LUNs to spread the I/O (Input/Outputs) between those pools?  Well, we have to look at how we are presenting our disk to our Windows servers.  Since a basic disk is just that, a single disk, that won’t help us.  However, if we use dynamic volumes that can span multiple disks (in this case LUNs presented from the SAN), we can stripe them and use both pools to spread that I/O load out and keep from orphaning as much storage.  I say “as much storage” because it will be inevitable that you will reach your I/O load before you carve up all those nice terabytes into LUNs.

Even if we change from basic disk as a standard to dynamic disks we will still be able to do many of the things we used a basic disk for (with a few caveats).

  • We can swing a dynamic disk from one server to another in the event that a server is down
  • We can grow that dynamic volume at anytime (as long as that partition was not a basic partition first).
  • We can...well those were the two main reasons we used them.


If you have any questions or comments please feel free to post them (as the blog title says, I am a newbie).