Planlægge en ExpressRoute-installation til brug med Power Platform

Når du har besluttet dig for at bruge ExpressRoute til Power Platform, er det næste trin at planlægge udrulningen. Denne artikel indeholder vejledning om forudsætninger og overvejelser.

Forudsætninger for brug af ExpressRoute

ExpressRoute kræver specifikke forudsætninger. Hvis du ikke planlægger dem, kan det resultere i uventede omkostninger, forstyrre projektet og påvirke driften af andre tjenester.

• En fysisk forbindelse skal konfigureres af en forbindelsesudbyder. ExpressRoute leverer ikke selve den fysiske forbindelse. I stedet leverer den privat forbindelse via en etableret fysisk forbindelse, som skal opsat af en forbindelsesudbyder. Fysisk netværksmulighed kan etableres med ExpressRoute på flere måder. Få mere at vide i ExpressRoute-dokumentationen, og kontrollér listen over partnere i dit område.

• Et Azure-abonnement. Klargør,konfigurer og fakturér ExpressRoute-ordrer i dette abonnement.

Planlæg udrulningen

I forbindelse med planlægning skal du tage følgende faktorer i betragtning:

• Geografi: Forstå, hvor forbindelser skal oprettes geografisk.

• Omkostning: Forbindelsesudbyderen skal opkræve for oprettelse af den private forbindelse. Omkostningen kan være stor og variere, afhængigt af typen og antallet af forbindelser, du skal bruge.

• Tidspunkt for installation: I visse tilfælde skal der konfigureres fysisk hardware. Indarbejd tid til denne indsats i implementeringsplanen.

• Konfigurationsfærdigheder og -ressourcer: De fleste af kompleksiteter i forbindelse med konfiguration af den interne routing i netværket. Sørg for, at der er kvalificerede personer til rådighed til at udføre dette arbejde.

Planlægning af distributionskonfigurationen for Power Platform-trafik på tværs af ExpressRoute

Du eller forbindelsesudbyderen konfigurerer routing af Power Platform trafik via ExpressRoute, afhængigt af forbindelsestypen. Når du planlægger at dirigere Power Platform trafik, skal du tage højde for de typer trafik, forbindelsen skal håndtere, og forbindelserne til og fra Power Platform, som afhænger af de tjenester og funktioner, du bruger.

Selvom ExpressRoute-forbindelsen er mellem datacentre, kommer netværksforbindelsen primært fra brugerens klientenheder. Disse enheder distribueres ofte via et WAN-netværk (Wide Area Network), f.eks. afdelingskontorer. Forbindelser dirigeres fra klientenhedens placering via WAN til datacenteret og derefter hen over ExpressRoute-forbindelsen.

Dette kræver en forsigtig konfiguration. Opsæt WAN, så eller:

• Ruten via netværksundernet er konfigureret til ExpressRoute, eller
• Failovertilslutning vælges frem for den offentlige internetforbindelse til Power Platform.

Det er derfor vigtigt at identificere, hvilke undernet i netværket der skal være målene for de primære og fallback Border Gateway Protocol-sessionsforbindelser (BGP), for at sikre, at -præfikser foretrækker den pågældende rute. Sørg for, at Power Platform præfikser foretrækker den pågældende rute. Det er ikke nødvendigt at konfigurere tjenesterne specifikt i hver ende. Denne konfiguration udføres ved at annoncere IP-undernet eller præfikser gennem forbindelsen. Når en forespørgsel startes, kan routingalgoritmen se, at den direkte BGP-forbindelse er den foretrukne rute for trafik til det undernet, der er forbundet med ExpressRoute,og dirigerer trafik på den måde.

Konfiguration af ExpressRoute til distribuerede brugerbaser

ExpressRoute er udviklet til at levere private, dedikerede og forudsigelige forbindelser fra dit miljø til Microsoft-netværket. En dedikeret og direkte forbindelse via forbindelsesudbyderen til Microsoft reducerer muligheden for at kunne anvende anden trafik på de forbindelser, du deler via forbindelsesudbyderens netværk. Brug af ExpressRoute er ikke nødvendig for at opnå denne forbindelseskvalitet, men det er med til at sikre den.

I følgende eksempel opretter en bruger en grenplacering forbindelse til firmaets datacenterforbindelse til ExpressRoute via WAN.

Hvis brugerne er meget distribuerede, f.eks. i filialer i hele et land/område, skal netværkstrafikken forbindes effektivt fra flere geografisk adskilte placeringer. Det typiske mønster er at distribuere trafik via WAN til det lokale netværk, der er forbundet med ExpressRoute, som vist på følgende billede.

ExpressRoute kan ikke løse problemer med dårlige, mættede eller ineffektive forbindelser mellem klientenheden og ExpressRoute. Overvej at bruge ExpressRoute Direct, som giver dig mulighed for at oprette direkte forbindelse til Microsofts globale netværk.

Når du står over for udfordrende WAN-forbindelser, kan det være nyttigt at oprette lokale internetafledninger fra afdelingskontorer. Derved undgår du, at WAN-forbindelser kører langsommere og bruger forbindelsens udbyders muligheder for at opnå en mere direkte forbindelse til skytjenesten.

Du kan konfigurere ExpressRoute fra flere placeringer – og endda til individuelle forgreningsplaceringer – via en lokal internetafledning som vist på følgende billede.

Du kan afhjælpe WAN-forbindelsesproblemer ved at oprette en ExpressRoute-forbindelse fra hvert afdelingskontor. Det er dog dyrt og kompliceret at oprette forbindelser mange steder. Du har mere praktiske alternativer:

• Du kan oprette forbindelse mellem forgreningsplaceringer og et centralt datacenter via et WAN og oprette en ExpressRoute-forbindelse fra det centrale datacenter.

• Du kan optimere WAN-forbindelsen ved at tilføje båndbredde eller forbedre routing.

• Du kan etablere forbindelse mellem alle afdelingskontorer og dit datacenter på samme IP VPN, og IP VPN-tjenesteudbyderen kan oprette forbindelse til Microsoft på en ExpressRoute-placering.

I forbindelse med netværk, der er distribueret på tværs af et bredt geografisk område, kan det være en god ide at have flere hubs tilsluttet ExpressRoute for at minimere det nødvendige antal ExpressRoute-forbindelser, samtidig med at der stadig tilbydes et mere lokalt forbindelsespunkt for de enkelte brugere. Sørg for, at entydige offentlige IP-adresser publiceres via hvert ExpressRoute-kredsløb. Hvert undernet skal være unikke, hvilket kræver lige så mange offentligt rettede undernet som ExpressRoute-forbindelser.

Dette gælder især, hvis forskellige driftsområder er placeret i meget forskellige geografiske områder, eller hvis der er begrænset netværksforbindelse mellem områderne, og der kan oprettes en mere direkte forbindelse til Microsoft for hver enkelt område.

Forskellige områder kan have forskellige krav til beskyttelse af personlige oplysninger. Det er ikke alle områder, der behøver at bruge ExpressRoute, bare fordi der er ét, der gør det. Det kan være muligt at dirigere nogle forbindelser direkte via internettet og andre via ExpressRoute, som vist på følgende billede.

ExpressRoute (standard) tilbyder forbindelse i et bestemt geografisk område. Der kræves ExpressRoute Premium for at få adgang til flere geografiske forbindelser via et enkelt ExpressRoute-forbindelsespunkt. Lad os sige, at du har kontorer i USA og europæiske kontorer, der alle bruger et enkelt Power Platform miljø. Hvis din Power Platform-lejer er installeret i USA, kræver dit ExpressRoute-område i Europa leje i Premium-versionen. Hvis din Power Platform-lejer er i Europa, skal deres amerikanske gruppe være Premium.

Undgå asymmetrisk routing

En udfordring at holde øje med er asymmetrisk routing. I asymmetrisk routing sender netværkets routingkonfiguration trafik til Microsoft-datacenteret direkte via internettet, men returtrafikken dirigeres via et ExpressRoute-kredsløb. Denne uoverensstemmelse kan udløse en firewall til at afvise trafik, da den modtager svarpakker uden at have sendt tilsvarende anmodningspakker.

Asymmetrisk routing kan ske, hvis det lokale netværk for en klient vurderer, at den mest effektive routing til Microsoft Cloud Services er på tværs af det offentlige internet og ikke via WAN til den private ExpressRoute. Men hvis klient IP-adressen enten er en offentlig IP-adresse, eller den oversættes via NAT-tilknytninger til en offentlig IP-adresse, der annonceres via ExpressRoute, vil den mest effektive rute tilbage til den pågældende IP sandsynligvis være via BGP-sessionen over ExpressRoute. Du kan undgå denne situation med forskellige NAT IP-adresser på din internet edge og ExpressRoute edge. Hvis der er en tydelig kildeadresse, vender returtrafikken entydigt tilbage til den samme kant.

Asymmetrisk routing kan også forekomme, når der er konfigureret flere ExpressRoute-kredsløb for den samme kunde med rute for udgående trafik gennem ét kredsløb og omdirigering af trafik gennem et andet. Firewallkontroller kan blokere trafikken på returstien. For at undgå asymmetrisk routing på tværs af en anden ExpressRoute-rute for udgående og indgående stier er det vigtigt at sikre, at der publiceres entydige offentlige ip-adresser på tværs af alle forbindelser.

Ekstern forbindelse til/fra Power Platform

Når du opretter forbindelse til Power Platform fra dine placeringer, kan forbindelsen omfatte to typer peering, Microsoft og privat. Det samme ExpressRoute-kredsløb understøtter begge peering-typer som vist på følgende billede.

Forskellige forbindelsestyper mellem Power Platform-tjenester og et eksternt netværk. Forbindelsen til Exchange Webtjenester bruger f.eks. ExpressRoute til at sende netværkstrafik fra Microsoft-netværket til kundenetværket ved hjælp af synkronisering på serversiden. HTTPS-klienten bruges ExpressRoute-forbindelsen til adgang fra kundenetværket til Microsoft-netværket. Webtjenesters forbindelse bruger ExpressRoute for både indgående og udgående trafik til Microsoft-netværket.

Udgående trafik (trafik fra Power Platform-tjenester)

Flere typer udgående trafik kan passere direkte fra Power Platform-services til kundeservice. Kundeservicen skal være offentligt tilgængelig med en offentlig IP-adresse, som Power Platform tjenester kan fortolke via offentlig DNS. IP-adressen skal også annonceres for Microsoft via ExpressRoute, så den interne netværksrouting i Power Platform-tjenesterne ved, at den skal distribueres via den pågældende ExpressRoute-forbindelse.

Power Platform-tjenester kan ikke angive, hvilken tjenesteforekomst eller kundeorganisation der kan anmodes om hvilke IP-adresser. Det er derfor vigtigt at behandle indgående anmodninger på firmanetværket, som om de var fra internettet, og at sikre dem som sådan.

I følgende tabel beskrives udgående trafik fra Power Platform-tjenester.

Beskrivelse	Trafiktype og retning	Peeringtype	Formål
Webtjenester	HTTPS-udgående fra Power Platform-tjenester	Microsoft Peering Publicere webtjenester på offentlige IP-adresser, der findes i ExpressRoute-konfigurerede undernet.	Brugerdefinerede plug-ins og arbejdsprocesaktiviteter foretager webtjenesteanmodninger til eksterne tjenester
Exchange-integration: Hybrid tilstand	HTTPS-udgående fra Power Platform-tjenester	Microsoft Peering Publicere webtjenester på offentlige IP-adresser, der findes i ExpressRoute-konfigurerede undernet.	Exchange Webtjenester-anmodninger fra synkronisering på serversiden for udrulninger på serversiden (Power Platform-tjenester, Exchange i det lokale miljø)
Connectorer	HTTPS-indgående fra Power Platform-tjenester	Microsoft Peering	Anmodninger fra Power Platform-tjenester via Azure API Management via connectorer ved hjælp af det lokale miljø-data gateway
Azure Relay	HTTPS-udgående fra Power Platform-tjenester	Microsoft Peering Publicere webtjenester på offentlige IP-adresser, der findes i ExpressRoute-konfigurerede undernet.	Direkte forbindelse mellem Power Automate-cloudflows og -skrivebordsflows

Indgående trafik (trafik til Power Platform-tjenester)

Følgende tabel beskriver indgående trafik er mulig for Power Platform-tjenester fra kundenetværket.

Description	Trafiktype og retning	Peeringtype	Formål
Klientforbindelse	HTTPS-indgående til Power Platform-tjenester	Microsoft Peering Direkte internetforbindelse til statisk indhold, der serveres af Azure Content Delivery Network	Brugergrænsefladen til Power Platform-tjenesters brugergrænseflade
Webtjenester	HTTPS-indgående til Power Platform-tjenester	Microsoft Peering	Anmodninger til Power Platform tjenester via webtjeneste-API'er (SOAP, Web API), enten fra en standardklient eller en brugerdefineret klientapplikation
Connectors	HTTPS-indgående til Power Platform-tjenester	Microsoft Peering	Svarer tilbage til Power Platform-tjenester via API Management via connectorer ved hjælp det lokale miljø data gateway

Intern skyforbindelse i Power Platform-tjenester

Følgende tabel beskriver, hvordan Power Platform-tjenester bruges og integreres med flere andre Microsoft Online Services, der har både Microsoft 365 og Azure som vært.

Description	Trafiktype og retning	Purpose
Integration af Exchange	HTTPS-udgående til Microsoft 365	Exchange Web-tjenesteanmodninger til Exchange Online fra synkronisering på serversiden
SharePoint-integration	HTTPS-udgående til Microsoft 365	SharePoint Web-tjenesteanmodninger til SharePoint Online fra Power Platform-tjenester
Service Bus	HTTPS-udgående til Azure Service Bus	Push-hændelser til Azure Service Bus enten som standardhændelsesregistrering eller fra brugerdefinerede plug-ins og arbejdsprocesaktiviteter
Datasynkronisering	HTTPS-indgående fra Azure	Indgående forespørgsler om ændringssporing af synkronisering af datatjenester, herunder søgning/offline/kundeindsigt
Godkendelse	HTTPS-udgående til Microsoft Entra	De fleste godkendelser udføres via passive omdirigeringer og kravstokener, men nogle data synkroniseres med Microsoft Entra ID direkte.
Dataflows	HTTPS-udgående til Azure Data Lake Storage	Leverer analysefunktioner og giver adgang til big data-løsninger, der omfatter data fra Power Platform-tjenester og andre kilder, samt den indsigt, der kommer fra analyser.
Connectors	HTTPS udgående til Azure-platform-as-a-service (PaaS)-tjeneste	Forbindelser til forskellige Azure PaaS services
Desktop flows	HTTPS-udgående til Azure Relay	Direkte forbindelse mellem Power Automate-cloudflows og -skrivebordsflows, der er oprettet i Power Automate til skrivebord

Microsoft håndterer forbindelse mellem disse tjenester, som enten er vært for Microsoft- eller kunde Azure-abonnementer. ExpressRoute gælder ikke for forbindelser til disse tjenester.

Hvis hændelser overføres til Service Bus, håndteres forbindelsen mellem Power Platform-tjenester og Azure internt. Separat kan kunden anmode servicebussen om at hente oplysninger, der kan administreres via Microsoft-peering.

Offentlig og privat kundetilslutning i skyen til/fra Power Platform-tjenester

Power Platform-tjenester muliggør også direkte integration med offentlige eller private Azure-ressourcer:

• Fra eksterne kilder ved hjælp af Microsoft Dataverse-webtjeneste-API'er.
• Til eksterne kilder ved hjælp af forespørgsler fra webtjeneste.
• Til eksterne kilder ved hjælp af forbindelser.

I følgende tabel beskrives de typer trafik, der kan dirigeres via ExpressRoute til og fra Power Platform tjenester.

Description	Trafiktype og retning	Peeringtype	Purpose
Portaler	HTTPS-indgående til Azure	Internt i datacenter med undtagelse af statisk indhold, der bruger Netværk, der kan levere indhold (CDN). ExpressRoute understøtter ikke CDN, så statisk indhold bevæger sig via det offentlige internet.	Vært for offentlige tjenester. Hvis interne medarbejdere har adgang til disse ressourcer, så du vil måske have trafik på tværs af ExpressRoute i stedet for det offentlige internet.
Læringsforløb	HTTPS-indgående til Azure	Bruger CDN ExpressRoute understøtter ikke CDN, så indhold bevæger sig via det offentlige internet.	Tilknyttet som en offentlig service, da den ikke indeholder private kundedata. Af hensyn til fleksibiliteten kan der være scenarier, hvor du vil distribuere denne trafik via ExpressRoute.
Service Bus	HTTPS-indgående til Azure Service Bus	Internt til datacenter	Pull-hændelser fra Azure Service Bus der er placeret som standardhændelsesregistrering eller fra brugerdefinerede plug-ins eller arbejdsprocesaktiviteter
Webtjenesteanmodninger	Indgående fra Azure infrastruktur som en service (IaaS) eller PaaS	Internt til datacenter	Kunder kan være vært for brugerdefinerede programmer i Azure og anmode om Power Platform-webtjenester.
Webtjenesteanmodninger	Udgående til Azure IaaS/PaaS	Internt til datacenter	Kunder kan implementere brugerdefinerede plug-ins og arbejdsprocesaktiviteter, der foretager anmodninger til Azure-værtstjenester.
Dataflows	Dataforbindelser til Azure Data Lake Storage	Internt til datacenter	Levér analysefunktioner og giv adgang til big data-løsninger, der omfatter data fra både Power Platform-tjenester og andre kilder, samt den indsigt, der kommer fra analysen.
Azure Data Lake	Dataforbindelser til Azure Data Lake Storage	Internt til datacenter	Leverer analysefunktioner og giver adgang til big data-løsninger, der omfatter data fra Power Platform-tjenester og andre kilder, og den indsigt, der kommer fra analyserne.
Azure SQL	Dataforbindelser til Azure SQL-tjenester	Internt til datacenter	Med funktioner som Eksportér til Datalager vil brugen af en Azure SQL-forekomst til at indeholde replikaer af Microsoft Dataverse-data, der enten er til rapporterings- eller replikeringsformål, stige. Det kan være nyttigt at beskytte forbindelser til disse ressourcer via ExpressRoute.

Andre offentlige tjenester kan være forbundet internt til datacenteret, da flere Azure-funktioner bruges.

Næste trin

Konfigurere ExpressRoute til Power Platform