NetApp - Dave's Blog

Is Data ONTAP Based On UNIX?

A customer recently asked, “Is Data ONTAP based on UNIX?” Complicated question.

The first version of Data ONTAP borrowed lots of code from Berkeley Net/2 (one of the earliest open-source releases of UNIX), including the TCP/IP stack, system boot code, and device drivers. Since then, we’ve borrowed liberally from other open-source UNIX releases. We wrote the command line interface from scratch, but we designed it to look like UNIX, since our first market was UNIX system administrators. Clearly, ONTAP is related to UNIX.

On the other hand, ONTAP’s architecture is very different from UNIX. There is no user-space, the filesystem is completely different, the RAID and diskubsystems are completely different and most important of all, the interaction between subsystems is very different. The key data paths from network to disk look nothing at all like UNIX.

You can imagine two completely different ways of building an appliance. You could start with UNIX and strip out, disable, or hide the pieces you don’t want. sOr else you could start from scratch, inventing a new architecture optimized for the task at hand, but borrowing liberally from the UNIX code-base as appropriate. We chose the latter.

Interestingly, our advanced ONTAP GX architecture is built on top of a full UNIX release. We took Data ONTAP, including WAFL and RAID, combined it with the new code from our Spinnaker acquisition, and hosted the combined result on FreeBSD in a combination of user processes and kernel modules. For security and simplicity we have disabled and hidden many parts of FreeBSD.

Even for ONTAP GX, this isn’t quite the “start with UNIX and slim it down” approach, because most of the system lives in large kernel modules that kick UNIX out of the way. They grab control of almost all of the memory, as well as the critical device drivers, and we even re-wrote the scheduler to make sure the UNIX parts don’t get in the way. We’re still not using the normal UNIX data paths.

Why the difference? One reason is that CPUs are way more powerful now than when we started, so a little bit of extra overhead matters less. (Our first product used a 50 megahertz 486.) In addition, UNIXs have gotten much better. When we started, there was no Linux, no FreeBSD, and AT&T and UC Berkeley were still in a legal battle over big chunks of the Berkeley Net/2 Release.

Although these two approaches feel very different to engineers developing the systems, each with its own advantages and disadvantages, there is little if any difference to the end-user.

Is iSCSI SAN or is iSCSI NAS? I Don’t Know.

Many customers wonder whether iSCSI is a type of SAN or a type of NAS. I used to know, but not any more.

The two big differences between NAS and Fibre Channel SAN are the wires and the protocols. In terms of wires, NAS runs on Ethernet, and FC-SAN runs on Fibre Channel. The protocols are also different. NAS communicates at the file level, with requests like create-file-MyHomework.doc or read-file-Budget.xls. FC-SAN communicates at the block level, with requests over the wire like read-block-thirty-four or write-block-five-thousand-and-two.

If you think the protocol is more important, then iSCSI is like SAN; if the wire is more important, then iSCSI is like NAS.

Technical people know that the protocol is more important; it determines how the compute server talks with the storage. With FC-SAN, a filesystem like UFS, VxFS or ZFS runs on the host and converts file requests into the block requests that are sent over the wire. With NAS, the host sends file requests over the wire, so a filesystem must run in the storage system. There are advantages and disadvantages to both approaches, but the point is that from an architectural perspective, iSCSI looks just like FC-SAN. The filesystem runs on the host and sends block requests over the wire. (Many technical people are offended by the idea that iSCSI might be NAS.)

Business people focus on infrastructure, budgets, and org charts, so they worry about wires. Choosing NAS over SAN for Oracle, Exchange, or SAP affects the capital budget for Ethernet versus Fibre Channel, and it can even affect organizational structure. Sometimes an “Apps/Servers/Storage Group” owns Fibre Channel, while Ethernet belongs to a “Distributed Infrastructure Group”. Is the Apps group allowed to buy and manage their own Ethernet switches if they decide to run Oracle over NAS? They may argue, “We should own the switches between server and storage.” The Distributed Infrastructure group may argue, “We own all TCP/IP networking,” but the corporate network may not offer the bandwidth or quality of service required for Oracle-on-NAS. I’ve seen CIOs do reorgs over these issues. Business-wise, iSCSI looks just like NAS, so business people often assume that iSCSI is a form of NAS.

I used to know iSCSI was SAN, and I lectured business people about why – technically speaking – they were wrong. But if I accept that technical and business perspectives are equally important, then I really can’t categorize iSCSI. Plus, many people still think of NetApp as “the NAS company”. Gartner’s SAN Magic Quadrant has us tied with EMC for first place in SAN, but perception is what matters, so it’s great for NetApp if customers think iSCSI is NAS. Why argue?

Our President Tom Mendoza taught me this: “Don’t waste time in sales calls trying to convince customers that they are wrong.”

Now, when I want to talk about the whole market, I just say: SAN, NAS and iSCSI. I don’t know whether iSCSI is SAN or NAS, so I list all three. If a customer presses me, I’ll say, “From a technical perspective, iSCSI looks more like SAN, but in terms of business issues, it looks more like NAS.” I’m no longer interested in debating the issue.

EMC’s Celerra Simulator (I Eat My Words)

A while ago I bragged about NetApp’s simulator, how useful it is for customers, and how no other storage vendor has anything like it.

I received a message from Chad Sakac at EMC who told me, “We have a Celerra simulator, and it’s great for all the same reasons that your simulator is.”

As Chad and I got to chatting, I said that I thought EMC was a great competitor, and that NetApp and EMC were probably good for each other, because competing kept us on our toes. Here was his response:

For what it’s worth – personally, certainly I don’t necessarily represent EMC in this context – I appreciate having as formidable a competitor as Network Appliance. With other competitors, we compete with them, and it’s a slow waltz, but with you folks, it’s a tango. It makes us better, win or lose with any individual customer, and in the end, it’s good for the industry and the customers.

I completely agree. I feel the same way about EMC.

Anyway, I replied that if the simulator was easily available to customers on the web, like ours is, then I’d retract my words and post a link. That shut him up for quite a while, because it wasn’t easily available anywhere, but I think my taunting gave him ammo to get things moving at EMC. He just sent another message saying that the Celerra simulator is now available on the web.

The URL is only accessible to EMC employees and partners, but Chad says that they are allowed to give the simulator to customers, so if you want it, and your EMC contact can’t find it, give them this link:

http://powerlink.emc.com/km/appmanager/km/secureDesktop?
_nfpb=true&_pageLabel=query1&internalId=0b01406680224db3&_irrt=true

Helping make EMC’s customers happier with EMC equipment isn’t normally the goal of my blog, but if that’s an unintended consequence here, then so be it. To really be of service to EMC’s customers, I suppose I’m now on the hook to find simulators for DMX, CLARiiON, and Centera. :-)

Tom Mendoza's Lessons on Public Speaking (Feelings, Action, Data)

This week I worked on a big presentation, so I thought I’d share some public speaking techniques I learned from Tom Mendoza.

Many people – especially technical folks like me – focus way too much on the data that they want to present to their audience. Tom always asks me how I want the audience to feel after my talk. Before I learned his technique, my answer would be something like, “I want them to feel that they understand the design goals and architectural details of ?”

At this point Tom would interrupt: “Feelings are one word. Angry. Proud. You know – emotions.” You can have a small phrase describing what the feeling is about. “Disappointed in our performance.” “Proud of our new release.”

Next, Tom would ask what I wanted people to do differently after my presentation. He argued: “If you don’t want them to do anything different, why are you wasting your time talking with them?” If you’ve reached an important milestone in a project, like a key code-freeze date, you might want people to feel proud of what they’ve accomplished so far, but to keep working hard until they’re done. If a project is way off track, the feeling of disappointment in the progress so far could motivate people to accept and engage a new approach. If a competitor is beating you, perhaps anger will help drive action. Part of the trick is to choose actions and emotions that naturally reinforce each other.

When you are clear on the feelings and actions that you hope to inspire with your presentation, then, and only then, should you start to worry about the content – about what data to share to inspire those feelings. You can say, “I want you to feel excited about what you did,” but it might work better to show the sales figures or benchmark results that prove people did a good job. Then the audience will naturally be excited. Or if the results are bad, naturally disappointed.

When I start with feelings and actions, it makes my presentations much better. Good content is important, but it’s only a tool. Feelings and actions are the goal.

At first, I struggled with Tom’s method because I wanted to share too much information. Now, I’ve learned to appreciate the elegance of finding the smallest amount of data required to drive the feelings and actions I want. For exhaustive detail, a web site or white paper is a much better communication tool. Sometimes go read the white paper is the action I want to inspire. Even in a classroom setting, lectures don’t replace textbooks.

I used to worry that removing details would result in over-simplified presentations. Now I believe that my job as a public speaker is to over-simplify.

But I still try not to over-over-simplify.

Does Helping Customers Use Less Disk Hurt NetApp's Business?

We got an interesting question in the Q&A session at our Analyst Day conference a couple of weeks ago:

NetApp focuses so much on technologies to save disk space—like Thin Provisioning and Clones—could that hurt your business by reducing the amount of disk that customers need to buy?

I don't think so. Here are three reasons.

First, we have an opportunity to gain share. NetApp has less than 10% market share for SAN, NAS and iSCSI, so if we can help customers save money by using less disk, then we have a great opportunity to grow. (We've roughly tripled our revenue in three years, so it seems to be working.)

Second, storage purchases are elastic. When storage gets cheaper, customers just seem to buy more. Remember, disk prices have been dropping by 40% per year forever, yet the storage industry keeps growing.

Third, we charge for the software that helps people use less storage. I would much rather make money by selling software that helps customers rather than by marking up commodity disk drives. (To put it another way, would you rather be Michael Dell or Bill Gates?)

These are the reasons that we gave on stage at the analysts meeting, but there is also a deeper, more philosophical reason. I strongly believe that innovating to help customers is always the right thing for our business. If there is a clever way to help customers, someone is going to do it, and I want it to be NetApp. One of the reasons that we've been taking share from EMC and HP is that we have been very creative about how to help customers. If we hold back, it will make us vulnerable to the next generation of emerging competitors.

Summary: If you don't eat your own lunch, somebody else will.