Share via


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 dat is toegewezen en een NSG die is geconfigureerd voor essentiële clusterfunctionaliteit. Er zijn ook optionele NSG-regels toegepast, zoals het toestaan van al het uitgaande verkeer dat standaard is bedoeld om de configuratie van de klant eenvoudiger te maken. In dit document wordt uitgelegd hoe u de volgende netwerkconfiguratieopties en meer kunt wijzigen:

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 en met 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 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 de resource Microsoft.ServiceFabric/managedclusters (versie 2021-05-01 of hoger) om NSG-regels toe te wijzen. Voorbeeld:

{
  "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 van het cluster en httpGatewayConnectionPort. Met deze regel hebt 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 via PowerShell en service Fabric-cluster-API-eindpunten van internet gebruiken door LB-poorten te openen voor clientConnectionPort en httpGatewayPort.

Notitie

Deze regel wordt niet toegevoegd als er een aangepaste regel is met dezelfde toegangs-, richting- 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 binnenkomende toegang tot de RDP-poorten van internet in. U kunt binnenkomende toegang tot de RDP-poorten vanaf internet openen 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 de 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"
    }
}

Met Service Fabric beheerde clusters worden automatisch binnenkomende NAT-regels gemaakt 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 De Azure-portal het beheerde cluster dat binnenkomende NAT-regels voor Remote Desktop Protocol (RDP) heeft gemaakt.

  1. Navigeer naar de resourcegroep van het beheerde cluster binnen uw abonnement met de volgende indeling: SFC_{cluster-id}

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

  3. Selecteer op de pagina voor uw load balancer de inkomende NAT-regels. Controleer de binnenkomende NAT-regels om de binnenkomende front-endpoorttoewijzing 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 BYOLB-functie gebruikt en u RDP wilt, moet u een NAT-pool afzonderlijk configureren om dit te doen. Hiermee worden geen NAT-regels voor deze knooppunttypen automatisch gemaakt.

  4. Maak extern verbinding met het specifieke knooppunt (exemplaar van de schaalset). 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 LB-poorten (loadBalancingRules ) die zijn geconfigureerd onder de eigenschappen managedCluster . Met deze regel worden LB-poorten geopend voor binnenkomend verkeer vanaf internet.

Notitie

Deze regel wordt toegevoegd in 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

Met Service Fabric beheerde clusters worden automatisch load balancer-tests gemaakt voor fabric-gatewaypoorten en alle poorten die zijn geconfigureerd in het loadBalancingRules gedeelte 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 vereisen geen eigen openbare IP-adressen voor communicatie. In sommige scenario's is echter mogelijk vereist dat een knooppunt een eigen openbaar IP-adres heeft om te communiceren met internet en openbare Azure-services. Voorbeeld:

  • Gaming, waarbij een console een directe verbinding moet maken met een virtuele cloudmachine die gamefysica verwerkt.
  • Virtuele machines die externe verbindingen met elkaar moeten maken in verschillende regio's in een gedistribueerde database.

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

Openbare IP-adressen kunnen alleen worden ingeschakeld voor secundaire knooppunttypen, omdat primaire knooppunttypen zijn gereserveerd voor Service Fabric-systeemservices. Volg de stappen in de sectie Bring your own load balancer van dit artikel 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 beschreven hoe u het openbare IP-adres op uw knooppunt inschakelt.

  1. Download uw ARM-sjabloon.

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

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

  4. Controleer of u een openbaar IP-adres op uw knooppunten hebt 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 van de Load Balancer-front-end naar de back-endbronnen ingeschakeld. Wijzigingen die u aanbrengt in de configuratie van de beheerde clustertaakverdeling of NSG-regels, zijn van invloed op zowel de IPv4- als de IPv6-routering.

Notitie

Deze instelling is niet beschikbaar in de portal en kan niet worden gewijzigd zodra 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 op 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 indien nodig aan of bouw uw eigen sjabloon . In het volgende voorbeeld maken we een resourcegroep die is aangeroepen MyResourceGroup westus 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
    

    Na de implementatie zijn het virtuele netwerk en de resources van uw clusters dual-stack. Als gevolg hiervan heeft de front-end load balancer van clusters een uniek DNS-adres dat bijvoorbeeld mycluster-ipv6.southcentralus.cloudapp.azure.com 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 implementeert. 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 clusterbronnen in één subnet geïmplementeerd.

Notitie

Deze instelling kan niet worden gewijzigd zodra het cluster is gemaakt en het beheerde cluster wijst een NSG toe aan het opgegeven subnet. Overschrijf de NSG-toewijzing of het verkeer mogelijk niet.

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 waarden en Role definition ID eigenschapswaarden 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 standaard.

    Haal de vereiste gegevens 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 wordt 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 ook de roltoewijzing toevoegen met behulp van een ARM-sjabloon (Azure Resource Manager) die is geconfigureerd met de juiste waarden voorprincipalId, roleDefinitionIdenvnetNamesubnetName:

       "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 een sjabloon opnieuw implementeert, inclusief deze roltoewijzing, moet u ervoor zorgen dat de GUID hetzelfde is als de sjabloon die oorspronkelijk is gebruikt. We raden u aan deze geïsoleerde resource uit te voeren of deze na de implementatie van de clustersjabloon te verwijderen, omdat deze slechts eenmaal moet worden gemaakt.

    Hier volgt een volledig voorbeeld van een Arm-sjabloon (Azure Resource Manager) die een VNet-subnet maakt en roltoewijzing uitvoert die u voor deze stap kunt gebruiken.

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

  1. Implementeer de geconfigureerde ARM-sjabloon (Managed Cluster Azure Resource Manager).

    In het volgende voorbeeld maken we een resourcegroep die is aangeroepen MyResourceGroup westus 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 geen statisch IP-adres opgeven/opnieuw gebruiken op de Azure Load Balancer. U kunt uw eigen Azure Load Balancer gebruiken 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 gebruiken

Beheerde clusters maken een openbare Load Balancer van Azure en een volledig gekwalificeerde domeinnaam met een statisch openbaar IP-adres voor zowel de primaire als de secundaire knooppunttypen. Met Bring Your Own 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 gebruikt, kunt u het volgende doen:

  • Een vooraf geconfigureerd statisch IP-adres van load balancer 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 aanvullende geconfigureerde load balancers.

Notitie

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

Functievereisten

  • Basic- en Standard SKU Azure Load Balancer-typen 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 waarvoor klanten dit kunnen gebruiken:

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

Bring your own Load Balancer example 1

In dit voorbeeld wil een klant verkeer routeren via bestaande Azure Load Balancers om hen te helpen de verkeersstroom naar hun toepassingen onafhankelijk te beheren die zich op afzonderlijke knooppunttypen bevinden. Wanneer u dit voorbeeld instelt, bevindt elk knooppunttype zich achter een eigen beheerde NSG.

Bring your own Load Balancer example 2

In dit voorbeeld wil een klant verkeer routeren via bestaande interne Azure Load Balancers. Hierdoor kunnen ze de verkeersstroom naar hun toepassingen onafhankelijk beheren die zich op afzonderlijke knooppunttypen bevinden. Wanneer u dit voorbeeld instelt, bevindt elk knooppunttype zich achter een eigen beheerde NSG en gebruikt u de standaard load balancer voor extern verkeer.

Bring your own Load Balancer example 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 waarden en Role definition ID eigenschapswaarden 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 van de bestaande Azure Load Balancer.

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

    Let op het volgende dat Id 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 ook de roltoewijzing 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 een sjabloon opnieuw implementeert, inclusief deze roltoewijzing, moet u ervoor zorgen dat de GUID hetzelfde is als de sjabloon die oorspronkelijk is gebruikt. We raden u aan deze geïsoleerde resource uit te voeren of deze na de implementatie van de clustersjabloon te verwijderen, omdat deze slechts eenmaal moet 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 te gebruiken.

    Configureren outboundRules om een openbare load balancer te configureren om uitgaande connectiviteit te bieden Zie de load balancer maken en een ARM-sjabloon (Role Sample Azure Resource Manager) 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 gerelateerde test op uw bestaande Azure Load Balancer. Zie de ARM-voorbeeldsjabloon (Bring Your Own Load Balancer) van Azure Resource Manager voor een voorbeeld

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

  6. Implementeer de geconfigureerde ARM-sjabloon voor beheerde clusters voor deze stap met behulp van de ARM-sjabloon (Bring Your Own Load Balancer)

    Hierna maakt u een resourcegroep die is aangeroepen MyResourceGroup westus en implementeert u een cluster 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 is het secundaire knooppunttype geconfigureerd voor het gebruik van de opgegeven load balancer voor inkomend 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.

Versneld netwerken inschakelen

Versneld netwerken maakt I/O-virtualisatie met één hoofdmap (SR-IOV) mogelijk voor een virtuele-machineschaalset-VM die de onderliggende resource is voor knooppunttypen. Dit pad met hoge prestaties omzeilt de host van het gegevenspad, waardoor latentie, jitter en CPU-gebruik voor de meest veeleisende netwerkworkloads worden verminderd. Door Service Fabric beheerde 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 voor de meeste algemene en voor rekendoeleinden geoptimaliseerde instantiegrootten 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 de eigenschap in uw Resource Manager-sjabloon als volgt te declareren enableAcceleratedNetworking :

  • 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 voor een bestaand Service Fabric-cluster, moet u eerst een Service Fabric-cluster uitschalen door een nieuw knooppunttype toe te voegen en het volgende uit te voeren:

  1. Een knooppunttype inrichten waarvoor versneld netwerken is ingeschakeld
  2. Uw services en hun status migreren 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 tot downtime zou leiden, omdat alle virtuele machines in een beschikbaarheidsset moeten worden gestopt en de toewijzing ongedaan moet worden gemaakt voordat versneld netwerken op een bestaande NIC worden ingeschakeld.

Hulpsubnetten configureren

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

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

  • 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

Overzicht van beheerde Service Fabric-clusterconfiguratieoptiesvoor beheerde Service Fabric-clusters