Een ExpressRoute-implementatie plannen voor gebruik met Microsoft Power Platform
Nu u hebt besloten om ExpressRoute te gebruiken voor Microsoft Power Platform, is het belangrijk om de implementatie te plannen, rekening houdend met uw behoeften en omgeving.
Vereisten voor ExpressRoute
Voor het instellen van ExpressRoute moeten verschillende vereisten worden overwogen en ingesteld. Deze kunnen leiden tot onverwachte kosten en activiteiten die, indien niet gepland, van invloed kunnen zijn op het project en de werking van andere services.
Externe vereisten
ExpressRoute biedt niet de fysieke verbinding zelf; het biedt de privé-connectiviteit via een reeds bestaande fysieke verbinding. De fysieke connectiviteit moet eerst worden ingesteld door een connectiviteitsprovider. Er zijn verschillende manieren waarop deze connectiviteit tot stand kan worden gebracht met bestaande ExpressRoute-partners. De ExpressRoute-documentatie geeft gedetailleerde uitleg over de opties en de momenteel beschikbare partners.
Als onderdeel van de planning moet u rekening houden met het volgende:
Geografie: Zoals we later in meer detail zullen bespreken, heeft het inzicht in de geografische locatie van waaruit een of meer verbindingen gemaakt moeten worden, invloed op uw algehele planning.
kosten: De connectiviteitsprovider brengt kosten in rekening voor het tot stand brengen van de privéverbinding. Dit kan een aanzienlijke kostenpost zijn; dit is afhankelijk van het type en het aantal benodigde verbindingen.
Installatietijd: In sommige gevallen moet fysieke hardware worden geïnstalleerd. Deze installatietijd moet in de implementatieplanning worden meegenomen.
Configuratie vaardigheden en bronnen: De meeste configuratiecomplexiteit zit in het instellen van de interne routering binnen uw netwerk. Het is essentieel dat u ervoor zorgt dat hiervoor vakbekwame mensen beschikbaar zijn.
Microsoft Voorwaarden
Nadat de fysieke connectiviteit tot stand is gebracht, kunt u doorgaan met het instellen van de ExpressRoute-verbindingen zelf. Dit vereist:
Een Azure-abonnement waarbinnen de ExpressRoute-circuits kunnen worden ingericht en gefactureerd.
Configuratie binnen het Azure-abonnement van de ExpressRoute-circuits, die wordt uitgevoerd door middel van de Azure-hulpprogramma's.
De routeringsconfiguratie plannen voor Microsoft Power Platform-verkeer via ExpressRoute
Bij het plannen van routering van Microsoft Power Platform-verkeer moet u rekening houden met de verschillende soorten verkeer, afhankelijk van hoe u Microsoft Power Platform configureert en gebruikt.
Om te begrijpen hoe u ExpressRoute configureert voor Microsoft Power Platform moet u rekening houden met de verschillende toepassingen en verbindingen van en naar Microsoft Power Platform, afhankelijk van de services en functies die u gebruikt.
Configuratie voor doorsturen
De routeringsconfiguratie wordt verricht door de connectiviteitsprovider of de klant, afhankelijk van het geleverde verbindingstype.
Hoewel de ExpressRoute-verbinding zelf tussen datacenters loopt, loopt de daadwerkelijke netwerkverbinding grotendeels van de clientapparaten van de gebruiker (die vaak over een breder WAN zijn verspreid, bijvoorbeeld gedistribueerde bankvestigingen). Dit betekent dat verbindingen worden gerouteerd vanaf de locatie van het clientapparaat via het WAN naar het datacenter en vervolgens over het ExpressRoute-circuit. Dit vereist zorgvuldige configuratie. Het WAN moet zo worden ingesteld dat:
De route via het netwerksubnet is geconfigureerd voor ExpressRoute.
or
Het failovercircuit wordt verkozen boven de openbare internetverbinding naar Microsoft Power Platform.
Daarom is het belangrijk om te bepalen welke subnetten binnen uw netwerk de doelen moeten zijn voor de hoofd- en fallbackverbindingen van de Border Gateway Protocol (BGP) sessie, om er zeker van te zijn dat Microsoft Power Platform-prefixes de voorkeur geven aan die route. Het is niet nodig om de services aan beide uiteinden specifiek te configureren, omdat deze configuratie wordt verricht door het adverteren van de IP-subnetten/-prefixen via deze verbinding. Wanneer een aanvraag wordt gestart, ziet het routeringsalgoritme de directe BGP-verbinding als de voorkeursroute voor verkeer naar het subnet dat is verbonden met het ExpressRoute-circuit en stuurt het verkeer die kant op.
ExpressRoute configureren voor gedistribueerde gebruikers
ExpressRoute is ontworpen om privé, toegewijde en daarom voorspelbare verbindingen te bieden van uw Verbinden naar het Microsoft netwerk. Wanneer u via de connectiviteitsprovider een speciale en directe verbinding met Microsoft hebt, verkleint u de kans dat u te maken krijgt met ander verkeer op de verbindingen die u via het netwerk van de connectiviteitsprovider Delen. Het zou niet nodig moeten zijn om ExpressRoute te gebruiken om deze verbindingskwaliteit te bereiken via een connectiviteitsprovider, maar het is wel een manier om dit te waarborgen.
In het volgende voorbeeld wordt de verbinding van een gebruiker op een vestiging via het WAN gerouteerd naar de datacenterverbinding van de klant met ExpressRoute.
Wanneer een klant een sterk gedistribueerd netwerk van gebruikers heeft, zoals een netwerk van kantoren verspreid over een land/regio, moet het netwerkverkeer efficiënt worden verbonden vanaf meerdere, sterk geografisch verspreide locaties. Het gangbare patroon hiervoor is om verbindingen via het WAN te routeren naar het lokale netwerk dat is verbonden met ExpressRoute, zoals wordt weer gegeven in de volgende afbeelding.
Als de verbinding tussen de client en ExpressRoute slecht is, of op een andere manier verzadigd of inefficiënt is, kan ExpressRoute dit niet oplossen, omdat de verbindingsproblemen bij het bereiken van het ExpressRoute-toegangspunt nog altijd gevolgen hebben voor de gebruikerservaring. In een dergelijk geval kunt u overwegen om ExpressRoute Direct te gebruiken, waarmee u rechtstreeks verbinding kunt maken met het wereldwijde netwerk van Microsoft.
Wanneer u verbinding maakt met cloudservices en wordt beperkt door problematische WAN-verbindingen, kan het nuttig zijn om lokale internetbreakouts vanuit lokale vestigingen tot stand te brengen. Hierbij wordt de tragere WAN-verbinding vermeden en gebruikgemaakt van het bereik van de connectiviteitsprovider om een directere verbinding met de cloudservice te realiseren.
Het is mogelijk om ExpressRoute-circuits vanaf meerdere locaties in te stellen, en zelfs naar individuele vestigingen, via een lokale internetbreakout, zoals weergegeven in de volgende afbeelding.
De aanpak waarbij filialen via een WAN met een centraal datacenter worden verbonden en ExpressRoute-circuits worden ingesteld tussen de klant en de datacenters, is doorgaans beter en praktischer dan te proberen een ExpressRoute-verbinding vanaf elke filiaallocatie tot stand te brengen. Microsoft Dat zou relatief duur en ingewikkeld zijn om op te zetten en te onderhouden, als dit op veel locaties moet worden uitgevoerd.
Een alternatieve aanpak is om alle vestigingen en het datacenter van de klant op hetzelfde IP-VPN te Verbinden en de IP-VPN-serviceprovider op een ExpressRoute-locatie te Verbinden. Microsoft
Als u problemen ondervindt met een lokale WAN-verbinding, is het doorgaans beter om die te optimaliseren via methoden zoals het verkrijgen van extra bandbreedte of het optimaliseren van de routering, dan te proberen een ExpressRoute-verbinding tot stand te brengen vanaf elke locatie.
Voor netwerken die zich uitstrekken over een groot geografisch gebied, kan het waardevol zijn meerdere hubs te verbinden met ExpressRoute om het aantal benodigde ExpressRoute-verbindingen te minimaliseren en toch een meer lokaal verbindingspunt voor elke gebruiker te bieden. In dit geval is het belangrijk om ervoor te zorgen dat unieke openbare IP's worden gepubliceerd via elk ExpressRoute-circuit; elk van deze subnetten moet verschillend zijn, wat vereist dat u beschikt over net zoveel publieksgerichte subnetten als ExpressRoute-verbindingen.
Dit is vooral handig als verschillende operationele gebieden zich in zeer verschillende geografische gebieden bevinden, of als de netwerkconnectiviteit tussen de gebieden beperkt is en er voor elk gebied een directere verbinding tot stand kan worden gebracht. Microsoft
Het is ook mogelijk dat verschillende regio's verschillende privacyvereisten hebben. Het is niet nodig dat elke regio ExpressRoute gebruikt, simpelweg omdat dat één regio dat doet. Het is mogelijk dat sommige verbindingen rechtstreeks via internet worden gerouteerd en andere via ExpressRoute, zoals weergegeven in de volgende afbeelding.
ExpressRoute (Standard) biedt alleen connectiviteit binnen een specifieke geografische regio; ExpressRoute Premium is vereist om toegang tot meerdere geografische locaties te bieden vanaf één ExpressRoute-verbindingspunt. Dit is bijvoorbeeld relevant als een klant kantoren in de VS en in Europa heeft, die allemaal gebruikmaken van een enkele Microsoft Power Platform-omgeving. Als de Microsoft Power Platform-tenant van de klant is geïmplementeerd in de Verenigde Staten, moet het ExpressRoute-circuit van de klant in Europa een Premium-SKU zijn. Als de Microsoft Power Platform-tenant zich in Europa bevindt, moet het Amerikaanse circuit Premium zijn.
Asymmetrische routering vermijden
Een uitdaging waar u op moet letten, is asymmetrische routering. Hierbij wordt het verkeer binnen het netwerk van de klant rechtstreeks via internet naar het datacenter geleid, maar bepaalt het retourverkeer vervolgens dat de reacties via een ExpressRoute-circuit moeten worden gerouteerd. Microsoft Dit kan vaak een firewall activeren om het verkeer te blokkeren, omdat het systeem antwoordpakketten ontvangt zonder verzoekpakketten te hebben verzonden.
Dit kan gebeuren als het lokale netwerk voor een client bepaalt dat de meest efficiënte routering naar cloudservices via het openbare internet verloopt in plaats van via het WAN naar het privé ExpressRoute-circuit. Microsoft Maar als het IP-adres van de client een openbaar IP-adres is, of via NAT-toewijzingen is omgezet in een openbaar IP-adres dat wordt geadverteerd via ExpressRoute, is de meest efficiënte route terug naar dat IP waarschijnlijk via de BGP-sessie via ExpressRoute. U kunt verschillende NAT IP's gebruiken voor uw internetedge en uw ExpressRoute-edge. Bij gebruik van een afzonderlijk bronadres komt retourverkeer ondubbelzinnig terug naar dezelfde edge.
Dit kan ook gebeuren wanneer er meerdere ExpressRoute-circuits zijn geconfigureerd voor dezelfde klant met routering van uitgaand verkeer via het ene circuit, maar retourroutering via een ander circuit, waar firewallcontroles verkeer via het retourpad kunnen blokkeren. Om asymmetrische routering via een ander ExpressRoute-circuit voor uitgaande en inkomende paden te voorkomen, is het belangrijk om ervoor te zorgen dat in elk circuit unieke openbare IP-adressen worden gepubliceerd.
Zoals u ziet, is het belangrijk om te bepalen hoe de routering binnen uw WAN wordt beheerd en ervoor te zorgen dat de paden van en naar Microsoft cloudservices zorgvuldig worden overwogen.
Externe connectiviteit van/naar Microsoft Power Platform
Bij het maken van verbindingen met Microsoft Power Platform vanaf klantlocaties zijn er meerdere verkeerstypen waarmee rekening moet worden gehouden. Dit kan leiden tot beide peeringtypen, Microsoft en privépeering. Voor deze peeringtypen kan hetzelfde ExpressRoute-circuit worden gebruikt, zoals weergegeven in de volgende afbeelding.
Er bestaan verschillende verbindingstypen tussen Microsoft Power Platform-services en een extern netwerk. Exchange Web Services-connectiviteit met server-side synchronisatie gebruikt bijvoorbeeld ExpressRoute om netwerkverkeer van het Microsoft netwerk naar het klantnetwerk door te geven. Webservicesconnectiviteit maakt gebruik van ExpressRoute voor zowel inkomend als uitgaand verkeer naar het Microsoft netwerk. Voor de HTTPS-client wordt de ExpressRoute-verbinding gebruikt voor toegang vanaf het klantnetwerk tot het Microsoft netwerk. Deze voorbeelden worden geïllustreerd in de volgende afbeelding.
Uitgaand verkeer (verkeer van Microsoft Power Platform-services)
Verschillende soorten uitgaand verkeer kunnen rechtstreeks plaatsvinden vanuit Microsoft Power Platform-services naar services van de klant. Voor elk van deze is het belangrijk op te merken dat de service van de klanten openbaar adresseerbaar moet zijn met een openbaar IP-adres dat door de Microsoft Power Platform-services kan worden omgezet via openbare DNS.
Dit IP-adres moet ook worden geadverteerd via ExpressRoute, zodat de interne netwerkroutering binnen de services weet dat het via die ExpressRoute-verbinding moet worden gerouteerd. Microsoft Microsoft Power Platform
Microsoft Power Platform-services kunnen niet specificeren welk service-instance of klantorganisatie verzoeken kan indienen bij welke IP-adressen. Daarom is het belangrijk dat verzoeken die binnenkomen op het bedrijfsnetwerk worden behandeld alsof ze van internet komen en ze als zodanig worden beveiligd.
In de volgende tabel wordt het uitgaande verkeer van Microsoft Power Platform-services beschreven.
| Beschrijving | Verkeerstype en richting | Peeringtype | Purpose |
|---|---|---|---|
| Webservices | HTTPS uitgaand van Microsoft Power Platform-services | Microsoft gluren Webservices publiceren op openbare IP-adressen die zich binnen in ExpressRoute-geconfigureerde subnetten bevinden |
Aangepaste plug-ins en workflowactiviteiten kunnen webserviceverzoeken indienen bij externe services |
| Exchange-integratie: hybride modus | HTTPS uitgaand van Microsoft Power Platform-services | Microsoft gluren Webservices moeten worden gepubliceerd op openbare IP-adressen die zich binnen in ExpressRoute-geconfigureerde subnetten bevinden |
Exchange Web Services-verzoeken van serversynchronisatie voor hybride implementaties (Microsoft Power Platform-services, Exchange on-premises) |
| Connectors | HTTPS inkomend van Microsoft Power Platform-services | Microsoft gluren | Verzoeken van Microsoft Power Platform-services via de Azure API Management-service via connectoren met behulp van de on-premises gegevensgateway |
| Azure Relay | HTTPS uitgaand van Microsoft Power Platform-services | Microsoft gluren Webservices publiceren op openbare IP-adressen die zich binnen in ExpressRoute-geconfigureerde subnetten bevinden |
Directe connectiviteit tussen Power Automate-cloudstromen en desktopstromen |
Inkomend verkeer (verkeer naar Microsoft Power Platform-services)
Het volgende inkomende verkeer is mogelijk naar Microsoft Power Platform-services vanuit het netwerk van de klant.
| Beschrijving | Verkeerstype en richting | Peeringtype | Purpose |
|---|---|---|---|
| Clientconnectiviteit | HTTPS inkomend naar Microsoft Power Platform-services | Microsoft gluren Directe internetverbinding voor statische inhoud geleverd door Azure Content Delivery Network |
Clientverzoeken voor de UI van Microsoft Power Platform-services |
| Webservices | HTTPS inkomend naar Microsoft Power Platform-services | Microsoft gluren | Verzoeken aan Microsoft Power Platform-services via de webservice-API's (SOAP, Web API). Hetzij vanuit een standaard of aangepaste clienttoepassing |
| Connectors | HTTPS inkomend naar Microsoft Power Platform-services | Microsoft gluren | Reacties terug naar Microsoft Power Platform-services door middel van de APIM's via connectoren met behulp van de on-premises gegevensgateway |
Interne Cloud-connectiviteit binnen Microsoft Power Platform-services
Microsoft Power Platform services gebruiken en integreren met diverse andere Microsoft online services die zowel in Microsoft 365 als Azure worden gehost.
| Beschrijving | Verkeerstype en richting | Purpose |
|---|---|---|
| Exchange-integratie | HTTPS uitgaand naar Microsoft 365 | Exchange-webserviceverzoeken aan Exchange Online van serversynchronisatie |
| SharePoint-integratie | HTTPS uitgaand naar Microsoft 365 | SharePoint-webserviceverzoeken aan SharePoint Online van Microsoft Power Platform-services |
| Service Bus | HTTPS uitgaand naar Azure Service Bus | Pushgebeurtenissen naar Azure Service Bus, hetzij als standaard gebeurtenisregistratie of vanuit aangepaste plug-ins en workflowactiviteiten |
| Gegevenssynchronisatie | HTTPS inkomend vanuit Azure | Inkomende verzoeken voor het bijhouden van wijzigingen voor synchronisatie van dataservices, inclusief zoeken/offline/klantinzicht |
| Verificatie | HTTPS uitgaand naar Microsoft Entra | De meeste verificatie vindt plaats via passieve omleidingen en kost tokens, maar sommige gegevens worden direct in Microsoft Entra ID gesynchroniseerd |
| Gegevensstromen | HTTPS uitgaand naar Azure Data Lake Storage | Biedt analysemogelijkheden en geeft toegang tot big data-oplossingen waarin gegevens zijn opgenomen uit zowel Microsoft Power Platform-services als andere bronnen, naast het resulterende inzicht uit analyses. |
| Connectors | HTTPS uitgaand naar Azure PaaS-services | Verbindingen met verschillende Azure PaaS-services |
| Desktop flows | HTTPS uitgaand naar Azure Relay | Directe connectiviteit tussen Power Automate-cloudstromen en desktopstromen gemaakt in Power Automate voor Desktop |
De daadwerkelijke connectiviteit tussen deze services, gehost in Microsoft of Azure-abonnementen van klanten, wordt afgehandeld door Microsoft. ExpressRoute is niet van toepassing op verbindingen met deze services.
Wanneer gebeurtenissen worden gepusht naar de servicebus, wordt de connectiviteit tussen Microsoft Power Platform-services en Azure intern afgehandeld. Daarnaast kan de klant ook verzoeken indienen bij de Service Bus om informatie op te halen. Dit kan worden beheerd via Microsoft peering.
Openbare en privé-cloudconnectiviteit van de klant van/naar Microsoft Power Platform-services
Microsoft Power Platform-services maken ook directe integratie met openbare of privé Azure-bronnen mogelijk:
Vanuit externe bronnen, met behulp van de Microsoft Dataverse-webservices-API's.
Naar externe bronnen, door gebruik te maken van gedane webserviceverzoeken.
Naar externe bronnen, met behulp van connectoren.
De implicaties hiervan moeten worden overwogen in de ExpressRoute-routering.
| Beschrijving | Verkeerstype en richting | Peeringtype | Doel |
|---|---|---|---|
| Portals | HTTPS inkomend naar Azure | Intern in het datacenter, met uitzondering van statische content die gebruikmaakt van Content Delivery Network. (Content Delivery Network wordt niet ondersteund door ExpressRoute, dus statische inhoud wordt via het openbare internet verzonden.) | Hosten van publieksservices. Er kunnen scenario's zijn waarin interne medewerkers toegang hebben tot deze bronnen, dus het kan zijn dat u verkeer via ExpressRoute wilt laten lopen in plaats van via het openbare internet |
| Leerpad | HTTPS inkomend naar Azure | Maakt gebruik van Content Delivery Network, wat niet wordt ondersteund door ExpressRoute; dus statische inhoud wordt via het openbare internet verzonden | Dit wordt gehost op een publieksservice omdat het geen persoonlijke klantgegevens bevat. Er kunnen scenario's zijn waarin u dit voor voorspelbaarheidsdoeleinden via ExpressRoute wilt routeren |
| Service Bus | HTTPS inkomend naar Azure Service Bus | Intern naar datacenter | Pullgebeurtenissen vanuit Azure Service Bus die daar zijn geplaatst als standaard gebeurtenisregistratie of vanuit aangepaste plug-ins of workflowactiviteiten |
| Webserviceaanvragen | Inkomend vanuit Azure IaaS/PaaS | Intern naar datacenter | Klanten kunnen aangepaste toepassingen hosten in Azure en aanvragen richten aan Microsoft Power Platform-webservices |
| Webserviceaanvragen | Uitgaand naar Azure IaaS/PaaS | Intern naar datacenter | Klanten kunnen aangepaste plug-ins en werkstroomactiviteiten implementeren die verzoeken indienen bij door Azure gehoste services |
| Gegevensstromen | Gegevensverbindingen naar Azure Data Lake Storage | Intern naar datacenter | Bieden analysemogelijkheden en geven toegang tot big data-oplossingen waarin gegevens zijn opgenomen uit zowel Microsoft Power Platform-services als andere bronnen, naast het resulterende inzicht uit de analyses. |
| Azure Data Lake | Gegevensverbindingen naar Azure Data Lake Storage | Intern naar datacenter | Bieden analysemogelijkheden en geven toegang tot big data-oplossingen waarin gegevens zijn opgenomen uit zowel Microsoft Power Platform-services als andere bronnen en het resulterende inzicht uit de analyses. |
| Azure SQL | Gegevensverbindingen naar Azure SQL-services | Intern naar datacenter | Door mogelijkheden als exporteren naar Data Warehouse, zal het gebruik van een Azure SQL-instance voor het bewaren van replica's van Microsoft Dataverse-gegevens voor rapportage- of replicatiedoeleinden toenemen. Het kan nuttig zijn om verbindingen met deze resources te beveiligen via ExpressRoute. |
Er kunnen in de toekomst andere openbare services komen die intern verbinding maken met het datacenter, naarmate andere Azure-mogelijkheden worden gebruikt.