Cloud

For another project, I had reason to try and find out the limits of the OnTap 8 Cluster-Mode; apart from the fact that NetApp need taking out and shooting with regards to their documentation, I’ve ended up reading more about Cluster-Mode than was probably entirely necessary for this project but it has been fascinating and some subsequent conversations with people have left with a very distinct impression that few people really understand what Cluster-Mode does. I made assumptions about what it was based on biases and prejudices from using other products.

For some reason, I equated OnTap 8 Cluster-Mode with SONAS and Isilon for example; this was a mistake, NetApp have as per usual taken their own approach and have produced something quite different. It is probably useful to understand some terminology.

Global Namespace is a term which gets thrown about a lot and is going to probably cause confusion when comparing products.

A File System is a method of storing and organising computer files and their data.

A Global NameSpace provides an aggregated view of an Enterprise’s File Systems allowing files to be accessed without knowing where they physically live; it is a virtual directory structure.

NetApp’s Cluster-Mode is really the aggregation of a number of NetApp Filers and volumes into a single virtual server, providing a Global Namespace for this aggregation, meaning that instead of having to know which filer a share lives on, it is possible to move from mounts which look like:

\\server1\share1
\\server2\share2

to mounts which look more like

\\company\share1
\\company\share2

This is obviously a lot easier for the end-users and means migrations etc do not require reconfiguration of end-user machines. This is a good thing!

OnTap 8 Cluster-Mode does allow you to aggregate performance of up to 24 filers; all of them can see all of the data and serve it out. But as far as I understand and I will be happy to be corrected, you are still limited to file-system sizes of 100 Tb i.e the maximum size of a 64-bit aggregate and also as far as I can tell, you are limited to having the file-system owned by a single HA pair. Data is not striped across all the nodes and the loss of an HA pair will result in the file-systems being hosted by that pair going off-line.

Isilon, IBM and HP in their products allow file-system sizes far in excess of this and measure their sizes in petabytes; this is because at their back-end, there is a true cluster file-system. This enables an individual directory for example to be considerably larger than 100 Tb or even individual files to be larger than this. Some of you are probably now shaking your heads and wondering what sort of files could possibly be that large; I will admit that 100 Tb would a very large file but files in excess of 1 Tb are not that uncommon in my world and a 100 Tb file-system could only have 100 of these in, not that much really.

A single file-system can also be made up of pools of storage which performs in different ways and can be fairly easily be automatically tiered; you can have files in the same directory which actually live on differing tiers of storage. Your home directory for example, those files which you are currently working on could be sitting on active disk whereas the files which are gathering dust could live on spun-down SATA.

Isilon, IBM and HP don’t have to implement a Global Namespace because their file systems are large enough and are distributed in such a way that a single file system could provide all file space required by an Enterprise.

Now NetApp’s approach does have some huge advantages when building Secure Multi-Tenancy for example and it allows for a very granular approach for replication etc. Also NetApp don’t have to deal with huge amounts of meta-data and their file-locking is probably easier but it is different.

There  is certainly a take-away from my research….

Global Namespace != Single Huge Filesystem

Now perhaps you already knew this but I suspect many were under the same delusion as me! And does this mean that NetApp don’t have a true Scale-Out Solution? I can certainly make arguments for both views.

Bring on OnTap 9! I reckon that’s the release which will combine it all including Striped Volumes from 7G.

p.s If I am completely wrong; it’s NetApp’s fault, the documentation and description of Cluster-mode is rubbish! Truly terrible! And yes, I could get someone from NetApp to come and talk to me about it but if I can’t get it from the documentation…you fscked up!

Now some people might think I was being a bit unfair picking on EMC/Isilon in my previous entry and to be honest I was but in a good cause. I’d picked up on a story which ‘Zilla retweeted a link to and it actually gave me the hook to something that I had been intended to write for some time.

IT Procurement policies need to change to reflect new paradigms and technologies. In the story that I picked apart, the customer bought 1.4 petabytes of Isilon disk up front; the customer only needed 200 terabytes of disk to cope with the first year of growth with an additional 340 terabytes per year there-after.

Isilon’s technolgy would make it easy to simply purchase additional nodes as needed and there was probably no technical reason for this up-front procurement. But I suspect the up-front was a requirement due to the way that the project was financed and budgeted, there was no internal mechanism to procure capacity when needed.

Now I suspect EMC/Isilon would have offered a decent additional discount for the initial up-front purchase but would it have offset the additional maintenance, power-requirements etc that would be accrued by early installation? And would it offset the year-on-year price decline of storage?

I can’t really blame a vendor for taking all the money up front and I certainly would not blame the sales-team for accepting an order which might have blown their targets. (There is a downside to the sale-team tho’; next year’s target might expect that you do another large deal again even though you have just sold a customer three years capacity).

I have read people talking about the possibilities and opportunities for IT to move to a purely Opex model using the Public Cloud; let’s get real for a minute, we are not currently capable of tweaking our Capex models to reflect a reality where money does not need to all spent up front. What are the odds that we can completely change our finance models to an Opex model? In my reality, we are constantly being challenged to reduce our Opex model; we often do this with Capex purchases. I’m not sure suggesting increasing my Opex even with a decreased Capex would meet with an entirely favourable reaction.

If the Capex model was tweaked to allow a more linear and time-based investment; I could have an even more dramatic impact on Opex and also reduce Capex expenditure but I’m a simple IT manager, what do I know?

Cloud and Dynamic IT is technically achievable in large parts today and not at huge disruptive cost but it does require disruptive thinking.

Big Data like Cloud Computing is going to be one of those phrases which like a bar of soap is hard to grasp and get hold of; the firmer the hold you feel you have on the definition, the more likely you are to be wrong. The thing about Big Data is that it does not have to be big; the storage vendors want you to think that it is all about size but it isn’t necessarily.

Many people reading this blog might think that I am extremely comfortable with Big Data; hey, it’s part of my day-to-day work isn’t it? Dealing with large HD files, that’s Big Data isn’t it? Well, they are certainly large but are they Big Data. The answer could be yes but the answer generally today is no. As I say Big Data is not about size or general bigness.

But if it’s not big, what is Big Data? Okay in my mind, Big Data is about data-points and analysing these data-points to produce some kind of meaningful information; in my mind, I have a little mantra which I repeat to myself when thinking about Big Data; ‘Big Data becomes Little Information’.

The number of data-points that we now collect about an interaction of some sort is huge; we are massively increasing the resolution of data collection for pretty much interaction we make. Retail web-sites can analyse your whole path through a web-site; not just the clicks you make but the time you hover over a particular option, this results in hundreds of data-points per visit and these data-points are individually quite small and actually collectively may result in a relatively small data-set.

Take a social media web-site like Twitter for example; a tweet being a 140 characters, so even if we allow a 50% overhead for other information about the tweet, it could be stored in 210 bytes and I suspect possibly even less; a billion tweets (an American billion) would take up about 200 Gigabytes by my calculations. But to process these data-points into useful information will need something considerably more powerful than a 200 Gigabyte disk.

A soccer match for instance could be analysed in a lot more detail than it is at the moment and could generate Big Data; so those HD files that we are storing could be used to produce Big Data to then produce Little Information. The Big Data will probably be much smaller than the original Data-set and the resulting information will almost certainly be much smaller.

And then of course there is everyone’s favourite Big Data; the Large Hadron Collider, now that certainly does produce Big Big Data but let’s be honest, there aren’t that many Large Hadron Colliders out there. Actually a couple of years ago; I attended a talk by one of the scientists involved with the LHC and CERN all about their data storage strategies and some of things they do. Let me tell you, they do some insane things including writing bespoke tape-drivers to use the redundant tracks on some tape formats and he also admitted that they could probably get away with loosing nearly of their data and still derive useful results.

That latter point may actually be true of much of the Big Data out there and that is going to be something interesting to deal with; your Big Data is important but not that important.

So I think the biggest point to consider about Big Data is that it doesn’t have to be large but it’s probably different to anything you’ve dealt with so far.

Okay, despite the title; I don't actually think that VCE is Evil, certainly no more so than any other IT company. As we move to an increasingly virtualised data-centre environment; I believe that VCE does have something to offer to the market, the more vertically integrated a stack, the more chance that it is going to work within design parameters and with a reduced management footprint. 

Yet, I do have a problem with VCE and that is it is not consolidated enough; it's like some kind of trial marriage or perhaps some troilistic civil partnership. (And I have similar problems with the even looser Flexpod arrangement with NetApp/Cisco/VMWare.) 

As a customer; it seems that I am expected to make a huge commitment and move to an homogeneous infrastructure even if it is some kind of 'virtual homogeneity'. Yes, there are management benefits but the problem with both vBlock and Flexpods is what happens when the relationship founders and fractures? What happens to my investment in consolidated management tools to support these environments; where is the five, ten year roadmap? And where is the commitment to deliver? Who gets custody of the kids?

Are the relationships going to last more than one depreciation/refresh cycle? Perhaps the problem is that the evil is not consolidated enough? Or am I just cynical in expecting the relationship to fail? I would say that the odds are that one of them will fail, you?

Perhaps Cisco/EMC/NetApp should de-risk by all merging!