NetApp storage systems are best known as network-attached storage (NAS) devices, but I think few people appreciate just what a versatile storage platform they really are. With a single system you can provide NAS, both CIFS and NFS, Fibre Channel SAN (both fabric and DAS), and IP SAN (iSCSI and iFCP). I've found times in my past where I knew I needed storage for a project, but it wasn't clear at the time of purchase just exactly how we needed to access the storage. In these cases, choosing NetApp storage provided me with the widest range of possible solutions to solve the problem and further to continue using that storage beyond its original intent.

To truly appreciate the versatility of the NetApp architecture, it is important to view how the storage is managed and how the storage is accessed as related functionality. Too often storage vendors separate these two concepts, which creates overly specialized storage systems that eventually become isolated islands. Storage consolidation is a constantly reoccurring storage theme, which typically requires migration to yet another storage platform only to repeat the scenario again in the future. Choosing a platform that will not only meet your needs today but also has the flexibility to meet your needs in the future will allow you to continue to leverage your initial investment, scale that investment over time without migrating the underlying platform, and ultimately deliver a return on investment that you can depend on for years to come.

In this article, I’ll take a broad look at how the NetApp operating system, Data ONTAP, manages data on disk and how that data is accessed from your client systems. Some of the technologies I'll explore include:

• RAID, RAID-DP™, and traditional volumes
• Aggregates and FlexVol™ volumes
• Snapshot™ functionality and FlexClone™ technology
• LUN creation and masking

In releases prior to Data ONTAP 7G, volumes were defined much like they are with other tools, creating an intimate relationship between volume and disk. A volume (on which a file system sits that contains data) would be created on top of one or more RAID groups. Each RAID group is RAID4, containing n data disks plus one parity disk. With RAID4 you can lose no more than one disk, which means that when a disk fails, you're completely vulnerable to a second failure during the disk rebuild (and with 300GB drives, a disk rebuild can take a while).

The 6.x and later releases of Data ONTAP include a nifty feature called double parity, which allows you to have two parity disks (this isn't just a mirror of parity; learn more about RAID-DP here (pdf)). By using RAID-DP you could lose up to two disks, which covers you during a spare reconstruction and gives you a little extra security and peace of mind.

Here's an example of the creation and configuration of a traditional volume:

When you create a traditional volume (simply referred to in releases before Data ONTAP 7G as a "volume"), the volume sits on top of the RAID groups you created. If you want to increase the size of the volume, you must add more disks. For performance reasons you typically want to add additional full RAID groups at a time.

This method of allocation is fairly inflexible: you can't shrink volumes, and your volume sizing is based on the physical disk sizes, not simply needed capacity. To make up for this, you can create within a traditional volume a quota tree (qtree), which by and large can be treated like a volume itself. For example, you can replicate individual qtrees using NetApp mirroring software (SnapMirror®) and define different access types (UNIX®, NTFS, or mixed). But qtrees are only so flexible.

Enter Data ONTAP 7G, in which NetApp introduces a new concept called aggregates. Aggregates add a layer of abstraction between the physical disks and the volumes. The idea is simple: allocate a certain number of disks to a big aggregate, which is built on RAID groups just like traditional volumes. However, there is no file system within an aggregate; it is just allocatable space.

Now within this big aggregate we can create something NetApp calls flexible volumes ("FlexVol"). Because a FlexVol volume is abstracted from the underlying disk, you can create a volume to meet your capacity needs without regard for physical layout. Furthermore, you can grow or shrink a FlexVol volume easily at any time. This truly is flexible. One advantage of flexible volumes is that as your needs and requirements change over time, you can manipulate your storage by sloshing things around within the aggregate.

This is an example of aggregate creation with RAID-DP enabled:

Flexible volumes let users do some really kool things. One of my favorites involves cloning. We can take an existing FlexVol volume and create a clone from it, either using the volume itself (right now) or using an existing Snapshot copy from some point in the past (like before your server blew up). A FlexClone volume looks exactly like the volume it was created from (its parent FlexVol volume or another FlexClone volume), but it uses no additional physical storage!

This code shows you how easy it is to create a FlexClone volume:

Snapshot Copies + FlexClone Volumes = A Powerful Tool

Snapshot copy management itself is really easy. The operation takes milliseconds. The combination of robust NetApp Snapshot capabilities and the WAFL® file system means that operations such as volume creation, Snapshot copy creation, and cloning require almost no work at all. No more sitting around waiting an hour for volumes to become usable. This is the real magic.

Here's an interesting example. Say your PostgreSQL system got attacked and the database was corrupt. Your first priority is going to be getting the databases back online, but it would also be nice to have a copy of that corrupt data for further analysis when some of the DBAs get into the office in the morning.

If we were using NetApp storage with Data ONTAP 7G, we could create a clone of the affected volume based on a prior Snapshot copy that is known to be good, make that available to the system (export the NFS share, CIFS share it, or remap the LUN for iSCSI or SAN), and be back online in the time that it took you to type the commands and to roll forward the logs. Then we could mount that corrupt volume off to a test system for analysis. When the analysis is complete, we could split off the clone that we created so that it would be its own unique volume.

At this point we have two options: we can keep using the clone as is (not losing the changes between the time we recovered and now), or we could delete the clone and revert the whole volume back to the last known good Snapshot copy. If you choose to revert back to a previous Snapshot copy, all of the Snapshot copies that were created after that point in time will be destroyed. Sometimes you need to revert to an older Snapshot copy but don't want to lose more recent changes: in this scenario, cloning based on a point-in-time Snapshot copy and then being able to split off that clone provides some flexibility.

Reviewer note: Depending on the scenario, the process for rolling changes back into a live database can vary. For more information and specific examples, NetApp recommends reading A Thorough Introduction to FlexClone Volumes (pdf).

If you're interested in cloning, I'd recommend Bruce Moxon's article about developing a rapid application development model for database-centric applications.

Managing LUNs for Fibre Channel SAN and iSCSI

Just managing data is only part of any storage solution and doesn't provide any real value if you can't access that data. NetApp storage systems are legendary NAS devices and well known and trusted in that space. The FlexVol volumes that we created earlier needed only to be exported via NFS ("exportfs") or shared via CIFS ("cifs shares -add") to be made available on your network as NAS resources. However, many users may be unfamiliar with the ability of Data ONTAP to serve block storage LUNs for iSCSI and Fibre Channel SAN access.

To demonstrate just how easy and painless NetApp is to manage for block environments, let's expand on the concepts we explored earlier to build LUNs and control how they are accessed by clients.

When dealing with iSCSI or FCP (Fibre Channel Protocol: that is, SAN), we are making block allocations, which we call LUNs, available. A LUN is just a big allocated file sitting on a volumes file system (or so it appears). In order to create a LUN, you must first create a volume, as discussed earlier. Then, when creating the LUN, you'll specify the path within that volume. Here is an example:

You can see how easy it is to create LUNs. You'll notice that while I created a 100GB volume, 20GB of it is allocated to Snapshot copies. We can limit that easily:

Once you've created a LUN, you make it accessible by mapping it to an initiator group. Initiator groups contain one or more iSCSI IQNs or FCP WWNs, which map to a LUN on the NetApp storage system. This is traditionally known as LUN masking, because you're making sure that only the initiators (clients) that should see certain LUNs can.

LUN masking sounds a lot more difficult than it is. Here is an example:

iSCSI and FCP are handled in exactly the same way, except for a single flag. Notice the -f in igroup create in the preceding code. This means FCP; change it to -i, and you're doing iSCSI instead.

This is only a taste of what you can do with a NetApp storage system. I hope you can see that there is a huge amount of flexibility that is either unavailable from other vendors or so expensive as to be unpractical (replication using EMC software vs. NetApp SnapMirror software is a good example). Personally, I view NetApp storage systems as the Swiss Army knives of the storage world: they do everything you need to do and a ton of stuff that might come in handy someday (like that little toothpick).

When you need flexibility to roll with whatever comes your way, nothing beats NetApp: the versatile storage platform.

---