Recuperação após desastre no Azure Service Fabric

  • Artigo

Uma parte crítica do fornecimento de elevada disponibilidade é garantir que os serviços podem sobreviver a todos os diferentes tipos de falhas. Isto é especialmente importante para falhas não planeadas e fora do seu controlo.

Este artigo descreve alguns modos de falha comuns que podem ser desastres se não forem modelados e geridos corretamente. Também aborda mitigações e ações a tomar se um desastre acontecer de qualquer forma. O objetivo é limitar ou eliminar o risco de indisponibilidade ou perda de dados quando ocorrerem falhas, planeadas ou não.

Evitar desastre

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

Em geral, existem dois tipos de cenários de desastre/falha:

  • Falhas de hardware e software
  • Falhas operacionais

Falhas de hardware e software

As falhas de hardware e software são imprevisíveis. A forma mais fácil de sobreviver a falhas é executar mais cópias do serviço através dos limites de falhas de hardware ou software.

Por exemplo, se o serviço estiver em execução apenas num computador, a falha desse computador é um desastre para esse serviço. A forma simples de evitar este desastre é garantir que o serviço está em execução em várias máquinas. Os testes também são necessários para garantir que a falha de um computador não interrompe o serviço em execução. O planeamento de capacidade garante que uma instância de substituição pode ser criada noutro local e que a redução da capacidade não sobrecarrega os restantes serviços.

O mesmo padrão funciona independentemente do que está a tentar evitar a falha. Por exemplo, se estiver preocupado com a falha de uma SAN, pode executar várias SANs. Se estiver preocupado com a perda de um rack de servidores, é executado em vários racks. Se estiver preocupado com a perda de datacenters, o seu serviço deve ser executado em várias regiões do Azure, em vários Zonas de Disponibilidade do Azure ou nos seus próprios datacenters.

Quando um serviço é distribuído por várias instâncias físicas (máquinas, racks, datacenters, regiões), ainda está sujeito a alguns tipos de falhas simultâneas. Mas as falhas individuais e mesmo múltiplas de um determinado tipo (por exemplo, uma única máquina virtual ou ligação de rede a falhar) são processadas automaticamente, pelo que já não são um "desastre".

O Service Fabric fornece mecanismos para expandir o cluster e processa a reativação de nós e serviços com falhas. O Service Fabric também permite executar muitas instâncias dos seus serviços para evitar que falhas não planeadas se transformem em desastres reais.

Pode haver razões pelas quais a execução de uma implementação suficientemente grande para abranger falhas não é viável. Por exemplo, pode ser necessário mais recursos de hardware do que está disposto a pagar relativamente à possibilidade de falha. Quando lida com aplicações distribuídas, os saltos de comunicação adicionais ou os custos de replicação de estado em distâncias geográficas podem causar latência inaceitável. Quando esta linha é desenhada, é diferente para cada aplicação.

Para falhas de software especificamente, a falha pode estar no serviço que está a tentar dimensionar. Neste caso, mais cópias não impedem o desastre, porque a condição de falha está correlacionada em todas as instâncias.

Falhas operacionais

Mesmo que o seu serviço esteja distribuído por todo o mundo com muitas redundâncias, ainda pode experienciar eventos desastrosos. Por exemplo, alguém pode reconfigurar acidentalmente o nome DNS do serviço ou eliminá-lo totalmente.

Por exemplo, digamos que tinha um serviço do Service Fabric com estado e que alguém eliminou esse serviço acidentalmente. A menos que haja outra mitigação, esse serviço e todo o estado que tinha já se foram. Estes tipos de desastres operacionais ("oops") requerem mitigações e passos diferentes para a recuperação do que falhas regulares não planeadas.

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

  • Restringir o acesso operacional ao ambiente.
  • Audite estritamente operações perigosas.
  • Imponha automatização, impeça alterações manuais ou fora de banda e valide alterações específicas no ambiente antes de as decretar.
  • Certifique-se de que as operações destrutivas são "suaves". As operações suaves não são aplicadas imediatamente ou podem ser anuladas dentro de um período de tempo.

O Service Fabric fornece mecanismos para evitar falhas operacionais, como o fornecimento de controlo de acesso baseado em funções para operações de cluster. No entanto, a maioria destas falhas operacionais requer esforços organizacionais e outros sistemas. O Service Fabric fornece mecanismos para sobreviver a falhas operacionais, nomeadamente cópia de segurança e restauro para serviços com estado.

Gerir falhas

O objetivo do Service Fabric é a gestão automática de falhas. Contudo, para lidar com alguns tipos de falhas, os serviços têm de ter código adicional. Outros tipos de falhas não devem ser resolvidos automaticamente por motivos de segurança e continuidade empresarial.

Lidar com falhas individuais

As máquinas individuais podem falhar por todos os tipos de razões. Por vezes, são causas de hardware, como fontes de alimentação e falhas de hardware de rede. Outras falhas estão no software. Estas incluem falhas do sistema operativo e do próprio serviço. O Service Fabric deteta automaticamente estes tipos de falhas, incluindo casos em que a máquina fica isolada de outras máquinas devido a problemas de rede.

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

Para lidar com qualquer falha individual, a coisa mais simples que pode fazer é garantir que os seus serviços são executados em mais do que um nó por predefinição. Para serviços sem estado, certifique-se de que InstanceCount é superior a 1. Para serviços com estado, a recomendação mínima é que TargetReplicaSetSize e MinReplicaSetSize estão ambos definidos como 3. Executar mais cópias do seu código de serviço garante que o seu serviço consegue lidar automaticamente com qualquer falha individual.

Lidar com falhas coordenadas

As falhas coordenadas num cluster podem dever-se a falhas e alterações de infraestrutura planeadas ou não planeadas ou alterações de software planeadas. O Service Fabric modela zonas de infraestrutura que experimentam falhas coordenadas como domínios de falha. As áreas que irão sofrer alterações de software coordenadas são modeladas como domínios de atualização. Para obter mais informações sobre domínios de falha, domínios de atualização e topologia de cluster, veja Descrever um cluster do Service Fabric com o Cluster Resource Manager.

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

Por exemplo, digamos que a falha de uma fonte de energia faz com que todas as máquinas num rack falhem simultaneamente. Com várias cópias do serviço em execução, a perda de muitas máquinas em falhas de domínio de falha transforma-se apenas mais um exemplo de uma única falha para um serviço. É por isso que a gestão de domínios de falha e atualização é fundamental para garantir a elevada disponibilidade dos seus serviços.

Quando está a executar o Service Fabric no Azure, os domínios de falha e os domínios de atualização são geridos automaticamente. Noutros ambientes, podem não estar. Se estiver a criar os seus próprios clusters no local, certifique-se de que mapeia e planeia corretamente o esquema do seu domínio de falha.

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

Pode visualizar o esquema do cluster com o mapa de cluster fornecido no Service Fabric Explorer:

Nós distribuídos por domínios de falha no Service Fabric Explorer

Nota

As áreas de modelação de falhas, atualizações sem interrupção, execução de muitas instâncias do seu código de serviço e estado, regras de colocação para garantir que os seus serviços são executados em domínios de falha e atualização, e a monitorização do estado de funcionamento incorporada são apenas algumas das funcionalidades fornecidas pelo Service Fabric para evitar que os problemas operacionais normais e as falhas se transformem em desastres.

Lidar com falhas simultâneas de hardware ou software

Temos falado de falhas individuais. Como pode ver, são fáceis de processar para serviços sem estado e com estado apenas mantendo mais cópias do código (e estado) em execução em domínios de falha e atualização.

Também podem ocorrer várias falhas aleatórias simultâneas. Estes são mais propensos a causar um período de indisponibilidade ou um desastre real.

Serviços sem estado

A contagem de instâncias de um serviço sem estado indica o número pretendido de instâncias que precisam de ser executadas. Quando qualquer (ou todos) das instâncias falham, o Service Fabric responde ao criar automaticamente instâncias de substituição noutros nós. O Service Fabric continua a criar substituições até que o serviço volte à contagem de instâncias pretendida.

Por exemplo, suponha que o serviço sem estado tem um InstanceCount valor de -1. Este valor significa que uma instância deve estar em execução em cada nó no cluster. Se algumas dessas instâncias falharem, o Service Fabric detetará que o serviço não está no estado pretendido e tentará criar as instâncias nos nós onde estão em falta.

Serviços com estado

Existem dois tipos de serviços com estado:

  • Com estado persistente.
  • Com estado com estado não persistente. (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, do número de réplicas que o serviço tinha e de quantas réplicas falharam.

Num serviço com estado, os dados recebidos são replicados entre réplicas (primárias e secundárias ativas). Se a maioria das réplicas receber os dados, os dados são considerados consolidados pelo quórum . (Para cinco réplicas, três serão quórum.) Isto significa que, a qualquer momento, haverá, pelo menos, um quórum de réplicas com os dados mais recentes. Se as réplicas falharem (digamos dois em cinco), podemos utilizar o valor do quórum para calcular se podemos recuperar. (Uma vez que as restantes três em cada cinco réplicas ainda estão em funcionamento, é garantido que pelo menos uma réplica terá dados completos.)

Quando um quórum de réplicas falha, a partição é declarada como estando num estado de perda de quórum . Digamos que uma partição tem cinco réplicas, o que significa que pelo menos três têm dados completos garantidos. Se um quórum (três em cinco) de réplicas falhar, o Service Fabric não consegue determinar se as réplicas restantes (duas em cinco) têm dados suficientes para restaurar a partição. Nos casos em que o Service Fabric deteta a perda de quórum, o comportamento predefinido é impedir escritas adicionais na partição, declarar perda de quórum e aguardar que seja restaurado um quórum de réplicas.

Determinar se ocorreu um desastre para um serviço com estado e, em seguida, geri-lo segue três fases:

  1. Determinar se houve ou não perda de quórum.

    A perda de quórum é declarada quando a maioria das réplicas de um serviço com estado estão inativas ao mesmo tempo.

  2. Determinar se a perda de quórum é 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 relançadas e as partições de rede são curadas. Por vezes, porém, as falhas são permanentes. Se as falhas são permanentes ou não depende se o serviço com estado persiste ou se mantém apenas na memória:

    • Para serviços sem estado persistente, uma falha de um quórum ou de mais réplicas resulta imediatamente na perda permanente de quórum. Quando o Service Fabric deteta a perda de quórum num serviço não persistente com estado, continua imediatamente para o passo 3 declarando (potencial) perda de dados. Continuar a perder dados faz sentido porque o Service Fabric sabe que não faz sentido esperar que as réplicas voltem. Mesmo que recuperem, os dados serão perdidos devido à natureza não persistente do serviço.
    • Para serviços persistentes com estado, uma falha de um quórum ou de mais réplicas faz com que o Service Fabric aguarde que as réplicas regressem e restaurem o quórum. Isto resulta numa falha de serviço para quaisquer escritas na partição afetada (ou "conjunto de réplicas") do serviço. No entanto, as leituras podem continuar a ser possíveis com garantias de consistência reduzidas. A quantidade predefinida de tempo que o Service Fabric espera que o quórum seja restaurado é infinita, porque o processo é um evento (potencial) de perda de dados e acarreta outros riscos. Isto significa que o Service Fabric não avançará para o passo seguinte, a menos que um administrador tome medidas para declarar a perda de dados.

  3. Determinar se os dados são perdidos e restaurar a partir de cópias de segurança.

    Se a perda de quórum tiver sido declarada (automaticamente ou através de uma ação administrativa), o Service Fabric e os serviços avançarão para determinar se os dados foram realmente perdidos. Neste momento, o Service Fabric também sabe que as outras réplicas não estão a voltar. Esta foi a decisão tomada quando deixámos de esperar que a perda de quórum se resolvesse. Normalmente, a melhor ação para o serviço é fixar e aguardar por uma intervenção administrativa específica.

    Quando o Service Fabric chama o OnDataLossAsync método, é sempre devido a suspeitas de perda de dados. O Service Fabric garante que esta chamada é entregue na melhor réplica restante. Esta é a réplica que fez mais progressos.

    A razão pela qual dizemos sempre a suspeita de perda de dados é que é possível que a réplica restante tenha o mesmo estado que a primária fez quando o quórum foi perdido. No entanto, sem esse estado para compará-lo, não há uma boa forma de o Service Fabric ou os operadores saberem ao certo.

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

    1. Os registos de implementação que OnDataLossAsync foram acionados e acionam todos os alertas administrativos necessários.

    2. Normalmente, a implementação coloca em pausa e aguarda que sejam tomadas novas decisões e ações manuais. Isto acontece porque, mesmo que as cópias de segurança estejam disponíveis, poderão ter de estar preparadas.

      Por exemplo, se dois serviços diferentes coordenarem informações, essas cópias de segurança poderão ter de ser modificadas para garantir que, após o restauro, as informações de que esses dois serviços se preocupam são consistentes.

    3. Muitas vezes, existe outra telemetria ou esgotamento do serviço. Estes metadados podem estar contidos noutros serviços ou nos registos. Estas informações podem ser utilizadas conforme necessário para determinar se foram recebidas e processadas chamadas na primária que não estavam presentes na cópia de segurança ou replicadas para esta réplica específica. Estas chamadas podem ter de ser reproduzidas ou adicionadas à cópia de segurança antes de o restauro ser viável.

    4. A implementação compara o estado da réplica restante com o contido em quaisquer cópias de segurança disponíveis. Se estiver a utilizar coleções fiáveis do Service Fabric, existem ferramentas e processos disponíveis para o fazer. O objetivo é ver se o estado na réplica é suficiente e ver o que a cópia de segurança pode estar em falta.

    5. Depois de concluída a comparação e após a conclusão do restauro (se necessário), o código de serviço deverá ser devolvido verdadeiro se forem efetuadas alterações de estado. Se a réplica determinou que era a melhor cópia disponível do estado e não efetuou alterações, o código devolve falso.

      Um valor verdadeiro indica que quaisquer outras réplicas restantes podem agora ser inconsistentes com esta. Serão largadas e reconstruídas a partir desta réplica. Um valor de falso indica que não foram efetuadas alterações de estado, pelo que as outras réplicas podem manter o que têm.

É extremamente importante que os autores de serviços pratiquem potenciais cenários de perda e falha de dados antes de os serviços serem implementados na produção. Para proteger contra a possibilidade de perda de dados, é importante fazer periodicamente uma cópia de segurança do estado de qualquer um dos seus serviços com monitorização de estado num arquivo georredundante.

Também tem de garantir que tem a capacidade de restaurar o estado. Uma vez que as cópias de segurança de muitos serviços diferentes são efetuadas em momentos diferentes, tem de garantir que, após um restauro, os seus serviços têm uma vista consistente entre si.

Por exemplo, considere uma situação em que um serviço gera um número e o armazena e, em seguida, envia-o para outro serviço que também o armazena. Após um restauro, poderá descobrir que o segundo serviço tem o número, mas o primeiro não, porque a cópia de segurança não incluiu essa operação.

Se descobrir que as réplicas restantes são insuficientes para continuar num cenário de perda de dados e não conseguir reconstruir o estado do serviço a partir da telemetria ou do esgotamento, a frequência das cópias de segurança determina o seu melhor objetivo de ponto de recuperação (RPO). O Service Fabric fornece muitas ferramentas para testar vários cenários de falha, incluindo quórum permanente e perda de dados que requerem restauro a partir de uma cópia de segurança. Estes cenários são incluídos como parte das ferramentas de teste no Service Fabric, geridas pelo Serviço de Análise de Falhas. Para obter mais informações sobre essas ferramentas e padrões, veja Introdução ao Serviço de Análise de Falhas.

Nota

Os serviços de sistema também podem sofrer perda de quórum. O impacto é específico do serviço em questão. Por exemplo, a perda de quórum no serviço de nomenclatura afeta a resolução de nomes, enquanto a perda de quórum no serviço Gestor de Ativação Pós-falha bloqueia a criação de novos serviços e as ativações pós-falha.

Os serviços de sistema do Service Fabric seguem o mesmo padrão que os seus serviços para gestão de estado, mas não recomendamos que tente movê-los para fora da perda de quórum e para potenciais perdas de dados. Em vez disso, recomendamos que procure suporte para encontrar uma solução direcionada para a sua situação. Normalmente, é preferível esperar até que as réplicas para baixo regressem.

Resolver problemas de perda de quórum

As réplicas podem estar inativas intermitentemente devido a uma falha transitória. Aguarde algum tempo enquanto o Service Fabric tenta trazê-los para cima. Se as réplicas estiverem inativas há mais do que o esperado, siga estas ações de resolução de problemas:

  • As réplicas podem estar a falhar. Verifique os relatórios de estado de funcionamento ao nível da réplica e os registos da aplicação. Recolha informações de falha de sistema e tome as ações necessárias para recuperar.
  • O processo de réplica pode ter ficado sem resposta. Inspecione os registos da sua aplicação para verificar esta situação. Recolha informações de falha de sistema do processo e, em seguida, pare o processo sem resposta. O Service Fabric irá criar um processo de substituição e tentará trazer a réplica de volta.
  • Os nós que alojam as réplicas podem estar inativos. Reinicie a máquina virtual subjacente para aumentar os nós.

Por vezes, poderá não ser possível recuperar réplicas. Por exemplo, as unidades falharam ou os computadores fisicamente não estão a responder. Nestes casos, o Service Fabric tem de ser informado para não esperar pela recuperação da réplica.

Não utilize estes métodos se a potencial perda de dados for inaceitável para colocar o serviço online. Nesse caso, devem ser envidados todos os esforços para recuperar máquinas físicas.

As seguintes ações podem resultar na perda de dados. Verifique antes de os seguir.

Nota

Nunca é seguro utilizar estes métodos para além de uma forma direcionada contra partições específicas.

  • Utilize a Repair-ServiceFabricPartition -PartitionId API ou System.Fabric.FabricClient.ClusterManagementClient.RecoverPartitionAsync(Guid partitionId) . Esta API permite especificar o ID da partição para sair da perda de quórum e para potencial perda de dados.
  • Se o cluster encontrar falhas frequentes que fazem com que os serviços entrem num estado de perda de quórum e a potencial perda de dados for aceitável, especificar um valor QuorumLossWaitDuration adequado pode ajudar o seu serviço a recuperar automaticamente. O Service Fabric aguardará pelo valor fornecido QuorumLossWaitDuration (a predefinição é infinita) antes de efetuar a recuperação. Não recomendamos este método porque 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 nó não causará problemas de disponibilidade ou fiabilidade para o cluster, principalmente porque os serviços de sistema do Service Fabric seguem as mesmas diretrizes fornecidas anteriormente. Ou seja, são sempre executados com três ou mais réplicas por predefinição e serviços de sistema que são executados sem estado em todos os nós.

As camadas de rede e deteção de falhas subjacentes do Service Fabric estão totalmente distribuídas. A maioria dos serviços de sistema pode ser reconstruída a partir de metadados no cluster ou saber como ressincronizar o estado a partir de outros locais. A disponibilidade do cluster pode ficar comprometida se os serviços do sistema entrarem em situações de perda de quórum, como as descritas anteriormente. Nestes casos, poderá não conseguir efetuar determinadas operações no cluster (como iniciar uma atualização ou implementar novos serviços), mas o cluster em si ainda está em funcionamento.

Os serviços num cluster em execução continuarão a ser executados nestas condições, a menos que necessitem de escritas nos serviços do sistema para continuarem a funcionar. Por exemplo, se o Gestor de Ativação Pós-falha estiver em perda de quórum, todos os serviços continuarão a ser executados. No entanto, quaisquer serviços que falhem não poderão ser reiniciados automaticamente, porque isto requer o envolvimento do Gestor de Ativação Pós-falha.

Falhas de um datacenter ou de uma região do Azure

Em casos raros, um datacenter físico pode ficar temporariamente indisponível devido à perda de energia ou conectividade de rede. Nestes casos, os clusters e serviços do Service Fabric nessa região do datacenter ou do Azure estarão indisponíveis. No entanto, os seus dados são preservados.

Para clusters em execução no Azure, pode ver atualizações sobre falhas na página de estado do Azure. No caso altamente improvável de um datacenter físico ser parcial ou totalmente destruído, todos os clusters do Service Fabric aí alojados, ou os serviços dentro dos mesmos, poderão perder-se. Esta perda inclui qualquer estado que não tenha sido efetuado uma cópia de segurança fora desse datacenter ou região.

Existem várias estratégias diferentes para sobreviver à falha permanente ou sustentada de um único datacenter ou região:

  • Execute clusters do Service Fabric separados em várias regiões e utilize algum mecanismo para ativação pós-falha e reativação pós-falha entre estes ambientes. Este tipo de modelo ativo/ativo ou ativo/passivo de múltiplos clusters requer código de operações e gestão adicionais. Este modelo também requer coordenação de cópias de segurança dos serviços num datacenter ou região para que estejam disponíveis noutros datacenters ou regiões quando uma falha.

  • Execute um único cluster do Service Fabric que abrange vários datacenters. A configuração mínima suportada para esta estratégia é três datacenters. Para obter mais informações, veja Implementar um cluster do Service Fabric em Zonas de Disponibilidade.

    Este modelo requer uma configuração adicional. No entanto, o benefício é que a falha de um datacenter é convertida de um desastre numa falha normal. Estas falhas podem ser processadas pelos mecanismos que funcionam para clusters numa única região. Os domínios de falha, os domínios de atualização e as regras de colocação do Service Fabric garantem que as cargas de trabalho são distribuídas de modo a tolerarem falhas normais.

    Para obter mais informações sobre políticas que podem ajudar a operar serviços neste tipo de cluster, veja Políticas de colocação para serviços do Service Fabric.

  • Execute um único cluster do Service Fabric que abrange várias regiões com o modelo Autónomo. O número recomendado de regiões é três. Veja Criar um cluster autónomo para obter detalhes sobre a configuração autónoma do Service Fabric.

Falhas aleatórias que levam a falhas de cluster

O Service Fabric tem o conceito de nós de seed. Estes são nós que mantêm a disponibilidade do cluster subjacente.

Os nós de sementes ajudam a garantir que o cluster se mantém atualizado ao estabelecer concessões com outros nós e servir como desempates durante determinados tipos de falhas. Se as falhas aleatórias removerem a maioria dos nós de seed no cluster e não forem reativadas rapidamente, o cluster será encerrado automaticamente. Em seguida, o cluster falha.

No Azure, o Fornecedor de Recursos do Service Fabric gere as configurações do cluster do Service Fabric. Por predefinição, o Fornecedor de Recursos distribui nós de seed entre domínios de falha e atualização para o tipo de nó primário. Se o tipo de nó primário estiver marcado como Durabilidade Silver ou Gold, quando remover um nó de semente (ao dimensionar no tipo de nó primário ou ao removê-lo manualmente), o cluster tentará promover outro nó não semente da capacidade disponível do tipo de nó primário. Esta tentativa falhará se tiver menos capacidade disponível do que o nível de fiabilidade do cluster necessário para o tipo de nó principal.

Tanto nos clusters autónomos do Service Fabric como no Azure, o tipo de nó principal é aquele que executa as sementes. Quando estiver a definir um tipo de nó primário, o Service Fabric irá tirar partido automaticamente do número de nós fornecidos ao criar até nove nós de seed e sete réplicas de cada serviço de sistema. Se um conjunto de falhas aleatórias eliminar a maioria dessas réplicas em simultâneo, os serviços do sistema irão introduzir perda de quórum. Se a maioria dos nós de seed for perdida, o cluster será encerrado logo a seguir.

Passos seguintes