Migrieren Ihres Service Fabric-Clusters zur Unterstützung von Verfügbarkeitszonen

Artikel
04/29/2024

In diesem Leitfaden wird beschrieben, wie Service Fabric-Cluster von der fehlenden Unterstützung von Verfügbarkeitszonen zur Unterstützung von Verfügbarkeitszonen migriert werden. Wir führen Sie durch die verschiedenen Optionen für die Migration. Ein Service Fabric-Cluster, der auf mehrere Verfügbarkeitszonen verteilt ist, stellt die Hochverfügbarkeit des Clusterzustands sicher.

Sie können sowohl verwaltete als auch nicht verwaltete Cluster migrieren. Beide Varianten werden in diesem Artikel beschrieben.

Bei nicht verwalteten Clustern werden zwei verschiedene Szenarien beschrieben:

Migrieren eines Clusters mit einem Lastenausgleich mit Standard-SKU und einer IP-Adressressource. Diese Konfiguration unterstützt Verfügbarkeitszonen ohne die Erstellung neuer Ressourcen.
Migrieren eines Clusters mit einem Lastenausgleich mit Basic-SKU und einer IP-Adressressource. Diese Konfiguration unterstützt keine Verfügbarkeitszonen und erfordert die Erstellung neuer Ressourcen.

Weitere Informationen finden Sie in den entsprechenden Abschnitten unter den einzelnen Überschriften für Ihr Service Fabric-Clusterszenario.

Hinweis

Der Vorteil, den primären Knotentyp über die Verfügbarkeitszonen hinweg zu verteilen, zeigt sich nur bei drei Zonen und nicht bei zwei Zonen. Dies gilt sowohl für verwaltete als auch für nicht verwaltete Cluster.

Beispielvorlagen finden Sie auf der Seite mit verfügbarkeitszonenübergreifenden Service Fabric-Vorlagen.

Voraussetzungen

Verwaltete Service Fabric-Cluster

Erforderlich:

Standard-SKU-Cluster
Drei Verfügbarkeitszonen in der Region.

Nicht verwaltete Service Fabric-Cluster

Erforderlich: nicht zutreffend.

Vorhandene Lastenausgleichsressource mit Standard-SKU und IP-Adressressource

Für dieses Szenario gelten keine Voraussetzungen, da davon ausgegangen wird, dass Sie über die erforderlichen Ressourcen verfügen.

Lastenausgleichsressource mit Basic-SKU und IP-Adressressource

Ein neuer Lastenausgleich mit Standard-SKU, der sich von Ihrem vorhandenen Lastenausgleich mit Standard-SKU unterscheidet
Eine neue IP-Adressressource mit Standard-SKU, die sich von Ihrer vorhandenen IP-Adressressource mit Basic-SKU unterscheidet

Hinweis

Es ist nicht möglich, ein Upgrade Ihrer vorhandenen Ressourcen von einer Basic-SKU auf eine Standard-SKU durchzuführen, daher sind neue Ressourcen erforderlich.

Anforderungen an Ausfallzeiten

Verwalteter Service Fabric-Cluster

Die Migration zu einer zonenresilienten Konfiguration kann zu einem kurzen Verlust der externen Konnektivität durch den Lastenausgleich führen, wirkt sich jedoch nicht auf die Clusterintegrität aus. Dieser Konnektivitätsverlust tritt auf, wenn eine neue öffentliche IP-Adresse erstellt werden muss, um Netzwerkresilienz gegen Zonenausfälle zu erzielen. Planen Sie die Migration entsprechend.

Nicht verwalteter Service Fabric-Cluster

Die Downtime für die Migration von nicht verwalteten Service Fabric-Clustern variieren je nach Anzahl der VMs und Upgradedomänen (UDs) in Ihrem Cluster. UDs sind logische Gruppierungen von VMs, die die Reihenfolge bestimmen, in der Upgrades auf die VMs in Ihrem Cluster gepusht werden. Die Downtime wird auch durch den Upgrademodus Ihres Clusters beeinflusst, der festlegt, wie Upgradeaufgaben für die UDs in Ihrem Cluster verarbeitet werden. Die sfZonalUpgradeMode-Eigenschaft, die den Upgrademodus steuert, wird in den folgenden Abschnitten ausführlicher behandelt.

Migration verwalteter Service Fabric-Cluster

Führen Sie die Schritte unter Migrieren verwalteter Service Fabric-Cluster zur Zonenresilienz aus.

Migrationsoptionen für nicht verwaltete Service Fabric-Cluster

Migrationsoption 1: Aktivieren mehrerer Verfügbarkeitszonen in einer einzelnen VM-Skalierungsgruppe

Anwendungsfall für diese Option

Mit dieser Lösung können die Benutzer drei Verfügbarkeitszonen in demselben Knotentyp umfassen. Dies ist die empfohlene Bereitstellungstopologie, da sie eine Bereitstellung über die Verfügbarkeitszonen hinweg ermöglicht und gleichzeitig eine einzelne VM-Skalierungsgruppe beibehält.

Eine vollständige Beispielvorlage ist auf GitHub verfügbar.

Sie sollten diese Option verwenden, wenn Sie über einen nicht verwalteten Service Fabric-Cluster mit Lastenausgleichs- und IP-Adressressourcen mit Standard-SKU verfügen, den Sie migrieren möchten. Wenn Ihr vorhandener nicht verwalteter Cluster über Ressourcen mit Basic-SKU verfügt, lesen Sie weiter unten unter der Migrationsoption bei einer Basic-SKU nach.

Migrieren Ihres nicht verwalteten Service Fabric-Clusters mit Lastenausgleichs- und IP-Adressressourcen mit Standard-SKU

So aktivieren Sie Zonen in einer VM-Skalierungsgruppe

Fügen Sie die folgenden drei Werte in die Ressource der VM-Skalierungsgruppe ein:

Der erste Wert ist die zones-Eigenschaft, die angibt, welche Verfügbarkeitszonen in der VM-Skalierungsgruppe vorhanden sind.
Der zweite Wert ist die Eigenschaft singlePlacementGroup, die auf true festgelegt werden muss. Die Skalierungsgruppe, die sich über drei Verfügbarkeitszonen erstreckt, kann selbst mit der Einstellung singlePlacementGroup = true auf bis zu 300 VMs hochskaliert werden.
Der dritte Wert ist zoneBalance, der einen strikten Zonenausgleich sicherstellt. Dieser Wert sollte auf true festgelegt werden. Dadurch wird sichergestellt, dass die zonenübergreifenden VM-Verteilungen nicht unausgeglichen sind. Beim Ausfall einer Zone verfügen die anderen Zonen also über genügend VMs für einen unterbrechungsfreien Betrieb des Clusters.

Ein Cluster mit einer unausgeglichenen VM-Verteilung ist in einem Szenario mit Zonenausfall möglicherweise nicht länger verfügbar, da diese Zone gegebenenfalls über die meisten VMs verfügt. Eine unausgeglichene zonenübergreifende VM-Verteilung führt außerdem zu Problemen bei der Dienstplatzierung sowie dazu, dass Infrastrukturupdates nicht erfolgreich abgeschlossen werden können. Weitere Informationen finden Sie unter zoneBalancing.

Die Außerkraftsetzungen FaultDomain und UpgradeDomain müssen nicht konfiguriert werden.

{
  "apiVersion": "2018-10-01",
  "type": "Microsoft.Compute/virtualMachineScaleSets",
  "name": "[parameters('vmNodeType1Name')]",
  "location": "[parameters('computeLocation')]",
  "zones": [ "1", "2", "3" ],
  "properties": {
    "singlePlacementGroup": true,
    "zoneBalance": true
  }
}

Hinweis

Service Fabric-Cluster sollten über mindestens einen primären Knotentyp verfügen. Die Dauerhaftigkeitsstufe primärer Knotentypen sollte auf „Silver“ (Silber) oder höher festgelegt werden.
Eine Verfügbarkeitszone, die eine VM-Skalierungsgruppe umfasst, sollte unabhängig von der Dauerhaftigkeitsstufe mit mindestens drei Verfügbarkeitszonen konfiguriert werden.
Eine Verfügbarkeitszone, die eine VM-Skalierungsgruppe mit der Dauerhaftigkeit „Silver“ (Silber) oder höher umfasst, sollte über mindestens 15 VMs verfügen.
Eine Verfügbarkeitszone, die eine VM-Skalierungsgruppe mit der Dauerhaftigkeit „Bronze“ umfasst, sollte über mindestens 6 VMs verfügen.

Aktivieren der Unterstützung für mehrere Zonen im Service Fabric-Knotentyp

Der Service Fabric-Knotentyp muss aktiviert werden, um mehrere Verfügbarkeitszonen zu unterstützen.

Der erste Wert lautet multipleAvailabilityZones. Dieser Wert sollte für den Knotentyp auf true gesetzt werden.
Der zweite, optionale Wert ist sfZonalUpgradeMode. Diese Eigenschaft kann nicht geändert werden, wenn im Cluster bereits ein Knotentyp mit mehreren Verfügbarkeitszonen vorhanden ist. Diese Eigenschaft steuert die logische Gruppierung von VMs in Upgradedomänen (UDs).
- Bei Festlegung auf Parallel gilt Folgendes: VMs, die dem Knotentyp zugeordnet sind, werden in Upgradedomänen gruppiert. Die Zoneninformationen zu den fünf Upgradedomänen werden ignoriert. Mit dieser Einstellung werden die Upgradedomänen aller Zonen gleichzeitig aktualisiert. Dieser Bereitstellungsmodus ist bei Upgrades zwar schneller, wird jedoch nicht empfohlen, da er gegen die SDP-Richtlinien verstößt, die festlegen, dass Updates jeweils nur in einer Zone angewandt werden sollten.
- Wird dieser Wert ausgelassen oder auf Hierarchical festgelegt, gilt Folgendes: VMs werden gemäß der Zonenverteilung in bis zu 15 Upgradedomänen gruppiert. Jede der drei Zonen verfügt über fünf Upgradedomänen. Dadurch wird sichergestellt, dass die Zonen nacheinander aktualisiert werden. Erst wenn der Vorgang für die fünf Upgradedomänen innerhalb der ersten Zone abgeschlossen wurde, wird mit der nächsten Zone fortgefahren. Dieser Updatevorgang bietet eine höhere Sicherheit für den Cluster und die Benutzeranwendung.
Diese Eigenschaft definiert lediglich das Upgradeverhalten für Service Fabric-Anwendungen und Codeupgrades. Upgrades der zugrunde liegenden VM-Skalierungsgruppe werden weiterhin in allen Verfügbarkeitszonen parallel ausgeführt. Diese Eigenschaft wirkt sich nicht auf die Verteilung von Upgradedomänen für Knotentypen aus, für die nicht mehrere Zonen aktiviert sind.
Der dritte Wert ist vmssZonalUpgradeMode. Er ist optional und kann jederzeit aktualisiert werden. Diese Eigenschaft definiert das Upgradeschema für die VM-Skalierungsgruppe: parallel oder sequenziell über Verfügbarkeitszonen hinweg.
- Ist der Wert auf Parallel festgelegt, werden alle Updates für Skalierungsgruppen parallel in allen Zonen durchgeführt. Dieser Bereitstellungsmodus ist bei Upgrades schneller, wird jedoch nicht empfohlen, da er gegen die SDP-Richtlinien verstößt, die festlegen, dass Updates jeweils nur in einer Zone angewandt werden sollten.
- Ist der Wert nicht angegeben oder auf Hierarchical festgelegt, werden die Zonen nacheinander aktualisiert. Erst wenn der Vorgang für die fünf Upgradedomänen innerhalb der ersten Zone abgeschlossen wurde, wird mit der nächsten Zone fortgefahren. Dieser Updatevorgang bietet eine höhere Sicherheit für den Cluster und die Benutzeranwendung.

Wichtig

Die API-Version der Service Fabric-Clusterressource sollte „2020-12-01-preview“ oder höher lauten.

Die Clustercodeversion sollte mindestens 8.1.321 sein.

{
  "apiVersion": "2020-12-01-preview",
  "type": "Microsoft.ServiceFabric/clusters",
  "name": "[parameters('clusterName')]",
  "location": "[parameters('clusterLocation')]",
  "dependsOn": [
    "[concat('Microsoft.Storage/storageAccounts/', parameters('supportLogStorageAccountName'))]"
  ],
  "properties": {
    "reliabilityLevel": "Platinum",
    "sfZonalUpgradeMode": "Hierarchical",
    "vmssZonalUpgradeMode": "Parallel",
    "nodeTypes": [
      {
        "name": "[parameters('vmNodeType0Name')]",
        "multipleAvailabilityZones": true
      }
    ]
  }
}

Hinweis

Die Ressource für öffentliche IP-Adressen und die Lastenausgleichsressource sollten die Standard-SKU verwenden, wie zuvor in diesem Artikel beschrieben.
Die Eigenschaft multipleAvailabilityZones kann für den Knotentyp nur beim Erstellen definiert werden. Eine spätere Änderung ist nicht möglich. Vorhandene Knotentypen können also nicht mit dieser Eigenschaft konfiguriert werden.
Wenn sfZonalUpgradeMode ausgelassen oder auf Hierarchical festgelegt wird, werden die Cluster- und Anwendungsbereitstellungen langsamer, da im Cluster mehr Upgradedomänen vorhanden sind. Für die erforderliche Upgradedauer der 15 Upgradedomänen müssen angemessene Upgraderichtlinientimeouts festgelegt werden. Die Upgraderichtlinie für App und Cluster sollte aktualisiert werden, um sicherzustellen, dass die Bereitstellung nicht das Timeout von 12 Stunden überschreitet, das für die Azure-Ressourcendienstbereitstellung festgelegt ist. Das bedeutet, dass die Bereitstellung für 15 Upgradedomänen nicht länger als 12 Stunden dauern sollte (also nicht mehr als 40 Minuten pro Upgradedomäne).
Legen Sie für den Cluster die Zuverlässigkeitsstufe Platinum fest, um sicherzustellen, dass der Cluster in einem Szenario mit einer ausgefallenen Zone weiterhin verfügbar ist.
Das Upgrade des DurabilityLevel (Dauerhaftigkeitsstufe) für einen nodetype (Knotentyp) mit multipleAvailabilityZones (mehreren Verfügbarkeitszonen) wird nicht unterstützt. Erstellen Sie stattdessen einen neuen Knotentyp mit der höheren Dauerhaftigkeit.
SF unterstützt nur 3 AvailabilityZones (Verfügbarkeitszonen). Eine höhere Zahl wird jetzt nicht unterstützt.

Tipp

Es wird empfohlen, sfZonalUpgradeMode auf Hierarchical festzulegen oder diesen Wert auszulassen. Bei der Bereitstellung wird die Zonenverteilung von VMs befolgt, die sich auf eine geringere Anzahl von Replikaten oder Instanzen auswirkt und sie dadurch sicherer macht. Verwenden Sie sfZonalUpgradeMode mit der Einstellung Parallel, wenn die Bereitstellungsgeschwindigkeit Priorität hat oder lediglich eine zustandslose Workload auf dem Knotentyp mit mehreren Verfügbarkeitszonen ausgeführt wird. Dies führt dazu, dass die Upgradedomänen in allen Verfügbarkeitszonen parallel aktualisiert werden.

Migration zum Knotentyp mit mehreren Verfügbarkeitszonen

Für jedes Migrationsszenario muss ein neuer Knotentyp hinzugefügt werden, der mehrere Verfügbarkeitszonen unterstützt. Vorhandene Knotentypen können nicht migriert werden, um mehrere Zonen zu unterstützen. Im Artikel Hochskalieren des primären Knotentyps eines Service Fabric-Clusters sind die Schritte zum Hinzufügen eines neuen Knotentyps sowie weiterer Ressourcen beschrieben, die für den neuen Knotentyp benötigt werden (z. B. IP- und Lastenausgleichsressourcen). Außerdem wird in diesem Artikel beschrieben, wie Sie den vorhandenen Knotentyp außer Betrieb nehmen, nachdem der neue Knotentyp mit mehreren Verfügbarkeitszonen dem Cluster hinzugefügt wurde.

Die Migration von einem Knotentyp der einen grundlegenden Lastenausgleicher und IP-Ressourcen verwendet. Dieser Vorgang ist bereits in einem nachfolgenden Unterabschnitt für die Lösung mit einem Knotentyp pro Verfügbarkeitszone beschrieben.

Der einzige Unterschied für den neuen Knotentyp besteht darin, dass nur eine VM-Skalierungsgruppe und ein Knotentyp für alle Verfügbarkeitszonen vorhanden sind (anstelle von einem Knotentyp pro Verfügbarkeitszone).
Migration von einem Knotentyp mit Lastenausgleichs- und IP-Ressourcen der Standard-SKU: Befolgen Sie die zuvor beschriebenen Schritte. Es ist jedoch nicht erforderlich, neue Lastenausgleichs-, IP- und NSG-Ressourcen hinzuzufügen. Für den neuen Knotentyp können dieselben Ressourcen wiederverwendet werden.

Sollten Sie auf Probleme stoßen, wenden Sie sich für Hilfe an den Support.

Migrationsoption 2: Bereitstellen von Zonen durch Anheften einer VM-Skalierungsgruppe an jede Zone

Anwendungsfall für diese Option

Das ist momentan die allgemein verfügbare Konfiguration.

Um einen Service Fabric-Cluster über mehrere Verfügbarkeitszonen hinweg zu verteilen, müssen Sie in jeder von der Region unterstützten Verfügbarkeitszone einen primären Knotentyp erstellen. Dadurch werden Startknoten gleichmäßig auf jeden der primären Knotentypen verteilt.

Die empfohlene Topologie für den primären Knotentyp erfordert folgendes:

Es müssen drei Knotentypen vorhanden sein, die als primäre Knotentypen markiert sind
- Jeder Knotentyp sollte einer eigenen VM-Skalierungsgruppe zugeordnet sein, die sich in einer anderen Zone befindet.
- Jede VM-Skalierungsgruppe sollte mindestens fünf Knoten aufweisen (Dauerhaftigkeit „Silver“ (Silber)).

Migrieren Ihres nicht verwalteten Service Fabric-Clusters mit Lastenausgleichs- und IP-Adressressourcen mit Standard-SKU

Aktivieren von Zonen in VM-Skalierungsgruppen

Um eine Zone in einer VM-Skalierungsgruppe zu aktivieren, fügen Sie die folgenden drei Werte in der Ressource der VM-Skalierungsgruppe hinzu:

Der erste Wert ist die zones-Eigenschaft, die angibt, in welcher Verfügbarkeitszone die VM-Skalierungsgruppe bereitgestellt wird.
Der zweite Wert ist die Eigenschaft singlePlacementGroup, die auf true festgelegt werden muss.
Der dritte Wert ist die faultDomainOverride-Eigenschaft in der Service Fabric-Erweiterung der VM-Skalierungsgruppe. Diese Eigenschaft sollte nur die Zone enthalten, in der diese VM-Skalierungsgruppe platziert wird. Beispiel: "faultDomainOverride": "az1". Da Azure Service Fabric-Cluster keine regionsübergreifende Unterstützung bieten, müssen alle VM-Skalierungsgruppenressourcen in derselben Region platziert werden.

{
  "apiVersion": "2018-10-01",
  "type": "Microsoft.Compute/virtualMachineScaleSets",
  "name": "[parameters('vmNodeType1Name')]",
  "location": "[parameters('computeLocation')]",
  "zones": [
    "1"
  ],
  "properties": {
    "singlePlacementGroup": true
  },
  "virtualMachineProfile": {
    "extensionProfile": {
      "extensions": [
        {
          "name": "[concat(parameters('vmNodeType1Name'),'_ServiceFabricNode')]",
          "properties": {
            "type": "ServiceFabricNode",
            "autoUpgradeMinorVersion": false,
            "publisher": "Microsoft.Azure.ServiceFabric",
            "settings": {
              "clusterEndpoint": "[reference(parameters('clusterName')).clusterEndpoint]",
              "nodeTypeRef": "[parameters('vmNodeType1Name')]",
              "dataPath": "D:\\\\SvcFab",
              "durabilityLevel": "Silver",
              "certificate": {
                "thumbprint": "[parameters('certificateThumbprint')]",
                "x509StoreName": "[parameters('certificateStoreValue')]"
              },
              "systemLogUploadSettings": {
                "Enabled": true
              },
              "faultDomainOverride": "az1"
            },
            "typeHandlerVersion": "1.0"
          }
        }
      ]
    }
  }
}

Aktivieren mehrerer primärer Knotentypen in der Service Fabric-Clusterressource

Legen Sie die isPrimary-Eigenschaft auf true fest, um einen oder mehrere Knotentypen in einer Clusterressource als primären Knotentyp festzulegen. Wenn Sie einen Service Fabric-Cluster über mehrere Verfügbarkeitszonen hinweg bereitstellen, sollten drei Knotentypen in unterschiedlichen Zonen bereitgestellt werden.

{
  "reliabilityLevel": "Platinum",
  "nodeTypes": [
    {
      "name": "[parameters('vmNodeType0Name')]",
      "applicationPorts": {
        "endPort": "[parameters('nt0applicationEndPort')]",
        "startPort": "[parameters('nt0applicationStartPort')]"
      },
      "clientConnectionEndpointPort": "[parameters('nt0fabricTcpGatewayPort')]",
      "durabilityLevel": "Silver",
      "ephemeralPorts": {
        "endPort": "[parameters('nt0ephemeralEndPort')]",
        "startPort": "[parameters('nt0ephemeralStartPort')]"
      },
      "httpGatewayEndpointPort": "[parameters('nt0fabricHttpGatewayPort')]",
      "isPrimary": true,
      "vmInstanceCount": "[parameters('nt0InstanceCount')]"
    },
    {
      "name": "[parameters('vmNodeType1Name')]",
      "applicationPorts": {
        "endPort": "[parameters('nt1applicationEndPort')]",
        "startPort": "[parameters('nt1applicationStartPort')]"
      },
      "clientConnectionEndpointPort": "[parameters('nt1fabricTcpGatewayPort')]",
      "durabilityLevel": "Silver",
      "ephemeralPorts": {
        "endPort": "[parameters('nt1ephemeralEndPort')]",
        "startPort": "[parameters('nt1ephemeralStartPort')]"
      },
      "httpGatewayEndpointPort": "[parameters('nt1fabricHttpGatewayPort')]",
      "isPrimary": true,
      "vmInstanceCount": "[parameters('nt1InstanceCount')]"
    },
    {
      "name": "[parameters('vmNodeType2Name')]",
      "applicationPorts": {
        "endPort": "[parameters('nt2applicationEndPort')]",
        "startPort": "[parameters('nt2applicationStartPort')]"
      },
      "clientConnectionEndpointPort": "[parameters('nt2fabricTcpGatewayPort')]",
      "durabilityLevel": "Silver",
      "ephemeralPorts": {
        "endPort": "[parameters('nt2ephemeralEndPort')]",
        "startPort": "[parameters('nt2ephemeralStartPort')]"
      },
      "httpGatewayEndpointPort": "[parameters('nt2fabricHttpGatewayPort')]",
      "isPrimary": true,
      "vmInstanceCount": "[parameters('nt2InstanceCount')]"
    }
  ]
}

Sollten Sie auf Probleme stoßen, wenden Sie sich für Hilfe an den Support.

Migrationsoption: Nicht verwalteter Service Fabric-Cluster mit Lastenausgleichs- und IP-Adressressourcen mit Basic-SKU

Anwendungsfall für diese Option

Sie sollten diese Option verwenden, wenn Sie über einen nicht verwalteten Service Fabric-Cluster mit Lastenausgleichs- und IP-Adressressourcen mit Basic-SKU verfügen, den Sie migrieren möchten. Wenn Ihr vorhandener nicht verwalteter Cluster über Ressourcen mit Standard-SKU verfügt, lesen Sie die oben aufgeführten Migrationsoptionen. Wenn Sie Ihren nicht verwalteten Cluster noch nicht erstellt haben, aber wissen, dass er AZ-aktiviert sein soll, erstellen Sie ihn mit Ressourcen mit Standard-SKU.

Migrieren Ihres nicht verwalteten Service Fabric-Clusters mit Lastenausgleichs- und IP-Adressressourcen mit Basic-SKU

Wenn Sie einen Cluster migrieren möchten, der eine Lastenausgleichs- und IP-Ressource mit Basic-SKU nutzt, müssen Sie zunächst eine neue Lastenausgleichs- und IP-Ressource mit der Standard-SKU erstellen. Diese Ressourcen können nicht aktualisiert werden.

Verweisen Sie in den neuen verfügbarkeitszonenübergreifenden Knotentypen, die Sie verwenden möchten, auf die neuen Lastenausgleichs- und IP-Ressourcen. Im obigen Beispiel wurden drei neue VM-Skalierungsgruppenressourcen in den Zonen 1, 2 und 3 hinzugefügt. Diese VM-Skalierungsgruppen verweisen auf die neu erstellten Lastenausgleichs- und IP-Adressressourcen, die in der Service Fabric-Clusterressource als primäre Knotentypen gekennzeichnet sind.

Fügen Sie zunächst die neuen Ressourcen zu Ihrer vorhandenen Azure Resource Manager-Vorlage hinzu. Diese Ressourcen umfassen Folgendes:
- Eine Ressource für öffentliche IP-Adressen mit Standard-SKU
- Eine Lastenausgleichsressource mit Standard-SKU
- Eine Netzwerksicherheitsgruppe (NSG), auf die das Subnetz verweist, in dem Sie Ihre VM-Skalierungsgruppen bereitstellen
- Es müssen drei Knotentypen vorhanden sein, die als primäre Knotentypen markiert sind
  - Jeder Knotentyp sollte einer eigenen VM-Skalierungsgruppe zugeordnet sein, die sich in einer anderen Zone befindet.
  - Jede VM-Skalierungsgruppe sollte mindestens fünf Knoten aufweisen (Dauerhaftigkeit „Silver“ (Silber)).
Ein Beispiel für diese Ressourcen finden Sie in der Beispielvorlage.
```
New-AzureRmResourceGroupDeployment `
    -ResourceGroupName $ResourceGroupName `
    -TemplateFile $Template `
    -TemplateParameterFile $Parameters
```

Nach der Bereitstellung der Ressourcen können Sie die Knoten im primären Knotentyp des ursprünglichen Clusters deaktivieren. Sobald die Knoten deaktiviert sind, werden die Systemdienste zum neuen primären Knotentyp migriert, der im obigen Schritt bereitgestellt wurde.

Connect-ServiceFabricCluster -ConnectionEndpoint $ClusterName `
    -KeepAliveIntervalInSec 10 `
    -X509Credential `
    -ServerCertThumbprint $thumb  `
    -FindType FindByThumbprint `
    -FindValue $thumb `
    -StoreLocation CurrentUser `
    -StoreName My 

Write-Host "Connected to cluster"

$nodeNames = @("_nt0_0", "_nt0_1", "_nt0_2", "_nt0_3", "_nt0_4")

Write-Host "Disabling nodes..."
foreach($name in $nodeNames) {
    Disable-ServiceFabricNode -NodeName $name -Intent RemoveNode -Force
}

Nachdem alle Knoten deaktiviert wurden, werden die Systemdienste auf dem primären Knotentyp ausgeführt, der auf mehrere Zonen verteilt ist. Sie können dann die deaktivierten Knoten aus dem Cluster entfernen. Nachdem die Knoten entfernt wurden, können Sie die ursprünglichen IP-Adress-, Lastenausgleichs- und VM-Skalierungsgruppenressourcen entfernen.

foreach($name in $nodeNames){
    # Remove the node from the cluster
    Remove-ServiceFabricNodeState -NodeName $name -TimeoutSec 300 -Force
    Write-Host "Removed node state for node $name"
}

$scaleSetName="nt0"
Remove-AzureRmVmss -ResourceGroupName $groupname -VMScaleSetName $scaleSetName -Force

$lbname="LB-cluster-nt0"
$oldPublicIpName="LBIP-cluster-0"
$newPublicIpName="LBIP-cluster-1"

Remove-AzureRmLoadBalancer -Name $lbname -ResourceGroupName $groupname -Force
Remove-AzureRmPublicIpAddress -Name $oldPublicIpName -ResourceGroupName $groupname -Force

Dann sollten Sie die Verweise auf diese Ressourcen aus der Resource Manager-Vorlage entfernen, die Sie bereitgestellt haben.
Abschließend aktualisieren Sie den DNS-Namen und die öffentliche IP-Adresse.

$oldprimaryPublicIP = Get-AzureRmPublicIpAddress -Name $oldPublicIpName  -ResourceGroupName $groupname
$primaryDNSName = $oldprimaryPublicIP.DnsSettings.DomainNameLabel
$primaryDNSFqdn = $oldprimaryPublicIP.DnsSettings.Fqdn

Remove-AzureRmLoadBalancer -Name $lbname -ResourceGroupName $groupname -Force
Remove-AzureRmPublicIpAddress -Name $oldPublicIpName -ResourceGroupName $groupname -Force

$PublicIP = Get-AzureRmPublicIpAddress -Name $newPublicIpName  -ResourceGroupName $groupname
$PublicIP.DnsSettings.DomainNameLabel = $primaryDNSName
$PublicIP.DnsSettings.Fqdn = $primaryDNSFqdn
Set-AzureRmPublicIpAddress -PublicIpAddress $PublicIP

Sollten Sie auf Probleme stoßen, wenden Sie sich für Hilfe an den Support.

Teilen über

Migrieren Ihres Service Fabric-Clusters zur Unterstützung von Verfügbarkeitszonen

Voraussetzungen

Verwaltete Service Fabric-Cluster

Nicht verwaltete Service Fabric-Cluster

Vorhandene Lastenausgleichsressource mit Standard-SKU und IP-Adressressource

Lastenausgleichsressource mit Basic-SKU und IP-Adressressource

Anforderungen an Ausfallzeiten

Verwalteter Service Fabric-Cluster

Nicht verwalteter Service Fabric-Cluster

Migration verwalteter Service Fabric-Cluster

Migrationsoptionen für nicht verwaltete Service Fabric-Cluster

Migrationsoption 1: Aktivieren mehrerer Verfügbarkeitszonen in einer einzelnen VM-Skalierungsgruppe

Anwendungsfall für diese Option

Migrieren Ihres nicht verwalteten Service Fabric-Clusters mit Lastenausgleichs- und IP-Adressressourcen mit Standard-SKU

Aktivieren der Unterstützung für mehrere Zonen im Service Fabric-Knotentyp

Migration zum Knotentyp mit mehreren Verfügbarkeitszonen

Migrationsoption 2: Bereitstellen von Zonen durch Anheften einer VM-Skalierungsgruppe an jede Zone

Anwendungsfall für diese Option

Migrieren Ihres nicht verwalteten Service Fabric-Clusters mit Lastenausgleichs- und IP-Adressressourcen mit Standard-SKU

Aktivieren von Zonen in VM-Skalierungsgruppen

Aktivieren mehrerer primärer Knotentypen in der Service Fabric-Clusterressource

Migrationsoption: Nicht verwalteter Service Fabric-Cluster mit Lastenausgleichs- und IP-Adressressourcen mit Basic-SKU

Anwendungsfall für diese Option

Migrieren Ihres nicht verwalteten Service Fabric-Clusters mit Lastenausgleichs- und IP-Adressressourcen mit Basic-SKU

Nächste Schritte

Feedback

Feedback

Zusätzliche Ressourcen