Criar um pool do Lote do Azure em uma rede virtual
Ao criar um pool do Lote 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 do Lote em uma Rede Virtual.
Por que usar uma Rede Virtual?
Os nós de computação de um pool podem se comunicar entre si a fim de executar tarefas de várias instâncias sem a necessidade de uma Rede Virtual. No entanto, por padrão, os nós em um pool não conseguem se comunicar com nenhuma máquina virtual (VM) que esteja fora do pool, como servidores de licença ou de arquivo.
Para permitir que nós de computação se comuniquem de forma segura 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 de cliente do Lote deve usar a autenticação do Microsoft Entra. Para saber mais, confira como Autenticar soluções do serviço do Lote no Active 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 do Microsoft Azure (CLI) ou outros métodos.
Para criar uma Rede Virtual baseada no Azure Resource Manager, consulte Criar uma rede virtual. Uma Rede Virtual baseada no Resource Manager é recomendável para novas implantações e só tem suporte em pools que usam Configuração da 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 tem suporte apenas em pools na configuração de Serviços de Nuvem.
Importante
Evite usar 172.17.0.0/16 para a rede virtual do pool de lotes do Azure. Ele é 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 de rede virtual
A Rede Virtual deve estar na mesma assinatura e região da conta do Lote que você usa para criar o 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 direcionadas para o pool, o suficiente para acomodar as propriedades
targetDedicatedNodesetargetLowPriorityNodesdo pool. Se a sub-rede não tiver endereços IP não atribuídos suficientes, o pool alocará parcialmente os nós de computação e ocorrerá um erro de redimensionamento.Se você não estiver usando a Comunicação simplificada do nó de computação, precisará resolver os pontos de extremidade do Armazenamento do Azure por eventuais servidores DNS personalizados que atendam à sua rede virtual. Especificamente, as URLs no formato
<account>.table.core.windows.net,<account>.queue.core.windows.net, e<account>.blob.core.windows.netdevem poder ser resolvidas.Vários pools podem ser criados na mesma rede virtual ou na mesma sub-rede (desde que ela tenha espaço de endereço suficiente). Um único pool não pode existir entre várias redes virtuais ou sub-redes.
Outros requisitos de rede virtual diferem, dependendo de o pool do Lote estar no VirtualMachineConfiguration ou no CloudServiceConfiguration. VirtualMachineConfiguration para pools do Lote é recomendado, porque os pools CloudServiceConfiguration foram preteridos.
Importante
Os pools do Lote podem ser configurados em um de dois modos de comunicação do nó. O modo de comunicação de nó clássico é onde o serviço do 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 do 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 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 em 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 acesso remoto via SSH.
Pools na configuração de Máquina Virtual
Requisitos:
- Redes Virtuais com suporte: somente 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 recursos da sub-rede. O identificador da sub-rede está no formato:
/subscriptions/{subscription}/resourceGroups/{group}/providers/Microsoft.Network/virtualNetworks/{network}/subnets/{subnet}
- Permissões: verifique se as políticas de segurança, os bloqueios na assinatura da Rede Virtual ou o grupo de recursos restringem permissões de um usuário para gerenciar a Rede Virtual.
- Recursos de rede adicionais: o Lote 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 Lote cria um NSG (grupo de segurança de rede), um endereço IP público e um balanceador de carga. Esses recursos são limitados pelas cotas de recursos da assinatura. Para pools grandes, talvez você precise solicitar um aumento de cota para um ou mais desses recursos.
Grupos de segurança de rede para pools de Configuração de Máquina Virtual: padrão do Lote
O Lote cria um NSG (grupo de segurança de rede) no nível da interface de rede de cada implantação do Conjunto de Dimensionamento de Máquinas Virtuais dentro de um pool do Lote. Para pools que não têm endereços IP públicos na comunicação do nó de computação simplified, os NSGs não são criados.
Para fornecer a comunicação necessária entre nós de computação e o serviço do Lote, esses NSGs são configurados de modo que:
- Tráfego TCP de entrada nas portas 29876 e 29877 dos endereços IP do serviço de Lote que correspondem ao BatchNodeManagement. a marca de serviço da região. Essa regra só é criada no modo de comunicação do pool
classic. - Tráfego TCP de entrada na porta 22 (nós do Linux) ou na porta 3389 (nós do Windows) para permitir o acesso remoto para SSH ou RDP em portas padrão, respectivamente. Para determinados tipos de tarefas de várias instâncias no Linux (como a MPI), você também precisa permitir o tráfego na porta SSH 22 para IPs na sub-rede que contém os nós de computação do Lote. Determinados runtimes de 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 pelas regras de NSG no nível da sub-rede.
- Envie qualquer tráfego na porta 443 para endereços IP do serviço de Lote que correspondem ao BatchNodeManagement. a marca de serviço da região.
- Tráfego de saída em qualquer porta para a rede virtual. Essa regra pode ser corrigida pelas regras de NSG no nível da sub-rede.
- Tráfego de saída em qualquer porta para a Internet. Essa regra pode ser corrigida pelas regras de NSG no nível da sub-rede.
Importante
Tenha cuidado se você modificar ou adicionar regras de entrada ou de saída nos NSGs configurados pelo Lote. Se a comunicação com os nós de computação na sub-rede especificada for negada por um NSG, o serviço do Lote definirá o estado dos nós de computação como inutilizável. Além disso, nenhum bloqueio de recurso deve ser aplicado a recursos criados pelo Lote, porque isso pode impedir a limpeza de recursos como resultado de ações iniciadas pelo usuário, como a exclusão de 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ê tem um NSG associado à sub-rede para nós de computação do Lote, precisa 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 de lote podem mudar ao longo do tempo. Portanto, você deve usar a marca de serviço da região BatchNodeManagement para as regras de NSG indicadas nas tabelas a seguir. Evite popular as regras de NSG com endereços IP específicos do serviço do Lote.
Regras de segurança de entrada
| Endereços IP ou marca de serviço de origem | Portas de destino | Protocolo | Modo de Comunicação do Pool | Obrigatório |
|---|---|---|---|---|
| BatchNodeManagement. a marca 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 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 você precisar de suporte para tarefas de várias instâncias com determinados tempos de execução da Interface de Passagem de Mensagens (MPI) na sub-rede que contém os nós de computação do Lote, pois o tráfego pode ser bloqueado por regras NSG no nível da sub-rede. O tráfego MPI normalmente ocorre em um 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. Não é estritamente necessário permitir o tráfego nessas portas 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 do pool.
Regras de segurança de saída
| Marca de serviço de destino | Portas de destino | Protocolo | Modo de Comunicação do Pool | Obrigatório |
|---|---|---|---|---|
| BatchNodeManagement. a marca de serviço de região | 443 | * | Simplificado | Sim |
| Armazenamento. marca de serviço de região | 443 | TCP | Clássico | Sim |
A saída para o BatchNodeManagement. a marca de serviço da região é exigida no modo de comunicação do pool classic se você estiver usando tarefas do Gerenciador de Trabalhos ou se suas tarefas precisam se comunicar novamente com o serviço do Lote. Na saída de para o BatchNodeManagement. daregião no modo de comunicação do pool simplified, o serviço do Lote atualmente usa apenas o protocolo TCP, mas o UDP pode ser exigido para compatibilidade futura. Para pools sem endereços IP públicos que usam o modo de comunicação simplified 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. a marca de serviço da região, confira Usar a comunicação simplificada de nó de computação.
Pools na configuração dos Serviços de Nuvem
Aviso
Os pools de Configuração de Serviços de Nuvem foram preteridos. Como alternativa, use pools de Configuração de Máquina Virtual.
Requisitos:
Redes Virtuais com suporte: somente Redes Virtuais Clássicas.
ID da sub-rede: ao especificar a sub-rede usando as APIs de Lote, use o identificador de recursos da sub-rede. O identificador da sub-rede está no formato:
/subscriptions/{subscription}/resourceGroups/{group}/providers/Microsoft.ClassicNetwork/virtualNetworks/{network}/subnets/{subnet}Permissões: a entidade de serviço
Microsoft Azure Batchdeve ter a funçãoClassic Virtual Machine Contributorno Azure para a 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 a partir do serviço de Lote para conseguir agendar as tarefas nos nós de computação e deve permitir que a comunicação de saída se comunicar com o Armazenamento do Azure ou outros recursos.
Você não precisa especificar um NSG, porque o Lote configura comunicação de entrada apenas dos endereços IP de Lote para os nós do pool. No entanto, se a sub-rede especificada associou NSGs e/ou um firewall, configure as regras de segurança de entrada e saída conforme mostrado nas tabelas a seguir. Se a comunicação com os nós de computação na sub-rede especificada for negada por um NSG, o serviço do Lote definirá o estado dos nós de computação como inutilizável.
Configure o tráfego de entrada na porta 3389 para o Windows se precisar permitir o acesso RDP aos nós do pool. Essa regra não é obrigatória para que os nós do pool possam ser usados.
Regras de segurança de entrada
| Endereços IP da fonte | Portas de origem | Destino | Portas de destino | Protocolo | Ação |
|---|---|---|---|---|---|
| Qualquer Embora essa regra exija efetivamente permitir tudo, o serviço do Lote aplica uma regra ACL no nível de cada nó que filtra todos os endereços IP que não são do serviço do Lote. |
* | Qualquer | 10100, 20100, 30100 | TCP | Allow |
| Opcional, para permitir o acesso RDP aos nós de computação. | * | Qualquer | 3389 | TCP | Allow |
Regras de segurança da saída
| Fonte | Portas de origem | Destino | Portas de destino | Protocolo | Ação |
|---|---|---|---|---|---|
| Qualquer | * | Qualquer | 443 | Qualquer | Allow |
Criar um pool com um Rede Virtual no portal do Azure
Depois de criar a Rede Virtual e atribuir uma sub-rede a ela, você poderá criar um pool do lote com essa Rede Virtual. Siga estas etapas para criar um pool no portal do Azure:
Pesquise e selecione Azure AD B2C na barra de pesquisa na parte superior do portal do Azure. Selecione sua conta do Lote. Esta conta deve estar na mesma assinatura e na mesma região que o grupo de recursos que contém a Rede Virtual que você deseja usar.
Selecione Pools do painel de navegação esquerdo.
Na janela Pools, selecione Adicionar.
Na página Adicionar Pool, selecione as opções e insira as informações do pool. Para obter mais informações sobre como criar pools para sua conta do Lote, confira Criar um pool de nós de computação. O Tamanho do nó, os Nós dedicados de destino e os Nós spot/de baixa prioridade de destino, bem como qualquer configuração opcional desejada.
Em Rede virtual, selecione a rede virtual e a sub-rede que você deseja usar.
Selecione OK para criar o pool.
Importante
Se tentar excluir uma sub-rede que está sendo usada por um pool, receberá uma mensagem de erro. Todos os pools que usam uma sub-rede devem ser excluídos antes de excluir a sub-rede.
Rotas definidas pelo usuário para o túnel forçado
Você pode ter requisitos em sua organização para redirecionar (forçar) o tráfego associado à Internet da sub-rede de volta para a sua localização para inspeção e registro em log. Além disso, talvez você tenha habilitado o túnel forçado para as sub-redes na sua Rede Virtual.
Para garantir que os nós no pool funcionem em uma Rede Virtual com túnel forçado habilitado, você deve adicionar as seguintes UDRs (rotas definidas pelo usuário) a essa sub-rede.
Para pools de modo de comunicação clássico:
O serviço do Lote precisa se comunicar com os nós para o agendamento de tarefas. Para habilitar essa comunicação, adicione uma UDR correspondente ao BatchNodeManagement. a marca de serviço da região na região onde existe sua conta do Lote. Defina o tipo do próximo salto para Internet.
Confirme se a rede local não está bloqueando o tráfego TCP de saída no Armazenamento do Azure na porta de destino 443 (especificamente, as URLs da forma
*.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:
- Verifique se a rede local não está bloqueando o tráfego TCP/UDP de saída para o BatchNodeManagement. a marca de serviço da região do Lote do Azure na porta de destino 443. Atualmente, apenas o protocolo TCP é usado, mas o UDP pode ser exigido para compatibilidade futura.
Para todos os pools:
- 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 de lote podem mudar ao longo do tempo. Para evitar interrupções devido a alterações de endereço IP do serviço Lote, não especifique diretamente os endereços IP. Em vez disso, use o BatchNodeManagement. a marca de serviço da região.