WAFL

You are currently browsing articles tagged WAFL.

The Future of NetApp

Friday, June 18, 2010 in Storage by slowe | 56 comments

As I was sitting in London’s Heathrow Airport this morning catching up on RSS feeds before boarding my plane back to the United States, an article headline caught my eye: Why NetApp Must Seek Acquisition.

I can’t tell you how glad I am to see this article published, because it gives me the opportunity to share something I’ve been thinking about for a while, even before I joined EMC. I’m sure that everything I have to say about NetApp will be colored by the fact that I now work for EMC, and—whether I like it or not—all comments about any other storage vendor or technology are immediately suspect. Recent comments to my VPLEX article proved that point; it will take time to re-establish objectivity and prove to my readers that I’m not an EMC shill.

But I digress; back to the article. In the article, the author (“secretcto”) states why he believes that NetApp must seek acquisition in order to survive. The crux of his article is this:

Now lets take a look at the market cap of each of these players. A company’s market cap is a good place start in order to identify which of these companies will have money to invest in tomorrow. I am not saying that ‘cloud’ is the IT of tomorrow, but if it is the direction of tomorrow, then one thing is certain, the folks in that list that have more of the necessary ‘cloud’ pieces (or the money to invest in building out a portfolio of integrated cloud components) will be the most successful competitors.

The author states that NetApp has a few key problems:

  • NetApp only owns one component (storage) of the multiple components (the others being servers, networking, software, and security) necessary to continue to be a key competitor moving forward.
  • NetApp doesn’t own any software that drives customers to its products.
  • NetApp lacks the bankroll to acquire the technologies necessary to build out their portfolio in order to compete with more “full-featured” competitors.
  • NetApp has a history of difficulty integrating their acquisitions. Even if the bankroll was present, there is no indication that additionsl to their portfolio could be successfully integrated into the company.

I would add an additional weakness. Being on the outside—and not only on the outside, but working for a competitor that NetApp fiercely detests—I lack any inside knowledge of what might be going on at NetApp. I know they have a ton of very smart, talented folks over there, and those smart folks have engineered the heck out of their WAFL and snapshot technologies. But the reality is that NetApp is a one-trick pony. Look at their products: every single one is in some way based on the same underlying technologies. Kudos to them for getting as much mileage about of these technologies as they have; that’s a huge testament to the skill of their engineering staff.

However, it appears to me (again, lacking any inside knowledge I could be completely wrong) that they have reached the end of the road. I get the feeling that NetApp has done everything they possibly could do with WAFL and snapshots, and now that they have no more mileage with this pony and no more ponies in the stable, where does that leave them?

Again, I’m sure that everyone will take these comments as me bashing NetApp. My intent here is most definitely not to bash NetApp, but to simply state my observations. I’d love to hear others’ thoughts on the matter; my only request is that you fully disclose your affiliations. Speak up in the comments and let me know what you think! All courteous comments are welcome.

Tags: , , ,

3010: A MultiStore Primer

Wednesday, April 8, 2009 in Storage, Virtualization by slowe | 13 comments

This session describes NetApp’s MultiStore functionality. MultiStore is the name given to NetApp’s functionality for secure logical partitioning of network and storage resources. The presenters for the session are Roger Weeks, TME with NetApp, and Scott Gelb with Insight Investments.

When using MultiStore, the basic building block is the vFiler. A vFiler is a logical construct within Data ONTAP that contains a lightweight instance of the Data ONTAP multi-protocol server. vFilers provide the ability to securely partition both storage resources and network resources. Storage resources are partitioned at either the FlexVol or Qtree level; it’s recommended to use FlexVols instead of Qtrees. (The presenters did not provide any further information beyond that recommendation. Do any readers have more information?) On the network side, the resources that can be logically partitioned are IP addresses, VLANs, VIFs, and IPspaces (logical routing tables).

Some reasons to use vFilers would include storage consolidation, seamless data migration, simple disaster recovery, or better workload management. MultiStore integrates with SnapMirror to provide some of the functionality needed for some of these use cases.

MultiStore uses vFiler0 to denote the physical hardware, and vFiler0 “owns” all the physical storage resources. You can create up to 64 vFiler instances, and active/active clustered configurations can support up to 130 vFiler instances (128 vFilers plus 2 vFiler0 instances) during a takeover scenario.

Each vFiler stores its configuration in a separate FlexVol (it’s own root vol, if you will). All the major protocols are supported within a vFiler context: NFS, CIFS, iSCSI, HTTP, and NDMP. Fibre Channel is not supported; you can only use Fibre Channel with vFiler0. This is due to the lack of NPIV support within Data ONTAP 7. (It’s theoretically possible, then, that if/when NetApp adds NPIV support to Data ONTAP that Fibre Channel would be supported within vFiler instances.)

Although it is possible to move resources between vFiler0 and a separate vFiler instance, doing so may impact client connections.

Managing vFilers appears to be the current weak spot; you can manage vFiler instances using the Data ONTAP CLI, but vFiler instances don’t have an interactive shell. Therefore, you have to direct commands to vFiler instances via SSH or RSH or using the vFiler context in vFiler0. You access the vFiler context by prepending the “vfiler” keyword to the commands at the CLI in vFiler0. Operations Manager 3.7 and Provisioning Manager can manage vFiler instances; FilerView can start, stop, or delete individual vFiler instances but cannot direct commands to an individual vFiler. If you need to manage CIFS on a vFiler instance, you can use the Computer Management MMC console to connect remotely to that vFiler instance to manage shares and share permissions, just as you can with vFiler0 (assuming CIFS is running within the vFiler, of course).

IPspaces are a logical routing construct that allow each vFiler to have its own routing table. For example, you may have a DMZ vFiler and an internal vFiler, each with their own, separate routing table. Up to 101 IPspaces are supported per controller. You can’t delete the default IPspace, as it’s the routing table for vFiler0. It is recommended to use VLANs and/or VIFs with IPspaces as a best practice.

One of the real advantages of using MultiStore and vFilers is the data migration and disaster recovery functionality that it enables when used in conjunction with SnapMirror. There are two sides to this:

  • “vfiler migrate” allows you to move an entire vFiler instance, including all data and configuration, from one physical storage system to another physical storage system. You can keep the same IP address or change the IP address. All other network identification remains the same: NetBIOS name, host name, etc., so the vFiler should look exactly the same across the network after the migration as it did before the migration.
  • “vfiler dr” is similar to “vfiler migrate” but uses SnapMirror to keep the source and target vFiler instances in sync with each other.

It makes sense, but you can’t use “vfiler dr” or “vfiler migrate” on vFiler0 (the physical storage system). My own personal thought regarding “vfiler dr”: what would this look like in a VMware environment using NFS? There could be some interesting possibilities there.

With regard to security, a Matasano security audit was performed and the results showed that there were no vulnerabilities that would allow “data leakage” between vFiler instances. This means that it’s OK to run a DMZ vFiler and an internal vFiler on the same physical system; the separation is strong enough.

Other points of interest:

  • Each vFiler adds about 400K of system memory, so keep that in mind when creating additional vFiler instances.
  • You can’t put more load on a MultiStore-enabled system than a non-MultiStore-enabled system. The ability to create logical vFilers doesn’t mean the physical storage system can suddenly handle more IOPS or more capacity.
  • You can use FlexShare on a MultiStore-enabled system to adjust priorities for the FlexVols assigned to various vFiler instances.
  • As of Data ONTAP 7.2, SnapMirror relationships created in a vFiler context are preserved during a “vfiler migrate” or “vfiler dr” operation.
  • More enhancements are planned for Data ONTAP 7.3, including deduplication support, SnapDrive 5.0 or higher support for iSCSI with vFiler instances, SnapVault additions, and SnapLock support.

Some of the potential use cases for MultiStore include file services consolidation (allows you to preserve file server identification onto separate vFiler instances), data migration, and disaster recovery. You might also use MultiStore if you needed support for multiple Active Directory domains with CIFS.

UPDATE: Apparently, my recollection of the presenters’ information was incorrect, and FTP is not a protocol supported with vFilers. I’ve updated the article accordingly.

Tags: , , , , , , , , , , , ,

2031: Enhancements to NetApp Cloning Technology

Wednesday, December 3, 2008 in Storage by slowe | No comments

This session provided information on enhancements to NetApp’s cloning functionality. These enhancements are due to be released along with Data ONTAP 7.3.1, which is expected out in December. Of course, that date may shift, but that’s the expected release timeframe.

The key focus of the session was new functionality that allows for Data ONTAP to clone individual files without a backing Snapshot. This new functionality is an extension of NetApp’s deduplication functionality, and is enabled by changes within Data ONTAP that enable block sharing, i.e., the ability for a single block to appear in multiple files or in multiple places in the same file. The number of times these blocks appear is tracked using a reference count. The actual reference count is always 1 less than the number of times the block appears. A block which is not shared has no reference count; a block that is shared in two locations has a reference count of 1. The maximum reference count is 255, so that means a single block is allowed to be shared up to 256 times within a single FlexVol. Unfortunately, there’s no way to view the reference count currently, as it’s stored in the WAFL metadata.

As with other cloning technologies, the only space that is required is for incremental changes from the base. (There is small overhead for metadata as well.) This functionality is going to be incorporated into the FlexClone license and will likely be referred to as “file-level FlexClone”. I suppose that cloning volumes with be referred to as “volume FlexClone” or similar.

This functionality will be command-line driven, but only from advanced mode (must do a “priv set adv” in order to access the commands). The commands are described below.

To clone a file or a LUN (the command is the same in both cases):

clone start <src_path> <dst_path> -n -l

To check the status of a cloning process or stop a cloning process, respectively:

clone status
clone stop

Existing commands for Snapshot-backed clones (“lun clone” or “vol clone”) will remain unchanged.

File-level cloning will integrate with Volume SnapMirror (VSM) without any problems; the destination will be an exact copy of the source, including clones. Not so for Qtree SnapMirror (QSM) and SnapVault, which will re-inflate the clones to full size. Users will need to run deduplication on the destination to try to regain the space. Dump/restores will work like QSM or SnapVault.

Now for the limitations, caveats and the gotchas:

  • Users can’t run single-file SnapRestore and a clone process at the same time.
  • Users can’t clone a file or a LUN that exists only in a Snapshot. The file or LUN must exist in the active file system.
  • ACLs and streams are not cloned.
  • The “clone” command does not work in a vFiler context.
  • Users can’t use synchronous SnapMirror with a volume that contains cloned files or LUNs.
  • Volume SnapRestore cannot run while cloning is in progress.
  • SnapDrive does not currently support this method of cloning. It’s anticipated that SnapManager for Virtual Infrastructure (SMVI) will be the first to leverage this functionality.
  • File-level FlexClone will be available for NFS only at first. Although it’s possible to clone data regions within a LUN, support is needed at the host level that isn’t present today.
  • Because blocks can only be shared 256 times (within a file or across files), it’s possible that some blocks in a clone will be full copies. This is especially true if there are lots of clones. Unfortunately, there is no easy way to monitor or check this. “df -s” can show space savings due to cloning, but that isn’t very granular.
  • There can be a maximum of 16 outstanding clone operations per FlexVol.
  • There is a maximum of 16TB of shared data among all clones. Trying to clone more than that results in full copies.
  • The maximum volume size for being able to use cloning is the same as for deduplication.

Obviously, VMware environments—VDI in particular—are a key use case for this sort of technology. (By the way, in case no one has yet connected the dots, this is the technology that I discussed here). To leverage this functionality, NetApp will update a tool known as the Rapid Cloning Utility (RCU; described in more detail in TR-3705) to take full advantage of file-level FlexCloning after Data ONTAP 7.3.1 is released. Note that the RCU is available today, but it only uses volume-level FlexClone.

Tags: , , , , , , , ,

Virtualization Short Take #20

Thursday, October 23, 2008 in Microsoft, Virtualization by slowe | 1 comment

This week’s Short Take is a collection of links and articles that I’ve seen over the last few weeks (or longer ago, in some cases!) that I thought others might find interesting or useful. Enjoy!

  • Alessandro broke the news to the general public about some anticipated new virtualization features that are expected to make their debut in Windows Server 2008 R2, expected sometime in 2010. Microsoft announced live migration for Hyper-V back at the beginning of September, so that part was already known. Now coming from Alessandro’s article is the announcement that Microsoft is developing a cluster file system, similar to VMFS, called Cluster Shared Volumes (CSV). Personally, this wasn’t a big surprise to me as a contact of mine leaked this to me a while ago. Hopefully this won’t hit Sanbolic too hard, whose Melio FS and Kayo FS solutions were intended to fill this gap (as discussed here and here).
  • As fully expected, VMware and Microsoft trade lots of barbs back and forth about VMware ESX vs. Hyper-V and vice versa. Out of the various exchanges, I found the “Too Dry and Crunchy” exchange—now quite old, having been published back at the end of September—the most entertaining. It started here with a barb from VMware about how Hyper-V with Server Core, the recommended configuration from Microsoft for virtualization hosts, is “not the Windows you know.” They compared Hyper-V on Server Core to ESXi and, not surprisingly, found ESXi to be easier and faster to install. What was really surprising though, was the response from James O’Neill in which he essentially agreed: Server Core isn’t “the Windows you know.” While he does love Server Core, James also recognizes that Server Core is not the right fit for every workload, and that management processes and procedures may need to change when using Server Core. Personally, I’m glad to see James recognizing and being honest about the limitations (or caveats) of Server Core. If only all vendors were so honest about their own products…one day, perhaps.
  • Duncan points out a great PDF on the definitions of various memory statistics. Readers may find that useful in understanding the various counters within VirtualCenter.
  • This VMware KB article outlines a potential VMware HA problem with multiple Service Console interfaces.
  • Andy Leonard picked up this VMware KB article that I bookmarked via Delicious.com and discussed how VMware’s recommendations and NetApp’s recommendations seem to run counter to each other. Personally, I’m inclined to follow VMware’s recommendations after the little snafu with NetApp’s NFS file locking suggestion.
  • This is a cool article on the use of ZFS and iSCSI to create clones in storage instead of at the virtualization layer. This is interesting because it’s being done with Solaris and ZFS, but it’s functionally equivalent to FlexClones with NetApp, which I’ve discussed before (see here, here, and here). Accordingly, ZFS clones will suffer from all the same limitations as NetApp FlexClones.
  • And while we’re on the topic of Sun and NetApp, what’s the deal with the recent patent rulings in the ZFS vs. WAFL lawsuit? If I’m reading this update correctly, it looks like some of the core WAFL patents from NetApp are being invalidated. Is Sun going to win this thing?

That does it for now. Thanks for reading!

Tags: , , , , , , , , , , ,

NetApp Suing Sun over ZFS

Wednesday, September 5, 2007 in Storage by slowe | 2 comments

I was on the road most of the day today, so I must have missed this news earlier. Apparently, Sun Microsystems and Network Appliance have had a little spat over ZFS and WAFL, and now NetApp is suing Sun for patent infringement.

Dave Hitz explained the situation in a blog entry:

This morning, NetApp filed an IP (intellectual property) lawsuit against Sun. It has two parts. The first is a “declaratory judgment”, asking the court to decide whether we infringe a set of patents that Sun claims we do. The second says that Sun infringes several of our patents with its ZFS technology.

Dave Hitz goes on to attempt to differentiate NetApp’s actions from the IP lawsuit(s) of SCO infamy. Personally, I wouldn’t place NetApp and SCO in the same situation, although I am strongly opposed to the current system of software patents. Patent reform is desperately needed, before things get worse than they already are.

In any case, this turn of events is unfortunate. I’m not technical enough to be able to provide any sort of opinion with regards to whether or not ZFS actually does infringe upon NetApp’s WAFL patents (or the other way around), but I do hope that Sun and NetApp can settle things amicably and move forward with more innovation, rather than getting stuck in an argument over who owns what. That’s the last thing either company needs right now. In addition, ZFS’ status needs to be settled quickly, before more companies decide to try to adopt a supposedly open sourced file system and incorporate it into their own products (as Apple reportedly did with ZFS and Leopard).

For more information on the lawsuit, see this eWeek article or this report from The Register. I’d also be interested in hearing anyone else’s feedback on the situation. What’s your take?

Tags: , , , , ,

Comparison of WAFL and ZFS

Monday, March 12, 2007 in Storage, UNIX by slowe | No comments

This comparison of ZFS (Zettabyte File System) and WAFL (Write Anywhere File Layout) by Network Appliance (no direct link for WAFL) is an interesting comparison of these two advanced filesystems and their feature set. Be sure to read the comments for some additional insight on the comparison of the two filesystems and some clarification about supported features.

One distinction raised in the comments that’s worthy to be noted here is that any comparison of this sort also, by its very nature, takes into account the operating system that runs the filesystem. As a result, any comparison of ZFS vs. WAFL also involves, to a lesser extent, Solaris and Data ONTAP, respectively. Similarly (and I think this may have been pointed out in the comments as well), the underlying hardware used by these filesystems (and their operating systems) also comes into play as well.

For these reasons, it’s impossible—in my mind, at least—to perform any sort of apples-to-apples comparison of these two technologies. It’s still an interesting article, though.

Tags: , , , , , ,