Déployer Azure Databricks dans votre réseau virtuel Azure (injection dans le réseau virtuel)
Cet article explique comment déployer un espace de travail Azure Databricks sur votre réseau virtuel Azure, opération également appelée injection de réseau virtuel.
Personnalisation de réseau avec l’injection de réseau virtuel
Le déploiement par défaut d’Azure Databricks est un service complètement managé sur Azure. Un réseau virtuel (VNet) Azure est déployé sur un groupe de ressources verrouillé. Toutes les ressources de plan de calcul classiques sont associées à ce réseau virtuel. Si vous exigez une personnalisation de réseau, vous pouvez déployer des ressources de plan de calcul classiques Azure Databricks sur votre propre réseau virtuel. Vous pouvez ainsi effectuer les opérations suivantes :
- Connectez Azure Databricks à d’autres services Azure (par exemple, Stockage Azure) de manière plus sécurisée en utilisant des points de terminaison de service ou des points de terminaison privés Azure.
- Connectez-vous à des sources de données locales en tirant parti des routes définies par l’utilisateur. Consultez Paramètres de routage définis par l’utilisateur pour Azure Databricks.
- Connecter Azure Databricks à une appliance de réseau virtuel pour inspecter tout le trafic sortant et prendre des mesures appropriées pour autoriser et refuser des règles. Voir Option : acheminer le trafic Azure Databricks en utilisant une appliance virtuelle ou un pare-feu
- Configurer Azure Databricks pour utiliser un DNS personnalisé. Consultez Option : configurer un système DNS personnalisé.
- Configurer des règles de groupe de sécurité réseau (NSG) pour spécifier des restrictions sur le trafic de sortie.
Le déploiement des ressources du plan de calcul classique Azure Databricks sur votre propre réseau virtuel vous permet également de tirer parti de plages CIDR flexibles. Pour le réseau virtuel, vous pouvez utiliser la taille de plage CIDR /16-/24. Pour les sous-réseaux, utilisez des plages d’adresses IP aussi petites que /26.
Important
Vous ne pouvez pas remplacer le réseau virtuel pour un espace de travail existant. Si votre espace de travail actuel ne peut pas prendre en compte le nombre requis de nœuds de cluster actifs, nous vous recommandons de créer un autre espace de travail dans un réseau virtuel plus étendu. Suivez cette procédure de migration détaillée pour copier les ressources (notebooks, configurations de cluster, tâches) de l’ancien espace de travail vers le nouveau.
Conditions requises pour le réseau virtuel
Le réseau virtuel sur lequel vous déployez votre espace de travail Azure Databricks doit respecter les conditions suivantes :
- Région : le réseau virtuel doit résider dans la même région et le même abonnement que l’espace de travail Azure Databricks.
- Abonnement : Le réseau virtuel doit se trouver dans le même abonnement que l’espace de travail Azure Databricks.
- Espace d’adressage : Un bloc CIDR entre
/16et/24pour le réseau virtuel et un bloc CIDR pouvant aller jusqu’à/26pour les deux sous-réseaux (un sous-réseau de conteneurs et un sous-réseau d’hôtes). Pour obtenir des instructions sur le nombre maximal de nœuds de cluster en fonction de la taille de votre réseau virtuel et de ses sous-réseaux, consultez Espace d’adressage et nombre maximal de nœuds de cluster. - Sous-réseaux : Le réseau virtuel doit inclure deux sous-réseaux dédiés à votre espace de travail Azure Databricks, à savoir un sous-réseau de conteneurs (parfois appelé « sous-réseau privé ») et un sous-réseau d’hôtes (parfois appelé « sous-réseau public »). Quand vous déployez un espace de travail en tirant parti de la connectivité sécurisée des clusters, le sous-réseau de conteneurs et le sous-réseau d’hôtes utilisent des adresses IP privées. Vous ne pouvez pas partager des sous-réseaux entre plusieurs espaces de travail ni déployer d’autres ressources Azure sur les sous-réseaux utilisés par votre espace de travail Azure Databricks. Pour obtenir des instructions sur le nombre maximal de nœuds de cluster en fonction de la taille de votre réseau virtuel et de ses sous-réseaux, consultez Espace d’adressage et nombre maximal de nœuds de cluster.
Espace d’adressage et nombre maximal de nœuds de cluster
Un espace de travail doté d’un réseau virtuel plus restreint peut épuiser sa réserve d’adresses IP (espace réseau) plus rapidement qu’un espace de travail doté d’un réseau virtuel plus étendu. Utilisez un bloc CIDR entre /16 et /24 pour le réseau virtuel et un bloc CIDR pouvant aller jusqu’à /26 pour les deux sous-réseaux (le sous-réseau de conteneurs et le sous-réseau d’hôtes). Vous pouvez créer un bloc de routage CIDR jusqu’à /28 pour vos sous-réseaux, cependant Databricks ne recommande pas un sous-réseau plus petit que /26.
La plage CIDR de votre espace d’adressage de réseau virtuel affecte le nombre maximal de nœuds de cluster que votre espace de travail peut utiliser.
Un espace de travail Azure Databricks nécessite deux sous-réseaux dans le réseau virtuel : un sous-réseau de conteneurs et un sous-réseau d’hôtes. Azure réserve cinq adresses IP dans chaque sous-réseau. Azure Databricks nécessite deux adresses IP pour chaque nœud de cluster : une adresse IP pour l’hôte dans le sous-réseau d’hôtes et une adresse IP pour le conteneur dans le sous-réseau de conteneurs.
- Il est possible que vous ne souhaitiez pas utiliser tout l’espace d’adressage de votre réseau virtuel. Par exemple, vous voulez peut-être créer plusieurs espaces de travail dans un même réseau virtuel. Étant donné que vous ne pouvez pas partager de sous-réseaux entre plusieurs espaces de travail, il est possible que vous vouliez des sous-réseaux qui n’utilisent pas la totalité de l’espace d’adressage du réseau virtuel.
- Vous devez allouer un espace d’adressage pour deux nouveaux sous-réseaux qui se trouvent dans l’espace d’adressage du réseau virtuel et qui ne chevauchent pas l’espace d’adressage des sous-réseaux actuels ou futurs dans ce réseau virtuel.
Le tableau suivant indique la taille maximale du sous-réseau en fonction de la taille du réseau. Ce tableau suppose qu’aucun sous-réseau supplémentaire n’occupe l’espace d’adressage. Utilisez des sous-réseaux plus petits si vous avez des sous-réseaux préexistants ou si vous souhaitez réserver un espace d’adressage pour d’autres sous-réseaux :
| Espace d’adressage du réseau virtuel (CIDR) | Taille maximale du sous-réseau Azure Databricks (CIDR), en supposant aucun autre sous-réseau |
|---|---|
/16 |
/17 |
/17 |
/18 |
/18 |
/19 |
/20 |
/21 |
/21 |
/22 |
/22 |
/23 |
/23 |
/24 |
/24 |
/25 |
Pour trouver le nombre maximal de nœuds de cluster en fonction de la taille du sous-réseau, utilisez le tableau suivant. La colonne Adresses IP par sous-réseau inclut les cinq adresses IP réservées à Azure. La colonne la plus à droite indique le nombre de nœuds de cluster qui peuvent s’exécuter simultanément dans un espace de travail provisionné avec des sous-réseaux de cette taille.
| Taille du sous-réseau (CIDR) | Adresses IP par sous-réseau | Nombre maximal de nœuds de cluster Azure Databricks |
|---|---|---|
/17 |
32 768 | 32 763 |
/18 |
16384 | 16 379 |
/19 |
8 192 | 8187 |
/20 |
4096 | 4 091 |
/21 |
2 048 | 2 043 |
/22 |
1 024 | 1019 |
/23 |
512 | 507 |
/24 |
256 | 251 |
/25 |
128 | 123 |
/26 |
64 | 59 |
Adresses IP de sortie lors de l’utilisation d’une connectivité de cluster sécurisée
Si vous activez la connectivité de cluster sécurisée sur votre espace de travail qui utilise l’injection de réseau virtuel, Databricks recommande que votre espace de travail dispose d’une adresse IP publique de sortie stable.
Les adresses IP publiques de sortie stables sont utiles, car vous pouvez les ajouter à des listes d’autorisation externes. Par exemple, pour vous connecter à Salesforce à partir d’Azure Databricks avec une adresse IP sortante stable. Si vous configurez des listes d’accès IP, ces adresses IP publiques doivent être ajoutées à une liste d’autorisation. Voir Configurer des listes d’accès IP pour les espaces de travail.
Avertissement
Microsoft a annoncé que le 30 septembre 2025, la connectivité d’accès sortante par défaut pour les machines virtuelles dans Azure sera supprimée. Consultez cette annonce. Cela signifie que les espaces de travail Azure Databricks qui utilisent l’accès sortant par défaut, plutôt qu’une adresse IP publique de sortie stable, peuvent ne pas continuer à fonctionner après cette date. Databricks vous recommande d’ajouter des méthodes sortantes explicites pour vos espaces de travail avant cette date.
Pour configurer une adresse IP publique de sortie stable, voir Sortie avec injection dans le réseau virtuel
Ressources partagées et peering
Si des ressources réseau partagées comme DNS sont requises, Databricks vous recommande vivement de suivre les meilleures pratiques Azure pour le modèle hub-and-spoke. Utilisez le peering de réseaux virtuels pour étendre l’espace IP privé du réseau virtuel de l’espace de travail au hub tout en conservant les spokes isolés les uns des autres.
Si vous disposez d’autres ressources dans le réseau virtuel ou utilisez le peering, Databricks recommande vivement d’ajouter des règles de refus aux groupes de sécurité réseau (NSG) attachés à d’autres réseaux et sous-réseaux qui se trouvent dans le même réseau virtuel ou qui sont appairés à ce réseau virtuel. Ajoutez des règles de refus pour les connexions entrantes et sortantes afin qu’elles limitent les connexions à la fois aux ressources de calcul Azure Databricks et à partir de celles-ci. Si votre cluster a besoin d’accéder aux ressources sur le réseau, ajoutez des règles pour autoriser uniquement la quantité minimale d’accès requise pour répondre aux exigences.
Pour plus d’informations, consultez Règles de groupe de sécurité réseau.
Créer un espace de travail Azure Databricks à l’aide du Portail Azure
Cette section décrit comment créer un espace de travail Azure Databricks dans le portail Azure et comment le déployer sur votre propre réseau virtuel existant. Azure Databricks met à jour le réseau virtuel avec deux nouveaux sous-réseaux (s’ils n’existent pas encore) à l’aide des plages CIDR que vous spécifiez. Le service met également à jour les sous-réseaux avec un nouveau groupe de sécurité réseau en configurant des règles de trafic entrant et de trafic sortant, puis déploie l’espace de travail sur le réseau virtuel mis à jour. Pour obtenir plus de contrôle sur la configuration du réseau virtuel, utilisez les modèles ARM (Azure Resource Manager) fournis par Azure Databricks au lieu du portail. Par exemple, utilisez des groupes de sécurité réseau existants ou créez vos propres règles de sécurité. Consultez Configuration avancée avec des modèles Azure Resource Manager.
L’utilisateur qui crée l’espace de travail doit se voir attribuer le rôle Contributeur de réseaux sur le réseau virtuel correspondant ou un rôle personnalisé auquel les autorisations Microsoft.Network/virtualNetworks/subnets/join/action et Microsoft.Network/virtualNetworks/subnets/write sont affectées.
Vous devez configurer un réseau virtuel sur lequel vous déploierez l’espace de travail Azure Databricks. Vous pouvez utiliser un réseau virtuel existant ou en créer un, mais il doit être dans la même région et le même abonnement que l’espace de travail Azure Databricks que vous prévoyez de créer. Le réseau virtuel doit être dimensionné avec une plage CIDR comprise entre /16 et /24. Pour les autres exigences, consultez la configuration requise pour le réseau virtuel.
Utilisez des sous-réseaux existants ou de nouveaux sous-réseaux, en spécifiant les noms et les plages d’adresses IP quand vous configurez votre espace de travail.
Dans le portail Azure, sélectionnez + Créer une ressource > Analytics > Azure Databricks ou recherchez Azure Databricks, puis cliquez sur Créer ou + Ajouter pour ouvrir la boîte de dialogue du service Azure Databricks.
Effectuez les étapes de configuration décrites dans le guide de démarrage rapide Créer un espace de travail Azure Databricks dans votre propre réseau virtuel.
Sous l’onglet Réseau, sélectionnez le réseau virtuel que vous souhaitez utiliser dans le champ Réseau virtuel.
Important
Si le nom réseau ne figure pas dans le sélecteur, vérifiez que la région Azure que vous avez spécifiée pour l’espace de travail correspond à la région Azure du réseau virtuel désiré.
Nommez vos sous-réseaux et indiquez des plages CIDR dans un bloc d’une taille maximale de
/26. Pour obtenir des instructions sur le nombre maximal de nœuds de cluster en fonction de la taille de votre réseau virtuel et de ses sous-réseaux, consultez Espace d’adressage et nombre maximal de nœuds de cluster. Les plages CIDR du sous-réseau ne peuvent pas être modifiées après le déploiement de l’espace de travail.- Pour spécifier des sous-réseaux existants, indiquez le nom exact de chaque sous-réseau. Si vous utilisez des sous-réseaux existants, définissez également dans le formulaire de création de l’espace de travail des plages d’adresses IP qui correspondent exactement à celles des sous-réseaux existants.
- Pour créer des sous-réseaux, entrez des noms qui ne sont pas déjà pris par d’autres sous-réseaux dans ce réseau virtuel. Les sous-réseaux sont créés avec les plages d’adresses IP spécifiées. Vous devez spécifier des plages d’adresses IP dans la plage d’adresses IP de votre réseau virtuel qui ne sont pas déjà allouées aux sous-réseaux existants.
Avec Azure Databricks, les noms de sous-réseau ne doivent pas dépasser 80 caractères.
Les sous-réseaux obtiennent les règles de groupe de sécurité réseau associées qui incluent la règle autorisant la communication interne au cluster. Azure Databricks dispose d’autorisations déléguées pour mettre à jour les deux sous-réseaux via le fournisseur de ressources
Microsoft.Databricks/workspaces. Ces autorisations ne s’appliquent qu’aux règles de groupe de sécurité réseau requises par Azure Databricks. Elles ne s’appliquent pas aux autres règles de groupe de sécurité réseau que vous ajoutez ni à celles par défaut incluses avec tous les groupes de sécurité réseau.Cliquez sur Créer pour déployer l’espace de travail Azure Databricks sur le réseau virtuel.
Configuration avancée avec des modèles Azure Resource Manager
Pour davantage de contrôle sur la configuration du réseau virtuel, utiliser les modèles ARM (Azure Resource Manager) suivants à la place du déploiement de l’espace de travail et de la configuration de réseau virtuel automatiques basés sur l’interface utilisateur du portail. Vous pouvez par exemple utiliser des sous-réseaux existants, un groupe de sécurité réseau existant ou ajouter vos propres règles de sécurité.
Si vous utilisez un modèle ARM personnalisé ou le modèle d’espace de travail Azure Databricks pour injection dans le réseau virtuel afin de déployer un espace de travail sur un réseau virtuel existant, vous devez créer des sous-réseaux d’hôtes et de conteneurs, attacher un groupe de sécurité réseau à chaque sous-réseau et déléguer les sous-réseaux au fournisseur de ressources Microsoft.Databricks/workspacesavant de déployer l’espace de travail. Vous devez avoir une paire distincte de sous-réseaux pour chaque espace de travail que vous déployez.
Modèle tout-en-un
Pour créer un réseau virtuel et un espace de travail Azure Databricks avec un seul modèle, utilisez le modèle tout-en-un d’espace de travail Azure Databricks pour injection dans le réseau virtuel.
Modèle de réseau virtuel
Pour créer un réseau virtuel avec les sous-réseaux appropriés à l’aide d’un modèle, utilisez le modèle de réseau virtuel Databricks pour injection dans le réseau virtuel.
Modèle d’espace de travail Azure Databricks
Pour déployer un espace de travail Azure Databricks sur un réseau virtuel existant à l’aide d’un modèle, utilisez le modèle d’espace de travail Azure Databricks pour injection dans le réseau virtuel.
Le modèle d’espace de travail vous permet de spécifier un réseau virtuel existant et d’utiliser des sous-réseaux existants :
- Vous devez avoir une paire distincte de sous-réseaux d’hôtes/de conteneurs pour chaque espace de travail que vous déployez. Le partage de sous-réseaux entre plusieurs espaces de travail et le déploiement d’autres ressources Azure sur les sous-réseaux utilisés par votre espace de travail Azure Databricks ne sont pas pris en charge.
- Vous devez attacher des groupes de sécurité réseau aux sous-réseaux d’hôtes et de conteneurs de votre réseau virtuel et déléguer ces sous-réseaux au service
Microsoft.Databricks/workspacesavant de pouvoir utiliser ce modèle ARM pour déployer un espace de travail. - Pour créer un réseau virtuel avec des sous-réseaux correctement délégués, utilisez le modèle de réseau virtuel Databricks pour injection dans le réseau virtuel.
- Pour utiliser un réseau virtuel existant lorsque vous n’avez pas encore délégué les sous-réseaux d’hôte et de conteneur, consultez Ajouter ou supprimer une délégation de sous-réseau.
Règles du groupe de sécurité réseau
Les tableaux suivants présentent les règles de groupe de sécurité réseau actuelles utilisées par Azure Databricks. Si Azure Databricks doit ajouter une règle ou modifier l’étendue d’une règle existante dans cette liste, vous recevrez une notification préalable. Cet article et les tableaux seront mis à jour chaque fois qu’une telle modification se produit.
Comment Azure Databricks gère les règles de groupe de sécurité réseau
Les règles NSG listées dans les sections suivantes correspondent à celles provisionnées automatiquement par Azure Databricks dans votre NSG, en vertu de la délégation des sous-réseaux d’hôtes et de conteneurs de votre réseau virtuel au service Microsoft.Databricks/workspaces. Vous n’avez pas l’autorisation de mettre à jour ou de supprimer ces règles de groupe de sécurité réseau et toute tentative est bloquée par la délégation de sous-réseau. Azure Databricks doit être propriétaire de ces règles pour garantir que Microsoft peut exploiter et prendre en charge de manière fiable le service Azure Databricks dans votre réseau virtuel.
Dans certaines de ces règles NSG, VirtualNetwork est affecté à la fois comme source et comme destination. Cette implémentation a pour but de simplifier la conception en l’absence d’une étiquette de service au niveau du sous-réseau dans Azure. Tous les clusters sont protégés par une deuxième couche de stratégie réseau en interne. Ainsi, le cluster A ne peut pas se connecter au cluster B dans le même espace de travail. Cela s’applique également à plusieurs espaces de travail si ceux-ci sont déployés dans une paire différente de sous-réseaux dans le même réseau virtuel géré par le client.
Important
Databricks vous recommande vivement d’ajouter des règles de refus aux groupes de sécurité réseau (NSG) attachés à d’autres réseaux et sous-réseaux qui se trouvent dans le même réseau virtuel ou qui sont appairés à celui-ci. Ajoutez des règles de refus pour les connexions entrantes et sortantes afin qu’elles limitent les connexions à la fois aux ressources de calcul Azure Databricks et à partir de celles-ci. Si votre cluster a besoin d’accéder aux ressources sur le réseau, ajoutez des règles pour autoriser uniquement la quantité minimale d’accès requise pour répondre aux exigences.
Règles du groupe de sécurité réseau pour des espaces de travail
Les informations de cette section s’appliquent uniquement aux espaces de travail Azure Databricks créés après le 13 janvier 2020. Si votre espace de travail a été créé avant la publication de la connectivité sécurisée des clusters (SCC) le 13 janvier 2020, consultez la section suivante.
Ce tableau répertorie les règles de groupe de sécurité règle pour des espaces de travail et inclut deux règles entrantes de groupe de sécurité incluses uniquement si la connectivité sécurisée des clusters (SCC) est désactivée.
| Sens | Protocol | Source | Port source | Destination | Port de destination | Utilisé |
|---|---|---|---|---|---|---|
| Trafic entrant | Quelconque | VirtualNetwork | Quelconque | VirtualNetwork | Quelconque | Default |
| Trafic entrant | TCP | AzureDatabricks (étiquette de service) Uniquement si SCC est désactivé |
Quelconque | VirtualNetwork | 22 | Adresse IP publique |
| Trafic entrant | TCP | AzureDatabricks (étiquette de service) Uniquement si SCC est désactivé |
Quelconque | VirtualNetwork | 5557 | Adresse IP publique |
| Règle de trafic sortant | TCP | VirtualNetwork | Quelconque | AzureDatabricks (étiquette de service) | 443, 3306, 8443-8451 | Par défaut |
| Règle de trafic sortant | TCP | VirtualNetwork | Quelconque | SQL | 3306 | Default |
| Règle de trafic sortant | TCP | VirtualNetwork | Quelconque | Stockage | 443 | Default |
| Règle de trafic sortant | Quelconque | VirtualNetwork | Quelconque | VirtualNetwork | Quelconque | Default |
| Règle de trafic sortant | TCP | VirtualNetwork | Quelconque | Event Hub | 9093 | Par défaut |
Remarque
Si vous limitez les règles de trafic sortant, Databricks vous recommande d’ouvrir les ports 111 et 2049, afin d’activer certaines installations de bibliothèque.
Important
Azure Databricks est un service Microsoft Azure interne déployé sur l’infrastructure globale de cloud public Azure. Toutes les communications entre les composants du service, notamment entre les adresses IP publiques dans le plan de contrôle et le plan de calcul client, restent dans le segment principal du réseau Microsoft Azure. Voir aussi Réseau Microsoft mondial.
Résolution des problèmes
Erreurs de création de l’espace de travail
Le sous-réseau <subnet-id> exige que les délégations suivantes référencent le lien d’association du service [Microsoft.Databricks/workspaces]
Cause possible : Vous créez un espace de travail dans un réseau virtuel dont les sous-réseaux d’hôtes et de conteneurs n’ont pas été délégués au service Microsoft.Databricks/workspaces. Chaque sous-réseau doit avoir un groupe de sécurité réseau attaché et doit être correctement délégué. Pour plus d’informations, consultez la configuration requise pour le réseau virtuel.
Le sous-réseau <subnet-id> est déjà utilisé par l’espace de travail <workspace-id>
Cause possible : Vous créez un espace de travail dans un réseau virtuel avec des sous-réseaux d’hôtes et de conteneurs qui sont déjà utilisés par un espace de travail Azure Databricks existant. Vous ne pouvez pas partager plusieurs espaces de travail dans un même sous-réseau. Vous devez avoir une nouvelle paire de sous-réseaux d’hôtes et de conteneurs pour chaque espace de travail que vous déployez.
Dépannage
Instances inaccessibles : Les ressources ne sont pas accessibles sur SSH.
Cause probable : le trafic à partir du plan de contrôle vers les rôles de travail est bloqué. Si vous déployez sur un réseau virtuel existant connecté à votre réseau local, passez en revue votre configuration en utilisant les informations fournies dans Connecter votre espace de travail Azure Databricks à votre réseau local.
Échec inattendu du lancement : Une erreur inattendue a été rencontrée lors de la configuration du cluster. Veuillez réessayer. Si le problème persiste, contactez Azure Databricks. Message d’erreur interne : Timeout while placing node.
Cause probable : le trafic des points de terminaison des rôles de travail jusqu’à ceux du Stockage Azure est bloqué. Si vous utilisez des serveurs DNS personnalisés, vérifiez également l’état des serveurs DNS dans votre réseau virtuel.
Échec du lancement du fournisseur cloud : une erreur de fournisseur de cloud s’est produite lors de la configuration du cluster. Veuillez consulter le guide relatif à Azure Databricks pour plus d’informations. Code d’erreur Azure : AuthorizationFailed/InvalidResourceReference.
Cause possible : Le réseau virtuel ou les sous-réseaux n’existent plus. Vérifiez que le réseau virtuel et les sous-réseaux existent.
Cluster arrêté. Raison : échec de démarrage Spark : Spark n’a pas pu démarrer dans le temps. Ce problème peut provenir d’un disfonctionnement de metastore Hive, de configurations Spark non valides ou d’un disfonctionnement de scripts init. Consultez les journaux du pilote Spark pour résoudre ce problème, et contactez Databricks si le problème persiste. Message d’erreur interne : Spark failed to start: Driver failed to start in time.
Cause possible : un conteneur ne peut pas communiquer avec l’instance d’hébergement ou le compte de stockage de l’espace de travail. Veuillez corriger ceci en ajoutant un itinéraire personnalisé aux sous-réseaux pour le compte de stockage de l’espace de travail dans lequel le tronçon suivant est Internet.