APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Contar réplicas não basta para avaliar continuidade. Identifica o que pode falhar em conjunto: host, rack, rede, zona, controlo e dependências da aplicação. Duas instâncias em zonas diferentes continuam vulneráveis se ambas precisam de uma única base de dados sem alternativa. A distribuição deve abranger o caminho funcional e o acesso aos dados. Depois calcula capacidade residual. Se cada uma de duas zonas suporta 600 pedidos por segundo e o pico acordado é 900, perder uma deixa apenas 600. Os 1200 normais não satisfazem o requisito de manter o pico durante essa falha. Os números são exemplos originais, não especificações de fornecedor.
Aplicação guiada
Static stability reduz dependência de criar recursos durante a crise: a capacidade sobrevivente já deve permitir o comportamento definido. Isso tem custo, que deve ser comparado com o impacto e os modos degradados aceites. Autoscaling pode ajudar, mas precisa de tempo, capacidade e mecanismos de controlo disponíveis. Em Kubernetes, topology spread constraints podem distribuir Pods; com DoNotSchedule, uma colocação incompatível pode ficar Pending. Relaxar para ScheduleAnyway altera a garantia, não cria recursos. Num cluster etcd fictício com dois votantes numa zona e um noutra, perder a zona com dois votos perde a maioria. O gestor deve pedir evidência da falha específica e da carga sobrevivente, em vez de aceitar um diagrama com várias caixas.
Capacidade normal de 1200 pedidos/s pode tornar-se 600 quando uma zona falha.
Armadilhas comuns
Réplicas como independência; soma normal como margem após falha; autoscaling imediato; preferência como garantia.
Tópicos relacionados: Objetivos e impacto no serviço · Quorum e isolamento de escritores · Replicação, promoção e redundância
Demonstra que o caminho completo e a capacidade sobrevivem à falha definida.
Referência: Static stability and capacity during failure · DR HA 2026-09; Pacemaker 3.0, etcd 3.6, PostgreSQL 18 and selected Kubernetes/AWS behavior