Eine ExpressRoute-Bereitstellung für die Verwendung mit Power Platform planen

Nachdem Sie sich für die Verwendung von ExpressRoute für Power Platform entschieden haben, müssen Sie als Nächsten die Bereitstellung planen. Dieser Artikel enthält Informationen zu Voraussetzungen und Überlegungen.

Voraussetzungen für den Einsatz von ExpressRoute

Für ExpressRoute sind bestimmte Voraussetzungen erforderlich. Wenn diese nicht eingeplant werden, kann dies zu unerwarteten Kosten führen, das Projekt unterbrechen und den Betrieb anderer Dienste beeinträchtigen.

• Eine von einem Konnektivitätsanbieter eingerichtete physische Verbindung. ExpressRoute stellt die physische Verbindung selbst nicht bereit. Stattdessen wird private Konnektivität über eine etablierte physische Verbindung bereitgestellt, die von einem Konnektivitätsanbieter eingerichtet werden muss. Es gibt verschiedene Möglichkeiten, eine physische Konnektivität mit ExpressRoute-Partnern herzustellen. Weitere Informationen finden Sie in der ExpressRoute-Dokumentation. Sehen Sie sich außerdem die Liste der Partner in Ihrer Region an.

• Ein Azure-Abonnement. Nutzen Sie dieses Abonnement, um die ExpressRoute-Verbindungen bereitzustellen, zu konfigurieren und abzurechnen.

Die Bereitstellung planen

Bei der Planung müssen Sie die folgenden Faktoren berücksichtigen:

• Geografie: Finden Sie heraus, wo Verbindungen geografisch hergestellt werden müssen.

• Kosten: Der Konnektivitätsanbieter berechnet Gebühren für den Aufbau der privaten Verbindung. Diese Kosten können erheblich sein und je nach Art und Anzahl der benötigten Verbindungen variieren.

• Zeit für die Einrichtung: In einigen Fällen muss physische Hardware eingerichtet werden. Planen Sie die Zeit für diesen Aufwand in den Implementierungsplan ein.

• Konfigurationskenntnisse und -ressourcen: Der größte Teil der Komplexität liegt in der Einrichtung des internen Routings in Ihrem Netzwerk. Stellen Sie sicher, dass qualifiziertes Personal für diese Arbeit zur Verfügung steht.

Die Routingkonfiguration für Power Platform-Datenverkehr in ExpressRoute planen

Je nach Verbindungstyp konfigurieren Sie oder der Konnektivitätsanbieter das Routing des Power Platform-Datenverkehrs über ExpressRoute. Berücksichtigen Sie beim Planen des Routings des Power Platform-Datenverkehrs, welche Art von Datenverkehr die Verbindung verarbeitet muss, sowie die Verbindungen zu und von Power Platform, was von den Diensten und Features abhängt, die Sie verwenden.

Obwohl die ExpressRoute-Verbindung zwischen Rechenzentren besteht, stammt die Netzwerkverbindung in erster Linie von den Clientgeräten des Benutzers. Diese Geräte sind häufig über ein Wide Area Network (WAN) verteilt, z. B. in Zweigstellen. Verbindungen werden vom Clientgerät über das WAN zum Rechenzentrum und dann über die ExpressRoute-Verbindung geleitet.

Gehen Sie bei dieser Konfiguration mit Bedacht vor. Richten Sie das WAN so ein, dass entweder:

• Die Weiterleitung über das Netzwerksubnetz für ExpressRoute konfiguriert ist oder
• Die Failover-Schaltung wird der öffentlichen Internetverbindung zu Power Platform vorgezogen.

Es ist wichtig, zu ermitteln, welche Subnetze in Ihrem Netzwerk die Ziele für die Haupt- und Fallback-Sitzungsverbindungen des Border Gateway Protocol (BGP) sein sollen. Stellen Sie sicher, dass Power Platform-Präfixe diese Weiterleitung bevorzugen. Es ist nicht erforderlich, die Dienste an jedem Ende speziell zu konfigurieren. Diese Konfiguration erfolgt durch Ankündigen der IP-Subnetze oder Präfixe über die Verbindung. Wenn eine Anforderung initiiert wird, betrachtet der Routingalgorithmus diese direkte BGP-Verbindung als bevorzugte Route für den Datenverkehr zu dem mit ExpressRoute verbundenen Subnetz, und leitet den Datenverkehr auf diese Weise weiter.

ExpressRoute für verteilte Benutzerbasen konfigurieren

ExpressRoute ist so konzipiert, dass private, dedizierte und vorhersehbare Verbindungen von Ihrer Umgebung zum Microsoft-Netzwerk bereitgestellt werden. Eine dedizierte und direkte Verbindung über den Konnektivitätsanbieter zu Microsoft reduziert das Potenzial, mit anderem Datenverkehr auf den Verbindungen, die Sie über das Netzwerk des Konnektivitätsanbieters teilen, konkurrieren zu müssen. Die Verwendung von ExpressRoute ist nicht erforderlich, um diese Qualität der Verbindung zu erreichen, aber sie trägt dazu bei, sie sicherzustellen.

Im folgenden Beispiel stellt ein Benutzender in einer Zweigstelle die Rechenzentrumsverbindung des Unternehmens mit ExpressRoute über das WAN her

Wenn Ihre Benutzer stark verteilt sind, z. B. in Zweigstellen in einem Land/einer Region, muss der Netzwerkverkehr von mehreren geografisch getrennten Standorten aus effizient verbunden werden. Das typische Muster ist die Weiterleitung des Datenverkehrs über das WAN zum lokalen Netzwerk, das mit ExpressRoute verbunden ist, wie im folgenden Bild gezeigt.

ExpressRoute kann schlechte, überlastete oder ineffiziente Verbindungen zwischen dem Clientgerät und ExpressRoute nicht beheben. Erwägen Sie ExpressRoute Direct zu verwenden, womit Sie sich direkt mit dem globalen Netzwerk von Microsoft verbinden können.

Wenn Sie mit schwierigen WAN-Verbindungen konfrontiert sind, kann es hilfreich sein, lokale Internet-Breakouts von Zweigstellen aus einzurichten. Durch diesen Ansatz werden die langsameren WAN-Verbindung vermieden und die Reichweite des Konnektivitätsanbieters genutzt, um eine direktere Verbindung zum Cloud Service herzustellen.

Sie können ExpressRoute-Verbindungen von mehreren Standorten und sogar zu einzelnen Zweigstellen über einen lokalen Internet-Breakout einzurichten, wie in der folgenden Abbildung gezeigt.

Um WAN-Konnektivitätsprobleme zu verringern, können Sie eine ExpressRoute-Verbindung von jeder Zweigstelle aus einrichten. Das Einrichten von Verbindungen ist jedoch an vielen Standorten teuer und kompliziert in der Wartung. Sie haben praktischere Alternativen:

• Sie können Zweigstellen über ein WAN mit einem zentralen Rechenzentrum verbinden und eine ExpressRoute-Verbindung vom zentralen Rechenzentrum aus einrichten.

• Sie können die WAN-Verbindung optimieren, indem Sie Bandbreite hinzufügen oder das Routing verbessern.

• Sie können alle Zweigstellen und Ihre Rechenzentren über dasselbe IP-VPN (virtuelles privates Netzwerk) verbinden und den IP-VPN-Dienstanbieter eine Verbindung mit Microsoft an einem ExpressRoute-Standort herstellen lassen.

Bei Netzwerken, die über ein weites geografisches Gebiet verteilt sind, kann die Verwendung mehrere Hubs mit ExpressRoute die Anzahl der benötigten ExpressRoute-Verbindungen minimieren und gleichzeitig jedem Benutzenden einen lokaleren Verbindungspunkt bieten. Stellen Sie sicher, dass über jede ExpressRoute-Verbindung eindeutige öffentliche IPs veröffentlicht werden. Jedes Subnetz muss eindeutig sein, was so viele öffentlich zugängliche Subnetze wie ExpressRoute-Verbindungen erfordert.

Dieser Ansatz ist hilfreich, wenn sich verschiedene Betriebsbereiche in geografisch sehr unterschiedlichen Gebieten befinden oder die Netzwerkkonnektivität zwischen den Bereichen begrenzt ist und für jeden Bereich eine direktere Verbindung zu Microsoft hergestellt werden kann.

Unterschiedliche Regionen können unterschiedliche Datenschutzanforderungen haben. Nicht jede Region muss ExpressRoute verwenden, nur weil es eine tut. Einige Verbindungen können möglicherweise direkt über das Internet geleitet werden, während andere ExpressRoute verwenden, wie in der folgenden Abbildung gezeigt.

ExpressRoute (Standard) bietet Konnektivität in einer bestimmten geografischen Region. ExpressRoute Premium ist erforderlich, um Multi-Geo-Zugriff von einem einzigen ExpressRoute-Verbindungspunkt aus anzubieten. Angenommen, Sie haben Niederlassungen in den USA und in Europa, die alle eine einzige Power Platform-Umgebung verwenden. Wenn Ihr Power Platform-Mandant in den USA bereitgestellt wird, muss Ihre ExpressRoute-Verbindung in Europa die Premium-Version verwenden. Wenn Ihr Power Platform-Mandant sich in Europa befindet, muss Ihre US-Verbindung eine Premium-Verbindung sein.

Asymmetrisches Routing vermeiden

Eine Herausforderung, auf die man achten sollte, ist das asymmetrische Routing. Beim asymmetrischen Routing sendet die Routingkonfiguration Ihres Netzwerks den Datenverkehr direkt über das Internet an das Microsoft-Rechenzentrum, der Rückverkehr wird jedoch über eine ExpressRoute-Verbindung geleitet. Diese fehlende Übereinstimmung kann dazu führen, dass eine Firewall den Datenverkehr zurückweist, da sie Antwortpakete empfängt, ohne die dazugehörigen Anforderungspakete gesendet zu haben.

Asymmetrisches Routing kann vorkommen, wenn das lokale Netzwerk eines Clients feststellt, dass das effizienteste Routing zu Microsoft Cloud Services über das öffentliche Internet und nicht über das WAN zur privaten ExpressRoute-Verbindung erfolgt. Wenn die Client-IP-Adresse entweder eine öffentliche IP-Adresse ist oder durch Zuordnungen von Netzwerkadressenübersetzungen (NAT) zu einer öffentlichen IP-Adresse übersetzt wird, die über ExpressRoute angekündigt wird, wäre die effizienteste Weiterleitung zurück zu dieser Adresse wahrscheinlich über die BGP-Sitzung über ExpressRoute. Um diese Situation zu vermeiden, verwenden Sie verschiedene NAT-IPs auf Ihrem Internet-Edge und ExpressRoute-Edge. Mit einer eindeutigen Quelladresse kommt der zurückkehrende Datenverkehr eindeutig zur selben Edge zurück.

Asymmetrisches Routing kann auch auftreten, wenn mehrere ExpressRoute-Verbindungen für denselben Kunden konfiguriert sind, wobei ausgehender Datenverkehr über eine Verbindung und Rückverkehr über eine andere Verbindung geleitet wird. Firewall-Überprüfungen blockieren möglicherweise den Datenverkehr auf dem Rückweg. Um asymmetrisches Routing über eine andere ExpressRoute-Verbindung für den ausgehenden und den eingehenden Pfad zu vermeiden, stellen Sie sicher, dass eindeutige öffentliche IPs über jede Verbindung veröffentlicht werden.

Externe Konnektivität zu/von Power Platform

Wenn Sie von Ihren Standorten aus eine Verbindung mit Power Platform herstellen, kann die Verbindung zwei Arten von Peering umfassen: Microsoft und privat. Dieselbe ExpressRoute-Verbindung unterstützt beide Peering-Typen, wie in der folgenden Abbildung gezeigt.

Es gibt verschiedene Verbindungstypen zwischen Power Platform-Diensten und einem externen Netzwerk. Die Konnektivität der Exchange-Webdienste mit serverseitiger Synchronisierung verwendet beispielsweise ExpressRoute, um den Netzwerkdatenverkehr vom Microsoft-Netzwerk an das Kundennetzwerk weiterzuleiten. Der HTTPS-Client verwendet die ExpressRoute-Verbindung für den Zugriff vom Kundennetzwerk auf das Microsoft-Netzwerk. Die Webdienstkonnektivität verwendet ExpressRoute für den ein- und ausgehenden Microsoft-Netzwerkdatenverkehr.

Ausgehender Datenverkehr (Datenverkehr von Power Platform-Diensten)

Verschiedene Arten von ausgehendem Datenverkehr können direkt von den Power Platform-Diensten an die Kundenservices weitergegeben werden. Der Kundenservice muss öffentlich ansprechbar sein und eine öffentliche IP-Adresse haben, die Power Platform-Dienste über das öffentliche DNS auflösen können. Die IP-Adresse muss auch über ExpressRoute bei Microsoft angekündigt werden, damit das interne Netzwerkrouting in Power Platform-Diensten weiß, dass Datenverkehr über diese ExpressRoute-Verbindung geleitet werden soll.

Power Platform-Dienste können nicht angeben, welche Serviceinstanz oder Kundenorganisation Anforderungen an welche IP-Adressen senden kann. Daher ist es wichtig, eingehende Unternehmensnetzwerkanforderungen so zu behandeln, als kämen sie aus dem Internet, und sie entsprechend zu sichern.

Die folgende Tabelle beschreibt den ausgehenden Datenverkehr von Power Platform-Diensten.

Beschreibung	Datenverkehrstyp und -richtung	Peering-Typ	Zweck
Webdienste	HTTPS ausgehend von Power Platform-Diensten	Microsoft-Peering Veröffentlichen Sie Webdienste auf öffentlichen IP-Adressen in in ExpressRoute konfigurierten Subnetzen.	Benutzerdefinierte Plug-Ins und Workflowaktivitäten senden Webdienstanforderungen an externe Dienste
Exchange-Integration: Hybridmodus	HTTPS ausgehend von Power Platform-Diensten	Microsoft-Peering Veröffentlichen Sie Webdienste auf öffentlichen IP-Adressen in in ExpressRoute konfigurierten Subnetzen.	Exchange-Webdienstanforderungen von der serverseitigen Synchronisierung für Hybridbereitstellungen (Power Platform-Dienste, Exchange lokal)
Konnektoren	HTTPS eingehend von Power Platform-Diensten	Microsoft-Peering	Anforderungen von Power Platform-Diensten durch das Azure API Management durch Connectors mit dem lokalen Datengateway
Azure Relay	HTTPS ausgehend von Power Platform-Diensten	Microsoft-Peering Veröffentlichen Sie Webdienste auf öffentlichen IP-Adressen in in ExpressRoute konfigurierten Subnetzen.	Direkte Verbindung zwischen Power Automate-Cloud-Flows und Desktop-Flows

Eingehender Datenverkehr (Datenverkehr an Power Platform-Dienste)

Der folgende Tabelle beschreibt den eingehenden Datenverkehr zu den Power Platform-Diensten von den Kundennetzwerken aus.

Beschreibung	Datenverkehrstyp und -richtung	Peering-Typ	Zweck
Client-Konnektivität	HTTPS eingehend an Power Platform-Dienste	Microsoft-Peering Direkte Internetverbindung für statische Inhalte, die vom Azure Content Delivery Network bereitgestellt werden	Clientanforderungen für die Benutzeroberfläche von Power Platform-Diensten
Webdienste	HTTPS eingehend an Power Platform-Dienste	Microsoft-Peering	Anforderungen an Power Platform-Dienste über die Webdienst-APIs (SOAP, Web-API), entweder von einer Standard- oder einer benutzerdefinierten Client-Anwendung aus
Konnektoren	HTTPS eingehend an Power Platform-Dienste	Microsoft-Peering	Antworten zurück zu Power Platform-Diensten durch das API Management über Connectors unter Verwendung des lokalen Datengateways

Interne Cloud-Konnektivität in Power Platform-Diensten

Die folgende Tabelle beschreibt, wie Power Platform-Dienste andere Microsoft-Onlinedienste, die sowohl in Microsoft 365 als auch Azure gehostet werden, verwenden und sich mit diesen integrieren.

Beschreibung	Datenverkehrstyp und -richtung	Purpose
Exchange-Integration	HTTPS ausgehend an Microsoft 365	Exchange-Webdienstanforderungen an Exchange Online über die serverseitige Synchronisierung
SharePoint-Integration	HTTPS ausgehend an Microsoft 365	SharePoint-Webdienstanforderungen an SharePoint Online über Power Platform-Dienste
Service Bus	HTTPS ausgehend an Azure Service Bus	Push-Ereignisse an Azure Service Bus als Standardereignisregistrierung oder über benutzerdefinierte Plug-ins und Workflowaktivitäten
Datensynchronisierung	HTTPS eingehend von Azure	Eingehende Änderungsnachverfolgungs-Anforderungen für die Synchronisierung von Datendiensten, einschließlich Suche/offline/Kundeneinblick
Authentifizierung	HTTPS ausgehend an Microsoft Entra	Die meisten Authentifizierungen erfolgen über passive Weiterleitungen und Anspruchstoken, einige Daten werden jedoch direkt mit Microsoft Entra ID synchronisiert.
Dataflows	HTTPS ausgehend an Azure Data Lake Storage	Bietet Analysefunktionen und ermöglicht den Zugriff auf Big-Data-Lösungen, die Daten von Power Platform-Diensten und anderen Quellen zusätzlich zu den daraus resultierenden Erkenntnissen aus der Analyse enthalten.
Konnektoren	HTTPS ausgehend an Azure Platform-as-a-Service (PaaS)-Dienste	Verbindungen zu verschiedenen Azure PaaS-Diensten
Desktop flows	HTTPS ausgehend an Azure Relay	Direkte Konnektivität zwischen Power Automate-Cloud-Flows und -Desktop-Flows, die in Power Automate für Desktop erstellt wurden

Microsoft übernimmt die Konnektivität zwischen diesen Diensten, die entweder in Microsoft oder in Azure-Abonnements des Kunden gehostet werden. ExpressRoute gilt nicht für Verbindungen mit diesen Diensten.

Wenn Ereignisse per Push auf den Service Bus übertragen werden, erfolgt die Konnektivität zwischen Power Platform-Diensten und Azure intern. Der Kunde kann davon abgesehen Anforderungen an den Service Bus senden, um Informationen abzurufen, was von Microsoft-Peering übernommen werden kann.

Öffentliche und private Cloud-Konnektivität des Kunden zu/von Power Platform-Diensten

Power Platform-Dienste ermöglichen auch die direkte Integration in öffentliche oder private Azure-Ressourcen:

• Aus externen Quellen, unter Verwendung der Microsoft Dataverse-Webdienst-APIs
• An externe Quellen über gesendet Webdienstanforderungen
• Zu externen Quellen über Connectors

In der folgenden Tabelle werden die Arten von Datenverkehr beschrieben, die über ExpressRoute an Power Platform-Dienste oder von diesen weitergeleitet werden können.

Beschreibung	Datenverkehrstyp und -richtung	Peering-Typ	Purpose
Portale	HTTPS eingehend an Azure	Intern an das Rechenzentrum mit Ausnahme von statischen Inhalten, die das Content Delivery Network (CDN) verwenden. ExpressRoute unterstützt CDN nicht, daher werden statische Inhalte über das öffentliche Internet übertragen.	Hosten Sie öffentlich zugängliche Dienste. Wenn interne Mitarbeiter auf diese Ressourcen zugreifen können, möchten Sie möglicherweise, dass der Datenverkehr über ExpressRoute und nicht über das öffentliche Internet geleitet wird.
Lernpfad	HTTPS eingehend an Azure	Verwendet das CDN. ExpressRoute unterstützt CDN nicht, daher werden Inhalte über das öffentliche Internet übertragen.	Wird auf einem öffentlich zugänglichen Dienst gehostet, da es keine privaten Kundendaten enthält. Aus Gründen der Vorhersagbarkeit möchten Sie dies eventuell über ExpressRoute weiterleiten.
Service Bus	HTTPS eingehend an Azure Service Bus	Intern an das Rechenzentrum	Pull-Ereignisse von Azure Service Bus, die dort als Standardereignisregistrierung oder über benutzerdefinierte Plug-ins oder Workflowaktivitäten platziert wurden.
Webservice-Anfragen	Eingehend von Azure Infrastructure-as-a-Service (IaaS) oder PaaS	Intern an das Rechenzentrum	Kunden können benutzerdefinierte Anwendungen in Azure hosten und Power Platform-Webdienstanforderungen senden.
Webservice-Anfragen	Ausgehend zu Azure IaaS/PaaS	Intern an das Rechenzentrum	Kunden können benutzerdefinierte Plug-Ins und Workflowaktivitäten implementieren, die Anforderungen an Dienste senden, die von Azure gehostet werden.
Dataflows	Datenverbindungen zu Azure Data Lake Storage	Intern an das Rechenzentrum	Analysefunktionen bereitstellen und den Zugriff auf Big-Data-Lösungen ermöglichen, die Daten von Power Platform-Diensten und anderen Quellen zusätzlich zu den daraus resultierenden Erkenntnissen aus der Analyse enthalten.
Azure Data Lake	Datenverbindungen zu Azure Data Lake Storage	Intern an das Rechenzentrum	Analysefunktionen bereitstellen und den Zugriff auf Big-Data-Lösungen ermöglichen, die Daten von Power Platform-Diensten und anderen Quellen zusätzlich zu den daraus resultierenden Erkenntnissen aus der Analyse enthalten.
Azure-SQL	Datenverbindungen zu Azure SQL-Diensten	Intern an das Rechenzentrum	Mit Funktionen wie dem Export nach Data Warehouse nimmt die Verwendung einer Azure SQL-Instanz zur Speicherung von Replikaten von Microsoft Dataverse-Daten für Berichts- oder Replikationszwecke zu. Es kann sinnvoll sein, Verbindungen zu diesen Ressourcen über ExpressRoute zu schützen.

Möglicherweise stellen weitere öffentliche Dienste intern eine Verbindung mit dem Rechenzentrum her, wenn mehr Azure-Funktionen verwendet werden.

Nächster Schritt

ExpressRoute für Power Platform einrichten