Implementowanie usługi ExpressRoute dla platformy Microsoft 365
Ten artykuł dotyczy Microsoft 365 Enterprise.
Usługa ExpressRoute dla platformy Microsoft 365 zapewnia alternatywną ścieżkę routingu do wielu usług platformy Microsoft 365 dostępnych z Internetu. Architektura usługi ExpressRoute dla platformy Microsoft 365 jest oparta na anonsowaniu publicznych prefiksów adresów IP usług Microsoft 365, które są już dostępne przez Internet w aprowizowanych obwodach usługi ExpressRoute w celu późniejszej redystrybucji tych prefiksów IP do sieci. Dzięki usłudze ExpressRoute można skutecznie włączyć kilka różnych ścieżek routingu, przez Internet i za pośrednictwem usługi ExpressRoute, dla wielu usług Platformy Microsoft 365. Ten stan routingu w sieci może znacząco zmienić sposób projektowania topologii sieci wewnętrznej.
Uwaga
Nie zalecamy usługi ExpressRoute dla platformy Microsoft 365, ponieważ w większości przypadków nie zapewnia ona najlepszego modelu łączności dla usługi. W związku z tym autoryzacja firmy Microsoft jest wymagana do korzystania z tego modelu łączności. Sprawdzamy każde żądanie klienta i autoryzujemy usługę ExpressRoute dla platformy Microsoft 365 tylko w rzadkich scenariuszach, w których jest to konieczne. Przeczytaj przewodnik usługi ExpressRoute dla platformy Microsoft 365 , aby uzyskać więcej informacji i po kompleksowym przeglądzie dokumentu z zespołami ds. produktywności, sieci i zabezpieczeń, skontaktuj się z zespołem ds. konta Microsoft, aby w razie potrzeby przesłać wyjątek. Nieautoryzowane subskrypcje próbujące utworzyć filtry tras dla platformy Microsoft 365 otrzymają komunikat o błędzie.
Musisz starannie zaplanować implementację usługi ExpressRoute dla platformy Microsoft 365, aby uwzględnić złożoność sieci, ponieważ routing jest dostępny zarówno za pośrednictwem dedykowanego obwodu z trasami wprowadzonymi do sieci podstawowej, jak i Internetu. Jeśli Ty i Twój zespół nie wykonacie szczegółowego planowania i testowania w tym przewodniku, istnieje duże ryzyko sporadycznego lub całkowitej utraty łączności z usługami Microsoft 365 po włączeniu obwodu usługi ExpressRoute.
Aby pomyślnie przeprowadzić implementację, musisz przeanalizować wymagania dotyczące infrastruktury, przejść przez szczegółową ocenę i projektowanie sieci, dokładnie zaplanować wdrożenie w sposób etapowy i kontrolowany oraz utworzyć szczegółowy plan weryfikacji i testowania. W przypadku dużego, rozproszonego środowiska nie jest niczym niezwykłym, że implementacje obejmują kilka miesięcy. Ten przewodnik ma na celu ułatwienie planowania z wyprzedzeniem.
Planowanie dużych pomyślnych wdrożeń może potrwać sześć miesięcy i często obejmuje członków zespołu z wielu obszarów w organizacji, w tym administratorów sieci, zapory i serwera proxy, administratorów platformy Microsoft 365, zabezpieczeń, obsługi użytkowników końcowych, zarządzania projektami i sponsorowania kadry kierowniczej. Inwestycja w proces planowania zmniejszy prawdopodobieństwo wystąpienia błędów wdrażania powodujących przestój lub złożone i kosztowne rozwiązywanie problemów.
Oczekujemy, że następujące wymagania wstępne zostaną spełnione przed rozpoczęciem tego przewodnika implementacji.
Przeprowadzono ocenę sieci, aby ustalić, czy usługa ExpressRoute jest zalecana i zatwierdzona.
Wybrano dostawcę usług sieciowych usługi ExpressRoute. Znajdź szczegółowe informacje o partnerach usługi ExpressRoute i lokalizacjach komunikacji równorzędnej.
Zapoznaliśmy się już z dokumentacją usługi ExpressRoute i twoja sieć wewnętrzna może spełniać wymagania wstępne usługi ExpressRoute.
Twój zespół zapoznał się ze wszystkimi publicznymi wskazówkami i dokumentacją w witrynie https://aka.ms/expressrouteoffice365, https://aka.ms/erti obejrzał serię szkoleń usługi Azure ExpressRoute dla platformy Microsoft 365 w kanale Channel 9, aby zrozumieć krytyczne szczegóły techniczne, w tym:
Zależności internetowe usług SaaS.
Jak unikać tras asymetrycznych i obsługiwać złożony routing.
Jak uwzględnić zabezpieczenia obwodowe, dostępność i mechanizmy kontroli na poziomie aplikacji.
Rozpocznij od zebrania wymagań
Zacznij od określenia, które funkcje i usługi mają zostać wdrożone w organizacji. Musisz określić, które funkcje różnych usług Platformy Microsoft 365 będą używane i które lokalizacje w sieci będą hostować osoby korzystające z tych funkcji. W przypadku wykazu scenariuszy należy dodać atrybuty sieci, których wymaga każdy z tych scenariuszy; takie jak przychodzące i wychodzące przepływy ruchu sieciowego oraz czy punkty końcowe platformy Microsoft 365 są dostępne za pośrednictwem usługi ExpressRoute, czy nie.
Aby zebrać wymagania organizacji:
Katalog ruchu przychodzącego i wychodzącego sieciowego dla usług platformy Microsoft 365 używanych przez organizację. Zapoznaj się ze stroną adresów URL i zakresów adresów IP platformy Microsoft 365, aby uzyskać opis przepływów wymaganych przez różne scenariusze platformy Microsoft 365.
Zbierz dokumentację istniejącej topologii sieci zawierającej szczegóły wewnętrznej sieci szkieletowej sieci WAN i topologii, łączności lokacji satelitarnych, łączności użytkownika z ostatniej mili, routingu do punktów ruchu wychodzącego obwodu sieciowego i usług proxy.
Zidentyfikuj punkty końcowe usługi dla ruchu przychodzącego na diagramach sieciowych, z którymi będzie się łączyć platforma Microsoft 365 i inne usługi firmy Microsoft, pokazując zarówno internet, jak i proponowane ścieżki połączenia usługi ExpressRoute.
Zidentyfikuj wszystkie lokalizacje użytkowników geograficznych i łączność sieci WAN między lokalizacjami wraz z lokalizacjami, które obecnie mają ruch wychodzący do Internetu i które lokalizacje są proponowane, aby miały ruch wychodzący do lokalizacji komunikacji równorzędnej usługi ExpressRoute.
Zidentyfikuj wszystkie urządzenia brzegowe, takie jak serwery proxy, zapory itd., i skataloguj ich relacje z przepływami przechodzącymi przez Internet i usługę ExpressRoute.
Określ, czy użytkownicy końcowi będą uzyskiwać dostęp do usług Platformy Microsoft 365 za pośrednictwem routingu bezpośredniego lub pośredniego serwera proxy aplikacji dla przepływów Internetu i usługi ExpressRoute.
Dodaj lokalizację dzierżawy i lokalizacje meet-me do diagramu sieciowego.
Oszacuj oczekiwaną i obserwowaną wydajność sieci oraz charakterystykę opóźnienia z głównych lokalizacji użytkowników na platformę Microsoft 365. Należy pamiętać, że platforma Microsoft 365 to globalny i rozproszony zestaw usług, a użytkownicy będą łączyć się z lokalizacjami, które mogą różnić się od lokalizacji dzierżawy. Z tego powodu zaleca się mierzenie i optymalizowanie pod kątem opóźnienia między użytkownikiem a najbliższą krawędzią globalnej sieci firmy Microsoft za pośrednictwem usługi ExpressRoute i połączeń internetowych. Możesz użyć wyników z oceny sieci, aby ułatwić wykonanie tego zadania.
Wyświetl listę wymagań dotyczących zabezpieczeń sieci firmowych i wysokiej dostępności, które należy spełnić w przypadku nowego połączenia usługi ExpressRoute. Na przykład w jaki sposób użytkownicy nadal uzyskują dostęp do platformy Microsoft 365 w przypadku wystąpienia awarii ruchu wychodzącego z Internetu lub obwodu usługi ExpressRoute.
Dokument, które przychodzące i wychodzące przepływy sieciowe platformy Microsoft 365 będą używać ścieżki internetowej i która będzie używać usługi ExpressRoute. Specyfika lokalizacji geograficznych użytkowników i szczegóły topologii sieci lokalnej mogą wymagać, aby plan różnił się od jednej lokalizacji użytkownika do innej.
Katalog ruchu wychodzącego i przychodzącego sieci
Aby zminimalizować routing i inne złożoność sieci, zalecamy używanie usługi ExpressRoute tylko dla platformy Microsoft 365 dla przepływów ruchu sieciowego wymaganych do przejścia przez dedykowane połączenie ze względu na wymagania prawne lub w wyniku oceny sieci. Ponadto zalecamy przygotowanie zakresu routingu usługi ExpressRoute i podejścia wychodzącego i przychodzącego ruchu sieciowego jako różnych etapów projektu implementacji. Wdrożenie usługi ExpressRoute dla platformy Microsoft 365 tylko dla przepływów ruchu wychodzącego zainicjowanego przez użytkownika i pozostawienie przepływów ruchu sieciowego ruchu przychodzącego przez Internet może pomóc w kontrolowaniu wzrostu złożoności topologicznej i ryzyka związanego z wprowadzeniem dodatkowych możliwości routingu asymetrycznego.
Katalog ruchu sieciowego powinien zawierać listę wszystkich połączeń sieciowych dla ruchu przychodzącego i wychodzącego, które będą nawiązywane między siecią lokalną a firmą Microsoft.
Wychodzące przepływy ruchu sieciowego to dowolne scenariusze, w których połączenie jest inicjowane ze środowiska lokalnego, na przykład z wewnętrznych klientów lub serwerów, z miejscem docelowym usług firmy Microsoft. Te połączenia mogą być bezpośrednie dla platformy Microsoft 365 lub pośrednie, na przykład gdy połączenie przechodzi przez serwery proxy, zapory lub inne urządzenia sieciowe w ścieżce do platformy Microsoft 365.
Przychodzące przepływy ruchu sieciowego to dowolne scenariusze, w których połączenie jest inicjowane z chmury firmy Microsoft do hosta lokalnego. Te połączenia zwykle muszą przechodzić przez zaporę i inną infrastrukturę zabezpieczeń wymaganą przez zasady zabezpieczeń klienta dla przepływów pochodzących z zewnątrz.
Przeczytaj sekcję Zapewnianie symetrii trasy , aby określić, które usługi będą wysyłać ruch przychodzący, i wyszukaj kolumnę oznaczoną jako ExpressRoute dla platformy Microsoft 365 w artykule dotyczącym punktów końcowych platformy Microsoft 365 , aby określić pozostałe informacje o łączności.
Dla każdej usługi, która wymaga połączenia wychodzącego, należy opisać planowaną łączność dla usługi, w tym routing sieciowy, konfigurację serwera proxy, inspekcję pakietów i wymagania dotyczące przepustowości.
Dla każdej usługi, która wymaga połączenia przychodzącego, potrzebne będą dodatkowe informacje. Serwery w chmurze firmy Microsoft będą nawiązywać połączenia z siecią lokalną. Aby upewnić się, że połączenia są prawidłowo nawiązywane, należy opisać wszystkie aspekty tej łączności, w tym; publiczne wpisy DNS dla usług, które zaakceptują te połączenia przychodzące, adresy IP IPv4 sformatowane przez cidr, który jest zaangażowany w sprzęt usługodawcy sieciowego oraz sposób obsługi przychodzącego translatora adresów sieciowych lub źródłowego translatora adresów sieciowych dla tych połączeń.
Połączenia przychodzące powinny być sprawdzane niezależnie od tego, czy nawiązują połączenie za pośrednictwem Internetu, czy usługi ExpressRoute, aby upewnić się, że routing asymetryczny nie został wprowadzony. W niektórych przypadkach lokalne punkty końcowe, do których usługi Platformy Microsoft 365 inicjują połączenia przychodzące, mogą również wymagać dostępu do innych usług firmy Microsoft i innych firm. Najważniejsze jest, aby włączenie routingu usługi ExpressRoute do tych usług na potrzeby platformy Microsoft 365 nie przerywało innych scenariuszy. W wielu przypadkach klienci mogą wymagać zaimplementowania określonych zmian w sieci wewnętrznej, takich jak źródłowy translator adresów sieciowych, aby zapewnić, że przepływy przychodzące od firmy Microsoft pozostaną symetryczne po włączeniu usługi ExpressRoute.
Oto przykład wymaganego poziomu szczegółów. W takim przypadku usługa Exchange Hybrid będzie kierowana do systemu lokalnego za pośrednictwem usługi ExpressRoute.
| Właściwość połączenia | Value |
|---|---|
| Kierunek ruchu sieci |
Przychodzących |
| Usługa |
Wdrożenie hybrydowe programu Exchange |
| Publiczny punkt końcowy platformy Microsoft 365 (źródło) |
Exchange Online (adresy IP) |
| Publiczny lokalny punkt końcowy (miejsce docelowe) |
5.5.5.5 |
| Publiczny wpis DNS (Internet) |
Autodiscover.contoso.com |
| Czy ten lokalny punkt końcowy będzie używany dla innych (innych niż Microsoft 365) usług firmy Microsoft |
Nie |
| Czy ten lokalny punkt końcowy będzie używany przez użytkowników/systemy w Internecie |
Tak |
| Systemy wewnętrzne publikowane za pośrednictwem publicznych punktów końcowych |
Exchange Server roli dostępu klienta (lokalnie) 192.168.101, 192.168.102, 192.168.103 |
| Anons ip publicznego punktu końcowego |
Do Internetu: 5.5.0.0/16 do usługi ExpressRoute: 5.5.5.0/24 |
| Zabezpieczenia/kontrolki obwodowe |
Ścieżka internetowa: DeviceID_002 ścieżka usługi ExpressRoute: DeviceID_003 |
| Wysoka dostępność |
Aktywne/aktywne w 2 obwodach geograficznie nadmiarowych / ExpressRoute — Chicago i Dallas |
| Kontrolka symetrii ścieżki |
Metoda: Źródłowa ścieżka internetowa NAT: źródłowe połączenia przychodzące NAT do ścieżki usługi ExpressRoute 192.168.5.5: Źródłowe połączenia NAT z 192.168.1.0 (Chicago) i 192.168.2.0 (Dallas) |
Oto przykład usługi, która jest tylko wychodząca:
| Właściwość połączenia | Wartość |
|---|---|
| Kierunek ruchu sieci |
Wychodzące |
| Usługa |
SharePoint |
| Lokalny punkt końcowy (źródło) |
Stacja robocza użytkownika |
| Publiczny punkt końcowy platformy Microsoft 365 (miejsce docelowe) |
SharePoint (adresy IP) |
| Publiczny wpis DNS (Internet) |
*.sharepoint.com (i więcej nazw FQDN) |
| Odwołania usługi CDN |
cdn.sharepointonline.com (i więcej nazw FQDN) — adresy IP obsługiwane przez dostawców sieci CDN) |
| Anonsowanie adresów IP i translator adresów sieciowych w użyciu |
Ścieżka internetowa/źródłowy translator adresów sieciowych: 1.1.1.0/24 Ścieżka usługi ExpressRoute/Źródłowy translator adresów sieciowych: 1.1.2.0/24 (Chicago) i 1.1.3.0/24 (Dallas) |
| Metoda łączności |
Internet: za pośrednictwem serwera proxy warstwy 7 (plik pac) ExpressRoute: routing bezpośredni (bez serwera proxy) |
| Zabezpieczenia/kontrolki obwodowe |
Ścieżka internetowa: DeviceID_002 Ścieżka usługi ExpressRoute: DeviceID_003 |
| Wysoka dostępność |
Ścieżka internetowa: Nadmiarowy ruch wychodzący z Internetu Ścieżka usługi ExpressRoute: Routing aktywnych/aktywnych "gorących ziemniaków" na 2 geograficznie nadmiarowych obwodach usługi ExpressRoute — Chicago i Dallas |
| Kontrolka symetrii ścieżki |
Metoda: Źródłowy translator adresów sieciowych dla wszystkich połączeń |
Projekt topologii sieci z łącznością regionalną
Po zapoznaniu się z usługami i skojarzonymi z nimi przepływami ruchu sieciowego możesz utworzyć diagram sieciowy, który zawiera te nowe wymagania dotyczące łączności i ilustruje zmiany wprowadzone w celu używania usługi ExpressRoute dla platformy Microsoft 365. Diagram powinien zawierać następujące elementy:
Wszystkie lokalizacje użytkowników, z których będzie uzyskiwany dostęp platforma Microsoft 365 i inne usługi.
Wszystkie punkty ruchu wychodzącego z Internetu i usługi ExpressRoute.
Wszystkie urządzenia wychodzące i przychodzące, które zarządzają łącznością w sieci i poza nią, w tym routery, zapory, serwery proxy aplikacji oraz wykrywanie/zapobieganie włamaniom.
Wewnętrzne miejsca docelowe dla całego ruchu przychodzącego, takie jak wewnętrzne serwery usług AD FS, które akceptują połączenia z serwerów proxy aplikacji internetowych usług AD FS.
Wykaz wszystkich podsieci IP, które będą anonsowane
Zidentyfikuj każdą lokalizację, z której użytkownicy będą uzyskiwać dostęp do usługi Microsoft 365, i wyświetl listę lokalizacji spotkania, które będą używane w usłudze ExpressRoute.
Lokalizacje i fragmenty topologii sieci wewnętrznej, w których prefiksy adresów IP firmy Microsoft poznane w usłudze ExpressRoute będą akceptowane, filtrowane i propagowane.
Topologia sieci powinna przedstawiać lokalizację geograficzną każdego segmentu sieci oraz sposób nawiązywania połączenia z siecią firmy Microsoft za pośrednictwem usługi ExpressRoute i/lub Internetu.
Na poniższym diagramie przedstawiono każdą lokalizację, w której użytkownicy będą korzystać z platformy Microsoft 365 wraz z anonsami routingu przychodzącego i wychodzącego do platformy Microsoft 365.
W przypadku ruchu wychodzącego użytkownicy uzyskują dostęp do platformy Microsoft 365 na jeden z trzech sposobów:
Dzięki lokalizacji meet-me w Ameryka Północna dla ludzi w Kalifornii.
Dzięki lokalizacji meet-me w Hong Kongu Specjalnego Regionu Administracyjnego dla ludzi w Hong Kong SAR.
Za pośrednictwem Internetu w Bangladeszu, gdzie jest mniej osób i nie aprowizowano obwodu usługi ExpressRoute.
Podobnie przychodzący ruch sieciowy z platformy Microsoft 365 jest zwracany na jeden z trzech sposobów:
Dzięki lokalizacji meet-me w Ameryka Północna dla ludzi w Kalifornii.
Dzięki lokalizacji meet-me w Hong Kongu Specjalnego Regionu Administracyjnego dla ludzi w Hong Kong SAR.
Za pośrednictwem Internetu w Bangladeszu, gdzie jest mniej osób i nie aprowizowano obwodu usługi ExpressRoute.
Określanie odpowiedniej lokalizacji spotkania
Wybór lokalizacji meet-me, które są lokalizacją fizyczną, w której obwód usługi ExpressRoute łączy sieć z siecią firmy Microsoft, ma wpływ na lokalizacje, z których użytkownicy będą uzyskiwać dostęp do usługi Microsoft 365. Jako oferta SaaS platforma Microsoft 365 nie działa w ramach modelu regionalnego IaaS ani PaaS w taki sam sposób jak platforma Azure. Zamiast tego platforma Microsoft 365 to rozproszony zestaw usług współpracy, w którym użytkownicy mogą potrzebować połączenia z punktami końcowymi w wielu centrach danych i regionach, które niekoniecznie znajdują się w tej samej lokalizacji lub regionie, w którym hostowana jest dzierżawa użytkownika.
Oznacza to, że najważniejszą kwestią, którą należy wziąć pod uwagę podczas wybierania lokalizacji meet-me dla usługi ExpressRoute dla platformy Microsoft 365, jest miejsce, z którego będą nawiązywać połączenia osoby w organizacji. Ogólne zalecenie dotyczące optymalnej łączności z platformą Microsoft 365 polega na zaimplementowaniu routingu, tak aby żądania użytkowników do usług Platformy Microsoft 365 były przekazywane do sieci firmy Microsoft za pośrednictwem najkrótszej ścieżki sieciowej, co jest często nazywane routingiem "gorących ziemniaków". Jeśli na przykład większość użytkowników platformy Microsoft 365 znajduje się w jednej lub dwóch lokalizacjach, wybranie lokalizacji meet-me znajdujących się w najbliższej odległości od lokalizacji tych użytkowników spowoduje utworzenie optymalnego projektu. Jeśli twoja firma ma duże populacje użytkowników w wielu różnych regionach, warto rozważyć posiadanie wielu obwodów usługi ExpressRoute i lokalizacji typu meet-me. W przypadku niektórych lokalizacji użytkowników najkrótsza/najbardziej optymalna ścieżka do sieci firmy Microsoft i platformy Microsoft 365 może nie dotyczyć wewnętrznych punktów połączenia sieci WAN i usługi ExpressRoute, ale za pośrednictwem Internetu.
Często istnieje wiele lokalizacji meet-me, które można wybrać w regionie ze względną bliskością użytkowników. Wypełnij poniższą tabelę, aby kierować swoimi decyzjami.
Planowane lokalizacje usługi ExpressRoute w Kalifornii i Nowym Jorku
| Lokalizacja |
Liczba osób |
Oczekiwane opóźnienie dla sieci firmy Microsoft za pośrednictwem ruchu wychodzącego z Internetu |
Oczekiwane opóźnienie w sieci firmy Microsoft za pośrednictwem usługi ExpressRoute |
|---|---|---|---|
| Los Angeles |
10,000 |
~15ms |
~10ms (przez Dolinę Krzemową) |
| Waszyngtonie |
15,000 |
~20ms |
~10ms (przez Nowy Jork) |
| Dallas |
5,000 |
~15ms |
~40ms (przez Nowy Jork) |
Po opracowaniu architektury sieci globalnej przedstawiającej region platformy Microsoft 365, lokalizacje dostawcy usług sieciowych usługi ExpressRoute oraz liczbę osób według lokalizacji można określić, czy można dokonać optymalizacji. Może również pokazać globalne połączenia sieciowe spinki do włosów, gdzie ruch kieruje się do odległej lokalizacji w celu uzyskania lokalizacji meet-me. Jeśli odnaleziono spinkę do włosów w sieci globalnej, należy ją skorygować przed kontynuowaniem. Znajdź inną lokalizację meet-me lub użyj selektywnych punktów wyjścia internet breakout, aby uniknąć spinki do włosów.
Pierwszy diagram przedstawia przykład klienta z dwoma lokalizacjami fizycznymi w Ameryka Północna. Możesz wyświetlić informacje o lokalizacjach biura, lokalizacjach dzierżawy platformy Microsoft 365 i kilku opcjach dla lokalizacji usługi ExpressRoute meet-me. W tym przykładzie klient wybrał lokalizację meet-me na podstawie dwóch zasad w kolejności:
Najbliższa bliskość osób w organizacji.
Najbliżej centrum danych firmy Microsoft, w którym jest hostowana platforma Microsoft 365.
Rozszerzając tę koncepcję nieco dalej, drugi diagram przedstawia przykładowego klienta z wieloma państwami, który ma do czynienia z podobnymi informacjami i podejmowaniem decyzji. Ten klient ma małe biuro w Bangladeszu, a tylko niewielki zespół 10 osób koncentruje się na zwiększaniu swojego śladu w regionie. Jest lokalizacja meet-me w Chennai i centrum danych firmy Microsoft z platformą Microsoft 365 hostowaną w Chennai, więc lokalizacja meet-me miałaby sens; jednak dla 10 osób koszt dodatkowego obwodu jest uciążliwy. Patrząc na sieć, musisz określić, czy opóźnienie związane z wysyłaniem ruchu sieciowego przez sieć jest bardziej efektywne niż wydawanie kapitału w celu uzyskania innego obwodu usługi ExpressRoute.
Alternatywnie, 10 osób w Bangladeszu może doświadczyć lepszej wydajności z ich ruchu sieciowego wysyłane przez Internet do sieci Firmy Microsoft niż oni routingu w sieci wewnętrznej, jak pokazaliśmy na diagramach wprowadzających i odtworzone poniżej.
Twórca plan implementacji usługi ExpressRoute dla platformy Microsoft 365
Plan implementacji powinien obejmować zarówno szczegóły techniczne konfigurowania usługi ExpressRoute, jak i szczegóły konfigurowania całej innej infrastruktury w sieci, takie jak poniżej.
Planowanie usług podzielonych między usługę ExpressRoute i Internet.
Zaplanuj przepustowość, zabezpieczenia, wysoką dostępność i tryb failover.
Projektowanie routingu przychodzącego i wychodzącego, w tym odpowiednich optymalizacji ścieżki routingu dla różnych lokalizacji
Zdecyduj, jak daleko trasy usługi ExpressRoute będą anonsowane w sieci i jaki jest mechanizm wybierania przez klientów ścieżki do Internetu lub usługi ExpressRoute; na przykład routing bezpośredni lub serwer proxy aplikacji.
Planowanie zmian rekordów DNS, w tym wpisów struktury zasad nadawcy .
Planowanie strategii translatora adresów sieciowych, w tym wychodzącego i przychodzącego źródłowego translatora adresów sieciowych.
Planowanie routingu przy użyciu ścieżek sieciowych Internetu i usługi ExpressRoute
W przypadku początkowego wdrożenia zaleca się korzystanie z Internetu we wszystkich usługach przychodzących, takich jak przychodzące wiadomości e-mail lub łączność hybrydowa.
Planowanie routingu sieci LAN klienta użytkownika końcowego, takiego jak konfigurowanie pliku PAC/WPAD, trasy domyślnej, serwerów proxy i anonsów tras protokołu BGP.
Planowanie routingu obwodu, w tym serwerów proxy, zapór i serwerów proxy w chmurze.
Planowanie przepustowości, zabezpieczeń, wysokiej dostępności i trybu failover
Twórca plan przepustowości wymagany dla każdego dużego obciążenia platformy Microsoft 365. Oddzielnie oszacuj wymagania dotyczące przepustowości Exchange Online, programu SharePoint i Skype dla firm Online. Możesz użyć kalkulatorów szacowania dostępnych dla Exchange Online i Skype dla firm jako miejsca początkowego. Jednak test pilotażowy z reprezentatywną próbką profilów i lokalizacji użytkowników jest wymagany, aby w pełni zrozumieć potrzeby dotyczące przepustowości organizacji.
Dodaj sposób obsługi zabezpieczeń w poszczególnych lokalizacjach internetu i ruchu wychodzącego usługi ExpressRoute do planu, pamiętaj, że wszystkie połączenia usługi ExpressRoute z usługą Microsoft 365 korzystają z publicznej komunikacji równorzędnej i muszą być zabezpieczone zgodnie z zasadami zabezpieczeń firmy dotyczącymi łączenia się z sieciami zewnętrznymi.
Dodaj szczegółowe informacje do planu, na które osoby będą miały wpływ awarie i jak te osoby będą mogły wykonywać swoją pracę na pełnych obrotach w najprostszy sposób.
Planowanie wymagań dotyczących przepustowości, w tym wymagań Skype dla firm dotyczących jitteru, opóźnienia, przeciążenia i przestrzeni headroom
Skype dla firm Online ma również określone dodatkowe wymagania dotyczące sieci, które zostały szczegółowo opisane w artykule Jakość multimediów i wydajność łączności sieciowej w usłudze Skype dla firm Online.
Przeczytaj sekcję Planowanie przepustowości dla usługi Azure ExpressRoute. Podczas przeprowadzania oceny przepustowości z użytkownikami pilotażowymi możesz użyć naszego przewodnika dostrajania wydajności platformy Microsoft 365 przy użyciu punktów odniesienia i historii wydajności.
Planowanie wymagań dotyczących wysokiej dostępności
Twórca plan wysokiej dostępności w celu spełnienia twoich potrzeb i uwzględnienia go w zaktualizowanym diagramie topologii sieci. Przeczytaj sekcję Wysoka dostępność i tryb failover w usłudze Azure ExpressRoute.
Planowanie wymagań dotyczących zabezpieczeń sieci
Twórca plan, aby spełnić wymagania dotyczące zabezpieczeń sieci i włączyć go do zaktualizowanego diagramu topologii sieci. Przeczytaj sekcję Stosowanie mechanizmów kontroli zabezpieczeń do scenariuszy usługi Azure ExpressRoute dla platformy Microsoft 365.
Projektowanie łączności usługi wychodzącej
Usługa ExpressRoute dla platformy Microsoft 365 ma wymagania dotyczące sieci wychodzącej , które mogą być nieznane. W szczególności adresy IP reprezentujące użytkowników i sieci do platformy Microsoft 365 i pełniące rolę źródłowych punktów końcowych dla wychodzących połączeń sieciowych z firmą Microsoft muszą spełniać określone wymagania opisane poniżej.
Punkty końcowe muszą być publicznymi adresami IP zarejestrowanymi w firmie lub dla operatora zapewniającego łączność usługi ExpressRoute z Tobą.
Punkty końcowe muszą być anonsowane do firmy Microsoft i weryfikowane/akceptowane przez usługę ExpressRoute.
Punkty końcowe nie mogą być anonsowane w Internecie przy użyciu tej samej lub bardziej preferowanej metryki routingu.
Punktów końcowych nie można używać do łączności z usługami firmy Microsoft, które nie są skonfigurowane za pośrednictwem usługi ExpressRoute.
Jeśli projekt sieci nie spełnia tych wymagań, istnieje duże ryzyko, że użytkownicy będą doświadczać błędów łączności z usługą Microsoft 365 i innymi usługami firmy Microsoft z powodu trasowania czarnego holingu lub routingu asymetrycznego. Dzieje się tak, gdy żądania do usług firmy Microsoft są kierowane za pośrednictwem usługi ExpressRoute, ale odpowiedzi są kierowane z powrotem przez Internet lub odwrotnie, a odpowiedzi są porzucane przez stanowe urządzenia sieciowe, takie jak zapory.
Najczęściej używaną metodą do spełnienia powyższych wymagań jest użycie źródłowego translatora adresów sieciowych zaimplementowanego jako część sieci lub dostarczonego przez operatora usługi ExpressRoute. Źródłowy translator adresów sieciowych umożliwia abstrakcję szczegółów i prywatnych adresów IP sieci internetowej z usługi ExpressRoute i; w połączeniu z odpowiednimi anonsami tras ip, zapewniają łatwy mechanizm zapewniający symetrię ścieżki. Jeśli używasz stanowych urządzeń sieciowych specyficznych dla lokalizacji komunikacji równorzędnej usługi ExpressRoute, musisz zaimplementować oddzielne pule NAT dla każdej komunikacji równorzędnej usługi ExpressRoute, aby zapewnić symetrię ścieżki.
Dowiedz się więcej o wymaganiach dotyczących translatora adresów sieciowych usługi ExpressRoute.
Dodaj zmiany dotyczące łączności wychodzącej do diagramu topologii sieci.
Projektowanie łączności usługi przychodzącej
Większość wdrożeń platformy Microsoft 365 w przedsiębiorstwie przyjmuje pewną formę łączności przychodzącej z usługi Microsoft 365 do usług lokalnych, takich jak exchange, SharePoint i Skype dla firm scenariusze hybrydowe, migracje skrzynek pocztowych i uwierzytelnianie przy użyciu infrastruktury usług ADFS. Gdy usługa ExpressRoute włączy dodatkową ścieżkę routingu między siecią lokalną a firmą Microsoft na potrzeby łączności wychodzącej, na te połączenia przychodzące może przypadkowo mieć wpływ routing asymetryczny, nawet jeśli zamierzasz, aby te przepływy nadal korzystały z Internetu. Kilka opisanych poniżej środków ostrożności zaleca się, aby upewnić się, że nie ma to wpływu na przepływy przychodzące oparte na Internecie z platformy Microsoft 365 do systemów lokalnych.
Aby zminimalizować ryzyko związane z routingiem asymetrycznym dla przepływów ruchu przychodzącego sieciowego, wszystkie połączenia przychodzące powinny używać źródłowego translatora adresów sieciowych, zanim zostaną przekierowane do segmentów sieci, które mają wgląd w routing w usłudze ExpressRoute. Jeśli połączenia przychodzące są dozwolone w segmencie sieci z widocznością routingu do usługi ExpressRoute bez źródłowego translatora adresów sieciowych, żądania pochodzące z platformy Microsoft 365 będą wprowadzane z Internetu, ale odpowiedź wracająca do platformy Microsoft 365 będzie preferować ścieżkę sieciową usługi ExpressRoute z powrotem do sieci firmy Microsoft, powodując routing asymetryczny.
Aby spełnić to wymaganie, możesz rozważyć jeden z następujących wzorców implementacji:
Przed skierowaniem żądań do sieci wewnętrznej przy użyciu sprzętu sieciowego, takiego jak zapory lub moduły równoważenia obciążenia na ścieżce z Internetu do systemów lokalnych, wykonaj źródłowy translator adresów sieciowych.
Upewnij się, że trasy usługi ExpressRoute nie są propagowane do segmentów sieci, w których znajdują się usługi przychodzące, takie jak serwery frontonu lub odwrotne systemy proxy, obsługujące połączenia internetowe.
Jawne uwzględnianie tych scenariuszy w sieci i utrzymywanie wszystkich przepływów ruchu przychodzącego przez Internet pomaga zminimalizować wdrożenie i ryzyko operacyjne routingu asymetrycznego.
Mogą wystąpić przypadki, w których można kierować niektóre przepływy przychodzące za pośrednictwem połączeń usługi ExpressRoute. W przypadku tych scenariuszy należy wziąć pod uwagę następujące dodatkowe zagadnienia.
Platforma Microsoft 365 może być przeznaczona tylko dla lokalnych punktów końcowych korzystających z publicznych adresów IP. Oznacza to, że nawet jeśli lokalny punkt końcowy ruchu przychodzącego jest uwidoczniany tylko na platformie Microsoft 365 za pośrednictwem usługi ExpressRoute, nadal musi mieć skojarzony publiczny adres IP.
Wszystkie rozpoznawanie nazw DNS wykonywane przez usługi Microsoft 365 w celu rozpoznawania lokalnych punktów końcowych odbywa się przy użyciu publicznego systemu DNS. Oznacza to, że musisz zarejestrować nazwę FQDN punktów końcowych usługi dla ruchu przychodzącego w mapowaniach adresów IP w Internecie.
Aby odbierać przychodzące połączenia sieciowe za pośrednictwem usługi ExpressRoute, publiczne podsieci IP dla tych punktów końcowych muszą być anonsowane do firmy Microsoft za pośrednictwem usługi ExpressRoute.
Dokładnie oceń te przychodzące przepływy ruchu sieciowego, aby upewnić się, że odpowiednie zabezpieczenia i mechanizmy kontroli sieci są stosowane zgodnie z zasadami zabezpieczeń i sieci firmy.
Po anonsowaniu lokalnych punktów końcowych przychodzących do firmy Microsoft za pośrednictwem usługi ExpressRoute usługa ExpressRoute stanie się preferowaną ścieżką routingu do tych punktów końcowych dla wszystkich usług firmy Microsoft, w tym platformy Microsoft 365. Oznacza to, że te podsieci punktów końcowych muszą być używane tylko do komunikacji z usługami Platformy Microsoft 365 i bez innych usług w sieci firmy Microsoft. W przeciwnym razie twój projekt spowoduje routing asymetryczny, w którym połączenia przychodzące z innych usług firmy Microsoft wolą kierować ruch przychodzący za pośrednictwem usługi ExpressRoute, podczas gdy ścieżka powrotna będzie korzystać z Internetu.
W przypadku wyłączenia obwodu usługi ExpressRoute lub lokalizacji meet-me należy upewnić się, że lokalne punkty końcowe ruchu przychodzącego są nadal dostępne do akceptowania żądań za pośrednictwem oddzielnej ścieżki sieciowej. Może to oznaczać anonsowanie podsieci dla tych punktów końcowych za pośrednictwem wielu obwodów usługi ExpressRoute.
Zalecamy zastosowanie źródłowego translatora adresów sieciowych dla wszystkich przepływów ruchu sieciowego ruchu przychodzącego do sieci za pośrednictwem usługi ExpressRoute, zwłaszcza gdy te przepływy są między stanowymi urządzeniami sieciowymi, takimi jak zapory.
Niektóre usługi lokalne, takie jak serwer proxy usług ADFS lub automatyczne wykrywanie programu Exchange, mogą odbierać żądania przychodzące zarówno od usług platformy Microsoft 365, jak i użytkowników z Internetu. W przypadku tych żądań platforma Microsoft 365 będzie przeznaczona dla tej samej nazwy FQDN co żądania użytkowników przez Internet. Zezwolenie na przychodzące połączenia użytkowników z Internetu do tych lokalnych punktów końcowych przy jednoczesnym wymuszaniu połączeń platformy Microsoft 365 do korzystania z usługi ExpressRoute oznacza znaczną złożoność routingu. Dla zdecydowanej większości klientów implementujących tak złożone scenariusze w usłudze ExpressRoute nie jest zalecane ze względu na kwestie operacyjne. To dodatkowe obciążenie obejmuje zarządzanie ryzykiem routingu asymetrycznego i wymaga starannego zarządzania anonsami i zasadami routingu w wielu wymiarach.
Zaktualizuj plan topologii sieci, aby pokazać, jak można uniknąć tras asymetrycznych
Chcesz uniknąć routingu asymetrycznego, aby zapewnić, że osoby w organizacji będą mogły bezproblemowo korzystać z platformy Microsoft 365 oraz innych ważnych usług w Internecie. Istnieją dwie typowe konfiguracje, które klienci mają, które powodują routing asymetryczny. Teraz warto zapoznać się z konfiguracją sieci, której planujesz użyć, i sprawdzić, czy może istnieć jeden z tych scenariuszy routingu asymetrycznego.
Na początek przeanalizujemy kilka różnych sytuacji związanych z poniższym diagramem sieciowym. Na tym diagramie wszystkie serwery, które odbierają żądania przychodzące, takie jak usługi ADFS lub lokalne serwery hybrydowe, znajdują się w centrum danych New Jersey i są anonsowane w Internecie.
Sieć obwodowa jest bezpieczna, ale nie ma dostępnego źródłowego translatora adresów sieciowych dla żądań przychodzących.
Serwery w centrum danych New Jersey mogą wyświetlać zarówno trasy internetowe, jak i expressroute.
Mamy również sugestie dotyczące sposobu ich naprawy.
Problem 1. Połączenie z chmurą do połączenia lokalnego przez Internet
Na poniższym diagramie przedstawiono asymetryczną ścieżkę sieciową podjętą, gdy konfiguracja sieci nie zapewnia translatora adresów sieciowych dla żądań przychodzących z chmury firmy Microsoft przez Internet.
Żądanie przychodzące z usługi Microsoft 365 pobiera adres IP lokalnego punktu końcowego z publicznego systemu DNS i wysyła żądanie do sieci obwodowej.
W tej wadliwej konfiguracji nie skonfigurowano ani nie ma dostępnego źródłowego translatora adresów sieciowych w sieci obwodowej, w której wysyłany jest ruch, co powoduje użycie rzeczywistego źródłowego adresu IP jako miejsca docelowego powrotu.
Serwer w sieci kieruje ruch powrotny do platformy Microsoft 365 za pośrednictwem dowolnego dostępnego połączenia sieciowego usługi ExpressRoute.
Wynikiem jest ścieżka asymetryczna dla tego przepływu do platformy Microsoft 365, co powoduje przerwanie połączenia.
Rozwiązanie 1a: źródłowy translator adresów adresów domeny
Po prostu dodanie źródłowego translatora adresów sieciowych do żądania przychodzącego rozwiązuje problem z nieprawidłowo skonfigurowaną siecią. Na tym diagramie:
Żądanie przychodzące nadal jest wprowadzane za pośrednictwem sieci obwodowej centrum danych New Jersey. Tym razem dostępna jest źródłowa translator adresów sieciowych.
Odpowiedź z serwera kieruje się z powrotem do adresu IP skojarzonego ze źródłowym translatorem adresów sieciowych zamiast oryginalnego adresu IP, co powoduje zwrócenie odpowiedzi w tej samej ścieżce sieciowej.
Rozwiązanie 1b: określanie zakresu tras
Alternatywnie możesz nie zezwalać na anonsowanie prefiksów protokołu BGP usługi ExpressRoute, usuwając alternatywną ścieżkę sieci dla tych komputerów. Na tym diagramie:
Żądanie przychodzące nadal jest wprowadzane za pośrednictwem sieci obwodowej centrum danych New Jersey. Tym razem prefiksy anonsowane przez firmę Microsoft za pośrednictwem obwodu usługi ExpressRoute nie są dostępne dla centrum danych New Jersey.
Odpowiedź z serwera kieruje się z powrotem do adresu IP skojarzonego z oryginalnym adresem IP za pośrednictwem jedynej dostępnej trasy, co powoduje zwrócenie odpowiedzi w tej samej ścieżce sieciowej.
Problem 2. Połączenie z chmurą do środowiska lokalnego za pośrednictwem usługi ExpressRoute
Na poniższym diagramie przedstawiono asymetryczną ścieżkę sieciową podjętą, gdy konfiguracja sieci nie zapewnia translatora adresów sieciowych dla żądań przychodzących z chmury firmy Microsoft za pośrednictwem usługi ExpressRoute.
Żądanie przychodzące od platformy Microsoft 365 pobiera adres IP z systemu DNS i wysyła żądanie do sieci obwodowej.
W tej wadliwej konfiguracji nie skonfigurowano ani nie ma dostępnego źródłowego translatora adresów sieciowych w sieci obwodowej, w której wysyłany jest ruch, co powoduje użycie rzeczywistego źródłowego adresu IP jako miejsca docelowego powrotu.
Komputer w sieci kieruje ruch powrotny do platformy Microsoft 365 za pośrednictwem dowolnego dostępnego połączenia sieciowego usługi ExpressRoute.
Rezultatem jest połączenie asymetryczne z platformą Microsoft 365.
Rozwiązanie 2: źródłowy translator adresów
Po prostu dodanie źródłowego translatora adresów sieciowych do żądania przychodzącego rozwiązuje problem z nieprawidłowo skonfigurowaną siecią. Na tym diagramie:
Żądanie przychodzące nadal jest wprowadzane za pośrednictwem sieci obwodowej centrum danych w Nowym Jorku. Tym razem dostępna jest źródłowa translator adresów sieciowych.
Odpowiedź z serwera kieruje się z powrotem do adresu IP skojarzonego ze źródłowym translatorem adresów sieciowych zamiast oryginalnego adresu IP, co powoduje zwrócenie odpowiedzi w tej samej ścieżce sieciowej.
Papierowe sprawdzanie, czy projekt sieci ma symetrię ścieżki
Na tym etapie należy sprawdzić na papierze, czy plan implementacji oferuje symetrię tras dla różnych scenariuszy, w których będziesz używać platformy Microsoft 365. Zidentyfikujesz określoną trasę sieciową, która ma zostać podjęta, gdy dana osoba korzysta z różnych funkcji usługi. Od sieci lokalnej i routingu sieci WAN do urządzeń obwodowych do ścieżki łączności; Usługa ExpressRoute lub Internet oraz połączenie z punktem końcowym online.
Należy to zrobić w przypadku wszystkich usług sieciowych platformy Microsoft 365, które zostały wcześniej zidentyfikowane jako usługi, które organizacja wdroży.
Pomaga to zrobić ten papierowy przewodnik po trasach z drugą osobą. Wyjaśnij im, skąd oczekuje się, że każdy przeskok sieciowy ma uzyskać następną trasę, i upewnij się, że znasz ścieżki routingu. Pamiętaj, że usługa ExpressRoute zawsze zapewnia trasę o większym zakresie do adresów IP serwera firmy Microsoft, co zapewnia niższy koszt trasy niż domyślna trasa internetowa.
Projektowanie konfiguracji łączności klienta
Jeśli używasz serwera proxy dla ruchu związanego z Internetem, musisz dostosować wszystkie pliki PAC lub konfiguracji klienta, aby upewnić się, że komputery klienckie w sieci są prawidłowo skonfigurowane do wysyłania ruchu usługi ExpressRoute żądanego do platformy Microsoft 365 bez przesyłania serwera proxy, a pozostały ruch, w tym część ruchu platformy Microsoft 365, jest wysyłany do odpowiedniego serwera proxy. Przeczytaj nasz przewodnik dotyczący zarządzania punktami końcowymi platformy Microsoft 365, na przykład plikami PAC.
Uwaga
Punkty końcowe zmieniają się często, tak często jak co tydzień. Zmiany należy wprowadzać tylko w oparciu o usługi i funkcje, które organizacja przyjęła, aby zmniejszyć liczbę zmian, które należy wprowadzić, aby zachować aktualność. Zwróć szczególną uwagę na datę wejścia w życie w kanale informacyjnym RSS, w którym zmiany są ogłaszane, a do momentu osiągnięcia daty wejścia w życie nie można anonsować ani usuwać z reklamy wszystkie wcześniejsze zmiany, adresy IP, które są ogłaszane.
Zapewnianie symetrii tras
Serwery frontonu platformy Microsoft 365 są dostępne zarówno w Internecie, jak i w usłudze ExpressRoute. Te serwery wolą kierować z powrotem do środowiska lokalnego za pośrednictwem obwodów usługi ExpressRoute, gdy oba są dostępne. W związku z tym istnieje możliwość asymetrii tras, jeśli ruch z sieci woli kierować się przez obwody internetowe. Trasy asymetryczne stanowią problem, ponieważ urządzenia, które przeprowadzają inspekcję pakietów stanowych, mogą blokować ruch powrotny, który podąża inną ścieżką niż obserwowane pakiety wychodzące.
Niezależnie od tego, czy inicjujesz połączenie z usługą Microsoft 365 za pośrednictwem Internetu, czy usługi ExpressRoute, źródło musi być adresem publicznie routingu. W przypadku wielu klientów komunikacji równorzędnej bezpośrednio z firmą Microsoft posiadanie prywatnych adresów, w których możliwe jest duplikowanie między klientami, nie jest możliwe.
Poniżej przedstawiono scenariusze, w których zostanie zainicjowana komunikacja z platformy Microsoft 365 do sieci lokalnej. Aby uprościć projekt sieci, zalecamy kierowanie następujących elementów za pośrednictwem ścieżki internetowej.
Usługi SMTP, takie jak poczta e-mail z dzierżawy Exchange Online do hosta lokalnego lub poczty programu SharePoint wysyłanej z programu SharePoint do hosta lokalnego. Protokół SMTP jest używany szerzej w sieci firmy Microsoft niż prefiksy tras udostępnione przez obwody usługi ExpressRoute i anonsowanie lokalnych serwerów SMTP za pośrednictwem usługi ExpressRoute spowoduje błędy z tymi innymi usługami.
Usługi ADFS podczas walidacji haseł na potrzeby logowania.
Aby firma Microsoft przekierowała z powrotem do sieci dla tych dwukierunkowych przepływów ruchu, trasy protokołu BGP do urządzeń lokalnych muszą być współużytkowane z firmą Microsoft. W przypadku anonsowania prefiksów tras do firmy Microsoft za pośrednictwem usługi ExpressRoute należy postępować zgodnie z następującymi najlepszymi rozwiązaniami:
Nie anonsuj tego samego prefiksu trasy publicznego adresu IP do publicznego Internetu i za pośrednictwem usługi ExpressRoute. Zaleca się, aby anonsy prefiksów tras protokołu BGP protokołu IP do firmy Microsoft za pośrednictwem usługi ExpressRoute pochodziły z zakresu, który nie jest w ogóle anonsowany w Internecie. Jeśli nie jest to możliwe ze względu na dostępną przestrzeń adresów IP, należy upewnić się, że anonsujesz bardziej szczegółowy zakres za pośrednictwem usługi ExpressRoute niż jakiekolwiek obwody internetowe.
Użyj oddzielnych pul adresów IP translatora adresów sieciowych na obwód usługi ExpressRoute i oddziel je od obwodów internetowych.
Każda trasa anonsowana do firmy Microsoft przyciągnie ruch sieciowy z dowolnego serwera w sieci firmy Microsoft, a nie tylko tych, dla których trasy są anonsowane do sieci za pośrednictwem usługi ExpressRoute. Anonsuj trasy tylko do serwerów, na których scenariusze routingu są zdefiniowane i dobrze zrozumiałe dla twojego zespołu. Anonsuj oddzielne prefiksy tras adresów IP w każdym z wielu obwodów usługi ExpressRoute z sieci.
Wysoka dostępność i tryb failover w usłudze Azure ExpressRoute
Zalecamy aprowizowanie co najmniej dwóch aktywnych obwodów z każdego ruchu wychodzącego za pomocą usługi ExpressRoute do dostawcy usługi ExpressRoute. Jest to najczęstsze miejsce, w których występują błędy dla klientów i można ich łatwo uniknąć, aprowizacja pary aktywnych/aktywnych obwodów usługi ExpressRoute. Zalecamy również co najmniej dwa aktywne/aktywne obwody internetowe, ponieważ wiele usług platformy Microsoft 365 jest dostępnych tylko przez Internet.
Wewnątrz punktu ruchu wychodzącego sieci znajduje się wiele innych urządzeń i obwodów, które odgrywają kluczową rolę w postrzeganiu dostępności przez użytkowników. Te części scenariuszy łączności nie są objęte umowami SLA usługi ExpressRoute ani Platformy Microsoft 365, ale odgrywają one kluczową rolę w kompleksowej dostępności usługi, co są postrzegane przez osoby w organizacji.
Skoncentruj się na osobach korzystających z platformy Microsoft 365 i korzystających z nich, jeśli awaria jednego składnika wpłynie na środowisko osób korzystających z usługi, poszukaj sposobów ograniczenia całkowitego odsetka osób, których dotyczy problem. Jeśli tryb pracy w trybie failover jest złożony pod względem operacyjnym, należy wziąć pod uwagę środowisko ludzi z długiego czasu odzyskiwania i poszukać prostych operacyjnie i zautomatyzowanych trybów pracy w trybie failover.
Poza siecią, platforma Microsoft 365, usługa ExpressRoute i dostawca usługi ExpressRoute mają różne poziomy dostępności.
Dostępność usługi
Usługi platformy Microsoft 365 są objęte dobrze zdefiniowanymi umowami dotyczącymi poziomu usług, które obejmują metryki czasu pracy i dostępności dla poszczególnych usług. Jednym z powodów, dla których platforma Microsoft 365 może utrzymać tak wysoki poziom dostępności usług, jest możliwość bezproblemowego przełączania poszczególnych składników w tryb failover między wieloma centrami danych firmy Microsoft przy użyciu globalnej sieci firmy Microsoft. Ten tryb failover rozciąga się z centrum danych i sieci do wielu internetowych punktów ruchu wychodzącego i umożliwia bezproblemowe przejście w tryb failover z perspektywy osób korzystających z usługi.
Usługa ExpressRoute zapewnia 99,9% dostępności umowy SLA dla poszczególnych dedykowanych obwodów między przeglądarką Microsoft Network Edge a dostawcą usługi ExpressRoute lub infrastrukturą partnera. Te poziomy usług są stosowane na poziomie obwodu usługi ExpressRoute, który składa się z dwóch niezależnych połączeń między nadmiarowym sprzętem firmy Microsoft a sprzętem dostawcy sieci w każdej lokalizacji komunikacji równorzędnej.
Dostępność dostawcy
- Ustalenia dotyczące poziomu usług firmy Microsoft są zatrzymywane u dostawcy lub partnera usługi ExpressRoute. Jest to również pierwsze miejsce, w których można dokonywać wyborów, które będą miały wpływ na poziom dostępności. Należy dokładnie ocenić architekturę, dostępność i odporność, które dostawca usługi ExpressRoute oferuje między obwodem sieci a połączeniem dostawców w każdej lokalizacji komunikacji równorzędnej firmy Microsoft. Zwróć szczególną uwagę na logiczne i fizyczne aspekty nadmiarowości, sprzętu komunikacji równorzędnej, obwodów sieci WAN dostarczanych przez przewoźnika oraz wszelkich dodatkowych usług dodawania wartości, takich jak usługi NAT lub zarządzane zapory.
Projektowanie planu dostępności
Zdecydowanie zalecamy planowanie i projektowanie wysokiej dostępności i odporności w kompleksowych scenariuszach łączności dla platformy Microsoft 365. Projekt powinien obejmować;
Brak pojedynczych punktów awarii, w tym obwodów Internetowych i ExpressRoute.
Minimalizowanie liczby osób, których to dotyczy, i czasu trwania tego wpływu w przypadku większości przewidywanych trybów awarii.
Optymalizacja dla prostego, powtarzalnego i automatycznego procesu odzyskiwania z większości przewidywanych trybów awarii.
Obsługa pełnego zapotrzebowania na ruch sieciowy i funkcjonalność za pośrednictwem ścieżek nadmiarowych bez znacznego pogorszenia wydajności.
Scenariusze łączności powinny obejmować topologię sieci zoptymalizowaną pod kątem wielu niezależnych i aktywnych ścieżek sieciowych do platformy Microsoft 365. Zapewni to lepszą kompleksową dostępność niż topologia zoptymalizowana tylko pod kątem nadmiarowości na poziomie poszczególnych urządzeń lub urządzeń.
Porada
Jeśli użytkownicy są rozdzielani między wieloma kontynentami lub regionami geograficznymi, a każda z tych lokalizacji łączy się za pośrednictwem nadmiarowych obwodów sieci WAN z pojedynczą lokalizacją lokalną, w której znajduje się pojedynczy obwód usługi ExpressRoute, użytkownicy będą mieć mniejszą dostępność usługi end-to-end niż projekt topologii sieci, który obejmuje niezależne obwody usługi ExpressRoute łączące różne regiony z najbliższą lokalizacją komunikacji równorzędnej.
Zalecamy aprowizowanie co najmniej dwóch obwodów usługi ExpressRoute z każdym obwodem łączącym się z inną geograficzną lokalizacją komunikacji równorzędnej. Należy aprowizować tę aktywno-aktywną parę obwodów dla każdego regionu, w którym użytkownicy będą korzystać z łączności usługi ExpressRoute dla usług Microsoft 365. Dzięki temu każdy region może pozostać połączony podczas awarii, która ma wpływ na główną lokalizację, taką jak centrum danych lub lokalizacja komunikacji równorzędnej. Skonfigurowanie ich jako aktywnych/aktywnych umożliwia dystrybucję ruchu użytkowników końcowych na wielu ścieżkach sieciowych. Zmniejsza to zakres osób dotkniętych awariami urządzeń lub urządzeń sieciowych.
Nie zalecamy używania jednego obwodu usługi ExpressRoute z Internetem jako kopii zapasowej.
Przykład: tryb failover i wysoka dostępność
Projekt wielo geograficzny firmy Contoso został poddany przeglądowi routingu, przepustowości, zabezpieczeń, a teraz musi przejść przez przegląd wysokiej dostępności. Firma Contoso uważa wysoką dostępność za obejmującą trzy kategorie; odporność, niezawodność i nadmiarowość.
Odporność umożliwia firmie Contoso szybkie odzyskiwanie po awariach. Niezawodność umożliwia firmie Contoso zapewnienie spójnego wyniku w systemie. Nadmiarowość umożliwia firmie Contoso przejście między co najmniej jednym dublowanym wystąpieniem infrastruktury.
W ramach każdej konfiguracji krawędzi firma Contoso ma nadmiarowe zapory, serwery proxy i identyfikatory. W przypadku Ameryka Północna firma Contoso ma jedną konfigurację krawędzi w centrum danych Dallas i inną konfigurację krawędzi w centrum danych w Wirginii. Nadmiarowy sprzęt w każdej lokalizacji zapewnia odporność na tę lokalizację.
Konfiguracja sieci w firmie Contoso jest oparta na kilku kluczowych zasadach:
W każdym regionie geograficznym istnieje wiele obwodów usługi Azure ExpressRoute.
Każdy obwód w regionie może obsługiwać cały ruch sieciowy w tym regionie.
Routing wyraźnie preferuje jedną lub drugą ścieżkę w zależności od dostępności, lokalizacji itd.
Przełączanie w tryb failover między obwodami usługi Azure ExpressRoute odbywa się automatycznie bez dodatkowej konfiguracji lub akcji wymaganej przez firmę Contoso.
Tryb failover między obwodami internetowymi odbywa się automatycznie bez dodatkowej konfiguracji lub akcji wymaganej przez firmę Contoso.
W tej konfiguracji dzięki nadmiarowości na poziomie fizycznym i wirtualnym firma Contoso może w niezawodny sposób zaoferować lokalną odporność, odporność regionalną i globalną odporność. Firma Contoso wybrała tę konfigurację po dokonaniu oceny pojedynczego obwodu usługi Azure ExpressRoute na region, a także możliwości przełączenia w tryb failover do Internetu.
Jeśli firma Contoso nie może mieć wielu obwodów usługi Azure ExpressRoute na region, kierowanie ruchu pochodzącego z Ameryka Północna do obwodu usługi Azure ExpressRoute w regionie Azji i Pacyfiku spowoduje dodanie niedopuszczalnego poziomu opóźnienia, a wymagana konfiguracja usługi przesyłania dalej DNS zwiększa złożoność.
Korzystanie z Internetu jako konfiguracji kopii zapasowej nie jest zalecane. Powoduje to przerwanie zasady niezawodności firmy Contoso, co powoduje niespójne środowisko korzystania z połączenia. Ponadto ręczna konfiguracja byłaby wymagana do przełączenia w tryb failover, biorąc pod uwagę skonfigurowane anonse protokołu BGP, konfigurację translatora adresów sieciowych, konfigurację DNS i konfigurację serwera proxy. Ta dodatkowa złożoność trybu failover wydłuża czas odzyskiwania i zmniejsza ich zdolność do diagnozowania i rozwiązywania związanych z tym kroków.
Nadal masz pytania dotyczące planowania i implementowania zarządzania ruchem lub usługi Azure ExpressRoute? Przeczytaj pozostałe wskazówki dotyczące sieci i wydajności lub często zadawane pytania dotyczące usługi Azure ExpressRoute.
Stosowanie mechanizmów kontroli zabezpieczeń w scenariuszach usługi Azure ExpressRoute dla platformy Microsoft 365
Zabezpieczanie łączności usługi Azure ExpressRoute rozpoczyna się od tych samych zasad, co zabezpieczanie łączności z Internetem. Wielu klientów decyduje się na wdrożenie kontrolek sieciowych i obwodowych wzdłuż ścieżki usługi ExpressRoute łączącej sieć lokalną z platformą Microsoft 365 i innymi chmurami firmy Microsoft. Te mechanizmy kontroli mogą obejmować zapory, serwery proxy aplikacji, zapobieganie wyciekom danych, wykrywanie włamań, systemy zapobiegania włamaniom itd. W wielu przypadkach klienci stosują różne poziomy kontroli do ruchu inicjowanego ze środowiska lokalnego do firmy Microsoft w porównaniu z ruchem inicjowanym przez firmę Microsoft przechodzącym do sieci lokalnej klienta w porównaniu z ruchem inicjowanym ze środowiska lokalnego do ogólnego internetowego miejsca docelowego.
Oto kilka przykładów integracji zabezpieczeń z modelem łączności usługi ExpressRoute , który chcesz wdrożyć.
| Opcja integracji usługi ExpressRoute | Model obwodowy zabezpieczeń sieci |
|---|---|
| Colocated at a cloud exchange (Kolokowana na giełdzie w chmurze) |
Zainstaluj nową lub użyj istniejącej infrastruktury zabezpieczeń/obwodowej w obiekcie kolokacji, w którym nawiązano połączenie usługi ExpressRoute. Użyj obiektu kolokacji wyłącznie do celów routingu/połączenia wzajemnego i połączeń back haul z obiektu kolokacji do lokalnej infrastruktury zabezpieczeń/obwodowej. |
| Sieć Ethernet typu punkt-punkt |
Zakończ połączenie usługi ExpressRoute typu punkt-punkt w istniejącej lokalnej lokalizacji infrastruktury zabezpieczeń/obwodowej. Zainstaluj nową infrastrukturę zabezpieczeń/obwodową specyficzną dla ścieżki usługi ExpressRoute i zakończ tam połączenie punkt-punkt. |
| Dowolna-dowolna nazwa IPVPN |
Użyj istniejącej lokalnej infrastruktury zabezpieczeń/obwodowej we wszystkich lokalizacjach wychodzących do sieci IPVPN używanej do łączności usługi ExpressRoute dla usługi Microsoft 365. Zasuń nazwę IPVPN używaną w usłudze ExpressRoute dla platformy Microsoft 365 do określonych lokalizacji lokalnych wyznaczonych do pełnienia funkcji zabezpieczeń/obwodu. |
Niektórzy dostawcy usług oferują również funkcje zabezpieczeń zarządzanych/obwodowych w ramach swoich rozwiązań integracji z usługą Azure ExpressRoute.
Rozważając rozmieszczenie topologii opcji obwodowych sieci/zabezpieczeń używanych dla połączeń usługi ExpressRoute dla platformy Microsoft 365, poniżej przedstawiono dodatkowe zagadnienia
Mechanizmy kontroli sieci/zabezpieczeń typu i głębokości mogą mieć wpływ na wydajność i skalowalność środowiska użytkownika platformy Microsoft 365.
Przepływy wychodzące (lokalne firmy> Microsoft) i przychodzące (lokalne firmy Microsoft>) [jeśli są włączone] mogą mieć inne wymagania. Prawdopodobnie różnią się one od wychodzących do ogólnych miejsc docelowych w Internecie.
Wymagania platformy Microsoft 365 dotyczące portów/protokołów i niezbędnych podsieci IP są takie same, niezależnie od tego, czy ruch jest kierowany przez usługę ExpressRoute dla platformy Microsoft 365, czy przez Internet.
Rozmieszczenie topologiczne sieci klienta/mechanizmów kontroli zabezpieczeń określa ostateczną kompleksową sieć między użytkownikiem a usługą Microsoft 365 i może mieć znaczący wpływ na opóźnienie sieci i przeciążenie sieci.
Zachęcamy klientów do projektowania topologii zabezpieczeń/obwodu do użycia z usługą ExpressRoute dla platformy Microsoft 365 zgodnie z najlepszymi rozwiązaniami dotyczącymi nadmiarowości, wysokiej dostępności i odzyskiwania po awarii.
Oto przykład firmy Contoso, który porównuje różne opcje łączności usługi Azure ExpressRoute z modelami zabezpieczeń obwodowych omówionymi powyżej.
Przykład: zabezpieczanie usługi Azure ExpressRoute
Firma Contoso rozważa wdrożenie usługi Azure ExpressRoute i po zaplanowaniu optymalnej architektury usługi ExpressRoute dla platformy Microsoft 365 i po zastosowaniu powyższych wskazówek w celu zrozumienia wymagań dotyczących przepustowości określa najlepszą metodę zabezpieczania obwodu.
W przypadku firmy Contoso, organizacji wielonarodowej z lokalizacjami na wielu kontynentach, zabezpieczenia muszą obejmować wszystkie obwody. Optymalną opcją łączności dla firmy Contoso jest połączenie wielopunktowe z wieloma lokalizacjami komunikacji równorzędnej na całym świecie w celu zaspokojenia potrzeb pracowników na każdym kontynencie. Każdy kontynent obejmuje nadmiarowe obwody usługi Azure ExpressRoute na kontynencie, a zabezpieczenia muszą obejmować wszystkie te elementy.
Istniejąca infrastruktura firmy Contoso jest niezawodna i może obsłużyć dodatkową pracę, w związku z tym firma Contoso może korzystać z infrastruktury na potrzeby zabezpieczeń obwodowych usługi Azure ExpressRoute i Internetu. Gdyby tak nie było, firma Contoso mogłaby zdecydować się na zakup większej liczby urządzeń w celu uzupełnienia istniejącego sprzętu lub obsługi innego typu połączenia.
Planowanie przepustowości dla usługi Azure ExpressRoute
Każdy klient platformy Microsoft 365 ma unikatowe wymagania dotyczące przepustowości w zależności od liczby osób w każdej lokalizacji, aktywności poszczególnych aplikacji platformy Microsoft 365 oraz innych czynników, takich jak użycie sprzętu lokalnego lub hybrydowego oraz konfiguracje zabezpieczeń sieci.
Zbyt mała przepustowość spowoduje przeciążenie, retransmisję danych i nieprzewidywalne opóźnienia. Zbyt duża przepustowość spowoduje niepotrzebne koszty. W istniejącej sieci przepustowość jest często określana jako wartość procentowa dostępnego miejsca na pokładzie obwodu. Posiadanie 10% miejsca na głowę prawdopodobnie spowoduje przeciążenie, a posiadanie 80% miejsca na głowę zwykle oznacza niepotrzebne koszty. Typowe przydziały docelowe pomieszczeń docelowych to od 20% do 50%.
Aby znaleźć odpowiedni poziom przepustowości, najlepszym mechanizmem jest przetestowanie istniejącego użycia sieci. Jest to jedyny sposób uzyskania rzeczywistej miary użycia i potrzeb, ponieważ każda konfiguracja sieci i aplikacje są w pewnym sensie unikatowe. Podczas mierzenia należy zwrócić szczególną uwagę na całkowite zużycie przepustowości, opóźnienia i przeciążenie TCP, aby zrozumieć potrzeby sieci.
Po utworzeniu szacowanego planu bazowego obejmującego wszystkie aplikacje sieciowe należy pilotować usługę Microsoft 365 z niewielką grupą, która składa się z różnych profilów osób w organizacji, aby określić rzeczywiste użycie, i użyć tych dwóch pomiarów do oszacowania przepustowości wymaganej dla każdej lokalizacji biura. Jeśli podczas testowania występują problemy z opóźnieniami lub przeciążeniem TCP, może być konieczne przeniesienie ruchu wychodzącego bliżej osób korzystających z platformy Microsoft 365 lub usunięcie intensywnego skanowania sieci, takiego jak odszyfrowywanie/inspekcja protokołu SSL.
Wszystkie nasze zalecenia dotyczące tego, jaki typ przetwarzania sieci jest zalecany, mają zastosowanie zarówno do obwodów usługi ExpressRoute, jak i internetu. To samo dotyczy pozostałych wskazówek dotyczących witryny dostrajania wydajności.
Tworzenie procedur wdrażania i testowania
Plan implementacji powinien obejmować zarówno testowanie, jak i planowanie wycofywania. Jeśli implementacja nie działa zgodnie z oczekiwaniami, plan powinien mieć wpływ na najmniejszą liczbę osób przed wykryciem problemów. Poniżej przedstawiono niektóre zasady wysokiego poziomu, które należy wziąć pod uwagę w planie.
Przygotowanie segmentu sieci i dołączania usługi użytkownika w celu zminimalizowania zakłóceń.
Zaplanuj testowanie tras za pomocą funkcji traceroute i połączenia TCP z oddzielnego hosta połączonego z Internetem.
Najlepiej, aby testowanie usług przychodzących i wychodzących odbywało się w izolowanej sieci testowej z testową dzierżawą platformy Microsoft 365.
Alternatywnie testowanie można przeprowadzić w sieci produkcyjnej, jeśli klient nie korzysta jeszcze z platformy Microsoft 365 lub jest w trybie pilotażowym.
Alternatywnie testowanie można przeprowadzić podczas awarii produkcyjnej, która jest odkładana tylko do testowania i monitorowania.
Możesz też przeprowadzić testowanie, sprawdzając trasy dla każdej usługi w każdym węźle routera warstwy 3. Ta rezerwa powinna być używana tylko wtedy, gdy żadne inne testy nie są możliwe, ponieważ brak testów fizycznych wprowadza ryzyko.
Tworzenie procedur wdrażania
Procedury wdrażania powinny być wdrażane w małych grupach osób etapami, aby umożliwić testowanie przed wdrożeniem w większych grupach osób. Poniżej przedstawiono kilka sposobów wdrażania usługi ExpressRoute.
Skonfiguruj usługę ExpressRoute za pomocą komunikacji równorzędnej firmy Microsoft i przekaż anonsy tras do pojedynczego hosta tylko na potrzeby testowania etapowego.
Najpierw anonsuj trasy do sieci ExpressRoute do pojedynczego segmentu sieci i rozwiń anonsy tras według segmentu sieci lub regionu.
W przypadku wdrażania platformy Microsoft 365 po raz pierwszy użyj wdrożenia sieci usługi ExpressRoute jako pilotażu dla kilku osób.
Jeśli używasz serwerów proxy, możesz też skonfigurować testowy plik PAC, aby skierować kilka osób do usługi ExpressRoute z testowaniem i opinią przed dodaniem kolejnych.
Plan implementacji powinien zawierać listę wszystkich procedur wdrażania, które należy wykonać, lub poleceń, które należy użyć do wdrożenia konfiguracji sieci. Gdy nadejdzie czas awarii sieci, wszystkie wprowadzone zmiany powinny pochodzić z pisemnego planu wdrożenia, który został napisany z wyprzedzeniem, a element równorzędny powinien zostać przejrzany. Zapoznaj się z naszymi wskazówkami dotyczącymi konfiguracji technicznej usługi ExpressRoute.
Aktualizowanie rekordów SPF TXT w przypadku zmiany adresów IP dla wszystkich serwerów lokalnych, które będą nadal wysyłać wiadomości e-mail.
Aktualizowanie wszystkich wpisów DNS dla serwerów lokalnych, jeśli zmieniono adresy IP w celu uwzględnienia nowej konfiguracji translatora adresów sieciowych.
Upewnij się, że subskrybowaliśmy kanał informacyjny RSS dla powiadomień punktu końcowego platformy Microsoft 365, aby zachować dowolne konfiguracje routingu lub serwera proxy.
Po zakończeniu wdrażania usługi ExpressRoute należy wykonać procedury w planie testu. Wyniki dla każdej procedury powinny być rejestrowane. Należy uwzględnić procedury wycofywania do oryginalnego środowiska produkcyjnego w przypadku, gdy wyniki planu testu wskazują, że implementacja nie powiodła się.
Tworzenie procedur testowych
Procedury testowania powinny obejmować testy dla każdej wychodzącej i przychodzącej usługi sieciowej dla platformy Microsoft 365, która będzie używać usługi ExpressRoute, i tych, które nie będą. Procedury powinny obejmować testowanie z każdej unikatowej lokalizacji sieciowej, w tym użytkowników, którzy nie są lokalni w firmowej sieci LAN.
Poniżej przedstawiono przykłady działań testowych.
Polecenie ping z routera lokalnego do routera operatora sieciowego.
Sprawdź, czy reklamy adresów IP 500+ microsoft 365 i CRM Online są odbierane przez router lokalny.
Sprawdź, czy przychodzący i wychodzący translator adresów sieciowych działa między usługą ExpressRoute a siecią wewnętrzną.
Sprawdź, czy trasy do translatora adresów sieciowych są anonsowane z routera.
Sprawdź, czy usługa ExpressRoute zaakceptowała twoje anonsowane prefiksy.
- Użyj następującego polecenia cmdlet, aby zweryfikować anonsy komunikacji równorzędnej:
Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeeringSprawdź, czy publiczny zakres adresów IP translatora adresów sieciowych nie jest anonsowany dla firmy Microsoft za pośrednictwem żadnego innego obwodu usługi ExpressRoute lub publicznej sieci internetowej, chyba że jest to określony podzestaw większego zakresu, jak w poprzednim przykładzie.
Obwody usługi ExpressRoute są sparowane. Sprawdź, czy obie sesje protokołu BGP są uruchomione.
Skonfiguruj pojedynczego hosta wewnątrz translatora adresów sieciowych i użyj polecenia ping, tracert i tcpping, aby przetestować łączność między nowym obwodem a outlook.office365.com hosta. Alternatywnie można użyć narzędzia, takiego jak Wireshark lub Microsoft Network Monitor 3.4 na dublowanym porcie do programu MSEE, aby sprawdzić, czy możesz nawiązać połączenie z adresem IP skojarzonym z outlook.office365.com.
Testowanie funkcji na poziomie aplikacji dla Exchange Online.
Program Outlook testowy może nawiązać połączenie z Exchange Online i wysłać/odebrać wiadomość e-mail.
Testowanie programu Outlook umożliwia korzystanie z trybu online.
Przetestuj łączność ze smartfonem i możliwość wysyłania/odbierania.
- Testowanie funkcjonalności na poziomie aplikacji dla programu SharePoint
Testowanie klienta synchronizacji OneDrive dla Firm.
Testowanie dostępu do sieci Web programu SharePoint.
- Testowanie funkcji na poziomie aplikacji dla scenariuszy wywoływania Skype dla firm:
Dołącz do połączenia konferencyjnego jako uwierzytelniony użytkownik [zaproszenie zainicjowane przez użytkownika końcowego].
Zaproś użytkownika do połączenia konferencyjnego [zaproszenie wysłane z mcu].
Dołącz do konferencji jako użytkownik anonimowy przy użyciu aplikacji internetowej Skype dla firm.
Połącz połączenie z połączenia z komputerem przewodowym, telefonem IP i urządzeniem przenośnym.
Wywołanie użytkownika federacyjnego o Wywołanie weryfikacji PSTN: wywołanie zostało zakończone, jakość wywołań jest akceptowalna, czas połączenia jest akceptowalny.
Sprawdź, czy stan obecności kontaktów jest aktualizowany zarówno dla członków dzierżawy, jak i użytkowników federacyjnych.
Typowe problemy
Routing asymetryczny jest najczęstszym problemem z implementacją. Oto kilka typowych źródeł, których należy szukać:
Korzystanie z topologii routingu sieci otwartej lub płaskiej bez źródłowego translatora adresów sieciowych.
Nie używasz SNAT do kierowania do usług przychodzących zarówno za pośrednictwem Internetu, jak i połączeń usługi ExpressRoute.
Nie testowanie usług przychodzących w usłudze ExpressRoute w sieci testowej przed szerokim wdrożeniem.
Wdrażanie łączności usługi ExpressRoute za pośrednictwem sieci
Etap wdrożenia do jednego segmentu sieci naraz, stopniowo wdrażając łączność z różnymi częściami sieci z planem wycofania dla każdego nowego segmentu sieci. Jeśli wdrożenie jest zgodne z wdrożeniem platformy Microsoft 365, najpierw wdróż go u użytkowników pilotażowych platformy Microsoft 365 i rozszerz je stamtąd.
Najpierw na potrzeby testu, a następnie w środowisku produkcyjnym:
Uruchom kroki wdrażania, aby włączyć usługę ExpressRoute.
Sprawdź, czy widzisz, że trasy sieciowe są zgodnie z oczekiwaniami.
Wykonaj testy dla każdej usługi przychodzącej i wychodzącej.
Wycofywanie w przypadku wykrycia jakichkolwiek problemów.
Konfigurowanie połączenia testowego z usługą ExpressRoute przy użyciu segmentu sieci testowej
Teraz, gdy masz ukończony plan na papierze, nadszedł czas, aby przetestować go na małą skalę. W tym teście ustanowisz jedno połączenie usługi ExpressRoute z komunikacją równorzędną firmy Microsoft z podsiecią testową w sieci lokalnej. Możesz skonfigurować dzierżawę platformy Microsoft 365 w wersji próbnej z łącznością z i z podsieci testowej oraz uwzględnić wszystkie usługi wychodzące i przychodzące, których będziesz używać w środowisku produkcyjnym w podsieci testowej. Skonfiguruj system DNS dla segmentu sieci testowej i ustal wszystkie usługi przychodzące i wychodzące. Wykonaj plan testu i upewnij się, że znasz routing dla każdej usługi i propagację trasy.
Wykonywanie planów wdrażania i testowania
Po ukończeniu opisanych powyżej elementów sprawdź ukończone obszary i upewnij się, że Ty i Twój zespół przejrzeliście je przed wykonaniem planów wdrażania i testowania.
Lista usług wychodzących i przychodzących, które są zaangażowane w zmianę sieci.
Diagram architektury sieci globalnej przedstawiający zarówno ruch wychodzący z Internetu, jak i lokalizacje spotkania usługi ExpressRoute.
Diagram routingu sieciowego przedstawiający różne ścieżki sieciowe używane dla każdej wdrożonej usługi.
Plan wdrożenia z krokami implementowania zmian i wycofywania w razie potrzeby.
Plan testowy na potrzeby testowania każdej platformy Microsoft 365 i usługi sieciowej.
Ukończono weryfikację papieru tras produkcyjnych dla usług przychodzących i wychodzących.
Ukończony test w segmencie sieci testowej, w tym testowanie dostępności.
Wybierz okno awarii, które jest wystarczająco długie, aby przejść przez cały plan wdrożenia i plan testu, ma trochę czasu na rozwiązywanie problemów i czas wycofywania w razie potrzeby.
Uwaga
Ze względu na złożony charakter routingu przez Internet i usługę ExpressRoute zaleca się dodanie dodatkowego czasu buforu do tego okna w celu obsługi rozwiązywania problemów ze złożonym routingiem.
Konfigurowanie usługi QoS dla usługi Skype dla firm Online
Usługa QoS jest niezbędna do uzyskania korzyści związanych z obsługą głosu i spełniania Skype dla firm Online. Usługę QoS można skonfigurować po upewnieniu się, że połączenie sieciowe usługi ExpressRoute nie blokuje żadnego innego dostępu do usługi Microsoft 365. Konfiguracja usługi QoS została opisana w artykule ExpressRoute and QoS in Skype dla firm Online ( Usługa ExpressRoute i QoS w usłudze Skype dla firm Online).
Rozwiązywanie problemów z implementacją
Najpierw należy zapoznać się z krokami opisanymi w tym przewodniku implementacji. Czy zostały pominięte w planie implementacji? Wstecz i uruchom dalsze małe testy sieciowe, jeśli to możliwe, aby zreplikować błąd i debugować go tam.
Określ, które usługi przychodzące lub wychodzące nie powiodły się podczas testowania. Pobierz w szczególności adresy IP i podsieci dla każdej usługi, która uległa awarii. Przejdź do diagramu topologii sieci na papierze i zweryfikuj routing. Sprawdź, gdzie jest anonsowany routing usługi ExpressRoute, przetestuj ten routing podczas awarii, jeśli jest to możliwe ze śladami.
Uruchom narzędzie PSPing ze śledzeniem sieci dla każdego punktu końcowego klienta i oceń źródłowe i docelowe adresy IP, aby sprawdzić, czy są one zgodnie z oczekiwaniami. Uruchom polecenie telnet na dowolnym hoście poczty uwidocznianym na porcie 25 i sprawdź, czy usługa SNAT ukrywa oryginalny źródłowy adres IP, jeśli jest to oczekiwane.
Należy pamiętać, że podczas wdrażania usługi Microsoft 365 z połączeniem usługi ExpressRoute należy upewnić się, że konfiguracja sieci dla usługi ExpressRoute jest optymalnie zaprojektowana, a także zoptymalizowano inne składniki w sieci, takie jak komputery klienckie. Oprócz korzystania z tego przewodnika planowania w celu rozwiązywania problemów z krokami, które mogły zostać pominięte, napisaliśmy również plan rozwiązywania problemów z wydajnością dla platformy Microsoft 365 .
Oto krótki link, którego można użyć do powrotu: https://aka.ms/implementexpressroute365
Tematy pokrewne
Ocena łączności sieciowej na platformie Microsoft 365
Usługa Azure ExpressRoute dla platformy Microsoft 365
Jakość multimediów i wydajność łączności sieciowej w usłudze Skype dla firm Online
Optymalizowanie sieci pod kątem Skype dla firm Online
Usługi ExpressRoute i QoS w usłudze Skype dla firm Online
Przepływ wywołań przy użyciu usługi ExpressRoute
Dostrajanie wydajności platformy Microsoft 365 przy użyciu punktów odniesienia i historii wydajności
Plan rozwiązywania problemów z wydajnością dla platformy Microsoft 365
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla