Planifier un déploiement ExpressRoute pour une utilisation avec Microsoft Power Platform
Maintenant que vous avez décidé d’utiliser ExpressRoute pour Microsoft Power Platform, il est important de planifier le déploiement en fonction de vos besoins et de votre environnement.
Conditions requises préalables pour ExpressRoute
La configuration d’ExpressRoute nécessite la prise en compte et la configuration de plusieurs conditions requises préalables. Celles-ci peuvent entraîner des coûts et des activités imprévus qui, s’ils ne sont pas planifiés, peuvent affecter le projet et l’opération continue d’autres services.
Conditions requises préalables externes
ExpressRoute ne fournit pas de connexion physique, mais il fournit une connectivité privée sur une connexion physique déjà établie. La connectivité physique doit d’abord être configurée par un fournisseur de connectivité. Il existe plusieurs façons d’établir cette connectivité avec les partenaires ExpressRoute existants. La documentation ExpressRoute fournit des explications détaillées relatives aux options et aux partenaires actuellement disponibles.
Dans le cadre de la planification, vous devez prendre en compte les éléments suivants :
Géographie : Comme nous le verrons plus en détail plus tard, comprendre géographiquement d’où une ou plusieurs connexions doivent être établies affectera votre planification globale.
Coût : Le fournisseur de connectivité facturera l’établissement de la connexion privée. Cela peut représenter un coût important ; il varie en fonction du type et du nombre de connexions nécessaires.
Temps de configuration : Dans certains cas, le matériel physique devra être configuré. Cette durée d’installation doit être intégrée dans le planning d’implémentation.
Configuration compétences et ressources : La majeure partie de la complexité de la configuration réside dans la mise en place du routage interne au sein de votre réseau. Il est essentiel que vous vous assuriez que des personnes qualifiées soient disponibles pour le faire.
Microsoft prérequis
Une fois la connectivité physique en place, vous pouvez procéder à la configuration des connexions ExpressRoute. Cette opération nécessite :
Un abonnement Azure dans lequel vous pouvez approvisionner et facturer les circuits ExpressRoute.
Configuration au sein de l’abonnement Azure des circuits ExpressRoute, qui s’effectue à l’aide des outils Azure.
Planification de la configuration du routage pour le trafic Microsoft Power Platform sur ExpressRoute
Lors de la planification du routage du trafic Microsoft Power Platform, vous devez prendre en compte les différents types de trafic, qui dépendent de la façon dont vous avez configuré et utilisé Microsoft Power Platform.
Pour comprendre comment configurer ExpressRoute pour Microsoft Power Platform, vous devez tenir compte des différentes utilisations et connexions vers et depuis Microsoft Power Platform, qui dépendent des services et fonctionnalités que vous utilisez.
Configuration de l’acheminement
La configuration du routage est effectuée soit par le fournisseur de connectivité ou par le client, en fonction du type de connexion fournie.
Bien que la connexion ExpressRoute s’effectue entre des centres de données, la connexion réseau réelle provient principalement des appareils clients de l’utilisateur (qui sont souvent distribués sur un WAN plus large, par exemple des succursales bancaires distribuées). Cela signifie que les connexions sont acheminées depuis l’emplacement de l’appareil client via le WAN jusqu’au centre de données, puis via le circuit ExpressRoute. Cela nécessite une configuration minutieuse. Le WAN doit être configuré de telle sorte que :
L’itinéraire via le sous-réseau est configuré pour ExpressRoute.
ou
Le circuit de basculement est choisi de préférence sur la connexion Internet publique pour Microsoft Power Platform.
Par conséquent, il est important d’identifier les sous-réseaux au sein de votre réseau qui doivent être les cibles des connexions de session BGP (Border Gateway Protocol) principales et de secours afin de vous assurer que les préfixes Microsoft Power Platform préfèrent cette route. Il n’est pas nécessaire de configurer spécifiquement les services à chaque extrémité, car cette configuration s’effectue en annonçant les sous-réseaux/préfixes IP via cette connexion. Lorsqu’une requête est initiée, l’algorithme de routage considère cette connexion GPO directe comme l’itinéraire préféré pour le trafic vers le sous-réseau connecté au circuit ExpressRoute et dirige le trafic de cette façon.
Configuration d’ExpressRoute pour les bases d’utilisateur distribuées
ExpressRoute est conçu pour fournir des connexions privées, dédiées et donc prévisibles de votre environnement au réseau. Microsoft Lorsque vous disposez d’une connexion dédiée et directe via le fournisseur de connectivité à Microsoft, vous réduisez le risque de devoir faire face à d’autres trafics sur les connexions que vous Partager via le réseau du fournisseur de connectivité. Il ne devrait pas être nécessaire d’utiliser ExpressRoute pour obtenir cette qualité de connexion via un fournisseur de connectivité, mais c’est un moyen de l’assurer.
Dans l’exemple suivant, la connexion d’un utilisateur dans un emplacement de succursale est acheminée via le WAN vers la connexion du centre de données du client à ExpressRoute.
Lorsqu’un client dispose d’un réseau d’utilisateurs hautement distribué, comme un réseau de succursale de bureaux répartis dans un pays/une région, le trafic réseau doit être connecté efficacement à partir de plusieurs emplacements hautement distribués géographiquement. Le modèle standard pour cela consiste à acheminer des éléments via le WAN vers le réseau local connecté à ExpressRoute, comme illustré dans l’image suivante.
Si la connexion entre le client et ExpressRoute est mauvaise, saturée ou inefficace, ExpressRoute ne peut pas résoudre ce problème, car les problèmes de connexion pour accéder au point d’entrée ExpressRoute affectent toujours l’expérience utilisateur. Dans un cas comme celui-ci, vous devriez envisager d’utiliser ExpressRoute Direct, qui vous donne la possibilité de vous connecter directement au réseau mondial de Microsoft.
Lorsque vous vous connectez à des services cloud et que vous êtes limité par des connexions WAN difficiles, il peut être avantageux d’établir des évasions Internet locales à partir des succursales locales. Cela permet d’éviter la connexion WAN plus lente et de profiter de la portée du fournisseur de connectivité pour obtenir une connexion plus directe au service cloud.
Il est possible de configurer des circuits ExpressRoute à partir de plusieurs emplacements et même jusqu’à des emplacements de succursales individuelles via une interruption de la connexion Internet locale, comme illustré dans l’image suivante.
L’approche consistant à connecter les succursales à un centre de données central via un WAN et à établir des circuits ExpressRoute entre le client et les centres de données est généralement préférable et plus pratique que d’essayer d’établir une connexion ExpressRoute à partir de chaque succursale. Microsoft Ci cela était requis dans de nombreux emplacements, ce serait relativement coûteux et compliqué à configurer et à entretenir.
Une approche alternative consiste à Connecter toutes les succursales et le centre de données client sur le même VPN IP et à demander au fournisseur de services VPN IP de se trouver à un emplacement ExpressRoute. Microsoft
Si vous rencontrez des difficultés avec une connexion WAN locale, il est généralement préférable de l’optimiser à l’aide de méthodes, telles que gagner de la bande passante supplémentaire ou optimiser le routage, plutôt que d’essayer d’établir une connexion ExpressRoute à partir de chaque emplacement.
Pour les réseaux distribués sur une vaste zone géographique, il peut être utile d’avoir plusieurs hubs connectés à ExpressRoute pour minimiser le nombre de connexions ExpressRoute nécessaires tout en offrant un point de connexion plus local pour chaque utilisateur. Dans ce cas, il est important de s’assurer que des adresses IP publiques uniques sont publiées via chaque circuit ExpressRoute ; chacun de ces sous-réseaux doit être distinct, ce qui nécessite que vous ayez autant de sous-réseaux publics que de connexions ExpressRoute.
Cela est particulièrement bénéfique si différentes zones opérationnelles sont situées dans des zones géographiques très différentes, ou si la connectivité réseau entre les zones est limitée et qu’une connexion plus directe peut être établie pour chacune d’elles. Microsoft
Il est également possible que différentes régions aient des exigences de confidentialité différentes et il n’est pas nécessaire que chaque région utilise ExpressRoute simplement parce qu’une autre région l’utilise. Il est possible que certaines connexions soient acheminées directement via Internet et d’autres via ExpressRoute, comme illustré dans l’image suivante.
ExpressRoute (standard) offre une connectivité uniquement dans une région géographique spécifique ; ExpressRoute Premium est requis pour offrir un accès multi-géographique à partir d’un seul point de connexion ExpressRoute. Cela serait pertinent si, par exemple, un client possédait des bureaux basés aux États-Unis et en Europe qui utilisent tous un seul environnement Microsoft Power Platform. Si le locataire du client Microsoft Power Platform est déployé aux États-Unis, son circuit ExpressRoute en Europe doit être le SKU Premium. Si son locataire Microsoft Power Platform est en Europe, son circuit américain doit être Premium.
Éviter le routage asymétrique
L’un des défis à surveiller est le routage asymétrique, où la configuration de routage au sein du réseau client achemine le trafic vers le centre de données directement via Internet, mais le trafic de retour détermine ensuite que les réponses doivent être acheminées via un circuit ExpressRoute. Microsoft Cela peut souvent déclencher un pare-feu pour rejeter le trafic, car des paquets de réponse sont reçus sans avoir envoyé les paquets de requête.
Cela peut se produire si le réseau local d’un client détermine que le routage le plus efficace vers les services cloud passe par l’Internet public plutôt que par le WAN vers le circuit ExpressRoute privé. Microsoft Cependant, si l’adresse IP du client est une adresse IP publique ou est traduite via des mappages NAT vers une adresse IP publique annoncée via ExpressRoute, l’itinéraire le plus efficace vers cette IP est probablement via la session GPO sur ExpressRoute. Vous pouvez utiliser différentes adresses IP NAT sur votre périphérie Internet et votre périphérie ExpressRoute. Avec une adresse source distincte, le trafic de retour revient sans ambiguïté dans la même périphérie.
Cela peut également se produire lorsqu’il existe plusieurs circuits ExpressRoute configurés pour le même client avec un routage du trafic sortant via un circuit, mais un routage de retour via un autre circuit où les contrôles de pare-feu peuvent bloquer le trafic via le chemin de retour. Pour éviter le routage asymétrique sur un circuit ExpressRoute différent pour les chemins sortants et entrants, il est important de s’assurer que des adresses IP publiques uniques sont publiées sur chaque circuit.
Comme vous pouvez le constater, il est important de déterminer comment le routage est géré au sein de votre WAN et de garantir que les chemins vers et depuis les services cloud sont soigneusement étudiés. Microsoft
Connectivité externe vers/depuis Microsoft Power Platform
Lors de la connexion à Microsoft Power Platform depuis des emplacements de client, il existe plusieurs types de trafic à prendre en compte. Cela peut conduire à la fois à des types de peering et à un peering privé, et le même circuit ExpressRoute peut être utilisé pour ces types de peering comme indiqué dans l’image suivante. Microsoft
Il existe différents types de connexion entre les services Microsoft Power Platform et un réseau externe. Par exemple, la connectivité des services Web Exchange utilisant la synchronisation côté serveur utilise ExpressRoute pour transmettre le trafic réseau du réseau au réseau client. Microsoft La connectivité des services Web utilise ExpressRoute pour le trafic entrant et sortant vers le réseau. Microsoft Pour le client HTTPS, la connexion ExpressRoute est utilisée pour l’accès du réseau client au réseau. Microsoft L’image suivante illustre ces exemples.
Trafic sortant (trafic à partir des services Microsoft Power Platform)
Plusieurs types de trafic sortant peuvent se produire directement à partir des services Microsoft Power Platform vers des services clientèles. Pour chacun d’entre eux, il est important de noter que le service clientèle doit être adressable publiquement avec une IP publique qui peut être résolue via un DNS public par les services Microsoft Power Platform.
Cette adresse IP doit également être annoncée via ExpressRoute afin que le routage du réseau interne au sein des services sache qu’il doit l’acheminer via cette connexion ExpressRoute. Microsoft Microsoft Power Platform
Les services Microsoft Power Platform ne peuvent pas spécifier quelle instance de service ou quelle organisation cliente peut initier de requêtes à quelles adresses IP. Par conséquent, il est important de traiter les requêtes entrantes sur le réseau de l’entreprise comme si elles provenaient d’Internet et de les sécuriser en tant que telles.
Le tableau suivant décrit le trafic sortant des services Microsoft Power Platform.
| Description | Type et direction du trafic | Type de peering | Finalité |
|---|---|---|---|
| Services Web | HTTPS sortant depuis des services Microsoft Power Platform | Microsoft scrutation Publier des services Web sur des adresses IP publiques qui se trouvent dans des sous-réseaux configurés par ExpressRoute |
Les plug-ins et les activités de workflow personnalisés peuvent envoyer des requêtes de service Web à des services externes |
| Intégration d’Exchange : mode hybride | HTTPS sortant depuis des services Microsoft Power Platform | Microsoft scrutation Les services Web doivent être publiés sur des adresses IP publiques qui se trouvent dans des sous-réseaux configurés par ExpressRoute |
Requêtes de Services Web Exchange provenant de la synchronisation côté serveur pour les déploiements hybrides (services Microsoft Power Platform, Exchange localement) |
| Connecteurs | HTTPS entrant depuis des services Microsoft Power Platform | Microsoft scrutation | Requêtes à partir de services Microsoft Power Platform par le biais du service Gestion des API Azure via des connecteurs utilisant la passerelle de données locale |
| Azure Relay | HTTPS sortant depuis des services Microsoft Power Platform | Microsoft scrutation Publier des services Web sur des adresses IP publiques qui se trouvent dans des sous-réseaux configurés par ExpressRoute |
Connectivité directe entre les flux de cloud Power Automate et les flux de bureau |
Trafic entrant (trafic vers des services Microsoft Power Platform)
Le trafic entrant suivant est possible vers des services Microsoft Power Platform à partir du réseau client.
| Description | Type et direction du trafic | Type de peering | Finalité |
|---|---|---|---|
| Connectivité client | HTTPS entrant vers des services Microsoft Power Platform | Microsoft scrutation Connexion Internet directe pour le contenu statique servi par Azure Content Delivery Network |
Requêtes du client pour l’interface utilisateur des services Microsoft Power Platform |
| Services Web | HTTPS entrant vers des services Microsoft Power Platform | Microsoft scrutation | Requêtes vers les services Microsoft Power Platform via les API de services Web (SOAP, API Web). Soit à partir d’une application cliente standard ou personnalisée |
| Connecteurs | HTTPS entrant vers des services Microsoft Power Platform | Microsoft scrutation | Réponses aux services Microsoft Power Platform par le biais des APIM via des connecteurs utilisant la passerelle de données locale |
Connectivité cloud interne au sein des services Microsoft Power Platform
Microsoft Power Platform les services utilisent et s’intègrent à plusieurs autres services en ligne hébergés à la fois dans et dans Azure. Microsoft Microsoft 365
| Description | Type et direction du trafic | Objectif |
|---|---|---|
| Intégration d’Exchange | HTTPS sortant vers Microsoft 365 | Requêtes du service Web Exchange vers Exchange Online à partir de la synchronisation côté serveur |
| Intégration avec SharePoint | HTTPS sortant vers Microsoft 365 | Requêtes de service web SharePoint à SharePoint Online à partir des services Microsoft Power Platform |
| Bus des services | HTTPS sortant vers Azure Service Bus | Envoyer des événements vers Azure Service Bus soit en tant qu’inscription d’événement standard, soit à partir de plug-ins et d’activités de workflow personnalisés |
| Synchronisation de données | HTTPS entrant à partir d’Azure | Requêtes de suivi des modifications entrantes pour la synchronisation de services de données, notamment les insights de recherche/hors ligne/client |
| Authentification | HTTPS sortant vers Microsoft Entra | La plupart des authentifications sont effectuées via des redirections passives et des jetons de revendication, mais certaines données sont synchronisées directement sur Microsoft Entra ID |
| Flux de données | HTTPS sortant vers Azure Data Lake Storage | Fournit des capacités d’analyse et permet d’accéder à des solutions de Big Data incorporant des données des services Microsoft Power Platform et d’autres sources, en plus des insights résultant de l’analyse. |
| Connecteurs | HTTPS sortant vers les services PaaS Azure | Connexions à divers services PaaS Azure |
| Desktop flows | HTTPS sortant vers Azure Relay | Connectivité directe entre les flux de cloud Power Automate et flux de bureau créés dans Power Automate pour Bureau |
La connectivité réelle entre ces services, hébergés soit dans des abonnements Azure soit dans des abonnements clients, est gérée par Microsoft . Microsoft ExpressRoute ne s’applique pas aux connexions avec ces services.
Lorsque les événements sont poussés vers le bus de service, la connectivité entre les services Microsoft Power Platform et Azure est gérée en interne. Séparément, le client peut faire des demandes au Service Bus pour récupérer des informations, et cela peut être géré via le peering. Microsoft
Connectivité cloud public et privé du client vers/depuis les services Microsoft Power Platform
Les services Microsoft Power Platform permettent également une intégration directe avec des ressources Azure publiques ou privées :
à partir de sources externes, en utilisant les API de services Web Microsoft Dataverse ;
vers des sources externes, en utilisant des requêtes de service Web effectuées ,
vers des sources externes, en utilisant des connecteurs.
Les implications de cela doivent être prises en compte dans le routage ExpressRoute.
| Description | Type et direction du trafic | Type de peering | Objectif |
|---|---|---|---|
| Portails | HTTPS entrant vers Azure | En interne vers un centre de données, à l’exception du contenu statique, qui utilise le réseau de distribution de contenu. (Le réseau de diffusion de contenu n’est pas pris en charge par ExpressRoute, donc le contenu statique circule sur l’Internet public.) | Hébergez des services publics. Dans certains cas, les employés internes peuvent accéder à ces ressources. Vous souhaitez donc peut-être que le trafic circule sur ExpressRoute plutôt que sur l’Internet public |
| Parcours d’apprentissage | HTTPS entrant vers Azure | Utiliser le réseau de diffusion de contenu, qui n’est pas pris en charge par ExpressRoute, pour que le contenu statique circule sur l’Internet public | Il est hébergé sur un service public car il ne contient pas de données privées du client. À des fins de prévisibilité, il peut y avoir des scénarios où vous souhaitez acheminer cela via ExpressRoute |
| Bus des services | HTTPS entrant vers Azure Service Bus | En interne vers un centre de données | Envoyer des événements à partir d’Azure Service Bus, qui y ont été placés soit en tant qu’inscription d’événement standard, soit à partir de plug-ins et d’activités de workflow personnalisés |
| Demandes de service web | Entrant depuis IaaS/PaaS Azure | En interne vers un centre de données | Les clients peuvent héberger des applications personnalisées dans Azure et faire des requêtes de services Web Microsoft Power Platform |
| Demandes de service web | Sortant vers IaaS/PaaS Azure | En interne vers un centre de données | Les clients peuvent implémenter des plug-ins et des activités de workflow personnalisés qui font des requêtes de services hébergés Azure |
| Dataflows | Connexions de données vers Azure Data Lake Storage | En interne vers un centre de données | Fournit des capacités d’analyse et permet d’accéder à des solutions de Big Data incorporant des données des services Microsoft Power Platform et d’autres sources, en plus des insights résultant de l’analyse. |
| Azure Data Lake | Connexions de données vers Azure Data Lake Storage | En interne vers un centre de données | Fournit des capacités d’analyse et permet d’accéder à des solutions de Big Data incorporant des données des services Microsoft Power Platform et d’autres sources, en plus des insights résultant de l’analyse. |
| Azure SQL | Connexions de données vers des services SQL Azure | En interne vers un centre de données | Avec des fonctionnalités telles qu’Exporter vers l’entrepôt de données, l’utilisation d’une instance SQL Azure pour stocker des réplicas de données Microsoft Dataverse à des fins de rapport ou de réplication augmente. Il peut être utile de protéger les connexions à ces ressources via ExpressRoute. |
À l’avenir, il se peut que d’autres services publics se connectent en interne au centre de données à mesure que d’autres fonctionnalités Azure sont utilisées.