NetApp - The adventures of a Storage Researcher in Industrial Labs

The Birth of NetApp Blue Report

Our NetApp Advanced Technology Group has recently generated documents called Blue Reports that contain technical 1) background 2) analysis and 3) guidance information on many emerging technology trends and threats. Many co-workers from different groups at NetApp have asked me about the thinking or rationale behind these blue reports. So, in this blog I will articulate the thinking behind these reports. I will first list the problems we are trying to solve and will then briefly describe the process and how we are trying to tackle these problems. The NetApp Blue Report and the process associated in generating it is trying to solve the following issues (in no particular order):

•Empower researchers: The one thing most PhD grads hate is being told what to work on. This is a common phenomenon that I have seen at multiple research labs. Therefore, it is very important to let researchers have a say in figuring out the project they should work on.

• Bring focus and prioritize research areas: One of the common problems faced by managers in research labs is that their employees want to work on all sorts of things. Many times it is very difficult to get synergy and momentum amongst the different projects. It is desirable to work on a cohesive set of projects that can build upon each other. Furthermore, it is also necessary to quickly prune ideas without investing too much time.

• Early involvement and better communication with product groups: One of the major problems that researchers in industrial labs face is to get buy-in from product group architects. The architects feel that the researchers do not have a good understanding of the problem area, and the researchers feel that the product architects do not have an appreciation for the novelty of the idea.

• Early dissemination of analysis/guidance information of an emerging technical trend: Nowadays, new ideas are discussed in blogs, technical conferences, customer visits, and during interactions with product architects. Most researchers spend a lot of time understanding the customer problems and technical trends, and then doing a survey of related literature, analyzing the technical trend or problem, and then proposing new project ideas. This information is very valuable for executives and other employees within a company to get a good technical understanding of an emerging area and also its impact on the company.

Briefly speaking, the blue report process consists of identifying few new themes. The themes are identified by company leaders, researchers, and product architects based on emerging technology trends, competitor moves and customer problems. The notion of themes helps to bring focus with respect to what the group should work on. A set of researchers and relevant product group architects together form a theme team for each of the themes. This helps to both empower researchers as well as get early involvement by key product architects. Each theme team concretely defines the theme and its scope, does a background survey of the work done in that area, performs an analysis on what are the key problems, and how does this theme affect the company. Finally, the theme team also proposes a prioritized set of project ideas. The output of the theme team’s work is a blue report. This report can be read by others in the company to get a better technical understanding of an emerging technical area/threat. After the generation of the blue reports the research management tries to prioritize between the different themes and then allots resources for the top priority themes. Priority is determined based on company priorities, threat level, employee skill set etc. Generating a blue report typically takes around 3 months and one can periodically update it once in six months. Finally, I called it a Blue Report instead of calling it something else because I want a non-technical catchy name. Since NetApp’s new logo is blue in color, I thought about calling this report a Blue Report.

Re-emergence of DAS Model (Part 2)

As I mentioned in the previous part of this blog, primary storage at host (or DAS) model is definitely going to get more traction. This second part is only trying to articulate the different models for how the second copy of data can be stored. Second copy of data is required for availability (to overcome machine, site failures, data corruption), performance (load-balancing) and potentially for data integrity verification purposes. In this blog entry I am not focusing on the performance reasons for having the second copy. The two prevalent models being analyzed in this blog are peer-peer and host-storage controller models. In the peer to peer model, primary storage is backed at other peer nodes, whereas, in the host-storage controller model, the primary host storage is backed up at the storage controller. A peer is a light node with only 4 to 8 disks and it runs application code, whereas, a storage controller can support hundreds of disks and usually does not run application software. One could easily replace a storage controller with a storage cloud infra-structure. Furthermore, one could potentially also use tapes instead of disk based storage to store the second copy.

Now, I will articulate under what circumstances what will be the choice for the second copy of the data:

·        Case for Peer-Peer: For Map-Reduce applications, there is a need for a lot of processing nodes. Nowadays, in commodity configurations, most of these nodes come packaged also with some storage. If this storage is not being fully utilized for primary storage, then the peers will use the available space to backup other peer’s backup data. If the CPU/Memory requirements of the application don’t scale, then pursuing a peer to peer approach just for storing backup data will not be cost effective because of the low CPU/Memory utilization at the nodes. Similarly, if the cost of the storage media at the hosts is higher than the cost of the non-host storage media, then too it will not make economic sense to store the second copy at the host.

·        Case for Peer-Peer: Some companies have argued that a peer to peer setup consisting of commodity parts is more cost effective than using storage controllers. In some cases they have argued that it is cheaper to even have multiple copies of data in the peer to peer setup, rather than storing data in a storage controller. This is primarily the case if one is storing their data in Tier-1 storage controllers with full hardware redundancy and specialized non-commodity hardware. Furthermore, there is a difference in the cost to create a storage controller and the price the vendor charges. Thus, if a vendor uses commodity hardware components, then the vendor has the flexibility of reducing the price markup. In some cases due to their business models storage controller vendors will not be able to reduce the price.

·        Case for Storage Controller: If cost is really the issue, one could create a storage controller using commodity parts. That is, there are advantages to having higher number of disks behind a CPU complex (as in a storage controller) than as is the case in a host to prevent low utilization of the CPU resources.

·        Case for Storage Controller: One could argue that one can optimize the data layout format in a storage controller to focus of storage efficiency instead of performance. Furthermore, one can focus on operational efficiency by use very dense shelves, and also have the ability to power down/shutdown unused disks. It will be very difficult to realize these features in a peer to peer environment where the peers are storing both primary data as well as the second copy.

·        Case for Cloud Storage: For a small to medium size company, the operational efficiency (power, space, storage management) benefits of putting the second copy in a cloud managed by someone else is an attractive alternative. Internally, the cloud provider could employ either a peer to peer or a storage controller storage model. However, one has to trade-off cost/operational efficiency for privacy, wide-area network performance and availability concerns associated with cloud storage. Many organizations are experimenting with putting their archival storage into a cloud. There are other cost related reasons why small to medium organizations would want to also put their primary copy in a cloud (that is a separate topic for discussion).

·        Case for tape based storage: Based on the access pattern and purpose of the second copy, it could potentially be stored on tape. For example, people store backup data on tapes. People also store archival data, where the probability of retrieving archival data being close to zero, on tapes. However, the disk densities are approaching tape densities, and so, unless the tape cost is significantly lower, disk will be the preferred storage medium for the second copy due to the ability to perform random I/O, and due to the packaging of the disk head with the disk platters (that is, one does not have to worry about whether a particular head can read a particular cartridge).

Thus, as can be seen, people will choose different options based on the situation.