Aumentare le prestazioni di un tipo di nodo non primario del cluster di Service Fabric

Articolo
08/25/2024

Questo articolo descrive come aumentare le prestazioni di un tipo di nodo non primario del cluster di Service Fabric con tempi di inattività minimi. Gli aggiornamenti dello SKU sul posto non sono supportati nei nodi del cluster di Service Fabric, in quanto tali operazioni comportano potenzialmente la perdita di dati e disponibilità. Il metodo più sicuro, affidabile e consigliato per aumentare le prestazioni di un tipo di nodo di Service Fabric è il seguente:

Aggiungere un nuovo tipo di nodo al cluster di Service Fabric, supportato dallo SKU e dalla configurazione del set di scalabilità di macchine virtuali aggiornati (o modificati). Questo passaggio comporta anche la configurazione di un nuovo servizio di bilanciamento del carico, una subnet e un indirizzo IP pubblico per il set di scalabilità.
Quando entrambi i set di scalabilità originali e aggiornati vengono eseguiti fianco a fianco, eseguire la migrazione del carico di lavoro impostando vincoli di posizionamento per le applicazioni al nuovo tipo di nodo.
Verificare che il cluster sia integro, quindi rimuovere il set di scalabilità originale (e le risorse correlate) e lo stato del nodo per i nodi eliminati.

Di seguito viene illustrato il processo per aggiornare le dimensioni della macchina virtuale e il sistema operativo di macchine virtuali di tipo nodo non primario di un cluster di esempio con durabilità Silver, supportato da un singolo set di scalabilità con cinque nodi usati come tipo di nodo secondario. Il tipo di nodo primario con i servizi di sistema di Service Fabric rimarrà invariato. Verrà aggiornato il tipo di nodo non primario:

Dalle dimensioni della macchina virtuale Standard_D2_V2 a Standard D4_V2e
Dal sistema operativo della macchina virtuale Windows Server 2019 Datacenter a Windows Server 2022 Datacenter.

Avviso

Prima di provare a eseguire questa procedura su un cluster di produzione, è consigliabile esaminare i modelli di esempio e verificare il processo su un cluster di test.

Non tentare una procedura di aumento delle prestazioni del tipo di nodo non primario se lo stato del cluster non è integro, in quanto ciò destabilizzerà ulteriormente il cluster. Verranno usati i modelli di distribuzione di Azure passo dopo passo usati nella guida Aumentare le prestazioni di un tipo di nodo primario del cluster di Service Fabric. Tuttavia, le modifiche verranno modificate in modo che non siano specifiche per i tipi di nodo primario. I modelli sono disponibili in GitHub.

Configurare il cluster di test

Configurare il cluster di test iniziale di Service Fabric. Prima di tutto, scaricare i modelli di esempio di Azure Resource Manager che verranno usati per completare questo scenario.

Successivamente, accedere all'account Azure.

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

Aprire quindi il file parameters.json e aggiornare il valore clusterName con un valore univoco (all'interno di Azure).

I comandi seguenti consentono di generare un nuovo certificato autofirmato e di distribuire il cluster di test. Se si ha già un certificato da usare, andare a Usare un certificato esistente per distribuire il cluster.

Generare un certificato autofirmato e distribuire il cluster

Per prima cosa, assegnare le variabili necessarie per la distribuzione del cluster Service Fabric. Modificare i valori per resourceGroupName, certSubjectName, parameterFilePathe templateFilePath per l'account e l'ambiente specifici:

# 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

Prima di eseguire il comando per distribuire un nuovo cluster Service Fabric, verificare che nel computer locale esista il percorso certOutputFolder. Quindi distribuire il cluster di test di Service Fabric:

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

Al termine della distribuzione, individuare il file .pfx ($certPfx) nel computer locale e importarlo nell'archivio certificati:

cd c:\certificates
$certPfx = ".\sftestupgradegroup20200312121003.pfx"
Import-PfxCertificate `
     -FilePath $certPfx `
     -CertStoreLocation Cert:\CurrentUser\My `
     -Password (ConvertTo-SecureString Password!1 -AsPlainText -Force)

L'operazione restituirà l'identificazione personale del certificato, che ora è possibile usare per connettersi al nuovo cluster e controllarne lo stato di integrità. Ignorare la sezione seguente, ovvero un approccio alternativo alla distribuzione del cluster.

Usare un certificato esistente per distribuire il cluster

In alternativa, è possibile usare un certificato di Azure Key Vault esistente per distribuire il cluster di test. A tale scopo, è necessario ottenere riferimenti all'insieme di credenziali delle chiavi e all'identificazione personale del certificato.

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

Successivamente, designare un nome di gruppo di risorse per il cluster e impostare i percorsi templateFilePath e parameterFilePath:

Nota

Il gruppo di risorse designato deve già esistere e trovarsi nella stessa area dell'insieme di credenziali delle chiavi.

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

Eseguire infine il comando seguente per distribuire il cluster di test iniziale:

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

Connettersi al nuovo cluster e controllarne lo stato di integrità

Connettersi al cluster e assicurarsi che tutti e cinque i relativi nodi siano integri (sostituire le variabili clusterName e thumb con i propri valori):

# 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

A questo punto, è possibile iniziare la procedura di aggiornamento.

Distribuire un nuovo tipo di nodo non primario con un set di scalabilità aggiornato

Per aggiornare (dimensionare verticalmente) un tipo di nodo, è prima necessario distribuire un nuovo tipo di nodo supportato da un nuovo set di scalabilità e risorse di supporto. Il nuovo set di scalabilità verrà contrassegnato come non primario (isPrimary: false), proprio come il set di scalabilità originale. Per aumentare le prestazioni di un tipo di nodo primario, vedere Aumentare le prestazioni di un tipo di nodo primario del cluster di Service Fabric. Le risorse create nella sezione seguente diventeranno infine il nuovo tipo di nodo nel cluster e le risorse del tipo di nodo originale verranno eliminate.

Aggiornare il modello di cluster con il set di scalabilità aggiornato

Di seguito sono riportate le modifiche sezione per sezione del modello di distribuzione del cluster originale per l'aggiunta di un nuovo tipo di nodo e risorse di supporto.

La maggior parte delle modifiche necessarie per questo passaggio è già stata apportata nel file modello Step1-AddPrimaryNodeType.json. Tuttavia, è necessario apportare una modifica aggiuntiva in modo che il file modello funzioni per i tipi di nodo non primari. Le sezioni seguenti illustrano in dettaglio queste modifiche e le chiamate verranno effettuate quando è necessario apportare una modifica.

Nota

Assicurarsi di usare nomi univoci dal tipo di nodo originale, dal set di scalabilità, dal servizio di bilanciamento del carico, dall'indirizzo IP pubblico e dalla subnet del tipo di nodo non primario originale, perché queste risorse verranno eliminate in un passaggio successivo del processo.

Creare una nuova subnet nella rete virtuale esistente

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

Creare un nuovo indirizzo IP pubblico con domainNameLabel univoco

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

Creare un nuovo servizio di bilanciamento del carico per l'indirizzo IP pubblico

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

Creare un nuovo set di scalabilità di macchine virtuali (con SKU di macchina virtuale e sistema operativo aggiornati)

Riferimento al tipo di nodo

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

SKU di VM

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

SKU sistema operativo

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

Assicurarsi inoltre di includere eventuali estensioni aggiuntive necessarie per il carico di lavoro.

Aggiungere un nuovo tipo di nodo non primario al cluster

Ora che il nuovo tipo di nodo (vmNodeType1Name) ha nome, subnet, IP, servizio di bilanciamento del carico e set di scalabilità propri, può riutilizzare tutte le altre variabili dal tipo di nodo originale ( ad esempio nt0applicationEndPort, nt0applicationStartPorte nt0fabricTcpGatewayPort).

Nel file di modello esistente il parametro isPrimary è impostato su true per la guida Aumentare le prestazioni di un tipo di nodo primario del cluster di Service Fabric. Modificare isPrimary in false per il tipo di nodo non primario:

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

Dopo aver implementato tutte le modifiche apportate ai file di modello e parametri, passare alla sezione successiva per acquisire i riferimenti a Key Vault e distribuire gli aggiornamenti nel cluster.

Ottenere i riferimenti a Key Vault

Per distribuire la configurazione aggiornata, sono necessari diversi riferimenti al certificato del cluster archiviato nell'insieme di credenziali delle chiavi. Il modo più semplice per trovare questi valori è tramite il portale di Azure. Saranno necessari gli elementi seguenti:

URL dell'insieme di credenziali delle chiavi del certificato del cluster. Nell'insieme di credenziali delle chiavi nel portale di Azure selezionare Certificati>certificato desiderato>Identificatore segreto:
```
$certUrlValue="https://sftestupgradegroup.vault.azure.net/secrets/sftestupgradegroup20200309235308/dac0e7b7f9d4414984ccaa72bfb2ea39"
```
Identificazione personale del certificato del cluster. Probabilmente si dispone già di questo valore se si è connessi al cluster iniziale per verificarne lo stato di integrità. Dallo stesso pannello del certificato (Certificati>certificato desiderato) nel portale di Azure copiare l'identificazione personale SHA-509 SHA-1 (in cifre esadecimali):
```
$thumb = "BB796AA33BD9767E7DA27FE5182CF8FDEE714A70"
```

ID risorsa dell'insieme di credenziali delle chiavi. Nell'insieme di credenziali delle chiavi nel portale di Azure selezionare Proprietà>ID risorsa:

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

Distribuire il modello aggiornato

Modificare templateFilePath in base alle esigenze ed eseguire il comando seguente:

# 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

Al termine della distribuzione, controllare di nuovo l'integrità del cluster e assicurarsi che tutti i nodi in entrambi i tipi di nodo siano integri.

Get-ServiceFabricClusterHealth

Eseguire la migrazione dei carichi di lavoro al nuovo tipo di nodo

Attendere che tutte le applicazioni vengano spostate nel nuovo tipo di nodo e siano integre.

Disabilitare i nodi nel set di scalabilità del tipo di nodo originale

Dopo aver eseguito la migrazione di tutti i nodi di inizializzazione al nuovo set di scalabilità, è possibile disabilitare i nodi del set di scalabilità originale.

# 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
  }
}

Usare Service Fabric Explorer per monitorare l'avanzamento dei nodi nel set di scalabilità originale da Disabilitazione allo stato Disabilitato. Attendere che tutti i nodi raggiungano lo stato Disabilitato.

Arrestare i dati nei nodi disabilitati

È ora possibile arrestare i dati nei nodi disabilitati.

# 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
  }
}

Rimuovere il tipo di nodo originale e pulire le risorse

È possibile rimuovere il tipo di nodo originale e le risorse associate per concludere la procedura di ridimensionamento verticale.

Rimuovere il set di scalabilità originale

Rimuovere prima di tutto il set di scalabilità di backup del tipo di nodo.

$scaleSetName = "nt0vm"
$scaleSetResourceType = "Microsoft.Compute/virtualMachineScaleSets"
Remove-AzResource -ResourceName $scaleSetName -ResourceType $scaleSetResourceType -ResourceGroupName $resourceGroupName -Force

Eliminare gli indirizzi IP originali e le risorse del servizio di bilanciamento del carico

È ora possibile eliminare l'IP originale e le risorse di bilanciamento del carico. In questo passaggio si aggiornerà anche il nome DNS.

Nota

Questo passaggio è facoltativo se si usa già un indirizzo IP pubblico Standard e un servizio di bilanciamento del carico. In questo caso è possibile avere più set di scalabilità/tipi di nodo nello stesso servizio di bilanciamento del carico. Eseguire i comandi seguenti, modificando il valore $lbname in base alle esigenze.

# 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

Rimuovere lo stato del nodo dal tipo di nodo originale

I nodi del tipo di nodo originale visualizzeranno ora Errore per lo Stato di integrità. Rimuovere lo stato del nodo dal 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 dovrebbe ora riflettere solo i cinque nodi del nuovo tipo di nodo (nt1vm), tutti con valori dello stato di integrità OK. La correzione verrà eseguita successivamente aggiornando il modello in modo da riflettere le modifiche più recenti e la ridistribuzione.

Aggiornare il modello di distribuzione in modo che rifletta il nuovo tipo di nodo non primario con scalabilità orizzontale

La maggior parte delle modifiche necessarie per questo passaggio è già stata apportata nel file modello Step3-CleanupOriginalPrimaryNodeType.json. Tuttavia, è necessario apportare una modifica aggiuntiva in modo che il file modello funzioni per i tipi di nodo non primari. Le sezioni seguenti illustrano in dettaglio queste modifiche e le chiamate verranno effettuate quando è necessario apportare una modifica.

Aggiornare l'endpoint di gestione del cluster

Aggiornare il valore managementEndpoint del cluster nel modello di distribuzione per fare riferimento al nuovo IP (aggiornando vmNodeType0Name con vmNodeType1Name).

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

Rimuovere il riferimento al tipo di nodo originale

Rimuovere il riferimento al tipo di nodo originale dalla risorsa di Service Fabric nel modello di distribuzione.

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

Configurare i criteri di integrità per ignorare gli errori esistenti

Solo per i cluster Silver e con durabilità superiore, aggiornare la risorsa cluster nel modello e configurare i criteri di integrità per ignorare l'integrità dell'applicazione fabric:/System aggiungendo applicationDeltaHealthPolicies nelle proprietà delle risorse del cluster, come indicato di seguito. I criteri seguenti ignorano gli errori esistenti, ma non consentono nuovi errori di integrità.

"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 
           } 
       } 
   } 
 } 
}

Rimuovere le risorse di supporto per il tipo di nodo originale

Rimuovere tutte le altre risorse correlate al tipo di nodo originale dal modello di Resource Manager e dal file dei parametri. Eliminare quanto segue:

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

Distribuire il modello finalizzato

Distribuire infine il modello di Azure Resource Manager modificato.

# 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

Questo passaggio richiederà un po' di tempo, in genere fino a due ore. L'aggiornamento modificherà le impostazioni a InfrastructureService; pertanto, è necessario un riavvio del nodo. In questo caso, forceRestart viene ignorato. Il parametro upgradeReplicaSetCheckTimeout specifica il tempo massimo in cui Service Fabric attende che una partizione sia in uno stato sicuro, se non lo è già. Dopo aver superato i controlli di sicurezza per tutte le partizioni in un nodo, Service Fabric procederà con l'aggiornamento in tale nodo. Il valore del parametro upgradeTimeout può essere ridotto a 6 ore, ma per garantire la massima sicurezza è consigliabile usare 12 ore.

Al termine della distribuzione, verificare nel portale di Azure che lo stato della risorsa di Service Fabric sia Pronto. Verificare che sia possibile raggiungere il nuovo endpoint di Service Fabric Explorer, lo stato di integrità del cluster sia OK e tutte le applicazioni distribuite funzionino correttamente.

Con questa operazione, è stato dimensionato verticalmente un tipo di nodo non primario del cluster.

Passaggi successivi

Informazioni su come aggiungere un tipo di nodo a un cluster
Informazioni sulla scalabilità delle applicazioni.
Ridimensionamento orizzontale di un cluster di Azure.
Ridimensionamento di un cluster di Azure a livello di codice tramite l'SDK di calcolo di Azure Fluent.
Ridimensionamento orizzontale di un cluster autonomo.

Condividi tramite

Aumentare le prestazioni di un tipo di nodo non primario del cluster di Service Fabric

Configurare il cluster di test

Generare un certificato autofirmato e distribuire il cluster

Usare un certificato esistente per distribuire il cluster

Connettersi al nuovo cluster e controllarne lo stato di integrità

Distribuire un nuovo tipo di nodo non primario con un set di scalabilità aggiornato

Aggiornare il modello di cluster con il set di scalabilità aggiornato

Creare una nuova subnet nella rete virtuale esistente

Creare un nuovo indirizzo IP pubblico con domainNameLabel univoco

Creare un nuovo servizio di bilanciamento del carico per l'indirizzo IP pubblico

Creare un nuovo set di scalabilità di macchine virtuali (con SKU di macchina virtuale e sistema operativo aggiornati)

Aggiungere un nuovo tipo di nodo non primario al cluster

Ottenere i riferimenti a Key Vault

Distribuire il modello aggiornato

Eseguire la migrazione dei carichi di lavoro al nuovo tipo di nodo

Disabilitare i nodi nel set di scalabilità del tipo di nodo originale

Arrestare i dati nei nodi disabilitati

Rimuovere il tipo di nodo originale e pulire le risorse

Rimuovere il set di scalabilità originale

Eliminare gli indirizzi IP originali e le risorse del servizio di bilanciamento del carico

Rimuovere lo stato del nodo dal tipo di nodo originale

Aggiornare il modello di distribuzione in modo che rifletta il nuovo tipo di nodo non primario con scalabilità orizzontale

Aggiornare l'endpoint di gestione del cluster

Rimuovere il riferimento al tipo di nodo originale

Configurare i criteri di integrità per ignorare gli errori esistenti

Rimuovere le risorse di supporto per il tipo di nodo originale

Distribuire il modello finalizzato

Passaggi successivi

Commenti e suggerimenti

Risorse aggiuntive