Netwerkinstellingen configureren voor beheerde Service Fabric-clusters
Beheerde Service Fabric-clusters worden gemaakt met een standaardnetwerkconfiguratie. Deze configuratie bestaat uit een Azure Load Balancer met een openbaar IP-adres, een VNet met één subnet toegewezen en een NSG die is geconfigureerd voor essentiële clusterfunctionaliteit. Er zijn ook optionele NSG-regels toegepast, zoals het standaard toestaan van al het uitgaande verkeer dat is bedoeld om de configuratie van de klant eenvoudiger te maken. In dit document wordt uitgelegd hoe u de volgende configuratieopties voor netwerken kunt wijzigen en meer:
- NSG-regels beheren
- RDP-toegang beheren
- Configuratie van Load Balancer beheren
- Openbaar IP-adres inschakelen
- IPv6 inschakelen
- Uw eigen virtuele netwerk gebruiken
- Bring Your Own Load Balancer
- Versneld netwerken inschakelen
- Hulpsubnetten configureren
NSG-regels beheren
Richtlijnen voor NSG-regels
Houd rekening met deze overwegingen bij het maken van nieuwe NSG-regels voor uw beheerde cluster.
- Beheerde Service Fabric-clusters reserveren het prioriteitsbereik van de NSG-regel 0 tot 999 voor essentiële functionaliteit. U kunt geen aangepaste NSG-regels maken met een prioriteitswaarde van minder dan 1000.
- Beheerde Service Fabric-clusters reserveren het prioriteitsbereik 3001 tot 4000 voor het maken van optionele NSG-regels. Deze regels worden automatisch toegevoegd om configuraties snel en eenvoudig te maken. U kunt deze regels overschrijven door aangepaste NSG-regels toe te voegen in het prioriteitsbereik 1000 tot 3000.
- Aangepaste NSG-regels moeten een prioriteit hebben binnen het bereik van 1000 tot 3000.
NSG-regels toepassen
Met beheerde Service Fabric-clusters kunt u NSG-regels rechtstreeks binnen de clusterresource van uw implementatiesjabloon toewijzen.
Gebruik de eigenschap networkSecurityRules van uw Resource Microsoft.ServiceFabric/managedclusters (versie 2021-05-01
of hoger) om NSG-regels toe te wijzen. Bijvoorbeeld:
{
"apiVersion": "2021-05-01",
"type": "Microsoft.ServiceFabric/managedclusters",
"properties": {
"networkSecurityRules": [
{
"name": "AllowCustomers",
"protocol": "*",
"sourcePortRange": "*",
"sourceAddressPrefix": "Internet",
"destinationAddressPrefix": "*",
"destinationPortRange": "33000-33499",
"access": "Allow",
"priority": 2001,
"direction": "Inbound"
},
{
"name": "AllowARM",
"protocol": "*",
"sourcePortRange": "*",
"sourceAddressPrefix": "AzureResourceManager",
"destinationAddressPrefix": "*",
"destinationPortRange": "33500-33699",
"access": "Allow",
"priority": 2002,
"direction": "Inbound"
},
{
"name": "DenyCustomers",
"protocol": "*",
"sourcePortRange": "*",
"sourceAddressPrefix": "Internet",
"destinationAddressPrefix": "*",
"destinationPortRange": "33700-33799",
"access": "Deny",
"priority": 2003,
"direction": "Outbound"
},
{
"name": "DenyRDP",
"protocol": "*",
"sourcePortRange": "*",
"sourceAddressPrefix": "*",
"destinationAddressPrefix": "VirtualNetwork",
"destinationPortRange": "3389",
"access": "Deny",
"priority": 2004,
"direction": "Inbound",
"description": "Override for optional SFMC_AllowRdpPort rule. This is required in tests to avoid Sev2 incident for security policy violation."
}
],
"fabricSettings": [
"..."
]
}
}
Standaard- en optionele regels voor ClientConnection en HttpGatewayConnection
NSG-regel: SFMC_AllowServiceFabricGatewayToSFRP
Er wordt een standaard-NSG-regel toegevoegd om de Service Fabric-resourceprovider toegang te geven tot de clientConnectionPort en httpGatewayConnectionPort van het cluster. Met deze regel verleent u toegang tot de poorten via de servicetag 'ServiceFabric'.
Notitie
Deze regel wordt altijd toegevoegd en kan niet worden overschreven.
{
"name": "SFMC_AllowServiceFabricGatewayToSFRP",
"type": "Microsoft.Network/networkSecurityGroups/securityRules",
"properties": {
"description": "This is required rule to allow SFRP to connect to the cluster. This rule can't be overridden.",
"protocol": "TCP",
"sourcePortRange": "*",
"sourceAddressPrefix": "ServiceFabric",
"destinationAddressPrefix": "VirtualNetwork",
"access": "Allow",
"priority": 500,
"direction": "Inbound",
"sourcePortRanges": [],
"destinationPortRanges": [
"19000",
"19080"
]
}
}
NSG-regel: SFMC_AllowServiceFabricGatewayPorts
Met deze optionele regel kunnen klanten toegang krijgen tot SFX, verbinding maken met het cluster met behulp van PowerShell en Service Fabric-cluster-API-eindpunten gebruiken vanaf internet door LB-poorten te openen voor clientConnectionPort en httpGatewayPort.
Notitie
Deze regel wordt niet toegevoegd als er een aangepaste regel is met dezelfde toegangs-, richtings- en protocolwaarden voor dezelfde poort. U kunt deze regel overschrijven met aangepaste NSG-regels.
{
"name": "SFMC_AllowServiceFabricGatewayPorts",
"type": "Microsoft.Network/networkSecurityGroups/securityRules",
"properties": {
"description": "Optional rule to open SF cluster gateway ports. To override add a custom NSG rule for gateway ports in priority range 1000-3000.",
"protocol": "tcp",
"sourcePortRange": "*",
"sourceAddressPrefix": "*",
"destinationAddressPrefix": "VirtualNetwork",
"access": "Allow",
"priority": 3001,
"direction": "Inbound",
"sourcePortRanges": [],
"destinationPortRanges": [
"19000",
"19080"
]
}
}
Toegang tot RDP-poorten via internet inschakelen
Beheerde Service Fabric-clusters schakelen standaard geen inkomende toegang tot de RDP-poorten via internet in. U kunt binnenkomende toegang tot de RDP-poorten openen vanaf internet door de volgende eigenschap in te stellen op een beheerde Service Fabric-clusterresource.
"allowRDPAccess": true
Wanneer de eigenschap allowRDPAccess is ingesteld op true, wordt de volgende NSG-regel toegevoegd aan uw clusterimplementatie.
{
"name": "SFMC_AllowRdpPort",
"type": "Microsoft.Network/networkSecurityGroups/securityRules",
"properties": {
"description": "Optional rule to open RDP ports.",
"protocol": "tcp",
"sourcePortRange": "*",
"sourceAddressPrefix": "*",
"destinationAddressPrefix": "VirtualNetwork",
"access": "Allow",
"priority": 3002,
"direction": "Inbound",
"sourcePortRanges": [],
"destinationPortRange": "3389"
}
}
Beheerde Service Fabric-clusters maken automatisch binnenkomende NAT-regels voor elk exemplaar in een knooppunttype. Volg de onderstaande stappen om de poorttoewijzingen te vinden om specifieke exemplaren (clusterknooppunten) te bereiken:
Zoek met behulp van Azure Portal het beheerde cluster dat inkomende NAT-regels voor RdP (Remote Desktop Protocol) heeft gemaakt.
Navigeer naar de beheerde clusterresourcegroep in uw abonnement met de naam met de volgende indeling: SFC_{cluster-id}
Selecteer de load balancer voor het cluster met de volgende indeling: LB-{cluster-name}
Selecteer inkomende NAT-regels op de pagina voor uw load balancer. Controleer de binnenkomende NAT-regels om de binnenkomende front-endpoort naar de doelpoorttoewijzing voor een knooppunt te bevestigen.
In de volgende schermopname ziet u de binnenkomende NAT-regels voor drie verschillende knooppunttypen:
Voor Windows-clusters bevindt de front-endpoort zich standaard in het bereik 50000 en hoger en is de doelpoort poort 3389, die wordt toegewezen aan de RDP-service op het doelknooppunt.
Notitie
Als u de FUNCTIE BYOLB gebruikt en RDP wilt gebruiken, moet u een NAT-pool afzonderlijk configureren om dit te doen. Hiermee worden niet automatisch NAT-regels voor deze knooppunttypen gemaakt.
Extern verbinding maken met het specifieke knooppunt (schaalsetexemplaar). U kunt de gebruikersnaam en het wachtwoord gebruiken die u hebt ingesteld bij het maken van het cluster of andere referenties die u hebt geconfigureerd.
In de volgende schermopname ziet u hoe u Verbinding met extern bureaublad gebruikt om verbinding te maken met het knooppunt apps (exemplaar 0) in een Windows-cluster:
Standaardconfiguratie van load balancer wijzigen
Load balancer-poorten
Beheerde Service Fabric-clusters maken een NSG-regel in het standaardprioriteitsbereik voor alle load balancer-poorten (LB) die zijn geconfigureerd in de sectie loadBalancingRules onder ManagedCluster-eigenschappen . Met deze regel opent u LB-poorten voor binnenkomend verkeer van internet.
Notitie
Deze regel wordt toegevoegd aan het optionele prioriteitsbereik en kan worden overschreven door aangepaste NSG-regels toe te voegen.
{
"name": "SFMC_AllowLoadBalancedPorts",
"type": "Microsoft.Network/networkSecurityGroups/securityRules",
"properties": {
"description": "Optional rule to open LB ports",
"protocol": "*",
"sourcePortRange": "*",
"sourceAddressPrefix": "*",
"destinationAddressPrefix": "VirtualNetwork",
"access": "Allow",
"priority": 3003,
"direction": "Inbound",
"sourcePortRanges": [],
"destinationPortRanges": [
"80", "8080", "4343"
]
}
}
Load balancer-tests
Beheerde Service Fabric-clusters maken automatisch load balancer-tests voor infrastructuurgatewaypoorten en alle poorten die zijn geconfigureerd in de loadBalancingRules
sectie met beheerde clustereigenschappen.
{
"value": [
{
"name": "FabricTcpGateway",
"properties": {
"provisioningState": "Succeeded",
"protocol": "Tcp",
"port": 19000,
"intervalInSeconds": 5,
"numberOfProbes": 2,
"loadBalancingRules": [
{
"id": "<>"
}
]
},
"type": "Microsoft.Network/loadBalancers/probes"
},
{
"name": "FabricHttpGateway",
"properties": {
"provisioningState": "Succeeded",
"protocol": "Tcp",
"port": 19080,
"intervalInSeconds": 5,
"numberOfProbes": 2,
"loadBalancingRules": [
{
"id": "<>"
}
]
},
"type": "Microsoft.Network/loadBalancers/probes"
},
{
"name": "probe1_tcp_8080",
"properties": {
"provisioningState": "Succeeded",
"protocol": "Tcp",
"port": 8080,
"intervalInSeconds": 5,
"numberOfProbes": 2,
"loadBalancingRules": [
{
"id": "<>"
}
]
},
"type": "Microsoft.Network/loadBalancers/probes"
}
]
}
Openbaar IP-adres inschakelen
Notitie
Momenteel wordt alleen openbare IPv4 ondersteund.
Beheerde Service Fabric-clusterknooppunten hebben geen eigen openbare IP-adressen nodig voor communicatie. In sommige scenario's moet een knooppunt echter een eigen openbaar IP-adres hebben om te communiceren met internet en openbare Azure-services. Bijvoorbeeld:
- Gaming, waarbij een console een directe verbinding moet maken met een virtuele machine in de cloud die gamefysica-verwerking uitvoert.
- Virtuele machines die externe verbindingen met elkaar moeten maken tussen regio's in een gedistribueerde database.
Zie Uitleg over uitgaande verbindingen voor meer informatie over uitgaande verbindingen in Azure.
Openbaar IP-adres kan alleen worden ingeschakeld voor secundaire knooppunttypen, omdat primaire knooppunttypen zijn gereserveerd voor Service Fabric-systeemservices. Volg de stappen in de sectie Uw eigen load balancer van dit artikel gebruiken om een secundair knooppunttype voor uw beheerde cluster te maken.
Azure wijst dynamisch beschikbare IP-adressen toe.
Notitie
Het inschakelen van een openbaar IP-adres wordt alleen ondersteund via een ARM-sjabloon.
In de volgende stappen wordt het inschakelen van een openbaar IP-adres op uw knooppunt beschreven.
Download uw ARM-sjabloon.
Voeg voor elk knooppunttype in de sjabloon toe
enableNodePublicIP
aan de ARM-sjabloon:{ "name": "<secondary_node_type_name>", "apiVersion": "2023-02-01-preview", "properties": { "isPrimary" : false, "vmImageResourceId": "/subscriptions/<your_subscription_id>/resourceGroups/<your_resource_group>/providers/Microsoft.Compute/images/<your_custom_image>", "vmSize": "Standard_D2", "vmInstanceCount": 5, "dataDiskSizeGB": 100, "enableNodePublicIP": true } }
Controleer of uw knooppunten een openbaar IP-adres hebben door de volgende PowerShell-opdracht uit te voeren:
az vmss list-instance-public-ips -g MC_MyResourceGroup2_MyManagedCluster_eastus -n YourVirtualMachineScaleSetName
De opdracht wordt uitgevoerd in JSON-indeling.
[ { "etag": "etag_0", "id": "<id_0/name>", "idleTimeoutInMinutes": 15, "ipAddress": "<ip_address_0>", "ipConfiguration": { "id": "<configuration_id_0>", "resourceGroup": "<your_resource_group>" }, "ipTags": [], "name": "<name>", "provisioningState": "Succeeded", "publicIPAddressVersion": "IPv4", "publicIPAllocationMethod": "Static", "resourceGroup": "<your_resource_group>", "resourceGuid": "resource_guid_0", "sku": { "name": "Standard" } }, { "etag": "etag_1", "id": "/<id_1/name>", "idleTimeoutInMinutes": 15, "ipAddress": "<ip_address_1>", "ipConfiguration": { "id": "<configuration_id_1>", "resourceGroup": "<your_resource_group>" }, "ipTags": [], "name": "<name>", "provisioningState": "Succeeded", "publicIPAddressVersion": "IPv4", "publicIPAllocationMethod": "Static", "resourceGroup": "<your_resource_group>", "resourceGuid": "resource_guid_1", "sku": { "name": "Standard" } }, { "etag": "etag_2", "id": "<id_2/name>", "idleTimeoutInMinutes": 15, "ipAddress": "<ip_address_2>", "ipConfiguration": { "id": "<configuration_id_2>", "resourceGroup": "<your_resource_group>" }, "ipTags": [], "name": "<name>", "provisioningState": "Succeeded", "publicIPAddressVersion": "IPv4", "publicIPAllocationMethod": "Static", "resourceGroup": "<your_resource_group>", "resourceGuid": "resource_guid_2", "sku": { "name": "Standard" } } ]
IPv6 inschakelen
Beheerde clusters schakelen IPv6 niet standaard in. Met deze functie wordt volledige IPv4-/IPv6-functionaliteit met dubbele stack ingeschakeld van de Load Balancer front-end naar de back-endresources. Wijzigingen die u aanbrengt in de configuratie van de load balancer of NSG-regels voor beheerde clusters, zijn van invloed op zowel de IPv4- als IPv6-routering.
Notitie
Deze instelling is niet beschikbaar in de portal en kan niet worden gewijzigd nadat het cluster is gemaakt.
- De apiVersion van de beheerde Service Fabric-clusterresource moet 2022-01-01 of hoger zijn.
Stel de volgende eigenschap in voor een beheerde Service Fabric-clusterresource.
"resources": [ { "apiVersion": "[variables('sfApiVersion')]", "type": "Microsoft.ServiceFabric/managedclusters", ... "properties": { "enableIpv6": true }, } ]
Implementeer uw beheerde IPv6-cluster. Pas de voorbeeldsjabloon naar behoefte aan of bouw uw eigen sjabloon. In het volgende voorbeeld maken we een resourcegroep die wordt aangeroepen
MyResourceGroup
enwestus
implementeren we een cluster waarvoor deze functie is ingeschakeld.New-AzResourceGroup -Name MyResourceGroup -Location westus New-AzResourceGroupDeployment -Name deployment -ResourceGroupName MyResourceGroup -TemplateFile AzureDeploy.json
Na de implementatie zijn het virtuele netwerk en de resources van uw clusters dual-stack. Als gevolg hiervan wordt voor de front-end load balancer van de clusters een uniek DNS-adres gemaakt dat
mycluster-ipv6.southcentralus.cloudapp.azure.com
bijvoorbeeld is gekoppeld aan een openbaar IPv6-adres op de Azure Load Balancer en privé-IPv6-adressen op de VM's.
Uw eigen virtuele netwerk gebruiken
Met deze functie kunnen klanten een bestaand virtueel netwerk gebruiken door een toegewezen subnet op te geven waarin het beheerde cluster de resources gaat implementeren. Dit kan handig zijn als u al een geconfigureerd VNet en subnet hebt met gerelateerd beveiligingsbeleid en verkeersroutering die u wilt gebruiken. Nadat u in een bestaand virtueel netwerk hebt geïmplementeerd, kunt u eenvoudig andere netwerkfuncties gebruiken of opnemen, zoals Azure ExpressRoute, Azure VPN Gateway, een netwerkbeveiligingsgroep en peering van virtuele netwerken. Daarnaast kunt u indien nodig ook uw eigen Azure Load Balancer meenemen .
Notitie
Wanneer u BYOVNET gebruikt, worden beheerde clusterresources geïmplementeerd in één subnet.
Notitie
Deze instelling kan niet worden gewijzigd nadat het cluster is gemaakt en het beheerde cluster een NSG toewijst aan het opgegeven subnet. Overschrijf de NSG-toewijzing niet, anders kan het verkeer worden onderbroken.
Uw eigen virtuele netwerk gebruiken:
Haal de service
Id
op uit uw abonnement voor de Service Fabric Resource Provider-toepassing.Login-AzAccount Select-AzSubscription -SubscriptionId <SubId> Get-AzADServicePrincipal -DisplayName "Azure Service Fabric Resource Provider"
Notitie
Zorg ervoor dat u zich in het juiste abonnement bevindt. De principal-id wordt gewijzigd als het abonnement zich in een andere tenant bevindt.
ServicePrincipalNames : {74cb6831-0dbb-4be1-8206-fd4df301cdc2} ApplicationId : 74cb6831-0dbb-4be1-8206-fd4df301cdc2 ObjectType : ServicePrincipal DisplayName : Azure Service Fabric Resource Provider Id : 00000000-0000-0000-0000-000000000000
Noteer de id van de vorige uitvoer als principalId voor gebruik in een latere stap
Naam van roldefinitie Roldefinitie-id Inzender voor netwerken 4d97b98b-1d4f-4787-a291-c67834d212e7 Noteer de
Role definition name
eigenschapswaarden enRole definition ID
voor gebruik in een latere stapVoeg een roltoewijzing toe aan de Service Fabric Resource Provider-toepassing. Het toevoegen van een roltoewijzing is een eenmalige actie. U voegt de rol toe door de volgende PowerShell-opdrachten uit te voeren of door een Arm-sjabloon (Azure Resource Manager) te configureren, zoals hieronder wordt beschreven.
In de volgende stappen beginnen we met een bestaand virtueel netwerk met de naam ExistingRG-vnet, in de resourcegroep ExistingRG. Het subnet heeft de naam default.
Haal de vereiste informatie op uit het bestaande VNet.
Login-AzAccount Select-AzSubscription -SubscriptionId <SubId> Get-AzVirtualNetwork -Name ExistingRG-vnet -ResourceGroupName ExistingRG
Noteer de volgende subnetnaam en
Id
eigenschapswaarde die worden geretourneerd uit deSubnets
sectie in het antwoord dat u in latere stappen gaat gebruiken.Subnets:[ { ... "Id": "/subscriptions/<subscriptionId>/resourceGroups/Existing-RG/providers/Microsoft.Network/virtualNetworks/ExistingRG-vnet/subnets/default" }]
Voer de volgende PowerShell-opdracht uit met behulp van de principal-id, de naam van de roldefinitie uit stap 2 en het toewijzingsbereik
Id
dat hierboven is verkregen:New-AzRoleAssignment -PrincipalId 00000000-0000-0000-0000-000000000000 -RoleDefinitionName "Network Contributor" -Scope "/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/<subnetName>"
U kunt de roltoewijzing ook toevoegen met behulp van een Arm-sjabloon (Azure Resource Manager) die is geconfigureerd met de juiste waarden voor
principalId
,roleDefinitionId
,vnetName
ensubnetName
:"type": "Microsoft.Authorization/roleAssignments", "apiVersion": "2020-04-01-preview", "name": "[parameters('VNetRoleAssignmentID')]", "scope": "[concat('Microsoft.Network/virtualNetworks/', parameters('vnetName'), '/subnets/', parameters('subnetName'))]", "dependsOn": [ "[concat('Microsoft.Network/virtualNetworks/', parameters('vnetName'))]" ], "properties": { "roleDefinitionId": "[concat('/subscriptions/', subscription().subscriptionId, '/providers/Microsoft.Authorization/roleDefinitions/4d97b98b-1d4f-4787-a291-c67834d212e7')]", "principalId": "00000000-0000-0000-0000-000000000000" }
Notitie
VNetRoleAssignmentID moet een GUID zijn. Als u opnieuw een sjabloon implementeert met deze roltoewijzing, moet u ervoor zorgen dat de GUID dezelfde is als de guid die oorspronkelijk is gebruikt. We raden u aan deze geïsoleerd uit te voeren of deze resource na de implementatie uit de clustersjabloon te verwijderen, omdat deze slechts één keer hoeft te worden gemaakt.
Hier volgt een volledig azure Resource Manager-sjabloon (ARM) waarmee een VNet-subnet wordt gemaakt en roltoewijzingen worden uitgevoerd die u voor deze stap kunt gebruiken.
Configureer de
subnetId
eigenschap voor de clusterimplementatie nadat de rol is ingesteld, zoals hieronder wordt weergegeven:
De apiVersion van de beheerde Service Fabric-clusterresource moet 2022-01-01 of hoger zijn.
"resources": [ { "apiVersion": "[variables('sfApiVersion')]", "type": "Microsoft.ServiceFabric/managedclusters", ... }, "properties": { "subnetId": "subnetId", ... } ]
Zie de voorbeeldsjabloon Bring Your Own VNet cluster of pas uw eigen cluster aan.
Implementeer de geconfigureerde AZURE Resource Manager-sjabloon (ARM) voor beheerde clusters.
In het volgende voorbeeld maken we een resourcegroep die wordt
westus
aangeroepenMyResourceGroup
en implementeren we een cluster waarvoor deze functie is ingeschakeld.New-AzResourceGroup -Name MyResourceGroup -Location westus New-AzResourceGroupDeployment -Name deployment -ResourceGroupName MyResourceGroup -TemplateFile AzureDeploy.json
Wanneer u uw eigen VNet-subnet gebruikt, wordt het openbare eindpunt nog steeds gemaakt en beheerd door de resourceprovider, maar in het geconfigureerde subnet. Met de functie kunt u het openbare IP-adres/het statische IP-adres niet opgeven op de Azure Load Balancer. U kunt uw eigen Azure Load Balancer in combinatie met deze functie of op zichzelf als u deze of andere load balancer-scenario's nodig hebt die niet systeemeigen worden ondersteund.
Uw eigen Azure Load Balancer
Beheerde clusters maken een openbare Azure-Standard Load Balancer en een volledig gekwalificeerde domeinnaam met een statisch openbaar IP-adres voor zowel het primaire als secundaire knooppunttype. Met Uw eigen load balancer kunt u een bestaande Azure Load Balancer gebruiken voor secundaire knooppunttypen voor zowel inkomend als uitgaand verkeer. Wanneer u uw eigen Azure Load Balancer mee te nemen, kunt u het volgende doen:
- Een vooraf geconfigureerd Load Balancer statisch IP-adres gebruiken voor privé- of openbaar verkeer
- Een Load Balancer toewijzen aan een specifiek knooppunttype
- Regels voor netwerkbeveiligingsgroepen per knooppunttype configureren, omdat elk knooppunttype wordt geïmplementeerd in een eigen subnet
- Bestaande beleidsregels en besturingselementen onderhouden die u mogelijk hebt
- Een interne load balancer configureren en de standaard load balancer gebruiken voor extern verkeer
Notitie
Wanneer u BYOVNET gebruikt, worden beheerde clusterresources geïmplementeerd in één subnet met één NSG, ongeacht extra geconfigureerde load balancers.
Notitie
U kunt niet overschakelen van de standaard load balancer naar een aangepaste load balancer na de implementatie van een knooppunttype, maar u kunt de aangepaste load balancer-configuratie na de implementatie wijzigen als deze is ingeschakeld.
Functievereisten
- De typen Basic- en Standard-SKU-Azure Load Balancer worden ondersteund
- U moet back-end- en NAT-pools hebben geconfigureerd op de Azure Load Balancer
- U moet uitgaande connectiviteit inschakelen met behulp van een opgegeven openbare load balancer of de standaard openbare load balancer
Hier volgen enkele voorbeeldscenario's die klanten kunnen gebruiken voor:
In dit voorbeeld wil een klant verkeer routeren via een bestaande Azure Load Balancer geconfigureerd met een bestaand statisch IP-adres naar twee knooppunttypen.
In dit voorbeeld wil een klant verkeer routeren via bestaande Azure Load Balancers om hen te helpen bij het beheren van de verkeersstroom naar hun toepassingen die zich op afzonderlijke knooppunttypen bevinden. Wanneer dit wordt ingesteld zoals in dit voorbeeld, bevindt elk knooppunttype zich achter zijn eigen beheerde NSG.
In dit voorbeeld wil een klant verkeer routeren via bestaande interne Azure Load Balancers. Zo kunnen ze de verkeersstroom naar hun toepassingen onafhankelijk beheren die op afzonderlijke knooppunttypen staan. Bij de configuratie zoals in dit voorbeeld bevindt elk knooppunttype zich achter zijn eigen beheerde NSG en wordt de standaard load balancer voor extern verkeer gebruikt.
Configureren met uw eigen load balancer:
Haal de service
Id
op uit uw abonnement voor de Service Fabric Resource Provider-toepassing:Login-AzAccount Select-AzSubscription -SubscriptionId <SubId> Get-AzADServicePrincipal -DisplayName "Azure Service Fabric Resource Provider"
Notitie
Zorg ervoor dat u zich in het juiste abonnement bevindt. De principal-id wordt gewijzigd als het abonnement zich in een andere tenant bevindt.
ServicePrincipalNames : {74cb6831-0dbb-4be1-8206-fd4df301cdc2} ApplicationId : 74cb6831-0dbb-4be1-8206-fd4df301cdc2 ObjectType : ServicePrincipal DisplayName : Azure Service Fabric Resource Provider Id : 00000000-0000-0000-0000-000000000000
Noteer de id van de vorige uitvoer als principalId voor gebruik in een latere stap
Naam van roldefinitie Roldefinitie-id Inzender voor netwerken 4d97b98b-1d4f-4787-a291-c67834d212e7 Noteer de
Role definition name
eigenschapswaarden enRole definition ID
voor gebruik in een latere stapVoeg een roltoewijzing toe aan de Service Fabric Resource Provider-toepassing. Het toevoegen van een roltoewijzing is een eenmalige actie. U voegt de rol toe door de volgende PowerShell-opdrachten uit te voeren of door een Arm-sjabloon (Azure Resource Manager) te configureren, zoals hieronder wordt beschreven.
In de volgende stappen beginnen we met een bestaande load balancer met de naam Existing-LoadBalancer1, in de resourcegroep Existing-RG.
Haal de vereiste
Id
eigenschapsgegevens op uit de bestaande Azure Load Balancer.Login-AzAccount Select-AzSubscription -SubscriptionId <SubId> Get-AzLoadBalancer -Name "Existing-LoadBalancer1" -ResourceGroupName "Existing-RG"
Let op het volgende
Id
dat u in de volgende stap gaat gebruiken:{ ... "Id": "/subscriptions/<subscriptionId>/resourceGroups/Existing-RG/providers/Microsoft.Network/loadBalancers/Existing-LoadBalancer1" }
Voer de volgende PowerShell-opdracht uit met behulp van de principal-id, de naam van de roldefinitie uit stap 2 en het toewijzingsbereik
Id
dat u zojuist hebt verkregen:New-AzRoleAssignment -PrincipalId 00000000-0000-0000-0000-000000000000 -RoleDefinitionName "Network Contributor" -Scope "/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/loadBalancers/<LoadBalancerName>"
U kunt de roltoewijzing ook toevoegen met behulp van een ARM-sjabloon (Azure Resource Manager) die is geconfigureerd met de juiste waarden voor
principalId
,roleDefinitionId
":"type": "Microsoft.Authorization/roleAssignments", "apiVersion": "2020-04-01-preview", "name": "[parameters('loadBalancerRoleAssignmentID')]", "scope": "[concat('Microsoft.Network/loadBalancers/', variables('lbName'))]", "dependsOn": [ "[concat('Microsoft.Network/loadBalancers/', variables('lbName'))]" ], "properties": { "roleDefinitionId": "[concat('/subscriptions/', subscription().subscriptionId, '/providers/Microsoft.Authorization/roleDefinitions/4d97b98b-1d4f-4787-a291-c67834d212e7')]", "principalId": "00000000-0000-0000-0000-000000000000" }
Notitie
loadBalancerRoleAssignmentID moet een GUID zijn. Als u opnieuw een sjabloon implementeert met deze roltoewijzing, moet u ervoor zorgen dat de GUID dezelfde is als de guid die oorspronkelijk is gebruikt. We raden u aan deze geïsoleerd uit te voeren of deze resource na de implementatie uit de clustersjabloon te verwijderen, omdat deze slechts één keer hoeft te worden gemaakt.
Zie deze voorbeeldsjabloon om een openbare load balancer te maken en een rol toe te wijzen.
Configureer de vereiste uitgaande connectiviteit voor het knooppunttype. U moet een openbare load balancer configureren om uitgaande connectiviteit te bieden of de standaard openbare load balancer gebruiken.
Configureren
outboundRules
om een openbare load balancer te configureren om uitgaande connectiviteit te bieden Zie de azure-sjabloon Azure Resource Manager (ARM) voor het maken van een load balancer en rol toewijzenOF
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 } } ]
Configureer eventueel een binnenkomende toepassingspoort en een gerelateerde test op uw bestaande Azure Load Balancer. Zie de ARM-sjabloon (Bring Your Own Load Balancer)-voorbeeld van Azure Resource Manager (ARM) voor een voorbeeld
Configureer eventueel de NSG-regels voor het beheerde cluster die worden toegepast op het knooppunttype om toe te staan dat vereist verkeer dat u hebt geconfigureerd op de Azure Load Balancer of dat verkeer wordt geblokkeerd. Zie de ARM-sjabloon (Bring Your Own Load Balancer)-voorbeeld van Azure Resource Manager (ARM) voor een voorbeeld van de configuratie van een binnenkomende NSG-regel. Zoek in de sjabloon naar de
networkSecurityRules
eigenschap.De geconfigureerde ARM-sjabloon voor het beheerde cluster implementeren Voor deze stap gebruiken we de ARM-sjabloon (Bring Your Own Load Balancer)-voorbeeld van Azure Resource Manager (ARM)
Hieronder wordt een resourcegroep gemaakt die wordt aangeroepen
MyResourceGroup
inwestus
en wordt een cluster geïmplementeerd met behulp van een bestaande load balancer.New-AzResourceGroup -Name MyResourceGroup -Location westus New-AzResourceGroupDeployment -Name deployment -ResourceGroupName MyResourceGroup -TemplateFile AzureDeploy.json
Na de implementatie wordt het secundaire knooppunttype geconfigureerd voor het gebruik van de opgegeven load balancer voor binnenkomend en uitgaand verkeer. De Service Fabric-clientverbinding en gateway-eindpunten verwijzen nog steeds naar de openbare DNS van het primaire knooppunttype van het beheerde cluster, zoals het statische IP-adres.
Versneld netwerken inschakelen
Versneld netwerken maakt I/O-virtualisatie met één hoofdmap (SR-IOV) mogelijk voor een VIRTUELE-machineschaalset-VM die de onderliggende resource voor knooppunttypen is. Dit pad met hoge prestaties omzeilt de host van het gegevenspad, waardoor latentie, jitter en CPU-gebruik voor de meest veeleisende netwerkworkloads worden verminderd. Beheerde Service Fabric-clusterknooppunttypen kunnen worden ingericht met versneld netwerken op ondersteunde VM-SKU's. Raadpleeg deze beperkingen en beperkingen voor aanvullende overwegingen.
- Houd er rekening mee dat versneld netwerken wordt ondersteund op de meeste instantiegrootten voor algemeen gebruik en geoptimaliseerd voor rekenkracht met 2 of meer vCPU's. Op exemplaren die hyperthreading ondersteunen, wordt versneld netwerken ondersteund op VM-exemplaren met 4 of meer vCPU's.
Schakel versneld netwerken in door als volgt de eigenschap in uw Resource Manager-sjabloon te declarerenenableAcceleratedNetworking
:
- De apiVersion van de beheerde Service Fabric-clusterresource moet 2022-01-01 of hoger zijn.
{
"apiVersion": "[variables('sfApiVersion')]",
"type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
...
"properties": {
...
"enableAcceleratedNetworking": true,
...
}
Als u versneld netwerken wilt inschakelen in een bestaand Service Fabric-cluster, moet u eerst een Service Fabric-cluster uitschalen door een nieuw knooppunttype toe te voegen en het volgende te doen:
- Een knooppunttype inrichten met Versneld netwerken ingeschakeld
- Migreer uw services en hun status naar het ingerichte knooppunttype met versneld netwerken ingeschakeld
Het uitschalen van de infrastructuur is vereist om versneld netwerken in te schakelen op een bestaand cluster, omdat het inschakelen van versneld netwerken ter plaatse downtime zou veroorzaken, omdat hiervoor alle virtuele machines in een beschikbaarheidsset moeten worden gestopt en de toewijzing ervan ongedaan moeten worden gemaakt voordat versneld netwerken op een bestaande NIC wordt ingeschakeld.
Hulpsubnetten configureren
Hulpsubnetten bieden de mogelijkheid om extra beheerde subnetten zonder een knooppunttype te maken voor ondersteunende scenario's zoals Private Link Service en Bastion-hosts.
Configureer hulpsubnetten door als volgt eigenschap en vereiste parameters in uw Resource Manager-sjabloon te declarerenauxiliarySubnets
:
- De apiVersion van de beheerde Service Fabric-clusterresource moet 2022-01-01 of hoger zijn.
"resources": [
{
"apiVersion": "[variables('sfApiVersion')]",
"type": "Microsoft.ServiceFabric/managedclusters",
"properties": {
"auxiliarySubnets": [
{
"name" : "mysubnet",
"enableIpv6" : "true"
}
]
}
}
]
Volledige lijst met beschikbare parameters weergeven
Volgende stappen
Configuratieopties voor beheerde Service Fabric-clusters Overzicht van beheerde ServiceFabric-clusters