Compartilhar via

Recuperação de desastre no Azure Service Fabric

  • Artigo

Uma parte fundamental da entrega de alta disponibilidade é garantir que os serviços possam sobreviver a todos os tipos diferentes de falhas. Isso é especialmente importante para falhas não planejadas e fora de seu controle.

Este artigo descreve alguns modos de falha comuns que podem se transformar em desastres se não forem modelados e gerenciados corretamente. Ele também aborda mitigações e ações a serem tomadas se, ainda assim, um desastre acontecer. A meta é limitar ou eliminar o risco de que haja tempo de inatividade ou perda de dados quando ocorrerem falhas, planejadas ou não.

Evitando desastres

O principal objetivo do Microsoft Azure Service Fabric é ajudá-lo a modelar seu ambiente e seus serviços de forma que tipos de falha comuns não se transformem em desastres.

De modo geral, há dois tipos de cenários de desastre/falha:

  • Falhas de hardware e software
  • Falhas operacionais

Falhas de hardware e software

Falhas de hardware e software são imprevisíveis. A maneira mais fácil de sobreviver a falhas é executar mais cópias do serviço entre os limites de falha de hardware ou software.

Por exemplo, se seu serviço estiver em execução somente em apenas um computador, a falha desse computador será um desastre para o serviço em questão. A maneira simples de evitar esse desastre é garantir que o serviço esteja em execução em vários computadores. Testes também são necessários para garantir que a falha de um computador não interrompa o serviço em execução. O planejamento de capacidade garante que uma instância de substituição possa ser criada em outro lugar e que a redução da capacidade não sobrecarregue os serviços restantes.

O mesmo padrão funciona independentemente da falha que você estiver tentando evitar. Por exemplo, se estiver preocupado com a falha de uma rede SAN, execute-a entre várias redes SAN. Se estiver preocupado com a perda de um rack de servidores, execute entre vários racks. Se você estiver preocupado com a perda de datacenters, seu serviço deverá ser executado em várias regiões do Azure, em vários Zonas de Disponibilidade do Azure ou em seus próprios datacenters.

Quando um serviço é distribuído em várias instâncias físicas (computadores, racks, datacenters, regiões), você ainda está sujeito a alguns tipos de falhas simultâneas. No entanto, uma falha única e até várias falhas de um determinado tipo (por exemplo, uma única máquina virtual ou um link de rede que falhou) são manipuladas automaticamente e, portanto, não se tornam mais um "desastre".

O Service Fabric oferece mecanismos para expandir o cluster e trabalha para colocar nós e serviços com falha de volta em funcionamento. O Service Fabric também permite executar várias instâncias de seus serviços de modo a evitar que esses tipos de falhas não planejadas se tornem desastres reais.

Podem existir motivos pelos quais não é possível executar uma implantação grande o suficiente para abranger as falhas. Por exemplo, podem ser necessários mais recursos de hardware do que você está disposto a pagar em relação à possibilidade de falha. Ao lidar com aplicativos distribuídos, é possível que os saltos de comunicação adicionais ou os custos de replicação de estado entre distâncias geográficas causem latência inaceitável. Esse limite varia com cada aplicativo.

Especificamente para falhas de software, a falha pode estar no serviço que você está tentando dimensionar. Nesse caso, mais cópias não impedem um desastre, pois a condição de falha está correlacionada entre todas as instâncias.

Falhas operacionais

Mesmo que o serviço esteja estendido por todo o mundo com muitas redundâncias, ele ainda poderá passar por eventos desastrosos. Por exemplo, se alguém reconfigurar acidentalmente o nome DNS do serviço ou simplesmente exclui-lo.

Por exemplo, digamos que você tivesse um serviço do Service Fabric com estado e alguém excluísse esse serviço acidentalmente. A menos que houvesse alguma outra mitigação de risco, esse serviço e todos do seu estado desapareceriam. Esses tipos de desastres operacionais ("ops") exigem mitigações e etapas de recuperação diferentes do que as que são necessárias para falhas não planejadas regulares.

As melhores formas de evitar esses tipos de falhas operacionais são:

  • Restringir o acesso operacional ao ambiente.
  • Realizar auditorias rígidas de operações perigosas.
  • Impor a automação, prevenir-se contra alterações manuais ou fora de banda e validar alterações específicas no ambiente real antes de aplicá-las.
  • Verifique se as operações destrutivas são "flexíveis". Operações flexíveis não entram em vigor imediatamente ou podem ser desfeitas em uma janela de tempo.

O Service Fabric fornece mecanismos para evitar falhas operacionais, como fornecer controle de acesso baseado em função para operações de cluster. No entanto, a maioria dessas falhas operacionais exige esforços organizacionais e outros sistemas. O Service Fabric oferece alguns mecanismos para sobreviver a falhas operacionais, de forma mais destacada o backup e a restauração para serviços com estado.

Gerenciando falhas

A meta do Service Fabric é o gerenciamento automático de falhas. No entanto, para lidar com alguns tipos de falhas, os serviços precisam ter código adicional. Outros tipos de falhas não devem ser resolvidas automaticamente por motivos de segurança e de continuidade de negócios.

Lidando com falhas únicas

Um único computador pode falhar por diversos tipos de motivos. Às vezes, são as causas de hardware, como fontes de alimentação e falhas de hardware de rede. Outras falhas estão no software. Elas incluem falhas no sistema operacional e no próprio serviço. O Service Fabric detecta automaticamente esses tipos de falha, inclusive os casos em que o computador fica isolado de outros computadores devido a problemas de rede.

Independentemente do tipo de serviço, executar uma única instância resulta em tempo de inatividade para esse serviço se essa única cópia do código falhar por qualquer motivo.

Para lidar com qualquer falha única, a coisa mais simples que você pode fazer é garantir que seus serviços sejam executados em mais de um nó por padrão. Para serviços sem estado, certifique-se de que InstanceCount seja maior que 1. Para serviços com estado, a recomendação mínima é que TargetReplicaSetSize e MinReplicaSetSize sejam definidos como 3. Executar mais cópias do código de seu serviço garante que o serviço seja capaz de lidar com qualquer falha única automaticamente.

Lidando com falhas coordenadas

Falhas coordenadas em um cluster podem ser devido a alterações e falhas de infraestrutura planejadas ou não planejadas, ou a alterações planejadas de software. O Service Fabric modela zonas de infraestrutura que passam por falhas coordenadas como domínios de falha. As áreas que passarão por alterações coordenadas de software são chamadas de domínios de atualização. Para obter mais informações sobre domínios de falha, domínios de atualização e topologia de cluster, consulte Descrever um cluster de Service Fabric usando o Gerenciador de Recursos de Cluster.

Por padrão, o Service Fabric considera os domínios de falha e de atualização ao planejar onde os serviços devem ser executados. Por padrão, o Service Fabric tenta garantir que seus serviços sejam executados em vários domínios de falha e de atualização, de modo que se ocorrerem alterações planejadas ou não planejadas, os serviços permaneçam disponíveis.

Por exemplo, digamos que a falha de uma fonte de energia faça com que todos os computadores em um rack falhem simultaneamente. Com várias cópias do serviço em execução, a perda de vários computadores em uma falha de domínio de falha se transforma em apenas mais um exemplo de falha única para um serviço. Por isso, é essencial gerenciar domínios de falha e de atualização para garantir a alta disponibilidade de seus serviços.

Ao executar o Service Fabric no Azure, os domínios de falha e de atualização são gerenciados automaticamente. Em outros ambientes, eles podem não ser. Se você estiver criando seus próprios clusters locais, lembre-se de mapear e planejar o layout de seu domínio de falha corretamente.

Os domínios de atualização são úteis para modelar áreas em que o software será atualizado ao mesmo tempo. Por isso, frequentemente os domínios de atualização também definem os limites em que o software é desativado durante atualizações planejadas. Atualizações do Service Fabric e de seus serviços seguem o mesmo modelo. Para obter mais informações sobre as atualizações sem interrupção, os domínios de atualização e o modelo de integridade do Service Fabric que ajuda a impedir que alterações não intencionais afetem o cluster e seu serviço, consulte estes documentos:

Você pode visualizar o layout do cluster usando o mapa de cluster fornecido no Service Fabric Explorer:

Nós espalhados pelos domínios de falha no Service Fabric Explorer

Observação

A modelagem de áreas de falha, as atualizações sem interrupção, a execução de várias instâncias de seu código e estado de serviço, as regras de posicionamento para garantir que os serviços sejam executados entre os domínios de falha e de atualização e o monitoramento de integridade interno são apenas alguns dos recursos que o Service Fabric fornece para impedir que falhas e problemas operacionais normais se tornem desastres.

Lidando com falhas simultâneas de hardware ou software

Falamos sobre falhas únicas. Como você pode ver, é fácil lidar com elas com serviços com e sem estado apenas mantendo mais cópias do código (e do estado) em execução entre domínios de falha e de atualização.

Várias falhas aleatórias simultâneas também podem ocorrer. Elas são mais propensas a levar a um tempo de inatividade ou causar um desastre real.

Serviço sem estado

A contagem de instâncias para um serviço sem estado indica o número desejado de instâncias que precisam estar em execução. Quando alguma (ou todas) das instâncias falha, o Service Fabric responde criando automaticamente as instâncias de substituição em outros nós. O Service Fabric continuará criando substituições até que o serviço volte à contagem de instâncias desejada.

Por exemplo, suponha que o serviço sem estado tenha um valor InstanceCount de-1. Esse valor significa que uma instância deve ser executada em cada nó no cluster. Se algumas dessas instâncias falharem, o Service Fabric detectará que o serviço não está em seu estado desejado e tentará criar as instâncias nos nós em que estão ausentes.

Serviço com estado

Há dois tipos de serviço com estado:

  • Com estado persistente.
  • Com estado sem persistência. (O estado é armazenado na memória.)

A recuperação de uma falha de um serviço com estado depende do tipo de serviço com estado, quantas réplicas o serviço tinha e quantas réplicas falharam.

Em um serviço com estado, os dados de entrada são replicados entre as réplicas (a primária e as secundárias ativas). Se a maioria das réplicas receber os dados, os dados serão considerados quorum confirmados. (Para cinco réplicas, três serão um quorum.) Isso significa que, a qualquer momento, haverá pelo menos um quorum de réplicas com os dados mais recentes. Se as réplicas falharem (digamos duas de cinco), podemos usar o valor de quorum para calcular se podemos recuperar. (Como as três restantes das cinco réplicas ainda estão ativas, é garantido que pelo menos uma réplica terá os dados completos.)

Quando um quorum de réplicas falha, a partição é declarada para estar em um estado de perda de quorum. Digamos que uma partição tenha cinco réplicas, o que significa que pelo menos três têm a garantia de ter os dados completos. Se um quorum (três de cinco) de réplicas falhar, o Service Fabric não poderá determinar se as réplicas restantes (duas de cinco) têm dados suficientes para restaurar a partição. Nos casos em que o Service Fabric detecta perda de quorum, seu comportamento padrão é impedir gravações adicionais na partição, declarar a perda de quorum e aguardar a restauração de um quorum de réplicas.

Determinar se um desastre ocorreu para um serviço com estado e depois gerenciá-lo é um processo de três estágios:

  1. Determinar se houve perda de quorum ou não.

    Uma perda de quorum é declarada quando a maioria das réplicas de um serviço com estado ficam inativas ao mesmo tempo.

  2. Determinar se a perda de quorum é permanente ou não.

    Na maioria das vezes, as falhas são transitórias. Os processos são reiniciados, os nós são reiniciados, as máquinas virtuais são reiniciadas e as partições de rede se recuperam. No entanto, algumas vezes as falhas são permanentes. Se as falhas são permanentes ou não depende se o serviço com estado permanece em seu estado ou se ele o mantém apenas na memória:

    • Para serviços sem estado persistente, a falha de um quorum ou mais de réplicas causa imediatamente uma perda de quorum permanente. Quando o Service Fabric detecta a perda de quorum em um serviço não persistente com estado, ele prossegue imediatamente para a etapa 3, declarando uma (potencial) perda de dados. Prosseguir com a perda de dados faz sentido porque o Service Fabric sabe que não há motivos para aguardar que as réplicas retornem. Mesmo que elas sejam recuperadas, os dados serão perdidos devido à natureza não persistente do serviço.
    • Para serviços persistentes com estado, uma falha de um quorum ou mais de réplicas faz com que o Service Fabric aguarde que as réplicas retornem e restaurem o quorum. Isso resulta em uma interrupção de serviço para qualquer gravação na partição afetada (ou "conjunto de réplicas") do serviço. No entanto, leituras ainda podem ocorrer, com garantias de consistência reduzidas. O tempo padrão que o Service Fabric aguarda o quorum ser restaurado é infinito, pois prosseguir representa um (potencial) evento de perda de dados e traz consigo outros riscos. Isso significa que o Service Fabric não passará para a próxima etapa, a menos que um administrador decida declarar a perda de dados.

  3. Determinar se os dados estão perdidos e restaurá-los de backups.

    Se a perda de quorum tiver sido declarada (automaticamente ou por meio de ação administrativa), o Service Fabric e os serviços vão prosseguir para determinar se os dados foram realmente perdidos. Nesse ponto, o Service Fabric também sabe que as outras réplicas não retornarão. Essa foi a decisão tomada quando paramos de esperar que a perda de quorum se resolvesse. Normalmente, a melhor alternativa para o serviço é congelar e aguardar a intervenção administrativa específica.

    Quando o Service Fabric chama o método OnDataLossAsync, é sempre devido à suspeita de perda de dados. O Service Fabric garante que essa chamada seja entregue para a melhor réplica restante. Essa seria qualquer réplica tenha tido o maior progresso.

    O motivo pelo qual sempre falamos em perdas de dados suspeita é porque é possível que a réplica restante tenha o mesmo estado que a réplica primária tinha quando o quorum foi perdido. No entanto, sem o estado para compará-la, não há nenhum modo adequado do Service Fabric ou dos operadores terem certeza.

    Então, o que uma implementação típica do método OnDataLossAsync faz?

    1. Os logs de implementação que OnDataLossAsync foram disparados e que são acionados por todos os alertas administrativos necessários.

    2. Em geral, a implementação pausa e aguarda mais decisões e ações manuais serem realizadas. Isso ocorre porque, mesmo que os backups estejam disponíveis, talvez seja necessário prepará-los.

      Por exemplo, se dois serviços diferentes coordenarem informações, talvez seja necessário modificar esses backups para garantir que, depois que a restauração acontecer, as informações com que esses dois serviços se preocupam sejam consistentes.

    3. Geralmente, há alguma outra telemetria ou o esgotamento do serviço. Talvez esses metadados estejam contidos em outros serviços ou em logs. Essas informações podem ser usadas conforme necessário para determinar se houve alguma chamada recebida e processada na primária que não estava presente no backup ou que não foi replicada nessa réplica específica. Pode ser necessário reproduzir ou adicionar tais chamadas ao backup antes que a restauração seja viável.

    4. A implementação compara o estado da réplica restante com o que está contido em qualquer backup disponível. Se você estiver usando coletas confiáveis do Service Fabric, existem ferramentas e processos disponíveis para realizar isso. O objetivo é verificar se o estado dentro da réplica é suficiente e identificar o que pode estar faltando no backup.

    5. Depois de a comparação ser feita e a restauração ser concluída (se necessário), o código de serviço deverá retornar true se alterações de estado tiverem sido realizadas. Se a réplica tiver determinado que essa era a melhor cópia do estado e não tiver feito alterações, false será o valor retornado.

      Um valor true indica que qualquer outra réplica restante pode agora estar inconsistente com esta. Elas serão descartadas e recriadas desta réplica. Um valor false indica que nenhuma alteração de estado foi realizada, de modo que as outras réplicas podem manter o que possuem.

É extremamente importante que os autores de serviço pratiquem cenários potenciais de falha e perda de dados antes que os serviços sejam implantados em produção. Para se proteger contra a possibilidade de perda de dados, é importante periodicamente fazer backup do estado de qualquer um de seus serviços com estado para um repositório com redundância geográfica.

Você também deve garantir ter a capacidade de restaurar o estado. Como são feitos backups de vários serviços diferentes em momentos diferentes, você precisa garantir que, após uma restauração, seus serviços tenham uma exibição consistente uns dos outros.

Por exemplo, considere uma situação em que um serviço gera e armazena um número e, então, o envia para outro serviço que também o armazena. Após uma restauração, talvez você descubra que o segundo serviço tem o número, mas o primeiro não tem, porque seu backup não incluiu essa operação.

Se você descobrir que as réplicas restantes são insuficientes para continuar em um cenário de perda de dados e se você não puder reconstruir o estado do serviço da telemetria ou esgotamento, a frequência dos backups determinará o melhor RPO (objetivo de ponto de recuperação) possível. O Service Fabric fornece várias ferramentas para testar diferentes cenários de falha, incluindo a perda permanente de quorum e de dados que exige a restauração de um backup. Esses cenários são incluídos como parte das ferramentas de teste do Service Fabric, gerenciadas pelo Serviço de Análise de Falha. Para obter mais informações sobre essas ferramentas e padrões, consulte Introdução ao Serviço de Análise de Falha.

Observação

Os serviços do sistema também podem sofrer perda de quorum. O impacto é específico para o serviço em questão. Por exemplo, a perda de quorum no serviço de nomenclatura afeta a resolução de nomes, ao passo que a perda de quorum no serviço Gerenciador de Failover bloqueia os failovers e a criação de novos serviços.

Os serviços de sistema do Service Fabric seguem o mesmo padrão que seus serviços para o gerenciamento de estado, mas recomendamos que você tente movê-los da perda de quorum e para uma possível perda de dados. Em vez disso, recomendamos que você procure o suporte para encontrar uma solução que seja destinada à sua situação. Normalmente, é preferível simplesmente aguardar até que as réplicas desativadas retornem.

Solucionando problemas de perda de quorum

Talvez as réplicas estejam inativas de modo intermitente devido a uma falha transitória. Espere um pouco enquanto o Service Fabric tenta trazê-las. Se as réplicas estiverem inativas por um tempo maior do que o esperado, siga estas ações de solução de problemas:

  • As réplicas podem estar falhando. Verifique os relatórios de integridade no nível da réplica e os logs do aplicativo. Colete despejos de memória e execute as ações necessárias para recuperar.
  • O processo de réplica pode ter se tornado sem resposta. Inspecione os logs do aplicativo para verificar isso. Colete os despejos do processo e, em seguida, interrompa o processo sem resposta. O Service Fabric criará um processo de substituição e tentará trazer a réplica de volta.
  • Os nós que hospedam as réplicas podem estar inativos. Reinicie a máquina virtual subjacente para ativar os nós.

Às vezes, talvez não seja possível recuperar as réplicas. Por exemplo, as unidades falharam ou os computadores não estão respondendo fisicamente. Nesses casos, o Service Fabric precisa ser instruído a não esperar pela recuperação da réplica.

Não use esses métodos se a possível perda de dados for inaceitável para colocar o serviço online. Nesse caso, todos os esforços devem ser feitos para recuperar os computadores físicos.

As ações a seguir podem resultar em perda de dados. Verifique antes de segui-las.

Observação

Nunca é seguro usar esses métodos a não ser como uma maneira direcionada contra partições específicas.

  • Use a API (interface de programação de aplicativo) Repair-ServiceFabricPartition -PartitionId ou System.Fabric.FabricClient.ClusterManagementClient.RecoverPartitionAsync(Guid partitionId). Essa API permite especificar a ID da partição a ser movida da perda de quorum para a perda de dados em potencial.
  • Se o cluster encontrar falhas frequentes que levam os serviços a entrar em um estado de perda de quorum e a possível perda de dados for aceitável, a especificação de um valor QuorumLossWaitDuration apropriado poderá ajudar seu serviço a se recuperar automaticamente. O Service Fabric aguardará o valor fornecido QuorumLossWaitDuration (o padrão é infinito) antes de executar a recuperação. Não recomendamos esse método porque isso pode causar perdas de dados inesperadas.

Disponibilidade do cluster do Service Fabric

Em geral, o cluster do Service Fabric é um ambiente altamente distribuído, sem pontos únicos de falha. Uma falha de qualquer um dos nós não causará problemas de disponibilidade ou confiabilidade para o cluster, principalmente porque os serviços de sistema do Service Fabric seguem as mesmas diretrizes fornecidas anteriormente. Ou seja, eles sempre executam com três ou mais réplicas por padrão, e os serviços do sistema que são executados sem monitoração de estado em todos os nós.

As camadas subjacentes de detecção de falha e rede do Service Fabric são totalmente distribuídas. A maioria dos serviços de sistema podem ser recriados dos metadados no cluster ou sabem como ressincronizar seu estado de outros locais. A disponibilidade do cluster poderá ser comprometida se os serviços de sistema entrarem em situações de perda de quorum como as descritas anteriormente. Nesses casos, talvez você não consiga executar determinadas operações no cluster (como iniciar uma atualização ou implantar novos serviços), mas o cluster em si ainda está ativo.

Os serviços em um cluster em execução continuarão em execução nessas condições, a menos que eles exijam gravações nos serviços de sistema para continuar funcionando. Por exemplo, se Gerenciador de Failover estiver em perda de quorum, todos os serviços continuarão a ser executados. Mas todos os serviços que falharem não poderão ser reiniciados automaticamente, pois isso requer o envolvimento do Gerenciador de Failover.

Falhas de um data center ou uma região do Azure

Raramente, um datacenter físico pode ficar indisponível temporariamente devido à perda de energia ou de conectividade de rede. Nesses casos, seus clusters e serviços do Service Fabric nesse data center ou região do Azure ficarão indisponíveis. No entanto, os dados ficam preservados.

Para os clusters em execução no Azure, você pode exibir as atualizações sobre interrupções na Página de status do Azure. Na hipótese altamente improvável de um datacenter físico ser destruído parcial ou completamente, todos os clusters do Service Fabric hospedados nele, ou os serviços dentro dele, poderão ser perdidos. Essa perda inclui qualquer estado que não esteja salvo em backup fora do datacenter ou da região.

Há duas estratégias diferentes para sobreviver a uma falha prolongada ou permanente de um único datacenter ou região:

  • Executar clusters separados do Service Fabric em várias dessas regiões e usar um mecanismo para failover e failback entre esses ambientes. Esse tipo de modelo de vários clusters ativo/ativo ou ativo/passivo requer código adicional de gerenciamento e operações. Esse modelo também requer a coordenação de backups dos serviços em um datacenter ou região para que eles fiquem disponíveis em outros datacenters ou regiões quando um deles falhar.

  • Executa um único cluster do Service Fabric que abrange vários datacenters. A configuração mínima com suporte para essa estratégia é de três datacenters. Para obter mais informações, consulte Implantar um cluster do Service Fabric entre zonas de disponibilidade.

    Esse modelo requer configuração adicional. No entanto, o benefício é que a falha de um datacenter é convertida de um desastre em uma falha normal. Essas falhas podem ser tratadas pelos mecanismos que funcionam para clusters dentro de uma única região. Domínios de falha, domínios de atualização e regras de posicionamento do Service Fabric garantem que as cargas de trabalho sejam distribuídas para que tolerem falhas normais.

    Para obter mais informações sobre as políticas que podem ajudar a operar serviços nesse tipo de cluster, leia sobre as Políticas de posicionamento para serviços do Service Fabric.

  • Executar um único cluster do Service Fabric que abrange várias regiões usando o modelo autônomo. O número recomendado de regiões é três. Consulte Criar um cluster autônomo para obter detalhes sobre a configuração de Service Fabric autônomo.

Falhas aleatórias que causam falhas de cluster

O Service Fabric tem o conceito de nós de semente. Trata-se de nós que mantêm a disponibilidade do cluster subjacente.

Esses nós de semente ajudam a garantir que o cluster permaneça ativo estabelecendo concessões com outros nós e servindo como agentes de desempate durante determinados tipos de falhas. Se falhas aleatórias removerem a maioria dos nós de semente no cluster e eles não forem trazidos de volta rapidamente, o cluster será desligado automaticamente. O cluster falhará.

No Azure, o Provedor de Recursos Service Fabric gerencia as configurações de cluster do Service Fabric. Por padrão, o Provedor de Recursos distribui os nós de semente entre os domínios de falha e de atualização para o tipo de nó primário. Se o tipo de nó primário estiver marcado como durabilidade prata ou ouro, quando você remover um nó semente (seja dimensionando em seu tipo de nó primário ou removendo-o manualmente), o cluster tentará promover outro nó não semente da capacidade disponível do tipo de nó primário. Essa tentativa falhará se você tiver menos capacidade disponível do que o nível de confiabilidade do cluster exigir para o tipo de nó primário.

Tanto em clusters autônomos do Service Fabric e no Azure, o tipo de nó primário é aquele que executa as sementes. Quando você define um tipo de nó primário, o Service Fabric aproveitará automaticamente o número de nós fornecidos, criando até nove nós de semente e sete réplicas de cada serviço do sistema. Se um conjunto de falhas aleatórias desativar a maior parte dessas réplicas simultaneamente, os serviços do sistema entrarão em perda de quorum. Se a maioria desses nós de semente for perdida, o cluster será desligado logo em seguida.

Próximas etapas