Lightning Strike KOs Amazon, Microsoft EuroClouds 189
1sockchuck writes "A lightning strike has caused power outages at the major cloud computing data hubs for Amazon and Microsoft in Dublin, Ireland. The incident has caused downtime for many sites using Amazon's EC2 cloud computing platform and Microsoft's BPOS (Business Productivity Online Suite)."
Re:Cloud fail (Score:5, Informative)
For EC2, it's only distributed if you pay to have your "service" running in more than one availability zone.
Serves them right (Score:2, Informative)
I'd call a few lightning strikes the least of the punishments those data centers - and the entire infrastructures to which they're attached - really deserve.
How shocking! (Score:5, Informative)
Re:at that level the safety's tipped foreing a man (Score:5, Informative)
Also Surge Protectors can't really take a direct lighting strike.
But lightning arrestors can. [iceradioproducts.com] A serious lightning arrestor is a spark gap (sometimes open air, sometimes in an inert gas) to ground, with a very heavy cable or busbar to multiple ground rods, and no sharp turns in the path to ground. This is followed up by an inductor which is a few turns of busbar. This gear is usually placed where power lines or antenna feeds enter a building. MOV-type protection is further downstream.
Antenna towers are struck by lightning frequently, and the associated radio gear routinely continues to operate. This isn't rocket science. It's big hunks of copper.
The Hartford Steam Boiler Inspection and Insurance Company, in their publication "The Locomotive" (they've been at this since 1867) has a good article on lightning protection. [google.com] Hartford Steam Boiler insures not only against boiler explosions, but things like downtime due to lightning strikes. But only after their inspectors (they have 1200) have visited the plant and are satisfied with the equipment.
A question to ask your "cloud" provider - who handles your business interruption insurance, and do they inspect your faclities?
Re:Cloud fail (Score:4, Informative)
Cloud computing is a buzzword meaning "don't run your own hardware, run your business on someone elses". Which might mean anything from a virtual server that you manage at one end of the sophistication scale to a SaaS product at the other.
All sorts of aspects of this are optional. Including:
1. Whether or not you manage the underlying operating system - including things like security patches and hardening. You can choose a cloud computing provider that has sysadmins deal with that for you and just run the application yourself; they are a LOT more expensive than Amazon.
2. How much effort your provider puts into making their systems geographically redundant. Few will talk openly about this; I'm prepared to bet hard cash this is because the vast majority that offer you a virtualised server are just using a web interface to expose a fairly vanilla Xen-with-a-SAN infrastructure to the world with everything sat in one place. Providers that will run the OS for you and can honestly say their infrastructure accounts for complete data centre loss are like hen's teeth.
3. If you've gone for a SaaS provider - how much effort their developers went to to ensure their application can stand up to everything up to and including total loss of a data centre. And whether or not they test for such an occurrence.
Re:So Cloud v Cloud.... (Score:4, Informative)
That might be true if Amazon didn't have multiple AZs in single datacenters.
The fault isn't necessarily Amazon's for stuff like this. The whole point of cloud infrastructure is that you use many cheaper instances to scale load and provide high availability caused by the failure of any one (or group of) node. Take Netflix, for example. While they do have their share of outages, they were completely unaffected by Amazon's big EC2 failure a few months ago, despite the fact that a significant portion of Netflix' infrastructure was hosted out of the affected region. Why? Because they built failure into their system, to the extent where they have a process that goes around killing random instances to keep them on their toes. They've planned for and built their system around the possibility that large chunks of the system might just up and vanish without warning.
If you're building a large-scale cloud system, *geographic* diversity should obviously be a part of any high availability plan. I'd also say that having provider diversity isn't a bad idea, but it seems like a lot of big cloud customers just stick with one provider.
Re:So Cloud v Cloud.... (Score:4, Informative)
I live in Dublin, and that was some seriously targeted lightning. No sign of storms here, that I saw...