Een Azure Service Fabric-cluster implementeren in Beschikbaarheidszones

  • Artikel

Beschikbaarheidszones in Azure is een aanbieding met hoge beschikbaarheid waarmee uw toepassingen en gegevens worden beschermd tegen storingen in datacenters. Een beschikbaarheidszone is een unieke fysieke locatie die is uitgerust met onafhankelijke voeding, koeling en netwerken binnen een Azure-regio.

Azure Service Fabric biedt de twee configuratiemethoden, zoals beschreven in het onderstaande artikel ter ondersteuning van clusters die zich in Beschikbaarheidszones bevinden. Beschikbaarheidszones zijn alleen beschikbaar in bepaalde regio's. Zie het overzicht van Beschikbaarheidszones voor meer informatie.

Voorbeeldsjablonen zijn beschikbaar in Service Fabric-sjablonen voor meerdere beschikbaarheidszones.

Topologie voor het overspannen van een primair knooppunttype in Beschikbaarheidszones

Notitie

Het voordeel van het overspannen van het primaire knooppunttype in beschikbaarheidszones is alleen zichtbaar voor drie zones en niet slechts twee.

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

Notitie

De eigenschap voor één plaatsingsgroep van de virtuele-machineschaalset moet worden ingesteld op true.

In de volgende voorbeeldknooppuntlijst ziet u FD-/UD-indelingen in een virtuele-machineschaalset die zones beslaat:

Screenshot that shows a sample node list of FD/UD formats in a virtual machine scale set spanning zones.

Distributie van servicereplica's tussen zones

Wanneer een service wordt geïmplementeerd op de knooppunttypen die Beschikbaarheidszones omvatten, worden de replica's geplaatst om ervoor te zorgen dat ze in afzonderlijke zones terechtkomen. De foutdomeinen op de knooppunten in elk van deze knooppunttypen worden geconfigureerd met de zone-informatie (dat wil gezegd FD = fd:/zone1/1, enzovoort). Voor vijf replica's of service-exemplaren is de distributie bijvoorbeeld 2-2-1 en probeert de runtime gelijke verdeling tussen zones te garanderen.

Configuratie van gebruikersservicereplica

Stateful gebruikersservices die zijn geïmplementeerd op de knooppunttypen in Beschikbaarheidszones moeten als volgt worden geconfigureerd: aantal replica's met doel = 9, min = 5. Deze configuratie helpt de service te werken, zelfs wanneer één zone uitvalt, omdat er nog zes replica's in de andere twee zones zijn. Een toepassingsupgrade in dit scenario is ook geslaagd.

Betrouwbaarheidsniveau van cluster

Deze waarde definieert het aantal seed-knooppunten in het cluster en de replicagrootte van de systeemservices. Een instelling voor meerdere beschikbaarheidszones heeft een hoger aantal knooppunten, verspreid over zones om zonetolerantie mogelijk te maken.

Een hogere ReliabilityLevel waarde zorgt ervoor dat er meer seed-knooppunten en systeemservicereplica's aanwezig zijn en gelijkmatig over zones worden verdeeld, zodat het cluster en de systeemservices niet worden beïnvloed als een zone uitvalt. ReliabilityLevel = Platinum (aanbevolen) zorgt ervoor dat er negen seed-knooppunten zijn verdeeld over zones in het cluster, met drie zaden in elke zone.

Scenario voor zone-omlaag

Wanneer een zone uitvalt, worden alle knooppunten en servicereplica's voor die zone als offline weergegeven. Omdat er replica's in de andere zones zijn, blijft de service reageren. Primaire replica's uitvoeren een failover naar de functionerende zones. De services lijken waarschuwingsstatussen te hebben omdat het aantal doelreplica's nog niet is bereikt en het aantal virtuele machines (VM's) nog steeds hoger is dan de minimale grootte van de doelreplica.

Met de Load Balancer van Service Fabric worden replica's in de werkzones weergegeven die overeenkomen met het aantal doelreplica's. Op dit moment worden de services in orde weergegeven. Wanneer de zone die uitvalt weer omhoog komt, verspreidt de load balancer alle servicereplica's gelijkmatig over de zones.

Geplande optimalisaties

  • Voor betrouwbare infrastructuurupdates vereist Service Fabric dat de duurzaamheid van de virtuele-machineschaalset ten minste op Silver moet worden ingesteld. Hierdoor kunnen de onderliggende virtuele-machineschaalset en Service Fabric-runtime betrouwbare updates bieden. Dit vereist ook dat elke zone minimaal vijf VM's heeft. We werken eraan om deze vereiste te verkleinen tot respectievelijk 3 & 2 VM's per zone voor primaire en niet-primaire knooppunttypen.
  • Alle onderstaande configuraties en gepland werk bieden in-place migratie naar de klanten waar hetzelfde cluster kan worden geüpgraded om de nieuwe configuratie te gebruiken door nieuwe nodeTypes toe te voegen en de oude te buiten gebruik te stellen.

Netwerkvereisten

Openbare IP- en load balancer-resource

Als u de zones eigenschap wilt inschakelen voor een virtuele-machineschaalsetresource, moeten de load balancer en de IP-resource waarnaar wordt verwezen door die virtuele-machineschaalset beide een Standard-SKU gebruiken. Als u een load balancer of IP-resource maakt zonder de SKU-eigenschap, wordt er een basic-SKU gemaakt die geen ondersteuning biedt voor Beschikbaarheidszones. Een standard-SKU-load balancer blokkeert standaard al het verkeer van buitenaf. Implementeer een NSG naar het subnet om verkeer buiten het verkeer toe te staan.

{
  "apiVersion": "2018-11-01",
  "type": "Microsoft.Network/publicIPAddresses",
  "name": "[concat('LB','-', parameters('clusterName')]",
  "location": "[parameters('computeLocation')]",
  "sku": {
    "name": "Standard"
  }
}

{
  "apiVersion": "2018-11-01",
  "type": "Microsoft.Network/loadBalancers",
  "name": "[concat('LB','-', parameters('clusterName')]",
  "location": "[parameters('computeLocation')]",
  "dependsOn": [
    "[concat('Microsoft.Network/networkSecurityGroups/', concat('nsg', parameters('subnet0Name')))]"
  ],
  "properties": {
    "addressSpace": {
      "addressPrefixes": [
        "[parameters('addressPrefix')]"
      ]
    },
    "subnets": [
      {
        "name": "[parameters('subnet0Name')]",
        "properties": {
          "addressPrefix": "[parameters('subnet0Prefix')]",
          "networkSecurityGroup": {
            "id": "[resourceId('Microsoft.Network/networkSecurityGroups', concat('nsg', parameters('subnet0Name')))]"
          }
        }
      }
    ]
  },
  "sku": {
    "name": "Standard"
  }
}

Notitie

Het is niet mogelijk om een in-place wijziging van de SKU uit te voeren op de openbare IP- en load balancer-resources. Als u migreert van bestaande resources met een basic-SKU, raadpleegt u de migratiesectie van dit artikel.

NAT-regels voor virtuele-machineschaalsets

De nat-regels (Network Address Translation) voor de load balancer moeten overeenkomen met de NAT-pools van de virtuele-machineschaalset. Elke virtuele-machineschaalset moet een unieke inkomende NAT-pool hebben.

{
  "inboundNatPools": [
    {
      "name": "LoadBalancerBEAddressNatPool0",
      "properties": {
        "backendPort": "3389",
        "frontendIPConfiguration": {
          "id": "[variables('lbIPConfig0')]"
        },
        "frontendPortRangeEnd": "50999",
        "frontendPortRangeStart": "50000",
        "protocol": "tcp"
      }
    },
    {
      "name": "LoadBalancerBEAddressNatPool1",
      "properties": {
        "backendPort": "3389",
        "frontendIPConfiguration": {
          "id": "[variables('lbIPConfig0')]"
        },
        "frontendPortRangeEnd": "51999",
        "frontendPortRangeStart": "51000",
        "protocol": "tcp"
      }
    },
    {
      "name": "LoadBalancerBEAddressNatPool2",
      "properties": {
        "backendPort": "3389",
        "frontendIPConfiguration": {
          "id": "[variables('lbIPConfig0')]"
        },
        "frontendPortRangeEnd": "52999",
        "frontendPortRangeStart": "52000",
        "protocol": "tcp"
      }
    }
  ]
}

Uitgaande regels voor een standard-SKU-load balancer

De Load Balancer van de Standard-SKU en het openbare IP-adres introduceren nieuwe mogelijkheden en verschillende gedragingen voor uitgaande connectiviteit in vergelijking met het gebruik van Basic-SKU's. Als u uitgaande connectiviteit wilt wanneer u met Standard-SKU's werkt, moet u deze expliciet definiëren met een openbare IP-adressen van een Standard-SKU of een Standard SKU-load balancer. Zie Uitgaande verbindingen en wat is Azure Load Balancer? voor meer informatie.

Notitie

De standaardsjabloon verwijst naar een NSG die standaard al het uitgaande verkeer toestaat. Binnenkomend verkeer is beperkt tot de poorten die vereist zijn voor Service Fabric-beheerbewerkingen. De NSG-regels kunnen worden aangepast om aan uw vereisten te voldoen.

Belangrijk

Elk knooppunttype in een Service Fabric-cluster dat gebruikmaakt van een Standard SKU-load balancer, vereist een regel voor uitgaand verkeer op poort 443. Dit is nodig om het instellen van het cluster te voltooien. Implementaties zonder deze regel mislukken.

1. Meerdere Beschikbaarheidszones inschakelen in één virtuele-machineschaalset

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.

Diagram of the Azure Service Fabric Availability Zone architecture.

Zones configureren op een virtuele-machineschaalset

Als u zones 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, 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-machineschaalsets met Silver of een hogere duurzaamheid moet ten minste 15 VM's (5 per regio) hebben.
  • Een beschikbaarheidszone voor virtuele-machineschaalsets met bronzen duurzaamheid moet ten minste zes VM's hebben.

Ondersteuning inschakelen voor meerdere zones in het Service Fabric-knooppunttype

Het Service Fabric-knooppunttype moet zijn ingeschakeld voor ondersteuning van meerdere Beschikbaarheidszones.

  • 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 upgradedomeinen (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. Deze implementatiemodus is sneller voor upgrades, het wordt niet aanbevolen 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. Dit 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, het wordt niet aanbevolen 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.

2. Zones implementeren door één virtuele-machineschaalset vast te maken aan elke zone

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.

In het volgende diagram ziet u de azure Service Fabric-beschikbaarheidszonearchitectuur:

Diagram that shows the Azure Service Fabric Availability Zone architecture.

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 virtuele-machineschaalsetresource:

  • 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 van de 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')]"
    }
  ]
}

Migreren naar Beschikbaarheidszones vanuit een cluster met behulp van een Basic SKU-load balancer en een Basic SKU IP

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 virtuele-machineschaalsetbronnen 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