Share via

Hochskalieren eines nicht primären Knotentyps eines Service Fabric-Clusters

  • Artikel

Dieser Artikel beschreibt, wie Sie den nicht primären Knotentyp eines Service Fabric-Clusters mit minimalen Ausfallzeiten hochskalieren können. Direkte SKU-Upgrades auf Service Fabric-Clusterknoten werden nicht unterstützt, da solche Vorgänge potenziell Datenverluste und Verfügbarkeitsausfälle nach sich ziehen. Als sicherste und zuverlässigste Methode zum Hochskalieren eines Service Fabric-Knotentyps wird Folgendes empfohlen:

  1. Fügen Sie Ihrem Service Fabric-Cluster einen neuen Knotentyp hinzu, der durch die SKU und die Konfiguration der aktualisierten (oder geänderten) VM-Skalierungsgruppe unterstützt wird. Dieser Schritt umfasst auch das Einrichten eines neuen Load Balancers, Subnetzes und einer öffentlichen IP-Adresse für die Skalierungsgruppe.

  2. Sobald sowohl die ursprünglichen als auch die upgegradeten Skalierungsgruppen nebeneinander ausgeführt werden, migrieren Sie die Workloads durch Festlegen von Platzierungsbeschränkungen für Anwendungen auf den neuen Knotentyp.

  3. Überprüfen Sie, ob der Cluster fehlerfrei ist, und entfernen Sie dann die ursprüngliche Skalierungsgruppe (sowie in Beziehung stehende Ressourcen) und den Knotenzustand für die gelöschten Knoten.

Im folgenden wird Schritt für Schritt erläutert, wie Sie die VM-Größe und das Betriebssystem von VMs des nicht primären Knotentyps eines Beispielclusters mit Dauerhaftigkeit „Silber“ aktualisieren, die von einer einzelnen Skalierungsgruppe mit fünf Knoten, die als sekundärer Knotentyp verwendet werden, unterstützt werden. Der primäre Knotentyp mit Service Fabric-Systemdiensten bleibt unberührt. Sie aktualisieren den nicht primären Knotentyp:

  • Aus der VM-Größe Standard_D2_V2 in Standard D4_V2.
  • Aus dem VM-Betriebssystem Windows Server 2019 Datacenter in Windows Server 2022 Datacenter.

Warnung

Bevor Sie versuchen, diesen Vorgang für einen Produktionscluster auszuführen, sollten Sie sich die Beispielvorlagen ansehen und den Vorgang mithilfe eines Testclusters überprüfen.

Versuchen Sie nicht, eine Hochskalierungsprozedur für nicht primäre Knoten auszuführen, wenn der Cluster einen fehlerhaften Status aufweist. Dies würde die Stabilität des Clusters nur weiter gefährden. Wir verwenden die schrittweisen Azure-Bereitstellungsvorlagen, die in der Anleitung Hochskalieren des primären Knotentyps eines Service Fabric-Clusters genutzt werden. Wir ändern sie jedoch, sodass sie auch für nicht primäre Knotentypen funktionieren. Die Vorlagen sind auf GitHub zu finden.

Einrichten des Testclusters

Richten Sie zunächst Ihren Service Fabric-Testcluster ein. Laden Sie dazu die Azure Resource Manager-Beispielvorlagen herunter, die Sie für dieses Szenario benötigen.

Melden Sie sich anschließend bei Ihrem Azure-Konto an.

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

Öffnen Sie dann die Datei parameters.json, und aktualisieren Sie den Wert für clusterName in einen eindeutigen Wert (in Azure).

Mithilfe der folgenden Befehle können Sie ein neues selbstsigniertes Zertifikat erstellen und das Testcluster bereitstellen. Wenn Sie bereits über ein Zertifikat verfügen, das Sie verwenden möchten, können Sie direkt mit dem Abschnitt Verwenden eines bestehenden Zertifikats für die Clusterbereitstellung fortfahren.

Generieren eines selbstsignierten Zertifikats und Bereitstellen des Clusters

Weisen Sie zunächst die Variablen zu, die Sie für die Bereitstellung des Service Fabric-Clusters benötigen. Passen Sie die Werte für resourceGroupName, certSubjectName, parameterFilePath und templateFilePath an Ihr spezifisches Konto und Ihre Umgebung an:

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

Hinweis

Stellen Sie sicher, dass der Speicherort certOutputFolder auf Ihrem lokalen Computer vorhanden ist, bevor Sie den Befehl zum Bereitstellen eines neuen Service Fabric-Clusters ausführen. Stellen Sie nun den Service Fabric-Testcluster bereit:

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

Nachdem die Bereitstellung abgeschlossen ist, suchen Sie die .pfx-Datei ($certPfx) auf Ihrem lokalen Computer, und importieren Sie sie in Ihren Zertifikatspeicher:

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

Bei diesem Vorgang wird der Zertifikatfingerabdruck zurückgegeben, mit dem Sie nun eine Verbindung mit dem neuen Cluster herstellen und dessen Integritätsstatus überprüfen können. (Sie können den folgenden Abschnitt überspringen, denn darin wird ein alternativer Ansatz für die Clusterbereitstellung beschrieben.)

Verwenden eines bestehenden Zertifikats für die Clusterbereitstellung

Der Testcluster lässt sich alternativ mithilfe eines vorhandenen Azure Key Vault-Zertifikats bereitstellen. Dazu müssen Sie die Verweise auf Ihren Key Vault-Tresor und den Zertifikatfingerabdruck abrufen.

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

Legen Sie nun einen Ressourcengruppennamen für den Cluster fest, und legen Sie die Speicherorte templateFilePath und parameterFilePath fest:

Hinweis

Die bereitgestellte Ressourcengruppe muss bereits vorhanden sein und sich in derselben Region wie Ihr Key Vault-Tresor befinden.

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

Führen Sie abschließend den folgenden Befehl aus, um den anfangs erstellten Testcluster bereitzustellen:

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

Herstellen einer Verbindung zu dem neuen Cluster und Überprüfen des Integritätsstatus

Stellen Sie eine Verbindung mit dem Cluster her, und stellen Sie sicher, dass alle fünf Knoten fehlerfrei sind (ersetzen Sie die Variablen clusterName und thumb durch Ihre eigenen Werte):

# 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

Damit sind Sie bereit dazu, das Upgrade zu beginnen.

Bereitstellen eines neuen nicht primären Knotentyps mit der aktualisierten Skalierungsgruppe

Um einen Knotentyp zu aktualisieren (vertikal zu skalieren), müssen Sie zunächst einen neuen Knotentyp bereitstellen, der durch eine neue Skalierungsgruppe und unterstützende Ressourcen unterstützt wird. Die neue Skalierungsgruppe wird als nicht primär gekennzeichnet (isPrimary: false), ebenso wie die ursprüngliche Skalierungsgruppe. Wenn Sie einen primären Knotentyp hochskalieren möchten, lesen Sie Hochskalieren eines primären Knotentyps eines Service Fabric-Clusters. Die im folgenden Abschnitt erstellten Ressourcen werden schließlich zum neuen Knotentyp in Ihrem Cluster, und die ursprünglichen Knotentypressourcen werden gelöscht.

Aktualisieren der Clustervorlage mit der upgegradeten Skalierungsgruppe

Im Folgenden finden Sie die abschnittsweisen Änderungen der ursprünglichen Vorlage für die Bereitstellung von Clustern zum Hinzufügen eines neuen Knotentyps und unterstützender Ressourcen.

Die meisten erforderlichen Änderungen für diesen Schritt wurden in der Datei Step1-AddPrimaryNodeType.json bereits vorgenommen. Eine zusätzliche Änderung muss jedoch vorgenommen werden, sodass die Vorlagendatei für nicht primäre Knotentypen funktioniert. In den folgenden Abschnitten werden diese Änderungen ausführlich erläutert, und wenn Sie eine Änderung vornehmen müssen, werden Sie dazu aufgefordert.

Hinweis

Stellen Sie sicher, dass Sie Namen verwenden, die sich eindeutig vom ursprünglichen Knotentyp, der Skalierungsgruppe, dem Load Balancer, der öffentlichen IP-Adresse und dem Subnetz des ursprünglichen nicht primären Knotentyps unterscheiden, da diese Ressourcen in einem späteren Schritt des Prozesses gelöscht werden.

Erstellen eines neuen Subnetzes im vorhandenen virtuellen Netzwerk

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

Erstellen einer neuen öffentlichen IP-Adresse mit einem eindeutigen domainNameLabel-Element

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

Erstellen eines neuen Load Balancers für die öffentliche IP-Adresse

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

Erstellen einer neuen VM-Skalierungsgruppe (mit aktualisierter VM und aktualisierten Betriebssystem-SKUs)

Knotentypverweis

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

VM-SKU

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

Betriebssystem-SKU

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

Stellen Sie sicher, dass alle zusätzlichen Erweiterungen einbezogen werden, die für Ihre Workload erforderlich sind.

Hinzufügen eines neuen nicht primären Knotentyps zum Cluster

Nachdem der neue Knotentyp (vmNodeType1Name) einen eigenen Namen, ein Subnetz, eine IP-Adresse, einen Load Balancer und eine Skalierungsgruppe besitzt, kann er alle anderen Variablen aus dem ursprünglichen Knotentyp (z. B. nt0applicationEndPort, nt0applicationStartPort und nt0fabricTcpGatewayPort) wiederverwenden.

Zur Verwendung in der Anleitung Hochskalieren des primären Knotentyps eines Service Fabric-Clusters ist der Parameter isPrimary in der vorhandenen Vorlagendatei auf true festgelegt. Ändern Sie isPrimary zu false für Ihren nicht primären Knotentyp:

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

Wenn Sie alle Änderungen in der Vorlagen- und der Parameterdatei implementiert haben, fahren Sie mit dem nächsten Abschnitt fort, um Ihre Key Vault-Verweise abzurufen und die Updates in Ihrem Cluster bereitzustellen.

Abrufen Ihrer Key Vault-Verweise

Zum Bereitstellen der aktualisierten Konfiguration benötigen Sie mehrere Verweise auf das Clusterzertifikat, das in Ihrem Key Vault gespeichert ist. Dies lässt sich am einfachsten im Azure-Portal durchführen. Sie benötigen Folgendes:

  • Die Key Vault-URL Ihres Clusterzertifikats: Klicken Sie im Azure-Portal in Ihrem Key Vault-Tresor auf Zertifikate>Ihr gewünschtes Zertifikat>Geheimnis-ID:

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

  • Den Fingerabdruck Ihres Clusterzertifikats: (Wenn Sie eine Verbindung zum ursprünglichen Cluster hergestellt haben, um dessen Integritätsstatus zu überprüfen, verfügen Sie wahrscheinlich bereits über den Fingerabdruck.) Kopieren Sie im Azure-Portal auf demselben Zertifikatblatt (Zertifikate>Ihr gewünschtes Zertifikat) den Wert unter X.509 SHA-1 Thumbprint (in hex) (X.509-SHA-1-Fingerabdruck [hexadezimal]):

    $thumb = "BB796AA33BD9767E7DA27FE5182CF8FDEE714A70"

  • Die Ressourcen-ID Ihres Key Vault-Tresors: Klicken Sie im Azure-Portal in Ihrem Key Vault-Tresor auf Eigenschaften>Ressourcen-ID:

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

Bereitstellen der aktualisierten Vorlage

Passen Sie templateFilePath nach Bedarf an, und führen Sie den folgenden Befehl aus:

# 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

Überprüfen Sie nach Abschluss der Bereitstellung noch einmal die Clusterintegrität, und stellen Sie sicher, dass alle Knoten für beide Knotentypen fehlerfrei sind.

Get-ServiceFabricClusterHealth

Migrieren der Workloads zum neuen Knotentyp

Warten Sie, bis alle Anwendungen in den neuen Knotentyp verschoben wurden und fehlerfrei sind.

Deaktivieren der Knoten in der ursprünglichen Knotentyp-Skalierungsgruppe

Nachdem alle Startknoten zur neuen Skalierungsgruppe migriert wurden, können Sie die Knoten der ursprünglichen Skalierungsgruppe deaktivieren.

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

Verwenden Sie Service Fabric Explorer, um den Statuswechsel der Knoten in der ursprünglichen Skalierungsgruppe von Wird deaktiviert zu Deaktiviert zu überwachen. Warten Sie, bis alle Knoten den Status Deaktiviert erreicht haben.

Beenden von Daten auf den deaktivierten Knoten

Nun können Sie Daten auf den deaktivierten Knoten beenden.

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

Entfernen des ursprünglichen Knotentyps und Bereinigen seiner Ressourcen

Sie sind bereit, den ursprünglichen Knotentyp und die zugehörigen Ressourcen zu entfernen, um die vertikale Skalierung abzuschließen.

Entfernen der ursprünglichen Skalierungsgruppe

Entfernen Sie zuerst die sichernde Skalierungsgruppe des Knotentyps.

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

Löschen der ursprünglichen IP-Adresse und der Load Balancer-Ressourcen

Sie können nun die ursprüngliche IP-Adresse und die Load Balancer-Ressourcen löschen. In diesem Schritt aktualisieren Sie auch den DNS-Namen.

Hinweis

Dieser Schritt ist optional, wenn Sie bereits eine öffentliche IP-Adresse einer Standard-SKU und einen Load Balancer Standard verwenden. In diesem Fall können mehrere VM-Skalierungsgruppen/Knotentypen unter demselben Load Balancer vorhanden sein. Führen Sie die folgenden Befehle aus, und ändern Sie den Wert $lbname nach Bedarf.

# 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

Entfernen des Knotenstatus aus dem ursprünglichen Knotentyp

Die Knoten des ursprünglichen Knotentyps zeigen nun Fehler als ihren Integritätsstatus an. Entfernen Sie ihren Knotenstatus aus dem 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 sollte nun nur die fünf Knoten des neuen Knotentyps (nt1vm) mit Integritätsstatuswerten OK für alle Knoten anzeigen. Sie beheben dieses Problem nun, indem Sie die Vorlage so aktualisieren, dass sie die neuesten Änderungen berücksichtigt. Stellen Sie die Vorlage dann erneut bereit.

Aktualisieren der Bereitstellungsvorlage, damit sie den gerade skalierten nicht primären Knotentyp berücksichtigt

Die meisten erforderlichen Änderungen für diesen Schritt wurden in der Datei Step3-CleanupOriginalPrimaryNodeType.json bereits vorgenommen. Eine zusätzliche Änderung muss jedoch vorgenommen werden, sodass die Vorlagendatei für nicht primäre Knotentypen funktioniert. In den folgenden Abschnitten werden diese Änderungen ausführlich erläutert, und wenn Sie eine Änderung vornehmen müssen, werden Sie dazu aufgefordert.

Aktualisieren des Verwaltungsendpunkts des Clusters

Aktualisieren Sie den Cluster managementEndpoint in der Bereitstellungsvorlage, um auf die neue IP-Adresse zu verweisen (durch Aktualisieren von vmNodeType0Name in vmNodeType1Name).

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

Entfernen des ursprünglichen Knotentypverweises

Entfernen Sie den ursprünglichen Knotentypverweis aus der Service Fabric-Ressource in der Bereitstellungsvorlage.

Zur Verwendung in der Anleitung Hochskalieren des primären Knotentyps eines Service Fabric-Clusters ist der Parameter isPrimary in der vorhandenen Vorlagendatei auf true festgelegt. Ändern Sie isPrimary zu false für Ihren nicht primären Knotentyp:

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

Konfigurieren von Integritätsrichtlinien zum Ignorieren vorhandener Fehler

Nur für Cluster mit der Dauerhaftigkeit „Silber“ und höher aktualisieren Sie die Clusterressource in der Vorlage und konfigurieren die Integritätsrichtlinien so, dass der Zustand von fabric:/System ignoriert wird, indem Sie applicationDeltaHealthPolicies unter den Clusterressourceneigenschaften wie unten angegeben hinzufügen. Die folgende Richtlinie ignoriert vorhandene Fehler, lässt aber keine neuen Integritätsfehler zu.

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

Entfernen unterstützender Ressourcen für den ursprünglichen Knotentyp

Entfernen Sie alle anderen Ressourcen im Zusammenhang mit dem ursprünglichen Knotentyp aus der ARM-Vorlage und der Parameterdatei. Löschen Sie Folgendes:

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

Bereitstellen der fertigen Vorlage

Stellen Sie schließlich die geänderte Azure Resource Manager-Vorlage bereit.

# Deploy the updated template file
$templateFilePath = "C:\Step3-CleanupOriginalPrimaryNodeType"
New-AzResourceGroupDeployment `
    -ResourceGroupName $resourceGroupName `
    -TemplateFile $templateFilePath `
    -TemplateParameterFile $parameterFilePath `
    -CertificateThumbprint $thumb `
    -CertificateUrlValue $certUrlValue `
    -SourceVaultValue $sourceVaultValue `
    -Verbose

Hinweis

Dieser Schritt dauert eine Weile (in der Regel bis zu zwei Stunden). Durch dieses Upgrade ändern sich die Einstellungen für InfrastructureService. Daher ist ein Neustart des Knotens erforderlich. In diesem Fall wird forceRestart ignoriert. Der Parameter upgradeReplicaSetCheckTimeout gibt die maximale Zeit an, die Service Fabric wartet, bis sich eine Partition in einem sicheren Zustand befindet, sofern dies noch nicht der Fall ist. Sobald die Sicherheitsprüfungen für alle Partitionen eines Knotens absolviert sind, fährt Service Fabric mit dem Upgrade auf diesem Knoten fort. Der Wert für den Parameter upgradeTimeout kann auf 6 Stunden verkürzt werden, aber für maximale Sicherheit sollten 12 Stunden gewählt werden.

Nachdem die Bereitstellung abgeschlossen wurde, überprüfen Sie im Azure-Portal, ob der Status der Service Fabric-Ressource Bereit ist. Vergewissern Sie sich, dass Sie den neuen Service Fabric Explorer-Endpunkt erreichen können, dass der Integritätsstatus des Clusters den Wert OK aufweist und dass alle bereitgestellten Anwendungen ordnungsgemäß funktionieren.

Sie haben den nicht primären Knotentyp eines Clusters vertikal skaliert!

Nächste Schritte