Padrões de rede do Service Fabric
Pode integrar o cluster do Azure Service Fabric com outras funcionalidades de rede do Azure. Neste artigo, mostramos-lhe como criar clusters que utilizam as seguintes funcionalidades:
- 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 num conjunto de dimensionamento de máquinas virtuais padrão. Qualquer funcionalidade que possa utilizar num conjunto de dimensionamento de máquinas virtuais, pode utilizar com um cluster do Service Fabric. As secções de rede dos modelos do Azure Resource Manager para conjuntos de dimensionamento de máquinas virtuais e Service Fabric são idênticas. Depois de implementar numa rede virtual existente, é fácil incorporar outras funcionalidades de rede, como o Azure ExpressRoute, o Azure Gateway de VPN, um grupo de segurança de rede e o peering de rede virtual.
Permitir que o fornecedor de recursos do Service Fabric consulte o cluster
O Service Fabric é exclusivo de outras funcionalidades de rede num aspeto. O portal do Azure utiliza internamente o fornecedor de recursos do Service Fabric para chamar um cluster para obter informações sobre nós e aplicações. O fornecedor de recursos do Service Fabric requer acesso de entrada acessível publicamente à porta de gateway HTTP (porta 19080, por predefinição) no ponto final de gestão. Service Fabric Explorer utiliza o ponto final de gestão para gerir o cluster. O fornecedor de recursos do Service Fabric também utiliza esta porta para consultar informações sobre o cluster, para apresentar no portal do Azure.
Se a porta 19080 não estiver acessível a partir do fornecedor de recursos do Service Fabric, é apresentada uma mensagem como Nós Não Encontrados no portal e o nó e a lista de aplicações aparecem vazios. Se quiser ver o cluster no portal do Azure, o balanceador de carga tem de expor um endereço IP público e o grupo de segurança de rede tem de permitir tráfego de entrada da porta 19080. Se a configuração não cumprir estes requisitos, o portal do Azure não apresenta o estado do cluster.
Nota
Recomendamos que utilize o módulo do Azure Az PowerShell para interagir com o Azure. Veja Instalar o Azure PowerShell para começar. 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. Deverá conseguir implementar os modelos tal como estão com os seguintes comandos do PowerShell. Se estiver a implementar o modelo de Rede Virtual do Azure existente ou o modelo de IP público estático, leia primeiro a secção Configuração inicial deste artigo.
Configuração inicial
Rede virtual existente
No exemplo seguinte, começamos com uma rede virtual existente chamada ExistingRG-vnet, no grupo de recursos ExistingRG . A sub-rede tem o nome predefinido. Estes recursos predefinidos são criados quando utiliza o portal do Azure para criar uma máquina virtual (VM) padrão. Pode criar a rede virtual e a sub-rede sem criar a VM, mas o principal objetivo de adicionar um cluster a uma rede virtual existente é fornecer conectividade de rede a outras VMs. A criação da VM dá um bom exemplo de como uma rede virtual existente é normalmente utilizada. Se o cluster do Service Fabric utilizar apenas um balanceador de carga interno, sem um endereço IP público, pode utilizar a VM e o respetivo IP público como uma caixa de salto segura.
Endereço IP público estático
Geralmente, um endereço IP público estático é um recurso dedicado que é gerido separadamente da VM ou das VMs às quais está atribuído. É aprovisionado num grupo de recursos de rede dedicado (por oposição ao próprio grupo de recursos do cluster do Service Fabric). Crie um endereço IP público estático com o nome staticIP1 no mesmo grupo de recursos ExistingRG, no portal do Azure ou com 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 neste artigo, utilizamos o modelo.json do Service Fabric. Pode utilizar o assistente do portal padrão para transferir o modelo a partir do portal antes de criar um cluster. Também pode utilizar um dos modelos de exemplo, como o cluster seguro do Service Fabric de cinco nós.
Rede virtual ou sub-rede existente
Altere o parâmetro da sub-rede para o nome da sub-rede existente e, em seguida, adicione dois novos parâmetros para referenciar a 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" },*/Também pode comentar o parâmetro com o nome "virtualNetworkName" para que não lhe seja pedido que introduza o nome da rede virtual duas vezes no painel de implementação do cluster no portal do Azure.
Comente o
nicPrefixOverrideatributo deMicrosoft.Compute/virtualMachineScaleSets, porque está a utilizar a sub-rede existente e desativou esta variável no passo 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
dependsOnpartir do atributo deMicrosoft.Compute/virtualMachineScaleSets, para que não dependa da criação de uma 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])]",Implementar o modelo:
New-AzResourceGroup -Name sfnetworkingexistingvnet -Location westus New-AzResourceGroupDeployment -Name deployment -ResourceGroupName sfnetworkingexistingvnet -TemplateFile C:\SFSamples\Final\template\_existingvnet.jsonApós a implementação, a sua rede virtual deve incluir as novas VMs do conjunto de dimensionamento. O tipo de nó do conjunto de dimensionamento de máquinas virtuais deve mostrar a rede virtual e a sub-rede existentes. Também pode utilizar o Protocolo RDP (Remote Desktop Protocol) para aceder à VM que já se encontrava na rede virtual e enviar ping às novas VMs do conjunto de dimensionamento:
C:>\Users\users>ping 10.0.0.5 -n 1 C:>\Users\users>ping NOde1000000 -n 1
Para obter outro exemplo, veja um que não seja específico do Service Fabric.
Endereço IP público estático
Adicione parâmetros para o nome do grupo de recursos ip estático existente, nome e nome de domínio completamente qualificado (FQDN):
"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 referenciar o 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 a
dependsOnpartir do atributo deMicrosoft.Network/loadBalancers, para que não dependa da criação de um 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": {Microsoft.Network/loadBalancersNo recurso, altere opublicIPAddresselemento defrontendIPConfigurationspara referenciar o 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://. (Tenha em atenção que este passo se aplica apenas aos clusters do Service Fabric. Se estiver a utilizar um conjunto de dimensionamento de máquinas virtuais, ignore este passo.)"fabricSettings": [], /*"managementEndpoint": "[concat('http://',reference(concat(parameters('lbIPName'),'-','0')).dnsSettings.fqdn,':',parameters('nt0fabricHttpGatewayPort'))]",*/ "managementEndpoint": "[concat('http://',parameters('existingStaticIPDnsFQDN'),':',parameters('nt0fabricHttpGatewayPort'))]",Implementar 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 implementação, pode ver que o balanceador de carga está vinculado ao endereço IP estático público do outro grupo de recursos. O ponto final de ligação do cliente do Service Fabric e Service Fabric Explorer ponto final 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 predefinido do Service Fabric por um balanceador de carga apenas interno. Veja anteriormente no artigo as implicações para o portal do Azure e para o fornecedor de recursos do Service Fabric.
Remova o
dnsNameparâmetro. (Não é necessário.)/* "dnsName": { "type": "string" }, */Opcionalmente, se utilizar um método de alocação estático, pode adicionar um parâmetro de endereço IP estático. Se utilizar um método de alocação dinâmico, não precisa de efetuar este passo.
"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 endereço
dependsOnIP deMicrosoft.Network/loadBalancers, para que não dependa da criação de um novo endereço IP. Adicione o atributo de rededependsOnvirtual porque o balanceador de carga depende agora 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 definição do balanceador de carga de
frontendIPConfigurationsumapublicIPAddress, para utilizar uma sub-rede eprivateIPAddress.privateIPAddressutiliza um endereço IP interno estático predefinido. Para utilizar um endereço IP dinâmico, remova oprivateIPAddresselemento e, em seguida, 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 utilizar um cluster seguro, certifique-se de que altera http:// para https://. (Tenha em atenção que este passo se aplica apenas aos clusters do Service Fabric. Se estiver a utilizar um conjunto de dimensionamento de máquinas virtuais, ignore este passo.)"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'))]",Implementar o modelo:
New-AzResourceGroup -Name sfnetworkinginternallb -Location westus New-AzResourceGroupDeployment -Name deployment -ResourceGroupName sfnetworkinginternallb -TemplateFile C:\SFSamples\Final\template\_internalonlyLB.json
Após a implementação, o balanceador de carga utiliza o endereço IP estático privado 10.0.0.250. Se tiver outra máquina na mesma rede virtual, pode aceder ao ponto final interno Service Fabric Explorer. Tenha em atenção que se liga a um dos nós por trás do balanceador de carga.
Balanceador de carga interno e externo
Neste cenário, vai começar com o balanceador de carga externo do tipo de nó único existente e adicionar um balanceador de carga interno para o mesmo tipo de nó. Uma porta de back-end anexada a um conjunto de endereços de back-end só pode ser atribuída a um único balanceador de carga. Escolha o balanceador de carga que terá as portas da aplicação e qual o balanceador de carga que terá os pontos finais de gestão (portas 19000 e 19080). Se colocar os pontos finais de gestão no balanceador de carga interno, tenha em atenção as restrições do fornecedor de recursos do Service Fabric abordadas anteriormente no artigo. No exemplo que utilizamos, os pontos finais de gestão permanecem no balanceador de carga externo. Também adiciona uma porta de aplicação porta 80 e coloca-a no balanceador de carga interno.
Num 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 utilizar um cluster de dois nós, no modelo de dois nós criado pelo portal (que vem com dois balanceadores de carga), mude o segundo balanceador de carga para um balanceador de carga interno. Para obter mais informações, veja a secção Balanceador de carga apenas interno .
Adicione o parâmetro de endereço IP do balanceador de carga interno estático. (Para obter notas relacionadas com a utilização de um endereço IP dinâmico, veja secções anteriores deste artigo.)
"internalLBAddress": { "type": "string", "defaultValue": "10.0.0.250" }Adicione um parâmetro de porta de aplicação 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 começar com o modelo gerado pelo portal que utiliza a porta da aplicação 80, o modelo de portal predefinido adiciona AppPort1 (porta 80) ao balanceador de carga externo. Neste caso, remova AppPort1 do balanceador
loadBalancingRulesde carga externo e sondas, para que possa adicioná-lo ao balanceador de 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. Tem um aspeto semelhante ao balanceador de carga interno criado na secção Balanceador de carga apenas interno , mas utiliza as variáveis de balanceador de carga "-Int" e implementa apenas a porta da aplicação 80. Esta ação também removeinboundNatPools, para manter os pontos finais RDP no balanceador de carga público. Se pretender o 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')]" } },No
networkProfilepara oMicrosoft.Compute/virtualMachineScaleSetsrecurso, adicione o conjunto de endereços de back-end interno:"loadBalancerBackendAddressPools": [ { "id": "[variables('lbPoolID0')]" }, { /* Add internal BE pool */ "id": "[variables('lbPoolID0-Int')]" } ],Implementar o modelo:
New-AzResourceGroup -Name sfnetworkinginternalexternallb -Location westus New-AzResourceGroupDeployment -Name deployment -ResourceGroupName sfnetworkinginternalexternallb -TemplateFile C:\SFSamples\Final\template\_internalexternalLB.json
Após a implementação, pode ver dois balanceadores de carga no grupo de recursos. Se procurar os balanceadores de carga, pode ver os pontos finais de gestão e endereço IP públicos (portas 19000 e 19080) atribuídos ao endereço IP público. Também pode ver o endereço IP interno estático e o ponto final da aplicação (porta 80) atribuídos ao balanceador de carga interno. Ambos os balanceadores de carga utilizam o mesmo conjunto de back-end do conjunto de dimensionamento de máquinas virtuais.
Notas para cargas de trabalho de produção
Os modelos do GitHub acima foram concebidos para funcionar com o SKU predefinido para o Azure Balanceador de Carga Standard (SLB), o SKU Básico. O LB do SKU Básico não tem SLA, pelo que, para cargas de trabalho de produção, o SKU Standard deve ser utilizado. Para obter mais informações, veja Azure Balanceador de Carga Standard overview (Descrição geral do Azure Balanceador de Carga Standard). Qualquer cluster do Service Fabric que utilize o SKU Standard para SLB tem de garantir que cada tipo de nó tem uma regra que permite o tráfego de saída na porta 443. Isto é necessário para concluir a configuração do cluster e qualquer implementação sem essa regra falhará. No exemplo acima de um balanceador de carga "apenas interno", tem de ser adicionado um balanceador de carga externo adicional ao modelo com uma regra que permita o tráfego de saída para a porta 443.