Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Le runtime d’intégration (IR) est l’infrastructure de calcul utilisée par Microsoft Purview pour alimenter l’analyse des données dans différents environnements réseau. Cet article présente les différents types de runtime d’intégration disponibles dans Microsoft Purview et fournit des conseils sur la façon de choisir la configuration du runtime d’intégration appropriée pour votre scénario.
Types de runtimes d’intégration
Purview fournit les types de runtimes d’intégration suivants :
Azure runtime d’intégration : le runtime d’intégration Azure est un calcul entièrement managé et élastique que vous pouvez utiliser pour analyser des sources de données Azure ou non Azure. Le runtime d’intégration Azure prend en charge les connexions aux magasins de données et aux services de calcul avec des points de terminaison accessibles publiquement. Il s’agit du runtime d’intégration par défaut dont vous n’avez pas besoin pour créer quoi que ce soit pour commencer.
Runtime d’intégration managed Réseau virtuel : vous pouvez créer un runtime d’intégration Managed Réseau virtuel, qui réside dans un Réseau virtuel managé Purview. Il peut utiliser des points de terminaison privés pour se connecter et analyser en toute sécurité les sources de données prises en charge. Pour en savoir plus, consultez Managed Réseau virtuel et points de terminaison privés managés.
Runtime d’intégration auto-hébergé : le runtime d’intégration auto-hébergé peut être utilisé pour analyser des sources de données dans un réseau local ou un réseau virtuel. Vous pouvez l’installer sur un ordinateur local ou une machine virtuelle à l’intérieur de votre réseau privé. Pour plus d’informations, consultez Créer et gérer des runtimes d’intégration auto-hébergés.
Runtime d’intégration auto-hébergé pris en charge par Kubernetes : ce runtime d’intégration est hébergé sur un cluster Kubernetes et peut être utilisé pour analyser des sources de données dans un réseau local ou un réseau virtuel. La prise en charge de Kubernetes améliore les performances globales et permet au runtime d’intégration de s’adapter au travail. Pour en savoir plus , consultez Créer et gérer des runtimes d’intégration auto-hébergés pris en charge par Kubernetes.
Runtime d’intégration AWS : le runtime d’intégration AWS est un runtime d’intégration entièrement managé et élastique hébergé par Microsoft Purview dans AWS. Elle s’applique lors de l’analyse de sources de données Amazon telles que S3, RDS.
Choisir le runtime d’intégration approprié
Choisissez le runtime d’intégration adapté à vos besoins. Tenez compte de votre architecture et de vos exigences existantes pour l’intégration des données. Réfléchissez également à la façon de répondre aux besoins croissants de l’entreprise et à toute augmentation future de la charge de travail.
Les considérations suivantes peuvent vous aider à prendre votre décision :
Quels types de sources de données souhaitez-vous analyser ?
Consultez la section Sources de données prises en charge pour en savoir plus sur les types de runtime d’intégration pris en charge pour les sources de données que vous souhaitez analyser.
Quel est le contrôle d’accès réseau sur votre source de données ?
Les différentes sources de données ont des paramètres de pare-feu réseau différents pour les protéger contre les accès aléatoires sur Internet. Ces paramètres s’appliquent aux magasins de données locaux, cloud et SaaS. Le tableau suivant répertorie certaines options de pare-feu courantes. Choisissez le type de runtime d’intégration pris en charge en fonction de votre scénario.
Pare-feu de source de données runtime d’intégration Azure Runtime d’intégration Réseau virtuel managé SHIR Kubernetes pris en charge par SHIR Autoriser l’accès public ✓ ✓ ✓ ✓ Autoriser Azure service ou service approuvé ✓ ✓ ✓ ✓ Autoriser l’accès à partir d’un réseau virtuel Azure spécifique ✓ (avec prise en charge des points de terminaison privés managés) ✓ ✓ Autoriser une plage d’adresses IP/IP spécifiques ✓ ✓ Autre accès réseau local ou privé ✓ ✓ Quel est le paramètre de pare-feu de votre Microsoft Purview ?
Purview fournit différentes options de pare-feu réseau. Pour plus d’informations, consultez Configurer le pare-feu Microsoft Purview. Choisissez le type de runtime d’intégration pris en charge en fonction de votre scénario.
Pare-feu Purview runtime d’intégration Azure Runtime d’intégration Réseau virtuel managé SHIR Kubernetes pris en charge par SHIR Activé à partir de tous les réseaux ✓ ✓ ✓ ✓ Désactivé à partir de tous les réseaux ✓ (point de terminaison privé managé requis) ✓ (besoin de créer un point de terminaison privé à partir de votre réseau) ✓ (besoin de créer un point de terminaison privé à partir de votre réseau) Quel niveau de sécurité avez-vous besoin lors de la transmission des données ?
L’emplacement du runtime d’intégration définit l’emplacement de son calcul principal et l’emplacement où les opérations d’analyse sont effectuées. Pour prendre en compte la résidence des données :
Lorsque vous utilisez Azure IR, Purview détecte automatiquement l’emplacement de la source de données et utilise le runtime d’intégration dans cette région. Si Purview ne peut pas détecter la région, il utilise la région du compte Purview.
Lorsque vous utilisez Managed Réseau virtuel IR, il s’exécute dans la région que vous configurez pour le réseau virtuel managé.
Lorsque vous utilisez SHIR, vous pouvez décider entièrement de l’emplacement dans vos machines virtuelles locales ou Azure.
Pour vous protéger contre, par exemple, les attaques de l’intercepteur lors de la transmission des données, utilisez un point de terminaison privé et une liaison privée pour garantir la sécurité des données.
Vous pouvez créer des points de terminaison privés managés pour vos magasins de données lorsque vous utilisez Managed Réseau virtuel IR. Le service Purview gère les points de terminaison privés au sein du réseau virtuel managé.
Vous pouvez également créer des points de terminaison privés dans votre réseau virtuel et le SHIR peut les utiliser pour accéder aux magasins de données.
Quel niveau de maintenance pouvez-vous fournir ?
La maintenance de l’infrastructure, des serveurs et de l’équipement est l’une des tâches importantes du service informatique d’une entreprise. Cela prend généralement beaucoup de temps et d’efforts.
- Lorsque vous utilisez Azure ir et Managed Réseau virtuel IR, vous n’avez pas à vous soucier de la maintenance, comme les mises à jour, les correctifs et les versions. Le service Purview prend en charge tous les efforts de maintenance.
- Étant donné que le SHIR est installé sur vos machines et que le SHIR pris en charge par Kubernetes se trouve sur vos clusters Kubernetes, vous devez gérer la maintenance.
- SHIR prend en charge la mise à jour automatique pour obtenir automatiquement la dernière version chaque fois qu’il y a une mise à jour. Pour plus d’informations, consultez Mise à jour automatique et expiration du runtime d’intégration auto-hébergé.
- Actuellement, le runtime d’intégration auto-hébergé pris en charge par Kubernetes prend uniquement en charge les mises à jour manuelles.
Performances et évolutivité
Utilisez le runtime d’intégration Azure complètement managé et mis à l’échelle automatiquement, le runtime d’intégration Réseau virtuel managé ou le runtime d’intégration auto-hébergé pris en charge par Kubernetes, le cas échéant. En utilisant l’élasticité, ils peuvent vous offrir de meilleures performances et scalabilité, en particulier lors de l’analyse de systèmes de données à grande échelle.
Mise en veille prolongée du runtime d’intégration de réseau virtuel managé
Si le runtime d’intégration est inactif (aucune analyse sur le runtime d’intégration pendant plus de 90 jours), votre managed Réseau virtuel Integration Runtime passe automatiquement en veille prolongée. Son status s’affiche comme Hibernated lorsque vous sélectionnez le runtime d’intégration.
Signification de cette modification pour vous
Lorsque vous exécutez Test Connection sur un runtime d’intégration hibernated, la connexion de test échoue. Un message s’affiche pour tester la connexion au bout de 15 minutes. À ce stade, votre Réseau virtuel managée revient à un état normal. Après cela, vous pouvez exécuter vos connexions de test et analyses normalement.
Lorsque vous exécutez une analyse directement à l’aide des options Exécuter l’analyse maintenant ou Modifier l’analyse sans exécuter d’abord une connexion de test à partir d’un Integration Runtime hiberné, ou que vous exécutez une analyse via l’API, vous voyez un message indiquant que cette analyse prend jusqu’à 15 minutes supplémentaires. Ce temps supplémentaire permet au Integration Runtime hibernated de se réveiller et au processus d’analyse de commencer. Vous voyez votre analyse status comme Queued_Waking Runtime d’intégration au lieu de l’état File d’attente que vous voyez en cas d’analyse normale. Après la première analyse, vous pouvez exécuter toutes vos analyses suivantes normalement.
Sources de données prises en charge
Le tableau suivant présente toutes les sources de données prises en charge par l’analyse Purview, ainsi que les types de runtime d’intégration pris en charge.
| Catégorie | Magasin de données pris en charge | Azure IR/AWS IR | Runtime d’intégration Réseau virtuel managé | SHIR | Kubernetes SHIR |
|---|---|---|---|---|---|
| Azure | Plusieurs sources | ✓ | |||
| Stockage Blob Azure | ✓ | ✓ (y compris point de terminaison privé managé) | ✓ | ✓ | |
| Azure Cosmos DB (API pour NoSQL) | ✓ | ✓ (y compris point de terminaison privé managé) | ✓ | ✓ | |
| Explorateur de données Azure | ✓ | ✓ (v2 uniquement) | ✓ | ✓ | |
| Azure Data Lake Storage Gen1 | ✓ | ✓ (v2 uniquement) | ✓ | ||
| Azure Data Lake Storage Gen2 | ✓ | ✓ (y compris point de terminaison privé managé) | ✓ | ✓ | |
| Base de données Azure pour MySQL | ✓ | ✓ (y compris point de terminaison privé managé) | ✓ | ✓ | |
| Base de données Azure pour PostgreSQL | ✓ | ✓ (y compris point de terminaison privé managé) | ✓ | ✓ | |
| Azure Databricks Hive Metastore | ✓ | ✓ | |||
| Catalogue Unity d' Azure Databricks | ✓ | ✓ (v2 uniquement, y compris point de terminaison privé managé) | ✓ | ||
| Pool SQL dédié Azure (anciennement SQL DW) | ✓ | ✓ (y compris point de terminaison privé managé) | ✓ | ✓ | |
| Azure Files | ✓ | ✓ (y compris point de terminaison privé managé) | ✓ | ✓ | |
| Base de données Azure SQL | ✓ | ✓ (y compris point de terminaison privé managé) | ✓ | ✓ | |
| Azure SQL Managed Instance | ✓ | ✓ (y compris point de terminaison privé managé) | ✓ | ✓ | |
| Analytique Azure Synapse (Espace de travail) | ✓ | ✓ (y compris point de terminaison privé managé) | ✓ | ✓ | |
| Database | Amazon RDS | ✓ | ✓ | ||
| Amazon Redshift | ✓ | ✓ | |||
| Cassandra | ✓ | ✓ (v2 uniquement) | ✓ | ✓ | |
| Db2 | ✓ | ✓ | |||
| Google BigQuery | ✓ | ✓ | |||
| Base de données Hive Metastore | ✓ | ✓ | |||
| MongoDB | ✓ | ✓ | |||
| MySQL | ✓ | ✓ (v2 uniquement) | ✓ | ✓ | |
| Oracle | ✓ | ||||
| PostgreSQL | ✓ | ✓ (v2 uniquement) | ✓ | ✓ | |
| SAP Business Warehouse (entrepôt de données) | ✓ | ✓ | |||
| SAP HANA | ✓ | ✓ | |||
| Snowflake | ✓ | ✓ (v2 uniquement, y compris point de terminaison privé managé) | ✓ | ||
| SQL Server | ✓ | ✓ | |||
| SQL Server sur Azure-Arc | ✓ | ✓ | |||
| Teradata | ✓ | ||||
| Fichier | Amazon S3 | ✓ | |||
| HDFS | ✓ | ✓ | |||
| Services et applications | Dataverse | ✓ | ✓ (v2 uniquement) | ✓ | |
| Erwin | ✓ | ||||
| Looker | ✓ | ✓ (v2 uniquement) | ✓ | ✓ | |
| Fabric | ✓ | ✓ (v2 uniquement) | ✓ | ✓ | |
| Power BI | ✓ | ✓ (v2 uniquement) | ✓ | ✓ | |
| Qlik Sense Mobile | ✓ | ✓ (v2 uniquement) | ✓ | ||
| Salesforce | ✓ | ✓ (v2 uniquement) | ✓ | ✓ | |
| SAP ECC | ✓ | ✓ | |||
| SAP S/4HANA | ✓ | ✓ | |||
| Tableau | ✓ | ✓ (v2 uniquement) | ✓ |