Partilhar via

Dimensionar o tipo de nó primário de um cluster do Service Fabric

Este artigo descreve como dimensionar um tipo de nó primário de cluster do Service Fabric com o mínimo de tempo de inatividade. Não há suporte para atualizações de SKU no local em nós de cluster do Service Fabric, pois essas operações potencialmente envolvem perda de dados e de disponibilidade. O método mais seguro, confiável e recomendado para dimensionar um tipo de nó do Service Fabric é:

  1. Adicione um novo tipo de nó ao cluster do Service Fabric, apoiado pela SKU e configuração atualizadas (ou modificadas) do conjunto de dimensionamento da máquina virtual. Esta etapa também envolve a configuração de um novo balanceador de carga, sub-rede e IP público para o conjunto de escala.

  2. Quando os conjuntos de escalas originais e atualizados estiverem a ser executados lado a lado, desative as instâncias do nó original, uma de cada vez, para que os serviços do sistema (ou réplicas de serviços com estado) migrem para o novo conjunto de escalas.

  3. Verifique se o cluster e os novos nós estão íntegros e, em seguida, remova o conjunto de escalonamento original (e os recursos relacionados) e o estado dos nós que foram excluídos.

A seguir, será explicado o processo para atualizar o tamanho da VM e o sistema operacional das VMs do tipo nó primário de um cluster de amostra com durabilidade Silver, suportado por um conjunto de escalonamento único com cinco nós. Vamos atualizar o tipo de nó principal:

  • Do tamanho da VM Standard_D2_V2 ao D4_V2 padrão, e
  • Do sistema operacional VM Windows Server 2019 Datacenter para o Windows Server 2022 Datacenter.

Advertência

Antes de tentar este procedimento em um cluster de produção, recomendamos que você estude os modelos de exemplo e verifique o processo em relação a um cluster de teste. O cluster também pode estar indisponível por um curto período de tempo.

Não tente um procedimento de dimensionamento do tipo de nó primário se o estado do cluster não for saudável, pois isso só desestabilizará ainda mais o cluster.

Os modelos de implantação passo a passo do Azure que usaremos para concluir este cenário de atualização de exemplo estão disponíveis no GitHub.

Configurar o cluster de teste

Vamos configurar o cluster de teste inicial do Service Fabric. Primeiro, baixe os modelos de exemplo do Azure Resource Manager que usaremos para concluir esse cenário.

Em seguida, entre na sua conta do Azure.

# Sign in to your Azure account
Login-AzAccount -SubscriptionId "<subscription ID>"

Em seguida, abra o ficheiro parameters.json e atualize o valor para clusterName um valor único (dentro do Azure).

Os comandos a seguir irão guiá-lo através da geração de um novo certificado autoassinado e da implantação do cluster de teste. Se você já tiver um certificado que gostaria de usar, pule para Usar um certificado existente para implantar o cluster.

Gerar um certificado autoassinado e implantar o cluster

Primeiro, atribua as variáveis necessárias para a implantação do cluster do Service Fabric. Ajuste os valores para resourceGroupName, certSubjectName, parameterFilePathe templateFilePath para sua conta e ambiente específicos:

# Assign deployment variables
$resourceGroupName = "sftestupgradegroup"
$certOutputFolder = "c:\certificates"
$certPassword = "Password!1" | ConvertTo-SecureString -AsPlainText -Force
$certSubjectName = "sftestupgrade.southcentralus.cloudapp.azure.com"
$parameterFilePath = "C:\parameters.json"
$templateFilePath = "C:\Initial-TestClusterSetup.json"

Observação

Verifique se o local certOutputFolder existe no seu computador antes de executar o comando para implantar um novo cluster do Service Fabric.

Em seguida, implante o cluster de teste do Service Fabric:

# Deploy the initial test cluster
New-AzServiceFabricCluster `
    -ResourceGroupName $resourceGroupName `
    -CertificateOutputFolder $certOutputFolder `
    -CertificatePassword $certPassword `
    -CertificateSubjectName $certSubjectName `
    -TemplateFile $templateFilePath `
    -ParameterFile $parameterFilePath

Quando a implantação estiver concluída, localize o arquivo .pfx ($certPfx) em sua máquina local e importe-o para seu armazenamento de certificados:

cd c:\certificates
$certPfx = ".\sftestupgradegroup20200312121003.pfx"

Import-PfxCertificate `
     -FilePath $certPfx `
     -CertStoreLocation Cert:\CurrentUser\My `
     -Password (ConvertTo-SecureString Password!1 -AsPlainText -Force)

A operação retorna a impressão digital do certificado, que agora você pode usar para se conectar ao novo cluster e verificar seu status de integridade. (Ignore a seção a seguir, que é uma abordagem alternativa para a implantação de cluster.)

Usar um certificado existente para implantar o cluster

Como alternativa, você pode usar um certificado existente do Azure Key Vault para implantar o cluster de teste. Para fazer isso, precisas obter referências ao teu Cofre de Chaves e impressão digital do certificado.

# Key Vault variables
$certUrlValue = "https://sftestupgradegroup.vault.azure.net/secrets/sftestupgradegroup20200309235308/dac0e7b7f9d4414984ccaa72bfb2ea39"
$sourceVaultValue = "/subscriptions/########-####-####-####-############/resourceGroups/sftestupgradegroup/providers/Microsoft.KeyVault/vaults/sftestupgradegroup"
$thumb = "AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00"

Em seguida, atribua um nome de grupo de recursos para o cluster e defina as localizações templateFilePath e parameterFilePath.

Observação

O grupo de recursos designado já deve existir e estar localizado na mesma região do Cofre da Chave.

$resourceGroupName = "sftestupgradegroup"
$templateFilePath = "C:\Initial-TestClusterSetup.json"
$parameterFilePath = "C:\parameters.json"

Finalmente, execute o seguinte comando para implantar o cluster de teste inicial:

# Deploy the initial test cluster
New-AzResourceGroupDeployment `
    -ResourceGroupName $resourceGroupName `
    -TemplateFile $templateFilePath `
    -TemplateParameterFile $parameterFilePath `
    -CertificateThumbprint $thumb `
    -CertificateUrlValue $certUrlValue `
    -SourceVaultValue $sourceVaultValue `
    -Verbose

Conectar-se ao novo cluster e verificar o estado de saúde

Conecte-se ao cluster e verifique se todos os cinco nós estão íntegros (substitua as clusterName variáveis e thumb por seus próprios valores):

# Connect to the cluster
$clusterName = "sftestupgrade.southcentralus.cloudapp.azure.com:19000"
$thumb = "AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00"

Connect-ServiceFabricCluster `
    -ConnectionEndpoint $clusterName `
    -KeepAliveIntervalInSec 10 `
    -X509Credential `
    -ServerCertThumbprint $thumb  `
    -FindType FindByThumbprint `
    -FindValue $thumb `
    -StoreLocation CurrentUser `
    -StoreName My

# Check cluster health
Get-ServiceFabricClusterHealth

Agora, estamos prontos para iniciar o procedimento de atualização.

Implantar um novo tipo de nó primário com conjunto de escala atualizado

Para atualizar (dimensionar verticalmente) um tipo de nó, primeiro precisaremos implantar um novo tipo de nó apoiado por um novo conjunto de escala e recursos de suporte. O novo conjunto de escalas será marcado como primário (isPrimary: true), tal como o conjunto de escalas original. Se você quiser dimensionar um tipo de nó não primário, consulte Dimensionar um tipo de nó não primário de cluster do Service Fabric. Os recursos criados na seção a seguir se tornarão, em última análise, o novo tipo de nó primário em seu cluster, e os recursos de tipo de nó primário original serão excluídos.

Atualizar o modelo de cluster com o conjunto de escala atualizado

Aqui estão as modificações seção por seção do modelo de implantação de cluster original para adicionar um novo tipo de nó primário e recursos de suporte.

As alterações necessárias para esta etapa já foram feitas para você no arquivo de modeloStep1-AddPrimaryNodeType.json , e o seguinte explicará essas alterações em detalhes. Se preferir, você pode ignorar a explicação e continuar a obter suas referências do Cofre da Chave e implantar o modelo atualizado que adiciona um novo tipo de nó primário ao cluster.

Observação

Certifique-se de usar nomes exclusivos do tipo de nó original, conjunto de escala, balanceador de carga, IP público e sub-rede do tipo de nó primário original, pois esses recursos são excluídos em uma etapa posterior do processo.

Criar uma nova sub-rede na rede virtual existente

{
    "name": "[variables('subnet1Name')]",
    "properties": {
        "addressPrefix": "[variables('subnet1Prefix')]"
    }
}

Criar um novo IP público com um domainNameLabel exclusivo

{
    "apiVersion": "[variables('publicIPApiVersion')]",
    "type": "Microsoft.Network/publicIPAddresses",
    "name": "[concat(variables('lbIPName'),'-',variables('vmNodeType1Name'))]",
    "location": "[variables('computeLocation')]",
    "properties": {
        "dnsSettings": {
            "domainNameLabel": "[concat(variables('dnsName'),'-','nt1')]"
        },
        "publicIPAllocationMethod": "Dynamic"
    },
    "tags": {
        "resourceType": "Service Fabric",
        "clusterName": "[parameters('clusterName')]"
    }
}

Criar um novo balanceador de carga para o IP público

"dependsOn": [
    "[concat('Microsoft.Network/publicIPAddresses/',concat(variables('lbIPName'),'-',variables('vmNodeType1Name')))]"
]

Criar um novo conjunto de dimensionamento de máquina virtual (com SKUs de VM e SO atualizadas)

Tipo de nó de referência

"nodeTypeRef": "[variables('vmNodeType1Name')]"

VM SKU

"sku": {
    "name": "[parameters('vmNodeType1Size')]",
    "capacity": "[parameters('nt1InstanceCount')]",
    "tier": "Standard"
}

OS SKU

"imageReference": {
    "publisher": "[parameters('vmImagePublisher1')]",
    "offer": "[parameters('vmImageOffer1')]",
    "sku": "[parameters('vmImageSku1')]",
    "version": "[parameters('vmImageVersion1')]"
}

Se você estiver alterando o SKU do sistema operacional em um cluster Linux

No cluster do Windows, o valor da propriedade vmImage é 'Windows', enquanto o valor da mesma propriedade para o cluster Linux é o nome da imagem do sistema operacional usada. Por exemplo, - Ubuntu20_04(use o nome da imagem vm mais recente).

Portanto, se você estiver alterando a imagem da VM (OS SKU) em um cluster Linux, atualize a configuração vmImage no recurso de cluster do Service Fabric também.

#Update the property vmImage with the required OS name in your ARM template
{
    "vmImage": "[parameter(newVmImageName]”
}

Nota: Exemplo de newVmImageName: Ubuntu20_04

Você também pode atualizar o recurso de cluster usando o seguinte comando do PowerShell:

# Update cluster vmImage to target OS. This registers the SF runtime package type that is supplied for upgrades.
Update-AzServiceFabricVmImage -ResourceGroupName $resourceGroup -ClusterName $clusterName -VmImage Ubuntu20_04

Além disso, certifique-se de incluir quaisquer extensões adicionais necessárias para sua carga de trabalho.

Adicionar ao cluster um tipo de nó primário novo

Agora que o novo tipo de nó (vmNodeType1Name) tem seu próprio nome, sub-rede, IP, balanceador de carga e conjunto de escala, ele pode reutilizar todas as outras variáveis do tipo de nó original (como nt0applicationEndPort, nt0applicationStartPorte nt0fabricTcpGatewayPort):

"name": "[variables('vmNodeType1Name')]",
"applicationPorts": {
    "endPort": "[variables('nt0applicationEndPort')]",
    "startPort": "[variables('nt0applicationStartPort')]"
},
"clientConnectionEndpointPort": "[variables('nt0fabricTcpGatewayPort')]",
"durabilityLevel": "Bronze",
"ephemeralPorts": {
    "endPort": "[variables('nt0ephemeralEndPort')]",
    "startPort": "[variables('nt0ephemeralStartPort')]"
},
"httpGatewayEndpointPort": "[variables('nt0fabricHttpGatewayPort')]",
"isPrimary": true,
"reverseProxyEndpointPort": "[variables('nt0reverseProxyEndpointPort')]",
"vmInstanceCount": "[parameters('nt1InstanceCount')]"

Depois de implementar todas as alterações em seus arquivos de modelo e parâmetros, vá para a próxima seção para adquirir suas referências do Cofre da Chave e implantar as atualizações no cluster.

Obtenha as referências do Key Vault

Para implantar a configuração atualizada, você precisa de várias referências ao certificado de cluster armazenado no Cofre da Chave. A maneira mais fácil de encontrar esses valores é por meio do portal do Azure. Precisas:

  • URL do Cofre de Chaves do certificado do cluster. No seu Cofre de Chaves no portal do Azure, selecione Certificados> Seu identificadorsecreto> desejado:

    $certUrlValue="https://sftestupgradegroup.vault.azure.net/secrets/sftestupgradegroup20200309235308/dac0e7b7f9d4414984ccaa72bfb2ea39"

  • A impressão digital do certificado do cluster. (Você provavelmente já tem o certificado se se conectou ao cluster inicial para verificar seu status de integridade.) Na mesma folha de certificado (Certificados>Seu certificado desejado) no portal do Azure, copie a impressão digital X.509 SHA-1 (em hex):

    $thumb = "AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00"

  • O Identificador de Recurso do seu Cofre de Chaves. No seu Cofre de Chaves no portal do Azure, selecione Propriedades>ID do Recurso:

    $sourceVaultValue = "/subscriptions/########-####-####-####-############/resourceGroups/sftestupgradegroup/providers/Microsoft.KeyVault/vaults/sftestupgradegroup"

Implantar o modelo atualizado

Ajuste o templateFilePath conforme necessário e execute o seguinte comando:

# Deploy the new node type and its resources
$templateFilePath = "C:\Step1-AddPrimaryNodeType.json"

New-AzResourceGroupDeployment `
    -ResourceGroupName $resourceGroupName `
    -TemplateFile $templateFilePath `
    -TemplateParameterFile $parameterFilePath `
    -CertificateThumbprint $thumb `
    -CertificateUrlValue $certUrlValue `
    -SourceVaultValue $sourceVaultValue `
    -Verbose

Quando a implementação for concluída, verifique novamente a integridade do cluster e assegure-se de que todos os nós em ambos os tipos de nó estão saudáveis.

Get-ServiceFabricClusterHealth

Migrar nós de propagação para o novo tipo de nó

Agora estamos prontos para atualizar o tipo de nó original para não primário e começar a desativar os seus nós. À medida que os nós são desativados, os serviços do sistema e os nós de propagação do cluster migram para o novo conjunto de escalas.

Desmarcar o tipo de nó original como primário

Primeiro, remova a designação isPrimary do modelo do tipo de nó original.

{
    "isPrimary": false,
}

Em seguida, implante o modelo com a atualização. Esta implantação inicia a migração dos nós semente para o novo conjunto de dimensionamento.

$templateFilePath = "C:\Step2-UnmarkOriginalPrimaryNodeType.json"

New-AzResourceGroupDeployment `
    -ResourceGroupName $resourceGroupName `
    -TemplateFile $templateFilePath `
    -TemplateParameterFile $parameterFilePath `
    -CertificateThumbprint $thumb `
    -CertificateUrlValue $certUrlValue `
    -SourceVaultValue $sourceVaultValue `
    -Verbose

Observação

Levará algum tempo até que a migração do nó semente para o novo conjunto de dimensionamento seja concluída. Para garantir a consistência dos dados, apenas um nó semente pode ser alterado de cada vez. Cada alteração de nó semente requer uma atualização de cluster; assim, a substituição de um nó semente requer duas atualizações de cluster (uma para adição e remoção de nós). A atualização dos cinco nós semente neste cenário de exemplo resultará em dez atualizações de cluster.

Utilize o Service Fabric Explorer para monitorizar a migração dos nós semente para o novo conjunto de dimensionamento. Os nós do tipo de nó original (nt0vm) devem ser false na coluna Is Seed Node e os do novo tipo de nó (nt1vm) devem ser true.

Desativar os nós no conjunto de escala de tipo de nó original

Depois que todos os nós semente tiverem migrado para o novo conjunto de escalas, pode desativar os nós do conjunto de escalas original.

# Disable the nodes in the original scale set.
$nodeType = "nt0vm"
$nodes = Get-ServiceFabricNode

Write-Host "Disabling nodes..."
foreach($node in $nodes)
{
  if ($node.NodeType -eq $nodeType)
  {
    $node.NodeName

    Disable-ServiceFabricNode -Intent RemoveNode -NodeName $node.NodeName -Force
  }
}

Use o Service Fabric Explorer para monitorizar a progressão dos nós no conjunto de dimensionamento original do estado Desabilitando para Desabilitado.

Service Fabric Explorer mostrando o status de nós desabilitados

Para a durabilidade Silver e Gold, alguns nós entrarão no estado Desativado, enquanto outros poderão permanecer no estado de Desativação. No Service Fabric Explorer, verifique a guia Detalhes dos nós no estado de Desativação. Se eles mostrarem uma verificação de segurança pendente do tipo EnsurePartitionQuorum (garantindo o quórum para partições de serviço de infraestrutura), é seguro continuar.

Você pode continuar com a interrupção de dados e a remoção de nós presos no status 'Desativação' se eles mostrarem uma verificação de segurança pendente do tipo 'EnsurePartitionQuorum'.

Se o cluster tiver durabilidade Bronze, aguarde até que todos os nós atinjam o estado Desativado.

Interromper o fluxo de dados nos nós desativados

Agora você pode interromper dados nos nós desativados.

# Stop data on the disabled nodes.
foreach($node in $nodes)
{
  if ($node.NodeType -eq $nodeType)
  {
    $node.NodeName

    Start-ServiceFabricNodeTransition -Stop -OperationId (New-Guid) -NodeInstanceId $node.NodeInstanceId -NodeName $node.NodeName -StopDurationInSeconds 10000
  }
}

Remova o tipo de nó original e limpe seus recursos

Estamos prontos para remover o tipo de nó original e seus recursos associados para concluir o procedimento de dimensionamento vertical.

Remover o conjunto de escala original

Primeiro, remova o conjunto de escala de suporte do tipo de nó.

$scaleSetName = "nt0vm"
$scaleSetResourceType = "Microsoft.Compute/virtualMachineScaleSets"

Remove-AzResource -ResourceName $scaleSetName -ResourceType $scaleSetResourceType -ResourceGroupName $resourceGroupName -Force

Excluir o IP original e os recursos do balanceador de carga

Agora você pode excluir o IP original e os recursos do balanceador de carga. Nesta etapa, você também atualizará o nome DNS.

Observação

Esta etapa é opcional se você já estiver usando um IP público de SKU padrão e um balanceador de carga. Nesse caso, podes ter múltiplos conjuntos de escala/tipos de nós no mesmo balanceador de carga.

Execute os seguintes comandos, modificando o $lbname valor conforme necessário.

# Delete the original IP and load balancer resources
$lbName = "LB-sftestupgrade-nt0vm"
$lbResourceType = "Microsoft.Network/loadBalancers"
$ipResourceType = "Microsoft.Network/publicIPAddresses"
$oldPublicIpName = "PublicIP-LB-FE-nt0vm"
$newPublicIpName = "PublicIP-LB-FE-nt1vm"

$oldPrimaryPublicIP = Get-AzPublicIpAddress -Name $oldPublicIpName  -ResourceGroupName $resourceGroupName
$primaryDNSName = $oldPrimaryPublicIP.DnsSettings.DomainNameLabel
$primaryDNSFqdn = $oldPrimaryPublicIP.DnsSettings.Fqdn

Remove-AzResource -ResourceName $lbName -ResourceType $lbResourceType -ResourceGroupName $resourceGroupName -Force
Remove-AzResource -ResourceName $oldPublicIpName -ResourceType $ipResourceType -ResourceGroupName $resourceGroupName -Force

$PublicIP = Get-AzPublicIpAddress -Name $newPublicIpName  -ResourceGroupName $resourceGroupName
$PublicIP.DnsSettings.DomainNameLabel = $primaryDNSName
$PublicIP.DnsSettings.Fqdn = $primaryDNSFqdn
Set-AzPublicIpAddress -PublicIpAddress $PublicIP

Remover o estado do nó do tipo original de nó

Os nós do tipo original agora exibirão Erro para o seu Estado de Integridade. Remova o estado do nó deles do cluster.

# Remove state of the obsolete nodes from the cluster
$nodeType = "nt0vm"
$nodes = Get-ServiceFabricNode

Write-Host "Removing node state..."
foreach($node in $nodes)
{
  if ($node.NodeType -eq $nodeType)
  {
    $node.NodeName

    Remove-ServiceFabricNodeState -NodeName $node.NodeName -Force
  }
}

O Service Fabric Explorer agora deve refletir apenas os cinco nós do novo tipo de nó (nt1vm), todos com valores de Estado de Saúde de OK. O Estado de Integridade do Cluster continuará a mostrar Erro. Em seguida, corrigiremos isso atualizando o modelo para refletir as alterações mais recentes e reimplantando-o.

Atualize o modelo de implantação para refletir o tipo de nó primário recém-dimensionado

As alterações necessárias para esta etapa já foram feitas para você no arquivo de modeloStep3-CleanupOriginalPrimaryNodeType.json , e as seções a seguir explicarão essas alterações de modelo em detalhes. Se preferir, você pode pular a explicação e continuar a implantar o modelo atualizado e concluir o tutorial.

Atualizar a interface de gestão do cluster

Atualize o cluster managementEndpoint no modelo de implantação para fazer referência ao novo IP (atualizando vmNodeType0Name com vmNodeType1Name).

  "managementEndpoint": "[concat('https://',reference(concat(variables('lbIPName'),'-',variables('vmNodeType1Name'))).dnsSettings.fqdn,':',variables('nt0fabricHttpGatewayPort'))]",

Remova a referência do tipo de nó original

Remova a referência de tipo de nó original do recurso do Service Fabric no modelo de implantação:

"name": "[variables('vmNodeType0Name')]",
"applicationPorts": {
    "endPort": "[variables('nt0applicationEndPort')]",
    "startPort": "[variables('nt0applicationStartPort')]"
},
"clientConnectionEndpointPort": "[variables('nt0fabricTcpGatewayPort')]",
"durabilityLevel": "Bronze",
"ephemeralPorts": {
    "endPort": "[variables('nt0ephemeralEndPort')]",
    "startPort": "[variables('nt0ephemeralStartPort')]"
},
"httpGatewayEndpointPort": "[variables('nt0fabricHttpGatewayPort')]",
"isPrimary": true,
"reverseProxyEndpointPort": "[variables('nt0reverseProxyEndpointPort')]",
"vmInstanceCount": "[parameters('nt0InstanceCount')]"

Configurar políticas de saúde para ignorar erros existentes

Somente para clusters Silver e de maior durabilidade, atualize o recurso de cluster no modelo e configure as políticas de integridade para ignorar fabric:/System a integridade do aplicativo adicionando applicationDeltaHealthPolicies nas propriedades do recurso de cluster, conforme indicado abaixo. A política abaixo ignorará os erros existentes, mas não permitirá novos erros de saúde.

"upgradeDescription":  
{ 
 "forceRestart": false, 
 "upgradeReplicaSetCheckTimeout": "10675199.02:48:05.4775807", 
 "healthCheckWaitDuration": "00:05:00", 
 "healthCheckStableDuration": "00:05:00", 
 "healthCheckRetryTimeout": "00:45:00", 
 "upgradeTimeout": "12:00:00", 
 "upgradeDomainTimeout": "02:00:00", 
 "healthPolicy": { 
   "maxPercentUnhealthyNodes": 100, 
   "maxPercentUnhealthyApplications": 100 
 }, 
 "deltaHealthPolicy":  
 { 
   "maxPercentDeltaUnhealthyNodes": 0, 
   "maxPercentUpgradeDomainDeltaUnhealthyNodes": 0, 
   "maxPercentDeltaUnhealthyApplications": 0, 
   "applicationDeltaHealthPolicies":  
   { 
       "fabric:/System":  
       { 
           "defaultServiceTypeDeltaHealthPolicy":  
           { 
                   "maxPercentDeltaUnhealthyServices": 0 
           } 
       } 
   } 
 } 
}

Remover os recursos de suporte para o tipo original de nó

Remova todos os outros recursos relacionados ao tipo de nó original do modelo ARM e do ficheiro de parâmetros. Suprimir o seguinte:

    "vmImagePublisher": {
      "value": "MicrosoftWindowsServer"
    },
    "vmImageOffer": {
      "value": "WindowsServer"
    },
    "vmImageSku": {
      "value": "2019-Datacenter"
    },
    "vmImageVersion": {
      "value": "latest"
    },

Implantar o modelo finalizado

Por fim, implante o modelo modificado do Azure Resource Manager.

# Deploy the updated template file
$templateFilePath = "C:\Step3-CleanupOriginalPrimaryNodeType"

New-AzResourceGroupDeployment `
    -ResourceGroupName $resourceGroupName `
    -TemplateFile $templateFilePath `
    -TemplateParameterFile $parameterFilePath `
    -CertificateThumbprint $thumb `
    -CertificateUrlValue $certUrlValue `
    -SourceVaultValue $sourceVaultValue `
    -Verbose

Observação

Esta etapa demora um pouco, geralmente até duas horas.

A atualização alterará as configurações para o InfrastructureService; portanto, uma reinicialização do nó é necessária. Nesse caso, forceRestart é ignorado. O parâmetro upgradeReplicaSetCheckTimeout especifica o tempo máximo que o Service Fabric aguarda para que uma partição esteja em um estado seguro, se ainda não estiver em um estado seguro. Depois que as verificações de segurança forem aprovadas para todas as partições em um nó, o Service Fabric prosseguirá com a atualização nesse nó. O valor para o parâmetro upgradeTimeout pode ser reduzido para 6 horas, mas para segurança máxima devem ser utilizadas 12 horas.

Após a conclusão da implantação, verifique no portal do Azure se o Status do recurso do Service Fabric está Pronto. Verifique se você pode acessar o novo ponto de extremidade do Service Fabric Explorer, se o Estado de Integridade do Cluster está OK e se todos os aplicativos implantados funcionam corretamente.

Agora, você dimensionou verticalmente um tipo de nó primário de cluster!

Próximos passos