Live data from Hacker News

Google Cloud Networking Incident Postmortem

status.cloud.google.com

181–190 of 190 posts

Re: Google Cloud Networking Incident Postmortem

#181

Earlier quoted context omitted.

> Debugging the problem was significantly hampered by failure of tools competing over use of the now-congested network. Man that's got to suck.

This is inconceivable ... they don't have an OOB management network?

Still have to get to it.

Re: Google Cloud Networking Incident Postmortem

#182

Earlier quoted context omitted.

Is there anything that can be done to mitigate that? E.g. give ssh network and the daemon top cpu priority?

Some equipment will auto-revert to a last known good configuration if you don't approve new changes within a window... though high CPU could lock that process up..

in this case the old configuration was lost, it took an hour to rebuild because tooling normally used to rebuild it for testing was unavailable and building had to be done locally, using a single machine someone ssh-ed into, and that just takes a while. Luckily, a person was around who knew how to do the rebuild without fancy tooling.

Re: Google Cloud Networking Incident Postmortem

#183

Earlier quoted context omitted.

> Debugging the problem was significantly hampered by failure of tools competing over use of the now-congested network. Man that's got to suck.

This is inconceivable ... they don't have an OOB management network?

That's less of an issue. Issue is in how you classify traffic on a network. e.g. Gmail, it's helpful to incident response, should it be used for OOB management.

Re: Google Cloud Networking Incident Postmortem

#184
post #29
post #19

Earlier quoted context omitted.

> I agree, but it’s pretty standard SLA verbiage (from the telco/bandwith provider days) to require the customer to request/register the SLA violation to benefit. FiOS has proactively given me per-day refunds of service without notification on my part. Weird to me that Verizon acts better than Google in this case.

Interesting, which kind of fios account? (residential/SMB/data center interconnect) That’s ideally how it should be!

Residential.

Re: Google Cloud Networking Incident Postmortem

#185
post #149

I was curious to know how cascading failures in one region effected other regions. Impact was " ...increased latency, intermittent errors, and connectivity loss to instances in us-central1, us-east1, us-east4, us-west2, northamerica-northeast1, and southamerica-east1." Answer, and the root cause summarized: Maintenance started in a physical location, and then "... the automation software created a list of jobs to des…

At some point people realized servers are prone to failure. They then started deploying their system redundantly to multiple servers in the data center (AZ) to increase availability. This helped, but created consistency issues. To fix this people started building multi-server software systems, creating dependencies across servers that weakened overall availability. At some point people realized multi-server systems w…

At some point the system realized people are prone to failure. It then started deploying itself redundantly without dependence on people. This helped, but the people interfered. To fix this the system started building self replicating physical instances, creating new dependencies on material that resulted in grey goo (or paper clips).

Re: Google Cloud Networking Incident Postmortem

#186
post #19

Earlier quoted context omitted.

> I agree, but it’s pretty standard SLA verbiage (from the telco/bandwith provider days) to require the customer to request/register the SLA violation to benefit. FiOS has proactively given me per-day refunds of service without notification on my part. Weird to me that Verizon acts better than Google in this case.

It’s easier to determine “this line was down thus everyone along the line was also down” than what Google is facing.

Google knows the affected regions and probably has very fine grained data around this. I mean, they can even tell you metrics about your instances, they don't have monitoring on their own infrastructure to determine impact radius?

Re: Google Cloud Networking Incident Postmortem

#187

Earlier quoted context omitted.

Is there anything that can be done to mitigate that? E.g. give ssh network and the daemon top cpu priority?

Yes - use taskset or isolcpus with other magic to put sshd on its own CPU core, or one core per CPU. Lots of HFT places do that.

That doesn't help if the problem is a bandwidth congestion problem.

Re: Google Cloud Networking Incident Postmortem

#188
post #186

Earlier quoted context omitted.

It’s easier to determine “this line was down thus everyone along the line was also down” than what Google is facing.

Google knows the affected regions and probably has very fine grained data around this. I mean, they can even tell you metrics about your instances, they don't have monitoring on their own infrastructure to determine impact radius?

It’s a vastly complex problem. What servers were impacted? For what percentage of the overall outage was each server impacted? During that time, was the server offline or simply slower than usual?

And the part that even Google can’t know, even if they somehow can assemble all of the above: did it matter? Not all servers are created equal.

Small wonder they’re letting customers drive their own reimbursement process.

Re: Google Cloud Networking Incident Postmortem

#189

Earlier quoted context omitted.

Yes - use taskset or isolcpus with other magic to put sshd on its own CPU core, or one core per CPU. Lots of HFT places do that.

That doesn't help if the problem is a bandwidth congestion problem.

It can help some amount, though. Bind the NIC interrupts to a small handful of cores. Or, ensure that ssh only works through a management NIC, and have that NIC bound to the same cores as sshd. You can get really fancy with these setups, especially when working with NUMA stuffs

Re: Google Cloud Networking Incident Postmortem

#190

Earlier quoted context omitted.

SLACreditRequestsAAS? Who's with me, all I need is a co-founder and an eight million dollar series A round to last long enough that a cloud provider buys us up before they actually have to pay out a request!

This exists for Comcast and some other stuff, I'll ask my roommate what the service is called.

It's https://www.asktrim.com/
Post reply on HN