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
- Hantera RDP-åtkomst
- Hantera Load Balancer konfiguration
- Aktivera offentlig IP
- Aktivera IPv6
- Ta med ditt eget virtuella nätverk
- Ta med din egen lastbalanserare
- Aktivera accelererat nätverk
- Konfigurera extra undernät
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).
Gå till resursgruppen för det hanterade klustret i din prenumeration med följande format: SFC_{cluster-id}
Välj lastbalanseraren för klustret med följande format: LB-{cluster-name}
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:
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.
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:
Ä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.
Ladda ned ARM-mallen.
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 } }
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.
Ange följande egenskap för en Service Fabric-hanterad klusterresurs.
"resources": [ { "apiVersion": "[variables('sfApiVersion')]", "type": "Microsoft.ServiceFabric/managedclusters", ... "properties": { "enableIpv6": true }, } ]
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
iwestus
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:
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
ochRole definition ID
för användning i ett senare stegLä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ånSubnets
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
,vnetName
ochsubnetName
:"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.
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.
Distribuera den konfigurerade ARM-mallen (Managed Cluster Azure Resource Manager).
I följande exempel skapar vi en resursgrupp med namnet
MyResourceGroup
iwestus
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.
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.
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.
Så här konfigurerar du med din egen lastbalanserare:
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
ochRole definition ID
för användning i ett senare stegLä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.
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 } } ]
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)
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
.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
iwestus
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:
- Etablera en nodtyp med accelererat nätverk aktiverat
- 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
Feedback
https://aka.ms/ContentUserFeedback.
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i:Skicka och visa feedback för