Een beheerd Service Fabric-cluster implementeren in beschikbaarheidszones

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.

Het beheerde Service Fabric-cluster ondersteunt implementaties die meerdere Beschikbaarheidszones omvatten om zonetolerantie te bieden. Deze configuratie zorgt voor hoge beschikbaarheid van de kritieke systeemservices en uw toepassingen om te beschermen tegen single-points-of-failure. Azure Beschikbaarheidszones zijn alleen beschikbaar in bepaalde regio's. Zie Overzicht van Azure Beschikbaarheidszones voor meer informatie.

Notitie

Beschikbaarheidszone-spanning is alleen beschikbaar op Standard-SKU-clusters.

Voorbeeldsjablonen zijn beschikbaar: Sjabloon voor meerdere beschikbaarheidszones van Service Fabric

Topologie voor zonetolerante Beheerde Azure Service Fabric-clusters

Notitie

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

Een Service Fabric-cluster dat is gedistribueerd over Beschikbaarheidszones (AZ) zorgt voor hoge beschikbaarheid van de clusterstatus.

Voor de aanbevolen topologie voor het beheerde cluster zijn de volgende resources vereist:

  • De cluster-SKU moet standaard zijn
  • Het primaire knooppunttype moet ten minste negen knooppunten (3 in elke AZ) hebben voor de beste tolerantie, maar ondersteunt minimaal zes (2 in elke AZ).
  • Secundaire knooppunttypen moeten ten minste zes knooppunten hebben voor de beste tolerantie, maar ondersteunt minimaal drie.

Notitie

Er worden slechts 3 implementaties van beschikbaarheidszones ondersteund.

Notitie

Het is niet mogelijk om een in-place wijziging van virtuele-machineschaalsets in een beheerd cluster uit te voeren van niet-zone-spanning naar een zone-spanned cluster.

Diagram met de azure Service Fabric-beschikbaarheidszonearchitectuur Azure Service Fabric-beschikbaarheidszonearchitectuur

Voorbeeld van een knooppuntlijst met FD-/UD-indelingen in een virtuele-machineschaalset die zones overspant

Voorbeeld van een knooppuntlijst met FD-/UD-indelingen in een virtuele-machineschaalset die zones omspant.

Distributie van servicereplica's tussen zones: wanneer een service wordt geïmplementeerd op de knooppunttypen die zones overspannen, worden de replica's geplaatst om ervoor te zorgen dat ze in afzonderlijke zones terechtkomen. Deze scheiding wordt gegarandeerd omdat het foutdomein op de knooppunten in elk van deze knooppunttypen is geconfigureerd met de zone-informatie (d.w.z. FD = fd:/zone1/1, enzovoort). Bijvoorbeeld: voor vijf replica's of exemplaren van een service is de distributie 2-2-1 en wordt geprobeerd een gelijke verdeling tussen AZ's te garanderen.

Configuratie van gebruikersservicereplica: Stateful-gebruikersservices die zijn geïmplementeerd op de typen knooppunten voor meerdere beschikbaarheidszones moeten worden geconfigureerd met deze configuratie: 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 een dergelijk scenario wordt ook uitgevoerd.

Scenario voor zone-omlaag: wanneer een zone uitvalt, worden alle knooppunten in die zone als offline weergegeven. Servicereplica's op deze knooppunten zijn ook offline. Omdat er replica's in de andere zones zijn, blijft de service reageren met failover van primaire replica's naar de zones die werken. De services worden weergegeven met de waarschuwingsstatus omdat niet wordt voldaan aan het aantal doelreplica's en het aantal virtuele machines (VM's) nog steeds groter is dan de gedefinieerde minimale grootte van de doelreplica. Als gevolg hiervan brengt Service Fabric load balancer replica's in de werkzones op zodat deze overeenkomen met het geconfigureerde aantal doelreplica's. Op dit moment moeten de services in orde zijn. Wanneer de zone die uitvalt weer omhoog komt, verspreidt de load balancer alle servicereplica's gelijkmatig over alle zones.

Netwerkconfiguratie

Zie Netwerkinstellingen configureren voor beheerde Service Fabric-clusters voor meer informatie.

Een zonebestendig beheerd Azure Service Fabric-cluster inschakelen

Als u een zonebestendig beheerd Azure Service Fabric-cluster wilt inschakelen, moet u de volgende eigenschap ZonealResiliency opnemen, die aangeeft of het cluster zonebestendig is of niet.

{
  "apiVersion": "2021-05-01",
  "type": "Microsoft.ServiceFabric/managedclusters",
  "properties": {
  ...
  "zonalResiliency": "true",
  ...
  }
}

Een bestaand niet-zone tolerant cluster migreren naar Zone Resilient (preview)

Bestaande beheerde Service Fabric-clusters die niet zijn verspreid over beschikbaarheidszones, kunnen nu ter plaatse worden gemigreerd om beschikbaarheidszones te omvatten. Ondersteunde scenario's zijn clusters die zijn gemaakt in regio's met drie beschikbaarheidszones en clusters in regio's waar drie beschikbaarheidszones beschikbaar worden gesteld na de implementatie.

Vereisten:

Notitie

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. Dit gebeurt wanneer er een nieuw openbaar IP-adres moet worden gemaakt om het netwerk tolerant te maken voor zonefouten. Plan de migratie dienovereenkomstig.

  1. Begin met het bepalen of een nieuw IP-adres vereist is en welke resources moeten worden gemigreerd om zonebestendig te worden. Gebruik de volgende API-aanroep om de huidige tolerantiestatus van de beschikbaarheidszone voor de resources van het beheerde cluster op te halen:

    POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ServiceFabric/managedClusters/{clusterName}/getazresiliencystatus?api-version=2022-02-01-preview
    

    U kunt ook de Az-module als volgt gebruiken:

    Select-AzSubscription -SubscriptionId {subscriptionId}
    Invoke-AzResourceAction -ResourceId /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ServiceFabric/managedClusters/{clusterName} -Action getazresiliencystatus -ApiVersion 2022-02-01-preview
    

    De opdracht moet een antwoord geven dat vergelijkbaar is met:

    {
    "baseResourceStatus" :[
      {
      "resourceName": "sfmccluster1"
      "resourceType": "Microsoft.Storage/storageAccounts"
      "isZoneResilient": false
      },
      {
      "resourceName": "PublicIP-sfmccluster1"
      "resourceType": "Microsoft.Network/publicIPAddresses"
      "isZoneResilient": false
      },
      {
      "resourceName": "primary"
      "resourceType": "Microsoft.Compute/virutalmachinescalesets"
      "isZoneResilient": false
      }
    ],
    "isClusterZoneResilient": false
    }
    

    Als de openbare IP-resource niet zonebestendig is, leidt de migratie van het cluster tot een kort verlies van externe connectiviteit. Dit verbindingsverlies is het gevolg van het instellen van een nieuw openbaar IP-adres en het bijwerken van de FQDN (Fully Qualified Domain Name) van het cluster naar het nieuwe IP-adres. Als de openbare IP-resource zonebestendig is, wijzigt migratie de openbare IP-resource en de FQDN niet en is er geen invloed op externe connectiviteit.

  2. Start de conversie van het onderliggende opslagaccount dat is gemaakt voor een beheerd cluster van lokaal redundante opslag (LRS) naar Zone Redundant Storage (ZRS) met behulp van door de klant geïnitieerde conversie. De resourcegroep van het opslagaccount dat moet worden gemigreerd, heeft de vorm 'SFC_ClusterId'(bijvoorbeeld SFC_9240df2f-71ab-4733-a641-53a8464d992d) onder hetzelfde abonnement als de beheerde clusterresource.

  3. De eigenschap Zones toevoegen aan bestaande knooppunttypen

    Met deze stap configureert u de beheerde virtuele-machineschaalset die is gekoppeld aan het knooppunttype als zonebestendig, zodat nieuwe VIRTUELE machines die eraan worden toegevoegd, worden geïmplementeerd in beschikbaarheidszones (zonegebonden VM's). Als het opgegeven knooppunttype primair is, voert de resourceprovider de migratie van het openbare IP-adres uit, samen met een DNS-update van het cluster, indien nodig om zonebestendig te worden. Gebruik de getazresiliencystatus API om inzicht te hebben in de implicatie van deze stap.

  • Gebruik apiVersion 2022-02-01-preview of hoger.

  • Voeg de zones parameter die is ingesteld op ["1", "2", "3"] bestaande knooppunttypen toe:

    {
       "apiVersion": "2024-02-01-preview",
       "type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
       "name": "[concat(parameters('clusterName'), '/', parameters('nodeTypeName'))]",
       "location": "[resourcegroup().location]",
       "dependsOn": [
         "[concat('Microsoft.ServiceFabric/managedclusters/', parameters('clusterName'))]"
       ],
       "properties": {
         ...
         "isPrimary": true,
         "zones": ["1", "2", "3"]
         ...
       }
    },
    {
       "apiVersion": "2024-02-01-preview",
       "type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
       "name": "[concat(parameters('clusterName'), '/', parameters('nodeTypeNameSecondary'))]",
       "location": "[resourcegroup().location]",
       "dependsOn": [
         "[concat('Microsoft.ServiceFabric/managedclusters/', parameters('clusterName'))]"
       ],
       "properties": {
         ...
         "isPrimary": false,
         "zones": ["1", "2", "3"]
         ...
       }
    }
    
  1. Knooppunttypen schalen om zonegebonden knooppunten toe te voegen en regionale knooppunten te verwijderen

    In deze fase worden de virtuele-machineschaalsets gemarkeerd als zone-tolerant. Wanneer u omhoog schaalt, zijn nieuw toegevoegde knooppunten dus zonegebonden en wanneer u omlaag schaalt, worden regionale knooppunten verwijderd. Deze aanpak biedt de flexibiliteit om te schalen in elke volgorde die overeenkomt met uw capaciteitsvereisten door de vmInstanceCount eigenschap op de knooppunttypen aan te passen.

    Als de eerste vmInstanceCount bijvoorbeeld is ingesteld op 6 (wat zes regionale knooppunten aangeeft), kunt u twee implementaties uitvoeren:

    • Eerste implementatie: Verhoog de vmInstanceCount naar 12 om 6 zonegebonden knooppunten toe te voegen.
    • Tweede implementatie: verklein de vmInstanceCount tot 6 om alle regionale knooppunten te verwijderen.

    Tijdens het proces kunt u de getazresiliencystatus API controleren om de voortgangsstatus op te halen, zoals hieronder wordt geïllustreerd. Het proces wordt beschouwd als voltooid zodra elk knooppunttype minimaal zes zonegebonden knooppunten en 0 regionale knooppunten heeft.

    {
    "baseResourceStatus" :[
      {
      "resourceName": "sfmccluster1"
      "resourceType": "Microsoft.Storage/storageAccounts"
      "isZoneResilient": true
      },
      {
      "resourceName": "PublicIP-sfmccluster1"
      "resourceType": "Microsoft.Network/publicIPAddresses"
      "isZoneResilient": true
      },
      {
      "resourceName": "ntPrimary"
      "resourceType": "Microsoft.Compute/virutalmachinescalesets"
      "isZoneResilient": false
      "details": "Status: InProgress, ZonalNodes: 6, RegionalNodes: 6"
      },
      {
      "resourceName": "ntSecondary"
      "resourceType": "Microsoft.Compute/virutalmachinescalesets"
      "isZoneResilient": true
      "details": "Status: Done, ZonalNodes: 6, RegionalNodes: 0"
      }
    ],
    "isClusterZoneResilient": false
    }
    

    Notitie

    Voor het schaalproces voor het primaire knooppunttype is extra tijd vereist, omdat elke toevoeging of verwijdering van een knooppunt een upgrade van een Service Fabric-cluster start.

  2. Het cluster tolerant markeren voor zonefouten

    Deze stap helpt bij toekomstige implementaties, omdat dit ervoor zorgt dat alle toekomstige implementaties van knooppunttypen over verschillende beschikbaarheidszones bestaan en het cluster dus tolerant blijft voor AZ-fouten. Stel zonalResiliency: true in de ARM-clustersjabloon in en voer een implementatie uit om het cluster als zonebestendig te markeren en ervoor te zorgen dat alle implementaties van nieuwe knooppunttypen over meerdere beschikbaarheidszones bestaan. Deze update is alleen toegestaan als alle knooppunttypen ten minste zes zonegebonden knooppunten en 0 regionale knooppunten hebben.

    {
      "apiVersion": "2022-02-01-preview",
      "type": "Microsoft.ServiceFabric/managedclusters",
      "zonalResiliency": "true"
    }
    

    U kunt ook de bijgewerkte status in de portal zien onder Overzicht -> Eigenschappen die vergelijkbaar zijn met Zonal resiliency True, zodra het is voltooid.

  3. Controleer of alle resources zonetolerant zijn

    Gebruik de volgende GET API-aanroep om de tolerantiestatus van de beschikbaarheidszone voor de resources van het beheerde cluster te valideren:

    POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ServiceFabric/managedClusters/{clusterName}/getazresiliencystatus?api-version=2022-02-01-preview
    

    Deze API-aanroep moet een antwoord bieden dat vergelijkbaar is met:

    {
     "baseResourceStatus" :[
       {
       "resourceName": "sfmccluster1"
       "resourceType": "Microsoft.Storage/storageAccounts"
       "isZoneResilient": true
       },
       {
       "resourceName": "PublicIP-sfmccluster1"
       "resourceType": "Microsoft.Network/publicIPAddresses"
       "isZoneResilient": true
       },
       {
         "resourceName": "ntPrimary"
         "resourceType": "Microsoft.Compute/virutalmachinescalesets"
         "isZoneResilient": true
         "details": "Status: Done, ZonalNodes: 6, RegionalNodes: 0"
       },
       {
         "resourceName": "ntSecondary"
         "resourceType": "Microsoft.Compute/virutalmachinescalesets"
         "isZoneResilient": true
         "details": "Status: Done, ZonalNodes: 6, RegionalNodes: 0"
       }
     ],
     "isClusterZoneResilient": true
    }
    

    Als u problemen ondervindt, neemt u contact op met ondersteuning voor hulp.

FastZonalUpdate inschakelen op beheerde Service Fabric-clusters (preview)

Beheerde Service Fabric-clusters ondersteunen snellere cluster- en toepassingsupgrades door de maximale upgradedomeinen per beschikbaarheidszone te verminderen. De standaardconfiguratie kan nu maximaal 15 upgradedomeinen (UD's) hebben in meerdere AZ-knooppunttypen. Dit enorme aantal UD's heeft de upgradesnelheid verminderd. De nieuwe configuratie vermindert de maximum aantal UD's, wat resulteert in snellere updates, waardoor de veiligheid van de upgrades intact blijft.

De update moet worden uitgevoerd via een ARM-sjabloon door de eigenschap zonealUpdateMode in te stellen op 'snel' en vervolgens een kenmerk van het knooppunttype te wijzigen, zoals het toevoegen van een knooppunt en het verwijderen van het knooppunt aan elk knooppunttype (zie vereiste stappen 2 en 3). De apiVersion van de beheerde Service Fabric-clusterresource moet 2022-10-01-preview of hoger zijn.

  1. Wijzig de ARM-sjabloon met de nieuwe eigenschap zonalUpdateMode.
   "resources": [
        {
            "type": "Microsoft.ServiceFabric/managedClusters",
            "apiVersion": "2022-10-01-preview",
            '''
            "properties": {
                '''
                "zonalResiliency": true,
                "zonalUpdateMode": "fast",
                ...
            }
        }]
  1. Voeg een knooppunt toe aan een cluster met behulp van de opdracht az sf cluster node add PowerShell.

  2. Verwijder een knooppunt uit een cluster met behulp van de opdracht az sf cluster node remove PowerShell.