Netzwerkmuster für Service Fabric
Sie können Ihre Azure Service Fabric-Cluster in andere Azure-Netzwerkfeatures integrieren. In diesem Artikel erfahren Sie, wie Sie Cluster erstellen, die folgende Features nutzen:
- Vorhandenes virtuelles Netzwerk oder Subnetz
- Statische öffentliche IP-Adressen
- Rein interner Lastenausgleich
- Interner und externer Lastenausgleich
Service Fabric wird in einer standardmäßigen VM-Skalierungsgruppe ausgeführt. Alle Funktionen, die Sie in einer VM-Skalierungsgruppe verwenden können, können Sie mit einem Service Fabric-Cluster verwenden. Die Netzwerkabschnitte der Azure Resource Manager-Vorlagen für VM-Skalierungsgruppen und Service Fabric sind identisch. Sobald Sie ein vorhandenes virtuelles Netzwerk bereitgestellt haben, ist es einfach, andere Netzwerkfeatures wie Azure ExpressRoute, Azure-VPN-Gateway, eine Netzwerksicherheitsgruppe und Peering virtueller Netzwerke zu integrieren.
Zulassen, dass der Service Fabric-Ressourcenanbieter Ihren Cluster abfragt
Service Fabric unterscheidet sich in einem Aspekt von anderen Netzwerkfeatures. Das Azure-Portal verwendet intern den Service Fabric-Ressourcenanbieter, um Informationen über Knoten und Anwendungen von einem Cluster abzurufen. Der Service Fabric-Ressourcenanbieter erfordert öffentlich zugänglichen eingehenden Zugriff auf den HTTP-Gatewayport (standardmäßig Port 19080) auf dem Verwaltungsendpunkt. Service Fabric Explorer verwendet den Verwaltungsendpunkt zur Verwaltung Ihres Clusters. Der Service Fabric-Ressourcenanbieter verwendet diesen Port außerdem zur Abfrage von Informationen über Ihren Cluster, um sie im Azure-Portal anzuzeigen.
Wenn vom Service Fabric-Ressourcenanbieter aus kein Zugriff auf Port 19080 möglich ist, wird eine Meldung wie Knoten nicht gefunden im Portal angezeigt, und die Liste Ihrer Knoten und Anwendungen ist leer. Wenn Sie Ihren Cluster im Azure-Portal anzeigen möchten, muss Ihr Lastenausgleich eine öffentliche IP-Adresse bereitstellen, und Ihre Netzwerksicherheitsgruppe muss über Port 19080 eingehenden Datenverkehr zulassen. Wenn Ihr Setup diese Anforderungen nicht erfüllt, zeigt das Azure-Portal den Status Ihres Clusters nicht an.
Hinweis
Es wird empfohlen, das Azure Az PowerShell-Modul für die Interaktion mit Azure zu verwenden. Informationen zu den ersten Schritten finden Sie unter Installieren des Azure Az PowerShell-Moduls. Informationen zum Migrieren zum Az PowerShell-Modul finden Sie unter Migrieren von Azure PowerShell von AzureRM zum Az-Modul.
Vorlagen
Alle Service Fabric-Vorlagen befinden sich in GitHub. Sie sollten in der Lage sein, die Vorlagen mithilfe der folgenden PowerShell-Befehle ohne Änderungen bereitzustellen. Wenn Sie die vorhandene Azure Virtual Network-Vorlage oder die Vorlage der statischen öffentlichen IP bereitstellen, lesen Sie zuerst den Abschnitt Anfangssetup dieses Artikels.
Anfangssetup
Vorhandenes virtuelles Netzwerk
Im folgenden Beispiel beginnen wir mit einem vorhandenen virtuellen Netzwerk mit dem Namen „ExistingRG-vnet“ in der Ressourcengruppe ExistingRG. Das Subnetz ist standardmäßig benannt. Diese Standardressourcen werden erstellt, wenn Sie im Azure-Portal einen standardmäßigen virtuellen Computer erstellen. Sie könnten das virtuelle Netzwerk und Subnetz erstellen, ohne den virtuellen Computer zu erstellen, aber einem vorhandenen virtuellen Netzwerk einen Cluster hinzuzufügen dient im Wesentlichen dazu, die Netzwerkkonnektivität mit anderen virtuellen Computern bereitzustellen. Das Erstellen des virtuellen Computers ist ein gutes Beispiel dafür, wie ein vorhandenes virtuelles Netzwerk in der Regel verwendet wird. Wenn Ihr Service Fabric-Cluster nur einen internen Lastenausgleich ohne öffentliche IP-Adresse verwendet, können Sie die VM mit öffentlicher IP-Adresse als Jumpbox verwenden.
Statische öffentliche IP-Adressen
Eine statische öffentliche IP-Adresse ist im Allgemeinen eine dedizierte Ressourcen, die getrennt von dem virtuellen Computer bzw. den virtuellen Computern verwaltet wird, dem bzw. denen sie zugewiesen ist. Sie wird in einer dedizierten Netzwerkressourcengruppe bereitgestellt (statt in der Service Fabric-Clusterressourcengruppe selbst). Erstellen Sie entweder über das Azure-Portal oder PowerShell eine statische öffentliche IP-Adresse mit dem Namen staticIP1 in der gleichen Ressourcengruppe ExistingRG:
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-Vorlage
In den Beispielen in diesem Artikel wird die Service Fabric-template.json verwendet. Sie können die Vorlage mit dem standardmäßigen Portal-Assistenten vom Portal herunterladen, bevor Sie einen Cluster erstellen. Sie können auch eine der Beispielvorlagen verwenden, z.B. den sicheren Service Fabric-Cluster mit fünf Knoten.
Vorhandenes virtuelles Netzwerk oder Subnetz
Ändern Sie den Parameter des Subnetzes in den Namen des vorhandenen Subnetzes, und fügen Sie zwei weitere Parameter hinzu, um auf das vorhandene virtuelle Netzwerk zu verweisen:
"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" },*/Sie können auch den Parameter „virtualNetworkName“ auskommentieren, damit Sie im Azure-Portal auf dem Blatt für die Clusterbereitstellung nicht zweimal zur Eingabe des Namens des virtuellen Netzwerks aufgefordert werden.
Kommentieren Sie das Attribut
nicPrefixOverridevonMicrosoft.Compute/virtualMachineScaleSetsaus, da Sie das vorhandene Subnetz verwenden und diese Variable in Schritt 1 deaktiviert haben./*"nicPrefixOverride": "[parameters('subnet0Prefix')]",*/Ändern Sie die Variable
vnetIDso, dass sie auf das vorhandene virtuelle Netzwerk zeigt:/*old "vnetID": "[resourceId('Microsoft.Network/virtualNetworks',parameters('virtualNetworkName'))]",*/ "vnetID": "[concat('/subscriptions/', subscription().subscriptionId, '/resourceGroups/', parameters('existingVNetRGName'), '/providers/Microsoft.Network/virtualNetworks/', parameters('existingVNetName'))]",Entfernen Sie
Microsoft.Network/virtualNetworksaus Ihren Ressourcen, sodass Azure kein neues virtuelles Netzwerk erstellt:/*{ "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')]" } },*/Kommentieren Sie das virtuelle Netzwerk aus dem
dependsOn-Attribut vonMicrosoft.Compute/virtualMachineScaleSetsaus, sodass Sie nicht vom Erstellen eines neuen virtuellen Netzwerks abhängig sind:"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])]",Stellen Sie die Vorlage bereit:
New-AzResourceGroup -Name sfnetworkingexistingvnet -Location westus New-AzResourceGroupDeployment -Name deployment -ResourceGroupName sfnetworkingexistingvnet -TemplateFile C:\SFSamples\Final\template\_existingvnet.jsonNach der Bereitstellung sollte Ihr virtuelles Netzwerk die neuen Skalierungsgruppen-VMs enthalten. Der Knotentyp der VM-Skalierungsgruppe sollte das vorhandene virtuelle Netzwerk und Subnetz anzeigen. Sie können auch mit dem Remotedesktopprotokoll (Remote Desktop Protocol, RDP) auf den virtuellen Computer zugreifen, der sich bereits im virtuellen Netzwerk befand, und die neuen Skalierungsgruppen-VMs pingen:
C:>\Users\users>ping 10.0.0.5 -n 1 C:>\Users\users>ping NOde1000000 -n 1
Ein weiteres Beispiel, das nicht für Service Fabric spezifisch ist, finden Sie hier.
Statische öffentliche IP-Adressen
Fügen Sie Parameter für den Namen der vorhandenen Ressourcengruppe der statischen IP-Adresse, den Namen und den vollqualifizierten Domänennamen (FQDN) hinzu:
"existingStaticIPResourceGroup": { "type": "string" }, "existingStaticIPName": { "type": "string" }, "existingStaticIPDnsFQDN": { "type": "string" }Entfernen Sie den
dnsName-Parameter. (Die statische IP-Adresse hat bereits einen.)/* "dnsName": { "type": "string" }, */Fügen Sie eine Variable hinzu, um auf die vorhandene statische IP-Adresse zu verweisen:
"existingStaticIP": "[concat('/subscriptions/', subscription().subscriptionId, '/resourceGroups/', parameters('existingStaticIPResourceGroup'), '/providers/Microsoft.Network/publicIPAddresses/', parameters('existingStaticIPName'))]",Entfernen Sie
Microsoft.Network/publicIPAddressesaus Ihren Ressourcen, sodass Azure keine neue IP-Adresse erstellt:/* { "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')]" } }, */Kommentieren Sie die IP-Adresse aus dem
dependsOn-Attribut vonMicrosoft.Network/loadBalancersaus, sodass Sie nicht vom Erstellen einer neuen IP-Adresse abhängig sind:"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": {Ändern Sie in der
Microsoft.Network/loadBalancers-Ressource daspublicIPAddress-Element vonfrontendIPConfigurationsso, dass auf die vorhandene statische IP-Adresse statt auf eine neu erstellte verwiesen wird:"frontendIPConfigurations": [ { "name": "LoadBalancerIPConfig", "properties": { "publicIPAddress": { /*"id": "[resourceId('Microsoft.Network/publicIPAddresses',concat(parameters('lbIPName'),'-','0'))]"*/ "id": "[variables('existingStaticIP')]" } } } ],Ändern Sie in der
Microsoft.ServiceFabric/clusters-RessourcemanagementEndpointin den DNS-FQDN der statischen IP-Adresse. Wenn Sie einen sicheren Cluster verwenden, stellen Sie sicher, dass Sie http:// in https:// ändern. (Beachten Sie, dass dieser Schritt nur für Service Fabric-Cluster gilt. Überspringen Sie diesen Schritt, wenn Sie eine VM-Skalierungsgruppe für virtuelle Computer verwenden.)"fabricSettings": [], /*"managementEndpoint": "[concat('http://',reference(concat(parameters('lbIPName'),'-','0')).dnsSettings.fqdn,':',parameters('nt0fabricHttpGatewayPort'))]",*/ "managementEndpoint": "[concat('http://',parameters('existingStaticIPDnsFQDN'),':',parameters('nt0fabricHttpGatewayPort'))]",Stellen Sie die Vorlage bereit:
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
Nach der Bereitstellung sehen Sie, dass Ihr Lastenausgleich an die öffentliche statische IP-Adresse aus der anderen Ressourcengruppe gebunden ist. Der Service Fabric-Clientverbindungsendpunkt und der Service Fabric Explorer-Endpunkt zeigen beide auf den DNS-FDQN der statischen IP-Adresse.
Rein interner Lastenausgleich
Dieses Szenario ersetzt den externen Lastenausgleich in der standardmäßigen Service Fabric-Vorlage durch einen rein internen Lastenausgleich. Informationen zu Konsequenzen für das Azure-Portal und den Service Fabric-Ressourcenanbieter finden Sie oben in diesem Artikel.
Entfernen Sie den
dnsName-Parameter. (Er ist nicht erforderlich.)/* "dnsName": { "type": "string" }, */Optional können Sie einen statischen IP-Adressparameter hinzufügen, wenn Sie eine statische Zuordnungsmethode verwenden. Wenn Sie eine dynamische Zuordnungsmethode verwenden, müssen Sie diesen Schritt nicht ausführen.
"internalLBAddress": { "type": "string", "defaultValue": "10.0.0.250" }Entfernen Sie
Microsoft.Network/publicIPAddressesaus Ihren Ressourcen, sodass Azure keine neue IP-Adresse erstellt:/* { "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')]" } }, */Entfernen Sie das IP-Adressen-
dependsOn-Attribut vonMicrosoft.Network/loadBalancers, sodass Sie nicht vom Erstellen einer neuen IP-Adresse abhängig sind. Fügen Sie das AttributdependsOndes virtuellen Netzwerks hinzu, da der Lastenausgleich jetzt vom Subnetz aus dem virtuellen Netzwerk abhängig ist:"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'))]" ],Ändern Sie die Einstellung
frontendIPConfigurationsdes Lastenausgleichs von der Verwendung einerpublicIPAddressin die Verwendung eines Subnetzes und einerprivateIPAddress.privateIPAddressverwendet eine vordefinierte statische interne IP-Adresse. Um eine dynamische IP-Adresse zu verwenden, entfernen Sie dasprivateIPAddress-Element, und ändern Sie dannprivateIPAllocationMethodin Dynamisch."frontendIPConfigurations": [ { "name": "LoadBalancerIPConfig", "properties": { /* "publicIPAddress": { "id": "[resourceId('Microsoft.Network/publicIPAddresses',concat(parameters('lbIPName'),'-','0'))]" } */ "subnet" :{ "id": "[variables('subnet0Ref')]" }, "privateIPAddress": "[parameters('internalLBAddress')]", "privateIPAllocationMethod": "Static" } } ],Ändern Sie in der
Microsoft.ServiceFabric/clusters-RessourcemanagementEndpointso, dass auf die interne Adresse des Lastenausgleichs verwiesen wird. Wenn Sie einen sicheren Cluster verwenden, stellen Sie sicher, dass Sie http:// in https:// ändern. (Beachten Sie, dass dieser Schritt nur für Service Fabric-Cluster gilt. Überspringen Sie diesen Schritt, wenn Sie eine VM-Skalierungsgruppe für virtuelle Computer verwenden.)"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'))]",Stellen Sie die Vorlage bereit:
New-AzResourceGroup -Name sfnetworkinginternallb -Location westus New-AzResourceGroupDeployment -Name deployment -ResourceGroupName sfnetworkinginternallb -TemplateFile C:\SFSamples\Final\template\_internalonlyLB.json
Nach der Bereitstellung verwendet Ihr Lastenausgleich die private statische IP-Adresse 10.0.0.250. Wenn Sie in diesem gleichen virtuellen Netzwerk über einen anderen Computer verfügen, können Sie zu dem internen Service Fabric Explorer-Endpunkt gehen. Beachten Sie, dass er eine Verbindung mit einem der Knoten hinter dem Lastenausgleich herstellt.
Interner und externer Lastenausgleich
In diesem Szenario beginnen Sie mit dem vorhandenen externen Lastenausgleich mit einem einzigen Knotentyp und fügen einen internen Lastenausgleich für den gleichen Knotentyp hinzu. Ein Back-End-Port, der einem Back-End-Adresspool angefügt ist, kann nur einem einzelnen Lastenausgleich zugewiesen werden. Wählen Sie, welcher Lastenausgleich Ihre Anwendungsports und welcher Lastenausgleich Ihre Verwaltungsendpunkte (Ports 19000 und 19080) enthalten soll. Wenn Sie die Verwaltungsendpunkte auf den internen Lastenausgleich legen, beachten Sie die weiter oben in diesem Artikel erläuterten Service Fabric-Ressourcenanbieter-Einschränkungen. In unserem Beispiel verbleiben die Verwaltungsendpunkte auf dem externen Lastenausgleich. Sie können auch einen Port 80-Anwendungsport hinzufügen und auf dem internen Lastenausgleich platzieren.
In einem Zwei-Knotentypen-Cluster befindet sich ein Knotentyp auf dem externen Lastenausgleich. Der andere Knotentyp befindet sich auf dem internen Lastenausgleich. Um einen Zwei-Knotentypen-Cluster zu verwenden, wandeln Sie in der im Portal erstellten Zwei-Knotentypen-Vorlage (mit zwei Lastenausgleichsmodulen) den zweiten Lastenausgleich in einen internen Lastenausgleich um. Weitere Informationen finden Sie unter Rein interner Lastenausgleich.
Fügen Sie den statischen IP-Adressparameter für den internen Lastenausgleich hinzu. (Hinweise zur Verwendung einer dynamischen IP-Adresse finden Sie in vorherigen Abschnitten dieses Artikels.)
"internalLBAddress": { "type": "string", "defaultValue": "10.0.0.250" }Fügen Sie einen Parameter für den Anwendungsport 80 hinzu.
Um interne Versionen der vorhandenen Netzwerkvariablen hinzuzufügen, kopieren Sie sie, fügen Sie sie ein, und fügen Sie ihrem Namen das Suffix „-Int“ an:
/* 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 */Wenn Sie mit der vom Portal generierten Vorlage mit Anwendungsport 80 beginnen, fügt die Standardportalvorlage dem externen Lastenausgleich AppPort1 (Port 80) hinzu. Entfernen Sie in diesem Fall AppPort1 vom externen Lastenausgleich
loadBalancingRulesund von Tests, damit Sie ihn später dem internen Lastenausgleich hinzufügen können:"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": [Fügen Sie eine zweite
Microsoft.Network/loadBalancers-Ressource hinzu. Sie ähnelt dem im Abschnitt Rein interner Lastenausgleich erstellten internen Lastenausgleich, verwendet jedoch die „-Int“-Lastenausgleichsvariablen und implementiert nur den Anwendungsport 80. Dies entfernt auchinboundNatPools, um die RDP-Endpunkte auf dem öffentlichen Lastenausgleich beizubehalten. Wenn Sie die RDP-Endpunkte auf dem internen Lastenausgleich wünschen, verschieben SieinboundNatPoolsvom externen Lastenausgleich auf diesen internen Lastenausgleich:/* 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')]" } },Fügen Sie in
networkProfilefür dieMicrosoft.Compute/virtualMachineScaleSets-Ressource den internen Back-End-Adresspool hinzu:"loadBalancerBackendAddressPools": [ { "id": "[variables('lbPoolID0')]" }, { /* Add internal BE pool */ "id": "[variables('lbPoolID0-Int')]" } ],Stellen Sie die Vorlage bereit:
New-AzResourceGroup -Name sfnetworkinginternalexternallb -Location westus New-AzResourceGroupDeployment -Name deployment -ResourceGroupName sfnetworkinginternalexternallb -TemplateFile C:\SFSamples\Final\template\_internalexternalLB.json
Nach der Bereitstellung sehen Sie zwei Lastenausgleichsmodule in der Ressourcengruppe. Wenn Sie die Lastenausgleichsmodule durchsuchen, sehen Sie die öffentliche IP-Adresse und die Verwaltungsendpunkte (Ports 19000 und 19080), die der öffentlichen IP-Adresse zugewiesen sind. Sie können auch die statische interne IP-Adresse und den Anwendungsendpunkt (Port 80) sehen, die dem internen Lastenausgleich zugewiesen sind. Beide Lastenausgleichsmodule verwenden den gleichen VM-Skalierungsgruppen-Back-End-Pool.
Anmerkungen zu Produktionsworkloads
Die oben genannten GitHub-Vorlagen sind für die Verwendung mit der Standard-SKU für Azure Load Balancer Standard (SLB), der SKU „Basic“, konzipiert. Die Standard-SKU LB verfügt über keine SLA. Daher sollte für Produktionsarbeitslasten die Standard-SKU verwendet werden. Weitere Informationen dazu finden Sie unter Azure Load Balancer Standard: Übersicht. Jeder Service Fabric Cluster, der die Standard-SKU für SLB verwendet, muss sicherstellen, dass jeder Knotentyp über eine Regel verfügt, die ausgehenden Datenverkehr an Port 443 zulässt. Dies ist erforderlich, um die Clustereinrichtung abzuschließen, und jede Bereitstellung ohne diese Regel schlägt fehl. Im Beispiel oben für einen „nur internen“ Load Balancer muss der Vorlage ein zusätzlicher externer Load Balancer mit einer Regel hinzugefügt werden, die ausgehenden Datenverkehr für Port 443 zulässt.