If you have a single point of failure for data and "snapshots" then you should explain that very clearly to customers. Moreover, as I understand it, competitors like AWS do not have such a single point of failure (ie: EBS Snapshots are on S3 and not EBS) so using the same terminology/workflow is going to cause confusion.
Postmortem of the failure of one hosting storage unit on Jan. 8, 2020
11–20 of 83 posts
Re: Postmortem of the failure of one hosting storage unit on Jan. 8, 2020
#12Re: Postmortem of the failure of one hosting storage unit on Jan. 8, 2020
#13An old highrise is filled with ten thousands of old second hand server blades, floors by floors of equpiment prolifically producing waste heat. A sure recipe for disaster?
Sure!
A wrongly installed fuse at one phase in the building made one phase burn out too early. I saw a picture of an archeological breaker equipment. They fixed that.
However the missing phase destroyed the compressor motors of their cooling systems. Temperature crept up higher and higher. They had to turn off whole floors of servers. When they believed they fixed the problem, they turned on row by row. Renters then frantically tried to copy what they had on the servers and the half repaired cooling system was overtaxed and they had to turn off servers again.
Edit: made some details more specific.
Re: Postmortem of the failure of one hosting storage unit on Jan. 8, 2020
#14This is basically the stuff of nightmares. You can't really fault them for the zfs version being so old the feature they needed wasn't yet implemented, because the machine was literally part of the last batch to be upgraded. The root cause is just some random hardware failure that can't be anticipated. Just bad luck. Beyond radically changing how their core infrastructure works, doesn't seem like there was a lot they…
It's not like the backups have to be customer available, use them to increase availability and decrease MTTR. In this situation, even with a daily snapshot they could have had customers up and running with yesterday's data while they took their time recovering the old system and not moving boxes around and bypassing safeties for speed. How much did five days of panic cost them? Their customers? Their brand?
I feel like they read something about how S3 has at least three copies of everything, and then did that locally with ZFS, instead of accounting for all the other failures that can happen that the S3 design accounts for.
You are right, there isn't a whole lot that could have been done without radically changing their infrastructure, but they're clearly at the scale and have the hardware available to make better choices than they have.
Re: Postmortem of the failure of one hosting storage unit on Jan. 8, 2020
#15Case in point.
Re: Postmortem of the failure of one hosting storage unit on Jan. 8, 2020
#16Would it be possible to backup the precious metadata separately to mitigate the issue?
Re: Postmortem of the failure of one hosting storage unit on Jan. 8, 2020
#17The take-away here is clear: don't trust Gandi with anything you care about.
Re: Postmortem of the failure of one hosting storage unit on Jan. 8, 2020
#18This is basically the stuff of nightmares. You can't really fault them for the zfs version being so old the feature they needed wasn't yet implemented, because the machine was literally part of the last batch to be upgraded. The root cause is just some random hardware failure that can't be anticipated. Just bad luck. Beyond radically changing how their core infrastructure works, doesn't seem like there was a lot they…
There was one, obvious thing they could have done. Backups. ZFS even makes it easy. They state they have triple redundancy on their servers. Pull 1/2 of the drives and have backups. ZFS supports streaming snapshots (maybe not on this particularly old system). It sounds like they have multiple ZFS servers per datacenter, so given 2 servers, they could use 50% of the storage on each nodes as a backup of the other node.…
Intangibles. Whenever you go to talk to management or even co-workers about this stuff, they look at you like you are crazy. I think it is just human nature to not even think that something could go wrong, let alone make decisions based on this.
Re: Postmortem of the failure of one hosting storage unit on Jan. 8, 2020
#19I’m no ZFS expert, but it must have been incredibly stressful, if not mildly terrifying, going that far down the rabbit hole with customer data on the line. I have a bad feeling someone is going to read their write up and tweet at them, “Why didn’t you use -xyz switch, it fixes exactly this issue in 12 seconds”. Indeed it appears that the option they needed existed, but only in a later version of ZFS than they were r…
I don't have hundreds customers, but I handle hundreds of TiB of data (for a science lab). Issues occur from time to time, and I can assure that these times are very stressful. I am grateful to rely on ZFS, because yet I have never lost any data from people (datasets are often around 10TiB).
Re: Postmortem of the failure of one hosting storage unit on Jan. 8, 2020
#20And now their postmortem blog post is down with a 503 error. Doesn’t exactly fill me with confidence about their abilities.
Their handling of the issue on Twitter was enough for to decide to move my domain names away from them when their renewal is due.