Condividi tramite

Pianificare una rete virtuale per Azure HDInsight

  • Articolo

Questo articolo fornisce informazioni di base sull'uso di Azure Rete virtuale (VNet) con Azure HDInsight. Vengono inoltre illustrate le decisioni di progettazione e implementazione da prendere prima di poter implementare una rete virtuale per il cluster HDInsight. Al termine della fase di pianificazione, è possibile passare a Creare reti virtuali per i cluster Azure HDInsight. Per altre informazioni sugli indirizzi IP di gestione di HDInsight necessari per configurare correttamente i gruppi di sicurezza di rete e le route definite dall'utente, vedere Indirizzi IP di gestione di HDInsight.

Il servizio Rete virtuale di Azure consente di implementare gli scenari seguenti:

  • Connessione a HDInsight direttamente da una rete locale.
  • Connessione di HDInsight ad archivi dati in una rete virtuale di Azure.
  • Accesso diretto ai servizi Apache Hadoop non disponibili pubblicamente tramite Internet. ad esempio le API Apache Kafka o l'API Java Apache HBase.

Importante

La creazione di un cluster HDInsight in una rete virtuale creerà diverse risorse di rete, ad esempio schede di interfaccia di rete e servizi di bilanciamento del carico. Non eliminare o modificare queste risorse di rete, perché sono necessarie affinché il cluster funzioni correttamente con la rete virtuale.

Pianificazione

Di seguito sono elencate le domande che è necessario porsi quando si intende installare HDInsight in una rete virtuale:

  • Occorre installare HDInsight in una rete virtuale esistente? Oppure si intende creare una rete nuova?

    Se si usa una rete virtuale esistente, potrebbe essere necessario modificare la configurazione di rete prima di poter installare HDInsight. Per altre informazioni, vedere la sezione aggiunta di HDInsight a una rete virtuale esistente.

  • La rete virtuale che contiene HDInsight deve essere connessa a un'altra rete virtuale o alla rete locale?

    Per usare facilmente le risorse tra più reti, potrebbe essere necessario creare un DNS personalizzato e configurare l'inoltro DNS. Per altre informazioni, vedere la sezione Connessione a più reti.

  • Si vuole limitare/reindirizzare il traffico in ingresso o in uscita a HDInsight?

    HDInsight deve disporre di una comunicazione senza restrizioni con indirizzi IP specifici nel data center di Azure. Sono presenti anche diverse porte che devono essere abilitate attraverso i firewall per la comunicazione client. Per altre informazioni, vedere Controllare il traffico di rete.

Aggiungere HDInsight a una rete virtuale esistente

Seguire la procedura in questa sezione per aggiungere un nuovo cluster HDInsight a una rete virtuale di Azure esistente.

Nota

  • È possibile aggiungere un cluster HDInsight esistente in una rete virtuale.
  • La rete virtuale e il cluster da creare devono trovarsi nella stessa sottoscrizione.

  1. Si intende usare un modello di distribuzione classico o di Resource Manager per la rete virtuale?

    HDInsight 3.4 e versione successiva richiedono l'utilizzo di una rete virtuale di Resource Manager. Le versioni precedenti di HDInsight richiedono una rete virtuale classica.

    Se la rete virtuale esistente è un modello classico, è necessario creare una rete virtuale di Resource Manager e successivamente connettere le due reti. Connessione di reti virtuali classiche a reti virtuali nuove.

    Dopo che le due reti sono state unite, HDInsight installato nella rete di Resource Manager può interagire con le risorse della rete classica.

  2. Si usano gruppi di sicurezza di rete, route definite dall'utente o appliance di rete virtuali per limitare il traffico all'interno o all'esterno della rete virtuale?

    In qualità di servizio gestito, HDInsight richiede l'accesso senza restrizioni a vari indirizzi IP nel data center di Azure. Per consentire la comunicazione con questi indirizzi IP, aggiornare tutti i gruppi di sicurezza di rete o le route definite dall'utente esistenti.

    HDInsight ospita più servizi, che usano diverse porte. Non bloccare il traffico verso queste porte. Per un elenco di porte da abilitare attraverso i firewall dell'appliance virtuale, vedere la sezione Sicurezza.

    Per trovare la configurazione di sicurezza esistente, usare i comandi di Azure PowerShell o dell'interfaccia della riga di comando di Azure che seguono:

    • Gruppi di sicurezza di rete

      Sostituire RESOURCEGROUP con il nome del gruppo di risorse che contiene la rete virtuale e quindi immettere il comando:

      Get-AzNetworkSecurityGroup -ResourceGroupName  "RESOURCEGROUP"

      az network nsg list --resource-group RESOURCEGROUP

      Per altre informazioni, vedere Risolvere i problemi relativi ai gruppi di sicurezza di rete.

      Importante

      Le regole di gruppo di sicurezza di rete vengono applicate seguendo un ordine basato sulla priorità delle regole. Viene applicata la prima regola che corrisponde al modello di traffico, dopodiché non vengono applicate altre regole per quel traffico. Ordinare le regole dalla più permissiva alla più restrittiva. Per altre informazioni, vedere il documento Filtrare il traffico di rete con gruppi di sicurezza di rete.

    • Percorsi definiti dall'utente

      Sostituire RESOURCEGROUP con il nome del gruppo di risorse che contiene la rete virtuale e quindi immettere il comando:

      Get-AzRouteTable -ResourceGroupName "RESOURCEGROUP"

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

      Per altre informazioni, vedere il documento Diagnosticare un problema di routing di una macchina virtuale.

  3. Creare un cluster HDInsight e selezionare l'Rete virtuale di Azure durante la configurazione. Per comprendere il processo di creazione del cluster, attenersi alla procedura nei documenti seguenti:

    Importante

    L'aggiunta di un cluster HDInsight a una rete virtuale è un passaggio di configurazione facoltativo. Assicurarsi di selezionare la rete virtuale quando si configura il cluster.

Connessione a più reti

Il problema più grande con una configurazione con più reti è la risoluzione dei nomi tra le reti.

Azure assicura la risoluzione dei nomi per i servizi di Azure che vengono installati in una rete virtuale. La risoluzione dei nomi integrata consente a HDInsight di connettersi alle risorse seguenti usando un nome di dominio completo (FQDN):

  • Qualsiasi risorsa disponibile in Internet, ad esempio microsoft.com o windowsupdate.com.

  • Qualsiasi risorsa che si trovi nella stessa rete virtuale di Azure tramite l'utilizzo del nome DNS interno della risorsa. Ad esempio, quando si usa la risoluzione dei nomi predefinita, di seguito sono riportati esempi di nomi DNS interni assegnati ai nodi di lavoro HDInsight:

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

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

      Entrambi questi nodi possono comunicare direttamente tra loro e con altri nodi in HDInsight, usando i nomi DNS interni.

La risoluzione dei nomi predefinita non consente a HDInsight di risolvere i nomi di risorse in reti che sono aggiunte alla rete virtuale. Ad esempio, è comune aggiungere la rete locale alla rete virtuale. Con solo la risoluzione dei nomi predefinita, HDInsight non può accedere alle risorse nella rete locale in base al nome. L'opposto è anche vero, le risorse nella rete locale non possono accedere alle risorse nella rete virtuale in base al nome.

Avviso

È necessario creare il server DNS personalizzato e configurare la rete virtuale per il suo utilizzo prima di creare il cluster HDInsight.

Per abilitare la risoluzione dei nomi tra la rete virtuale e le risorse in reti aggiunte, è necessario eseguire le azioni seguenti:

  1. Creare un server DNS personalizzato nella rete virtuale di Azure in cui si intende installare HDInsight.

  2. Configurare la rete virtuale per l'utilizzo del server DNS personalizzato.

  3. Trovare il suffisso DNS assegnato da Azure per la rete virtuale. Questo valore è simile a 0owcbllr5hze3hxdja3mqlrhhe.ex.internal.cloudapp.net. Per informazioni sulla ricerca del suffisso DNS, vedere la sezione Esempio: DNS personalizzato.

  4. Configurare l'inoltro tra i server DNS. La configurazione dipende dal tipo di rete remota.

    • Se la rete remota è una rete locale, configurare il DNS come indicato di seguito:

      • DNS personalizzato (nella rete virtuale):

        • Inoltrare le richieste per il suffisso DNS della rete virtuale al sistema di risoluzione ricorsiva di Azure (168.63.129.16). Azure gestisce le richieste per le risorse nella rete virtuale

        • Inoltrare tutte le altre richieste al server DNS locale. Il server DNS locale gestisce tutte le altre richieste di risoluzione dei nomi, persino le richieste per le risorse Internet quali Microsoft.com.

      • DNS locale: inoltrare le richieste per il suffisso DNS di rete virtuale al server DNS personalizzato. Il server DNS personalizzato le inoltra quindi al sistema di risoluzione ricorsiva di Azure.

        Questa configurazione indirizza le richieste di nomi di dominio completi che contengono il suffisso DNS della rete virtuale al server DNS personalizzato. Tutte le altre richieste (anche per gli indirizzi Internet pubblici) vengono gestite dal server DNS locale.

    • Se la rete remota è un'altra rete virtuale di Azure, configurare il DNS come indicato di seguito:

      • DNS personalizzato (in ogni rete virtuale):

        • Le richieste per il suffisso DNS delle reti virtuali vengono inoltrate ai server DNS personalizzati. Il DNS in ogni rete virtuale è responsabile della risoluzione delle risorse all'interno della propria rete.

        • Inoltrare tutte le altre richieste al sistema di risoluzione ricorsiva di Azure. Il sistema di risoluzione ricorsiva è responsabile della risoluzione delle risorse Internet e locali.

        Il server DNS per ogni rete inoltra le richieste all'altro, in base al suffisso DNS. Le altre richieste vengono risolte usando il sistema di risoluzione ricorsiva di Azure.

      Per un esempio di ogni configurazione, vedere la sezione Esempio: DNS personalizzato.

Per altre informazioni, vedere il documento Risoluzione dei nomi per le macchine virtuali e le istanze del ruolo.

Connettersi direttamente ai servizi Apache Hadoop

È possibile connettersi al cluster all'indirizzo https://CLUSTERNAME.azurehdinsight.net. Questo indirizzo usa un IP pubblico, che potrebbe non essere accessibile se sono stati usati gruppi di sicurezza di rete per limitare il traffico in ingresso da Internet. Inoltre, quando si distribuisce il cluster in una rete virtuale, è possibile accedervi usando l'endpoint https://CLUSTERNAME-int.azurehdinsight.netprivato . Questo endpoint viene risolto in un indirizzo IP privato all'interno della rete virtuale per l'accesso al cluster.

Per connettersi alle pagine Apache Ambari e ad altre pagine Web tramite la rete virtuale, seguire questa procedura:

  1. Per individuare i nomi di dominio completi (FQDN) interni dei nodi del cluster HDInsight, usare uno dei modi seguenti:

    Sostituire RESOURCEGROUP con il nome del gruppo di risorse che contiene la rete virtuale e quindi immettere il 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}"

    Nell'elenco di nodi restituito, trovare i nomi di dominio completi dei nodi head e usarli per connettersi ad Ambari e altri servizi Web. Usare ad esempio http://<headnode-fqdn>:8080 per accedere ad Ambari.

    Importante

    Alcuni servizi ospitati nei nodi head sono attivi solo in un nodo alla volta. Se nel tentativo di accedere a un servizio in un nodo head si riceve un messaggio di errore 404, passare al nodo head successivo.

  2. Per determinare il nodo e la porta su cui un servizio è disponibile, vedere il documento Porte usate dai servizi Hadoop su HDInsight.

Bilanciamento del carico

Quando si crea un cluster HDInsight, vengono creati anche diversi servizi di bilanciamento del carico. A causa del ritiro del servizio di bilanciamento del carico di base, il tipo di servizi di bilanciamento del carico è a livello di SKU standard, con determinati vincoli. I flussi in ingresso ai servizi di bilanciamento del carico standard vengono chiusi a meno che non sia consentito da un gruppo di sicurezza di rete. Potrebbe essere necessario collegare una sicurezza di rete alla subnet e configurare le regole di sicurezza di rete.

Esistono diversi metodi di connettività in uscita abilitati per il servizio di bilanciamento del carico standard. Vale la pena notare che l'accesso in uscita predefinito verrà ritirato a breve. Se viene adottato un gateway NAT per fornire l'accesso alla rete in uscita, la subnet non è in grado di usare il servizio di bilanciamento del carico di base. Se si intende legare un gateway NAT a una subnet, non dovrebbe esistere alcun servizio di bilanciamento del carico di base in questa subnet. Con il gateway NAT come metodo di accesso in uscita, un cluster HDInsight appena creato non può condividere la stessa subnet con cluster HDInsight creati in precedenza con i servizi di bilanciamento del carico di base.

Un altro vincolo è che i servizi di bilanciamento del carico HDInsight non devono essere eliminati o modificati. Eventuali modifiche alle regole del servizio di bilanciamento del carico verranno sovrascritte durante determinati eventi di manutenzione, ad esempio i rinnovi dei certificati. Se i servizi di bilanciamento del carico vengono modificati e influiscono sulla funzionalità del cluster, potrebbe essere necessario ricreare il cluster.

Passaggi successivi