Azure Databricks implementeren in uw Microsoft Azure Virtual Network (VNet-opname)

In dit artikel wordt beschreven hoe u een Azure Databricks-werkruimte implementeert in uw eigen virtuele Azure-netwerk, ook wel VNet-injectie genoemd.

Netwerkaanpassing met VNet-injectie

De standaardimplementatie van Azure Databricks is een volledig beheerde service in Azure. Een virtueel Azure-netwerk (VNet) wordt geïmplementeerd in een vergrendelde resourcegroep. Alle klassieke rekenvlakresources zijn gekoppeld aan dat VNet. Als u netwerkaanpassing nodig hebt, kunt u klassieke Azure Databricks-rekenvlakresources implementeren in uw eigen virtuele netwerk. Hiermee kunt u:

• Verbinding maken Azure Databricks naar andere Azure-services (zoals Azure Storage) op een veiligere manier met behulp van service-eindpunten of privé-eindpunten van Azure.
• Verbinding maken naar on-premises gegevensbronnen met behulp van door de gebruiker gedefinieerde routes. Zie door de gebruiker gedefinieerde route-instellingen voor Azure Databricks.
• Verbinding maken Azure Databricks naar een virtueel netwerkapparaat om al het uitgaande verkeer te inspecteren en acties uit te voeren op basis van regels voor toestaan en weigeren. Zie optie: Azure Databricks-verkeer routeren met behulp van een virtueel apparaat of een firewall
• Configureer Azure Databricks voor het gebruik van aangepaste DNS. Zie Optie: Aangepaste DNS configureren.
• Configureer NSG-regels (netwerkbeveiligingsgroep) om beperkingen voor uitgaand verkeer op te geven.

Door klassieke Azure Databricks-rekenvlakresources te implementeren in uw eigen VNet, kunt u ook profiteren van flexibele CIDR-bereiken. Voor het VNet kunt u ciDR-bereikgrootte /16-/24gebruiken. Voor de subnetten gebruikt u IP-bereiken zo klein als /26.

Belangrijk

U kunt het VNet niet vervangen voor een bestaande werkruimte. Als de huidige werkruimte niet het vereiste aantal actieve clusterknooppunten kan omvatten, raden we u aan om nog een werkruimte te maken in een groter VNet. Volg deze gedetailleerde migratiestappen om resources (notebooks, clusterconfiguraties, taken) van de oude naar de nieuwe werkruimte te kopiëren.

Vereisten voor virtueel netwerk

Het VNet dat u uw Azure Databricks-werkruimte implementeert, moet voldoen aan de volgende vereisten:

• Regio: Het VNet moet zich in dezelfde regio en hetzelfde abonnement bevinden als de Azure Databricks-werkruimte.
• Abonnement: het VNet moet zich in hetzelfde abonnement bevinden als de Azure Databricks-werkruimte.
• Adresruimte: een CIDR-blok tussen /16 en /24 voor het VNet en een CIDR-blok tot aan /26 de twee subnetten: een containersubnet en een hostsubnet. Zie Adresruimte en maximumclusterknooppunten voor hulp bij maximale clusterknooppunten op basis van de grootte van uw VNet en de bijbehorende subnetten.
• Subnetten: Het VNet moet twee subnetten bevatten die zijn toegewezen aan uw Azure Databricks-werkruimte: een containersubnet (ook wel het privésubnet genoemd) en een hostsubnet (ook wel het openbare subnet genoemd). Wanneer u een werkruimte implementeert met beveiligde clusterconnectiviteit, maken zowel het subnet van de container als het hostsubnet gebruik van privé-IP's. U kunt geen subnetten delen tussen werkruimten of andere Azure-resources implementeren op de subnetten die worden gebruikt door uw Azure Databricks-werkruimte. Zie Adresruimte en maximumclusterknooppunten voor hulp bij maximale clusterknooppunten op basis van de grootte van uw VNet en de bijbehorende subnetten.

Adresruimte en maximale clusterknooppunten

Een werkruimte met een kleiner virtueel netwerk kan sneller geen IP-adressen (netwerkruimte) meer hebben dan een werkruimte met een groter virtueel netwerk. Gebruik een CIDR-blok tussen /16 en /24 voor het VNet en een CIDR-blok tot aan /26 de twee subnetten (het containersubnet en het hostsubnet). U kunt een CIDR-blok maken tot /28 uw subnetten, maar Databricks raadt geen subnet aan dat kleiner is dan /26.

Het CIDR-bereik voor uw VNet-adresruimte is van invloed op het maximum aantal clusterknooppunten dat uw werkruimte kan gebruiken.

Voor een Azure Databricks-werkruimte zijn twee subnetten in het VNet vereist: een containersubnet en een hostsubnet. Azure reserveert vijf IP-adressen in elk subnet. Azure Databricks vereist twee IP-adressen voor elk clusterknooppunt: één IP-adres voor de host in het hostsubnet en één IP-adres voor de container in het containersubnet.

• Mogelijk wilt u niet alle adresruimte van uw VNet gebruiken. U kunt bijvoorbeeld meerdere werkruimten in één VNet maken. Omdat u geen subnetten in werkruimten kunt delen, wilt u mogelijk subnetten die niet gebruikmaken van de totale VNet-adresruimte.
• U moet adresruimte toewijzen voor twee nieuwe subnetten die zich in de adresruimte van het VNet bevinden en geen adresruimte van huidige of toekomstige subnetten in dat VNet overlappen.

In de volgende tabel ziet u de maximale subnetgrootte op basis van de netwerkgrootte. In deze tabel wordt ervan uitgegaan dat er geen extra subnetten bestaan die adresruimte in beslag nemen. Gebruik kleinere subnetten als u al bestaande subnetten hebt of als u adresruimte wilt reserveren voor andere subnetten:

VNet-adresruimte (CIDR)	Maximale azure Databricks-subnetgrootte (CIDR) ervan uitgaande dat er geen andere subnetten zijn
/16	/17
/17	/18
/18	/19
/20	/21
/21	/22
/22	/23
/23	/24
/24	/25

Gebruik de volgende tabel om de maximale clusterknooppunten te vinden op basis van de grootte van het subnet. De KOLOM IP-adressen per subnet bevat de vijf gereserveerde IP-adressen van Azure. De meest rechtse kolom geeft het aantal clusterknooppunten aan dat tegelijkertijd kan worden uitgevoerd in een werkruimte die is ingericht met subnetten van die grootte.

Subnetgrootte (CIDR)	IP-adressen per subnet	Maximum aantal Azure Databricks-clusterknooppunten
/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

Uitgaande IP-adressen bij het gebruik van beveiligde clusterconnectiviteit

Als u beveiligde clusterconnectiviteit inschakelt in uw werkruimte die gebruikmaakt van VNet-injectie, raadt Databricks aan dat uw werkruimte een stabiel openbaar IP-adres voor uitgaand verkeer heeft.

Stabiele openbare IP-adressen voor uitgaand verkeer zijn handig omdat u ze kunt toevoegen aan externe acceptatielijsten. Als u bijvoorbeeld vanuit Azure Databricks verbinding wilt maken met Salesforce met een stabiel uitgaand IP-adres.

Waarschuwing

Microsoft heeft aangekondigd dat op 30 september 2025 de standaardconnectiviteit voor uitgaande toegang voor virtuele machines in Azure buiten gebruik wordt gesteld. Bekijk deze aankondiging. Dit betekent dat Azure Databricks-werkruimten die gebruikmaken van standaard uitgaande toegang in plaats van een stabiel openbaar IP-adres voor uitgaand verkeer mogelijk na die datum niet meer werken. Databricks raadt u aan expliciete uitgaande methoden toe te voegen voor uw werkruimten vóór die datum.

Als u een stabiel openbaar IP-adres voor uitgaand verkeer wilt configureren, raadpleegt u Egress met VNet-injectie

Gedeelde resources en peering

Als gedeelde netwerkresources zoals DNS vereist zijn, raadt Databricks u ten zeerste aan om de best practices van Azure voor hub- en spoke-modellen te volgen. Gebruik VNet-peering om de privé-IP-ruimte van het werkruimte-VNet uit te breiden naar de hub, terwijl spokes van elkaar worden geïsoleerd.

Als u andere resources in het VNet hebt of peering gebruikt, raadt Databricks u ten zeerste aan regels voor weigeren toe te voegen aan de netwerkbeveiligingsgroepen (NSG's) die zijn gekoppeld aan andere netwerken en subnetten die zich in hetzelfde VNet bevinden of die zijn gekoppeld aan dat VNet. Voeg regels voor weigeren toe voor verbindingen voor zowel binnenkomende als uitgaande verbindingen, zodat verbindingen worden beperkt tot en met Azure Databricks-rekenresources. Als uw cluster toegang nodig heeft tot resources in het netwerk, voegt u regels toe om alleen de minimale hoeveelheid toegang toe te staan die nodig is om te voldoen aan de vereisten.

Zie Regels voor netwerkbeveiligingsgroepen voor gerelateerde informatie.

Een Azure Databricks-werkruimte maken met behulp van Azure Portal

In deze sectie wordt beschreven hoe u een Azure Databricks-werkruimte maakt in Azure Portal en deze implementeert in uw eigen bestaande VNet. Azure Databricks werkt het VNet bij met twee nieuwe subnetten als deze nog niet bestaan, met behulp van CIDR-bereiken die u opgeeft. De service werkt ook de subnetten bij met een nieuwe netwerkbeveiligingsgroep, het configureren van regels voor inkomend en uitgaand verkeer en implementeert ten slotte de werkruimte in het bijgewerkte VNet. Voor meer controle over de configuratie van het VNet gebruikt u Azure Databricks-opgegeven Arm-sjablonen (Azure Resource Manager) in plaats van de portal. Gebruik bijvoorbeeld bestaande netwerkbeveiligingsgroepen of maak uw eigen beveiligingsregels. Zie Geavanceerde configuratie met behulp van Azure Resource Manager-sjablonen.

De gebruiker die de werkruimte maakt, moet de rol Netwerkbijdrager toewijzen aan het bijbehorende virtuele netwerk of aan een aangepaste rol waaraan de Microsoft.Network/virtualNetworks/subnets/join/action en de Microsoft.Network/virtualNetworks/subnets/write machtigingen zijn toegewezen.

U moet een VNet configureren waarnaar u de Azure Databricks-werkruimte gaat implementeren. U kunt een bestaand VNet gebruiken of een nieuw VNet maken, maar het VNet moet zich in dezelfde regio en hetzelfde abonnement bevinden als de Azure Databricks-werkruimte die u wilt maken. Het VNet moet de grootte hebben van een CIDR-bereik tussen /16 en /24. Zie Vereisten voor virtueel netwerk voor meer vereisten.

Gebruik bestaande subnetten of geef namen en IP-bereiken op voor nieuwe subnetten wanneer u uw werkruimte configureert.

1. Selecteer in Azure Portal + Een resourceanalyse >> maken in Azure Databricks of zoek naar Azure Databricks en klik op Maken of + Toevoegen om het dialoogvenster Azure Databricks Service te starten.

2. Volg de configuratiestappen die worden beschreven in de azure Databricks-werkruimte maken in uw eigen VNet-quickstart .

3. Selecteer op het tabblad Netwerken het VNet dat u wilt gebruiken in het veld Virtueel netwerk .

   Belangrijk

   Als u de netwerknaam niet in de kiezer ziet, controleert u of de Azure-regio die u hebt opgegeven voor de werkruimte overeenkomt met de Azure-regio van het gewenste VNet.

   

4. Geef uw subnetten een naam en geef CIDR-bereiken op in een blok tot grootte /26. Zie Adresruimte en maximumclusterknooppunten voor hulp bij maximale clusterknooppunten op basis van de grootte van uw VNet en de bijbehorende subnetten. De CIDR-bereiken van het subnet kunnen niet worden gewijzigd nadat de werkruimte is geïmplementeerd.

   • Als u bestaande subnetten wilt opgeven, geeft u de exacte namen van de bestaande subnetten op. Wanneer u bestaande subnetten gebruikt, stelt u ook de IP-bereiken in het formulier voor het maken van de werkruimte in zodat deze exact overeenkomen met de IP-bereiken van de bestaande subnetten.
   • Als u nieuwe subnetten wilt maken, geeft u subnetnamen op die nog niet in dat VNet bestaan. De subnetten worden gemaakt met de opgegeven IP-bereiken. U moet IP-bereiken opgeven binnen het IP-bereik van uw VNet en niet al zijn toegewezen aan bestaande subnetten.

   Voor Azure Databricks moeten subnetnamen niet langer zijn dan 80 tekens.

   De subnetten krijgen gekoppelde netwerkbeveiligingsgroepsregels die de regel bevatten om interne clustercommunicatie toe te staan. Azure Databricks heeft gedelegeerde machtigingen voor het bijwerken van beide subnetten via de Microsoft.Databricks/workspaces resourceprovider. Deze machtigingen zijn alleen van toepassing op regels voor netwerkbeveiligingsgroepen die vereist zijn voor Azure Databricks, niet op andere regels voor netwerkbeveiligingsgroepen die u toevoegt of aan de standaardregels voor netwerkbeveiligingsgroepen die zijn opgenomen in alle netwerkbeveiligingsgroepen.

5. Klik op Maken om de Azure Databricks-werkruimte in het VNet te implementeren.

Geavanceerde configuratie met behulp van Azure Resource Manager-sjablonen

Voor meer controle over de configuratie van het VNet gebruikt u de volgende ARM-sjablonen (Azure Resource Manager) in plaats van de automatische VNet-configuratie en werkruimte-implementatie op basis van de portalinterface. Gebruik bijvoorbeeld bestaande subnetten, een bestaande netwerkbeveiligingsgroep of voeg uw eigen beveiligingsregels toe.

Als u een aangepaste Azure Resource Manager-sjabloon of de werkruimtesjabloon voor Azure Databricks VNet-injectie gebruikt om een werkruimte te implementeren in een bestaand VNet, moet u host- en containersubnetten maken, een netwerkbeveiligingsgroep aan elk subnet koppelen en de subnetten delegeren aan de Microsoft.Databricks/workspaces resourceprovider voordat u de werkruimte implementeert. U moet een afzonderlijk paar subnetten hebben voor elke werkruimte die u implementeert.

Alles-in-één-sjabloon

Als u een VNet- en Azure Databricks-werkruimte wilt maken met één sjabloon, gebruikt u de All-in-one-sjabloon voor azure Databricks VNet geïnjecteerde werkruimten.

Sjabloon voor virtueel netwerk

Als u een VNet wilt maken met de juiste subnetten met behulp van een sjabloon, gebruikt u de VNet-sjabloon voor Databricks VNet-injectie.

Azure Databricks-werkruimtesjabloon

Als u een Azure Databricks-werkruimte wilt implementeren in een bestaand VNet met een sjabloon, gebruikt u de werkruimtesjabloon voor Azure Databricks VNet-injectie.

Met de werkruimtesjabloon kunt u een bestaand VNet opgeven en bestaande subnetten gebruiken:

• U moet een afzonderlijk paar host-/containersubnetten hebben voor elke werkruimte die u implementeert. Het wordt niet ondersteund om subnetten te delen tussen werkruimten of om andere Azure-resources te implementeren op de subnetten die worden gebruikt door uw Azure Databricks-werkruimte.
• De host- en containersubnetten van uw VNet moeten netwerkbeveiligingsgroepen hebben gekoppeld en moeten worden gedelegeerd aan de Microsoft.Databricks/workspaces service voordat u deze Azure Resource Manager-sjabloon gebruikt om een werkruimte te implementeren.
• Als u een VNet met correct gedelegeerde subnetten wilt maken, gebruikt u de VNet-sjabloon voor Databricks VNet-injectie.
• Als u een bestaand VNet wilt gebruiken wanneer u de host- en containersubnetten nog niet hebt gedelegeerd, raadpleegt u Een subnetdelegering toevoegen of verwijderen.

Regels voor netwerkbeveiligingsgroepen

In de volgende tabellen worden de huidige regels voor netwerkbeveiligingsgroepen weergegeven die worden gebruikt door Azure Databricks. Als Azure Databricks een regel moet toevoegen of het bereik van een bestaande regel in deze lijst moet wijzigen, ontvangt u vooraf bericht. Dit artikel en de tabellen worden bijgewerkt wanneer een dergelijke wijziging plaatsvindt.

Hoe Azure Databricks regels voor netwerkbeveiligingsgroepen beheert

De NSG-regels die in de volgende secties worden vermeld, vertegenwoordigen die door Azure Databricks automatisch worden uitgevoerd en beheerd in uw NSG, op grond van de overdracht van de host- en containersubnetten van uw VNet aan de Microsoft.Databricks/workspaces service. U bent niet gemachtigd om deze NSG-regels bij te werken of te verwijderen en een poging om dit te doen, wordt geblokkeerd door de subnetdelegering. Azure Databricks moet eigenaar zijn van deze regels om ervoor te zorgen dat Microsoft betrouwbaar kan werken en de Azure Databricks-service in uw VNet kan ondersteunen.

Sommige van deze NSG-regels hebben VirtualNetwork toegewezen als de bron en het doel. Dit is geïmplementeerd om het ontwerp te vereenvoudigen bij het ontbreken van een servicetag op subnetniveau in Azure. Alle clusters worden intern beveiligd door een tweede laag netwerkbeleid, zodat cluster A geen verbinding kan maken met cluster B in dezelfde werkruimte. Dit geldt ook voor meerdere werkruimten als uw werkruimten worden geïmplementeerd in een ander paar subnetten in hetzelfde door de klant beheerde VNet.

Belangrijk

Databricks raadt u ten zeerste aan regels voor weigeren toe te voegen aan de netwerkbeveiligingsgroepen (NSG's) die zijn gekoppeld aan andere netwerken en subnetten die zich in hetzelfde VNet bevinden of die zijn gekoppeld aan dat VNet. Voeg regels voor weigeren toe voor verbindingen voor zowel binnenkomende als uitgaande verbindingen, zodat verbindingen worden beperkt tot en met Azure Databricks-rekenresources. Als uw cluster toegang nodig heeft tot resources in het netwerk, voegt u regels toe om alleen de minimale hoeveelheid toegang toe te staan die nodig is om te voldoen aan de vereisten.

Regels voor netwerkbeveiligingsgroepen voor werkruimten

De informatie in deze sectie is alleen van toepassing op Azure Databricks-werkruimten die zijn gemaakt na 13 januari 2020. Als uw werkruimte is gemaakt vóór de release van SCC (Secure Cluster Connectivity) op 13 januari 2020, raadpleegt u de volgende sectie.

Deze tabel bevat de regels voor de netwerkbeveiligingsgroep voor werkruimten en bevat twee regels voor binnenkomende beveiligingsgroepen die alleen zijn opgenomen als beveiligde clusterconnectiviteit (SCC) is uitgeschakeld.

Richting	Protocol	Bron	Bronpoort	Doel	Dest-poort	Used
Inkomend	Alle	VirtualNetwork	Alle	VirtualNetwork	Alle	Standaardinstelling
Inkomend	TCP	AzureDatabricks (servicetag) Alleen als SCC is uitgeschakeld	Alle	VirtualNetwork	22	Openbare IP
Inkomend	TCP	AzureDatabricks (servicetag) Alleen als SCC is uitgeschakeld	Alle	VirtualNetwork	5557	Openbare IP
Uitgaand	TCP	VirtualNetwork	Alle	AzureDatabricks (servicetag)	443, 3306, 8443-8451	Standaardinstelling
Uitgaand	TCP	VirtualNetwork	Alle	SQL	3306	Standaardinstelling
Uitgaand	TCP	VirtualNetwork	Alle	Storage	443	Standaardinstelling
Uitgaand	Alle	VirtualNetwork	Alle	VirtualNetwork	Alle	Standaardinstelling
Uitgaand	TCP	VirtualNetwork	Alle	EventHub	9093	Standaard

Notitie

Als u uitgaande regels beperkt, raadt Databricks u aan poorten 111 en 2049 te openen om bepaalde bibliotheekinstallaties in te schakelen.

Belangrijk

Azure Databricks is een eigen Microsoft Azure-service die wordt geïmplementeerd in de algemene openbare Azure-cloudinfrastructuur. Alle communicatie tussen onderdelen van de service, inclusief tussen de openbare IP-adressen in het besturingsvlak en het rekenvlak van de klant, blijft binnen de Microsoft Azure-netwerk-backbone. Zie ook het wereldwijde Microsoft-netwerk.

Problemen oplossen

Fouten bij het maken van werkruimten

Voor het subnet <subnet-id> is een of meer van de volgende delegatie(s) [Microsoft.Databricks/workspaces] vereist om te verwijzen naar de koppeling voor servicekoppelingen

Mogelijke oorzaak: u maakt een werkruimte in een VNet waarvan de host- en containersubnetten niet aan de Microsoft.Databricks/workspaces service zijn gedelegeerd. Aan elk subnet moet een netwerkbeveiligingsgroep zijn gekoppeld en elk subnet moet correct zijn gedelegeerd. Zie Vereisten voor het virtuele netwerk voor meer informatie.

Het subnet <subnet-id> wordt al gebruikt door de werkruimte <workspace-id>

Mogelijke oorzaak: u maakt een werkruimte in een VNet met host- en containersubnetten die al worden gebruikt door een bestaande Azure Databricks-werkruimte. U kunt niet meerdere werkruimten delen binnen één subnet. U moet een nieuw paar host- en containersubnetten hebben voor elke werkruimte die u implementeert.

Probleemoplossing

Exemplaren zijn niet bereikbaar: resources zijn niet bereikbaar via SSH.

Mogelijke oorzaak: verkeer van besturingsvlak naar werknemers wordt geblokkeerd. Als je implementeert in een bestaand VNet dat is verbonden met je on-premises netwerk, controleert je je installatie met behulp van de informatie in Je Azure Databricks-werkruimte verbinden met je on-premises netwerk.

Onverwachte startfout: er is een onverwachte fout opgetreden tijdens het instellen van het cluster. Probeer het opnieuw en neem contact op met Azure Databricks als het probleem zich blijft voordoen. Intern foutbericht: Timeout while placing node.

Mogelijke oorzaak: verkeer van werknemers naar Azure Storage-eindpunten wordt geblokkeerd. Als je aangepaste DNS-servers gebruikt, controleer je ook de status van de DNS-servers in je VNet.

Fout bij het starten van de cloudprovider: Er is een fout met de cloudprovider opgetreden tijdens het instellen van het cluster. Raadpleeg de Azure Databricks handleiding voor meer informatie. Azure-foutcode: AuthorizationFailed/InvalidResourceReference.

Mogelijke oorzaak: het VNet of de subnetten bestaan niet meer. Zorg ervoor dat het VNet en de subnetten bestaan.

Cluster is beëindigd. Reden: Spark-opstartfout: Spark kan niet op tijd worden gestart. Dit probleem kan worden veroorzaakt door een defecte Hive-metastore, ongeldige Spark-configuraties of slecht werkende init-scripts. Raadpleeg de logboeken van het Spark-stuurprogramma om dit probleem op te lossen en neem contact op met Databricks als het probleem aanhoudt. Intern foutbericht: Spark failed to start: Driver failed to start in time.

Mogelijke oorzaak: Container kan niet communiceren met het hosten van een exemplaar of DBFS-opslagaccount. Dit probleem kan worden opgelost door een aangepaste route voor het DBFS-opslagaccount aan de subnetten toe te voegen, waarbij de volgende hop het internet is.