Tornar todos os aspetos redundantes

Integre a redundância na sua aplicação, para evitar ter pontos únicos de falha

Uma aplicação resiliente contorna as falhas. Identifique os caminhos críticos na sua aplicação. Há redundância em cada um dos pontos no caminho? Quando um subsistema falhar, o aplicativo fará failover para outra coisa?

Em uma implementação perfeita, adicionar redundância uniforme pode aumentar exponencialmente a disponibilidade do seu sistema. Por exemplo, imagine que você tem N componentes equivalentes e igualmente equilibrados que:

• pode funcionar de forma independente e simultaneamente removido da piscina
• têm estado idêntico ou nenhum estado
• não têm nenhum trabalho em andamento que seja permanentemente perdido durante o mau funcionamento
• são idênticos em capacidades
• não têm dependências uns dos outros
• lida com a redução da capacidade sem avarias adicionais

Se cada componente individual tiver uma disponibilidade de , então a disponibilidade geral do Asistema pode ser calculada usando a fórmula 1 - (1 - A)^N.

Recomendações

Considere os requisitos empresariais. A quantidade de redundância incorporada num sistema pode afetar o custo e a complexidade. Sua arquitetura deve ser informada pelos requisitos de negócios, como RTO (Recovery Time Objetive, objetivo de tempo de recuperação) e RPO (Recovery Point Objetive, objetivo de ponto de recuperação). Você também deve considerar seus requisitos de desempenho e a capacidade de sua equipe de gerenciar conjuntos complexos de recursos.

Considere arquiteturas multizona e multirregião. Certifique-se de entender como as zonas e regiões de disponibilidade fornecem resiliência e diferentes conjuntos de compensações arquitetônicas.

As zonas de disponibilidade do Azure são conjuntos isolados de data centers dentro de uma região. Usando zonas de disponibilidade, você pode ser resiliente a falhas de um único data center ou de uma zona de disponibilidade inteira. Você pode usar zonas de disponibilidade para fazer compensações entre custo, redução de riscos, desempenho e capacidade de recuperação. Por exemplo, quando você usa serviços redundantes de zona em sua arquitetura, o Azure fornece replicação automática de dados e failover entre instâncias separadas geograficamente, o que reduz muitos tipos diferentes de riscos.

Se você tiver uma carga de trabalho de missão crítica e precisar reduzir o risco de uma interrupção em toda a região, considere uma implantação em várias regiões. Embora as implantações em várias regiões isolem você contra desastres regionais, elas têm um custo. As implantações em várias regiões são mais caras do que uma implantação em uma única região e são mais complicadas de gerenciar. Você precisará de procedimentos operacionais para lidar com failover e failback. Dependendo dos seus requisitos de RPO, talvez seja necessário aceitar um desempenho ligeiramente inferior para habilitar a replicação de dados entre regiões. O custo adicional e a complexidade podem ser justificados para alguns cenários de negócios.

Para saber mais sobre como projetar sua solução para usar zonas e regiões de disponibilidade, consulte Recomendações para usar zonas e regiões de disponibilidade.

Coloque VMs atrás de um balanceador de carga. Não utilize só uma VM para as cargas de trabalho fundamentais. Em vez disso, coloque várias VMs atrás de um balanceador de carga. Se qualquer uma das VMs ficar indisponível, o balanceador de carga distribui o tráfego pelas restantes VMs em bom estado de funcionamento.

Replique as bases de dados. O Banco de Dados SQL do Azure e o Azure Cosmos DB replicam automaticamente os dados dentro de uma região e podem ser configurados para replicar entre zonas de disponibilidade para maior resiliência. Você também pode optar por habilitar a replicação geográfica entre regiões. A replicação geográfica para o Banco de Dados SQL do Azure e o Azure Cosmos DB cria réplicas secundárias legíveis de seus dados em uma ou mais regiões secundárias. Se ocorrer uma interrupção na região primária, o banco de dados poderá fazer failover para a região secundária para gravações. Dependendo da configuração de replicação, você pode experimentar alguma perda de dados de transações não replicadas.

Se você usar uma solução de banco de dados IaaS, escolha uma que ofereça suporte à replicação e ao failover, como grupos de disponibilidade Always On do SQL Server.

Crie partições para a disponibilidade. Muitas vezes, a criação de partições de bases de dados é utilizada para melhorar a escalabilidade, mas também pode melhorar a disponibilidade. Se uma partição ficar inativa, continua a ser possível aceder às outras partições. Uma falha numa partição irá interromper apenas um subconjunto do total de transações.

Teste e valide seus componentes redundantes. A confiabilidade se beneficia de muitas maneiras da simplicidade e adicionar redundância pode aumentar a complexidade. Para garantir que a adição de redundância realmente leve a uma maior disponibilidade, você deve validar o seguinte:

• Seu sistema pode detetar de forma confiável componentes redundantes íntegros e não íntegros e removê-los com segurança e rapidez do pool de componentes?
• O seu sistema pode ser expandido de forma confiável e nos componentes redundantes?
• Suas operações de carga de trabalho de rotina, ad hoc e de emergência podem lidar com a redundância?

Soluções multi-região

O diagrama seguinte mostra uma aplicação com várias regiões que utiliza o Gestor de Tráfego do Azure para processar a ativação pós-falha.

Se você usar o Gerenciador de Tráfego ou o Azure Front Door em uma solução de várias regiões como seu mecanismo de roteamento de failover, considere as seguintes recomendações:

Sincronize a ativação pós-falha do front-end e back-end. Use seu mecanismo de roteamento para fazer failover no front-end. Se o front-end ficar inacessível em uma região, o failover encaminhará novas solicitações para a região secundária. Dependendo dos componentes de back-end e da solução de banco de dados, talvez seja necessário coordenar o failover dos serviços de back-end e dos bancos de dados.

Utilize a ativação pós-falha automática por um lado, mas a reativação pós-falha manual por outro. Use a automação para failover, mas não para failback. A reativação pós-falha automática comporta um risco, que se traduz na possibilidade de mudar para a região primária antes de a região atingir o bom estado de funcionamento pleno. Em vez disso, verifique se todos os subsistemas da aplicação estão em bom estado de funcionamento antes de efetuar a reativação pós-falha manual. Além disso, você deve verificar a consistência dos dados antes de fazer failback.

Para conseguir isso, desative o ponto de extremidade primário após o failover. Observe que, se o intervalo de monitoramento dos testes for curto e o número tolerado de falhas for pequeno, o failover e o failback ocorrerão em um curto espaço de tempo. Em alguns casos, a desativação não será concluída a tempo. Para evitar failback não confirmado, considere também implementar um ponto de extremidade de integridade que possa verificar se todos os subsistemas estão íntegros. Consulte o padrão Health Endpoint Monitoring.

Inclua redundância para sua solução de roteamento. Considere projetar uma solução de redundância de roteamento global para aplicativos Web de missão crítica.