Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
Konfigurationen af ExpressRoute er ofte mere kompleks, end du tror. I planlægning eller udførelse er det let at overse eller undervurdere faktorer som disse:
Konfiguration af netværket til at distribuere trafik til det undernet, der er forbundet med ExpressRoute.
Undgå asymmetrisk routing, hvor trafik går direkte til Power Platform over internettet, men returneres af ExpressRoute til firmanetværket og afvises af firewallen.
Fastlæggelse af, om der skal oprettes flere ExpressRoute-installationer for distribuerede installationer.
De overordnede omkostninger ved klargøring af ExpressRoute, herunder Microsoft Azure-tjenester, klargøring af forbindelsesudbydere og konfiguration af løbende service og interne konfigurationer af it-netværk.
Du bør også overveje muligheden for problemer med forbindelsens ydeevne og sikkerhedsrisici. I denne artikel beskrives de problemer, der kan opstå, når ExpressRoute Power Platform bruges, og hvordan de kan afhjælpes.
Forbindelsesproblemer med ydeevnen
Det er vigtigt at forstå de problemer med forbindelsens ydeevne, der kan opstå med ExpressRoute.
Dårlig LAN-forbindelse: Nye tjenester kan belaste et allerede mættet lokalt netværk. F.eks. erstatter Power Platform et klientprogram til præsentation, hvor kun dataene blev overført på tværs af netværket, i stedet for både data- og præsentationsoplysninger. Selvom en browserapplikation kræver mindre administration af udrulninger på klientsiden, kræver den højere båndbredde for at overføre både data- og præsentationsoplysninger.
Dårlig WAN-forbindelse: På niveau med WAN (Wide Area Network) kan trafik krydse virksomhedens netværk i stedet for at dirigere ud til internettet tidligere. Det kan dirigeres gennem en proxyserver, eller WAN-linket kan være mættet. Disse faktorer introducerer ventetid, der kan påvirke ydeevnen betydeligt. Hvis der er udfordringer i forbindelse med Power Platform-trafik, kan det også forringe ydeevnen på klientdelen.
Ringe internetforbindelse: Tilføjelse af skytjenester kan medføre ekstra forbrug og belastning på virksomhedens forbindelse til internettet. Internetforbindelsen kan muligvis ikke bære den ekstra belastning, især i perioder med spidsbelastning. Internetudbyderen kan ineffektivt dirigere trafik til Microsoft's netværk. Forbindelsen kan lide under en blanding af trafik, der konkurrerer om den tilgængelige båndbredde, hvilket påvirker forbindelsens kvalitet.
Du kan løse disse problemer ved at få mere båndbredde eller separate forbindelser via din internetudbyder. En separat forbindelse, der er dedikeret til prioritetstrafik, kan hjælpe med at forbedre ydeevne og forudsigeligheden i trafikken. Kontrollér, at du konfigurerer QoS (Quality of Service) korrekt. Få mere at vide i ExpressRoute QoS-krav.
Sikkerhedsstyring
Den næste overvejelse er sikkerhed. ExpressRoute krypterer eller filtrerer ikke trafik som standard, undtagen ExpressRoute Direct, hvor MACsec er aktiveret. Det opretter simpelthen en privat forbindelse direkte mellem Microsoft- og kundedatacentrene via en forbindelsesudbyder.
Alle anmodninger fra en Microsoft Online Service eller Azure-tjeneste til det undernet, der annonceres via en ExpressRoute-rute, distribueres via den pågældende rute, uanset service eller kunde. Da anmodningen distribueres i netværkslaget, er der ingen kontrolelement på programniveau, der kan afgøre, om det er den rette anmoder for den pågældende destinationstjeneste.
Trafik til Microsoft Cloud bruger offentlige delte tjenester, der kan der oprettes direkte adgang til disse via offentlige internet, da der er tale om offentlige tjenester. Adgangskontrol til disse tjenester håndteres via godkendelses- og godkendelsestjenester på programniveau. De er yderligere beskyttet på infrastrukturniveau mod uautoriseret adgang og trusler som denial-of-service-angreb. For trafik fra Microsoft-tjenester til det lokale miljø til tilknyttede tjenester er kunden ansvarlig for at yde lignende beskyttelse som deres egne tjenester, når der modtages trafik på tværs af en ExpressRoute-forbindelse.
Mulighed for kun at begrænse brugen af ExpressRoute til visse Microsoft-tjenester
En af de udfordringer, du kan stå over for, er at ville bruge ExpressRoute til en bestemt Microsoft cloud service, men ikke til andre. Selvom de forskellige peering-indstillinger giver en vis grad af kontrol her, giver peering ikke selv den detaljerede styring i tjenester af samme peering-type - f.eks. kun at aktivere ruter til Azure-virtuelle maskiner, men ikke til Microsoft 365. Da Power Platform-tjenester og Microsoft 365-tjenester begge tilbydes via Microsoft-peering, vil opsætningen af Microsoft-peering som standard annoncere alle Power Platform-tjenester og Microsoft 365-tjenester på tværs af ExpressRoute-kredsløbet.
ExpressRoute giver ikke mulighed for direkte at konfigurere tjenester, der skal distribueres gennem et bestemt kredsløb. Det er dog muligt at bruge BGP-communitykoder (Border Gateway Protocol) til at styre routingen, så det kun er bestemte tjenester, der bruger ExpressRoute-forbindelsen.
Microsoft reklamerer for ruter i Microsoft-peering-stierne med ruter, der er markeret ved hjælp af de relevante værdier for BGP-communityet for geografiske placeringer og servicetyper. Du kan konfigurere dine routere til at bruge mærker til Microsoft 365-tjenester til kun at distribuere trafik for disse tjenester via ExpressRoute-ruten, og du kan distribuere resten på tværs af en anden ExpressRoute-rute eller det offentlige internet.
Ikke alle Microsoft 365-tjenester er udviklet til at fungere sammen med ExpressRoute. I øjeblikket har Power Platform-tjenesterne ikke et angivet BGP-community, som nogle af Microsoft 365-tjenesterne har. Du bør i stedet bruge regionale BGP-communities, så de stemmer overens med det område, hvor Power Platform-miljøet blev oprettet. Da Power Platform-miljøerne bruger to sæt datacentre, skal du huske at tjekke oversigten over områder og se, hvilke to datacentre der bruges.
Husk, at hvis BGP-communities får mulighed for at distribuere trafik for én tjeneste, vil begge blive dirigeret over ExpressRoute, hvilket kan have ugunstige konsekvenser. Hvis du f.eks. har besluttet, hvilken netværksbåndbredde der skal bruges til Power Platform, og har tilpasset størrelse af ExpressRoute-forbindelsen herefter, men derefter utilsigtet også distribuerer al Microsoft 365-trafik via ExpressRoute, kan det medføre udfordringer for netværket og ydeevnen.
Da Power Platform-tjenester delvist fungerer som en del af tjenesten Microsoft 365, kræves der også mange krydstjenester, f.eks. administrationsportalen og godkendelse. Det er ikke muligt at beskytte alle disse tjenester ved hjælp af ExpressRoute. Microsoft 365 Administration, for eksempel, er ikke publiceret på tværs af ExpressRoute.
Få mere at vide i Azure ExpressRoute til Microsoft 365.
Understøttelse af national cloud-system
Kunder, der bliver bedt om at overholde offentlige eller landespecifikke regler, kan vælge at anvende et national cloud-system. National cloud-systemer er fysisk placeret i et område for at imødekomme de krav, der er specifikke for det pågældende land eller område. For eksempel er Power Apps for GCC (Government Community Cloud) placeret i USA, hvor det overholder myndighedernes specifikke regler og certificeringer samt protokollerne for at imødekomme disse krav.
Se denne video, der beskriver, hvordan Power Platform er tilgængelig med national cloud-system: Video: National cloud-system med Marty Carreras.
Når du overvejer at bruge et nationalt cloudmiljø, skal du også overveje, hvilke begrænsninger der findes. Ikke alle funktioner er tilgængelige sammenlignet med offentlige cloudmiljøer. Følgende tabel viser tilgængeligheden af ExpressRoute for Power Platform i miljøer. Få mere at vide om andre forskelle i tilgængelighed i Power Automate områders oversigt.
| Land/område | ExpressRoute-support |
|---|---|
| US Government Community Cloud (GCC) | Understøttet 1 |
| US Government Community Cloud High (GCC High) | Understøttet 1 |
| Kina | Understøttet 2 |
1 Du skal bruge Azure Government ExpressRoute, ikke ExpressRoute for Azure commercial cloud.
2 Du skal bruge Azure China 21Vianet ExpressRoute, ikke ExpressRoute for Azure commercial cloud.
Azure ExpressRoute-omkostninger
Hvis du vil fastslå business casen nøjagtigt, skal du huske at medtage Azure omkostninger, omkostninger til forbindelsesudbydere og omkostninger til intern opsætningsindsats, når du estimerer omkostningerne til ExpressRoute for Power Platform.
Azure-omkostninger
Azure ExpressRoute kan købes i forskellige modeller. Den model, du vælger, afhænger af den type forbindelse, du vil oprette, og de tjenester, du vil have adgang til.
Faktureringstype
- Betal efter forbrug: Et basisabonnement koster pr. måned med ubegrænset indgående trafik, men en afgift pr. GB for udgående trafik
- Ubegrænset: En grundlæggende abonnementudgift hver måned med ubegrænset indgående og udgående trafik
SKU / Plan
Standard
- Grundlæggende forbindelse ved hjælp af ExpressRoute
- Tilbyder adgang til servicer inden for et enkelt geografisk område
Hvis ExpressRoute-gruppen er i det samme område som det Power Platform-miljø, brugere opretter forbindelse til, er det kun ExpressRoute-standarden, der kræves for det pågældende kredsløb.
Premium
- Giver adgang til geografiske tjenester verden over, uanset hvor der oprettes forbindelse
Hvis en bruger opretter forbindelse via en ExpressRoute-rute fra et andet område end sluttjenesten, kræver de ExpressRoute Premium for den pågældende ExpressRoute-rute.
Få mere at vide i Azure ExpressRoute Prisfastsættelse.
Omkostninger for forbindelsesudbyder
I visse tilfælde kan omkostningerne ved at oprette forbindelse til forbindelsesudbyderen være store. Disse omkostninger er adskilt fra Azure-omkostningerne for ExpressRoute.
Intern kundeindsats for at konfigurere netværksrouting
Hvis du vil bruge ExpressRoute, skal netværksrouting konfigureres internt. For mange kunder kræver det en intern afgift for netværksteamet eller en ekstern omkostning for en it-udbyder eller som minimum en omkostning for salgsmuligheder i forbindelse med interne medarbejderes indsats for at fokusere på konfigurationen.
Påvirkninger af eksisterende Power Platform-, Microsoft 365- og Azure-tjenester
Når Microsoft-peering er aktiveret, konfigureres trafik til Power Platform-tjenester, Microsoft 365 og Azure, så den som standard distribueres via ExpressRoute. Hvis du allerede bruger enten Power Platform, Dynamics 365-programmer eller Microsoft 365 uden ExpressRoute, er det vigtigt at være opmærksom på påvirkningen af disse eksisterende tjenester, når du aktiverer Microsoft-peering via ExpressRoute. Det kan være nødvendigt at konfigurere routing ved at bruge BGP-communities til at adskille trafik til forskellige tjenester.
Genbrug af ExpressRoute på tværs af flere onlinetjenester
En enkelt ExpressRoute-forbindelse kan bruges til at få adgang til flere onlinetjenester, f.eks. Power Platform, Dynamics 365, Microsoft 365 og Azure.
Diagram, der viser en delt ExpressRoute-forbindelse til Microsofts offentlige tjenester og Azure. Microsoft-peering til Microsoft 365, Power Platform, Dynamics 365 og offentlige Azure-tjenester deler den samme ExpressRoute-forbindelse med privat Azure-peering til virtuelle netværk.
ExpressRoute adskiller ikke forskellige typer Microsoft-tjenester fra et bestemt undernet. Det er muligt at bruge BGP-communitykoder til at styre routingen af trafik til bestemte tjenester på tværs af ExpressRoute. Microsoft distribuerer ikke trafik tilbage over ExpressRoute, der er baseret på BGP-communitykoder. Hvis trafik skal returneres forskelligt, afhængigt af tjenestetypen, skal du kontrollere, at trafik kommer fra forskellige offentlige IP-adresser. Da al trafik, der vender tilbage til et undernet, håndteres på netværksniveau, er det vigtigt kun at konfigurere lidt trafik fra et undernet til at bruge ExpressRoute, da dette kan medføre asymmetrisk routing.