Share via

Migrera Service Fabric-klustret till stöd för tillgänglighetszoner

  • Artikel

Den här guiden beskriver hur du migrerar Service Fabric-kluster från stöd för icke-tillgänglighetszoner till tillgänglighetssupport. Vi tar dig igenom de olika alternativen för migrering. Ett Service Fabric-kluster som distribueras över tillgänglighetszoner garanterar hög tillgänglighet för klustertillståndet.

Du kan migrera både hanterade och icke-hanterade kluster. Båda beskrivs i den här artikeln.

För icke-hanterade kluster diskuterar vi två olika scenarier:

  • Migrera ett kluster med en Standard SKU-lastbalanserare och IP-resurs. Den här konfigurationen stöder tillgänglighetszoner utan att behöva skapa nya resurser.
  • Migrera ett kluster med en Basic SKU-lastbalanserare och IP-resurs. Den här konfigurationen stöder inte tillgänglighetszoner och kräver att nya resurser skapas.

Se lämpliga avsnitt under varje rubrik för ditt Service Fabric-klusterscenario.

Kommentar

Fördelen med att sträcka sig över den primära nodtypen mellan tillgänglighetszoner visas bara för tre zoner och inte bara två. Detta gäller både för hanterade och icke-hanterade kluster.

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

Förutsättningar

System Fabric-hanterade kluster

Krav:

Rekommenderat:

  • Kluster-SKU:n måste vara Standard.
  • Primär nodtyp bör ha minst nio noder för bästa återhämtning, men stöder minst sex.
  • Sekundära nodtyper ska ha minst sex noder för bästa återhämtning, men har stöd för minst tre.

Icke-hanterade Service Fabric-kluster

Obligatoriskt: Ej tillämpligt.

Rekommenderat:

  • Klustertillförlitlighetsnivån är 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.

Befintlig standard-SKU-lastbalanserare och IP-resurs

Det finns inga förutsättningar för det här scenariot eftersom det förutsätter att du har de befintliga nödvändiga resurserna.

Grundläggande SKU-lastbalanserare och IP-resurs

  • En ny lastbalanserare med standard-SKU:n, som skiljer sig från din befintliga Basic SKU-lastbalanserare.
  • En ny IP-resurs med standard-SKU:n, som skiljer sig från din befintliga Basic SKU IP-resurs.

Kommentar

Det går inte att uppgradera dina befintliga resurser från en grundläggande SKU till en standard-SKU, så nya resurser krävs.

Krav på stilleståndstid

Service Fabric-hanterat kluster

Migrering till en zonmotståndskraftig konfiguration kan orsaka en kort förlust av extern anslutning via lastbalanseraren, men påverkar inte klustrets hälsa. Förlusten av extern anslutning sker när en ny offentlig IP-adress måste skapas för att göra nätverket motståndskraftigt mot zonfel. Planera migreringen i enlighet med detta.

Service Fabric-icke-hanterat kluster

Stilleståndstiden för migrering av icke-hanterade Service Fabric-kluster varierar kraftigt beroende på antalet virtuella datorer och uppgraderingsdomäner (UD: er) i klustret. UD:er är logiska grupper av virtuella datorer som avgör i vilken ordning uppgraderingarna skickas till de virtuella datorerna i klustret. Stilleståndstiden påverkas också av uppgraderingsläget för klustret, som hanterar hur uppgraderingsuppgifter för UD:erna i klustret bearbetas. Egenskapen sfZonalUpgradeMode , som styr uppgraderingsläget, beskrivs mer detaljerat i följande avsnitt.

Migrering för Service Fabric-hanterade kluster

Följ stegen i Migrera Service Fabric-hanterat kluster till zonmotståndskraftigt.

Migreringsalternativ för icke-hanterade Service Fabric-kluster

Migreringsalternativ 1: Aktivera flera Tillgänglighetszoner i en enda vm-skalningsuppsättning

När du ska använda det här alternativet

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

En fullständig exempelmall finns på GitHub.

Du bör använda det här alternativet när du har ett befintligt Service Fabric-icke-hanterat kluster med standard-SKU-lastbalanseraren och IP-resurser som du vill migrera. Om ditt befintliga icke-hanterade kluster har Grundläggande SKU-resurser bör du se alternativet Grundläggande SKU-migrering nedan.

Så här migrerar du service fabric-icke-hanterat kluster med befintliga Standard SKU-lastbalanserare och IP-resurser

Så här aktiverar du zoner på en VM-skalningsuppsättning:

Inkludera följande tre värden i vm-skalningsuppsättningsresursen:

  • 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 sträcker sig över vm-skalningsuppsättningen ska konfigureras med minst tre Tillgänglighetszoner, oavsett hållbarhetsnivå.
  • En tillgänglighetszon som sträcker sig över VM-skalningsuppsättning med Silver eller högre hållbarhet bör ha minst 15 virtuella datorer.
  • En tillgänglighetszon som sträcker sig över VM-skalningsuppsättning med bronshållbarhet bör ha minst sex virtuella datorer.
Aktivera stöd för flera zoner i Service Fabric-nodtypen

För att stöda flera tillgänglighetszoner måste service fabric-nodtypen vara aktiverad.

  • 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 det redan finns en nodtyp med flera tillgänglighetszoner i klustret. Den här egenskapen styr den logiska gruppering av virtuella datorer i UD:er.

    • 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. Även om det här distributionsläget går snabbare för uppgraderingar rekommenderar vi 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. 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ättningen ä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, så 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 ska 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 lastbalanserare och 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-lastbalanseraren och IP-resurser med en NSG: Följ samma procedur som beskrevs tidigare. Det finns dock inget behov av att lägga till nya lastbalanserare, IP- och NSG-resurser. Samma resurser kan återanvändas i den nya nodtypen.

Om du stöter på problem kan du kontakta supporten för hjälp.

Migreringsalternativ 2: Distribuera zoner genom att fästa en VM-skalningsuppsättning i varje zon

När du ska använda det här alternativet

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).

Du bör använda det här alternativet när du har ett befintligt Service Fabric-icke-hanterat kluster med standard-SKU-lastbalanseraren och IP-resurser som du vill migrera. Om ditt befintliga icke-hanterade kluster har Grundläggande SKU-resurser bör du se alternativet Grundläggande SKU-migrering nedan.

Så här migrerar du service fabric-icke-hanterat kluster med befintliga Standard SKU-lastbalanserare och IP-resurser

Aktivera zoner på en VM-skalningsuppsättning

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

  • 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 Service Fabric Virtual Machine Scale Set-tillägget. 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')]"
    }
  ]
}

Om du stöter på problem kan du kontakta supporten för hjälp.

Migreringsalternativ: Service Fabric-icke-hanterat kluster med Basic SKU-lastbalanserare och IP-resurser

När du ska använda det här alternativet

Du bör använda det här alternativet när du har ett befintligt Service Fabric-icke-hanterat kluster med basic SKU-lastbalanseraren och IP-resurser som du vill migrera. Om ditt befintliga icke-hanterade kluster har Standard SKU-resurser bör du se migreringsalternativen ovan. Om du ännu inte har skapat ditt icke-hanterade kluster men vet att du vill att det ska vara AZ-aktiverat skapar du det med Standard SKU-resurser.

Så här migrerar du service fabric-icke-hanterat kluster med Basic SKU-lastbalanserare och IP-resurser

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

Referera till den nya lastbalanseraren och IP-adressen i de nya nodtyperna för zonen för flera tillgängligheter 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 lastbalanseraren och 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

Om du stöter på problem kan du kontakta supporten för hjälp.

Nästa steg