Glacier redux
storagemojo.com
storagemojo.com
I am with the author in that I do not think they are using older disks. From personal experience (working with petabytes of disk based storage), I would put money on the fact that AWS is not using stock off the shelf older disks and then powering them on/off as a method of storage. The last thing you want to do with an older disk (5+ years) is ever power it off. The chances of it coming back to life decrease rapidly with each cycle. Picture seized bearings, etc. Your best hope it to keep them continually moving, but never powered down for extended periods of time.
Also, the GB/power/physical space required ratio does not make sense after X number of years. For example, you could replace 3 shelves of 1TB disks, with one shelf of 3TB disks. Yielding less power consumption in less physical space! When you are at scale, data centre space and power are big factors. For these reasons, I do not think they are using old stock disks.
NOTE: Maybe they are using some custom make disks, but from what I know about standard disks, even enterprise, they do not like being powered on/off when they get old.
"Unless the prices of copper, PDUs and diesel-generators have started following Moore’s Law, this is probably more true today than in 2007."
But this is fallaciously assuming that Glacier servers would need to be like EC2 or S3 servers that are switched on for x random hours per day. This isn't the case at all.
Diesel generators, for instance - what's the use? If you're replicating the data around the world, it doesn't matter if your Glacier servers in one location are powered down for days.
Cooling, power - just switch off every single Glacier server at each location during the peak hours of the day. No additional capital costs, because you're never adding to peak power usage.
Distribution of reads - Profile customers based on how frequently they're reading from the data store. I bet 50% of customers never read a single byte back. Colocate these customers on the same servers, and you only have to power up the server once a month to check if the data is still there.
Bonus - Profile data access patterns with simple heuristics to determine what's likely to be read back in, and temporarily store that data in S3. Imagine a company that archives everything to Glacier daily, but restores day, week and month old backups regularly. Keep all data less than a month old in S3, and the rest on the indefinitely powered down servers talked about above.
I actually quite liked the author's case for BDXL, but it seems he's doing a straw man on other possible solutions. Well implemented BDXL more cost efficient than a naively implemented disk strategy? Not exactly news.
Database machines are usually never shut down. And when they are, it's usually a manual process (unless we're talking about a power failure or something)
"Diesel generators, for instance - what's the use?"
Backup power (not only for Glacier).
Reducing power consumption in peak hours is a good strategy, however, I'm not sure how worried Amazon is about this (and the difference in price between regular hours and peak hours)
As the article (correctly) says, the capital costs are dependent on your peak usage. If you have 1000 servers using 400kW at peak, you need sufficient air conditioning to extract 400kW worth of heat, and backup generation capable of producing 400kW. It doesn't matter if you only use 100kW 16 hours a day - the capital costs are the same.
I'm suggesting that Glacier could live entirely in non peak periods, meaning that the capital costs are unchanged and the demand curve is flattened.
How much power does Amazon use during mornings compared to Netflix watching peak time?
Also you might be able to skip the backup power part completely. The data is anyways distributed to few locations. The probability of many of them losing to power at the same time for several hours is likely to be very small.
Maybe there's also large differences in how the customers use the system. I would assume some customers are more likely to retrieve data than others. Once you start learning these patterns you could further optimize the storage.
The pricing of Glacier is not necessarily driven by technical reasons. Amazon already has S3 and they need to differentiate the products.
But NONE of the Hacker News commenters addressed Sony and
Panasonic’s continued investment in high-density optical
disc technology. [...] There has to be a business reason
for the continued investment, i.e. customers prepared to
buy a lot of product in the future and buying a lot right
now.
If Amazon was the only customer for high-density optical storage, they'd be crazy to invest in developing it, because Amazon will have all the negotiating power in the relationship.There must be other customers somewhere if two companies are continuing to develop this stuff.
Backing up to the cloud is great, but a lot of people can't do that
Explain how BDXL, a new format, which has never proved itself beyond a few years, which costs $45 for a few hundred GB, which AFAIK has very little data on re-writability (which is probably terrible and close to one-time use) could be any more profitable or reliable, or useful than tape.
I don't buy it. Tape would be the logical short-term choice to get started, because Amazon could just go buy an off-the-shelf tape library and add tape as they needed from Oracle, versus again, engineering their own BDXL library on the expectation that it would cost less than tape, taking into account factors such as:
1. Reliability and degradation 2. Supply 3. Cost 4. Reusability/Re-Writability
"Essentially you can see this as a replacement for tape,"
and: "inexpensive commodity hardware components"
Nowhere did they explicitly deny that it may be tape-backed.In addition, From the article:
Instead, Glacier runs on "inexpensive commodity hardware components", he said, noting that the service is designed to be hardware-agnostic.
Which may allude to the fact that the backing storage itself may be flexible (a combination of HDD, Tape, possible BDXL)The author himself only acknowledges:
This suggests the system will be based on very large storage arrays consisting of a multitude of high-capacity low-cost discs.
Which isn't definitive in the slightest. Also, the article is over 18 months old.I've said it before, I wouldn't be terrible surprised if they got started with old commodity hardware to get started, but the economics and characteristics of tape still seem much more amenable to the use case.
* By default instance storage isn't attached, so there's probably a lot of completely available capacity.
* Even if attached, it's rare that the full capacity would be used, so thin provisioning would leave some space available.
* Some host machines won't be fully allocated.
I imagine taking this pool of capacity and using erasure coding and replication to build reliable storage. As your volumes come and go, you need to make sure it remains available, which is why I imagine erasure coding across a large number of customers. By integrating with the guest -> host assignment function you can ensure that you never lose data, if need be delaying scheduling until you've copied data elsewhere.
You'd have to throttle reads & writes to ensure that the guests weren't unduly impacted (easier with SSD's predictable IOPS), and the splitting and erasure coding would make for slow reads & writes as well. But this makes the economics a lot more attractive (free!).
One thing that suggests Glacier could be doing this: if I was AWS, and I was doing this, I would not be in any rush to tell EC2 customers that I was "stealing" their unused capacity!
In short, your way is a good alternative, but my guess is that buying the full capacity and selling the surplus is probably roughly cost-equivalent, and considerably less likely to end up with you not being able to sell the full capacity of any given host.
They see a computer with an attached disk of, say, 1 TB. They don't see the filesystem at all. They don't know if a sequence of zeros is unused space, or are literally zeros in data. There is no way that Amazon can use slack space because they don't know what is slack space.
This incomplete view of how disks (both instance and EBS) are used is also evident by what metrics CloudFront can track: CPU usage. Raw I/O stats for disk and network. To get richer metrics, you have to install scripts/agents running inside your EC2 instance which than beacon the info to CloudFront via the API.
In short, Amazon's current setup means they cannot use the slack space inside of attached block devices, even if they wanted to.
As to whether EC2 does this I don't know - based on your observations they may not. I think it's an interesting way to build a storage product like Glacier, even if Amazon may have chosen to do something different.
One thing that gets overlooked in almost all comparisons is the pricing models. I actually use Glacier through Arq (brilliant backup for Mac), but the catch is in the requests. I recently uploaded 200GB of photos to glacier and the upload process cost me about $10. The monthly storage is about $2.
The thing is that you shouldn't compare the sole storage price, but the total of cost of storing your data in glacier, which was also overlooked in the original article.
I'm sure AWS has understood this through their S3 storage lifecycle and thus developed an appropriate pricing model for glacier that arouses interest in the product like no other.
(Well, I guess it means that your request size averaged 1 MB. If I'm already using Glacier, I would be perfectly happy with archive granularity coarser than 1 MB.)
Glacier is significantly cheaper than S3
Yes, as long as you put something in and almost never take it out. They charge for deletions in the first 3 months
What if this is just disincentive to pull content out and treat Glacier like S3? Power is not the driving cost for Internet scale infrastructure
It is not the only cost, but it is still one of the largest factors, no? Sony and Panasonic continue to invest in a product that has no visible commercial uptake
That means nothing in and of itself. The only person who will win such a market needs to be one of the first there, innovator's dilemma, etc. Facebook believes optical is a reasonable solution to their archive needs
Do they? I saw one mention in the author's previous post of James Hamilton commenting on a Facebook cold storage system using Blu-ray but is unclear to me if it is in production.Assuming it is true though, it is likely an apples-to-oranges comparison. Glacier provides archival restoration for presumably largely enterprise-level customers. Facebook backs up data from users, and I'd presume this is from deactivated accounts, etc., and unlikely to need urgent restoration.
Every example of their pricing I've seen has been cost plus, cost plus, and/or cost plus.
Thus it seems at least an order of magnitude more likely that the $.03 reflects some cost.
http://static.googleusercontent.com/media/labs.google.com/en...
The data is also > 7 years old.
EDIT: working link:
http://static.googleusercontent.com/media/research.google.co...
There's a data retrieval period of multiple hours [1]. That doesn't sound like they're just powering up a drive. It sounds like they're moving something around or doing some kind of linear read (as opposed to random-access). I'd bet on "a retrieval job fetches this stack of read-only media and connects it to the powered device, which loads it onto hard drives for quick download".
[1] "Retrieval jobs typically complete within 3-5 hours" - http://aws.amazon.com/glacier/faqs/
Yet that is what the author thinks Amazon is doing with BDXL.
So who's funding high-capacity optical storage? Hmm, can we think of a customer who ingests huge amounts of data, wants to keep it for a long time, and has no fear if funding cutting-edge product development? Yes: defense departments.
A little off topic, but it seems really strange to me that Amazon is not transparent on the technology. Because of the high charge for fast reads, I tend to believe that the underlying storage is some form of media that gets mounted, perhaps like Facebook's bluray archival system.
Other than that, I think the big culprit will be photos; everyone's family photos are different (the JPEG header is a tiny proportion of a modern 5MB photo) and that's one of the most popular things for people to back up on these kind of services.
Plenty of data is generic in the way you say, but plenty of it isn't. So I don't think there's any free lunch here.
So either cheap VPSs or dedicated servers are still much cheaper if you don't want to deal with Glacier.
As an aside, erasure codes allow you to reduce power consumption as the redundant fragments are only necessary for safety, not for regular retrieval. You don't need glacier to benefit from that. (But glacier might be an optimization of that strategy)
Dedicated servers are still much cheaper than even Glacier.
And he not only responds to the comments, but adds plenty of other information and reasons why he suspects optical media is used by Glacier.
So no, I don't see anything "meta" about this post.