Bereitstellen eines verwalteten Service Fabric-Clusters über Verfügbarkeitszonen hinweg

Verfügbarkeitszonen in Azure sind ein Hochverfügbarkeitsangebot, das Anwendungen und Daten vor Ausfällen von Rechenzentren schützt. Eine Verfügbarkeitszone ist ein eindeutiger physischer Standort, der mit unabhängiger Stromversorgung, Kühlung und Netzwerk innerhalb einer Azure-Region ausgestattet ist.

Ein verwalteter Service Fabric-Cluster unterstützt Bereitstellungen, die sich über mehrere Verfügbarkeitszonen erstrecken, um Zonenresilienz bereitzustellen. Durch diese Konfiguration wird Hochverfügbarkeit der wichtigen Systemdienste und Ihrer Anwendungen sichergestellt, um Schutz vor Single Points of Failure zu gewährleisten. Azure-Verfügbarkeitszonen sind nur in ausgewählten Regionen verfügbar. Weitere Informationen finden Sie unter Übersicht über Azure-Verfügbarkeitszonen.

Hinweis

Die verfügbarkeitszonenübergreifende Funktion ist nur in Standard-SKU-Clustern verfügbar.

Es sind Beispielvorlagen verfügbar: Verfügbarkeitszonenübergreifende Service Fabric-Vorlage

Topologie für zonenresiliente verwaltete Azure Service Fabric-Cluster

Hinweis

Der Vorteil, den primären Knotentyp über die Verfügbarkeitszonen hinweg zu verteilen, zeigt sich eigentlich nur bei drei Zonen und nicht bei zwei Zonen.

Ein Service Fabric-Cluster, der über die Verfügbarkeitszonen verteilt ist, stellt die Hochverfügbarkeit des Clusterzustands sicher.

Die empfohlene Topologie für verwaltete Cluster erfordert die nachfolgend beschriebenen Ressourcen:

  • Die Cluster-SKU muss Standard sein.
  • Der primäre Knotentyp sollte mindestens neun Knoten für optimale Resilienz aufweisen, unterstützt werden jedoch mindestens sechs Knoten.
  • Die sekundären Knotentypen sollten mindestens sechs Knoten für optimale Resilienz aufweisen, unterstützt werden jedoch mindestens drei Knoten.

Hinweis

Es werden nur drei Bereitstellungen von Verfügbarkeitszonen unterstützt.

Hinweis

Es ist nicht möglich, die Skalierungssätze für virtuelle Maschinen in einem verwalteten Cluster von einem nichtzonenübergreifenden Cluster zu einem zonenübergreifenden Cluster zu ändern.

Abbildung, die die Azure Service Fabric Verfügbarkeitszonenarchitektur zeigt Azure Service Fabric Availability Zone Architecture

Beispiel Knotenliste mit FD/UD-Formaten in einer zonenübergreifenden VM-Skalierungsgruppe

Sample node list depicting FD/UD formats in a virtual machine scale set spanning zones.

Zonenübergreifende Verteilung von Dienstreplikaten: Wenn ein Dienst auf den zonenübergreifenden Knotentypen bereitgestellt wird, werden die Replikate so platziert, dass sichergestellt ist, dass sie in separaten Zonen angeordnet werden. Diese Trennung wird sichergestellt, da die Fehlerdomäne auf den Knoten, die in jedem dieser Knotentypen vorhanden sind, mit den Zoneninformationen konfiguriert ist (d. h. FD = fd:/zone1/1 etc.). Beispiel: für fünf Replikate oder Instanzen eines Diensts lautet die Verteilung 2-2-1, und die Runtime versucht, eine gleichmäßige Verteilung über Verfügbarkeitszonen hinweg sicherzustellen.

Replikatkonfigurationfür den Benutzerdienst: Zustandsbehaftete Benutzerdienste, die auf den Knotentypen für zonenübergreifende Verfügbarkeit bereitgestellt werden, müssen mit dieser Konfiguration konfiguriert werden: Replikatanzahl mit Ziel = 9, min = 5. Diese Konfiguration unterstützt den Dienst auch dann, wenn eine Zone ausfällt, da in den anderen beiden Zonen weiterhin 6 Replikate in Betrieb sind. Auch ein Anwendungsupgrade wird in einem solchen Szenario durchlaufen.

Szenario bei Zonenausfall: Wenn eine Zone ausfällt, werden alle Knoten in dieser Zone als ausgefallen angezeigt. Auch die Dienstreplikate auf diesen Knoten sind ausgefallen. Da in den anderen Zonen Replikate vorhanden sind, reagiert der Dienst weiterhin mit einem Failover der primären Replikate auf die Zonen, die funktionsfähig sind. Die Dienste werden mit dem Status „Warnung“ angezeigt, da die Anzahl der Zielreplikate nicht erreicht wurde und die VM-Anzahl immer noch über der definierten minimalen Zielreplikatgröße liegt. Daher startet der Service Fabric-Lastenausgleich in den Arbeitszonen so viele Replikate, dass die Anzahl mit der konfigurierten Zielreplikatanzahl übereinstimmt. An diesem Punkt erscheinen die Dienste fehlerfrei. Wenn die ausgefallene Zone erneut verfügbar ist, verteilt der Lastenausgleich alle Dienstreplikate gleichmäßig auf alle Zonen.

Netzwerkkonfiguration

Weitere Informationen finden Sie unter Konfigurieren von Netzwerkeinstellungen für verwaltete Service Fabric-Cluster.

Aktivieren eines zonenresilienten verwalteten Azure Service Fabric-Clusters

Um einen zonenresilienten verwalteten Azure Service Fabric-Cluster zu aktivieren, müssen Sie Folgendes in die Ressourcendefinition des verwalteten Clusters einschließen.

  • Die ZonalResiliency-Eigenschaft, die angibt, ob der Cluster zonenresilient ist.
{
  "apiVersion": "2021-05-01",
  "type": "Microsoft.ServiceFabric/managedclusters",
  "properties": {
  ...
  "zonalResiliency": "true",
  ...
  }
}

Migrieren eines vorhandenen nichtzonenresilienten Clusters zu zonenresilient (Vorschau)

Vorhandene von Service Fabric verwaltete Cluster, die nicht über Verfügbarkeitszonen verteilt sind, können jetzt zu Verfügbarkeitszonen migriert werden. Unterstützte Szenarien umfassen Cluster, die in Regionen mit drei Verfügbarkeitszonen sowie Clustern in Regionen erstellt wurden, in denen drei Verfügbarkeitszonen nach der Bereitstellung zur Verfügung gestellt werden.

Anforderungen:

Hinweis

Die Migration zu einer zonenresilienten Konfiguration kann zu einem kurzen Verlust der externen Konnektivität durch den Lastenausgleich führen, wirkt sich jedoch nicht auf die Clusterintegrität aus. Dies tritt auf, wenn eine neue öffentliche IP erstellt werden muss, um die Netzwerksicherheit für Zonenfehler zu erzielen. Planen Sie die Migration entsprechend.

  1. Beginnen Sie mit der Bestimmung, ob eine neue IP erforderlich ist und welche Ressourcen migriert werden müssen, um zonenresilient zu werden. Um den aktuellen Resilienzstatus der Verfügbarkeitszone für die Ressourcen des verwalteten Clusters abzurufen, verwenden Sie den folgenden API-Aufruf:

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

    Oder Sie können das Az-Modul wie folgt verwenden:

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

    Dies sollte die Antwort ähnlich wie folgt bieten:

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

    Wenn die öffentliche IP-Ressource nicht belastbar ist, führt die Migration des Clusters zu einem kurzen Verlust der externen Konnektivität. Dies ist darauf zurückzuführen, dass bei der Migration eine neue öffentliche IP eingerichtet und der FQDN des Clusters auf die neue IP aktualisiert wird. Wenn die öffentliche IP-Ressource resilient ist, ändert die Migration die öffentliche IP-Ressource oder FQDN nicht, und es gibt keine Auswirkungen auf die externe Konnektivität.

  2. Starten Sie die Migration des zugrunde liegenden Speicherkontos, das für verwalteten Cluster von LRS zu ZRS mit Livemigration erstellt wurde. Die Ressourcengruppe des Speicherkontos, das migriert werden muss, wäre das Formular „SFC_ClusterId“ (Bsp. SFC_9240df2f-71ab-4733-a641-53a84d992d) unter demselben Abonnement wie die verwaltete Clusterressource.

  3. Hinzufügen eines neuen primären Knotentyps, der sich auf Verfügbarkeitszonen erstreckt

    Dieser Schritt löst den Ressourcenanbieter aus, um die Migration des primären Knotentyps und der öffentlichen IP zusammen mit einem Cluster-FQDN-DNS-Update durchzuführen, falls erforderlich, um zonensicher zu werden. Verwenden Sie die obige API, um die Umsetzung dieses Schritts zu verstehen.

  • Verwenden Sie apiVersion 2022-02-01-preview oder höher.
  • Fügen Sie dem Cluster einen neuen primären Knotentyp hinzu, der auf [„1“, „2“, „3“] festgelegt ist, wie unten gezeigt:
{
  "apiVersion": "2022-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"]
    ...
  }
}
  1. Hinzufügen eines sekundären Knotentyps, der sich auf Verfügbarkeitszonen erstreckt Dieser Schritt fügt einen sekundären Knotentyp hinzu, der sich auf Verfügbarkeitszonen erstreckt, ähnlich dem primären Knotentyp. Sobald sie erstellt wurden, müssen Kunden vorhandene Dienste aus den alten Knotentypen in die neuen migrieren, indem Sie Platzierungseigenschaften verwenden.
  • Verwenden Sie apiVersion 2022-02-01-preview oder höher.

  • Fügen Sie dem Cluster einen neuen sekundären Knotentyp hinzu, der auf [„1“, „2“, „3“] festgelegt ist, wie unten gezeigt:

    {
       "apiVersion": "2022-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": false,
         "zones": ["1", "2", "3"]
         ...
       }
    }
    
  1. Beginnen Sie, ältere nicht az-Knotentypen aus dem Cluster zu entfernen.

    Sobald alle Ihre Dienste nicht mehr auf Ihren nicht zonenübergreifenden Knotentypen vorhanden sind, müssen Sie die alten Knotentypen entfernen. Beginnen Sie mit dem Entfernen der alten Knotentypen aus dem Cluster mithilfe von Portal oder Cmdlet. Entfernen Sie als letzten Schritt alle alten Knotentypen aus Ihrer Vorlage.

  2. Markieren des Clusters, der für Zonenfehler resilient ist

    Dieser Schritt hilft in zukünftigen Bereitstellungen, da alle zukünftigen Bereitstellungen von Knotentypen über Verfügbarkeitszonen hinweg bestehen und damit das Cluster weiterhin tolerant für AZ-Fehler bleibt. Legen Sie zonalResiliency: true in der Cluster-ARM-Vorlage fest, und führen Sie eine Bereitstellung aus, um Cluster als zonenresilient zu markieren und sicherzustellen, dass alle neuen Knotentypbereitstellungen über Verfügbarkeitszonen verfügen.

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

    Sie können den aktualisierten Status auch nach Abschluss im Portal unter Übersicht -> Eigenschaften wie Zonal resiliency True anzeigen.

  3. Überprüfen, dass alle Ressourcen zonenresilient sind

    Um den Resilienzstatus der Verfügbarkeitszone für die Ressourcen des verwalteten Clusters zu validieren, verwenden Sie den folgenden GET API-Aufruf:

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

    Dies sollte die Antwort ähnlich wie folgt bieten:

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

    Sollten Sie auf Probleme stoßen, wenden Sie sich bitte an den Support, um Hilfe zu erhalten.