Udostępnij za pośrednictwem


Planowanie sieci wirtualnej dla usługi Azure HDInsight

Ten artykuł zawiera podstawowe informacje na temat korzystania z sieci wirtualnych platformy Azure w usłudze Azure HDInsight. Omówiono również decyzje projektowe i wdrożeniowe, które należy podjąć przed wdrożeniem sieci wirtualnej dla klastra usługi HDInsight. Po zakończeniu fazy planowania możesz przejść do sekcji Tworzenie sieci wirtualnych dla klastrów usługi Azure HDInsight. Aby uzyskać więcej informacji na temat adresów IP zarządzania usługą HDInsight, które są potrzebne do prawidłowego konfigurowania sieciowych grup zabezpieczeń i tras zdefiniowanych przez użytkownika, zobacz adresy IP zarządzania usługą HDInsight.

Korzystanie z usługi Azure Virtual Network umożliwia wykonanie następujących scenariuszy:

  • Nawiązywanie połączenia z usługą HDInsight bezpośrednio z sieci lokalnej.
  • Łączenie usługi HDInsight z magazynami danych w sieci wirtualnej platformy Azure.
  • Bezpośredni dostęp do usług Apache Hadoop, które nie są dostępne publicznie za pośrednictwem Internetu. Na przykład interfejsy API platformy Apache Kafka lub interfejs API języka Java bazy danych Apache HBase.

Ważne

Utworzenie klastra usługi HDInsight w sieci wirtualnej spowoduje utworzenie kilku zasobów sieciowych, takich jak karty sieciowe i moduły równoważenia obciążenia. Nie usuwaj ani nie modyfikuj tych zasobów sieciowych, ponieważ są one potrzebne do poprawnego działania klastra z siecią wirtualną.

Planowanie

Poniżej przedstawiono pytania, na które należy odpowiedzieć podczas planowania instalacji usługi HDInsight w sieci wirtualnej:

  • Czy musisz zainstalować usługę HDInsight w istniejącej sieci wirtualnej? Czy tworzysz nową sieć?

    Jeśli używasz istniejącej sieci wirtualnej, może być konieczne zmodyfikowanie konfiguracji sieci przed zainstalowaniem usługi HDInsight. Aby uzyskać więcej informacji, zobacz sekcję dodano usługę HDInsight do istniejącej sieci wirtualnej.

  • Czy chcesz połączyć sieć wirtualną zawierającą usługę HDInsight z inną siecią wirtualną lub siecią lokalną?

    Aby łatwo pracować z zasobami w sieciach, może być konieczne utworzenie niestandardowego systemu DNS i skonfigurowanie przekazywania DNS. Aby uzyskać więcej informacji, zobacz sekcję Łączenie wielu sieci .

  • Czy chcesz ograniczyć/przekierować ruch przychodzący lub wychodzący do usługi HDInsight?

    Usługa HDInsight musi mieć nieograniczoną komunikację z określonymi adresami IP w centrum danych platformy Azure. Istnieje również kilka portów, które muszą być dozwolone przez zapory dla komunikacji klienta. Aby uzyskać więcej informacji, zobacz Kontrolowanie ruchu sieciowego.

Dodawanie usługi HDInsight do istniejącej sieci wirtualnej

Wykonaj kroki opisane w tej sekcji, aby dowiedzieć się, jak dodać nową usługę HDInsight do istniejącej sieci wirtualnej platformy Azure.

Uwaga

  • Nie można dodać istniejącego klastra usługi HDInsight do sieci wirtualnej.
  • Sieć wirtualna i tworzony klaster muszą znajdować się w tej samej subskrypcji.
  1. Czy używasz klasycznego lub modelu wdrażania usługi Resource Manager dla sieci wirtualnej?

    Usługa HDInsight 3.4 lub nowsza wymaga sieci wirtualnej usługi Resource Manager. Wcześniejsze wersje usługi HDInsight wymagały klasycznej sieci wirtualnej.

    Jeśli istniejąca sieć jest klasyczną siecią wirtualną, musisz utworzyć sieć wirtualną usługi Resource Manager, a następnie połączyć te dwie sieci. Łączenie klasycznych sieci wirtualnych z nowymi sieciami wirtualnymi.

    Po dołączeniu usługa HDInsight zainstalowana w sieci usługi Resource Manager może wchodzić w interakcje z zasobami w sieci klasycznej.

  2. Czy używasz sieciowych grup zabezpieczeń, tras zdefiniowanych przez użytkownika lub wirtualnych urządzeń sieciowych w celu ograniczenia ruchu do lub z sieci wirtualnej?

    Jako usługa zarządzana usługa HDInsight wymaga nieograniczonego dostępu do kilku adresów IP w centrum danych platformy Azure. Aby umożliwić komunikację z tymi adresami IP, zaktualizuj wszystkie istniejące sieciowe grupy zabezpieczeń lub trasy zdefiniowane przez użytkownika.

    Usługa HDInsight hostuje wiele usług, które używają różnych portów. Nie blokuj ruchu do tych portów. Aby uzyskać listę portów umożliwiających korzystanie z zapór urządzeń wirtualnych, zobacz sekcję Zabezpieczenia.

    Aby znaleźć istniejącą konfigurację zabezpieczeń, użyj następujących poleceń programu Azure PowerShell lub interfejsu wiersza polecenia platformy Azure:

    • Sieciowe grupy zabezpieczeń

      Zastąp RESOURCEGROUP ciąg nazwą grupy zasobów, która zawiera sieć wirtualną, a następnie wprowadź polecenie:

      Get-AzNetworkSecurityGroup -ResourceGroupName  "RESOURCEGROUP"
      
      az network nsg list --resource-group RESOURCEGROUP
      

      Aby uzyskać więcej informacji, zobacz Dokument Rozwiązywanie problemów z sieciowych grup zabezpieczeń.

      Ważne

      Reguły sieciowej grupy zabezpieczeń są stosowane w kolejności na podstawie priorytetu reguły. Pierwsza reguła zgodna ze wzorcem ruchu jest stosowana, a dla tego ruchu nie są stosowane żadne inne. Reguły kolejności od większości permissive do najmniej permissive. Aby uzyskać więcej informacji, zobacz dokument Filtrowanie ruchu sieciowego za pomocą sieciowych grup zabezpieczeń.

    • Trasy zdefiniowane przez użytkownika

      Zastąp RESOURCEGROUP ciąg nazwą grupy zasobów, która zawiera sieć wirtualną, a następnie wprowadź polecenie:

      Get-AzRouteTable -ResourceGroupName "RESOURCEGROUP"
      
      az network route-table list --resource-group RESOURCEGROUP
      

      Aby uzyskać więcej informacji, zobacz dokument Diagnozowanie problemu z routingiem maszyny wirtualnej.

  3. Utwórz klaster usługi HDInsight i wybierz sieć wirtualną platformy Azure podczas konfiguracji. Wykonaj kroki opisane w poniższych dokumentach, aby zrozumieć proces tworzenia klastra:

    Ważne

    Dodawanie usługi HDInsight do sieci wirtualnej jest opcjonalnym krokiem konfiguracji. Pamiętaj, aby wybrać sieć wirtualną podczas konfigurowania klastra.

Łączenie wielu sieci

Największym wyzwaniem z konfiguracją z wieloma sieciami jest rozpoznawanie nazw między sieciami.

Platforma Azure udostępnia rozpoznawanie nazw dla usług platformy Azure zainstalowanych w sieci wirtualnej. To wbudowane rozpoznawanie nazw umożliwia usłudze HDInsight łączenie się z następującymi zasobami przy użyciu w pełni kwalifikowanej nazwy domeny (FQDN):

  • Każdy zasób dostępny w Internecie. Na przykład microsoft.com, windowsupdate.com.

  • Każdy zasób, który znajduje się w tej samej sieci wirtualnej platformy Azure, przy użyciu wewnętrznej nazwy DNS zasobu. Na przykład w przypadku korzystania z domyślnego rozpoznawania nazw poniżej przedstawiono przykłady wewnętrznych nazw DNS przypisanych do węzłów procesu roboczego usługi HDInsight:

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

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

      Oba te węzły mogą komunikować się bezpośrednio ze sobą i z innymi węzłami w usłudze HDInsight przy użyciu wewnętrznych nazw DNS.

Domyślne rozpoznawanie nazw nie zezwala usłudze HDInsight na rozpoznawanie nazw zasobów w sieciach, które są przyłączone do sieci wirtualnej. Na przykład często dołączanie sieci lokalnej do sieci wirtualnej. Przy użyciu tylko domyślnego rozpoznawania nazw usługa HDInsight nie może uzyskać dostępu do zasobów w sieci lokalnej według nazwy. Odwrotnie jest również prawdą, zasoby w sieci lokalnej nie mogą uzyskiwać dostępu do zasobów w sieci wirtualnej według nazwy.

Ostrzeżenie

Przed utworzeniem klastra usługi HDInsight należy utworzyć niestandardowy serwer DNS i skonfigurować sieć wirtualną.

Aby włączyć rozpoznawanie nazw między siecią wirtualną a zasobami w połączonych sieciach, należy wykonać następujące czynności:

  1. Utwórz niestandardowy serwer DNS w usłudze Azure Virtual Network, w której planujesz zainstalować usługę HDInsight.

  2. Skonfiguruj sieć wirtualną tak, aby korzystała z niestandardowego serwera DNS.

  3. Znajdź sufiks DNS przypisany przez platformę Azure dla sieci wirtualnej. Ta wartość jest podobna do 0owcbllr5hze3hxdja3mqlrhhe.ex.internal.cloudapp.net. Aby uzyskać informacje na temat znajdowania sufiksu DNS, zobacz sekcję Przykład: niestandardowy system DNS .

  4. Skonfiguruj przekazywanie między serwerami DNS. Konfiguracja zależy od typu sieci zdalnej.

    • Jeśli sieć zdalna jest siecią lokalną, skonfiguruj system DNS w następujący sposób:

      • Niestandardowy system DNS (w sieci wirtualnej):

        • Przesyłanie dalej żądań sufiksu DNS sieci wirtualnej do rekursywnego rozpoznawania nazw platformy Azure (168.63.129.16). Platforma Azure obsługuje żądania dotyczące zasobów w sieci wirtualnej

        • Przekaż wszystkie pozostałe żądania do lokalnego serwera DNS. Lokalna usługa DNS obsługuje wszystkie inne żądania rozpoznawania nazw, nawet żądania dotyczące zasobów internetowych, takich jak Microsoft.com.

      • Lokalny system DNS: przekazywanie żądań sufiksu DNS sieci wirtualnej do niestandardowego serwera DNS. Następnie niestandardowy serwer DNS przekazuje do modułu rozpoznawania cyklicznego platformy Azure.

        Ta konfiguracja kieruje żądania dla w pełni kwalifikowanych nazw domen, które zawierają sufiks DNS sieci wirtualnej do niestandardowego serwera DNS. Wszystkie inne żądania (nawet w przypadku publicznych adresów internetowych) są obsługiwane przez lokalny serwer DNS.

    • Jeśli sieć zdalna jest inną siecią wirtualną platformy Azure, skonfiguruj usługę DNS w następujący sposób:

      • Niestandardowy system DNS (w każdej sieci wirtualnej):

        • Żądania sufiksu DNS sieci wirtualnych są przekazywane do niestandardowych serwerów DNS. System DNS w każdej sieci wirtualnej jest odpowiedzialny za rozpoznawanie zasobów w sieci.

        • Prześlij dalej wszystkie inne żądania do programu rozpoznawania cyklicznego platformy Azure. Rekursywny program rozpoznawania jest odpowiedzialny za rozpoznawanie zasobów lokalnych i internetowych.

        Serwer DNS dla każdej sieci przekazuje żądania do drugiej na podstawie sufiksu DNS. Inne żądania są rozwiązywane przy użyciu narzędzia rozpoznawania cyklicznego platformy Azure.

      Przykład każdej konfiguracji można znaleźć w sekcji Przykład: niestandardowy system DNS .

Aby uzyskać więcej informacji, zobacz dokument Rozpoznawanie nazw dla maszyn wirtualnych i wystąpień ról.

Bezpośrednie nawiązywanie połączenia z usługami Apache Hadoop

Możesz nawiązać połączenie z klastrem pod adresem https://CLUSTERNAME.azurehdinsight.net. Ten adres używa publicznego adresu IP, który może nie być dostępny, jeśli do ograniczenia ruchu przychodzącego z Internetu użyto sieciowych grup zabezpieczeń. Ponadto podczas wdrażania klastra w sieci wirtualnej można uzyskać do niego dostęp przy użyciu prywatnego punktu końcowego https://CLUSTERNAME-int.azurehdinsight.net. Ten punkt końcowy jest rozpoznawany jako prywatny adres IP wewnątrz sieci wirtualnej na potrzeby dostępu do klastra.

Aby nawiązać połączenie z usługą Apache Ambari i innymi stronami internetowymi za pośrednictwem sieci wirtualnej, wykonaj następujące kroki:

  1. Aby odnaleźć wewnętrzne w pełni kwalifikowane nazwy domen (FQDN) węzłów klastra usługi HDInsight, użyj jednej z następujących metod:

    Zastąp RESOURCEGROUP ciąg nazwą grupy zasobów, która zawiera sieć wirtualną, a następnie wprowadź polecenie:

    $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 liście zwróconych węzłów znajdź nazwę FQDN węzłów głównych i użyj nazw FQDN do nawiązania połączenia z usługą Ambari i innymi usługami sieci Web. Na przykład użyj polecenia http://<headnode-fqdn>:8080 , aby uzyskać dostęp do systemu Ambari.

    Ważne

    Niektóre usługi hostowane w węzłach głównych są aktywne tylko w jednym węźle jednocześnie. Jeśli spróbujesz uzyskać dostęp do usługi w jednym węźle głównym i zwróci błąd 404, przełącz się do drugiego węzła głównego.

  2. Aby określić węzeł i port, w ramach którego jest dostępna usługa, zobacz dokument Porty używane przez usługi Hadoop w usłudze HDInsight .

Równoważenie obciążenia

Podczas tworzenia klastra usługi HDInsight tworzone jest również kilka modułów równoważenia obciążenia. Ze względu na wycofanie podstawowego modułu równoważenia obciążenia typ modułu równoważenia obciążenia jest na poziomie standardowej jednostki SKU, który ma pewne ograniczenia. Przepływy przychodzące do standardowych modułów równoważenia obciążenia są zamykane, chyba że jest to dozwolone przez sieciową grupę zabezpieczeń. Może być konieczne wiązanie zabezpieczeń sieci z podsiecią i skonfigurowanie reguł zabezpieczeń sieci.

Dla standardowego modułu równoważenia obciążenia włączono kilka metod łączności wychodzącej. Warto zauważyć, że domyślny dostęp wychodzący zostanie wkrótce wycofany. Jeśli brama translatora adresów sieciowych zostanie przyjęta w celu zapewnienia dostępu do sieci wychodzącej, podsieć nie może korzystać z podstawowego modułu równoważenia obciążenia. Jeśli zamierzasz połączyć bramę translatora adresów sieciowych z podsiecią, w tej podsieci nie powinno istnieć żadne podstawowe moduły równoważenia obciążenia. W przypadku bramy translatora adresów sieciowych jako metody dostępu wychodzącego nowo utworzony klaster usługi HDInsight nie może współużytkować tej samej podsieci z wcześniej utworzonymi klastrami usługi HDInsight z podstawowymi modułami równoważenia obciążenia.

Innym ograniczeniem jest to, że moduły równoważenia obciążenia usługi HDInsight nie powinny być usuwane ani modyfikowane. Wszelkie zmiany reguł modułu równoważenia obciążenia zostaną zastąpione podczas niektórych zdarzeń konserwacji, takich jak odnawianie certyfikatów. Jeśli moduły równoważenia obciążenia są modyfikowane i wpływają na funkcjonalność klastra, może być konieczne ponowne utworzenie klastra.

Następne kroki