Definir configurações de rede para clusters gerenciados do Service Fabric

Os clusters gerenciados do Service Fabric são criados com uma configuração de rede padrão. Essa configuração consiste em um Azure Load Balancer com um ip público, uma rede virtual com uma sub-rede alocada e um NSG configurado para funcionalidade de cluster essencial. Também há regras do NSG opcionais aplicadas, como permitir todo o tráfego de saída por padrão, que se destinam a facilitar a configuração do cliente. Este documento orienta como modificar as opções de configuração de rede a seguir e muito mais:

• Gerenciar regras do NSG
• Gerenciar o acesso RDP
• Gerenciar a configuração do Load Balancer
• Habilitar IP público
• Habilitar IPv6
• Traga sua própria rede virtual
• Traga seu próprio balanceador de carga
• Habilitar a rede acelerada
• Configurar sub-redes auxiliares

Gerenciar regras do NSG

Diretrizes de regras do NSG

Lembre-se dessas considerações ao criar novas regras do NSG para seu cluster gerenciado.

• Os clusters gerenciados do Service Fabric reservam o intervalo de prioridade de regra do NSG de 0 a 999 para a funcionalidade essencial. Não é possível criar regras NSG personalizadas com um valor de prioridade inferior a 1000.
• Os clusters gerenciados do Service Fabric reservam o intervalo de prioridade de 3001 a 4000 para criar regras opcionais do NSG. Essas regras são adicionadas automaticamente para tornar as configurações mais rápidas e fáceis. Você pode substituir essas regras adicionando regras personalizadas do NSG no intervalo de prioridade de 1000 a 3000.
• As regras personalizadas do NSG devem ter uma prioridade no intervalo de 1000 a 3000.

Aplicar regras do NSG

Os clusters gerenciados do Service Fabric permitem atribuir as regras do NSG diretamente no recurso do cluster do seu modelo de implantação.

Use a propriedade networkSecurityRules do seu recurso Microsoft.ServiceFabric/managedclusters (versão 2021-05-01 ou posterior) para atribuir as regras do 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": [
      "..."
    ]
  }
}

ClientConnection e HttpGatewayConnection padrão e regras opcionais

Regra do NSG: SFMC_AllowServiceFabricGatewayToSFRP

Uma regra do NSG padrão é adicionada para permitir que o provedor de recursos do Service Fabric acesse o clientConnectionPort e o httpGatewayConnectionPort do cluster. Essa regra permite o acesso às portas por meio da marca de serviço ServiceFabric.

{
    "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 do NSG: SFMC_AllowServiceFabricGatewayPorts

Essa regra opcional permite que os clientes acessem o SFX, conectem-se ao cluster usando o PowerShell, e usem os ponto de extremidade da API de cluster do Service Fabric da Internet abrindo portas LB para clientConnectionPort e httpGatewayPort.

{
    "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"
        ]
    }
}

Habilitar o acesso a portas RDP da Internet

Os clusters gerenciados do Service Fabric não permitem o acesso de entrada às portas RDP da Internet por padrão. Você pode abrir o acesso de entrada às portas RDP da Internet, definindo a seguinte propriedade em um recurso de cluster gerenciado do Service Fabric.

"allowRDPAccess": true

Quando a propriedade allowRDPAccess é definida como true, a regra NSG a seguir é adicionada à sua implantação de 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 gerenciados do Service Fabric criam automaticamente regras NAT de entrada para cada instância em um tipo de nó. Para localizar os mapeamentos de porta a fim de acessar instâncias específicas (nós de cluster), siga as etapas abaixo:

Usando portal do Azure, localize as regras NAT de entrada do cluster gerenciado criado para o Protocolo de Área de Trabalho Remota (RDP).

1. Navegue até o grupo de recursos do cluster gerenciado em sua assinatura nomeada no seguinte formato: SFC_ {ID-do-cluster}

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

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

   A captura de tela a seguir mostra as regras NAT de entrada para três tipos diferentes de nó:

   

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

   Observação

   Se você estiver usando o recurso BYOLB e quiser o RDP, será necessário configurar um pool de NAT separadamente para fazer isso. Isso não criará automaticamente nenhuma regra NAT para esses tipos de nó.

4. Conectar-se remotamente ao nó (instância do conjunto de dimensionamento) específico. Você pode usar o nome de usuário e senha que você definiu quando criou o cluster ou outras credenciais que você configurou.

A captura de tela a seguir mostra o uso da Conexão de Área de Trabalho Remota para conectar-se aos nós de aplicativos(Instância 0) em um cluster do Windows:

Modificar a configuração padrão do balanceador de carga

Portas do Balanceador de Carga

Os clusters gerenciados do Service Fabric criam uma regra do NSG no intervalo de prioridade padrão para todas as portas do balanceador de carga (LB) configuradas na seção "loadBalancingRules", nas propriedades ManagedCluster. Essa regra abre portas LB para o tráfego de entrada da Internet.

{
    "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"
        ]
    }
}

Investigações do balanceador de carga

Os clusters gerenciados do Service Fabric criam automaticamente investigações do balanceador de carga para portas do gateway para a malha e todas as portas configuradas na seção loadBalancingRules das propriedades do cluster gerenciado.

{
  "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"
    }
  ]
}

Habilitar IP público

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

• Jogos, em que um console precisa fazer uma conexão direta com uma máquina virtual em nuvem que está processando a física do jogo.
• Máquinas virtuais que precisam fazer conexões externas entre si em regiões de um banco de dados distribuído.

Para obter mais informações sobre conexões de saída no Azure, consulte Entender as conexões de saída.

O IP público só pode ser habilitado em tipos de nó secundários, pois os tipos de nó primários são reservados para serviços do sistema do Service Fabric. Siga as etapas na seção Traga seu próprio balanceador de carga deste artigo para criar um tipo de nó secundário para seu cluster gerenciado.

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

As etapas a seguir descrevem habilitar o IP público em seu nó.

1. Baixe o modelo do ARM.

2. Para cada tipo de nó no modelo, adicione enableNodePublicIP ao modelo do 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. Desaloque o modelo do ARM.

4. Verifique se você tem um IP público em seus nós executando o seguinte comando do PowerShell:

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

   O comando é gerado 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"
       }
     }
   ]
   

Habilitar IPv6

Os clusters gerenciados não habilitam o IPv6 por padrão. Esse recurso habilita a funcionalidade IPv4/IPv6 de pilha dupla completa do front-end do Load Balancer para os recursos de back-end. As alterações feitas na configuração do balanceador de carga do cluster gerenciado ou nas regras NSG afetam o roteamento IPv4 e IPv6.

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

1. Defina a seguinte propriedade em um recurso de cluster gerenciado do Service Fabric.

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

2. Implante o cluster gerenciado habilitado para IPv6. Personalize o modelo de exemplo conforme necessário ou crie seu próprio. No exemplo a seguir, criamos um grupo de recursos chamado MyResourceGroup em westus e implantamos um cluster com esse recurso habilitado.

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

   Após a implantação, os recursos e a rede virtual dos clusters serão de pilha dupla. Como resultado, o balanceador de carga de front-end de clusters tem um endereço dns exclusivo criado, por exemplo, mycluster-ipv6.southcentralus.cloudapp.azure.com associado a um endereço IPv6 público no Azure Load Balancer e endereços IPv6 privados nas VMs.

Traga sua própria rede virtual

Esse recurso permite que os clientes usem uma rede virtual existente especificando uma sub-rede dedicada na qual o cluster gerenciado implanta seus recursos. Isso pode ser útil se você já tiver uma rede virtual configurada e uma sub-rede com políticas de segurança relacionadas e roteamento de tráfego que você deseja usar. Depois de implantar em uma rede virtual existente, é fácil usar ou incorporar outros recursos de rede como o Azure ExpressRoute, o Gateway de VPN do Azure, um grupo de segurança de rede e emparelhamento de rede virtual. Além disso, você também pode trazer seu próprio Azure Load Balancer, se necessário.

Para trazer sua própria rede virtual:

1. Obtenha o serviço Id de sua assinatura para o provedor de recursos do Service Fabric.

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

   Observação

   Verifique se você está na assinatura correta. A ID da entidade de segurança será alterada se a assinatura estiver em um locatário 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 a ID da saída anterior como principalId para usar em uma etapa posterior

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

   Anote os valores de propriedade Role definition name e Role definition ID para usar em uma etapa posterior

2. Adicione uma atribuição ao aplicativo do provedor de recursos do Service Fabric. Adicionar uma atribuição de função é uma ação única. Adicione a função executando os comandos do PowerShell a seguir ou configurando um modelo Azure Resource Manager (ARM), conforme detalhado abaixo.

   Nas etapas a seguir, começamos com uma rede virtual existente chamada ExistingRG-vnet no grupo de recursos ExistingRG. Essa sub-rede é chamada de default.

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

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

   Anote o seguinte nome de sub-rede e o valor da propriedade Id retornados da seção Subnets na resposta que você usará em etapas posteriores.

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

   Execute o seguinte comando do PowerShell usando a ID da entidade de serviço, o nome da definição de função da etapa 2 e o escopo de atribuição Id 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>"
   

   Ou você pode adicionar a atribuição de função usando um modelo Azure Resource Manager (ARM) configurado com valores corretos para principalId, roleDefinitionId, vnetName e 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"
      }
   

   Observação

   O VNetRoleAssignmentID deve ser um GUID. Se implantar um modelo novamente incluindo esta atribuição de função, certifique-se de que o GUID seja o mesmo que foi usado originalmente. Sugerimos que você execute esse recurso isolado ou remova-o do modelo de cluster após a implantação, pois ele só precisa ser criado uma vez.

   Aqui está um modelo completo do ARM (Azure Resource Manager) que cria uma sub-rede de rede virtual e faz a atribuição de função que você pode usar para esta etapa.

3. Configure a propriedade subnetId para a implantação do cluster depois que a função for configurada, conforme mostrado abaixo:

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

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

  Consulte o modelo de exemplo traga seu próprio cluster de rede virtual ou personalize o seu próprio.

4. Implante o modelo de cluster gerenciado do ARM (Azure Resource Manager) configurado.

   No exemplo a seguir, criaremos um grupo de recursos chamado MyResourceGroup em westus e implantaremos um cluster com esse recurso habilitado.

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

   Quando você traz sua própria sub-rede de rede virtual, o ponto de extremidade público ainda é criado e gerenciado pelo provedor de recursos, mas na sub-rede configurada. O recurso não permite que você especifique o ip público/reuso do ip estático no Azure Load Balancer. Você pode trazer seu próprio Azure Load Balancer em conjunto com esse recurso ou, somente ele, se precisar desses ou de outros cenários de balanceador de carga que não têm suporte nativo.

   Wehn o cluster é criado, um grupo de segurança de rede é criado no grupo de recursos gerenciados para a sub-rede de nível de cluster padrão. Quando um tipo de nó é criado, ele é colocado nessa sub-rede e herda automaticamente as regras do grupo de segurança de rede, a menos que você use sub-redes de nível de tipo de nó.

   Traga sua própria rede virtual também dá suporte a sub-redes de nível de nó, que permitem colocar tipos de nó em sub-redes separadas, fornecendo flexibilidade para várias configurações e configurações de rede.

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

   Para usar sub-redes de nível de tipo de nó, especifique "useCustomVnet": true na definição de cluster gerenciado. Quando "useCustomVnet" é definido como true, uma sub-rede de cluster padrão não é criada. Ao usar sub-redes de nível de tipo de nó, subnetId se torna uma propriedade necessária na definição de tipo de nó.

   Importante

   Ao usar sub-redes de nível de tipo de nó, você deve atribuir um grupo de segurança de rede à sub-rede de tipo de nó antes da criação do tipo de nó. O grupo de segurança de rede deve incluir a regra de entrada necessária SFMC_AllowServiceFabricGatewayToSFRP ou falha na criação do tipo de nó.

Traga seu próprio Azure Load Balancer

Os clusters gerenciados criam um Azure Standard Load Balancer público e um nome de domínio totalmente qualificado com um IP público estático para os tipos de nó primário e secundário. Trazer seu próprio balanceador de carga permite que você use um Azure Load Balancer existente para tipos de nó secundário para o tráfego de entrada e saída. Ao trazer seu próprio Azure Load Balancer, você pode:

• Use um endereço IP estático pré-configurado do Load Balancer para tráfego privado ou público
• Mapear um Load Balancer 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ó é implantado na própria sub-rede
• Manter políticas e controles existentes que você posa ter no local
• Configurar um balanceador de carga somente interno e usar o balanceador de carga padrão para tráfego externo

Requisitos de Recursos

• Há suporte para o tipo de SKU Standard do Azure Load Balancer
• Você deverá ter pools NAT e back-end configurados no Azure Load Balancer
• Você deve habilitar a conectividade de saída usando um balanceador de carga público fornecido ou o balanceador de carga público padrão

Aqui estão alguns cenários de exemplo que os clientes podem usar para:

Neste exemplo, um cliente deseja rotear o tráfego por meio de um Azure Load Balancer existente, configurado com um endereço IP estático existente, para dois tipos de nó.

Neste exemplo, um cliente deseja rotear o tráfego por meio de Azure Load Balancers existentes para ajudá-lo a gerenciar o fluxo de tráfego para seus aplicativos independentemente de residirem em tipos de nó separados. Quando configurada como este exemplo, cada tipo de nó estará por trás de seu próprio NSG gerenciado.

Neste exemplo, um cliente deseja rotear o tráfego por meio de Azure Load Balancers internos existentes. Isso ajuda a gerenciar o fluxo de tráfego para seus aplicativos independentemente que residam em tipos de nó separados. Quando configurada como neste exemplo, cada tipo de nó estará atrás de seu próprio NSG gerenciado e usará o balanceador de carga padrão para tráfego externo.

Para configurar com seu balanceador de carga:

1. Obtenha o serviço Id de sua assinatura para o provedor de recursos do Service Fabric:

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

   Observação

   Verifique se você está na assinatura correta. A ID da entidade de segurança será alterada se a assinatura estiver em um locatário 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 a ID da saída anterior como principalId para usar em uma etapa posterior

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

   Anote os valores de propriedade Role definition name e Role definition ID para usar em uma etapa posterior

2. Adicione uma atribuição ao aplicativo do provedor de recursos do Service Fabric. Adicionar uma atribuição de função é uma ação única. Adicione a função executando os comandos do PowerShell a seguir ou configurando um modelo Azure Resource Manager (ARM), conforme detalhado abaixo.

   Nas etapas a seguir, começamos com um balanceador de carga existente chamado Existing-LoadBalancer1, no grupo de recursos Existing-RG.

   Obtenha as informações necessárias da propriedade Id do Azure Load Balancer existente.

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

   Anotar o Id seguinte, que você usará na próxima etapa:

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

   Executar o seguinte comando do PowerShell usando a ID da entidade de serviço, o nome da definição de função da etapa 2 e o escopo de atribuição Id que você acabou de obter:

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

   Ou você pode adicionar a atribuição de função usando um modelo Azure Resource Manager (ARM) configurado com valores corretos 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"
      }
   

   Observação

   O loadBalancerRoleAssignmentID deve ser um GUID. Se implantar um modelo novamente incluindo esta atribuição de função, certifique-se de que o GUID seja o mesmo que foi usado originalmente. Sugerimos que você execute esse recurso isolado ou remova-o do modelo de cluster após a implantação, pois ele só precisa ser criado uma vez.

   Consulte 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ó. Você deve configurar um balanceador de carga público para fornecer conectividade de saída ou usar o balanceador de carga público padrão.

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

   OU

   Para configurar o tipo de nó para usar o balanceador de carga padrão, defina o seguinte em seu modelo:

   • O recurso de cluster gerenciado do Service Fabric apiVersion 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 aplicativo de entrada e uma investigação relacionada no Azure Load Balancer existente. Consulte o modelo de exemplo traga seu próprio balanceador de carga Azure Resource Manager (ARM) para ver um exemplo

5. Opcionalmente, configure as regras NSG do cluster gerenciado aplicadas ao tipo de nó para permitir qualquer tráfego necessário configurado no Azure Load Balancer ou o tráfego será bloqueado. Consulte o modelo de exemplo traga seu próprio balanceador de carga Azure Resource Manager (ARM) para ver um exemplo sobre a configuração de regra NSG de entrada. No modelo, procure a propriedade networkSecurityRules.

6. Implantar o modelo arm do cluster gerenciado configurado Para esta etapa, vamos usar o modelo Azure Resource Manager de exemplo do traga seu próprio balanceador de carga do ARM (Azure Resource Manager)

   O exemplo a seguir criará um grupo de recursos chamado MyResourceGroup em westus e implantará um cluster usando um balanceador de carga existente.

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

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

Habilitar Rede acelerada

A rede acelerada permite a SR-IOV (virtualização de E/S de raiz única) para uma VM do conjunto de dimensionamento de máquinas virtuais, que é o recurso subjacente para tipos de nó. Esse caminho de alto desempenho ignora o host do caminho de dados, o que reduz a latência, a tremulação e a utilização da CPU para as cargas de trabalho de rede mais exigentes. Service Fabric de nó de cluster gerenciado podem ser provisionados com Rede Acelerada em SKUs de VM com suporte. Consulte essas limitações e restrições para obter considerações adicionais.

• Observe que a Rede Acelerada é compatível com os tamanhos de instância de uso geral e de computação otimizada com 2 ou mais vCPUs. Em instâncias que são compatíveis com hyperthreading, a Rede Acelerada é compatível com instâncias de VM com 4 ou mais vCPUs.

Habilita a rede acelerada declarando {1} a propriedade enableAcceleratedNetworking em seu modelo Resource Manager da seguinte forma:

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

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

Para habilitar a Rede Acelerada em um cluster existente do Service Fabric, primeiro você precisará Expandir um cluster do Service Fabric adicionando um conjunto de dimensionamento de máquinas virtuais para executar o seguinte:

1. Provisionar um tipo de nó com a Rede Acelerada habilitada
2. Migrar serviços e seus estados para o tipo de nó provisionado com a Rede Acelerada habilitada

A expansão da infraestrutura é necessária para habilitar a Rede Acelerada em um cluster existente, pois a habilitação da Rede Acelerada in-loco causará tempo de inatividade, já que ela exige que todas as máquinas virtuais em um conjunto de disponibilidade sejam paradas e desalocadas antes de habilitar a Rede Acelerada em uma NIC existente.

Configurar sub-redes auxiliares

As sub-redes auxiliares fornecem a capacidade de criar sub-redes gerenciadas adicionais sem um tipo de nó para dar suporte a cenários como Serviço de Link Privado e Bastion Hosts.

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

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

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

Confira a lista completa de parâmetros disponíveis

Próximas etapas

Opções de configuração de cluster gerenciado do Service FabricVisão geral de clusters gerenciados do Service Fabric