Rede

Conforme você cria e gerencia clusters do Azure Service Fabric, você fornece conectividade de rede para seus nós e seus aplicativos. Os recursos de rede incluem intervalos de endereços IP, redes virtuais, balanceadores de carga e grupos de segurança de rede. Neste artigo, você aprenderá as melhores práticas para esses recursos.

Examine os Padrões de Rede do Service Fabric do Azure para saber como criar clusters que usam os seguintes recursos: rede virtual ou sub-rede existente, endereço IP público estático, balanceador de carga somente interno ou balanceador de carga interno e externo.

Rede de infraestrutura

Maximize o desempenho de sua máquina virtual com a rede acelerada declarando a propriedade enableAcceleratedNetworking no modelo do Resource Manager. O seguinte snippet refere-se a NetworkInterfaceConfigurations de um conjunto de dimensionamento de máquinas virtuais que habilita a rede acelerada:

"networkInterfaceConfigurations": [
  {
    "name": "[concat(variables('nicName'), '-0')]",
    "properties": {
      "enableAcceleratedNetworking": true,
      "ipConfigurations": [
        {
        <snip>
        }
      ],
      "primary": true
    }
  }
]

O cluster do Service Fabric pode ser provisionado no Linux com a Rede Acelerada e no Windows com a Rede Acelerada.

A rede acelerada tem suporte para SKUs da série de máquinas virtuais do Azure: D/DSv2, D/DSv3, E/ESv3, F/FS, FSv2 e Ms/Mms. A rede acelerada foi testada com êxito usando o SKU Standard_DS8_v3 em 23/01/2019 em um Cluster do Windows no Service Fabric e usando o Standard_DS12_v2 em 29/01/2019 em um Cluster do Linux no Service Fabric. Observe que a rede acelerada requer pelo menos 4 vCPUs.

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 as seguintes etapas:

1. Provisionar um NodeType com a Rede Acelerada habilitada
2. Migrar serviços e seus estados para o NodeType 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.

Rede de cluster

• Os clusters do Service Fabric podem ser implantados em uma rede virtual existente seguindo as etapas descritas em Padrões de rede do Service Fabric.

• Os NSGs (grupos de segurança de rede) são recomendados para tipos de nós que restringem o tráfego de entrada e saída para o cluster. Verifique se as portas necessárias estão abertas no NSG.

• O tipo de nó primário, que contém os serviços do sistema do Service Fabric, não precisa ser exposto por meio do balanceador de carga externo e pode ser exposto por um balanceador de carga interno

• Use um endereço IP público estático para seu cluster.

Regras de Segurança de Rede

As regras descritas a seguir são o mínimo recomendado para uma configuração típica. Também incluímos quais regras são obrigatórias para um cluster operacional, se as regras opcionais não forem desejadas. Isso permite um bloqueio de segurança completo com conceitos de emparelhamento de rede e jumpbox, como o Azure Bastion. A falha em abrir as portas obrigatórias ou aprovar o IP/URL impedirá a operação adequada do cluster e talvez ele não tenha suporte.

Entrada

Mais informações sobre as regras de segurança de entrada:

• Portal do Azure. Essa porta é usada pelo Provedor de Recursos do Service Fabric para consultar informações sobre o cluster para exibição no Portal de Gerenciamento do Azure. Se essa porta não estiver acessível do provedor de recursos do Service Fabric, você verá uma mensagem como “Nós não encontrados” ou “UpgradeServiceNotReachable” no portal do Azure e sua lista de nós e aplicativos aparecerá vazia. Isso significa que, se desejar ter visibilidade do cluster por meio do Portal de Gerenciamento do Azure, o balanceador de carga deverá expor um endereço IP público e o NSG deverá permitir o tráfego de entrada de 19080. Essa porta é recomendada para operações de gerenciamento estendidas do Provedor de recursos do Service Fabric para garantir maior confiabilidade.

• API do cliente. O ponto de extremidade de conexão de cliente para APIs usadas pelo PowerShell.

• SFX + API do Cliente. Essa porta é usada pelo Service Fabric Explorer para navegar e gerenciar seu cluster. Ela é usada pelas APIs mais comuns, como REST/PowerShell (Microsoft.ServiceFabric.PowerShell.Http)/CLI/.NET, da mesma forma.

• Cluster. Usado para a comunicação entre nós.

• Efêmero. O Service Fabric usa parte dessas portas como portas do aplicativo e o restante fica disponível para o SO. Ele também mapeia esse intervalo para o intervalo existente presente no sistema operacional. Então, para todas as finalidades, você pode usar os intervalos fornecidos na amostra aqui. Verifique se a diferença entre as portas de início e de fim é de pelo menos 255. Você poderá encontrar conflitos se a diferença for muito baixa, uma vez que esse intervalo é compartilhado com o sistema operacional. Para ver o intervalo de portas dinâmicas configurado, execute netsh int ipv4 show dynamicport tcp. Essas portas não são necessárias para clusters do Linux.

• Aplicativo. O intervalo de portas do aplicativo deve ser amplo o bastante para cobrir o requisito de ponto de extremidade dos aplicativos. Esse intervalo deve ser exclusivo no intervalo de portas dinâmico no computador, isto é, o intervalo ephemeralPorts conforme definido na configuração. O Service Fabric usará essas portas sempre que novas portas forem necessárias e cuidará de abrir o firewall para essas portas nos nós.

• RDP. Opcional, se o RDP for necessário na Internet ou no VirtualNetwork para cenários jumpbox.

• SSH. Opcional, se o SSH for necessário na Internet ou no VirtualNetwork para cenários jumpbox.

• Ponto de extremidade personalizado. Um exemplo para seu aplicativo habilitar um ponto de extremidade acessível pela Internet.

Saída

Mais informações sobre as regras de segurança de saída:

• Provedor de Recursos. Conexão entre UpgradeService e o provedor de recursos do Service Fabric para receber operações de gerenciamento, como implantações ARM ou operações obrigatórias, como seleção de nó de semente ou atualização de tipo de nó principal.

• Baixar binários. O serviço de atualização está usando o endereço download.microsoft.com para obter os binários. Essa relação é necessária para a instalação, para restaurar ao estado anterior e para as atualizações de runtime. No cenário de um balanceador de carga "somente interno", um balanceador de carga externo adicional deve ser adicionado com uma regra que permita o tráfego de saída para a porta 443. Opcionalmente, essa porta pode ser bloqueada após uma configuração bem-sucedida, mas, nesse caso, o pacote de atualização deve ser distribuído para os nós ou a porta precisará ser aberta por um curto período e, posteriormente, uma atualização manual será necessária.

Use o Firewall do Azure com o log de fluxo do NSG e a análise de tráfego para acompanhar problemas de conectividade. O modelo do ARM Service Fabric com NSG é um bom exemplo para começar.

Cenários comuns que precisam de regras adicionais

Todos os cenários adicionais podem ser abordados com asmarcas de serviço do Azure.

Azure DevOps

As tarefas clássicas do PowerShell no Azure DevOps (Marca de Serviço: AzureCloud) precisam de acesso à API do Cliente para o cluster, exemplos são implantações de aplicativo ou tarefas operacionais. Isso não se aplica apenas à abordagem de modelos do ARM, incluindo recursos de aplicativo do ARM.

Atualizar o Windows

Melhor prática para aplicar patch no sistema operacional Windows está substituindo o disco do SO por atualizações automáticas de imagem do SO, nenhuma regra adicional é necessária. O aplicativo de orquestração de Patch está gerenciando atualizações de VM em que o Windows Updates aplica patches do sistema operacional, isso precisa acessar o centro de Download (marca de serviço: AzureUpdateDelivery) para baixar os binários de atualização.

Gerenciamento de API

A integração do Gerenciamento de API do Azure (marca de serviço: ApiManagement) precisa de acesso à API do cliente para consultar informações de ponto de extremidade do cluster.

Rede de aplicativo

• Para executar cargas de trabalho de contêiner do Windows, use o modo de rede aberto para facilitar a comunicação de serviço a serviço.

• Use um proxy reverso, como o Traefik ou o proxy reverso do Service Fabric, para expor portas de aplicativo comuns, como 80 ou 443.

• Para contêineres do Windows hospedados em computadores desconectados que não podem efetuar pull de camadas de base do armazenamento em nuvem do Azure, substitua o comportamento da camada externa usando o sinalizador --allow-nondistributable-artifacts no daemon do Docker.

Próximas etapas

• Crie um cluster em VMs ou em computadores que estejam executando o Windows Server: Criação de um cluster do Service Fabric para o Windows Server
• Criar um cluster em VMs ou em computadores que estejam executando o Linux: Criar um cluster do Linux
• Saiba mais sobre as opções de suporte do Service Fabric