Zaplanuj wdrożenie rozwiązania ExpressRoute do użytku z Power Platform

Po podjęciu decyzji o użyciu usługi ExpressRoute dla Power Platform następnym krokiem jest zaplanowanie wdrożenia. Ten artykuł zawiera wskazówki dotyczące wymagań wstępnych i zagadnień.

Wymagania wstępne dotyczące usługi ExpressRoute

Usługa ExpressRoute wymaga określonych wymagań wstępnych. Niezaplanowanie ich może skutkować nieoczekiwanymi kosztami, zakłócić projekt i wpłynąć na działanie innych usług.

• Fizyczna łączność musi być najpierw skonfigurowana przez dostawcę usług łączności. Usługa ExpressRoute nie zapewnia samego połączenia fizycznego. Zamiast tego zapewnia łączność prywatną za pośrednictwem ustanowionego połączenia fizycznego, które musi zostać skonfigurowane przez dostawcę łączności. Istnieje kilka sposobów nawiązania fizycznej łączności z istniejącymi partnerami ExpressRoute. Dowiedz się więcej w dokumentacji usługi ExpressRoute i sprawdź listę partnerów w swoim regionie.

• Subskrypcja platformy Azure. Subskrypcja, w ramach której można dostarczać i rozliczać obwody ExpressRoute.

Zaplanuj wdrażanie

W ramach planowania należy wziąć pod uwagę następujące kwestie:

• Geografia: Dowiedz się, gdzie geograficznie należy nawiązać połączenia.

• Koszt: Dostawca usług łączności pobiera opłatę za ustanowienie połączenia prywatnego. Może to być duży koszt; będzie się on różnił w zależności od rodzaju i liczby potrzebnych połączeń.

• Czas konfiguracji: W niektórych przypadkach konieczna będzie konfiguracja fizycznego sprzętu. Uwzględnij czas przeznaczony na ten wysiłek w harmonogramie implementacji.

• Kompetencje i zasoby konfiguracyjne: Większość złożoności konfiguracji polega na ustawieniu wewnętrznego routingu w sieci. Upewnij się, że wykwalifikowani ludzie są dostępni do wykonania tej pracy.

Zaplanowanie konfiguracji routingu dla ruchu Power Platform przez ExpressRoute

Ty lub dostawca połączenia konfigurujesz routing ruchu Power Platform za pośrednictwem usługi ExpressRoute, w zależności od typu połączenia. Planując routing Power Platform ruchu, należy wziąć pod uwagę typy ruchu obsługiwanego przez połączenie oraz połączenia przychodzące i wychodzące Power Platform, które zależą od używanych usług i funkcji.

Mimo że połączenie usługi ExpressRoute odbywa się między centrami danych, połączenie sieciowe pochodzi głównie z urządzeń klienckich użytkownika. Urządzenia te są często rozproszone w sieci rozległej (WAN), takiej jak oddziały firmy. Połączenia są kierowane z urządzenia klienckiego przez sieć WAN do centrum danych, a następnie przez obwód usługi ExpressRoute.

Wymaga to starannej konfiguracji. Skonfiguruj sieć WAN tak, aby albo:

• Trasa przez podsieć sieci była skonfigurowana dla ExpressRoute lub
• Obwód awaryjny był wybierany jako preferowany w stosunku do publicznego połączenia internetowego z Power Platform.

Dlatego ważne jest, aby określić, które podsieci w sieci powinny być celami dla głównych i rezerwowych połączeń sesji Border Gateway Protocol (BGP), aby upewnić się, że prefiksy preferują tę trasę. Upewnij się, że Power Platform prefiksy preferują tę trasę. Nie trzeba specjalnie konfigurować usług na każdym końcu. Ta konfiguracja jest wykonywana przez anonsowanie podsieci IP lub prefiksów za pośrednictwem połączenia. Kiedy żądanie jest zainicjowane, algorytm routingu widzi to bezpośrednie połączenie BGP jako preferowaną trasę dla ruchu do podsieci podłączonej do obwodu ExpressRoute i kieruje ruch tam.

Konfiguracja ExpressRoute dla rozproszonych baz użytkowników

ExpressRoute został zaprojektowany w celu zapewnienia prywatnych, dedykowanych, a więc przewidywalnych połączeń z Twojego środowiska do sieci Microsoft. Kiedy masz dedykowane i bezpośrednie połączenie z firmą Microsoft przez dostawcę usług łączności, zmniejszasz potencjalną konieczność rywalizowania z innym ruchem na połączeniach udostępnianych przez sieć dostawcy usług łączności. Korzystanie z usługi ExpressRoute nie jest wymagane do osiągnięcia tej jakości połączenia, ale pomaga ją zapewnić.

W poniższym przykładzie użytkownik w oddziale firmy ma połączenie kierowane przez sieć WAN do połączenia z centrum danych klienta do ExpressRoute.

Jeśli użytkownicy są bardzo rozproszeni, na przykład w oddziałach zlokalizowanych w całym kraju/regionie, ruch sieciowy musi być efektywnie połączony z wielu oddalonych geograficznie lokalizacji. Typowym schematem jest kierowanie rzeczy przez sieć WAN do sieci lokalnej podłączonej do ExpressRoute, jak pokazano na poniższym obrazku.

Usługa ExpressRoute nie może rozwiązać słabych, nasyconych lub nieefektywnych połączeń między urządzeniem klienckim a usługą ExpressRoute. Rozważ użycie usługi ExpressRoute Direct, która umożliwia bezpośrednie łączenie się z globalną siecią Microsoft.

W przypadku problemów z połączeniami sieci WAN pomocne może być ustanowienie lokalnych połączeń internetowych z oddziałów. Pozwoli to uniknąć wolniejszego połączenia WAN i wykorzystać zasięg dostawcy usług łączności, aby uzyskać bardziej bezpośrednie połączenie z usługą w chmurze.

Możliwe jest skonfigurowanie obwodów ExpressRoute z wielu lokalizacji a nawet do poszczególnych oddziałów poprzez lokalne rozgałęzienie Internetu, jak pokazano na poniższym obrazku.

Aby rozwiązać problemy z łącznością sieci WAN, można skonfigurować połączenie usługi ExpressRoute z każdego oddziału. Jednak tworzenie połączeń w wielu lokalizacjach jest kosztowne i skomplikowane w utrzymaniu. Masz bardziej praktyczne alternatywy:

• Lokalizacje oddziałów można połączyć z centralnym centrum danych za pośrednictwem sieci WAN i skonfigurować połączenie usługi ExpressRoute z centralnego centrum danych.

• Połączenie WAN można zoptymalizować, zwiększając przepustowość lub poprawiając routing.

• Alternatywnym podejściem jest połączenie wszystkich oddziałów i centrum danych klienta za pomocą tej samej sieci IP VPN i zlecenie dostawcy usług IP VPN nawiązania połączenia z firmą Microsoft w lokalizacji ExpressRoute.

W przypadku sieci rozproszonych na dużym obszarze geograficznym korzystne może być posiadanie kilku koncentratorów podłączonych do ExpressRoute, aby zminimalizować liczbę potrzebnych połączeń ExpressRoute, a jednocześnie zapewnić każdemu użytkownikowi bardziej lokalny punkt połączenia. Upewnij się, że unikatowe publiczne adresy IP są publikowane za pośrednictwem każdego obwodu usługi ExpressRoute. Każda podsieć musi być odrębna, co wymaga tylu podsieci dostępnych publicznie, co połączenia usługi ExpressRoute.

Jest to szczególnie korzystne, gdy różne obszary operacyjne znajdują się w bardzo różnych obszarach geograficznych lub gdy łączność sieciowa między obszarami jest ograniczona i można ustanowić bardziej bezpośrednie połączenie z firmą Microsoft dla każdego z nich.

W różnych regionach mogą obowiązywać różne wymagania dotyczące prywatności. Nie każdy region musi używać usługi ExpressRoute tylko dlatego, że to robi. Może się zdarzyć, że niektóre połączenia będą kierowane bezpośrednio przez Internet, a inne przez ExpressRoute, jak pokazano na poniższym obrazku.

Usługa ExpressRoute (standardowa) oferuje łączność w określonym regionie geograficznym. Usługa ExpressRoute Premium jest wymagana do oferowania dostępu do wielu obszarów geograficznych z jednego punktu połączenia usługi ExpressRoute. Załóżmy, że masz biura w USA i w Europie, a wszystkie korzystają z jednego Power Platform środowiska. Jeśli platforma Power Platform klienta jest wdrożona w Stanach Zjednoczonych, jego układ ExpressRoute w Europie musi być układem Premium SKU. Jeśli dzierżawa Power Platform klienta znajduje się w Europie, jego amerykański obwód musiałby być Premium.

Unikanie asymetrycznego routingu

Jednym z wyzwań, na które należy zwrócić uwagę, jest routing asymetryczny. W przypadku routingu asymetrycznego konfiguracja routingu sieci wysyła ruch do Microsoft centrum danych bezpośrednio przez Internet, ale ruch powrotny jest kierowany przez obwód usługi ExpressRoute. Często może to spowodować odrzucenie ruchu przez zaporę, ponieważ otrzymuje ona pakiety odpowiedzi bez uprzedniego wysłania pakietów żądania.

Może się to zdarzyć, jeśli sieć lokalna klienta stwierdzi, że najbardziej efektywne kierowanie do usług w chmurze firmy Microsoft odbywa się przez publiczny Internet, a nie przez sieć WAN do prywatnego obwodu ExpressRoute. Jeśli jednak adres IP klienta jest publicznym adresem IP lub został przetłumaczony przez mapowanie NAT na publiczny adres IP, który jest reklamowany przez ExpressRoute, najbardziej efektywna trasa powrotna do tego adresu IP będzie prawdopodobnie przebiegać przez sesję BGP przez ExpressRoute. Aby tego uniknąć, można użyć różnych adresów IP NAT na granicy Internetu i granicy ExpressRoute. Przy odrębnym adresie źródłowym ruch powrotny będzie jednoznacznie wracał do tej samej krawędzi.

Routing asymetryczny może również wystąpić, gdy wiele obwodów usługi ExpressRoute jest skonfigurowanych dla tego samego klienta, z routingiem ruchu wychodzącego przez jeden obwód i routingiem ruchu powrotnego przez inny. Testy zapory mogą blokować ruch na ścieżce zwrotnej. Aby uniknąć asymetrycznego routingu przez różne obwody ExpressRoute dla ścieżki wychodzącej i przychodzącej, ważne jest, aby zapewnić, że unikalne publiczne adresy IP są publikowane w każdym obwodzie.

Zewnętrzna łączność z/do Power Platform

Gdy łączysz się Power Platform ze swoimi lokalizacjami, połączenie może obejmować dwa typy komunikacji równorzędnej: Microsoft i prywatne. Ten sam obwód usługi ExpressRoute obsługuje oba typy komunikacji równorzędnej, jak pokazano na poniższej ilustracji.

Istnieją różne typy połączeń między usługami Power Platform a siecią zewnętrzną. Na przykład łączność Exchange Web Services z wykorzystaniem synchronizacji po stronie serwera używa ExpressRoute do przekazywania ruchu sieciowego z sieci Microsoft do sieci klienta. W przypadku klienta HTTPS połączenie ExpressRoute jest używane do uzyskania dostępu z sieci klienta do sieci Microsoft. Łączność z usługami sieci Web używa ExpressRoute zarówno dla ruchu przychodzącego, jak i wychodzącego do sieci Microsoft.

Ruch wychodzący (ruch z usług Power Platform)

Bezpośrednio z usług Power Platform może wystąpić kilka rodzajów ruchu wychodzącego do usług klienta. Obsługa klienta musi być publicznie adresowalna z publicznym adresem IP, który Power Platform usługi mogą rozpoznawać za pośrednictwem publicznego systemu DNS. Ten adres IP musi być również rozgłaszany firmie Microsoft za pośrednictwem usługi ExpressRoute, aby wewnętrzne usługi routingu sieciowego w ramach usługi Power Platform wiedziały, że należy kierować je przez to połączenie ExpressRoute.

W usługach Power Platform nie można określić, która instancja usługi lub organizacja klienta może kierować żądania do poszczególnych adresów IP. Dlatego ważne jest, aby traktować żądania przychodzące do sieci firmowej tak, jakby pochodziły z Internetu i w ten sposób je zabezpieczać.

W poniższej tabeli opisano ruch wychodzący z usług Power Platform.

Opis	Rodzaj i kierunek ruchu	Typ komunikacji równorzędnej	Przeznaczenie
Usługi sieci Web	HTTPS wychodzący z usług Power Platform	Komunikacja równorzędna Microsoft Publikuj usługi sieciowe na publicznych adresach IP, które znajdują się w podsieciach skonfigurowanych przez ExpressRoute.	Niestandardowe wtyczki i aktywności przepływu pracy mogą wykonywać żądania usług sieciowych do usług zewnętrznych
Integracja z Exchange: tryb hybrydowy	HTTPS wychodzący z usług Power Platform	Komunikacja równorzędna Microsoft Publikuj usługi sieciowe na publicznych adresach IP, które znajdują się w podsieciach skonfigurowanych przez ExpressRoute.	Żądania Exchange Web Services z synchronizacji po stronie serwera dla wdrożeń hybrydowych (usługi Power Platform, Exchange lokalnie)
Łączniki	HTTPS przychodzący z usług Power Platform	Komunikacja równorzędna Microsoft	Żądania z usług Power Platform za pośrednictwem usługi Azure API Management przez łączniki wykorzystujące bramę danych w siedzibie firmy
Azure Relay	HTTPS wychodzący z usług Power Platform	Komunikacja równorzędna Microsoft Publikuj usługi sieciowe na publicznych adresach IP, które znajdują się w podsieciach skonfigurowanych przez ExpressRoute.	Bezpośrednia łączność pomiędzy przepływami chmury Power Automate i przepływami pulpitu

Ruch przychodzący (ruch do usług Power Platform)

Z sieci klienta możliwy jest następujący ruch przychodzący do usług Power Platform.

Podpis	Rodzaj i kierunek ruchu	Typ komunikacji równorzędnej	Przeznaczenie
Łączność z klientem	HTTPS przychodzący do usług Power Platform	Komunikacja równorzędna Microsoft Bezpośrednie połączenie internetowe dla zawartości statycznej obsługiwanej przez sieć dostarczania zawartości Azure	Zapytania klienta dotyczące interfejsu użytkownika usług Power Platform
Usługi sieci Web	HTTPS przychodzący do usług Power Platform	Komunikacja równorzędna Microsoft	Żądania do Power Platform usług za pośrednictwem interfejsów API usług internetowych (SOAP, internetowy interfejs API) ze standardowej lub niestandardowej aplikacji klienckiej
Łączniki	HTTPS przychodzący do usług Power Platform	Komunikacja równorzędna Microsoft	Odpowiedzi z powrotem do usług Power Platform poprzez API Management za pośrednictwem łączników z wykorzystaniem lokalnej bramy danych

Wewnętrzna łączność z chmurą w ramach usług Power Platform

Następujące tabela opisuje jak usługi Power Platform korzystają z kilku innych usług online Microsoft hostowanych zarówno na platformie Azure, jak i Microsoft 365.

Podpis	Rodzaj i kierunek ruchu	Purpose
Integracja z Exchange	HTTPS wychodzący do Microsoft 365	Żądania usługi Exchange sieci Web do Exchange Online z Server-Side Synchronization
Integracja aplikacji SharePoint	HTTPS wychodzący do Microsoft 365	Żądania SharePoint sieci Web do SharePoint Online z usług Power Platform
Usługa Service Bus	HTTPS wychodzący do Azure Service Bus	Zdarzenia Push do Azure Service Bus, zarówno jako standardowa rejestracja zdarzeń lub z niestandardowych wtyczek i działań przepływu pracy
Synchronizacja danych	HTTPS przychodzący z Azure	Żądania przychodzące dotyczące śledzenia zmian w zakresie synchronizacji usług danych, w tym wyszukiwania/offline/Customer Insights
Uwierzytelnianie	HTTPS wychodzący do Microsoft Entra	Większość uwierzytelniania odbywa się poprzez pasywne przekierowania i tokeny roszczeń, ale niektóre dane są synchronizowane bezpośrednio z Microsoft Entra
Przepływy danych	HTTPS wychodzący do Azure Data Lake Storage	Zapewnia możliwości analityczne i umożliwia dostęp do rozwiązań typu big data zawierających dane zarówno z usług Power Platform, jak i innych źródeł, a także wgląd wynikający z analizy.
Łączniki	Ruch wychodzący HTTPS do usług platformy jako usługi (PaaS) Azure	Połączenia z różnymi usługami Azure PaaS
Przepływy na komputerach	Protokół HTTPS wychodzący do Azure Relay	Bezpośrednia łączność pomiędzy przepływami w chmurze Power Automate a przepływami na pulpicie utworzonymi w Power Automate for Desktop

Rzeczywista łączność między tymi usługami, hostowanymi w firmie Microsoft lub w subskrypcjach Azure klienta, jest obsługiwana przez firmę Microsoft. ExpressRoute nie ma zastosowania w połączeniach z tymi usługami.

Tam, gdzie zdarzenia są przesyłane do szyny usług, łączność między usługami Power Platform i Azure jest obsługiwana wewnętrznie. Oddzielnie klient może kierować zapytania do Service Bus w celu pobrania informacji, co może być zarządzane poprzez komunikację równorzędną Microsoft.

Łączność z chmurą publiczną i prywatną klienta do/z usług Power Platform

Usługi Power Platform umożliwiają również bezpośrednią integrację z publicznymi lub prywatnymi zasobami Azure:

• Ze źródeł zewnętrznych, za pomocą interfejsów API usług sieciowych Microsoft Dataverse.
• Do źródeł zewnętrznych, poprzez wykorzystanie zapytań usługi sieci Web.
• Do źródeł zewnętrznych, za pomocą łączników.

W poniższej tabeli opisano typy ruchu, który może być kierowany za pośrednictwem usługi ExpressRoute do i z Power Platform usług.

Podpis	Rodzaj i kierunek ruchu	Typ komunikacji równorzędnej	Purpose
Portale	HTTPS przychodzący do Azure	Wewnętrznie do centrum danych, z wyjątkiem treści statycznych, które korzystają z sieci dostarczania zawartości (CDN). Usługa ExpressRoute nie obsługuje sieci CDN, więc zawartość statyczna jest przesyłana przez publiczny Internet.	Hosting usług skierowanych publicznie. Mogą istnieć scenariusze, w których pracownicy wewnętrzni mogą uzyskać dostęp do tych zasobów, więc może być konieczne, aby ruch odbywał się przez ExpressRoute, a nie przez publiczny Internet.
Ścieżka szkoleniowa	HTTPS przychodzący do Azure	Grupa używa CDN. Usługa ExpressRoute nie obsługuje sieci CDN, więc zawartość jest przesyłana przez publiczny Internet.	Hosting jest w publicznej usłudze, ponieważ nie zawiera prywatnych danych klientów. W niektórych scenariuszach, ze względu na przewidywanie, może się zdarzyć, że będziesz chciał to poprowadzić przez ExpressRoute.
Usługa Service Bus	HTTPS przychodzący do Azure Service Bus	Wewnętrzne do centrum danych	Zdarzenia Pull z Azure Service Bus, które zostały tam umieszczone zarówno jako standardowa rejestracja zdarzeń lub z niestandardowych wtyczek lub działań przepływu pracy
Żądania usługi sieci Web	Przychodzące z infrastruktury Azure jako usługa (IaaS) lub PaaS	Wewnętrzne do centrum danych	Klienci mogą hostować niestandardowe aplikacje w Azure i korzystać z usług sieciowych Power Platform.
Żądania usługi sieci Web	Wychodzące do Azure IaaS/PaaS	Wewnętrzne do centrum danych	Klienci mogą implementować niestandardowe wtyczki i działania przepływu pracy, które wykorzystują usługi hostowane na platformie Azure.
Przepływy danych	Połączenia danych do Azure Data Lake Storage	Wewnętrzne do centrum danych	Zapewnia możliwości analityczne i umożliwia dostęp do rozwiązań typu big data zawierających dane zarówno z usług Power Platform, jak i innych źródeł, a także wgląd wynikający z analizy.
Azure Data Lake	Połączenia danych do Azure Data Lake Storage	Wewnętrzne do centrum danych	Zapewniają możliwości analityczne i umożliwiają dostęp do rozwiązań typu big data zawierających dane zarówno z usług Power Platform, jak i innych źródeł, a także wgląd wynikający z analizy.
Azure SQL	Połączenia danych z usługami Azure SQL	Wewnętrzne do centrum danych	Dzięki możliwościom takim jak Export to Data Warehouse, wzrośnie wykorzystanie instancji Azure SQL do przechowywania replik danych Microsoft Dataverse w celach raportowania lub replikacji. Dobrze jest zabezpieczyć połączenia do tych zasobów przez ExpressRoute.

W przyszłości mogą pojawić się inne usługi publiczne, które będą się łączyć wewnętrznie z centrum danych w miarę wykorzystywania innych możliwości Azure.

Następny krok

Konfigurowanie usługi ExpressRoute dla platformy Power Platform