Thursday, 28 January 2010

Foggy Computing

So... this term cloud computing is being bounced around, alliances springing up everywhere and apparently there is a paradigm shift to this new cloud services model... but you know what, i think it should be called fog (or foggy) computing

Why - well reasoning goes something like this:
  • There is a total lack of use cases, yep SaaS, IaaS and such terms have been bonded around but where is the detail
  • Management is being spoken about as if you can just wave your hands and suddenly you get a compute service delivered - but really, where are the overlaying / orchestration management tools or in fact a list of those which could be used
  • Technical ratification of all of the major players? oops- that’s not there either (believe it or not – oracle does account for something like 60% of my estate – so I would like to be able to use whatever I deploy in conjunction with this tool)
  • If I deploy this nice new shiny cloud along with tools – i now sit in the middle of even more tool sets rather than consolidation - I can’t get rid of my existing tool set as i still have to manage Sparc / AIX / HPUX resources and now i am getting additional toolsets thrown at me with no roadmap or view into how I am going to solve this.
  • Open API's / ways of integrating.. you know what XML is a great way of letting me "do stuff and manage" to a compute environment but i still need something to orchestrate this... i am starting to feel that open api's is a new way of the vendors saying that the orchestration bit is just just a little to hard and leave it to the end-user... This is a fine approach – but also suggest a way forward / management framework along with tools.
  • Overstated "easy to do" configs... A number of these have been presented at very large forums, an example being Virtual Hosted Desktops bounded around as a no-brainer... I personally have just been involved with / at the back end of a significant deployment - and it has been by far, one of the most difficult things i have done (if you want some details and guidance - please shout) – don’t buy this as being easy...
  • Alliance's, so i am not sure what is going on here... I have alliances, new partner agreements and all sorts of stuff spinning up – its coming out of my ears to be honest... If you don’t have an alliance on the way, apparently you are “behind the times....” – but what do they really mean??? Even basic interoperability sheets are yet to be fully populated, along with application & ISV support.
  • Go to market model... Is there really a go to market model, other than loads of salesmen trying to sell me bits of stuff that they don’t understand? In the worse case I have actually had someone come up to me, and say - do you want to buy a cloud... I mean... come on vendors - please sort this out...
  • And by the way - when you come and sell this stuff to me, I really don’t expect to tell you how your solution is being sold, how an alliance is being formed and what you can and cannot do with the infrastructure - surely that’s your job – (and before anyone asks - yes this did really happen!)
What is starting to arrive is some pretty smart compute platforms (and I use this in the broadest meaning of the term (inclusive of CPU / RAM / Network / storage etc) but at this time it is just a bunch of stuff that needs gluing together – and lots of people writing operating models around this kit...

Also – whilst it is sold as simplifying environments – this may be true for those doing the provision after infrastructure has been built, in truth – the underlying complexity and layers of abstraction is really quite scary... Performance fault finding as an example – has just become orders of magnitude harder...

So back to the title - why foggy computing - well, it’s sort of unclear, un-instrumented, undefined, unworkable and quite frankly- unreal at this time..



Review on the iPad

Hi.... so thought this would be interesting - a review on the iPad - would be interested in your feedback!



Friday, 15 January 2010

LUN Provision models and technology change

A fellow bloggist / tweeter of mine who works in storage (see www.grumpystoragre or tweet at @ianhf) recently posted an article around LUN sizing / tiers and asked what we were using... Debate continued on twitter (albeit in short-phrasing due to the max size of at tweet post) so i thought I would put some of my thoughts down around where we are with lun sizing, how we got there and where i feel we may need to adapt to adopt new sizing.  

This is really just a rambling note throwing some food for thought out there - feedback and ideas muchly welcome!

So... where to begin... 

Back in the dawn of time there was an incumbent, and said technology made use of small bits of logical disk (in this case lets call them hypers) and you could glue these hypers together to make bigger single luns (lets call them meta's) - OK so i guess thats let the cat out of the bag then ;-) With said incumbent due to best practices, max logical limits etc we had carve up sizes (for the hyper) of around  8.4gb - and hence a standard was born.. Charge back models were fixed to this increment and everyone started working in multiples of 8.4gb for all allocations.

New technologies came along, different tiers of storage rocked up etc - but due to the complexity of changing financial models / chargebacks within the org - the same increments of chargeback were used (yep 8.4gig)

So how does our charge / billing system look today (for our traditional tier-1 storage) - well something like this:

  • Tier-1, charged in increments of 8.4gb (with possible meta sizes of 16, 32, 64 or 128) - then glued together with vol mgr
  • Tier-2, charged in increments of 8.4gb (with possible meta sizes of 16, 32, 64 or 128) - then glued together with vol mgr
  • Tier-3, charged in increments of 8.4gb (with possible meta sizes of 64 or 128) - then glued together with vol mgr

In terms of tier (performance), tier-1= mirrored 15k, tier-2=raid-5 10K (3+1), tier-3=raid-5 sata (3+1)

Typically we use products such as VxVM to glue these lun's together (and obviously this incurs a charge also).

Pretty boring and inflexible huh! - well this is where we are at right now!! (we do have some nice new shiny storage (read following paragraphs) but this is still in process of being rolled out mainstream.

Enter the new tranche of technologies such as virtual provision, over provision (thin provision, what ever you want to call it), thin snap, fat-to-thin, automated tiering and a dual vendor strategy and suddenly it all breaks... why - because we have become so rigid in our approach on chargeback and using this pre-determined lun sizes with a chargeback system that has been built around that...(we are currently trying to figure out how we want chargeback to really work over the next 3-5 years).

People no longer want to play for this inflexible amount of disk due to standards we have to impose on then (due to a once rigid technology issue) - they want to pay for blocks they use, but with the ability to grow into as and when (and also with minimum disruption). Its also worth noting - they may now wish to grow into more disk space, but be upgraded in terms of IO performance. Basically our customers want to use the new and shiny products that were mentioned in the paragraph above and have a chargeback model that works.... hmmmmppphhhhhh if anyone has any ideas on that or event better - has something that works, utilising these technologies - then please shout and let use all know (will save a whole bunch of heartache!)

So back to where we want to go with lun sizing - basically to move away from this 8.4gb increment and give the customer what they think they want - as an example they want 20tb usable then we will give it to them (sort of) - but make it thin provisioned and let them grow (single lun - why not, the wide striping that is available on most arrays does the nice back end spread for us) - basically move to an oversubscribed model. Generally we see 40% disk utilisation on most of out file systems...We might even make them pay the full 20tb to start with - as this can pay for the next tranche of seed kit. 

As for tiers of storage and performance - we will probably stick to the same standards we have had (mentioned above) in terms of drive performance - with the obvious addition of SSD's (At some point)...

In terms of volume management - they will be knocking around for donkeys.. I make no secret that I am a fan of vxvm as it has been pretty consistent through the years, however i can see a point soon where native OS volume managers are going to be good enough that we will start using them (wish i could say the same for multipath products!!!!)

So thats where we are i guess.....

But hang on... hold the press (as they say) - there is another change on the way......

So we spend time modifying our chargeback models to cope with these different tiers of storage and thin provision... but there are three more changes that we have heading our way, we may mean we have to evolve again, these being:

  • SSD Caching layer with nothing but SATA spindles (With some top-notch caching algorithms)
  • SSD only arrays
  • Automatic tier upgrade /downgrade at an atomic level (i.e. upgrade frequently used blocks to higher tiers).
These obviously change the chargeback model once more - as we don't have so many tiers (and in the case of SSD only arrays - 1 tier and 1only)...

The SSD only array is interesting, and in my humble opinion where the technology will ultimately be heading... There are a couple of vendors that i have been speaking to (Currently in stealth - happy to share on 1:1 basis where i can) that have some very healthy ideas and some great technologies... I'm also not (a) totally mad or (b) have shed loads of money to throw at SSD only - the reasoning goes like this:

  • SSD pricing will fall more and more as it is put in commodity machines such as desktops (not enterprise drives i know - but there is a knock on (just note what happened with SATA)
  • With all the de-dupe / compression that is now viable, the io profile of ssd (on the premise of size of todays data set) we will possibly be able to use less drives (also depends on how de-dupable your data is!)

I guess in reality - the first step will be combination of ssd and sata if you invest in the relative near-time.

So - there are my rambling notes... 

One other point of mention (and note that i put this on my previous blog entry) - in order for us to facilitate all of this new shiny technology and be able to truly offer chargeback - we need to see the tools that allow us to charge by $/TB of data/information stored and not charge on physical allocation... More importantly the vendors need some way of charging on that metric also... no more dealing in $/TB physical please!

Have a good one...


Friday, 8 January 2010

Measuring the cost of storage

2010 begins, the promise of innovative new technologies and further development / extensions on current product sets. High on the agenda of any storage manager are how to stop this mad growth of disk that is consumed, key topics / technologies being discussed are:
  • De-Duplication
  • Compression
  • Thin Provision
  • Fat-To-Thin provision
  • Storage Virtualisation
  • Automated tiering at the block / file system level
  • Tiering within the application layer (read database)
  • and the list continues....

Some of these products are maturing quite nicely from various vendors providing some real business value, be it in the end-cost to the business, extending the life of our DC's or just a quicker time to market...

Obviously, all of the above functionality comes at a cost as we would expect (and no IT manager minds paying for these type of features as long as he / she can reap the reward after implementation) and therein lies the problem....we get to the age-old method of measuring how cheap (or expensive) our cost of storage procurement and ongoing run-rate....

Lets all stop thinking about $/TB of the tin...

Vendor sales teams - please please please stop telling me what a great cost of physical tin i am getting, and that the $/TB cost I am getting is fantastic... I want to know logical data storage and get a per TB cost of that...

Procurement Dept's - please please please stop thinking that $/TB is the way to measure how succesful we have been at maintaining (or bringing down) cost of storage - we need to get smarter with how we manage technology vendors and the value add that they offer.

IT Mangers - the trick here is to do more with less, not work everything out on the cost of procurement on your particular flavour of tin - the smart stuff is in the software - and you peeps need to recognise this... its what is gonna stop our hardware costs spiralling out of control...

So... what does all of this mean, well for one definte - we need to get a lot smarter at working out how much of this new smart storage we need to buy and this brings on another intersting little problem - measurement....

Storage Vendors - you need to give us some new and shiny ways of measuring the value you are bringing so we can justify usage of some of these new toolsets (and the uplift in cost)... An example - A certain CAS offering that has been out for some time (vendor / product shall remain nameless) done a pretty good job of de-duplicating at the object level - and we knew it did a decent job... then management asked "how good, and show us" - guess what we couldnt.. There was no tooling to show what had been de-duplicated and how much logical (virtual) space had been consumed and how much physical provisioned had been used... (this issue may have been fixed on the latest iteration of code - i havent checked yet).

Imagine how good both the vendor and storage dept would have looked if we had told them that 2pb of storage had been crunched down to 500TB by use of technology - everyone would have looked a winner! instead - numbers on gut feel (and by the way - i dont want to get into the game of comparing host reports on file systems etc against physical provisioned - i want it all measured at the storage layer!)

We need effective tools to measure, prove value and stop working on this $/TB for physical tin and start focusing on driving cost down and telling us after de-dupe / compression (and any other technology you care to mention) what the cost of information stored is in terms of $ value

Bottom line - we need to get out of the game of $/TB (value against tin) - talk to me about $ / TB of data stored....


Wednesday, 6 January 2010

Happy New Year

Happy New Year... so after issues with my previous blog (using another service that shall remain nameless) and it all being lost (and i dont mean it went wondering in the wrong direction) - i upped and moved...

Hopefully peeps will start following this one - and will start posting some storage & techy stuff on here... My new years resolution to start doing this stuff properly....

again - Happy New Year - Hope you had a great break and look forward to the next #storagebeers! 8-)

Railway's in the surrey area - 6/1/2010

Hmmm... what to say... Went down to the train station today at around 6:10am... Train depature times looked all good.... so i waited and waited and waited... Guess what... No trains arrived (I did note that after some time something in the distance that looked remotely like a train was just stuck).

So - I asked staff at the station what was going on? Reply "we dont know sir" - we had a couple of rounds of this conversation... What about annoucements over the tannoy - "I dont know sir".. Arrgghhh.. after some time the same member of rail staff suggested i check the internet... How funny - down the station and he wants me to go home and check the internet nice... anyways - i have my netbook with me (with the pre-req 3G card) - i check the internet... yep - you guessed it - am seeing the most effective denial of service due to number of people checking the operators website...

Really people - how hard can it be to do some announcement work to say trains are broken or delayed... Needless to say - I shall be asking for a ticket refund!!!!