Introdução ao Serviço de Análise de Falhas

O Serviço de Análise de Falhas foi projetado para testar serviços criados no Microsoft Azure Service Fabric. Com o Serviço de Análise de Falhas, você pode induzir falhas significativas e executar cenários de teste completos em seus aplicativos. Essas falhas e cenários exercitam e validam os inúmeros estados e transições que um serviço experimentará ao longo de sua vida útil, tudo de forma controlada, segura e consistente.

Ações são as falhas individuais direcionadas a um serviço para testá-lo. Um desenvolvedor de serviços pode usá-los como blocos de construção para escrever cenários complicados. Por exemplo:

• Reinicie um nó para simular qualquer número de situações em que uma máquina ou VM é reinicializada.
• Mova uma réplica do seu serviço stateful para simular balanceamento de carga, failover ou atualização de aplicativo.
• Invoque a perda de quórum em um serviço com monitoração de estado para criar uma situação em que as operações de gravação não possam prosseguir porque não há réplicas de "backup" ou "secundárias" suficientes para aceitar novos dados.
• Invoque a perda de dados em um serviço com monitoração de estado para criar uma situação em que todo o estado na memória seja completamente apagado.

Os cenários são operações complexas compostas por uma ou mais ações. O Serviço de Análise de Falhas fornece dois cenários completos internos:

• Cenário de caos
• Cenário de failover

Teste como serviço

O Serviço de Análise de Falhas é um serviço do sistema Service Fabric que é iniciado automaticamente com um cluster do Service Fabric. Esse serviço atua como host para injeção de falhas, execução de cenários de teste e análise de integridade.

Quando uma ação de falha ou um cenário de teste é iniciado, um comando é enviado ao Serviço de Análise de Falhas para executar a ação de falha ou o cenário de teste. O Serviço de Análise de Falhas tem monitoração de estado para que possa executar falhas e cenários de forma confiável e validar resultados. Por exemplo, um cenário de teste de longa execução pode ser executado de forma confiável pelo Serviço de Análise de Falhas. E como os testes estão sendo executados dentro do cluster, o serviço pode examinar o estado do cluster e seus serviços para fornecer informações mais detalhadas sobre falhas.

Testando sistemas distribuídos

O Service Fabric facilita significativamente o trabalho de escrever e gerenciar aplicativos escaláveis distribuídos. O Serviço de Análise de Falhas torna o teste de um aplicativo distribuído igualmente mais fácil. Há três problemas principais que precisam ser resolvidos durante os testes:

1. Simulação/geração de falhas que podem ocorrer em cenários reais: um dos aspetos importantes do Service Fabric é que ele permite que aplicativos distribuídos se recuperem de várias falhas. No entanto, para testar se o aplicativo é capaz de se recuperar dessas falhas, precisamos de um mecanismo para simular/gerar essas falhas do mundo real em um ambiente de teste controlado.
2. A capacidade de gerar falhas correlacionadas: Falhas básicas no sistema, como falhas de rede e falhas de máquina, são fáceis de produzir individualmente. Gerar um número significativo de cenários que podem acontecer no mundo real como resultado das interações dessas falhas individuais não é trivial.
3. Experiência unificada em vários níveis de desenvolvimento e implantação: há muitos sistemas de injeção de falhas que podem fazer vários tipos de falhas. No entanto, a experiência em todos eles é pobre quando se muda de cenários de desenvolvedor de caixa única, para executar os mesmos testes em grandes ambientes de teste, para usá-los para testes em produção.

Embora existam muitos mecanismos para resolver esses problemas, um sistema que faça o mesmo com as garantias necessárias - desde um ambiente de desenvolvedor de caixa única, até testes em clusters de produção - está faltando. O Serviço de Análise de Falhas ajuda os desenvolvedores de aplicativos a se concentrarem em testar sua lógica de negócios. O Serviço de Análise de Falhas fornece todos os recursos necessários para testar a interação do serviço com o sistema distribuído subjacente.

Simulação/geração de cenários de falha do mundo real

Para testar a robustez de um sistema distribuído contra falhas, precisamos de um mecanismo para gerar falhas. Embora, em teoria, gerar uma falha como um nó para baixo pareça fácil, ele começa a atingir o mesmo conjunto de problemas de consistência que o Service Fabric está tentando resolver. Por exemplo, se quisermos desligar um nó, o fluxo de trabalho necessário é o seguinte:

1. A partir do cliente, emita uma solicitação de nó de desligamento.

2. Envie a solicitação para o nó certo.

   a. Se o nó não for encontrado, ele deve falhar.

   b. Se o nó for encontrado, ele deverá retornar somente se o nó for desligado.

Para verificar a falha de uma perspetiva de teste, o teste precisa saber que, quando essa falha é induzida, a falha realmente acontece. A garantia que o Service Fabric fornece é que o nó ficará inativo ou já estava inativo quando o comando atingiu o nó. Em ambos os casos, o teste deve ser capaz de raciocinar corretamente sobre o estado e ter sucesso ou falhar corretamente em sua validação. Um sistema implementado fora do Service Fabric para fazer o mesmo conjunto de falhas pode atingir muitos problemas de rede, hardware e software, o que o impediria de fornecer as garantias anteriores. Na presença dos problemas mencionados anteriormente, o Service Fabric reconfigurará o estado do cluster para contornar os problemas e, portanto, o Serviço de Análise de Falhas ainda poderá fornecer o conjunto certo de garantias.

Geração de eventos e cenários necessários

Embora simular uma falha do mundo real consistentemente seja difícil de começar, a capacidade de gerar falhas correlacionadas é ainda mais difícil. Por exemplo, uma perda de dados acontece em um serviço persistente com monitoração de estado quando as seguintes coisas acontecem:

1. Apenas um quórum de gravação das réplicas é capturado na replicação. Todas as réplicas secundárias ficam atrás da primária.
2. O quórum de gravação diminui devido à queda das réplicas (devido à queda de um pacote de código ou nó).
3. O quorum de gravação não pode voltar porque os dados das réplicas são perdidos (devido a corrupção de disco ou recriação de imagens de máquina).

Essas falhas correlacionadas acontecem no mundo real, mas não com tanta frequência quanto as falhas individuais. A capacidade de testar esses cenários antes que eles aconteçam na produção é fundamental. Ainda mais importante é a capacidade de simular esses cenários com cargas de trabalho de produção em circunstâncias controladas (no meio do dia com todos os engenheiros no convés). Isso é muito melhor do que ter acontecido pela primeira vez em produção às 2:00 da manhã.

Experiência unificada em diferentes ambientes

A prática tradicionalmente tem sido criar três conjuntos diferentes de experiências, um para o ambiente de desenvolvimento, um para testes e outro para produção. O modelo era:

1. No ambiente de desenvolvimento, produza transições de estado que permitam testes de unidade de métodos individuais.
2. No ambiente de teste, produza falhas para permitir testes de ponta a ponta que executam vários cenários de falha.
3. Mantenha o ambiente de produção intacto para evitar falhas não naturais e garantir que haja uma resposta humana extremamente rápida às falhas.

No Service Fabric, por meio do Serviço de Análise de Falhas, estamos propondo reverter isso e usar a mesma metodologia desde o ambiente do desenvolvedor até a produção. Existem duas formas de o conseguir:

1. Para induzir falhas controladas, use as APIs do Serviço de Análise de Falhas de um ambiente de caixa única até os clusters de produção.
2. Para dar ao cluster uma febre que causa indução automática de falhas, use o Serviço de Análise de Falhas para gerar falhas automáticas. O controle da taxa de falhas através da configuração permite que o mesmo serviço seja testado de forma diferente em ambientes diferentes.

Com o Service Fabric, embora a escala de falhas fosse diferente nos diferentes ambientes, os mecanismos reais seriam idênticos. Isso permite um pipeline de código para implantação muito mais rápido e a capacidade de testar os serviços sob cargas do mundo real.

Usando o Serviço de Análise de Falhas

C#

Os recursos do Serviço de Análise de Falhas estão no namespace System.Fabric no pacote NuGet Microsoft.ServiceFabric. Para usar os recursos do Serviço de Análise de Falhas, inclua o pacote nuget como referência em seu projeto.

PowerShell

Para usar o PowerShell, você deve instalar o SDK do Service Fabric. Depois que o SDK é instalado, o módulo PowerShell do ServiceFabric é carregado automaticamente para você usar.

Próximos passos

Para criar serviços verdadeiramente em escala de nuvem, é fundamental garantir, antes e depois da implantação, que os serviços possam resistir a falhas do mundo real. No mundo dos serviços de hoje, a capacidade de inovar rapidamente e mover o código para a produção rapidamente é muito importante. O Serviço de Análise de Falhas ajuda os desenvolvedores de serviços a fazer exatamente isso.

Comece a testar seus aplicativos e serviços usando os cenários de teste internos ou crie seus próprios cenários de teste usando as ações de falha fornecidas pelo Serviço de Análise de Falhas.