Perguntas frequentes sobre o Service Fabric

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

Gerenciamento e instalação de cluster

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

Reverter qualquer atualização em sua aplicação requer a detecção de falhas de integridade antes que o quórum do seu cluster do Service Fabric confirme a alteração; alterações confirmadas só podem ser avançadas. Engenheiros de escalonamento, através dos Serviços de Suporte ao Cliente, podem ser necessários para recuperar seu cluster se algo introduzir uma alteração de certificado crítica não monitorada. A Atualização do aplicativo do Service Fabric aplica parâmetros de atualização de aplicativo e não oferece promessa de atualização de tempo de inatividade. Seguindo o nosso modo monitorado de atualização de aplicativo recomendado, o andamento automática através de domínios de atualização se baseia nas verificações de integridade sem interrupção, revertendo automaticamente se a atualização de um serviço padrão falhar.

Se o seu cluster ainda estiver usando a propriedade clássica de Impressão Digital de Certificado no seu modelo do Resource Manager, recomendamos que você Altere o cluster de impressão digital de certificado para nome comum, para aplicar os recursos modernos de gerenciamento de segredos.

É possível criar um cluster que abranja várias regiões do Azure ou meus próprios data centers?

Sim.

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

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

Veja a seguir alguns itens que você deve levar em consideração:

1. Atualmente, o recurso de cluster do Service Fabric no Azure é regional, assim como os conjuntos de dimensionamento de máquinas virtuais nos quais o cluster se baseia. Isso significa que, em caso de falha regional, você pode perder a capacidade de gerenciar o cluster por meio do Azure Resource Manager ou do Portal do Azure. Isso pode acontecer mesmo que o cluster permaneça em execução e que você possa interagir diretamente com ele. Além disso, o Azure atualmente não oferece a capacidade de ter uma única rede virtual que possa ser usada em várias regiões. Isso significa que um cluster de várias regiões do Azure requer endereços IP públicos para cada VM nos conjuntos de dimensionamento de máquina virtual ou Gateways de VPN do Azure. Essas opções de rede têm impactos diferentes sobre os custos, o desempenho e, até certo ponto, o design do aplicativo, de modo que análise e planejamento cuidadosos são necessários antes de manter um ambiente desse tipo.
2. A manutenção, o gerenciamento e o monitoramento dessas máquinas podem ficar complicados, especialmente quando distribuídas em tipos de ambientes, como entre provedores de nuvem diferentes ou entre recursos locais e o Azure. É necessário ter cuidado para garantir que as atualizações, o monitoramento, o gerenciamento e o diagnóstico sejam compreendidos para o cluster e para os aplicativos antes de executar cargas de trabalho de produção em um ambiente desse tipo. Se você já tem experiência em resolver esses problemas no Azure ou em seus próprios datacenters, é provável que as mesmas soluções possam ser aplicadas ao criar ou operar seu cluster do Service Fabric.

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

Você pode usar o recurso Atualização geral de imagem do sistema operacional em escala de computador virtual disponível hoje em dia.

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 conjuntos de dimensionamento de máquinas virtuais grandes no meu cluster do SF?

Resposta curta – Não.

Resposta longa – embora os conjuntos de dimensionamento de máquinas virtuais grandes permitam que você dimensione um conjunto de dimensionamento de máquinas virtuais até 1.000 instâncias de VM, isso é feito com o uso de PGs (Grupos de Posicionamento). FDs (domínios de falha) e UDs (domínios de atualização) só são consistentes dentro de um grupo de posicionamento. O Service Fabric usa UDs e FDs para tomar decisões de posicionamento de suas instâncias de serviço/réplicas de serviço. Como os FDs e UDs são comparáveis apenas em um grupo de posicionamento, o SF não pode usá-los. Por exemplo, se a VM1 no PG1 tiver uma topologia de FD=0 e a VM9 no PG2 tiver uma topologia de FD=4, isso não significa que a VM1 e a VM2 estejam em dois racks de hardware diferentes, portanto, o SF não pode usar os valores de FD nesse caso para tomar decisões de posicionamento.

Atualmente, há outros problemas com conjuntos de dimensionamento de máquinas virtuais grandes, como a falta de suporte para o balanceamento de carga de nível 4. Consulte para obter detalhes sobre grandes conjuntos de dimensionamento

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

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

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

1. Mesmo quando nenhum serviço de usuário estiver em execução, um cluster do Service Fabric executa um conjunto de serviços com sistema de estado, incluindo o serviço de nomes e o serviço de gerenciador de failover. Esses serviços do sistema são essenciais para o cluster permanecer operacional.
2. Sempre colocamos uma réplica de um serviço por nó, de modo que 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 desligará 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 necessário. O mínimo necessário é o tamanho do quorum de um serviço de sistema, conforme explicado abaixo.

Queremos que o cluster esteja disponíveis se houver falha simultânea de dois nós. Para que um cluster do Service Fabric esteja disponível, os serviços do sistema deverão estar disponíveis. Serviços de sistema com estado como serviço de nomenclatura e serviço de gerenciamento de failover, que controlam quais serviços foram implantados no cluster e onde eles estão hospedados atualmente, dependem de uma consistência forte. Essa consistência forte, por sua vez, depende da capacidade de adquirir um quorum para qualquer atualização para o estado desses serviços, onde um quorum representa a 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 (perda simultânea de duas réplicas de um serviço de sistema), devemos ter ClusterSize - QuorumSize >= 2, o que força o tamanho mínimo a ser cinco.

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, se alterássemos TargetReplicaSetSize, poderíamos deixar o tamanho do quorum menor que (N/2+1) que pode dar a impressão de que poderíamos ter um cluster menor do que 5 nós e ainda ter 2 nós extras acima do tamanho do quorum. Por exemplo, em um cluster de 4 nós, se definirmos o TargetReplicaSetSize como 3, o tamanho do quorum baseado em TargetReplicaSetSize será (3/2 + 1) ou 2 e, portanto, teremos ClusterSize - QuorumSize = 4-2 >= 2. No entanto, não podemos garantir que o serviço do sistema estará em ou acima do quórum se perdermos qualquer par de nós simultaneamente. Pode ser que os dois nós que perdemos estivessem hospedando duas réplicas, então o serviço do sistema entra em perda de quórum (ficando com apenas uma réplica restante) e se tornará indisponível.

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

Um nó: essa opção não oferece alta disponibilidade, pois a perda do único nó por qualquer motivo significa a perda de todo o cluster.

Dois nós: um quorum para um serviço implantado entre dois nós (N = 2) é 2 (2/2 + 1 = 2). Quando uma única réplica é perdida, é impossível criar um quorum. Como a realização de uma atualização de serviço exige a desativaçã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 quorum ainda é dois nós (3/2 + 1 = 2). Isso significa que você pode perder um nó individual e ainda manter o quorum, mas a falha simultânea de dois nós fará os serviços do sistema entrar em perda de quorum e fará o cluster se tornar indisponível.

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

Cinco nós: com cinco nós (N=5), o requisito para criar um quorum ainda é três nós (5/2 + 1 = 3). Isso significa que você pode perder dois nós ao mesmo tempo e ainda manter o quorum 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 de cluster, um por outros motivos), portanto, cinco nós são necessários.

Posso desativar meu cluster à noite/aos finais de semana para reduzir custos?

Em geral, não. O Service Fabric armazena o estado em discos locais e 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, haverá uma possibilidade significativa de a maioria dos nós iniciar em novos hosts e impossibilitar a recuperação do sistema.

Se você deseja criar clusters para testar seu aplicativo antes de implantá-lo, recomendamos que você crie esses clusters dinamicamente como parte do seu pipeline de integração/implantação contínua.

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

Embora estejamos 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 em uma VM por vez.

Posso criptografar discos de dados anexados em um tipo de nó de cluster (conjunto de dimensionamento de máquinas virtuais)?

Sim. Para obter mais informações, consulte criar um cluster com discos de dados anexados e Azure Disk Encryption para conjunto de dimensionamento de máquinas virtuais.

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

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

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

Como meu aplicativo pode se autenticar no Key Vault para obter segredos?

A seguir, os meios para o seu aplicativo obter credenciais para autenticação no Key Vault:

a. Durante o trabalho de criação / empacotamento de aplicativos, você pode inserir um certificado no pacote de dados do aplicativo SF e usá-lo para autenticar no Key Vault. B. Para os hosts habilitados para MSI de conjunto de dimensionamento de máquinas virtuais, você pode desenvolver um PowerShell SetupEntryPoint simples para seu aplicativo SF para obter um token de acesso do ponto de extremidade MSI e, em seguida, recuperar seus segredos de Key Vault.

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

Não. Neste momento, você precisaria 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ão. Neste momento, você precisaria criar um novo recurso de cluster do Service Fabric no novo locatário.

Posso mover/migrar meu cluster entre assinaturas?

Não. Neste momento, você precisaria criar um novo recurso de cluster do Service Fabric na nova assinatura.

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

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

Design do aplicativo

Qual a melhor maneira de consultar dados ao longo das partições de uma Coleção Confiável?

Coleções Confiáveis normalmente são particionadas para permitir a escalação horizontal para um melhor desempenho e resultado. Isso significa que o estado de um determinado serviço pode ser espalhado por dezenas ou centenas de máquinas. Para executar operações no conjunto de dados completo, você tem algumas opções:

• Criar um serviço que consulte todas as partições de outro serviço para obter os dados necessários.
• Criar um serviço que possa receber dados de todas as partições de outro serviço.
• Enviar dados por push periodicamente de cada serviço para um repositório externo. Essa abordagem é apropriada apenas se as consultas que você estiver fazendo não fizerem parte da lógica comercial principal, como os dados do armazenamento externo serão desatualizados.
• Como alternativa, armazene dados que devem dar suporte à consulta em todos os registros diretamente em um armazenamento de dados, em vez de em uma coleta confiável. Isso elimina o problema com dados desatualizados, mas não permite que as vantagens das coletas confiáveis sejam aproveitadas.

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

Os atores são projetados para serem unidades independentes de estado e processamento, por isso não é recomendável realizar consultas amplas sobre o estado dos atores em tempo de execução. Se você precisar fazer uma consulta em todo o conjunto de um estado do ator, deve considerar:

• Substituir seus serviços de ator por serviços confiáveis com estado, assim como o número de solicitações de rede para reunir todos os dados do número de atores para o número de partições do seu serviço.
• Projetar seus atores para enviar seu estado por push a um repositório externo periodicamente para facilitar a consulta. Como acima, essa abordagem só é viável se as consultas que você estiver executando não forem necessárias para o comportamento do seu runtime.

Quantos dados posso armazenar em uma Coleção Confiável?

Serviços confiáveis normalmente são particionados, de forma que o valor que você pode armazenar é limitado apenas pelo número de máquinas que tem no cluster e a 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 com uma média de 1 KB de tamanho. Agora, suponha que você tem um cluster de 10 máquinas com 16 gb de memória por máquina. Para simplificar e sendo cauteloso, suponha que o sistema operacional e os serviços do sistema, o runtime do Service Fabric e seus serviços consomem 6 GB disso, deixando 10 GB disponíveis por computador, 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 cerca de 35 milhões de objetos na sua coleção ao operar com capacidade total. No entanto, recomendamos ser resiliente à perda simultânea de um domínio de falha e um domínio de atualização, que representa aproximadamente 1/3 da capacidade e reduziria o número a aproximadamente 23 milhões.

Esse cálculo também pressupõe 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 Service Fabric executa balanceamento de carga com base na contagem de réplicas. No exemplo anterior, isso colocaria 10 réplicas primárias e 20 réplicas secundárias em cada nó no cluster. Isso funciona bem para cargas distribuídas uniformemente entre as partições. Se a carga não estiver equilibrada, você deve reportar a carga para que o Resource Manager possa agrupar réplicas menores juntas e permitir que réplicas maiores consumam mais memória em um nó individual.

• O serviço confiável em questão é o único estado de armazenamento no cluster. Como é possível implantar vários serviços em um cluster, é necessário estar atento aos recursos que cada um precisa para executar e gerenciar seu estado.

• Que o cluster em si não esteja crescendo ou diminuindo. Se você adicionar mais máquinas, o Service Fabric redistribuirá suas réplicas para aproveitar a capacidade adicional até que o número de computadores ultrapasse o número de partições em seu serviço, já que uma réplica individual não pode abranger máquinas. Em contrapartida, se você reduz o tamanho do cluster removendo computadores, suas réplicas são empacotadas mais próximas e têm 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 em disco total e a memória disponível entre os nós no cluster. No entanto, os atores individuais são mais eficazes quando são usados para encapsular uma pequena quantidade de estado e a lógica comercial associada. Como regra geral, um ator individual deve ter um estado que seja medido em quilobytes.

Onde o provedor de recursos do Azure Service Fabric armazena os dados do cliente?

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

Outras perguntas

Como o Service Fabric se relaciona com os contêineres?

Os contêineres oferecem uma maneira simples de empacotar serviços e suas dependências, de modo que executam consistentemente em todos os ambientes e podem operar de maneira 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ês pretendem abrir o código do Service Fabric?

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

Nós anunciamos recentemente que estamos planejando tornar o código-fonte aberto do runtime do Service Fabric. No momento, estamos com o repositório do Service Fabric no GitHub com compilação do Linux e ferramentas de teste, o que significa que você pode clonar o repositório, compilar o Service Fabric para Linux, executar testes básicos, indicar problemas e enviar solicitações de pull. Estamos trabalhando duro para migrar o ambiente de build do Windows junto com um ambiente completo de CI.

Siga o Blog do Service Fabric para obter mais detalhes à medida que eles forem anunciados.

Próximas etapas

Saiba mais sobre os Conceitos e melhores práticas de runtime do Service Fabric