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

Artigo
08/25/2024

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 in-loco em nós de cluster do Service Fabric, pois essas operações potencialmente envolvem perda de dados e disponibilidade. O método mais seguro, confiável e recomendado para dimensionar um tipo de nó do Service Fabric é:

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.
Quando os conjuntos de escala originais e atualizados estiverem sendo 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 monitoração de estado) migrem para o novo conjunto de escalas.
Verifique se o cluster e os novos nós estão íntegros e, em seguida, remova o conjunto de escala original (e os recursos relacionados) e o estado do nó dos nós excluídos.

A seguir, você será guiado pelo processo de atualização do tamanho da VM e do sistema operacional das VMs do tipo nó primário de um cluster de amostra com durabilidade Silver, apoiado por um conjunto de escala única 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.

Aviso

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 status do cluster não estiver íntegro, 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 arquivo parameters.json e atualize o valor para clusterName algo exclusivo (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"

Nota

Verifique se o certOutputFolder local existe em sua máquina local 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, você precisa obter referências ao seu 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 = "BB796AA33BD9767E7DA27FE5182CF8FDEE714A70"

Em seguida, designe um nome de grupo de recursos para o cluster e defina os templateFilePath locais e parameterFilePath :

Nota

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 status de integridade

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 = "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.

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 modelo Step1-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.

Nota

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ó ref

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

SKU da VM

"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 um novo tipo de nó primário ao cluster

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.

Obter 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. Necessita de:

A URL do Cofre da Chave do certificado do cluster. No seu Cofre de Chaves no portal do Azure, selecione Certificados>Seu identificador secreto de certificado>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 = "BB796AA33BD9767E7DA27FE5182CF8FDEE714A70"
```

O ID do recurso do Cofre da Chave. No seu Cofre da Chave no portal do Azure, selecione ID do Recurso de Propriedades>:

$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 implantação for concluída, verifique a integridade do cluster novamente e verifique se todos os nós em ambos os tipos de nó estão íntegros.

Get-ServiceFabricClusterHealth

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

Agora estamos prontos para atualizar o tipo de nó original como não primário e começar a desativar 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 isPrimary designação no modelo do tipo de nó original.

{
    "isPrimary": false,
}

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

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

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

Nota

Levará algum tempo para concluir a migração do nó semente para o novo conjunto de escalas. 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.

Use o Service Fabric Explorer para monitorar a migração de nós semente para o novo conjunto de escalas. Os nós do tipo de nó original (nt0vm) devem ser todos 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 de propagação tiverem migrado para o novo conjunto de escalas, você poderá desabilitar 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 monitorar a progressão dos nós no conjunto de escala original do status Desabilitando para Desabilitado.

Service Fabric Explorer mostrando o status de nós desabilitados

Para durabilidade Silver e Gold, alguns nós entrarão no estado Desativado, enquanto outros poderão permanecer em um estado Desabilitante . No Service Fabric Explorer, verifique a guia Detalhes dos nós em Desabilitando estado. Se eles mostrarem uma verificação de segurança pendente do tipo EnsurePartitionQuorem (garantindo 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 .

Parar dados nos nós desativados

Agora você 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
  }
}

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.

Nota

Esta etapa é opcional se você já estiver usando um IP público de SKU padrão e um balanceador de carga. Nesse caso, você pode ter vários conjuntos de escala/tipos de nó sob o 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 agora mostrarão Erro para seu Estado de Integridade. 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
  }
}

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

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 modelo Step3-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 o ponto de extremidade de gerenciamento de 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'))]",

Remover a referência de 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 integridade 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 integridade.

"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 ao tipo de nó original do modelo ARM e do arquivo 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

Nota

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

Saiba como adicionar um tipo de nó a um cluster
Saiba mais sobre a escalabilidade do aplicativo.
Dimensione um cluster do Azure para dentro ou para fora.
Dimensione um cluster do Azure programaticamente usando o SDK de computação fluente do Azure.
Dimensione um cluster autônomo para dentro ou para fora.

Partilhar via

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

Configurar o cluster de teste

Gerar um certificado autoassinado e implantar o cluster

Usar um certificado existente para implantar o cluster

Conectar-se ao novo cluster e verificar o status de integridade

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

Atualizar o modelo de cluster com o conjunto de escala atualizado

Criar uma nova sub-rede na rede virtual existente

Criar um novo IP público com um domainNameLabel exclusivo

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

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

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

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

Obter as referências do Key Vault

Implantar o modelo atualizado

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

Desmarcar o tipo de nó original como primário

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

Parar dados nos nós desativados

Remova o tipo de nó original e limpe seus recursos

Remover o conjunto de escala original

Excluir o IP original e os recursos do balanceador de carga

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

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

Atualizar o ponto de extremidade de gerenciamento de cluster

Remover a referência de tipo de nó original

Configurar políticas de integridade para ignorar erros existentes

Remover recursos de suporte para o tipo de nó original

Implantar o modelo finalizado

Próximos passos

Comentários

Recursos adicionais