Wdrażanie usługi Azure Databricks w sieci wirtualnej platformy Azure (iniekcja sieci wirtualnej)

W tym artykule opisano sposób wdrażania obszaru roboczego usługi Azure Databricks we własnej sieci wirtualnej platformy Azure, znanego również jako iniekcja sieci wirtualnej.

Dostosowywanie sieci za pomocą iniekcji sieci wirtualnej

Domyślne wdrożenie usługi Azure Databricks to w pełni zarządzana usługa na platformie Azure. Sieć wirtualna platformy Azure jest wdrażana w zablokowanej grupie 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:

• Połącz usługę Azure Databricks z innymi usługami platformy Azure (takimi jak Azure Storage) w bardziej bezpieczny sposób przy użyciu punktów końcowych usługi lub prywatnych punktów końcowych platformy Azure.
• Nawiąż połączenie z lokalnymi źródłami danych przy użyciu tras zdefiniowanych przez użytkownika. Zobacz Ustawienia trasy zdefiniowane przez użytkownika dla usługi Azure Databricks.
• Połącz usługę Azure Databricks z wirtualnym urządzeniem sieciowym, aby sprawdzić cały ruch wychodzący i podjąć działania zgodnie z regułami zezwalania i odmowy. Zobacz Opcję: kierowanie ruchu usługi Azure Databricks przy użyciu urządzenia wirtualnego lub zapory
• Skonfiguruj usługę Azure Databricks do używania niestandardowego systemu DNS. Zobacz Opcję: Konfigurowanie niestandardowego systemu DNS.
• Skonfiguruj reguły sieciowej grupy zabezpieczeń w celu określenia ograniczeń ruchu wychodzącego.

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.

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 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 między /16 i /24 dla sieci wirtualnej i bloku CIDR do /26 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 i /24 dla sieci wirtualnej i bloku CIDR do /26 dwóch podsieci (podsieci kontenera i podsieci hosta). Blok CIDR można utworzyć do /28 podsieci, jednak usługa Databricks nie zaleca 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 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. 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 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 skonfigurować stabilny publiczny adres IP ruchu wychodzącego, zobacz Egress with VNet injection (Ruch wychodzący z iniekcją sieci wirtualnej)

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) 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ół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.

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

2. Wykonaj kroki konfiguracji opisane w przewodniku Szybki start Tworzenie obszaru roboczego usługi Azure Databricks we własnej 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.

   

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

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

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 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/workspaces usł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.

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ń, a każda próba wykonania tej czynności jest blokowana 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

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

Ta tabela zawiera listę reguł sieciowej grupy zabezpieczeń dla obszarów roboczych i zawiera dwie reguły grupy zabezpieczeń dla ruchu przychodzącego, które są uwzględniane tylko wtedy, gdy łączność bezpiecznego klastra (SCC) jest wyłączona.

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.

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 hostowania ani kontem magazynu obszaru roboczego. Poprawka przez dodanie trasy niestandardowej do podsieci dla konta magazynu obszaru roboczego z następnym przeskokiem jest Internet.