Wdrażanie usługi Azure Databricks w sieci wirtualnej platformy Azure (iniekcja sieci wirtualnej)
Domyślne wdrożenie usługi Azure Databricks to w pełni zarządzana usługa na platformie Azure: wszystkie klasyczne zasoby płaszczyzny obliczeniowej, w tym sieć wirtualna, z którą będą skojarzone wszystkie klastry, są wdrażane w zablokowanej grupie zasobów. Jeśli jednak potrzebujesz dostosowania sieci, możesz wdrożyć klasyczne zasoby płaszczyzny obliczeniowej usługi Azure Databricks we własnej sieci wirtualnej (czasami nazywane iniekcją sieci wirtualnej), co umożliwia:
- Połączenie usługi Azure Databricks do innych usług platformy Azure (takich jak Azure Storage) w sposób bardziej bezpieczny przy użyciu punktów końcowych usługi lub prywatnych punktów końcowych.
- Połączenie do lokalnych źródeł danych do użycia z usługą Azure Databricks, korzystając z tras zdefiniowanych przez użytkownika.
- Połączenie usługi Azure Databricks do wirtualnego urządzenia sieciowego w celu sprawdzenia całego ruchu wychodzącego i podjęcia akcji zgodnie z regułami zezwalania i odmowy przy użyciu tras zdefiniowanych przez użytkownika.
- Skonfiguruj usługę Azure Databricks do używania niestandardowego systemu DNS.
- Skonfiguruj reguły sieciowej grupy zabezpieczeń w celu określenia ograniczeń ruchu wychodzącego.
- Wdróż klastry usługi Azure Databricks w istniejącej sieci wirtualnej.
Wdrażanie klasycznych zasobów płaszczyzny obliczeniowej usługi Azure Databricks we własnej sieci wirtualnej umożliwia również korzystanie z elastycznych zakresów CIDR. W przypadku sieci wirtualnej można użyć rozmiaru /16-/24zakresu CIDR . W przypadku podsieci użyj zakresów adresów IP tak małych, jak /26. Mniejsze zakresy podsieci, takie jak /27 nie są obsługiwane.
Ważne
Nie można zastąpić sieci wirtualnej dla istniejącego obszaru roboczego. Jeśli bieżący obszar roboczy nie może zostać dostosowany do wymaganej liczby aktywnych węzłów klastra, zalecamy utworzenie kolejnego obszaru roboczego w większej sieci wirtualnej. Postępuj zgodnie z tymi szczegółowymi krokami migracji, aby skopiować zasoby (notesy, konfiguracje klastrów, zadania) ze starego obszaru roboczego do nowego.
Wymagania dotyczące sieci wirtualnej
Sieć wirtualna, w której wdrożono obszar roboczy usługi Azure Databricks, musi spełniać następujące wymagania:
Region: Sieć wirtualna musi znajdować się w tym samym regionie co obszar roboczy usługi Azure Databricks.
Subskrypcja: sieć wirtualna musi znajdować się w tej samej subskrypcji co obszar roboczy usługi Azure Databricks.
Przestrzeń adresowa: blok CIDR między
/16i/24dla sieci wirtualnej i bloku CIDR do/26dwóch podsieci: podsieci kontenera i podsieci hosta. Aby uzyskać wskazówki dotyczące maksymalnej liczby węzłów klastra na podstawie rozmiaru sieci wirtualnej i jej podsieci, zobacz Przestrzeń adresowa i maksymalne węzły klastra.Podsieci: Sieć wirtualna musi zawierać dwie podsieci dedykowane obszarowi roboczemu usługi Azure Databricks: podsieć kontenera (czasami nazywaną podsiecią prywatną) i podsiecią hosta (czasami nazywaną podsiecią publiczną). Jednak w przypadku obszaru roboczego korzystającego z bezpiecznej łączności klastra zarówno podsieć kontenera, jak i podsieć hosta są prywatne. Nie jest obsługiwane udostępnianie podsieci między obszarami roboczymi lub wdrażanie innych zasobów platformy Azure w podsieciach używanych przez obszar roboczy usługi Azure Databricks. Aby uzyskać wskazówki dotyczące maksymalnej liczby węzłów klastra na podstawie rozmiaru sieci wirtualnej i jej podsieci, zobacz Przestrzeń adresowa i maksymalne węzły klastra.
- Jeśli utworzysz obszar roboczy usługi Azure Databricks przy użyciu witryny Azure Portal, wybierz opcję używania istniejących podsieci w sieci wirtualnej lub utwórz dwie nowe podsieci określone przez nazwy i zakresy adresów IP.
- Jeśli używasz szablonu arm all-in-one lub szablonu arm tylko dla sieci wirtualnej, szablony tworzą podsieci. W obu przypadkach podsieci są delegowane do
Microsoft.Databricks/workspacesdostawcy zasobów przed wdrożeniem obszaru roboczego, co umożliwia usłudze Azure Databricks tworzenie reguł sieciowej grupy zabezpieczeń. Usługa Azure Databricks powiadomi z wyprzedzeniem o konieczności dodania lub zaktualizowania zakresu reguły sieciowej grupy zabezpieczeń zarządzanej przez usługę Azure Databricks. - Jeśli używasz szablonu arm obszaru roboczego lub niestandardowego szablonu usługi ARM, należy upewnić się, że dwie podsieci dla obszaru roboczego używają tej samej sieciowej grupy zabezpieczeń i są prawidłowo delegowane. Zobacz Dodawanie lub usuwanie delegowania podsieci.
Ważne
Istnieje relacja jeden do jednego między tymi podsieciami a obszarem roboczym usługi Azure Databricks. Nie można udostępniać wielu obszarów roboczych w jednej podsieci. Nie jest obsługiwane udostępnianie podsieci między obszarami roboczymi lub wdrażanie innych zasobów platformy Azure w podsieciach używanych przez obszar roboczy usługi Azure Databricks.
Aby uzyskać więcej informacji na temat szablonów do konfigurowania sieci wirtualnej i wdrażania obszaru roboczego, zobacz Szablony usługi Azure Resource Manager dostarczone przez usługę Azure Databricks.
Przestrzeń adresowa i maksymalne węzły klastra
Obszar roboczy z mniejszą siecią wirtualną może szybciej zabraknie adresów IP (przestrzeni sieciowej) niż obszar roboczy z większą siecią wirtualną. Użyj bloku CIDR między /16 i /24 dla sieci wirtualnej i bloku CIDR do /26 dwóch podsieci (podsieci kontenera i podsieci hosta).
Uwaga
Blok CIDR można utworzyć do /28 podsieci, jednak usługa Databricks nie zaleca podsieci mniejszej niż /26.
Zakres CIDR dla przestrzeni adresowej sieci wirtualnej ma wpływ na maksymalną liczbę węzłów klastra, których można użyć w obszarze roboczym:
- Obszar roboczy usługi Azure Databricks wymaga dwóch podsieci w sieci wirtualnej: podsieci kontenera (nazywanej również podsiecią prywatną) i podsiecią hosta (znaną również jako podsieć publiczna). Jeśli obszar roboczy korzysta z bezpiecznej łączności klastra, zarówno podsieci kontenera, jak i podsieci hostów są prywatne.
- Platforma Azure rezerwuje pięć adresów IP w każdej podsieci.
- W każdej podsieci usługa Azure Databricks wymaga jednego adresu IP na węzeł klastra. Łącznie istnieją dwa adresy IP dla każdego węzła klastra: jeden adres IP hosta w podsieci hosta i jeden adres IP kontenera w podsieci kontenera.
- Możesz nie chcieć używać całej przestrzeni adresowej sieci wirtualnej. Możesz na przykład utworzyć wiele obszarów roboczych w jednej sieci wirtualnej. Ponieważ nie można udostępniać podsieci między obszarami roboczymi, mogą być potrzebne podsieci, które nie korzystają z łącznej przestrzeni adresowej sieci wirtualnej.
- Należy przydzielić przestrzeń adresową dla dwóch nowych podsieci znajdujących się w przestrzeni adresowej sieci wirtualnej i nie nakładać się na przestrzeń adresową bieżących lub przyszłych podsieci w tej sieci wirtualnej.
W poniższej tabeli przedstawiono maksymalny rozmiar podsieci na podstawie rozmiaru sieci. W tej tabeli założono, że nie istnieją żadne dodatkowe podsieci, które zajmują przestrzeń adresową. Użyj mniejszych podsieci, jeśli masz wstępnie istniejące podsieci lub jeśli chcesz zarezerwować przestrzeń adresową dla innych podsieci:
| Przestrzeń adresowa sieci wirtualnej (CIDR) | Maksymalny rozmiar podsieci usługi Azure Databricks (CIDR) przy założeniu, że nie ma innych podsieci |
|---|---|
/16 |
/17 |
/17 |
/18 |
/18 |
/19 |
/20 |
/21 |
/21 |
/22 |
/22 |
/23 |
/23 |
/24 |
/24 |
/25 |
Aby znaleźć maksymalne węzły klastra na podstawie rozmiaru podsieci, użyj poniższej tabeli. Kolumna Adresy IP na podsieć zawiera pięć zarezerwowanych adresów IP platformy Azure. Kolumna po prawej stronie wskazuje liczbę węzłów klastra, które mogą być jednocześnie uruchamiane w obszarze roboczym aprowizacji z podsieciami tego rozmiaru.
| Rozmiar podsieci (CIDR) | Adresy IP na podsieć | Maksymalna liczba węzłów klastra usługi Azure Databricks |
|---|---|---|
/17 |
32768 | 32763 |
/18 |
16384 | 16379 |
/19 |
8192 | 8187 |
/20 |
4096 | 4091 |
/21 |
2048 | 2043 |
/22 |
1024 | 1019 |
/23 |
512 | 507 |
/24 |
256 | 251 |
/25 |
128 | 123 |
/26 |
64 | 59 |
Adresy IP ruchu wychodzącego podczas korzystania z bezpiecznej łączności klastra
Jeśli włączysz bezpieczną łączność klastra w obszarze roboczym korzystającym z iniekcji sieci wirtualnej, usługa Databricks zaleca, aby obszar roboczy miał stabilny publiczny adres IP ruchu wychodzącego.
Stabilne publiczne adresy IP ruchu wychodzącego są przydatne, ponieważ można je dodać do zewnętrznych list dozwolonych. Na przykład aby nawiązać połączenie z usługi Azure Databricks z usługą Salesforce przy użyciu stabilnego wychodzącego adresu IP.
Ostrzeżenie
Firma Microsoft ogłosiła, że 30 września 2025 r. zostanie wycofana domyślna łączność dostępu wychodzącego dla maszyn wirtualnych na platformie Azure. Zobacz to ogłoszenie. Oznacza to, że istniejące obszary robocze usługi Azure Databricks korzystające z domyślnego dostępu wychodzącego zamiast stabilnego publicznego adresu IP ruchu wychodzącego mogą nie nadal działać po tej dacie. Usługa Databricks zaleca dodanie jawnych metod ruchu wychodzącego dla obszarów roboczych przed tą datą.
Aby uzyskać informacje o opcjach implementacji, zobacz secure cluster connectivity (Bezpieczna łączność klastra)
Udostępnione zasoby i komunikacja równorzędna
Jeśli wymagane są udostępnione zasoby sieciowe, takie jak DNS, usługa Databricks zdecydowanie zaleca stosowanie najlepszych rozwiązań dotyczących platformy Azure dla modelu piasty i szprych. Użyj komunikacji równorzędnej sieci wirtualnych, aby rozszerzyć prywatną przestrzeń IP sieci wirtualnej obszaru roboczego na piastę przy jednoczesnym zachowaniu izolacji od siebie szprych.
Jeśli masz inne zasoby w sieci wirtualnej lub używasz komunikacji równorzędnej, usługa Databricks zdecydowanie zaleca dodanie reguł Odmowy do sieciowych grup zabezpieczeń dołączonych do innych sieci i podsieci, które znajdują się w tej samej sieci wirtualnej lub są połączone za pomocą komunikacji równorzędnej z tą siecią wirtualną. Dodaj reguły odmowy dla połączeń zarówno dla połączeń przychodzących, jak i wychodzących, aby ograniczyć połączenia zarówno do, jak i z zasobów obliczeniowych usługi Azure Databricks. Jeśli klaster potrzebuje dostępu do zasobów w sieci, dodaj reguły, aby zezwolić tylko na minimalną ilość dostępu wymaganą do spełnienia wymagań.
Aby uzyskać powiązane informacje, zobacz Reguły sieciowej grupy zabezpieczeń.
Tworzenie obszaru roboczego usługi Azure Databricks przy użyciu witryny Azure Portal
W tej sekcji opisano sposób tworzenia obszaru roboczego usługi Azure Databricks w witrynie Azure Portal i wdrażania go we własnej istniejącej sieci wirtualnej. Usługa Azure Databricks aktualizuje sieć wirtualną z dwiema nowymi podsieciami, jeśli jeszcze nie istnieją, używając określonych zakresów CIDR. Usługa aktualizuje również podsieci za pomocą nowej sieciowej grupy zabezpieczeń, konfigurowania reguł ruchu przychodzącego i wychodzącego, a na koniec wdraża obszar roboczy w zaktualizowanej sieci wirtualnej. Aby uzyskać większą kontrolę nad konfiguracją sieci wirtualnej, użyj szablonów usługi Azure Resource Manager (ARM) dostarczanych przez usługę Azure Databricks zamiast interfejsu użytkownika portalu. Na przykład użyj istniejących sieciowych grup zabezpieczeń lub utwórz własne reguły zabezpieczeń. Zobacz Konfiguracja zaawansowana przy użyciu szablonów usługi Azure Resource Manager.
Ważne
Użytkownik tworzący obszar roboczy musi mieć przypisaną rolę Współautor sieci do odpowiedniej sieci wirtualnej lub roli niestandardowej, która ma przypisane Microsoft.Network/virtualNetworks/subnets/join/action uprawnienia i Microsoft.Network/virtualNetworks/subnets/write .
Musisz skonfigurować sieć wirtualną, w której wdrożysz obszar roboczy usługi Azure Databricks. Możesz użyć istniejącej sieci wirtualnej lub utworzyć nową, ale sieć wirtualna musi znajdować się w tym samym regionie i tej samej subskrypcji co obszar roboczy usługi Azure Databricks, który ma zostać utworzony. Sieć wirtualna musi mieć rozmiar z zakresem CIDR z zakresu od /16 do /24. Aby uzyskać więcej wymagań, zobacz Wymagania dotyczące sieci wirtualnej.
Użyj istniejących podsieci lub określ nazwy i zakresy adresów IP dla nowych podsieci podczas konfigurowania obszaru roboczego.
W witrynie Azure Portal wybierz pozycję + Utwórz zasób > Analytics > w usłudze Azure Databricks lub wyszukaj usługę Azure Databricks, a następnie kliknij pozycję Utwórz lub + Dodaj , aby uruchomić okno dialogowe usługi Azure Databricks.
Wykonaj kroki konfiguracji opisane w przewodniku Szybki start Tworzenie obszaru roboczego usługi Azure Databricks we własnej sieci wirtualnej.
Na karcie Sieć wybierz sieć wirtualną, której chcesz użyć w polu Sieć wirtualna.
Ważne
Jeśli nazwa sieci nie jest widoczna w selektorze, upewnij się, że region świadczenia usługi Azure określony dla obszaru roboczego jest zgodny z regionem platformy Azure żądanej sieci wirtualnej.
Nazwij podsieci i podaj zakresy CIDR w bloku o maksymalnym rozmiarze
/26. Aby uzyskać wskazówki dotyczące maksymalnej liczby węzłów klastra na podstawie rozmiaru sieci wirtualnej i jej podsieci, zobacz Przestrzeń adresowa i maksymalne węzły klastra.
Ważne
Nie można zmienić zakresów CIDR podsieci po wdrożeniu obszaru roboczego.
- Aby określić istniejące podsieci, określ dokładne nazwy istniejących podsieci. W przypadku korzystania z istniejących podsieci ustaw również zakresy adresów IP w formularzu tworzenia obszaru roboczego, aby dokładnie odpowiadały zakresom adresów IP istniejących podsieci.
- Aby utworzyć nowe podsieci, określ nazwy podsieci, które jeszcze nie istnieją w tej sieci wirtualnej. Podsieci są tworzone z określonymi zakresami adresów IP. Należy określić zakresy adresów IP w zakresie adresów IP sieci wirtualnej i nie zostały jeszcze przydzielone do istniejących podsieci.
Ważne
Usługa Azure Databricks wymaga, aby nazwy podsieci nie przekraczały 80 znaków. Jest to krótsza niż maksymalna długość dozwolona dla podsieci w witrynie Azure Portal. Przed użyciem istniejącej podsieci zmień jej nazwę, jeśli jej nazwa jest dłuższa niż 80 znaków.
Podsieci uzyskują skojarzone reguły sieciowej grupy zabezpieczeń, które obejmują regułę zezwalającą na komunikację wewnętrzną klastra. Usługa Azure Databricks będzie mieć delegowane uprawnienia do aktualizowania obu podsieci za pośrednictwem Microsoft.Databricks/workspaces dostawcy zasobów. Te uprawnienia mają zastosowanie tylko do reguł sieciowej grupy zabezpieczeń, które są wymagane przez usługę Azure Databricks, a nie do innych reguł sieciowej grupy zabezpieczeń, które są dodawane lub do domyślnych reguł sieciowych grup zabezpieczeń dołączonych do wszystkich sieciowych grup zabezpieczeń.
Kliknij przycisk Utwórz , aby wdrożyć obszar roboczy usługi Azure Databricks w sieci wirtualnej.
Uwaga
Gdy wdrożenie obszaru roboczego zakończy się niepowodzeniem, obszar roboczy jest nadal tworzony, ale ma stan niepowodzenia. Usuń nieudanych obszarów roboczych i utwórz nowy obszar roboczy, który usuwa błędy wdrażania. Po usunięciu zakończonego niepowodzeniem obszaru roboczego zarządzana grupa zasobów i wszystkie pomyślnie wdrożone zasoby również zostaną usunięte.
Zaawansowana konfiguracja przy użyciu szablonów usługi Azure Resource Manager
Aby uzyskać większą kontrolę nad konfiguracją sieci wirtualnej, użyj następujących szablonów usługi Azure Resource Manager (ARM) zamiast automatycznego wdrażania sieci wirtualnej opartej na interfejsie użytkownika portalu. Na przykład użyj istniejących podsieci, istniejącej sieciowej grupy zabezpieczeń lub dodaj własne reguły zabezpieczeń.
Jeśli używasz niestandardowego szablonu usługi Azure Resource Manager lub szablonu obszaru roboczego dla iniekcji sieci wirtualnej usługi Azure Databricks w celu wdrożenia obszaru roboczego w istniejącej sieci wirtualnej, musisz utworzyć podsieci hostów i kontenerów, dołączyć sieciową grupę zabezpieczeń do każdej podsieci i delegować podsieci do Microsoft.Databricks/workspaces dostawcy zasobów przed wdrożeniem obszaru roboczego. Musisz mieć oddzielną parę podsieci dla każdego wdrażanego obszaru roboczego.
Szablon all-in-one
Aby utworzyć sieć wirtualną i obszar roboczy usługi Azure Databricks przy użyciu jednego szablonu, użyj szablonu All-in-one dla obszarów roboczych z wstrzykniętą siecią wirtualną usługi Azure Databricks.
Szablon sieci wirtualnej
Aby utworzyć sieć wirtualną z odpowiednimi podsieciami przy użyciu szablonu, użyj szablonu sieci wirtualnej do wstrzykiwania sieci wirtualnej usługi Databricks.
Szablon obszaru roboczego usługi Azure Databricks
Aby wdrożyć obszar roboczy usługi Azure Databricks w istniejącej sieci wirtualnej przy użyciu szablonu, użyj szablonu obszaru roboczego dla iniekcji sieci wirtualnej usługi Azure Databricks.
Szablon obszaru roboczego umożliwia określenie istniejącej sieci wirtualnej i użycie istniejących podsieci:
- Musisz mieć oddzielną parę podsieci hosta/kontenera dla każdego wdrożonego obszaru roboczego. Nie jest obsługiwane udostępnianie podsieci między obszarami roboczymi lub wdrażanie innych zasobów platformy Azure w podsieciach używanych przez obszar roboczy usługi Azure Databricks.
- Podsieci hosta i kontenera sieci wirtualnej muszą mieć dołączone sieciowe grupy zabezpieczeń i muszą być delegowane do
Microsoft.Databricks/workspacesusługi przed użyciem tego szablonu usługi Azure Resource Manager w celu wdrożenia obszaru roboczego. - Aby utworzyć sieć wirtualną z prawidłowo delegowanymi podsieciami, użyj szablonu sieci wirtualnej do iniekcji sieci wirtualnej usługi Databricks.
- Aby użyć istniejącej sieci wirtualnej, jeśli nie delegowano jeszcze podsieci hosta i kontenera, zobacz Dodawanie lub usuwanie delegowania podsieci.
Reguły sieciowej grupy zabezpieczeń
W poniższych tabelach są wyświetlane bieżące reguły sieciowej grupy zabezpieczeń używane przez usługę Azure Databricks. Jeśli usługa Azure Databricks musi dodać regułę lub zmienić zakres istniejącej reguły na tej liście, otrzymasz powiadomienie z wyprzedzeniem. Ten artykuł i tabele zostaną zaktualizowane za każdym razem, gdy wystąpi taka modyfikacja.
W tej sekcji:
- Jak usługa Azure Databricks zarządza regułami sieciowej grupy zabezpieczeń
- Reguły sieciowej grupy zabezpieczeń dla obszarów roboczych utworzonych po 13 stycznia 2020 r.
- Reguły sieciowej grupy zabezpieczeń dla obszarów roboczych utworzonych przed 13 stycznia 2020 r.
Jak usługa Azure Databricks zarządza regułami sieciowej grupy zabezpieczeń
Reguły sieciowej grupy zabezpieczeń wymienione w poniższych sekcjach reprezentują te, które usługa Azure Databricks automatycznie aprowizuje i zarządza w sieciowej grupie zabezpieczeń, dzięki delegowaniu podsieci hosta i kontenera sieci wirtualnej do Microsoft.Databricks/workspaces usługi. Nie masz uprawnień do aktualizowania ani usuwania tych reguł sieciowej grupy zabezpieczeń; wszelkie próby wykonania tej czynności są blokowane przez delegowanie podsieci. Usługa Azure Databricks musi być właścicielem tych reguł w celu zapewnienia, że firma Microsoft może niezawodnie działać i obsługiwać usługę Azure Databricks w sieci wirtualnej.
Niektóre z tych reguł sieciowej grupy zabezpieczeń mają przypisaną sieć wirtualną jako źródło i miejsce docelowe. Zostało to zaimplementowane w celu uproszczenia projektu w przypadku braku tagu usługi na poziomie podsieci na platformie Azure. Wszystkie klastry są chronione przez drugą warstwę zasad sieciowych wewnętrznie, tak aby klaster A nie mógł połączyć się z klastrem B w tym samym obszarze roboczym. Dotyczy to również wielu obszarów roboczych, jeśli obszary robocze są wdrażane w innej parze podsieci w tej samej sieci wirtualnej zarządzanej przez klienta.
Ważne
Usługa Databricks zdecydowanie zaleca dodanie reguł odmowy do sieciowych grup zabezpieczeń dołączonych do innych sieci i podsieci, które znajdują się w tej samej sieci wirtualnej lub są połączone za pomocą komunikacji równorzędnej z tą siecią wirtualną. Dodaj reguły odmowy dla połączeń zarówno dla połączeń przychodzących, jak i wychodzących , aby ograniczyć połączenia zarówno do, jak i z zasobów obliczeniowych usługi Azure Databricks. Jeśli klaster potrzebuje dostępu do zasobów w sieci, dodaj reguły, aby zezwolić tylko na minimalną ilość dostępu wymaganą do spełnienia wymagań.
Reguły sieciowej grupy zabezpieczeń dla obszarów roboczych utworzonych po 13 stycznia 2020 r.
Informacje w tej sekcji dotyczą tylko obszarów roboczych usługi Azure Databricks utworzonych po 13 stycznia 2020 r. Jeśli obszar roboczy został utworzony przed wydaniem bezpiecznej łączności klastra (SCC) 13 stycznia 2020 r., zobacz następną sekcję.
Ważne
W tej tabeli wymieniono dwie reguły grupy zabezpieczeń dla ruchu przychodzącego, które są uwzględniane tylko wtedy, gdy wyłączono bezpieczną łączność klastra (SCC ).
| Kierunek | Protokół | Element źródłowy | Port źródłowy | Element docelowy | Dest Port | Used |
|---|---|---|---|---|---|---|
| Przychodzący | Dowolne | VirtualNetwork | Dowolne | VirtualNetwork | Dowolne | Wartość domyślna |
| Przychodzący | TCP | AzureDatabricks (tag usługi) Tylko wtedy, gdy SCC jest wyłączona |
Dowolne | VirtualNetwork | 22 | Publiczny adres IP |
| Przychodzący | TCP | AzureDatabricks (tag usługi) Tylko wtedy, gdy SCC jest wyłączona |
Dowolne | VirtualNetwork | 5557 | Publiczny adres IP |
| Wychodzący | TCP | VirtualNetwork | Dowolne | AzureDatabricks (tag usługi) | 443, 3306, 8443-8451 | Wartość domyślna |
| Wychodzący | TCP | VirtualNetwork | Dowolne | SQL | 3306 | Wartość domyślna |
| Wychodzący | TCP | VirtualNetwork | Dowolne | Storage | 443 | Wartość domyślna |
| Wychodzący | Dowolne | VirtualNetwork | Dowolne | VirtualNetwork | Dowolne | Wartość domyślna |
| Wychodzący | TCP | VirtualNetwork | Dowolne | EventHub | 9093 | Domyślnie |
Uwaga
Jeśli ograniczysz reguły ruchu wychodzącego, usługa Databricks zaleca otwieranie portów 111 i 2049 w celu włączenia niektórych instalacji biblioteki.
Reguły sieciowej grupy zabezpieczeń dla obszarów roboczych utworzonych przed 13 stycznia 2020 r.
Informacje w tej sekcji dotyczą tylko obszarów roboczych usługi Azure Databricks utworzonych przed 13 stycznia 2020 r. Jeśli obszar roboczy został utworzony 13 stycznia 2020 r., zobacz poprzednią sekcję.
| Kierunek | Protokół | Element źródłowy | Port źródłowy | Element docelowy | Dest Port | Used |
|---|---|---|---|---|---|---|
| Przychodzący | Dowolne | VirtualNetwork | Dowolne | VirtualNetwork | Dowolne | Wartość domyślna |
| Przychodzący | TCP | Adres IP płaszczyzny sterowania | Dowolne | VirtualNetwork | 22 | Publiczny adres IP |
| Przychodzący | TCP | Adres IP płaszczyzny sterowania | Dowolne | VirtualNetwork | 5557 | Publiczny adres IP |
| Wychodzący | TCP | VirtualNetwork | Dowolne | Adres IP aplikacji internetowej | 443 | Wartość domyślna |
| Wychodzący | TCP | VirtualNetwork | Dowolne | SQL | 3306 | Wartość domyślna |
| Wychodzący | TCP | VirtualNetwork | Dowolne | Storage | 443 | Wartość domyślna |
| Wychodzący | Dowolne | VirtualNetwork | Dowolne | VirtualNetwork | Dowolne | Wartość domyślna |
| Wychodzący | TCP | VirtualNetwork | Dowolne | EventHub | 9093 | Wartość domyślna |
Ważne
Azure Databricks to usługa firmy Microsoft Azure, która jest wdrażana w globalnej infrastrukturze chmury publicznej platformy Azure. Cała komunikacja między składnikami usługi, w tym między publicznymi adresami IP na płaszczyźnie sterowania i płaszczyzną obliczeniową klienta, pozostaje w sieci szkieletowej sieci platformy Microsoft Azure. Zobacz również sieć globalną firmy Microsoft.
Rozwiązywanie problemów
Błędy tworzenia obszaru roboczego
<subnet-id> Podsieć wymaga dowolnych z następujących delegowania [Microsoft.Databricks/workspaces] w celu odwołania się do linku skojarzenia usługi
Możliwa przyczyna: tworzysz obszar roboczy w sieci wirtualnej, której podsieci hostów i kontenerów nie zostały delegowane do Microsoft.Databricks/workspaces usługi. Każda podsieć musi mieć dołączoną sieciową grupę zabezpieczeń i musi być prawidłowo delegowana. Aby uzyskać więcej informacji, zobacz Tabela routingu sieci wirtualnej.
Podsieć <subnet-id> jest już używana przez obszar roboczy <workspace-id>
Możliwa przyczyna: tworzysz obszar roboczy w sieci wirtualnej z podsieciami hosta i kontenera, które są już używane przez istniejący obszar roboczy usługi Azure Databricks. Nie można udostępniać wielu obszarów roboczych w jednej podsieci. Musisz mieć nową parę podsieci hosta i kontenera dla każdego wdrażanego obszaru roboczego.
Rozwiązywanie problemów
Wystąpienia nieosiągalne: zasoby nie były osiągalne za pośrednictwem protokołu SSH.
Możliwa przyczyna: ruch z płaszczyzny sterowania do procesów roboczych jest blokowany. Jeśli wdrażasz w istniejącej sieci wirtualnej połączonej z siecią lokalną, przejrzyj konfigurację, korzystając z informacji podanych w artykule Łączenie obszaru roboczego usługi Azure Databricks z siecią lokalną.
Nieoczekiwany błąd uruchamiania: napotkano nieoczekiwany błąd podczas konfigurowania klastra. Spróbuj ponownie i skontaktuj się z pomocą usługi Azure Databricks, jeśli problem będzie nadal występować. Wewnętrzny komunikat o błędzie: Timeout while placing node.
Możliwa przyczyna: ruch z procesów roboczych do punktów końcowych usługi Azure Storage jest zablokowany. Jeśli używasz niestandardowych serwerów DNS, sprawdź również stan serwerów DNS w sieci wirtualnej.
Niepowodzenie uruchomienia dostawcy usług w chmurze: Podczas konfigurowania klastra wystąpił błąd dostawcy w chmurze. Aby uzyskać więcej informacji, zobacz przewodnik po usłudze Azure Databricks. Kod błędu platformy Azure: AuthorizationFailed/InvalidResourceReference.
Możliwa przyczyna: sieć wirtualna lub podsieci nie istnieją już. Upewnij się, że sieć wirtualna i podsieci istnieją.
Klaster został zatrzymany. Przyczyna: Niepowodzenie uruchamiania platformy Spark: Nie udało się uruchomić platformy Spark na czas. Ten problem może być spowodowany nieprawidłowo działającym magazynem metadanych Hive, nieprawidłowymi konfiguracjami platformy Spark lub nieprawidłowo działającymi skryptami inicjowania. Zapoznaj się z dziennikami sterowników platformy Spark, aby rozwiązać ten problem, i skontaktuj się z zespołem usługi Databricks, jeśli problem będzie się powtarzać. Wewnętrzny komunikat o błędzie: Spark failed to start: Driver failed to start in time.
Możliwa przyczyna: Kontener nie może komunikować się z wystąpieniem hostingu ani kontem magazynu SYSTEMU PLIKÓW DBFS. Napraw tę sytuację, dodając trasę niestandardową do podsieci dla konta magazynu DBFS z Internetem będącym następnym przeskokiem.