Tolerância a falhas para cargas de trabalho de nível de operadora

As empresas de telecomunicações mostraram que é possível implementar aplicativos que atendem e excedem os requisitos de disponibilidade de nível de operadora, enquanto são executados em cima de elementos não confiáveis. As empresas excedem esses requisitos por meio da tolerância a falhas, o que inclui os seguintes aspectos:

• Combinação de elementos independentes e não altamente disponíveis.
• Mecanismos de resposta a falhas de gerenciamento de tráfego.
• Mecanismos de reparo e recuperação de capacidade e resposta a falhas.
• Uso de bancos de dados entre elementos altamente disponíveis.

Ao projetar para confiabilidade e resiliência de nível de operadora, suponha que todos os componentes podem e falharão . O design exigirá uma abordagem em camadas para a resolução de falhas. Parte da validação do design é criar um modelo probabilístico quantitativo dos vários modos de falha que identificam claramente as principais dependências que o aplicativo tem e mostra que o aplicativo pode obter a disponibilidade necessária, considerando que essas dependências atendem aos seus próprios SLOs (Objetivos de Nível de Serviço). Esse modelo deve ser retido e validado continuamente após o desenvolvimento e em produção para garantir que os dados de teste e ao vivo correspondam ao que o modelo prevê.

Alta disponibilidade por meio da combinação

Para alcançar alta disponibilidade, pegue elementos independentes, que não estão altamente disponíveis, e combine-os para que permaneçam entidades independentes. A probabilidade de vários elementos falharem juntos é muito menor do que a probabilidade de falha de qualquer elemento único. Definimos esse processo como o estilo arquitetônico Compartilhar Nada .

Resposta de falha de gerenciamento de tráfego

Quando elementos individuais falham ou há problemas de conectividade, a camada de gerenciamento de tráfego do sistema tem várias maneiras de responder para manter o serviço geral. A solução deve implementar o maior número possível de mecanismos a seguir ou necessários para obter disponibilidade. Os dois primeiros mecanismos dependem de um comportamento específico no cliente, que pode nem sempre ser uma opção:

1. Tentativa instantânea do cliente para o destino alternativo — Em caso de falha ou após nenhuma resposta de uma repetição, o cliente pode tentar instantaneamente a solicitação com um elemento alternativo que é considerado provável de ter êxito, em vez de enviar uma nova consulta DNS para identificar uma alternativa.

2. Listas de integridade baseadas no cliente – mantém listas de elementos, que são conhecidos como íntegros e não íntegros. As solicitações sempre são enviadas para um elemento íntegro conhecido, a menos que essa lista esteja vazia. Se estiverem vazios, os elementos não íntegros conhecidos serão testados.

3. Sondagem baseada em servidor – mecanismos de distribuição baseados no sistema, como DNS ou ATM (Gerenciador de Tráfego do Azure), implementam sua própria detecção e monitoramento de atividade para habilitar o roteamento em torno de elementos não íntegros.

Resposta de falha de reparo e recuperação

As respostas de gerenciamento de tráfego podem contornar falhas, mas quando a falha é de longa duração ou permanente, o elemento defeituoso deve ser reparado ou substituído. Há duas opções main aqui:

1. Restaurando a redundância — a falha de um elemento reduz a capacidade geral do sistema. O design do sistema deve permitir essa redução de capacidade por meio da capacidade redundante de provisionamento; no entanto, várias falhas sobrepostas levarão a interrupções verdadeiras. Deve haver um processo automatizado que detecte a falha e adicione capacidade para restaurar a redundância aos níveis normais. O impacto pode ser determinado a partir da análise da taxa de falha. Em muitos casos, restaurar automaticamente o nível de redundância pode aumentar o tempo de inatividade aceitável de qualquer elemento individual.

2. (Opcional) Reparar o elemento com falha — a solução pode precisar incluir um mecanismo que detecta a falha e tenta reparar o elemento com falha em vigor. Essa solução pode não se aplicar a casos em que o processo de restauração de redundância cria uma instância de um novo elemento para substituir o com falha e encerra e desativa o elemento com falha.

O diagrama a seguir mostra como os dois modos de resposta a falhas cooperam para fornecer tolerância a falhas no nível do serviço:

Análise de taxa de falha

Nenhuma quantidade de esforço leva a um sistema perfeito, então comece com a suposição de que tudo pode e falhará. Considere como a solução, como um todo, se comportará. A análise de taxa de falha começa com os sistemas individuais de nível inferior e combina os resultados para modelar a solução completa.

Normalmente, a análise é feita usando a modelagem Markov, que considera todos os modos de falha possíveis. Para cada modo de falha, considere os seguintes fatores:

• Tarifa
• Duração e tempo de resolução
• Probabilidade de falha correlacionada (qual é a chance de que uma falha no serviço X cause uma falha no serviço Y)

O resultado é uma estimativa da disponibilidade do sistema e informa a consideração do raio de explosão. O raio de explosão é o conjunto de coisas que não funcionarão devido a uma falha específica. Um bom design visa limitar o escopo e a gravidade desse conjunto, pois a falha vai acontecer. Por exemplo, uma falha que bloqueia a criação de novos usuários, mas não afeta os existentes, é menos preocupante do que uma falha que interrompe o serviço para todos os usuários.

A análise de taxa de falha fornece uma estimativa da disponibilidade geral no nível do sistema. A análise identifica as dependências críticas nas quais essa disponibilidade depende. Quando a análise de taxa de falha indica que a disponibilidade do sistema fica aquém, ela também fornece insights quantitativos específicos sobre onde as melhorias são necessárias e até que ponto.

Para obter mais detalhes sobre a análise do modo de falha no Azure, consulte Análise do modo de falha para aplicativos do Azure.

Falhas em cascata e sobrecarga

O design do aplicativo de nível de operadora deve prestar atenção aos riscos de falhas em cascata, em que a falha de um elemento leva à falha de outros elementos, muitas vezes devido à sobrecarga. Falhas em cascata não são exclusivas para aplicativos de nível de operadora, mas a confiabilidade e o tempo de resposta exigem degradação normal e recuperação automatizada.

Próxima etapa

Examine a área de design do modelo de dados considerada para cargas de trabalho de nível de operadora.

Área de design: modelo de dados