Skip to main content

Storage Networking Basics: Configuring Disk Arrays

                   The most critical, sometimes tedious, part of setting up a SAN is configuring each individual disk array. In this Storage Networking 101, we'll delve into best practices and cover the general concepts you must know before configuring SAN-attached storage.
There are three general steps when configuring a disk array:
  • First, you create a RAID set. It can be any type of RAID the array supports, and we'll just assume RAID-5 for this article so that we can talk about hot spares.
  • You can either slice up the RAID set to present multiple LUNs to a host, or you can create "RAID Groups," as most vendors call it. This is a completely optional step, but it can make your life easier.
  • Third, you must assign LUNs to a host.
Create a RAID Set
The first step can be done many ways. Say you have an array that holds 14 disks per tray, and you have four trays. One option is to create two (or more) RAID-5 volumes on each tray. You can then assign part or all of each RAID-5 volume to various hosts. The advantage to this method is that you will know which hosts use what specific disks. If the array with three additional trays was purchased at the same time, it actually makes more sense to allocate the RAID sets vertically, so that a single tray failure doesn't take out the RAID volume. With only four trays this means you'll have three disks worth of usable space per 4-disk RAID-5 volume: probably not a good use of space.

More often people will create huge RAID-5 sets on the arrays. There's a balance between performance and resiliency that needs to be found. More disks mean better performance, but it also means that two disk failures at once could take out all of your data. Surprisingly, multiple disk-at-once failures are quite common. When the array starts rebuilding data onto a previously unused disk, it frequently fails.

Configure RAID Groups
The second step causes quite a bit of confusion. Regardless of how you've configured the RAID sets in the array, you'll need to bind some amount of storage to a LUN before a host can use it. The LUN can be an entire RAID-5 set (not recommended), or it can be a portion. The partitioning method ensures that you aren't giving too large a volume to a host. There are many reasons for this:
  • Some file systems cannot handle a 1TB or larger volume
  • Your backup system probably won't be able to backup a file system that's larger than a single tape
  • The important one: more LUNs presented to the host (seen as individual disks by the OS) means that separate I/O queues will be used

Back to the second step: Raid Groups. A partitioned RAID-5 set of 1TB, for example, into 100GB chunks, will provide 10 LUNs to deal with. If you don't care what nodes use what disks, you can just throw these LUNs into a group with other LUNs. I prefer to keep one RAID group per host, but others see that as limiting flexibility. Some hosts need a dedicated set of disks, where you know that only one host will be accessing the disks. A high-traffic database server, for example, should not have to contend with other servers for I/O bandwidth and disk seeks. If it truly doesn't matter to you, simply create a bunch of LUNs, and assign them to random groups
It is also important to create and assign "hot spare" coverage. Spare disks that are left inside the array are "hot" spares. They can be "global," so that any RAID volume in the event of a failure uses them, or they can be assigned to specific RAID volumes. Either way, ensure you have a hot spare, if you can afford the lost space. If not, be sure to monitor the array closely—you'll need to replace any failed disk immediately.
Assign Your LUNS
Step three, "assign LUNs to a host," means that you're going to map WWNs to LUNs on the array. If you didn't, then any host zoned properly could see all the volumes on the array, and pandemonium would ensue. Be cautious about certain cheaper storage arrays, too. They may not even have this feature by default, until you purchase a license to enable it. While the purveyors of limited-use technology call this feature "WWN Masking" or "SAN-Share," the market leaders in the SAN space realize that it's required functionality.
The most common approach is to create a "storage group," which will contain "hosts" and "LUNs" (or RAID groups with many LUNs). Whatever diverging terminology is used, the universal concept is that you need to create a host entry. This is done by manually entering in a WWN, or connecting the host and zoning it appropriately so that the array can see it. Most arrays will notice the new initiator and ask you to assign it a name. Once your hosts, and all their initiator addresses, are known to the array, it can be configured to present LUNs to the host.
One final note about array configuration. You'll be connecting two HBAs to two different fabrics, and the array will have one controller in each fabric. The host needs to be configured for multipathing, so that either target on the array can disappear and everything will continue to function. We'll dedicate an entire article to host configuration, including multipathing and volume managers, but be aware that the disk array side often needs configuring too. The majority of disk arrays require that you specify what type of host is being connected, and what type of multipathing will be used. Without multipathing, LUNs need to be assigned to specific controllers, so that the appropriate hosts can see them.
Once LUNs are assigned to a host, they should be immediately available to the operating system, viewed as distinct disks.
Think about this for a moment. You've taken individual disks, and combined them into RAID volumes. Then, you've probably partitioned them into smaller LUNs, which is handled by the disk array's controllers. Now the host has ownership of a LUN, comprised of possibly 10 different disks, but each LUN is smaller than individual disks. The host OS can choose to stripe together multiple LUNs, or even partition individual LUNs further. It's quite fun to think about.

Popular posts from this blog


The BCD registry file controls which operating system installation starts and how long the boot manager waits before starting Windows. Basically, it’s like the Boot.ini file in earlier versions of Windows. If you need to edit it, the easiest way is to use the Startup And Recovery tool from within Vista. Just follow these steps: 1. Click Start. Right-click Computer, and then click Properties. 2. Click Advanced System Settings. 3. On the Advanced tab, under Startup and Recovery, click Settings. 4. Click the Default Operating System list, and edit other startup settings. Then, click OK. Same as Windows XP, right? But you’re probably not here because you couldn’t find that dialog box. You’re probably here because Windows Vista won’t start. In that case, you shouldn’t even worry about editing the BCD. Just run Startup Repair, and let the tool do what it’s supposed to. If you’re an advanced user, like an IT guy, you might want to edit the BCD file yourself. You can do this

DNS Scavenging.

                        DNS Scavenging is a great answer to a problem that has been nagging everyone since RFC 2136 came out way back in 1997.  Despite many clever methods of ensuring that clients and DHCP servers that perform dynamic updates clean up after themselves sometimes DNS can get messy.  Remember that old test server that you built two years ago that caught fire before it could be used?  Probably not.  DNS still remembers it though.  There are two big issues with DNS scavenging that seem to come up a lot: "I'm hitting this 'scavenge now' button like a snare drum and nothing is happening.  Why?" or "I woke up this morning, my DNS zones are nearly empty and Active Directory is sitting in a corner rocking back and forth crying.  What happened?" This post should help us figure out when the first issue will happen and completely avoid the second.  We'll go through how scavenging is setup then I'll give you my best practices.  Scavenging s

AD LDS – Syncronizing AD LDS with Active Directory

First, we will install the AD LDS Instance: 1. Create and AD LDS instance by clicking Start -> Administrative Tools -> Active Directory Lightweight Directory Services Setup Wizard. The Setup Wizard appears. 2. Click Next . The Setup Options dialog box appears. For the sake of this guide, a unique instance will be the primary focus. I will have a separate post regarding AD LDS replication at some point in the near future. 3. Select A unique instance . 4. Click Next and the Instance Name dialog box appears. The instance name will help you identify and differentiate it from other instances that you may have installed on the same end point. The instance name will be listed in the data directory for the instance as well as in the Add or Remove Programs snap-in. 5. Enter a unique instance name, for example IDG. 6. Click Next to display the Ports configuration dialog box. 7. Leave ports at their default values unless you have conflicts with the default values. 8. Click N