Udostępnij za pośrednictwem

Traffic Manager — często zadawane pytania

  • Artykuł

Podstawy usługi Traffic Manager

Jakiego adresu IP używa usługa Traffic Manager?

Zgodnie z opisem w artykule Jak działa usługa Traffic Manager, usługa Traffic Manager działa na poziomie systemu nazw domen (DNS). Wysyła odpowiedzi DNS, aby skierować klientów do odpowiedniego punktu końcowego usługi. Następnie klienci łączą się z punktem końcowym usługi bezpośrednio, a nie za pośrednictwem usługi Traffic Manager.

W związku z tym usługa Traffic Manager nie udostępnia punktu końcowego ani adresu IP, z którymi mogą się łączyć klienci. Jeśli chcesz, aby statyczny adres IP usługi był skonfigurowany w usłudze, a nie w usłudze Traffic Manager.

Jakie typy ruchu można kierować przy użyciu usługi Traffic Manager?

Jak wyjaśniono w artykule Jak działa usługa Traffic Manager, punkt końcowy usługi Traffic Manager może być dowolną usługą internetową hostowaną wewnątrz lub poza platformą Azure. W związku z tym usługa Traffic Manager może kierować ruch pochodzący z publicznego Internetu do zestawu punktów końcowych, które również mają połączenie z Internetem. Jeśli masz punkty końcowe, które znajdują się w sieci prywatnej (na przykład wewnętrznej wersji usługi Azure Load Balancer) lub użytkownicy wysyłający żądania DNS z takich sieci wewnętrznych, nie można użyć usługi Traffic Manager do kierowania tego ruchu.

Czy usługa Traffic Manager obsługuje sesje "lepkie"?

Jak wyjaśniono w artykule Jak działa usługa Traffic Manager, usługa Traffic Manager działa na poziomie DNS. Za pomocą odpowiedzi DNS kieruje klientów do odpowiedniego punktu końcowego usługi. Klienci łączą się bezpośrednio z punktem końcowym usługi, a nie za pośrednictwem usługi Traffic Manager. W związku z tym usługa Traffic Manager nie widzi ruchu HTTP między klientem a serwerem.

Ponadto źródłowy adres IP zapytania DNS odebranego przez usługę Traffic Manager należy do cyklicznej usługi DNS, a nie klienta. W związku z tym usługa Traffic Manager nie ma możliwości śledzenia poszczególnych klientów i nie może zaimplementować sesji "lepkich". To ograniczenie jest wspólne dla wszystkich systemów zarządzania ruchem opartych na systemie DNS i nie jest specyficzne dla usługi Traffic Manager.

Dlaczego podczas korzystania z usługi Traffic Manager występuje błąd HTTP?

Jak wyjaśniono w artykule Jak działa usługa Traffic Manager, usługa Traffic Manager działa na poziomie DNS. Za pomocą odpowiedzi DNS kieruje klientów do odpowiedniego punktu końcowego usługi. Następnie klienci łączą się z punktem końcowym usługi bezpośrednio, a nie za pośrednictwem usługi Traffic Manager. Usługa Traffic Manager nie widzi ruchu HTTP między klientem a serwerem. Dlatego wszelkie napotkane błędy protokołu HTTP muszą pochodzić z aplikacji. Aby klient nawiązał połączenie z aplikacją, wszystkie kroki rozpoznawania nazw DNS zostały ukończone. Obejmuje to wszelkie interakcje, które usługa Traffic Manager ma w przepływie ruchu aplikacji.

Dalsze badanie powinno zatem skupić się na aplikacji.

Nagłówek hosta HTTP wysyłany z przeglądarki klienta jest najczęstszym źródłem problemów. Upewnij się, że aplikacja jest skonfigurowana do akceptowania poprawnego nagłówka hosta dla używanej nazwy domeny. W przypadku punktów końcowych korzystających z usługi aplikacja systemu Azure zobacz Konfigurowanie niestandardowej nazwy domeny dla aplikacji internetowej w usłudze aplikacja systemu Azure przy użyciu usługi Traffic Manager.

Jak rozwiązać problem 500 (wewnętrzny błąd serwera) podczas korzystania z usługi Traffic Manager?

Jeśli klient lub aplikacja otrzymuje błąd HTTP 500 podczas korzystania z usługi Traffic Manager, może to być spowodowane nieaktualnym zapytaniem DNS. Aby rozwiązać ten problem, wyczyść pamięć podręczną DNS i zezwól klientowi na wystawienie nowego zapytania DNS.

Gdy punkt końcowy usługi nie odpowiada, klienci i aplikacje korzystające z tego punktu końcowego nie są resetowane, dopóki pamięć podręczna DNS nie zostanie odświeżona. Czas trwania pamięci podręcznej jest określany przez czas wygaśnięcia (TTL) rekordu DNS. Aby uzyskać więcej informacji, zobacz Traffic Manager i pamięć podręczną DNS.

Zobacz również następujące powiązane często zadawane pytania w tym artykule:

Jaki jest wpływ na wydajność korzystania z usługi Traffic Manager?

Jak wyjaśniono w artykule Jak działa usługa Traffic Manager, usługa Traffic Manager działa na poziomie DNS. Ponieważ klienci łączą się bezpośrednio z punktami końcowymi usługi, nie ma żadnego wpływu na wydajność podczas korzystania z usługi Traffic Manager po nawiązaniu połączenia.

Ponieważ usługa Traffic Manager integruje się z aplikacjami na poziomie DNS, wymaga wstawienia dodatkowego wyszukiwania DNS do łańcucha rozpoznawania nazw DNS. Wpływ usługi Traffic Manager na czas rozpoznawania nazw DNS jest minimalny. Usługa Traffic Manager używa globalnej sieci serwerów nazw i używa dowolnej sieci emisji w celu zapewnienia, że zapytania DNS są zawsze kierowane do najbliższego dostępnego serwera nazw. Ponadto buforowanie odpowiedzi DNS oznacza, że dodatkowe opóźnienie DNS poniesione przy użyciu usługi Traffic Manager dotyczy tylko części sesji.

Metoda wydajności kieruje ruch do najbliższego dostępnego punktu końcowego. Wynikiem netto jest to, że ogólny wpływ na wydajność skojarzony z tą metodą powinien być minimalny. Każdy wzrost opóźnienia DNS powinien zostać przesunięty przez mniejsze opóźnienie sieci do punktu końcowego.

Jakich protokołów aplikacji można używać z usługą Traffic Manager?

Jak wyjaśniono w artykule Jak działa usługa Traffic Manager, usługa Traffic Manager działa na poziomie DNS. Po zakończeniu wyszukiwania DNS klienci łączą się bezpośrednio z punktem końcowym aplikacji, a nie za pośrednictwem usługi Traffic Manager. W związku z tym połączenie może używać dowolnego protokołu aplikacji. Jeśli wybierzesz protokół TCP jako protokół monitorowania, monitorowanie kondycji punktu końcowego usługi Traffic Manager można wykonać bez używania żadnych protokołów aplikacji. Jeśli zdecydujesz się zweryfikować kondycję przy użyciu protokołu aplikacji, punkt końcowy musi mieć możliwość odpowiadania na żądania HTTP lub HTTPS GET.

Czy mogę używać usługi Traffic Manager z "nagą" nazwą domeny?

Tak. Aby dowiedzieć się, jak utworzyć rekord aliasu dla wierzchołka nazwy domeny, aby odwołać się do profilu usługi Azure Traffic Manager, zobacz Konfigurowanie rekordu aliasu w celu obsługi nazw domen wierzchołków za pomocą usługi Traffic Manager.

Czy usługa Traffic Manager uwzględnia adres podsieci klienta podczas obsługi zapytań DNS?

Tak. Oprócz źródłowego adresu IP zapytania DNS (zazwyczaj adresu IP programu rozpoznawania nazw DNS), usługa Traffic Manager uwzględnia również adres podsieci klienta, jeśli jest on uwzględniony w zapytaniu DNS wysyłanym przez program rozpoznawania nazw DNS wysyłający żądanie w imieniu użytkownika końcowego. Te adresy IP służą do optymalizowania metod routingu geograficznego, wydajności i podsieci. W szczególności RFC 7871 — podsieć klienta w zapytaniach DNS zapewnia mechanizm rozszerzenia dla systemu DNS (EDNS0) może przekazać adres podsieci klienta z rozpoznawania, które go obsługują.

Co to jest czas wygaśnięcia SYSTEMU DNS i jak ma to wpływ na moich użytkowników?

Gdy zapytanie DNS ląduje w usłudze Traffic Manager, ustawia wartość w odpowiedzi o nazwie time-to-live (TTL). Ta wartość, której jednostka znajduje się w sekundach, wskazuje na podrzędne metody rozpoznawania nazw DNS w zakresie czasu buforowania tej odpowiedzi. Mimo że narzędzia rozpoznawania nazw DNS nie mają gwarancji buforowania tego wyniku, buforowanie umożliwia reagowanie na wszelkie kolejne zapytania poza pamięcią podręczną zamiast przechodzenia do serwerów DNS usługi Traffic Manager. Ma to wpływ na odpowiedzi w następujący sposób:

  • wyższy czas wygaśnięcia zmniejsza liczbę zapytań, które znajdują się na serwerach DNS usługi Traffic Manager, co może zmniejszyć koszt klienta, ponieważ liczba obsługiwanych zapytań jest rozliczanym użyciem.
  • wyższy czas wygaśnięcia może potencjalnie skrócić czas potrzebny na wyszukiwanie DNS.
  • wyższy czas wygaśnięcia oznacza również, że dane nie odzwierciedlają najnowszych informacji o kondycji uzyskanych przez usługę Traffic Manager za pośrednictwem agentów sondowania.

Jak wysoki lub niski mogę ustawić czas wygaśnięcia odpowiedzi usługi Traffic Manager?

Na poziomie profilu można ustawić czas wygaśnięcia dns równy 0 sekund i maksymalnie 2147 483 647 sekund (maksymalny zakres zgodny z RFC-1035). Czas wygaśnięcia 0 oznacza, że podrzędne metody rozpoznawania nazw DNS nie buforują odpowiedzi na zapytania, a wszystkie zapytania mają dotrzeć do serwerów DNS usługi Traffic Manager w celu rozwiązania problemu.

Jak mogę zrozumieć ilość zapytań przychodzących do mojego profilu?

Jedną z metryk udostępnianych przez usługę Traffic Manager jest liczba zapytań udzielonych przez profil. Te informacje można uzyskać na poziomie agregacji na poziomie profilu lub podzielić je dalej, aby zobaczyć liczbę zapytań, w których zostały zwrócone określone punkty końcowe. Ponadto można skonfigurować alerty, aby otrzymywać powiadomienia, jeśli wolumin odpowiedzi zapytania przekroczy ustawione warunki. Aby uzyskać więcej informacji, metryki i alerty usługi Traffic Manager.

Kiedy usuwam profil usługi Traffic Manager, jaki jest czas, po jakim czasie nazwa profilu będzie dostępna do ponownego użycia?

Po usunięciu profilu usługi Traffic Manager skojarzona nazwa domeny jest zarezerwowana przez pewien czas. Inne profile usługi Traffic Manager w tej samej dzierżawie mogą natychmiast ponownie użyć nazwy. Jednak inna dzierżawa platformy Azure nie może używać tej samej nazwy profilu, dopóki rezerwacja nie wygaśnie. Ta funkcja pozwala zachować uprawnienia do wdrożonych przestrzeni nazw, eliminując obawy, że nazwa może zostać podjęta przez inną dzierżawę.

Jeśli na przykład nazwa profilu usługi Traffic Manager ma etykietę 1, label1.trafficmanager.net jest zarezerwowana dla dzierżawy, nawet jeśli usuniesz profil. Podrzędne przestrzenie nazw, takie jak xyz.label1 lub 123.abc.label1 , są również zarezerwowane. Po wygaśnięciu rezerwacji nazwa jest udostępniana innym dzierżawcom. Nazwa skojarzona z wyłączonym profilem jest zarezerwowana na czas nieokreślony. W przypadku pytań dotyczących czasu zarezerwowanego nazwy skontaktuj się z przedstawicielem konta.

Jaka wersja protokołu TLS jest wymagana przez usługę Traffic Manager?

Implementacja starszych wersji protokołu TLS przez firmę Microsoft nie jest znana jako podatna na zagrożenia, jednak protokół TLS 1.2 i nowsze jego wersje oferują lepsze zabezpieczenia dzięki funkcjom, takim jak doskonała tajemnica przesyłania dalej i silniejsze zestawy szyfrowania. Aby zwiększyć bezpieczeństwo i zapewnić najlepsze w swojej klasie szyfrowanie danych, usługa Traffic Manger wymaga interakcji z usługami, które mają być zabezpieczone przy użyciu protokołu Transport Layer Security (TLS) 1.2 lub nowszego przed 28 lutego 2025 r. Obsługa protokołu Traffic Manger dla protokołów TLS 1.0 i 1.1 zakończy się w tej dacie. Ta data może być inna niż data wycofania protokołu TLS 1.0 i TLS 1.1 dla całej platformy Azure.

Zalecana akcja

Aby uniknąć przerw w działaniu usługi, zasoby, które wchodzą w interakcję z usługą Traffic Manager, muszą używać protokołu TLS 1.2 lub nowszego.

  • Jeśli zasoby są już używane wyłącznie przy użyciu protokołu TLS 1.2 lub nowszego, nie musisz podejmować dalszych działań.
  • Jeśli zasoby nadal mają zależność od protokołu TLS 1.0 lub 1.1, należy przenieść je do protokołu TLS 1.2 lub nowszego do 28 lutego 2025 r.

Aby uzyskać informacje na temat migracji z protokołów TLS 1.0 i 1.1 do protokołu TLS 1.2, zobacz Rozwiązywanie problemu z protokołem TLS 1.0.

Metoda routingu ruchu geograficznego usługi Traffic Manager

Jakie są przypadki użycia, w których routing geograficzny jest przydatny?

Typ routingu geograficznego może być używany w dowolnym scenariuszu, w którym klient platformy Azure musi rozróżniać swoich użytkowników na podstawie regionów geograficznych. Na przykład przy użyciu metody routingu ruchu geograficznego można nadać użytkownikom z określonych regionów inne środowisko użytkownika niż w innych regionach. Innym przykładem jest zgodność z lokalnymi mandatami dotyczącymi niezależności danych, które wymagają, aby użytkownicy z określonego regionu mogli obsługiwać tylko punkty końcowe w tym regionie.

Jak mogę zdecydować, czy należy użyć metody routingu wydajności lub metody routingu geograficznego?

Kluczową różnicą między tymi dwoma popularnymi metodami routingu jest to, że w metodzie routingu wydajności głównym celem jest wysłanie ruchu do punktu końcowego, który może zapewnić najmniejsze opóźnienie do wywołującego, podczas gdy w routingu geograficznym głównym celem jest wymuszenie ogrodzenia geograficznego dla osób wywołujących, aby umożliwić celowe kierowanie ich do określonego punktu końcowego. Nakładanie się występuje, ponieważ istnieje korelacja między zbliżeniem geograficznym a mniejszym opóźnieniem, chociaż nie zawsze jest to prawdą. W innej lokalizacji geograficznej może istnieć punkt końcowy, który może zapewnić lepsze opóźnienie dla elementu wywołującego, a w takim przypadku routing wydajności wysyła użytkownika do tego punktu końcowego, ale routing geograficzny zawsze wysyła je do punktu końcowego zamapowanego na ich region geograficzny. Aby jeszcze bardziej wyjaśnić, rozważmy poniższy przykład — przy użyciu routingu geograficznego można tworzyć nietypowe mapowania, takie jak wysyłanie całego ruchu z Azji do punktów końcowych w Stanach Zjednoczonych i cały ruch amerykański do punktów końcowych w Azji. W takim przypadku routing geograficzny celowo wykonuje dokładnie to, co zostało skonfigurowane do wykonania, a optymalizacja wydajności nie jest brana pod uwagę.

Uwaga

Mogą istnieć scenariusze, w których mogą być potrzebne zarówno możliwości wydajności, jak i routingu geograficznego. W przypadku tych scenariuszy zagnieżdżone profile mogą być doskonałym wyborem. Na przykład można skonfigurować profil nadrzędny z routingiem geograficznym, w którym wysyłasz cały ruch z Ameryka Północna do profilu zagnieżdżonego, który ma punkty końcowe w Stanach Zjednoczonych i użyj routingu wydajności, aby wysłać ten ruch do najlepszego punktu końcowego w tym zestawie.

Jakie są regiony obsługiwane przez usługę Traffic Manager na potrzeby routingu geograficznego?

Hierarchia kraju/regionu, która jest używana przez usługę Traffic Manager, można znaleźć tutaj. Chociaż ta strona jest aktualna z wszelkimi zmianami, można również programowo pobrać te same informacje przy użyciu interfejsu API REST usługi Azure Traffic Manager.

W jaki sposób usługa Traffic Manager określa, gdzie użytkownik wykonuje zapytania?

Usługa Traffic Manager analizuje źródłowy adres IP zapytania (najprawdopodobniej jest to lokalny program rozpoznawania nazw DNS wykonujący zapytanie w imieniu użytkownika) i używa wewnętrznego adresu IP do mapowania regionów w celu określenia lokalizacji. Ta mapa jest aktualizowana w sposób ciągły, aby uwzględnić zmiany w Internecie.

Czy gwarantuje to, że usługa Traffic Manager może poprawnie określić dokładną lokalizację geograficzną użytkownika w każdym przypadku?

Nie, usługa Traffic Manager nie może zagwarantować, że region geograficzny, który wywnioskujemy ze źródłowego adresu IP zapytania DNS, zawsze odpowiada lokalizacji użytkownika z następujących powodów:

  • Najpierw, jak opisano w poprzednich często zadawanych pytaniach, źródłowy adres IP jest tym, że rozpoznawanie nazw DNS wykonuje wyszukiwanie w imieniu użytkownika. Chociaż lokalizacja geograficzna rozpoznawania nazw DNS jest dobrym serwerem proxy dla lokalizacji geograficznej użytkownika, może być również różna w zależności od śladu usługi rozpoznawania nazw DNS i określonej usługi rozpoznawania nazw DNS wybranej przez klienta do użycia. Na przykład klient znajdujący się w Malezji może określić w ustawieniach urządzenia użycie usługi rozpoznawania nazw DNS, której serwer DNS w Singapurze może zostać wybrany do obsługi rozwiązań zapytań dla tego użytkownika/urządzenia. W takim przypadku usługa Traffic Manager może zobaczyć tylko adres IP programu resolver, który odpowiada lokalizacji Singapuru. Zobacz również wcześniejsze często zadawane pytania dotyczące obsługi adresów podsieci klienta na tej stronie.

  • Po drugie usługa Traffic Manager używa wewnętrznej mapy do wykonania adresu IP do tłumaczenia regionów geograficznych. Chociaż ta mapa jest weryfikowana i aktualizowana na bieżąco w celu zwiększenia dokładności i uwzględnienia zmieniającego się charakteru Internetu, nadal istnieje możliwość, że nasze informacje nie są dokładną reprezentacją lokalizacji geograficznej wszystkich adresów IP.

Czy punkt końcowy musi znajdować się fizycznie w tym samym regionie co punkt końcowy skonfigurowany na potrzeby routingu geograficznego?

Nie, lokalizacja punktu końcowego nie nakłada żadnych ograniczeń dotyczących regionów, które można do niego mapować. Na przykład punkt końcowy w regionie świadczenia usługi Azure Środkowe stany USA może mieć wszystkich użytkowników z Indii skierowanych do niego.

Czy mogę przypisać regiony geograficzne do punktów końcowych w profilu, który nie jest skonfigurowany do routingu geograficznego?

Tak, jeśli metoda routingu profilu nie jest geograficzna, możesz użyć interfejsu API REST usługi Azure Traffic Manager, aby przypisać regiony geograficzne do punktów końcowych w tym profilu. W przypadku profilów typów routingu nie geograficznego ta konfiguracja jest ignorowana. Jeśli później zmienisz taki profil na typ routingu geograficznego, usługa Traffic Manager będzie mogła używać tych mapowań.

Dlaczego występuje błąd podczas próby zmiany metody routingu istniejącego profilu na Geographic?

Wszystkie punkty końcowe w profilu z routingiem geograficznym muszą mieć mapowany co najmniej jeden region. Aby przekonwertować istniejący profil na typ routingu geograficznego, należy najpierw skojarzyć regiony geograficzne ze wszystkimi punktami końcowymi przy użyciu interfejsu API REST usługi Azure Traffic Manager przed zmianą typu routingu na geograficzny. Jeśli używasz portalu, najpierw usuń punkty końcowe, zmień metodę routingu profilu na geograficzną, a następnie dodaj punkty końcowe wraz z mapowaniem regionów geograficznych.

Region można przypisać tylko do jednego punktu końcowego w profilu, jeśli używa metody routingu geograficznego. Jeśli ten punkt końcowy nie jest typem zagnieżdżonym z dołączonym profilem podrzędnym, jeśli ten punkt końcowy będzie w złej kondycji, usługa Traffic Manager będzie nadal wysyłać do niego ruch, ponieważ alternatywa nie wysyła żadnego ruchu nie jest lepsza. Usługa Traffic Manager nie przechodzi w tryb failover do innego punktu końcowego, nawet jeśli przypisany region jest "nadrzędny" regionu przypisanego do punktu końcowego, który poszedł w złej kondycji (na przykład jeśli punkt końcowy z regionem Hiszpania przejdzie w złej kondycji, nie przejdziemy w tryb failover do innego punktu końcowego, do którego przypisano region Europa). Jest to wykonywane w celu zapewnienia, że usługa Traffic Manager przestrzega granic geograficznych skonfigurowanych przez klienta w swoim profilu. Aby uzyskać korzyści wynikające z przechodzenia w tryb failover do innego punktu końcowego, gdy punkt końcowy przejdzie w złej kondycji, zaleca się przypisanie regionów geograficznych do profilów zagnieżdżonych z wieloma punktami końcowymi zamiast poszczególnych punktów końcowych. W ten sposób, jeśli punkt końcowy w zagnieżdżonym profilu podrzędnym zakończy się niepowodzeniem, ruch może przejść w tryb failover do innego punktu końcowego w tym samym zagnieżdżonym profilu podrzędnym.

Czy istnieją ograniczenia dotyczące wersji interfejsu API obsługującej ten typ routingu?

Tak, tylko interfejs API w wersji 2017-03-01 i nowszej obsługuje typ routingu geograficznego. Nie można używać starszych wersji interfejsu API do tworzenia profilów typu routingu geograficznego ani przypisywania regionów geograficznych do punktów końcowych. Jeśli starsza wersja interfejsu API jest używana do pobierania profilów z subskrypcji platformy Azure, żaden profil typu routingu geograficznego nie jest zwracany. Ponadto w przypadku korzystania ze starszych wersji interfejsu API każdy profil zwrócony z punktami końcowymi z przypisaniem regionu geograficznego nie ma pokazanego przypisania regionu geograficznego.

Metoda routingu ruchu podsieci usługi Traffic Manager

Jakie są przypadki użycia, w których przydatny jest routing podsieci?

Routing podsieci umożliwia odróżnienie środowiska dostarczanego dla określonych zestawów użytkowników zidentyfikowanych przez źródłowy adres IP żądań DNS. Przykładem może być wyświetlanie innej zawartości, jeśli użytkownicy łączą się z witryną internetową z firmowej siedziby firmy. Innym rozwiązaniem byłoby ograniczenie użytkowników z niektórych dostawców usług internetowych do uzyskiwania dostępu tylko do punktów końcowych, które obsługują tylko połączenia IPv4, jeśli ci dostawcy usług internetowych mają wydajność podrzędną w przypadku użycia protokołu IPv6.

Innym powodem użycia metody routingu podsieci jest połączenie z innymi profilami w zagnieżdżonym zestawie profilów. Jeśli na przykład chcesz użyć metody routingu geograficznego dla użytkowników geograficznych, ale dla określonego usługodawcy isp chcesz wykonać inną metodę routingu, możesz mieć profil z metodą routingu podsieci subnet jako profil nadrzędny i przesłonić, że usługodawca internetowym używa określonego profilu podrzędnego i ma standardowy profil geograficzny dla wszystkich innych.

Uwaga

Usługa Azure Traffic Manager obsługuje adresy IPv6 w przesłonięciach podsieci dla profilów podsieci. Ta funkcja umożliwia bardziej szczegółową kontrolę nad routingiem ruchu na podstawie źródłowego adresu IP zapytań DNS, w tym adresów IPv4 i IPv6.

W jaki sposób usługa Traffic Manager zna adres IP użytkownika końcowego?

Urządzenia użytkowników końcowych zazwyczaj używają rozpoznawania nazw DNS do wyszukiwania DNS w ich imieniu. Wychodzący adres IP takich rozpoznawania nazw jest tym, co usługa Traffic Manager widzi jako źródłowy adres IP. Ponadto metoda routingu podsieci sprawdza również, czy istnieją informacje o rozszerzonej podsieci klienta (ECS) EDNS0, które zostały przekazane wraz z żądaniem. Jeśli są obecne informacje usługi ECS, jest to adres używany do określania routingu. W przypadku braku informacji usługi ECS źródłowy adres IP zapytania jest używany do celów routingu.

Jak określić adresy IP podczas korzystania z routingu podsieci?

Adresy IP do skojarzenia z punktem końcowym można określić na dwa sposoby. Najpierw można użyć czterokątnej notacji dziesiętnej dziesiętnej z adresami początkowymi i końcowymi, aby określić zakres (na przykład 1.2.3.4-5.6.7.8 lub 3.4.5.6-3.4.5.6). Po drugie, możesz użyć notacji CIDR, aby określić zakres (na przykład 1.2.3.0/24). Można określić wiele zakresów i użyć obu typów notacji w zestawie zakresów. Zastosowanie ma kilka ograniczeń.

  • Nie można nakładać się zakresów adresów, ponieważ każdy adres IP musi być mapowany tylko na jeden punkt końcowy
  • Adres początkowy nie może być większy niż adres końcowy
  • W przypadku notacji CIDR adres IP przed "/" powinien być adresem sieciowym tego zakresu (na przykład 1.2.3.0/24 jest prawidłowy, ale 1.2.3.4.4/24 jest nieprawidłowy)

Jak określić rezerwowy punkt końcowy podczas korzystania z routingu podsieci?

W profilu z routingiem podsieci, jeśli masz punkt końcowy bez zamapowanych podsieci, każde żądanie, które nie jest zgodne z innymi punktami końcowymi, są kierowane do tego miejsca. Zdecydowanie zaleca się posiadanie takiego rezerwowego punktu końcowego w profilu, ponieważ usługa Traffic Manager zwraca odpowiedź NXDOMAIN, jeśli żądanie jest przychodzące i nie jest mapowane na żadne punkty końcowe lub jeśli jest mapowany na punkt końcowy, ale ten punkt końcowy jest w złej kondycji.

Co się stanie, jeśli punkt końcowy jest wyłączony w profilu typu routingu podsieci?

Jeśli masz punkt końcowy z wyłączonym profilem z routingiem podsieci, usługa Traffic Manager zachowuje się tak, jakby ten punkt końcowy i mapowania podsieci nie istniały. Jeśli zostanie odebrane zapytanie zgodne z mapowaniem adresu IP, a punkt końcowy jest wyłączony, usługa Traffic Manager zwraca rezerwowy punkt końcowy (jeden bez mapowań) lub jeśli taki punkt końcowy nie jest obecny, zwraca odpowiedź NXDOMAIN.

Metoda routingu ruchu MultiValue usługi Traffic Manager

Jakie są przypadki użycia, w których przydatny jest routing MultiValue?

Routing MultiValue zwraca wiele punktów końcowych w dobrej kondycji w jednej odpowiedzi na zapytanie. Główną zaletą jest to, że jeśli punkt końcowy jest w złej kondycji, klient ma więcej opcji ponawiania próby bez wykonywania innego wywołania DNS (co może zwrócić tę samą wartość z nadrzędnej pamięci podręcznej). Dotyczy to aplikacji wrażliwych na dostępność, które chcą zminimalizować przestoje. Innym zastosowaniem metody routingu MultiValue jest to, czy punkt końcowy jest "podwójny" do adresów IPv4 i IPv6 i chcesz nadać obiekt wywołujący obie opcje do wyboru, gdy inicjuje połączenie z punktem końcowym.

Ile punktów końcowych jest zwracanych, gdy jest używany routing MultiValue?

Można określić maksymalną liczbę punktów końcowych, które mają być zwracane, a funkcja MultiValue zwraca nie więcej niż wiele punktów końcowych w dobrej kondycji po odebraniu zapytania. Maksymalna możliwa wartość dla tej konfiguracji to 10.

Czy po użyciu routingu MultiValue otrzymam ten sam zestaw punktów końcowych?

Nie możemy zagwarantować, że w każdym zapytaniu zwracany jest ten sam zestaw punktów końcowych. Ma to również wpływ na fakt, że niektóre punkty końcowe mogą pójść w złej kondycji, w którym momencie nie zostaną uwzględnione w odpowiedzi

Pomiary rzeczywistego użytkownika

Jakie są zalety korzystania z pomiarów rzeczywistego użytkownika?

W przypadku korzystania z metody routingu wydajności usługa Traffic Manager wybiera najlepszy region świadczenia usługi Azure, z którym użytkownik końcowy ma nawiązać połączenie, sprawdzając źródłowy adres IP i podsieć klienta EDNS (jeśli została przekazana) i sprawdzając go względem analizy opóźnień sieci, z którą utrzymuje usługa. Pomiary rzeczywistego użytkownika zwiększają to w przypadku bazy użytkowników końcowych, ponieważ środowisko współtworzy tę tabelę opóźnień oprócz zapewnienia, że ta tabela odpowiednio obejmuje sieci użytkowników końcowych, z których użytkownicy końcowi łączą się z platformą Azure. Prowadzi to do zwiększenia dokładności routingu użytkownika końcowego.

Czy mogę używać pomiarów rzeczywistego użytkownika z regionami spoza platformy Azure?

Miary rzeczywistego użytkownika i raporty dotyczące tylko opóźnień w celu dotarcia do regionów platformy Azure. Jeśli używasz routingu opartego na wydajności z punktami końcowymi hostowanymi w regionach spoza platformy Azure, nadal możesz korzystać z tej funkcji, zapewniając większe opóźnienie informacji o reprezentatywnym regionie świadczenia usługi Azure, który został wybrany do skojarzenia z tym punktem końcowym.

Która metoda routingu korzysta z pomiarów rzeczywistego użytkownika?

Dodatkowe informacje uzyskane za pomocą pomiarów rzeczywistego użytkownika mają zastosowanie tylko dla profilów korzystających z metody routingu wydajności. Link Pomiary rzeczywistego użytkownika jest dostępny we wszystkich profilach podczas wyświetlania go w witrynie Azure Portal.

Czy muszę włączyć pomiary rzeczywistego użytkownika osobno dla każdego profilu?

Nie, wystarczy włączyć ją raz na subskrypcję, a wszystkie informacje o opóźnieniu mierzone i zgłaszane są dostępne dla wszystkich profilów.

Jak mogę wyłączyć pomiary rzeczywistego użytkownika dla mojej subskrypcji?

Opłaty związane z pomiarami rzeczywistego użytkownika można zatrzymać podczas zbierania i wysyłania pomiarów opóźnienia zwrotnego z aplikacji klienckiej. Na przykład w przypadku pomiaru języka JavaScript osadzonego na stronach internetowych można przestać używać tej funkcji, usuwając kod JavaScript lub wyłączając wywołanie podczas renderowania strony.

Możesz również wyłączyć pomiary rzeczywistego użytkownika, usuwając klucz. Po usunięciu klucza wszystkie miary wysyłane do usługi Traffic Manager z tym kluczem zostaną odrzucone.

Czy można używać pomiarów rzeczywistego użytkownika z aplikacjami klienckimi innymi niż strony internetowe?

Tak, pomiary rzeczywistego użytkownika są przeznaczone do pozyskiwania danych zbieranych za pośrednictwem różnych typów klientów użytkowników końcowych. Te często zadawane pytania są aktualizowane w miarę obsługi nowych typów aplikacji klienckich.

Ile pomiarów jest wykonanych za każdym razem, gdy strona internetowa z włączoną obsługą pomiarów rzeczywistego użytkownika jest renderowana?

Gdy miary rzeczywistego użytkownika są używane z podanym pomiarem w języku JavaScript, każda strona renderuje wyniki sześciu pomiarów. Są one następnie zgłaszane z powrotem do usługi Traffic Manager. Opłata za tę funkcję jest naliczana na podstawie liczby pomiarów zgłoszonych w usłudze Traffic Manager. Jeśli na przykład użytkownik odchodzi od strony internetowej, gdy pomiary są wykonywane, ale przed jego zgłoszeniem, te pomiary nie są brane pod uwagę do celów rozliczeniowych.

Czy istnieje opóźnienie przed uruchomieniem skryptu Pomiary rzeczywistego użytkownika na mojej stronie internetowej?

Nie, nie ma zaprogramowanego opóźnienia przed wywołaniem skryptu.

Czy mogę używać pomiarów rzeczywistego użytkownika tylko w regionach świadczenia usługi Azure, które chcę zmierzyć?

Nie, za każdym razem, gdy jest wywoływany, skrypt Pomiary rzeczywistego użytkownika mierzy zestaw sześciu regionów platformy Azure określonych przez usługę. Ten zestaw zmienia się między różnymi wywołaniami i w przypadku wystąpienia dużej liczby takich wywołań pokrycie pomiarów obejmuje różne regiony świadczenia usługi Azure.

Czy mogę ograniczyć liczbę pomiarów wykonanych do określonej liczby?

Kod JavaScript pomiaru jest osadzony na stronie internetowej i masz pełną kontrolę nad tym, kiedy zacząć i przestać z niej korzystać. Jeśli usługa Traffic Manager otrzyma żądanie zmierzenia listy regionów świadczenia usługi Azure, zwracany jest zestaw regionów.

Czy mogę zobaczyć pomiary wykonywane przez moją aplikację kliencą w ramach pomiarów rzeczywistego użytkownika?

Ponieważ logika pomiaru jest uruchamiana z aplikacji klienckiej, masz pełną kontrolę nad tym, co się stanie, w tym zobaczysz pomiary opóźnień. Usługa Traffic Manager nie zgłasza zagregowanego widoku pomiarów odebranych w kluczu połączonym z subskrypcją.

Czy mogę zmodyfikować skrypt pomiaru dostarczony przez usługę Traffic Manager?

Chociaż masz kontrolę nad tym, co jest osadzone na stronie internetowej, zdecydowanie odradzamy wprowadzanie jakichkolwiek zmian w skrycie pomiaru, aby upewnić się, że mierzy i raportuje opóźnienia prawidłowo.

Czy będzie możliwe, aby inne osoby widziały klucz używany z pomiarami rzeczywistego użytkownika?

Po osadzeniu skryptu pomiaru na stronie internetowej można zobaczyć skrypt i klucz Pomiary rzeczywistego użytkownika (RUM). Ważne jest jednak, aby wiedzieć, że ten klucz różni się od identyfikatora subskrypcji i jest generowany przez usługę Traffic Manager do użycia tylko w tym celu. Znajomość klucza RUM nie spowoduje naruszenia bezpieczeństwa konta platformy Azure.

Czy inni mogą nadużywać mojego klucza RUM?

Chociaż istnieje możliwość, aby inne osoby używały twojego klucza do wysyłania nieprawidłowych informacji na platformę Azure, kilka nieprawidłowych pomiarów nie zmieni routingu, ponieważ jest brane pod uwagę wraz ze wszystkimi innymi otrzymanymi pomiarami. Jeśli musisz zmienić klucze, możesz ponownie wygenerować klucz, w którym stary klucz zostanie odrzucony.

Czy muszę umieścić miarę w języku JavaScript na wszystkich stronach sieci Web?

Pomiary rzeczywistego użytkownika zapewniają większą wartość w miarę wzrostu liczby pomiarów. Mówiąc to, to twoja decyzja, czy trzeba umieścić ją na wszystkich stronach internetowych, czy kilka. Naszym zaleceniem jest umieszczenie go na najczęściej odwiedzanej stronie, na której oczekuje się, że użytkownik pozostanie na tej stronie pięć sekund lub więcej.

Czy informacje o użytkownikach końcowych mogą być identyfikowane przez usługę Traffic Manager, jeśli używam pomiarów rzeczywistego użytkownika?

Gdy jest używany podany kod JavaScript pomiaru, usługa Traffic Manager ma wgląd w adres IP klienta użytkownika końcowego i źródłowy adres IP lokalnego rozpoznawania nazw DNS, którego używają. Usługa Traffic Manager używa adresu IP klienta dopiero po obcięciu, aby nie można było zidentyfikować konkretnego użytkownika końcowego, który wysłał pomiary.

Czy strona internetowa mierząca rzeczywiste pomiary użytkowników musi używać usługi Traffic Manager do routingu?

Nie, nie musi używać usługi Traffic Manager. Strona routingu usługi Traffic Manager działa oddzielnie od części Pomiar rzeczywistego użytkownika i chociaż jest to doskonały pomysł, aby mieć je zarówno w tej samej właściwości internetowej, jak i nie muszą być.

Czy muszę hostować dowolną usługę w regionach platformy Azure do użycia z pomiarami rzeczywistego użytkownika?

Nie, nie musisz hostować żadnego składnika po stronie serwera na platformie Azure, aby pomiary rzeczywistego użytkownika działały. Obraz z jednym pikselem pobrany przez kod JavaScript miary i usługę uruchomioną w różnych regionach platformy Azure są hostowane i zarządzane przez platformę Azure.

Czy użycie przepustowości platformy Azure zwiększy się podczas korzystania z pomiarów rzeczywistego użytkownika?

Jak wspomniano w poprzedniej odpowiedzi, składniki po stronie serwera pomiarów rzeczywistego użytkownika są własnością platformy Azure i zarządzane przez platformę Azure. Oznacza to, że użycie przepustowości platformy Azure nie zwiększy się, ponieważ używasz pomiarów rzeczywistego użytkownika. Nie obejmuje to żadnego użycia przepustowości poza opłatami za platformę Azure. Minimalizujemy przepustowość używaną przez pobranie tylko pojedynczego obrazu pikseli w celu pomiaru opóźnienia w regionie świadczenia usługi Azure.

Widok ruchu

Co robi widok ruchu?

Traffic View to funkcja usługi Traffic Manager, która pomaga zrozumieć więcej informacji o użytkownikach i sposobie ich doświadczenia. Używa ona zapytań odebranych przez usługę Traffic Manager i tabele analizy opóźnień sieci, które są obsługiwane przez usługę w celu zapewnienia następujących elementów:

  • Regiony, w których znajdują się użytkownicy łączący się z punktami końcowymi na platformie Azure.
  • Liczba użytkowników łączących się z tych regionów.
  • Regiony platformy Azure, do których są kierowane.
  • Środowisko opóźnienia użytkowników dotyczące routingu do tych regionów platformy Azure.

Te informacje są dostępne do użytku za pośrednictwem nakładki mapy geograficznej i widoków tabelarycznych w portalu, a także są dostępne jako nieprzetworzone dane do pobrania.

Jak korzystać z widoku ruchu?

Widok ruchu zapewnia ogólny widok ruchu odbieranego przez profile usługi Traffic Manager. W szczególności można go użyć do zrozumienia, gdzie baza użytkowników łączy się z i równie ważne, jakie jest ich średnie opóźnienie. Następnie możesz użyć tych informacji, aby znaleźć obszary, w których należy skupić się, na przykład przez rozszerzenie obszaru świadczenia usługi Azure do regionu, który może obsłużyć tych użytkowników z mniejszym opóźnieniem. Inną analizą, z której można korzystać przy użyciu widoku ruchu, jest wyświetlenie wzorców ruchu do różnych regionów, co z kolei może pomóc w podejmowaniu decyzji dotyczących zwiększania lub zmniejszania wymyślenia w tych regionach.

W jaki sposób widok ruchu różni się od metryk usługi Traffic Manager dostępnych za pośrednictwem usługi Azure Monitor?

Usługa Azure Monitor może służyć do zrozumienia na poziomie agregacji ruchu odebranego przez profil i jego punkty końcowe. Umożliwia również śledzenie stanu kondycji punktów końcowych przez uwidacznianie wyników sprawdzania kondycji. Jeśli musisz przejść poza te elementy i zrozumieć środowisko użytkownika końcowego łączące się z platformą Azure na poziomie regionalnym, widok ruchu może służyć do osiągnięcia tego celu.

Czy widok ruchu używa informacji o podsieci klienta EDNS?

Zapytania DNS obsługiwane przez usługę Azure Traffic Manager uwzględniają informacje usługi ECS w celu zwiększenia dokładności routingu. Jednak podczas tworzenia zestawu danych, który pokazuje, gdzie użytkownicy nawiązują połączenie, widok ruchu używa tylko adresu IP programu rozpoznawania nazw DNS.

Ile dni danych używa widok ruchu?

Widok ruchu tworzy dane wyjściowe, przetwarzając dane z siedmiu dni poprzedzających dzień przed wyświetleniem danych. Jest to okno ruchome, a najnowsze dane są używane za każdym razem, gdy odwiedzasz.

Jak widok ruchu obsługuje zewnętrzne punkty końcowe?

Jeśli używasz zewnętrznych punktów końcowych hostowanych poza regionami świadczenia usługi Azure w profilu usługi Traffic Manager, możesz wybrać mapowanie ich na region platformy Azure, który jest serwerem proxy dla swoich właściwości opóźnienia (jest to w rzeczywistości konieczne, jeśli używasz metody routingu wydajności). Jeśli ma to mapowanie regionów platformy Azure, metryki opóźnienia regionu platformy Azure są używane podczas tworzenia danych wyjściowych widoku ruchu. Jeśli nie określono żadnego regionu świadczenia usługi Azure, informacje o opóźnieniu są puste w danych dla tych zewnętrznych punktów końcowych.

Czy muszę włączyć widok ruchu dla każdego profilu w mojej subskrypcji?

W okresie obowiązywania wersji zapoznawczej widok ruchu został włączony na poziomie subskrypcji. W ramach ulepszeń wprowadzonych przed ogólną dostępnością można teraz włączyć widok ruchu na poziomie profilu, co pozwala na bardziej szczegółowe włączanie tej funkcji. Domyślnie widok ruchu jest wyłączony dla profilu.

Uwaga

Jeśli widok ruchu został włączony na poziomie subskrypcji w czasie obowiązywania wersji zapoznawczej, musisz teraz ponownie włączyć go dla każdego profilu w ramach tej subskrypcji.

Jak wyłączyć widok ruchu?

Widok ruchu można wyłączyć dla dowolnego profilu przy użyciu portalu lub interfejsu API REST.

Jak działa rozliczenia w widoku ruchu?

Cennik widoku ruchu jest oparty na liczbie punktów danych używanych do utworzenia danych wyjściowych. Obecnie jedynym obsługiwanym typem danych są zapytania odbierane przez profil. Ponadto opłaty są naliczane tylko za przetwarzanie, które zostało wykonane po włączeniu widoku ruchu. Oznacza to, że jeśli włączysz widok ruchu przez jakiś czas w danym miesiącu i wyłączysz go w innych godzinach, tylko punkty danych przetworzone, gdy włączono funkcję wliczania do rachunku.

Punkty końcowe usługi Traffic Manager

Czy mogę używać usługi Traffic Manager z punktami końcowymi z wielu subskrypcji?

Korzystanie z punktów końcowych z wielu subskrypcji nie jest możliwe w przypadku usługi Azure Web Apps. Usługa Azure Web Apps wymaga, aby dowolna niestandardowa nazwa domeny używana w usłudze Web Apps była używana tylko w ramach jednej subskrypcji. Nie można używać usługi Web Apps z wielu subskrypcji o tej samej nazwie domeny.

W przypadku innych typów punktów końcowych można używać usługi Traffic Manager z punktami końcowymi z więcej niż jednej subskrypcji. W usłudze Resource Manager punkty końcowe z dowolnej subskrypcji można dodać do usługi Traffic Manager, o ile osoba konfigurująca profil usługi Traffic Manager ma dostęp do odczytu do punktu końcowego. Te uprawnienia można przyznać przy użyciu kontroli dostępu opartej na rolach platformy Azure (rola RBAC platformy Azure). Punkty końcowe z innych subskrypcji można dodawać przy użyciu programu Azure PowerShell lub interfejsu wiersza polecenia platformy Azure.

Czy mogę używać usługi Traffic Manager z miejscami przejściowymi usługi w chmurze?

Tak. Miejsca przejściowe usługi w chmurze można skonfigurować w usłudze Traffic Manager jako zewnętrzne punkty końcowe. Testy kondycji są nadal naliczane według stawki punktów końcowych platformy Azure.

Czy usługa Traffic Manager obsługuje punkty końcowe IPv6?

Usługa Traffic Manager nie udostępnia obecnie serwerów nazw adresowych IPv6. Jednak usługa Traffic Manager może być nadal używana przez klientów IPv6 łączących się z punktami końcowymi IPv6, jeśli rekursywny serwer DNS klienta obsługuje protokół IPv4. Klient nie wysyła żądania DNS bezpośrednio do usługi Traffic Manager. Zamiast tego klient używa cyklicznej usługi DNS. Klient korzystający tylko z protokołu IPv6 wysyła żądania do cyklicznej usługi DNS za pośrednictwem protokołu IPv6. Usługa rekursywna musi następnie mieć możliwość skontaktowania się z serwerami nazw usługi Traffic Manager przy użyciu protokołu IPv4. Usługa Traffic Manager odpowiada za pomocą nazwy DNS lub adresu IP punktu końcowego.

Czy mogę używać usługi Traffic Manager z więcej niż jedną aplikacją internetową w tym samym regionie?

Zazwyczaj usługa Traffic Manager służy do kierowania ruchu do aplikacji wdrożonych w różnych regionach. Można go jednak również użyć, gdy aplikacja ma więcej niż jedno wdrożenie w tym samym regionie. Punkty końcowe platformy Azure usługi Traffic Manager nie zezwalają na dodanie więcej niż jednego punktu końcowego aplikacji internetowej z tego samego regionu świadczenia usługi Azure do tego samego profilu usługi Traffic Manager.

Jak mogę przenieść punkty końcowe platformy Azure profilu usługi Traffic Manager do innej grupy zasobów lub subskrypcji?

Punkty końcowe platformy Azure skojarzone z profilem usługi Traffic Manager są śledzone przy użyciu ich identyfikatorów zasobów. Gdy zasób platformy Azure używany jako punkt końcowy (na przykład publiczny adres IP, klasyczna usługa w chmurze, aplikacja internetowa lub inny profil usługi Traffic Manager używany w sposób zagnieżdżony) zostanie przeniesiony do innej grupy zasobów lub subskrypcji, zmienia się jego identyfikator zasobu. W tym scenariuszu należy obecnie zaktualizować profil usługi Traffic Manager, usuwając najpierw, a następnie dodając z powrotem punkty końcowe do profilu.

Aby uzyskać więcej informacji, zobacz Aby przenieść punkt końcowy.

Czy usługa Azure Traffic Manager obsługuje mechanizmy rozszerzeń IPv6 dla usługi DNS (ECS)?

Usługa Azure Traffic Manager obsługuje adresy IPv6 z mechanizmami rozszerzeń dla usługi DNS (ECS). Oznacza to, że gdy zapytanie DNS zawiera informacje USŁUGI ECS, usługa Azure Traffic Manager może używać źródłowego adresu IP w usłudze ECS do podejmowania inteligentnych decyzji dotyczących routingu.

Obsługa protokołu IPv6 ECS ma kilka zalet:

  • Ulepszona lokalizacja: biorąc pod uwagę adres IPv6 w usłudze ECS, usługa Traffic Manager może kierować użytkowników do najbliższego lub najbardziej odpowiedniego punktu końcowego, zwiększając środowisko użytkownika z ograniczonym opóźnieniem.
  • Ulepszona kontrola ruchu: usługa IPv6 ECS umożliwia bardziej szczegółowe decyzje dotyczące routingu ruchu, co umożliwia lepsze zarządzanie globalnym ruchem i dystrybucją.

W przypadku korzystania z usługi ECS IPv6 należy upewnić się, że punkty końcowe są prawidłowo skonfigurowane do obsługi ruchu IPv6. Sprawdź również, czy infrastruktura DNS, w tym rekursywne metody rozpoznawania nazw, może obsługiwać informacje usługi ECS przy użyciu adresów IPv6.

Monitorowanie punktu końcowego usługi Traffic Manager

Czy usługa Traffic Manager jest odporna na błędy regionów świadczenia usługi Azure?

Traffic Manager to kluczowy składnik dostarczania aplikacji o wysokiej dostępności na platformie Azure. Aby zapewnić wysoką dostępność, usługa Traffic Manager musi mieć wyjątkowo wysoki poziom dostępności i być odporna na awarie regionalne.

Zgodnie z projektem składniki usługi Traffic Manager są odporne na całkowitą awarię dowolnego regionu świadczenia usługi Azure. Ta odporność dotyczy wszystkich składników usługi Traffic Manager: serwerów nazw DNS, interfejsu API, warstwy magazynu i usługi monitorowania punktu końcowego.

W mało prawdopodobnym przypadku awarii całego regionu świadczenia usługi Azure oczekuje się, że usługa Traffic Manager będzie nadal działać normalnie. Aplikacje wdrożone w wielu regionach platformy Azure mogą polegać na usłudze Traffic Manager w celu kierowania ruchu do dostępnego wystąpienia aplikacji.

W jaki sposób wybór lokalizacji grupy zasobów wpływa na usługę Traffic Manager?

Traffic Manager to pojedyncza, globalna usługa. Nie jest to region. Wybór lokalizacji grupy zasobów nie ma znaczenia dla profilów usługi Traffic Manager wdrożonych w tej grupie zasobów.

Usługa Azure Resource Manager wymaga, aby wszystkie grupy zasobów określiły lokalizację, która określa domyślną lokalizację zasobów wdrożonych w tej grupie zasobów. Podczas tworzenia profilu usługi Traffic Manager jest on tworzony w grupie zasobów. Wszystkie profile usługi Traffic Manager używają wartości globalnej jako ich lokalizacji, przesłaniając domyślną grupę zasobów.

Jak mogę określić bieżącą kondycję każdego punktu końcowego?

Bieżący stan monitorowania każdego punktu końcowego, oprócz ogólnego profilu, jest wyświetlany w witrynie Azure Portal. Te informacje są również dostępne za pośrednictwem interfejsu API REST usługi Traffic Monitor, poleceń cmdlet programu PowerShell i międzyplatformowego interfejsu wiersza polecenia platformy Azure.

Możesz również użyć usługi Azure Monitor do śledzenia kondycji punktów końcowych i zobaczyć ich wizualną reprezentację. Aby uzyskać więcej informacji na temat korzystania z usługi Azure Monitor, zobacz dokumentację monitorowania platformy Azure.

Czy mogę monitorować punkty końcowe HTTPS?

Tak. Usługa Traffic Manager obsługuje sondowanie za pośrednictwem protokołu HTTPS. Skonfiguruj protokół HTTPS jako protokół w konfiguracji monitorowania.

Usługa Traffic Manager nie może podać żadnej weryfikacji certyfikatu, w tym:

  • Certyfikaty po stronie serwera nie są weryfikowane
  • Certyfikaty po stronie serwera SNI nie są weryfikowane
  • Certyfikaty klienta nie są obsługiwane

Czy używam adresu IP lub nazwy DNS podczas dodawania punktu końcowego?

Usługa Traffic Manager obsługuje dodawanie punktów końcowych przy użyciu trzech sposobów odwoływania się do nich:

  • Jako nazwa DNS
  • Jako adres IPv4
  • Jako adres IPv6

Jeśli punkt końcowy zostanie dodany jako adres IPv4 lub IPv6, odpowiedź zapytania ma odpowiednio typ rekordu A lub AAAA. Jeśli punkt końcowy został dodany jako nazwa DNS, odpowiedź zapytania jest typu rekordu CNAME. Dodawanie punktów końcowych jako adresu IPv4 lub IPv6 jest dozwolone tylko wtedy, gdy punkt końcowy ma typ External.

Wszystkie metody routingu i ustawienia monitorowania są obsługiwane przez trzy typy adresowania punktów końcowych.

Jakiego typu adresy IP można używać podczas dodawania punktu końcowego?

Usługa Traffic Manager umożliwia określanie punktów końcowych przy użyciu adresów IPv4 lub IPv6. Poniżej wymieniono kilka ograniczeń:

  • Adresy odpowiadające zastrzeżonym prywatnym przestrzeniom adresów IP nie są dozwolone. Te adresy obejmują te wymienione w RFC 1918, RFC 6890, RFC 5737, RFC 3068, RFC 2544 i RFC 5771.
  • Adres IP nie może zawierać żadnych numerów portów (można określić porty, które mają być używane w ustawieniach konfiguracji profilu).
  • Żadne dwa punkty końcowe w tym samym profilu nie mogą mieć tego samego docelowego adresu IP.

Czy mogę używać różnych typów adresowania punktów końcowych w ramach jednego profilu?

L.p. Usługa Traffic Manager nie zezwala na mieszanie typów adresów punktów końcowych w profilu, z wyjątkiem przypadku profilu z typem routingu MultiValue, w którym można mieszać typy adresowania IPv4 i IPv6.

Co się stanie, gdy typ rekordu zapytania przychodzącego różni się od typu rekordu skojarzonego z typem adresowania punktów końcowych?

Po odebraniu zapytania względem profilu usługa Traffic Manager najpierw znajduje punkt końcowy, który musi zostać zwrócony zgodnie z określoną metodą routingu i stanem kondycji punktów końcowych. Następnie analizuje typ rekordu żądany w zapytaniu przychodzącym i typ rekordu skojarzony z punktem końcowym przed zwróceniem odpowiedzi na podstawie poniższej tabeli.

W przypadku profilów z dowolną metodą routingu inną niż MultiValue:

Przychodzące żądanie zapytania Typ punktu końcowego Podana odpowiedź
DOWOLNE A / AAAA / CNAME Docelowy punkt końcowy
A A / CNAME Docelowy punkt końcowy
A AAAA NODATA
AAAA AAAA / CNAME Docelowy punkt końcowy
AAAA A NODATA
CNAME CNAME Docelowy punkt końcowy
CNAME A / AAAA NODATA

W przypadku profilów z metodą routingu ustawioną na wartość MultiValue:

Przychodzące żądanie zapytania Typ punktu końcowego Podana odpowiedź
DOWOLNE Mieszanka A i AAAA Docelowe punkty końcowe
A Mieszanka A i AAAA Tylko docelowe punkty końcowe typu A
AAAA Mieszanka A i AAAA Tylko docelowe punkty końcowe typu AAAA
CNAME Mieszanka A i AAAA NODATA

Czy mogę użyć profilu z adresami IPv4/IPv6 w profilu zagnieżdżonym?

Tak, z wyjątkiem, że profil typu MultiValue nie może być profilem nadrzędnym w zagnieżdżonym zestawie profilów.

Zatrzymano punkt końcowy aplikacji internetowej w profilu usługi Traffic Manager, ale nie otrzymuję żadnego ruchu nawet po ponownym uruchomieniu. Jak rozwiązać ten problem?

Gdy punkt końcowy aplikacji internetowej platformy Azure zostanie zatrzymany, usługa Traffic Manager przestanie sprawdzać kondycję i uruchamia ją ponownie dopiero po wykryciu ponownego uruchomienia punktu końcowego. Aby zapobiec temu opóźnieniu, wyłącz i ponownie włącz ten punkt końcowy w profilu usługi Traffic Manager po ponownym uruchomieniu punktu końcowego.

Czy mogę używać usługi Traffic Manager, nawet jeśli moja aplikacja nie ma obsługi protokołu HTTP lub HTTPS?

Tak. Jako protokół monitorowania można określić protokół TCP, a usługa Traffic Manager może zainicjować połączenie TCP i poczekać na odpowiedź z punktu końcowego. Jeśli punkt końcowy odpowiada na żądanie połączenia z odpowiedzią na nawiązanie połączenia, w okresie przekroczenia limitu czasu ten punkt końcowy jest oznaczony jako w dobrej kondycji.

Jakie konkretne odpowiedzi są wymagane z punktu końcowego podczas korzystania z monitorowania TCP?

Gdy jest używane monitorowanie protokołu TCP, usługa Traffic Manager uruchamia trzykierunkowe uzgadnianie protokołu TCP, wysyłając żądanie SYN do punktu końcowego na określonym porcie. Następnie czeka na odpowiedź SYN-ACK z punktu końcowego przez pewien czas (określony w ustawieniach limitu czasu).

  • Jeśli odpowiedź SYN-ACK zostanie odebrana w okresie przekroczenia limitu czasu określonym w ustawieniach monitorowania, ten punkt końcowy jest uznawany za w dobrej kondycji. Fin lub FIN-ACK jest oczekiwaną odpowiedzią z usługi Traffic Manager, gdy regularnie przerywa gniazdo.
  • Jeśli po upływie określonego limitu czasu zostanie odebrana odpowiedź SYN-ACK, usługa Traffic Manager odpowie za pomocą RST, aby zresetować połączenie.

Jak szybko usługa Traffic Manager przenosi użytkowników z punktu końcowego w złej kondycji?

Usługa Traffic Manager udostępnia wiele ustawień, które mogą pomóc w kontrolowaniu zachowania trybu failover profilu usługi Traffic Manager w następujący sposób:

  • Można określić, że sondowanie punktów końcowych usługi Traffic Manager częściej przez ustawienie interwału sondowania na 10 sekund. Gwarantuje to, że każdy punkt końcowy będzie w złej kondycji można wykryć tak szybko, jak to możliwe.
  • Możesz określić czas oczekiwania przed przekroczeniem limitu czasu żądania sprawdzania kondycji (minimalna wartość limitu czasu wynosi 5 sekund).
  • Można określić, ile błędów może wystąpić, zanim punkt końcowy zostanie oznaczony jako w złej kondycji. Ta wartość może być niska od 0, w takim przypadku punkt końcowy jest oznaczony jako w złej kondycji, gdy tylko zakończy się niepowodzeniem pierwszego sprawdzenia kondycji. Jednak użycie minimalnej wartości 0 dla tolerowanej liczby awarii może prowadzić do wyprowadzenia punktów końcowych z rotacji z powodu wszelkich przejściowych problemów, które mogą wystąpić w momencie sondowania.
  • Możesz określić czas wygaśnięcia (TTL), aby odpowiedź DNS wynosiła nawet 0. Oznacza to, że moduły rozpoznawania nazw DNS nie mogą buforować odpowiedzi, a każde nowe zapytanie otrzymuje odpowiedź zawierającą najbardziej aktualne informacje o kondycji, które ma usługa Traffic Manager.

Korzystając z tych ustawień, usługa Traffic Manager może zapewnić tryb failover poniżej 10 sekund po przejściu punktu końcowego w złej kondycji, a zapytanie DNS jest wykonywane względem odpowiedniego profilu.

Jak określić różne ustawienia monitorowania dla różnych punktów końcowych w profilu?

Ustawienia monitorowania usługi Traffic Manager są na poziomie profilu. Jeśli musisz użyć innego ustawienia monitorowania tylko dla jednego punktu końcowego, można to zrobić, używając tego punktu końcowego jako profilu zagnieżdżonego, którego ustawienia monitorowania różnią się od profilu nadrzędnego.

Jak przypisać nagłówki HTTP do kontroli kondycji usługi Traffic Manager do moich punktów końcowych?

Usługa Traffic Manager umożliwia określanie niestandardowych nagłówków w testach kondycji protokołu HTTP inicjowanych w punktach końcowych. Jeśli chcesz określić nagłówek niestandardowy, możesz to zrobić na poziomie profilu (dotyczy wszystkich punktów końcowych) lub określić go na poziomie punktu końcowego. Jeśli nagłówek jest zdefiniowany na obu poziomach, to określony na poziomie punktu końcowego zastępuje poziom profilu 1. Jednym z typowych przypadków użycia jest określenie nagłówków hostów, dzięki czemu żądania usługi Traffic Manager mogą być prawidłowo kierowane do punktu końcowego hostowanego w środowisku wielodostępnym. Innym przypadkiem użycia jest zidentyfikowanie żądań usługi Traffic Manager z dzienników żądań HTTP punktu końcowego

Jakiego nagłówka hosta używają testy kondycji punktu końcowego?

Jeśli nie podano niestandardowego ustawienia nagłówka hosta, nagłówek hosta używany przez usługę Traffic Manager jest nazwą DNS obiektu docelowego punktu końcowego skonfigurowanego w profilu, jeśli jest dostępny.

Jakie są adresy IP, z których pochodzą kontrole kondycji?

Zapoznaj się z tym artykułem , aby dowiedzieć się, jak pobrać listy adresów IP, z których mogą pochodzić testy kondycji usługi Traffic Manager. Aby pobrać najnowszą listę, możesz użyć interfejsu API REST, interfejsu wiersza polecenia platformy Azure lub programu Azure PowerShell. Przejrzyj listę adresów IP, aby upewnić się, że połączenia przychodzące z tych adresów IP są dozwolone w punktach końcowych w celu sprawdzenia stanu kondycji.

Przykład użycia programu Azure PowerShell:

$serviceTags = Get-AzNetworkServiceTag -Location eastus
$result = $serviceTags.Values | Where-Object { $_.Name -eq "AzureTrafficManager" }
$result.Properties.AddressPrefixes

Uwaga

Publiczne adresy IP mogą ulec zmianie bez powiadomienia. Upewnij się, że pobrać najnowsze informacje przy użyciu interfejsu API odnajdywania tagów usługi lub pliku JSON, który można pobrać.

Ile kontroli kondycji punktu końcowego mogę oczekiwać od usługi Traffic Manager?

Liczba kontroli kondycji usługi Traffic Manager zbliżających się do punktu końcowego zależy od następujących elementów:

  • wartość ustawiona dla interwału monitorowania (mniejszy interwał oznacza więcej żądań docelowych w punkcie końcowym w danym okresie).
  • liczba lokalizacji, z których pochodzą kontrole kondycji (adresy IP, z których można oczekiwać, te kontrole są wymienione w poprzednich często zadawanych pytaniach).

Jak otrzymywać powiadomienia, jeśli jeden z moich punktów końcowych ulegnie awarii?

Jedną z metryk udostępnianych przez usługę Traffic Manager jest stan kondycji punktów końcowych w profilu. Można to zobaczyć jako agregację wszystkich punktów końcowych w profilu (na przykład 75% punktów końcowych jest w dobrej kondycji) lub na poziomie punktu końcowego. Metryki usługi Traffic Manager są uwidocznione za pośrednictwem usługi Azure Monitor i można użyć jej funkcji alertów, aby otrzymywać powiadomienia, gdy nastąpi zmiana stanu kondycji punktu końcowego. Aby uzyskać więcej informacji, zobacz Metryki i alerty usługi Traffic Manager.

Profile zagnieżdżone usługi Traffic Manager

Jak mogę skonfigurować zagnieżdżone profile?

Zagnieżdżone profile usługi Traffic Manager można skonfigurować przy użyciu zarówno usługi Azure Resource Manager, jak i klasycznych interfejsów API REST platformy Azure, poleceń cmdlet programu Azure PowerShell i wieloplatformowych poleceń interfejsu wiersza polecenia platformy Azure. Są one również obsługiwane za pośrednictwem nowej witryny Azure Portal.

Ile warstw zagnieżdżania obsługuje usługa Traffic Manger?

Profile można zagnieżdżać do 10 poziomów głębokości. Pętle "" nie są dozwolone.

Czy można mieszać inne typy punktów końcowych z profilami zagnieżdżonych podrzędnych w tym samym profilu usługi Traffic Manager?

Tak. Nie ma żadnych ograniczeń dotyczących łączenia punktów końcowych różnych typów w profilu.

Jak model rozliczeniowy ma zastosowanie do profilów zagnieżdżonych?

Nie ma negatywnego wpływu cen na używanie profilów zagnieżdżonych.

Rozliczenia usługi Traffic Manager mają dwa składniki: kontrole kondycji punktu końcowego i miliony zapytań DNS

  • Testy kondycji punktu końcowego: nie ma opłat za profil podrzędny skonfigurowany jako punkt końcowy w profilu nadrzędnym. Monitorowanie punktów końcowych w profilu podrzędnym jest rozliczane w zwykły sposób.
  • Zapytania DNS: każde zapytanie jest liczone tylko raz. Zapytanie względem profilu nadrzędnego, które zwraca punkt końcowy z profilu podrzędnego, jest liczone tylko względem profilu nadrzędnego.

Aby uzyskać szczegółowe informacje, zobacz stronę cennika usługi Traffic Manager.

Czy istnieje wpływ na wydajność profilów zagnieżdżonych?

Nie, nie ma żadnego wpływu na wydajność w przypadku korzystania z profilów zagnieżdżonych.

Serwery nazw usługi Traffic Manager przechodzą wewnętrznie przez hierarchię profilów podczas przetwarzania każdego zapytania DNS. Zapytanie DNS do profilu nadrzędnego może odbierać odpowiedź DNS z punktem końcowym z profilu podrzędnego. Pojedynczy rekord CNAME jest używany niezależnie od tego, czy używasz jednego profilu, czy profilów zagnieżdżonych. Nie ma potrzeby tworzenia rekordu CNAME dla każdego profilu w hierarchii.

Jak usługa Traffic Manager oblicza kondycję zagnieżdżonego punktu końcowego w profilu nadrzędnym?

Profil nadrzędny nie wykonuje bezpośrednio kontroli kondycji elementu podrzędnego. Zamiast tego kondycja punktów końcowych profilu podrzędnego służy do obliczania ogólnej kondycji profilu podrzędnego. Te informacje są propagowane w górę hierarchii profilów zagnieżdżonych w celu określenia kondycji zagnieżdżonego punktu końcowego. Profil nadrzędny używa tej zagregowanej kondycji, aby określić, czy ruch może być kierowany do elementu podrzędnego.

W poniższej tabeli opisano zachowanie kontroli kondycji usługi Traffic Manager dla zagnieżdżonego punktu końcowego.

Stan monitora profilu podrzędnego Stan nadrzędnego monitora punktu końcowego Uwagi
Wyłączone. Profil podrzędny został wyłączony. Zatrzymana Stan nadrzędnego punktu końcowego to Stopped, a nie Disabled. Stan Disabled jest zarezerwowany dla wskazania, że punkt końcowy został wyłączony w profilu nadrzędnym.
Obniżona wydajność. Co najmniej jeden punkt końcowy profilu podrzędnego Degraded jest w stanie. Online: liczba Online punktów końcowych w profilu podrzędnym jest co najmniej wartością MinChildEndpoints.
CheckEndpoint: liczba Online punktów końcowych plus CheckingEndpoint w profilu podrzędnym jest co najmniej wartością MinChildEndpoints.
Obniżona wydajność: w przeciwnym razie.		 Ruch jest kierowany do punktu końcowego stanu CheckingEndpoint. Jeśli MinChildEndpoints ustawienie jest zbyt wysokie, punkt końcowy jest zawsze obniżony.
Online. Co najmniej jeden punkt końcowy profilu podrzędnego jest stanem Online . Żaden punkt końcowy nie jest w Degraded stanie. Zobacz powyżej.
CheckEndpoints.CheckEndpoints (Punkty kontrolne). Co najmniej jeden punkt końcowy profilu podrzędnego to CheckingEndpoint. Brak punktów końcowych Online lub Degraded Jak wyżej.
Nieaktywne. Wszystkie punkty końcowe profilu podrzędnego są albo Disabled Stopped, albo ten profil nie ma punktów końcowych. Zatrzymana

Ważne

Podczas zarządzania profilami podrzędnymi w profilu nadrzędnym w usłudze Azure Traffic Manager problem może wystąpić, jeśli jednocześnie wyłączysz i włączysz dwa profile podrzędne. Jeśli te akcje wystąpią w tym samym czasie, może wystąpić krótki okres, gdy oba punkty końcowe są wyłączone, co prowadzi do wprowadzenia stanu naruszenia zabezpieczeń profilu nadrzędnego.

Aby uniknąć tego problemu, należy zachować ostrożność podczas wprowadzania równoczesnych zmian w profilach podrzędnych. Rozważ nieznaczne rozłożenie tych akcji, aby zapobiec niezamierzonym zakłóceniom konfiguracji zarządzania ruchem.

Dlaczego nie mogę dodać punktów końcowych rozszerzonej pomocy technicznej usług Azure Cloud Services do profilu usługi Traffic Manager?

Aby dodać punkty końcowe rozszerzone usługi Azure Cloud do profilu usługi Traffic Manager, grupa zasobów musi mieć zgodność z interfejsem API usługi Azure Service Management (ASM). Profile znajdujące się w starszej grupie zasobów muszą być zgodne ze standardami interfejsu API usługi ASM, które zabraniają dołączania publicznych punktów końcowych adresów IP lub punktów końcowych z innej subskrypcji niż profil. Aby rozwiązać ten problem, rozważ przeniesienie profilu usługi Traffic Manager i skojarzonych zasobów do nowej grupy zasobów zgodnej z interfejsem API usługi ASM.

Następne kroki: