Criar um conjunto do Azure Batch numa rede virtual

Ao criar um pool de Lotes do Azure, você pode provisionar o pool em uma sub-rede de uma Rede Virtual do Azure que você especificar. Este artigo explica como configurar um pool de lotes em uma rede virtual.

Porquê utilizar uma Rede Virtual?

Os nós de computação em um pool podem se comunicar uns com os outros, como executar tarefas de várias instâncias, sem exigir uma rede virtual separada. No entanto, por padrão, os nós em um pool não podem se comunicar com nenhuma máquina virtual (VM) que esteja fora do pool, como servidores de licença ou de arquivos.

Para permitir que os nós de computação se comuniquem com segurança com outras máquinas virtuais ou com uma rede local, você pode provisionar o pool em uma sub-rede de uma Rede Virtual.

Pré-requisitos

  • Autenticação. Para usar uma Rede Virtual do Azure, a API do cliente Batch deve usar a autenticação do Microsoft Entra. Para saber mais, consulte Autenticar soluções de serviço em lote com o Ative Directory.

  • Uma Rede Virtual do Azure. Para preparar uma Rede Virtual com uma ou mais sub-redes com antecedência, você pode usar o portal do Azure, o Azure PowerShell, a CLI (CLI) do Microsoft Azure ou outros métodos.

    • Para criar uma Rede Virtual baseada no Azure Resource Manager, consulte Criar uma rede virtual. Uma Rede Virtual baseada no Gerenciador de Recursos é recomendada para novas implantações e é suportada apenas em pools que usam a Configuração de Máquina Virtual.

    • Para criar uma rede virtual clássica, consulte Criar uma rede virtual (clássica) com várias sub-redes. Uma Rede Virtual clássica é suportada apenas em pools que usam a Configuração de Serviços de Nuvem.

      Importante

      Evite usar 172.17.0.0/16 para VNet do pool de lotes do Azure. É o padrão para a rede de ponte do Docker e pode entrar em conflito com outras redes que você deseja conectar à rede virtual. A criação de uma rede virtual para o pool de Lotes do Azure requer um planejamento cuidadoso de sua infraestrutura de rede.

Requisitos gerais da rede virtual

  • A Rede Virtual deve estar na mesma assinatura e região que a conta de Lote que você usa para criar seu pool.

  • A sub-rede especificada para o pool deve ter endereços IP não atribuídos suficientes para acomodar o número de VMs destinadas ao pool, o suficiente para acomodar as targetDedicatedNodes propriedades e targetLowPriorityNodes do pool. Se a sub-rede não tiver endereços IP não atribuídos suficientes, o conjunto atribui parcialmente os nós de computação e ocorre um erro de redimensionamento.

  • Se você não estiver usando a Comunicação de Nó de Computação Simplificada, precisará resolver seus pontos de extremidade de Armazenamento do Azure usando quaisquer servidores DNS personalizados que sirvam sua rede virtual. Mais concretamente, devem ser resolvíveis os URLs no formato <account>.table.core.windows.net, <account>.queue.core.windows.net e <account>.blob.core.windows.net.

  • Vários pools podem ser criados na mesma rede virtual ou na mesma sub-rede (desde que tenha espaço de endereçamento suficiente). Um único pool não pode existir em várias redes virtuais ou sub-redes.

Outros requisitos de rede virtual diferem, dependendo se o pool de lotes está no VirtualMachineConfiguration ou CloudServiceConfiguration. VirtualMachineConfiguration para Pools de lotes é recomendado, porque CloudServiceConfiguration os pools foram preteridos.

Importante

Os pools de lotes podem ser configurados em um dos dois modos de comunicação de nós. O modo de comunicação de nó clássico é onde o serviço em lote inicia a comunicação com os nós de computação. O modo de comunicação de nó simplificado é onde os nós de computação iniciam a comunicação com o Serviço em lote.

  • Qualquer rede virtual ou rede virtual emparelhada que será usada para pools de lotes não deve ter intervalos de endereços IP sobrepostos com rede definida por software ou roteamento em nós de computação. Uma fonte comum para conflitos é o uso de um tempo de execução de contêiner, como o docker. O Docker criará uma ponte de rede padrão com um intervalo de sub-rede definido de 172.17.0.0/16. Todos os serviços executados dentro de uma rede virtual nesse espaço de endereço IP padrão entrarão em conflito com os serviços no nó de computação, como o acesso remoto via SSH.

Pools na configuração da máquina virtual

Requisitos:

  • Redes Virtuais suportadas: apenas redes virtuais baseadas no Azure Resource Manager.
  • ID da sub-rede: ao especificar a sub-rede usando as APIs de lote, use o identificador de recurso da sub-rede. O identificador da sub-rede tem o formato:

/subscriptions/{subscription}/resourceGroups/{group}/providers/Microsoft.Network/virtualNetworks/{network}/subnets/{subnet}

  • Permissões: verifique se suas políticas de segurança ou bloqueios na assinatura ou grupo de recursos da Rede Virtual restringem as permissões de um usuário para gerenciar a Rede Virtual.
  • Recursos de rede: o Batch cria automaticamente mais recursos de rede no grupo de recursos que contém a Rede Virtual.

Importante

Para cada 100 nós dedicados ou de baixa prioridade, o Batch cria um NSG (grupo de segurança de rede), um endereço IP público e um balanceador de carga. Estes recursos estão limitados pelas quotas de recursos da subscrição. Para conjuntos grandes, poderá ter de pedir um aumento de quota para um ou mais destes recursos.

Grupos de segurança de rede para pools de configuração de máquina virtual: padrão de lote

O Batch cria um NSG (grupo de segurança de rede) no nível da interface de rede de cada implantação do Conjunto de Escala de Máquina Virtual dentro de um pool de Lotes. Para pools que não têm endereços IP públicos sob simplified comunicação de nó de computação, os NSGs não são criados.

Para fornecer a comunicação necessária entre os nós de computação e o serviço em lote, esses NSGs são configurados de modo que:

  • Tráfego TCP de entrada nas portas 29876 e 29877 de endereços IP de serviço em lote que correspondem ao BatchNodeManagement.etiqueta de serviço de região . Esta regra só é criada no classic modo de comunicação do pool.
  • Tráfego TCP de entrada na porta 22 (nós Linux) ou na porta 3389 (nós Windows) para permitir o acesso remoto para SSH ou RDP em portas padrão, respectivamente. Para certos tipos de tarefas de várias instâncias no Linux, como MPI, talvez seja necessário permitir o tráfego SSH para IPs na sub-rede que contém nós de computação em lote. Certos tempos de execução do MPI podem exigir a inicialização por SSH, que normalmente é roteado no espaço de endereço IP privado. Esse tráfego pode ser bloqueado por regras NSG no nível de sub-rede.
  • Saída de qualquer tráfego na porta 443 para endereços IP de serviço de lote que correspondam ao BatchNodeManagement.etiqueta de serviço de região .
  • Tráfego de saída em qualquer porta para a rede virtual. Esta regra pode ser alterada por regras NSG de nível de sub-rede.
  • Tráfego de saída em qualquer porta para a Internet. Esta regra pode ser alterada por regras NSG de nível de sub-rede.

Importante

Tenha cuidado se modificar ou adicionar regras de entrada ou saída em NSGs configurados em lote. Se a comunicação com os nós de computação na sub-rede especificada for negada por um NSG, o serviço em lote definirá o estado dos nós de computação como inutilizável. Além disso, nenhum bloqueio de recurso deve ser aplicado a qualquer recurso criado pelo Batch, porque isso pode impedir a limpeza de recursos como resultado de ações iniciadas pelo usuário, como excluir um pool.

Grupos de segurança de rede para pools de Configuração de Máquina Virtual: Especificando regras no nível da sub-rede

Se você tiver um NSG associado à sub-rede para nós de computação em lote, deverá configurar esse NSG com, pelo menos, as regras de segurança de entrada e saída mostradas nas tabelas a seguir.

Aviso

Os endereços IP do serviço Batch podem ser alterados ao longo do tempo. Portanto, você deve usar o BatchNodeManagement.tag de serviço de região para as regras NSG indicadas nas tabelas a seguir. Evite preencher regras NSG com endereços IP específicos do serviço em lote.

Regras de segurança de entrada

Etiqueta de serviço de origem ou endereços IP Portos de destino Protocolo Modo de Comunicação de Pool Obrigatório
BatchNodeManagement.etiqueta de serviço de região 29876-29877 TCP Clássico Sim
Endereços IP de origem para acessar remotamente nós de computação 3389 (Windows), 22 (Linux) TCP Clássico ou simplificado Não

Configure o tráfego de entrada na porta 3389 (Windows) ou 22 (Linux) somente se precisar permitir o acesso remoto aos nós de computação de fontes externas nas portas RDP ou SSH padrão, respectivamente. Talvez seja necessário permitir o tráfego SSH no Linux se precisar de suporte para tarefas de várias instâncias com determinados tempos de execução MPI (Message Passing Interface) na sub-rede que contém os nós de computação em lote, pois o tráfego pode ser bloqueado por regras NSG no nível da sub-rede. O tráfego MPI normalmente está no espaço de endereço IP privado, mas pode variar entre os tempos de execução do MPI e a configuração do tempo de execução. Permitir o tráfego nessas portas não é estritamente necessário para que os nós de computação do pool sejam utilizáveis. Você também pode desabilitar o acesso remoto padrão nessas portas por meio da configuração de pontos de extremidade de pool.

Regras de segurança de saída

Etiqueta de serviço de destino Portos de destino Protocolo Modo de Comunicação de Pool Obrigatório
BatchNodeManagement.etiqueta de serviço de região 443 * Chinês Sim
Armazenamento.etiqueta de serviço de região 443 TCP Clássico Sim

Saída para BatchNodeManagement.A tag de serviço de região é necessária no classic modo de comunicação do pool se você estiver usando tarefas do Gerenciador de tarefas ou se as tarefas precisarem se comunicar de volta ao serviço em lote. Para saída para BatchNodeManagement.região no simplified modo de comunicação de pool, o serviço de lote atualmente usa apenas o protocolo TCP, mas UDP pode ser necessário para compatibilidade futura. Para pools sem endereços IP públicos usando simplified o modo de comunicação e com um ponto de extremidade privado de gerenciamento de nós, um NSG não é necessário. Para obter mais informações sobre regras de segurança de saída para o BatchNodeManagement.tag de serviço de região, consulte Usar comunicação simplificada de nó de computação.

Pools na configuração de serviços de nuvem

Aviso

Os pools de Configuração de Serviços de Nuvem foram preteridos. Em vez disso, use pools de Configuração de Máquina Virtual.

Requisitos:

  • Redes Virtuais Suportadas: Apenas Redes Virtuais Clássicas.

  • ID da sub-rede: ao especificar a sub-rede usando as APIs de lote, use o identificador de recurso da sub-rede. O identificador da sub-rede tem o formato:

    /subscriptions/{subscription}/resourceGroups/{group}/providers/Microsoft.ClassicNetwork/virtualNetworks/{network}/subnets/{subnet}

  • Permissões: a entidade de serviço deve ter a função do Azure para a Microsoft Azure BatchClassic Virtual Machine Contributor Rede Virtual especificada.

Grupos de segurança de rede para pools de Configuração de Serviços de Nuvem

A sub-rede deve permitir a comunicação de entrada do serviço em lote para poder agendar tarefas nos nós de computação e deve permitir que a comunicação de saída se comunique com o Armazenamento do Azure ou outros recursos.

Não é necessário especificar um NSG, porque o Batch configura a comunicação de entrada somente dos endereços IP do Batch para os nós do pool. No entanto, se a sub-rede especificada tiver NSGs associados e/ou uma firewall, configure as regras de segurança de entrada e saída conforme mostrado nas tabelas seguintes. Se a comunicação com os nós de computação na sub-rede especificada for negada por um NSG, o serviço em lote definirá o estado dos nós de computação como inutilizável.

Configure o tráfego de entrada na porta 3389 para Windows se tiver de permitir acesso RDP aos nós do conjunto. Esta regra não é necessária para que os nós do pool sejam utilizáveis.

Regras de segurança de entrada

Endereços IP de origem Portas de origem Destino Portas de destino Protocolo Ação
Qualquer

Embora essa regra exija efetivamente permitir tudo, o serviço de lote aplica uma regra de ACL no nível de cada nó que filtra todos os endereços IP de serviço que não são de lote.
* Qualquer 10100, 20100, 30100 TCP Permitir
Opcionalmente, para permitir o acesso RDP aos nós de computação. * Qualquer 3389 TCP Permitir

Regras de segurança de saída

Source Portas de origem Destino Portas de destino Protocolo Ação
Qualquer * Qualquer 443 Qualquer Permitir

Criar um pool com uma Rede Virtual no portal do Azure

Depois de criar sua Rede Virtual e atribuir uma sub-rede a ela, você pode criar um pool de lotes com essa Rede Virtual. Siga estas etapas para criar um pool a partir do portal do Azure:

  1. Procure e selecione Contas em lote na barra de pesquisa na parte superior do portal do Azure. Selecione sua conta Batch. Essa conta deve estar na mesma assinatura e região que o grupo de recursos que contém a Rede Virtual que você pretende usar.

  2. Selecione Pools na navegação à esquerda.

  3. Na janela Pools, selecione Adicionar.

    Screenshot of the Pools page in a Batch account that highlights the Pools option in the left side navigation and add button on the Pools page.

  4. Na página Adicionar Pool, selecione as opções e insira as informações do seu pool. Para obter mais informações sobre como criar pools para sua conta de lote, consulte Criar um pool de nós de computação. Tamanho do nó, nós dedicados de destino e nós de ponto de destino/baixa prioridade e quaisquer configurações opcionais desejadas.

  5. Em Rede Virtual, selecione a rede virtual e a sub-rede que deseja usar.

  6. Selecione OK para criar seu pool.

Importante

Se você tentar excluir uma sub-rede que está sendo usada por um pool, você receberá uma mensagem de erro. Todos os pools que usam uma sub-rede devem ser excluídos antes de excluir essa sub-rede.

Rotas definidas pelo utilizador para túnel forçado

Você pode ter requisitos em sua organização para redirecionar (forçar) o tráfego vinculado à Internet da sub-rede de volta para seu local local para inspeção e registro. Além disso, você pode ter ativado o túnel forçado para as sub-redes em sua rede virtual.

Para garantir que os nós em seu pool funcionem em uma Rede Virtual que tenha o encapsulamento forçado habilitado, você deve adicionar as seguintes rotas definidas pelo usuário (UDR) para essa sub-rede.

Para pools de modo de comunicação clássico:

  • O serviço de lote precisa se comunicar com os nós para agendar tarefas. Para habilitar essa comunicação, adicione um UDR correspondente ao BatchNodeManagement.tag de serviço de região na regiãoonde sua conta de lote existe. Defina o tipo de salto seguinte como Internet.

  • Certifique-se de que sua rede local não esteja bloqueando o tráfego TCP de saída para o Armazenamento do Azure na porta de destino 443 (especificamente, URLs do formato *.table.core.windows.net, *.queue.core.windows.nete *.blob.core.windows.net).

Para pools de modo de comunicação simplificado sem usar o ponto de extremidade privado de gerenciamento de nós:

  • Certifique-se de que sua rede local não esteja bloqueando o tráfego TCP/UDP de saída para o Azure Batch BatchNodeManagement.Etiqueta de serviço de região na porta de destino 443. Atualmente, apenas o protocolo TCP é usado, mas o UDP pode ser necessário para compatibilidade futura.

Para todas as piscinas:

  • Se você usar montagens de arquivos virtuais, revise os requisitos de rede e verifique se nenhum tráfego necessário está bloqueado.

Aviso

Os endereços IP do serviço Batch podem ser alterados ao longo do tempo. Para evitar interrupções devido a alterações no endereço IP do serviço em lote, não especifique diretamente os endereços IP. Em vez disso, use o BatchNodeManagement.etiqueta de serviço de região.

Próximos passos