Definições de configuração para um cluster autónomo do Windows

Este artigo descreve as definições de configuração de um cluster autônomo do Azure Service Fabric que pode ser definido no arquivo ClusterConfig.json . Você usará esse arquivo para especificar informações sobre os nós do cluster, configurações de segurança, bem como a topologia de rede em termos de domínios de falha e atualização. Depois de alterar ou adicionar definições de configuração, você pode criar um cluster autônomo ou atualizar a configuração de um cluster autônomo.

Quando você baixa o pacote autônomo do Service Fabric, ClusterConfig.json exemplos também são incluídos. Os exemplos que têm "DevCluster" em seus nomes criam um cluster com todos os três nós na mesma máquina, usando nós lógicos. Desses nós, pelo menos um deve ser marcado como um nó primário. Esse tipo de cluster é útil para ambientes de desenvolvimento ou teste. Não há suporte para ele como um cluster de produção. Os exemplos que têm "MultiMachine" em seus nomes ajudam a criar clusters de nível de produção, com cada nó em uma máquina separada. O número de nós primários para esses clusters é baseado no nível de confiabilidade do cluster. Na versão 5.7, API Versão 05-2017, removemos a propriedade de nível de confiabilidade. Em vez disso, nosso código calcula o nível de confiabilidade mais otimizado para seu cluster. Não tente definir um valor para esta propriedade nas versões 5.7 em diante.

• ClusterConfig.Unsecure.DevCluster.json e ClusterConfig.Unsecure.MultiMachine.json mostram como criar um cluster de teste ou produção não seguro, respectivamente.

• ClusterConfig.Windows.DevCluster.json e ClusterConfig.Windows.MultiMachine.json mostram como criar clusters de teste ou produção que são protegidos usando a segurança do Windows.

• ClusterConfig.X509.DevCluster.json e ClusterConfig.X509.MultiMachine.json mostram como criar clusters de teste ou produção que são protegidos usando a segurança baseada em certificado X509.

Agora vamos examinar as várias seções de um arquivo ClusterConfig.json.

Configurações gerais de cluster

As configurações gerais de cluster abrangem as configurações amplas específicas do cluster, conforme mostrado no seguinte trecho JSON:

    "name": "SampleCluster",
    "clusterConfigurationVersion": "1.0.0",
    "apiVersion": "01-2017",

Você pode dar qualquer nome amigável ao cluster do Service Fabric atribuindo-o à variável name. O clusterConfigurationVersion é o número da versão do cluster. Aumente sempre que atualizar o cluster do Service Fabric. Deixe apiVersion definido como o valor padrão.

Nós no cluster

Você pode configurar os nós em seu cluster do Service Fabric usando a seção de nós, como mostra o trecho a seguir:

"nodes": [{
    "nodeName": "vm0",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc1/r0",
    "upgradeDomain": "UD0"
}, {
    "nodeName": "vm1",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType1",
    "faultDomain": "fd:/dc1/r1",
    "upgradeDomain": "UD1"
}, {
    "nodeName": "vm2",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType2",
    "faultDomain": "fd:/dc1/r2",
    "upgradeDomain": "UD2"
}],

Um cluster do Service Fabric deve conter pelo menos três nós. Você pode adicionar mais nós a esta seção de acordo com sua configuração. A tabela a seguir explica as definições de configuração para cada nó:

Propriedades do cluster

A seção de propriedades no ClusterConfig.json é usada para configurar o cluster conforme mostrado:

Fiabilidade

O conceito de reliabilityLevel define o número de réplicas ou instâncias dos serviços do sistema Service Fabric que podem ser executadas nos nós primários do cluster. Determina a fiabilidade destes serviços e, consequentemente, do cluster. O valor é calculado pelo sistema no momento da criação e atualização do cluster.

Diagnóstico

Na seção diagnosticsStore, você pode configurar parâmetros para habilitar diagnósticos e solucionar problemas de falhas de nó ou cluster, conforme mostrado no seguinte trecho:

"diagnosticsStore": {
    "metadata":  "Please replace the diagnostics store with an actual file share accessible from all cluster machines.",
    "dataDeletionAgeInDays": "7",
    "storeType": "FileShare",
    "IsEncrypted": "false",
    "connectionstring": "c:\\ProgramData\\SF\\DiagnosticsStore"
}

Os metadados são uma descrição do diagnóstico do cluster e podem ser definidos de acordo com a configuração. Essas variáveis ajudam na coleta de logs de rastreamento ETW e despejos de falha, bem como contadores de desempenho. Para obter mais informações sobre logs de rastreamento ETW, consulte Tracelog e rastreamento ETW. Todos os logs, incluindo despejos de memória e contadores de desempenho, podem ser direcionados para a pasta connectionString em sua máquina. Você também pode usar o AzureStorage para armazenar diagnósticos. Veja o seguinte trecho de exemplo:

"diagnosticsStore": {
    "metadata":  "Please replace the diagnostics store with an actual file share accessible from all cluster machines.",
    "dataDeletionAgeInDays": "7",
    "storeType": "AzureStorage",
    "IsEncrypted": "false",
    "connectionstring": "xstore:DefaultEndpointsProtocol=https;AccountName=[AzureAccountName];AccountKey=[AzureAccountKey]"
}

Segurança

A seção de segurança é necessária para um cluster autônomo seguro do Service Fabric. O trecho a seguir mostra uma parte desta seção:

"security": {
    "metadata": "This cluster is secured using X509 certificates.",
    "ClusterCredentialType": "X509",
    "ServerCredentialType": "X509",
    . . .
}

Os metadados são uma descrição do seu cluster seguro e podem ser definidos de acordo com a sua configuração. O ClusterCredentialType e ServerCredentialType determinam o tipo de segurança que o cluster e os nós implementam. Eles podem ser definidos como X509 para uma segurança baseada em certificado ou Windows para segurança baseada no Ative Directory. O resto da seção de segurança é baseado no tipo de segurança. Para obter informações sobre como preencher o restante da seção de segurança, consulte Segurança baseada em certificados em um cluster autônomo ou Segurança do Windows em um cluster autônomo.

Tipos de nós

A seção nodeTypes descreve o tipo de nós que seu cluster tem. Pelo menos um tipo de nó deve ser especificado para um cluster, conforme mostrado no seguinte trecho:

"nodeTypes": [{
    "name": "NodeType0",
    "clientConnectionEndpointPort": "19000",
    "clusterConnectionEndpointPort": "19001",
    "leaseDriverEndpointPort": "19002",
    "serviceConnectionEndpointPort": "19003",
    "httpGatewayEndpointPort": "19080",
    "reverseProxyEndpointPort": "19081",
    "applicationPorts": {
        "startPort": "20575",
        "endPort": "20605"
    },
    "ephemeralPorts": {
        "startPort": "20606",
        "endPort": "20861"
    },
    "isPrimary": true
}]

O nome é o nome amigável para esse tipo de nó específico. Para criar um nó desse tipo de nó, atribua seu nome amigável à variável nodeTypeRef desse nó, conforme mencionado anteriormente. Para cada tipo de nó, defina os pontos de extremidade de conexão usados. Você pode escolher qualquer número de porta para esses pontos de extremidade de conexão, desde que eles não entrem em conflito com nenhum outro ponto de extremidade nesse cluster. Em um cluster de vários nós, há um ou mais nós primários (ou seja, isPrimary está definido como true), dependendo do reliabilityLevel. Para saber mais sobre os tipos de nós primários e não primários, consulte Considerações sobre planejamento de capacidade de cluster do Service Fabric para obter informações sobre nodeTypes e reliabilityLevel.

Pontos de extremidade usados para configurar os tipos de nó

• clientConnectionEndpointPort é a porta usada pelo cliente para se conectar ao cluster quando as APIs do cliente são usadas.
• clusterConnectionEndpointPort é a porta onde os nós se comunicam entre si.
• leaseDriverEndpointPort é a porta usada pelo driver de concessão de cluster para descobrir se os nós ainda estão ativos.
• serviceConnectionEndpointPort é a porta usada pelos aplicativos e serviços implantados em um nó para se comunicar com o cliente do Service Fabric nesse nó específico.
• httpGatewayEndpointPort é a porta usada pelo Service Fabric Explorer para se conectar ao cluster.
• ephemeralPorts substituem as portas dinâmicas usadas pelo sistema operacional. O Service Fabric usa uma parte dessas portas como portas de aplicativo, e as restantes estão disponíveis para o SO. Ele também mapeia esse intervalo para o intervalo existente presente no sistema operacional, portanto, para todos os fins, você pode usar os intervalos fornecidos nos arquivos JSON de exemplo. Certifique-se de que a diferença entre as portas inicial e final é de pelo menos 255. Você pode entrar em conflitos se essa diferença for muito baixa, porque esse intervalo é compartilhado com o sistema operacional. Para ver o intervalo de portas dinâmicas configurado, execute netsh int ipv4 show dynamicport tcp.
• applicationPorts são as portas usadas pelos aplicativos do Service Fabric. O intervalo de portas do aplicativo deve ser grande o suficiente para cobrir o requisito de ponto de extremidade de seus aplicativos. Esse intervalo deve ser exclusivo do intervalo de portas dinâmicas na máquina, ou seja, o intervalo de portas efêmeras conforme definido na configuração. O Service Fabric usa essas portas sempre que novas portas são necessárias e se encarrega de abrir o firewall para essas portas.
• reverseProxyEndpointPort é um ponto de extremidade de proxy reverso opcional. Para obter mais informações, consulte Proxy reverso do Service Fabric.

Configurações de log

Na seção fabricSettings, você pode definir os diretórios raiz para os dados e logs do Service Fabric. Você pode personalizar esses diretórios somente durante a criação inicial do cluster. Consulte o seguinte trecho de exemplo desta seção:

"fabricSettings": [{
    "name": "Setup",
    "parameters": [{
        "name": "FabricDataRoot",
        "value": "C:\\ProgramData\\SF"
    }, {
        "name": "FabricLogRoot",
        "value": "C:\\ProgramData\\SF\\Log"
}]

Recomendamos que você use uma unidade que não seja do sistema operacional como FabricDataRoot e FabricLogRoot. Ele fornece mais confiabilidade para evitar situações em que o sistema operacional para de responder. Se você personalizar apenas a raiz de dados, a raiz de log será colocada um nível abaixo da raiz de dados.

Configurações de Serviços Confiáveis com Estado

Na seção KtlLogger, você pode definir as definições de configuração global para Serviços Confiáveis. Para obter mais informações sobre essas configurações, consulte Configurar serviços confiáveis com monitoração de estado. O exemplo a seguir mostra como alterar o log de transações compartilhadas que é criado para fazer backup de quaisquer coleções confiáveis para serviços com monitoração de estado:

"fabricSettings": [{
    "name": "KtlLogger",
    "parameters": [{
        "name": "SharedLogSizeInMB",
        "value": "4096"
    }]
}]

Recursos do complemento

Para configurar recursos de complemento, configure o apiVersion como 04-2017 ou superior e configure o addonFeatures como mostrado aqui:

"apiVersion": "04-2017",
"properties": {
    "addOnFeatures": [
        "DnsService",
        "RepairManager"
    ]
}

Todos os recursos complementares disponíveis podem ser vistos na Referência da API REST do Service Fabric.

Suporte de contentor

Para habilitar o suporte a contêineres para contêineres do Windows Server e contêineres do Hyper-V para clusters autônomos, o recurso de complemento DnsService deve ser habilitado.

Próximos passos

Depois de ter um arquivo de ClusterConfig.json completo configurado de acordo com sua configuração de cluster autônomo, você pode implantar seu cluster. Siga as etapas em Criar um cluster autônomo do Service Fabric.

Se você tiver um cluster autônomo implantado, também poderá atualizar a configuração de um cluster autônomo.

Saiba como visualizar seu cluster com o Service Fabric Explorer.