December 11, 2000
Posts selected for this feature rarely stand alone. They are usually a part of an ongoing thread, and are out of context when presented here. The material should be read in that light. How are these posts selected? Click here to find out and nominate a post yourself!
DAFS and Other General Ruminations
First, I need to stop posting on this board -- it's killing my recommendation to post ratio. I was averaging about 10 recs per post before -- now, after posting EMC oriented items on the NTAP board, I think I'm somewhere around negative 2 . . . maybe I'll start double-posting this stuff on the EMC board as well ;-)
Ah well, popularity can be highly over-rated anyways . . .
On to the rchampoux's and nastynas's requested response on DAFS [Direct Access File System]:
My first thought on DAFS is that it is a very ambitious future that promises to rectify a good deal of NAS's downside (latency issues etc.) while retaining the upside (multiple server access, etc.). I say future in that, regarding the first paragraph of the version v0.54 spec:
"The DAFS Protocol Specification, Version 0.54, is a work in progress by the DAFS Collaborative. Eventually, the specification may be submitted to a computer industry standards organization, but the particular organization has not been determined."In that DAFS hasn't even been submitted to a standards organization, it is not exactly what we would call a current market-affecting product. The same goes for iSCSI and FC over IP by the way. I think we all realize this. The only reason I draw attention to it is that it speaks to my ongoing contention that NAS as a replacement technology is still a few years off.
Also, more than just getting DAFS recognized, once it is submitted, it still takes a great deal of time for folks to make the adapters to support VI, and in general to get through the bleeding edge technology phase into the leading edge phase. More on this later.
My second thought on DAFS is to look at all the network inefficiencies regarding I/O that it is set to address (page 10 of v0.54 the spec is especially insightful on this matter). Once you see this, you may understand more why I keep stating that TODAY, with NFS or CIFS (SMB)at the core, NAS is not ready to replace SAN, DAS, etc. Namely, it is not because I am a Net App or NAS basher, but rather that there are good, sound, technical considerations that led me to this opinion. Check out the following excerpt as well:
"To understand these advantages [of DAFS], look at a typical network file access protocol like NFS. In NFS each I/O operation or I/O operation reply, like read or write, is embodied in a header. The header is inserted into the network byte stream followed by any user data. The receiver must parse the header and figure out the appropriate place to put any data that follows. For example, during a read operation the requester must parse the reply packet header to determine which of the many possible outstanding read operations this data is for. Then it must determine the destination data buffer associated with the request and copy the data into the buffer or otherwise cause the data to be copied there."
Again, just a bit more insight into why I stated previously that NAS is currently relying on RAW speed to overcome the inherent inefficiencies of using the network as a transport for I/O. This may also give some insight as to why I don't find NAS all that disruptive in its current iteration.
Regarding rchmampoux's comments about file systems, metadata, and the other benefits of NAS -- I am fully cognizant that there is a tremendous value to accessing data from multiple different servers and operating systems simultaneously -- for that reason, NAS is here to stay. All I am stating is that, due to the current inefficiencies of network attached storage, there is also an absolute need for channel-attached applications systems.
Perhaps, after iSCSI or FC over IP or DAFS come along and reach fruition, then we are dealing with something that is a replacement technology . . . but this is a few years off. Until then, it is my feeling that NAS is a very complementary technology to SAN, DAS, and other channel-based I/0 transports -- but not a replacement.
As a note, Data General and EMC both participated in the development of VI (a core part of DAFS), so I would be cautious of the opinion that EMC isn't watching the development of DAFS and preparing to integrate it if it becomes a worthwhile technology. I would also guarantee you that the same watchful eye is tracking the development of FC over IP and iSCSI.
As to whether DAFS will be a superior implementation to FC over IP or iSCSI -- my first thought here is that all of these specifications are currently way too embryonic for me to make any firm prediction on this matter. My second thought is that it would be much easier for FC over IP to gain a foothold in that it abstracts the applications and operating systems from change. Namely, it is simply creating a mechanism to transport a currently supported specification (Fibre Channel) over the network.
There would need to be no further application integration. DAFS, on the other hand, will require modification of existing applications to support it. Getting Oracle, Microsoft, SAS, DB2, Sybase, etc., etc. to all get on board and support the DAFS spec will be a monumental undertaking.
These are the types of issues that are going to take a good deal of pain and blood to overcome. They are the exact sort of issues that will delay DAFS from being put into mission critical environments for years. Namely, with any new technology, there is an adoption cycle that follows a bell curve pattern with the following groups -- visionaries, early adopters, the masses, late adopters, and the slow-moving, blind idiots with no money. Um, so anyways, the exact names of those groups aren't as I put them, but you get the idea.
The other important thing about this adoption cycle is that it is a bell curve -- which means that during the visionary and early adopter portion of the cycle, we are not talking about any large number of people. Only once those two groups go through the bleeding edge portion of the tech adoption cycle do the masses begin to move in and adopt the technology as leading edge. And it is only once the masses begin adopting that we are talking about the large portion of the bell curve as well as the mission critical data center environments and replacing SAN, DAS, etc.
By the way, I'm not saying DAFS won't eventually get there -- if it can deliver on everything it promises, it will merit the pain for the end benefit. What I am saying is that anything that requires change of this magnitude will by nature have to go through a long adoption cycle. On the other hand, something that can deliver the same benefit (or a reasonable subset of the benefit) without having to change applications, etc. will be able to go through this same bell curve adoption cycle somewhat more expeditiously.
This is why I have a better feeling about FC over IP and iSCSI which basically are finding ways to send currently known protocols (FibreChannel and SCSI respectively) over the existing cabling plant. They may only deliver a subset of what DAFS promises -- but the deliver it in a hardware implementation that abstracts applications and operating systems from change. This is a huge consideration when it comes to getting industry buy-in.
Note, that NastyNas feels that the fact that FC over IP and iSCSI is done in hardware ("in silicon" is how I think he put it) is actually a disadvantage to it getting done quicker, and that DAFS being done in software is actually an advantage. I point this out only to note that two intelligent, logical, technical people can see the same facts and come to two completely different conclusions. Either one or both of us could be right (or wrong for that matter).
Anyways, check out the following excerpt from the v0.54 spec regarding database integration with DAFS to see just one difficulty of integrating applications with DAFS:
"Some applications (such as databases) employ very large buffer caches of their own. Depending on the DBMS implementation, these buffer caches can be directly accessed by a large number of processes (on the order of several hundred to a few thousand). Large enterprise server-class systems currently support maximum memory configurations in the range of 32 GB to 128 GB. High-end published TPC-C results use most of this memory for DBMS buffer cache. These memory sizes and process counts clearly exceed the capability of today's NICs to maintain memory registrations for all of the DBMS buffer cache. Some applications will be leery of allowing relatively new hardware devices to directly DMA into their address space and may want to minimize their exposure to risk. For instance, mapping an entire DBMS buffer cache increases the risk that a read into one buffer may overwrite adjacent buffers. InfiniBand Memory Windows are designed to address this problem. In VI there seem to be two approaches to providing adequate protection: 1) have each buffer mapped with a separate memory handle, or 2) provide some new NIC VIPL interface to dynamically adjust the protection attributes in a TPT. The first approach requires a separate mapping of buffer address to memory handle on a per-process basis."
Application integration, by the way, is why I keep saying that, as transporting I/O over the network becomes more prevalent, that EMC may be in a better position than NTAP. I also noted that this may seem counterintuitive in that NTAP has done everything to make their name synonymous with network storage.
The thing is that easy, efficient, fast access to data assets is only half of the ballgame. The network may long term be the best way of taking care of this half -- I certainly believe that over the next three to five years, the network will begin to supplant fibre channel and other transport mechanisms.
However, there is another half of the picture that is extremely important. And that is management of that data and the optimization of business processes regarding that data. This is where integration with databases, mail platforms, data warehouse providers, etc. becomes increasingly significant. For instance, Oracle, Sybase, DB2, Informix, SAS, Informatica, MetroCluster, Legato, Tivoli, Veritas, etc., etc. have all written to EMC's Open API to optimize business processes such as nightly batch, backups, data loads,
database consistency checks, database tuning, development environment refresh, etc., etc. There are some of these processes that NAS and NTAP have not and are not currently addressing. This is yet another reason that I have stated previously that, while you CAN run a DB or other mission critical app on NAS -- when it comes to mission critical environments, there is a huge difference between can and ought.
So, at the end of the day when network attaching storage becomes the predominant transport mechanism for mission critical environments, all EMC has to do is support the new transport (whether it be DAFS or iSCSI or FC over IP). This is not a great or timely engineering feat.
In that NTAP did not grow up in mission critical environs, and hasn't delivered on this type of integration to date, what it has to do to compete on the other hand, is develop all of the integration that EMC is currently using to establish and extend its external storage leading market share. This is a much more timely and arduous engineering process.
EMC has spent the past 10 years putting these relationships in place and assisting vendors with developing the technology. They have also earmarked $10 billion dollars over the next 5 years to continue these sorts of efforts which, withstanding sirbruce's questionable statistic that this investment needs to be 24 times as great for the same effect, is more R&D dollars per year than NTAP makes in revenue.
NTAP is a great company -- they made a great effort to popularize NAS and continue, with technologies like DAFS, to push the envelope. They may be up to the this challenge. However, it just seems to me when they say that, "EMC doesn't get it" . . . that it is really NTAP that doesn't get it (or more likely -- in that the folks at NTAP are pretty bright -- that they are putting the market spin on).
It looks to me that EMC understands that network attaching arrays may be the way of the future -- but what they are saying is that it is the way of the FUTURE. TODAY, it is important to deliver on systems that can meet the demands of mission critical application environments as only SAN and DAS can currently do.
In addition it is important to deliver on a NAS solution that is complimentary to SAN and DAS -- and that for certain applications (file serving, delivering web content, etc.) is superior to SAN or DAS. As to the future and network attaching everything, that is what R&D is for. We certainly aren't there today. DAFS has a good deal of promise if it can deliver. FC over IP and iSCSI are also interesting trends to watch. I'm not sure which will win. Maybe they will coexist for awhile. Anyone that has been in this business for any length of time, realizes that emerging standards are tough to come by.
NTAP certainly has a good technical vision and has the strong ability of evangelizing this vision for the future. My only contention is that the key word there is "future." Network speeds will accelerate, fibre channel may eventually go the way of the dodo, new specifications will address network latency and overhead, etc., etc. I don't question the truth of these statements one bit . . . but the thing is that "will" and "eventually" don't help me build a mission critical storage topology today.
So, perhaps you understand now why I call NAS a segment or niche of the overall storage market, and also why I question NTAP's ability to knock EMC off the external storage market at large.
By the way, the current NAS market alone is significant enough for NTAP to grow substantially if it can retain market share. EMC will be the number one contender to take that title over the next year. Whether they can or not will be interesting to watch. The NAS market is certainly NTAP's core competency. To underestimate NTAP in that market would not be any more wise than it would be to underestimate EMC in the mission-critical market segment.
As to the future beyond that and network attaching everything, only time will tell -- I certainly think that is where the industry is heading, but some major engineering and scar tissue need to occur before we are talking about a legitimate replacement technology.
At the end of the day, I don't think whether the transport mechanism ends up being the network or ends up being Fibre Channel makes much difference as to who will win anyways. It's who can best integrate, manage, and streamline the business processes involving that stored data that has the advantage.
Ah well, it's late . . . I've begun to ramble. I hope there aren't too many areas above that could use more clarity, but I'm going to go to sleep rather than proofread. Happy Holidays and all that.
Industry Focus 2001
The companies highlighted in Industry Focus 2001 are a great place to start when you're planning your investments for the year ahead.
Become a Fool, it's Free!
Join us for: A free "Getting Started" series; Portfolio tracking; Free trials to IBD and others.
Read More Posts by This Author
Go To This Post
More Recommended Posts