Netwerkinstellingen configureren voor beheerde Service Fabric-clusters

Beheerde Service Fabric-clusters worden gemaakt met een standaardnetwerkconfiguratie. Deze configuratie bestaat uit een Azure Load Balancer met een openbaar IP-adres, een VNet met één subnet toegewezen en een NSG die is geconfigureerd voor essentiële clusterfunctionaliteit. Er zijn ook optionele NSG-regels toegepast, zoals het standaard toestaan van al het uitgaande verkeer dat is bedoeld om de configuratie van de klant eenvoudiger te maken. In dit document wordt uitgelegd hoe u de volgende configuratieopties voor netwerken kunt wijzigen en meer:

NSG-regels beheren

Richtlijnen voor NSG-regels

Houd rekening met deze overwegingen bij het maken van nieuwe NSG-regels voor uw beheerde cluster.

  • Beheerde Service Fabric-clusters reserveren het prioriteitsbereik van de NSG-regel 0 tot 999 voor essentiële functionaliteit. U kunt geen aangepaste NSG-regels maken met een prioriteitswaarde van minder dan 1000.
  • Beheerde Service Fabric-clusters reserveren het prioriteitsbereik 3001 tot 4000 voor het maken van optionele NSG-regels. Deze regels worden automatisch toegevoegd om configuraties snel en eenvoudig te maken. U kunt deze regels overschrijven door aangepaste NSG-regels toe te voegen in het prioriteitsbereik 1000 tot 3000.
  • Aangepaste NSG-regels moeten een prioriteit hebben binnen het bereik van 1000 tot 3000.

NSG-regels toepassen

Met beheerde Service Fabric-clusters kunt u NSG-regels rechtstreeks binnen de clusterresource van uw implementatiesjabloon toewijzen.

Gebruik de eigenschap networkSecurityRules van uw Resource Microsoft.ServiceFabric/managedclusters (versie 2021-05-01 of hoger) om NSG-regels toe te wijzen. Bijvoorbeeld:

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

Standaard- en optionele regels voor ClientConnection en HttpGatewayConnection

NSG-regel: SFMC_AllowServiceFabricGatewayToSFRP

Er wordt een standaard-NSG-regel toegevoegd om de Service Fabric-resourceprovider toegang te geven tot de clientConnectionPort en httpGatewayConnectionPort van het cluster. Met deze regel verleent u toegang tot de poorten via de servicetag 'ServiceFabric'.

Notitie

Deze regel wordt altijd toegevoegd en kan niet worden overschreven.

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

Met deze optionele regel kunnen klanten toegang krijgen tot SFX, verbinding maken met het cluster met behulp van PowerShell en Service Fabric-cluster-API-eindpunten gebruiken vanaf internet door LB-poorten te openen voor clientConnectionPort en httpGatewayPort.

Notitie

Deze regel wordt niet toegevoegd als er een aangepaste regel is met dezelfde toegangs-, richtings- en protocolwaarden voor dezelfde poort. U kunt deze regel overschrijven met aangepaste NSG-regels.

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

Toegang tot RDP-poorten via internet inschakelen

Beheerde Service Fabric-clusters schakelen standaard geen inkomende toegang tot de RDP-poorten via internet in. U kunt binnenkomende toegang tot de RDP-poorten openen vanaf internet door de volgende eigenschap in te stellen op een beheerde Service Fabric-clusterresource.

"allowRDPAccess": true

Wanneer de eigenschap allowRDPAccess is ingesteld op true, wordt de volgende NSG-regel toegevoegd aan uw clusterimplementatie.

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

Beheerde Service Fabric-clusters maken automatisch binnenkomende NAT-regels voor elk exemplaar in een knooppunttype. Volg de onderstaande stappen om de poorttoewijzingen te vinden om specifieke exemplaren (clusterknooppunten) te bereiken:

Zoek met behulp van Azure Portal het beheerde cluster dat inkomende NAT-regels voor RdP (Remote Desktop Protocol) heeft gemaakt.

  1. Navigeer naar de beheerde clusterresourcegroep in uw abonnement met de naam met de volgende indeling: SFC_{cluster-id}

  2. Selecteer de load balancer voor het cluster met de volgende indeling: LB-{cluster-name}

  3. Selecteer inkomende NAT-regels op de pagina voor uw load balancer. Controleer de binnenkomende NAT-regels om de binnenkomende front-endpoort naar de doelpoorttoewijzing voor een knooppunt te bevestigen.

    In de volgende schermopname ziet u de binnenkomende NAT-regels voor drie verschillende knooppunttypen:

    Inkomende NAT-regels

    Voor Windows-clusters bevindt de front-endpoort zich standaard in het bereik 50000 en hoger en is de doelpoort poort 3389, die wordt toegewezen aan de RDP-service op het doelknooppunt.

    Notitie

    Als u de FUNCTIE BYOLB gebruikt en RDP wilt gebruiken, moet u een NAT-pool afzonderlijk configureren om dit te doen. Hiermee worden niet automatisch NAT-regels voor deze knooppunttypen gemaakt.

  4. Extern verbinding maken met het specifieke knooppunt (schaalsetexemplaar). U kunt de gebruikersnaam en het wachtwoord gebruiken die u hebt ingesteld bij het maken van het cluster of andere referenties die u hebt geconfigureerd.

In de volgende schermopname ziet u hoe u Verbinding met extern bureaublad gebruikt om verbinding te maken met het knooppunt apps (exemplaar 0) in een Windows-cluster:

Verbinding met extern bureaublad

Standaardconfiguratie van load balancer wijzigen

Load balancer-poorten

Beheerde Service Fabric-clusters maken een NSG-regel in het standaardprioriteitsbereik voor alle load balancer-poorten (LB) die zijn geconfigureerd in de sectie loadBalancingRules onder ManagedCluster-eigenschappen . Met deze regel opent u LB-poorten voor binnenkomend verkeer van internet.

Notitie

Deze regel wordt toegevoegd aan het optionele prioriteitsbereik en kan worden overschreven door aangepaste NSG-regels toe te voegen.

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

Load balancer-tests

Beheerde Service Fabric-clusters maken automatisch load balancer-tests voor infrastructuurgatewaypoorten en alle poorten die zijn geconfigureerd in de loadBalancingRules sectie met beheerde clustereigenschappen.

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

Openbaar IP-adres inschakelen

Notitie

Momenteel wordt alleen openbare IPv4 ondersteund.

Beheerde Service Fabric-clusterknooppunten hebben geen eigen openbare IP-adressen nodig voor communicatie. In sommige scenario's moet een knooppunt echter een eigen openbaar IP-adres hebben om te communiceren met internet en openbare Azure-services. Bijvoorbeeld:

  • Gaming, waarbij een console een directe verbinding moet maken met een virtuele machine in de cloud die gamefysica-verwerking uitvoert.
  • Virtuele machines die externe verbindingen met elkaar moeten maken tussen regio's in een gedistribueerde database.

Zie Uitleg over uitgaande verbindingen voor meer informatie over uitgaande verbindingen in Azure.

Openbaar IP-adres kan alleen worden ingeschakeld voor secundaire knooppunttypen, omdat primaire knooppunttypen zijn gereserveerd voor Service Fabric-systeemservices. Volg de stappen in de sectie Uw eigen load balancer van dit artikel gebruiken om een secundair knooppunttype voor uw beheerde cluster te maken.

Azure wijst dynamisch beschikbare IP-adressen toe.

Notitie

Het inschakelen van een openbaar IP-adres wordt alleen ondersteund via een ARM-sjabloon.

In de volgende stappen wordt het inschakelen van een openbaar IP-adres op uw knooppunt beschreven.

  1. Download uw ARM-sjabloon.

  2. Voeg voor elk knooppunttype in de sjabloon toe enableNodePublicIP aan de ARM-sjabloon:

    {
        "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. Uw ARM-sjabloon verwijderen.

  4. Controleer of uw knooppunten een openbaar IP-adres hebben door de volgende PowerShell-opdracht uit te voeren:

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

    De opdracht wordt uitgevoerd in JSON-indeling.

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

IPv6 inschakelen

Beheerde clusters schakelen IPv6 niet standaard in. Met deze functie wordt volledige IPv4-/IPv6-functionaliteit met dubbele stack ingeschakeld van de Load Balancer front-end naar de back-endresources. Wijzigingen die u aanbrengt in de configuratie van de load balancer of NSG-regels voor beheerde clusters, zijn van invloed op zowel de IPv4- als IPv6-routering.

Notitie

Deze instelling is niet beschikbaar in de portal en kan niet worden gewijzigd nadat het cluster is gemaakt.

  • De apiVersion van de beheerde Service Fabric-clusterresource moet 2022-01-01 of hoger zijn.
  1. Stel de volgende eigenschap in voor een beheerde Service Fabric-clusterresource.

        "resources": [
             {
             "apiVersion": "[variables('sfApiVersion')]",
             "type": "Microsoft.ServiceFabric/managedclusters",
             ...
             "properties": {
                 "enableIpv6": true
                 },
             }
        ]
    
  2. Implementeer uw beheerde IPv6-cluster. Pas de voorbeeldsjabloon naar behoefte aan of bouw uw eigen sjabloon. In het volgende voorbeeld maken we een resourcegroep die wordt aangeroepen MyResourceGroup en westus implementeren we een cluster waarvoor deze functie is ingeschakeld.

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

    Na de implementatie zijn het virtuele netwerk en de resources van uw clusters dual-stack. Als gevolg hiervan wordt voor de front-end load balancer van de clusters een uniek DNS-adres gemaakt dat mycluster-ipv6.southcentralus.cloudapp.azure.com bijvoorbeeld is gekoppeld aan een openbaar IPv6-adres op de Azure Load Balancer en privé-IPv6-adressen op de VM's.

Uw eigen virtuele netwerk gebruiken

Met deze functie kunnen klanten een bestaand virtueel netwerk gebruiken door een toegewezen subnet op te geven waarin het beheerde cluster de resources gaat implementeren. Dit kan handig zijn als u al een geconfigureerd VNet en subnet hebt met gerelateerd beveiligingsbeleid en verkeersroutering die u wilt gebruiken. Nadat u in een bestaand virtueel netwerk hebt geïmplementeerd, kunt u eenvoudig andere netwerkfuncties gebruiken of opnemen, zoals Azure ExpressRoute, Azure VPN Gateway, een netwerkbeveiligingsgroep en peering van virtuele netwerken. Daarnaast kunt u indien nodig ook uw eigen Azure Load Balancer meenemen .

Notitie

Wanneer u BYOVNET gebruikt, worden beheerde clusterresources geïmplementeerd in één subnet.

Notitie

Deze instelling kan niet worden gewijzigd nadat het cluster is gemaakt en het beheerde cluster een NSG toewijst aan het opgegeven subnet. Overschrijf de NSG-toewijzing niet, anders kan het verkeer worden onderbroken.

Uw eigen virtuele netwerk gebruiken:

  1. Haal de service Id op uit uw abonnement voor de Service Fabric Resource Provider-toepassing.

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

    Notitie

    Zorg ervoor dat u zich in het juiste abonnement bevindt. De principal-id wordt gewijzigd als het abonnement zich in een andere tenant bevindt.

    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
    

    Noteer de id van de vorige uitvoer als principalId voor gebruik in een latere stap

    Naam van roldefinitie Roldefinitie-id
    Inzender voor netwerken 4d97b98b-1d4f-4787-a291-c67834d212e7

    Noteer de Role definition name eigenschapswaarden en Role definition ID voor gebruik in een latere stap

  2. Voeg een roltoewijzing toe aan de Service Fabric Resource Provider-toepassing. Het toevoegen van een roltoewijzing is een eenmalige actie. U voegt de rol toe door de volgende PowerShell-opdrachten uit te voeren of door een Arm-sjabloon (Azure Resource Manager) te configureren, zoals hieronder wordt beschreven.

    In de volgende stappen beginnen we met een bestaand virtueel netwerk met de naam ExistingRG-vnet, in de resourcegroep ExistingRG. Het subnet heeft de naam default.

    Haal de vereiste informatie op uit het bestaande VNet.

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

    Noteer de volgende subnetnaam en Id eigenschapswaarde die worden geretourneerd uit de Subnets sectie in het antwoord dat u in latere stappen gaat gebruiken.

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

    Voer de volgende PowerShell-opdracht uit met behulp van de principal-id, de naam van de roldefinitie uit stap 2 en het toewijzingsbereik Id dat hierboven is verkregen:

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

    U kunt de roltoewijzing ook toevoegen met behulp van een Arm-sjabloon (Azure Resource Manager) die is geconfigureerd met de juiste waarden voor principalId, roleDefinitionId, vnetNameen subnetName:

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

    Notitie

    VNetRoleAssignmentID moet een GUID zijn. Als u opnieuw een sjabloon implementeert met deze roltoewijzing, moet u ervoor zorgen dat de GUID dezelfde is als de guid die oorspronkelijk is gebruikt. We raden u aan deze geïsoleerd uit te voeren of deze resource na de implementatie uit de clustersjabloon te verwijderen, omdat deze slechts één keer hoeft te worden gemaakt.

    Hier volgt een volledig azure Resource Manager-sjabloon (ARM) waarmee een VNet-subnet wordt gemaakt en roltoewijzingen worden uitgevoerd die u voor deze stap kunt gebruiken.

  3. Configureer de subnetId eigenschap voor de clusterimplementatie nadat de rol is ingesteld, zoals hieronder wordt weergegeven:

  • De apiVersion van de beheerde Service Fabric-clusterresource moet 2022-01-01 of hoger zijn.

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

    Zie de voorbeeldsjabloon Bring Your Own VNet cluster of pas uw eigen cluster aan.

  1. Implementeer de geconfigureerde AZURE Resource Manager-sjabloon (ARM) voor beheerde clusters.

    In het volgende voorbeeld maken we een resourcegroep die wordt westus aangeroepen MyResourceGroup en implementeren we een cluster waarvoor deze functie is ingeschakeld.

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

    Wanneer u uw eigen VNet-subnet gebruikt, wordt het openbare eindpunt nog steeds gemaakt en beheerd door de resourceprovider, maar in het geconfigureerde subnet. Met de functie kunt u het openbare IP-adres/het statische IP-adres niet opgeven op de Azure Load Balancer. U kunt uw eigen Azure Load Balancer in combinatie met deze functie of op zichzelf als u deze of andere load balancer-scenario's nodig hebt die niet systeemeigen worden ondersteund.

Uw eigen Azure Load Balancer

Beheerde clusters maken een openbare Azure-Standard Load Balancer en een volledig gekwalificeerde domeinnaam met een statisch openbaar IP-adres voor zowel het primaire als secundaire knooppunttype. Met Uw eigen load balancer kunt u een bestaande Azure Load Balancer gebruiken voor secundaire knooppunttypen voor zowel inkomend als uitgaand verkeer. Wanneer u uw eigen Azure Load Balancer mee te nemen, kunt u het volgende doen:

  • Een vooraf geconfigureerd Load Balancer statisch IP-adres gebruiken voor privé- of openbaar verkeer
  • Een Load Balancer toewijzen aan een specifiek knooppunttype
  • Regels voor netwerkbeveiligingsgroepen per knooppunttype configureren, omdat elk knooppunttype wordt geïmplementeerd in een eigen subnet
  • Bestaande beleidsregels en besturingselementen onderhouden die u mogelijk hebt
  • Een interne load balancer configureren en de standaard load balancer gebruiken voor extern verkeer

Notitie

Wanneer u BYOVNET gebruikt, worden beheerde clusterresources geïmplementeerd in één subnet met één NSG, ongeacht extra geconfigureerde load balancers.

Notitie

U kunt niet overschakelen van de standaard load balancer naar een aangepaste load balancer na de implementatie van een knooppunttype, maar u kunt de aangepaste load balancer-configuratie na de implementatie wijzigen als deze is ingeschakeld.

Functievereisten

  • De typen Basic- en Standard-SKU-Azure Load Balancer worden ondersteund
  • U moet back-end- en NAT-pools hebben geconfigureerd op de Azure Load Balancer
  • U moet uitgaande connectiviteit inschakelen met behulp van een opgegeven openbare load balancer of de standaard openbare load balancer

Hier volgen enkele voorbeeldscenario's die klanten kunnen gebruiken voor:

In dit voorbeeld wil een klant verkeer routeren via een bestaande Azure Load Balancer geconfigureerd met een bestaand statisch IP-adres naar twee knooppunttypen.

Bring Your Own Load Balancer voorbeeld 1

In dit voorbeeld wil een klant verkeer routeren via bestaande Azure Load Balancers om hen te helpen bij het beheren van de verkeersstroom naar hun toepassingen die zich op afzonderlijke knooppunttypen bevinden. Wanneer dit wordt ingesteld zoals in dit voorbeeld, bevindt elk knooppunttype zich achter zijn eigen beheerde NSG.

Bring Your Own Load Balancer voorbeeld 2

In dit voorbeeld wil een klant verkeer routeren via bestaande interne Azure Load Balancers. Zo kunnen ze de verkeersstroom naar hun toepassingen onafhankelijk beheren die op afzonderlijke knooppunttypen staan. Bij de configuratie zoals in dit voorbeeld bevindt elk knooppunttype zich achter zijn eigen beheerde NSG en wordt de standaard load balancer voor extern verkeer gebruikt.

Bring Your Own Load Balancer voorbeeld 3

Configureren met uw eigen load balancer:

  1. Haal de service Id op uit uw abonnement voor de Service Fabric Resource Provider-toepassing:

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

    Notitie

    Zorg ervoor dat u zich in het juiste abonnement bevindt. De principal-id wordt gewijzigd als het abonnement zich in een andere tenant bevindt.

    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
    

    Noteer de id van de vorige uitvoer als principalId voor gebruik in een latere stap

    Naam van roldefinitie Roldefinitie-id
    Inzender voor netwerken 4d97b98b-1d4f-4787-a291-c67834d212e7

    Noteer de Role definition name eigenschapswaarden en Role definition ID voor gebruik in een latere stap

  2. Voeg een roltoewijzing toe aan de Service Fabric Resource Provider-toepassing. Het toevoegen van een roltoewijzing is een eenmalige actie. U voegt de rol toe door de volgende PowerShell-opdrachten uit te voeren of door een Arm-sjabloon (Azure Resource Manager) te configureren, zoals hieronder wordt beschreven.

    In de volgende stappen beginnen we met een bestaande load balancer met de naam Existing-LoadBalancer1, in de resourcegroep Existing-RG.

    Haal de vereiste Id eigenschapsgegevens op uit de bestaande Azure Load Balancer.

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

    Let op het volgende Id dat u in de volgende stap gaat gebruiken:

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

    Voer de volgende PowerShell-opdracht uit met behulp van de principal-id, de naam van de roldefinitie uit stap 2 en het toewijzingsbereik Id dat u zojuist hebt verkregen:

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

    U kunt de roltoewijzing ook toevoegen met behulp van een ARM-sjabloon (Azure Resource Manager) die is geconfigureerd met de juiste waarden voor principalId, roleDefinitionId":

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

    Notitie

    loadBalancerRoleAssignmentID moet een GUID zijn. Als u opnieuw een sjabloon implementeert met deze roltoewijzing, moet u ervoor zorgen dat de GUID dezelfde is als de guid die oorspronkelijk is gebruikt. We raden u aan deze geïsoleerd uit te voeren of deze resource na de implementatie uit de clustersjabloon te verwijderen, omdat deze slechts één keer hoeft te worden gemaakt.

    Zie deze voorbeeldsjabloon om een openbare load balancer te maken en een rol toe te wijzen.

  3. Configureer de vereiste uitgaande connectiviteit voor het knooppunttype. U moet een openbare load balancer configureren om uitgaande connectiviteit te bieden of de standaard openbare load balancer gebruiken.

    Configureren outboundRules om een openbare load balancer te configureren om uitgaande connectiviteit te bieden Zie de azure-sjabloon Azure Resource Manager (ARM) voor het maken van een load balancer en rol toewijzen

    OF

    Als u het knooppunttype wilt configureren voor het gebruik van de standaard load balancer, stelt u het volgende in uw sjabloon in:

    • De apiVersion van de beheerde Service Fabric-clusterresource moet 2022-01-01 of hoger zijn.
     "resources": [
       {
       "apiVersion": "[variables('sfApiVersion')]",
       "type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
       "properties": {
           "isPrimary": false,
           "useDefaultPublicLoadBalancer": true
           }
       }
     ]
    
  4. Configureer eventueel een binnenkomende toepassingspoort en een gerelateerde test op uw bestaande Azure Load Balancer. Zie de ARM-sjabloon (Bring Your Own Load Balancer)-voorbeeld van Azure Resource Manager (ARM) voor een voorbeeld

  5. Configureer eventueel de NSG-regels voor het beheerde cluster die worden toegepast op het knooppunttype om toe te staan dat vereist verkeer dat u hebt geconfigureerd op de Azure Load Balancer of dat verkeer wordt geblokkeerd. Zie de ARM-sjabloon (Bring Your Own Load Balancer)-voorbeeld van Azure Resource Manager (ARM) voor een voorbeeld van de configuratie van een binnenkomende NSG-regel. Zoek in de sjabloon naar de networkSecurityRules eigenschap.

  6. De geconfigureerde ARM-sjabloon voor het beheerde cluster implementeren Voor deze stap gebruiken we de ARM-sjabloon (Bring Your Own Load Balancer)-voorbeeld van Azure Resource Manager (ARM)

    Hieronder wordt een resourcegroep gemaakt die wordt aangeroepen MyResourceGroup in westus en wordt een cluster geïmplementeerd met behulp van een bestaande load balancer.

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

    Na de implementatie wordt het secundaire knooppunttype geconfigureerd voor het gebruik van de opgegeven load balancer voor binnenkomend en uitgaand verkeer. De Service Fabric-clientverbinding en gateway-eindpunten verwijzen nog steeds naar de openbare DNS van het primaire knooppunttype van het beheerde cluster, zoals het statische IP-adres.

Versneld netwerken inschakelen

Versneld netwerken maakt I/O-virtualisatie met één hoofdmap (SR-IOV) mogelijk voor een VIRTUELE-machineschaalset-VM die de onderliggende resource voor knooppunttypen is. Dit pad met hoge prestaties omzeilt de host van het gegevenspad, waardoor latentie, jitter en CPU-gebruik voor de meest veeleisende netwerkworkloads worden verminderd. Beheerde Service Fabric-clusterknooppunttypen kunnen worden ingericht met versneld netwerken op ondersteunde VM-SKU's. Raadpleeg deze beperkingen en beperkingen voor aanvullende overwegingen.

  • Houd er rekening mee dat versneld netwerken wordt ondersteund op de meeste instantiegrootten voor algemeen gebruik en geoptimaliseerd voor rekenkracht met 2 of meer vCPU's. Op exemplaren die hyperthreading ondersteunen, wordt versneld netwerken ondersteund op VM-exemplaren met 4 of meer vCPU's.

Schakel versneld netwerken in door als volgt de eigenschap in uw Resource Manager-sjabloon te declarerenenableAcceleratedNetworking:

  • De apiVersion van de beheerde Service Fabric-clusterresource moet 2022-01-01 of hoger zijn.
   {
   "apiVersion": "[variables('sfApiVersion')]",
   "type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
   ...
   "properties": {
       ...
       "enableAcceleratedNetworking": true,
       ...
   }

Als u versneld netwerken wilt inschakelen in een bestaand Service Fabric-cluster, moet u eerst een Service Fabric-cluster uitschalen door een nieuw knooppunttype toe te voegen en het volgende te doen:

  1. Een knooppunttype inrichten met Versneld netwerken ingeschakeld
  2. Migreer uw services en hun status naar het ingerichte knooppunttype met versneld netwerken ingeschakeld

Het uitschalen van de infrastructuur is vereist om versneld netwerken in te schakelen op een bestaand cluster, omdat het inschakelen van versneld netwerken ter plaatse downtime zou veroorzaken, omdat hiervoor alle virtuele machines in een beschikbaarheidsset moeten worden gestopt en de toewijzing ervan ongedaan moeten worden gemaakt voordat versneld netwerken op een bestaande NIC wordt ingeschakeld.

Hulpsubnetten configureren

Hulpsubnetten bieden de mogelijkheid om extra beheerde subnetten zonder een knooppunttype te maken voor ondersteunende scenario's zoals Private Link Service en Bastion-hosts.

Configureer hulpsubnetten door als volgt eigenschap en vereiste parameters in uw Resource Manager-sjabloon te declarerenauxiliarySubnets:

  • De apiVersion van de beheerde Service Fabric-clusterresource moet 2022-01-01 of hoger zijn.
    "resources": [
        {
            "apiVersion": "[variables('sfApiVersion')]",
            "type": "Microsoft.ServiceFabric/managedclusters",
              "properties": {
                "auxiliarySubnets": [
                  {
                  "name" : "mysubnet",
                  "enableIpv6" : "true"
                  }
                ]
              }
        }
    ]              

Volledige lijst met beschikbare parameters weergeven

Volgende stappen

Configuratieopties voor beheerde Service Fabric-clusters Overzicht van beheerde ServiceFabric-clusters