Storagebod Rotating Header Image

gestaltit

Assault on Benchmarking

Nov 9th, 2010
by Martin Glassborow.
7 comments

I've been thinking a bit about benchmarking and benchmarketing; pretty everyone agrees that SPC is a very poor representation of real world storage performance but at the moment, it's the only thing that most of the market supports with one key exception. So I thought I'd come up with my own, so let me introduce the SSAC.

Storagebod's Storage Assault Course


This is a multi-part benchmark and is supposed to reflect the real world life of an storage array. You may bid what you like but all costs including the costs of team who support and run the benchmark must be declared.

1) You must specify an array to run the SPC benchmarking suite; this array must be ordered through the normal ordering process.

2) A short period of time prior to the delivery of the array; you will be informed that the workload for the array has been changed to another random work. However, the delivery date agreed must still be met; so any changes to the configuration must be made without impact to the delivery.

3) You must carry out an audit of the existing SAN environment and ensure that the installation of your array will not cause any impact to the already running environment. In the course of the audit, you will discover that pretty much the whole of the environment is down-level and not currently certified against your new array. You must agree any outage required to upgrade the new array; this may involve you auditing every single server and switch to ensure that key variables such as time-outs on multipathing are set correctly.

The day before installation, you will discover a dozen servers which you were not aware of and at least three of these will be running operating systems which are so far out of support that no-one is sure what is going to happen.

You will be responsible for raising changes, carrying out risk assessments and arranging site surveys, traffic plans and any other supporting tasks.

4) On day of delivery, you will discover that the array is to be installed in another part of the data centre which neither has power and the array will probably fall through the floor crushing the secretarial team below.

You will be responsible for arranging the remedial works and rescheduling all the changes required.

5) Once the array is installed, you will be responsible for powering it up and installing the initial configuration.

6) A Major Production Incident is declared and you will be responsible for convincing everyone that it is not your new array which caused the problem.

7) You are finally allowed to run your first benchmark.

8) You discover that all of the SAN switches have been set to run at the wrong speed and you need to raise changes to correct this.

9) You are allowed to re-run your benchmark again but halfway through your benchmark a Performance Major Production Incident is declared and you are responsible for first proving that it is not your array which caused the problem and then fixing the Incident which is nothing to do with the work you are carrying out.

10) You manage to successfully run your benchmark. 

11) You receive an urgent change request and you must find space on your array for a new workload; this workload has completely different performance requirements but you will told to JFDI.
12) You run your second benchmark.

13) You receive an urgent call from the original application team; apparently they mis-stated their requirement and they are servicing twice as many requests as originally thought. You must expand the environment as an urgent priority. 

14) Through the normal ordering channels, you must arrange any necessary expansion to the current environment. 

15) You must carry out any necessary reconfiguration without impact to the running workloads or agree any downtime with the business to allow you to carry out the necessary reconfiguration.

16) You will recieve an emergency technical notice from your vendor support teams; a fix must be implemented immediately or the array will catch fire (possibly).

17) You must re-audit the environment and carry out any remedial work on servers, switches and applications to support the new code level.

18) You will be informed that the system must now have a DR capability due to government regulation.

19) Carry out any design and certification work to provide DR capability. The order for the DR capability will be held up in procurement but you still need to implement within the government timescales or face severe financial penalties.

20) Re-benchmark the entire environment showing the impact of replication on the environment.

Explain to a non-technical person that the speed of light differs in fibre to that of that in vacuum. Explain in a louder voice that no, the speed of light is not something which can be overcome and no, rival company X has not overcome despite what they might say.

21) A third workload will be detailed; this must be shoe-horned onto the array at no extra cost but with no impact to the additional applications.

22) Benchmark again to prove this case.

23) You are summoned to a meeting to explain and justify your array to a Senior Manager who has just been bought a three star lunch by a rival vendor.

24) You will experience a failure on your array; record how many logs and diagnostics that the vendor support team (and no cheating, you must use the customer route) ask you before agreeing to replace the failed disk.

25) You will be informed that Group Audit have looked at the application that you provided DR for and decided that actually it was exempt, hence you have wasted time and money.

26) Plan to repurpose DR array for a new workload requirement. 

27) A new capability is announced and will require a major firmware upgrade that may require downtime but your support team are not sure. Carry out the risk analysis and plan for upgrades.

28) You are outsourced!

At this stage please disclose:

1) Total Staff costs including time-off for stress related illness

2) Total Capital Expenditure

3) Total Downtime due to upgrades and other non-disruptive activities

4) Any other expenditure due to work required to existing SAN environment and Server infrastructure

And those performance benchmarks, throw them away; you didn't think I was actually interested in them!?

Manage Data Not Storage

Oct 10th, 2010
by Martin Glassborow.
5 comments

With Automated Tiering solutions now rapidly becoming de rigeur, well in announcement form anyway; perhaps it's time for us to consider again what is going to go wrong and how much trouble the whole thing is going to cause some people. 

Fully Automated Tiering solutions are going to cause catastrophic failures when they are deployed without understanding the potential pitfalls. I keep going on about this because I think that some people are sleep-walking into a false nirvana where they no longer need skilled people to manage their infrastructure estates; in fact, automated solutions means that you are going need even more skilled people; you will probably need less monkeys but you are going to need people who can think and learn.

Fully Automated Tiering solutions cannot be fully automated and be safe for most large businesses to run; they work on the premise that data gets aged out to slower and less performant disk, this reduces the amount of expensive fast disk that you require and can save you serious money. So why wouldn't you do this, it's obvious that you want to do this, isn't it? 

Actually in most cases, it probably is; unstructured file data almost certainly is safe to shift on this basis, actually most unstructured data could be stuck on the lowest tier of disk from day one and most people wouldn't notice. In fact you could write most of it to /dev/null and not that many people would notice. 

But structured data often has more complex life-cycle; accounting and billing systems for instance, the data can be very active initially eventually entering a period of dormancy when it basically goes to sleep. However, then something will happen to wake it up; periodic accounting runs, auditing and then the data will be awake and almost certainly required pretty sharpish. If your automated array has moved all the dormant data to a less performant tier; your periodic accounting jobs will suddenly take a lot longer than expect and potentially cripple your infrastructure. And that is just the predictable periodic jobs.

Automated Tiering solutions also encourage poor data management policies; actually, they don't encourage but they certainly reinforce a lot of bad practise which is in place at the moment. How many people have applications which have data which will grow forever? Those applications which have been designed to acquire data but do not age it out? Well, with Automated Tiering solutions, growing your data forever no longer attracts the cost that it once did; well, certainly from a storage point of view and it might even make you look good; as the data continues to grow, the amount of active data as a percentage of the estate will fall and hence the amount of data which sits on the lower tiers increases and you could argue that you have really good storage management policies in place. And you do!

However, you have really poor Data Management policies in place and I think that one of the consequences of Automated Tiering, is the need for Data Management; your storage might well be self-managing, your data isn't. If you do not address this and do not get a true understanding of your data, its life-cycle, its value; you are looking down the barrel of a gun. Eventually, you are going to face a problem which dwarfs the current storage-management problems.

What kind of problems?

  • Applications that are impossible to upgrade because the time taken to upgrade data-in-place will be unacceptable.
  • Applications that are impossible to recover in a timely fashion.
  • Application data which is impossible to migrate.
  • Data corruptions which down your application for weeks

And I'm sure there are a lot more. It's hard enough to get the business to agree on retention periods for back-ups; you need to start addressing Data Management now with both your Business and your Application teams.

The good news is that as Storage Management becomes easier, you've got more time to think about it; the bad news is you should have been doing something about it already.  

Wize Up

Oct 8th, 2010
by Martin Glassborow.
6 comments

Some months ago I speculated on the future of IBM's storage roadmap; a post which I believed caused some consternation in IBM as it foreshadowed some of their recent announcement. I expect that over time even more of that entry's predictions will become fact. For what is basically a packaging exercise, the v7000 is actually an interesting announcement in that it shows that IBM do want a piece of the storage pie and they are going to use their own products to do so.

I believe that the v7000 will cause IBM some real problems around the XIV message; with the new GUI, the v7000 is pretty much as easy to manage as an XIV and realistically, that was XIV's biggest selling point. The v7000 is more flexible, potentially more scalable and more performant that the XIV and I wonder how much of an influence that it's development had on Moshe's departure. I like to tease IBM that Barry Whyte is the new Moshe; he was brought up on the mean streets of Glasgow and no one crosses a WeeGie.

There are some features missing at launch which are interesting; the scalability for example seems to be being constrained for some reason. Certainly SVC can support an 8 node cluster at the moment and Barry has stated that there are no real issues going beyond this. So why doesn't the v7000 not have clustering from day one? Perhaps to allow XIV some breathing space to get the long roadmapped clustering out of the door. A cluster-enabled 7000 would be a very interesting prospect and I wonder whether we'll see a v9000 which offers clustering?

v7000's integration with VMware does at first glance appear to be lacking; at the announcement, I don't think VMware even got mentioned but v7000 shares all the current SVC/VMware integration points. However I do believe that IBM need to up their game on the VMware integration.

No compression or dedupe; this isn't suprising really as IBM haven't have StorWize for that long although it's long enough to for StorWize to become the storage brand; certainly in the mid-range space. But I'd expect to see announcements around compression and dedupe in the next twelve months, I think IBM will motor on that one with their big focus on Storage Efficiency, it's really obvious that they intend to do so. I'm pretty sure I saw Steve Kenniston sitting in the audience at the v7000 launch, I'd expect him to be on stage next time.

There's a few really nice little touches which show that IBM are listening to customers and understand some of the day-to-day pain of the Storage Admin; for example, the v7000 comes with a USB key which can be plugged into a PC and all the initial configuration can be built there without the need for a serial cable. Once you have finished the configuration; plug the key into the v7000 and it'll configure itself. So many laptops these days don't come with serial ports, this shows some real thought on IBM's part.

SONAS integration; will we see a unified interface from IBM to enable SONAS, SVC and the v7000 to all be managed from a common simple GUI? I know NetApp will jump up and down if anyone was to call that Unified Storage but I can see IBM doing something like that. There's probably little reason why SONAS and SVC cannot co-exist on the same physical hardware. SONAS will certainly get Storwize integrated; I'd expect a rapid rebrand of the SONAS product to bring it in line with the Storwize branding. 

OEM relationships with LSI, NetApp and DDN are probably going to become less crucial to IBM; IBM will have control of their own storage destiny again and I fully expect the number of OEMed products to reduce with the LSI relationship probably the first under serious pressure. 

And IBM do amuse me; if EMC or NetApp had launched the v7000; there would have been fireworks, orchestras and ticker-tape parades; we would have had a teaser campaign and the whole works. This was all rather understated, there were bold statements made but there wasn't the chest-thumping that we have come to expect from storage announcements. 

Agile IT leads to Agility?

Oct 4th, 2010
by Martin Glassborow.
No comments yet

Leadership, management and agility are becoming important watchwords in the role of IT delivery and it is these three concepts which need to drive any IT organisation forward over the next decade or so. It is the third of these that is probably the most important.

Leadership and management can almost be interchangeable when an organisation is in a steady-state and lets be honest, most IT organisations have been in some kind of semi-steady-state for the last decade. IT Delivery became very procedural in a glacial sort of way.

Radical change in many IT organisations is simply shuffling the cards around without adding anything else in; perhaps moving what already is being done to a third party. In fact, arguably the trend to outsource can be pretty much attributed to the steady-state of the organisation. IT became something to be managed as opposed to something to lead. IT leaders who want to change things rapidly and quickly often find themselves at conflict with their own internal organisations; it becomes easier to accept the status-quo as opposed to embracing the change. 

Arguably, IT's success in becoming ubiquitous in many organisations has become it's biggest blocker to change; IT has become so large and so important that it's ability to respond to the business has become seriously compromised by this importance. Look at the sheer amount of work it takes to roll out a new version of Microsoft Office to an organisation? Okay, it is a moot point whether upgrading Microsoft Office buys very much to an organisation but lets look at the number of corporates who are still running with huge amount of risk because changing from IE6 to a later version is allegedly so complex. 

This apparent complexity has lead to an inward focus on the delivery of IT and paradoxically this focus on the delivery of IT has significantly damaged it's delivery. It has become more important to the manage the delivery than to deliver. 

However, we have already seen changes in the way that applications are being delivered and developed; agile development techniques are probably used for more than 50% of our applications internally. I suspect that this is an industry trend and your mileage will certainly vary, yet I remember when I first ran an agile development team nearly ten years ago that this was considered to be extremely unusual and that the 'Agile Manifesto' was some kind of hippie movement. 

The move to agile development techniques has been remarkably quick compared to say that of take up of object orientated techniques which can only be attributed to that there is something right and easily implementable about the techniques.  You can find the Agile Manifesto here.

Agile development techniques have some key points that I believe point to the direction that all IT organisations need to take.

  • Customer involvement in writing the stories which are to be delivered are key; every successful agile development has customer involvement at it's heart. Don't hide your people away from the Business; introduce them slowly if needed but stop making every communication between the IT organisation and the Business a management function.
  • Leaders can develop without been forced into some management cookie-cutter mould. A great developer gets to work with many different developers and gets to disseminate their greatness but there is no pressure on them to become managers or team-leaders. 
  • Teams should be allowed to organise themselves and define their own structures. They will often surprise you and if you allow them to break down organisational silos, you will find that their effectiveness is significantly increased. 
  • The acceptance that no plan survives contact with the enemy. This does not mean that there should be no plan but there needs to be flexibility and options. 
  • Simplicity and the art of doing the minimum to deliver is essential. For a long time I have preached the concept of 'Constructive Laziness'; do nothing which does not need doing and do what needs doing in the easiest manner. 

 How many organisations are ready to embrace this? I think this where the real difference between Leadership and Management will show, to implement such principles means taking up the mantle of Leader and dropping some of the comforting tropes of the Manager.  

Managing Migration Makes Martin Mad!

Aug 10th, 2010
by Martin Glassborow.
3 comments

So we can thin-provision, de-dupe and compress storage; we can automate the movement of the data between tiers; now one single array may not have all these features today but pretty much every vendor has them road-mapped in some form or another. Storage Efficiency has been the watch-word and long may it continue to be so. 

All of these features reduce the amount of money that we have to pay for our spinning rust; this is mostly a capital saving with a limited impact on operational expenditure. But there is more to life than money and capital expenditure; storage needs to become truly efficient through-out its life cycle; from acquisition to operation to disposal. And although some operational efficiencies have been realised, we are still some distance from a storage infrastructure that is efficient and effective throughout its life-cycle.

Storage Management software still arguably is in its infancy (although some may claim some vendor's tools are in their dotage); the tools are very much focused at the provisioning task. Improving initial provisioning has been the focus of many of the tools and it has got much better; certainly most provision tasks are point and click operations from the GUI and with thin and wide provisioning, much of the complexity has gone away. 

But provisioning is not the be all and end all of Storage Administration and Management and it is certainly only one part of the life-cycle of a storage volume. 

Once a volume has been provisioned, many things can happen to it; 

    i) it could stay the same

    ii) it could grow 

    iii) it could shrink

    iv) it could move within the array

    v)  it could change protection levels

    vi) it could be decommissioned

    vii) it could be replicated

    viii) it could be snapped

    ix) it could be cloned

    x) it could be deleted

    xi) it could be migrated

And it is that last one which is particularly time-consuming and generally painful; as has been pointed out a few times recently, there is no easy way to migrate a NetApp 32-bit aggregate to a 64-bit aggregate; there is currently no easy way to move from a traditional EMC LUN to a Virtual Provisioned one; and these are just examples within an array. 

Seamlessly moving data between arrays with no outage to the service is currently time-consuming and hard; yes, you can do it, I've migrated terabytes of data between EMC and IBM arrays with no outage using volume management tools but this was when large arrays were less than 50 Tb. 

We also have to consider things like moving replication configuration, snapped data, cloned data, de-duped data, compressed data; will the data rehydrate in the process of moving? Even within array families and even between code levels, I have to consider whether all the features at level X of the code are available at level Y of the code. 

As arrays get bigger, I could easily find myself in a constant state of migration; we turn our noses up at arrays which are less than 100 Tb which when we are talking in estates which are several petabytes is understandable but moving 100s of Tb around to ensure that we can refresh an array is no mean feat and will be a continuous process. Pretty much once I've migrated the data, it's going to be time to consider moving it again. 

There are things which vendors could consider; architectural changes which might make the process easier. Designing arrays with migration and movement in mind; ensure that I don't have to move data to upgrade code levels; perhaps consider modularising the array, so that I can upgrade the controllers without changing the disk. Data-in-place upgrades have been available even for hardware upgrades; this needs to become standard. 

Ways to export the existing configuration of an array; import it onto new array, perhaps even using performance data collected from existing array to optimise layout and then replicate the existing array's data to enable a less cumbersome migration approach. These are things which will make the job of migration more simple.

Of course, the big problem is…..these features are not really sexy and don't sell arrays. Headline features like De-Dupe, Compression, Automated Tiering, Expensive Fast Disks; they sell arrays. But perhaps once all arrays have them, perhaps then we'll see the tools that will really drive operational efficiencies appear.  

p.s I know, very poor attempt at a Tabloid Alliterative Headline

With Abundant Good Cheer

Aug 3rd, 2010
by Martin Glassborow.
2 comments

As we move from a time of IT as a scarce and controlled resource to a time where IT is seen as an abundant and easily available resource; we need to consider what this means to us in Enterprise IT. Is abundance a good thing and a power for good or does it bring with it issues? 

Lets look at a couple of quotes from Clay Shirky's book 'Cognitive Surplus'

'Abundance breaks many more things than scarcity does. Society knows how to react to scarcity' 

'Abundance is different: its advent means we can start treating previously valuable things as if they were cheap enough to waste, which is to say cheap enough to experiment with.' 

Now Shirky is talking about publishing, information and how we consume/create media but some of his thinking strikes a surprising amount of resonance as to what is going on in Enterprise IT today and how it is beginning to change.

In Enterprise IT, we know how to control access to resource, how to ration resource in such a way to ensure that we always have some resource saved and preserved for a rainy-day. But as we move to a world where resource is abundant; our models have to change. 

Perhaps we need to move from beyond the 'gate-keeping' mode of operation that many of us are used to where our job was only to let people into our environment if they met our very stringent criteria to a mode of operation more akin to one of the accommodating host where everyone is welcome as long as they do not impact any of the other guests.  

Enterprise IT is probably not yet at the stage where it can be considered to be cheap enough to waste but perhaps we are on the cusp of this? Or perhaps we need to be considering what needs to be done to get to that position. The Amazon EC2s of this world certainly allow experimentation at a very low cost financially. And arguably more important, the time to implement is much quicker. 

This may drive a culture of 'try often, fail a lot, succeed rarely'; as in the world of publishing, the average level of application quality may well be driven down and it will be important that we build infrastructures which can cope with failures. Badly behaved applications will need to be managed, we will need ways of spotting a badly behaved application quickly and like the good host, gently encourage it to behave better with the eventual sanction of kicking it out. 

Virtualisation can help to ensure that applications behave within limits but applications can fail in many ways and we will need to ensure that we have the tools to tidy up afterwards. This will limit the waste but allow our users to experiment and try things; yet again, like a good host, we tidy up after our guests and recycle or re-use what we can.

The IT Infrastructure Manager as 'Mein Host'…no more the grumpy chap in the corner but the genial host ensuring that the party runs smoothly yet with a swing. 

Infrastructure is Software

Jul 9th, 2010
by Martin Glassborow.
No comments yet

Chuck has just written a blog which was very similar to a blog that I was working and I agree with a lot of what he says but I'd take it a lot further and there are some interesting conclusions and potentials along the way which could open the market for interesting innovation going forward.

Chuck talks about storage as being software, go read his blog; there's little I would disagree with there at all; well, until he starts talking about EMC products! However, I would go much further and suggest that we are getting to the stage where all infrastructure at a very real level is becoming software. Although I am not totally enamoured with the Intel-focussed monoculture, it has allowed a common hardware platform and it is flattening the playing field when it comes to hardware differentiation.

In fact, to differentiate your hardware is going to become increasingly expensive and hard, so why bother? Yes, there will be edge cases where hardware differentiation will be a key USP but in 90% of all use-cases; an Intel box assembled from bog-standard off-the-shelf parts will be good enough. 

If we then factor in pervasive virtualisation in the data-centre; we have a platform which has become pretty much standardised and commoditised. I would like to see more 'standardisation' in the virtualisation arena but it's not that bad at present and you really do not have that many choices.

So this has some interesting results; it lowers the cost of entry for new players in the market, if they no longer have to spend time developing a hardware platform and packaging their infrastructure product as a device but simply as a 'soft appliance'; they can get it out there a lot quicker. If they can now rely on the virtualisation layer providing them with a common way of accessing hardware services; they can develop a lot quicker and they can try things much faster. The cost of failure is a lot less; it also allows integration with other types of infrastructure to be tested without a lot of expense; this is a plus for both the developer but also for the interested Infrastructure specialist.

The speed to market is greatly enhanced and they can get it front of idiots like me who will download the appliance and have a play and it's not just storage appliances. There are products like Traffic Squeezer which do WAN Network Traffic Acceleration; there are more open-source router projects than you can shake a stick at. 

I am slowly building a virtual Data Centre out of open source or at least free products; I want to see how far it would be possible to get. But I'm not suggesting that anyone would do this for real today, although I can see some Cloud providers having a really good bash at it. This approach probably would not make sense for most companies as a complete strategy but as part of a strategy, it may well be worth considering. There are large companies out there who invest in start-ups simply to develop stuff for them to use internally; the advent as 'infrastructure as software' without a huge investment in tooling up to build hardware means this a very viable approach for the biggest companies. 

Google do it, Amazon do it but often you hear the comments, 'Well they employ very clever people, so it's easier for them!' Well, don't you employ clever people? Or are you saying that all your employees are second rate.

It took me a long time to come round to the idea that commoditisation and standardisation could drive innovation at all levels; I now believe that it could. It's not just about more and more Web applications; it could drive a new wave of infrastructure innovation as well. 

This leaves some interesting conflicts on the horizon for companies like VMware; perhaps VMware might want to get into infrastructure appliances but that would lead them into direct competition with the Mothership. Infrastructure as software; interesting times.

Here's some links of things worth looking at or playing with, it possibly includes things which are not strictly infrastructure but are interesting anyway. Some are great, some not so great; some show great potential. 

Traffic Squeezer

Openfiler

Samba Ctdb

Vyatta

Amanda

OpenDedup

And of course, there is Ubuntu Server; which will let you build your own cloud for free; there are various ZFS-based storage appliances. You can build your own appliances as well, packaging up and integrating components in the way you want. 

One area where EMC have shown great foresight and that is investing in the vSpecialist team and building a team out of diverse specialities because as infrastructure becomes software; the cross-over between the infrastructure disciplines will become even more mandated. Now the vSpecialist team may be very focused on the 'EMC product set' but if I was an SI or another vendor playing in this space; I would be looking at doing something very similar in the near future. 

No Longer Functional

Jun 14th, 2010
by Martin Glassborow.
1 comment

Having worked in Corporate Infrastructure for many years, fighting the good fight and trying to get the enemy to conform to best practise and generally think beyond the next line of code that they are writing, I surrender! I throw the towel in!

I'd like to take an example without being too specific from my own experience; currently in the race to innovate, many corners are cut. Every screen whether it is a TV screen or the screen on a hand-held games device is now potential target for a product. 

Our developers build proof-of-concept systems on servers under their desks at best and often on desktops which might be laying around spare; proof-of-concepts are demonstrated and then proof-of-concepts are products. Cycle times for delivery of new product are often measured in weeks, not the months and years of the past. 

No thought is made to non-functional requirements, the capability is all and it's now a product with paying customers who expect it to be up and running. In fact, the mention of non-functional requirements are enough to send customers running for the hills, they don't want to know. 

But of course, in reality we have to retro-engineer in all those requirements that are required to make it a supportable service. And whilst we are doing this, our people are in a constant struggle to keep this system up. At times, our people do remarkable things in this battle and they should be commended for doing so. 

But there must be a better way than PCs under desks and developers acting like MacGyver to get a new service together? I think there is, I think it's a dynamic, scalable, on-demand infrastructure; call it Cloud, call it what you will. Users should be given the ability to throw-up an environment quickly and easily with almost no thought made to the availability, scalability requirements which will surely be required if the development is a success. 

Yes, some use is made of public Cloud but I think that pales into insignificance when compared to use of commodity hardware which is just lying about; this has been going on since the PC reared it's ugly head but as PC's have become more powerful with the ability to run server operating systems and especially with the rise of Open Source, every developer has the ability to build a 'production environment' without permission. 

Are they doing things in Cloud? Yes, they surely are but I suspect it is a more common situation for a infrastructure team to be presented with a skunk-works system built out of commodity and be told to make it live…..tomorrow. 

And it is then that the Cloud comes into play, it would be much better to have built an environment which allows developers the flexibility and agility that they require, having them work in an environment which can be promoted to a production environment rapidly. An environment which is as cheap and as flexible as the development teams believe that their PCs are but gives the infrastructure teams the supportability that they require.

Non-functional requirements whether we like it or not are just bolt-ons; after-thoughts. They are seen as the obstacles which stop customers gettting the new services which they require, it's time to move on. I still believe that developers should pay attention to non-functional requirements, I still believe that systems should be designed with availability, scalability, recoverability etc in mind but I think that this is now needs to provided in such a way that it is transparent to all.

Of course this transparency should be completely transparent and open allowing rapid migration between providers, private and public…but that is another story!

They know Jack….

Jun 4th, 2010
by Martin Glassborow.
8 comments

After latest 'twit-piss' mostly between NetApp and EMC, although HP also chimed in, I posted a tweet which most people seemed to agree with and it got retweeted a lot.

'Let me summarize NTAP know shit about EMC who know shit about IBM who know shit about HDS who know shit about HP who know shit about Oracle!'

But sadly, I don't think it's true at all! I think really goes something along the lines of

'NTAP pretend to know shit about EMC who pretend to know shit about IBM who pretend to know shit about HDS who pretend to know….'

Well you get the gist of it. 

Or perhaps

'NTAP marketing know shit about EMC, whose marketing know about IBM whose…'

Well you get the gist again!

You see there's a big game going on here and actually it's not doing us the customer any particular favours; you see most of the big vendors know alot about their competitors kit, they just can't admit it. I, suspect like most of my readers, have visited large vendor facilities and have been given the full on guided tour; often on these tours, one is taken to the interoperability lab. What's in in the interoperability lab? Well, just about every flavour of competitive kit going. All in the name of testing interoperability but are you really telling me that more doesn't go on? Are you really telling me that performance tests are not run? Are you telling me that the kit is not put through the same type of torture tests that their own kit is put through and that the results are not pored over? 

Frankly I don't believe it! So why don't we get to see the results? Funny isn't it!? 

Perhaps it's just a Mutually Assured Disinformation pact!?

NetApp StorageGrid – More Questions than Answers?

Jun 1st, 2010
by Martin Glassborow.
3 comments

Okay, so NetApp have announced the NetApp StorageGrid product, however at the moment as far as I can see it is a simple rebrand of the ByCast product. I am not sure whether I was expecting anything more or whether I was expecting them to go dark with the Bycast product set for the time being whilst they work out what the hell they are going to do with it and at least come up with an integration strategy for the products.

Like many I wonder what this does to the whole Unified Storage message because NetApp now have two disparate storage product sets which are not integrated; I'm sure that they are briefing the integration message under NDA and if not, I'd ask why? But I'd interested to see what form the integration takes, will be it be at the tools level or will be it more fundamental integration more akin to OnTap 8. 

As NetApp have announced it under the Storage Management Software product set, it appears to be the former, certainly for the short to medium term and I suspect that NetApp are going to be very wary about going after a full blown integration or at least a public statement on it after the torturous integration of Spinnaker.

The data-sheet shows a software gateway layer sitting above the OnTap filers, well I think that's what it shows. It says that the front-end app server supports NFS/CIFS/HTTP(Restful) protocols communicating with the back-end storage via NFSv3; so theoretically, the back-end storage could be anything supporting NFSv3? But at present the data sheet actually shows a very restricted storage environment supported, namely FAS31x0 and FAS20xx and only SATA drives, so there seems to be no way of utilising your legacy storage in your StorageGrid. This is a little disappointing but no huge surprise, if EMC decide to 'support' third party storage with Atmos, it should be no biggie for NetApp to follow suit with StorageGrid; or perhaps vice-versa.

And as ByCast StorageGrid was resold by a number of other vendors, what is the ongoing roadmap for those customers who are running StorageGrid with different vendors storage behind it? Are these customer's going to be expected to move to NetApp storage?

Also from the diagram in the data-sheet;

'NetApp StorageGRID object-based storage solution brings the best of NAS and RESTful HTTP client access together'

Now I am willing accept that NetApp claim that the Filer product set are the best of NAS but to provide this 'best of breed functionality' with the StorageGrid product would imply a deeper level of integration than I can currently see or are they claiming that the Bycast product was actually the best NAS product out there? 

Is the Filer behind the Gateway being treated as pretty a dumb-share-only Filer and not leveraging any of the OnTap features at all? Even if this is the case, it is a cute move politically as the sales-team will not see any potential Filer sales being cannibalised by this new product. A problem that I believe that EMC might have had to deal with the Atmos product set.

One of the keys will be how NetApp present the integration; will they add StorageGrid to Ops Manager? It seems to make sense that you add it at that level because Ops Manager is the preferred way of managing multiple Filers and to get the most out of StorageGrid, there will be many Filers.It also keeps it in the realms of the familiar.

If it is seen as very much a different product it makes the Unified Storage pitch a little harder as it becomes mostly-Unified-Storage product which is a bit like being a little bit unique.

So this announcement asks many more questions than it answers! 

And one final comment, what is the difference between an Storage Grid and a Storage Cloud? Is it an Object Cloud or an Object Grid? Does the Object Cloud live in the Storage Grid?? 

← Earlier Posts