Réplicas e instâncias
Este artigo fornece uma visão geral do ciclo de vida de réplicas de serviços com monitoração de estado e instâncias de serviços sem monitoração de estado.
Instâncias de serviços sem estado
Uma instância de um serviço sem estado é uma cópia da lógica de serviço que é executada em um dos nós do cluster. Uma instância dentro de uma partição é identificada exclusivamente por seu InstanceId. O ciclo de vida de uma instância é modelado no diagrama a seguir:
InBuild (IB)
Depois que o Gerenciador de Recursos de Cluster determina um posicionamento para a instância, ele entra nesse estado do ciclo de vida. A instância é iniciada no nó. O host do aplicativo é iniciado, a instância é criada e, em seguida, aberta. Após a conclusão da inicialização, a instância transita para o estado pronto.
Se o host ou nó do aplicativo para esta instância falhar, ele fará a transição para o estado descartado.
Pronto (RD)
No estado pronto, a instância está ativa e em execução no nó. Se esta instância for um serviço confiável, RunAsync foi invocado.
Se o host ou nó do aplicativo para esta instância falhar, ele fará a transição para o estado descartado.
Encerramento (CL)
No estado de fechamento, o Azure Service Fabric está no processo de desligamento da instância nesse nó. Esse desligamento pode ser devido a vários motivos, por exemplo, uma atualização de aplicativo, balanceamento de carga ou o serviço sendo excluído. Depois que o desligamento termina, ele passa para o estado descartado.
Caído (DD)
No estado descartado, a instância não está mais em execução no nó. Neste ponto, o Service Fabric mantém os metadados sobre essa instância, que eventualmente também são excluídos.
Nota
É possível fazer a transição de qualquer estado para o estado descartado usando a opção ForceRemove no Remove-ServiceFabricReplica.
Réplicas de serviços com monitoração de estado
Uma réplica de um serviço com monitoração de estado é uma cópia da lógica de serviço em execução em um dos nós do cluster. Além disso, a réplica mantém uma cópia do estado desse serviço. Dois conceitos relacionados descrevem o ciclo de vida e o comportamento de réplicas com monitoração de estado:
- Ciclo de vida da réplica
- Função de réplica
A discussão a seguir descreve serviços com monitoração de estado persistentes. Para serviços com estado voláteis (ou na memória), os estados para baixo e para baixo são equivalentes.
InBuild (IB)
Uma réplica do InBuild é uma réplica criada ou preparada para ingressar no conjunto de réplicas. Dependendo da função da réplica, o IB tem semânticas diferentes.
Se o host do aplicativo ou o nó de uma réplica do InBuild falhar, ele passará para o estado inativo.
Réplicas primárias do InBuild: o InBuild primário é a primeira réplica de uma partição. Essa réplica geralmente acontece quando a partição está sendo criada. As réplicas primárias do InBuild também surgem quando todas as réplicas de uma partição são reiniciadas ou descartadas.
Réplicas InBuild IdleSecondary : são réplicas novas criadas pelo Gerenciador de Recursos de Cluster ou réplicas existentes que foram inativas e precisam ser adicionadas novamente ao conjunto. Essas réplicas são semeadas ou criadas pelo primário antes de poderem se juntar ao conjunto de réplicas como ActiveSecondary e participar da confirmação de quórum das operações.
Réplicas do ActiveSecondary InBuild: esse estado é observado em algumas consultas. É uma otimização em que o conjunto de réplicas não está mudando, mas uma réplica precisa ser construída. A réplica em si segue as transições normais da máquina de estado (conforme descrito na seção sobre funções de réplica).
Pronto (RD)
Uma réplica Ready é uma réplica que participa da replicação e da confirmação de quórum das operações. O estado ready é aplicável a réplicas primárias e secundárias ativas.
Se o host do aplicativo ou o nó de uma réplica pronta falhar, ele passará para o estado inativo.
Encerramento (CL)
Uma réplica entra no estado de fechamento nos seguintes cenários:
Desligando o código da réplica: o Service Fabric pode precisar desligar o código em execução de uma réplica. Esse desligamento pode ser por vários motivos. Por exemplo, isso pode acontecer devido a uma atualização de aplicativo, malha ou infraestrutura, ou devido a uma falha relatada pela réplica. Quando o fechamento da réplica termina, a réplica passa para o estado inativo. O estado persistente associado a esta réplica armazenada no disco não é limpo.
Removendo a réplica do cluster: o Service Fabric pode precisar remover o estado persistente e desligar o código em execução de uma réplica. Esse desligamento pode ser por vários motivos, por exemplo, balanceamento de carga.
Caído (DD)
No estado descartado, a instância não está mais em execução no nó. Também não há nenhum estado restante no nó. Neste ponto, o Service Fabric mantém os metadados sobre essa instância, que eventualmente também são excluídos.
Para baixo (D)
No estado inativo, o código da réplica não está em execução, mas o estado persistente dessa réplica existe nesse nó. Uma réplica pode estar inativa por vários motivos, por exemplo, o nó estar inativo, uma falha no código da réplica, uma atualização de aplicativo ou falhas de réplica.
Uma réplica inativa é aberta pelo Service Fabric conforme necessário, por exemplo, quando a atualização é concluída no nó.
A função de réplica não é relevante no estado inativo.
Abertura (OP)
Uma réplica inativa entra no estado de abertura quando o Service Fabric precisa trazer a réplica de volta para cima. Por exemplo, esse estado pode ser após a conclusão de uma atualização de código para o aplicativo em um nó.
Se o host do aplicativo ou o nó de uma réplica de abertura falhar, ele passará para o estado inativo.
A função de réplica não é relevante no estado de abertura.
Em espera (SB)
Uma réplica em espera é uma réplica de um serviço persistente que caiu e foi aberto. Essa réplica pode ser usada pelo Service Fabric se precisar adicionar outra réplica ao conjunto de réplicas (porque a réplica já tem alguma parte do estado e o processo de compilação é mais rápido). Depois que o StandByReplicaKeepDuration expirar, a réplica em espera será descartada.
Se o host do aplicativo ou o nó de uma réplica em espera falhar, ele passará para o estado inativo.
A função de réplica não é relevante no estado de espera.
Nota
Qualquer réplica que não esteja inativa ou descartada é considerada ativa.
Nota
É possível fazer a transição de qualquer estado para o estado descartado usando a opção ForceRemove no Remove-ServiceFabricReplica.
Função de réplica
A função da réplica determina sua função no conjunto de réplicas:
- Primário (P): há um primário no conjunto de réplicas que é responsável por executar operações de leitura e gravação.
- ActiveSecondary (S): São réplicas que recebem atualizações de estado do primário, aplicam-nas e, em seguida, enviam confirmações. Há vários secundários ativos no conjunto de réplicas. O número desses secundários ativos determina o número de falhas que o serviço pode tratar.
- IdleSecondary (I): Estas réplicas estão a ser construídas pelo primário. Eles estão recebendo estado do primário antes de poderem ser promovidos a secundário ativo.
- Nenhuma (N): Essas réplicas não têm responsabilidade no conjunto de réplicas.
- Desconhecido (U): Esta é a função inicial de uma réplica antes de receber qualquer chamada de API ChangeRole do Service Fabric.
O diagrama a seguir ilustra as transições de função de réplica e alguns cenários de exemplo nos quais elas podem ocorrer:
- U -> P: Criação de uma nova réplica primária.
- U -> I: Criação de uma nova réplica ociosa.
- U -> N: Eliminação de uma réplica em espera.
- I -> S: Promoção do ocioso secundário para o ativo secundário para que seus reconhecimentos contribuam para o quórum.
- I -> P: Promoção do ocioso secundário ao primário. Isso pode acontecer em reconfigurações especiais quando o secundário ocioso é o candidato correto para ser primário.
- I -> N: Eliminação da réplica secundária ociosa.
- S -> P: Promoção do ativo secundário ao primário. Isso pode ser devido ao failover do movimento primário ou primário iniciado pelo Gerenciador de Recursos de Cluster. Por exemplo, pode ser em resposta a uma atualização de aplicativo ou balanceamento de carga.
- S -> N: Exclusão da réplica secundária ativa.
- P -> S: Rebaixamento da réplica primária. Isso pode ser devido a um movimento primário iniciado pelo Gerenciador de Recursos de Cluster. Por exemplo, pode ser em resposta a uma atualização de aplicativo ou balanceamento de carga.
- P -> N: Exclusão da réplica primária.
Nota
Modelos de programação de nível superior, como Reliable Actors e Reliable Services, ocultam o conceito de funções de réplica do desenvolvedor. Em Atores, a noção de um papel é desnecessária. Em Serviços, é amplamente simplificado para a maioria dos cenários.
Próximos passos
Para obter mais informações sobre conceitos do Service Fabric, consulte o seguinte artigo: