Aumentar verticalmente um nó do tipo primário do cluster do Service Fabric

  • Artigo

Este artigo descreve como aumentar verticalmente um tipo de nó primário do cluster do Service Fabric com um período de indisponibilidade mínimo. As atualizações de SKU no local não são suportadas em nós de cluster do Service Fabric, uma vez que tais operações potencialmente envolvem perda de dados e disponibilidade. O método mais seguro, fiável e recomendado para aumentar verticalmente um tipo de nó do Service Fabric é:

  1. Adicione um novo tipo de nó ao cluster do Service Fabric, apoiado pelo SKU e configuração do conjunto de dimensionamento de máquinas virtuais atualizado (ou modificado). Este passo também envolve a configuração de um novo balanceador de carga, sub-rede e IP público para o conjunto de dimensionamento.

  2. Assim que os conjuntos de dimensionamento originais e atualizados estiverem em execução lado a lado, desative as instâncias de nó originais uma de cada vez para que os serviços de sistema (ou réplicas de serviços com estado) sejam migrados para o novo conjunto de dimensionamento.

  3. Verifique se o cluster e os novos nós estão em bom estado de funcionamento e, em seguida, remova o conjunto de dimensionamento original (e os recursos relacionados) e o estado do nó para os nós eliminados.

O seguinte irá guiá-lo ao longo do processo de atualização do tamanho da VM e do sistema operativo de VMs do tipo de nó primário de um cluster de exemplo com durabilidade Silver, apoiado por um único conjunto de dimensionamento com cinco nós. Vamos atualizar o tipo de nó primário:

  • Do tamanho da VM Standard_D2_V2 ao D4_V2 Standard e
  • Do sistema operativo VM Windows Server 2019 Datacenter ao Windows Server 2022 Datacenter.

Aviso

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

Não tente um procedimento de aumento vertical do tipo de nó primário se o estado do cluster estiver em mau estado de funcionamento, uma vez que tal só irá desestabilizar ainda mais o cluster.

Os modelos de implementação passo a passo do Azure que iremos utilizar 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. Em primeiro lugar, transfira os modelos de exemplo do Azure Resource Manager que iremos utilizar para concluir este cenário.

Em seguida, inicie sessão 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 algo exclusivo (no Azure).

Os seguintes comandos irão orientá-lo ao longo da geração de um novo certificado autoassinado e da implementação do cluster de teste. Se já tiver um certificado que gostaria de utilizar, avance para Utilizar um certificado existente para implementar o cluster.

Gerar um certificado autoassinado e implementar o cluster

Em primeiro lugar, atribua as variáveis necessárias para a implementação do cluster do Service Fabric. Ajuste os valores para resourceGroupName, certSubjectName, parameterFilePathe templateFilePath para a 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"

Nota

Certifique-se de que a certOutputFolder localização existe no seu computador local antes de executar o comando para implementar um novo cluster do Service Fabric.

Em seguida, implemente 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

Assim que a implementação estiver concluída, localize o ficheiro .pfx ($certPfx) no seu computador local e importe-o para o arquivo 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 devolve o thumbprint do certificado, que agora pode utilizar para ligar ao novo cluster e verificar o estado de funcionamento do mesmo. (Ignore a secção seguinte, que é uma abordagem alternativa à implementação do cluster.)

Utilizar um certificado existente para implementar o cluster

Em alternativa, pode utilizar um certificado do Azure Key Vault existente para implementar o cluster de teste. Para tal, tem de obter referências ao seu Key Vault e thumbprint do certificado.

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

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

Nota

O grupo de recursos designado já tem de existir e estar localizado na mesma região que a sua Key Vault.

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

Por fim, execute o seguinte comando para implementar 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

Ligar ao novo cluster e verificar o estado de funcionamento

Ligue-se ao cluster e certifique-se de que todos os cinco nós estão em bom estado de funcionamento (substitua as clusterName variáveis e thumb pelos seus próprios valores):

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

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.

Implementar um novo tipo de nó primário com um conjunto de dimensionamento atualizado

Para atualizar (dimensionar verticalmente) um tipo de nó, primeiro teremos de implementar um novo tipo de nó apoiado por um novo conjunto de dimensionamento e recursos de suporte. O novo conjunto de dimensionamento será marcado como primário (isPrimary: true), tal como o conjunto de dimensionamento original. Se quiser aumentar verticalmente um tipo de nó não primário, veja Aumentar verticalmente um tipo de nó não primário do cluster do Service Fabric. Os recursos criados na secção seguinte tornar-se-ão, em última análise, no novo tipo de nó primário no cluster e os recursos originais do tipo de nó primário são eliminados.

Atualizar o modelo de cluster com o conjunto de dimensionamento atualizado

Eis as modificações secção a secção do modelo de implementação de cluster original para adicionar um novo tipo de nó primário e recursos de suporte.

As alterações necessárias para este passo já foram efetuadas no ficheiro de modelo Step1-AddPrimaryNodeType.json e o seguinte irá explicar estas alterações em detalhe. Se preferir, pode ignorar a explicação e continuar a obter as suas referências de Key Vault e implementar o modelo atualizado que adiciona um novo tipo de nó primário ao cluster.

Nota

Certifique-se de que utiliza nomes exclusivos do tipo de nó original, conjunto de dimensionamento, balanceador de carga, IP público e sub-rede do tipo de nó primário original, uma vez que estes recursos são eliminados num passo 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 domínio exclusivoNameLabel

{
    "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áquinas virtuais (com VMs atualizadas e SKUs do SO)

Ref de Tipo de Nó

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

SKU da VM

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

SKU do SO

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

Se estiver a alterar o SKU do SO num Cluster do Linux

No cluster do Windows, o valor da propriedade vmImage é "Windows", enquanto o valor da mesma propriedade para o cluster do Linux é o nome da imagem do SO utilizada. Por exemplo, - Ubuntu20_04(utilize o nome da imagem da vm mais recente).

Por isso, se estiver a alterar a imagem da VM (SKU do SO) num cluster do Linux, atualize também a definição vmImage no recurso de cluster do Service Fabric.

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

Nota: Exemplo de newVmImageName: Ubuntu20_04

Também pode atualizar o recurso do cluster com 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 que inclui todas as extensões adicionais necessárias para a carga de trabalho.

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

Agora que o novo tipo de nó (vmNodeType1Name) tem o seu próprio nome, sub-rede, IP, balanceador de carga e conjunto de dimensionamento, 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 nos ficheiros de modelo e parâmetros, avance para a secção seguinte para adquirir as referências Key Vault e implementar as atualizações no cluster.

Obter as suas referências de Key Vault

Para implementar a configuração atualizada, precisa de várias referências ao certificado de cluster armazenado no seu Key Vault. A forma mais fácil de encontrar estes valores é através de portal do Azure. É necessário:

  • O URL Key Vault do certificado de cluster. Na sua Key Vault no portal do Azure, selecione Certificados> Oidentificador de segredodo certificado> pretendido:

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

  • O thumbprint do certificado de cluster. (Provavelmente já tem o certificado se tiver ligado ao cluster inicial para verificar o estado de funcionamento.) No mesmo painel de certificado (Certificados>O certificado pretendido) no portal do Azure, copie X.509 SHA-1 Thumbprint (em hex):

    $thumb = "BB796AA33BD9767E7DA27FE5182CF8FDEE714A70"

  • O ID de Recurso da sua Key Vault. No seu Key Vault no portal do Azure, selecioneID de Recursode Propriedades>:

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

Implementar 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 estiver concluída, verifique novamente o estado de funcionamento do cluster e certifique-se de que todos os nós em ambos os tipos de nós estão em bom estado de funcionamento.

Get-ServiceFabricClusterHealth

Migrar nós de seed para o novo tipo de nó

Estamos agora prontos para atualizar o tipo de nó original como não primário e começar a desativar os respetivos nós. À medida que os nós desativam, os serviços de sistema e os nós de semente do cluster migram para o novo conjunto de dimensionamento.

Desmarcar o tipo de nó original como primário

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

{
    "isPrimary": false,
}

Em seguida, implemente o modelo com a atualização. Esta implementação inicia a migração de nós de seed 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

Nota

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

Utilize Service Fabric Explorer para monitorizar a migração de nós de sementes para o novo conjunto de dimensionamento. Os nós do tipo de nó original (nt0vm) devem ser todos falsos na coluna Nó É Seed e os do novo tipo de nó (nt1vm) devem ser verdadeiros.

Desativar os nós no conjunto de dimensionamento do tipo de nó original

Assim que todos os nós de seed tiverem sido migrados para o novo conjunto de dimensionamento, pode desativar os nós do conjunto de dimensionamento 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
  }
}

Utilize Service Fabric Explorer para monitorizar a progressão dos nós no conjunto de dimensionamento original de Desativar para Estado desativado.

Service Fabric Explorer a mostrar o estado dos nós desativados

Para a durabilidade Silver e Gold, alguns nós entrarão no estado Desativado, enquanto outros poderão permanecer num estado de Desativação . No Service Fabric Explorer, selecione o separador Detalhes dos nós no estado Desativar. Se mostrarem uma Verificação de Segurança Pendente do Tipo EnsurePartitionQuorem (garantindo o quórum para partições do serviço de infraestrutura), é seguro continuar.

Pode continuar com a paragem dos dados e a remoção de nós bloqueados no estado

Se o cluster for Durabilidade bronze, aguarde que todos os nós atinjam o estado Desativado .

Parar dados nos nós desativados

Agora pode parar os 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
  }
}

Remover o tipo de nó original e limpar os respetivos recursos

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

Remover o conjunto de dimensionamento original

Primeiro, remova o conjunto de dimensionamento de apoio do tipo de nó.

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

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

Eliminar o IP original e os recursos do balanceador de carga

Agora, pode eliminar o IP original e os recursos do balanceador de carga. Neste passo, também irá atualizar o nome DNS.

Nota

Este passo é opcional se já estiver a utilizar um IP público e um balanceador de carga do SKU Standard . Neste caso, pode ter vários conjuntos de dimensionamento/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 de nó original

Os nós do tipo de nó original mostrarão agora Erro para o estado de funcionamento. Remova o estado do nó 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
  }
}

Service Fabric Explorer devem agora refletir apenas os cinco nós do novo tipo de nó (nt1vm), todos com valores de Estado de Funcionamento de OK. O Estado de Funcionamento do Cluster continuará a mostrar o Erro. Vamos resolvê-lo em seguida ao atualizar o modelo para refletir as alterações mais recentes e reimplementar.

Atualizar o modelo de implementação para refletir o tipo de nó primário recém-aumentado verticalmente

As alterações necessárias para este passo já foram efetuadas no ficheiro de modelo Step3-CleanupOriginalPrimaryNodeType.json e as secções seguintes explicarão estas alterações de modelo em detalhe. Se preferir, pode ignorar a explicação e continuar a implementar o modelo atualizado e concluir o tutorial.

Atualizar o ponto final de gestão do cluster

Atualize o cluster managementEndpoint no modelo de implementação para referenciar o novo IP (ao atualizar vmNodeType0Name com vmNodeType1Name).

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

Remover a referência do tipo de nó original

Remova a referência do tipo de nó original do recurso do Service Fabric no modelo de implementaçã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 estado de funcionamento para ignorar erros existentes

Apenas para clusters silver e de maior durabilidade, atualize o recurso do cluster no modelo e configure políticas de estado de funcionamento para ignorar fabric:/System o estado de funcionamento da aplicação ao adicionar applicationDeltaHealthPolicies nas propriedades de recursos do cluster, conforme indicado abaixo. A política abaixo ignorará os erros existentes, mas não permitirá novos erros de estado de funcionamento.

"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 recursos de suporte para o tipo de nó original

Remova todos os outros recursos relacionados com o tipo de nó original do modelo arm e do ficheiro de parâmetros. Elimine o seguinte:

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

Implementar o modelo finalizado

Por fim, implemente o modelo de Resource Manager do Azure modificado.

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

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

Nota

Este passo demorará algum tempo, normalmente até duas horas.

A atualização irá alterar as definições para InfrastructureService; Por conseguinte, é necessário reiniciar um nó. Neste caso, forceRestart é ignorado. O parâmetro upgradeReplicaSetCheckTimeout especifica o tempo máximo durante o qual o Service Fabric aguarda que uma partição esteja num estado seguro, se ainda não estiver num estado seguro. Assim que as verificações de segurança passarem para todas as partições num nó, o Service Fabric avança com a atualização nesse nó. O valor do parâmetro upgradeTimeout pode ser reduzido para 6 horas, mas, para uma segurança máxima, devem ser utilizadas 12 horas.

Depois de concluída a implementação, verifique no portal do Azure se o Estado do recurso do Service Fabric está Pronto. Verifique se consegue aceder ao novo ponto final Service Fabric Explorer, se o Estado de Funcionamento do Cluster está OK e se todas as aplicações implementadas funcionam corretamente.

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

Passos seguintes