Share via

Configurar definições de rede para clusters geridos do Service Fabric

  • Artigo

Os clusters geridos do Service Fabric são criados com uma configuração de rede predefinida. Esta configuração consiste numa Balanceador de Carga do Azure com um IP público, uma VNet com uma sub-rede alocada e um NSG configurado para a funcionalidade de cluster essencial. Também são aplicadas regras NSG opcionais, tais como permitir todo o tráfego de saída por predefinição que se destina a facilitar a configuração do cliente. Este documento explica como modificar as seguintes opções de configuração de rede e muito mais:

Gerir regras do NSG

Documentação de orientação sobre regras do NSG

Tenha em atenção estas considerações ao criar novas regras do NSG para o cluster gerido.

  • Os clusters geridos do Service Fabric reservam o intervalo de prioridade da regra NSG de 0 a 999 para funcionalidades essenciais. Não pode criar regras NSG personalizadas com um valor de prioridade inferior a 1000.
  • Os clusters geridos do Service Fabric reservam o intervalo de prioridades 3001 a 4000 para criar regras NSG opcionais. Estas regras são adicionadas automaticamente para tornar as configurações rápidas e fáceis. Pode substituir estas regras ao adicionar regras NSG personalizadas no intervalo de prioridades de 1000 a 3000.
  • As regras NSG personalizadas devem ter uma prioridade dentro do intervalo de 1000 a 3000.

Aplicar regras NSG

Os clusters geridos do Service Fabric permitem-lhe atribuir regras NSG diretamente no recurso de cluster do modelo de implementação.

Utilize a propriedade networkSecurityRules do recurso Microsoft.ServiceFabric/managedclusters (versão 2021-05-01 ou posterior) para atribuir regras NSG. Por exemplo:

{
  "apiVersion": "2021-05-01",
  "type": "Microsoft.ServiceFabric/managedclusters",
  "properties": {
    "networkSecurityRules": [
      {
        "name": "AllowCustomers",
        "protocol": "*",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "Internet",
        "destinationAddressPrefix": "*",
        "destinationPortRange": "33000-33499",
        "access": "Allow",
        "priority": 2001,
        "direction": "Inbound"
      },
      {
        "name": "AllowARM",
        "protocol": "*",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "AzureResourceManager",
        "destinationAddressPrefix": "*",
        "destinationPortRange": "33500-33699",
        "access": "Allow",
        "priority": 2002,
        "direction": "Inbound"
      },
      {
        "name": "DenyCustomers",
        "protocol": "*",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "Internet",
        "destinationAddressPrefix": "*",
        "destinationPortRange": "33700-33799",
        "access": "Deny",
        "priority": 2003,
        "direction": "Outbound"
      },
      {
        "name": "DenyRDP",
        "protocol": "*",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "*",
        "destinationAddressPrefix": "VirtualNetwork",
        "destinationPortRange": "3389",
        "access": "Deny",
        "priority": 2004,
        "direction": "Inbound",
        "description": "Override for optional SFMC_AllowRdpPort rule. This is required in tests to avoid Sev2 incident for security policy violation."
      }
    ],
    "fabricSettings": [
      "..."
    ]
  }
}

Regras opcionais e predefinidas clientConnection e HttpGatewayConnection

Regra NSG: SFMC_AllowServiceFabricGatewayToSFRP

É adicionada uma regra NSG predefinida para permitir que o fornecedor de recursos do Service Fabric aceda ao cliente do clusterConnectionPort e httpGatewayConnectionPort. Esta regra permite o acesso às portas através da etiqueta de serviço "ServiceFabric".

Nota

Esta regra é sempre adicionada e não pode ser substituída.

{
    "name": "SFMC_AllowServiceFabricGatewayToSFRP",
    "type": "Microsoft.Network/networkSecurityGroups/securityRules",
    "properties": {
        "description": "This is required rule to allow SFRP to connect to the cluster. This rule can't be overridden.",
        "protocol": "TCP",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "ServiceFabric",
        "destinationAddressPrefix": "VirtualNetwork",
        "access": "Allow",
        "priority": 500,
        "direction": "Inbound",
        "sourcePortRanges": [],
        "destinationPortRanges": [
            "19000",
            "19080"
        ]
    }
}

Regra NSG: SFMC_AllowServiceFabricGatewayPorts

Esta regra opcional permite que os clientes acedam ao SFX, liguem ao cluster com o PowerShell e utilizem pontos finais da API de cluster do Service Fabric a partir da Internet ao abrir portas LB para clientConnectionPort e httpGatewayPort.

Nota

Esta regra não será adicionada se existir uma regra personalizada com os mesmos valores de acesso, direção e protocolo para a mesma porta. Pode substituir esta regra com regras de NSG personalizadas.

{
    "name": "SFMC_AllowServiceFabricGatewayPorts",
    "type": "Microsoft.Network/networkSecurityGroups/securityRules",
    "properties": {
        "description": "Optional rule to open SF cluster gateway ports. To override add a custom NSG rule for gateway ports in priority range 1000-3000.",
        "protocol": "tcp",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "*",
        "destinationAddressPrefix": "VirtualNetwork",
        "access": "Allow",
        "priority": 3001,
        "direction": "Inbound",
        "sourcePortRanges": [],
        "destinationPortRanges": [
            "19000",
            "19080"
        ]
    }
}

Ativar o acesso às portas RDP a partir da Internet

Por predefinição, os clusters geridos do Service Fabric não permitem o acesso de entrada às portas RDP a partir da Internet. Pode abrir o acesso de entrada às portas RDP a partir da Internet ao definir a seguinte propriedade num recurso de cluster gerido do Service Fabric.

"allowRDPAccess": true

Quando a propriedade allowRDPAccess estiver definida como true, a seguinte regra NSG será adicionada à implementação do cluster.

{
    "name": "SFMC_AllowRdpPort",
    "type": "Microsoft.Network/networkSecurityGroups/securityRules",
    "properties": {
        "description": "Optional rule to open RDP ports.",
        "protocol": "tcp",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "*",
        "destinationAddressPrefix": "VirtualNetwork",
        "access": "Allow",
        "priority": 3002,
        "direction": "Inbound",
        "sourcePortRanges": [],
        "destinationPortRange": "3389"
    }
}

Os clusters geridos do Service Fabric criam automaticamente regras NAT de entrada para cada instância num tipo de nó. Para encontrar os mapeamentos de portas para chegar a instâncias específicas (nós de cluster), siga os passos abaixo:

Com portal do Azure, localize as regras NAT de entrada criadas pelo cluster gerido para o Protocolo RDP (Remote Desktop Protocol).

  1. Navegue para o grupo de recursos do cluster gerido na sua subscrição com o nome com o seguinte formato: SFC_{cluster-id}

  2. Selecione o balanceador de carga do cluster com o seguinte formato: LB-{cluster-name}

  3. Na página do balanceador de carga, selecione Regras NAT de entrada. Reveja as regras NAT de entrada para confirmar a porta de front-end de entrada para o mapeamento de portas de destino de um nó.

    A captura de ecrã seguinte mostra as regras NAT de entrada para três tipos de nós diferentes:

    Regras nat de entrada

    Por predefinição, para clusters do Windows, a Porta de Front-end está no intervalo 50000 e superior e a porta de destino é a porta 3389, que mapeia para o serviço RDP no nó de destino.

    Nota

    Se estiver a utilizar a funcionalidade BYOLB e quiser RDP, tem de configurar um conjunto NAT separadamente para o fazer. Esta ação não criará automaticamente quaisquer regras NAT para esses tipos de nó.

  4. Ligue-se remotamente ao nó específico (instância do conjunto de dimensionamento). Pode utilizar o nome de utilizador e a palavra-passe que definiu quando criou o cluster ou quaisquer outras credenciais que tenha configurado.

A captura de ecrã seguinte mostra a utilização da Ligação ao Ambiente de Trabalho Remoto para ligar ao nó de aplicações (Instância 0) num cluster do Windows:

Ligação de Ambiente de Trabalho Remoto

Modificar a configuração predefinida do Balanceador de carga

Portas do balanceador de carga

Os clusters geridos do Service Fabric criam uma regra NSG no intervalo de prioridade predefinido para todas as portas do balanceador de carga (LB) configuradas na secção "loadBalancingRules" nas propriedades do ManagedCluster . Esta regra abre portas LB para tráfego de entrada a partir da Internet.

Nota

Esta regra é adicionada no intervalo de prioridades opcional e pode ser substituída ao adicionar regras de NSG personalizadas.

{
    "name": "SFMC_AllowLoadBalancedPorts",
    "type": "Microsoft.Network/networkSecurityGroups/securityRules",
    "properties": {
        "description": "Optional rule to open LB ports",
        "protocol": "*",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "*",
        "destinationAddressPrefix": "VirtualNetwork",
        "access": "Allow",
        "priority": 3003,
        "direction": "Inbound",
        "sourcePortRanges": [],
        "destinationPortRanges": [
        "80", "8080", "4343"
        ]
    }
}

Sondas do balanceador de carga

Os clusters geridos do Service Fabric criam automaticamente sondas de balanceador de carga para portas de gateway de recursos de infraestrutura e todas as portas configuradas na loadBalancingRules secção das propriedades do cluster gerido.

{
  "value": [
    {
        "name": "FabricTcpGateway",
        "properties": {
            "provisioningState": "Succeeded",
            "protocol": "Tcp",
            "port": 19000,
            "intervalInSeconds": 5,
            "numberOfProbes": 2,
            "loadBalancingRules": [
                {
                    "id": "<>"
                }
            ]
        },
        "type": "Microsoft.Network/loadBalancers/probes"
    },
    {
        "name": "FabricHttpGateway",
        "properties": {
            "provisioningState": "Succeeded",
            "protocol": "Tcp",
            "port": 19080,
            "intervalInSeconds": 5,
            "numberOfProbes": 2,
            "loadBalancingRules": [
                {
                    "id": "<>"
                }
            ]
        },
        "type": "Microsoft.Network/loadBalancers/probes"
    },
    {
        "name": "probe1_tcp_8080",
        "properties": {
            "provisioningState": "Succeeded",
            "protocol": "Tcp",
            "port": 8080,
            "intervalInSeconds": 5,
            "numberOfProbes": 2,
            "loadBalancingRules": [
            {
                "id": "<>"
            }
        ]
      },
      "type": "Microsoft.Network/loadBalancers/probes"
    }
  ]
}

Ativar o IP público

Nota

Atualmente, apenas o IPv4 público é suportado.

Os nós de cluster geridos do Service Fabric não necessitam dos seus próprios endereços IP públicos para comunicação. No entanto, alguns cenários podem exigir que um nó tenha o seu próprio endereço IP público para comunicar com a Internet e os serviços do Azure destinados ao público. Por exemplo:

  • Jogos, em que uma consola precisa de fazer uma ligação direta a uma máquina virtual na cloud que está a fazer o processamento físico de jogos.
  • Máquinas virtuais que precisam de fazer ligações externas entre si entre regiões numa base de dados distribuída.

Para obter mais informações sobre ligações de saída no Azure, veja Noções sobre ligações de saída.

O IP público só pode ser ativado em tipos de nó secundários, uma vez que os tipos de nó primários estão reservados para serviços de sistema do Service Fabric. Siga os passos na secção Traga o seu próprio balanceador de carga deste artigo para criar um tipo de nó secundário para o cluster gerido.

O Azure atribui dinamicamente endereços IP disponíveis.

Nota

A ativação do IP público só é suportada através do modelo do ARM.

Os passos seguintes descrevem ativar o IP público no nó.

  1. Transfira o modelo do ARM.

  2. Para cada tipo de nó no modelo, adicione enableNodePublicIP ao modelo arm:

    {
    "name": "<secondary_node_type_name>", 
    "apiVersion": "2023-02-01-preview", 
    "properties": { 
        "isPrimary" : false, 
        "vmImageResourceId": "/subscriptions/<your_subscription_id>/resourceGroups/<your_resource_group>/providers/Microsoft.Compute/images/<your_custom_image>", 
        "vmSize": "Standard_D2", 
        "vmInstanceCount": 5, 
        "dataDiskSizeGB": 100, 
        "enableNodePublicIP": true 
    }
}

  3. Desaloja o modelo do ARM.

  4. Verifique se tem um IP público nos nós ao executar o seguinte comando do PowerShell:

    az vmss list-instance-public-ips -g MC_MyResourceGroup2_MyManagedCluster_eastus -n YourVirtualMachineScaleSetName

    O comando é apresentado no formato JSON.

    [
  {
    "etag": "etag_0",
    "id": "<id_0/name>",
    "idleTimeoutInMinutes": 15,
    "ipAddress": "<ip_address_0>",
    "ipConfiguration": {
      "id": "<configuration_id_0>",
      "resourceGroup": "<your_resource_group>"
    },
    "ipTags": [],
    "name": "<name>",
    "provisioningState": "Succeeded",
    "publicIPAddressVersion": "IPv4",
    "publicIPAllocationMethod": "Static",
    "resourceGroup": "<your_resource_group>",
    "resourceGuid": "resource_guid_0",
    "sku": {
      "name": "Standard"
    }
  },
  {
    "etag": "etag_1",
    "id": "/<id_1/name>",
    "idleTimeoutInMinutes": 15,
    "ipAddress": "<ip_address_1>",
    "ipConfiguration": {
      "id": "<configuration_id_1>",
      "resourceGroup": "<your_resource_group>"
    },
    "ipTags": [],
    "name": "<name>",
    "provisioningState": "Succeeded",
    "publicIPAddressVersion": "IPv4",
    "publicIPAllocationMethod": "Static",
    "resourceGroup": "<your_resource_group>",
    "resourceGuid": "resource_guid_1",
    "sku": {
      "name": "Standard"
    }
  },
  {
    "etag": "etag_2",
    "id": "<id_2/name>",
    "idleTimeoutInMinutes": 15,
    "ipAddress": "<ip_address_2>",
    "ipConfiguration": {
      "id": "<configuration_id_2>",
      "resourceGroup": "<your_resource_group>"
    },
    "ipTags": [],
    "name": "<name>",
    "provisioningState": "Succeeded",
    "publicIPAddressVersion": "IPv4",
    "publicIPAllocationMethod": "Static",
    "resourceGroup": "<your_resource_group>",
    "resourceGuid": "resource_guid_2",
    "sku": {
      "name": "Standard"
    }
  }
]

Ativar IPv6

Os clusters geridos não ativam o IPv6 por predefinição. Esta funcionalidade irá ativar a capacidade IPv4/IPv6 de pilha dupla completa do front-end do Balanceador de Carga para os recursos de back-end. Quaisquer alterações efetuadas à configuração do balanceador de carga do cluster gerido ou às regras do NSG afetarão o encaminhamento IPv4 e IPv6.

Nota

Esta definição não está disponível no portal e não pode ser alterada depois de o cluster ser criado.

  • A apiVersion do recurso de cluster gerido do Service Fabric deve ser 2022-01-01 ou posterior.

  1. Defina a seguinte propriedade num recurso de cluster gerido do Service Fabric.

        "resources": [
         {
         "apiVersion": "[variables('sfApiVersion')]",
         "type": "Microsoft.ServiceFabric/managedclusters",
         ...
         "properties": {
             "enableIpv6": true
             },
         }
    ]

  2. Implemente o cluster gerido IPv6 ativado. Personalize o modelo de exemplo conforme necessário ou crie o seu próprio. No exemplo seguinte, vamos criar um grupo de recursos chamado MyResourceGroupwestus e implementar um cluster com esta funcionalidade ativada.

     New-AzResourceGroup -Name MyResourceGroup -Location westus
 New-AzResourceGroupDeployment -Name deployment -ResourceGroupName MyResourceGroup -TemplateFile AzureDeploy.json

    Após a implementação, a rede virtual e os recursos dos clusters serão de pilha dupla. Como resultado, o balanceador de carga de front-end dos clusters terá um endereço dns exclusivo criado, por exemplo, mycluster-ipv6.southcentralus.cloudapp.azure.com que está associado a um endereço IPv6 público nos endereços IPv6 Balanceador de Carga do Azure e privados nas VMs.

Traga a sua própria rede virtual

Esta funcionalidade permite que os clientes utilizem uma rede virtual existente ao especificar uma sub-rede dedicada na qual o cluster gerido irá implementar os respetivos recursos. Isto pode ser útil se já tiver uma VNet e sub-rede configuradas com políticas de segurança relacionadas e encaminhamento de tráfego que pretende utilizar. Depois de implementar numa rede virtual existente, é fácil utilizar ou 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. Além disso, também pode trazer o seu próprio Balanceador de Carga do Azure , se necessário.

Nota

Ao utilizar BYOVNET, os recursos de cluster gerido serão implementados numa sub-rede.

Nota

Esta definição não pode ser alterada depois de o cluster ser criado e o cluster gerido atribuirá um NSG à sub-rede fornecida. Não substitua a atribuição do NSG ou o tráfego pode falhar.

Para trazer a sua própria rede virtual:

  1. Obtenha o serviço Id a partir da sua subscrição da aplicação Fornecedor de Recursos do Service Fabric.

    Login-AzAccount
Select-AzSubscription -SubscriptionId <SubId>
Get-AzADServicePrincipal -DisplayName "Azure Service Fabric Resource Provider"

    Nota

    Certifique-se de que está na subscrição correta, o ID principal será alterado se a subscrição estiver num inquilino diferente.

    ServicePrincipalNames : {74cb6831-0dbb-4be1-8206-fd4df301cdc2}
ApplicationId         : 74cb6831-0dbb-4be1-8206-fd4df301cdc2
ObjectType            : ServicePrincipal
DisplayName           : Azure Service Fabric Resource Provider
Id                    : 00000000-0000-0000-0000-000000000000

    Anote o ID da saída anterior como principalId para utilização num passo posterior

    Nome da definição de função ID da definição de função
    Contribuidor de Rede 4d97b98b-1d4f-4787-a291-c67834d212e7

    Anote os valores de Role definition name propriedade e Role definition ID para utilizar num passo posterior

  2. Adicione uma atribuição de função à aplicação Fornecedor de Recursos do Service Fabric. Adicionar uma atribuição de função é uma ação única. Pode adicionar a função ao executar os seguintes comandos do PowerShell ou ao configurar um modelo do Azure Resource Manager (ARM), conforme descrito abaixo.

    Nos passos seguintes, começamos com uma rede virtual existente denominada ExistingRG-vnet, no grupo de recursos ExistingRG. A sub-rede tem o nome predefinido.

    Obtenha as informações necessárias da VNet existente.

    Login-AzAccount
Select-AzSubscription -SubscriptionId <SubId>
Get-AzVirtualNetwork -Name ExistingRG-vnet -ResourceGroupName ExistingRG

    Tenha em atenção o seguinte nome da sub-rede e Id o valor da propriedade que é devolvido da Subnets secção na resposta que irá utilizar nos passos posteriores.

    Subnets:[
{
...
"Id": "/subscriptions/<subscriptionId>/resourceGroups/Existing-RG/providers/Microsoft.Network/virtualNetworks/ExistingRG-vnet/subnets/default"
}]

    Execute o seguinte comando do PowerShell com o ID principal, o nome da definição de função do passo 2 e o âmbito Id de atribuição obtidos acima:

    New-AzRoleAssignment -PrincipalId 00000000-0000-0000-0000-000000000000 -RoleDefinitionName "Network Contributor" -Scope "/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/<subnetName>"

    Em alternativa, pode adicionar a atribuição de função com um modelo do Azure Resource Manager (ARM) configurado com valores adequados para principalId, roleDefinitionId, vnetNamee subnetName:

       "type": "Microsoft.Authorization/roleAssignments",
   "apiVersion": "2020-04-01-preview",
   "name": "[parameters('VNetRoleAssignmentID')]",
   "scope": "[concat('Microsoft.Network/virtualNetworks/', parameters('vnetName'), '/subnets/', parameters('subnetName'))]",
   "dependsOn": [
     "[concat('Microsoft.Network/virtualNetworks/', parameters('vnetName'))]"
   ],
   "properties": {
     "roleDefinitionId": "[concat('/subscriptions/', subscription().subscriptionId, '/providers/Microsoft.Authorization/roleDefinitions/4d97b98b-1d4f-4787-a291-c67834d212e7')]",
     "principalId": "00000000-0000-0000-0000-000000000000"
   }

    Nota

    VNetRoleAssignmentID tem de ser um GUID. Se implementar novamente um modelo, incluindo esta atribuição de função, certifique-se de que o GUID é o mesmo que utilizou originalmente. Sugerimos que execute este isolado ou remova este recurso do modelo de cluster após a implementação, uma vez que só precisa de ser criado uma vez.

    Eis um modelo de exemplo completo do Azure Resource Manager (ARM) que cria uma sub-rede VNet e atribui funções que pode utilizar para este passo.

  3. Configure a subnetId propriedade para a implementação do cluster depois de a função ser configurada, conforme mostrado abaixo:

  1. Implemente o modelo do Azure Resource Manager (ARM) do cluster gerido configurado.

    No exemplo seguinte, vamos criar um grupo de recursos chamado MyResourceGroup e westus implementar um cluster com esta funcionalidade ativada.

     New-AzResourceGroup -Name MyResourceGroup -Location westus
 New-AzResourceGroupDeployment -Name deployment -ResourceGroupName MyResourceGroup -TemplateFile AzureDeploy.json

    Quando traz a sua própria sub-rede VNet, o ponto final público ainda é criado e gerido pelo fornecedor de recursos, mas na sub-rede configurada. A funcionalidade não lhe permite especificar o IP público/reutilizar o IP estático no Balanceador de Carga do Azure. Pode trazer os seus próprios Balanceador de Carga do Azure em conjunto com esta funcionalidade ou por si só se precisar desses ou de outros cenários de balanceador de carga que não são suportados nativamente.

Traga o seu próprio Balanceador de Carga do Azure

Os clusters geridos criam um Balanceador de Carga Standard público do Azure e um nome de domínio completamente qualificado com um IP público estático para os tipos de nó primário e secundário. Traga o seu próprio balanceador de carga permite-lhe utilizar um Balanceador de Carga do Azure existente para tipos de nó secundários para tráfego de entrada e saída. Quando traz os seus próprios Balanceador de Carga do Azure, pode:

  • Utilizar um endereço IP estático de Balanceador de Carga pré-configurado para tráfego privado ou público
  • Mapear um Balanceador de Carga para um tipo de nó específico
  • Configurar regras de grupo de segurança de rede por tipo de nó porque cada tipo de nó é implementado na sua própria sub-rede
  • Manter políticas e controlos existentes que possa ter implementados
  • Configurar um balanceador de carga apenas interno e utilizar o balanceador de carga predefinido para tráfego externo

Nota

Ao utilizar BYOVNET, os recursos de cluster gerido serão implementados numa sub-rede com um NSG, independentemente dos balanceadores de carga configurados adicionais.

Nota

Não pode mudar do balanceador de carga predefinido para um personalizado após a implementação de um tipo de nó, mas pode modificar a configuração do balanceador de carga personalizada após a implementação, se estiver ativada.

Requisitos de Funcionalidades

  • Os tipos de Balanceador de Carga do Azure SKU Básico e Standard são suportados
  • Tem de ter conjuntos de back-end e NAT configurados no Balanceador de Carga do Azure
  • Tem de ativar a conectividade de saída através de um balanceador de carga público fornecido ou do balanceador de carga público predefinido

Eis alguns cenários de exemplo que os clientes podem utilizar para:

Neste exemplo, um cliente quer encaminhar o tráfego através de um Balanceador de Carga do Azure existente configurado com um endereço IP estático existente para dois tipos de nós.

Traga o seu próprio Balanceador de Carga exemplo 1

Neste exemplo, um cliente quer encaminhar o tráfego através de Balanceadores de Carga do Azure existentes para ajudá-lo a gerir o fluxo de tráfego para as suas aplicações de forma independente que resida em tipos de nós separados. Quando configurado como este exemplo, cada tipo de nó estará por trás do seu próprio NSG gerido.

Traga o seu próprio Balanceador de Carga exemplo 2

Neste exemplo, um cliente quer encaminhar o tráfego através de Balanceadores de Carga internos existentes do Azure. Isto ajuda-os a gerir o fluxo de tráfego para as respetivas aplicações de forma independente, que residem em tipos de nós separados. Quando configurado como este exemplo, cada tipo de nó estará atrás do seu próprio NSG gerido e utilizará o balanceador de carga predefinido para tráfego externo.

Traga o seu próprio Balanceador de Carga exemplo 3

Para configurar com o seu próprio balanceador de carga:

  1. Obtenha o serviço Id a partir da sua subscrição da aplicação Fornecedor de Recursos do Service Fabric:

    Login-AzAccount
Select-AzSubscription -SubscriptionId <SubId>
Get-AzADServicePrincipal -DisplayName "Azure Service Fabric Resource Provider"

    Nota

    Certifique-se de que está na subscrição correta, o ID principal será alterado se a subscrição estiver num inquilino diferente.

    ServicePrincipalNames : {74cb6831-0dbb-4be1-8206-fd4df301cdc2}
ApplicationId         : 74cb6831-0dbb-4be1-8206-fd4df301cdc2
ObjectType            : ServicePrincipal
DisplayName           : Azure Service Fabric Resource Provider
Id                    : 00000000-0000-0000-0000-000000000000

    Anote o ID da saída anterior como principalId para utilização num passo posterior

    Nome da definição de função ID da definição de função
    Contribuidor de Rede 4d97b98b-1d4f-4787-a291-c67834d212e7

    Anote os valores de Role definition name propriedade e Role definition ID para utilizar num passo posterior

  2. Adicione uma atribuição de função à aplicação Fornecedor de Recursos do Service Fabric. Adicionar uma atribuição de função é uma ação única. Pode adicionar a função ao executar os seguintes comandos do PowerShell ou ao configurar um modelo do Azure Resource Manager (ARM), conforme descrito abaixo.

    Nos passos seguintes, começamos com um balanceador de carga existente com o nome Existing-LoadBalancer1, no grupo de recursos Existing-RG.

    Obtenha as informações de propriedade necessárias Id do Balanceador de Carga do Azure existente.

    Login-AzAccount
Select-AzSubscription -SubscriptionId <SubId>
Get-AzLoadBalancer -Name "Existing-LoadBalancer1" -ResourceGroupName "Existing-RG"

    Tenha em atenção o seguinte Id que irá utilizar no próximo passo:

    {
...
"Id": "/subscriptions/<subscriptionId>/resourceGroups/Existing-RG/providers/Microsoft.Network/loadBalancers/Existing-LoadBalancer1"
}

    Execute o seguinte comando do PowerShell com o ID principal, o nome da definição de função do passo 2 e o âmbito Id de atribuição que acabou de obter:

    New-AzRoleAssignment -PrincipalId 00000000-0000-0000-0000-000000000000 -RoleDefinitionName "Network Contributor" -Scope "/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/loadBalancers/<LoadBalancerName>"

    Em alternativa, pode adicionar a atribuição de função com um modelo do Azure Resource Manager (ARM) configurado com valores adequados para principalId, roleDefinitionId":

       "type": "Microsoft.Authorization/roleAssignments",
   "apiVersion": "2020-04-01-preview",
   "name": "[parameters('loadBalancerRoleAssignmentID')]",
   "scope": "[concat('Microsoft.Network/loadBalancers/', variables('lbName'))]",
   "dependsOn": [
     "[concat('Microsoft.Network/loadBalancers/', variables('lbName'))]"
   ],
   "properties": {
     "roleDefinitionId": "[concat('/subscriptions/', subscription().subscriptionId, '/providers/Microsoft.Authorization/roleDefinitions/4d97b98b-1d4f-4787-a291-c67834d212e7')]",
     "principalId": "00000000-0000-0000-0000-000000000000"
   }

    Nota

    loadBalancerRoleAssignmentID tem de ser um GUID. Se implementar novamente um modelo, incluindo esta atribuição de função, certifique-se de que o GUID é o mesmo que utilizou originalmente. Sugerimos que execute este isolado ou remova este recurso do modelo de cluster após a implementação, uma vez que só precisa de ser criado uma vez.

    Veja este modelo de exemplo para criar um balanceador de carga público e atribuir uma função.

  3. Configure a conectividade de saída necessária para o tipo de nó. Tem de configurar um balanceador de carga público para fornecer conectividade de saída ou utilizar o balanceador de carga público predefinido.

    outboundRules Configurar para configurar um balanceador de carga público para fornecer conectividade de saída Veja o modelo criar balanceador de carga e atribuir o exemplo de função do Azure Resource Manager (ARM)

    OU

    Para configurar o tipo de nó para utilizar o balanceador de carga predefinido, defina o seguinte no modelo:

    • A apiVersion do recurso de cluster gerido do Service Fabric deve ser 2022-01-01 ou posterior.
     "resources": [
   {
   "apiVersion": "[variables('sfApiVersion')]",
   "type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
   "properties": {
       "isPrimary": false,
       "useDefaultPublicLoadBalancer": true
       }
   }
 ]

  4. Opcionalmente, configure uma porta de aplicação de entrada e uma sonda relacionada no seu Balanceador de Carga do Azure existente. Veja o modelo bring your own load balancer sample do Azure Resource Manager (ARM) para obter um exemplo

  5. Opcionalmente, configure as regras NSG do cluster gerido aplicadas ao tipo de nó para permitir qualquer tráfego necessário que tenha configurado no Balanceador de Carga do Azure ou tráfego será bloqueado. Veja o modelo bring your own load balancer sample do Azure Resource Manager (ARM) para obter um exemplo de configuração de regras NSG de entrada. No modelo, procure a networkSecurityRules propriedade.

  6. Implementar o modelo arm do cluster gerido configurado Para este passo, vamos utilizar o modelo de exemplo do Azure Resource Manager (ARM) do balanceador de carga

    O seguinte irá criar um grupo de recursos chamado MyResourceGroup e westus implementar um cluster com um balanceador de carga existente.

     New-AzResourceGroup -Name MyResourceGroup -Location westus
 New-AzResourceGroupDeployment -Name deployment -ResourceGroupName MyResourceGroup -TemplateFile AzureDeploy.json

    Após a implementação, o tipo de nó secundário é configurado para utilizar o balanceador de carga especificado para tráfego de entrada e saída. A ligação de cliente do Service Fabric e os pontos finais de gateway ainda apontarão para o DNS público do endereço IP estático do tipo de nó primário do cluster gerido.

Ativar Redes Aceleradas

A rede acelerada permite a virtualização de E/S de raiz única (SR-IOV) para uma VM de conjunto de dimensionamento de máquinas virtuais que é o recurso subjacente para tipos de nós. Este caminho de elevado desempenho ignora o anfitrião do caminho de dados, o que reduz a latência, o nervosismo e a utilização da CPU para as cargas de trabalho de rede mais exigentes. Os tipos de nó de cluster gerido do Service Fabric podem ser aprovisionados com Redes Aceleradas em SKUs de VM suportados. Veja estas limitações e restrições para considerações adicionais.

  • Tenha em atenção que a Rede Acelerada é suportada na maioria dos tamanhos de instâncias com fins gerais e otimizados para computação com 2 ou mais vCPUs. Nas instâncias que suportam a hiperthreading, a Rede Acelerada é suportada em instâncias de VM com 4 ou mais vCPUs.

Ative a rede acelerada ao declarar a enableAcceleratedNetworking propriedade no modelo de Resource Manager da seguinte forma:

  • A apiVersion do recurso de cluster gerido do Service Fabric deve ser 2022-01-01 ou posterior.
   {
   "apiVersion": "[variables('sfApiVersion')]",
   "type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
   ...
   "properties": {
       ...
       "enableAcceleratedNetworking": true,
       ...
   }

Para ativar a Rede Acelerada num cluster do Service Fabric existente, primeiro tem de dimensionar um cluster do Service Fabric ao adicionar um novo tipo de nó e executar o seguinte:

  1. Aprovisionar um tipo de nó com a Rede Acelerada ativada
  2. Migrar os seus serviços e o respetivo estado para o tipo de nó aprovisionado com a Rede Acelerada ativada

É necessário aumentar horizontalmente a infraestrutura para ativar a Rede Acelerada num cluster existente, uma vez que ativar a Rede Acelerada no local causaria um período de inatividade, uma vez que requer que todas as máquinas virtuais num conjunto de disponibilidade sejam paradas e desalocadas antes de ativar a Rede Acelerada em qualquer NIC existente.

Configurar Sub-redes Auxiliares

As sub-redes auxiliares proporcionam a capacidade de criar sub-redes geridas adicionais sem um tipo de nó para cenários de suporte, como Private Link Service e Anfitriões bastion.

Configure sub-redes auxiliares ao declarar a auxiliarySubnets propriedade e os parâmetros necessários no modelo de Resource Manager da seguinte forma:

  • A apiVersion do recurso de cluster gerido do Service Fabric deve ser 2022-01-01 ou posterior.
    "resources": [
        {
            "apiVersion": "[variables('sfApiVersion')]",
            "type": "Microsoft.ServiceFabric/managedclusters",
              "properties": {
                "auxiliarySubnets": [
                  {
                  "name" : "mysubnet",
                  "enableIpv6" : "true"
                  }
                ]
              }
        }
    ]

Veja a lista completa de parâmetros disponíveis

Passos seguintes

Descrição geraldas opções de configuração de clusters geridos do Service Fabric