Planera en ExpressRoute-distribution för användning med Microsoft Power Platform
Nu när du har bestämt dig för att använda ExpressRoute för Microsoft Power Platform är det viktigt att planera distributionen för dina behov och din miljö.
Förutsättningar för ExpressRoute
Att konfigurera ExpressRoute kräver att flera krav måste beaktas och konfigureras. Detta kan leda till oväntade kostnader och aktiviteter som, om de inte planerats, kan påverka projektet och den fortsatta verksamheten för andra tjänster.
Externa krav
ExpressRoute tillhandahåller inte den fysiska anslutningen i sig själv. Den tillhandahåller den privata anslutningen via en redan upprättad fysisk anslutning. Den fysiska anslutningen måste först konfigureras av en anslutningsleverantör. Anslutningen kan upprättas med befintliga ExpressRoute-partner på flera sätt. ExpressRoute-dokumentationen ger detaljerad information om alternativen och de partner som för närvarande är tillgängliga.
Som en del av planeringen måste du ta med följande i beräkningen:
Geografi: Som vi kommer att diskutera mer i detalj senare kommer det att påverka din övergripande planering att förstå geografiskt var en eller flera anslutningar behöver göras.
Kostnad: Anslutningsleverantören tar betalt för att upprätta den privata anslutningen. Detta kan vara en stor kostnad. Det varierar beroende på typ och antal anslutningar.
Installationstid: I vissa fall måste fysisk maskinvara ställas in. Den här installationstiden måste tas med i implementeringsschemat.
färdigheter och resurser för konfiguration: Det mesta av konfigurationskomplexiteten ligger i att konfigurera den interna routningen i nätverket. Det är viktigt att du ser till att duktiga människor är tillgängliga för att göra detta.
Microsoft Förutsättningar
När den fysiska anslutningen är på plats kan du fortsätta att konfigurera ExpressRoute-anslutningarna själva. Detta kräver:
En Azure-prenumeration för att tillhandahålla och fakturera ExpressRoute-kretsarna.
Konfiguration inom Azure-prenumerationen på ExpressRoute-kretsarna, vilket görs via Azure-verktygen.
Planerar routningskonfigurationen för Microsoft Power Platform trafik över ExpressRoute
När du planerar för routing Microsoft Power Platform trafik, måste du ta hänsyn till de olika typerna av trafik, som beror på hur du har konfigurerat och använt Microsoft Power Platform.
För att förstå hur du konfigurerar ExpressRoute för Microsoft Power Platform måste du ta hänsyn till olika användningsområden och anslutningar till och från Microsoft Power Platform, som beror på de tjänster och funktioner som du använder.
Dirigeringskonfiguration
Ruttkonfigurationen görs antingen av anslutningsleverantören eller kunden, beroende på anslutningstypen.
Även om ExpressRoute-anslutningen i sig är mellan datacenter, kommer den faktiska nätverksanslutningen mest från användarens klientenheter (som ofta kommer att distribueras över ett bredare WAN, till exempel distribuerade bankfilialer). Detta innebär att anslutningar dirigeras från platsen för klientenheten via WAN till datacentret och sedan över ExpressRoute-kretsen. Detta kräver noggrann konfiguration. WAN måste ställas in på ett sådant sätt att:
Rutten via nätverksundernätet är konfigurerad för ExpressRoute.
or
Failover-kretsen väljs framför den offentliga internetanslutningen till Microsoft Power Platform.
Därför är det viktigt att identifiera vilka undernät inom ditt nätverk som ska vara målen för huvud- och reserv Border Gateway Protocol (BGP) -sessionsanslutningar, för att se till attMicrosoft Power Platform prefix föredrar den rutten. Det är inte nödvändigt att specifikt konfigurera tjänsterna i varje ände, eftersom denna konfiguration görs genom att annonsera IP-undernät/prefix genom denna anslutning. När en begäran initieras ser dirigeringsalgoritmen den direkta BGP-anslutningen som den föredragna vägen för trafik till undernätet som är anslutet till ExpressRoute-kretsen och styr trafiken på det sättet.
Konfigurera ExpressRoute för distribuerade användarbaser
ExpressRoute är utformat för att tillhandahålla privata, dedikerade och därför förutsägbara anslutningar från din miljö till Microsoft nätverket. När du har en dedikerad och direkt anslutning via anslutningsleverantören minskar du risken för att Microsoft behöva kämpa med annan trafik på de anslutningar du delar via anslutningsleverantörens nätverk. Det borde inte vara nödvändigt att använda ExpressRoute för att uppnå denna anslutningskvalitet via en anslutningsleverantör, men det är ett sätt att hjälpa till att säkerställa det.
I följande exempel har en användare på en filial plats sin anslutning dirigerad via WAN till kunddatacenteranslutningen till ExpressRoute.
När en kund har ett kraftigt distribuerat nätverk av användare, såsom ett filialnätverk av kontor fördelat runt om i ett land/en region, måste nätverkstrafiken anslutas effektivt från flera, geografiskt ytterst utspridda platser. Det typiska mönstret för detta är att dirigera saker genom WAN till det lokala nätverket som är anslutet till ExpressRoute, som visas i följande bild.
Om anslutningen mellan klienten och ExpressRoute är dålig, eller är mättad eller ineffektiv på något annat sätt, kommer ExpressRoute inte att kunna lösa detta eftersom anslutningsproblemen för att komma till ExpressRoute-startpunkten fortfarande kommer att påverka användarupplevelsen. I ett sådant fall bör du överväga att använda ExpressRoute Direct, vilket ger dig möjlighet att ansluta direkt till Microsoft det globala nätverket.
När du ansluter till molntjänster och begränsas av utmanande WAN-anslutningar kan det vara fördelaktigt att upprätta lokala internetavbrott från lokala filialer. Detta kommer att undvika långsammare WAN-anslutning och dra nytta av anslutningsleverantörens räckvidd för att uppnå en mer direkt anslutning till molntjänsten.
Det är möjligt att ställa in ExpressRoute-kretsar från flera platser och även ut till enskilda filialer genom en lokal internetavbrott, som visas i följande bild.
Metoden att ansluta avdelningsplatser till ett centralt datacenter via ett WAN och upprätta ExpressRoute-kretsar mellan kunden och Microsoft datacenter är vanligtvis att föredra och mer praktiskt än att försöka upprätta en ExpressRoute-anslutning från varje avdelningskontor. Det skulle vara relativt dyrt och komplicerat att installera och underhålla om detta krävdes på många platser.
En annan metod är att ansluta alla avdelningskontor och kunddatacenter på samma IP VPN och låta IP VPN-tjänstleverantören ansluta till Microsoft på en ExpressRoute-plats.
Om du har utmaningar med en lokal WAN-anslutning är det vanligtvis bättre att optimera det genom metoder som att få ytterligare bandbredd eller optimera routningen snarare än att försöka skapa en ExpressRoute-anslutning från varje plats.
För nätverk som är fördelade över ett brett geografiskt område kan det vara värdefullt att ha flera nav anslutna till ExpressRoute för att minimera antalet ExpressRoute-anslutningar som behövs samtidigt som en mer lokal anslutningspunkt för varje användare erbjuds. I det här fallet är det viktigt att se till att unika offentliga IP-adresser publiceras via varje ExpressRoute-krets. var och en av dessa undernät måste vara distinkta, vilket kräver att du har lika många offentligt vända undernät som ExpressRoute-anslutningar.
Detta är särskilt fördelaktigt om olika verksamhetsområden är belägna i mycket olika geografiska områden, eller om nätverksanslutningen mellan områdena är begränsad och en mer direkt anslutning kan Microsoft upprättas för var och en.
Det är också möjligt för olika regioner att ha olika sekretesskrav, och det är inte nödvändigt för varje region att använda ExpressRoute bara för att man gör det. Det kan vara möjligt för vissa anslutningar att dirigeras direkt via internet och andra via ExpressRoute, som visas i följande bild.
ExpressRoute (standard) erbjuder endast anslutning inom en viss geografisk region; ExpressRoute Premium krävs för att erbjuda multigeo-åtkomst från en enda ExpressRoute-anslutningspunkt. Detta skulle vara relevant om till exempel en kund hade kontor i USA och europeiska kontor, alla med en enda Microsoft Power Platform miljö. Om kundens Microsoft Power Platform klientorganisation distribueras i USA, måste deras ExpressRoute-krets i Europa vara Premium SKU. Om deras Microsoft Power Platform klientorganisation är i Europa, måste deras amerikanska krets vara Premium.
Undvik asymmetrisk routing
En utmaning att hålla utkik efter är asymmetrisk routning, där routningskonfigurationen i kundens nätverk dirigerar trafik till Microsoft datacentret direkt via Internet, men sedan avgör returtrafiken att svaren ska dirigeras via en ExpressRoute-krets. Detta kan ofta utlösa en brandvägg för att avvisa trafiken, eftersom den tar emot svarspaket utan att ha skickat begäranpaketen.
Detta kan inträffa om det lokala nätverket för en klient fastställer att den mest effektiva routningen till Microsoft molntjänster finns via det offentliga Internet i stället för via WAN till den privata ExpressRoute-kretsen. Men om klientens IP-adress antingen är en offentlig IP-adress eller översätts genomNAT mappningar till en offentlig IP-adress som annonseras via ExpressRoute, den mest effektiva vägen tillbaka till den IP skulle troligen vara genom BGP-sessionen över ExpressRoute. Du kan använda olikaNAT IP-adresser på din Internet Edge och ExpressRoute Edge. Med en distinkt källadress kommer returtrafik otvetydigt tillbaka till samma kant.
Detta kan också hända när det finns flera ExpressRoute-kretsar konfigurerade för samma kund med utgående trafikrutt via en krets men returruttning genom en annan där brandväggskontroller kan blockera trafik genom returvägen. För att undvika asymmetrisk dirigering över en annan ExpressRoute-krets för utgående och inkommande vägar är det viktigt att se till att unika offentliga IP-adresser publiceras över varje krets.
Som du ser är det viktigt att avgöra hur routningen hanteras i ditt WAN och se till att sökvägarna till och från Microsoft molntjänster övervägs noggrant.
Extern anslutning till/från Microsoft Power Platform
När du ansluter till Microsoft Power Platform från kundplatser finns det flera trafiktyper att tänka på. Detta kan leda till både peeringtyper Microsoft och privat peering, och samma ExpressRoute-krets kan användas för dessa peeringtyper som visas i följande bild.
Det finns olika anslutningstyper som finns mellan Microsoft Power Platform tjänster och ett externt nätverk. Till exempel använder Exchange Web Services-anslutning med serversynkronisering ExpressRoute för att skicka nätverkstrafik från Microsoft nätverket till kundnätverket. Anslutning till webbtjänster använder ExpressRoute för både inkommande och utgående trafik till Microsoft nätverket. För HTTPS-klienten används ExpressRoute-anslutningen för åtkomst från kundens nätverk till Microsoft nätverket. Följande bild illustrerar dessa exempel.
Utgående trafik (trafik från Microsoft Power Platform tjänster)
Flera typer av utgående trafik kan uppstå direkt från Microsoft Power Platform tjänster till kundtjänster. För var och en av dessa är det viktigt att notera att kundtjänsten måste vara offentligt adresserbar med en offentlig IP som kan lösas via offentlig DNS av Microsoft Power Platform tjänster.
Den här IP-adressen måste också annonseras till Microsoft via ExpressRoute så att den interna nätverksroutningen i Microsoft Power Platform tjänsterna vet att den ska dirigeras via ExpressRoute-anslutningen.
Microsoft Power Platform-tjänster kan inte ange vilken tjänstinstans eller kundorganisation som kan göra förfrågningar till vilka IP-adresser. Därför är det viktigt att behandla förfrågningar inkommande till företagsnätverket som om de var från internet och säkra dem som sådana.
Följande tabell beskriver utgående trafik från Microsoft Power Platform tjänster.
| Beskrivning | Trafik typ och riktning | Peering typ | Purpose |
|---|---|---|---|
| Webbtjänster | HTTPS utgående från Microsoft Power Platform tjänster | Microsoft Peering Publicera webbtjänster på offentliga IP-adresser som finns inom ExpressRoute-konfigurerade undernät |
Anpassade plug-ins och arbetsflödesaktiviteter kan göra webbtjänstförfrågningar till externa tjänster |
| Exchange Integration: hybridläge | HTTPS utgående från Microsoft Power Platform tjänster | Microsoft Peering Webbtjänster måste publiceras på offentliga IP-adresser som finns inom ExpressRoute-konfigurerade undernät |
Exchange Web Services-förfrågningar från serversynkronisering för hybriddistributioner (Microsoft Power Platform tjänster, utbyte lokalt) |
| Anslutningsappar | HTTPS inkommande från Microsoft Power Platform tjänster | Microsoft Peering | Förfrågningar från Microsoft Power Platform tjänster via Azure API Management-tjänsten via kontakter som använder den lokala datagatewayen |
| Azure Relay | HTTPS utgående från Microsoft Power Platform tjänster | Microsoft Peering Publicera webbtjänster på offentliga IP-adresser som finns inom ExpressRoute-konfigurerade undernät |
Direkt anslutning mellan Power Automate molnflöden och datorflöden |
Inkommande trafik (trafik till Microsoft Power Platform tjänster)
Följande inkommande trafik är möjlig att Microsoft Power Platform tjänster från kundnätverket.
| Beskrivning | Trafik typ och riktning | Peering typ | Purpose |
|---|---|---|---|
| Klientanslutning | HTTPS inkommande till Microsoft Power Platform tjänster | Microsoft Peering Direkt internetanslutning för statiskt innehåll som serveras av Azure Content Delivery Network |
Kundförfrågningar för Microsoft Power Platform tjänster UI |
| Webbtjänster | HTTPS inkommande till Microsoft Power Platform tjänster | Microsoft Peering | Begäran till Microsoft Power Platform tjänster via webbtjänstens API: er (SOAP, Web API). Antingen från en standard eller anpassad klientapplikation |
| Anslutningsappar | HTTPS inkommande till Microsoft Power Platform tjänster | Microsoft Peering | Svar tillbaka till Microsoft Power Platform tjänster via APIM: erna via kontakter som använder den lokala datagatewayen |
Intern molnanslutning inom Microsoft Power Platform tjänster
Microsoft Power Platform tjänster använder och integrerar med flera andra Microsoft onlinetjänster som finns både i Microsoft 365 och Azure.
| Beskrivning | Trafik typ och riktning | Purpose |
|---|---|---|
| Exchange-integration | HTTPS utgående till Microsoft 365 | Byt webbtjänstförfrågningar tillExchange Online från synkronisering på serversidan |
| SharePoint-integrering | HTTPS utgående till Microsoft 365 | SharePoint webbtjänstförfrågningar till SharePoint Online från Microsoft Power Platform tjänster |
| Service Bus | HTTPS utgående till Azure Service Bus | Push händelser till Azure Service Bus antingen som standardhändelseregistrering eller från anpassade plugin-program och arbetsflödesaktiviteter |
| Datasynk | HTTPS inkommande från Azure | Inkommande ändringsspårningsförfrågningar för synkronisering av datatjänster, inklusive sök/offline/kundinsikt |
| Autentisering | HTTPS utgående till Microsoft Entra | Mest autentisering sker genom passiva omdirigeringar och anspråks-tokens, men vissa data synkroniseras Microsoft Entra ID direkt |
| Dataflöden | HTTPS utgående till Azure Data Lake Storage | Ger analysfunktioner och ger åtkomst till stora datalösningar som innehåller data från båda Microsoft Power Platform tjänster och andra källor, förutom den resulterande insikten från analyser. |
| Anslutningsappar | HTTPS utgående till Azure PaaS-tjänster | Anslutningar till olika Azure PaaS-tjänster |
| Desktop flows | HTTPS-utgående till Azure Relay | Direkt anslutning mellan Power Automate molnflöden och dataflöden skapades i Power Automate för Desktop |
Den faktiska anslutningen mellan dessa tjänster, som finns antingen i Microsoft eller kundens Azure-prenumerationer, hanteras av Microsoft. ExpressRoute är inte tillämpligt för anslutningar med dessa tjänster.
Där händelser trycks in i servicebussen är anslutningen mellan Microsoft Power Platform tjänster och Azure hanteras internt. Separat kan kunden göra begäranden till Service Bus för att hämta information, och detta kan hanteras via Microsoft peering.
Kundens offentliga och privata molnanslutning till/från Microsoft Power Platform tjänster
Microsoft Power Platform-tjänster tillåter även direkt integrering med offentliga eller privata Azure-resurser:
Från externa källor, med hjälp av Microsoft Dataverse API:er för webbtjänster.
Till externa källor, med hjälp av begärda webbtjänster.
Till externa källor, med hjälp av kontakter.
Konsekvenserna av detta måste beaktas i ExpressRoute-routningen.
| Beskrivning | Trafik typ och riktning | Peering typ | Syfte |
|---|---|---|---|
| Portaler | HTTPS inkommande till Azure | Internt till datacenter, med undantag för statiskt innehåll, som använder Content Delivery Network. (Innehållsleveransnätverk stöds inte av ExpressRoute, så statiskt innehåll kommer att resa över det offentliga internetet.) | Värd tjänster som riktar sig till allmänheten. Det kan finnas scenarier där interna anställda kan komma åt dessa resurser, så du kanske vill att trafik ska resa över ExpressRoute snarare än det offentliga internetet |
| Utbildningsväg | HTTPS inkommande till Azure | Använder innehållsleveransnätverk, som inte stöds av ExpressRoute, så innehållet kommer att resa över det allmänna internet | Detta är värd för en offentligt riktad tjänst eftersom den inte innehåller privata kunddata. Av förutsägbarhetsskäl kan det finnas scenarier där du vill dirigera detta via ExpressRoute |
| Service Bus | HTTPS inkommande till Azure Service Bus | Internt till datacentret | Dra händelser från Azure Service Bus som har placerats där antingen som standardhändelseregistrering eller från anpassade plugin-program eller arbetsflödesaktiviteter |
| Webbtjänstförfrågningar | Inkommande från Azure IaaS/PaaS | Internt till datacentret | Kunder kan vara värd för anpassade applikationer i Azure och göra förfrågningar om Microsoft Power Platform webbservice |
| Webbtjänstförfrågningar | Utgående till Azure IaaS/PaaS | Internt till datacentret | Kunder kan implementera anpassade plugin-program och arbetsflödesaktiviteter som gör förfrågningar om Azure-värdtjänster |
| Dataflöden | Dataanslutningar till Azure Data Lake Storage | Internt till datacentret | Ge analysfunktioner och ge åtkomst till stora datalösningar som innehåller data från båda Microsoft Power Platform tjänster och andra källor, förutom den resulterande insikten från analyserna. |
| Azure Data Lake | Dataanslutningar till Azure Data Lake Storage | Internt till datacentret | Ge analysfunktioner och ge åtkomst till stora datalösningar som innehåller data från båda Microsoft Power Platform tjänster och andra källor och den resulterande insikten från analyserna. |
| Azure SQL | Dataanslutningar till Azure SQL-tjänster | Internt till datacentret | Med funktioner som Export to Data Warehouse, användningen av en Azure SQL-instans för att hålla kopior av Microsoft Dataverse data antingen för rapporterings- eller replikeringsändamål kommer att öka. Det kan vara värdefullt att skydda anslutningar till dessa resurser via ExpressRoute. |
Det kan finnas andra offentliga tjänster i framtiden som ansluter internt till datacentret eftersom andra Azure-funktioner används.