7 ms·

Lessons from Rackspace's downtime

36 points by jacobian 17y ago

vicaya 17y ago
When will the rest of the industry start to bundle a battery on every server, a la laptops and Google servers, so that PDU glitches like this would be no big deal?
- showerst 17y ago
  Honest question, would a normal battery be able to keep a decent server running through a 5 minute outage? I was under the impression that google adds something like 9v's to last a few seconds through a flicker, not any sustained outage. (And all of that's assuming your network stack stays up, and things like routers/firewalls survive...)
  - jrockway 17y ago
    The idea is not to be reachable during the outage, it's to avoid filesystem corruption, not lose data in memcached, etc. These things are recoverable, of course, but if you can avoid them for the cost of a $2 battery... then why not?
- mmt 17y ago
  Never, I hope. As someone who actually touches the hardware in datacenters, ever, I'd like not to have the added fire and hazmat risk of that much lithium and non-EPSable power everywhere.
  - tesseract 17y ago
    Lithium? Don't lead-acid batteries still have a vastly better energy storage to cost ratio?
    - mmt 17y ago
      I would expect not in so tiny a size, no.
davidu 17y ago
Five nines is impossible Really. It’s just not going to happen. Actually, it is going to happen. One individual part may fail more than 99.999% of the time, but overall system integrity can certainly be designed with greater than 99.999% uptime. Just get a second datacenter, get a second transit provider. Just as folks scale horizontally, you can built out reliability into the many many 9's such that when one component fails, the overall system integrity isn't impacted. It's not easy, and not always cheap, but it's quite doable.
- mmt 17y ago
  Perhaps "impossible" is overly dramatic, but "economically impractical" may, in this context (general purpose networked computing), be the same thing. It seems to me that "five nines" is achieved more often with careful use of definitions, rather than careful engineering. Low-hanging fruit are scheduled maintenance and degraded performance. Otherwise, wouldn't Tandem have been wildly successful?
- bestes 17y ago
  Complexity costs. It costs money and it costs downtime. Look at Google: they have redundant everything, super-smart people, super good operations and still have some downtime.
- jacobian 17y ago
  How long does it take to fail over to a second data center? Can you do it in less than 26 seconds? I can't.
  - smhinsey 17y ago
    According to Amazon, EC2 can remove a server from an Elastic Load Balancer rotation at a polling interval of 5 seconds. You can pool servers in different availability zones into the same ELB. I'm not sure the question even makes sense in that context, which I sort of view as the logical extreme of what davidu wrote.
    - ensignavenger 17y ago
blhack 17y ago
I was actually a bit dissatisfied with how slicehost (part of rackspace, or at least using their DC) handled this last night. If something like this goes down, I want to know what is up within minutes of it happening. At least a "Yeah, things are going wrong. It's our fault, not yours.". I checked slicehost's website but...nothing. The only way I even knew that others were having a problem was by checking twitter. Seriously, guys...one of the things behind the pane of glass that says "break in case of emergency" needs to a sheet of paper with big red bold letters on it that says "TELL THE CUSTOMERS WHAT IS HAPPENING RIGHT NOW! DO NOT WAIT!" /yeah, yeah, I'm over-reacting. It's just really frustrating to be completely in the dark when something goes wrong, even if it is only for a few minutes.
- brk 17y ago
  Sounds good in theory... However, in a couple of my career cycles I've managed data centers and/or server farms upon which lots and lots of companies relied. Many times these unexpected outages are not always easy to diagnose even a rough root cause quickly. Sometimes you don't know if it's your issue, or an upstream issue, and so on. So, you put out a statement 5 seconds after and outage, and, oops, you misdiagnosed it. Now you get to deal with the shitty customers who want to play 1000 questions about why you told them it was a transfer switch when it turns out it was really a main breaker. Not that it matters much in the end. You're damned if you do, damned if you don't, but most of the time it's better overall to release an accurate statement later than a wrong statement early.
  - lsc 17y ago
    I think "having a problem, not sure what just yet" is a perfectly acceptable thing to say.
    - blhack 17y ago
      Exactly. I liken in to twitter's failwhale. What it is telling you is that something has gone wrong, and that it has nothing to do with you.
lsc 17y ago
wrong lesson. The right lesson is "have more than one data center, use automatic failover"
- lsc 17y ago
  to be clear, the above is meant as the lesson to the customer, not rackspace. It would be very nearly impossible for rackspace to make their virtual servers stay up if a whole data center went down. It's quite difficult to keep a VPS up when even just the hardware it is on goes down.
- ars 17y ago
  How? You need to put a switchover device somewhere. And that device (or NOC, or power, or router feeding it), can fail. Unless you want to give you dns addresses a 10 second ttl, and update them as needed. Really, how? I would love to do this, but I can't think of any method that does not have a single point of failure somewhere. (And I'm not as big as google with my own network lines, something that a regular budget can do.)
  - lsc 17y ago
    BGP. the idea is that you could have a data center in San Jose, connected via he.net, and another in, say, phoenix, connected via Cogent. you announce the same /24 out each data center... if one goes down, it stops announcing and all traffic goes to the other data center. The problem is that it's not a cheap answer, and that your application needs to be able to deal with queries going to either data center at any time. another option I've seen people use which is not nearly as robust but still 'automatic' is to have two authoritative nameservers; one at each location. But the nameserver at location 1 resolves all A records to IPs at location 1. At location 2, the nameserver is configured to resolve all A records to IP addresses at location 2. (of course, this has all the dns caching issues as setting the TTL to 10 minutes) A third option would be to have some sort of redirector on a network that is made redundant via BGP, then have some sort of hook so you can change the target of the redirector. But I don't know of anyone offering that service for cheap.
- mseebach 17y ago
justlearning 17y ago
I received this email an hour back from Rackspace: At approximately 12:29am CST this morning, our Dallas - Fort Worth (DFW) data center experienced a power disruption, and consequently an interruption of our services. The power disruption was the result of issues during a maintenance effort that was scheduled and expected to be non-impacting. This summer our DFW facility had power issues, and as a result, we invested significant resources to improve all aspects of our power systems. Last night, during one of these steps, we encountered issues and had a brief loss in power. The power disruption was approximately 5 minutes in duration. Despite this short power disruption, many customers experienced downtime that was significantly longer. Since the power disruption hit the core of many of our cloud services, recovery of full operations required more effort than simple recovery of power. The experience you had last night is not acceptable to us. Here is what we know about the events: · The scheduled maintenance was planned to occur from 12:05am - 6:05am CST in our DFW data center. This maintenance is part of a preventative maintenance schedule for several PDUs in UPS Cluster G at the DFW datacenter. The PDUs were down for a total of 5 minutes before power was restored. At approximately 12:29am CST, all PDUs behind UPS Cluster G lost power. · Although the power outage was very brief (5 minutes), it forced a hard re-boot to occur on a portion of our cloud infrastructure. As our engineers worked to bring hardware back online, we experienced several unforeseen hardware failures. Further complicating our recovery effort, the incident also created internal DNS issues, which caused additional delays. With that said, the vast majority of cloud customers affected by this outage had service restored within one hour's time (many in as little as five minutes); however, depending upon the service, a few customers experienced service interruptions for up to few hours. Here is how we plan to deal with it: · We have invested massively in the DFW facility to ensure it delivers at a level you expect from Rackspace - despite last night, we feel very good about our plan and have high confidence in the DFW facility - clearly we have to prove it. · We are reviewing our maintenance notifications - we typically do not share information on expected non-impacting events, but clearly we need to ensure we calibrate these events and are fully transparent. · We are reviewing our procedures and systems for quickly resuming cloud operations when an unexpected event like this occurs - unexpected events will happen, our job is to minimize their impacts. We live by high standards and clearly have not lived up to them. We welcome any feedback. If you would like a call from me, or anyone on our senior team to discuss these issues personally, please reply with a phone number. We have work to do to earn back your trust. We will not rest until we have.
joeycfan 17y ago
Ok, but what is the lesson from DEMONOID's downtime? Apparently the whole thing is is dependent on one guy who is nowhere to be found. Whats up with that?

36 points by jacobian 17y ago

When will the rest of the industry start to bundle a battery on every server, a la laptops and Google servers, so that PDU glitches like this would be no big deal?

showerst 17y ago
Honest question, would a normal battery be able to keep a decent server running through a 5 minute outage? I was under the impression that google adds something like 9v's to last a few seconds through a flicker, not any sustained outage. (And all of that's assuming your network stack stays up, and things like routers/firewalls survive...)
- jrockway 17y ago
  The idea is not to be reachable during the outage, it's to avoid filesystem corruption, not lose data in memcached, etc. These things are recoverable, of course, but if you can avoid them for the cost of a $2 battery... then why not?
mmt 17y ago
Never, I hope. As someone who actually touches the hardware in datacenters, ever, I'd like not to have the added fire and hazmat risk of that much lithium and non-EPSable power everywhere.
- tesseract 17y ago
  Lithium? Don't lead-acid batteries still have a vastly better energy storage to cost ratio?
  - mmt 17y ago
    I would expect not in so tiny a size, no.

davidu 17y ago

Five nines is impossible Really. It’s just not going to happen. Actually, it is going to happen. One individual part may fail more than 99.999% of the time, but overall system integrity can certainly be designed with greater than 99.999% uptime. Just get a second datacenter, get a second transit provider. Just as folks scale horizontally, you can built out reliability into the many many 9's such that when one component fails, the overall system integrity isn't impacted. It's not easy, and not always cheap, but it's quite doable.

mmt 17y ago
Perhaps "impossible" is overly dramatic, but "economically impractical" may, in this context (general purpose networked computing), be the same thing. It seems to me that "five nines" is achieved more often with careful use of definitions, rather than careful engineering. Low-hanging fruit are scheduled maintenance and degraded performance. Otherwise, wouldn't Tandem have been wildly successful?
bestes 17y ago
Complexity costs. It costs money and it costs downtime. Look at Google: they have redundant everything, super-smart people, super good operations and still have some downtime.
jacobian 17y ago
How long does it take to fail over to a second data center? Can you do it in less than 26 seconds? I can't.
- smhinsey 17y ago
  According to Amazon, EC2 can remove a server from an Elastic Load Balancer rotation at a polling interval of 5 seconds. You can pool servers in different availability zones into the same ELB. I'm not sure the question even makes sense in that context, which I sort of view as the logical extreme of what davidu wrote.
  - ensignavenger 17y ago

blhack 17y ago

I was actually a bit dissatisfied with how slicehost (part of rackspace, or at least using their DC) handled this last night. If something like this goes down, I want to know what is up within minutes of it happening. At least a "Yeah, things are going wrong. It's our fault, not yours.". I checked slicehost's website but...nothing. The only way I even knew that others were having a problem was by checking twitter. Seriously, guys...one of the things behind the pane of glass that says "break in case of emergency" needs to a sheet of paper with big red bold letters on it that says "TELL THE CUSTOMERS WHAT IS HAPPENING RIGHT NOW! DO NOT WAIT!" /yeah, yeah, I'm over-reacting. It's just really frustrating to be completely in the dark when something goes wrong, even if it is only for a few minutes.

brk 17y ago
Sounds good in theory... However, in a couple of my career cycles I've managed data centers and/or server farms upon which lots and lots of companies relied. Many times these unexpected outages are not always easy to diagnose even a rough root cause quickly. Sometimes you don't know if it's your issue, or an upstream issue, and so on. So, you put out a statement 5 seconds after and outage, and, oops, you misdiagnosed it. Now you get to deal with the shitty customers who want to play 1000 questions about why you told them it was a transfer switch when it turns out it was really a main breaker. Not that it matters much in the end. You're damned if you do, damned if you don't, but most of the time it's better overall to release an accurate statement later than a wrong statement early.
- lsc 17y ago
  I think "having a problem, not sure what just yet" is a perfectly acceptable thing to say.
  - blhack 17y ago
    Exactly. I liken in to twitter's failwhale. What it is telling you is that something has gone wrong, and that it has nothing to do with you.

lsc 17y ago

wrong lesson. The right lesson is "have more than one data center, use automatic failover"

lsc 17y ago
to be clear, the above is meant as the lesson to the customer, not rackspace. It would be very nearly impossible for rackspace to make their virtual servers stay up if a whole data center went down. It's quite difficult to keep a VPS up when even just the hardware it is on goes down.
ars 17y ago
How? You need to put a switchover device somewhere. And that device (or NOC, or power, or router feeding it), can fail. Unless you want to give you dns addresses a 10 second ttl, and update them as needed. Really, how? I would love to do this, but I can't think of any method that does not have a single point of failure somewhere. (And I'm not as big as google with my own network lines, something that a regular budget can do.)
- lsc 17y ago
  BGP. the idea is that you could have a data center in San Jose, connected via he.net, and another in, say, phoenix, connected via Cogent. you announce the same /24 out each data center... if one goes down, it stops announcing and all traffic goes to the other data center. The problem is that it's not a cheap answer, and that your application needs to be able to deal with queries going to either data center at any time. another option I've seen people use which is not nearly as robust but still 'automatic' is to have two authoritative nameservers; one at each location. But the nameserver at location 1 resolves all A records to IPs at location 1. At location 2, the nameserver is configured to resolve all A records to IP addresses at location 2. (of course, this has all the dns caching issues as setting the TTL to 10 minutes) A third option would be to have some sort of redirector on a network that is made redundant via BGP, then have some sort of hook so you can change the target of the redirector. But I don't know of anyone offering that service for cheap.
mseebach 17y ago

justlearning 17y ago

I received this email an hour back from Rackspace: At approximately 12:29am CST this morning, our Dallas - Fort Worth (DFW) data center experienced a power disruption, and consequently an interruption of our services. The power disruption was the result of issues during a maintenance effort that was scheduled and expected to be non-impacting. This summer our DFW facility had power issues, and as a result, we invested significant resources to improve all aspects of our power systems. Last night, during one of these steps, we encountered issues and had a brief loss in power. The power disruption was approximately 5 minutes in duration. Despite this short power disruption, many customers experienced downtime that was significantly longer. Since the power disruption hit the core of many of our cloud services, recovery of full operations required more effort than simple recovery of power. The experience you had last night is not acceptable to us. Here is what we know about the events: · The scheduled maintenance was planned to occur from 12:05am - 6:05am CST in our DFW data center. This maintenance is part of a preventative maintenance schedule for several PDUs in UPS Cluster G at the DFW datacenter. The PDUs were down for a total of 5 minutes before power was restored. At approximately 12:29am CST, all PDUs behind UPS Cluster G lost power. · Although the power outage was very brief (5 minutes), it forced a hard re-boot to occur on a portion of our cloud infrastructure. As our engineers worked to bring hardware back online, we experienced several unforeseen hardware failures. Further complicating our recovery effort, the incident also created internal DNS issues, which caused additional delays. With that said, the vast majority of cloud customers affected by this outage had service restored within one hour's time (many in as little as five minutes); however, depending upon the service, a few customers experienced service interruptions for up to few hours. Here is how we plan to deal with it: · We have invested massively in the DFW facility to ensure it delivers at a level you expect from Rackspace - despite last night, we feel very good about our plan and have high confidence in the DFW facility - clearly we have to prove it. · We are reviewing our maintenance notifications - we typically do not share information on expected non-impacting events, but clearly we need to ensure we calibrate these events and are fully transparent. · We are reviewing our procedures and systems for quickly resuming cloud operations when an unexpected event like this occurs - unexpected events will happen, our job is to minimize their impacts. We live by high standards and clearly have not lived up to them. We welcome any feedback. If you would like a call from me, or anyone on our senior team to discuss these issues personally, please reply with a phone number. We have work to do to earn back your trust. We will not rest until we have.

joeycfan 17y ago

Ok, but what is the lesson from DEMONOID's downtime? Apparently the whole thing is is dependent on one guy who is nowhere to be found. Whats up with that?