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 Balanceador de Carga do Azure com um ip público, uma rede virtual com uma sub-rede alocada e um NSG configurado para funcionalidade de cluster essencial. Há também regras NSG opcionais aplicadas, como permitir todo o tráfego de saída por padrã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:

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

Gerenciar regras NSG

Orientações sobre as regras do NSG

Esteja ciente dessas considerações ao criar novas regras NSG para seu cluster gerenciado.

• Os clusters gerenciados pelo Service Fabric reservam o intervalo de prioridade da regra 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 pelo Service Fabric reservam o intervalo de prioridade de 3001 a 4000 para a criação de regras NSG opcionais. Essas regras são adicionadas automaticamente para tornar as configurações rápidas e fáceis. Você pode substituir essas regras adicionando regras NSG personalizadas no intervalo de prioridade de 1000 a 3000.
• As regras NSG personalizadas devem ter prioridade dentro do intervalo de 1000 a 3000.

Aplicar regras NSG

Os clusters gerenciados do Service Fabric permitem que você atribua regras NSG diretamente no recurso de cluster do seu modelo de implantação.

Use 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": [
      "..."
    ]
  }
}

ClientConnection e HttpGatewayConnection padrão e regras opcionais

Regra NSG: SFMC_AllowServiceFabricGatewayToSFRP

Uma regra NSG padrão é adicionada para permitir que o provedor de recursos do Service Fabric acesse clientConnectionPort e httpGatewayConnectionPort do cluster. Esta regra permite o acesso às portas através da etiqueta ServiceFabricde serviço.

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

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

Nota

Esta regra não será adicionada se houver uma regra personalizada com os mesmos valores de acesso, direção e protocolo para a mesma porta. Você pode substituir essa regra por regras 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"
        ]
    }
}

Permitir o acesso a portas RDP a partir da Internet

Os clusters gerenciados do Service Fabric não habilitam 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 pelo Service Fabric.

"allowRDPAccess": true

Quando a propriedade allowRDPAccess é definida como true, a seguinte regra NSG é 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 para alcançar instâncias específicas (nós de cluster), siga as etapas abaixo:

Usando o portal do Azure, localize o cluster gerenciado criado regras NAT de entrada para o protocolo RDP (Remote Desktop Protocol).

1. Navegue até o grupo de recursos de cluster gerenciado em sua assinatura nomeado com o seguinte formato: SFC_{cluster-id}

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

3. Na página do seu balanceador de carga, selecione Regras de NAT de entrada. Analise as regras de NAT de entrada para confirmar o mapeamento da porta de entrada do Frontend para a porta de destino de um nó.

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

   

   Por padrão, para clusters do Windows, a Porta Frontend 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 você estiver usando o recurso BYOLB e quiser RDP, deverá configurar um pool de NAT separadamente para fazer isso. Isso não criará automaticamente nenhuma regra NAT para esses tipos de nó.

4. Conecte-se remotamente ao nó específico (instância do conjunto de escala). Você pode usar o nome de usuário e a senha definidos quando criou o cluster ou quaisquer outras credenciais configuradas.

A captura de tela a seguir mostra o uso da Conexão de Área de Trabalho Remota para se conectar ao nó 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 NSG no intervalo de prioridade padrão para todas as portas do balanceador de carga (LB) configuradas na seção "loadBalancingRules" em ManagedCluster properties. Esta regra abre portas LB para tráfego de entrada da Internet.

Nota

Essa regra é adicionada no intervalo de prioridade opcional e pode ser substituída adicionando regras 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 gerenciados do Service Fabric criam automaticamente testes de balanceador de carga para portas de gateway de malha e todas as portas configuradas na loadBalancingRules seção de propriedades de 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"
    }
  ]
}

Ativar IP público

Nota

Atualmente, apenas o IPv4 público é suportado.

Os nós de cluster gerenciados do Service Fabric não exigem 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 públicos do Azure. Por exemplo:

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

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 habilitado em tipos de nó secundário, porque os tipos de nó primário são reservados para serviços do sistema 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.

Nota

A habilitação de IP público só é suportada por meio do modelo ARM.

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

1. Faça o download do seu modelo 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. Deloy seu modelo 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
   

   As saídas do comando 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 gerenciados não habilitam o IPv6 por padrão. Esse recurso habilita o recurso IPv4/IPv6 de pilha dupla completa do frontend do Load Balancer para os recursos de back-end. Quaisquer alterações feitas na configuração do balanceador de carga do cluster gerenciado ou nas regras NSG afetam o roteamento IPv4 e IPv6.

Nota

Essa configuração não está disponível no portal e não pode ser alterada depois que o cluster é criado.

• 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 pelo Service Fabric.

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

2. Implante seu cluster gerenciado habilitado para IPv6. Personalize o modelo de exemplo conforme necessário ou crie o seu próprio. No exemplo a seguir, criamos um grupo de recursos chamado MyResourceGroup e westus 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, a rede virtual e os recursos 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 que está associado a um endereço IPv6 público no Balanceador de Carga do Azure e endereços IPv6 privados nas VMs.

Traga a 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 deseja usar. Depois de implantar em uma rede virtual existente, é fácil usar ou incorporar outros recursos de rede, como a Rota Expressa do Azure, o Gateway de VPN do Azure, um grupo de segurança de rede e o emparelhamento de rede virtual. Além disso, você também pode trazer seu próprio balanceador de carga do Azure, se necessário.

Nota

Ao usar o BYOVNET, os recursos de cluster gerenciados serão implantados em uma sub-rede.

Nota

Essa configuração não pode ser alterada depois que o cluster é criado e o cluster gerenciado atribuirá um NSG à sub-rede fornecida. Não substitua a atribuição NSG ou o tráfego pode quebrar.

Para trazer a sua própria rede virtual:

1. Obtenha o serviço Id da sua assinatura do aplicativo Provedor de Recursos do Service Fabric.

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

   Nota

   Verifique se você está na assinatura correta, a ID principal 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
   

   Observe o Id da saída anterior como principalId para uso em uma etapa posterior

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

   Observe os valores de Role definition name propriedade e Role definition ID para uso em uma etapa posterior

2. Adicione uma atribuição de função ao aplicativo Provedor de Recursos do Service Fabric. Adicionar uma atribuição de função é uma ação única. Você adiciona a função executando os seguintes comandos do PowerShell ou configurando um modelo do 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. A sub-rede é denominada padrão.

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

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

   Observe o seguinte nome de sub-rede e Id valor da propriedade que é retornado da Subnets seção 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 principal, o nome da definição de função da etapa 2 e o escopo Id da 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>"
   

   Ou você pode adicionar a atribuição de função usando 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 você implantar um modelo novamente incluindo essa atribuição de função, verifique se o GUID é o mesmo usado originalmente. Sugerimos que você execute esse recurso isolado ou remova esse recurso do modelo de cluster pós-implantação, pois ele só precisa ser criado uma vez.

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

3. Configure a subnetId propriedade 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.

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

   No exemplo a seguir, criaremos um grupo de recursos chamado MyResourceGroup e westus 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 especificar o ip público/reutilizar o ip estático no Balanceador de Carga do Azure. Você pode trazer seu próprio Balanceador de Carga do Azure em conjunto com esse recurso ou sozinho se precisar desses ou de outros cenários de balanceador de carga que não são suportados nativamente.

   Quando o cluster é criado, um grupo de segurança de rede é criado no grupo de recursos gerenciados para a sub-rede padrão de nível de cluster. 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ó.

   O Bring your own virtual network também suporta sub-redes de nível de tipo de nó, que permitem colocar tipos de nó em sub-redes separadas, proporcionando 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 em sua 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 torna-se 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 a criação do tipo de nó falhar.

Traga o seu próprio Azure Load Balancer

Os clusters gerenciados criam um Balanceador de Carga Padrão público do Azure 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. Traga seu próprio balanceador de carga permite que você use um Balanceador de Carga do Azure existente para tipos de nó secundário para tráfego de entrada e saída. Ao trazer seu próprio Balanceador de Carga do Azure, você pode:

• Usar um endereço IP estático do Balanceador de Carga pré-configurado para tráfego privado ou público
• Mapear um Load Balancer para um tipo de nó específico
• Configure regras de grupo de segurança de rede por tipo de nó porque cada tipo de nó é implantado em sua própria sub-rede
• Manter as políticas e os controlos existentes que possa ter em vigor
• Configure um balanceador de carga somente interno e use o balanceador de carga padrão para tráfego externo

Nota

Ao usar o BYOVNET, os recursos de cluster gerenciados serão implantados em uma sub-rede com um NSG, independentemente de balanceadores de carga configurados adicionais.

Nota

Você não pode alternar do balanceador de carga padrão para um personalizado após a implantação de um tipo de nó, mas pode modificar a configuração do balanceador de carga personalizado após a implantação, se habilitado.

Requisitos de recursos

• Os tipos de Balanceador de Carga do Azure SKU Básico e Padrão são suportados
• Você deve ter pools de back-end e NAT configurados no Balanceador de Carga do Azure
• 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 exemplos de cenários para os quais os clientes podem usar isso:

Neste exemplo, um cliente deseja rotear o tráfego por meio de um Balanceador de Carga do Azure 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 dos Balanceadores de Carga do Azure existentes para ajudá-lo a gerenciar o fluxo de tráfego para seus aplicativos de forma independente que vivem em tipos de nó separados. Quando configurado como este exemplo, cada tipo de nó estará atrás de seu próprio NSG gerenciado.

Neste exemplo, um cliente deseja rotear o tráfego por meio de Balanceadores de Carga do Azure internos existentes. Isso os ajuda a gerenciar o fluxo de tráfego para seus aplicativos de forma independente que vivem em tipos de nós separados. Quando configurado como este 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 próprio balanceador de carga:

1. Obtenha o serviço Id da sua subscrição da aplicação Service Fabric Resource Provider:

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

   Nota

   Verifique se você está na assinatura correta, a ID principal 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
   

   Observe o Id da saída anterior como principalId para uso em uma etapa posterior

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

   Observe os valores de Role definition name propriedade e Role definition ID para uso em uma etapa posterior

2. Adicione uma atribuição de função ao aplicativo Provedor de Recursos do Service Fabric. Adicionar uma atribuição de função é uma ação única. Você adiciona a função executando os seguintes comandos do PowerShell ou configurando um modelo do 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 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"
   

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

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

   Execute o seguinte comando do PowerShell usando a ID principal, o nome da definição de função da etapa 2 e o escopo Id da atribuição 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 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 você implantar um modelo novamente incluindo essa atribuição de função, verifique se o GUID é o mesmo usado originalmente. Sugerimos que você execute esse recurso isolado ou remova esse recurso do modelo de cluster pós-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 função 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 sonda relacionada em seu Balanceador de Carga do Azure existente. Consulte o modelo traga seu próprio exemplo de balanceador de carga Azure Resource Manager (ARM) para obter um exemplo

5. Opcionalmente, configure as regras NSG do cluster gerenciado aplicadas ao tipo de nó para permitir que qualquer tráfego necessário que você configurou no Balanceador de Carga do Azure ou o tráfego será bloqueado. Consulte o modelo bring your own load balancer sample Azure Resource Manager (ARM) para obter um exemplo de configuração de regra NSG de entrada. No modelo, procure o networkSecurityRules imóvel.

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

   O seguinte criará um grupo de recursos chamado MyResourceGroup e westus 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 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.

Habilite a rede acelerada

A rede acelerada permite a virtualização de E/S de raiz única (SR-IOV) para uma VM de conjunto de dimensionamento de máquina virtual 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, os desvios e a utilização da CPU para as cargas de trabalho de rede mais exigentes. Os tipos de nó de cluster gerenciado do Service Fabric podem ser provisionados com Rede Acelerada em SKUs de VM suportadas. Faça referência a essas limitações e restrições para considerações adicionais.

• Observe que a Rede Acelerada é suportada na maioria dos tamanhos de instância de uso geral e otimizados para computação com 2 ou mais vCPUs. Em instâncias que suportam hyperthreading, a Rede Acelerada é suportada em instâncias de VM com 4 ou mais vCPUs.

Habilite a rede acelerada declarando a propriedade em seu modelo do Gerenciador de enableAcceleratedNetworking Recursos da seguinte maneira:

• 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 do Service Fabric existente, você precisa primeiro dimensionar um cluster do Service Fabric adicionando um novo tipo de nó e executar o seguinte:

1. Provisionar um tipo de nó com a Rede Acelerada habilitada
2. Migre seus serviços e seu estado 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 habilitar a Rede Acelerada no local causaria tempo de inatividade, pois exige que todas as máquinas virtuais em um conjunto de disponibilidade sejam interrompidas e deslocadas antes de habilitar a Rede Acelerada em qualquer 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 suportar cenários como Private Link Service e Bastion Hosts.

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

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

Veja a lista completa de parâmetros disponíveis

Próximos passos

Opçõesde configuração de cluster gerenciado do Service Fabric Visão geral dos clusters gerenciados do Service Fabric