by Seiji Shintaku

For a long time, SAN was considered ‘real’ storage in the data storage realm. However, Microsoft is looking to change that impression with the introduction of the SMB 2.2 stack. It will address many of the issues that are inherent to SMB-based file system allocation. This will be a game changer by making NAS the primary form of large scale-out storage with Microsoft workloads on Windows 8.

Until now, NAS was a second-rate citizen, except in large Unix environments where NAS-based storage was very important. Today, NAS is a much bigger contender in the cloud computing space. The main reason for this shift is the fluidity and ease of allocating NAS-based-storage compared to SAN. In addition, most SAN-based storage runs at least at 4GB per second compared to NAS running on GIGE. Meanwhile, the cost of network connectivity has dramatically decreased with 10G NICs and core switches becoming more and more affordable. Furthermore, network aggregating technology, such as port channeling, and faster 10G connectivity has created a bigger pipe to storage than the fibre channel could ever deliver.

A day in the life of a SAN administrator
Unless you’ve experienced it yourself, you may find it hard to imagine how difficult it is to allocate block-based storage.

Within a server, either physical or virtual, there are SAN-based network connection expansion boards called fibre channel adapters, also known as Host Bus Adapters or HBAs. Each fibre channel adapter has a unique fingerprint represented by a hexadecimal number, also known as a worldwide name (WWN). A typical unique hexadecimal number is 32 digits long. Within a server, you have a bare minimum of two adapters. One will be connected to a side of the network called a ‘fabric’ (fabric A) and the second will be connected to another side of the network or fabric (fabric B), which is done for redundancy purposes. These two HBAs will display their WWNs on each respective fabric. Once the HBA’s WWN appears in the fabric, the SAN administrator creates a point-to-point connection from the server’s HBA WWN to the WWN of the storage array. However, in reality, the person who runs the cable and plugs in the HBA is not going to be the SAN administrator. Usually it is a facilities person who is not well versed in SAN administration. In addition, let’s imagine that the SAN administrator was expecting HBA #1 to be plugged into fabric A, and HBA #2 to be plugged into fabric B. Next, the SAN administrator looks at his or her fabric and sees that HBA #1 is plugged into fabric B and HBA #2 is not visible at all. Now what? The troubleshooting begins.

The SAN administrator calls a meeting with the facilities people. The facilities person now plugs in the cable for fabric A into HBA #1 and HBA #2 into fabric A. Now, the SAN administrator sees HBA #1 on fabric A, but still doesn’t see HBA #2 on fabric B. He asks the facilities person to swap the send/receive on the fibre cable and now HBA #2 shows up and fabric B.

Next, the SAN administrator begins carving up storage on the array. The array creates several devices and gets presented out to the target ports of the array with LUN numbers. The array needs to have the devices ‘masked’ properly. What is LUN masking? It is a means to mask or hide LUNS from being visible to other HBAs that are zoned into the target ports. Imagine if you had 50 servers sharing the same target ports and they all saw all the LUNS on those target ports. You would be asking for trouble. Say that you had a database running on one of the LUNS and another host thought that this LUN was free for consumption and it began formatting the LUN while the database is running. You instantly lose your entire database! In order to avoid this type of scenario, LUN masking is in place to mask or hide LUNs to only those hosts that should be seeing the LUN on the target ports. If the LUN masking is done incorrectly, the storage will either not show up or will behave unexpectedly, such as in a cluster configuration where a LUN is shared among multiple servers.

Once the LUN is visible to the host, the host now sees multiple LUNs. Now the host has to glue all these LUNs together by using volume management software to create one large partition. Do you see the complexity in all of this? Can you imagine the man hours and time to coordinate this effort? This complexity is one of the many factors driving the sudden popularity of virtualization and cloud computing.

Fluidity and ease of use
In the Unix/Linux world, the problem of storage allocation was solved many years ago. NFS (Network File System) was the primary means of allocating a file system out to hosts. With one simple export statement, you can share a 1TB volume to a host or group of hosts in a matter of seconds. The NAS device would handle all of the volume management, the write protection, and the file system layout. With one command, a server could have a file system presented to it. This powerful concept was extended to unstructured, as well as structured, data. Database companies such as Oracle began writing direct NFS drivers and NFS became the primary means of allocating storage to application servers. Coupled with automation, this means of allocating storage was infinitely more fluid than block-based allocation.

What about today and the near future? Microsoft has taken a firm stand in stating that SMB 2.2 is their company direction for server workloads with Windows 8. Imagine the fluidity, reduction of man-hours and simplicity in allocating Windows storage from NAS devices. This is Microsoft’s rebuttal to what has been happening in the Unix and NAS world for many years. The SMB 2.2 protocol will allow multiple connections, aggregating data streams over multiple network interfaces, and persistent handles, which allows for better throughput and resilience.

What the Unix world has enjoyed for many years, Microsoft will finally introduce to the Windows world, plus more. I can’t say that block based storage is dead or that it will go away any time soon, but NAS has definitely moved up in the stack as a more viable and fluid solution to allocating storage in our ever-changing and fast paced-cloud computing world.

Seiji Shintaku is the director of product management at Likewise Software (Bellevue, WA). www.likewise.com