Næste trin: Ting, du skal overveje, før du bruger ExpessRoute med Microsoft Power Platform
Kompleksiteten af at konfigurere ExpressRoute håndteres ofte. Især følgende handlinger og konsekvenser overses ofte i forbindelse med planlægning eller udførelse:
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 Microsoft Power Platform over internettet, men returneres af ExpressRoute til firmanetværket, hvilket udløser en advarsel om firewallens trafik
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
Fastlæggelse af, om der skal oprettes flere ExpressRoute-installationer for distribuerede installationer
Forbindelsesproblemer med ydeevnen
LAN-forbindelser
Nogle af de almindelige problemer, en bruger kan opleve, er:
Forbindelsen i det lokale netværk understøttes allerede, før der føjes et omfattende browserprogram til mixet.
Microsoft Power Platform erstatter 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.
Det er vigtigt at forstå, at et browserprogram, der kræver mindre i forbindelse med administration af installationer på klientsiden, kræver større båndbredde end et klientprogram til klient til klient, og derfor vil et lokalnetværk, der allerede er under udvikling, komme til at lide yderligere under tilføjelsen af nye tjenester.
Ringe WAN-forbindelse
Baseret på netværksanalyse af forbindelsen til onlinetjenesten er et almindeligt mønster, at netværkstrafik på et eller andet tidspunkt fører til en intern netværksrute, der tilføjer en længere ventetid. Det kan skyldes betingelser som:
Mætning af WAN-link.
Proxybehandling med flere ventetider og afhængigheder.
Ineffektiv intern routing (f.eks. routing inden for firmanetværket og ikke routing til internettet tidligere).
Hvis der er udfordringer i forbindelse med Microsoft Power Platform-trafik, kan det også gå ud over ydeevnen på klienten.
Ringe internetforbindelse
Tilføjelse af skytjenester kan medføre ekstra forbrug og belastning på virksomhedens forbindelse til internettet. Dette kan ske, hvis:
Internetforbindelsen er ikke tilstrækkelig til at understøtte den ekstra belastning.
Inden for internetudbyderens netværk styres dirigeringen af denne trafik til Microsoft internetudbyderens netværk af internetudbyderen; effektiviteten af denne routing kan variere.
Forbindelsen påvirkes af en blanding af trafik, der påvirker kvaliteten af forbindelsen (f.eks. flere internetbaserede uddannelsessessioner, Microsoft Stream eller YouTube-videoer med trafik til et forretningskritisk program, der konkurrerer om den tilgængelige båndbredde). Dette kan være tilstrækkeligt overordnet til mængden af trafik, men det kan potentielt påvirke ydeevnen via maksimale behov, som aktivitet som videostreaming introducerer.
Du kan gøre noget ved disse ting ved at få yderligere båndbredde eller separate forbindelser via internetudbyderen. Hvis der er en separat forbindelse, der er dedikeret til prioritetstrafik, kan det især hjælpe, hvad der skal til for at sikre, at den enkelte trafik kan arbejde, og at den er uafhængig.
Du skal også sikre dig, at du konfigurerer QoS (Quality of Service) korrekt. Hvis du bruger Microsoft Teams og Microsoft Stream, skal du se QoS-kravene i ExpressRoute.
Sikkerhedsstyring
Den næste konfiguration, du skal overveje, er sikkerhedskontrolelementet. ExpressRoute krypterer eller filtrerer ikke trafik oprindeligt (med undtagelse af ExpressRoute Direct med MACsec aktiveret). Den opretter blot en privat i stedet for delt forbindelse direkte mellem kundedatacentrene Microsoft og kundedatacentrene via deres forbindelsesudbyder.
Alle anmodninger fra en Microsoft onlinetjeneste eller Azure-tjeneste til det undernet, der annonceres via et ExpressRoute-kredsløb, distribueres via det pågældende kredsløb, uanset tjenesten eller kunden. 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.
For trafik til Microsoft tjenester, fordi disse er offentlige delte tjenester, kan de tilgås direkte via det offentlige internet. 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 hostede tjenester i det lokale miljø er kunden ansvarlig for at yde lignende beskyttelse som deres egne tjenester, når der modtages trafik via en ExpressRoute-forbindelse.
Mulighed for at begrænse brugen af ExpressRoute til kun at omfatte bestemte Microsoft tjenester
En af de udfordringer, du kan stå over for, er at ville bruge ExpressRoute til en bestemt Microsoft cloud-tjeneste, 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). Det er dog muligt kun at bruge B. Gateway Protocol-communities (Border Gateway Protocol) til at konfigurere trafik til bestemte tjenester.
Dette er relevant for Microsoft Power Platform-servicer med Microsoft 365-tilstedeværelse, hvor ruter via ExpressRoute kan være egnede for én service, men ikke for begge, eller kun for bestemte individuelle servicer af Microsoft 365, f.eks. Microsoft Teams.
ExpressRoute i sig selv tilbyder i øjeblikket ikke mulighed for direkte at konfigurere tjenester, der skal distribueres via en bestemt ExpressRoute-rute på dette niveau af service granularitet, men B.P.A.-communities kan bruges til at styre dette.
Microsoft annoncerer ruter i peering-stierne Microsoft med ruter, der er tagget ved hjælp af relevante BGP-communityværdier for geografiske placeringer og tjenestetyper. Disse kan derefter konfigureres i kundens routere til at distribuere trafik for disse tjenester via ExpressRoute-bjælken.
Du kan bruge forskellige 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.
Microsoft Power Platform-specifikke BGP-community-værdier er ikke tilgængelige, som de er til Microsoft 365-tjenester. I stedet bruges de regionale BGP-communities sammen med Microsoft Azure, der bruges til de enkelte Microsoft Power Platform-miljøer. Da Microsoft Power Platform-miljøerne bruger to sæt datacentre, skal du sørge for at kigge på oversigten over områder for at kontrollere, hvilke to datacentre der bruges. Flere oplysninger BGP-communities til GCC
Microsoft 365
Da Microsoft Power Platform både tjenester og Microsoft 365 tjenester tilbydes via Microsoft peering, vil konfiguration af Microsoft peering som standard annoncere for alle Microsoft Power Platform tjenester og Microsoft 365 tjenester på tværs af ExpressRoute-kredsløbet.
Resultatet er, at hvis BGP-communities får mulighed for at distribuere trafik for én tjeneste, vil begge blive dirigeret over ExpressRoute. Dette kan eller kan være undgået, men det kan have negative resultater. Hvis du f.eks. har fundet ud af, hvilken netværksbåndbredde der skal bruges til Microsoft 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.
Selvom aktivering af ExpressRoute til Microsoft peering distribuerer al Microsoft Power Platform trafik og Microsoft 365 trafik gennem ExpressRoute-forbindelsen, er det muligt at bruge BGP-community-koder til at styre distributionen, så det kun er bestemte tjenester – f.eks. Microsoft Power Platform . tjenester, men ikke andre Microsoft 365 tjenester – der bruger ExpressRoute-forbindelsen. Ikke alle Microsoft 365-tjenester er udviklet til at fungere sammen med ExpressRoute. I øjeblikket har Microsoft Power Platform-tjenesterne ikke et angivet BGB-community, som nogle af Microsoft 365-tjenesterne har. Du bør i stedet bruge regionale BPG-communities, så de stemmer overens med det område, hvor Microsoft Power Platform-miljøet blev oprettet.
Du kan finde flere oplysninger om Microsoft 365-ruter ved at gå til dokumentationen om udvælgelse af ruter med Microsoft 365.
Da Microsoft 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-administrationen udgives f.eks. ikke på tværs af ExpressRoute.
Understøttelse af national cloud-system
Kunder, der bliver bedt om at overholde offentlige eller lande-/områdespecifikke 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 specifikke regler og certificeringer, der gælder for myndighederne, og overholder protokollerne for at imødekomme disse krav.
Se denne video, der beskriver, hvordan Microsoft Power Platform er tilgængelig med national cloud-system: Video: National cloud-system med Marty Carreras.
Når du overvejer at bruge et national-cloud-system, skal du overveje, hvilke begrænsninger der findes, da ikke alle funktioner er tilgængelige i sammenligning med offentlige skymiljøer. Tilgængeligheden efter de enkelte miljøer for Microsoft Power Platform er angivet i følgende tabel. Hvis der er andre forskelle i tilgængelighed, kan du læse dokumentationen om datacenterområder.
| Region | Understøttelse af ExpressRoute |
|---|---|
| US Government Community Cloud (GCC) | Understøttet 1 |
| Amerikansk myndighedsfællesskab Cloud Høj (GCC High) | Understøttet 1 |
| Kina | Understøttet 2 |
1 Kunder skal bruge Azure Government ExpressRoute, når de bruger US GCC eller GCC High områder, og kan ikke bruge ExpressRoute i Azures kommercielle cloudmiljø. 2 Kunder skal bruge Azure China ExpressRoute, når de bruger områder i Kina GCC eller GCC High, og de kan ikke bruge Azure Commercial Cloud ExpressRoute.
Azure ExpressRoute-omkostninger
Når du estimerer omkostningerne for ExpressRoute, skal du overveje flere elementer:
Azure-omkostninger
Omkostninger for forbindelsesudbyder
Omkostninger til indsats i forbindelse med intern opsætning
Når du skal fastslå business casen nøjagtigt, er det vigtigt at overveje alle disse omkostninger, når ExpressRoute for Microsoft Power Platform evalueres. Alle beskrives i følgende afsnit.
Azure-omkostninger
Azure ExpressRoute kan købes i forskellige modeller.
Faktureringstype
Måling: Et basisabonnement koster pr. måned med ubegrænset indgående trafik, men en afgift pr. GB for udgående trafik
Ubegrænset: Et basisabonnement koster pr. måned med ubegrænset indgående og udgående trafik
SKU / Plan
Standard
Grundlæggende forbindelse ved hjælp af ExpressRoute
Tilbyd adgang til servicer inden for et enkelt geografisk område
Hvis expressRoute-gruppen er inden for det samme område som det Microsoft Power Platform-miljø, som brugere opretter forbindelse til, er det kun ExpressRoute-standarden, der kræves for den pågældende tilstand.
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.
Du finder flere oplysninger under: Azure ExpressRoute-prisfastsættelse
Omkostninger for forbindelsesudbyder
I visse tilfælde kan omkostningerne ved at oprette forbindelse til forbindelsesudbyderen være store. Disse er adskilt fra Azure-omkostningerne for ExpressRoute.
Intern kundeindsats for at konfigurere netværksrouting
Hvis du vil aktivere 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 Microsoft Power Platform- og Microsoft 365- og Azure-tjenester i brug
Når Microsoft peering er aktiveret, konfigurerer dette trafik for Microsoft Power Platform tjenester og Azure, Microsoft 365 der skal distribueres via ExpressRoute.
Hvis du allerede bruger enten Microsoft Power Platform Dynamics 365-programmer eller Microsoft 365 uden ExpressRoute, er det vigtigt at være opmærksom på indvirkningen på disse eksisterende tjenester, når du aktiverer Microsoft peering via ExpressRoute (som er standardfunktionen). Det kan være nødvendigt at konfigurere routing ved at bruge BGP-communities til at adskille trafik til forskellige tjenester.
Genbruge ExpressRoute på tværs af flere onlinetjenester
En enkelt ExpressRoute-forbindelse kan bruges til at få adgang til flere onlinetjenester, f.eks. Microsoft Power Platform, Dynamics 365, Microsoft 365 og Azure.
Diagram, der viser en delt ExpressRoute-forbindelse med Microsoft offentlige tjenester og Azure. Microsoft peering til Microsoft 365, Microsoft Power Platform Dynamics 365 og offentlige Azure-tjenester deler den samme ExpressRoute-forbindelse med privat Azure-peering til virtuelle netværk.
ExpressRoute adskiller ikke selv 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 dirigerer ikke trafik tilbage på tværs af ExpressRoute selektivt baseret på BGP-community-koder. 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.