A Uber detalhou como mantém seus clusters OpenSearch operacionais durante falhas de zona usando grupos de isolamento (IGs) e alocação forçada de shards, garantindo resiliência sem perda de dados.
- Grupos de isolamento lógicos garantem distribuição igualitária de nós entre domínios de falha.
- Forced allocation awareness evita tempestades de rebalanceamento durante falhas de zona.
- 5 nós gerenciadores com auto-shrink voting toleram falha de zona + nó adicional.
- 100% de atribuição de shards e saúde verde consistente em clusters Tier 3+ da Uber.
Contexto: O problema das falhas de zona no OpenSearch
Zonas físicas em datacenters frequentemente possuem quantidades desbalanceadas de nós. Esse desequilíbrio afeta a lógica de allocation awareness do OpenSearch, deixando clusters em estado amarelo com shards não atribuídos. Mapear shards para zonas físicas gera disk skew e hot nodes quando a capacidade das zonas é desigual.
A solução: Grupos de isolamento (IGs)
A Uber introduziu grupos de isolamento como uma camada lógica entre os domínios de falha físicos e a lógica de alocação do OpenSearch. Cada IG recebe um número igual de nós, independentemente de quantas zonas físicas estão abaixo. Um nó mantém sua associação ao IG mesmo após substituições de hardware. A maioria dos serviços da Uber, incluindo OpenSearch, executa 3 IGs, de modo que uma zona mapeia exatamente para um IG e uma falha de zona remove no máximo um terço da capacidade.
Cada índice é executado com no mínimo 2 réplicas (3 cópias de shard no total), uma por IG, fornecendo resiliência básica contra a perda de um único grupo.
Alocação forçada de shards com Forced Allocation Awareness
Por padrão, o OpenSearch responde à falta de cópias de shard rebalanceando rapidamente entre os nós restantes, o que pode sobrecarregar I/O, CPU e rede. A Uber resolve isso com alocação forçada de shards: o cluster é configurado com todos os valores de atributo de awareness esperados desde o início, não apenas os visíveis no momento. Quando um IG desaparece, o OpenSearch percebe a lacuna e não superaloca para os outros grupos, mantendo os shards afetados não atribuídos. O cluster fica amarelo em vez de iniciar uma tempestade de rebalanceamento. Os shards só são reatribuídos quando o IG falho retorna ou um operador atualiza explicitamente a configuração.
Resiliência dos nós gerenciadores
A Uber utiliza 5 nós gerenciadores (cluster manager) em vez dos 3 usuais, combinado com a configuração <code>cluster.auto_shrink_voting_configuration</code>. Uma falha de zona pode derrubar até 2 nós gerenciadores, restando 3; a configuração de votação encolhe automaticamente para esses 3, elegendo um novo primário com quorum de 2 de 3. Uma falha subsequente de um único nó ainda deixa 2 nós, suficientes para manter o quorum e o cluster gravável — algo que uma configuração padrão de 3 gerenciadores não sobreviveria.
Resultados e adoção prática
A abstração de IG eliminou problemas de estado amarelo e falhas de atribuição de shards causados por zonas físicas desiguais. Agora há 100% de atribuição de shards e saúde verde consistente. A abordagem também resolve disk skew e hot nodes associados à assimetria de zonas. Funciona para todos os clusters OpenSearch e Elasticsearch Tier 3+ da Uber, baseando-se em funcionalidades nativas como shard allocation awareness e auto-shrink voting, sem necessidade de fork personalizado.
Engenheiros que executam clusters OpenSearch ou Elasticsearch multi-zona podem adotar o padrão de forced awareness sem as ferramentas específicas da Uber (Odin). Os requisitos são: distribuição uniforme de nós entre valores de atributo de awareness fixos e explicitamente declarados, pelo menos 3 cópias de shard mapeadas um-para-um para domínios de falha, e um número ímpar de nós gerenciadores (5 em vez de 3) com auto-shrink voting ativado.
- Distribuição uniforme de nós entre valores de atributo de awareness fixos
- Pelo menos 3 cópias de shard (1 primário + 2 réplicas) mapeadas para domínios de falha
- 5 nós gerenciadores com auto-shrink voting habilitado
- Configuração de forced allocation awareness com todos os valores esperados
Impacto no mercado de TI brasileiro
Empresas brasileiras que operam clusters OpenSearch ou Elasticsearch em múltiplas zonas de disponibilidade podem se beneficiar diretamente dessa abordagem. A adoção de grupos de isolamento lógicos e alocação forçada de shards reduz significativamente o risco de interrupções durante falhas de infraestrutura, um cenário comum em provedores de nuvem locais. Além disso, a estratégia não requer mudanças profundas na stack, sendo aplicável a clusters existentes com ajustes de configuração.
| Componente | Configuração padrão | Configuração Uber |
|---|---|---|
| Nós gerenciadores | 3 | 5 |
| Réplicas por índice | 1 (2 cópias) | 2 (3 cópias) |
| Awareness de alocação | Automático | Forçado com valores esperados |
| Grupos de isolamento | N/A | 3 IGs lógicos |
| Comportamento pós-falha | Rebalanceamento imediato | Shards não atribuídos até recuperação |
Arraste para o lado para ver toda a tabela.
Perguntas Frequentes (FAQ)
O que são grupos de isolamento (IGs) no OpenSearch?
São uma camada lógica que garante distribuição igualitária de nós entre domínios de falha, independentemente do número de zonas físicas.
Como a Uber evita o rebalanceamento durante uma falha de zona?
Usando forced allocation awareness: o cluster espera todos os valores de atributo de awareness desde o início e não realoca shards para grupos restantes quando um IG desaparece.
Quantos nós gerenciadores a Uber usa e por quê?
Usa 5 nós gerenciadores para tolerar a perda de até 2 nós em uma falha de zona e ainda manter quorum após uma falha adicional de nó.
Essa abordagem funciona apenas no OpenSearch ou também no Elasticsearch?
Funciona em ambos, desde que as versões suportem shard allocation awareness e auto-shrink voting.
Preciso usar a plataforma Odin da Uber para implementar?
Não. O padrão pode ser implementado com configurações nativas do OpenSearch, sem dependência de ferramentas específicas da Uber.
Fontes e referencias
- Documentação oficial do OpenSearch sobre Shard Allocation Awareness (opensearch.org)
- Uber Engineering Blog (referência ao artigo original) (www.uber.com)