Dela via

Distribuera ett Azure Service Fabric-kluster över Tillgänglighetszoner

  • Artikel

Tillgänglighetszoner i Azure är ett erbjudande med hög tillgänglighet som skyddar dina program och data från datacenterfel. En tillgänglighetszon är en unik fysisk plats som är utrustad med oberoende ström, kylning och nätverk i en Azure-region.

För att stödja kluster som sträcker sig över Tillgänglighetszoner tillhandahåller Azure Service Fabric de två konfigurationsmetoderna enligt beskrivningen i artikeln nedan. Tillgänglighetszoner är endast tillgängliga i utvalda regioner. Mer information finns i översikten över Tillgänglighetszoner.

Exempelmallar finns i Service Fabric-mallar för zonövergripande tillgänglighet.

Topologi för att sträcka sig över en primär nodtyp över Tillgänglighetszoner

Kommentar

Fördelen med att sträcka sig över den primära nodtypen mellan tillgänglighetszoner visas egentligen bara för tre zoner och inte bara två.

  • Klustertillförlitlighetsnivån inställd på Platinum
  • En enskild offentlig IP-resurs med standard-SKU
  • En enskild lastbalanserare med standard-SKU
  • En nätverkssäkerhetsgrupp (NSG) som refereras av undernätet där du distribuerar vm-skalningsuppsättningar

Kommentar

Egenskapen för vm-skalningsuppsättningen för en enskild placeringsgrupp måste vara inställd på true.

Följande exempelnodlista visar FD/UD-format i en vm-skalningsuppsättning som sträcker sig över zoner:

Skärmbild som visar en exempelnodlista med FD/UD-format i en vm-skalningsuppsättning som sträcker sig över zoner.

Distribution av tjänstrepliker mellan zoner

När en tjänst distribueras på de nodtyper som sträcker sig över Tillgänglighetszoner placeras replikerna för att säkerställa att de hamnar i separata zoner. Feldomänerna på noderna i var och en av dessa nodtyper konfigureras med zoninformationen (d.v.s. FD = fd:/zone1/1 osv.). För fem repliker eller tjänstinstanser är distributionen till exempel 2-2-1 och körningen försöker säkerställa lika fördelning mellan zoner.

Konfiguration av användartjänstreplik

Tillståndskänsliga användartjänster som distribueras på nodtyperna över Tillgänglighetszoner ska konfigureras så här: antal repliker med mål = 9, min = 5. Den här konfigurationen hjälper tjänsten att fungera även när en zon slutar fungera eftersom sex repliker fortfarande finns kvar i de andra två zonerna. En programuppgradering i det här scenariot kommer också att lyckas.

KlustertillförlitlighetNivå

Det här värdet definierar antalet startnoder i klustret och replikstorleken för systemtjänsterna. En konfiguration av zonen för korstillgänglighet har ett högre antal noder, som är spridda över zoner för att möjliggöra zonåterhämtning.

Ett högre ReliabilityLevel värde säkerställer att fler startnoder och systemtjänstrepliker finns och fördelas jämnt mellan zoner, så att klustret och systemtjänsterna inte påverkas om en zon misslyckas. ReliabilityLevel = Platinum (rekommenderas) säkerställer att det finns nio frönoder spridda över zoner i klustret, med tre frön i varje zon.

Scenario med zon ned

När en zon går ned visas alla noder och tjänstrepliker för den zonen som ned. Eftersom det finns repliker i de andra zonerna fortsätter tjänsten att svara. Primära repliker redundansväxlar till de fungerande zonerna. Tjänsterna verkar vara i varningstillstånd eftersom antalet målrepliker ännu inte har uppnåtts och antalet virtuella datorer (VM) fortfarande är högre än den minsta målreplikstorleken.

Service Fabric-lastbalanseraren hämtar repliker i arbetszonerna för att matcha antalet målrepliker. Nu verkar tjänsterna vara felfria. När zonen som var nere säkerhetskopieras kommer lastbalanseraren att sprida alla tjänstrepliker jämnt över zonerna.

Kommande optimeringar

  • För att tillhandahålla tillförlitliga infrastrukturuppdateringar kräver Service Fabric att den virtuella datorns skalningsuppsättningshållbarhet måste anges till minst Silver. På så sätt kan den underliggande VM-skalningsuppsättningen och Service Fabric-körningen tillhandahålla tillförlitliga uppdateringar. Detta kräver också att varje zon har minst 5 virtuella datorer. Vi arbetar med att sänka det här kravet till 3 och 2 virtuella datorer per zon för primära respektive icke-primära nodtyper.
  • Alla nedanstående konfigurationer och kommande arbete ger migrering på plats till kunder där samma kluster kan uppgraderas för att använda den nya konfigurationen genom att lägga till nya nodeTypes och dra tillbaka de gamla.

Nätverkskrav

Offentlig IP- och lastbalanserareresurs

För att aktivera zones egenskapen på en vm-skalningsuppsättningsresurs måste lastbalanseraren och IP-resursen som refereras av den virtuella datorns skalningsuppsättning använda en standard-SKU. När du skapar en IP-resurs utan SKU-egenskapen skapas en basic-SKU som inte stöder Tillgänglighetszoner. En Standard SKU-lastbalanserare blockerar all trafik utifrån som standard. Om du vill tillåta extern trafik distribuerar du en NSG till undernätet.

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

Kommentar

Det går inte att göra en ändring på plats av SKU för offentliga IP-resurser. Om du migrerar från befintliga resurser som har en grundläggande SKU kan du läsa migreringsavsnittet i den här artikeln.

NAT-regler för VM-skalningsuppsättningar

NAT-reglerna (inkommande nätverksadressöversättning) för lastbalanseraren ska matcha NAT-poolerna från vm-skalningsuppsättningen. Varje VM-skalningsuppsättning måste ha en unik inkommande NAT-pool.

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

Utgående regler för en Standard SKU-lastbalanserare

Den offentliga IP-adressen för Standard SKU introducerar nya funktioner och olika beteenden för utgående anslutning jämfört med att använda grundläggande SKU:er. Om du vill ha utgående anslutning när du arbetar med standard-SKU:er måste du uttryckligen definiera den med antingen en offentlig IP-adress för Standard SKU eller en Standard SKU-lastbalanserare. Mer information finns i Utgående anslutningar och Vad är Azure Load Balancer?.

Kommentar

Standardmallen refererar till en NSG som tillåter all utgående trafik som standard. Inkommande trafik är begränsad till de portar som krävs för Service Fabric-hanteringsåtgärder. NSG-reglerna kan ändras för att uppfylla dina krav.

Viktigt!

Varje nodtyp i ett Service Fabric-kluster som använder en Standard SKU-lastbalanserare kräver en regel som tillåter utgående trafik på port 443. Detta är nödvändigt för att slutföra klusterkonfigurationen. All distribution utan den här regeln misslyckas.

1. Aktivera flera Tillgänglighetszoner i en enda VM-skalningsuppsättning

Med den här lösningen kan användare sträcka sig över tre Tillgänglighetszoner i samma nodtyp. Detta är den rekommenderade distributionstopologin eftersom du kan distribuera över tillgänglighetszoner samtidigt som du behåller en enda VM-skalningsuppsättning.

En fullständig exempelmall finns på GitHub.

Diagram över arkitekturen för Tillgänglighetszon för Azure Service Fabric.

Konfigurera zoner på en VM-skalningsuppsättning

Om du vill aktivera zoner på en VM-skalningsuppsättning inkluderar du följande tre värden i resursen för VM-skalningsuppsättningen:

  • Det första värdet är egenskapen zones som anger Tillgänglighetszoner som finns i vm-skalningsuppsättningen.

  • Det andra värdet är egenskapen singlePlacementGroup som måste anges till true. Skalningsuppsättningen som sträcker sig över tre Tillgänglighetszoner kan skala upp till 300 virtuella datorer även med singlePlacementGroup = true.

  • Det tredje värdet är zoneBalance, vilket säkerställer strikt zonbalansering. Det här värdet ska vara true. Detta säkerställer att de virtuella datordistributionerna mellan zoner inte är obalanserade, vilket innebär att de andra två zonerna har tillräckligt med virtuella datorer för att hålla klustret igång när en zon går ned.

    Ett kluster med en obalanserad VM-distribution kanske inte överlever ett zon-down-scenario eftersom den zonen kan ha majoriteten av de virtuella datorerna. Obalanserad VM-distribution mellan zoner leder också till problem med tjänstplacering och att infrastrukturuppdateringar fastnar. Läs mer om zoneBalancing.

Du behöver inte konfigurera åsidosättningarna FaultDomain och UpgradeDomain .

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

Kommentar

  • Service Fabric-kluster bör ha minst en primär nodtyp. Hållbarhetsnivån för primära nodtyper ska vara Silver eller högre.
  • En tillgänglighetszon som omfattar vm-skalningsuppsättningar ska konfigureras med minst tre Tillgänglighetszoner, oavsett hållbarhetsnivå.
  • En tillgänglighetszon som omfattar vm-skalningsuppsättningar med Silver eller högre hållbarhet bör ha minst 15 virtuella datorer (5 per region).
  • En tillgänglighetszon som omfattar vm-skalningsuppsättningar med bronshållbarhet bör ha minst sex virtuella datorer.

Aktivera stöd för flera zoner i Service Fabric-nodtypen

Nodtypen Service Fabric måste vara aktiverad för att stödja flera Tillgänglighetszoner.

  • Det första värdet är multipleAvailabilityZones, som ska anges till true för nodtypen.

  • Det andra värdet är sfZonalUpgradeMode och är valfritt. Det går inte att ändra den här egenskapen om en nodtyp med flera Tillgänglighetszoner redan finns i klustret. Den här egenskapen styr den logiska gruppering av virtuella datorer i uppgraderingsdomäner (UD).

    • Om det här värdet är inställt på Parallel: Virtuella datorer under nodtypen grupperas i UD:er och ignorerar zoninformationen i fem UD:er. Den här inställningen gör att UD:er i alla zoner uppgraderas samtidigt. Det här distributionsläget går snabbare för uppgraderingar, vi rekommenderar det inte eftersom det strider mot SDP-riktlinjerna, som anger att uppdateringarna ska tillämpas på en zon i taget.
    • Om det här värdet utelämnas eller anges till Hierarchical: Virtuella datorer grupperas för att återspegla zonfördelningen i upp till 15 UD:er. Var och en av de tre zonerna har fem UD:er. Detta säkerställer att zonerna uppdateras en i taget och flyttas till nästa zon först efter att fem UD:er har slutförts inom den första zonen. Den här uppdateringsprocessen är säkrare för klustret och användarprogrammet.

    Den här egenskapen definierar endast uppgraderingsbeteendet för Service Fabric-program och koduppgraderingar. De underliggande uppgraderingarna av vm-skalningsuppsättningar är fortfarande parallella i alla Tillgänglighetszoner. Den här egenskapen påverkar inte UD-fördelningen för nodtyper som inte har flera zoner aktiverade.

  • Det tredje värdet är vmssZonalUpgradeMode, är valfritt och kan uppdateras när som helst. Den här egenskapen definierar uppgraderingsschemat för vm-skalningsuppsättningen som ska ske parallellt eller sekventiellt över Tillgänglighetszoner.

    • Om det här värdet är inställt på Parallel: Alla skalningsuppsättningsuppdateringar sker parallellt i alla zoner. Det här distributionsläget går snabbare för uppgraderingar, vi rekommenderar det inte eftersom det strider mot SDP-riktlinjerna, som anger att uppdateringarna ska tillämpas på en zon i taget.
    • Om det här värdet utelämnas eller anges till Hierarchical: Detta säkerställer att zonerna uppdateras en i taget och flyttas till nästa zon först efter att fem UD:er har slutförts i den första zonen. Den här uppdateringsprocessen är säkrare för klustret och användarprogrammet.

Viktigt!

Api-versionen för Service Fabric-klusterresursen ska vara 2020-12-01-preview eller senare.

Klusterkodversionen bör vara minst 8.1.321 eller senare.

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

Kommentar

  • Offentliga IP- och lastbalanseringsresurser bör använda standard-SKU:n som beskrevs tidigare i artikeln.
  • Egenskapen multipleAvailabilityZones på nodtypen kan bara definieras när nodtypen skapas och kan inte ändras senare. Befintliga nodtyper kan inte konfigureras med den här egenskapen.
  • När sfZonalUpgradeMode utelämnas eller anges till Hierarchicalblir kluster- och programdistributionerna långsammare eftersom det finns fler uppgraderingsdomäner i klustret. Det är viktigt att justera tidsgränserna för uppgraderingsprincipen korrekt för att ta hänsyn till den uppgraderingstid som krävs för 15 uppgraderingsdomäner. Uppgraderingsprincipen för både appen och klustret bör uppdateras för att säkerställa att distributionen inte överskrider tidsgränsen för Distribution av Azure Resource Service på 12 timmar. Det innebär att distributionen inte bör ta mer än 12 timmar för 15 UD:er (det vill säga bör inte ta mer än 40 minuter för varje UD).
  • Ange tillförlitlighetsnivån för klustret för Platinum att säkerställa att klustret överlever scenariot med en zon ned.
  • Uppgradering av DurabilityLevel för en nodtyp med multipleAvailabilityZones stöds inte. Skapa en ny nodtyp med högre hållbarhet i stället.
  • SF stöder bara 3 AvailabilityZones. Ett högre tal stöds inte just nu.

Dricks

Vi rekommenderar att Hierarchical du ställer in sfZonalUpgradeMode eller utelämnar det. Distributionen följer zonfördelningen av virtuella datorer och påverkar en mindre mängd repliker eller instanser, vilket gör dem säkrare. Använd sfZonalUpgradeMode inställd på Parallel om distributionshastigheten är en prioritet eller endast tillståndslösa arbetsbelastningar körs på nodtypen med flera Tillgänglighetszoner. Detta gör att UD-promenaden sker parallellt i alla Tillgänglighetszoner.

Migrera till nodtypen med flera Tillgänglighetszoner

För alla migreringsscenarier måste du lägga till en ny nodtyp som stöder flera Tillgänglighetszoner. En befintlig nodtyp kan inte migreras för att stödja flera zoner. Artikeln Skala upp en primär nodtyp för Service Fabric-klustret innehåller detaljerade steg för att lägga till en ny nodtyp och de andra resurser som krävs för den nya nodtypen, till exempel IP- och lastbalanserarens resurser. Den artikeln beskriver också hur du drar tillbaka den befintliga nodtypen efter att en ny nodtyp med flera Tillgänglighetszoner har lagts till i klustret.

  • Migrering från en nodtyp som använder grundläggande IP-resurser: Den här processen beskrivs redan i ett underavsnitt nedan för lösningen med en nodtyp per tillgänglighetszon.

    För den nya nodtypen är den enda skillnaden att det bara finns en vm-skalningsuppsättning och en nodtyp för alla Tillgänglighetszoner i stället för en vardera per tillgänglighetszon.

  • Migrering från en nodtyp som använder Standard SKU IP-resurser med en NSG: Följ samma procedur som beskrevs tidigare. Det finns dock inget behov av att lägga till nya IP- och NSG-resurser. Samma resurser kan återanvändas i den nya nodtypen.

2. Distribuera zoner genom att fästa en vm-skalningsuppsättning i varje zon

Det här är den allmänt tillgängliga konfigurationen just nu. Om du vill sträcka dig över ett Service Fabric-kluster över Tillgänglighetszoner måste du skapa en primär nodtyp i varje tillgänglighetszon som stöds av regionen. Detta distribuerar startnoder jämnt över var och en av de primära nodtyperna.

Den rekommenderade topologin för den primära nodtypen kräver följande:

  • Tre nodtyper markerade som primära
    • Varje nodtyp ska mappas till en egen VM-skalningsuppsättning som finns i en annan zon.
    • Varje VM-skalningsuppsättning bör ha minst fem noder (silverhållbarhet).

Följande diagram visar arkitekturen för Tillgänglighetszon för Azure Service Fabric:

Diagram som visar arkitekturen för Tillgänglighetszon för Azure Service Fabric.

Aktivera zoner på en VM-skalningsuppsättning

Om du vill aktivera en zon på en VM-skalningsuppsättning inkluderar du följande tre värden i resursen för VM-skalningsuppsättningen:

  • Det första värdet är egenskapen zones som anger vilken tillgänglighetszon vm-skalningsuppsättningen distribueras till.
  • Det andra värdet är egenskapen singlePlacementGroup som måste anges till true.
  • Det tredje värdet är faultDomainOverride egenskapen i tillägget för service fabric-vm-skalningsuppsättningen. Den här egenskapen bör endast innehålla den zon där den här VM-skalningsuppsättningen ska placeras. Exempel: "faultDomainOverride": "az1". Alla vm-skalningsuppsättningsresurser måste placeras i samma region eftersom Azure Service Fabric-kluster inte har stöd för flera regioner.
{
  "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"
          }
        }
      ]
    }
  }
}

Aktivera flera primära nodtyper i Service Fabric-klusterresursen

Om du vill ange en eller flera nodtyper som primära i en klusterresurs anger du isPrimary egenskapen till true. När du distribuerar ett Service Fabric-kluster över Tillgänglighetszoner bör du ha tre nodtyper i distinkta zoner.

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

Migrera till Tillgänglighetszoner från ett kluster med hjälp av en Grundläggande SKU-IP

Om du vill migrera ett kluster som använder en IP-adress med en grundläggande SKU måste du först skapa en helt ny IP-resurs med hjälp av standard-SKU:n. Det går inte att uppdatera dessa resurser.

Referera till den nya IP-adressen i de nya nodtyperna för zonen för korstillgänglighet som du vill använda. I föregående exempel lades tre nya vm-skalningsuppsättningsresurser till i zonerna 1, 2 och 3. Dessa vm-skalningsuppsättningar refererar till den nyligen skapade IP-adressen och markeras som primära nodtyper i Service Fabric-klusterresursen.

  1. Börja med att lägga till de nya resurserna i din befintliga Azure Resource Manager-mall. Dessa resurser omfattar:

    • En offentlig IP-resurs med standard-SKU
    • En lastbalanserarresurs med standard-SKU
    • En NSG som refereras av undernätet där du distribuerar vm-skalningsuppsättningar
    • Tre nodtyper markerade som primära
      • Varje nodtyp ska mappas till en egen VM-skalningsuppsättning som finns i en annan zon.
      • Varje VM-skalningsuppsättning bör ha minst fem noder (silverhållbarhet).

    Ett exempel på dessa resurser finns i exempelmallen.

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

  2. När resurserna har distribuerats kan du inaktivera noderna i den primära nodtypen från det ursprungliga klustret. När noderna är inaktiverade migreras systemtjänsterna till den nya primära nodtypen som du distribuerade tidigare.

    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. När alla noder har inaktiverats körs systemtjänsterna på den primära nodtypen, som är spridda över zoner. Du kan sedan ta bort de inaktiverade noderna från klustret. När noderna har tagits bort kan du ta bort den ursprungliga IP-adressen, lastbalanseraren och vm-skalningsuppsättningsresurserna.

    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. Ta sedan bort referenserna till dessa resurser från Resource Manager-mallen som du distribuerade.

  5. Uppdatera slutligen DNS-namnet och den offentliga IP-adressen.

$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