Padrões de rede do Service Fabric
Você pode integrar seu cluster do Azure Service Fabric com outros recursos de rede do Azure. Neste artigo, mostramos como criar clusters que usam os seguintes recursos:
- Rede virtual ou sub-rede existente
- Endereço IP público estático
- Balanceador de carga apenas interno
- Balanceador de carga interno e externo
O Service Fabric é executado em um conjunto de dimensionamento de máquina virtual padrão. Qualquer funcionalidade que você possa usar em um conjunto de dimensionamento de máquina virtual, você pode usar com um cluster do Service Fabric. As seções de rede dos modelos do Azure Resource Manager para conjuntos de dimensionamento de máquina virtual e Service Fabric são idênticas. Depois de implantar em uma rede virtual existente, é fácil incorporar outros recursos de rede, como a Rota Expressa do Azure, o Gateway de VPN do Azure, um grupo de segurança de rede e o emparelhamento de rede virtual.
Permitindo que o provedor de recursos do Service Fabric consulte seu cluster
O Service Fabric é exclusivo de outros recursos de rede em um aspeto. O portal do Azure usa internamente o provedor de recursos do Service Fabric para chamar um cluster para obter informações sobre nós e aplicativos. O provedor de recursos do Service Fabric requer acesso de entrada acessível publicamente à porta do gateway HTTP (porta 19080, por padrão) no ponto de extremidade de gerenciamento. O Service Fabric Explorer usa o ponto de extremidade de gerenciamento para gerenciar seu cluster. O provedor de recursos do Service Fabric também usa essa porta para consultar informações sobre seu cluster, para exibir no portal do Azure.
Se a porta 19080 não estiver acessível a partir do provedor de recursos do Service Fabric, uma mensagem como Nós não encontrados aparecerá no portal e sua lista de nós e aplicativos aparecerá vazia. Se você quiser ver seu cluster no portal do Azure, seu balanceador de carga deve expor um endereço IP público e seu grupo de segurança de rede deve permitir o tráfego de entrada da porta 19080. Se sua configuração não atender a esses requisitos, o portal do Azure não exibirá o status do cluster.
Nota
Recomendamos que utilize o módulo Azure Az do PowerShell para interagir com o Azure. Para começar, consulte Instalar o Azure PowerShell. Para saber como migrar para o módulo do Az PowerShell, veja Migrar o Azure PowerShell do AzureRM para o Az.
Modelos
Todos os modelos do Service Fabric estão no GitHub. Você deve ser capaz de implantar os modelos como estão usando os seguintes comandos do PowerShell. Se você estiver implantando o modelo de Rede Virtual do Azure existente ou o modelo de IP público estático, leia primeiro a seção Configuração inicial deste artigo.
Configuração inicial
Rede virtual existente
No exemplo a seguir, começamos com uma rede virtual existente chamada ExistingRG-vnet, no grupo de recursos ExistingRG . A sub-rede é denominada padrão. Esses recursos padrão são criados quando você usa o portal do Azure para criar uma máquina virtual (VM) padrão. Você pode criar a rede virtual e a sub-rede sem criar a VM, mas o objetivo principal de adicionar um cluster a uma rede virtual existente é fornecer conectividade de rede para outras VMs. A criação da VM fornece um bom exemplo de como uma rede virtual existente normalmente é usada. Se o cluster do Service Fabric usar apenas um balanceador de carga interno, sem um endereço IP público, você poderá usar a VM e seu IP público como uma caixa de salto segura.
Endereço IP público estático
Um endereço IP público estático geralmente é um recurso dedicado que é gerenciado separadamente da VM ou VMs às quais está atribuído. Ele é provisionado em um grupo de recursos de rede dedicado (em oposição ao próprio grupo de recursos de cluster do Service Fabric). Crie um endereço IP público estático chamado staticIP1 no mesmo grupo de recursos ExistingRG, no portal do Azure ou usando o 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"
}
Modelo do Service Fabric
Nos exemplos deste artigo, usamos o Service Fabric template.json. Você pode usar o assistente de portal padrão para baixar o modelo do portal antes de criar um cluster. Você também pode usar um dos modelos de exemplo, como o cluster seguro de cinco nós do Service Fabric.
Rede virtual ou sub-rede existente
Altere o parâmetro de sub-rede para o nome da sub-rede existente e, em seguida, adicione dois novos parâmetros para fazer referência à rede virtual existente:
"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" },*/Você também pode comentar o parâmetro com o nome "virtualNetworkName" para que ele não solicite que você insira o nome da rede virtual duas vezes na folha de implantação de cluster no portal do Azure.
Comente o
nicPrefixOverrideatributo deMicrosoft.Compute/virtualMachineScaleSets, porque você está usando a sub-rede existente e desabilitou essa variável na etapa 1./*"nicPrefixOverride": "[parameters('subnet0Prefix')]",*/Altere a
vnetIDvariável para apontar para a rede virtual existente:/*old "vnetID": "[resourceId('Microsoft.Network/virtualNetworks',parameters('virtualNetworkName'))]",*/ "vnetID": "[concat('/subscriptions/', subscription().subscriptionId, '/resourceGroups/', parameters('existingVNetRGName'), '/providers/Microsoft.Network/virtualNetworks/', parameters('existingVNetName'))]",Remova
Microsoft.Network/virtualNetworksdos seus recursos, para que o Azure não crie uma nova rede virtual:/*{ "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')]" } },*/Comente a rede virtual a partir do
dependsOnatributo de , para que você não dependa da criação deMicrosoft.Compute/virtualMachineScaleSetsuma nova rede virtual:"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])]",Implante o modelo:
New-AzResourceGroup -Name sfnetworkingexistingvnet -Location westus New-AzResourceGroupDeployment -Name deployment -ResourceGroupName sfnetworkingexistingvnet -TemplateFile C:\SFSamples\Final\template\_existingvnet.jsonApós a implantação, sua rede virtual deve incluir as novas VMs do conjunto de escala. O tipo de nó do conjunto de escala da máquina virtual deve mostrar a rede virtual e a sub-rede existentes. Você também pode usar o protocolo RDP (Remote Desktop Protocol) para acessar a VM que já estava na rede virtual e executar ping nas VMs do novo conjunto de escala:
C:>\Users\users>ping 10.0.0.5 -n 1 C:>\Users\users>ping NOde1000000 -n 1
Para outro exemplo, consulte um que não é específico do Service Fabric.
Endereço IP público estático
Adicione parâmetros para o nome do grupo de recursos IP estáticos existente, nome e FQDN (nome de domínio totalmente qualificado):
"existingStaticIPResourceGroup": { "type": "string" }, "existingStaticIPName": { "type": "string" }, "existingStaticIPDnsFQDN": { "type": "string" }Remova o
dnsNameparâmetro. (O endereço IP estático já tem um.)/* "dnsName": { "type": "string" }, */Adicione uma variável para fazer referência ao endereço IP estático existente:
"existingStaticIP": "[concat('/subscriptions/', subscription().subscriptionId, '/resourceGroups/', parameters('existingStaticIPResourceGroup'), '/providers/Microsoft.Network/publicIPAddresses/', parameters('existingStaticIPName'))]",Remova
Microsoft.Network/publicIPAddressesdos seus recursos, para que o Azure não crie um novo endereço IP:/* { "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')]" } }, */Comente o endereço IP do
dependsOnatributo de , para que você não dependa da criação deMicrosoft.Network/loadBalancersum novo endereço IP:"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": {No recurso, altere
Microsoft.Network/loadBalancersopublicIPAddresselemento defrontendIPConfigurationspara fazer referência ao endereço IP estático existente em vez de um recém-criado:"frontendIPConfigurations": [ { "name": "LoadBalancerIPConfig", "properties": { "publicIPAddress": { /*"id": "[resourceId('Microsoft.Network/publicIPAddresses',concat(parameters('lbIPName'),'-','0'))]"*/ "id": "[variables('existingStaticIP')]" } } } ],Microsoft.ServiceFabric/clustersNo recurso, alteremanagementEndpointpara o FQDN DNS do endereço IP estático. Se estiver a utilizar um cluster seguro, certifique-se de que altera http:// para https://. (Observe que esta etapa se aplica somente a clusters do Service Fabric. Se você estiver usando um conjunto de dimensionamento de máquina virtual, ignore esta etapa.)"fabricSettings": [], /*"managementEndpoint": "[concat('http://',reference(concat(parameters('lbIPName'),'-','0')).dnsSettings.fqdn,':',parameters('nt0fabricHttpGatewayPort'))]",*/ "managementEndpoint": "[concat('http://',parameters('existingStaticIPDnsFQDN'),':',parameters('nt0fabricHttpGatewayPort'))]",Implante o modelo:
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
Após a implantação, você pode ver que seu balanceador de carga está vinculado ao endereço IP estático público do outro grupo de recursos. O ponto de extremidade de conexão do cliente do Service Fabric e o ponto de extremidade do Service Fabric Explorer apontam para o FQDN DNS do endereço IP estático.
Balanceador de carga apenas interno
Este cenário substitui o balanceador de carga externo no modelo padrão do Service Fabric por um balanceador de carga somente interno. Consulte anteriormente no artigo para obter implicações para o portal do Azure e para o provedor de recursos do Service Fabric.
Remova o
dnsNameparâmetro. (Não é necessário.)/* "dnsName": { "type": "string" }, */Opcionalmente, se você usar um método de alocação estática, poderá adicionar um parâmetro de endereço IP estático. Se você usar um método de alocação dinâmica, não precisará executar esta etapa.
"internalLBAddress": { "type": "string", "defaultValue": "10.0.0.250" }Remova
Microsoft.Network/publicIPAddressesdos seus recursos, para que o Azure não crie um novo endereço IP:/* { "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')]" } }, */Remova o atributo de endereço
dependsOnIP do , para que você não dependa da criação deMicrosoft.Network/loadBalancersum novo endereço IP. Adicione o atributo de rededependsOnvirtual porque o balanceador de carga agora depende da sub-rede da rede virtual:"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'))]" ],Altere a configuração do
frontendIPConfigurationsbalanceador de carga de usar umpublicIPAddress, para usar uma sub-rede eprivateIPAddress.privateIPAddressusa um endereço IP interno estático predefinido. Para usar um endereço IP dinâmico, remova oprivateIPAddresselemento e mudeprivateIPAllocationMethodpara Dinâmico."frontendIPConfigurations": [ { "name": "LoadBalancerIPConfig", "properties": { /* "publicIPAddress": { "id": "[resourceId('Microsoft.Network/publicIPAddresses',concat(parameters('lbIPName'),'-','0'))]" } */ "subnet" :{ "id": "[variables('subnet0Ref')]" }, "privateIPAddress": "[parameters('internalLBAddress')]", "privateIPAllocationMethod": "Static" } } ],Microsoft.ServiceFabric/clustersNo recurso, alteremanagementEndpointpara apontar para o endereço do balanceador de carga interno. Se você usar um cluster seguro, altere http:// para https://. (Observe que esta etapa se aplica somente a clusters do Service Fabric. Se você estiver usando um conjunto de dimensionamento de máquina virtual, ignore esta etapa.)"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'))]",Implante o modelo:
New-AzResourceGroup -Name sfnetworkinginternallb -Location westus New-AzResourceGroupDeployment -Name deployment -ResourceGroupName sfnetworkinginternallb -TemplateFile C:\SFSamples\Final\template\_internalonlyLB.json
Após a implantação, o balanceador de carga usa o endereço IP estático privado 10.0.0.250. Se você tiver outra máquina nessa mesma rede virtual, poderá ir para o ponto de extremidade interno do Service Fabric Explorer . Observe que ele se conecta a um dos nós atrás do balanceador de carga.
Balanceador de carga interno e externo
Nesse cenário, você começa com o balanceador de carga externo de nó único existente e adiciona um balanceador de carga interno para o mesmo tipo de nó. Uma porta back-end conectada a um pool de endereços back-end pode ser atribuída apenas a um único balanceador de carga. Escolha qual balanceador de carga terá suas portas de aplicativo e qual balanceador de carga terá seus pontos de extremidade de gerenciamento (portas 19000 e 19080). Se você colocar os pontos de extremidade de gerenciamento no balanceador de carga interno, lembre-se das restrições do provedor de recursos do Service Fabric discutidas anteriormente no artigo. No exemplo que usamos, os pontos de extremidade de gerenciamento permanecem no balanceador de carga externo. Você também adiciona uma porta de aplicativo de porta 80 e a coloca no balanceador de carga interno.
Em um cluster de dois nós, um tipo de nó está no balanceador de carga externo. O outro tipo de nó está no balanceador de carga interno. Para usar um cluster de dois nós, no modelo de dois nós criado pelo portal (que vem com dois balanceadores de carga), alterne o segundo balanceador de carga para um balanceador de carga interno. Para obter mais informações, consulte a seção Balanceador de carga somente interno.
Adicione o parâmetro de endereço IP do balanceador de carga interno estático. (Para obter notas relacionadas ao uso de um endereço IP dinâmico, consulte as seções anteriores deste artigo.)
"internalLBAddress": { "type": "string", "defaultValue": "10.0.0.250" }Adicione um parâmetro de porta de aplicativo 80.
Para adicionar versões internas das variáveis de rede existentes, copie-as e cole-as e adicione "-Int" ao nome:
/* 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 */Se você começar com o modelo gerado pelo portal que usa a porta de aplicativo 80, o modelo de portal padrão adicionará AppPort1 (porta 80) no balanceador de carga externo. Nesse caso, remova AppPort1 do balanceador de carga externo e das sondas, para que você possa adicioná-lo ao balanceador
loadBalancingRulesde carga interno:"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": [Adicione um segundo
Microsoft.Network/loadBalancersrecurso. Ele é semelhante ao balanceador de carga interno criado na seção Balanceador de carga somente interno, mas usa as variáveis do balanceador de carga "-Int" e implementa apenas a porta 80 do aplicativo. Isso também removeinboundNatPoolso , para manter os pontos de extremidade RDP no balanceador de carga público. Se desejar RDP no balanceador de carga interno, mudeinboundNatPoolsdo balanceador de carga externo para este balanceador de carga interno:/* 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')]" } },Para
networkProfileoMicrosoft.Compute/virtualMachineScaleSetsrecurso, adicione o pool de endereços back-end interno:"loadBalancerBackendAddressPools": [ { "id": "[variables('lbPoolID0')]" }, { /* Add internal BE pool */ "id": "[variables('lbPoolID0-Int')]" } ],Implante o modelo:
New-AzResourceGroup -Name sfnetworkinginternalexternallb -Location westus New-AzResourceGroupDeployment -Name deployment -ResourceGroupName sfnetworkinginternalexternallb -TemplateFile C:\SFSamples\Final\template\_internalexternalLB.json
Após a implantação, você pode ver dois balanceadores de carga no grupo de recursos. Se você navegar pelos balanceadores de carga, poderá ver o endereço IP público e os pontos de extremidade de gerenciamento (portas 19000 e 19080) atribuídos ao endereço IP público. Você também pode ver o endereço IP interno estático e o ponto de extremidade do aplicativo (porta 80) atribuídos ao balanceador de carga interno. Ambos os balanceadores de carga usam o mesmo pool de back-end do conjunto de dimensionamento de máquina virtual.
Notas para cargas de trabalho de produção
Os modelos do GitHub acima são projetados para funcionar com a SKU padrão para o SLB (Balanceador de Carga Padrão) do Azure, a SKU Básica. O SKU LB básico não tem SLA, portanto, para cargas de trabalho de produção, o SKU padrão deve ser usado. Para saber mais sobre isso, consulte a Visão geral do Balanceador de Carga Padrão do Azure. Qualquer cluster do Service Fabric usando a SKU padrão para SLB precisa garantir que cada tipo de nó tenha uma regra que permita o tráfego de saída na porta 443. Isso é necessário para concluir a configuração do cluster, e qualquer implantação sem essa regra falhará. No exemplo acima de um balanceador de carga "apenas interno", um balanceador de carga externo adicional deve ser adicionado ao modelo com uma regra que permita o tráfego de saída para a porta 443.