Partilhar via

Planear uma rede virtual para o Azure HDInsight

  • Artigo

Este artigo fornece informações em segundo plano sobre a utilização de Redes Virtuais (VNets) do Azure com o Azure HDInsight. Também aborda as decisões de conceção e implementação que têm de ser tomadas antes de poder implementar uma rede virtual para o cluster do HDInsight. Assim que a fase de planeamento estiver concluída, pode avançar para Criar redes virtuais para clusters do Azure HDInsight. Para obter mais informações sobre endereços IP de gestão do HDInsight necessários para configurar corretamente grupos de segurança de rede (NSGs) e rotas definidas pelo utilizador, veja Endereços IP de gestão do HDInsight.

A utilização de um Rede Virtual do Azure permite os seguintes cenários:

  • Ligar ao HDInsight diretamente a partir de uma rede no local.
  • Ligar o HDInsight a arquivos de dados numa rede virtual do Azure.
  • Aceder diretamente aos serviços do Apache Hadoop que não estão disponíveis publicamente através da Internet. Por exemplo, as APIs do Apache Kafka ou a API Java do Apache HBase.

Importante

Criar um cluster do HDInsight numa VNET irá criar vários recursos de rede, como NICs e balanceadores de carga. Não elimine nem modifique estes recursos de rede, pois são necessários para que o cluster funcione corretamente com a VNET.

Planeamento

Seguem-se as perguntas que tem de responder ao planear instalar o HDInsight numa rede virtual:

  • Precisa de instalar o HDInsight numa rede virtual existente? Ou está a criar uma nova rede?

    Se estiver a utilizar uma rede virtual existente, poderá ter de modificar a configuração de rede antes de poder instalar o HDInsight. Para obter mais informações, veja a secção Adicionar HDInsight a uma rede virtual existente .

  • Pretende ligar a rede virtual que contém o HDInsight a outra rede virtual ou à sua rede no local?

    Para trabalhar facilmente com recursos em redes, poderá ter de criar um DNS personalizado e configurar o reencaminhamento de DNS. Para obter mais informações, veja a secção ligar várias redes .

  • Pretende restringir/redirecionar o tráfego de entrada ou saída para o HDInsight?

    O HDInsight tem de ter uma comunicação sem restrições com endereços IP específicos no datacenter do Azure. Também existem várias portas que têm de ser permitidas através de firewalls para comunicação de cliente. Para obter mais informações, veja Controlar o tráfego de rede.

Adicionar o HDInsight a uma rede virtual existente

Utilize os passos nesta secção para descobrir como adicionar um novo HDInsight a um Rede Virtual do Azure existente.

Nota

  • Não é possível adicionar um cluster do HDInsight existente a uma rede virtual.
  • A VNET e o cluster que está a ser criado têm de estar na mesma subscrição.

  1. Está a utilizar um modelo de implementação clássico ou Resource Manager para a rede virtual?

    O HDInsight 3.4 e superior requer uma rede virtual Resource Manager. As versões anteriores do HDInsight necessitavam de uma rede virtual clássica.

    Se a rede existente for uma rede virtual clássica, tem de criar uma rede virtual Resource Manager e, em seguida, ligar as duas. Ligar VNets clássicas a novas VNets.

    Depois de associado, o HDInsight instalado na rede Resource Manager pode interagir com recursos na rede clássica.

  2. Utiliza grupos de segurança de rede, rotas definidas pelo utilizador ou aplicações de Rede Virtual para restringir o tráfego para dentro ou para fora da rede virtual?

    Como um serviço gerido, o HDInsight requer acesso sem restrições a vários endereços IP no datacenter do Azure. Para permitir a comunicação com estes endereços IP, atualize quaisquer grupos de segurança de rede existentes ou rotas definidas pelo utilizador.

    O HDInsight aloja vários serviços, que utilizam várias portas. Não bloqueie o tráfego para estas portas. Para obter uma lista de portas a permitir através de firewalls de aplicações virtuais, consulte a secção Segurança.

    Para localizar a configuração de segurança existente, utilize os seguintes comandos Azure PowerShell ou da CLI do Azure:

    • Grupos de segurança de rede

      Substitua RESOURCEGROUP pelo nome do grupo de recursos que contém a rede virtual e, em seguida, introduza o comando:

      Get-AzNetworkSecurityGroup -ResourceGroupName  "RESOURCEGROUP"

      az network nsg list --resource-group RESOURCEGROUP

      Para obter mais informações, veja o documento Resolver problemas de grupos de segurança de rede .

      Importante

      As regras do grupo de segurança de rede são aplicadas por ordem com base na prioridade da regra. A primeira regra que corresponde ao padrão de tráfego é aplicada e não são aplicadas outras pessoas a esse tráfego. Ordenar regras da maioria permissiva para a menos permissiva. Para obter mais informações, veja o documento Filtrar tráfego de rede com grupos de segurança de rede .

    • Rotas definidas pelo utilizador

      Substitua RESOURCEGROUP pelo nome do grupo de recursos que contém a rede virtual e, em seguida, introduza o comando:

      Get-AzRouteTable -ResourceGroupName "RESOURCEGROUP"

      az network route-table list --resource-group RESOURCEGROUP

      Para obter mais informações, veja o documento Resolução de problemas de rotas .

  3. Crie um cluster do HDInsight e selecione o Azure Rede Virtual durante a configuração. Utilize os passos nos seguintes documentos para compreender o processo de criação do cluster:

    Importante

    Adicionar o HDInsight a uma rede virtual é um passo de configuração opcional. Certifique-se de que seleciona a rede virtual ao configurar o cluster.

Ligar várias redes

O maior desafio com uma configuração de várias redes é a resolução de nomes entre as redes.

O Azure fornece resolução de nomes para os serviços do Azure que estão instalados numa rede virtual. Esta resolução de nomes incorporada permite ao HDInsight ligar-se aos seguintes recursos com um nome de domínio completamente qualificado (FQDN):

  • Qualquer recurso disponível na Internet. Por exemplo, microsoft.com, windowsupdate.com.

  • Qualquer recurso que esteja no mesmo Rede Virtual do Azure, utilizando o nome DNS interno do recurso. Por exemplo, ao utilizar a resolução de nomes predefinida, seguem-se exemplos de nomes DNS internos atribuídos a nós de trabalho do HDInsight:

    • <workername1.0owcbllr5hze3hxdja3mqlrhhe.ex.internal.cloudapp.net>

    • <workername2.0owcbllr5hze3hxdja3mqlrhhe.ex.internal.cloudapp.net>

      Ambos os nós podem comunicar diretamente entre si e outros nós no HDInsight com nomes DNS internos.

A resolução de nomes predefinida não permite que o HDInsight resolva os nomes dos recursos em redes associadas à rede virtual. Por exemplo, é comum associar a sua rede no local à rede virtual. Com apenas a resolução de nomes predefinida, o HDInsight não consegue aceder aos recursos na rede no local por nome. O contrário também é verdade: os recursos na sua rede no local não podem aceder aos recursos na rede virtual por nome.

Aviso

Tem de criar o servidor DNS personalizado e configurar a rede virtual para a utilizar antes de criar o cluster do HDInsight.

Para ativar a resolução de nomes entre a rede virtual e os recursos em redes associadas, tem de realizar as seguintes ações:

  1. Crie um servidor DNS personalizado no Azure Rede Virtual onde planeia instalar o HDInsight.

  2. Configure a rede virtual para utilizar o servidor DNS personalizado.

  3. Localize o sufixo DNS atribuído ao Azure para a sua rede virtual. Este valor é semelhante a 0owcbllr5hze3hxdja3mqlrhhe.ex.internal.cloudapp.net. Para obter informações sobre como localizar o sufixo DNS, veja a secção Exemplo: DNS Personalizado .

  4. Configurar o reencaminhamento entre os servidores DNS. A configuração depende do tipo de rede remota.

    • Se a rede remota for uma rede no local, configure o DNS da seguinte forma:

      • DNS personalizado (na rede virtual):

        • Reencaminhar pedidos para o sufixo DNS da rede virtual para a resolução recursiva do Azure (168.63.129.16). O Azure processa pedidos de recursos na rede virtual

        • Reencaminhar todos os outros pedidos para o servidor DNS no local. O DNS no local processa todos os outros pedidos de resolução de nomes, mesmo pedidos de recursos da Internet, como Microsoft.com.

      • DNS no local: reencaminhar pedidos para o sufixo DNS de rede virtual para o servidor DNS personalizado. Em seguida, o servidor DNS personalizado é reencaminhado para a resolução recursiva do Azure.

        Esta configuração encaminha os pedidos de nomes de domínio completamente qualificados que contêm o sufixo DNS da rede virtual para o servidor DNS personalizado. Todos os outros pedidos (mesmo para endereços de Internet públicos) são processados pelo servidor DNS no local.

    • Se a rede remota for outra Rede Virtual do Azure, configure o DNS da seguinte forma:

      • DNS personalizado (em cada rede virtual):

        • Os pedidos para o sufixo DNS das redes virtuais são reencaminhados para os servidores DNS personalizados. O DNS em cada rede virtual é responsável pela resolução de recursos na respetiva rede.

        • Reencaminhar todos os outros pedidos para a resolução recursiva do Azure. A resolução recursiva é responsável pela resolução de recursos locais e da Internet.

        O servidor DNS para cada rede reencaminha pedidos para o outro, com base no sufixo DNS. Outros pedidos são resolvidos com a resolução recursiva do Azure.

      Para obter um exemplo de cada configuração, veja a secção Exemplo: DNS Personalizado .

Para obter mais informações, veja o documento Resolução de Nomes para VMs e Instâncias de Função .

Ligar diretamente aos serviços do Apache Hadoop

Pode ligar ao cluster em https://CLUSTERNAME.azurehdinsight.net. Este endereço utiliza um IP público, que poderá não estar acessível se tiver utilizado NSGs para restringir o tráfego de entrada da Internet. Além disso, quando implementa o cluster numa VNet, pode aceder ao mesmo com o ponto https://CLUSTERNAME-int.azurehdinsight.netfinal privado . Este ponto final é resolvido para um IP privado dentro da VNet para acesso ao cluster.

Para ligar ao Apache Ambari e a outras páginas Web através da rede virtual, utilize os seguintes passos:

  1. Para detetar os nomes de domínio completamente qualificados internos (FQDN) dos nós de cluster do HDInsight, utilize um dos seguintes métodos:

    Substitua RESOURCEGROUP pelo nome do grupo de recursos que contém a rede virtual e, em seguida, introduza o comando:

    $clusterNICs = Get-AzNetworkInterface -ResourceGroupName "RESOURCEGROUP" | where-object {$_.Name -like "*node*"}

$nodes = @()
foreach($nic in $clusterNICs) {
    $node = new-object System.Object
    $node | add-member -MemberType NoteProperty -name "Type" -value $nic.Name.Split('-')[1]
    $node | add-member -MemberType NoteProperty -name "InternalIP" -value $nic.IpConfigurations.PrivateIpAddress
    $node | add-member -MemberType NoteProperty -name "InternalFQDN" -value $nic.DnsSettings.InternalFqdn
    $nodes += $node
}
$nodes | sort-object Type

    az network nic list --resource-group RESOURCEGROUP --output table --query "[?contains(name, 'node')].{NICname:name,InternalIP:ipConfigurations[0].privateIpAddress,InternalFQDN:dnsSettings.internalFqdn}"

    Na lista de nós devolvidos, localize o FQDN para os nós principais e utilize os FQDNs para ligar ao Ambari e a outros serviços Web. Por exemplo, utilize http://<headnode-fqdn>:8080 para aceder ao Ambari.

    Importante

    Alguns serviços alojados nos nós principais só estão ativos num nó de cada vez. Se tentar aceder a um serviço num nó principal e este devolver um erro 404, mude para o outro nó principal.

  2. Para determinar o nó e a porta em que um serviço está disponível, veja o documento Portas utilizadas pelos serviços do Hadoop no HDInsight .

Balanceamento de carga

Quando cria um cluster do HDInsight, também é criado um balanceador de carga. O tipo deste balanceador de carga está ao nível do SKU básico, que tem determinadas restrições. Uma destas restrições é que, se tiver duas redes virtuais em regiões diferentes, não poderá ligar a balanceadores de carga básicos. Veja FAQ sobre redes virtuais: restrições no peering de vnet global, para obter mais informações.

Outra restrição é que os balanceadores de carga do HDInsight não devem ser eliminados ou modificados. Quaisquer alterações às regras do balanceador de carga serão substituídas durante determinados eventos de manutenção, como renovações de certificados. Se os balanceadores de carga forem modificados e afetarem a funcionalidade do cluster, poderá ter de recriar o cluster.

Passos seguintes