Konfigurieren von Netzwerkeinstellungen für verwaltete Service Fabric-Cluster

Verwaltete Service Fabric-Cluster werden mit einer standardmäßigen Netzwerkkonfiguration erstellt. Diese Konfiguration besteht aus einem Azure Load Balancer mit einer öffentlichen IP-Adresse, einem virtuellen Netzwerk mit einem zugeordneten Subnetz und einer NSG, die für wichtige Clusterfunktionen konfiguriert ist. Es werden auch optionale NSG(-Netzwerksicherheitsgruppen)-Regeln angewendet, z. B. das standardmäßige Zulassen des gesamten ausgehenden Datenverkehrs, was die Kundenkonfiguration vereinfachen soll. In diesem Dokument wird erläutert, wie Sie die folgenden Netzwerkkonfigurationsoptionen und vieles mehr ändern:

• Verwalten von NSG-Regeln
• Verwalten des RDP-Zugriffs
• Verwalten der Lastenausgleichskonfiguration
• Aktivieren der öffentlichen IP-Adresse
• Aktivieren von IPv6
• Verwendung eines eigenen virtuellen Netzwerks
• Verwendung eines eigenen Lastenausgleichs
• Aktivieren des beschleunigten Netzwerkbetriebs
• Konfigurieren von Hilfssubnetzen

Verwalten von NSG-Regeln

Leitfaden zu NSG-Regeln

Berücksichtigen Sie die folgenden Überlegungen, wenn Sie neue NSG-Regeln für Ihren verwalteten Cluster erstellen.

• Verwaltete Service Fabric-Cluster reservieren den NSG-Regelprioritätsbereich 0 bis 999 für essenzielle Funktionen. Sie können keine benutzerdefinierten NSG-Regeln mit einem Prioritätswert unter 1000 erstellen.
• Verwaltete Service Fabric-Cluster reservieren den NSG-Regelprioritätsbereich 3001 bis 4000 für die Erstellung optionaler NSG-Regeln. Diese Regeln werden automatisch hinzugefügt, um die Konfiguration zu vereinfachen und zu beschleunigen. Sie können diese Regeln außer Kraft setzen, indem Sie benutzerdefinierte Regeln im Bereich 1000 bis 3000 hinzufügen.
• Benutzerdefinierte Regeln müssen eine Priorität im Bereich 1000 bis 3000 aufweisen.

Anwenden von NSG-Regeln

Verwaltete Service Fabric-Cluster ermöglichen Ihnen die Zuweisung von NSG-Regeln direkt in der Clusterressource Ihrer Bereitstellungsvorlage.

Verwenden Sie die Eigenschaft networkSecurityRules Ihrer Microsoft.ServiceFabric/managedclusters-Ressource (Version 2021-05-01 oder höher), um NSG-Regeln zuzuweisen. Beispiel:

{
  "apiVersion": "2021-05-01",
  "type": "Microsoft.ServiceFabric/managedclusters",
  "properties": {
    "networkSecurityRules": [
      {
        "name": "AllowCustomers",
        "protocol": "*",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "Internet",
        "destinationAddressPrefix": "*",
        "destinationPortRange": "33000-33499",
        "access": "Allow",
        "priority": 2001,
        "direction": "Inbound"
      },
      {
        "name": "AllowARM",
        "protocol": "*",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "AzureResourceManager",
        "destinationAddressPrefix": "*",
        "destinationPortRange": "33500-33699",
        "access": "Allow",
        "priority": 2002,
        "direction": "Inbound"
      },
      {
        "name": "DenyCustomers",
        "protocol": "*",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "Internet",
        "destinationAddressPrefix": "*",
        "destinationPortRange": "33700-33799",
        "access": "Deny",
        "priority": 2003,
        "direction": "Outbound"
      },
      {
        "name": "DenyRDP",
        "protocol": "*",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "*",
        "destinationAddressPrefix": "VirtualNetwork",
        "destinationPortRange": "3389",
        "access": "Deny",
        "priority": 2004,
        "direction": "Inbound",
        "description": "Override for optional SFMC_AllowRdpPort rule. This is required in tests to avoid Sev2 incident for security policy violation."
      }
    ],
    "fabricSettings": [
      "..."
    ]
  }
}

ClientConnection- und HttpGatewayConnection-Standardregeln und optionale Regeln

NSG-Regel: SFMC_AllowServiceFabricGatewayToSFRP

Es wird eine standardmäßige NSG-Regel hinzugefügt, um es dem Service Fabric-Ressourcenanbieter zu ermöglichen, auf den clientConnectionPort und den httpGatewayConnectionPort des Clusters zuzugreifen. Diese Regel erlaubt den Zugriff auf die Ports über das Diensttag „ServiceFabric“.

Hinweis

Diese Regel wird immer hinzugefügt und kann nicht außer Kraft gesetzt werden.

{
    "name": "SFMC_AllowServiceFabricGatewayToSFRP",
    "type": "Microsoft.Network/networkSecurityGroups/securityRules",
    "properties": {
        "description": "This is required rule to allow SFRP to connect to the cluster. This rule can't be overridden.",
        "protocol": "TCP",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "ServiceFabric",
        "destinationAddressPrefix": "VirtualNetwork",
        "access": "Allow",
        "priority": 500,
        "direction": "Inbound",
        "sourcePortRanges": [],
        "destinationPortRanges": [
            "19000",
            "19080"
        ]
    }
}

NSG-Regel: SFMC_AllowServiceFabricGatewayPorts

Diese optionale Regel ermöglicht es Kunden, auf SFX zuzugreifen, mit PowerShell eine Verbindung zum Cluster herzustellen und Cluster-API-Endpunkte in Service Fabric aus dem Internet zu nutzen, indem LB-Ports für clientConnectionPort und httpGatewayPort geöffnet werden.

Hinweis

Diese Regel wird nicht hinzugefügt, wenn bereits eine benutzerdefinierte Regel mit denselben Zugriffs-, Richtungs- und Protokollwerten für ein und denselben Port vorhanden ist. Sie können diese Regel mit benutzerdefinierten NSG-Regeln außer Kraft setzen.

{
    "name": "SFMC_AllowServiceFabricGatewayPorts",
    "type": "Microsoft.Network/networkSecurityGroups/securityRules",
    "properties": {
        "description": "Optional rule to open SF cluster gateway ports. To override add a custom NSG rule for gateway ports in priority range 1000-3000.",
        "protocol": "tcp",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "*",
        "destinationAddressPrefix": "VirtualNetwork",
        "access": "Allow",
        "priority": 3001,
        "direction": "Inbound",
        "sourcePortRanges": [],
        "destinationPortRanges": [
            "19000",
            "19080"
        ]
    }
}

Aktivieren des Zugriffs auf RDP-Ports über das Internet

Verwaltete Service Fabric-Cluster erlauben standardmäßig keinen Zugriff auf die RDP-Ports über das Internet. Sie können den eingehenden Zugriff auf RDP-Ports aus dem Internet aktivieren, indem Sie die folgende Eigenschaft in einer verwalteten Service Fabric-Clusterressource festlegen.

"allowRDPAccess": true

Wenn die Eigenschaft „allowRDPAccess“ auf TRUE festgelegt ist, wird Ihrer Clusterbereitstellung die folgende NSG-Regel hinzugefügt.

{
    "name": "SFMC_AllowRdpPort",
    "type": "Microsoft.Network/networkSecurityGroups/securityRules",
    "properties": {
        "description": "Optional rule to open RDP ports.",
        "protocol": "tcp",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "*",
        "destinationAddressPrefix": "VirtualNetwork",
        "access": "Allow",
        "priority": 3002,
        "direction": "Inbound",
        "sourcePortRanges": [],
        "destinationPortRange": "3389"
    }
}

Verwaltete Service Fabric-Cluster erstellen automatisch NAT-Regeln für eingehenden Datenverkehr für jede Instanz in einem Knotentyp. Wenn Sie die Portzuordnungen ermitteln möchten, mit denen Sie bestimmte Instanzen erreichen können (Clusterknoten), befolgen Sie die Schritte unten:

Suchen Sie mithilfe des Azure-Portals nach den NAT-Regeln für eingehenden Datenverkehr für den verwalteten Cluster für das Remotedesktopprotokoll (RDP).

1. Navigieren Sie zur verwalteten Clusterressourcengruppe innerhalb Ihres Abonnements, die mit dem folgenden Format benannt ist: SFC_{cluster-id}.

2. Wählen Sie den Lastenausgleich für den Cluster mit dem folgenden Format aus: LB-{cluster-name}.

3. Klicken Sie auf der Seite für Ihren Lastenausgleich auf „NAT-Regeln für eingehenden Datenverkehr“. Überprüfen Sie die NAT-Regeln für eingehenden Datenverkehr, um den eingehenden Front-End-Port zu bestätigen, um eine Portzuordnung für einen Knoten anzuzielen.

   Der folgende Screenshot zeigt die NAT-Regeln für eingehenden Datenverkehr für drei verschiedene Knotentypen:

   

   Standardmäßig befindet sich der Front-End-Port für Windows-Cluster im Bereich von 50000 und höher, und der Zielport ist 3389. Dies ist dem RDP-Dienst auf dem Zielknoten zugeordnet.

   Hinweis

   Wenn Sie das BYOLB-Feature benutzen und RDP verwenden möchten, müssen Sie dafür einen NAT-Pool separat konfigurieren. Dadurch werden nicht automatisch NAT-Regeln für diese Knotentypen erstellt.

4. Stellen Sie eine Remoteverbindung mit dem spezifischen Knoten (Skalierungsgruppeninstanz) her. Sie können den Benutzernamen und das Kennwort, die Sie beim Erstellen des Clusters erstellt haben, oder beliebige andere Anmeldeinformationen, die Sie konfiguriert haben, verwenden.

Der folgende Screenshot zeigt die Verwendung einer Remotedesktopverbindung, um eine Verbindung zum Apps-Knoten (Instanz 0) in einem Windows-Cluster herzustellen:

Ändern der Lastenausgleichs-Standardkonfiguration

Lastenausgleichsports

Verwaltete Service Fabric-Cluster erstellen eine NSG-Regel im Standardprioritätsbereich für alle LB-Ports (Lastenausgleich), die im Abschnitt „loadBalancingRules“ unter den Eigenschaften ManagedCluster konfiguriert sind. Diese Regel öffnet Lastenausgleichsports für eingehenden Datenverkehr aus dem Internet.

Hinweis

Diese Regel wird dem optionalen Prioritätsbereich hinzugefügt und kann durch Hinzufügen von benutzerdefinierten NSG-Regeln außer Kraft gesetzt werden.

{
    "name": "SFMC_AllowLoadBalancedPorts",
    "type": "Microsoft.Network/networkSecurityGroups/securityRules",
    "properties": {
        "description": "Optional rule to open LB ports",
        "protocol": "*",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "*",
        "destinationAddressPrefix": "VirtualNetwork",
        "access": "Allow",
        "priority": 3003,
        "direction": "Inbound",
        "sourcePortRanges": [],
        "destinationPortRanges": [
        "80", "8080", "4343"
        ]
    }
}

Lastenausgleichstests

Verwaltete Service Fabric-Cluster erstellen automatisch Lastenausgleichstests für Fabric Gateway-Ports sowie für alle Ports, die in den Eigenschaften für verwaltete Cluster im Abschnitt loadBalancingRules konfiguriert wurden.

{
  "value": [
    {
        "name": "FabricTcpGateway",
        "properties": {
            "provisioningState": "Succeeded",
            "protocol": "Tcp",
            "port": 19000,
            "intervalInSeconds": 5,
            "numberOfProbes": 2,
            "loadBalancingRules": [
                {
                    "id": "<>"
                }
            ]
        },
        "type": "Microsoft.Network/loadBalancers/probes"
    },
    {
        "name": "FabricHttpGateway",
        "properties": {
            "provisioningState": "Succeeded",
            "protocol": "Tcp",
            "port": 19080,
            "intervalInSeconds": 5,
            "numberOfProbes": 2,
            "loadBalancingRules": [
                {
                    "id": "<>"
                }
            ]
        },
        "type": "Microsoft.Network/loadBalancers/probes"
    },
    {
        "name": "probe1_tcp_8080",
        "properties": {
            "provisioningState": "Succeeded",
            "protocol": "Tcp",
            "port": 8080,
            "intervalInSeconds": 5,
            "numberOfProbes": 2,
            "loadBalancingRules": [
            {
                "id": "<>"
            }
        ]
      },
      "type": "Microsoft.Network/loadBalancers/probes"
    }
  ]
}

Aktivieren der öffentlichen IP-Adresse

Hinweis

Derzeit wird nur öffentliches IPv4 unterstützt.

Von Service Fabric verwaltete Clusterknoten benötigen keine eigene öffentliche IP-Adresse für die Kommunikation. In einigen Szenarien kann es jedoch vorkommen, dass ein Knoten über eine eigene öffentliche IP-Adresse verfügt, um mit dem Internet und öffentlichen Azure-Diensten zu kommunizieren. Zum Beispiel:

• Ein Beispiel sind etwa Spiele, bei denen eine Konsole eine direkte Verbindung mit einem virtuellen Cloudcomputer herstellen muss, der die Spielphysik verarbeitet.
• Ein weiteres Beispiel, bei dem virtuelle Computer regionsübergreifend gegenseitige externe Verbindungen herstellen müssen, sind verteilte Datenbanken.

Weitere Informationen zu ausgehenden Verbindungen in Azure finden Sie unter Grundlegendes zu ausgehenden Verbindungen.

Öffentliche IP-Adressen können nur für sekundäre Knotentypen aktiviert werden, da primäre Knotentypen für Service Fabric-Systemdienste reserviert sind. Führen Sie die Schritte im Abschnitt „Verwendung eines eigenen Lastenausgleichs“ dieses Artikels aus, um einen sekundären Knotentyp für Ihren verwalteten Cluster zu erstellen.

Azure weist verfügbare IP-Adressen dynamisch zu.

Hinweis

Das Aktivieren der öffentlichen IP-Adresse wird nur über die ARM-Vorlage unterstützt.

In den folgenden Schritten wird beschrieben, wie Sie öffentliche IP-Adressen auf Ihrem Knoten aktivieren.

1. Laden Sie Ihre ARM-Vorlage herunter.

2. Fügen Sie für jeden Knotentyp in der Vorlage enableNodePublicIP zur ARM-Vorlage hinzu:

   {
       "name": "<secondary_node_type_name>", 
       "apiVersion": "2023-02-01-preview", 
       "properties": { 
           "isPrimary" : false, 
           "vmImageResourceId": "/subscriptions/<your_subscription_id>/resourceGroups/<your_resource_group>/providers/Microsoft.Compute/images/<your_custom_image>", 
           "vmSize": "Standard_D2", 
           "vmInstanceCount": 5, 
           "dataDiskSizeGB": 100, 
           "enableNodePublicIP": true 
       }
   } 
   

3. Bereitstellen Ihrer ARM-Vorlage.

4. Überprüfen Sie, ob Sie über eine öffentliche IP-Adresse auf Ihren Knoten verfügen, indem Sie den folgenden PowerShell-Befehl ausführen:

   az vmss list-instance-public-ips -g MC_MyResourceGroup2_MyManagedCluster_eastus -n YourVirtualMachineScaleSetName
   

   Der Befehl wird im JSON-Format ausgegeben.

   [
     {
       "etag": "etag_0",
       "id": "<id_0/name>",
       "idleTimeoutInMinutes": 15,
       "ipAddress": "<ip_address_0>",
       "ipConfiguration": {
         "id": "<configuration_id_0>",
         "resourceGroup": "<your_resource_group>"
       },
       "ipTags": [],
       "name": "<name>",
       "provisioningState": "Succeeded",
       "publicIPAddressVersion": "IPv4",
       "publicIPAllocationMethod": "Static",
       "resourceGroup": "<your_resource_group>",
       "resourceGuid": "resource_guid_0",
       "sku": {
         "name": "Standard"
       }
     },
     {
       "etag": "etag_1",
       "id": "/<id_1/name>",
       "idleTimeoutInMinutes": 15,
       "ipAddress": "<ip_address_1>",
       "ipConfiguration": {
         "id": "<configuration_id_1>",
         "resourceGroup": "<your_resource_group>"
       },
       "ipTags": [],
       "name": "<name>",
       "provisioningState": "Succeeded",
       "publicIPAddressVersion": "IPv4",
       "publicIPAllocationMethod": "Static",
       "resourceGroup": "<your_resource_group>",
       "resourceGuid": "resource_guid_1",
       "sku": {
         "name": "Standard"
       }
     },
     {
       "etag": "etag_2",
       "id": "<id_2/name>",
       "idleTimeoutInMinutes": 15,
       "ipAddress": "<ip_address_2>",
       "ipConfiguration": {
         "id": "<configuration_id_2>",
         "resourceGroup": "<your_resource_group>"
       },
       "ipTags": [],
       "name": "<name>",
       "provisioningState": "Succeeded",
       "publicIPAddressVersion": "IPv4",
       "publicIPAllocationMethod": "Static",
       "resourceGroup": "<your_resource_group>",
       "resourceGuid": "resource_guid_2",
       "sku": {
         "name": "Standard"
       }
     }
   ]
   

Aktivieren von IPv6

Verwaltete Cluster aktivieren IPv6 nicht standardmäßig. Dieses Feature ermöglicht eine vollständige IPv4/IPv6-Funktion mit dualen Stapeln vom Load Balancer-Front-End zu den Back-End-Ressourcen. Alle Änderungen, die Sie an der Lastenausgleichskonfiguration oder den NSG-Regeln des verwalteten Clusters vornehmen, wirken sich sowohl auf das IPv4- als auch auf das IPv6-Routing aus.

Hinweis

Diese Einstellung ist im Portal nicht verfügbar und kann nach der Erstellung des Clusters nicht mehr geändert werden.

• Die apiVersion der verwalteten Service Fabric-Clusterressource sollte 2022-01-01 oder höher lauten.

1. Legen Sie die folgende Eigenschaft in einer verwalteten Service Fabric-Clusterressource fest.

       "resources": [
            {
            "apiVersion": "[variables('sfApiVersion')]",
            "type": "Microsoft.ServiceFabric/managedclusters",
            ...
            "properties": {
                "enableIpv6": true
                },
            }
       ]
   

2. Stellen Sie Ihren IPv6-fähigen verwalteten Cluster bereit. Passen Sie die Beispielvorlage nach Bedarf an oder erstellen Sie Ihre eigene Vorlage. Im folgenden Beispiel erstellen wir eine Ressourcengruppe namens MyResourceGroup in westus und stellen einen Cluster bereit, in dem diese Funktion aktiviert ist.

    New-AzResourceGroup -Name MyResourceGroup -Location westus
    New-AzResourceGroupDeployment -Name deployment -ResourceGroupName MyResourceGroup -TemplateFile AzureDeploy.json
   

   Nach der Bereitstellung befinden sich das virtuelle Netzwerk und die Ressourcen Ihrer Cluster im dualen Stapel. Daher verfügt der Front-End-Lastenausgleich des Clusters über eine eindeutige DNS-Adresse, z. B. mycluster-ipv6.southcentralus.cloudapp.azure.com, die einer öffentlichen IPv6-Adresse auf dem Azure Load Balancer und privaten IPv6-Adressen auf den VMs zugeordnet ist.

Verwendung eines eigenen virtuellen Netzwerks

Mit diesem Feature können Kunden ein vorhandenes virtuelles Netzwerk verwenden, indem sie ein dediziertes Subnetz angeben, in dem der verwaltete Cluster seine Ressourcen bereitstellt. Dies kann nützlich sein, wenn Sie bereits über ein konfiguriertes virtuelles Netzwerk und Subnetz mit zugehörigen Sicherheitsrichtlinien und Datenverkehrsrouting verfügen, die Sie verwenden möchten. Sobald die Bereitstellung an ein vorhandenes virtuelles Netzwerk durch Sie erfolgt ist, ist es einfach, andere Netzwerkfeatures wie Azure ExpressRoute, Azure-VPN-Gateway, eine Netzwerksicherheitsgruppe und Peering virtueller Netzwerke zu integrieren. Darüber hinaus können Sie bei Bedarf Ihren eigenen Azure-Lastenausgleich verwenden.

Hinweis

Bei Verwendung von BYOVNET werden verwaltete Clusterressourcen in einem Subnetz bereitgestellt.

Hinweis

Diese Einstellung kann nicht mehr geändert werden, nachdem der Cluster erstellt wurde, und der verwaltete Cluster weist dem bereitgestellten Subnetz eine NSG zu. Setzen Sie die NSG-Zuweisung nicht außer Kraft, da der Datenverkehr möglicherweise unterbrochen wird.

Verwendung eines eigenen virtuellen Netzwerks:

1. Sie können den Dienst Id aus Ihrem Abonnement für die Service Fabric-Ressourcenanbieteranwendung erhalten.

   Login-AzAccount
   Select-AzSubscription -SubscriptionId <SubId>
   Get-AzADServicePrincipal -DisplayName "Azure Service Fabric Resource Provider"
   

   Hinweis

   Stellen Sie sicher, dass Sie sich im richtigen Abonnement befinden. Die Prinzipal-ID ändert sich, wenn sich das Abonnement in einem anderen Mandanten befindet.

   ServicePrincipalNames : {74cb6831-0dbb-4be1-8206-fd4df301cdc2}
   ApplicationId         : 74cb6831-0dbb-4be1-8206-fd4df301cdc2
   ObjectType            : ServicePrincipal
   DisplayName           : Azure Service Fabric Resource Provider
   Id                    : 00000000-0000-0000-0000-000000000000
   

   Notieren Sie sich die ID aus der vorstehenden Ausgabe als principalId für die Verwendung in einem späteren Schritt.

   Name der Rollendefinition	Rollendefinitions-ID
   Mitwirkender von virtuellem Netzwerk	4d97b98b-1d4f-4787-a291-c67834d212e7

   Notieren Sie sich die Eigenschaftswerte Role definition name und Role definition ID für die Verwendung in einem späteren Schritt.

2. Fügen Sie der Service Fabric-Ressourcenanbieteranwendung eine Rollenzuweisung hinzu. Das Hinzufügen einer Rollenzuweisung ist eine einmalige Aktion. Sie fügen die Rolle hinzu, indem Sie die folgenden PowerShell-Befehle ausführen oder wie unten beschrieben eine ARM-Vorlage (Azure Resource Manager-Vorlage) konfigurieren.

   In den folgenden Schritten beginnen wir mit einem vorhandenen virtuellen Netzwerk mit dem Namen „ExistingRG-vnet“ in der Ressourcengruppe „ExistingRG“. Das Subnetz ist standardmäßig benannt.

   Rufen Sie die erforderlichen Informationen aus dem vorhandenen virtuellen Netzwerk ab.

   Login-AzAccount
   Select-AzSubscription -SubscriptionId <SubId>
   Get-AzVirtualNetwork -Name ExistingRG-vnet -ResourceGroupName ExistingRG
   

   Notieren Sie sich den folgenden Subnetznamen und den Eigenschaftswert Id, der vom Abschnitt Subnets in der Antwort ausgegeben wird, für die Antwort, die Sie in späteren Schritten verwenden werden.

   Subnets:[
   {
   ...
   "Id": "/subscriptions/<subscriptionId>/resourceGroups/Existing-RG/providers/Microsoft.Network/virtualNetworks/ExistingRG-vnet/subnets/default"
   }]
   

   Führen Sie den folgenden PowerShell-Befehl mithilfe der Prinzipal-ID, des Rollendefinitionsnamens aus Schritt 2 und des oben abgerufenen Zuweisungsbereichs Id aus:

   New-AzRoleAssignment -PrincipalId 00000000-0000-0000-0000-000000000000 -RoleDefinitionName "Network Contributor" -Scope "/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/<subnetName>"
   

   Sie können die Rollenzuweisung auch mithilfe einer ARM-Vorlage (Azure Resource Manager-Vorlage) hinzufügen, die mit den richtigen Werten für principalId, roleDefinitionId, vnetName und subnetName konfiguriert ist:

      "type": "Microsoft.Authorization/roleAssignments",
      "apiVersion": "2020-04-01-preview",
      "name": "[parameters('VNetRoleAssignmentID')]",
      "scope": "[concat('Microsoft.Network/virtualNetworks/', parameters('vnetName'), '/subnets/', parameters('subnetName'))]",
      "dependsOn": [
        "[concat('Microsoft.Network/virtualNetworks/', parameters('vnetName'))]"
      ],
      "properties": {
        "roleDefinitionId": "[concat('/subscriptions/', subscription().subscriptionId, '/providers/Microsoft.Authorization/roleDefinitions/4d97b98b-1d4f-4787-a291-c67834d212e7')]",
        "principalId": "00000000-0000-0000-0000-000000000000"
      }
   

   Hinweis

   VNetRoleAssignmentID muss eine GUID sein. Wenn Sie eine Vorlage erneut bereitstellen, einschließlich dieser Rollenzuweisung, vergewissern Sie sich, dass die GUID die gleiche wie die ursprünglich verwendete ist. Wir empfehlen, dies isoliert auszuführen oder nach der Bereitstellung diese Ressource aus der Clustervorlage zu entfernen, da sie nur einmal erstellt werden muss.

   Im Folgenden finden Sie ein Beispiel einer vollständigen Azure Resource Manager (ARM)-Vorlage, die ein Subnetz eines virtuellen Netzwerks erstellt und die Rollenzuweisung durchführt. Diese Vorlage können Sie für diesen Schritt verwenden.

3. Konfigurieren Sie die Eigenschaft subnetId für die Clusterbereitstellung, nachdem die Rolle wie unten gezeigt eingerichtet wurde:

• Die apiVersion der verwalteten Service Fabric-Clusterressource sollte 2022-01-01 oder höher lauten.

    "resources": [
        {
            "apiVersion": "[variables('sfApiVersion')]",
            "type": "Microsoft.ServiceFabric/managedclusters",
            ...
            },
            "properties": {
                "subnetId": "subnetId",
            ...
            }
    ]
  

  Nutzen Sie die Beispielvorlage zur Verwendung eines eigenen Clusters in einem virtuellen Netzwerk, oder passen Sie Ihre eigene Instanz an.

4. Stellen Sie die konfigurierte Azure Resource Manager(ARM)-Vorlage für verwaltete Cluster bereit.

   Im folgenden Beispiel erstellen wir eine Ressourcengruppe namens MyResourceGroup in westus und stellen einen Cluster bereit, in der diese Funktion aktiviert ist.

    New-AzResourceGroup -Name MyResourceGroup -Location westus
    New-AzResourceGroupDeployment -Name deployment -ResourceGroupName MyResourceGroup -TemplateFile AzureDeploy.json
   

   Wenn Sie ein Subnetz Ihres eigenes virtuellen Netzwerks verwenden, wird der öffentliche Endpunkt weiterhin vom Ressourcenanbieter erstellt und verwaltet, jedoch im konfigurierten Subnetz. Die Funktion lässt nicht zu, dass Sie die öffentliche IP-Adresse angeben bzw. die statische IP-Adresse auf dem Azure Load Balancer erneut verwenden. Sie können Ihren eigenen Azure Load Balancer verwenden, und zwar zusammen mit dieser Funktion oder allein, wenn Sie diese oder andere Lastenausgleichs-Szenarien benötigen, die nicht nativ unterstützt werden.

   Beim Erstellen des Clusters wird eine Netzwerksicherheitsgruppe in der verwalteten Ressourcengruppe für das standardmäßige Subnetz auf Clusterebene erstellt. Wenn ein Knotentyp erstellt wird, wird er in diesem Subnetz platziert und erbt automatisch die Regeln der Netzwerksicherheitsgruppe, es sei denn, Sie verwenden Subnetze auf Knotentypebene.

   Mit Ihrem eigenen virtuellen Netzwerk werden auch Subnetze auf Knotentypebene unterstützt, mit denen Sie Knotentypen in separaten Subnetzen platzieren können. Dies bietet Flexibilität für verschiedene Netzwerkkonfigurationen und Netzwerksetups.

   "resources": [
     {
       "apiVersion": "[variables('sfApiVersion')]",
       "type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
       ...
       },
       "properties": {
         "subnetId": "subnetId",
         ...
       }
   ]
   

   Wenn Sie Subnetze auf Knotentypebene verwenden möchten, geben Sie "useCustomVnet": true in Ihrer verwalteten Clusterdefinition an. Wenn "useCustomVnet" auf true festgelegt ist, wird kein Standardcluster-Subnetz erstellt. Bei Verwendung von Subnetzen auf Knotentypebene wird subnetId zu einer erforderlichen Eigenschaft in der Knotentypdefinition.

   Wichtig

   Bei Verwendung von Subnetzen auf Knotentypebene müssen Sie dem Subnetz des Knotentyps vor der Erstellung des Knotentyps eine Netzwerksicherheitsgruppe zuweisen. Die Netzwerksicherheitsgruppe muss die erforderliche Eingangsregel SFMC_AllowServiceFabricGatewayToSFRP enthalten. Andernfalls schlägt die Knotentyperstellung fehl.

Verwendung einer eigenen Azure Load Balancer-Instanz

Verwaltete Cluster erstellen einen öffentlichen standardisierten Azure Load Balancer und einen vollqualifizierten Domänennamen mit einer statischen öffentlichen IP-Adresse für den primären und sekundären Knotentyp. Mit der Funktion „bring your own load balancer“ (eigenen Load Balancer einbringen) können Sie einen vorhandenen Azure Load Balancer für sekundäre Knotentypen sowohl für eingehenden als auch für ausgehenden Datenverkehr verwenden. Wenn Sie Ihren eigenen Azure Load Balancer verwenden, können Sie Folgendes:

• Eine vorkonfigurierte statische IP-Adresse für den Load Balancer für privaten oder öffentlichen Datenverkehr nutzen
• Einen Load Balancer einem bestimmten Knotentyp zuordnen.
• Konfigurieren Sie Netzwerksicherheitsgruppenregeln pro Knotentyp, da jeder Knotentyp in einem eigenen Subnetz bereitgestellt wird
• Eventuell vorhandene Richtlinien und Kontrollen verwalten.
• Konfigurieren eines ausschließlich internen Lastenausgleichs (Load Balancer) und Verwenden des Standardlastenausgleichs für externen Datenverkehr

Hinweis

Bei Verwendung von BYOVNET werden verwaltete Clusterressourcen unabhängig von zusätzlichen konfigurierten Lastenausgleichsressourcen in einem Subnetz mit einer NSG bereitgestellt.

Hinweis

Sie können nach der Bereitstellung eines Knotentyps nicht vom Standardlastenausgleich zu einem benutzerdefinierten Lastenausgleich (Load Balancer) wechseln, aber Sie können die Konfiguration des benutzerdefinierten Lastenausgleichs nach der Bereitstellung ändern, wenn diese aktiviert ist.

Funktionsanforderungen

• SKU-Typen „Basic Azure Load Balancer“ und „Standard Azure Load Balancer“ werden unterstützt.
• Back-End- und NAT-Pools müssen auf dem Azure Load Balancer konfiguriert werden.
• Sie müssen die ausgehende Konnektivität entweder mithilfe eines bereitgestellten öffentlichen Lastenausgleichs oder des öffentlichen Standardlastenausgleichs aktivieren.

Hier sind einige Beispielszenarien, in denen Kunden dies verwenden können:

In diesem Beispiel möchte ein Kunde Datenverkehr über eine vorhandene Azure Load Balancer-Instanz, die mit einer vorhandenen statischen IP-Adresse konfiguriert ist, an zwei Knotentypen weiterleiten.

In diesem Beispiel möchte ein Kunde Datenverkehr über vorhandene Azure Load Balancers routen. Dies soll dazu dienen, ihn bei der unabhängigen Verwaltung des Datenverkehrsflusses zu seinen Anwendungen zu unterstützen, die auf separaten Knotentypen ausgeführt werden. Bei der Einrichtung wie in diesem Beispiel befindet sich jeder Knotentyp hinter seiner eigenen verwalteten NSG.

In diesem Beispiel möchte ein Kunde Datenverkehr über vorhandene interne Azure Load-Balancer-Systeme routen. Dies hilft ihnen, den Datenverkehrsfluss zu ihren Anwendungen unabhängig voneinander zu verwalten, die auf separaten Knotentypen ausgeführt werden. Bei der Einrichtung wie in diesem Beispiel befindet sich jeder Knotentyp hinter seiner eigenen verwalteten NSG und verwendet den Standardlastenausgleich für externen Datenverkehr.

So nehmen Sie die Konfiguration mit einem eigenen Lastenausgleich vor

1. Sie können den Dienst Id aus Ihrem Abonnement für die Service Fabric-Ressourcenanbieteranwendung erhalten:

   Login-AzAccount
   Select-AzSubscription -SubscriptionId <SubId>
   Get-AzADServicePrincipal -DisplayName "Azure Service Fabric Resource Provider"
   

   Hinweis

   Stellen Sie sicher, dass Sie sich im richtigen Abonnement befinden. Die Prinzipal-ID ändert sich, wenn sich das Abonnement in einem anderen Mandanten befindet.

   ServicePrincipalNames : {74cb6831-0dbb-4be1-8206-fd4df301cdc2}
   ApplicationId         : 74cb6831-0dbb-4be1-8206-fd4df301cdc2
   ObjectType            : ServicePrincipal
   DisplayName           : Azure Service Fabric Resource Provider
   Id                    : 00000000-0000-0000-0000-000000000000
   

   Notieren Sie sich die ID aus der vorstehenden Ausgabe als principalId für die Verwendung in einem späteren Schritt.

   Name der Rollendefinition	Rollendefinitions-ID
   Mitwirkender von virtuellem Netzwerk	4d97b98b-1d4f-4787-a291-c67834d212e7

   Notieren Sie sich die Eigenschaftswerte Role definition name und Role definition ID für die Verwendung in einem späteren Schritt.

2. Fügen Sie der Service Fabric-Ressourcenanbieteranwendung eine Rollenzuweisung hinzu. Das Hinzufügen einer Rollenzuweisung ist eine einmalige Aktion. Sie fügen die Rolle hinzu, indem Sie die folgenden PowerShell-Befehle ausführen oder wie unten beschrieben eine ARM-Vorlage (Azure Resource Manager-Vorlage) konfigurieren.

   In den folgenden Schritten beginnen wir mit einem vorhandenen Lastenausgleich mit dem Namen Existing-LoadBalancer1 in der Ressourcengruppe Existing-RG.

   Rufen Sie die erforderlichen Id-Eigenschaftsinformationen aus dem vorhandenen Azure Load Balancer ab.

   Login-AzAccount
   Select-AzSubscription -SubscriptionId <SubId>
   Get-AzLoadBalancer -Name "Existing-LoadBalancer1" -ResourceGroupName "Existing-RG"
   

   Beachten Sie folgenden Id, den Sie im nächsten Schritt verwenden:

   {
   ...
   "Id": "/subscriptions/<subscriptionId>/resourceGroups/Existing-RG/providers/Microsoft.Network/loadBalancers/Existing-LoadBalancer1"
   }
   

   Führen Sie den folgenden PowerShell-Befehl mithilfe der Prinzipal-ID, des Rollendefinitionsnamens aus Schritt 2 und des oben abgerufenen Zuweisungsbereichs Id aus:

   New-AzRoleAssignment -PrincipalId 00000000-0000-0000-0000-000000000000 -RoleDefinitionName "Network Contributor" -Scope "/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/loadBalancers/<LoadBalancerName>"
   

   Sie können die Rollenzuweisung auch mithilfe einer ARM-Vorlage (Azure-Ressourcen-Manager-Vorlage) hinzufügen, die mit den richtigen Werten für principalId, roleDefinitionId“ konfiguriert ist:

      "type": "Microsoft.Authorization/roleAssignments",
      "apiVersion": "2020-04-01-preview",
      "name": "[parameters('loadBalancerRoleAssignmentID')]",
      "scope": "[concat('Microsoft.Network/loadBalancers/', variables('lbName'))]",
      "dependsOn": [
        "[concat('Microsoft.Network/loadBalancers/', variables('lbName'))]"
      ],
      "properties": {
        "roleDefinitionId": "[concat('/subscriptions/', subscription().subscriptionId, '/providers/Microsoft.Authorization/roleDefinitions/4d97b98b-1d4f-4787-a291-c67834d212e7')]",
        "principalId": "00000000-0000-0000-0000-000000000000"
      }
   

   Hinweis

   loadBalancerRoleAssignmentID muss eine GUID sein. Wenn Sie eine Vorlage erneut bereitstellen, einschließlich dieser Rollenzuweisung, vergewissern Sie sich, dass die GUID die gleiche wie die ursprünglich verwendete ist. Wir empfehlen, dies isoliert auszuführen oder nach der Bereitstellung diese Ressource aus der Clustervorlage zu entfernen, da sie nur einmal erstellt werden muss.

   In dieser Beispielvorlage erfahren Sie, wie Sie einen öffentlichen Lastenausgleich erstellen und eine Rolle zuweisen.

3. Konfigurieren Sie die erforderliche ausgehende Konnektivität für den Knotentyp. Sie müssen einen öffentlichen Lastenausgleich konfigurieren, um ausgehende Verbindungen zu ermöglichen, oder den öffentlichen Standardlastenausgleich verwenden.

   Konfigurieren Sie outboundRules, um einen öffentlichen Load Balancer für die Bereitstellung ausgehender Konnektivität zu konfigurieren. Weitere Informationen finden Sie im Beispiel zum Erstellen eines Lastenausgleichs und Zuweisen eines Rolle-Samples in einer Azure Ressourcen-Manager(ARM)-Vorlage.

   oder

   Um den Knotentyp für die Verwendung des Standardlastenausgleichs zu konfigurieren, legen Sie Folgendes in Ihrer Vorlage fest:

   • Die apiVersion der verwalteten Service Fabric-Clusterressource sollte 2022-01-01 oder höher lauten.

    "resources": [
      {
      "apiVersion": "[variables('sfApiVersion')]",
      "type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
      "properties": {
          "isPrimary": false,
          "useDefaultPublicLoadBalancer": true
          }
      }
    ]
   

4. Konfigurieren Sie optional einen eingehenden Anwendungsport und einen zugehörigen Test für Ihren Azure Load Balancer. Ein Beispiel hierfür finden Sie unter „Verwendung eines eigenen Lastenausgleichs-Samples in einer Azure Ressourcen-Manager-(ARM-)Vorlage“.

5. Konfigurieren Sie optional die NSG-Regeln des verwalteten Clusters, die auf den Knotentyp angewendet werden, um jeglichen erforderlichen Datenverkehr zu ermöglichen, den Sie auf dem Azure Load Balancer konfiguriert haben, oder der Datenverkehr wird blockiert. Ein Beispiel für eingehenden NSG-Regel-Konfiguration finden Sie unter „Verwendung eines eigenen Lastenausgleich-Samples in einer Azure Ressourcen-Manager(ARM)-Vorlage“. Suchen Sie in der Vorlage nach der Eienschaft networkSecurityRules.

6. Bereitstellen der konfigurierten ARM-Vorlage für verwaltete Cluster: In diesem Schritt verwenden wir die Arm-Vorlage Verwendung eines eigenen Lastenausgleich-Samples in einer Azure Ressourcen-Manager(ARM)-Vorlage (Bring your own load balancer sample Azure Resource Manager (ARM) template).

   Im Folgenden wird eine Ressourcengruppe namens MyResourceGroup in westus erstellt und ein Cluster wird mithilfe eines vorhandenen Lastenausgleichs bereitgestellt.

    New-AzResourceGroup -Name MyResourceGroup -Location westus
    New-AzResourceGroupDeployment -Name deployment -ResourceGroupName MyResourceGroup -TemplateFile AzureDeploy.json
   

   Nach der Bereitstellung ist der sekundäre Knotentyp für die Verwendung des angegebenen Lastenausgleichs für eingehenden und ausgehenden Datenverkehr konfiguriert. Die Service Fabric-Clientverbindungs- und -Gatewayendpunkte verweisen weiterhin auf das öffentliche DNS der statischen IP-Adresse des primären Knotentyps des verwalteten Clusters.

Aktivieren des beschleunigten Netzwerkbetriebs

Der beschleunigte Netzwerkbetrieb ermöglicht die E/A-Virtualisierung mit einzelnem Stamm (Single Root I/O Virtualization, SR-IOV) für einen virtuellen Computer (VM) der VM-Skalierunggruppe, die die zugrunde liegende Ressource für Knotentypen ist. Dieser Hochleistungspfad umgeht den Host vom Datenpfad, wodurch Latenz, Jitter und CPU-Auslastung für die anspruchsvollsten Netzwerkworkloads reduziert werden. Von Service Fabric verwaltete Clusterknotentypen können mit beschleunigtem Netzwerkbetrieb auf unterstützten SKUs virtueller Computer bereitgestellt werden. Weitere Informationen finden Sie unter Einschränkungen und Bedingungen.

• Bitte beachten Sie, dass der beschleunigte Netzwerkbetrieb in den meisten universellen, compute-optimierten Instanzgrößen mit mindestens 2 vCPUs unterstützt wird. Bei Instanzen, die Hyperthreading unterstützen, wird der beschleunigte Netzwerkbetrieb auf VM-Instanzen mit mindestens 4 vCPUs unterstützt.

Aktivieren Sie den beschleunigten Netzwerkbetrieb, indem Sie die Eigenschaft enableAcceleratedNetworking in Ihrer Ressourcen-Manager-Vorlage wie folgt deklarieren:

• Die apiVersion der verwalteten Service Fabric-Clusterressource sollte 2022-01-01 oder höher lauten.

   {
   "apiVersion": "[variables('sfApiVersion')]",
   "type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
   ...
   "properties": {
       ...
       "enableAcceleratedNetworking": true,
       ...
   }

Um den beschleunigten Netzwerkbetrieb für einen vorhandenen Service-Fabric-Cluster zu aktivieren, müssen Sie zunächst einen Service-Fabric-Cluster erweitern, indem Sie einen neuen Knotentyp hinzufügen und Folgendes ausführen:

1. Bereitstellen eines Knotentyps mit aktiviertem beschleunigten Netzwerkbetrieb
2. Migrieren Ihrer Dienste und deren Status zum bereitgestellten Knotentyp mit aktiviertem beschleunigten Netzwerkbetrieb

Die Erweiterung der Infrastruktur ist erforderlich, um beschleunigten Netzwerkbetrieb für einen vorhandenen Cluster zu ermöglichen, da die Aktivierung von beschleunigtem Netzwerkbetrieb zu Ausfallzeiten führen würde, da alle virtuellen Computer in einer Verfügbarkeitsgruppe beendet werden müssen und ihre Zuordnung aufgehoben werden muss, bevor beschleunigter Netzwerkbetrieb für eine vorhandene NIC aktiviert werden kann.

Konfigurieren von Hilfssubnetzen

Zusätzliche Subnetze bieten die Möglichkeit, zusätzliche verwaltete Subnetze ohne Knotentyp zum Unterstützen von Fallszenarien wie Private Link Service und Bastion-Hosts zu erstellen.

Konfigurieren Sie weitere Subnetze, indem Sie die Eigenschaft auxiliarySubnets und die erforderlichen Parameter in Ihrer Ressourcen-Manager-Vorlage wie folgt deklarieren:

• Die apiVersion der verwalteten Service Fabric-Clusterressource sollte 2022-01-01 oder höher lauten.

    "resources": [
        {
            "apiVersion": "[variables('sfApiVersion')]",
            "type": "Microsoft.ServiceFabric/managedclusters",
              "properties": {
                "auxiliarySubnets": [
                  {
                  "name" : "mysubnet",
                  "enableIpv6" : "true"
                  }
                ]
              }
        }
    ]              

Siehe vollständige Liste der verfügbaren Parameter

Nächste Schritte

Konfigurationsoptionen für verwaltete verwaltete Service Fabric-ClusterVerwaltete Service Fabric-Cluster – Übersicht