Déployer Azure Databricks dans votre réseau virtuel Azure (injection dans le réseau virtuel)

Le déploiement par défaut d’Azure Databricks est un service complètement managé sur Azure : toutes les ressources de plan de données, notamment un réseau virtuel auquel tous les clusters seront associés, sont déployées sur un groupe de ressources verrouillé. Cependant, si vous devez personnaliser votre réseau, vous pouvez déployer les ressources de plan de données Azure Databricks dans votre propre réseau virtuel (ce qui parfois est appelé l’injection dans le réseau virtuel). Vous pouvez ainsi :

Le déploiement des ressources de plan de données Azure Databricks sur votre propre réseau virtuel vous permet également de tirer parti de plages d’adresses CIDR flexibles (n’importe où entre /16-/24 pour le réseau virtuel et jusqu’à /26 pour les sous-réseaux).

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 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 /16 et /24 pour le réseau virtuel et un bloc CIDR pouvant aller jusqu’à /26 pour 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 »). Toutefois, pour un espace de travail qui utilise la connectivité sécurisée des clusters, le sous-réseau de conteneurs et le sous-réseau d’hôtes sont privés. 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. 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.

    Important

    Il existe une relation un-à-un entre ces sous-réseaux et un espace de travail Azure Databricks. Vous ne pouvez pas partager plusieurs espaces de travail dans un même sous-réseau. 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.

Pour plus d’informations sur les modèles permettant de configurer votre réseau virtuel et de déployer votre espace de travail, consultez Modèles Azure Resource Manager fournis par Azure Databricks.

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

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 (également appelé « sous-réseau privé ») et un sous-réseau d’hôtes (également appelé « sous-réseau public »). Si l’espace de travail utilise la connectivité sécurisée des clusters, les sous-réseaux de conteneurs et d’hôtes sont privés.
  • Azure réserve cinq adresses IP dans chaque sous-réseau.
  • Dans chaque sous-réseau, Azure Databricks nécessite une adresse IP par nœud de cluster. Au total, vous avez 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.
  • Vous pouvez choisir de ne 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, vous pouvez choisir 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

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 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 de l’interface utilisateur 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.

Important

L’utilisateur qui crée l’espace de travail doit se voir attribuer le rôle de contributeur de réseaux ou un rôle personnalisé auquel l’action Microsoft.Network/virtualNetworks/subnets/join/action est affectée.

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.

Vous pouvez utiliser des sous-réseaux existants ou de nouveaux sous-réseaux en spécifiant des noms et des plages d’adresses IP quand vous configurez votre espace de travail.

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

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

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

    Select virtual network

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

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

    Important

    Avec Azure Databricks, les noms de sous-réseau ne doivent pas dépasser 30 caractères. C’est inférieur à la longueur maximale autorisée pour les sous-réseaux dans le portail Azure. Avant d’utiliser un sous-réseau existant, renommez-le si son nom comporte plus de 30 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 par le biais du 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.

  5. Cliquez sur Créer pour déployer l’espace de travail Azure Databricks sur le réseau virtuel.

    Notes

    Si le déploiement d’un espace de travail échoue, l’espace de travail est tout de même créé avec un état d’échec. Supprimez l’espace de travail défaillant et créez un espace de travail qui résout les erreurs de déploiement. Lorsque vous supprimez l’espace de travail défaillant, le groupe de ressources managé et toutes les ressources déployées correctement sont également supprimés.

Configuration avancée avec des modèles Azure Resource Manager

Si vous souhaitez davantage de contrôle sur la configuration du réseau virtuel, vous pouvez 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 :

Règles de 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.

Dans cette section :

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 NSG, toute tentative étant 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

Si le réseau virtuel de l’espace de travail est appairé à un autre réseau géré par le client ou si des ressources autres que des ressources Azure Databricks sont provisionnées dans d’autres sous-réseaux, Databricks vous recommande d’ajouter des règles de trafic entrant Refuser aux NSG attachés aux autres réseaux et sous-réseaux pour bloquer le trafic source provenant des clusters Azure Databricks. Il est inutile d’ajouter de telles règles pour les ressources auxquelles vous souhaitez que vos clusters Azure Databricks se connectent.

Règles de groupe de sécurité réseau pour les espaces de travail créés après le 13 janvier 2020

Le tableau suivant s’applique 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 le tableau de la section suivante.

Important

Le tableau suivant comprend deux règles de groupe de sécurité de trafic entrant qui sont 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é
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 Default
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 Default

Règles de groupe de sécurité réseau pour les espaces de travail créés avant le 13 janvier 2020

Le tableau suivant s’applique uniquement aux espaces de travail Azure Databricks créés avant le 13 janvier 2020. Si votre espace de travail a été créé le 13 janvier 2020 ou après cette date, consultez le tableau précédent.

Sens Protocol Source Port source Destination Port de destination Utilisé
Entrant Quelconque VirtualNetwork Quelconque VirtualNetwork Quelconque Default
Trafic entrant TCP ControlPlane IP Quelconque VirtualNetwork 22 Adresse IP publique
Trafic entrant TCP ControlPlane IP Quelconque VirtualNetwork 5557 Adresse IP publique
Règle de trafic sortant TCP VirtualNetwork Quelconque IP Webapp 443 Default
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 Default

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 données client, restent dans le segment principal du réseau Microsoft Azure. Voir aussi Réseau Microsoft mondial.

Dépannage

Erreurs de création de l’espace de travail

Le sous-réseau requiert l'une des délégations suivantes [Microsoft.Databricks/workspaces] pour référencer le lien d'association de services

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 est déjà utilisé par l’espace de travail

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 de 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 DBFS. Veuillez corriger ceci en ajoutant un itinéraire personnalisé aux sous-réseaux pour le compte de stockage DBFS où le tronçon suivant est Internet.