Could be very significant for enterprise disk architectures.  Read on to see why…

On the one hand I’m surprised.  When you consider the colossal amounts of data we’re storing these days, surely there is money to be made out of their disk drive business going forward.  After all, disk drives are key in the storing of this data, and there are no signs of this trend slowing.

On the other hand, IBM offloaded the business to Hitachi not that long ago, so IBM clearly didn’t see it as an easy profit making business either. 

Keeping up with the Joneses

There is no doubt that the R&D required to keep pace with the competition (Seagate, WD and Toshiba) is immense, and I can only think that Hitachi Ltd don’t feel up for the fight. 

Interestingly, as we all know, Hitachi is a huge conglomerate, manufacturing things from TV sets to Bullet Trains, to Nuclear Power Plants, whereas Seagate and Western Digital are both specialists in Disk Drive technology.

On the topic of specialising in disk drive technology, I’m a bit of  a fan of WD and like what they have pioneered in 4K Sector Advanced Format drives.  If you don’t know about it, go check it out.

Enterprise Drives – the Big Question

In the enterprise disk space, Seagate and Hitachi were the major players, with Seagate having significantly more market share than Hitachi.  However, enterprise disk drives account for a tiny fraction of drives shipped, so must be an expensive side of the business to run. 

For me, the big question is, will WD be up for the fight with Seagate? 

IBM and Hitachi clearly weren’t.

So, what happens if WD decide not to compete in this space?

If Seagate became the sole supplier in the enterprise space, they could effectively charge whatever they want.  Competition drives cost down. 

Competition also drives innovation, so where would the drive for innovation come from if this were to happen?

On the other hand (again, if WD decide not to scrap with Seagate in the enterprise space) we could see the end of the enterprise drive. 

After all, we’re already seeing commodity type drives making their way into the enterprise space.  7200rpm SATAII drives are becoming very common place now (I appreciate these are not exactly the same as the drives we have in our laptops etc).   It’s no secret that SSD drives sucking up much of the oxygen that 10K and 15K drives used to take for granted.  So with slow SATA drives are squeezing at the bottom and SSD squeezing at the top, life is not so cosy these days for our trusted traditional 10 and 15K drives.

I personally think that SSD is already killing the value prop for 15K drives.  I also think that NL-SAS will up the pressure on 10K drives.  Add my opinions to the hype we get from array vendors, it may not be that long before our enterprise storage deployments are comprised of only two tiers – Flash and Trash.

SSD Will Not Take Over the World.  At Least Not Any Time Soon

It’s my opinion that that SSD is not going to replace our beloved rotating rust any time soon, if ever. 

My opinion is nothing to do with $/GB, Watts/GB, performance or any of the usual arguments.  It’s far more basic than that, I’m lead to believe that there just aren’t enough raw materials or fabs in the world to do so.  It’s my opinion that while HDD’s will of course one day become extinct, they aint going nowhere in the foreseeable future.

Commodity

Despite the fact that Hitachi Ltd owned both a drive manufacturing business and an enterprise array business, they never leveraged any potential advantage this could have brought.  Not surprising I suppose, but from a technologist perspective I’d have liked to have seen this.  If they couldn’t leverage advantage, what is the advantage of having the business?

In the same way that drives are commodity, I wonder how long before arrays become commodity (providing only hardware RAID type functions) with so-called intelligence such as replication, copy services, thin provisioning, dedupe etc residing further up in the application/hypervisor…?  Just speculation of course.

Conclusion

Good luck to Western Digital.

If WD decide not to compete with Seagate in the enterprise space, I think we could see the death of our trusted enterprise drives accelerated.

NOTE: Hitachi will maintain 10% stakehold and two seats on the WD Board of Directors.

Thoughts and comments welcome.

You can follow me on Twitter, I’m @nigelpoulton.  I had a great conversation with several folks last night relative to this acquisition.

This was a landmark even for HDS PR and social media, and hopefully marks significant improvement in the way that HDS engage with the community and their customers. 

While at the event I had the privilege of joining with Greg Knieriemen (@knieriemen) and Devang Panchigar (@storagenerve) interviewing Hu Yoshida – Chief Technology Officer at HDS – on the latest episode of the legendary Infosmack Podcast.

On the podcast we talk to Hu about his career, HDS vision on unified compute (vertical stacks) and storage architectures.  It is well worth a listen, even if I do say so myself, as Hu is an industry legend.

I also highly recommend the Infosmack podcast (even the episodes that don’t feature me) for all the latest industry gossip and tech roundup.

Listen to the podcast here

In the near future I’ll be posting on what I learned while at the event.

What the H*!! is this GestaltIT Tech Field Day thing?

The crux of the event is this – taking a handful of bloggers and a handful of smaller vendors, locking them in the same room for two days with only blogging and tweeting as their connection to the outside world………. And seeing who comes out alive!

Presentations will be given, demos will be done and most importantly, no holds barred hard questions will be asked, and asked, and asked….. 

In fact, Stephen Foskett the event organiser, and industry legend, told me the other week that he had warned the vendors that the only way he could guarantee that we won’t say they suck, is if they don’t suck!

Why should you care?

Answer: Same reason I care…… It will be one hell of a learning opportunity.

Granted its an invite only event, so we cant all go, but I will be there and will be blogging and tweeting about everything I learn.  So if you want to know more about the technologies and strategies of the companies who will be presenting, then stay tuned this blog and tune in to my Twitter account (@nigelpoulton).

I promise to blog and tweet about everything I learn.  The good, the bad and the ugly.

Proxy

As everybody cant be there in person, feel free to drop me a line via any of the many means by which Im contactable, with any questions you want me to ask the vendors.  If they are good questions then I promise to ask them.

Who will be there – Vendors

Who will be there – Bloggers

Finally

I am genuinely excited about this event. Same kind of excitement I would have if my football team ever made the FA Cup final or England made the World Cup final (well….. may be not quite that excited).  But seriously, this is a landmark event and a great opportunity to learn about some of the less well known vendors and technologies out there.

Feel free to contact me with any questions you would like me to ask…….

Nigel

PS.  Im really looking forward to meeting all in attendance but in particular Xsigo, MDS and 3PAR.

• Over 1,200 servers
• 500 EVA arrays (although there didn't seem quite that many from where I was looking*)
• Over 20PB storage

Also, based on those numbers, way over 1,000 fabric ports.  As Calvin puts it just before we enter the room "its your momas data centre".
 

* I should point out that the far end of the lab was off limits to us, and no I didn't try and get a sneak peak.  From memory the off limits area was about 4 or 5 rows deep.  More than that I cannot say.

So the video below is an exclusive peak into the bowels of a major storage platforms support lab environment.  May I suggest that if you dont like this video then you dont like storage……………………… or you are a comptetitor

Enjoy the footage.

 
Although video footage is not quite the same as being there in person, I hope you get a glimpse of what an impressive facility this is and appreciate exactly what goes into delivering one of the best storage platforms in the world (and for the record Ive always been a fan of the EVA). 

For further written analysis and some great stills, I recommend you pop over to Ray Lucchesi's writeup.

Two final points –
 

1. This is not the only EVA testing facility HP have.  On our first, non-videod tour, Tony mentioned at least one other facility, where they do "level 1 testing".
2. Sadly there was no SSD available for us to shoot.  But remember that we werent allowed to view the entire facility, so may be they had some in the "off limits" area at the back of the lab??

I was impressed!  Thanks again to Calvin and the folks at HP for allowing us in with the cameras so we can share with everyone else – hope you enjoyed it.

Finally, for the record, the EVA currently supports up to 8 SSDs.

Nigel
 

Below are some notes to the above videos (especially for those in quiet offices who can’t watch the video yet).

I posted the video in response to Marc Farleys recent video and comments on Hitachi Dynamic Provisioning, as well as other comments that have been made in blogs and on twitter etc….. All of these comments have been slating HDP for being chubby and the likes. Hopefully this post and the video will help set the record straight.

On the topic of HDP being chubby. While I accept that the HDP extent (page) size of 42MB is by far the largest of all the major vendors, I do not think this is necessarily all bad. For a start it maps perfectly with the internal workings of the USP V and VM. Secondly I think there is more metadata overhead the smaller your extent size – internal tables need to be larger and then there’s metadata for replication, snapshots and the likes. The smaller your extent size, the more metatada required. May be that’s OK on a midrange box that won’t be expected to address large amounts of storage and have lots of copy services running in the background……. I just don’t think its as simple as saying “ho ho ho look at Hitachi’s huge allocation unit, that must be lazy coding from the engineers”.

Yes I know that a smaller extent might be more thin friendly, but how many enterprise customers are deploying this for the “thin” oversubscription benefits?

Oh and yes there are situations where two small writes to the same HDP volume will require two separate pages. However, this is not always the case and often not.

See this link for what I’ve written in the past regarding how perfectly aligned 42MB is with the internal structures of the USP V.

Then there’s Zero Page Reclaim. Suggesting that it’s an apology rather than a feature made me smile. I doubt anybody would take such a comment seriously, but I thought it created an opportunity to talk about it again. 

I’m pretty sure that Hitachi is the only vendor to offer it as GA. I’ve seen it and know that it works. Others talk about it but that’s about it (I understand they may be waiting for standards like TRIM). ZPR is a really great feature that allows you to reclaim unused capacity that can be used to offset future capacity purchases. Pretty good during times like these where purse strings are tightly controlled.

In the video I don’t even mention things like dynamic volume expansion or automatic dynamic relevelling etc. But put all of these together and Hitachi has a well stocked Dynamic Provisioning portfolio that stands up against any other vendors.

A few points about the video –

• Yes that’s me – sorry I didn’t have a shave first.
• Why a field of cows? Marc did his video in front of a field of cows so I thought it appropriate I respond like for like
• Why two videos? It was shot as a single video but I’ve never done this before and at 14 minutes was too long for YouTube as a single video
• Why don’t I work for HDS or HP or someone like that? Your guess is as good as mine. I do have to remind myself occasionally that I don’t actually work for HDS
• Yes I know its a bit pants compared to Marcs many videos
  

Questions and comments always welcome.

One of the projects I’m currently working on involves deploying a new USP V with native SATA disks side-by-side with FC disks (when I say “native”, I mean the SATA is sitting inside the USP V and on an external array being virtualised with UVM).  Although this configuration has been supported for a while, it’s the first time I’ve seen or done it, and hence the first time I’ve really given it any thought.  So I thought I’d share my thoughts for the greater good.

Seeing as how HDS and HP have supported SATA in a USP V/XP24000 for a while now, you’d think there’d be a bunch of people out there with experience and a boat load of best practice advice doing the rounds, right?  Apparently not!

In fact, the only best practice advice I initially got was that RAID 6 was recommended for the SATA disks.  Fair enough, in a storage array that builds RAID Groups in the way that the USP V does, RAID 6 is a no-brainer for large SATA.  But even knowing what little I know about SATA and the USP V I couldn’t believe that there was no other best practice advice.

Concerns

My overall question was simple –

What is the impact of installing larger, slower disks running a different protocol and a potentially higher failure rate, side-by-side with smaller faster FC disks?

When I asked this question, the most I got back was “you need to do RAID 6 with SATA”.  Thanks, but to be honest not very helpful.  Certainly not good enough for me to press ahead with a production install. 

So to break down my concerns into more detail –

1.  What is the recommendation regarding cache partitioning?

2.  Is the imposed verify-after-write operation that is mandatory for all writes to SATA disk in HDS midrange kit (AMS) also a requirement on a USP V with native SATA?

3.  What is the potential impact of larger, slower and disks with a potentially higher failure rate and resultant elongated rebuild times?

4.  Is there a recommendation for backend layout – SATA sharing BEDs with FC or SSD?

5.  Are there any System Option Modes (SOM) recommended for SATA disk, and if so what are they?

Really simple, and to me, intuitive questions.  Boy was it hard to get people to take me seriously!

So as a result of some digging, I propose the following answers and loose best practice advice –

NOTE:  The following are my opinions and I am absolutely not an authority on the USP V or XP24000.

Answering those concerns

Q1.  Cache partitioning

I highly recommend a dedicated cache partition for SATA.  This is to provide an element of protection for global cache and other cache partitions, effectively ring fencing a portion of cache for SATA. 

Why?  The potential for high cache write pending (WP) is increased with the use of SATA due to the larger size of SATA disks, the slower rotational speed, overall lower throughput, as well as the more limited protocol.

Obviously the size of you cache partition (CLPR) is entirely dependant on the amount of capacity in the SATA pool as well as how hard you will be pushing the SATA.  However, it is important not to size the CLPR too small as doing so can increase the chances of high Write Pending in the SATA CLPR, which in turn can affect the rest of cache (more on this in my answer to question 5). 

A good approach might be to start with a relatively small CLPR (but not too small) and grow it if required.  You can grow CLPRs in increments of 4GB relatively non-disruptively and easier than trying to reduce a CLPR.

Q2.  SATA and Verify-After-Write

In the HDS midrange kit, such as the AMS, there is an imposed verify operation (read) after every write to SATA.  This operation is intended to ensure your data is correctly committed to and retrievable from disk.  However, this brings with it a large performance penalty – increased number of backend read operations for every write operation.  This performance penalty saw SATA in HDS midrange kit perform quite poorly so far as feeds and speeds are concerned, but obviously perform admirably when it comes to data integrity.  Not the end of the world when we consider that SATA is not intended for high performance applications.

The USP V on the other hand is designed to be a high performance array.  So implementing a verity-after-write operation on a USP V in the same way as it is implemented in an AMS array would be disastrous for performance.

Fortunately it just so happens that the guys at Hitachi knew this, and as a result decided to implement the verify operation in circuitry in the disk canister.  This has the positive effect of keeping the verify operation without imposing extra load on the back end directors (BEDs) and back end loops.

It is probably worth pointing out at this point that SATA disks supported in the USP V have an FC <-> SATA bridge in the disk canister allowing them to sit directly onto the existing backend infrastructure, side-by-side with FC.

Net result is that in many cases SATA and FC can realistically site side-by-side on the same BEDs and loops.

But before jumping in with both feet, as always, consideration should be taken with performance centric configurations.  For example, a high performance OLTP System requiring its own dedicated 146GB 15K FC or 146GB SSD (assuming high random read) is probably not best suited sharing its backend with SATA.

Q3.  Potential impact of larger slower disks ……

While this is quite a generic question, the biggest risk, in my opinion, is around the elongated rebuild times associated with large SATA disks.  Rebuilds cause I/O on the backend loops as well as overhead (CPU cycles etc) on the BEDs.  The longer a rebuild, the longer this increased load exists.  On a subsystem under load, rebuilding large SATA disks can take several days.  I don’t know about you, but I don’t want my high performance LUNs sharing a backend with this.

Also, I know that SATA is usually associated with higher failure rates than FC.  However, I have to be honest and say that this is not something I have actually noticed in the real world.  Let’s not forget that build quality for SATA disks, bearings and all, has improved and is of a higher standard for enterprise class SATA.  Couple this with the fact that the disks will be housed in an enterprise array that is designed from the ground up to be a disk friendly environment – think; power, cooling, humidity, vibration……  MY personal opinion is that the notion that enterprise SATA disks fail frequently is a bit of an urban myth.  Happy to be proved wrong…. Well not “happy”.

Elongated rebuilds also increase the window of exposure to a double disk failure.  However, RAID 6 effectively mitigates this.

Q4.  Sharing your backend with SATA

This is issue is somewhat put to bed with the implementation of the verify operation in the disk canister.  With the responsibility for the verify operation being removed from the BED to the disk itself, backend performance should not be hugely impacted by SATA.  Therefore, is it moderately safe to have multiple Tiers of disk share the same backend.  However, h
aving said that, as previously mentioned – I would not personally recommend putting your highest performing disks on the same backend as SATA.

However, whether or not you want SATA stealing your premium priced USP V resources such as cache slots, CPU cycles, internal bandwidth and backend IOPs is another question.

Q5.  Are there any recommended SOMs for SATA

As appears to be standard practice in most installations, System Option Mode 454 should normally be set to ON.

This will base destaging algorithms etc on the average WP rate of all cache partitions, rather than just the highest.  Let me give an example –

You have two cache partitions; CLPR-0 and CLPR-1.  If SOM 454 is set to OFF and either of the cache partitions reaches 70% write pending (WP), aggressive destaging will kick-in across all partitions.  However, if SOM 454 is set to ON, destaging algorithms will be based on the average WP rate across all cache partitions.

Other than this, I’m not aware of any other SOMs that are of use particularly for SATA.

Resultant best practices

So my own personal best practice for USP Vs deployed with internal SATA are as follows –

• RAID 6
• Dedicated CLPR for SATA
• SOM 54 turned ON
• Isolation of high performance Array Groups on BEDs with no SATA disks.
• Tier 2 FC Array Groups can probably co-exist side-by-side on the same BEDs without any conflicts.

Oh, I suppose I should also expand a little on my previous reference to the different protocol.  Differences between SATA and FC amount to more than merely physical differences.  Lets not forget that the USP V and it ancestors have been supporting SCSI based disks for many years and as a result the USP V (actually its engineers) have extensive knowledge and experience with the SCSI protocol and how it behave under just about every condition.  The same could not be said about SATA.  This is no doubt one of the reasons why the AMS imposed the verify-after-write operation at such a high performance cost.  How does the protocol behave under all possible conditions etc is an important consideration.  And then there’s SATA Native Command Queueing versus SCSI Command Tag Queueing etc…….  When you add it up, there is a boat load of differences that need to be taken in to account.

As always, just my thoughts.  I don’t speak for any vendor and Im not an authority on the USP V.

Thoughts, experience, feedback and general comments welcome!

FINALLY……….Give this blog a pat on the back

If you like the content, including the technical deep dives, on this blog, then please take a moment to vote for us in the StorageMonkeys non-vendor blog poll.  We are currently way down in the poll.

StorageMonkeys is a great storage related site that you will probably enjoy if you are in to storage.  Thanks for your comments and support.

Nigel

UPDATE: It is only right of me to point out that there is healthy existing install base of USP V with internal SATA (as no doubt there is with the HP XP).  Not a huge percentage of the overall USP V isntall base, but enough to make me confident that this has been done elsewhere before.  Just a shame there is not better awareness of the requirements and best practices.

You can also follow me  on twitter  – http://www.twitter.com/nigelpoulton
I only talk about storage and not what I’m watching on TV (although that would be Lost, 24, Fringe…….)

<this was written while watching the Champions League final and twittering last night so more info might have emerged since I wrote it>

Where I come from in the world, "ham" is pig meat.  Let’s hope this doesn’t turn out to be a technology that resembles slapping lipstick on a pig, in an attempt to make the pig more attractive

What it is and what its not

First up, the announcement is basically a new supported configuration  – clustering of two USP V’s.  Seemingly they will use Synchronous TrueCopy  to achieve mirroring normally within a single campus to create a 2-way Active/Active cluster.  More than that I don’t know at the moment and even that is based on some assumptions.

Unlike the recent Symmetrix V-Max announcement, it is not an announcement of new hardware, internal architecture, or anything to do with feeds and speeds.  If you were expecting new hardware or major improvements to existing software features such as Dynamic Provisioning, Distance Replication, Snapshots etc then you might feel a little short changed, and clearly some people do.  In fact, my initial feeling was one of being somewhat underwhelmed, and that’s coming from someone who knew that this was essentially to be a storage clustering announcement.  But even I was expecting a little more than what was suggested on the solitary diagram, used during the Webex.

Second up, there is as yet very little information in the wild on how this will actually work.  In fact, the below diagram was all that was provided on the call.  With this in mind, it’s not possible to do any kind of deep dive….   And to be fair to those feeling short changed, looking at the diagram there doesn’t look to be *too much* anything new from a hardware perspective.  Added functionality to the microcode is obviously required, but as previously mentioned, this is essentially a minor change.

Steady as she goes

However, and I think this is an important point.  HDS are claiming a major new feature(s) resulting from a minor change.  And from where I stand most days, this is a win win situation!

If I take a moment for a sidestep.  I recently mentioned that in my opinion the fact that EMC stuck with crown jewel of the Enginuity code base in the Symmetrix V-Max was an excellent move (too much change is too much risk).  At the top end of the market, where much of the USP V install base lives, making major changes to anything, including hardware or software, presents a risk.  And we all know how risk averse people at the top end of the market tend to be, and for good reason.  Therefore, achieving a major improvement via a minor change is "win win" – less development costs, no fork lift upgrade, and less perceived risk to the customer.  This is all of course assuming that some of the functionality achieved from clustering a pair of USP Vs will yield "big wins".  Only time will tell.

A final point for those feeling short changed (I did initially, and with the lack of technical detail available I still havent been able to decide if I got "value for the hype").  Take another second to think about the recent Symmetrix V-Max announcement (apologies to both parties for the parallels) and in particular – FAST.  Some the goodness that EMC FAST promises to bring, are worthy of a separate mid-life V-Max announcement.  In fact FAST was not announced as being available at V-Max 1.0. 

Think in particular about the promised ability of FAST to migrate/re-tier volumes that are actively being replicated (SRDF…).  Might seem small compared to all the new glitzy hardware on show in the V-Max.  However, from a business and customer point of view, this is a big win.  Consider that re-tiering products that require suspension of remote copy operations while the re-tiering operation is in progress, such as Hitachi Tiered Storage Manager, sit on the shelf in large TrueCopy and HUR environments and only have the dust blown off them for planned out of hours migrations.  They’re not much use in production environments.  For FAST, online migrations during active remote replication load will be a big win to those kinds of customers.

Likewise, for some of the promises associated with USP V clustering (I can’t get my head around calling it HAM).  Large scale Zero Downtime Migrations (ZDM) is just one ability that will be a huge win for customers and businesses that don’t like downtime – anybody know any customers and companies like that?  Actually, if I understand the possibilities correctly, the term "migration" may no longer be appropriate in clustered USP V shops.  I don’t know a customer that would not like that!

Will it cost the earth?

Of course, any potential will come at what looks like a huge cost. 

2 x USPV != cheap 

But as a general rule in life, you get what you pay for, and this is one that looks like it will be reassuringly expensive

On the topic of cost, I recently did some work that resulted in the purchase of new kit to the tune of slightly north of £2M (not huge but also not insignificant).  However, over 3 years this actually resulted in a substantial saving for the customer as they were able to scrap their "extortionate maintenance fees* tended maintenance fees.  USP V clustering and Zero Down Time Migrations makes it possible to never have to fall into extended maintenance on current and future HDS storage.

That said though, from where I’m standing, implementing such a USP V cluster looks like it might cost the earth – basically double almost everything in the USP V – cost, power and cooling.  So it might not just be a case of having extremely deep pockets, there is also the environmental impact.  Talk about difficult to justify in current climate! (pun intended)

In fact I recently sidelined the idea of some SSD in an array because a single 8 disk array group was going to cost £2,000 less than the first house I bought in 2002!  That was despite the fact that they would be far more environmentally friendly.  So doubling the cost of a new USP V might be hard to get past investment review boards :-S

Summary

Its difficult to really say much, due to the lack of technical information out there.  However, after some thought while watching Man Utd being schooled by Barcelona last night, I’m starting to see some potential, and feel less and less like this is a mid life crisis for the USP V. 

Of course, like most people, my view is from a distance.  Up close and personal might reveal it to be a pig with lipstick, but at the moment nobody knows enough to say that.  In fact on the contrary, I think it is fair to say that Hitachi has a heritage of bringing some great array based products to the table.  With this in mind, I think writing this off without more knowledge or experience is probably a little rash.

Oh and Zero Downtime Migrations is not the only thing HAM will bring to the table.

Final thought – who came up with the acronym "HAM".  Not great!  Whats next, naming TrueCopy/HUR for z/OS "TURKEY" –
TrueCopy
Universal Replicator
for Count KEY Data volumes

PS.  Anyone with any technical info on the matter please feel free to contact me.

Nigel

http://www.twitter.com/nigelpoulton  (I only ever talk about storage, never what Im eating for breakfast)

This is the most important content that has ever been, or probably ever will, be posted on this site…….

Nick Glasgow, an EMC employee is dying from Leukaemia and is in desperate need of a bone marrow donor of caucasion-asian ehtnicity.

Please go to Mark Fredrickson’s blog to see if you can help save Nick Glasgows life.  If you don’t know Nick’s cause them please take the two minutes it requires to find out and see if you can help.

twitter: #helpnick

UPDATE:  Version 0.003.

Updated info on Hitachi, HDS, HP and Sun
Corrected some typos, clarified some points and corrected some mistakes.

v0.002 updates:
Updated content includes section on RAID6 contributed mainly by Devang Panchigar at http://storagenerve.com/ as well as content on RAID1 and HDP 42MB Page size.

As a result of feedback relating to the HDP unofficial best practice guide I made available for download I have put together the outline, and some content, for an unofficial USP V manual.

This is a very early draft version with lots of gaps and unwritten chapters.  My intention is to have other people with USP V (XP24000) experience contribute content to make it a community document.  Some people have already approached me asking if they could contribute content.  If you were one of them or if you would like to contribute content, now is the time to get in touch with me.  All contributors will be duly acknowledged.

Please take a look and let me know what you think.  Be warned though this initial version was written a while ago and has not been proof read so may have typos and some dated content (although I have re-read it tonight and updated the obvious stuff).

The content is from my experience, what I have been informally told, as well as what can be found on the internet and on the HDS and HP storage forums.  I hope that none of the content is confidential or protected by NDA.  Therefore, if you wish to contribute content I ask that you respect any confidentiality agreements and NDAs etc……..

The HDP doc appears to have helped a lot of people with their HDP/ThP deployments and make the decision to use HDP/ThP etc.  Im hoping that this document might have a similar effect on people using and deploying more Hitachi storage.

Download version 0.003 here

Give this blog a pat on the back

If you like the content, including the technical deep dives, on this blog, then please take a moment to vote for us in the StorageMonkeys non-vendor blog poll.  We are currently way down in the poll.

StorageMonkeys is a great storage related site that you will probably enjoy if you are in to storage.  Thanks for your comments and support.