Dela via


Konfigurera nätverksinställningar för Service Fabric-hanterade kluster

Service Fabric-hanterade kluster skapas med en standardkonfiguration för nätverk. Den här konfigurationen består av en Azure Load Balancer med en offentlig IP-adress, ett VNet med ett allokerat undernät och en NSG som konfigurerats för viktiga klusterfunktioner. Det finns också valfria NSG-regler som tillämpas, till exempel att tillåta all utgående trafik som standard som är avsedd att göra kundkonfigurationen enklare. Det här dokumentet beskriver hur du ändrar följande konfigurationsalternativ för nätverk med mera:

Hantera NSG-regler

Vägledning för NSG-regler

Tänk på dessa överväganden när du skapar nya NSG-regler för ditt hanterade kluster.

  • Service Fabric-hanterade kluster reserverar NSG-regelns prioritetsintervall 0 till 999 för viktiga funktioner. Du kan inte skapa anpassade NSG-regler med ett prioritetsvärde på mindre än 1 000.
  • Service Fabric-hanterade kluster reserverar prioritetsintervallet 3001 till 4 000 för att skapa valfria NSG-regler. Dessa regler läggs till automatiskt för att göra konfigurationerna snabba och enkla. Du kan åsidosätta dessa regler genom att lägga till anpassade NSG-regler i prioritetsintervallet 1 000 till 3 000.
  • Anpassade NSG-regler bör ha en prioritet inom intervallet 1 000 till 3 000.

Tillämpa NSG-regler

Med Service Fabric-hanterade kluster kan du tilldela NSG-regler direkt i klusterresursen i distributionsmallen.

Använd egenskapen networkSecurityRules för din Microsoft.ServiceFabric/managedclusters-resurs (version 2021-05-01 eller senare) för att tilldela NSG-regler. Exempel:

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

Standardregler för ClientConnection och HttpGatewayConnection och valfria

NSG-regel: SFMC_AllowServiceFabricGatewayToSFRP

En standardregel för NSG läggs till för att ge Service Fabric-resursprovidern åtkomst till klustrets clientConnectionPort och httpGatewayConnectionPort. Den här regeln tillåter åtkomst till portarna via tjänsttaggen "ServiceFabric".

Anteckning

Den här regeln läggs alltid till och kan inte åsidosättas.

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

Den här valfria regeln gör det möjligt för kunder att komma åt SFX, ansluta till klustret med PowerShell och använda SERVICE Fabric-kluster-API-slutpunkter från Internet genom att öppna LB-portar för clientConnectionPort och httpGatewayPort.

Anteckning

Den här regeln läggs inte till om det finns en anpassad regel med samma åtkomst-, riktnings- och protokollvärden för samma port. Du kan åsidosätta den här regeln med anpassade NSG-regler.

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

Aktivera åtkomst till RDP-portar från Internet

Service Fabric-hanterade kluster aktiverar inte inkommande åtkomst till RDP-portarna från Internet som standard. Du kan öppna inkommande åtkomst till RDP-portarna från Internet genom att ange följande egenskap för en Service Fabric-hanterad klusterresurs.

"allowRDPAccess": true

När egenskapen allowRDPAccess är inställd på true läggs följande NSG-regel till i klusterdistributionen.

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

Service Fabric-hanterade kluster skapar automatiskt inkommande NAT-regler för varje instans i en nodtyp. Följ stegen nedan för att hitta portmappningarna för att nå specifika instanser (klusternoder):

Använd Azure Portal och leta upp det hanterade klustret som skapade inkommande NAT-regler för Remote Desktop Protocol (RDP).

  1. Gå till resursgruppen för det hanterade klustret i din prenumeration med följande format: SFC_{cluster-id}

  2. Välj lastbalanseraren för klustret med följande format: LB-{cluster-name}

  3. På sidan för lastbalanseraren väljer du Inkommande NAT-regler. Granska de inkommande NAT-reglerna för att bekräfta den inkommande klientdelsporten till målportmappningen för en nod.

    Följande skärmbild visar inkommande NAT-regler för tre olika nodtyper:

    Regler för ingående NAT

    Som standard är klientdelsporten i intervallet 50000 och högre för Windows-kluster och målporten är port 3389, som mappar till RDP-tjänsten på målnoden.

    Anteckning

    Om du använder FUNKTIONEN BYOLB och vill ha RDP måste du konfigurera en NAT-pool separat för att göra det. Detta skapar inte automatiskt några NAT-regler för dessa nodtyper.

  4. Fjärransluta till den specifika noden (skalningsuppsättningsinstans). Du kan använda det användarnamn och lösenord som du angav när du skapade klustret eller andra autentiseringsuppgifter som du har konfigurerat.

Följande skärmbild visar hur du använder Anslutning till fjärrskrivbord för att ansluta till appnoden (Instans 0) i ett Windows-kluster:

Anslutning till fjärrskrivbord

Ändra standardkonfigurationen för lastbalanserare

Portar för lastbalanserare

Service Fabric-hanterade kluster skapar en NSG-regel i standardprioritetsintervallet för alla lastbalanseringsportar (LB) som konfigurerats under avsnittet "loadBalancingRules" under ManagedCluster-egenskaper . Den här regeln öppnar lastbalanserare för inkommande trafik från Internet.

Anteckning

Den här regeln läggs till i det valfria prioritetsintervallet och kan åsidosättas genom att lägga till anpassade NSG-regler.

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

Avsökningar för lastbalanserare

Service Fabric-hanterade kluster skapar automatiskt lastbalanseringsavsökningar för infrastrukturgatewayportar och alla portar som konfigurerats i loadBalancingRules avsnittet med egenskaper för hanterade kluster.

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

Aktivera offentlig IP

Anteckning

För närvarande stöds endast offentlig IPv4.

Service Fabric-hanterade klusternoder kräver inte egna offentliga IP-adresser för kommunikation. Vissa scenarier kan dock kräva att en nod har en egen offentlig IP-adress för att kommunicera med Internet och offentliga Azure-tjänster. Exempel:

  • Spel, där en konsol måste upprätta en direktanslutning till en virtuell molndator som utför bearbetning av spelfysik.
  • Virtuella datorer som behöver göra externa anslutningar till varandra mellan regioner i en distribuerad databas.

Mer information om utgående anslutningar i Azure finns i Förstå utgående anslutningar.

Offentlig IP kan bara aktiveras på sekundära nodtyper eftersom primära nodtyper är reserverade för Service Fabric-systemtjänster. Följ stegen i avsnittet Bring your own load balancer (Ta med din egen lastbalanserare) i den här artikeln för att skapa en sekundär nodtyp för det hanterade klustret.

Azure tilldelar dynamiskt tillgängliga IP-adresser.

Anteckning

Aktivering av offentlig IP stöds endast via ARM-mall.

Följande steg beskriver hur du aktiverar offentlig IP-adress på noden.

  1. Ladda ned ARM-mallen.

  2. För varje nodtyp i mallen lägger du till enableNodePublicIP i ARM-mallen:

    {
        "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. Deloy din ARM-mall.

  4. Kontrollera att du har en offentlig IP-adress på noderna genom att köra följande PowerShell-kommando:

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

    Kommandot matas ut i JSON-format.

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

Aktivera IPv6

Hanterade kluster aktiverar inte IPv6 som standard. Den här funktionen aktiverar en fullständig IPv4/IPv6-funktion med dubbla staplar från Load Balancer-klientdelen till serverdelsresurserna. Alla ändringar du gör i konfigurationen av den hanterade klusterlastbalanseraren eller NSG-reglerna påverkar både IPv4- och IPv6-routningen.

Anteckning

Den här inställningen är inte tillgänglig i portalen och kan inte ändras när klustret har skapats.

  • Den hanterade klusterresursen apiVersion för Service Fabric ska vara 2022-01-01 eller senare.
  1. Ange följande egenskap för en Service Fabric-hanterad klusterresurs.

        "resources": [
             {
             "apiVersion": "[variables('sfApiVersion')]",
             "type": "Microsoft.ServiceFabric/managedclusters",
             ...
             "properties": {
                 "enableIpv6": true
                 },
             }
        ]
    
  2. Distribuera ditt IPv6-aktiverade hanterade kluster. Anpassa exempelmallen efter behov eller skapa en egen. I följande exempel skapar vi en resursgrupp med namnet MyResourceGroup i westus och distribuerar ett kluster med den här funktionen aktiverad.

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

    Efter distributionen blir klustrens virtuella nätverk och resurser dubbla stackar. Därför har klusterklientdelslastbalanseraren en unik dns-adress som skapats, mycluster-ipv6.southcentralus.cloudapp.azure.com till exempel som är associerad med en offentlig IPv6-adress på Azure Load Balancer och privata IPv6-adresser på de virtuella datorerna.

Ta med ditt eget virtuella nätverk

Med den här funktionen kan kunder använda ett befintligt virtuellt nätverk genom att ange ett dedikerat undernät som det hanterade klustret ska distribuera sina resurser till. Detta kan vara användbart om du redan har ett konfigurerat virtuellt nätverk och undernät med relaterade säkerhetsprinciper och trafikroutning som du vill använda. När du har distribuerat till ett befintligt virtuellt nätverk är det enkelt att använda eller införliva andra nätverksfunktioner, till exempel Azure ExpressRoute, Azure VPN Gateway, en nätverkssäkerhetsgrupp och peering för virtuella nätverk. Dessutom kan du ta med din egen Azure Load Balancer om det behövs.

Anteckning

När du använder BYOVNET distribueras hanterade klusterresurser i ett undernät.

Anteckning

Den här inställningen kan inte ändras när klustret har skapats och det hanterade klustret tilldelar en NSG till det angivna undernätet. Åsidosätt inte NSG-tilldelningen eller så kan trafiken avbrytas.

Så här tar du med ditt eget virtuella nätverk:

  1. Hämta tjänsten Id från din prenumeration för Service Fabric Resource Provider-programmet.

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

    Anteckning

    Kontrollera att du har rätt prenumeration. Huvudnamns-ID:t ändras om prenumerationen finns i en annan klientorganisation.

    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
    

    Observera ID :t för föregående utdata som principalId för användning i ett senare steg

    Namn på rolldefinition Rolldefinitions-ID
    Nätverksdeltagare 4d97b98b-1d4f-4787-a291-c67834d212e7

    Observera egenskapsvärdena Role definition name och Role definition ID för användning i ett senare steg

  2. Lägg till en rolltilldelning i Service Fabric Resource Provider-programmet. Att lägga till en rolltilldelning är en engångsåtgärd. Du lägger till rollen genom att köra följande PowerShell-kommandon eller genom att konfigurera en Azure Resource Manager-mall (ARM) enligt beskrivningen nedan.

    I följande steg börjar vi med ett befintligt virtuellt nätverk med namnet ExistingRG-vnet i resursgruppen ExistingRG. Undernätet heter standard.

    Hämta nödvändig information från det befintliga virtuella nätverket.

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

    Observera följande undernätsnamn och Id egenskapsvärde som returneras från Subnets avsnittet i svaret som du ska använda i senare steg.

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

    Kör följande PowerShell-kommando med huvudnamns-ID, rolldefinitionsnamn från steg 2 och tilldelningsomfånget Id ovan:

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

    Eller så kan du lägga till rolltilldelningen med hjälp av en Arm-mall (Azure Resource Manager) som konfigurerats med rätt värden för principalId, roleDefinitionId, vnetNameoch 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"
       }
    

    Anteckning

    VNetRoleAssignmentID måste vara ett GUID. Om du distribuerar en mall igen med den här rolltilldelningen kontrollerar du att GUID:t är samma som det som ursprungligen användes. Vi föreslår att du kör den här isolerade resursen eller tar bort den här resursen från klustermallen efter distributionen eftersom den bara behöver skapas en gång.

    Här är en fullständig exempelmall för Azure Resource Manager (ARM) som skapar ett VNet-undernät och utför rolltilldelning som du kan använda för det här steget.

  3. subnetId Konfigurera egenskapen för klusterdistributionen när rollen har konfigurerats enligt nedan:

  • ApiVersion för service fabric-hanterade klusterresurser ska vara 2022-01-01 eller senare.

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

    Se exempelmallen ta med ditt eget VNet-kluster eller anpassa din egen.

  1. Distribuera den konfigurerade ARM-mallen (Managed Cluster Azure Resource Manager).

    I följande exempel skapar vi en resursgrupp med namnet MyResourceGroup i westus och distribuerar ett kluster med den här funktionen aktiverad.

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

    När du tar med ditt eget VNet-undernät skapas och hanteras den offentliga slutpunkten fortfarande av resursprovidern, men i det konfigurerade undernätet. Med funktionen kan du inte ange den offentliga ip-adressen/återanvändningen av statisk ip på Azure Load Balancer. Du kan använda egna Azure Load Balancer tillsammans med den här funktionen eller själv om du behöver de eller andra lastbalanseringsscenarier som inte stöds internt.

Ta med egna Azure Load Balancer

Hanterade kluster skapar ett offentligt Azure-Standard Load Balancer och ett fullständigt kvalificerat domännamn med en statisk offentlig IP-adress för både de primära och sekundära nodtyperna. Med Bring Your Own Load Balancer kan du använda en befintlig Azure Load Balancer för sekundära nodtyper för både inkommande och utgående trafik. När du tar med egna Azure Load Balancer kan du:

  • Använd en förkonfigurerad Load Balancer statisk IP-adress för privat eller offentlig trafik
  • Mappa en Load Balancer till en viss nodtyp
  • Konfigurera regler för nätverkssäkerhetsgrupp per nodtyp eftersom varje nodtyp distribueras i ett eget undernät
  • Underhålla befintliga principer och kontroller som du kan ha på plats
  • Konfigurera en intern lastbalanserare och använd standardlastbalanseraren för extern trafik

Anteckning

När du använder BYOVNET distribueras hanterade klusterresurser i ett undernät med en NSG oavsett ytterligare konfigurerade lastbalanserare.

Anteckning

Du kan inte växla från standardlastbalanseraren till en anpassad efter distributionen av en nodtyp, men du kan ändra den anpassade lastbalanserarens konfiguration efter distributionen om den är aktiverad.

Funktionskrav

  • Grundläggande och standard-SKU Azure Load Balancer typer stöds
  • Du måste ha serverdels- och NAT-pooler konfigurerade på Azure Load Balancer
  • Du måste aktivera utgående anslutning antingen med hjälp av en angivet offentlig lastbalanserare eller standard offentlig lastbalanserare

Här är några exempelscenarier som kunder kan använda detta för:

I det här exemplet vill en kund dirigera trafik via en befintlig Azure Load Balancer konfigurerad med en befintlig statisk IP-adress till två nodtyper.

Ta med egna Load Balancer exempel 1

I det här exemplet vill en kund dirigera trafik via befintliga Azure Load Balancers för att hjälpa dem att hantera trafikflödet till sina program oberoende av varandra som finns på separata nodtyper. När de konfigureras som det här exemplet ligger varje nodtyp bakom sin egen hanterade NSG.

Ta med egna Load Balancer exempel 2

I det här exemplet vill en kund dirigera trafik via befintliga interna Azure Load Balancers. Detta hjälper dem att hantera trafikflödet till sina program oberoende av varandra som finns på separata nodtyper. När du konfigurerar det här exemplet ligger varje nodtyp bakom en egen hanterad NSG och använder standardlastbalanseraren för extern trafik.

Ta med egna Load Balancer exempel 3

Så här konfigurerar du med din egen lastbalanserare:

  1. Hämta tjänsten Id från din prenumeration för Service Fabric Resource Provider-programmet:

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

    Anteckning

    Kontrollera att du har rätt prenumeration. Huvudnamns-ID:t ändras om prenumerationen finns i en annan klientorganisation.

    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
    

    Observera ID :t för föregående utdata som principalId för användning i ett senare steg

    Namn på rolldefinition Rolldefinitions-ID
    Nätverksdeltagare 4d97b98b-1d4f-4787-a291-c67834d212e7

    Observera egenskapsvärdena Role definition name och Role definition ID för användning i ett senare steg

  2. Lägg till en rolltilldelning i Service Fabric Resource Provider-programmet. Att lägga till en rolltilldelning är en engångsåtgärd. Du lägger till rollen genom att köra följande PowerShell-kommandon eller genom att konfigurera en Azure Resource Manager-mall (ARM) enligt beskrivningen nedan.

    I följande steg börjar vi med en befintlig lastbalanserare med namnet Existing-LoadBalancer1 i resursgruppen Existing-RG.

    Hämta nödvändig Id egenskapsinformation från den befintliga Azure Load Balancer.

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

    Observera följande Id som du kommer att använda i nästa steg:

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

    Kör följande PowerShell-kommando med huvudnamns-ID, rolldefinitionsnamn från steg 2 och tilldelningsomfånget Id du precis fått:

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

    Eller så kan du lägga till rolltilldelningen med hjälp av en ARM-mall (Azure Resource Manager) som konfigurerats med rätt värden för 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"
       }
    

    Anteckning

    loadBalancerRoleAssignmentID måste vara ett GUID. Om du distribuerar en mall igen med den här rolltilldelningen kontrollerar du att GUID:t är samma som det som ursprungligen användes. Vi föreslår att du kör den här isolerade resursen eller tar bort den här resursen från klustermallen efter distributionen eftersom den bara behöver skapas en gång.

    Se den här exempelmallen för att skapa en offentlig lastbalanserare och tilldela en roll.

  3. Konfigurera nödvändig utgående anslutning för nodtypen. Du måste konfigurera en offentlig lastbalanserare för att tillhandahålla utgående anslutning eller använda den offentliga standardlastbalanseraren.

    Konfigurera outboundRules för att konfigurera en offentlig lastbalanserare för att tillhandahålla utgående anslutning Se mallen skapa lastbalanserare och tilldela rollexempel för Azure Resource Manager (ARM)

    ELLER

    Konfigurera nodtypen för att använda standardlastbalanseraren genom att ange följande i mallen:

    • ApiVersion för service fabric-hanterade klusterresurser ska vara 2022-01-01 eller senare.
     "resources": [
       {
       "apiVersion": "[variables('sfApiVersion')]",
       "type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
       "properties": {
           "isPrimary": false,
           "useDefaultPublicLoadBalancer": true
           }
       }
     ]
    
  4. Du kan också konfigurera en inkommande programport och relaterad avsökning på din befintliga Azure Load Balancer. Ett exempel finns i exempelmallen Ta med din egen lastbalanserare i Azure Resource Manager (ARM)

  5. Du kan också konfigurera NSG-reglerna för det hanterade klustret som tillämpas på nodtypen för att tillåta all nödvändig trafik som du har konfigurerat på Azure Load Balancer eller så blockeras trafiken. En exempelkonfiguration av inkommande NSG-regler finns i exempelmallen Ta med din egen lastbalanserare i Azure Resource Manager (ARM). Leta efter egenskapen i mallen networkSecurityRules .

  6. Distribuera ARM-mallen för det konfigurerade hanterade klustret I det här steget använder vi mallen Ta med din egen lastbalanserare , Azure Resource Manager (ARM)

    Följande skapar en resursgrupp med namnet MyResourceGroup i westus och distribuerar ett kluster med hjälp av en befintlig lastbalanserare.

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

    Efter distributionen är den sekundära nodtypen konfigurerad att använda den angivna lastbalanseraren för inkommande och utgående trafik. Service Fabric-klientanslutningen och gatewayslutpunkterna pekar fortfarande på den offentliga DNS-adressen för det hanterade klustrets primära nodtyp statisk IP-adress.

Aktivera accelererat nätverk

Accelererat nätverk möjliggör enkel rot-I/O-virtualisering (SR-IOV) till en virtuell dators skalningsuppsättnings-VM som är den underliggande resursen för nodtyper. Den här högpresterande sökvägen kringgår värden från datasökvägen, vilket minskar svarstiden, jitter- och CPU-användningen för de mest krävande nätverksarbetsbelastningarna. Service Fabric-hanterade klusternodtyper kan etableras med accelererat nätverk på VM-SKU:er som stöds. Referera till dessa begränsningar och begränsningar för ytterligare överväganden.

  • Observera att accelererat nätverk stöds i de flesta allmänna och beräkningsoptimerade instansstorlekar med 2 eller fler virtuella processorer. På instanser som stöder hypertrådning stöds accelererat nätverk på VM-instanser med 4 eller fler virtuella processorer.

Aktivera accelererat nätverk genom att enableAcceleratedNetworking deklarera egenskapen i Resource Manager-mallen på följande sätt:

  • Den hanterade klusterresursen apiVersion för Service Fabric ska vara 2022-01-01 eller senare.
   {
   "apiVersion": "[variables('sfApiVersion')]",
   "type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
   ...
   "properties": {
       ...
       "enableAcceleratedNetworking": true,
       ...
   }

Om du vill aktivera accelererat nätverk i ett befintligt Service Fabric-kluster måste du först skala ut ett Service Fabric-kluster genom att lägga till en ny nodtyp och utföra följande:

  1. Etablera en nodtyp med accelererat nätverk aktiverat
  2. Migrera dina tjänster och deras tillstånd till den etablerade nodtypen med accelererat nätverk aktiverat

Utskalning av infrastrukturen krävs för att aktivera accelererat nätverk i ett befintligt kluster, eftersom aktivering av accelererat nätverk på plats skulle orsaka driftstopp eftersom det kräver att alla virtuella datorer i en tillgänglighetsuppsättning stoppas och frigörs innan accelererat nätverk aktiveras på ett befintligt nätverkskort.

Konfigurera extra undernät

Extra undernät ger möjlighet att skapa ytterligare hanterade undernät utan nodtyp för stödscenarier som Private Link Service och Bastion-värdar.

Konfigurera extra undernät genom att auxiliarySubnets deklarera egenskaper och obligatoriska parametrar i Resource Manager mallen på följande sätt:

  • Den hanterade klusterresursen apiVersion för Service Fabric ska vara 2022-01-01 eller senare.
    "resources": [
        {
            "apiVersion": "[variables('sfApiVersion')]",
            "type": "Microsoft.ServiceFabric/managedclusters",
              "properties": {
                "auxiliarySubnets": [
                  {
                  "name" : "mysubnet",
                  "enableIpv6" : "true"
                  }
                ]
              }
        }
    ]              

Se en fullständig lista över tillgängliga parametrar

Nästa steg

Översikt över service fabric-hanterade klusterkonfigurationsalternativ för Service Fabric-hanterade kluster