Rozwiązywanie problemów powodowanych przez sporadyczne błędy połączeń wychodzących w usłudze Azure App Service

Ten artykuł ułatwia rozwiązywanie sporadycznych błędów połączenia i związanych z nimi problemów z wydajnością w Azure App Service. Zawiera więcej informacji na temat metodologii rozwiązywania problemów z portami translacji adresów sieciowych (SNAT, source network address translation). Jeśli potrzebujesz dodatkowej pomocy w dowolnym momencie tego artykułu, skontaktuj się z ekspertami platformy Azure na forach MSDN Azure i Stack Overflow. Alternatywnie zgłoś zdarzenie pomoc techniczna platformy Azure. Przejdź do witryny pomocy technicznej platformy Azure i wybierz pozycję Uzyskaj pomoc techniczną.

Objawy

Aplikacje i funkcje hostowane w usłudze aplikacja systemu Azure mogą wykazywać co najmniej jeden z następujących objawów:

  • Wolne czasy odpowiedzi dla wszystkich lub niektórych wystąpień w planie usługi.
  • Sporadyczne błędy 5xx lub nieprawidłowej bramy
  • Komunikaty o błędach przekroczenia limitu czasu
  • Nie można nawiązać połączenia z zewnętrznymi punktami końcowymi (takimi jak SQLDB, Service Fabric, inne usługi App Services itp.)

Przyczyna

Główną przyczyną sporadycznych problemów z połączeniem jest przekroczenie limitu podczas tworzenia nowych połączeń wychodzących. Limity, które można osiągnąć, obejmują:

  • Połączenia TCP: istnieje limit liczby połączeń wychodzących, które można wykonać. Limit połączeń wychodzących jest skojarzony z rozmiarem używanego procesu roboczego.
  • Porty SNAT: połączenia wychodzące na platformie Azure opisują ograniczenia portów SNAT i ich wpływ na połączenia wychodzące. Platforma Azure używa źródłowego translatora adresów sieciowych (SNAT) i modułów równoważenia obciążenia (nie uwidacznianych klientom) do komunikowania się z publicznymi adresami IP. Każde wystąpienie w usłudze aplikacja systemu Azure początkowo otrzymuje wstępnie przydzieloną liczbę 128 portów SNAT. Limit portów SNAT wpływa na otwieranie połączeń z tą samą kombinacją adresu i portu. Jeśli aplikacja tworzy połączenia z kombinacją kombinacji adresów i portów, porty SNAT nie będą używane. Porty SNAT są zużywane w przypadku powtarzających się wywołań do tej samej kombinacji adresu i portu. Po zwolnieniu portu jest on dostępny do ponownego użycia w razie potrzeby. Moduł równoważenia obciążenia sieci platformy Azure odzyskuje port SNAT z zamkniętych połączeń dopiero po odczekaniu 4 minut.

Gdy aplikacje lub funkcje szybko otwierają nowe połączenie, mogą szybko wyczerpać przydział wstępny 128 portów. Następnie są blokowane do momentu udostępnienia nowego portu SNAT przez dynamiczne przydzielanie większej liczby portów SNAT lub ponowne użycie odzyskanego portu SNAT. Jeśli w aplikacji zabraknie portów SNAT, wystąpią sporadyczne problemy z łącznością wychodzącą.

Unikanie problemu

Istnieje kilka rozwiązań, które pozwalają uniknąć ograniczeń portów SNAT. Obejmują one:

  • pule połączeń: dzięki buforowaniu połączeń należy unikać otwierania nowych połączeń sieciowych dla wywołań do tego samego adresu i portu.
  • punkty końcowe usługi: nie masz ograniczenia portu SNAT do usług zabezpieczonych punktami końcowymi usługi.
  • prywatne punkty końcowe: nie masz ograniczenia portu SNAT do usług zabezpieczonych za pomocą prywatnych punktów końcowych.
  • Brama translatora adresów sieciowych: w przypadku bramy translatora adresów sieciowych masz 64 tys. wychodzących portów SNAT, które mogą być używane przez zasoby wysyłające ruch przez nią.

Aby uniknąć problemu z portem SNAT, należy zapobiec powtarzalnemu tworzeniu nowych połączeń z tym samym hostem i portem. Pule połączeń to jeden z bardziej oczywistych sposobów rozwiązania tego problemu.

Jeśli miejscem docelowym jest usługa platformy Azure, która obsługuje punkty końcowe usługi, możesz uniknąć problemów z wyczerpaniem portów SNAT przy użyciu regionalnych punktów końcowych integracji i usługi sieci wirtualnej lub prywatnych punktów końcowych. W przypadku korzystania z regionalnej integracji z siecią wirtualną i umieszczania punktów końcowych usługi w podsieci integracji ruch wychodzący aplikacji do tych usług nie będzie miał ograniczeń dotyczących ruchu wychodzącego portów SNAT. Podobnie, jeśli używasz regionalnej integracji z siecią wirtualną i prywatnych punktów końcowych, nie będziesz mieć żadnych problemów z portem wychodzącym SNAT do tego miejsca docelowego.

Jeśli miejsce docelowe jest zewnętrznym punktem końcowym poza platformą Azure, użycie bramy translatora adresów sieciowych zapewnia 64k wychodzących portów SNAT. Zapewnia również dedykowany adres wychodzący, który nie jest udostępniany nikomu.

Jeśli to możliwe, ulepsz kod, aby używać pul połączeń i uniknąć całej sytuacji. Nie zawsze można szybko zmienić kod, aby wyeliminować tę sytuację. W przypadku, gdy nie można zmienić kodu w czasie, skorzystaj z innych rozwiązań. Najlepszym rozwiązaniem problemu jest połączenie wszystkich rozwiązań najlepiej, jak to możliwe. Spróbuj użyć punktów końcowych usługi i prywatnych punktów końcowych do usług platformy Azure i bramy translatora adresów sieciowych dla pozostałych.

Ogólne strategie ograniczania wyczerpania portów SNAT zostały omówione w sekcji Rozwiązywanie problemów w dokumentacji połączeń wychodzących platformy Azure . Poniższe strategie dotyczą aplikacji i funkcji hostowanych w usłudze aplikacja systemu Azure.

Modyfikowanie aplikacji w celu używania puli połączeń

Oto zbiór linków do implementowania buforowania połączeń według innego stosu rozwiązań.

Węzeł

Domyślnie połączenia dla środowiska NodeJS nie są utrzymywane przy życiu. Poniżej znajdują się popularne bazy danych i pakiety dla buforowania połączeń, które zawierają przykłady implementacji.

Utrzymywanie aktywności połączenia HTTP

Java

Poniżej przedstawiono popularne biblioteki używane do buforowania połączeń JDBC, które zawierają przykłady implementowania ich: buforowanie połączeń JDBC.

Buforowanie połączeń HTTP

PHP

Mimo że język PHP nie obsługuje buforowania połączeń, możesz spróbować użyć trwałych Połączenia z bazą danych na serwerze zaplecza.

Python

Poniżej przedstawiono popularne bazy danych i moduły do buforowania połączeń, które zawierają przykłady sposobu ich implementacji.

Buforowanie połączeń HTTP

  • Obsługa aktywności i buforowanie połączeń HTTP są domyślnie włączone w module Żądania .
  • Urllib3

Modyfikowanie aplikacji w celu ponownego używania połączeń

Modyfikowanie aplikacji w celu używania łagodniejszej logiki ponawiania prób

Używanie elementów utrzymywania aktywności w celu resetowania limitu czasu bezczynności połączeń wychodzących

Więcej wskazówek dotyczących App Service:

  • Test obciążeniowy powinien symulować dane w świecie rzeczywistym ze stałą szybkością podawania. Testowanie aplikacji i funkcji w warunkach rzeczywistego obciążenia może identyfikować i rozwiązywać problemy z wyczerpaniem portów SNAT z wyprzedzeniem.
  • Upewnij się, że usługi zaplecza mogą szybko zwracać odpowiedzi. Aby rozwiązać problemy z wydajnością usługi Azure SQL Database, zobacz Rozwiązywanie problemów z wydajnością bazy danych Azure SQL w usłudze Intelligent Insights.
  • Skaluj w poziomie App Service planować więcej wystąpień. Aby uzyskać więcej informacji na temat skalowania, zobacz Skalowanie aplikacji w Azure App Service. Każde wystąpienie procesu roboczego w planie usługi App Service jest przydzielane kilka portów SNAT. Jeśli rozłożysz użycie na więcej wystąpień, możesz uzyskać użycie portów SNAT na wystąpienie poniżej zalecanego limitu 100 połączeń wychodzących na unikatowy zdalny punkt końcowy.
  • Rozważ przejście do App Service Environment (ASE), gdzie przydzielono pojedynczy wychodzący adres IP, a limity połączeń i portów SNAT są wyższe. W środowisku ASE liczba portów SNAT na wystąpienie jest oparta na tabeli wstępnej alokacji modułu równoważenia obciążenia platformy Azure. Na przykład środowiska ASE z wystąpieniami 1–50 procesów roboczych mają 1024 wstępnie przydzielone porty na wystąpienie, a środowiska ASE z 51–100 wystąpieniami procesu roboczego mają 512 wstępnie przydzielonych portów na wystąpienie.

Unikanie limitów wychodzących protokołu TCP jest łatwiejsze do rozwiązania, ponieważ limity są ustawiane przez rozmiar procesu roboczego. Limity można zobaczyć w artykule Limity liczbowe między maszynami wirtualnymi w piaskownicy — połączenia TCP

Nazwa limitu Opis Mały (A1) Średni (A2) Duży (A3) Warstwa izolowana (ASE)
Połączenia Liczba połączeń na całej maszynie wirtualnej 1920 3968 8064 16 000

Aby uniknąć limitów tcp dla ruchu wychodzącego, możesz zwiększyć rozmiar procesów roboczych lub skalować w poziomie.

Rozwiązywanie problemów

Znajomość dwóch typów limitów połączeń wychodzących i tego, co robi aplikacja, powinna ułatwić rozwiązywanie problemów. Jeśli wiesz, że aplikacja wykonuje wiele wywołań do tego samego konta magazynu, możesz podejrzewać limit SNAT. Jeśli aplikacja tworzy wiele wywołań do punktów końcowych przez Internet, podejrzewasz, że osiągniesz limit maszyny wirtualnej.

Jeśli nie znasz wystarczająco dużo zachowania aplikacji, aby szybko ustalić przyczynę, istnieją pewne narzędzia i techniki dostępne w App Service, aby pomóc w tym ustaleniu.

Znajdowanie informacji o alokacji portów SNAT

Możesz użyć diagnostyki App Service, aby znaleźć informacje o alokacji portów SNAT i obserwować metryki alokacji portów SNAT lokacji App Service. Aby znaleźć informacje o alokacji portów SNAT, wykonaj następujące kroki:

  1. Aby uzyskać dostęp do diagnostyki App Service, przejdź do aplikacji internetowej App Service lub App Service Environment w Azure Portal. W obszarze nawigacji po lewej stronie wybierz pozycję Diagnozuj i rozwiąż problemy.
  2. Wybierz kategorię dostępność i wydajność
  3. Wybierz kafelek Wyczerpanie portów SNAT na liście dostępnych kafelków w kategorii. Praktyką jest utrzymanie go poniżej 128. Jeśli jest to potrzebne, nadal możesz otworzyć bilet pomocy technicznej, a inżynier pomocy technicznej otrzyma metrykę z zaplecza.

Ponieważ użycie portów SNAT nie jest dostępne jako metryka, nie jest możliwe automatyczne skalowanie na podstawie użycia portów SNAT lub skonfigurowanie automatycznego skalowania na podstawie metryki alokacji portów SNAT.

Połączenia TCP i porty SNAT

Połączenia TCP i porty SNAT nie są bezpośrednio powiązane. Detektor użycia połączeń TCP znajduje się na stronie zarządzania Diagnozowanie i rozwiązywanie problemów z dowolną aplikacją App Service. Wyszukaj frazę "Połączenia TCP", aby ją znaleźć.

  • Porty SNAT są używane tylko dla przepływów sieci zewnętrznej, podczas gdy łączna liczba połączeń TCP obejmuje lokalne połączenia sprzężenia zwrotnego.
  • Port SNAT może być współużytkowany przez różne przepływy, jeśli przepływy różnią się w protokole, adresie IP lub porcie. Metryka Połączenia TCP liczy każde połączenie TCP.
  • Limit połączeń TCP występuje na poziomie wystąpienia procesu roboczego. Równoważenie obciążenia wychodzącego usługi Azure Network nie używa metryki Połączenia TCP dla limitu portów SNAT.
  • Limity połączeń TCP opisano w artykule Limity liczbowe między maszynami wirtualnymi w piaskownicy — połączenia TCP
  • Istniejące sesje TCP kończą się niepowodzeniem po dodaniu nowych wychodzących sesji TCP z portu źródłowego Azure App Service. Aby uniknąć konfliktów, możesz użyć jednego adresu IP lub ponownie skonfigurować elementy członkowskie puli zaplecza.
Nazwa limitu Opis Mały (A1) Średni (A2) Duży (A3) Warstwa izolowana (ASE)
Połączenia Liczba połączeń na całej maszynie wirtualnej 1920 3968 8064 16 000

Połączenia zadań WebJob i bazy danych

Jeśli porty SNAT są wyczerpane, a zadania WebJob nie mogą nawiązać połączenia z SQL Database, nie ma metryki pokazującej, ile połączeń jest otwieranych przez poszczególne procesy aplikacji internetowej. Aby znaleźć problematyczne zadania WebJob, przenieś kilka zadań WebJob do innego App Service plan, aby sprawdzić, czy sytuacja się poprawia lub czy problem pozostaje w jednym z planów. Powtórz ten proces, dopóki nie znajdziesz problematycznego zadania WebJob.

Dodatkowe informacje