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

Artigo
10/15/2024

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

Adicione um novo tipo de nó ao cluster do Service Fabric, apoiado pela configuração e SKU do conjunto de dimensionamento de máquinas virtuais atualizados (ou modificados). Essa etapa também envolve a configuração de um novo balanceador de carga, sub-rede e IP para o conjunto de dimensionamento.
Depois que os conjuntos de dimensionamento original e atualizado estiverem em execução lado a lado, desabilite as instâncias de nó originais uma de cada vez para que os serviços do sistema (ou réplicas dos serviços com estado) migrem para o novo conjunto de dimensionamento.
Verifique se o cluster e os novos nós estão íntegros e remova o conjunto de dimensionamento original (e os recursos relacionados) e o estado do nó para os nós excluídos.

As instruções a seguir guiarão você pelo processo de atualização do tamanho da VM e do sistema operacional de VMs do tipo de nó primário de um cluster de exemplo com durabilidade Prata, que conta com um único conjunto de dimensionamento com cinco nós. Atualizaremos o tipo de nó primário:

Do tamanho da VM Standard_D2_V2 para Standard D4_V2 e
Do sistema operacional da VM do Windows Server 2019 Datacenter ao Windows Server 2022 Datacenter.

Aviso

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

Não tente um procedimento de expansão do tipo de nó primário se o status do cluster não estiver íntegro, pois isso 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 inicial de teste do Service Fabric. Primeiro, baixe os modelos de amostra do Azure Resource Manager que usaremos para concluir este 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 de clusterName para algo exclusivo (no Azure).

Os comandos a seguir irão orientá-lo na geração de um novo certificado autoassinado e na implantação do cluster de teste. Se você já tiver um certificado que deseja usar, vá 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 de resourceGroupName, certSubjectName, parameterFilePath e templateFilePath da 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 a localização de certOutputFolder existe no computador 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 for concluída, localize o arquivo .pfx ($certPfx) no seu computador local e importe-o para o repositório 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 retornará a impressão digital do certificado, que você poderá usar para conectar-se ao novo cluster e verificar o status da integridade. (Pule 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 do Azure Key Vault existente para implantar o cluster de teste. Para fazer isso, você precisará obter referências ao Key Vault 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"

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

Observação

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

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

Por fim, 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 da integridade

Conecte-se ao cluster e verifique se todos os cinco nós estão íntegros (substitua as variáveis clusterName e thumb com 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 o conjunto de dimensionamento atualizado

Para atualizar (dimensionar verticalmente) um tipo de nó, primeiro precisaremos implantar um novo tipo de nó respaldado por um novo conjunto de dimensionamento e recursos de suporte. O novo conjunto de dimensionamento será marcado como primário (isPrimary: true), assim como o conjunto de dimensionamento original. Se você quiser escalar verticalmente um tipo de nó não primário, confira Escalar verticalmente um tipo de nó não primário de cluster do Service Fabric. Os recursos criados na seção a seguir serão, em última instância, o novo tipo de nó primário no cluster e os recursos do tipo de nó primário original serão excluídos.

Atualizar o modelo de cluster com o conjunto de dimensionamento atualizado

Estas são as modificações seção a 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 as referências do Key Vault e implantar o modelo atualizado que adiciona um novo tipo de nó primário ao cluster.

Observação

Certifique-se de usar nomes que sejam exclusivos do tipo de nó original, conjunto de dimensionamento, balanceador de carga, IP e sub-rede do tipo de nó primário original, pois esses recursos serão excluídos posteriormente no processo.

Criar uma nova sub-rede na rede virtual existente

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

Criar um novo IP 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

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

Criar um novo conjunto de dimensionamento de máquinas virtuais (com SKUs de OS e VM atualizados)

Referência 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 você estiver alterando o SKU do sistema operacional em um 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 sistema operacional usada. Por exemplo, - Ubuntu20_04 (use o nome da imagem da vm mais recente).

Portanto, se você estiver alterando a imagem da VM (SKU do SO) em um cluster do Linux, atualize também a configuraçã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]”
}

Observação: exemplo de newVmImageName: Ubuntu20_04

Você também pode atualizar o recurso de cluster por meio do 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 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 seu próprio nome, sub-rede, IP, balanceador de carga e conjunto de dimensionamento, ele pode reutilizar todas as outras variáveis do tipo de nó original (como nt0applicationEndPort, nt0applicationStartPort e 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 arquivos de modelo e de parâmetros, vá para a próxima seção para adquirir suas referências do Key Vault e implantar as atualizações no cluster.

Obter referências do Key Vault

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

A URL de Key Vault do seu certificado de cluster. Pelo Key Vault no portal do Azure, selecione Certificados>Certificado desejado>Identificador secreto:
```
$certUrlValue="https://sftestupgradegroup.vault.azure.net/secrets/sftestupgradegroup20200309235308/dac0e7b7f9d4414984ccaa72bfb2ea39"
```
A impressão digital do seu certificado de cluster. (Provavelmente você já terá isso se estiver conectado ao cluster inicial para verificar seu status de integridade.) Na mesma folha de certificado (Certificados>Certificado desejado) no portal do Azure, copie a impressão digital X.509 SHA-1 (em hexadecimal):
```
$thumb = "BB796AA33BD9767E7DA27FE5182CF8FDEE714A70"
```

A ID do Recurso do Key Vault. Pelo Key Vault 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 este 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 novamente a integridade do cluster e veja se todos os nós nos dois tipos estão íntegros.

Get-ServiceFabricClusterHealth

Migrar nós de semente 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 desabilitar os nós. Com a desabilitação dos nós, os serviços do sistema de cluster e nós de semente migram para o novo conjunto de dimensionamento.

Desmarcar o tipo de nó original como primário

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

{
    "isPrimary": false,
}

Em seguida, implante o modelo com a atualização. Essa implantação iniciará a migração de nós de 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

A migração do nó semente para o novo conjunto de dimensionamento levará um tempo para ser concluída. Para garantir a consistência dos dados, apenas um nó semente pode ser alterado por vez. Cada alteração de nó semente requer uma atualização do cluster. Portanto, a substituição de um nó semente exige duas atualizações do cluster (uma para adição e outra para remoção do nó). Atualizar os cinco nós semente neste cenário de exemplo resultará em dez atualizações do cluster.

Use o Service Fabric Explorer para monitorar a migração de nós de semente para o novo conjunto de dimensionamento. Os nós do tipo de nó original (nt0vm) devem ser false na coluna de É nó de semente e os do novo tipo de nó (nt1vm) serão true.

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

Depois que todos os nós de semente migraram para o novo conjunto de dimensionamento, você poderá desabilitar 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
  }
}

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

O Service Fabric Explorer mostrando o status dos nós desabilitados

Para durabilidade Prata e Ouro, alguns nós entrarão em estado Desabilitado, enquanto outros podem permanecer em um estado Desabilitando. No Service Fabric Explorer, verifique a guia Detalhes dos nós no estado Desabilitando. Se eles mostrarem uma verificação de segurança pendente do tipo EnsurePartitionQuorem (garantindo o quorum para partições de serviço de infraestrutura), será seguro continuar.

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

Se o cluster for de durabilidade Bronze, aguarde até que todos os nós atinjam o estado Desabilitado.

Interromper dados nos nós desabilitados

Você agora pode interromper dados nos nós desabilitados.

# 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 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 dimensionamento original

Primeiro, remova o conjunto de dimensionamento de backup 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

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

Observação

Essa etapa é opcional se você já estiver usando um IP de SKU e um balanceador de carga Standard. Nesse caso, você teria vários conjuntos de dimensionamento/tipos de nós no mesmo balanceador de carga.

Execute os comandos a seguir, modificando o valor $lbname 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 estado do nó do tipo de nó original

Os nós do tipo de nó original agora mostrarão Erro para o Estado de integridade. Remova o estado de 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 refletirá agora apenas os cinco nós do novo tipo de nó (nt1vm), todos com os valores de estado de integridade como OK. O estado de integridade do cluster ainda mostrará Erro. Corrigiremos isso em seguida ao atualizar o modelo para refletir as alterações e reimplantação mais recentes.

Atualizar o modelo de implantação para refletir o tipo de nó primário dimensionado recentemente

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 do modelo em detalhes. Se preferir, você pode ignorar 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 do tipo de nó original

Remova a referência do tipo de nó original do recurso 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 de durabilidade Prata e mais alta, atualize o recurso de cluster no modelo e configure as políticas de integridade para ignorar a integridade de aplicativo fabric:/System ao adicionar applicationDeltaHealthPolicies às propriedades do recurso de cluster, conforme as instruções abaixo. A política abaixo ignorará os erros atuais, 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 do ARM e do arquivo de parâmetros. Exclua:

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

Implantar o modelo finalizado

Por fim, implante o modelo do Azure Resource Manager 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

Observação

Esta etapa levará geralmente até duas horas.

A atualização altera as configurações de InfrastructureService; portanto, é necessário reiniciar o nó. Nesse caso, forceRestart é ignorado. O parâmetro upgradeReplicaSetCheckTimeout especifica o tempo máximo que Service Fabric aguarda até que uma partição esteja em um estado seguro, se ainda não estiver em um estado seguro. Depois que todas as partições de um nó passam nas verificações de segurança, o Service Fabric continua com a atualização do nó. É possível reduzir o valor do parâmetro upgradeTimeout para 6 horas, mas você deve usar 12 horas para ter segurança máxima.

Após a conclusão da implantação, verifique no portal do Azure se o status do recurso Service Fabric está como Pronto. Verifique se você consegue 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 estão funcionando corretamente.

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

Próximas etapas

Saiba como adicionar um tipo de nó a um cluster
Saiba mais sobre escalabilidade de aplicativo.
Reduzir horizontalmente ou escalar horizontalmente um cluster do Azure.
Dimensionar um cluster do Azure de forma programática usando a SDK fluente de computação do Azure.
Dimensione um cluster autônomo para dentro ou para fora.

Compartilhar via

Dimensionar um tipo de nó 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 da integridade

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

Atualizar o modelo de cluster com o conjunto de dimensionamento atualizado

Criar uma nova sub-rede na rede virtual existente

Criar um novo IP com um domainNameLabel exclusivo

Criar um novo balanceador de carga para o IP

Criar um novo conjunto de dimensionamento de máquinas virtuais (com SKUs de OS e VM atualizados)

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

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

Obter referências do Key Vault

Implantar o modelo atualizado

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

Desmarcar o tipo de nó original como primário

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

Interromper dados nos nós desabilitados

Remover o tipo de nó original e limpar seus recursos

Remover o conjunto de dimensionamento original

Excluir o IP original e os recursos do balanceador de carga

Remover estado do nó do tipo de nó original

Atualizar o modelo de implantação para refletir o tipo de nó primário dimensionado recentemente

Atualizar o ponto de extremidade de gerenciamento de cluster

Remover a referência do 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óximas etapas

Comentários

Recursos adicionais