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

  • Artigo

Este artigo descreve as definições de configuração de um cluster autónomo do Azure Service Fabric que pode ser definido no ficheiro ClusterConfig.json . Irá utilizar este ficheiro para especificar informações sobre os nós do cluster, as 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, pode criar um cluster autónomo ou atualizar a configuração de um cluster autónomo.

Quando transfere o pacote autónomo do Service Fabric, também são incluídos exemplos clusterConfig.json. Os exemplos que têm "DevCluster" nos respetivos nomes criam um cluster com os três nós no mesmo computador, utilizando nós lógicos. Destes nós, pelo menos um tem de ser marcado como um nó primário. Este tipo de cluster é útil para ambientes de desenvolvimento ou teste. Não é suportado como um cluster de produção. Os exemplos que têm "MultiMachine" nos respetivos nomes ajudam a criar clusters de nível de produção, com cada nó num computador separado. O número de nós principais para estes clusters baseia-se no nível de fiabilidade do cluster. Na versão 5.7, Versão 05-2017 da API, removemos a propriedade ao nível da fiabilidade. Em vez disso, o nosso código calcula o nível de fiabilidade mais otimizado para o cluster. Não tente definir um valor para esta propriedade nas versões 5.7 posteriores.

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

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

  • ClusterConfig.X509.DevCluster.json e ClusterConfig.X509.MultiMachine.json mostram como criar clusters de teste ou de produção protegidos através da segurança baseada em certificados X509.

Agora, vamos examinar as várias secções de um ficheiro ClusterConfig.json.

Configurações gerais do cluster

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

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

Pode atribuir qualquer nome amigável ao cluster do Service Fabric ao atribuí-lo à variável de nome. ClusterConfigurationVersion é o número da versão do cluster. Aumente-o sempre que atualizar o cluster do Service Fabric. Deixe apiVersion definido como o valor predefinido.

Nós no cluster

Pode configurar os nós no cluster do Service Fabric com a secção nós, como mostra o seguinte fragmento:

"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 tem de conter, pelo menos, três nós. Pode adicionar mais nós a esta secção de acordo com a configuração. A tabela seguinte explica as definições de configuração de cada nó:

Configuração do nó Descrição
nodeName Pode dar qualquer nome amigável ao nó.
iPAddress Descubra o endereço IP do nó ao abrir uma janela de comando e escrever ipconfig. Anote o endereço IPV4 e atribua-o à variável iPAddress.
nodeTypeRef Cada nó pode ser atribuído a um tipo de nó diferente. Os tipos de nó são definidos na secção seguinte.
faultDomain Os domínios de falha permitem que os administradores do cluster definam os nós físicos que podem falhar ao mesmo tempo devido a dependências físicas partilhadas.
upgradeDomain Os domínios de atualização descrevem conjuntos de nós que são encerrados para atualizações do Service Fabric ao mesmo tempo. Pode escolher os nós a atribuir a que domínios de atualização, uma vez que não estão limitados por quaisquer requisitos físicos.

Propriedades do cluster

A secção de propriedades no ClusterConfig.json é utilizada para configurar o cluster, conforme mostrado:

Fiabilidade

O conceito de fiabilidadeNvel define o número de réplicas ou instâncias dos serviços de sistema do Service Fabric que podem ser executados nos nós primários do cluster. Determina a fiabilidade destes serviços e, por conseguinte, o cluster. O valor é calculado pelo sistema na hora de criação e atualização do cluster.

Diagnóstico

Na secção diagnosticsStore, pode configurar parâmetros para ativar diagnósticos e resolver problemas de falhas de nó ou cluster, conforme mostrado no fragmento seguinte:

"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 dos diagnósticos do cluster e podem ser definidos de acordo com a configuração. Estas variáveis ajudam a recolher registos de rastreio etw e informações de falha de sistema, bem como contadores de desempenho. Para obter mais informações sobre os registos de rastreio etw, veja Rastreio e rastreio ETW. Todos os registos, incluindo informações de falha de sistema e contadores de desempenho, podem ser direcionados para a pasta connectionString no seu computador. Também pode utilizar o AzureStorage para armazenar diagnósticos. Veja o fragmento de exemplo seguinte:

"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 secção de segurança é necessária para um cluster do Service Fabric autónomo seguro. O fragmento seguinte mostra uma parte desta secção:

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

Os metadados são uma descrição do cluster seguro e podem ser definidos de acordo com a configuração. O ClusterCredentialType e o ServerCredentialType determinam o tipo de segurança que o cluster e os nós implementam. Podem ser definidos como X509 para uma segurança baseada em certificados ou segurança baseada no Windows para Active Directory. O resto da secção de segurança baseia-se no tipo de segurança. Para obter informações sobre como preencher o resto da secção de segurança, veja Segurança baseada em certificados num cluster autónomo ou segurança do Windows num cluster autónomo.

Tipos de nós

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

"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 este tipo de nó específico. Para criar um nó deste tipo de nó, atribua o nome amigável à variável nodeTypeRef para esse nó, conforme mencionado anteriormente. Para cada tipo de nó, defina os pontos finais de ligação que são utilizados. Pode escolher qualquer número de porta para estes pontos finais de ligação, desde que não entrem em conflito com outros pontos finais neste cluster. Num cluster multinódeo, existe um ou mais nós primários (ou seja, éPrimário definido como verdadeiro), consoante a fiabilidadeLevel. Para saber mais sobre os tipos de nó primários e não primários, veja Considerações de planeamento da capacidade do cluster do Service Fabric para obter informações sobre nósTypes e fiabilidadeLevel.

Pontos finais utilizados para configurar os tipos de nós

  • clientConnectionEndpointPort é a porta utilizada pelo cliente para ligar ao cluster quando são utilizadas APIs de cliente.
  • clusterConnectionEndpointPort é a porta onde os nós comunicam entre si.
  • leaseDriverEndpointPort é a porta utilizada pelo controlador de concessão do cluster para saber se os nós ainda estão ativos.
  • serviceConnectionEndpointPort é a porta utilizada pelas aplicações e serviços implementados num nó para comunicar com o cliente do Service Fabric nesse nó específico.
  • httpGatewayEndpointPort é a porta utilizada pelo Service Fabric Explorer para ligar ao cluster.
  • Os ephemeralPorts substituem as portas dinâmicas utilizadas pelo SO. O Service Fabric utiliza uma parte destas portas como portas de aplicação e as restantes estão disponíveis para o SO. Também mapeia este intervalo para o intervalo existente presente no SO, pelo que, para todos os efeitos, pode utilizar os intervalos indicados nos ficheiros JSON de exemplo. Certifique-se de que a diferença entre as portas de início e de fim é, pelo menos, 255. Poderá deparar-se com conflitos se esta diferença for demasiado baixa, porque este intervalo é partilhado com o SO. Para ver o intervalo de portas dinâmico configurado, execute netsh int ipv4 show dynamicport tcp.
  • applicationPorts são as portas que são utilizadas pelas aplicações do Service Fabric. O intervalo de portas da aplicação deve ser suficientemente grande para abranger os requisitos de ponto final das suas aplicações. Este intervalo deve ser exclusivo do intervalo de portas dinâmicas no computador, ou seja, do intervalo efémerosPorts, conforme definido na configuração. O Service Fabric utiliza estas portas sempre que são necessárias novas portas e trata de abrir a firewall para estas portas.
  • reverseProxyEndpointPort é um ponto final de proxy inverso opcional. Para obter mais informações, veja proxy inverso do Service Fabric.

Definições de registo

Na secção recursos de infraestruturaDefinições, pode definir os diretórios de raiz para os dados e registos do Service Fabric. Só pode personalizar estes diretórios durante a criação do cluster inicial. Veja o fragmento de exemplo seguinte desta secção:

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

Recomendamos que utilize uma unidade não SO como FabricDataRoot e FabricLogRoot. Fornece mais fiabilidade para evitar situações em que o SO deixa de responder. Se personalizar apenas a raiz de dados, a raiz de registo é colocada um nível abaixo da raiz de dados.

Definições do Reliable Services com monitorização de estado

Na secção KtlLogger, pode definir as definições de configuração global do Reliable Services. Para obter mais informações sobre estas definições, veja Configurar o Reliable Services com Monitorização de Estado. O exemplo seguinte mostra como alterar o registo de transações partilhadas que é criado para suportar quaisquer coleções fiáveis para serviços com monitorização de estado:

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

Funcionalidades de suplemento

Para configurar funcionalidades de suplementos, configure a apiVersion como 04-2017 ou superior e configure o addonFeatures, conforme mostrado aqui:

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

Todas as funcionalidades de suplemento disponíveis podem ser vistas na Referência da API REST do Service Fabric.

Suporte de contentor

Para ativar o suporte de contentores para contentores do Windows Server e contentores hyper-V para clusters autónomos, a funcionalidade de suplemento DnsService tem de estar ativada.

Passos seguintes

Depois de ter um ficheiro ClusterConfig.json completo configurado de acordo com a configuração do cluster autónomo, pode implementar o cluster. Siga os passos em Criar um cluster autónomo do Service Fabric.

Se tiver um cluster autónomo implementado, também pode atualizar a configuração de um cluster autónomo.

Saiba como visualizar o cluster com Service Fabric Explorer.