Do you remember them? If you go back that far in personal computing land you should recall what an external FPU or math co-processor is. Here’s the Wikipedia definition for context, which I find personally very interesting for this post:

A floating-point unit (FPU, colloquially a math coprocessor) is a part of a computer system specially designed to carry out operations on floating point numbers. Typical operations are addition, subtraction, multiplication, division, and square root. Some systems (particularly older, microcode-based architectures) can also perform various transcendental functions such as exponential or trigonometric calculations, though in most modern processors these are done with software library routines. In most modern general purpose computer architectures, one or more FPUs are integrated with the CPU; however many embedded processors, especially older designs, do not have hardware support for floating-point operations. In the past, some systems have implemented floating point via a coprocessor rather than as an integrated unit; in the microcomputer era, this was generally a single integrated circuit, while in older systems it could be an entire circuit board or a cabinet. Not all computer architectures have a hardware FPU. In the absence of an FPU, many FPU functions can be emulated, which saves the added hardware cost of an FPU but is significantly slower. Emulation can be implemented on any of several levels: in the CPU as microcode, as an operating system function, or in user space code. (source: http://en.wikipedia.org/wiki/Math_coprocessor )

If you’ve noticed the bold and colored sentence in the selected text above, it points to the fact that most modern processors have replaced math co-processors with embedded Floating Point Units and software libraries. So what has happened is that a previous cottage industry, which provided ASICs functioning alongside a CPU, have disappeared.

However, that hasn’t stopped new technologies from cropping up in the area of numerical processing. A type that has become extraordinarily popular for graphics and vector processing of late are GPUs. For specific numerical and highly parallel tasks GPUs with standard x86 CPUs have arrived on the scene and become popular for increasing compute capability while decreasing physical system footprint. Generalizing a bit, what I see is the sedimentary hypothesis in action: separate HW function lives for a while, but eventually, when functioning as the microprocessor, libraries and compliers become good enough that the need for a separate HW goes away. Repeat cycle!

Now let’s take a look at what Intel has been doing with their microprocessor family around embedded applications such as storage. Specifically, if you read some of Intel’s product briefs on their microprocessors for embedded applications and you’re a storage vendor, you might think that hell has finally frozen over.

Intel has been implementing embedded application functionality into their Xeon processor line adding in a veritable alphabet soup of TLAs. Here are but a few of the capabilities:

• Internal support for RAID 0, 1, 5, and 10
• Integrated SAS and PCIe
• Support for AES, Hashing, Chunking and Compression
• Non-transparent bridging
• Various virtualization assists

There’s also the assertion from Intel that software RAID stacks with Intel microprocessor assists are on par with ASICs that support RAID offload from a standard microprocessor.

My response: Okay, this is nothing more than the sedimentary hypothesis in action, and eventually Intel’s Xeon SoC for embedded systems will solve some, but not all, storage problems. Furthermore, new whitespace problems will emerge in the storage market, and guess what? Intel won’t have that capability on or near their processor for a while — just like we see with math co-processors being sucked into the micro process and GPUs in a Phoenix-like way, rising from the math co-processor ashes. So from ASIC to microprocessor and back again!

Any ideas for what the white space could be? Drop me a line or comment here if you have any suggestions. Otherwise, tune in soon to read some ideas in a future post.

Here goes example number one: NAS virtualization.

You may recall past companies and products in this space. Those that come immediately to mind include Rainfinity, Acopia, and StorageX, with only Acopia ARX really existing at F5 as a standalone NAS virtualization product. All the others have either been acquired or have gone out of business (at least as far as I know). As there are no longer being highlighted via a standalone application or appliance begs the question: Is NAS virtualization a viable technology?

You bet, and you can see it in action within two Hitachi products, except not as separate appliances: Notably, you’ll find NAS virtualization in the Hitachi Data Ingestor (HDI) and the Hitachi NAS Platform (HNAS).

Our first incarnation was done in 2007/2008 by applying engineering talent from HDS to the then standalone BlueArc. (Here’s a shout out to Simon, Paul, and Phil…welcome back!) It showed up as a feature called eXternal Volume Link (XVL) and was controlled through a basic interface on the native element manager or through full content and indexing via Hitachi Data Discovery Suite (HDDS). XVL can talk to any NFSv3 server as well as using REST over HTTP to talk to Hitachi Content Platform (HCP). So what we did was to put NAS Virtualization as a feature into the storage infrastructure four years ago.

The second incarnation is within HDI and was first implemented as a connection to HCP using REST over HTTP. It is and was designed as a cloud on-ramp for remote locations to connect to stellar Hitachi Private cloud/object storage infrastructure. Most recently with the updated version of HDI we are now able to also virtualize via the CIFS protocol to consolidate existing NAS and Windows Filers into a Hitachi Private Cloud infrastructure. The setup of HDI for this purpose, just like XVL, is as an inline file system virtualizer which can take over shares from the target filers or file servers and allow users to smartly drain these older systems into the cloud.

In both instances you can see that in-band/inline NAS or file system virtualization is no longer a standalone product like F5 ARX or any of the other legacy technologies. In fact the NAS virtualization feature has transformed from a standalone application or appliance to features in the storage infrastructure. Digging a little deeper, two more key questions are: Why did we do this and why in this way?

Well to answer the first one, our customers asked us to. Here is a customer quote from 2006/2007. (Now, I will add that at the time this customer was the “poster child” for Acopia and since there is no statute of limitations on protecting customer names, I’ve removed the customer name from the quote.)

“Acopia was our only choice at the time, but if it was incorporated into a NAS product we’d throw out their [ARX] product in a second.”

Wow! This is still, and was back then, a very clear driver to do what we did. As to why we implemented XVL and HDI file system and NAS virtualization the way we did, that is pretty simple. When we looked at our existing portfolio we already had what was becoming a blockbuster success in the form of in-band block storage virtualization in the form of the original USP. This system had the data movement engine within the storage controller sporting a basic control point on the native element manager and an advanced control mechanism in an out-of-band controller called Tiered Storage Manager at the time. As a result we made the determination that to help our customers as they wanted to add NAS to their portfolio, we’d follow a similar approach with the hope of making adoption easier.

If this isn’t a data point screaming that the sedimentary hypothesis of technology is true then I don’t know what else is. However, this is only one data point and more are needed, and for that you’ll have to wait until the next post.

Organic sedimentary rocks are formed under varying degrees of pressure and temperature over long periods of time. More pressure and an increase in temperature will form different types of organic sedimentary rocks. When organic material is broken down it becomes peat. Peat is the first step in the organic sedimentary rock process. As more earth accumulates over the peat and causes the peat to come under greater pressure and a higher temperature, then lignite is formed, another type of organic sedimentary rock. After the lignite is formed it begins to undergo a similar process as the peat. More pressure is applied to the lignite and the temperature becomes hotter resulting in the formation of bituminous coal. Bituminous coal then becomes anthracite coal as its temperature and pressure increases. Coal is created under swampy conditions that are not commonly found in our era because it needs higher sea levels to help it form. (Source: eHow.com on Organic Sedimentary Rock)

Obviously what precedes the generation of organic sedimentary rock is a vibrant active ecosystem filled with fauna and flora—both of which can die initiating the process of rock formation. I see technology in much the same way; basically it goes like this:

1. Application – correlates to the vibrant and active ecosystem, but eventually every application or at least some parts of an application “die”, begetting.
2. Middleware/Feature-ware – matches the peat stage of organic sedimentary rock formation and occurs when what were once vibrant applications or several application components transform into a middleware stack or a set of capabilities within an existing middleware stack, and with time and market pressure produce.
3. OS-ware/Infrastructure-ware – is rather like ignite or bituminous coal happening when middleware and feature-ware end up as either features or components  in either the OS or within the infrastructure (e.g. Storage, network or compute), and finally with additional market innovations result in.

Microprocessors, ASICs, ASSPs or FPGAs – realize the equivalent of anthracite coal and are comprised of accelerators, full/partial offloads of capabilities into silicon or assembly-like instructions executing on FPGAs. (Note that complete implementations may never find their way into silicon; however when algorithms arrive on silicon often extreme performance boosts and power consumption reductions are major benefits.) This is the general “hypothesis” that I’ve been referring to, and I think there may even be more sub-cycles within each layer. For example, multimedia functions (e.g. graphics and audio) used to be merely a set of software running on a general purpose processors. Then, over time, the GPUs and other accelerators have arisen, taking moving a large part of this function onto silicon. Now, given even more time, there is a processor from the SoC model to further compress things like GPUs onto a single multi-type many-core processor produced by the likes of Intel or AMD. Another example is in the DBMS world where there are a plethora of open source alternatives to Oracle and NO-SQL systems whose core is available for free. I believe that this shows in the middleware layer there is healthy market pressure/competition resulting in a wide selection of offerings.

A conclusion, and an inappropriate one, is that because of the large number of DBMS technologies, especially with the focus on open source, this market is officially commoditizing.

I have a couple of other posts up my sleeve with some real world examples coming soon. Until then, what do you think? Am I on to something? Can we transform the hypothesis into a theory?

I would say that the next tool in the arsenal of any Big Data question is Search!

However, the big “S” Search that I’m talking about is before an analytic query across data residing in a data mart, Key Value Store, Columnar Data Store, or any other NO-SQL (not only-SQL) system. Since in the era of the big bang of Data the super majority of data is potentially exabytes in scale and structured, unstructured and semi-strucured in type, I argue that this pre-Search may indeed be the most important of all.

In his post, Philip Russom talks about this very point: an early step in the overall analytic process, he calls “Discovery Analytics,” which is prior to the institutionalization phase requiring formal ETL placing the data into a DWH or NO-SQL store. This is not dissimilar to early phases in eDiscovery, which include a kind of raw search across mounds of content. Results from this search are then passed to a case management tool for further refinement and analysis. This Discovery Analytic process, to use Philip’s term, identifies the insightful diamonds in the rough which can literally transform, refine, revolutionize, or save an enterprise. Without this phase we are left with no seed to initiate a longer term or deep and recurring analytic process—the kind that Mr. Russom dubs as being institutionalized.

My worry is that the industry is largely leaving behind Search or Discovery Analytics in the general discussions surrounding Big Data. Instead there appears to be fascination with NO-SQL data stores, feeding Hadoop, releasing your own version of a Hadoop, evolving BI tools to handle Big Data, etc. Perhaps this is due to the fact that Search is not trendy enough to warrant hype and excitement, but I suppose if we modify the name to “Discovery Analytics” things could change.

Rest assured that worrying about Search within the enterprise can yield real and tangible results beyond Big Data. In fact, at least Forrester states, as of 2009 information workers spend almost a half a day a week merely finding things inside of an enterprise. To me, this means if the enterprises and vendors who provide to the enterprise focus on Search as Discovery Analytics, we could improve the lives of everyday users and put in the rebar needed to pave the path towards managing Big Data.

Furthermore, I think that an added and positive consequence of focusing on search is the real potential to start the democratization of the Data Scientist. In my humble opinion this could not happen soon enough so that the role is prevented from being entrenched in an almost ivory tower-esque way throughout the industry.

Here’s to a Big-Data-verse for the people, of the people, and by the people.

• The Grand Design By: Stephen Hawking (@Prof_S_Hawking)
  • I’m a huge Stephen Hawking fan and have read (more than once) every book he has published—which will explain the next book pick.
• The Illustrated – A Brief History of Time & The Universe in a Nutshell (double book release) By: Stephen Hawking (@Prof_S_Hawking)
  • Having read the original versions of these books, this superbly illustrated release is packed with high quality, glossy pictures compared to the original books. This is more of a collector’s edition and of course, when reading a Hawking’s book, a quality picture is with worth a billion-billion (Carl Sagan reference) words. The best part of this book is I bought it at an “everything must go” blowout sale as the Borders in my neighborhood was shutting down.
• Holographic Data Storage – from Theory to Practical Systems By: Kevin Curtis; Lisa Dhar; Adrian Hill; William Wilson; Mark Ayres
  • Since I was researching some optical storage technologies for Hitachi, this book came highly recommended and from an interesting angle. Customers were asking about the Hitachi references within the book, so I bought it. It has been extremely helpful for me to understand this evolving area of technology which I believe will be game changing in the future.
• CUDA by Example – An introduction to General-Purpose GPU Programming By: Jason Sanders; Edward Kandrot (@ekandrot)
  • Another part of my research for hardware accelerated applications and their uses in enterprise applications.
• HTML5 – Step by Step By: Faithe Wempen M.A.
  • Mainly purchased this as an HTML5 reference book for an internal project I am working on.
• Adobe Dreamweaver CS5 with PHP: Training Source Code By: David Powers
  • Same project support as above.
• HTML5 - 24–Hour Trainer By: Joseph W. Lowery; Mark Fletcher
  • Again, same project support as the above.

Also, here are some miscellaneous books I picked up at a clearance table. If you’re like me, you can’t pass up one of those 70% off clearance deals to fortify your technical library. And since I do a lot of video and audio editing, I also needed these for some personal projects.

• Producing Great Sounds for Digital Video By: Jay Rose
• Audio/Video Protocol Handbook By: Jerry Whitaker
• Gigahertz and Terahertz – Technologies for Broadcast Communications By: Terry Edwards

What are your top book recommendations from 2011?

In the United States, Commercially available Off-The-Shelf (COTS) is a Federal Acquisition Regulation (FAR) term defining a non-developmental item (NDI) of supply that is both commercial and sold in substantial quantities in the commercial marketplace, and that can be procured or utilized under government contract in the same precise form as available to the general public. For example, technology related items, such as computer software, hardware systems or free software with commercial support, and construction materials qualify, but bulk cargo, such as agricultural or petroleum products, do not. (source: Commercial off-the-shelf - Wikipedia, the free encyclopedia)

My colleague Ken Wood talks about commodity in a post several months ago, Soybean Is A Commodity, where he muses on what is and is not a commodity. His summary is that basically the output and the resulting measures of many of the devices and systems that are produced in the ICT field are a commodity. However, the systems and devices themselves aren’t.

He says, “It is my opinion that there is a misunderstanding and confusion in the IT industry between ‘commodity goods’ and ‘consumer products’ when it comes to technology. I can’t pinpoint the exact origin of why or how these two concepts seem to have become synonyms for each other, especially in the IT industry, but there is a difference between commodity goods and consumer products.”

Personally, I think that this stems from confusion about COTS and commodity, and may have crept into the ICT vocabulary just like “NIC Card” and “Transparent to the Application,” see my previous post where I ranted on the topic of language misuse in ICT. While occasional misuse is relatively harmless, I believe that the misapplication of commodity has resulted in inappropriate thinking about the costs of technology. Let’s explore this last point for a bit.

Let’s assume that hard disk drives and the resulting capacity were a commodity, if so they are a strange beast I would have to say. In fact they may even represent a kind of unique commodity which follow the law of supply and demand, but have planned cost erosion. The cost erosion is associated to predictions by industry patterns like Moore’s law, and is somewhere between 20%-30% per year. Imagine that—a commodity with a predictable annual per unit price decline. I’m sure that the mathematical wizards on Wall Street would love to have something with the level of predictability experienced in both consumer and enterprise capacity production/purchases. Sure tragedies like those in Thailand and restrictions of rare Earth metals can cause disruptions in supply that has the potential to increase costs if demand is not damped or constrained, but through the innovative human potential and given enough time even these unfortunate events have little impact. So is storage capacity a commodity? I would say that unless the definition of a commodity has changed, both the capacity measures and the actual devices aren’t a commodity. They are rather COTS devices with commodity properties.

With that in mind, what about CPUs, memories, and more importantly advanced systems that aggregate and combine COTS in unique ways to release innovation? In my opinion the clear answer is no. Storage, servers, networking, etc. are not commodity, but surely can be COTS. Obvious questions are: Why is this important? Why does it matter? I see this is important because of the potential for COTS to contain innovations unique to a particular technology supplier. This matters to any consumer of ICT because these innovations may actually be a better match to your business, and potentially even the entire market as a whole.

This last statement “entire market as a whole” is interesting because I see that the fundamental tectonic plates of the technology industry are shifting to favor more OPEX-friendly technologies. It also means that as a consumer, you may be willing to pay more for innovation in the short term especially if the technology delivers innovation you can leverage and amplify, or it reduces your OPEX such that you can reinvest money elsewhere. So where do we see this occurring in the industry now? Well, I would say that the trend to deliver complete IT stacks as I’ve discussed in The Rack is the New Server, the Data Center is the New Rack, is an example where CAPEX may be a bit higher but the potential for savings on the backend through staff reallocation, reduced maintenance costs, and assured configurations may make the slightly higher CAPEX worth it.

So the next time you hear an IT professional say something like, “That’s just a commodity technology…” stop them and correct the usage of commodity with COTS. By keeping this terminology misuse in the ICT industry it serves to devalue innovations that vendors add, users can take advantage of, and that creative companies can leverage to engender new innovation on top. I personally fear that without a grass roots effort to make a change here as an industry we are going to be increasingly satisfied with mediocre offerings and products.

I’d rather see more shoot for the moon and focus on “the insanely great” instead of settling for the mediocre.

This morning I was catching up on some HDS Industry Influencer Summit bloggers’ and analysts’ write-ups and opinions from the days of Nov 10th and 11th. As I wrote previously my blog, I was in a concurrent breakout event with several industry bloggers on the “other stage” during the afternoon’s main session. I was following links to various write-ups and ran across Ilja’s Coolen’s blog. Funny thing is, it was a write-up from a separate event back in March in the UK that I didn’t participate in. So, when I finished writing this blog, I realized what happened: too much link-clicking, and I ultimately ended up at an article that was six months old. While it is several months old, Ilja’s post did ask a very good question that still I would like to respond to on server packaging and capacity. In his blog, he states:

“Hitachi is able to deliver a completely filled 42u rack with 320 high density micro servers. The total rack would consume less than 12 Kilowatt. Whether or not this is a great accomplishment, actually depends on the total processing capacity this rack would have. I need to dig deeper into this to make a comparison.”

I have, in the past, performed paper exercises of sizing computing horsepower for initial comparisons. When everyone uses the same processor chips from either Intel or AMD, do they all perform the same? Where are the differentiators? To cut through the fat, one area is packaging.

The whole discussion of rack mount servers versus blade server systems has been in debate for a number of years, and it is somewhat falling into a religious discussion. The argument for commodity-like advantages of pizza box servers over the easier to manage enterprise blade server architectures is not going to be resolved here. But what I will offer is some of my insight into performance and the advantage of packaging using the same processor chipsets.

Using a standard formula to calculate floating-point operations per second (FLOPS) then applying to a server system such as the one I use here:

(Number of FLOPS per Cycle) * (Clock Cycle) * (Number of Cores)

Adding additional system level information will yield the system’s or blade’s overall calculated FLOPS performance (of course this is a brute force approach, but it is a good starting point). For instance, using the Compute Blade 320 (CB320) blade server option as stated in Ilja’s blog and as mentioned by Lynn McLean in her presentation:

• Using the X5670 XEON based blade
  • (there is a reason I’m using this one and not the fastest processor option for now)
  • 4 FLOPs per clock cycle
  • times 2.93GHz
  • times 6 cores per processor
  • times 2 processors per blade
• Single precision FLOPS – 4 times 2.93GHz times 6 times 2 = 140 GFLOPS
  • times 10 blades in a system= 1.4 TFLOPS
  • times 7 CB320 systems in a rack = ~10 TFLOPS

I should note here also, these are general purpose computing FLOPS as compared to GPGPU FLOPS, which require additional coding and compiling steps to take advantage of this technology. This means almost everything running on these systems can take advantage of the performance assuming internode awareness (application is scale-out aware).

If you followed this same formula for the standard 1U rack mount server using the same chipset and core count, it would result in about 6 TFLOPS (140 GFLOPS per server times 42 servers in a fully populated rack) compared to almost 10 TFLOPS per rack using the CB320 (70 blade servers in a rack). So, net results of this exercise is packaging and density of 70 blade servers in a rack compared to 42 servers using the standard 1U rack mount servers yields a 40% improvement in floor space requirements for the same computational capability. Stated in a more measurable metric, the CB320 yields 235 GFLOPS per rack U compared to 140 GFLOPS for a standard 1U server in the same 42U rack. On the higher end of the CB320 product line, the X5690 blade, the calculated floating-point performance for this blade is 166 GFLOPS, which would put the rack’s total calculated performance at 11.6 TFLOPS or 277 GFLOPS per rack U.

Hopefully this helps answer Ilja Coolen’s question about server density and capacity. The other point to finish off this article is the notion of data intensive and computational intensive architectures. I’ve just shown some data that suggests the CB320 has the capacity to be very computationally capable. On the other hand, the CB2000 has the capability to be very data intensive. The specifications for the CB2000 states 16 GB/s total bandwidth in a single blade system and 64 GB/s of total bandwidth from a fully configured rack. Combined, these two systems form a formidable platform for solving Big Data challenges. Not that Big Data problems are a floating-point intensive workloads, but you never know.

More on this thought in future blogs.

A VSP was on display in the booth, next to what I call the world’s largest server blade. I don’t actually know if this is a fact or not, but it is very impressive to see this device used in this specialized field of computing. Also, there was the new HA8000-tc rack mount server for technical computing (I want/need some of these in the Innovation Lab).

I also hung out at the BlueArc booth, which now displayed new panels with “BlueArc – Part of Hitachi Data Systems” in large, vivid lettering. Nice! Sorry, I didn’t get a picture of this for some reason, but I’ll grab one from someone or someplace. I did hang out at the booth meeting with new BlueArc colleagues and old HDS colleagues, as well as customers of other vendors interested in knowing more about everything.

Probably one of the more interesting activities at the conference for me was the attention given to data intensive workloads specifically around “Big Data”. There were several events going on surrounding Big Data that, unfortunately, I was not able to attend. However, since the majority of my time and my team’s time is spent solving Big Data problems in the enterprise, this is an area and community we will continue to monitor closely. I have been using scale-out and HPC architectures to explain and solve the Big Data challenges in the enterprise and this is evidence of that approach. Stay tuned for more on this subject. Unfortunately, I was unable to attend any of the sessions, tutorials or BoFs this year. I didn’t even get a t-shirt or conference goodie bag. Hopefully, next year my schedule will allow for more time to participate and explore like I usually do.

After that tour, and while walking Greg out of the rest of the day’s activities, he stated to me “…you’ve probably have the greatest job in the world!” I replied back “trust me, this isn’t the only thing I do, and the rest of my job isn’t so great” (sorry Michael). However, I took this in meaning that my team is instrumental to changing the industry’s perception of the “New HDS”, or at least that’s how I interpreted his comment.

I didn’t think much more about his comment until this week when he followed up with an email to Michael Hay and myself basically stating the same. Unfortunately, he didn’t say that I WAS ‘doing a great job’ and he included Michael so I couldn’t edit his email before forwarding it ;^) Obviously, there’s a sense of pride when someone recognizes the work being done, especially since being so close to the work can take your focus off the larger vision.

It is rewarding for me and my team to know that we are helping to transform HDS from  being viewed as a storage company to something more while keeping to our roots. I normally describe the difference between HDS and other technology companies in this market space as - companies that are primarily seen as a server company see storage as a place to keep data, but a storage company would treat data as the digital assets of an enterprise and use servers as a way of making that data useful to the business. To this, I also like to describe storage (at least the way HDS does it) as maintaining the “state” of the company, while servers can become “stateless” interchangeable components that essentially are data processing offload engines to the storage infrastructure.

I am definitely looking forward to following up with several participants of this event as I received many requests and questions. Also, I am looking forward to next year’s event, and what we will be sharing.

For more content from HDS Analyst Day, visit our bit.ly bundle: http://bitly.com/u0mh27

Listen below to hear John answer questions regarding Hitachi’s ability to differentiate in the future, and where we are uniquely positioned to be successful.

Also, I am interested in hearing your thoughts, so please post your questions and observations in the comment section below.