AWS EBS 2011: tempestade de re-espelhamento

01 · CONTEXTO

Um cluster de blocos replicado e um plano de controle regional

Em abril de 2011, um incidente na região US East da AWS deixou parte dos volumes do Amazon EBS, todos em uma única zona de disponibilidade, incapazes de atender leituras e escritas. A AWS chama esses volumes de presos (stuck), e instâncias que tentavam usá-los também ficavam presas. Segundo a AWS, o evento teve várias causas-raiz que interagiram entre si.

O EBS replica os dados de cada volume em vários nós de um cluster. Os nós se falam por duas redes: uma primária, de alta largura de banda e usada na operação normal, e uma secundária, de replicação, com capacidade menor e papel de reserva.

A rede secundária não foi desenhada para carregar todo o tráfego da primária, e sim para dar conectividade confiável entre os nós do cluster.

Quando um nó perde a conexão com o nó para o qual replica, presume que o outro falhou e precisa achar um novo nó com espaço para a réplica, processo chamado re-espelhamento (re-mirroring). Num cluster funcionando normalmente, achar esse lugar leva milissegundos. Enquanto o dado é re-espelhado, o acesso a ele fica bloqueado até que se identifique uma nova réplica primária, e para a instância o volume parece preso.

Acima dos clusters há serviços de plano de controle que aceitam pedidos dos usuários e os propagam ao cluster certo. Existe um conjunto deles por região, distribuído entre as zonas, e eles também são a autoridade que elege a réplica primária de cada volume, pois, por consistência, só pode haver uma réplica primária por volume a qualquer momento.

1. As instâncias de computação enviam seus acessos ao nó que guarda a réplica primária, a gravável, do volume.

2. Os dados do volume são replicados em mais de um nó. Entre os nós há a rede primária, de uso normal, e a rede de replicação, de capacidade menor e reserva.

3. O plano de controle é a autoridade que elege qual réplica de cada volume é a primária.

4. Se um nó perde a conexão com o par, presume que ele falhou e procura outro nó com espaço. Enquanto isso o acesso ao dado fica bloqueado e o volume parece preso.

02 · O GATILHO

Uma mudança de rede e a tempestade de re-espelhamento

O gatilho foi uma mudança de configuração de rede, executada em 21 de abril durante atividades normais de escala numa única zona. Ela visava aumentar a capacidade da rede primária, e um dos passos era desviar o tráfego de um roteador redundante para o outro. O desvio foi executado incorretamente e o tráfego foi parar na rede redundante, de menor capacidade.

Para parte do cluster, isso significou ficar sem rede primária nem secundária funcionais. Diferente de uma interrupção de rede comum, a mudança desconectou as duas redes ao mesmo tempo e deixou os nós afetados completamente isolados uns dos outros.

Quando o desvio foi desfeito e a rede voltou, os nós começaram rapidamente a procurar espaço para re-espelhar. Como muitos volumes foram afetados ao mesmo tempo, a capacidade livre do cluster se esgotou e muitos nós ficaram num laço, procurando espaço sem parar. Isso levou a uma tempestade de re-espelhamento, e cerca de 13% dos volumes da zona estavam presos nesse ponto.

Dois fatores degradaram ainda mais o cluster no início. Primeiro, os nós que não achavam espaço não recuaram (back off) de forma agressiva o bastante e continuaram buscando repetidamente. Segundo, havia uma condição de corrida no código dos nós que, com probabilidade muito baixa, os derrubava ao fechar muitas requisições de replicação ao mesmo tempo. Nós falharam pelo bug e deixaram mais volumes para re-espelhar, o que alimentou a tempestade.

03 · O PLANO DE CONTROLE

Quando a falha de uma zona vira falha da região

O cluster degradado afetou de imediato o plano de controle. Sem espaço livre, o cluster ficou incapaz de atender pedidos da API de criar volume. Como essa API tinha um tempo-limite (timeout) longo, as chamadas lentas se acumularam e causaram esgotamento de threads no plano de controle.

O plano de controle usa um pool regional de threads. Quando as requisições enfileiradas o encheram, ele perdeu a capacidade de atender e passou a falhar pedidos também de outras zonas da região.

1. A mudança de rede desconectou as duas redes ao mesmo tempo, e muitos nós do cluster da zona ficaram isolados uns dos outros.

2. Com a rede de volta, os nós procuraram espaço para re-espelhar, a capacidade livre se esgotou e eles ficaram num laço de busca.

3. O cluster não atendia mais criar volume. Com tempo-limite longo, as chamadas lentas se acumularam e esgotaram as threads do plano de controle.

4. Como o pool de threads é regional, o plano de controle passou a falhar também pedidos vindos de outras zonas.

5. A equipe desativou os novos pedidos de criar volume na zona afetada, e as demais APIs relacionadas ao EBS se recuperaram.

6. Sem sucesso no re-espelhamento, retries e novos pedidos aumentaram as negociações com o plano de controle, e a carga causou um brown out dele. A equipe então desligou a comunicação entre o cluster e o plano de controle.

04 · A RECUPERAÇÃO

Contenção, capacidade nova e plano de controle dedicado

A equipe desenvolveu uma forma de impedir que servidores do cluster degradado contatassem outros em vão, sem afetar a comunicação essencial entre os nós. Depois dessa mudança, o cluster parou de degradar e mais volumes deixaram de correr risco de ficar presos. Antes dela, servidores caídos pela condição de corrida deixaram presos 5% adicionais dos volumes da zona, e o total de volumes presos na zona, ao implantar a mudança, era 13%.

A prioridade passou a ser pôr capacidade nova no cluster para que os volumes presos achassem espaço para novas réplicas. Dois desafios atrasaram isso.

Com capacidade suficiente, a equipe trabalhou para reabrir o acesso do plano de controle à zona. Havia um grande backlog de mudanças de estado a propagar nos dois sentidos, e o trabalho foi feito gradualmente para não afetar os volumes restaurados nem o plano de controle.

A recuperação dos volumes restantes exigiu um processo mais manual. A equipe havia feito snapshots deles para backups no S3 no início do evento, por precaução, e depois desenvolveu e testou código para restaurá-los a partir desses snapshots. Os volumes sem snapshot, que haviam sofrido falha de máquina, passaram por forense. Ao final, 0,07% dos volumes da zona não puderam ser restaurados de forma consistente.

05 · IMPACTO NOS CLIENTES

RDS e a diferença entre uma zona e várias

O RDS depende do EBS para armazenar banco e logs, então parte dos bancos da zona afetada ficou inacessível. Instâncias single-AZ ficam expostas a interrupções de uma zona, e no pico 45% delas tiveram I/O preso. Cada instância RDS usa vários volumes, e um I/O preso em qualquer um pode deixá-la inoperante até o volume ser restaurado.

No modo multi-AZ, o RDS replica dados de forma síncrona entre duas réplicas em zonas diferentes e foi projetado para detectar a interrupção e fazer failover. Mesmo assim, 2,5% dos bancos multi-AZ da região US East não fizeram failover automático. A causa principal foi a sucessão rápida de interrupção de rede e I/O preso no primário, que disparou um bug nunca encontrado antes. O primário ficou isolado, o failover automático arriscava perda de dados e foi necessária intervenção manual.

Para as aplicações, a AWS afirma que o impacto nas instâncias em execução ficou limitado à zona afetada, e que muitos usuários que usaram várias zonas não tiveram impacto significativo de disponibilidade. Já algumas aplicações, ou componentes críticos como o banco, ficam numa só zona, e outras espalham instâncias mas mantêm pontos únicos de falha críticos numa zona.

1. Exemplo genérico: o tráfego é distribuído entre aplicações em duas zonas, mas ambas dependem de um banco que existe em uma só zona.

2. O problema de armazenamento ficou limitado à zona afetada, atingindo as instâncias e o banco que dependiam de volumes dela.

3. A aplicação da outra zona não usa volumes da zona afetada, mas depende do banco que está lá, um ponto único de falha numa zona.

4. Uma implantação multi-zona robusta, sem componentes críticos presos a uma zona, permitiria à aplicação continuar sem impacto.

06 · LIÇÕES

Controle de sobrecarga e isolamento entre zonas

Contra a repetição da tempestade, a AWS aponta três proteções: mais capacidade excedente, com a qual o cluster teria absorvido os pedidos de re-espelhamento e evitado a tempestade; retry com recuo mais agressivo; e a correção da condição de corrida, cuja origem foi identificada.

Para que uma zona não afete o plano de controle em várias zonas, a AWS prometeu melhorar a lógica de timeout para evitar esgotamento de threads, tornar o plano de controle ciente das zonas para descartar carga de forma inteligente quando acima da capacidade (load shedding), e mover mais funções para serviços por cluster EBS, rodando na mesma zona do cluster.

A AWS também lembra o papel das regiões: elas são completamente isoladas entre si, e muitos usuários usam várias regiões para tolerância a falhas. Mas a AWS não replica dados entre regiões em nome dos usuários, e aproveitar esse isolamento exige esforço de quem constrói aplicações.