Planejar e preparar a implantação de cluster autônomo do Service Fabric

Execute as etapas a seguir antes de criar o cluster.

Planeje sua infraestrutura de cluster

Você está prestes a criar um cluster do Service Fabric em máquinas que "possui", para que possa decidir quais tipos de falhas deseja que o cluster sobreviva. Por exemplo, você precisa de linhas de energia separadas ou conexões de Internet fornecidas a essas máquinas? Além disso, considere a segurança física dessas máquinas. Onde estão localizadas as máquinas e quem precisa ter acesso a elas? Depois de tomar essas decisões, você pode mapear logicamente as máquinas para vários domínios de falha (consulte a próxima etapa). O planejamento de infraestrutura para clusters de produção está mais envolvido do que para clusters de teste.

Determinar o número de domínios de falha e atualizar domínios

Um domínio de falha (FD) é uma unidade física de falha e está diretamente relacionado à infraestrutura física nos data centers. Um domínio de falha consiste em componentes de hardware (computadores, switches, redes e muito mais) que compartilham um único ponto de falha. Embora não haja mapeamento 1:1 entre domínios de falha e racks, vagamente falando, cada rack pode ser considerado um domínio de falha.

Ao especificar FDs em ClusterConfig.json, você pode escolher o nome para cada FD. O Service Fabric oferece suporte a FDs hierárquicos, para que você possa refletir sua topologia de infraestrutura neles. Por exemplo, os seguintes FDs são válidos:

• "faultDomain": "fd:/Room1/Rack1/Machine1"
• "faultDomain": "fd:/FD1"
• "faultDomain": "fd:/Room1/Rack1/PDU1/M1"

Um domínio de atualização (UD) é uma unidade lógica de nós. Durante as atualizações orquestradas do Service Fabric (uma atualização de aplicativo ou uma atualização de cluster), todos os nós em uma UD são removidos para executar a atualização, enquanto os nós em outras UDs permanecem disponíveis para atender solicitações. As atualizações de firmware que você executa em suas máquinas não honram UDs, então você deve fazê-las uma máquina de cada vez.

A maneira mais simples de pensar sobre esses conceitos é considerar FDs como a unidade de falha não planejada e UDs como a unidade de manutenção planejada.

Ao especificar UDs em ClusterConfig.json, você pode escolher o nome para cada UD. Por exemplo, os seguintes nomes são válidos:

• "upgradeDomain": "UD0"
• "upgradeDomain": "UD1A"
• "upgradeDomain": "DomainRed"
• "upgradeDomain": "Azul"

Para obter informações mais detalhadas sobre FDs e UDs, consulte Descrevendo um cluster do Service Fabric.

Um cluster em produção deve abranger pelo menos três FDs para ser suportado em um ambiente de produção, se você tiver controle total sobre a manutenção e o gerenciamento dos nós, ou seja, você for responsável pela atualização e substituição de máquinas. Para clusters executados em ambientes (ou seja, instâncias de VM da Amazon Web Services) em que você não tem controle total sobre as máquinas, você deve ter um mínimo de cinco FDs em seu cluster. Cada FD pode ter um ou mais nós. Isso é para evitar problemas causados por upgrades e atualizações de máquinas, que, dependendo de seu tempo, podem interferir na execução de aplicativos e serviços em clusters.

Determinar o tamanho inicial do cluster

Geralmente, o número de nós em seu cluster é determinado com base em suas necessidades de negócios, ou seja, quantos serviços e contêineres serão executados no cluster e quantos recursos você precisa para sustentar suas cargas de trabalho. Para clusters de produção, recomendamos ter pelo menos cinco nós em seu cluster, abrangendo 5 FDs. No entanto, como descrito acima, se você tiver controle total sobre seus nós e puder abranger três FDs, então três nós também devem fazer o trabalho.

Os clusters de teste que executam cargas de trabalho com monitoração de estado devem ter três nós, enquanto os clusters de teste que executam apenas cargas de trabalho sem estado precisam apenas de um nó. Também deve ser notado que, para fins de desenvolvimento, você pode ter mais de um nó em uma determinada máquina. Em um ambiente de produção, no entanto, o Service Fabric oferece suporte a apenas um nó por máquina física ou virtual.

Preparar as máquinas que servirão como nós

Aqui estão as especificações recomendadas para máquinas em um cluster do Service Fabric:

• Um mínimo de 16 GB de RAM
• Um mínimo de 40 GB de espaço disponível em disco
• Uma CPU de 4 núcleos ou superior
• Conectividade com uma rede ou redes seguras para todas as máquinas
• SO Windows Server instalado (versões válidas: 2012 R2, 2016, 1709 ou 1803). O Service Fabric versão 6.4.654.9590 e posterior também suporta o Server 2019 e 1809.
• .NET Framework 4.5.1 ou superior, instalação completa
• Windows PowerShell 3.0
• O serviço RemoteRegistry deve estar em execução em todas as máquinas
• A unidade de instalação do Service Fabric deve ser um sistema de arquivos NTFS
• Os Logs de Desempenho dos serviços do Windows e os Alertas e o Log de Eventos do Windows devem ser habilitados.
• O Controle de Conta de Usuário Remoto deve ser desativado

Baixe o pacote autônomo do Service Fabric para Windows Server

Baixe Link - Service Fabric Standalone Package - Windows Server e descompacte o pacote, seja para uma máquina de implantação que não faça parte do cluster ou para uma das máquinas que farão parte do cluster.

Modificar a configuração do cluster

Para criar um cluster autônomo, você precisa criar um arquivo de ClusterConfig.json de configuração de cluster autônomo, que descreve a especificação do cluster. Você pode basear o arquivo de configuração nos modelos encontrados no link abaixo.
Configurações de cluster autônomas

Para obter detalhes sobre as seções desse arquivo, consulte Definições de configuração para cluster autônomo do Windows.

Abra um dos arquivos ClusterConfig.json do pacote que você baixou e modifique as seguintes configurações:

Depois que a configuração de cluster tiver todas as configurações configuradas para o ambiente, ela poderá ser testada em relação ao ambiente de cluster (etapa 7).

Configuração do ambiente

Quando um administrador de cluster configura um cluster autônomo do Service Fabric, o ambiente precisa ser configurado com os seguintes critérios:

1. O usuário que cria o cluster deve ter privilégios de segurança em nível de administrador para todas as máquinas listadas como nós no arquivo de configuração do cluster.

2. A máquina a partir da qual o cluster é criado, bem como cada máquina de nó de cluster deve:

   • Ter o SDK do Service Fabric desinstalado
   • Ter o tempo de execução do Service Fabric desinstalado
   • Ter o serviço de Firewall do Windows (mpssvc) habilitado
   • Ter o Serviço de Registo Remoto (registo remoto) ativado
   • Ter o compartilhamento de arquivos (SMB) habilitado
   • Ter as portas necessárias abertas, com base nas portas de configuração do cluster
   • Ter as portas necessárias abertas para o serviço SMB e Registro Remoto do Windows: 135, 137, 138, 139 e 445
   • Ter conectividade de rede entre si

3. Nenhuma das máquinas de nó de cluster deve ser um Controlador de Domínio.

4. Se o cluster a ser implantado for um cluster seguro, valide se os pré-requisitos de segurança necessários estão em vigor e estão configurados corretamente em relação à configuração.

5. Se as máquinas de cluster não estiverem acessíveis pela Internet, defina o seguinte na configuração do cluster:

   • Desativar telemetria: em propriedades definidas "enableTelemetry": false
   • Desative o download automático da versão de malha & notificações de que a versão atual do cluster está chegando ao fim do suporte: Em propriedades definidas "fabricClusterAutoupgradeEnabled": false
   • Como alternativa, se o acesso à Internet na rede estiver limitado aos domínios permitidos, os domínios abaixo são necessários para a atualização automática: go.microsoft.com download.microsoft.com

6. Defina exclusões apropriadas do antivírus do Service Fabric:

Validar ambiente usando o script TestConfiguration

O script TestConfiguration.ps1 pode ser encontrado no pacote autônomo. Ele é usado como um Analisador de Práticas Recomendadas para validar alguns dos critérios acima e deve ser usado como uma verificação de sanidade para validar se um cluster pode ser implantado em um determinado ambiente. Se houver alguma falha, consulte a lista em Configuração do ambiente para solucionar problemas.

Esse script pode ser executado em qualquer máquina que tenha acesso de administrador a todas as máquinas listadas como nós no arquivo de configuração do cluster. A máquina na qual esse script é executado não precisa fazer parte do cluster.

PS C:\temp\Microsoft.Azure.ServiceFabric.WindowsServer> .\TestConfiguration.ps1 -ClusterConfigFilePath .\ClusterConfig.Unsecure.DevCluster.json
Trace folder already exists. Traces will be written to existing trace folder: C:\temp\Microsoft.Azure.ServiceFabric.WindowsServer\DeploymentTraces
Running Best Practices Analyzer...
Best Practices Analyzer completed successfully.


LocalAdminPrivilege        : True
IsJsonValid                : True
IsCabValid                 : True
RequiredPortsOpen          : True
RemoteRegistryAvailable    : True
FirewallAvailable          : True
RpcCheckPassed             : True
NoConflictingInstallations : True
FabricInstallable          : True
Passed                     : True

Atualmente, este módulo de teste de configuração não valida a configuração de segurança, portanto, isso deve ser feito de forma independente.

Próximos passos

• Criar um cluster autônomo em execução no Windows Server