Perguntas comuns acerca do Service Fabric

  • Artigo

Há muitas perguntas frequentes sobre o que o Service Fabric pode fazer e como ele deve ser usado. Este documento abrange muitas dessas perguntas comuns e as suas respostas.

Nota

Recomendamos que utilize o módulo do Azure Az PowerShell para interagir com o Azure. Veja Instalar o Azure PowerShell para começar. Para saber como migrar para o módulo do Az PowerShell, veja Migrar o Azure PowerShell do AzureRM para o Az.

Configuração e gerenciamento de clusters

Como faço para reverter meu certificado de cluster do Service Fabric?

A reversão de qualquer atualização para seu aplicativo requer a deteção de falhas de integridade antes que o quórum de cluster do Service Fabric confirme a alteração; as alterações confirmadas só podem ser roladas para a frente. Os engenheiros de escalonamento por meio dos Serviços de Suporte ao Cliente podem ser necessários para recuperar seu cluster, se uma alteração de certificado de quebra não monitorada tiver sido introduzida. A atualização de aplicativos do Service Fabric aplica parâmetros de atualização de aplicativos e oferece zero promessa de atualização de tempo de inatividade. Seguindo nosso modo monitorado de atualização de aplicativo recomendado, o progresso automático através de domínios de atualização é baseado na aprovação de verificações de integridade, revertendo automaticamente se a atualização de um serviço padrão falhar.

Se o cluster ainda estiver aproveitando a propriedade clássica Impressão digital do certificado no modelo do Gerenciador de recursos, é recomendável alterar o cluster da impressão digital do certificado para o nome comum, para aproveitar os recursos modernos de gerenciamento de segredos.

Posso criar um cluster que abranja várias regiões do Azure ou os meus próprios datacenters?

Sim.

A principal tecnologia de cluster do Service Fabric pode ser usada para combinar máquinas em execução em qualquer lugar do mundo, desde que tenham conectividade de rede entre si. No entanto, construir e executar esse cluster pode ser complicado.

Se você estiver interessado nesse cenário, recomendamos que entre em contato por meio da Lista de Problemas do GitHub do Service Fabric ou por meio de seu representante de suporte para obter orientações adicionais. A equipe do Service Fabric está trabalhando para fornecer clareza, orientação e recomendações adicionais para esse cenário.

Alguns aspetos a ter em conta:

  1. O recurso de cluster do Service Fabric no Azure é regional hoje, assim como os conjuntos de escala de máquina virtual nos quais o cluster é criado. Isso significa que, no caso de uma falha regional, você pode perder a capacidade de gerenciar o cluster por meio do Gerenciador de Recursos do Azure ou do portal do Azure. Isso pode acontecer mesmo que o cluster permaneça em execução e você possa interagir diretamente com ele. Além disso, o Azure hoje não oferece a capacidade de ter uma única rede virtual utilizável entre regiões. Isso significa que um cluster de várias regiões no Azure requer Endereços IP Públicos para cada VM nos conjuntos de escala de máquina virtual ou Gateways de VPN do Azure. Essas escolhas de rede têm impactos diferentes nos custos, no desempenho e, até certo ponto, no design do aplicativo, portanto, é necessária uma análise e um planejamento cuidadosos antes de criar tal ambiente.
  2. A manutenção, o gerenciamento e o monitoramento dessas máquinas podem se tornar complicados, especialmente quando abrangem vários tipos de ambientes, como entre diferentes provedores de nuvem ou entre recursos locais e o Azure. Deve-se tomar cuidado para garantir que as atualizações, o monitoramento, o gerenciamento e o diagnóstico sejam compreendidos para o cluster e os aplicativos antes de executar cargas de trabalho de produção em tal ambiente. Se você já tiver experiência em resolver esses problemas no Azure ou em seus próprios datacenters, é provável que essas mesmas soluções possam ser aplicadas ao criar ou executar seu cluster do Service Fabric.

Os nós do Service Fabric recebem automaticamente atualizações do sistema operacional?

Você pode usar o recurso Atualização Automática de Imagem do SO Conjunto de Dimensionamento de Máquina Virtual Geralmente Disponível hoje.

Para clusters que NÃO são executados no Azure, fornecemos um aplicativo para corrigir os sistemas operacionais abaixo dos nós do Service Fabric.

Posso usar grandes conjuntos de escala de máquina virtual no meu cluster SF?

Resposta curta - Não.

Resposta longa - Embora os grandes conjuntos de escala de máquina virtual permitam dimensionar uma configuração de escala de máquina virtual até 1000 instâncias de VM, ele faz isso usando grupos de posicionamento (PGs). Domínios de falha (FDs) e domínios de atualização (UDs) são consistentes apenas dentro de um grupo de posicionamento O Service Fabric usa FDs e UDs para tomar decisões de posicionamento de suas réplicas de serviço/instâncias de serviço. Uma vez que os FDs e UDs são comparáveis apenas dentro de um grupo de colocação, SF não pode usá-lo. Por exemplo, se VM1 em PG1 tem uma topologia de FD=0 e VM9 em PG2 tem uma topologia de FD=4, isso não significa que VM1 e VM2 estão em dois racks de hardware diferentes, portanto, SF não pode usar os valores FD neste caso para tomar decisões de posicionamento.

Existem outros problemas com grandes conjuntos de escala de máquina virtual atualmente, como a falta de suporte ao balanceamento de carga de nível 4. Consulte para obter detalhes sobre conjuntos de grande escala

Qual é o tamanho mínimo de um cluster do Service Fabric? Por que não pode ser menor?

O tamanho mínimo suportado para um cluster do Service Fabric que executa cargas de trabalho de produção é de cinco nós. Para cenários de desenvolvimento, oferecemos suporte a um nó (otimizado para experiência de desenvolvimento rápido no Visual Studio) e cinco clusters de nós.

Exigimos que um cluster de produção tenha pelo menos cinco nós devido aos três motivos a seguir:

  1. Mesmo quando nenhum serviço de usuário está em execução, um cluster do Service Fabric executa um conjunto de serviços do sistema com monitoração de estado, incluindo o serviço de nomenclatura e o serviço de gerenciador de failover. Estes serviços do sistema são essenciais para que o cluster se mantenha operacional.
  2. Sempre colocamos uma réplica de um serviço por nó, portanto, o tamanho do cluster é o limite superior para o número de réplicas que um serviço (na verdade, uma partição) pode ter.
  3. Como uma atualização de cluster derrubará pelo menos um nó, queremos ter um buffer de pelo menos um nó, portanto, queremos que um cluster de produção tenha pelo menos dois nós além do mínimo. O mínimo é o tamanho do quórum de um serviço do sistema, conforme explicado abaixo.

Queremos que o cluster esteja disponível em face da falha simultânea de dois nós. Para que um cluster do Service Fabric esteja disponível, os serviços do sistema devem estar disponíveis. Os serviços do sistema com monitoração de estado, como o serviço de nomeação e o serviço de gerenciador de failover, que rastreiam quais serviços foram implantados no cluster e onde estão hospedados no momento, dependem de uma forte consistência. Essa forte coerência, por sua vez, depende da capacidade de obter quórum para qualquer atualização do estado desses serviços, onde um quórum representa uma maioria estrita das réplicas (N/2 +1) para um determinado serviço. Assim, se quisermos ser resilientes contra a perda simultânea de dois nós (portanto, perda simultânea de duas réplicas de um serviço do sistema), devemos ter ClusterSize - QuorumSize >= 2, o que força o tamanho mínimo a ser cinco. Para ver isso, considere que o cluster tem N nós e há N réplicas de um serviço do sistema -- uma em cada nó. O tamanho do quórum para um serviço do sistema é (N/2 + 1). A desigualdade acima parece N - (N/2 + 1) >= 2. Há dois casos a considerar: quando N é par e quando N é ímpar. Se N é par, diga N = 2*m onde m >= 1, a desigualdade parece 2*m - (2*m/2 + 1) >= 2 ou m >= 3. O mínimo para N é 6 e isso é alcançado quando m = 3. Por outro lado, se N é ímpar, diga N = 2*m+1 onde m >= 1, a desigualdade parece 2*m+1 - ( (2*m+1)/2 + 1 ) >= 2 ou 2*m+1 - (m+1) >= 2 ou m >= 2. O mínimo para N é 5 e isso é alcançado quando m = 2. Portanto, entre todos os valores de N que satisfazem a desigualdade ClusterSize - QuorumSize >= 2, o mínimo é 5.

Observe que, no argumento acima, assumimos que cada nó tem uma réplica de um serviço do sistema, portanto, o tamanho do quórum é calculado com base no número de nós no cluster. No entanto, alterando TargetReplicaSetSize , poderíamos tornar o tamanho do quórum menor que (N/2+1), o que poderia dar a impressão de que poderíamos ter um cluster menor que 5 nós e ainda ter 2 nós extras acima do tamanho do quórum. Por exemplo, em um cluster de 4 nós, se definirmos o TargetReplicaSetSize como 3, o tamanho do quórum com base em TargetReplicaSetSize será (3/2 + 1) ou 2, portanto, teremos ClusterSize - QuorumSize = 4-2 >= 2. No entanto, não podemos garantir que o serviço do sistema estará no quórum ou acima dele se perdermos qualquer par de nós simultaneamente, pode ser que os dois nós que perdemos estavam hospedando duas réplicas, então o serviço do sistema entrará em perda de quórum (tendo apenas uma única réplica restante) e ficará indisponível.

Com esse plano de fundo, vamos examinar algumas configurações de cluster possíveis:

Um nó: esta opção não fornece alta disponibilidade, uma vez que a perda do nó único por qualquer motivo significa a perda de todo o cluster.

Dois nós: um quórum para um serviço implantado em dois nós (N = 2) é 2 (2/2 + 1 = 2). Quando uma única réplica é perdida, é impossível criar um quórum. Como a execução de uma atualização de serviço requer a remoção temporária de uma réplica, essa não é uma configuração útil.

Três nós: com três nós (N=3), o requisito para criar um quórum ainda é de dois nós (3/2 + 1 = 2). Isso significa que você pode perder um nó individual e ainda manter o quórum, mas a falha simultânea de dois nós levará os serviços do sistema à perda de quórum e fará com que o cluster fique indisponível.

Quatro nós: com quatro nós (N=4), o requisito para criar um quórum é de três nós (4/2 + 1 = 3). Isso significa que você pode perder um nó individual e ainda manter o quórum, mas a falha simultânea de dois nós levará os serviços do sistema à perda de quórum e fará com que o cluster fique indisponível.

Cinco nós: com cinco nós (N=5), o requisito para criar um quórum ainda é de três nós (5/2 + 1 = 3). Isso significa que você pode perder dois nós ao mesmo tempo e ainda manter o quórum para os serviços do sistema.

Para cargas de trabalho de produção, você deve ser resiliente a falhas simultâneas de pelo menos dois nós (por exemplo, um devido à atualização do cluster, um devido a outros motivos), para que cinco nós sejam necessários.

Posso desligar o meu cluster à noite/fins de semana para poupar custos?

Em geral, não. O Service Fabric armazena o estado em discos locais efêmeros, o que significa que, se a máquina virtual for movida para um host diferente, os dados não serão movidos com ela. Na operação normal, isso não é um problema, pois o novo nó é atualizado por outros nós. No entanto, se você parar todos os nós e reiniciá-los mais tarde, há uma possibilidade significativa de que a maioria dos nós comece em novos hosts e torne o sistema incapaz de se recuperar.

Se você quiser criar clusters para testar seu aplicativo antes que ele seja implantado, recomendamos que você crie dinamicamente esses clusters como parte de seu pipeline de integração contínua/implantação contínua.

Como faço para atualizar meu sistema operacional (por exemplo, do Windows Server 2012 para o Windows Server 2016)?

Enquanto estamos trabalhando em uma experiência aprimorada, hoje, você é responsável pela atualização. Você deve atualizar a imagem do sistema operacional nas máquinas virtuais do cluster uma VM de cada vez.

Posso criptografar discos de dados anexados em um tipo de nó de cluster (conjunto de escala de máquina virtual)?

Sim. Para obter mais informações, consulte Criar um cluster com discos de dados anexados e Azure Disk Encryption for Virtual Machine Scale Sets.

Posso usar VMs de baixa prioridade em um tipo de nó de cluster (conjunto de escala de máquina virtual)?

N.º Não há suporte para VMs de baixa prioridade.

Quais são os diretórios e processos que preciso excluir ao executar um programa antivírus no meu cluster?

Diretórios Antivírus Excluídos
Arquivos de Programas\Microsoft Service Fabric
FabricDataRoot (da configuração do cluster)
FabricLogRoot (da configuração do cluster)
Processos excluídos do antivírus
Fabric.exe
FabricHost.exe
FabricInstallerService.exe
FabricSetup.exe
FabricDeployer.exe
ImageBuilder.exe
FabricGateway.exe
FabricDCA.exe
FabricFAS.exe
FabricUOS.exe
FabricRM.exe
FileStoreService.exe

Como meu aplicativo pode se autenticar no Cofre da Chave para obter segredos?

A seguir estão os meios para seu aplicativo obter credenciais para autenticação no Cofre da Chave:

A. Durante o trabalho de compilação/empacotamento de aplicativos, você pode extrair um certificado para o pacote de dados do seu aplicativo SF e usá-lo para autenticar no Cofre de Chaves. B. Para hosts habilitados para MSI de conjunto de escala de máquina virtual, você pode desenvolver um SetupEntryPoint do PowerShell simples para seu aplicativo SF para obter um token de acesso do ponto de extremidade MSI e, em seguida , recuperar seus segredos do Cofre da Chave.

Posso transferir minha assinatura para outro locatário do Microsoft Entra?

N.º Neste momento, você precisará criar um novo recurso de cluster do Service Fabric depois que a assinatura tiver sido transferida para um locatário diferente do Microsoft Entra.

Posso mover/migrar meu cluster entre locatários do Microsoft Entra?

N.º Neste momento, você precisaria criar um novo recurso de cluster do Service Fabric sob o novo locatário.

Posso mover/migrar meu cluster entre assinaturas?

N.º Neste momento, você precisaria criar um novo recurso de cluster do Service Fabric sob a nova assinatura.

Posso mover/migrar meus recursos de cluster ou cluster para outros grupos de recursos ou renomeá-los?

N.º Neste momento, você precisaria criar um novo recurso de cluster do Service Fabric sob o novo grupo/nome de recursos.

Design de Aplicação

Qual é a melhor maneira de consultar dados entre partições de uma Coleção Confiável?

Coleções confiáveis geralmente são particionadas para permitir o dimensionamento para maior desempenho e taxa de transferência. Isso significa que o estado de um determinado serviço pode estar espalhado por dezenas ou centenas de máquinas. Para executar operações nesse conjunto de dados completo, você tem algumas opções:

  • Crie um serviço que consulte todas as partições de outro serviço para obter os dados necessários.
  • Crie um serviço que possa receber dados de todas as partições de outro serviço.
  • Envie periodicamente dados de cada serviço para um armazenamento externo. Essa abordagem só é apropriada se as consultas que você está realizando não fizerem parte da sua lógica de negócios principal, pois os dados do armazenamento externo serão obsoletos.
  • Como alternativa, armazene dados que devem oferecer suporte à consulta em todos os registros diretamente em um armazenamento de dados, em vez de em uma coleção confiável. Isso elimina o problema com dados obsoletos, mas não permite que as vantagens de coleções confiáveis sejam aproveitadas.

Qual é a melhor maneira de consultar dados entre meus atores?

Os atores são projetados para serem unidades independentes de estado e computação, portanto, não é recomendado executar consultas amplas do estado do ator em tempo de execução. Se você tiver a necessidade de consultar todo o conjunto completo do estado do ator, você deve considerar:

  • Substituindo seus serviços de ator por serviços confiáveis com monitoração de estado, para que o número de solicitações de rede para coletar todos os dados, desde o número de atores até o número de partições em seu serviço.
  • Projetando seus atores para enviar periodicamente seu estado para uma loja externa para facilitar a consulta. Como acima, essa abordagem só é viável se as consultas que você está executando não forem necessárias para seu comportamento de tempo de execução.

Quantos dados posso armazenar em uma coleção confiável?

Os serviços confiáveis geralmente são particionados, portanto, a quantidade que você pode armazenar é limitada apenas pelo número de máquinas que você tem no cluster e pela quantidade de memória disponível nessas máquinas.

Como exemplo, suponha que você tenha uma coleção confiável em um serviço com 100 partições e 3 réplicas, armazenando objetos que têm em média 1 kb de tamanho. Agora suponha que você tenha um cluster de 10 máquinas com 16 GB de memória por máquina. Para simplificar e ser conservador, suponha que o sistema operacional e os serviços do sistema, o tempo de execução do Service Fabric e seus serviços consomem 6 gb disso, deixando 10 gb disponíveis por máquina ou 100 gb para o cluster.

Tendo em mente que cada objeto deve ser armazenado três vezes (uma primária e duas réplicas), você teria memória suficiente para aproximadamente 35 milhões de objetos em sua coleção quando operando em plena capacidade. No entanto, recomendamos ser resiliente à perda simultânea de um domínio de falha e um domínio de atualização, o que representa cerca de 1/3 da capacidade, e reduziria o número para cerca de 23 milhões.

Este cálculo pressupõe ainda:

  • Que a distribuição de dados entre as partições é aproximadamente uniforme ou que você está relatando métricas de carga para o Gerenciador de Recursos de Cluster. Por padrão, o saldo de cargas do Service Fabric é baseado na contagem de réplicas. No exemplo anterior, isso colocaria 10 réplicas primárias e 20 réplicas secundárias em cada nó do cluster. Isso funciona bem para cargas distribuídas uniformemente pelas partições. Se a carga não for uniforme, você deverá relatar a carga para que o Gerenciador de Recursos possa agrupar réplicas menores e permitir que réplicas maiores consumam mais memória em um nó individual.

  • Que o serviço confiável em questão é o único que armazena o estado no cluster. Como você pode implantar vários serviços em um cluster, precisa estar atento aos recursos de que cada um precisa para executar e gerenciar seu estado.

  • Que o cluster em si não está crescendo ou encolhendo. Se você adicionar mais máquinas, o Service Fabric reequilibrará suas réplicas para aproveitar a capacidade adicional até que o número de máquinas ultrapasse o número de partições em seu serviço, já que uma réplica individual não pode abranger máquinas. Por outro lado, se você reduzir o tamanho do cluster removendo máquinas, suas réplicas serão compactadas com mais força e terão menos capacidade geral.

Quantos dados posso armazenar em um ator?

Assim como acontece com os serviços confiáveis, a quantidade de dados que você pode armazenar em um serviço de ator é limitada apenas pelo espaço total em disco e memória disponível nos nós do cluster. No entanto, os atores individuais são mais eficazes quando são usados para encapsular uma pequena quantidade de estado e lógica de negócios associada. Como regra geral, um ator individual deve ter um estado medido em kilobytes.

Onde o Provedor de Recursos do Azure Service Fabric armazena dados do cliente?

O Provedor de Recursos do Azure Service Fabric não move nem armazena dados do cliente para fora da região em que está implantado.

Outras questões

Como o Service Fabric se relaciona com contêineres?

Os contêineres oferecem uma maneira simples de empacotar serviços e suas dependências, de modo que sejam executados de forma consistente em todos os ambientes e possam operar de forma isolada em uma única máquina. O Service Fabric oferece uma maneira de implantar e gerenciar serviços, incluindo serviços que foram empacotados em um contêiner.

Você está planejando abrir o Service Fabric?

Temos partes de código aberto do Service Fabric (estrutura de serviços confiável, estrutura de atores confiáveis, bibliotecas de integração ASP.NET Core, Service Fabric Explorer e CLI do Service Fabric) no GitHub e aceitamos contribuições da comunidade para esses projetos.

Anunciamos recentemente que planejamos abrir o tempo de execução do Service Fabric. Neste ponto, temos o repositório do Service Fabric no GitHub com ferramentas de compilação e teste do Linux, o que significa que você pode clonar o repositório, compilar o Service Fabric para Linux, executar testes básicos, abrir problemas e enviar solicitações pull. Estamos trabalhando duro para migrar o ambiente de compilação do Windows também, juntamente com um ambiente de CI completo.

Siga o blog do Service Fabric para obter mais detalhes à medida que são anunciados.

Próximos passos

Saiba mais sobre os conceitos de tempo de execução e as práticas recomendadas do Service Fabric