Udostępnij za pośrednictwem

Wdróż Azure Databricks w swojej wirtualnej sieci Azure (VNet injection)

W tym artykule opisano, jak wdrożyć obszar roboczy usługi Azure Databricks we własnej sieci wirtualnej platformy Azure, znanej również jako iniekcja VNet.

Personalizacja sieci z wykorzystaniem injekcji VNet

Domyślne wdrożenie usługi Azure Databricks to w pełni zarządzana usługa na platformie Azure. Wirtualna sieć Azure jest wdrażana do zablokowanej grupy zasobów. Wszystkie klasyczne zasoby płaszczyzny obliczeniowej są skojarzone z tą siecią wirtualną. Jeśli potrzebujesz dostosowania sieci, możesz wdrożyć klasyczne zasoby płaszczyzny obliczeniowej usługi Azure Databricks we własnej sieci wirtualnej. Umożliwia to:

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ć zakresu CIDR o rozmiarze /16-/24. W przypadku podsieci użyj zakresów adresów IP tak małych, jak /26.

Ważne

Nie można zastąpić sieci wirtualnej skojarzonej z istniejącym obszarem roboczym usługi Azure Databricks. Jeśli sieć wirtualna bieżącego obszaru roboczego ma niewystarczającą pojemność, aby pomieścić wymaganą liczbę aktywnych węzłów klastra, wykonaj następujące kroki:

  1. W przypadku obszarów roboczych z wstrzykniętą siecią VNet: Rozszerz zakres CIDR dla podsieci. Aby zwiększyć dostępną przestrzeń adresów IP dla Twojego obszaru roboczego, możesz wystąpić z wnioskiem o aktualizację zakresu CIDR dla podsieci obszaru roboczego. Aby wprowadzić te zmiany, skontaktuj się z zespołem konta usługi Azure Databricks.
  2. W przypadku obszarów roboczych, które nie są wstrzykiwane do sieci wirtualnej: utwórz nowy obszar roboczy w większej sieci wirtualnej, która może spełniać wymagania dotyczące obciążenia.

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 i subskrypcji 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 w zakresie od /16 do /24 dla sieci wirtualnej oraz blok CIDR do /26 dla dwó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ą). Podczas wdrażania obszaru roboczego przy użyciu bezpiecznej łączności klastra zarówno podsieć kontenera, jak i podsieć hosta używają prywatnych adresów IP. Nie można udostępniać podsieci między obszarami roboczymi ani wdrażać 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.

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 a /24 dla sieci VNet oraz bloku CIDR do /26 dla dwóch podsieci (podsieci kontenera i podsieci hosta). Można utworzyć blok CIDR o rozmiarze do /28 dla swoich podsieci, jednak Databricks nie zaleca używania podsieci mniejszej niż /26.

Zakres CIDR przestrzeni adresowej sieci wirtualnej ma wpływ na maksymalną liczbę węzłów klastra, z których może korzystać obszar roboczy.

Obszar roboczy usługi Azure Databricks wymaga dwóch podsieci w sieci wirtualnej: podsieci kontenera i podsieci hosta. Platforma Azure rezerwuje pięć adresów IP w każdej podsieci. Usługa Azure Databricks wymaga dwóch adresów 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, możesz chcieć używać podsieci, które nie korzystają z łącznej przestrzeni adresowej sieci wirtualnej.
  • Należy przydzielić przestrzeń adresową dla dwóch nowych podsieci, które znajdują się w przestrzeni adresowej sieci wirtualnej i które nie nakładają 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 jedną podsieć zawiera pięć adresów IP zarezerwowanych przez platformę Azure. Najbardziej prawa kolumna wskazuje liczbę węzłów klastra, które mogą jednocześnie działać w obszarze roboczym, który został udostępniony z podsieciami o takim rozmiarze.

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 wyjścia podczas korzystania z bezpiecznej łączności z klastrem

Jeśli włączysz bezpieczne połączenie klastrowe w obszarze roboczym korzystającym z iniekcji VNet, usługa Databricks zaleca, aby obszar roboczy miał stabilny publiczny adres IP dla 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. W przypadku skonfigurowania list dostępu do adresów IP te publiczne adresy IP muszą zostać dodane do listy dozwolonych. Zobacz Konfigurowanie list dostępu do adresów IP dla obszarów roboczych.

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 obszary robocze usługi Azure Databricks, które korzystają z domyślnego dostępu wychodzącego zamiast stabilnego publicznego adresu IP wychodzącego, mogą przestać działać po tej dacie. Usługa Databricks zaleca, aby przed tym dniem dodać jawne metody komunikacji wychodzącej dla twoich obszarów roboczych.

Aby skonfigurować stabilny publiczny adres IP dla ruchu wychodzącego, zobacz Ruch wychodzący z iniekcją sieci wirtualnej

Współdzielone zasoby i usługi peeringowe

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 peeringu VNet, aby rozszerzyć prywatną przestrzeń adresów IP sieci wirtualnej obszaru roboczego na hub, przy jednoczesnym zachowaniu izolacji poszczególnych odgałęzień.

Jeśli masz inne zasoby w sieci wirtualnej lub używasz peeringu, usługa Databricks zdecydowanie zaleca dodanie reguł Odmowy do sieciowych grup bezpieczeństwa dołączonych do innych sieci i podsieci, które znajdują się w tej samej sieci wirtualnej lub są sparowane 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, jeśli jeszcze ich nie ma, dodaje do sieci wirtualnej dwie nowe podsieci, używając podanych przez użytkownika 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) dostarczonych przez usługę Azure Databricks zamiast 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.

Użytkownik tworzący obszar roboczy musi mieć przypisaną rolę Współautora sieci do odpowiedniej sieci wirtualnej lub rola niestandardowa, która ma przypisane uprawnienia Microsoft.Network/virtualNetworks/subnets/join/action 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ć zakres CIDR 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.

  1. W portalu Azure wybierz pozycję + Utwórz zasób > Analytics > Azure Databricks lub wyszukaj Azure Databricks, a następnie kliknij Utwórz lub + Dodaj, aby uruchomić okno dialogowe usługi Azure Databricks.

  2. Wykonaj kroki konfiguracji opisane w przewodniku Szybki start: Tworzenie obszaru roboczego Azure Databricks w swojej sieci wirtualnej.

  3. 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.

    Wybierz sieć wirtualną

  4. 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. 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. Ustaw zakresy adresów IP w formularzu tworzenia obszaru roboczego, aby dokładnie odpowiadały zakresom adresów IP istniejących podsieci, gdy korzystasz z 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 wskazać zakresy IP dopuszczalne dla sieci wirtualnej (VNet), które nie zostały jeszcze przydzielone do istniejących podsieci.

    Usługa Azure Databricks wymaga, aby nazwy podsieci nie przekraczały 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 ma delegowane uprawnienia do aktualizowania obu podsieci za pośrednictwem dostawcy zasobów Microsoft.Databricks/workspaces. 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ń.

  5. Kliknij przycisk Utwórz , aby wdrożyć obszar roboczy usługi Azure Databricks w sieci wirtualnej.

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 wszystko w jednym

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 usługi Azure Databricks z wstrzykniętą siecią VNet.

Szablon sieci wirtualnej

Aby utworzyć sieć wirtualną z odpowiednimi podsieciami za pomocą szablonu, użyj Szablonu VNet dla wstrzykiwania Databricks VNet.

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 VNet muszą mieć przypisane grupy zabezpieczeń sieciowych i muszą być delegowane do usługi Microsoft.Databricks/workspaces przed użyciem tego szablonu do wdrożenia obszaru roboczego.

  • Aby utworzyć sieć wirtualną z prawidłowo delegowanymi podsieciami, użyj szablonu sieci wirtualnej dla iniekcji usługi Databricks.

  • Aby użyć istniejącej sieci wirtualnej (VNet), jeśli jeszcze nie dokonano delegowania 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.

Jak usługa Azure Databricks zarządza regułami sieciowej grupy zabezpieczeń

Reguły NSG w poniższych sekcjach są automatycznie aprowizowane i zarządzane przez Azure Databricks poprzez delegowanie podsieci hosta i kontenera VNet do usługi Microsoft.Databricks/workspaces. Nie należy aktualizować ani usuwać tych reguł, gdyż delegowanie podsieci je chroni. Te reguły są niezbędne dla firmy Microsoft do niezawodnego działania i obsługi usługi Azure Databricks w sieci wirtualnej.

Niektóre reguły grup zabezpieczeń NSG używają VirtualNetwork jako źródła i miejsca docelowego, aby uprościć projektowanie przy braku tagów usług na poziomie podsieci. Wszystkie klastry są chronione przez wewnętrzne zasady sieci, które uniemożliwiają komunikację między klastrami, nawet między różnymi obszarami roboczymi wdrożonym w tej samej sieci wirtualnej zarządzanej przez klienta.

Azure Databricks zaleca, aby każdy obszar roboczy używał unikatowej sieciowej grupy zabezpieczeń (NSG).

Ważne

Databricks zdecydowanie zaleca dodanie reguł odmawiających do grup zabezpieczeń sieciowych przypisanych 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 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 przestrzeni roboczych

Ta tabela zawiera listę reguł sieciowej grupy zabezpieczeń dla obszarów roboczych i obejmuje dwie reguły grupy zabezpieczeń dla ruchu przychodzącego, które są stosowane tylko wtedy, gdy bezpieczne połączenie klastra (SCC) jest wyłączone.

Kierunek Protokół Źródło Port źródłowy Cel Docelowy port Używane
Przychodzący Dowolne Sieć wirtualna Dowolne Sieć wirtualna Dowolne Wartość domyślna
Przychodzący TCP AzureDatabricks (tag usługi)
Tylko wtedy, gdy SCC jest wyłączona		 Dowolne Sieć wirtualna 22 Publiczny adres IP
Przychodzący TCP AzureDatabricks (tag usługi)
Tylko wtedy, gdy SCC jest wyłączona		 Dowolne Sieć wirtualna 5557 Publiczny adres IP
Wychodzący TCP Sieć wirtualna Dowolne AzureDatabricks (tag usługi) 443, 3306, 8443-8451 Wartość domyślna
Wychodzący TCP Sieć wirtualna Dowolne SQL 3306 Wartość domyślna
Wychodzący TCP Sieć wirtualna Dowolne Przechowywanie 443 Wartość domyślna
Wychodzący Dowolne Sieć wirtualna Dowolne Sieć wirtualna Dowolne Wartość domyślna
Wychodzący TCP Sieć wirtualna Dowolne Usługa EventHub 9093 Wartość domyślna

Uwaga

Jeśli ograniczysz reguły ruchu wychodzącego, usługa Databricks zaleca otwarcie portów 111 i 2049, aby umożliwić instalację niektórych bibliotek.

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

<subnet-id> Podsieć wymaga jednego z następujących uprawnień [Microsoft.Databricks/workspaces], aby odwołać się do połączenia usługi

Możliwa przyczyna: tworzysz obszar roboczy w sieci wirtualnej, gdzie podsieci hostów i kontenerów nie zostały przypisane do usługi Microsoft.Databricks/workspaces. Każda podsieć musi mieć dołączoną sieciową grupę zabezpieczeń i musi być prawidłowo delegowana. Aby uzyskać więcej informacji, zobacz Wymagania dotyczące 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ć nowe podsieci hosta i kontenera dla każdego wdrażanego środowiska pracy.

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 węzłó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: przepływ danych od pracowników 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 instancją hostingu ani kontem magazynowym obszaru roboczego. Rozwiąż problem, dodając trasę niestandardową do podsieci dla konta magazynu obszaru roboczego, gdzie następnym przeskokiem jest Internet.

konflikt z zasadami intencji sieci

Podczas tworzenia nowego obszaru roboczego usługi Databricks, upewnij się, że reguła ruchu wychodzącego NSG (sieciowej grupy zabezpieczeń) z sieci wirtualnej do tagu usługi Databricks zezwala na ruch na portach 443, 3306 i 8443-8451. Istniejące obszary robocze muszą również mieć włączone te porty. Usługa Databricks powiadomiła Cię w lipcu 2024 r., jeśli zasady NSG nie zostały zaktualizowane i odpowiednie porty nie są włączone. Aby rozwiązać ten problem, włącz porty 443, 3306 i 8443-8451 w regule ruchu wychodzącego NSG (sieciowej grupy zabezpieczeń).

Zobacz Aktualizacje reguł sieciowej grupy zabezpieczeń i Reguły sieciowej grupy zabezpieczeń dla obszarów roboczych.