The Storage Architect » The Register

VAAI Posturing

Chris M Evans — Wed, 21 Sep 2011 08:10:02 +0000

With yet another HDS/VAAI post coming out from Scott Lowe (here), the irrelevant debate continues as to who is in and who is out of VMware’s inner circle of trusted storage vendors. Previously my friend Stephen Foskett discussed HDS’s position regarding VMware integration in this post, which followed on from an original post by Chris Mellor (who I hope would be happy to be called a friend of mine ).

So this is all great and understanding where vendors are heading in the future is nice to know, but perhaps we should take it back to today and the real world of using the current VAAI features. We’ve seen lots of posturing about who was first to support when VAAI first came out, but at the end of the day, what’s relevant is how this feature support works in practice. I’ve seen some good demonstrations of the technology, but as yet, there’s no meaningful measurement of who’s implementation of VAAI is best. Clearly it will depend on the underlying hardware and the way the engineers have chosen to prioritise VAAI workloads. I’ve not seen any answers to questions covering VAAI performance, if and how it could bring an array to its knees with overuse or how it can be controlled or prioritised. Oh and don’t get me started with the security implications. So for all of you out there involved in the discussion and promoting your VAAI support (that’s Scott, Heff and others), can you:

Provide real-world performance figures that show VAAI acceleration
Indicate how VAAI is prioritised/throttled from flooding a storage array
Explain how block copy functions are secure.

This degree of detail is much more interesting than discussing who’s in and out of the vStorage API Club.

As for the 3 points above, I’ll take the last one. I promised to follow up on it so expect a blog post soon. In the meantime, don’t question whether vendors have VAAI support – ask them how well that VAAI implementation works for you.

Enterprise Computing: Hitachi Enters The Cloud

Chris M Evans — Wed, 14 Oct 2009 08:01:15 +0000

Yesterday Hitachi Data Systems (HDS) used SNW USA to release information on their proposed cloud strategy, referred to as “Agile Cloud”. Everyone believes they need a cloud story and clearly Hitachi are no different.

Taken from the presentation I was given last week, is the following picture. This pretty much sums up Hitachi’s approach; make a virtue of the technology they have today around virtualisation and revamp their Content Archive Platform as a generic content platform – HCP.

Most of the things you’d expect are there – multi-tenancy, consistent name spaces, security, data tiering, REST interface to the HCP platform, but one or two differences stuck out for me. Firstly Hitachi are not about to get into the business of being a cloud services provider (CSP), like EMC, Microsoft, Amazon et al, but rather are making their technology available to other service providers to take up this challenge. Second, they are not betting on commodity solutions for data storage (e.g. Atmos) but are assuming Enterprise customers will want the same level of reliability they currently enjoy on existing Hitachi hardware.

With stories in The Press regarding data loss in cloud offerings ringing in everyone’s ears, there’s sure to be an increased focus on transparency regarding data security – not from an access point of view but on the use of technologies like RAID, backup and other methodologies cloud providers will implement to ensure data loss doesn’t occur. It’s also an opening for increasing the price and breadth of service offerings – a tiered approach to cloud storage provision as clearly one size/protection level doesn’t fit all.

The cuts are happening again

Chris M Evans — Tue, 29 Jul 2008 12:57:00 +0000

The Register has reported that some UK banks are forcing their contractors to take a 10% pay cut or take a hike. It is usual for contractors to take the hit first as they are an easy target compared to terminating permanent staff and to be fair, as a contractor/consultant myself, if the chop comes then so be it, it’s part of the nature of the business.

However, the downside is that the most able contractors are likely and will surely leave first. Many of those who remain will have a lethargic attitude to work and overall, the company suffers.

In addition, Barclays are offshoring more jobs, presumably to further save costs. In my experience, moving jobs offshore doesn’t work. It simply moves skills away from the business and causes the customers to lose control over their IT operations. This isn’t necessarily a reflection on poor quality of work from the outsourcing suppliers; far from it, I’m sure most are equally as competent or skilled as their UK counterparts. The issue is more to do with operating remotely from the customer; not understanding the “local” issues; not understanding local culture and not being part of the team who see and chat with each other every day. As someone who currently works with multiple clients for 1-2 days a week, I experience this problem even though I know my customers well. Imagine if you’ve never met most of the people you are providing complex services for.

One final note; Barclays claim they worked out they were paying “over the market rate”. That’s a phrase I’ve never understood. It assumes all contractor’s skills are equally good (or bad) and so they can be paid, or have their pay cut to the same degree. It also assumes that all contractors were taken on and overpaid by an equal amount. I wonder if they did the same market comparision for permanent staff and considered cutting their salaries by an equivalent amount? Somehow I think not…

5TB drives

Chris M Evans — Fri, 04 Jul 2008 21:31:00 +0000

I just read this on The Register. 5TB drives! Can you imagine it! The HDD manufacturers continue to push the envelope even further.

Now I have a concern about drives getting to this size and that’s the ability to get data on/off the drive itself. With 73/146/300GB drives, the capacity to response time ratio is still within a tolerance that means adequate random access throughput can be achieved. But with larger drives the number of different concurrent accesses will increase and if response time doesn’t decrease then very large HDDs will start to operate like sequential devices.

I think I need an illustration to make my point. Imagine a 73GB drive is receiving 200 random I/Os per second, each with an average 5ms response time. Scale the capacity up to a 5TB drive and that’s about 69 times the capacity. The scaled up drive would have to cope with 13800 I/Os a second and provide an average response time of 0.07ms!

Firstly, it is unlikely 5TB drives will be expected to perform like today’s 73GB drives but it serves to illustrate that we can’t expect to simply consolidate and shrink the number of drives installed into an array. We need something more.

I think we need a more innovative approach to the design of the drive interface. This may simply be shed loads of cache, to improve the overall average response time, or perhaps multiple virtual interfaces per drive or independently mobile read/write heads which don’t need to read/write a cylinder at the same time. It could even be drives that dynamically reallocate their data to make read/write quicker (for example, put frequently read/write blocks in the same physical area of the drive).

Who knows what the solution is, but rest assured something needs to happen to make 5TB drives useful devices.