Service Fabric-netwerkpatronen

U kunt uw Azure Service Fabric-cluster integreren met andere Azure-netwerkfuncties. In dit artikel laten we u zien hoe u clusters maakt die gebruikmaken van de volgende functies:

• Bestaand virtueel netwerk of subnet
• Statisch openbaar IP-adres
• Interne load balancer
• Interne en externe load balancer

Service Fabric wordt uitgevoerd in een standaard virtuele-machineschaalset. Elke functionaliteit die u in een virtuele-machineschaalset kunt gebruiken, kunt u gebruiken met een Service Fabric-cluster. De netwerksecties van de Azure Resource Manager-sjablonen voor virtuele-machineschaalsets en Service Fabric zijn identiek. Nadat u in een bestaand virtueel netwerk hebt geïmplementeerd, kunt u eenvoudig andere netwerkfuncties opnemen, zoals Azure ExpressRoute, Azure VPN Gateway, een netwerkbeveiligingsgroep en peering van virtuele netwerken.

De Service Fabric-resourceprovider toestaan om query's uit te voeren op uw cluster

Service Fabric is in één aspect uniek van andere netwerkfuncties. De Azure Portal maakt intern gebruik van de Service Fabric-resourceprovider om een cluster aan te roepen voor informatie over knooppunten en toepassingen. De Service Fabric-resourceprovider vereist openbaar toegankelijke binnenkomende toegang tot de HTTP-gatewaypoort (standaard poort 19080) op het beheereindpunt. Service Fabric Explorer gebruikt het beheereindpunt om uw cluster te beheren. De Service Fabric-resourceprovider gebruikt deze poort ook om informatie over uw cluster op te vragen en weer te geven in de Azure Portal.

Als poort 19080 niet toegankelijk is via de Service Fabric-resourceprovider, wordt een bericht zoals Knooppunten niet gevonden weergegeven in de portal en worden uw knooppunt en toepassingslijst leeg weergegeven. Als u uw cluster in de Azure Portal wilt zien, moet uw load balancer een openbaar IP-adres beschikbaar maken en moet uw netwerkbeveiligingsgroep binnenkomend verkeer via poort 19080 toestaan. Als uw installatie niet aan deze vereisten voldoet, wordt in de Azure Portal de status van uw cluster niet weergegeven.

Notitie

U wordt aangeraden de Azure Az PowerShell-module te gebruiken om te communiceren met Azure. Zie Azure PowerShell installeren om aan de slag te gaan. Raadpleeg Azure PowerShell migreren van AzureRM naar Az om te leren hoe u naar de Azure PowerShell-module migreert.

Sjablonen

Alle Service Fabric-sjablonen bevinden zich in GitHub. U moet de sjablonen als zodanig kunnen implementeren met behulp van de volgende PowerShell-opdrachten. Als u de bestaande Azure Virtual Network-sjabloon of de statische openbare IP-sjabloon implementeert, leest u eerst de sectie Eerste installatie van dit artikel.

Eerste configuratie

Bestaand virtueel netwerk

In het volgende voorbeeld beginnen we met een bestaand virtueel netwerk met de naam ExistingRG-vnet, in de resourcegroep ExistingRG . Het subnet heeft de naam default. Deze standaardresources worden gemaakt wanneer u de Azure Portal gebruikt om een standaard virtuele machine (VM) te maken. U kunt het virtuele netwerk en subnet maken zonder de VM te maken, maar het belangrijkste doel van het toevoegen van een cluster aan een bestaand virtueel netwerk is het bieden van netwerkconnectiviteit met andere VM's. Het maken van de VM geeft een goed voorbeeld van hoe een bestaand virtueel netwerk doorgaans wordt gebruikt. Als uw Service Fabric-cluster alleen een interne load balancer gebruikt, zonder een openbaar IP-adres, kunt u de VM en het bijbehorende openbare IP-adres gebruiken als een veilige jumpbox.

Statisch openbaar IP-adres

Een statisch openbaar IP-adres is over het algemeen een toegewezen resource die afzonderlijk wordt beheerd van de VM of VM's waaraan het is toegewezen. Het wordt ingericht in een toegewezen netwerkresourcegroep (in tegenstelling tot in de Service Fabric-clusterresourcegroep zelf). Maak een statisch openbaar IP-adres met de naam staticIP1 in dezelfde ExistingRG-resourcegroep, in de Azure Portal of met behulp van PowerShell:

PS C:\Users\user> New-AzPublicIpAddress -Name staticIP1 -ResourceGroupName ExistingRG -Location westus -AllocationMethod Static -DomainNameLabel sfnetworking

Name                     : staticIP1
ResourceGroupName        : ExistingRG
Location                 : westus
Id                       : /subscriptions/1237f4d2-3dce-1236-ad95-123f764e7123/resourceGroups/ExistingRG/providers/Microsoft.Network/publicIPAddresses/staticIP1
Etag                     : W/"fc8b0c77-1f84-455d-9930-0404ebba1b64"
ResourceGuid             : 77c26c06-c0ae-496c-9231-b1a114e08824
ProvisioningState        : Succeeded
Tags                     :
PublicIpAllocationMethod : Static
IpAddress                : 40.83.182.110
PublicIpAddressVersion   : IPv4
IdleTimeoutInMinutes     : 4
IpConfiguration          : null
DnsSettings              : {
                             "DomainNameLabel": "sfnetworking",
                             "Fqdn": "sfnetworking.westus.cloudapp.azure.com"
                           }

Service Fabric-sjabloon

In de voorbeelden in dit artikel gebruiken we de Service Fabric template.json. U kunt de standaardportalwizard gebruiken om de sjabloon uit de portal te downloaden voordat u een cluster maakt. U kunt ook een van de voorbeeldsjablonen gebruiken, zoals het beveiligde Service Fabric-cluster met vijf knooppunten.

Bestaand virtueel netwerk of subnet

1. Wijzig de subnetparameter in de naam van het bestaande subnet en voeg vervolgens twee nieuwe parameters toe om te verwijzen naar het bestaande virtuele netwerk:

       "subnet0Name": {
               "type": "string",
               "defaultValue": "default"
           },
           "existingVNetRGName": {
               "type": "string",
               "defaultValue": "ExistingRG"
           },
   
           "existingVNetName": {
               "type": "string",
               "defaultValue": "ExistingRG-vnet"
           },
           /*
           "subnet0Name": {
               "type": "string",
               "defaultValue": "Subnet-0"
           },
           "subnet0Prefix": {
               "type": "string",
               "defaultValue": "10.0.0.0/24"
           },*/
   

   U kunt ook commentaar toevoegen aan de parameter met de naam 'virtualNetworkName', zodat u niet tweemaal wordt gevraagd de naam van het virtuele netwerk in te voeren op de blade clusterimplementatie in de Azure Portal.

2. nicPrefixOverride Markeer het kenmerk van Microsoft.Compute/virtualMachineScaleSets, omdat u een bestaand subnet gebruikt en u deze variabele in stap 1 hebt uitgeschakeld.

           /*"nicPrefixOverride": "[parameters('subnet0Prefix')]",*/
   

3. Wijzig de vnetID variabele zodat deze verwijst naar het bestaande virtuele netwerk:

           /*old "vnetID": "[resourceId('Microsoft.Network/virtualNetworks',parameters('virtualNetworkName'))]",*/
           "vnetID": "[concat('/subscriptions/', subscription().subscriptionId, '/resourceGroups/', parameters('existingVNetRGName'), '/providers/Microsoft.Network/virtualNetworks/', parameters('existingVNetName'))]",
   

4. Verwijder Microsoft.Network/virtualNetworks uit uw resources, zodat Azure geen nieuw virtueel netwerk maakt:

   /*{
   "apiVersion": "[variables('vNetApiVersion')]",
   "type": "Microsoft.Network/virtualNetworks",
   "name": "[parameters('virtualNetworkName')]",
   "location": "[parameters('computeLocation')]",
   "properties": {
       "addressSpace": {
           "addressPrefixes": [
               "[parameters('addressPrefix')]"
           ]
       },
       "subnets": [
           {
               "name": "[parameters('subnet0Name')]",
               "properties": {
                   "addressPrefix": "[parameters('subnet0Prefix')]"
               }
           }
       ]
   },
   "tags": {
       "resourceType": "Service Fabric",
       "clusterName": "[parameters('clusterName')]"
   }
   },*/
   

5. Markeer het virtuele netwerk uit het dependsOn kenmerk van Microsoft.Compute/virtualMachineScaleSets, zodat u niet afhankelijk bent van het maken van een nieuw virtueel netwerk:

   "apiVersion": "[variables('vmssApiVersion')]",
   "type": "Microsoft.Computer/virtualMachineScaleSets",
   "name": "[parameters('vmNodeType0Name')]",
   "location": "[parameters('computeLocation')]",
   "dependsOn": [
       /*"[concat('Microsoft.Network/virtualNetworks/', parameters('virtualNetworkName'))]",
       */
       "[Concat('Microsoft.Storage/storageAccounts/', variables('uniqueStringArray0')[0])]",
   
   

6. De sjabloon implementeren:

   New-AzResourceGroup -Name sfnetworkingexistingvnet -Location westus
   New-AzResourceGroupDeployment -Name deployment -ResourceGroupName sfnetworkingexistingvnet -TemplateFile C:\SFSamples\Final\template\_existingvnet.json
   

   Na de implementatie moet uw virtuele netwerk de nieuwe schaalset-VM's bevatten. Het knooppunttype virtuele-machineschaalset moet het bestaande virtuele netwerk en subnet weergeven. U kunt ook Remote Desktop Protocol (RDP) gebruiken om toegang te krijgen tot de VM die zich al in het virtuele netwerk bevond en om de nieuwe schaalset-VM's te pingen:

   C:>\Users\users>ping 10.0.0.5 -n 1
   C:>\Users\users>ping NOde1000000 -n 1
   

Zie een ander voorbeeld dat niet specifiek is voor Service Fabric.

Statisch openbaar IP-adres

1. Voeg parameters toe voor de naam van de bestaande statische IP-resourcegroep, naam en FQDN (Fully Qualified Domain Name):

   "existingStaticIPResourceGroup": {
               "type": "string"
           },
           "existingStaticIPName": {
               "type": "string"
           },
           "existingStaticIPDnsFQDN": {
               "type": "string"
   }
   

2. Verwijder de dnsName parameter. (Het statische IP-adres heeft er al een.)

   /*
   "dnsName": {
       "type": "string"
   },
   */
   

3. Voeg een variabele toe om te verwijzen naar het bestaande statische IP-adres:

   "existingStaticIP": "[concat('/subscriptions/', subscription().subscriptionId, '/resourceGroups/', parameters('existingStaticIPResourceGroup'), '/providers/Microsoft.Network/publicIPAddresses/', parameters('existingStaticIPName'))]",
   

4. Verwijder Microsoft.Network/publicIPAddresses uit uw resources, zodat Azure geen nieuw IP-adres maakt:

   /*
   {
       "apiVersion": "[variables('publicIPApiVersion')]",
       "type": "Microsoft.Network/publicIPAddresses",
       "name": "[concat(parameters('lbIPName'),)'-', '0')]",
       "location": "[parameters('computeLocation')]",
       "properties": {
           "dnsSettings": {
               "domainNameLabel": "[parameters('dnsName')]"
           },
           "publicIPAllocationMethod": "Dynamic"        
       },
       "tags": {
           "resourceType": "Service Fabric",
           "clusterName": "[parameters('clusterName')]"
       }
   }, */
   

5. Markeer het IP-adres uit het dependsOn kenmerk van Microsoft.Network/loadBalancers, zodat u niet afhankelijk bent van het maken van een nieuw IP-adres:

   "apiVersion": "[variables('lbIPApiVersion')]",
   "type": "Microsoft.Network/loadBalancers",
   "name": "[concat('LB', '-', parameters('clusterName'), '-', parameters('vmNodeType0Name'))]",
   "location": "[parameters('computeLocation')]",
   /*
   "dependsOn": [
       "[concat('Microsoft.Network/publicIPAddresses/', concat(parameters('lbIPName'), '-', '0'))]"
   ], */
   "properties": {
   

6. Wijzig in de Microsoft.Network/loadBalancers resource het publicIPAddress element van frontendIPConfigurations om te verwijzen naar het bestaande statische IP-adres in plaats van een nieuw gemaakt IP-adres:

               "frontendIPConfigurations": [
                       {
                           "name": "LoadBalancerIPConfig",
                           "properties": {
                               "publicIPAddress": {
                                   /*"id": "[resourceId('Microsoft.Network/publicIPAddresses',concat(parameters('lbIPName'),'-','0'))]"*/
                                   "id": "[variables('existingStaticIP')]"
                               }
                           }
                       }
                   ],
   

7. Wijzig managementEndpoint in de Microsoft.ServiceFabric/clusters resource in de DNS-FQDN van het statische IP-adres. Als u een beveiligd cluster gebruikt, moet u http:// wijzigen in https://. (Houd er rekening mee dat deze stap alleen van toepassing is op Service Fabric-clusters. Als u een virtuele-machineschaalset gebruikt, slaat u deze stap over.)

                   "fabricSettings": [],
                   /*"managementEndpoint": "[concat('http://',reference(concat(parameters('lbIPName'),'-','0')).dnsSettings.fqdn,':',parameters('nt0fabricHttpGatewayPort'))]",*/
                   "managementEndpoint": "[concat('http://',parameters('existingStaticIPDnsFQDN'),':',parameters('nt0fabricHttpGatewayPort'))]",
   

8. De sjabloon implementeren:

   New-AzResourceGroup -Name sfnetworkingstaticip -Location westus
   
   $staticip = Get-AzPublicIpAddress -Name staticIP1 -ResourceGroupName ExistingRG
   
   $staticip
   
   New-AzResourceGroupDeployment -Name deployment -ResourceGroupName sfnetworkingstaticip -TemplateFile C:\SFSamples\Final\template\_staticip.json -existingStaticIPResourceGroup $staticip.ResourceGroupName -existingStaticIPName $staticip.Name -existingStaticIPDnsFQDN $staticip.DnsSettings.Fqdn
   

Na de implementatie ziet u dat uw load balancer is gebonden aan het openbare statische IP-adres van de andere resourcegroep. Het eindpunt van de Service Fabric-clientverbinding en het Service Fabric Explorer-eindpunt verwijzen naar de DNS-FQDN van het statische IP-adres.

Interne load balancer

In dit scenario wordt de externe load balancer in de standaardService Fabric-sjabloon vervangen door een interne load balancer. Zie eerder in het artikel voor gevolgen voor de Azure Portal en voor de Service Fabric-resourceprovider.

1. Verwijder de dnsName parameter. (Dit is niet nodig.)

   /*
   "dnsName": {
       "type": "string"
   },
   */
   

2. Als u een statische toewijzingsmethode gebruikt, kunt u desgewenst een parameter voor een statisch IP-adres toevoegen. Als u een dynamische toewijzingsmethode gebruikt, hoeft u deze stap niet uit te voeren.

           "internalLBAddress": {
               "type": "string",
               "defaultValue": "10.0.0.250"
           }
   

3. Verwijder Microsoft.Network/publicIPAddresses uit uw resources, zodat Azure geen nieuw IP-adres maakt:

   /*
   {
       "apiVersion": "[variables('publicIPApiVersion')]",
       "type": "Microsoft.Network/publicIPAddresses",
       "name": "[concat(parameters('lbIPName'),)'-', '0')]",
       "location": "[parameters('computeLocation')]",
       "properties": {
           "dnsSettings": {
               "domainNameLabel": "[parameters('dnsName')]"
           },
           "publicIPAllocationMethod": "Dynamic"        
       },
       "tags": {
           "resourceType": "Service Fabric",
           "clusterName": "[parameters('clusterName')]"
       }
   }, */
   

4. Verwijder het ip-adreskenmerk dependsOn van Microsoft.Network/loadBalancers, zodat u niet afhankelijk bent van het maken van een nieuw IP-adres. Voeg het kenmerk virtueel netwerk dependsOn toe omdat de load balancer nu afhankelijk is van het subnet van het virtuele netwerk:

               "apiVersion": "[variables('lbApiVersion')]",
               "type": "Microsoft.Network/loadBalancers",
               "name": "[concat('LB','-', parameters('clusterName'),'-',parameters('vmNodeType0Name'))]",
               "location": "[parameters('computeLocation')]",
               "dependsOn": [
                   /*"[concat('Microsoft.Network/publicIPAddresses/',concat(parameters('lbIPName'),'-','0'))]"*/
                   "[concat('Microsoft.Network/virtualNetworks/',parameters('virtualNetworkName'))]"
               ],
   

5. Wijzig de instelling van frontendIPConfigurations de load balancer van het gebruik van een publicIPAddress, in het gebruik van een subnet en privateIPAddress. privateIPAddress maakt gebruik van een vooraf gedefinieerd statisch intern IP-adres. Als u een dynamisch IP-adres wilt gebruiken, verwijdert u het privateIPAddress element en wijzigt u vervolgens in privateIPAllocationMethodDynamisch.

               "frontendIPConfigurations": [
                       {
                           "name": "LoadBalancerIPConfig",
                           "properties": {
                               /*
                               "publicIPAddress": {
                                   "id": "[resourceId('Microsoft.Network/publicIPAddresses',concat(parameters('lbIPName'),'-','0'))]"
                               } */
                               "subnet" :{
                                   "id": "[variables('subnet0Ref')]"
                               },
                               "privateIPAddress": "[parameters('internalLBAddress')]",
                               "privateIPAllocationMethod": "Static"
                           }
                       }
                   ],
   

6. Wijzig in de Microsoft.ServiceFabric/clusters resource managementEndpoint om te verwijzen naar het adres van de interne load balancer. Als u een beveiligd cluster gebruikt, moet u http:// wijzigen in https://. (Houd er rekening mee dat deze stap alleen van toepassing is op Service Fabric-clusters. Als u een virtuele-machineschaalset gebruikt, slaat u deze stap over.)

                   "fabricSettings": [],
                   /*"managementEndpoint": "[concat('http://',reference(concat(parameters('lbIPName'),'-','0')).dnsSettings.fqdn,':',parameters('nt0fabricHttpGatewayPort'))]",*/
                   "managementEndpoint": "[concat('http://',reference(variables('lbID0')).frontEndIPConfigurations[0].properties.privateIPAddress,':',parameters('nt0fabricHttpGatewayPort'))]",
   

7. De sjabloon implementeren:

   New-AzResourceGroup -Name sfnetworkinginternallb -Location westus
   
   New-AzResourceGroupDeployment -Name deployment -ResourceGroupName sfnetworkinginternallb -TemplateFile C:\SFSamples\Final\template\_internalonlyLB.json
   

Na de implementatie gebruikt uw load balancer het privé statische IP-adres 10.0.0.250. Als u een andere machine in hetzelfde virtuele netwerk hebt, kunt u naar het interne Service Fabric Explorer-eindpunt gaan. Houd er rekening mee dat deze verbinding maakt met een van de knooppunten achter de load balancer.

Interne en externe load balancer

In dit scenario begint u met de bestaande externe load balancer van het type één knooppunt en voegt u een interne load balancer voor hetzelfde knooppunttype toe. Een back-endpoort die is gekoppeld aan een back-endadresgroep, kan alleen worden toegewezen aan één load balancer. Kies welke load balancer uw toepassingspoorten heeft en welke load balancer uw beheereindpunten heeft (poorten 19000 en 19080). Als u de beheereindpunten op de interne load balancer plaatst, moet u rekening houden met de beperkingen van de Service Fabric-resourceprovider die eerder in het artikel zijn besproken. In het voorbeeld dat we gebruiken, blijven de beheereindpunten op de externe load balancer staan. U voegt ook een poort 80-toepassingspoort toe en plaatst deze op de interne load balancer.

In een cluster met twee knooppunten bevindt zich één knooppunttype op de externe load balancer. Het andere knooppunttype bevindt zich op de interne load balancer. Als u een cluster met twee knooppunten wilt gebruiken, schakelt u in de portal gemaakte sjabloon met twee knooppunten (die wordt geleverd met twee load balancers) de tweede load balancer over naar een interne load balancer. Zie de sectie Alleen interne load balancer voor meer informatie.

1. Voeg de ip-adresparameter van de statische interne load balancer toe. (Zie eerdere secties van dit artikel voor opmerkingen met betrekking tot het gebruik van een dynamisch IP-adres.)

           "internalLBAddress": {
               "type": "string",
               "defaultValue": "10.0.0.250"
           }
   

2. Voeg een parameter voor toepassingspoort 80 toe.

3. Als u interne versies van de bestaande netwerkvariabelen wilt toevoegen, kopieert en plakt u deze en voegt u '-Int' toe aan de naam:

   /* Add internal load balancer networking variables */
           "lbID0-Int": "[resourceId('Microsoft.Network/loadBalancers', concat('LB','-', parameters('clusterName'),'-',parameters('vmNodeType0Name'), '-Internal'))]",
           "lbIPConfig0-Int": "[concat(variables('lbID0-Int'),'/frontendIPConfigurations/LoadBalancerIPConfig')]",
           "lbPoolID0-Int": "[concat(variables('lbID0-Int'),'/backendAddressPools/LoadBalancerBEAddressPool')]",
           "lbProbeID0-Int": "[concat(variables('lbID0-Int'),'/probes/FabricGatewayProbe')]",
           "lbHttpProbeID0-Int": "[concat(variables('lbID0-Int'),'/probes/FabricHttpGatewayProbe')]",
           "lbNatPoolID0-Int": "[concat(variables('lbID0-Int'),'/inboundNatPools/LoadBalancerBEAddressNatPool')]",
           /* Internal load balancer networking variables end */
   

4. Als u begint met de door de portal gegenereerde sjabloon die gebruikmaakt van toepassingspoort 80, voegt de standaardportalsjabloon AppPort1 (poort 80) toe aan de externe load balancer. In dit geval verwijdert u AppPort1 uit de externe load balancer loadBalancingRules en tests, zodat u deze kunt toevoegen aan de interne load balancer:

   "loadBalancingRules": [
       {
           "name": "LBHttpRule",
           "properties":{
               "backendAddressPool": {
                   "id": "[variables('lbPoolID0')]"
               },
               "backendPort": "[parameters('nt0fabricHttpGatewayPort')]",
               "enableFloatingIP": "false",
               "frontendIPConfiguration": {
                   "id": "[variables('lbIPConfig0')]"            
               },
               "frontendPort": "[parameters('nt0fabricHttpGatewayPort')]",
               "idleTimeoutInMinutes": "5",
               "probe": {
                   "id": "[variables('lbHttpProbeID0')]"
               },
               "protocol": "tcp"
           }
       } /* Remove AppPort1 from the external load balancer.
       {
           "name": "AppPortLBRule1",
           "properties": {
               "backendAddressPool": {
                   "id": "[variables('lbPoolID0')]"
               },
               "backendPort": "[parameters('loadBalancedAppPort1')]",
               "enableFloatingIP": "false",
               "frontendIPConfiguration": {
                   "id": "[variables('lbIPConfig0')]"            
               },
               "frontendPort": "[parameters('loadBalancedAppPort1')]",
               "idleTimeoutInMinutes": "5",
               "probe": {
                   "id": "[concate(variables('lbID0'), '/probes/AppPortProbe1')]"
               },
               "protocol": "tcp"
           }
       }*/
   
   ],
   "probes": [
       {
           "name": "FabricGatewayProbe",
           "properties": {
               "intervalInSeconds": 5,
               "numberOfProbes": 2,
               "port": "[parameters('nt0fabricTcpGatewayPort')]",
               "protocol": "tcp"
           }
       },
       {
           "name": "FabricHttpGatewayProbe",
           "properties": {
               "intervalInSeconds": 5,
               "numberOfProbes": 2,
               "port": "[parameters('nt0fabricHttpGatewayPort')]",
               "protocol": "tcp"
           }
       } /* Remove AppPort1 from the external load balancer.
       {
           "name": "AppPortProbe1",
           "properties": {
               "intervalInSeconds": 5,
               "numberOfProbes": 2,
               "port": "[parameters('loadBalancedAppPort1')]",
               "protocol": "tcp"
           }
       } */
   
   ],
   "inboundNatPools": [
   

5. Voeg een tweede Microsoft.Network/loadBalancers resource toe. Deze lijkt op de interne load balancer die is gemaakt in de sectie Alleen interne load balancer , maar maakt gebruik van de load balancer-variabelen '-Int' en implementeert alleen de toepassingspoort 80. Hiermee verwijdert inboundNatPoolsu ook , om RDP-eindpunten op de openbare load balancer te houden. Als u RDP op de interne load balancer wilt gebruiken, gaat inboundNatPools u van de externe load balancer naar deze interne load balancer:

           /* Add a second load balancer, configured with a static privateIPAddress and the "-Int" load balancer variables. */
           {
               "apiVersion": "[variables('lbApiVersion')]",
               "type": "Microsoft.Network/loadBalancers",
               /* Add "-Internal" to the name. */
               "name": "[concat('LB','-', parameters('clusterName'),'-',parameters('vmNodeType0Name'), '-Internal')]",
               "location": "[parameters('computeLocation')]",
               "dependsOn": [
                   /* Remove public IP dependsOn, add vnet dependsOn
                   "[concat('Microsoft.Network/publicIPAddresses/',concat(parameters('lbIPName'),'-','0'))]"
                   */
                   "[concat('Microsoft.Network/virtualNetworks/',parameters('virtualNetworkName'))]"
               ],
               "properties": {
                   "frontendIPConfigurations": [
                       {
                           "name": "LoadBalancerIPConfig",
                           "properties": {
                               /* Switch from Public to Private IP address
                               */
                               "publicIPAddress": {
                                   "id": "[resourceId('Microsoft.Network/publicIPAddresses',concat(parameters('lbIPName'),'-','0'))]"
                               }
                               */
                               "subnet" :{
                                   "id": "[variables('subnet0Ref')]"
                               },
                               "privateIPAddress": "[parameters('internalLBAddress')]",
                               "privateIPAllocationMethod": "Static"
                           }
                       }
                   ],
                   "backendAddressPools": [
                       {
                           "name": "LoadBalancerBEAddressPool",
                           "properties": {}
                       }
                   ],
                   "loadBalancingRules": [
                       /* Add the AppPort rule. Be sure to reference the "-Int" versions of backendAddressPool, frontendIPConfiguration, and the probe variables. */
                       {
                           "name": "AppPortLBRule1",
                           "properties": {
                               "backendAddressPool": {
                                   "id": "[variables('lbPoolID0-Int')]"
                               },
                               "backendPort": "[parameters('loadBalancedAppPort1')]",
                               "enableFloatingIP": "false",
                               "frontendIPConfiguration": {
                                   "id": "[variables('lbIPConfig0-Int')]"
                               },
                               "frontendPort": "[parameters('loadBalancedAppPort1')]",
                               "idleTimeoutInMinutes": "5",
                               "probe": {
                                   "id": "[concat(variables('lbID0-Int'),'/probes/AppPortProbe1')]"
                               },
                               "protocol": "tcp"
                           }
                       }
                   ],
                   "probes": [
                   /* Add the probe for the app port. */
                   {
                           "name": "AppPortProbe1",
                           "properties": {
                               "intervalInSeconds": 5,
                               "numberOfProbes": 2,
                               "port": "[parameters('loadBalancedAppPort1')]",
                               "protocol": "tcp"
                           }
                       }
                   ],
                   "inboundNatPools": [
                   ]
               },
               "tags": {
                   "resourceType": "Service Fabric",
                   "clusterName": "[parameters('clusterName')]"
               }
           },
   

6. Voeg networkProfile voor de Microsoft.Compute/virtualMachineScaleSets resource de interne back-endadresgroep toe:

   "loadBalancerBackendAddressPools": [
                                                       {
                                                           "id": "[variables('lbPoolID0')]"
                                                       },
                                                       {
                                                           /* Add internal BE pool */
                                                           "id": "[variables('lbPoolID0-Int')]"
                                                       }
   ],
   

7. De sjabloon implementeren:

   New-AzResourceGroup -Name sfnetworkinginternalexternallb -Location westus
   
   New-AzResourceGroupDeployment -Name deployment -ResourceGroupName sfnetworkinginternalexternallb -TemplateFile C:\SFSamples\Final\template\_internalexternalLB.json
   

Na de implementatie ziet u twee load balancers in de resourcegroep. Als u door de load balancers bladert, ziet u het openbare IP-adres en de beheereindpunten (poorten 19000 en 19080) die zijn toegewezen aan het openbare IP-adres. U kunt ook het statische interne IP-adres en het toepassingseindpunt (poort 80) zien die zijn toegewezen aan de interne load balancer. Beide load balancers gebruiken dezelfde back-endpool voor virtuele-machineschaalsets.

Opmerkingen voor productieworkloads

De bovenstaande GitHub-sjablonen zijn ontworpen om te werken met de standaard-SKU voor Azure Standard Load Balancer (SLB), de Basic-SKU. De Basic SKU LB heeft geen SLA, dus voor productieworkloads moet de Standard-SKU worden gebruikt. Zie overzicht van Azure Standard Load Balancer voor meer informatie hierover. Elk Service Fabric-cluster dat gebruikmaakt van de Standard-SKU voor SLB moet ervoor zorgen dat elk knooppunttype een regel heeft die uitgaand verkeer op poort 443 toestaat. Dit is nodig om de clusterinstallatie te voltooien en elke implementatie zonder een dergelijke regel mislukt. In het bovenstaande voorbeeld van een 'interne load balancer' moet een extra externe load balancer worden toegevoegd aan de sjabloon met een regel die uitgaand verkeer toestaat voor poort 443.

Volgende stappen

Een cluster maken