Modes et exigences de connectivité
Cet article décrit les modes de connectivité disponibles pour les services de données avec Azure Arc, ainsi que leurs exigences respectives.
Modes de connectivité
Il existe plusieurs options pour le degré de connectivité de votre environnement de services de données avec Azure Arc vers Azure. À mesure que vos besoins varient en fonction de la stratégie d’entreprise, du règlement gouvernemental ou de la disponibilité de la connectivité réseau à Azure, vous pouvez choisir parmi les modes de connectivité suivants.
Les services de données avec Azure Arc vous permettent de vous connecter à Azure selon deux modes de connexion différents :
- Connecté directement
- Connecté indirectement
Ce mode de connectivité vous offre la possibilité de choisir la quantité de données envoyées à Azure et la manière dont les utilisateurs interagissent avec le contrôleur de données Arc. Selon le mode de connexion choisi, certaines fonctionnalités des services de données avec Azure Arc peuvent être disponibles ou non.
Notez que, si les services de données avec Azure Arc sont directement connectés à Azure, les utilisateurs peuvent utiliser des API Azure Resource Manager, l’interface Azure CLI et le portail Azure pour utiliser les services de données Azure Arc. L’expérience en mode de connexion directe est très similaire à l’utilisation d’un autre service Azure avec l’approvisionnement, le déprovisionnement, la mise à l’échelle, la configuration, etc., dans le portail Azure. Si les services de données avec Azure Arc sont indirectement connectés à Azure, le portail Azure est une vue en lecture seule. Vous pouvez voir l’inventaire des instances managées SQL et des serveurs PostgreSQL que vous avez déployés, ainsi que leurs détails, mais vous ne pouvez pas agir dessus dans le portail Azure. En mode de connexion indirecte, toutes les actions doivent être effectuées localement à l’aide d’Azure Data Studio, de l’interface CLI appropriée ou des outils natifs Kubernetes comme kubectl.
En outre, Microsoft Entra ID et le contrôle d’accès en fonction du rôle Azure peuvent être utilisés en mode connecté directement, car il existe une dépendance d’une connexion continue et directe à Azure pour fournir cette fonctionnalité.
Certains services attachés à Azure sont disponibles uniquement lorsqu’ils sont directement accessibles, comme Container Insights, et peuvent être sauvegardés sur Stockage Blob.
| Connecté indirectement | Connecté directement | Jamais connecté | |
|---|---|---|---|
| Description | Le mode connecté indirectement offre la plupart des services de gestion localement dans votre environnement, sans connexion directe à Azure. Une quantité minimale de données doit être envoyée à Azure à des fins d’inventaire et de facturation uniquement. Elle est exportée vers un fichier et chargée vers Azure au moins une fois par mois. Aucune connexion directe ou continue à Azure n’est requise. Certains services et fonctionnalités qui nécessitent une connexion à Azure ne seront pas disponibles. | Le mode connecté directement offre tous les services disponibles quand une connexion directe peut être établie avec Azure. Les connexions sont toujours lancées depuis votre environnement vers Azure et utilisent des ports standard et des protocoles tels que HTTPS/443. | Aucune donnée ne peut être envoyée vers ou à partir d’Azure. |
| Disponibilité actuelle | Disponible | Disponible | Actuellement non pris en charge. |
| Cas d’usage classiques | Centres de données locaux qui n’autorisent pas la connectivité dans ou à l’extérieur de la région de données du centre de données en raison de stratégies de conformité commerciales ou réglementaires ou de problèmes d’attaques externes ou d’exfiltration de données. Exemples classiques : institutions financières, soins de santé, secteur public. Sites de périmètre où le site de périphérie ne dispose généralement pas d’une connectivité à Internet. Exemples typiques : applications de terrain, pétrolières, gazières ou militaires. Emplacements de site de périphérie disposant d’une connectivité intermittente avec de longues périodes de panne. Exemples typiques : stades, bateaux de croisière. |
Organisations qui utilisent des clouds publics. Exemples classiques : Azure, AWS ou Google Cloud. Emplacements de sites de périphérie où la connectivité Internet est généralement présente et autorisée. Exemples typiques : magasins de vente au détail, fabrication. Centres de données d’entreprise avec des stratégies plus permissives pour la connectivité vers Internet et depuis leur région de données du centre de données. Exemples classiques : entreprises non réglementées, petites et moyennes entreprises |
Environnements parfaitement hermétiques dans lesquels aucune donnée n’est susceptible de se trouver dans l’environnement de données. Exemples typiques : principales fonctionnalités gouvernementales des clés secrètes. |
| Comment les données sont envoyées à Azure | Il existe trois options pour l’envoi des données de facturation et d’inventaire vers Azure : 1) Les données sont exportées hors de la région de données par un processus automatisé qui est connecté à la fois à la région de données sécurisée et à Azure. 2) Les données sont exportées hors de la région de données par un processus automatisé dans la région de données, copiées automatiquement vers une région moins sécurisée, et un processus automatisé dans la région moins sécurisée charge les données vers Azure. 3) Les données sont exportées manuellement par un utilisateur dans la région sécurisée, extraites manuellement de la région sécurisée et chargées manuellement vers Azure. Les deux premières options sont un processus continu automatisé qui peut être planifié pour s’exécuter fréquemment, de sorte qu’il y a un délai minimal dans le transfert de données vers Azure, qui est uniquement soumis à la connectivité disponible à Azure. |
Les données sont envoyées automatiquement et en continu à Azure. | Les données ne sont jamais envoyées à Azure. |
Disponibilité des fonctionnalités par mode de connectivité
| Fonctionnalité | Connecté indirectement | Connecté directement |
|---|---|---|
| Haute disponibilité automatique | Prise en charge | Prise en charge |
| Approvisionnement en libre-service | Prise en charge Utilisez Azure Data Studio, l’interface CLI appropriée ou des outils natifs Kubernetes, tels que Helm, kubectl ou oc, ou utilisez l’approvisionnement Kubernetes GitOps avec Azure Arc. |
Prise en charge Outre les options de création en mode connecté indirectement, vous pouvez créer via le portail Azure, des API Azure Resource Manager, Azure CLI ou des modèles Resource Manager. |
| Scalabilité élastique | Prise en charge | Prise en charge |
| Billing | Prise en charge Les données de facturation sont régulièrement exportées et envoyées à Azure. |
Prise en charge Les données de facturation sont envoyées automatiquement et en permanence à Azure, et elles sont reflétées en temps quasi réel. |
| Gestion des stocks | Prise en charge Les données d’inventaire sont régulièrement exportées et envoyées à Azure. Utilisez des outils clients comme Azure Data Studio, Azure Data CLI ou kubectl pour afficher et gérer l’inventaire localement. |
Prise en charge Les données d’inventaire sont envoyées automatiquement et en permanence à Azure, et elles sont reflétées en temps quasi réel. Vous pouvez ainsi gérer l’inventaire directement à partir du portail Azure. |
| Mises à niveau et mises à jour correctives automatiques | Prise en charge Le contrôleur de données doit avoir un accès direct à Microsoft Container Registry (MCR) ou les images de conteneur doivent être extraites de la valeur de la clé et transmises à un registre de conteneurs privé local auquel le contrôleur de données a accès. |
Prise en charge |
| Sauvegarde et restauration automatiques | Prise en charge Sauvegarde et restauration locales automatiques. |
Prise en charge En plus de la sauvegarde et de la restauration locales automatisées, vous pouvez éventuellement envoyer des sauvegardes à Stockage Blob Azure pour une conservation des données hors site à long terme. |
| Surveillance | Prise en charge Analyse locale à l’aide des tableaux de bord Grafana et Kibana. |
Prise en charge Outre les tableaux de bord de surveillance locaux, vous pouvez éventuellement envoyer des données et des journaux de surveillance à Azure Monitor pour une surveillance à l’échelle de plusieurs sites dans un même emplacement. |
| Authentification | Utilisez le nom d’utilisateur/mot de passe local pour l’authentification du contrôleur de données et du tableau de bord. Utilisez soit les connexions SQL et Postgres, soit Active Directory (AD n’est pas pris en charge pour le moment) pour la connectivité aux instances de base de données. Utilisez les fournisseurs d’authentification Kubernetes pour l’authentification auprès de l’API Kubernetes. | En plus ou à la place des méthodes d’authentification pour le mode de connexion indirecte, vous pouvez éventuellement utiliser Microsoft Entra ID. |
| Contrôle d’accès en fonction du rôle (RBAC) | Utilisez le contrôle d’accès en fonction du rôle Kubernetes sur l’API Kubernetes. Utilisez le contrôle d’accès en fonction du rôle SQL et Postgres pour les instances de base de données. | Vous pouvez utiliser Microsoft Entra ID et Azure RBAC. |
Connectivité requise
Certaines fonctionnalités nécessitent une connexion à Azure.
Toutes les communications avec Azure sont toujours lancées à partir de votre environnement. Cela est vrai même pour les opérations qui sont initiées par un utilisateur dans le portail Azure. Dans ce cas, il y a effectivement une tâche, qui est mise en file d’attente dans Azure. Un agent de votre environnement lance la communication avec Azure pour voir quelles tâches sont dans la file d’attente, exécute les tâches et renvoie l’état/l’achèvement/l’échec à Azure.
| Type de données | Direction | Obligatoire/facultatif | Coûts supplémentaires | Mode requis | Notes |
|---|---|---|---|---|---|
| Images conteneur | Microsoft Container Registry -> Client | Requis | Non | Indirect ou direct | Les images conteneur sont la méthode de distribution du logiciel. Dans un environnement qui peut se connecter à Microsoft Container Registry (MCR) par le biais d’Internet, les images de conteneur peuvent être extraites directement à partir de la valeur de la valeur. Si l’environnement de déploiement ne dispose pas d’une connectivité directe, vous pouvez extraire les images de la clé et les envoyer vers un registre de conteneurs privé dans l’environnement de déploiement. Au moment de la création, vous pouvez configurer le processus de création pour effectuer l’extraction à partir du registre de conteneurs privé au lieu de MCR. Cela s’applique également aux mises à jour automatisées. |
| Inventaire des ressources | Environnement client -> Azure | Requis | Non | Indirect ou direct | Un inventaire des contrôleurs de données, des instances de base de données (PostgreSQL et SQL) est conservé dans Azure à des fins de facturation, ainsi qu’à des fins de création d’un inventaire de tous les contrôleurs de données et d’instances de base de données dans un seul emplacement, ce qui est particulièrement utile si vous avez plusieurs environnements avec des services de données Azure Arc. À mesure que les instances sont approvisionnées, annulées, mises à l’échelle (scale-up/scale-down), l’inventaire est mis à jour dans Azure. |
| Données de télémétrie de facturation | Environnement client -> Azure | Requis | Non | Indirect ou direct | L’utilisation des instances de base de données doit être envoyée à Azure à des fins de facturation. |
| Analyse des données et des journaux | Environnement client -> Azure | Facultatif | Peut-être en fonction du volume de données (voir Tarification Azure Monitor) | Indirect ou direct | Vous pouvez envoyer les données de surveillance et les journaux collectés localement à Azure Monitor pour agréger des données dans plusieurs environnements à un même emplacement et pour utiliser des services Azure Monitor comme des alertes, à l’aide des données d’Azure Machine Learning, etc. |
| Contrôle d’accès en fonction du rôle Azure (Azure RBAC) | Environnement client -> Azure -> Environnement client | Facultatif | Non | Directe uniquement | Si vous souhaitez utiliser Azure RBAC, la connectivité doit être établie avec Azure à tout moment. Si vous ne souhaitez pas utiliser Azure RBAC, vous pouvez utiliser le contrôle d’accès en fonction du rôle Kubernetes local. |
| Microsoft Entra ID (futur) | Environnement client -> Azure -> environnement client | Facultatif | Peut-être, mais vous payez déjà peut-être Microsoft Entra ID | Directe uniquement | Si vous souhaitez utiliser Microsoft Entra ID pour l’authentification, la connectivité doit être établie avec Azure à tout moment. Si vous ne souhaitez pas utiliser Microsoft Entra ID pour l’authentification, vous pouvez utiliser les services de fédération Active Directory (AD FS) sur Active Directory. Disponibilité en attente en mode de connexion directe |
| Sauvegarde et restauration | Environnement client -> Environnement client | Requis | Non | Direct ou indirect | Le service de sauvegarde et de restauration peut être configuré pour pointer vers des classes de stockage locales. |
| Sauvegarde Azure – Conservation à long terme (à venir) | Environnement client -> Azure | Facultatif | Oui, pour Stockage Azure | Directe uniquement | Vous souhaiterez peut-être envoyer des sauvegardes effectuées localement à Sauvegarde Azure pour la rétention à long terme et hors site des sauvegardes, puis les remettre dans l’environnement local pour la restauration. |
| Mise en service et modification de la configuration à partir du Portail Azure | Environnement client -> Azure -> environnement client | Facultatif | Non | Directe uniquement | Les modifications de provisionnement et de configuration peuvent être effectuées localement à l’aide d’Azure Data Studio ou de l’interface CLI appropriée. En mode de connexion directe, vous pouvez également approvisionner et apporter des modifications de configuration à partir du portail Azure. |
Détails sur les adresses Internet, les ports, le chiffrement et la prise en charge du serveur proxy
| service | Port | URL | Direction | Notes |
|---|---|---|---|---|
| Graphique Helm (mode de connexion directe uniquement) | 443 | arcdataservicesrow1.azurecr.io |
Règle de trafic sortant | Approvisionne les objets de programme d’amorçage et de niveau de cluster du contrôleur de données Azure Arc, tels que les définitions de ressources personnalisées, les rôles de cluster et les liaisons de rôle de cluster. Extrait d’Azure Container Registry. |
| API Azure Monitor 1 | 443 | *.ods.opinsights.azure.com*.oms.opinsights.azure.com*.monitoring.azure.com |
Règle de trafic sortant | Azure Data Studio et Azure CLI se connectent aux API Azure Resource Manager pour envoyer et récupérer des données vers et depuis Azure pour certaines fonctionnalités. Consultez la section API Azure Monitor. |
| Service de traitement des données Azure Arc 1 | 443 | *.<region>.arcdataservices.com 2 |
Règle de trafic sortant |
1 Condition requise dépend du mode de déploiement :
- Pour le mode direct, le pod de contrôleur sur le cluster Kubernetes doit disposer d’une connectivité sortante aux points de terminaison pour envoyer les journaux, les métriques, l’inventaire et les informations de facturation à Azure Monitor/service de traitement des données.
- Pour le mode indirect, la machine qui exécute
az arcdata dc uploaddoit disposer de la connectivité sortante à Azure Monitor et au service de traitement des données.
2 Pour les versions d’extension jusqu’au 13 février 2024, utilisez san-af-<region>-prod.azurewebsites.net.
API Azure Monitor
La connectivité d’Azure Data Studio au serveur d’API Kubernetes utilise l’authentification et le chiffrement Kubernetes que vous avez établis. Chaque utilisateur qui utilise Azure Data Studio ou l’interface CLI doit disposer d’une connexion authentifiée à l’API Kubernetes pour effectuer un grand nombre des actions associées aux services de données avec Azure Arc.
Conditions requises supplémentaires du réseau
De plus, le pont de ressources nécessite des points de terminaison Kubernetes avec Arc.