Skala upp en primär nodtyp för Service Fabric-klustret

Artikel
08/25/2024

Den här artikeln beskriver hur du skalar upp en primär nodtyp för Service Fabric-kluster med minimal stilleståndstid. SKU-uppgraderingar på plats stöds inte på Service Fabric-klusternoder, eftersom sådana åtgärder kan innebära data- och tillgänglighetsförluster. Den säkraste, mest tillförlitliga och rekommenderade metoden för att skala upp en Service Fabric-nodtyp är att:

Lägg till en ny nodtyp i Service Fabric-klustret, som backas upp av din uppgraderade (eller ändrade) SKU och konfiguration av vm-skalningsuppsättningar. Det här steget omfattar även att konfigurera en ny lastbalanserare, ett undernät och en offentlig IP-adress för skalningsuppsättningen.
När både de ursprungliga och uppgraderade skalningsuppsättningarna körs sida vid sida inaktiverar du de ursprungliga nodinstanserna en i taget så att systemtjänsterna (eller replikerna av tillståndskänsliga tjänster) migreras till den nya skalningsuppsättningen.
Kontrollera att klustret och de nya noderna är felfria och ta sedan bort den ursprungliga skalningsuppsättningen (och relaterade resurser) och nodtillståndet för de borttagna noderna.

Följande vägleder dig genom processen för att uppdatera vm-storleken och operativsystemet för virtuella datorer av primär nodtyp för ett exempelkluster med silverhållbarhet, som backas upp av en enda skalningsuppsättning med fem noder. Vi uppgraderar den primära nodtypen:

Från VM-storlek Standard_D2_V2 till Standard D4_V2 och
Från operativsystemet Windows Server 2019 Datacenter till Windows Server 2022 Datacenter.

Varning

Innan du provar den här proceduren i ett produktionskluster rekommenderar vi att du studerar exempelmallarna och verifierar processen mot ett testkluster. Klustret kan också vara otillgängligt under en kort tidsperiod.

Försök inte skala upp en primär nodtyp om klusterstatusen inte är felfri, eftersom detta endast destabiliserar klustret ytterligare.

De stegvisa Azure-distributionsmallar som vi ska använda för att slutföra det här exempeluppgraderingsscenariot är tillgängliga på GitHub.

Konfigurera testklustret

Nu ska vi konfigurera det första Service Fabric-testklustret. Ladda först ned de Azure Resource Manager-exempelmallar som vi ska använda för att slutföra det här scenariot.

Logga sedan in på ditt Azure-konto.

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

Öppna sedan filen parameters.json och uppdatera värdet för clusterName till något unikt (i Azure).

Följande kommandon vägleder dig genom att generera ett nytt självsignerat certifikat och distribuera testklustret. Om du redan har ett certifikat som du vill använda går du vidare till Använd ett befintligt certifikat för att distribuera klustret.

Generera ett självsignerat certifikat och distribuera klustret

Tilldela först de variabler som du behöver för distribution av Service Fabric-kluster. Justera värdena för resourceGroupName, certSubjectName, parameterFilePathoch templateFilePath för ditt specifika konto och din miljö:

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

Kommentar

Kontrollera att platsen certOutputFolder finns på den lokala datorn innan du kör kommandot för att distribuera ett nytt Service Fabric-kluster.

Distribuera sedan Service Fabric-testklustret:

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

När distributionen är klar letar du upp pfx-filen ($certPfx) på den lokala datorn och importerar den till certifikatarkivet:

cd c:\certificates
$certPfx = ".\sftestupgradegroup20200312121003.pfx"

Import-PfxCertificate `
     -FilePath $certPfx `
     -CertStoreLocation Cert:\CurrentUser\My `
     -Password (ConvertTo-SecureString Password!1 -AsPlainText -Force)

Åtgärden returnerar certifikatets tumavtryck, som du nu kan använda för att ansluta till det nya klustret och kontrollera dess hälsostatus. (Hoppa över följande avsnitt, som är en alternativ metod för klusterdistribution.)

Använda ett befintligt certifikat för att distribuera klustret

Alternativt kan du använda ett befintligt Azure Key Vault-certifikat för att distribuera testklustret. För att göra detta måste du hämta referenser till ditt Key Vault och certifikatets tumavtryck.

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

Ange sedan ett resursgruppsnamn för klustret och ange templateFilePath platserna och parameterFilePath :

Kommentar

Den avsedda resursgruppen måste redan finnas och finnas i samma region som ditt Key Vault.

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

Kör slutligen följande kommando för att distribuera det första testklustret:

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

Anslut till det nya klustret och kontrollera hälsostatusen

Anslut till klustret och se till att alla fem noderna är felfria (ersätt variablerna clusterName och thumb med dina egna värden):

# 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

Nu är vi redo att påbörja uppgraderingsproceduren.

Distribuera en ny primär nodtyp med uppgraderad skalningsuppsättning

För att kunna uppgradera (lodrätt skala) en nodtyp måste vi först distribuera en ny nodtyp som backas upp av en ny skalningsuppsättning och stödresurser. Den nya skalningsuppsättningen markeras som primär (isPrimary: true), precis som den ursprungliga skalningsuppsättningen. Om du vill skala upp en icke-primär nodtyp kan du läsa Skala upp ett Service Fabric-kluster av icke-primär nodtyp. Resurserna som skapas i följande avsnitt blir i slutändan den nya primära nodtypen i klustret och de ursprungliga resurserna av primär nodtyp tas bort.

Uppdatera klustermallen med den uppgraderade skalningsuppsättningen

Här följer avsnitt för avsnitt-ändringar av den ursprungliga klusterdistributionsmallen för att lägga till en ny primär nodtyp och stödresurser.

De nödvändiga ändringarna för det här steget har redan gjorts åt dig i Step1-AddPrimaryNodeType.json-mallfilen , och följande förklarar dessa ändringar i detalj. Om du vill kan du hoppa över förklaringen och fortsätta att hämta dina Key Vault-referenser och distribuera den uppdaterade mallen som lägger till en ny primär nodtyp i klustret.

Kommentar

Se till att du använder namn som är unika från den ursprungliga nodtypen, skalningsuppsättningen, lastbalanseraren, den offentliga IP-adressen och undernätet av den ursprungliga primära nodtypen, eftersom dessa resurser tas bort i ett senare steg i processen.

Skapa ett nytt undernät i det befintliga virtuella nätverket

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

Skapa en ny offentlig IP-adress med en unik domainNameLabel

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

Skapa en ny lastbalanserare för den offentliga IP-adressen

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

Skapa en ny VM-skalningsuppsättning (med uppgraderade vm- och OS-SKU:er)

Referens för nodtyp

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

VM-SKU

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

OS SKU

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

Om du ändrar OS SKU i ett Linux-kluster

I Windows-kluster är värdet för egenskapen vmImage "Windows" medan värdet för samma egenskap för Linux-klustret är namnet på os-avbildningen som används. Till exempel – Ubuntu20_04(använd det senaste vm-avbildningsnamnet).

Om du ändrar VM-avbildningen (OS SKU) i ett Linux-kluster uppdaterar du vmImage-inställningen även på Service Fabric-klusterresursen.

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

Obs! Exempel på newVmImageName: Ubuntu20_04

Du kan också uppdatera klusterresursen med hjälp av följande PowerShell-kommando:

# 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

Se också till att du inkluderar eventuella ytterligare tillägg som krävs för din arbetsbelastning.

Lägga till en ny primär nodtyp i klustret

Nu när den nya nodtypen (vmNodeType1Name) har sitt eget namn, undernät, IP, lastbalanserare och skalningsuppsättning kan den återanvända alla andra variabler från den ursprungliga nodtypen (till exempel nt0applicationEndPort, nt0applicationStartPortoch 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')]"

När du har implementerat alla ändringar i mall- och parameterfilerna fortsätter du till nästa avsnitt för att hämta dina Key Vault-referenser och distribuera uppdateringarna till klustret.

Hämta dina Key Vault-referenser

För att distribuera den uppdaterade konfigurationen behöver du flera referenser till klustercertifikatet som lagras i ditt Key Vault. Det enklaste sättet att hitta dessa värden är via Azure-portalen. Du måste:

Key Vault-URL:en för ditt klustercertifikat. Från Key Vault i Azure-portalen väljer du Certifikat>Din önskade certifikathemlighetsidentifierare:>
```
$certUrlValue="https://sftestupgradegroup.vault.azure.net/secrets/sftestupgradegroup20200309235308/dac0e7b7f9d4414984ccaa72bfb2ea39"
```
Tumavtrycket för klustercertifikatet. (Du har förmodligen redan certifikatet om du är ansluten till det första klustret för att kontrollera dess hälsostatus.) Kopiera X.509 SHA-1 Tumavtryck (i hex) från samma certifikatblad (certifikat>som önskat certifikat) i Azure-portalen:
```
$thumb = "BB796AA33BD9767E7DA27FE5182CF8FDEE714A70"
```

Resurs-ID:t för ditt Nyckelvalv. Från Key Vault i Azure-portalen väljer du Egenskaper>Resurs-ID:

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

Distribuera den uppdaterade mallen

Justera efter templateFilePath behov och kör följande kommando:

# 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

När distributionen är klar kontrollerar du klusterhälsan igen och ser till att alla noder på båda nodtyperna är felfria.

Get-ServiceFabricClusterHealth

Migrera startnoder till den nya nodtypen

Nu är vi redo att uppdatera den ursprungliga nodtypen som icke-primär och börja inaktivera noderna. När noderna inaktiveras migreras klustrets systemtjänster och startnoder till den nya skalningsuppsättningen.

Avmarkera den ursprungliga nodtypen som primär

Ta först bort beteckningen isPrimary i mallen från den ursprungliga nodtypen.

{
    "isPrimary": false,
}

Distribuera sedan mallen med uppdateringen. Den här distributionen initierar migreringen av startnoder till den nya skalningsuppsättningen.

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

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

Kommentar

Det tar lite tid att slutföra migreringen av startnoden till den nya skalningsuppsättningen. För att garantera datakonsekvens kan endast en startnod ändras i taget. Varje ändring av startnoden kräver en klusteruppdatering. att ersätta en startnod kräver därför två klusteruppgraderingar (en vardera för nodtillägg och borttagning). Om du uppgraderar de fem startnoderna i det här exempelscenariot resulterar det i tio klusteruppgraderingar.

Använd Service Fabric Explorer för att övervaka migreringen av startnoder till den nya skalningsuppsättningen. Noderna i den ursprungliga nodtypen (nt0vm) bör alla vara falska i kolumnen Is Seed Node och nodtypen (nt1vm) ska vara sanna.

Inaktivera noderna i den ursprungliga skalningsuppsättningen för nodtyp

När alla startnoder har migrerats till den nya skalningsuppsättningen kan du inaktivera noderna i den ursprungliga skalningsuppsättningen.

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

Använd Service Fabric Explorer för att övervaka förloppet för noder i den ursprungliga skalningsuppsättningen från Inaktivera till Inaktiverad status.

Service Fabric Explorer som visar status för inaktiverade noder

För silver- och guldhållbarhet går vissa noder i inaktiverat tillstånd, medan andra kan förbli i inaktiverat tillstånd. I Service Fabric Explorer kontrollerar du fliken Information för noder i inaktiverat tillstånd. Om de visar en väntande säkerhetskontroll av typen EnsurePartitionQuorem (säkerställa kvorum för infrastrukturtjänstpartitioner) är det säkert att fortsätta.

Du kan fortsätta med att stoppa data och ta bort noder som fastnat i statusen Inaktivera om de visar en väntande säkerhetskontroll av typen

Om klustret är bronsbeständigt väntar du på att alla noder ska nå inaktiverat tillstånd.

Stoppa data på inaktiverade noder

Nu kan du stoppa data på de inaktiverade noderna.

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

Ta bort den ursprungliga nodtypen och rensa dess resurser

Vi är redo att ta bort den ursprungliga nodtypen och dess associerade resurser för att slutföra den lodräta skalningsproceduren.

Ta bort den ursprungliga skalningsuppsättningen

Ta först bort nodtypens backningsskalningsuppsättning.

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

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

Ta bort de ursprungliga IP- och lastbalanseringsresurserna

Nu kan du ta bort den ursprungliga IP-adressen och lastbalanserarens resurser. I det här steget uppdaterar du även DNS-namnet.

Kommentar

Det här steget är valfritt om du redan använder en offentlig IP-adress för Standard SKU och lastbalanserare. I det här fallet kan du ha flera skalningsuppsättningar/nodtyper under samma lastbalanserare.

Kör följande kommandon och $lbname ändra värdet efter behov.

# 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

Ta bort nodtillstånd från den ursprungliga nodtypen

De ursprungliga nodtyperna visar nu fel för hälsotillståndet. Ta bort nodtillståndet från klustret.

# 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 bör nu endast återspegla de fem noderna i den nya nodtypen (nt1vm), alla med hälsotillståndsvärdena OK. Ditt klusters hälsotillstånd visar fortfarande fel. Vi kommer att åtgärda det härnäst genom att uppdatera mallen så att den återspeglar de senaste ändringarna och omdistribueringen.

Uppdatera distributionsmallen så att den återspeglar den nyligen uppskalade primära nodtypen

De nödvändiga ändringarna för det här steget har redan gjorts åt dig i Step3-CleanupOriginalPrimaryNodeType.json mallfil, och följande avsnitt förklarar dessa malländringar i detalj. Om du vill kan du hoppa över förklaringen och fortsätta att distribuera den uppdaterade mallen och slutföra självstudien.

Uppdatera slutpunkten för klusterhantering

Uppdatera klustret managementEndpoint i distributionsmallen för att referera till den nya IP-adressen (genom att uppdatera vmNodeType0Name med vmNodeType1Name).

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

Ta bort referensen för den ursprungliga nodtypen

Ta bort den ursprungliga nodtypsreferensen från Service Fabric-resursen i distributionsmallen:

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

Konfigurera hälsoprinciper för att ignorera befintliga fel

Endast för Silver- och högre hållbarhetskluster uppdaterar du klusterresursen i mallen och konfigurerar hälsoprinciper för att ignorera fabric:/System programmets hälsa genom att lägga till applicationDeltaHealthPolicies under klusterresursegenskaper enligt nedan. Principen nedan ignorerar befintliga fel men tillåter inte nya hälsofel.

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

Ta bort stödresurser för den ursprungliga nodtypen

Ta bort alla andra resurser som är relaterade till den ursprungliga nodtypen från ARM-mallen och parameterfilen. Ta bort följande:

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

Distribuera den färdiga mallen

Distribuera slutligen den ändrade Azure Resource Manager-mallen.

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

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

Kommentar

Det här steget tar en stund, vanligtvis upp till två timmar.

Uppgraderingen ändrar inställningarna till InfrastructureService. Därför krävs en omstart av noden. I det här fallet ignoreras forceRestart . Parametern upgradeReplicaSetCheckTimeout anger den maximala tid som Service Fabric väntar på att en partition ska vara i ett säkert tillstånd, om inte redan i ett säkert tillstånd. När säkerhetskontrollerna har passerat för alla partitioner på en nod fortsätter Service Fabric med uppgraderingen på den noden. Värdet för parametern upgradeTimeout kan minskas till 6 timmar, men för maximal säkerhet ska 12 timmar användas.

När distributionen har slutförts kontrollerar du i Azure-portalen att Service Fabric-resursstatusen är klar. Kontrollera att du kan nå den nya Service Fabric Explorer-slutpunkten, klustrets hälsotillstånd är OK och att alla distribuerade program fungerar korrekt.

Nu har du skalat en primär nodtyp i ett kluster lodrätt!

Nästa steg

Lär dig hur du lägger till en nodtyp i ett kluster
Lär dig mer om programmets skalbarhet.
Skala in eller ut ett Azure-kluster.
Skala ett Azure-kluster programmatiskt med hjälp av Fluent Azure Compute SDK.
Skala ett fristående kluster in eller ut.

Dela via

Skala upp en primär nodtyp för Service Fabric-klustret

Konfigurera testklustret

Generera ett självsignerat certifikat och distribuera klustret

Använda ett befintligt certifikat för att distribuera klustret

Anslut till det nya klustret och kontrollera hälsostatusen

Distribuera en ny primär nodtyp med uppgraderad skalningsuppsättning

Uppdatera klustermallen med den uppgraderade skalningsuppsättningen

Skapa ett nytt undernät i det befintliga virtuella nätverket

Skapa en ny offentlig IP-adress med en unik domainNameLabel

Skapa en ny lastbalanserare för den offentliga IP-adressen

Skapa en ny VM-skalningsuppsättning (med uppgraderade vm- och OS-SKU:er)

Om du ändrar OS SKU i ett Linux-kluster

Lägga till en ny primär nodtyp i klustret

Hämta dina Key Vault-referenser

Distribuera den uppdaterade mallen

Migrera startnoder till den nya nodtypen

Avmarkera den ursprungliga nodtypen som primär

Inaktivera noderna i den ursprungliga skalningsuppsättningen för nodtyp

Stoppa data på inaktiverade noder

Ta bort den ursprungliga nodtypen och rensa dess resurser

Ta bort den ursprungliga skalningsuppsättningen

Ta bort de ursprungliga IP- och lastbalanseringsresurserna

Ta bort nodtillstånd från den ursprungliga nodtypen

Uppdatera distributionsmallen så att den återspeglar den nyligen uppskalade primära nodtypen

Uppdatera slutpunkten för klusterhantering

Ta bort referensen för den ursprungliga nodtypen

Konfigurera hälsoprinciper för att ignorera befintliga fel

Ta bort stödresurser för den ursprungliga nodtypen

Distribuera den färdiga mallen

Nästa steg

Feedback

Ytterligare resurser