HGST has an entry-level 14PB archive box... is that enough for your, er, home collection? Western Digital has added another HGST archive array, the SA1000, to its range of gear plus software enhancements across the product line. The Active Archive Systems provide object storage, using acquired Amplidata software, for markets such as media and entertainment digital data preservation, life sciences data pools, and …
Why can't they just quote the usable capacity? When you're talking PB the difference is significant.
And on the subject, let's just have a bloody storage amnesty and move to binary TB. Yes, decimal is more correct, and an SI unit, but end users would prefer binary because that's what their computers do.
Exactly! The storage policies which determine how objects are stored, how many parts they are spread across on the disks and how many parts we can afford to lose (the 'safety') is customer configurable and determines the effective storage size.
/Currently sitting in a training course at HGST for this, so getting a kick etc...
So are you guys the actual people who buy the storage? Do you say in your RFPs I want X TB of storage? Don't worry about what protection level - we'll decide that and we'll take the hit of capacity loss.
I'm genuinely interested because every RFP I've answered (and there have been many) has clearly, or not so clearly stated usable, binary TB. I've also seen plenty of cases where the salesman has sold decimal, the customer has set it up, found they're many TB down on what they thought they were buying, and the vendor has had to throw in a bunch of free storage.
Some systems give you RAID 6 protection and others demand mirroring. Is it fair to compare raw capacities between those? Of course, there are plenty which give you options, but does anyone actually presume RAID6 when purchasing then decide to go RAID10 without having to buy extra?
By the way, K, M etc are SI prefixes. They are everything to do with SI units. Without SI units there would be no SI prefixes.
This is stupid. Once you get to 4 9s, human error becomes the dominant factor in outages. Even something that should never be screwed up like replacing a bad drive sometimes is - I saw a three hour outage on a VNX pool last fall when the EMC contractor replaced the wrong drive.
You can mitigate that through strategies that remove the human element from the picture as much as possible, but there's no way you can remove the human element enough to get to 15 9s. That's just stupid stuff some marketer came up with that the engineers in the company were probably all against claiming.
You're right that human error is a great contributor to outages, but that's not availability figures are about. Availability measures the machine's availability, so if you were to yank all the power cables out, it wouldn't count, as you could hardly blame the machine, but if the power supplies were to all fail simultaneously it would.
There's two ways to talk about availability and the Xx9s numbers. The first is the design - storage systems are designed to meet availability targets. So to go for 5x9s you will need two controllers for example. This is based on the probability that each of these controllers will fail. If you want to go above 5x9s you either need to increase the resilience of these controllers, which is difficult and expensive or add a third controller, especially if you're using off-the-shelf components as most people now are.
Similarly there's the way you protect your data. RAID 5 won't cut it with large disk drives nowadays, so to get 5x9s you need RAID 6. Rebuild times are terrible so various people have designed more granular dual-protection mechanisms to mitigate against that. Those can generally give you 6x9s and above.
The second way to talk about it is to actually measure it. This is a bit more difficult for a new product as there aren't any boxes out in the field. For established products, one can build up a reasonably accurate availability picture, to an extent. Most outages go up the support chain as far as the people who do the measuring. They actually time the outage from when it begins until the last host is back up. Or at least that's what they're supposed to do.
There are some caveats: if the outage was not caused by a failure in the box, it doesn't count at all. If the system is back up but the customer is taking their time bringing up hosts, then a decision will be taken regarding whether to include that as part of the outage. More importantly, if an outage is caused, for example, by a heavily loaded system losing a controller, and the resulting latency increase resulting in many hosts timing out, it doesn't count as an outage as the system is "working as designed".
The other thing to bear in mind is the vendors do fiddle the numbers a bit. If you remember about a decade or so ago, a lot of hardware (not just storage) was hit by a timer bug in the Linux kernel (I forget the details). A lot of machines fell over so availability was terrible for that day/month. Vendors will not have highlighted that, smoothing it out by taking a 6-month number, or discarding it completely as it wasn't their fault.
The system discussed in the article is new, so HDS are making their claim based on the architecture they have used. Clearly they have no field measurements. It's a bold claim, and the details of the architecture will help people decide how realistic this is. Ultimately though, this is the best way to determine what your availability is going to be like: understand the architecture and the components within. Take the vendors' figures with a pinch of salt.
This post has been deleted by its author
Important notes:
This is not an HDS system; it's from HGST - totally different organisations.
These systems use Erasure Coding to scatter elements of the stored objects across multiple disks (or sites, if you have more than one system), and rebuild times are based on the time taken to reconstruct the elements stored on one disk.
There are boxes out in the field (previous generation ones) for which reliability data is available, plus there are the ones in the labs and development centres. Overall, it's possible to calculate reliability figures based on the MTBF/AFR and other parameters for individual components.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
