Share via

Uw Service Fabric-cluster migreren naar ondersteuning voor beschikbaarheidszones

  • Artikel

In deze handleiding wordt beschreven hoe u Service Fabric-clusters migreert van ondersteuning voor niet-beschikbaarheidszones naar beschikbaarheidsondersteuning. We nemen u door de verschillende opties voor migratie. Een Service Fabric-cluster verdeeld over beschikbaarheidszones zorgt voor hoge beschikbaarheid van de clusterstatus.

U kunt zowel beheerde als niet-beheerde clusters migreren. Beide worden behandeld in dit artikel.

Voor niet-beheerde clusters bespreken we twee verschillende scenario's:

  • Een cluster migreren met een Standard SKU load balancer en IP-resource. Deze configuratie ondersteunt beschikbaarheidszones zonder nieuwe resources te hoeven maken.
  • Een cluster migreren met een Basic SKU load balancer en IP-resource. Deze configuratie biedt geen ondersteuning voor beschikbaarheidszones en vereist het maken van nieuwe resources.

Zie de juiste secties onder elke header voor uw Service Fabric-clusterscenario.

Notitie

Het voordeel van het overspannen van het primaire knooppunttype in beschikbaarheidszones is alleen zichtbaar voor drie zones en niet slechts twee. Dit geldt voor zowel beheerde als niet-beheerde clusters.

Voorbeeldsjablonen zijn beschikbaar in service fabric-zonesjablonen voor meerdere beschikbaarheidszones.

Vereisten

Beheerde Service Fabric-clusters

Vereist:

Aanbevolen:

  • De cluster-SKU moet Standard zijn.
  • Het primaire knooppunttype moet ten minste negen knooppunten hebben voor de beste tolerantie, maar ondersteunt minimaal zes.
  • Secundaire knooppunttypen moeten ten minste zes knooppunten hebben voor de beste tolerantie, maar ondersteunt minimaal drie.

Niet-beheerde Service Fabric-clusters

Vereist: N.v.v.

Aanbevolen:

  • Het betrouwbaarheidsniveau van het cluster is ingesteld op Platinum.
  • Eén openbare IP-resource met behulp van standard-SKU.
  • Eén load balancer-resource met behulp van standard-SKU.
  • Een netwerkbeveiligingsgroep (NSG) waarnaar wordt verwezen door het subnet waarin u uw virtuele-machineschaalsets implementeert.

Bestaande standard-SKU-load balancer en IP-resource

Er zijn geen vereisten voor dit scenario, omdat ervan wordt uitgegaan dat u over de bestaande vereiste resources beschikt.

Basic SKU load balancer en IP-resource

  • Een nieuwe load balancer die gebruikmaakt van de Standard-SKU, verschilt van uw bestaande Basic SKU-load balancer.
  • Een nieuwe IP-resource die gebruikmaakt van de Standard-SKU, verschilt van uw bestaande BASIC SKU IP-resource.

Notitie

Het is niet mogelijk om uw bestaande resources te upgraden van een basic-SKU naar een standard-SKU, zodat er nieuwe resources nodig zijn.

Vereisten voor downtime

Beheerde Service Fabric-cluster

Migratie naar een zonetolerante configuratie kan leiden tot een kort verlies van externe connectiviteit via de load balancer, maar heeft geen invloed op de clusterstatus. Het verlies van externe connectiviteit treedt op wanneer een nieuw openbaar IP-adres moet worden gemaakt om het netwerk bestand te maken tegen zonefouten. Plan de migratie dienovereenkomstig.

Service Fabric-cluster dat niet wordt beheerd

Downtime voor het migreren van niet-beheerde Service Fabric-clusters varieert sterk op basis van het aantal VM's en UD's (Upgrade Domains) in uw cluster. UD's zijn logische groeperingen van VM's die bepalen in welke volgorde upgrades naar de VM's in uw cluster worden gepusht. De downtime wordt ook beïnvloed door de upgrademodus van uw cluster, waarmee wordt verwerkt hoe upgradetaken voor de UD's in uw cluster worden verwerkt. De sfZonalUpgradeMode eigenschap, die de upgrademodus beheert, wordt uitgebreider behandeld in de volgende secties.

Migratie voor beheerde Service Fabric-clusters

Volg de stappen in Het beheerde Service Fabric-cluster migreren naar zonetolerant.

Migratieopties voor niet-beheerde Service Fabric-clusters

Migratieoptie 1: meerdere Beschikbaarheidszones inschakelen in één virtuele-machineschaalset

Wanneer u deze optie gebruikt

Met deze oplossing kunnen gebruikers drie Beschikbaarheidszones in hetzelfde knooppunttype. Dit is de aanbevolen implementatietopologie, omdat u hiermee in verschillende beschikbaarheidszones kunt implementeren terwijl u één virtuele-machineschaalset onderhoudt.

Er is een volledige voorbeeldsjabloon beschikbaar op GitHub.

Gebruik deze optie als u een bestaand niet-beheerd Service Fabric-cluster hebt met de Standard SKU-load balancer en IP-resources die u wilt migreren. Als uw bestaande niet-beheerde cluster basic-SKU-resources heeft, ziet u de onderstaande migratieoptie Basic SKU.

Uw Niet-beheerde Service Fabric-cluster migreren met bestaande Standard SKU-load balancer en IP-resources

Zones inschakelen voor een virtuele-machineschaalset:

Neem de volgende drie waarden op in de virtuele-machineschaalsetresource:

  • De eerste waarde is de zones eigenschap, die de Beschikbaarheidszones aangeeft die zich in de virtuele-machineschaalset bevinden.

  • De tweede waarde is de singlePlacementGroup eigenschap, die moet worden ingesteld op true. De schaalset die over drie Beschikbaarheidszones kan worden geschaald tot 300 VM's, zelfs met singlePlacementGroup = true.

  • De derde waarde is zoneBalance, wat zorgt voor strikte zoneverdeling. Deze waarde moet zijn true. Dit zorgt ervoor dat de VM-distributies tussen zones niet onevenwichtig zijn, wat betekent dat wanneer één zone uitvalt, de andere twee zones voldoende VM's hebben om het cluster actief te houden.

    Een cluster met een niet-verdeelde VM-distributie overleeft mogelijk geen zone-down scenario omdat die zone mogelijk het merendeel van de VM's heeft. Niet-verdeelde VM-distributie tussen zones leidt ook tot problemen met de plaatsing van services en infrastructuurupdates blijven hangen. Lees meer over zoneBalancing.

U hoeft de FaultDomain en UpgradeDomain onderdrukkingen niet te configureren.

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

Notitie

  • Service Fabric-clusters moeten ten minste één primair knooppunttype hebben. Het duurzaamheidsniveau van primaire knooppunttypen moet Silver of hoger zijn.
  • Een beschikbaarheidszone voor virtuele-machineschaalsets moet worden geconfigureerd met ten minste drie Beschikbaarheidszones, ongeacht het duurzaamheidsniveau.
  • Een beschikbaarheidszone voor virtuele-machineschaalset met zilver of een hogere duurzaamheid moet ten minste 15 VM's hebben.
  • Een beschikbaarheidszone die virtuele-machineschaalset met bronzen duurzaamheid beslaat, moet ten minste zes VM's hebben.
Ondersteuning inschakelen voor meerdere zones in het Service Fabric-knooppunttype

Als u meerdere beschikbaarheidszones wilt ondersteunen, moet het Service Fabric-knooppunttype zijn ingeschakeld.

  • De eerste waarde is multipleAvailabilityZones, die moet worden ingesteld true voor het knooppunttype.

  • De tweede waarde is sfZonalUpgradeMode en is optioneel. Deze eigenschap kan niet worden gewijzigd als een knooppunttype met meerdere beschikbaarheidszones al aanwezig is in het cluster. Deze eigenschap bepaalt de logische groepering van VM's in UD's.

    • Als deze waarde is ingesteld op Parallel: VM's onder het knooppunttype worden gegroepeerd in UD's en de zonegegevens in vijf UD's negeren. Deze instelling zorgt ervoor dat UD's in alle zones tegelijkertijd worden bijgewerkt. Hoewel deze implementatiemodus sneller is voor upgrades, raden we dit niet aan omdat deze in strijd is met de SDP-richtlijnen, die aangeven dat de updates op één zone tegelijk moeten worden toegepast.

    • Als deze waarde wordt weggelaten of ingesteld op Hierarchical: VM's worden gegroepeerd om de zonegebonden verdeling in maximaal 15 UD's weer te geven. Elk van de drie zones heeft vijf UD's. Dit zorgt ervoor dat de zones één voor één worden bijgewerkt en pas na het voltooien van vijf UD's binnen de eerste zone naar de volgende zone worden verplaatst. Het updateproces is veiliger voor het cluster en de gebruikerstoepassing.

    Deze eigenschap definieert alleen het upgradegedrag voor Service Fabric-toepassings- en code-upgrades. De onderliggende upgrades voor virtuele-machineschaalsets zijn nog steeds parallel in alle Beschikbaarheidszones. Deze eigenschap heeft geen invloed op de UD-distributie voor knooppunttypen waarvoor geen meerdere zones zijn ingeschakeld.

  • De derde waarde is vmssZonalUpgradeModeoptioneel en kan op elk gewenst moment worden bijgewerkt. Met deze eigenschap wordt het upgradeschema voor de virtuele-machineschaalset parallel of opeenvolgend in Beschikbaarheidszones gedefinieerd.

    • Als deze waarde is ingesteld op Parallel: Alle updates van de schaalset worden parallel uitgevoerd in alle zones. Deze implementatiemodus is sneller voor upgrades en daarom raden we het niet aan omdat deze in strijd is met de SDP-richtlijnen, die aangeven dat de updates op één zone tegelijk moeten worden toegepast.
    • Als deze waarde wordt weggelaten of is ingesteld op Hierarchical: Dit zorgt ervoor dat de zones één voor één worden bijgewerkt, zodat u pas na het voltooien van vijf UD's binnen de eerste zone naar de volgende zone gaat. Dit updateproces is veiliger voor het cluster en de gebruikerstoepassing.

Belangrijk

De resource-API-versie van het Service Fabric-cluster moet 2020-12-01-preview of hoger zijn.

De clustercodeversie moet ten minste 8.1.321 of hoger zijn.

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

Notitie

  • Openbare IP- en load balancer-resources moeten gebruikmaken van de Standard-SKU die eerder in het artikel is beschreven.
  • De multipleAvailabilityZones eigenschap van het knooppunttype kan alleen worden gedefinieerd wanneer het knooppunttype wordt gemaakt en kan later niet meer worden gewijzigd. Bestaande knooppunttypen kunnen niet worden geconfigureerd met deze eigenschap.
  • Wanneer sfZonalUpgradeMode dit wordt weggelaten of ingesteld Hierarchicalop, zijn de cluster- en toepassingsimplementaties langzamer omdat er meer upgradedomeinen in het cluster zijn. Het is belangrijk om de time-outs van het upgradebeleid correct aan te passen om rekening te houden met de upgradetijd die nodig is voor 15 upgradedomeinen. Het upgradebeleid voor zowel de app als het cluster moet worden bijgewerkt om ervoor te zorgen dat de implementatie niet langer is dan de tijdslimiet voor de Implementatie van Azure Resource Service van 12 uur. Dit betekent dat de implementatie niet langer dan 12 uur mag duren voor 15 UD's (dat wil zeggen dat het niet langer dan 40 minuten duurt voor elke UD).
  • Stel het betrouwbaarheidsniveau van het cluster in om ervoor te Platinum zorgen dat het cluster het scenario met één zone-down overleeft.
  • Het upgraden van het Duurzaamheidsniveau voor een knooppunttype met multipleAvailabilityZones wordt niet ondersteund. Maak in plaats daarvan een nieuw knooppunttype met de hogere duurzaamheid.
  • SF ondersteunt slechts 3 AvailabilityZones. Een hoger getal wordt momenteel niet ondersteund.

Tip

U wordt aangeraden deze instelling in te Hierarchical stellen sfZonalUpgradeMode of weg te laten. Implementatie volgt de zonegebonden distributie van VM's en heeft invloed op een kleinere hoeveelheid replica's of exemplaren, waardoor ze veiliger zijn. Gebruik sfZonalUpgradeMode deze optie als Parallel de implementatiesnelheid een prioriteit is of alleen staatloze workloads worden uitgevoerd op het knooppunttype met meerdere Beschikbaarheidszones. Dit zorgt ervoor dat de UD-wandeling parallel plaatsvindt in alle Beschikbaarheidszones.

Migreren naar het knooppunttype met meerdere Beschikbaarheidszones

Voor alle migratiescenario's moet u een nieuw knooppunttype toevoegen dat ondersteuning biedt voor meerdere Beschikbaarheidszones. Een bestaand knooppunttype kan niet worden gemigreerd om meerdere zones te ondersteunen. Het artikel Over het omhoog schalen van het primaire knooppunttype van een Service Fabric-cluster bevat gedetailleerde stappen voor het toevoegen van een nieuw knooppunttype en de andere resources die nodig zijn voor het nieuwe knooppunttype, zoals IP- en load balancer-resources. In dit artikel wordt ook beschreven hoe u het bestaande knooppunttype buiten gebruik kunt stellen nadat een nieuw knooppunttype met meerdere Beschikbaarheidszones is toegevoegd aan het cluster.

  • Migratie van een knooppunttype dat gebruikmaakt van basic load balancer- en IP-resources: dit proces wordt al beschreven in een subsectie hieronder voor de oplossing met één knooppunttype per beschikbaarheidszone.

    Voor het nieuwe knooppunttype is het enige verschil dat er slechts één virtuele-machineschaalset en één knooppunttype is voor alle Beschikbaarheidszones in plaats van één per beschikbaarheidszone.

  • Migratie van een knooppunttype dat gebruikmaakt van de Standard SKU-load balancer en IP-resources met een NSG: volg dezelfde procedure die eerder is beschreven. U hoeft echter geen nieuwe load balancer-, IP- en NSG-resources toe te voegen. Dezelfde resources kunnen opnieuw worden gebruikt in het nieuwe knooppunttype.

Als u problemen ondervindt, kunt u contact opnemen met ondersteuning voor hulp.

Migratieoptie 2: zones implementeren door één virtuele-machineschaalset vast te maken aan elke zone

Wanneer u deze optie gebruikt

Dit is momenteel de algemeen beschikbare configuratie.

Als u een Service Fabric-cluster in Beschikbaarheidszones wilt omvatten, moet u een primair knooppunttype maken in elke beschikbaarheidszone die wordt ondersteund door de regio. Hiermee worden seed-knooppunten gelijkmatig verdeeld over elk van de primaire knooppunttypen.

Voor de aanbevolen topologie voor het primaire knooppunttype is dit vereist:

  • Drie knooppunttypen die zijn gemarkeerd als primair
    • Elk knooppunttype moet worden toegewezen aan een eigen virtuele-machineschaalset in een andere zone.
    • Elke virtuele-machineschaalset moet ten minste vijf knooppunten (Silver-duurzaamheid) hebben.

Gebruik deze optie als u een bestaand niet-beheerd Service Fabric-cluster hebt met de Standard SKU-load balancer en IP-resources die u wilt migreren. Als uw bestaande niet-beheerde cluster basic-SKU-resources heeft, ziet u de onderstaande migratieoptie Basic SKU.

Uw Niet-beheerde Service Fabric-cluster migreren met bestaande Standard SKU-load balancer en IP-resources

Zones inschakelen op een virtuele-machineschaalset

Als u een zone wilt inschakelen voor een virtuele-machineschaalset, moet u de volgende drie waarden opnemen in de resource van de virtuele-machineschaalset:

  • De eerste waarde is de zones eigenschap, waarmee wordt aangegeven op welke beschikbaarheidszone de virtuele-machineschaalset wordt geïmplementeerd.
  • De tweede waarde is de singlePlacementGroup eigenschap, die moet worden ingesteld op true.
  • De derde waarde is de faultDomainOverride eigenschap in de extensie Virtuele-machineschaalset van Service Fabric. Deze eigenschap moet alleen de zone bevatten waarin deze virtuele-machineschaalset wordt geplaatst. Voorbeeld: "faultDomainOverride": "az1". Alle virtuele-machineschaalsetresources moeten in dezelfde regio worden geplaatst omdat Azure Service Fabric-clusters geen ondersteuning voor meerdere regio's hebben.
{
  "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"
          }
        }
      ]
    }
  }
}
Meerdere primaire knooppunttypen inschakelen in de Service Fabric-clusterresource

Als u een of meer knooppunttypen wilt instellen als primair in een clusterresource, stelt u de isPrimary eigenschap in op true. Wanneer u een Service Fabric-cluster in Beschikbaarheidszones implementeert, moet u drie knooppunttypen in verschillende zones hebben.

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

Als u problemen ondervindt, kunt u contact opnemen met ondersteuning voor hulp.

Migratieoptie: Service Fabric-niet-beheerd cluster met Basic SKU-load balancer en IP-resources

Wanneer u deze optie gebruikt

Gebruik deze optie als u een bestaand niet-beheerd Service Fabric-cluster hebt met de Load Balancer basic SKU en IP-resources die u wilt migreren. Als uw bestaande niet-beheerde cluster standard-SKU-resources heeft, ziet u de bovenstaande migratieopties. Als u uw niet-beheerde cluster nog niet hebt gemaakt, maar weet dat het az-enabled moet zijn, maakt u het met standard-SKU-resources.

Uw Niet-beheerde Service Fabric-cluster migreren met load balancer en IP-resources van Basic SKU

Als u een cluster wilt migreren dat gebruikmaakt van een load balancer en IP met een basis-SKU, moet u eerst een volledig nieuwe load balancer en IP-resource maken met behulp van de standaard-SKU. Het is niet mogelijk om deze resources bij te werken.

Verwijs naar de nieuwe load balancer en HET IP-adres in de nieuwe typen knooppunten voor meerdere beschikbaarheidszones die u wilt gebruiken. In het vorige voorbeeld zijn er drie nieuwe virtuele-machineschaalsetbronnen toegevoegd in zones 1, 2 en 3. Deze virtuele-machineschaalsets verwijzen naar de zojuist gemaakte load balancer en HET IP-adres en worden gemarkeerd als primaire knooppunttypen in de Service Fabric-clusterresource.

  1. Voeg eerst de nieuwe resources toe aan uw bestaande Azure Resource Manager-sjabloon. Deze resources zijn onder andere:

    • Een openbare IP-resource met standard-SKU
    • Een load balancer-resource met standard-SKU
    • Een NSG waarnaar wordt verwezen door het subnet waarin u uw virtuele-machineschaalsets implementeert
    • Drie knooppunttypen die zijn gemarkeerd als primair
      • Elk knooppunttype moet worden toegewezen aan een eigen virtuele-machineschaalset in een andere zone.
      • Elke virtuele-machineschaalset moet ten minste vijf knooppunten (Silver-duurzaamheid) hebben.

    Een voorbeeld van deze resources vindt u in de voorbeeldsjabloon.

    New-AzureRmResourceGroupDeployment `
    -ResourceGroupName $ResourceGroupName `
    -TemplateFile $Template `
    -TemplateParameterFile $Parameters

  2. Wanneer de resources zijn geïmplementeerd, kunt u de knooppunten in het primaire knooppunttype uitschakelen vanuit het oorspronkelijke cluster. Wanneer de knooppunten zijn uitgeschakeld, worden de systeemservices gemigreerd naar het nieuwe primaire knooppunttype dat u eerder hebt geïmplementeerd.

    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
}

  3. Nadat de knooppunten zijn uitgeschakeld, worden de systeemservices uitgevoerd op het primaire knooppunttype, dat verspreid is over zones. Vervolgens kunt u de uitgeschakelde knooppunten uit het cluster verwijderen. Nadat de knooppunten zijn verwijderd, kunt u de oorspronkelijke IP-, load balancer- en virtual machineschaalset-resources verwijderen.

    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

  4. Verwijder vervolgens de verwijzingen naar deze resources uit de Resource Manager-sjabloon die u hebt geïmplementeerd.

  5. Werk ten slotte de DNS-naam en het openbare IP-adres bij.

$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

Als u problemen ondervindt, kunt u contact opnemen met ondersteuning voor hulp.

Volgende stappen