Att tänka på innan du använder ExpressRoute med Microsoft Power Platform
Komplexiteten med att ställa in ExpressRoute underskattas ofta. I synnerhet förbises följande åtgärder och konsekvenser, antingen i planering eller utförande:
Konfigurera ditt nätverk för att dirigera trafik till det undernät som är anslutet till ExpressRoute
Undvik asymmetrisk dirigering, där trafiken går direkt till Microsoft Power Platform över internet men returneras av ExpressRoute till företagsnätverket, vilket utlöser avvisning av trafiken från brandväggen
De totala kostnaderna för att tillhandahålla ExpressRoute, inklusiveMicrosoft Azure tjänster, tillhandahållande av anslutningsleverantörer och löpande konfiguration av tjänster och interna IT-nätverk
Avgöra om flera ExpressRoute-kretsar ska upprättas för distribuerade distributioner
Problem med anslutningsprestanda
LAN-anslutning
Några av de vanligaste problemen som en användare kan uppleva är:
Anslutningen inom det lokala nätverket är redan mättad innan du lägger till ett rikt webbläsarprogram till mixen.
Microsoft Power Platform ersätter ett klientprogram som fungerar som klient för klienten och där endast data har överförts över nätverket, i stället för både data och presentationsinformation.
Det är viktigt att förstå att en webbläsarapplikation kräver mindre bandbredd än en tjock klientapplikation, samtidigt som det kräver mindre när det gäller distribution av klientsidan, och därför kommer ett redan mättat lokalt nätverk att drabbas ytterligare med tillägget av nya tjänster.
Dålig WAN-anslutning
Baserat på nätverksanalys av anslutning till onlinetjänsten är ett vanligt mönster att nätverkstrafiken någon gång går igenom en intern nätverksrutt som ger betydande latens. Detta kan bero på villkor som:
Mättnad av WAN-länken.
Proxybehandling, medför mer latens och overhead.
Ineffektiv intern routing (till exempel routing inom företagsnätverket snarare routing till internet tidigare).
Om Microsoft Power Platform trafik lider av dessa utmaningar, kan också prestanda hos kunden drabbas.
Dålig internetanslutning
Lägga till molntjänster kan ge extra konsumtion och belastning på företagets anslutning till internet. Detta kan hända om:
Internetanslutningen är inte tillräcklig för att stödja den extra belastningen.
Inom internetleverantörens nätverk styrs routningen av trafiken till Microsoft nätverket av internetleverantören. Effektiviteten på routningen kan variera.
Anslutningen lider av en blandning av trafik, vilket påverkar anslutningens kvalitet (till exempel flera internetbaserade träningspass, Microsoft Stream, eller YouTube videor med trafik till en affärskritisk applikation som konkurrerar om tillgänglig bandbredd). Detta kan vara tillräckligt totalt för trafikvolymen, men kan potentiellt påverka prestanda genom toppar av efterfrågan, vilken aktivitet som videostreaming kommer att introducera.
Dessa saker kan hanteras genom att få ytterligare bandbredd eller separata anslutningar via ISP. I synnerhet kan en separat anslutning som är avsedd för prioritetstrafik hjälpa till med både prestanda och förutsägbarhet för trafiken.
Se också till att du ställer in QoS (Quality of Service) korrekt. Om du använderMicrosoft Teams ochMicrosoft Stream, se QoS-kraven i ExpressRoute.
Säkerhetskontroll
Nästa konfiguration du behöver tänka på är säkerhetskontrollen. ExpressRoute i sig krypterar eller filtrerar inte trafik internt (med undantag för ExpressRoute Direct med MACsec aktiverat), utan upprättar bara en privat, i stället för delad, anslutning direkt mellan kundens Microsoft datacenter via deras anslutningsleverantör.
Alla begäranden från en Microsoft onlinetjänst eller Azure-tjänst till undernätet som annonseras via en ExpressRoute-krets dirigeras via den kretsen, oavsett tjänst eller kund. Eftersom begäran dirigeras till nätverkslagret finns det ingen kontroll på applikationsnivå för att avgöra om det är en lämplig beställare för den måltjänsten.
För trafik till Microsoft tjänster kan de, eftersom dessa är offentliga delade tjänster, nås direkt via det offentliga Internet. Åtkomstkontroll till dessa tjänster hanteras genom autentiserings- och auktoriseringstjänster på applikationsnivå. De skyddas vidare på infrastrukturnivå mot intrång och hot som förnekande av tjänsteattacker.
För trafik från Microsoft tjänster till lokala värdbaserade tjänster ansvarar kunden för att tillhandahålla liknande skydd för sina egna tjänster när trafik tas emot via en ExpressRoute-anslutning.
Möjlighet att begränsa ExpressRoute-användningen till endast vissa Microsoft tjänster
En av de utmaningar som du kan stöta på är att du vill använda ExpressRoute för en viss Microsoft molntjänst men inte för andra. Även om de olika peering-alternativen ger viss kontrollnivå här ger peering i sig inte granular kontroll inom tjänster av samma peering-typ (om du till exempel endast vill aktivera vidarebefordran till Azure virtuella datorer men inte till Microsoft 365). Det är dock möjligt att använda Border Gateway Protocol (BGP) -grupper för att bara konfigurera trafik för specifika tjänster.
Detta är relevant för Microsoft Power Platform-tjänster med Microsoft 365 närvaro, där vidarebefordran via ExpressRoute kan vara nödvändigt för en tjänst, men inte för båda, eller endast för vissa enskilda Microsoft 365-tjänster av till exempel Microsoft Teams.
ExpressRoute i sig erbjuder för närvarande inte möjligheten att direkt konfigurera tjänster som ska dirigeras via en specifik ExpressRoute-krets på denna servicenivå, men BGP-grupper kan användas för att kontrollera detta.
Microsoft annonserar vägar i peeringsökvägarna med vägar taggade med hjälp av Microsoft lämpliga BGP-communityvärden för geografiska platser och tjänsttyper. Dessa kan sedan konfigureras i kundens routrar för att dirigera trafik för dessa tjänster genom ExpressRoute-kretsen.
Du kan använda olika taggar för Microsoft 365 tjänster för att dirigera endast trafik för dessa tjänster via ExpressRoute och dirigera resten antingen över en annan ExpressRoute-tjänst eller det offentliga Internet.
Microsoft Power Platform-specifika BGP-community-värden är inte tillgängliga på samma sätt som de är för Microsoft 365-tjänster. I stället används regionala BGP-samhällen med motsvarande Microsoft Azure regioner som används för varje Microsoft Power Platform miljö. Eftersom Microsoft Power Platform miljöer använder två uppsättningar datacenter, se till att titta på regionöversikten för att kontrollera vilka två datacenter som används. Mer information: BGP-grupper för GCC.
Microsoft 365
Eftersom Microsoft Power Platform både tjänster och Microsoft 365 tjänster erbjuds via Microsoft peering skulle konfiguration av Microsoft peering som standard annonsera alla Microsoft Power Platform tjänster och Microsoft 365 tjänster i ExpressRoute-kretsen.
Resultatet av detta är att om BGP-samhällen ska kunna dirigera trafik för en tjänst skulle båda ledas över ExpressRoute. Detta kanske eller inte är önskvärt, men det kan få ogynnsamma resultat. Om du till exempel har fastställt vilken bandbredd som behövs för Microsoft Power Platform och dimensionerade ExpressRoute-anslutningen därefter, men sedan oavsiktligt även dirigera all din Microsoft 365 trafik via ExpressRoute, kan detta mätta ditt nätverk och orsaka prestandautmaningar.
Även om aktivering av ExpressRoute för Microsoft peering dirigerar all Microsoft Power Platform trafik Microsoft 365 via ExpressRoute-anslutningen är det möjligt att använda BGP-communitytaggar för att styra routningen så att endast specifika tjänster, till exempel Microsoft Power Platform tjänster men inte andra Microsoft 365 tjänster, använder ExpressRoute-anslutningen. Alla Microsoft 365 tjänster är inte utformade för att fungera med ExpressRoute. För närvarande har inte Microsoft Power Platform tjänster någon särskilt avsedd BTP-community, vilket vissa Microsoft 365 tjänster har. Istället bör du använda regionala BPG-samhällen för att matcha med regionen där Microsoft Power Platformmiljö skapades.
Mer information om vidarebefordran finns i Microsoft 365, gå till dokumentationen på selektiv vidarebefordran med Microsoft 365.
Eftersom Microsoft Power Platform tjänster delvis fungerar som en del av Microsoft 365 tjänsten krävs även många crossover-tjänster, till exempel administrationsportalen och autentisering. Det är inte möjligt att skydda alla dessa tjänster med hjälp av ExpressRoute; Microsoft 365 administrationscentret publiceras till exempel inte över ExpressRoute.
Stöd för suveräna moln
Kunder som måste uppfylla myndighets- eller lands-/regionsspecifika regler kan välja att använda ett nationellt moln. Suveräna moln är fysiskt belägna i en region för att uppfylla de specifika kraven för just den regeringen eller landet. Till exempel, Power Apps för Government Community Cloud (GCC) ligger i USA, där det möter USA:s regering specifika regler och certifieringar och uppfyller protokoll för att uppfylla dessa krav.
Titta på den här videon som beskriver hur Microsoft Power Platform är tillgängligt med suveräna moln: Video: Suveräna moln med Marty Carreras.
När du överväger att använda en suverän molnmiljö måste du överväga vilka begränsningar som finns, eftersom inte alla funktioner är tillgängliga jämfört med offentliga molnmiljöer. Tillgängligheten för varje miljö för Microsoft Power Platform anges i följande tabell. För andra skillnader i tillgänglighet, läs igenom dokumentationen om datacenterregioner.
| Region | Stöd för ExpressRoute |
|---|---|
| US Government Community Cloud (GCC) | Stöds 1 |
| Moln för amerikansk myndighetscommunity hög (GCC High) | Stöds 1 |
| Kina | Stöds 2 |
1 Kunder måste använda Azure Government ExpressRoute när de använder amerikanska GCC eller GCC High regioner och kan inte använda Azures kommersiella ExpressRoute-moln. 2 Kunder måste använda Azure China ExpressRoute när de använder regioner i Kina och kan inte använda Azure Commercials moln ExpressRoute.
Azure ExpressRoute kostnader
När du beräknar kostnaderna för ExpressRoute måste du överväga flera element:
Azure-kostnader
Kostnader för leverantör av anslutningar
Kostnader för intern installation
När du bestämmer affärsfallet korrekt är det viktigt att ta hänsyn till alla dessa kostnader när du utvärderar ExpressRoute för Microsoft Power Platform. Var och en diskuteras i följande avsnitt.
Azure-kostnader
Azure ExpressRoute kan köpas i olika modeller.
Faktureringstyp
Uppmätt: en basprenumerationskostnad per månad med obegränsad inkommande trafik men en avgift per GB för utgående trafik
Obegränsad: en basabonnemangskostnad per månad med obegränsad in- och utgående trafik
SKU/Plan
Standard
Grundläggande anslutning med ExpressRoute
Erbjuder tillgång till tjänster inom en enda geografisk region
Om ExpressRoute-kretsen ligger inom samma region som Microsoft Power Platform miljö som användarna ansluter till, krävs bara ExpressRoute-standarden för den kretsen
Premium
Erbjuder tillgång till globala geografiska tjänster, varhelst anslutningen görs
Om en användare ansluter via en ExpressRoute-krets från en annan region än sin sluttjänst, behöver de ExpressRoute Premium för den ExpressRoute-kretsen.
Mer information: Azure ExpressRoute-prissättning
Kostnader för leverantör av anslutningar
I vissa fall kan kostnaderna för att upprätta anslutningen med anslutningsleverantören vara betydande. Dessa är separata från Azure-kostnaderna för ExpressRoute.
Intern kundinsats för att konfigurera nätverksdirigering
För att aktivera ExpressRoute måste nätverksdirigering konfigureras internt.
För många kunder kräver detta en intern korsladdning till nätverksteamet eller en extern kostnad för en IT-outsourcingleverantör, eller åtminstone möjlighetskostnad för den interna personalens ansträngningar att fokusera på konfigurationen.
Effekter på befintliga Microsoft Power Platform, Microsoft 365 och Azure-tjänster som används
När Microsoft peering är aktiverat konfigurerar detta trafik för Microsoft Power Platform tjänster Microsoft 365 och Azure så att den dirigeras via ExpressRoute.
Om du redan använder antingen Microsoft Power Platform Dynamics 365-program eller Microsoft 365 utan ExpressRoute är det viktigt att vara känslig för påverkan på dessa befintliga tjänster när du aktiverar Microsoft peering via ExpressRoute (vilket är standardbeteendet). Det kan vara nödvändigt att konfigurera routing genom att använda BGP-grupper för att separera trafik till olika tjänster.
Återanvända ExpressRoute över flera onlinetjänster
En enda ExpressRoute-anslutning kan användas för att få åtkomst till flera onlinetjänster, till exempel Microsoft Power Platform, Dynamics 365, Microsoft 365 och Azure.
Diagram som visar en delad ExpressRoute-anslutning med Microsoft offentliga tjänster och Azure. Microsoft peering för Microsoft 365, Microsoft Power Platform, Dynamics 365 och offentliga Azure-tjänster delar samma ExpressRoute-anslutning med privat Azure-peering för virtuella nätverk.
ExpressRoute i sig separerar inte olika typer av Microsoft tjänster från ett visst undernät. Det är möjligt att använda BGP-communitytaggar för att styra dirigering av trafik till vissa tjänster över ExpressRoute. Microsoft dirigerar inte trafik tillbaka över ExpressRoute selektivt baserat på BGP-communitytaggar. Om trafiken måste returneras annorlunda baserat på tjänsten, se till att trafiken kommer från olika offentliga IP-adresser. Eftersom all trafik som återvänder till ett undernät hanteras på nätverksnivå, skulle det vara farligt att bara konfigurera en del trafik från ett undernät för att använda ExpressRoute, eftersom detta kan leda till asymmetrisk dirigering.