Service Fabric-hálózatkezelési minták
Az Azure Service Fabric-fürtöt integrálhatja más Azure hálózati funkciókkal. Ebben a cikkben bemutatjuk, hogyan hozhat létre fürtöket, amelyek az alábbi funkciókat használják:
- Meglévő virtuális hálózat vagy alhálózat
- Statikus nyilvános IP-cím
- Csak belső terheléselosztó
- Belső és külső terheléselosztó
A Service Fabric standard virtuálisgép-méretezési csoportban fut. A virtuálisgép-méretezési csoportokban használható funkciók a Service Fabric-fürttel is használhatók. A virtuálisgép-méretezési csoportokhoz és a Service Fabrichez készült Azure Resource Manager-sablonok hálózatkezelési szakaszai azonosak. Miután üzembe helyez egy meglévő virtuális hálózaton, egyszerűen beépíthet más hálózati funkciókat, például az Azure ExpressRoute-ot, az Azure VPN Gateway-ot, egy hálózati biztonsági csoportot és a virtuális hálózatok közötti társviszony-létesítést.
A Service Fabric erőforrás-szolgáltatójának engedélyezése a fürt lekérdezésére
A Service Fabric egy szempontból egyedi a többi hálózati funkciótól. A Azure Portal belsőleg a Service Fabric erőforrás-szolgáltatót használja egy fürt meghívására a csomópontokkal és alkalmazásokkal kapcsolatos információk lekéréséhez. A Service Fabric-erőforrás-szolgáltatónak nyilvánosan elérhető bejövő hozzáférést kell biztosítani a HTTP-átjáró portjához (alapértelmezés szerint az 19080-ás porthoz) a felügyeleti végponton. Service Fabric Explorer a felügyeleti végpontot használja a fürt kezeléséhez. A Service Fabric erőforrás-szolgáltató is ezt a portot használja a fürt adatainak lekérdezéséhez, hogy megjelenjenek a Azure Portal.
Ha az 19080-s port nem érhető el a Service Fabric erőforrás-szolgáltatójától, a portálon megjelenik egy üzenet, például a Csomópontok nem találhatók , és a csomópont- és alkalmazáslista üresen jelenik meg. Ha látni szeretné a fürtöt a Azure Portal, a terheléselosztónak nyilvános IP-címet kell elérhetővé tennie, és a hálózati biztonsági csoportnak engedélyeznie kell a bejövő 19080-ás port forgalmát. Ha a beállítás nem felel meg ezeknek a követelményeknek, a Azure Portal nem jeleníti meg a fürt állapotát.
Megjegyzés
Javasoljuk, hogy az Azure Az PowerShell-modullal kommunikáljon az Azure-ral. Az első lépésekhez tekintse meg az Azure PowerShell telepítését ismertető szakaszt. Az Az PowerShell-modulra történő migrálás részleteiről lásd: Az Azure PowerShell migrálása az AzureRM modulból az Az modulba.
Sablonok
Minden Service Fabric-sablon a GitHubon található. A sablonokat az alábbi PowerShell-parancsok használatával is üzembe helyezheti. Ha a meglévő Azure Virtual Network-sablont vagy a statikus nyilvános IP-sablont helyezi üzembe, először olvassa el a cikk Kezdeti beállítás szakaszát.
Kezdeti beállítás
Meglévő virtuális hálózat
A következő példában egy MeglévőRG-vnet nevű meglévő virtuális hálózattal kezdjük a ExistingRG erőforráscsoportban. Az alhálózat neve alapértelmezett. Ezek az alapértelmezett erőforrások akkor jönnek létre, ha a Azure Portal egy standard virtuális gép (VM) létrehozásához használja. A virtuális hálózatot és az alhálózatot a virtuális gép létrehozása nélkül is létrehozhatja, de a fürt meglévő virtuális hálózathoz való hozzáadásának fő célja, hogy hálózati kapcsolatot biztosítson más virtuális gépekhez. A virtuális gép létrehozása jó példa arra, hogyan használják általában a meglévő virtuális hálózatokat. Ha a Service Fabric-fürt csak belső terheléselosztót használ nyilvános IP-cím nélkül, biztonságos jump boxként használhatja a virtuális gépet és annak nyilvános IP-címét.
Statikus nyilvános IP-cím
A statikus nyilvános IP-cím általában egy dedikált erőforrás, amelyet a hozzárendelt virtuális géptől vagy virtuális gépektől elkülönítve kezel. Egy dedikált hálózati erőforráscsoportban van kiépítve (nem a Service Fabric-fürt erőforráscsoportjában). Hozzon létre egy staticIP1 nevű statikus nyilvános IP-címet ugyanabban a MeglévőRG erőforráscsoportban a Azure Portal vagy a PowerShell használatával:
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-sablon
A cikkben szereplő példákban a Service Fabric template.json fájlt használjuk. A szabványos portálvarázslóval a fürt létrehozása előtt letöltheti a sablont a portálról. A mintasablonok egyikét is használhatja, például a biztonságos ötcsomópontos Service Fabric-fürtöt.
Meglévő virtuális hálózat vagy alhálózat
Módosítsa az alhálózat paraméterét a meglévő alhálózat nevére, majd adjon hozzá két új paramétert a meglévő virtuális hálózatra való hivatkozáshoz:
"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" },*/A paramétert a "virtualNetworkName" névvel is megjegyzéssel láthatja el, így nem fogja kérni, hogy kétszer adja meg a virtuális hálózat nevét a fürt üzembe helyezési paneljén a Azure Portal.
A megjegyzést
nicPrefixOverridejelölő attribútumaMicrosoft.Compute/virtualMachineScaleSets, mert meglévő alhálózatot használ, és letiltotta ezt a változót az 1. lépésben./*"nicPrefixOverride": "[parameters('subnet0Prefix')]",*/Módosítsa a változót
vnetIDúgy, hogy a meglévő virtuális hálózatra mutasson:/*old "vnetID": "[resourceId('Microsoft.Network/virtualNetworks',parameters('virtualNetworkName'))]",*/ "vnetID": "[concat('/subscriptions/', subscription().subscriptionId, '/resourceGroups/', parameters('existingVNetRGName'), '/providers/Microsoft.Network/virtualNetworks/', parameters('existingVNetName'))]",Távolítsa el
Microsoft.Network/virtualNetworksaz erőforrásokat, így az Azure nem hoz létre új virtuális hálózatot:/*{ "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')]" } },*/Tegye megjegyzésbe a virtuális hálózatot a
dependsOnattribútumábólMicrosoft.Compute/virtualMachineScaleSets, így nem kell új virtuális hálózatot létrehoznia:"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])]",A sablon üzembe helyezése:
New-AzResourceGroup -Name sfnetworkingexistingvnet -Location westus New-AzResourceGroupDeployment -Name deployment -ResourceGroupName sfnetworkingexistingvnet -TemplateFile C:\SFSamples\Final\template\_existingvnet.jsonAz üzembe helyezés után a virtuális hálózatnak tartalmaznia kell az új méretezési csoport virtuális gépeit. A virtuálisgép-méretezési csoport csomóponttípusának meg kell jelennie a meglévő virtuális hálózatnak és alhálózatnak. A Remote Desktop Protocol (RDP) használatával is elérheti a virtuális hálózaton már meglévő virtuális gépet, és pingelheti az új méretezési csoport virtuális gépeit:
C:>\Users\users>ping 10.0.0.5 -n 1 C:>\Users\users>ping NOde1000000 -n 1
Egy másik példaként tekintse meg a Service Fabricre nem jellemzőt.
Statikus nyilvános IP-cím
Paraméterek hozzáadása a meglévő statikus IP-erőforráscsoport nevéhez, a névhez és a teljes tartománynévhez (FQDN):
"existingStaticIPResourceGroup": { "type": "string" }, "existingStaticIPName": { "type": "string" }, "existingStaticIPDnsFQDN": { "type": "string" }Távolítsa el a paramétert
dnsName. (A statikus IP-cím már rendelkezik ilyen címmel.)/* "dnsName": { "type": "string" }, */Adjon hozzá egy változót a meglévő statikus IP-címre való hivatkozáshoz:
"existingStaticIP": "[concat('/subscriptions/', subscription().subscriptionId, '/resourceGroups/', parameters('existingStaticIPResourceGroup'), '/providers/Microsoft.Network/publicIPAddresses/', parameters('existingStaticIPName'))]",Távolítsa el
Microsoft.Network/publicIPAddressesaz erőforrásokat, így az Azure nem hoz létre új IP-címet:/* { "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')]" } }, */Tegye megjegyzésbe az IP-címet a
dependsOnattribútumábólMicrosoft.Network/loadBalancers, így nem kell új IP-címet létrehoznia:"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": {Microsoft.Network/loadBalancersAz erőforrásban módosítsa apublicIPAddresselemétfrontendIPConfigurationsúgy, hogy a meglévő statikus IP-címre hivatkozzon az újonnan létrehozott helyett:"frontendIPConfigurations": [ { "name": "LoadBalancerIPConfig", "properties": { "publicIPAddress": { /*"id": "[resourceId('Microsoft.Network/publicIPAddresses',concat(parameters('lbIPName'),'-','0'))]"*/ "id": "[variables('existingStaticIP')]" } } } ],Az erőforrásban
Microsoft.ServiceFabric/clustersváltsonmanagementEndpointa statikus IP-cím DNS-teljes tartománynevére. Ha biztonságos fürtöt használ, győződjön meg arról, hogy http://https://. (Vegye figyelembe, hogy ez a lépés csak a Service Fabric-fürtökre vonatkozik. Ha virtuálisgép-méretezési csoportot használ, hagyja ki ezt a lépést.)"fabricSettings": [], /*"managementEndpoint": "[concat('http://',reference(concat(parameters('lbIPName'),'-','0')).dnsSettings.fqdn,':',parameters('nt0fabricHttpGatewayPort'))]",*/ "managementEndpoint": "[concat('http://',parameters('existingStaticIPDnsFQDN'),':',parameters('nt0fabricHttpGatewayPort'))]",A sablon üzembe helyezése:
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
Az üzembe helyezés után láthatja, hogy a terheléselosztó a másik erőforráscsoport nyilvános statikus IP-címéhez van kötve. A Service Fabric-ügyfél kapcsolati végpontja és Service Fabric Explorer végpontja a statikus IP-cím DNS-teljes tartománynevére mutat.
Csak belső terheléselosztó
Ez a forgatókönyv lecseréli az alapértelmezett Service Fabric-sablonban lévő külső terheléselosztót egy csak belső terheléselosztóra. A cikk korábbi részében a Azure Portal és a Service Fabric-erőforrás-szolgáltatóra gyakorolt hatásokat ismertető cikkben olvashat.
Távolítsa el a paramétert
dnsName. (Nincs rá szükség.)/* "dnsName": { "type": "string" }, */Ha statikus kiosztási módszert használ, statikus IP-címparamétert is hozzáadhat. Ha dinamikus foglalási módszert használ, nem kell elvégeznie ezt a lépést.
"internalLBAddress": { "type": "string", "defaultValue": "10.0.0.250" }Távolítsa el
Microsoft.Network/publicIPAddressesaz erőforrásokat, így az Azure nem hoz létre új IP-címet:/* { "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')]" } }, */Távolítsa el a IP-cím
dependsOnattribútumát,Microsoft.Network/loadBalancersígy nem kell új IP-címet létrehoznia. Adja hozzá a virtuális hálózatidependsOnattribútumot, mert a terheléselosztó mostantól a virtuális hálózat alhálózatától függ:"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'))]" ],Módosítsa a terheléselosztó beállítását
frontendIPConfigurationsapublicIPAddress-ről alhálózatra ésprivateIPAddress.privateIPAddresselőre definiált statikus belső IP-címet használ. Dinamikus IP-cím használatához távolítsa el azprivateIPAddresselemet, majd váltsonprivateIPAllocationMethodDinamikusra."frontendIPConfigurations": [ { "name": "LoadBalancerIPConfig", "properties": { /* "publicIPAddress": { "id": "[resourceId('Microsoft.Network/publicIPAddresses',concat(parameters('lbIPName'),'-','0'))]" } */ "subnet" :{ "id": "[variables('subnet0Ref')]" }, "privateIPAddress": "[parameters('internalLBAddress')]", "privateIPAllocationMethod": "Static" } } ],Az erőforrásban
Microsoft.ServiceFabric/clustersváltsonmanagementEndpointúgy, hogy a belső terheléselosztó címére mutasson. Ha biztonságos fürtöt használ, győződjön meg arról, hogy http://https://. (Vegye figyelembe, hogy ez a lépés csak a Service Fabric-fürtökre vonatkozik. Ha virtuálisgép-méretezési csoportot használ, hagyja ki ezt a lépést.)"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'))]",A sablon üzembe helyezése:
New-AzResourceGroup -Name sfnetworkinginternallb -Location westus New-AzResourceGroupDeployment -Name deployment -ResourceGroupName sfnetworkinginternallb -TemplateFile C:\SFSamples\Final\template\_internalonlyLB.json
Az üzembe helyezés után a terheléselosztó a privát statikus 10.0.0.250 IP-címet használja. Ha ugyanabban a virtuális hálózatban van egy másik gépe, lépjen a belső Service Fabric Explorer végpontra. Vegye figyelembe, hogy a terheléselosztó mögötti csomópontok egyikéhez csatlakozik.
Belső és külső terheléselosztó
Ebben a forgatókönyvben a meglévő egycsomópontos típusú külső terheléselosztóval kell kezdenie, és hozzá kell adnia egy belső terheléselosztót ugyanahhoz a csomóponttípushoz. A háttércímkészlethez csatolt háttérportok csak egyetlen terheléselosztóhoz rendelhetők hozzá. Válassza ki, hogy melyik terheléselosztóhoz tartoznak majd az alkalmazásportok, és melyik terheléselosztó rendelkezzen a felügyeleti végpontokkal (19000-ben és 19080-ben). Ha a felügyeleti végpontokat a belső terheléselosztóra helyezi, vegye figyelembe a cikk korábbi részében tárgyalt Service Fabric-erőforrás-szolgáltatói korlátozásokat. Az általunk használt példában a felügyeleti végpontok a külső terheléselosztón maradnak. Hozzáadhat egy 80-os portot is az alkalmazásporthoz, és elhelyezheti a belső terheléselosztón.
Egy kétcsomópontos fürtben egy csomóponttípus található a külső terheléselosztón. A másik csomóponttípus a belső terheléselosztón található. Kétcsomópontos fürt használatához a portál által létrehozott kétcsomópontos típusú sablonban (amely két terheléselosztóval rendelkezik) váltsa át a második terheléselosztót egy belső terheléselosztóra. További információt a Csak belső terheléselosztó című szakaszban talál.
Adja hozzá a statikus belső terheléselosztó IP-cím paraméterét. (A dinamikus IP-cím használatával kapcsolatos megjegyzésekért tekintse meg a cikk korábbi szakaszait.)
"internalLBAddress": { "type": "string", "defaultValue": "10.0.0.250" }Adjon hozzá egy 80-os alkalmazásport paramétert.
A meglévő hálózati változók belső verzióinak hozzáadásához másolja és illessze be őket, majd adja hozzá az "-Int" kifejezést a névhez:
/* 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 */Ha a portál által létrehozott sablonnal kezdi, amely a 80-as alkalmazásportot használja, az alapértelmezett portálsablon hozzáadja az AppPort1 -et (80-as portot) a külső terheléselosztóhoz. Ebben az esetben távolítsa el az AppPort1-et a külső terheléselosztóból
loadBalancingRulesés a mintavételekből, hogy hozzáadhassa a belső terheléselosztóhoz:"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": [Adjon hozzá egy második
Microsoft.Network/loadBalancerserőforrást. Hasonlít a Csak belső terheléselosztó szakaszban létrehozott belső terheléselosztóhoz , de az "-Int" terheléselosztó változóit használja, és csak a 80-es alkalmazásportot implementálja. Ezzel eltávolítjainboundNatPoolsa elemet is, hogy az RDP-végpontok megmaradjanak a nyilvános terheléselosztón. Ha rdp-t szeretne használni a belső terheléselosztón, lépjeninboundNatPoolsa külső terheléselosztóról a belső terheléselosztóra:/* 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')]" } },Az
networkProfileerőforráshoz adja hozzá aMicrosoft.Compute/virtualMachineScaleSetsbelső háttércímkészletet:"loadBalancerBackendAddressPools": [ { "id": "[variables('lbPoolID0')]" }, { /* Add internal BE pool */ "id": "[variables('lbPoolID0-Int')]" } ],A sablon üzembe helyezése:
New-AzResourceGroup -Name sfnetworkinginternalexternallb -Location westus New-AzResourceGroupDeployment -Name deployment -ResourceGroupName sfnetworkinginternalexternallb -TemplateFile C:\SFSamples\Final\template\_internalexternalLB.json
Az üzembe helyezés után két terheléselosztó jelenik meg az erőforráscsoportban. Ha a terheléselosztók között böngészik, láthatja a nyilvános IP-címhez rendelt nyilvános IP-címeket és felügyeleti végpontokat (19000-19080-ás portokat). A belső terheléselosztóhoz rendelt statikus belső IP-címet és alkalmazásvégpontot (80-ás port) is láthatja. Mindkét terheléselosztó ugyanazt a virtuálisgép-méretezési csoport háttérkészletét használja.
Megjegyzések éles számítási feladatokhoz
A fenti GitHub-sablonok úgy lettek kialakítva, hogy az Azure standard Load Balancer (SLB) alapértelmezett termékváltozatával, az alapszintű termékváltozattal működjenek. Az alapszintű termékváltozat LB-jének nincs SLA-ja, ezért éles számítási feladatokhoz a Standard termékváltozatot kell használni. Erről további információt az Azure standard Load Balancer áttekintésében talál. Az SLB standard termékváltozatát használó Service Fabric-fürtöknek biztosítaniuk kell, hogy minden csomóponttípus rendelkezik olyan szabánnyal, amely engedélyezi a kimenő forgalmat a 443-es porton. Ez a fürt beállításának befejezéséhez szükséges, és az ilyen szabály nélküli üzembe helyezés meghiúsul. A "csak belső" terheléselosztó fenti példájában egy további külső terheléselosztót kell hozzáadni a sablonhoz egy olyan szabmánnyal, amely engedélyezi a kimenő forgalmat a 443-as porton.