Dela via

Distribuera Azure Databricks i ditt virtuella Azure-nätverk (VNet-inmatning)

  • Artikel

Den här artikeln beskriver hur du distribuerar en Azure Databricks-arbetsyta i ditt eget virtuella Azure-nätverk, även kallat VNet-inmatning.

Nätverksanpassning med VNet-inmatning

Standarddistributionen av Azure Databricks är en fullständigt hanterad tjänst på Azure. Ett virtuellt Azure-nätverk (VNet) distribueras till en låst resursgrupp. Alla klassiska beräkningsplanresurser är associerade med det virtuella nätverket. Om du behöver nätverksanpassning kan du distribuera klassiska Azure Databricks-beräkningsplanresurser i ditt eget virtuella nätverk. Detta gör att du kan:

När du distribuerar klassiska Azure Databricks-beräkningsplanresurser till ditt eget virtuella nätverk kan du också dra nytta av flexibla CIDR-intervall. För det virtuella nätverket kan du använda CIDR-intervallstorleken /16-/24. För undernäten använder du IP-intervall så små som /26.

Viktigt!

Du kan inte ersätta det virtuella nätverket för en befintlig arbetsyta. Om den aktuella arbetsytan inte kan hantera det antal aktiva klusternoder som behövs rekommenderar vi att du skapar en annan arbetsyta i ett större virtuellt nätverk. Följ de här detaljerade migreringsstegen och kopiera resurser (anteckningsböcker, klusterkonfigurationer, jobb) från den gamla arbetsytan till den nya.

Krav för virtuellt nätverk

Det virtuella nätverk som du distribuerar din Azure Databricks-arbetsyta till måste uppfylla följande krav:

  • Region: Det virtuella nätverket måste finnas i samma region och prenumeration som Azure Databricks-arbetsytan.
  • Prenumeration: Det virtuella nätverket måste finnas i samma prenumeration som Azure Databricks-arbetsytan.
  • Adressutrymme: Ett CIDR-block mellan /16 och /24 för det virtuella nätverket och ett CIDR-block upp till /26 för de två undernäten: ett containerundernät och ett värdundernät. Vägledning om maximala klusternoder baserat på storleken på ditt virtuella nätverk och dess undernät finns i Adressutrymme och maximalt klusternoder.
  • Undernät: Det virtuella nätverket måste innehålla två undernät som är dedikerade till din Azure Databricks-arbetsyta: ett containerundernät (kallas ibland det privata undernätet) och ett värdundernät (kallas ibland det offentliga undernätet). När du distribuerar en arbetsyta med säker klusteranslutning använder både containerundernätet och värdundernätet privata IP-adresser. Du kan inte dela undernät mellan arbetsytor eller distribuera andra Azure-resurser på de undernät som används av din Azure Databricks-arbetsyta. Vägledning om maximala klusternoder baserat på storleken på ditt virtuella nätverk och dess undernät finns i Adressutrymme och maximalt klusternoder.

Adressutrymme och maximalt antal klusternoder

En arbetsyta med ett mindre virtuellt nätverk kan få slut på IP-adresser (nätverksutrymme) snabbare än en arbetsyta med ett större virtuellt nätverk. Använd ett CIDR-block mellan /16 och /24 för det virtuella nätverket och ett CIDR-block upp till /26 för de två undernäten (containerundernätet och värdundernätet). Du kan skapa ett CIDR-block upp till /28 för dina undernät, men Databricks rekommenderar inte ett undernät som är mindre än /26.

CIDR-intervallet för ditt VNet-adressutrymme påverkar det maximala antalet klusternoder som arbetsytan kan använda.

En Azure Databricks-arbetsyta kräver två undernät i det virtuella nätverket: ett containerundernät och ett värdundernät. Azure reserverar fem IP-adresser i varje undernät. Azure Databricks kräver två IP-adresser för varje klusternod: en IP-adress för värden i värdundernätet och en IP-adress för containern i containerundernätet.

  • Du kanske inte vill använda allt adressutrymme för ditt virtuella nätverk. Du kanske till exempel vill skapa flera arbetsytor i ett virtuellt nätverk. Eftersom du inte kan dela undernät mellan arbetsytor kanske du vill ha undernät som inte använder det totala VNet-adressutrymmet.
  • Du måste allokera adressutrymme för två nya undernät som finns inom det virtuella nätverkets adressutrymme och inte överlappa adressutrymmet för aktuella eller framtida undernät i det virtuella nätverket.

I följande tabell visas den maximala undernätsstorleken baserat på nätverkets storlek. Den här tabellen förutsätter att det inte finns några ytterligare undernät som tar upp adressutrymme. Använd mindre undernät om du har befintliga undernät eller om du vill reservera adressutrymme för andra undernät:

VNet-adressutrymme (CIDR) Maximal Azure Databricks-undernätsstorlek (CIDR) förutsatt att inga andra undernät
/16 /17
/17 /18
/18 /19
/20 /21
/21 /22
/22 /23
/23 /24
/24 /25

Använd följande tabell för att hitta maximalt antal klusternoder baserat på undernätsstorleken. KOLUMNEN IP-adresser per undernät innehåller de fem Azure-reserverade IP-adresserna. Kolumnen längst till höger anger antalet klusternoder som kan köras samtidigt på en arbetsyta som etableras med undernät av den storleken.

Undernätsstorlek (CIDR) IP-adresser per undernät Maximalt antal Azure Databricks-klusternoder
/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

Utgående IP-adresser när du använder säker klusteranslutning

Om du aktiverar säker klusteranslutning på din arbetsyta som använder VNet-inmatning rekommenderar Databricks att din arbetsyta har en stabil offentlig IP-adress för utgående trafik.

Stabila offentliga IP-adresser för utgående trafik är användbara eftersom du kan lägga till dem i externa tillåtna listor. Om du till exempel vill ansluta från Azure Databricks till Salesforce med en stabil utgående IP-adress. Om du konfigurerar IP-åtkomstlistor måste dessa offentliga IP-adresser läggas till i en lista över tillåtna. Se Konfigurera IP-åtkomstlistor för arbetsytor.

Varning

Microsoft meddelade att den 30 september 2025 kommer standardanslutningen för utgående åtkomst för virtuella datorer i Azure att dras tillbaka. Se det här meddelandet. Det innebär att Azure Databricks-arbetsytor som använder standardutgående åtkomst i stället för en stabil offentlig IP-adress för utgående trafik kanske inte fortsätter att fungera efter det datumet. Databricks rekommenderar att du lägger till explicita utgående metoder för dina arbetsytor före det datumet.

Information om hur du konfigurerar en stabil offentlig IP-adress för utgående trafik finns i Utgående med VNet-inmatning

Delade resurser och peering

Om delade nätverksresurser som DNS krävs rekommenderar Databricks starkt att du följer Azures metodtips för hubb- och ekermodellen. Använd VNet-peering för att utöka det privata IP-utrymmet för arbetsytans virtuella nätverk till hubben samtidigt som ekrarna hålls isolerade från varandra.

Om du har andra resurser i det virtuella nätverket eller använder peering rekommenderar Databricks starkt att du lägger till Neka-regler till nätverkssäkerhetsgrupper (NSG:er) som är kopplade till andra nätverk och undernät som finns i samma virtuella nätverk eller är peer-kopplade till det virtuella nätverket. Lägg till Neka-regler för anslutningar för både inkommande och utgående anslutningar så att de begränsar anslutningar både till och från Azure Databricks-beräkningsresurser. Om klustret behöver åtkomst till resurser i nätverket lägger du till regler för att endast tillåta den minsta mängd åtkomst som krävs för att uppfylla kraven.

Relaterad information finns i Regler för nätverkssäkerhetsgrupp.

Skapa en Azure Databricks-arbetsyta med Hjälp av Azure-portalen

I det här avsnittet beskrivs hur du skapar en Azure Databricks-arbetsyta i Azure-portalen och distribuerar den i ditt eget befintliga virtuella nätverk. Azure Databricks uppdaterar det virtuella nätverket med två nya undernät om de inte finns ännu, med hjälp av CIDR-intervall som du anger. Tjänsten uppdaterar även undernäten med en ny nätverkssäkerhetsgrupp, konfigurerar regler för inkommande och utgående trafik och distribuerar slutligen arbetsytan till det uppdaterade virtuella nätverket. Om du vill ha mer kontroll över konfigurationen av det virtuella nätverket använder du Azure-Databricks-tillhandahållna Azure Resource Manager-mallar (ARM) i stället för portalen. Du kan till exempel använda befintliga nätverkssäkerhetsgrupper eller skapa egna säkerhetsregler. Se Avancerad konfiguration med Hjälp av Azure Resource Manager-mallar.

Användaren som skapar arbetsytan måste tilldelas rollen Nätverksdeltagare till motsvarande virtuella nätverk eller en anpassad roll som har tilldelats behörigheterna Microsoft.Network/virtualNetworks/subnets/join/action Microsoft.Network/virtualNetworks/subnets/write och .

Du måste konfigurera ett virtuellt nätverk som du ska distribuera Azure Databricks-arbetsytan till. Du kan använda ett befintligt virtuellt nätverk eller skapa ett nytt, men det virtuella nätverket måste finnas i samma region och samma prenumeration som den Azure Databricks-arbetsyta som du planerar att skapa. Det virtuella nätverket måste vara storleksanpassat med ett CIDR-intervall mellan /16 och /24. Fler krav finns i Krav för virtuellt nätverk.

Använd antingen befintliga undernät eller ange namn och IP-intervall för nya undernät när du konfigurerar din arbetsyta.

  1. I Azure-portalen väljer du + Skapa en resursanalys > > Azure Databricks eller söker efter Azure Databricks och klickar på Skapa eller + Lägg till för att starta dialogrutan Azure Databricks Service.

  2. Följ konfigurationsstegen som beskrivs i snabbstarten Skapa en Azure Databricks-arbetsyta i ditt eget virtuella nätverk .

  3. På fliken Nätverk väljer du det virtuella nätverk som du vill använda i fältet Virtuellt nätverk .

    Viktigt!

    Om du inte ser nätverksnamnet i väljaren kontrollerar du att den Azure-region som du har angett för arbetsytan matchar Azure-regionen för det önskade virtuella nätverket.

    Välj virtuellt nätverk

  4. Namnge dina undernät och ange CIDR-intervall i ett block upp till storlek /26. Vägledning om maximala klusternoder baserat på storleken på ditt virtuella nätverk och dess undernät finns i Adressutrymme och maximalt klusternoder. Det går inte att ändra CIDR-intervallen för undernätet när arbetsytan har distribuerats.

    • Om du vill ange befintliga undernät anger du de exakta namnen på de befintliga undernäten. När du använder befintliga undernät anger du även IP-intervallen i formuläret för att skapa arbetsytan så att de exakt matchar IP-intervallen för de befintliga undernäten.
    • Om du vill skapa nya undernät anger du undernätsnamn som inte redan finns i det virtuella nätverket. Undernäten skapas med de angivna IP-intervallen. Du måste ange IP-intervall inom IP-intervallet för ditt virtuella nätverk och inte redan allokerade till befintliga undernät.

    Azure Databricks kräver att undernätsnamnen inte är längre än 80 tecken.

    Undernäten hämtar associerade regler för nätverkssäkerhetsgrupper som innehåller regeln för att tillåta klusterintern kommunikation. Azure Databricks har delegerade behörigheter för att uppdatera båda undernäten via resursprovidern Microsoft.Databricks/workspaces . Dessa behörigheter gäller endast för regler för nätverkssäkerhetsgrupper som krävs av Azure Databricks, inte för andra regler för nätverkssäkerhetsgrupper som du lägger till eller för standardreglerna för nätverkssäkerhetsgruppen som ingår i alla nätverkssäkerhetsgrupper.

  5. Klicka på Skapa för att distribuera Azure Databricks-arbetsytan till det virtuella nätverket.

Avancerad konfiguration med Hjälp av Azure Resource Manager-mallar

Om du vill ha mer kontroll över konfigurationen av det virtuella nätverket använder du följande Arm-mallar (Azure Resource Manager) i stället för den portalbaserade automatiska VNet-konfigurationen och arbetsytedistributionen. Du kan till exempel använda befintliga undernät, en befintlig nätverkssäkerhetsgrupp eller lägga till egna säkerhetsregler.

Om du använder en anpassad Azure Resource Manager-mall eller arbetsytemallen för Azure Databricks VNet Injection för att distribuera en arbetsyta till ett befintligt VNet måste du skapa värd- och containerundernät, koppla en nätverkssäkerhetsgrupp till varje undernät och delegera undernäten Microsoft.Databricks/workspaces till resursprovidern innan du distribuerar arbetsytan. Du måste ha ett nytt par med värd- och containerundernät för varje arbetsyta som du distribuerar.

Allt-i-ett-mall

Om du vill skapa en VNet- och Azure Databricks-arbetsyta med en mall använder du allt-i-ett-mallen för Azure Databricks VNet-inmatade arbetsytor.

Mall för virtuellt nätverk

Om du vill skapa ett virtuellt nätverk med rätt undernät med hjälp av en mall använder du VNet-mallen för Databricks VNet Injection.

Mall för Azure Databricks-arbetsytor

Om du vill distribuera en Azure Databricks-arbetsyta till ett befintligt virtuellt nätverk med en mall använder du arbetsytemallen för Azure Databricks VNet Injection.

Med arbetsytemallen kan du ange ett befintligt VNet och använda befintliga undernät:

  • Du måste ha ett separat par värd-/containerundernät för varje arbetsyta som du distribuerar. Det stöds inte att dela undernät mellan arbetsytor eller att distribuera andra Azure-resurser på de undernät som används av din Azure Databricks-arbetsyta.
  • Det virtuella nätverkets värd- och containerundernät måste ha nätverkssäkerhetsgrupper kopplade och måste delegeras till Microsoft.Databricks/workspaces tjänsten innan du använder den här Azure Resource Manager-mallen för att distribuera en arbetsyta.
  • Om du vill skapa ett virtuellt nätverk med korrekt delegerade undernät använder du VNet-mallen för databricks VNet-inmatning.
  • Information om hur du använder ett befintligt virtuellt nätverk när du ännu inte har delegerat värd- och containerundernäten finns i Lägga till eller ta bort en delegering av undernät.

Regler för nätverkssäkerhetsgrupp

Följande tabeller visar de aktuella reglerna för nätverkssäkerhetsgrupper som används av Azure Databricks. Om Azure Databricks behöver lägga till en regel eller ändra omfånget för en befintlig regel i den här listan får du ett meddelande i förväg. Den här artikeln och tabellerna uppdateras när en sådan ändring sker.

Så hanterar Azure Databricks regler för nätverkssäkerhetsgrupper

NSG-reglerna som anges i följande avsnitt representerar de som Azure Databricks automatiskt etablerar och hanterar i din NSG, tack vare delegeringen av ditt virtuella nätverks värd- och containerundernät till Microsoft.Databricks/workspaces tjänsten. Du har inte behörighet att uppdatera eller ta bort dessa NSG-regler och alla försök att göra det blockeras av undernätsdelegeringen. Azure Databricks måste äga dessa regler för att säkerställa att Microsoft kan använda och stödja Azure Databricks-tjänsten på ett tillförlitligt sätt i ditt virtuella nätverk.

Vissa av dessa NSG-regler har VirtualNetwork tilldelat som källa och mål. Detta har implementerats för att förenkla designen i avsaknad av en tjänsttagg på undernätsnivå i Azure. Alla kluster skyddas av ett andra lager av nätverksprinciper internt, så att kluster A inte kan ansluta till kluster B på samma arbetsyta. Detta gäller även för flera arbetsytor om dina arbetsytor distribueras till ett annat par undernät i samma kundhanterade virtuella nätverk.

Viktigt!

Databricks rekommenderar starkt att du lägger till Neka-regler till nätverkssäkerhetsgrupper (NSG:er) som är kopplade till andra nätverk och undernät som finns i samma virtuella nätverk eller är peer-kopplade till det virtuella nätverket. Lägg till Neka-regler för anslutningar för både inkommande och utgående anslutningar så att de begränsar anslutningar både till och från Azure Databricks-beräkningsresurser. Om klustret behöver åtkomst till resurser i nätverket lägger du till regler för att endast tillåta den minsta mängd åtkomst som krävs för att uppfylla kraven.

Regler för nätverkssäkerhetsgrupp för arbetsytor

Informationen i det här avsnittet gäller endast för Azure Databricks-arbetsytor som skapats efter den 13 januari 2020. Om din arbetsyta skapades före lanseringen av säker klusteranslutning (SCC) den 13 januari 2020 läser du nästa avsnitt.

Den här tabellen visar regler för nätverkssäkerhetsgrupp för arbetsytor och innehåller två regler för inkommande säkerhetsgrupper som endast ingår om säker klusteranslutning (SCC) är inaktiverad.

Riktning Protokoll Källa Källport Mål Dest-port Använd
Inkommande Valfri VirtualNetwork Valfri VirtualNetwork Alla Standardvärde
Inkommande TCP AzureDatabricks (tjänsttagg)
Endast om SCC är inaktiverat		 Valfri VirtualNetwork 22 Offentlig IP-adress
Inkommande TCP AzureDatabricks (tjänsttagg)
Endast om SCC är inaktiverat		 Valfri VirtualNetwork 5557 Offentlig IP-adress
Utgående TCP VirtualNetwork Alla AzureDatabricks (tjänsttagg) 443, 3306, 8443-8451 Standardvärde
Utgående TCP VirtualNetwork Alla SQL 3306 Standardvärde
Utgående TCP VirtualNetwork Alla Storage 443 Standardvärde
Utgående Valfri VirtualNetwork Valfri VirtualNetwork Alla Standardvärde
Utgående TCP VirtualNetwork Alla EventHub 9093 Standardvärde

Kommentar

Om du begränsar regler för utgående trafik rekommenderar Databricks att du öppnar portarna 111 och 2049 för att aktivera vissa biblioteksinstallationer.

Viktigt!

Azure Databricks är en microsoft Azure-tjänst från första part som distribueras i den globala offentliga Azure-molninfrastrukturen. All kommunikation mellan komponenter i tjänsten, inklusive mellan de offentliga IP-adresserna i kontrollplanet och kundens beräkningsplan, förblir inom Microsoft Azure-nätverkets stamnät. Se även Microsofts globala nätverk.

Felsökning

Fel vid skapande av arbetsyta

Undernätet <subnet-id> kräver någon av följande delegeringar [Microsoft.Databricks/workspaces] för att referera till länken för tjänstassociation

Möjlig orsak: du skapar en arbetsyta i ett virtuellt nätverk vars värd- och containerundernät inte har delegerats till Microsoft.Databricks/workspaces tjänsten. Varje undernät måste ha en nätverkssäkerhetsgrupp kopplad och vara korrekt delegerad. Mer information finns i Krav för virtuella nätverk.

Undernätet <subnet-id> används redan av arbetsytan <workspace-id>

Möjlig orsak: du skapar en arbetsyta i ett virtuellt nätverk med värd- och containerundernät som redan används av en befintlig Azure Databricks-arbetsyta. Du kan inte dela flera arbetsytor i ett enda undernät. Du måste ha ett nytt par med värd- och containerundernät för varje arbetsyta som du distribuerar.

Felsökning

Instanser kan inte nås: Resurser kunde inte nås via SSH.

Möjlig orsak: trafik från kontrollplanet till arbetare blockeras. Om du distribuerar till ett befintligt virtuellt nätverk som är anslutet till ditt lokala nätverk granskar du konfigurationen med hjälp av informationen i Ansluta Azure Databricks-arbetsytan till ditt lokala nätverk.

Oväntat startfel: Ett oväntat fel påträffades när klustret konfigurerades. Försök igen och kontakta Azure Databricks om problemet kvarstår. Internt felmeddelande: Timeout while placing node.

Möjlig orsak: trafik från arbetare till Azure Storage-slutpunkter blockeras. Om du använder anpassade DNS-servrar kontrollerar du även statusen för DNS-servrarna i ditt virtuella nätverk.

Startfel för molnleverantör: Ett fel hos molnleverantören inträffade när klustret konfigurerades. Mer information finns i Azure Databricks-guiden. Azure-felkod: AuthorizationFailed/InvalidResourceReference.

Möjlig orsak: det virtuella nätverket eller undernäten finns inte längre. Kontrollera att det virtuella nätverket och undernäten finns.

Klustret avslutades. Orsak: Spark-startfel: Spark kunde inte startas i tid. Det här problemet kan orsakas av att ett Hive-metaarkiv inte fungerar, ogiltiga Spark-konfigurationer eller felaktiga init-skript. Kontrollera Spark-drivrutinsloggarna för att felsöka det här problemet och kontakta Databricks om problemet kvarstår. Internt felmeddelande: Spark failed to start: Driver failed to start in time.

Möjlig orsak: Containern kan inte kommunicera med värdinstansen eller arbetsytans lagringskonto. Åtgärda genom att lägga till en anpassad väg till undernäten för arbetsytans lagringskonto med nästa hopp som Internet.