Megosztás a következőn keresztül:

Service Fabric-hálózatkezelési minták

  • Cikk

Az Azure Service Fabric-fürt integrálható más Azure-hálózati funkciókkal. Ebben a cikkben bemutatjuk, hogyan hozhat létre olyan fürtöket, amelyek az alábbi funkciókat használják:

A Service Fabric egy szabványos 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ózati szakaszai azonosak. A meglévő virtuális hálózaton való üzembe helyezés után egyszerűen beépíthet más hálózati funkciókat is, például az Azure ExpressRoute-t, az Azure VPN Gatewayt, a 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ó számára lehetővé teszi a fürt lekérdezését

A Service Fabric egy szempontból egyedi a többi hálózati funkciótól. Az Azure Portal belsőleg a Service Fabric erőforrás-szolgáltatót használja egy fürt hívásához, hogy információkat kapjon a csomópontokról és alkalmazásokról. 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. A Service Fabric Explorer a felügyeleti végpontot használja a fürt kezeléséhez. A Service Fabric-erőforrás-szolgáltató ezen a porton is lekérdezi a fürt adatait az Azure Portalon való megjelenítéshez.

Ha az 19080-es 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ó , és a csomópont- és alkalmazáslista üresen jelenik meg. Ha látni szeretné a fürtöt az Azure Portalon, 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 az 19080-es port forgalmát. Ha a telepítés nem felel meg ezeknek a követelményeknek, az Azure Portal nem jeleníti meg a fürt állapotát.

Feljegyzés

Javasoljuk, hogy az Azure Az PowerShell modult használja az Azure-ral való interakcióhoz. Első lépésként tekintse meg az Azure PowerShell telepítését ismertető témakört. 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 a következő PowerShell-parancsokkal telepítheti. Ha a meglévő Azure Virtual Network-sablont vagy a statikus nyilvános IP-sablont telepíti, 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

Az alábbi példában egy MeglévőRG-vnet nevű meglévő virtuális hálózattal kezdjük a MeglévőRG erőforráscsoportban. Az alhálózat neve alapértelmezett. Ezek az alapértelmezett erőforrások akkor jönnek létre, amikor az Azure Portal használatával hoz létre egy szabványos virtuális gépet . 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 az, hogy hálózati kapcsolatot biztosítson más virtuális gépekhez. A virtuális gép létrehozása jó példát ad egy meglévő virtuális hálózat használatára. 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ímek általában egy dedikált erőforrás, amely a hozzárendelt virtuális géptől vagy virtuális gépektől külön van felügyelve. Egy dedikált hálózati erőforráscsoportban van kiépítve (szemben a Service Fabric-fürt erőforráscsoportjával). Hozzon létre egy staticIP1 nevű statikus nyilvános IP-címet ugyanabban a MeglévőRG-erőforráscsoportban, akár az Azure Portalon, akár 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 használjuk. A standard portál varázslóval letöltheti a sablont a portálról, mielőtt létrehoz egy fürtöt. Használhatja az egyik mintasablont is, például a biztonságos ötcsomópontos Service Fabric-fürtöt.

Meglévő virtuális hálózat vagy alhálózat

  1. 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"
        },*/

    Megjegyzést fűzhet a paraméterhez "virtualNetworkName" néven is, így az nem fogja kérni, hogy kétszer adja meg a virtuális hálózat nevét az Azure Portal fürttelepítési paneljén.

  2. Megjegyzés kijelölő nicPrefixOverride attribútuma Microsoft.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')]",*/

  3. 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'))]",

  4. Távolítsa el Microsoft.Network/virtualNetworks az 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')]"
}
},*/

  5. Megjegyzést fűzhet a virtuális hálózathoz az dependsOn attribútumból Microsoft.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])]",

  6. A sablon üzembe helyezése:

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

    Az ü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 jelenítenie a meglévő virtuális hálózatot és alhálózatot. A távoli asztali protokoll (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

  1. 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"
}

  2. Távolítsa el a paramétert dnsName . (A statikus IP-cím már rendelkezik ilyen címmel.)

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

  3. 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'))]",

  4. Távolítsa el Microsoft.Network/publicIPAddresses az erőforrásokból, í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')]"
    }
}, */

  5. Megjegyzést fűzhet az IP-címhez az dependsOn attribútumból Microsoft.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": {

  6. Microsoft.Network/loadBalancers Az erőforrásban módosítsa a publicIPAddress meglévő statikus IP-címre való hivatkozás elemét frontendIPConfigurations az újonnan létrehozott helyett:

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

  7. Az erőforrásban Microsoft.ServiceFabric/clusters váltson managementEndpoint a 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'))]",

  8. 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élkapcsolati végpontja és a Service Fabric Explorer végpontja a statikus IP-cím DNS-tartománynevére mutat.

Csak belső terheléselosztó

Ez a forgatókönyv az alapértelmezett Service Fabric-sablonban lévő külső terheléselosztót egy csak belső terheléselosztóra cseréli. A cikk korábbi részében az Azure Portalra és a Service Fabric-erőforrás-szolgáltatóra gyakorolt hatásokról olvashat.

  1. Távolítsa el a paramétert dnsName . (Nincs rá szükség.)

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

  2. Ha statikus kiosztási módszert használ, statikus IP-címparamétert is hozzáadhat. Ha dinamikus foglalási módszert használ, ezt a lépést nem kell elvégeznie.

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

  3. Távolítsa el Microsoft.Network/publicIPAddresses az erőforrásokból, í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')]"
    }
}, */

  4. Távolítsa el az IP-cím dependsOn attribútumát Microsoft.Network/loadBalancers, hogy ne függjön új IP-cím létrehozásától. Adja hozzá a virtuális hálózati dependsOn attribú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'))]"
            ],

  5. A terheléselosztó beállításának frontendIPConfigurations publicIPAddressmódosítása alhálózat privateIPAddressés . privateIPAddress előre definiált statikus belső IP-címet használ. Dinamikus IP-cím használatához távolítsa el az privateIPAddress elemet, majd váltson privateIPAllocationMethod dinamikusra.

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

  6. Az erőforrásban Microsoft.ServiceFabric/clusters váltson managementEndpoint a belső terheléselosztó címé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://',reference(variables('lbID0')).frontEndIPConfigurations[0].properties.privateIPAddress,':',parameters('nt0fabricHttpGatewayPort'))]",

  7. 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ép, a belső Service Fabric Explorer-végpontra léphet. 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 csatlakoztatott 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óhoz tartoznak a felügyeleti végpontok (19000- és 19080-os portok). Ha a felügyeleti végpontokat a belső terheléselosztóra helyezi, vegye figyelembe a cikkben korábban 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, és elhelyezheti a belső terheléselosztón.

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) állítsa át a második terheléselosztót egy belső terheléselosztóra. További információ: Csak belső terheléselosztó szakasz.

  1. Adja hozzá a statikus belső terheléselosztó IP-címparamé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"
        }

  2. Adjon hozzá egy 80-os alkalmazásport paramétert.

  3. 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á a "-Int" nevet 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 */

  4. 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": [

  5. Adjon hozzá egy második Microsoft.Network/loadBalancers erő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ítja inboundNatPoolsaz RDP-végpontokat a nyilvános terheléselosztón. Ha RDP-t szeretne használni a belső terheléselosztón, lépjen inboundNatPools a külső terheléselosztóról erre 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')]"
            }
        },

  6. Adja networkProfile hozzá az Microsoft.Compute/virtualMachineScaleSets erőforráshoz a belső háttércímkészletet:

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

  7. 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ó látható az erőforráscsoportban. Ha a terheléselosztókat böngészi, láthatja a nyilvános IP-címhez hozzárendelt nyilvános IP-címeket és felügyeleti végpontokat (19000-ben és 19080-ban). A belső terheléselosztóhoz rendelt statikus belső IP-cím és alkalmazásvégpont (80-os port) is látható. Mindkét terheléselosztó ugyanazt a virtuálisgép-méretezési csoportot használja háttérkészletként.

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. Minden Service Fabric-fürtnek, amely az SLB standard termékváltozatát használja, biztosítania kell, hogy minden csomóponttípus rendelkezik olyan szabálysal, amely engedélyezi a kimenő forgalmat a 443-as 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. Az "csak belső" terheléselosztó fenti példájában egy további külső terheléselosztót kell hozzáadni a sablonhoz egy olyan szabálysal, amely engedélyezi a kimenő forgalmat a 443-as porton.

Következő lépések

Fürt létrehozása