Najlepsze praktyki dotyczące niestandardowego systemu DNS dla sieci wirtualnych obszaru roboczego Azure Databricks

Gdy wdrażasz przestrzeń roboczą Azure Databricks w swojej własnej sieci wirtualnej (VNet injection), możesz skonfigurować VNet tak, aby używał niestandardowych serwerów DNS zamiast DNS dostarczonego przez Azure. Niestandardowa konfiguracja DNS jest często stosowana, gdy przestrzeń robocza musi rozpoznawać nazwy hostów w środowisku lokalnym, korzystać ze scentralizowanego serwera przekazującego DNS w topologii hub-and-spoke lub stosować filtrowanie na poziomie DNS.

Własny DNS daje ci kontrolę nad rozwiązywaniem nazw, ale jednocześnie sprawia, że odpowiedzialność za rozwiązywanie nazw spoczywa na tobie. Jeśli twoje niestandardowe serwery DNS nie są w stanie rozwiązać nazw, których potrzebuje klasyczny komputer, klastry nie uruchamiają się i tracą łączność wychodzącą z zewnętrznymi źródłami danych i repozytoriami bibliotek. Ten artykuł opisuje zalecaną niestandardową konfigurację DNS dla przestrzeni roboczych wstrzykiwanych przez VNet, najczęstsze błędy konfiguracji oraz sposoby ich rozwiązywania problemów.

Note

Niestandardowy serwer DNS ma zastosowanie do klasycznej warstwy obliczeniowej w obszarze roboczym z iniekcją do sieci wirtualnej (VNet). Obliczenia bezserwerowe działają w sieci Azure Databricks i nie używają konfiguracji DNS Twojego VNet.

Jak Azure Databricks używa systemu DNS w obszarze roboczym wdrożonym w sieci wirtualnej (VNet)

Klasyczne węzły obliczeniowe działają w kontenerach (prywatnych) i hostowych (publicznych) podsieciach VNet. Podczas uruchamiania klastra i jego działania te węzły muszą prawidłowo rozpoznawać i uzyskiwać dostęp do kilku punktów końcowych usług Azure Databricks i Azure. Jeśli jest włączona bezpieczna łączność klastra (SCC), każdy klaster podczas tworzenia otwiera połączenie wychodzące do przekaźnika SCC w płaszczyźnie sterującej, dlatego rozwiązywanie nazw musi działać poprawnie, zanim klaster będzie mógł zostać uruchomiony.

Punkty końcowe, od których zależy klasyczne obliczenie, obejmują:

Punkt końcowy Jak się tam dostać
Płaszczyzna sterowania i aplikacja internetowa usługi Azure Databricks Regionalne zakresy IP, reprezentowane przez AzureDatabricks tag usługi
Przekaźnik bezpiecznej łączności klastrowej (SCC) W pełni kwalifikowana nazwa domenowa (FQDN) tunnel.<region>.azuredatabricks.net
Metastore Legacy Hive consolidated-<region>-prod-metastore.mysql.database.azure.com
Pamięć masowa w obszarze roboczym (DBFS) Punkty końcowe dfs i blob konta magazynu obszaru roboczego
Przechowywanie artefaktów i logów Blob dbartifactsprod<region>.blob.core.windows.net, dblogprod<region>.blob.core.windows.net
Event Hubs (logowanie) prod-<region>-observabilityeventhubs.servicebus.windows.net
Zewnętrzne źródła danych i repozytoria biblioteczne Publiczne nazwy DNS, takie jak repozytoria PyPI, Maven i CRAN

Klasyczne obliczenia docierają do płaszczyzny sterowania i aplikacji webowej przez regionalne zakresy IP, a nie przez nazwę hosta skierowaną do klienta, dlatego Azure Databricks zaleca dopuszczanie ich do listy z tagiem AzureDatabricks serwisowym w tabelach tras, grupach bezpieczeństwa sieciowego lub firewallu. Niektóre zapory, takie jak Palo Alto, nie mogą obsługiwać tagów usług platformy Azure. W takich przypadkach zamiast tego dodaj do listy dozwolonych bazowe zakresy adresów IP z listy referencyjnej.

Oznaczenie serwisowe AzureDatabricks już obejmuje przekaźnik SCC. Jeśli zamiast tagu usługi dodajesz do listy dozwolonych konkretne adresy IP, dodaj do niej przekaźnik SCC przy użyciu jego nazwy FQDN, ponieważ stojące za nim adresy IP ulegają zmianie. Niektóre regiony przechodzą do regionu drugorzędnego, więc lista referencyjna może pokazywać więcej niż jeden tunnel FQDN dla danego regionu. Dodaj je wszystkie do listy dozwolonych. Metastore, storage i Event Hubs należą do innych usług Azure z własnymi tagami usług, takimi jak Sql, Storage, i EventHub. Pełną listę adresów i FQDN dla regionów można znaleźć w Metastore, pamięć artefaktów Blob, pamięć tabel systemowych, pamięć logów Blob oraz adresy IP punktów końcowych Event Hubs.

Twoje niestandardowe serwery DNS nie muszą samodzielnie rozpoznawać wszystkich nazw platformy Azure i nazw publicznych. Zalecany wzorzec polega na rozwiązywaniu własnych nazw i przekazywaniu wszystkiego pozostałego do platformy Azure.

Przekazuj nierozstrzygnięte zapytania do usługi Azure DNS

Konfiguruj własne serwery DNS tak, aby warunkowo przekazywały nazwy, których nie potrafią rozwiązać, do resolvera DNS dostarczonego przez Azure na wirtualnym adresie 168.63.129.16IP. Azure DNS rozpoznaje za Ciebie nazwy płaszczyzny sterowania Azure Databricks, magazynu, metastore i innych usług platformy Azure oraz nadal działa, nawet gdy te adresy się zmieniają.

Ważna

Nie zastępuj całkowicie DNS dostarczonego przez Azure bez warunkowego przekierowania. Jeśli twoje niestandardowe serwery DNS staną się autorytatywne dla domen Azure lub Azure Databricks i nie przekierują zapytań, na które nie mogą odpowiedzieć, rozwiązanie wymaganych punktów końcowych zawodzi, a klastry nie mogą się uruchomić.

Co najmniej warunkowo przekieruj następujące domeny do Azure DNS oraz przekieruj wszystkie domeny pamięci masowej i usług Azure, z których korzystają Twoje obciążenia:

  • *.azuredatabricks.net
  • *.privatelink.azuredatabricks.net
  • *.databricksapps.com

Jeśli Twój obszar roboczy używa usługi Azure Private Link do połączenia z klasyczną warstwą obliczeniową, rozwiązywanie nazw musi zwracać prywatne adresy IP punktów końcowych, a nie adresy publiczne. Azure tworzy prywatną strefę DNS privatelink.azuredatabricks.net i dodaje rekordy adresowe dla punktów końcowych obszaru roboczego, w tym punkt końcowy databricks_ui_api oraz punkt końcowy browser_authentication używany na potrzeby logowania jednokrotnego. Rekord uwierzytelniania przeglądarki używa formatu pl-auth.<region>.

Gdy przestrzeń robocza używa niestandardowego DNS, jego klasyczne węzły obliczeniowe wysyłają zapytania DNS do Twoich niestandardowych serwerów DNS zamiast do Azure DNS. Prywatna strefa DNS połączona z siecią VNet jest odpytywana wyłącznie za pośrednictwem resolwera udostępnianego przez platformę Azure pod adresem 168.63.129.16, więc samo połączenie tej strefy nie spowoduje zwracania adresów prywatnego punktu końcowego do zasobu obliczeniowego, który wysyła zapytania do niestandardowego resolwera. Oba te wymagania są wymagane:

  • Połącz prywatną strefę DNS privatelink.azuredatabricks.net z siecią wirtualną (VNet), w której usługa Azure DNS rozpoznaje to zapytanie: z siecią wirtualną obszaru roboczego lub z siecią wirtualną huba, w której znajduje się resolver, w topologii typu hub-and-spoke. Daje to Azure DNS prywatne rekordy adresów końcowych do zwracania.
  • Skonfiguruj niestandardowe serwery DNS tak, aby warunkowo przekazywały dalej *.privatelink.azuredatabricks.net i *.azuredatabricks.net do usługi Azure DNS pod adresem 168.63.129.16. Przekierowanie to właśnie wysyła zapytanie do powiązanej prywatnej strefy DNS. W topologii hub-and-spoke można przekierować do centralnego resolvera, który dociera do Azure DNS.

Jeśli prywatna strefa DNS nie jest połączona lub jest połączona, ale brakuje rekordu adresu dla punktu końcowego, Azure DNS wraca do publicznej rekurencji i zwraca publiczny adres IP punktu końcowego. Rozwiązywanie nazw wydaje się działać poprawnie, ale ruch trafia do publicznego punktu końcowego zamiast do prywatnego punktu końcowego. Potwierdź, że połączona strefa zawiera oczekiwane rekordy adresowe dla każdego prywatnego punktu końcowego, z którego korzysta przestrzeń robocza.

Inne prywatne endpointy Azure, takie jak storage, korzystają z własnych prywatnych stref DNS Azure, na przykład privatelink.dfs.core.windows.net oraz privatelink.blob.core.windows.net. Zastosuj ten sam wzór: połącz te strefy i warunkowo przekieruj odpowiadające im privatelink domeny do Azure DNS, aby powiązane strefy były konsultowane. Integracja DNS z prywatnymi punktami końcowymi ma kilka scenariuszy w zależności od konfiguracji. Szczegóły można znaleźć w artykule o integracji DNS z Azure Private Endpoint.

Aby uzyskać pełną konfigurację usługi Private Link dla warstwy front-end i back-end, zobacz Configure classic compute plane private connectivity to Azure Databricks i Configure inbound Private Link for workspaces.

Typowe niestandardowe błędy w konfiguracji DNS

Większość przypadków wsparcia dla niestandardowego DNS wynika z jednej z następujących nieprawidłowych konfiguracji:

  • Brak przekierowania do Azure DNS. Niestandardowe serwery DNS nie mogą rozpoznawać nazw płaszczyzny sterowania, magazynu ani metastore usługi Azure Databricks i nie przekazują zapytań do 168.63.129.16. Klastry nie uruchamiają się lub nie docierają do pamięci masowej i metastore po uruchomieniu.
  • Brakuje połączenia z prywatną strefą DNS, przekazywania dalej lub rekordów. Przestrzeń robocza korzysta z Private Link, ale VNet nie jest powiązany ze strefąprivatelink.azuredatabricks.net, nie przekierowuje do Azure DNS lub strefa powiązana nie ma poprawnego rekordu adresu dla punktu końcowego. Nazwy rozwiązują się na publiczne adresy IP, zły adres lub nic, więc łączność prywatna zawodzi.
  • Niestandardowe serwery DNS są niedostępne. Niestandardowe adresy serwerów DNS w VNet są błędne lub reguły sieciowe blokują dostęp do podsieci obliczeniowej, na przykład gdy workspace VNet nie jest powiązany z VNetem, który hostuje twoje niestandardowe serwery DNS. Wszystkie próby rozwiązywania nazw kończą się niepowodzeniem.
  • Lokalny resolver bez przekazywania do platformy Azure. Zapytania DNS kierują się do lokalnego resolvera, który rozwiązuje nazwy wewnętrzne, ale nie potrafi rozwiązać ani przekazać nazw Azure. Dodaj warunkowe przekierowanie dla domen Azure i Azure Databricks.
  • Zablokowane repozytoria biblioteczne. DNS rozwiązuje wymagane punkty końcowe Azure Databricks, ale nie repozytoria bibliotek publicznych, więc instalacje bibliotek z PyPI, Maven lub CRAN zawodzą.

Rozwiązywanie problemów z niestandardowym DNS

Jeśli klastry nie mogą się uruchomić lub stracą łączność, sprawdź rozdzielczość DNS z klastra.

  1. Utwórz klaster w obszarze roboczym. Jeśli klastra nie daje się uruchomić, a w dzienniku zdarzeń pojawia się błąd, taki jak Cluster terminated. Reason: Control Plane Request Failure, klaster nie może połączyć się z płaszczyzną sterowania, co często wskazuje na problem z rozpoznawaniem nazw.

  2. Z notatnika na działającym klastrze rozstrzygnij wymagany punkt końcowy, aby potwierdzić, że Twój niestandardowy DNS zwraca oczekiwany adres. W przypadku przestrzeni roboczej Private Link sprawdź, czy adres URL przestrzeni roboczej wskazuje na prywatny adres IP punktu końcowego, a nie na publiczny adres IP.

    %sh
nslookup adb-<workspace-id>.<n>.azuredatabricks.net
nslookup tunnel.<region>.azuredatabricks.net

    Jeśli klastry w ogóle nie mogą się uruchomić, na przykład z powodu problemu z Private Link w back-endzie, wykonuj te kontrole z maszyny wirtualnej Azure w publicznej podsieci przestrzeni roboczej VNet zamiast z notatnika.

  3. Jeśli rozwiązanie się nie powiodło lub zwrócił się niewłaściwy adres, sprawdź następujące informacje. Gdy klaster nie uruchamia się z powodu DNS, dziennik zdarzeń klastra nazywa nieudane sprawdzenie stanu sieci, pokazane w nawiasach:

    • Niestandardowe adresy serwerów DNS VNet są poprawne, a podsieci obliczeniowe mogą dotrzeć do tych serwerów (X_NHC_DNS_SERVER_UNREACHABLE).
    • Twoje niestandardowe serwery DNS warunkowo przekazują domeny Azure i Azure Databricks do usługi Azure DNS pod adresem 168.63.129.16 (X_NHC_MULTIPLE_COMPONENTS_DNS_ERROR, gdy nazwy płaszczyzny sterowania lub magazynu artefaktów nie są rozpoznawane).
    • W przypadku usługi Private Link strefa privatelink.azuredatabricks.net jest połączona z siecią wirtualną (VNet), w której Azure DNS rozpoznaje nazwy, niestandardowe serwery DNS przekazują zapytania dotyczące domen Azure Databricks do usługi Azure DNS, a oczekiwane rekordy adresowe istnieją (X_NHC_CONTROL_PLANE_HTTP_ERROR, gdy prywatny punkt końcowy płaszczyzny sterowania nie jest rozpoznawany).

  4. Jeśli klastry uruchamiają się, ale nie mogą uzyskać dostępu do zasobów lokalnych lub innych zasobów platformy Azure jako usługi (PaaS), potwierdź, że dla tych lokalizacji docelowych istnieją trasy zdefiniowane przez użytkownika, ponieważ trasowanie i DNS są konfigurowane oddzielnie.

Jeśli nadal nie możesz rozwiązać problemu, skontaktuj się z zespołami kont Microsoft i Azure Databricks.

Dodatkowe zasoby

  • Ostatnia aktualizacja o