Tornar todas as coisas redundantes

Criar redundância no seu aplicativo, evite ter pontos únicos de falha

Um aplicativo resiliente contorna a falha. Identifique os caminhos críticos em seu aplicativo. Há redundância em cada ponto no caminho? Se um subsistema falhar, o aplicativo fará failover para algo diferente?

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 mal de forma independente e simultaneamente removido da piscina
• ter estado idêntico ou nenhum estado
• não tem nenhum trabalho em andamento que seja perdido permanentemente durante o mau funcionamento
• são idênticos em capacidades
• não têm dependências umas das outras
• lida com a redução da capacidade sem mau funcionamento adicional

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

Recomendações

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

Considere arquiteturas de várias zonas e várias regiões. Certifique-se de entender como as zonas e regiões de disponibilidade oferecem resiliência e diferentes conjuntos de compensações arquitetônicas.

As zonas de disponibilidade do Azure são conjuntos isolados de data centers em uma região. Ao usar zonas de disponibilidade, você pode ser resiliente a falhas de um único data center ou de toda uma zona de disponibilidade. Você pode usar as 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 geograficamente separadas, 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 o protejam contra desastres regionais, elas têm um custo. As implantações em várias regiões são mais caras do que uma implementaçã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 permitir a replicação de dados entre regiões. O custo e a complexidade adicionais podem ser justificados em alguns cenários comerciais.

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

Posicione as VMs por trás de um balanceador de carga. Não use uma única VM para cargas de trabalho de missão crítica. Em vez disso, posicione várias VMs atrás de um balanceador de carga. Se qualquer VM ficar indisponível, o balanceador de carga distribuirá o tráfego para as VMs íntegras restantes.

Replique os bancos de dados. O Banco de Dados SQL do Azure e o Azure Cosmos DB replicam automaticamente os dados em uma região e podem ser configurados para replicar em zonas de disponibilidade para maior resiliência. Você também pode optar por ativar 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 o failover para a região secundária para gravações. Dependendo da configuração de replicação, você poderá sofrer 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 os Grupos de Disponibilidade Always On do SQL Server.

Partição para disponibilidade. O particionamento do banco de dados geralmente é usado para melhorar a escalabilidade, mas também pode melhorar a disponibilidade. Se um fragmento falhar, os outros fragmentos ainda poderão ser acessados. Uma falha em um fragmento 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 a adição de 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 detectar de forma confiável componentes redundantes íntegros e não íntegros e removê-los com segurança e rapidez do pool de componentes?
• Seu sistema pode escalar horizontalmente 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 para várias regiões

O diagrama a seguir mostra um aplicativo de várias regiões que usa o Gerenciador de Tráfego do Azure para controlar o failover.

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

Sincronize o failover de front e back-end. Use seu mecanismo de roteamento para fazer o failover do 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 a falha nos serviços de back-end e nos bancos de dados.

Use o failover automático, mas o failback manual. Use a automação para failover, mas não para failback. O failback automático traz um risco de você alternar para a região primária antes de a região estar completamente íntegra. Em vez disso, verifique se todos os subsistemas de aplicativo estão íntegros antes de realizar o failback. Além disso, você deve verificar a consistência dos dados antes de fazer o failback.

Para isso, desative o ponto de extremidade primário após o failover. Observe que, se o intervalo de monitoramento das sondas for curto e o número tolerado de falhas for pequeno, o failover e o failback ocorrerão em pouco tempo. Em alguns casos, a desativação não será concluída a tempo. Para evitar um failback não confirmado, considere também implementar um endpoint de integridade que possa verificar se todos os subsistemas estão íntegros. Consulte o padrão Monitoramento do Ponto de Extremidade de Integridade.

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