Eine ExpressRoute-Bereitstellung für die Verwendung mit Microsoft Power Platform planen
Jetzt, da Sie sich entschieden haben, ExpressRoute für Microsoft Power Platform zu verwenden, ist es wichtig, die Bereitstellung entsprechend Ihren Anforderungen und Ihrer Umgebung zu planen.
Voraussetzungen für ExpressRoute
Für das Einrichten von ExpressRoute müssen mehrere Voraussetzungen berücksichtigt und eingerichtet werden. Diese können zu unerwarteten Kosten und Aktivitäten führen, die sich auf das Projekt und die weitere Funktion anderer Dienste auswirken können, , wenn sie nicht geplant sind.
Externe Voraussetzungen
ExpressRoute stellt die physische Verbindung selbst nicht bereit. Es stellt die private Konnektivität über eine bereits hergestellte physische Verbindung zur Verfügung. Die physische Konnektivität muss zunächst von einem Konnektivitätsanbieter eingerichtet werden. Es gibt mehrere Möglichkeiten, diese Konnektivität mit bestehenden ExpressRoute-Partnern herzustellen. Die ExpressRoute-Dokumentation enthält detaillierte Erläuterungen zu den Optionen und den aktuell verfügbaren Partnern.
Bei der Planung müssen Sie Folgendes berücksichtigen:
Geografie: Wie wir später noch ausführlicher besprechen werden, wirkt sich das Verständnis des geografischen Standorts, von dem aus eine oder mehrere Verbindungen hergestellt werden müssen, auf Ihre Gesamtplanung aus.
Kosten: Der Konnektivitätsanbieter berechnet für die Herstellung der privaten Verbindung eine Gebühr. Dies kann je nach Typ und Anzahl der benötigten Verbindungen erhebliche Kosten verursachen.
Einrichtungszeit: In einigen Fällen muss physische Hardware eingerichtet werden. Diese Rüstzeit muss in den Implementierungsplan aufgenommen werden.
Konfiguration Skills und Ressourcen: Der größte Teil der Konfigurationskomplexität liegt in der Einrichtung des internen Routings innerhalb Ihres Netzwerks. Es ist wichtig, dass Sie dafür sorgen, dass qualifiziertes Personal zur Verfügung steht.
Microsoft Voraussetzungen
Nachdem die physische Verbindung hergestellt wurde, können Sie die ExpressRoute-Verbindungen selbst einrichten. Dazu ist Folgendes erforderlich:
Ein Azure-Abonnement, das die Bereitstellung und Abrechnung der ExpressRoute-Verbindungen beinhaltet
Konfiguration innerhalb des Azure-Abonnements der ExpressRoute-Verbindungen, die über die Azure-Tools erfolgt
Planung der Routingkonfiguration für Microsoft Power Platform-Datenverkehr in ExpressRoute
Wenn Sie das Routing des Microsoft Power Platform-Datenverkehrs planen, müssen Sie die verschiedenen Typen von Datenverkehr berücksichtigen, die davon abhängen, wie Sie Microsoft Power Platform konfiguriert und verwendet haben.
Um zu verstehen, wie ExpressRoute für Microsoft Power Platform konfiguriert wird, müssen Sie die verschiedenen Verwendungen und Verbindungen von und zu Microsoft Power Platform berücksichtigen, die von den Diensten und Funktionen abhängen, die Sie verwenden.
Routingkonfiguration
Die Routingkonfiguration wird je nach bereitgestelltem Verbindungstyp entweder vom Konnektivitätsanbieter oder vom Kunden durchgeführt.
Obwohl die ExpressRoute-Verbindung selbst zwischen Rechenzentren besteht, erfolgt die eigentliche Netzwerkverbindung hauptsächlich über die Clientgeräte des Benutzers (die oft über ein breiteres WAN verteilt sind, beispielsweise verteilte Bankfilialen). Dies bedeutet, dass Verbindungen vom Standort des Clientgeräts über das WAN zum Rechenzentrum und dann über die ExpressRoute-Verbindung geleitet werden. Dies erfordert eine sorgfältige Konfiguration. Das WAN muss folgendermaßen eingerichtet werden:
Die Route über das Netzwerksubnetz ist für ExpressRoute konfiguriert.
or
Die Failover-Schaltung wird der öffentlichen Internetverbindung zu Microsoft Power Platform vorgezogen.
Daher ist es wichtig, zu ermitteln, welche Subnetze in Ihrem Netzwerk die Ziele für die Haupt- und Fallback-Sitzungsverbindungen des Border Gateway Protocol (BGP) sein sollen, um sicherzustellen, dass Microsoft Power Platform-Präfixe diese Route bevorzugen. Es ist nicht erforderlich, die Dienste an jedem Ende speziell zu konfigurieren, da diese Konfiguration durch Ankündigen der IP-Subnetze/-Präfixe über diese Verbindung erfolgt. 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.
Konfigurieren von ExpressRoute für verteilte Benutzerbasen
ExpressRoute dient der Bereitstellung privater, dedizierter und daher vorhersehbarer Verbindungen von Ihrem Teilen zum Microsoft Netzwerk. Wenn Sie über den Konnektivitätsanbieter eine dedizierte und direkte Verbindung zu Microsoft haben, verringern Sie die Möglichkeit, mit anderem Datenverkehr auf den Verbindungen, die Sie über das Netzwerk des Konnektivitätsanbieters herstellen, in Konflikt geraten zu müssen. Es sollte nicht notwendig sein, ExpressRoute zu verwenden, um diese Qualität der Verbindung durch einen Konnektivitätsanbieter zu erreichen, es ist jedoch eine Möglichkeit, dies sicherzustellen.
Im folgenden Beispiel wird die Verbindung eines Benutzers in einer Zweigstelle über das WAN zur Rechenzentrumsverbindung des Kunden an ExpressRoute weitergeleitet.
Wenn ein Kunde über ein weit verteiltes Netzwerk von Benutzern verfügt, z. B. ein Netzwerk von Zweigstellen, die über ein Land/eine Region verteilt sind, muss der Netzwerkverkehr von mehreren, geografisch stark verteilten Standorten effizient verbunden werden. Das typische Muster hierfür ist die Weiterleitung über das WAN zum lokalen Netzwerk, das mit ExpressRoute verbunden ist, wie im folgenden Bild gezeigt.
Wenn die Verbindung zwischen dem Client und ExpressRoute schlecht oder auf andere Weise gesättigt oder ineffizient ist, kann ExpressRoute dies nicht lösen, da die Verbindungsprobleme beim Erreichen des ExpressRoute-Einstiegspunkts die Benutzererfahrung weiterhin beeinträchtigen. In einem solchen Fall sollten Sie die Verwendung von ExpressRoute Direct in Betracht ziehen. Damit können Sie Verbinden direkt auf das globale Netzwerk von Microsoft zugreifen.
Wenn Sie eine Verbindung mit Cloud Service herstellen und durch schwierige WAN-Verbindungen eingeschränkt sind, kann es von Vorteil sein, lokale Internet-Breakouts über lokale Verzweigungen einzurichten. Dadurch wird die langsamere WAN-Verbindung vermieden und die Reichweite des Konnektivitätsanbieters genutzt, um eine direktere Verbindung zum Cloud Service zu erzielen.
Es ist möglich, ExpressRoute-Verbindungen von mehreren Standorten und sogar zu einzelnen Zweigstellen über einen lokalen Internet-Breakout einzurichten, wie im folgenden Bild gezeigt.
Der Ansatz, Zweigstellen über ein WAN mit einem zentralen Rechenzentrum zu verbinden und ExpressRoute-Verbindungen zwischen dem Kunden und den Rechenzentren herzustellen, ist in der Regel vorzuziehen und praktischer, als zu versuchen, von jeder Zweigstelle aus eine ExpressRoute-Verbindung herzustellen. Microsoft Das wäre relativ teuer und kompliziert einzurichten und zu warten, wenn dies an vielen Standorten erforderlich wäre.
Ein alternativer Ansatz besteht darin, alle Zweigstellen und das Kundenrechenzentrum auf demselben IP-VPN zu Verbinden und den IP-VPN-Dienstanbieter an einem ExpressRoute-Standort zu Verbinden Microsoft zu haben.
Wenn Sie Probleme mit einer lokalen WAN-Verbindung haben, ist es in der Regel besser, diese durch Methoden wie die Gewinnung zusätzlicher Bandbreite oder die Optimierung des Routings zu optimieren, anstatt zu versuchen, eine ExpressRoute-Verbindung von jedem Standort aus herzustellen.
Bei Netzwerken, die über ein weites geografisches Gebiet verteilt sind, kann es sinnvoll sein, mehrere Hubs mit ExpressRoute zu verbinden, um die Anzahl der benötigten ExpressRoute-Verbindungen zu minimieren und gleichzeitig jedem Benutzer einen lokaleren Verbindungspunkt anzubieten. In diesem Fall ist es wichtig, sicherzustellen, dass über jede ExpressRoute-Schaltung eindeutige öffentliche IPs veröffentlicht werden; jedes dieser Subnetze muss eindeutig sein, was voraussetzt, dass Sie so viele öffentlich zugängliche Subnetze wie ExpressRoute-Verbindungen haben.
Dies ist insbesondere dann von Vorteil, wenn sich verschiedene Einsatzgebiete in völlig unterschiedlichen geografischen Gebieten befinden oder wenn die Netzwerkkonnektivität zwischen den Gebieten eingeschränkt ist und für jedes Gebiet eine direktere Verbindung hergestellt werden kann. Microsoft
Es ist auch möglich, dass verschiedene Regionen unterschiedliche Datenschutzanforderungen haben, und es ist nicht notwendig, dass jede Region ExpressRoute verwendet, nur weil dies auf eine zutrifft. Einige Verbindungen können möglicherweise direkt über das Internet und andere über ExpressRoute geleitet werden, wie in der folgenden Abbildung gezeigt.
ExpressRoute (Standard) bietet Konnektivität nur innerhalb einer bestimmten geografischen Region. ExpressRoute Premium ist erforderlich, um Multi-Geo-Zugriff von einem einzigen ExpressRoute-Verbindungspunkt aus anzubieten. Dies wäre relevant, wenn ein Kunde beispielsweise über Niederlassungen in den USA und in Europa verfügt, die alle eine einzige Microsoft Power Platform-Umgebung verwenden. Wenn der Microsoft Power Platform-Mandant des Kunden in den USA bereitgestellt wird, muss seine ExpressRoute-Verbindung in Europa die Premium-SKU sein. Wenn ihr Microsoft Power Platform-Mandant sich in Europa befindet, muss deren US-Verbindung eine Premium-Verbindung sein.
Vermeiden von asymmetrischem Routing
Eine zu beachtende Herausforderung ist das asymmetrische Routing. Dabei leitet die Routing-Konfiguration innerhalb des Kundennetzwerks den Datenverkehr direkt über das Internet an das Rechenzentrum weiter, der Rückverkehr legt dann jedoch fest, dass die Antworten über einen ExpressRoute-Schaltkreis weitergeleitet werden sollen. Microsoft Dies kann oft dazu führen, dass eine Firewall den Verkehr zurückweist, da sie Antwortpakete empfängt, ohne die Anforderungspakete gesendet zu haben.
Dies kann passieren, wenn das lokale Netzwerk eines Clients feststellt, dass die effizienteste Weiterleitung zu Microsoft Cloud-Diensten über das öffentliche Internet und nicht über das WAN zum privaten ExpressRoute-Schaltkreis erfolgt. Wenn die Client-IP-Adresse jedoch eine öffentliche IP-Adresse ist oder durch NAT-Zuordnungen zu einer öffentlichen IP-Adresse übersetzt wird, die über ExpressRoute angekündigt wird, wäre die effizienteste Route zurück zu dieser IP wahrscheinlich über die BGP-Sitzung über ExpressRoute. Sie können verschiedene NAT-IPs auf Ihrem Internet-Edge und ExpressRoute-Edge verwenden. Mit einer eindeutigen Quelladresse kommt der Rückverkehr eindeutig zur selben Rand zurück.
Dies kann auch passieren, wenn mehrere ExpressRoute-Verbindungen für denselben Kunden konfiguriert sind, wobei ausgehender Datenverkehr über eine Verbindung geleitet wird, die Rückführung jedoch über eine andere Verbindung erfolgt, bei der Firewallprüfungen den Datenverkehr über den Rückweg blockieren können. Um asymmetrisches Routing über einen unterschiedlichen ExpressRoute-Schaltkreis für den ausgehenden und den eingehenden Pfad zu vermeiden, ist es wichtig, sicherzustellen, dass eindeutige öffentliche IPs über jede Verbindung veröffentlicht werden.
Wie Sie sehen, ist es wichtig, zu bestimmen, wie das Routing innerhalb Ihres WAN verwaltet wird, und sicherzustellen, dass die Pfade zu und von Microsoft Cloud-Diensten sorgfältig bedacht werden.
Externe Konnektivität zu/von Microsoft Power Platform
Beim Herstellen von Verbindungen zu Microsoft Power Platform von Kundenstandorten aus sind mehrere Datenverkehrstypen zu berücksichtigen. Dies kann sowohl zu Peering-Typen Microsoft als auch zu privatem Peering führen, und für diese Peering-Typen kann derselbe ExpressRoute-Schaltkreis verwendet werden, wie in der folgenden Abbildung gezeigt.
Es gibt verschiedene Verbindungstypen zwischen Microsoft Power Platform-Diensten und einem externen Netzwerk. Beispielsweise nutzt die Exchange-Webdienstkonnektivität mit serverseitiger Synchronisierung ExpressRoute, um Netzwerkverkehr vom Microsoft Netzwerk zum Kundennetzwerk weiterzuleiten. Die Webdienstkonnektivität verwendet ExpressRoute für eingehenden und ausgehenden Datenverkehr zum Microsoft Netzwerk. Für den HTTPS-Client wird die ExpressRoute-Verbindung für den Zugriff vom Kundennetzwerk auf das Microsoft Netzwerk verwendet. Das folgende Bild zeigt diese Beispiele.
Ausgehender Datenverkehr (Datenverkehr von Microsoft Power Platform-Diensten)
Verschiedene Arten von ausgehendem Datenverkehr können direkt von den Microsoft Power Platform-Diensten zu den Kundenservices erfolgen. Für diese muss jeweils beachtet werden, dass der Kundenservice öffentlich über eine öffentliche IP-Adresse ansprechbar sein muss, die durch das öffentliche DNS von den Microsoft Power Platform-Diensten aufgelöst werden kann.
Diese IP-Adresse muss auch über ExpressRoute bekannt gegeben werden, damit das interne Netzwerkrouting innerhalb der Dienste weiß, dass es über diese ExpressRoute-Verbindung weitergeleitet werden soll. Microsoft Microsoft Power Platform
Microsoft 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 als solche zu sichern.
Die folgende Tabelle beschreibt den ausgehenden Datenverkehr von Microsoft Power Platform-Diensten.
| Beschreibung | Datenverkehrstyp und -richtung | Peering-Typ | Purpose |
|---|---|---|---|
| Webdienste | HTTPS ausgehend von Microsoft Power Platform-Diensten | Microsoft Peering (Blicken) Webdienste auf öffentlichen IP-Adressen veröffentlichen, die sich in ExpressRoute-konfigurierten Subnetzen befinden |
Benutzerdefinierte Plug-ins und Workflowaktivitäten können Webdienstanforderungen an externe Dienste senden |
| Exchange-Integration: Hybridmodus | HTTPS ausgehend von Microsoft Power Platform-Diensten | Microsoft Peering (Blicken) Webdienste müssen auf öffentlichen IP-Adressen veröffentlicht werden, die sich in ExpressRoute-konfigurierten Subnetzen befinden. |
Exchange-Webdienstanforderungen von der serverseitigen Synchronisierung für Hybridbereitstellungen (Microsoft Power Platform-Dienste, Exchange lokal) |
| Konnektoren | HTTPS eingehend von Microsoft Power Platform-Diensten | Microsoft Peering (Blicken) | Anforderungen von Microsoft Power Platform-Diensten durch den Azure API Management-Dienst über Connectors mit dem lokalen Datengateway |
| Azure Relay | HTTPS ausgehend von Microsoft Power Platform-Diensten | Microsoft Peering (Blicken) Webdienste auf öffentlichen IP-Adressen veröffentlichen, die sich in ExpressRoute-konfigurierten Subnetzen befinden |
Direkte Verbindung zwischen Power Automate-Cloud-Flows und Desktop-Flows |
Eingehender Datenverkehr (Datenverkehr an Microsoft Power Platform-Dienste)
Der folgende eingehende Datenverkehr ist vom Kundennetzwerk an Microsoft Power Platform-Dienste möglich.
| Beschreibung | Datenverkehrstyp und -richtung | Peering-Typ | Purpose |
|---|---|---|---|
| Client-Konnektivität | HTTPS eingehend an Microsoft Power Platform-Dienste | Microsoft Peering (Blicken) Direkte Internetverbindung für statische Inhalte, die vom Azure Content Delivery Network bereitgestellt werden |
Clientanforderungen für die Benutzeroberfläche von Microsoft Power Platform-Diensten |
| Webdienste | HTTPS eingehend an Microsoft Power Platform-Dienste | Microsoft Peering (Blicken) | Anforderungen an Microsoft Power Platform-Dienste über die Webdienst-APIs (SOAP, Web-API). Entweder über eine Standard- oder eine benutzerdefinierte Clientanwendung |
| Konnektoren | HTTPS eingehend an Microsoft Power Platform-Dienste | Microsoft Peering (Blicken) | Antworten zurück zu Microsoft Power Platform-Diensten durch die APIMs über Connectors unter Verwendung des lokalen Datengateways |
Interne Cloud-Konnektivität innerhalb von Microsoft Power Platform-Diensten
Microsoft Power Platform Dienste verwenden und integrieren mehrere andere Microsoft Onlinedienste, die sowohl in Microsoft 365 als auch in Azure gehostet werden.
| Beschreibung | Datenverkehrstyp und -richtung | Zweck |
|---|---|---|
| Exchange-Integration | HTTPS ausgehend an Microsoft 365 | Exchange-Webdienstanforderungen an Exchange Online über die serverseitigen Synchronisierung |
| SharePoint-Integration | HTTPS ausgehend an Microsoft 365 | SharePoint-Webdienstanforderungen an SharePoint Online über Microsoft 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 Microsoft Power Platform-Diensten und anderen Quellen zusätzlich zu den daraus resultierenden Erkenntnissen aus der Analyse enthalten. |
| Konnektoren | HTTPS ausgehend an Azure PaaS-Dienste | Verbindungen zu verschiedenen Azure PaaS-Diensten |
| Desktop flows | HTTPS ausgehend an Azure Relay | Direkte Konnektivität zwischen den in Power Automate für Desktop erstellten Power Automate-Cloud-Flows und Desktop-Flows |
Die eigentliche Konnektivität zwischen diesen Diensten, die entweder in Microsoft oder in Azure-Abonnements der Kunden gehostet werden, wird von verwaltet Microsoft. ExpressRoute gilt nicht für Verbindungen mit diesen Diensten.
Wenn Ereignisse per Push auf den Service Bus übertragen werden, erfolgt die Konnektivität zwischen Microsoft Power Platform-Diensten und Azure intern. Darüber hinaus kann der Kunde Anfragen zum Abrufen von Informationen an den Service Bus stellen. Dies kann über Microsoft Peering verwaltet werden.
Öffentliche und private Cloud-Konnektivität des Kunden zu/von Microsoft Power Platform-Diensten
Microsoft 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
Die jeweiligen Auswirkungen müssen beim ExpressRoute-Routing berücksichtigt werden.
| Beschreibung | Datenverkehrstyp und -richtung | Peering-Typ | Zweck |
|---|---|---|---|
| Portale | HTTPS eingehend an Azure | Intern an das Rechenzentrum mit Ausnahme von statischen Inhalten, die das Content Delivery Network verwenden. (Content Delivery Network wird von ExpressRoute nicht unterstützt, daher werden statische Inhalte über das öffentliche Internet übertragen.) | Hosten Sie öffentlich zugängliche Dienste. Es kann Szenarien geben, in denen interne Mitarbeiter auf diese Ressourcen zugreifen können. Daher möchten Sie möglicherweise, dass der Datenverkehr über ExpressRoute und nicht über das öffentliche Internet geleitet wird. |
| Lernpfad | HTTPS eingehend an Azure | Verwendet Content Delivery Network, das nicht von ExpressRoute unterstützt wird. Daher werden statische Inhalte über das öffentliche Internet übertragen. | Dies wird auf einem öffentlich zugänglichen Dienst gehostet, da es keine privaten Kundendaten enthält. Aus Gründen der Vorhersagbarkeit kann es Szenarien geben, in denen Sie dies über ExpressRoute weiterleiten möchten. |
| 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 IaaS/PaaS | Intern an das Rechenzentrum | Kunden können benutzerdefinierte Anwendungen in Azure hosten und Microsoft 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 | Bietet Analysefunktionen und ermöglicht den Zugriff auf Big Data-Lösungen, die Daten von Microsoft 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 | Bietet Analysefunktionen und ermöglicht den Zugriff auf Big Data-Lösungen, die Daten von Microsoft Power Platform-Diensten und anderen Quellen sowie 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. |
In Zukunft gibt es möglicherweise weitere öffentliche Dienste, die sich intern mit dem Rechenzentrum verbinden, wenn andere Azure-Funktionen verwendet werden.