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

Este artigo descreve como aumentar verticalmente um tipo de nó não 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 nos 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 a ser executados lado a lado, migre a carga de trabalho ao definir restrições de colocação das aplicações para o novo tipo de nó.

3. Verifique se o cluster está 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ó não primário de um cluster de exemplo com durabilidade Silver, apoiado por um único conjunto de dimensionamento com cinco nós utilizados como um tipo de nó secundário. O tipo de nó principal com os serviços do sistema do Service Fabric permanecerá inalterado. Vamos atualizar o tipo de nó não primário:

• Do tamanho da VM Standard_D2_V2 ao D4_V2 Standard e
• Do sistema operativo VM Windows Server 2019 Datacenter para o 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.

Não tente um procedimento de aumento vertical do tipo de nó não primário se o estado do cluster estiver em mau estado de funcionamento, uma vez que tal só irá desestabilizar ainda mais o cluster. Vamos utilizar os modelos de implementação passo a passo do Azure utilizados no guia Aumentar verticalmente um tipo de nó primário do cluster do Service Fabric . No entanto, vamos modificá-los para que não sejam específicos dos tipos de nós primários. Os modelos estão disponíveis no GitHub.

Configurar o cluster de teste

Vamos configurar o cluster de teste inicial do Service Fabric. Primeiro, 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 de 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 devolverá 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, terá 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 o 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 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

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

Implementar um novo tipo de nó não 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 não primário (isPrimary: false), tal como o conjunto de dimensionamento original. Se quiser aumentar verticalmente um tipo de nó primário, veja Aumentar verticalmente um tipo de nó primário do cluster do Service Fabric. Os recursos criados na secção seguinte acabarão por se tornar no novo tipo de nó no cluster e os recursos do tipo de nó original serão eliminados.

Atualizar o modelo de cluster com o conjunto de dimensionamento atualizado

Seguem-se as modificações secção a secção do modelo de implementação de cluster original para adicionar um novo tipo de nó e recursos de suporte.

A maioria das alterações necessárias para este passo já foram efetuadas no ficheiro de modelo Step1-AddPrimaryNodeType.json . No entanto, tem de ser efetuada uma alteração adicional para que o ficheiro de modelo funcione para tipos de nós não primários. As secções seguintes explicarão estas alterações em detalhe e serão efetuadas chamadas quando tiver de fazer uma alteração.

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ó original não primário, uma vez que estes recursos serã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 ASCs e VMs atualizadas)

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')]"
}

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

Adicionar um novo tipo de nó não 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).

No ficheiro de modelo existente, o isPrimary parâmetro está definido como true para o guia Aumentar verticalmente um tipo de nó primário do cluster do Service Fabric . Altere isPrimary para false para o tipo de nó não primário:

"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": false,
"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 de Key Vault e implementar as atualizações no cluster.

Obter as suas referências de Key Vault

Para implementar a configuração atualizada, precisará 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. Precisará:

• O URL de Key Vault do certificado de cluster. No Key Vault no portal do Azure, selecione Certificados> OIdentificador de Segredo docertificado> pretendido:

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

• O thumbprint do certificado de cluster. (Provavelmente já o tem 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 do Recurso da sua Key Vault. No Key Vault no portal do Azure, selecioneID do 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 cargas de trabalho para o novo tipo de nó

Aguarde até que todas as aplicações sejam movidas para o novo tipo de nó e estejam em bom estado de funcionamento.

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. 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 de SKU Standard e um balanceador de carga. 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"
$oldPublicIP = Get-AzPublicIpAddress -Name $oldPublicIpName  -ResourceGroupName $resourceGroupName
$nonPrimaryDNSName = $oldNonPrimaryPublicIP.DnsSettings.DomainNameLabel
$nonPrimaryDNSFqdn = $oldNonPrimaryPublicIP.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 = $nonPrimaryDNSName
$PublicIP.DnsSettings.Fqdn = $nonPrimaryDNSFqdn
Set-AzPublicIpAddress -PublicIpAddress $PublicIP

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

Os nós originais do tipo de nó 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 deve agora refletir apenas os cinco nós do novo tipo de nó (nt1vm), todos com valores de Estado de Funcionamento de OK. Vamos remediar isso 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ó não primário recentemente aumentado verticalmente

A maioria das alterações necessárias para este passo já foram efetuadas no ficheiro de modelo Step3-CleanupOriginalPrimaryNodeType.json . No entanto, tem de ser efetuada uma alteração adicional para que o ficheiro de modelo funcione para tipos de nós não primários. As secções seguintes explicarão estas alterações detalhadamente e serão efetuadas chamadas quando tiver de fazer uma alteração.

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.

No ficheiro de modelo existente, o isPrimary parâmetro está definido como true para o guia aumentar verticalmente um tipo de nó primário do cluster do Service Fabric . Altere isPrimary para para false o tipo de nó não primário:

"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": false,
"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 em propriedades de recursos de 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; portanto, é necessário reiniciar um nó. Neste caso, forceRestart é ignorado. O parâmetro upgradeReplicaSetCheckTimeout especifica o tempo máximo que o Service Fabric aguarda para 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 por todas as partições num nó, o Service Fabric continua com a atualização nesse nó. O valor do parâmetro upgradeTimeout pode ser reduzido para 6 horas, mas para segurança máxima devem ser utilizadas 12 horas.

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

Com isso, dimensionou verticalmente um tipo de nó não primário do cluster!

Passos seguintes

• Saiba como adicionar um tipo de nó a um cluster
• Saiba mais sobre a escalabilidade da aplicação.
• Dimensionar ou reduzir um cluster do Azure.
• Dimensione um cluster do Azure programaticamente com o fluente SDK de computação do Azure.
• Dimensionar um cluster autónomo para dentro ou para fora.