Storagebod's Blog

Important Announcement

This is a very important announcement; there will be #Storagebeers on Wednesday 7th October following the first day of the IP Expo. IP Expo is being held 7th-8th October at Earls Court, London. It has a rather good list of keynote speakers and should be one of the better events in the UK this year.

Venue for drinks has yet to be finalised and any suggestions would be welcomed. Vendor sponsorship is always appreciated at such events but it will be a vendor neutral engagement i.e no fighting!!

And beer should never be virtualised or thin-provisioned!

I'll certainly tweet the venue once it has been agreed!! I look forward to seeing as many of you as possible!

Economic Truth

Steve Duplessie posts on Cloud Economics and especially the economics of Cloud Storage, 20 TBs of storage from Amazon's S3 cloud will cost you $36,000 a year and that doesn't necessarily compare especially well with purchasing your own array. So do the economics of the Cloud storage scale, especially when we start talking about the 100s of terabytes of storage which many enterprises consume?

The problem is we don't really know how much it costs us per terabyte in total! There are no good published TCO models for storage; this is why the initiative started by Nick Pearce and Ian are so important. Go and read their blogs here and here on building a TCO model for storage; let's get this thing crowd-sourced and perhaps we can make the TCO costs of storage a little less cloudy.

And then we can start on the model for Cloud TCO...public vs private etc!!

Many Solutions, Many Problems...

Instead of focusing on product, more and more of us are concentrating on solutions; products don't solve business problems, solutions do; I like this entry on Eigenmagic which looks at the differences between products and solutions.

But concentrating on solutions can be dangerous because next thing you know you have a data centre full of point solutions and a support nightmare. Many vendors like to try and package their solutions as black-box type solutions which require their own OS builds, own hardware, do not support virtualisation, do not co-exist well with others. 

Software appliances which run on industry-standard hardware may well be the answer but even these often have stringent requirements. I have come across software appliances which specify that they only support certain types of server underneath; we need to move away from this and to very high-level requirements i.e how much memory, how much CPU and how I/O is required to support the application; not it requires a specific HP server. 

Solutions are great as long as they are not used as a way to sell me expensive OEMed hardware which I can buy off the shelf from half the cost. And you may claim that the TCO will be lower; let me tell you, often the TCO goes up because I still have to manage the security patching, multiple support contracts, non-standard form-factors etc, etc.

You Gotta Love Larry

You really have to love Larry Ellison of Oracle; if there is one thing that you cannot acuse him of and that is being a shy retiring violet. But his latest pronouncements on becoming the new IBM; not the IBM we have today but the monopolistic (although very successful) monster of Thomas Watson Jr's day.

The IBM which manipulated the market, the big arrogant beast? Do we really want this to happen? Does anyone really want the IBM of the past back? I don't, do you? Perhaps he thinks that today's crop of ITers don't remember that IBM gouged the market with their prices for years. Is this the message that he is really sending out!

However to be honest, I don't think he stands a hope in hell of becoming the behemoth; there is too much competition out there and that in my mind is good.

Happy Blog Day

This blog is now a year old; who'd have thought it!!

It seems to have become part of the fabric of the many storage bloggers and it's certainly become part of the fabric of my life. I started the blog as a counter to many of the vendor blogs I see out there; trashing each other products but often not in a useful way.

I wanted to represent the customer's view; especially the larger customers, those with multiple arrays and multiple petabytes of data; those who have to struggle with management tools which didn't (and still don't) scale; those who have to deal with application architects who have no idea about what their applications do; those who don't have time to tune each individual LUN etc. 

I hope I have done so; I certainly feel that I've had some success and I know that some vendors are taking notice. I wish I was a 'Force for Change' but I think I probably more a 'Little Nudge for Change' but that is all good!

I like to thank my many readers and commentors; I like to thank all those who have linked to my blog either in posts or part of your blog-rolls. It's really quite odd when people in the industry who I have admired and read for years start linking and quoting me but hey, it's very cool.

I'd also like to thank Stephen Foskett for asking me to be part of the Gestalt IT team; that was a great honour and I look forward to collaborating on more posts with you guys!

Obviously I intend to carry on with the blog; calling FUD when I see it, hopefully talking about some of the cool stuff I'm currently involved in and generally supporting the customer point of view. And I keep meaning to do some more personal stuff; perhaps some book reviews and more about my home data centre.

And if you are ever in London; give us a shout, I'm always happy to have a beer...

I spy FUD

When I see things which are blatantly FUD; I get really annoyed! And every now and then, I am going to call it! Hu posts on SVC, it's always a bad start when you dedicate an entire article to a competitors product, it can never end well.

And there is a big, whopping piece of FUD in the article and I quote Hu here!

"I asked why they were converting from Brocade to CISCO, and their answer was that they were planning ahead for FCoE. I pointed out that the SVC may work well in a FC SAN, but may have to do a lot more work to guarantee delivery of packets in a lossy network like Ethernet. The SVC will have to be reworked in order to work in a non FC environment, where packets may be dropped when the network gets congested.   Since the USP V does its virtualization in the storage controller, we would be able to convert the front end ports to FCoE ports and not do a major revision of the storage virtualization functions."

Yes, you can if you are insane run FCoE over non-DCE; you can run it over 1 GbE if you insist (I have for experimentation purposes at home) but the whole point of running FCoE is that you run it over DCE which is lossless; it implements flow control!

FCoE is fibre channel! IBM are not going to support FCoE over anything else apart from DCE! FCoE is fibre-channel! Perhaps Hu has confused iSCSI with FCoE?

So is Hu going to go back to that customer and apologise? What he should have done was said, why are you converting to Cisco to get FCoE? Brocade has a roadmap to support FCoE, you may have good reasons to go to Cisco but FCoE at this point probably should not be the driver!

Backup Bod

At the moment, I am an in the unusual position to be considering building a greenfield backup/archiving solution with none of the legacy considerations of the past. I do not have to think about migrating  existing policies into the new environment.

This gives me the fairly unusual position of being able to consider how to do things properly. Although key technology positions have been made i.e what tools I have available and some key policy decisions have been made i.e the archive is forever (whatever that means); much is still up for grabs.

So I hope to be able to lay some long-held sacred cows to rest, especially in the arena of back-up; instead of focussing on back-up, I want to focus on restore and how we restore.

Like security, I want to back-up up just enough so that I can restore what needs to be restored reliably; this means that areas like build policies should be taken into account. If you are never, ever, going to do a bare-metal restore; why back-up all those operating system files etc? Do I really need 4000 copies of Redhat backed-up? We are putting in place automated build-tools and application repositories; it will be quicker to restore using these than to do a traditional restore.

So identifying what needs to be backed up is going to be key; I think I've got buy-in from the sysadmins and the dbas to help with this. We are not going to sit and say that it's too hard; that's lame!

Also, from day one; I'll shall be enforcing zero failure tolerance; I've seen what happens when you tolerate a certain number of failures and the insidious nature of this. You build an air of complacency which eventually bites you; either with data-loss or the sheer tedium of producing S-OX reports about the failures. By taking a zero failure tolerance from day one; hopefully when this environment is running 10s of 1000s of back-up jobs, management will not be the horrendous nightmare that it is in other environments.

Oh, I do have another advantage; the whole environmnet is being designed with back-up in mind, it is not an adjunct, it is a key delivery.

NetApp Reveal Cisco's Storage Incompetence

Peter Perrault, a NetApp marketing tweeted this link to some NetApp marketing fluff about about Cisco's use of NetApp storage; there is a very scarey statement in the PDF which if true makes me wonder about Cisco as a credible partner in the world of storage.

From the article;

"A few years ago, faulty disk drives on the development team’s underlying enterprise storage systems were a nuisance for Cisco IT, as Storage Domain Design Architect Rich Harper recalled. But, it wasn’t insurmountable until double-disk drive failures in the same parity stripe occurred twice in six months, resulting in the loss of hundreds of days of development work. While Harper readily acknowledged the drive issues were an industry problem that all vendors were experiencing, he admitted, “The experience still left a bad taste in our mouths.” "

Can anyone else see how scarey this is? A double-disk failure caused the loss of hundeds of days of development work? Have these people not heard of back-ups? Are Cisco still relying on parity to protect against data loss? Or is this just pure marketing hyperbole?

Look guys, RAID is not a substitute for back-ups! Snaps, clones and whatever else are not substitutes for back-ups. You need to get the data off the primary storage to another physical location/device. BackUp is not exciting but you need to do it.

Live Forever

No not my favourite Oasis track, no it's something which I've been thinking about and a subject I've touched on a few times; once you've deployed a technology, how do you get out of it? Do you get out of it? And what impact does virtualisation have on this.

How many of us are running or are aware of business critical applications running on hardware which is no longer supported by the vendor? And the reasons? Often the reasons are that the application only runs on a particular operating system which is no longer supported and will not run on current generations on hardware.

Virtualisation may well allow you to refresh the hardware; for example if you insist in running applications under DOS; pretty much any of the x86 hypervisors will run DOS. This will allow you to run that business critical application on DOS for the forseeable future and will allow you to continually refresh the hardware underneath it.

Well, it will until the Hypervisor vendor calls time and decides that they no longer want to certify the hypervisor with DOS x.xx; oh well, what do you do? Obviously you shrug your shoulders and now run a back-level hypervisor with an unsupported Operating System which is running an application which by now, no-one has a clue on how it works!

Oh, you've migrated the application into a Public Cloud? Well, it didn't need much in the way of the resources and suited the Cloud perfectly. And now your Cloud provider has said that they are no-longer supporting or even allowing DOS instances to run; oh heck and now you can't get the hardware/software to run your application locally. 

So although virtualisation will allow you to get away with running legacy apps for a long time; don't assume that this means that they can 'Live Forever'! Virtualisation is not an excuse for not carrying out essential maintenance and keeping your estate up-to-date.

*that's 'Bring It On Down', just in case you were interested!

The Cry of the Grump!!

A slightly plaintiff and frustrated tweet from grumpystorage aka @ianhf inspired this blog as did replies from various of the storage twitteratti.

Ian cries the lonely cry of the infrastructure architect

'Application architects - please know & understand your infrastructure requirements. Infrastructure isn't magic or telepathic!'

And of course, IaaS and PaaS are then held up as potential solutions to the problem. I've got bad news; they're not! Cloud Architectures are neither magic or telepathic, they still rely on application developers and architects understanding their infrastructure requirements.

Now we, in the infrastructure world can help them by educating in the questions that they both need to ask and also need to answer. Questions like, what availability does your application require? What is it's throughput? Have you designed an application which scales either horizontally or vertically?  Infrastructure Architects have always had to work in a consultative manner and drag the requirements from the Application teams.

All providers of infrastructure need to understand the importance of this; nothing will destroy the credibility of Cloud Architectures quicker than the inappropriate and unplanned deployment of applications into the Cloud.

I think there is a temptation that we represent the Cloud as Magic Smoke where things happen but just look at the backlash when Gmail goes down? Fortunately for Google; people have become so reliant on Gmail, beyond a bit of moaning, few people will really change but a Corporate taking their first steps into the Cloud who loses a key application or a key application under performs may well be more unforgiving. 

Push button deployment without the consultative input of the Infrastructure Architects guiding could end up in a world of pain and it won't be the application at fault, it will be the Infrastructure.