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

Artigo
10/15/2024

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

Importante

O administrador de cluster que implanta e configura o cluster deve ter privilégios de administrador em cada uma das máquinas. Não pode instalar o Service Fabric num controlador de domínio.

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:

Definição de configuração	Descrição
Tipos de nó	Os tipos de nó permitem separar os nós do cluster em vários grupos. Um cluster deve ter pelo menos um NodeType. Todos os nós de um grupo têm as seguintes características comuns: Nome - Este é o nome do tipo de nó. Portas de ponto de extremidade - São pontos de extremidade nomeados (portas) associados a esse tipo de nó. Você pode usar qualquer número de porta que desejar, desde que eles não entrem em conflito com nada mais neste manifesto e não estejam já em uso por nenhum outro aplicativo em execução na máquina/VM. Propriedades de posicionamento - Descrevem propriedades para esse tipo de nó que você usa como restrições de posicionamento para os serviços do sistema ou seus serviços. Essas propriedades são pares chave/valor definidos pelo usuário que fornecem metadados extras para um determinado nó. Exemplos de propriedades de nó seriam se o nó tem um disco rígido ou placa gráfica, o número de eixos em seu disco rígido, núcleos e outras propriedades físicas. Capacidades - As capacidades do nó definem o nome e a quantidade de um determinado recurso que um determinado nó tem disponível para consumo. Por exemplo, um nó pode definir que tem capacidade para uma métrica chamada "MemoryInMb" e que tem 2048 MB disponíveis por padrão. Essas capacidades são usadas em tempo de execução para garantir que os serviços que exigem quantidades específicas de recursos sejam colocados nos nós que têm esses recursos disponíveis nas quantidades necessárias. IsPrimary - Se você tiver mais de um NodeType definido, certifique-se de que apenas um esteja definido como primário com o valor true, que é onde os serviços do sistema são executados. Todos os outros tipos de nó devem ser definidos com o valor false
Nós	Estes são os detalhes de cada um dos nós que fazem parte do cluster (tipo de nó, nome do nó, endereço IP, domínio de falha e domínio de atualização do nó). As máquinas nas quais você deseja que o cluster seja criado precisam ser listadas aqui com seus endereços IP. Se você usar o mesmo endereço IP para todos os nós, um cluster de caixa única será criado, que poderá ser usado para fins de teste. Não use clusters de caixa única para implantar cargas de trabalho de produção.

Definição de configuração

Descrição

Tipos de nó

Os tipos de nó permitem separar os nós do cluster em vários grupos. Um cluster deve ter pelo menos um NodeType. Todos os nós de um grupo têm as seguintes características comuns:
Nome - Este é o nome do tipo de nó.
Portas de ponto de extremidade - São pontos de extremidade nomeados (portas) associados a esse tipo de nó. Você pode usar qualquer número de porta que desejar, desde que eles não entrem em conflito com nada mais neste manifesto e não estejam já em uso por nenhum outro aplicativo em execução na máquina/VM.
Propriedades de posicionamento - Descrevem propriedades para esse tipo de nó que você usa como restrições de posicionamento para os serviços do sistema ou seus serviços. Essas propriedades são pares chave/valor definidos pelo usuário que fornecem metadados extras para um determinado nó. Exemplos de propriedades de nó seriam se o nó tem um disco rígido ou placa gráfica, o número de eixos em seu disco rígido, núcleos e outras propriedades físicas.
Capacidades - As capacidades do nó definem o nome e a quantidade de um determinado recurso que um determinado nó tem disponível para consumo. Por exemplo, um nó pode definir que tem capacidade para uma métrica chamada "MemoryInMb" e que tem 2048 MB disponíveis por padrão. Essas capacidades são usadas em tempo de execução para garantir que os serviços que exigem quantidades específicas de recursos sejam colocados nos nós que têm esses recursos disponíveis nas quantidades necessárias.
IsPrimary - Se você tiver mais de um NodeType definido, certifique-se de que apenas um esteja definido como primário com o valor true, que é onde os serviços do sistema são executados. Todos os outros tipos de nó devem ser definidos com o valor false

Nós

Estes são os detalhes de cada um dos nós que fazem parte do cluster (tipo de nó, nome do nó, endereço IP, domínio de falha e domínio de atualização do nó). As máquinas nas quais você deseja que o cluster seja criado precisam ser listadas aqui com seus endereços IP.
Se você usar o mesmo endereço IP para todos os nós, um cluster de caixa única será criado, que poderá ser usado para fins de teste. Não use clusters de caixa única para implantar cargas de trabalho de produção.

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:

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.
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
Nenhuma das máquinas de nó de cluster deve ser um Controlador de Domínio.
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.
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
Defina exclusões apropriadas do antivírus do Service Fabric:

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

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.

Nota

Estamos continuamente fazendo melhorias para tornar este módulo mais robusto, portanto, se houver um caso defeituoso ou ausente que você acredita que não é atualmente capturado pelo TestConfiguration, informe-nos através de nossos canais de suporte.

Próximos passos

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

Partilhar via