Połączenia wychodzące (klasyczne)

  • Artykuł

Platforma Azure zapewnia łączność wychodzącą dla wdrożeń klientów za pośrednictwem kilku różnych mechanizmów. W tym artykule opisano, jakie scenariusze są stosowane, jak działają i jak nimi zarządzać.

Uwaga

W tym artykule opisano tylko wdrożenia klasyczne. Zapoznaj się z artykułem Połączenia wychodzące dla wszystkich scenariuszy wdrażania Resource Manager na platformie Azure.

Wdrożenie na platformie Azure może komunikować się z punktami końcowymi spoza platformy Azure w publicznej przestrzeni adresowej IP. Gdy wystąpienie inicjuje przepływ wychodzący do miejsca docelowego w publicznej przestrzeni adresowej IP, platforma Azure dynamicznie mapuje prywatny adres IP na publiczny adres IP. Po utworzeniu tego mapowania ruch zwracany dla tego przepływu pochodzącego z ruchu wychodzącego może również uzyskać dostęp do prywatnego adresu IP, z którego pochodzi przepływ.

Platforma Azure używa źródłowego tłumaczenia adresów sieciowych (SNAT) do wykonania tej funkcji. Gdy wiele prywatnych adresów IP jest podszywających się za jednym publicznym adresem IP, platforma Azure używa translacji adresów portowych (PAT) do maskowania prywatnych adresów IP. Efemeryczne porty są używane do pat i są wstępnie przydzielane na podstawie rozmiaru puli.

Istnieje wiele scenariuszy ruchu wychodzącego. Możesz połączyć te scenariusze zgodnie z potrzebami. Dokładnie przejrzyj je, aby zrozumieć możliwości, ograniczenia i wzorce w miarę ich stosowania do modelu wdrażania i scenariusza aplikacji. Zapoznaj się ze wskazówkami dotyczącymi zarządzania tymi scenariuszami.

Omówienie scenariusza

Platforma Azure udostępnia trzy różne metody umożliwiające osiągnięcie wdrożeń klasycznych łączności wychodzącej. Nie wszystkie wdrożenia klasyczne mają dostępne trzy scenariusze:

Scenariusz Metoda Protokoły IP Opis Rola internetowego procesu roboczego IaaS
1. Maszyna wirtualna z publicznym adresem IP na poziomie wystąpienia SNAT, maskowanie portów nieużytne TCP, UDP, ICMP, ESP Platforma Azure używa przypisanego publicznego adresu IP maszyny wirtualnej. Wystąpienie ma dostępne wszystkie efemeryczne porty. Nie Tak
2. publiczny punkt końcowy ze zrównoważonym obciążeniem SNAT z maskowaniem portów (PAT) do publicznego punktu końcowego TCP, UDP Platforma Azure udostępnia publiczny punkt końcowy adresu IP z wieloma prywatnymi punktami końcowymi. Platforma Azure używa efemerycznych portów publicznego punktu końcowego dla pat. Tak Tak
3. Autonomiczna maszyna wirtualna SNAT z maskowaniem portów (PAT) TCP, UDP Platforma Azure automatycznie wyznacza publiczny adres IP dla protokołu SNAT, udostępnia ten publiczny adres IP całej wdrożeniu i używa efemerycznych portów publicznego adresu IP punktu końcowego dla adresu PAT. Jest to scenariusz rezerwowy dla powyższych scenariuszy. Nie zalecamy jej, jeśli potrzebujesz widoczności i kontroli. Tak Tak

Jest to podzbiór funkcji połączeń wychodzących dostępnych dla wdrożeń Resource Manager na platformie Azure.

Różne wdrożenia w wersji klasycznej mają różne funkcje:

Wdrożenie klasyczne Dostępne funkcje
Maszyna wirtualna scenariusz 1, 2 lub 3
Rola internetowego procesu roboczego tylko scenariusz 2, 3

Strategie ograniczania ryzyka mają również te same różnice.

Algorytm używany do wstępnego przydzielania portów efemerycznych na potrzeby wdrożeń klasycznych jest taki sam jak w przypadku wdrożeń zasobów platformy Azure Resource Manager.

Scenariusz 1. Maszyna wirtualna z publicznym adresem IP na poziomie wystąpienia

W tym scenariuszu maszyna wirtualna ma przypisany publiczny adres IP (ILPIP) na poziomie wystąpienia. Jeśli chodzi o połączenia wychodzące, nie ma znaczenia, czy maszyna wirtualna ma punkt końcowy ze zrównoważonym obciążeniem, czy nie. Ten scenariusz ma pierwszeństwo przed innymi. Gdy jest używana funkcja ILPIP, maszyna wirtualna używa funkcji ILPIP dla wszystkich przepływów wychodzących.

Publiczny adres IP przypisany do maszyny wirtualnej to relacja 1:1 (a nie 1:wiele) i zaimplementowana jako bezstanowa translator adresów sieciowych 1:1. Maskowanie portów (PAT) nie jest używane, a maszyna wirtualna ma wszystkie efemeryczne porty dostępne do użycia.

Jeśli aplikacja inicjuje wiele przepływów wychodzących i występuje wyczerpanie portów SNAT, rozważ przypisanie funkcji ILPIP w celu ograniczenia ograniczeń protokołu SNAT. Zapoznaj się z artykułem Zarządzanie wyczerpaniem SNAT w całości.

Scenariusz 2. Publiczny punkt końcowy ze zrównoważonym obciążeniem

W tym scenariuszu rola maszyny wirtualnej lub procesu roboczego sieci Web jest skojarzona z publicznym adresem IP za pośrednictwem punktu końcowego ze zrównoważonym obciążeniem. Maszyna wirtualna nie ma przypisanego publicznego adresu IP.

Gdy maszyna wirtualna o zrównoważonym obciążeniu tworzy przepływ wychodzący, platforma Azure tłumaczy prywatny źródłowy adres IP przepływu wychodzącego na publiczny adres IP publicznego punktu końcowego ze zrównoważonym obciążeniem. Platforma Azure używa protokołu SNAT do wykonania tej funkcji. Platforma Azure używa również pat do maskowania wielu prywatnych adresów IP za publicznym adresem IP.

Efemeryczne porty frontonu publicznego adresu IP modułu równoważenia obciążenia są używane do rozróżniania poszczególnych przepływów pochodzących z maszyny wirtualnej. Funkcja SNAT dynamicznie używa wstępnie przydzielonych portów efemerycznych podczas tworzenia przepływów wychodzących. W tym kontekście efemeryczne porty używane dla protokołu SNAT są nazywane portami SNAT.

Porty SNAT są wstępnie przydzielane zgodnie z opisem w sekcji Understanding SNAT and PAT (Opis protokołu SNAT i pat ). Są to skończony zasób, który może zostać wyczerpany. Ważne jest, aby zrozumieć, jak są one używane. Aby dowiedzieć się, jak zaprojektować to użycie i ograniczyć je w razie potrzeby, zapoznaj się z artykułem Zarządzanie wyczerpaniem SNAT.

Jeśli istnieje wiele publicznych punktów końcowych o zrównoważonym obciążeniu , każdy z tych publicznych adresów IP jest kandydatem do przepływów wychodzących, a jeden jest wybierany losowo.

Scenariusz 3. Brak skojarzonego publicznego adresu IP

W tym scenariuszu maszyna wirtualna lub składnik ROle procesu roboczego sieci Web nie jest częścią publicznego punktu końcowego ze zrównoważonym obciążeniem. W przypadku maszyny wirtualnej nie ma przypisanego adresu ILPIP. Gdy maszyna wirtualna tworzy przepływ wychodzący, platforma Azure tłumaczy prywatny źródłowy adres IP przepływu wychodzącego na publiczny źródłowy adres IP. Publiczny adres IP używany dla tego przepływu wychodzącego nie jest konfigurowalny i nie jest liczone względem limitu zasobów publicznego adresu IP subskrypcji. Platforma Azure automatycznie przydziela ten adres.

Do wykonania tej funkcji platforma Azure używa protokołu SNAT z maskowaniem portów (PAT). Ten scenariusz jest podobny do scenariusza 2, z wyjątkiem braku kontroli nad używanym adresem IP. Jest to scenariusz rezerwowy, w przypadku gdy scenariusze 1 i 2 nie istnieją. Nie zalecamy tego scenariusza, jeśli chcesz kontrolować adres wychodzący. Jeśli połączenia wychodzące są krytyczną częścią aplikacji, należy wybrać inny scenariusz.

Porty SNAT są wstępnie przydzielane zgodnie z opisem w sekcji Understanding SNAT and PAT (Opis protokołu SNAT i pat ). Liczba maszyn wirtualnych lub ról procesu roboczego sieci Web współużytkowania publicznego adresu IP określa liczbę wstępnie przydzielonych portów efemerycznych. Ważne jest, aby zrozumieć, jak są one używane. Aby dowiedzieć się, jak zaprojektować to użycie i ograniczyć je w razie potrzeby, zapoznaj się z artykułem Zarządzanie wyczerpaniem SNAT.

Opis protokołu SNAT i pat

Port maskujący SNAT (PAT)

Gdy wdrożenie tworzy połączenie wychodzące, każde źródło połączenia wychodzącego zostanie przepisane. Źródło zostanie przepisane z prywatnej przestrzeni adresów IP do publicznego adresu IP skojarzonego z wdrożeniem (na podstawie opisanych powyżej scenariuszy). W przestrzeni publicznych adresów IP 5-krotka przepływu (źródłowy adres IP, port źródłowy, protokół transportu IP, docelowy adres IP, port docelowy) musi być unikatowa.

Porty efemeryczne (porty SNAT) są używane do osiągnięcia tego celu po ponownym zapisaniu prywatnego źródłowego adresu IP, ponieważ wiele przepływów pochodzi z jednego publicznego adresu IP.

Jeden port SNAT jest używany na przepływ do pojedynczego docelowego adresu IP, portu i protokołu. W przypadku wielu przepływów do tego samego docelowego adresu IP, portu i protokołu każdy przepływ używa jednego portu SNAT. Dzięki temu przepływy są unikatowe, gdy pochodzą z tego samego publicznego adresu IP i przechodzą do tego samego docelowego adresu IP, portu i protokołu.

Wiele przepływów, z których każdy ma inny docelowy adres IP, port i protokół, współużytkuje jeden port SNAT. Docelowy adres IP, port i protokół sprawiają, że przepływy są unikatowe bez konieczności rozróżniania przepływów w publicznej przestrzeni adresów IP.

Po wyczerpaniu zasobów portów SNAT przepływy wychodzące kończą się niepowodzeniem, dopóki istniejące przepływy nie zwolnią portów SNAT. Load Balancer odzyskuje porty SNAT po zamknięciu przepływu i używa 4-minutowego limitu czasu bezczynności na potrzeby odzyskiwania portów SNAT z przepływów bezczynnych.

Aby uzyskać wzorce w celu ograniczenia warunków, które często prowadzą do wyczerpania portów SNAT, zapoznaj się z sekcją Zarządzanie portem SNAT .

Wstępna alokacja portu efemerycznego dla portów maskujących port SNAT (PAT)

Platforma Azure używa algorytmu do określenia liczby wstępnie przydzielonego portów SNAT dostępnych na podstawie rozmiaru puli zaplecza podczas korzystania z portu maskowanego translatora adresów sieciowych (PAT). Porty SNAT są portami efemerycznym dostępnymi dla określonego publicznego adresu źródłowego IP.

Platforma Azure wstępnie przydziela porty SNAT po wdrożeniu wystąpienia na podstawie liczby wystąpień maszyny wirtualnej lub roli procesu roboczego sieci Web współużytkują dany publiczny adres IP. Po utworzeniu przepływów wychodzących token dostępu dynamicznie zużywa (do limitu przydziału wstępnego) i zwalnia te porty po zamknięciu przepływu lub przekroczeniu limitu czasu bezczynności.

W poniższej tabeli przedstawiono wstępne alokacje portów SNAT dla warstw rozmiarów puli zaplecza:

Wystąpienia Wstępnie przydzielone porty SNAT na wystąpienie
1-50 1,024
51-100 512
101-200 256
201-400 128

Należy pamiętać, że liczba dostępnych portów SNAT nie przekłada się bezpośrednio na liczbę przepływów. Pojedynczy port SNAT można użyć ponownie dla wielu unikatowych miejsc docelowych. Porty są używane tylko wtedy, gdy jest konieczne, aby przepływy są unikatowe. Aby uzyskać wskazówki dotyczące projektowania i ograniczania ryzyka, zapoznaj się z sekcją dotyczącą zarządzania tym wyczerpanym zasobem oraz sekcją opisową tokenu dostępu.

Zmiana rozmiaru wdrożenia może mieć wpływ na niektóre ustalone przepływy. Jeśli rozmiar puli zaplecza zwiększa się i przechodzi do następnej warstwy, połowa wstępnie przeniesionych portów SNAT zostanie odzyskana podczas przejścia do następnej większej warstwy puli zaplecza. Upłynął limit czasu przepływów skojarzonych z odzyskanym portem SNAT i należy je ponownie opublikować. Jeśli zostanie podjęta próba nowego przepływu, przepływ zakończy się powodzeniem natychmiast, o ile są dostępne wstępnie przydzielone porty.

Jeśli rozmiar wdrożenia się zmniejszy i przejdzie do niższej warstwy, liczba dostępnych portów SNAT wzrośnie. W takim przypadku istniejące przydzielone porty SNAT i ich odpowiednie przepływy nie mają wpływu.

Jeśli usługa w chmurze zostanie ponownie wdrożona lub zmieniona, infrastruktura może tymczasowo zgłosić, że pula zaplecza będzie maksymalnie dwukrotnie większa niż rzeczywista, a platforma Azure z kolei wstępnie przydzieli mniej portów SNAT na wystąpienie niż oczekiwano. Może to tymczasowo zwiększyć prawdopodobieństwo wyczerpania portów SNAT. Ostatecznie rozmiar puli zostanie przeniesiony do rzeczywistego rozmiaru, a platforma Azure automatycznie zwiększy wstępnie przydział portów SNAT do oczekiwanej liczby zgodnie z powyższą tabelą. To zachowanie jest projektowane i nie jest konfigurowalne.

Alokacje portów SNAT są specyficzne dla protokołu transportowego IP (protokoły TCP i UDP są obsługiwane oddzielnie) i są zwalniane w następujących warunkach:

Wydanie portu SNAT protokołu TCP

  • Jeśli oba serwery/klient wysyła protokół FIN/ACK, port SNAT zostanie zwolniony po 240 sekundach.
  • Jeśli widoczny jest RST, port SNAT zostanie zwolniony po 15 sekundach.
  • Osiągnięto limit czasu bezczynności

Wydanie portu SNAT protokołu UDP

  • Osiągnięto limit czasu bezczynności

Rozwiązywanie problemów

Ta sekcja ma pomóc w ograniczeniu wyczerpania translatora adresów sieciowych i innych scenariuszy, które mogą wystąpić w przypadku połączeń wychodzących na platformie Azure.

Zarządzanie wyczerpaniem portów SNAT (PAT)

Efemeryczne porty używane na potrzeby tokenu pat są zasobem wyczerpanym, zgodnie z opisem w żadnym publicznym adresie IP ipublicznym punkcie końcowym o zrównoważonym obciążeniu.

Jeśli wiesz, że inicjujesz wiele wychodzących połączeń TCP lub UDP z tym samym docelowym adresem IP i portem, a zauważasz, że połączenia wychodzące kończą się niepowodzeniem lub są zalecane przez obsługę wyczerpania portów SNAT (wstępnie przydziału portów efemerycznych używanych przez pat), masz kilka ogólnych opcji ograniczania ryzyka. Przejrzyj te opcje i zdecyduj, co jest dostępne i najlepsze dla danego scenariusza. Istnieje możliwość, że co najmniej jeden może pomóc w zarządzaniu tym scenariuszem.

Jeśli masz problemy ze zrozumieniem zachowania połączenia wychodzącego, możesz użyć statystyk stosu adresów IP (netstat). Pomocne może być też obserwowanie zachowań połączeń przy użyciu przechwytywania pakietów.

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

Możesz zmniejszyć zapotrzebowanie na porty efemeryczne, które są używane na potrzeby SNAT, ponownie używając połączeń w aplikacji. Dotyczy to szczególnie protokołów, takich jak HTTP/1.1, gdzie ponowne użycie połączenia jest ustawieniem domyślnym. Inne protokoły korzystające z protokołu HTTP jako transportu (na przykład REST) mogą korzystać z kolei.

Ponowne użycie jest zawsze lepsze niż pojedyncze, niepodzielne połączenia TCP dla każdego żądania. Ponowne użycie wyników w bardziej wydajnych, bardzo wydajnych transakcjach TCP.

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

W aplikacji można stosować schemat buforowania połączeń, w którym żądania są wewnętrznie dystrybuowane między stały zestaw połączeń (każdy z nich jest ponownie w miarę możliwości). Ten schemat ogranicza liczbę używanych portów efemerycznych i tworzy bardziej przewidywalne środowisko. Ten schemat może również zwiększyć przepływność żądań, zezwalając na wiele jednoczesnych operacji, gdy jedno połączenie blokuje odpowiedź operacji.

Buforowanie połączeń może już istnieć w ramach używanej platformy do tworzenia aplikacji lub ustawień konfiguracji aplikacji. Można połączyć buforowanie połączeń z ponownym użyciem połączenia. Następnie wiele żądań używa stałej, przewidywalnej liczby portów do tego samego docelowego adresu IP i portu. Żądania korzystają również z wydajnego korzystania z transakcji TCP, co zmniejsza opóźnienie i wykorzystanie zasobów. Transakcje UDP mogą również przynieść korzyści, ponieważ zarządzanie liczbą przepływów UDP może z kolei uniknąć warunków wyczerpania i zarządzać wykorzystaniem portów SNAT.

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

W przypadku wstępnego przydzielonego przydziału portów używanych do pat są wyczerpane lub występują błędy aplikacji, agresywne lub brutalne próby siłowe bez rozpadu i logiki wycofywania powodują wyczerpanie lub utrwalone. Zapotrzebowanie na porty efemeryczne można zmniejszyć przy użyciu mniej agresywnej logiki ponawiania prób.

Porty efemeryczne mają 4-minutowy limit czasu bezczynności (nie można go regulować). Jeśli ponawianie prób jest zbyt agresywne, wyczerpanie nie ma możliwości samodzielnego oczyszczenia. W związku z tym rozważenie sposobu i częstotliwości ponawiania prób transakcji przez aplikację jest krytyczną częścią projektu.

Przypisywanie publicznego adresu IP na poziomie wystąpienia do każdej maszyny wirtualnej

Przypisanie funkcji ILPIP zmienia twój scenariusz na publiczny adres IP na poziomie wystąpienia do maszyny wirtualnej. Wszystkie efemeryczne porty publicznego adresu IP, które są używane dla każdej maszyny wirtualnej, są dostępne dla maszyny wirtualnej. (W przeciwieństwie do scenariuszy, w których efemeryczne porty publicznego adresu IP są współużytkowane ze wszystkimi maszynami wirtualnymi skojarzonymi z odpowiednim wdrożeniem). Istnieją kompromisy, które należy wziąć pod uwagę, takie jak potencjalny wpływ na listę dozwolonych dużej liczby poszczególnych adresów IP.

Uwaga

Ta opcja nie jest dostępna dla ról internetowego procesu roboczego.

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

Połączenia wychodzące mają 4-minutowy limit czasu bezczynności. Ten limit czasu nie jest regulowany. Można jednak użyć transportu (na przykład utrzymywania tcp) lub utrzymywania warstwy aplikacji, aby odświeżyć bezczynny przepływ i zresetować ten limit czasu bezczynności w razie potrzeby. Sprawdź dostawcę dowolnego spakowanego oprogramowania, czy jest to obsługiwane, czy też jak go włączyć. Zazwyczaj tylko jedna strona musi wygenerować utrzymywania w celu zresetowania limitu czasu bezczynności.

Odnajdywanie publicznego adresu IP używanego przez maszynę wirtualną

Istnieje wiele sposobów określania publicznego źródłowego adresu IP połączenia wychodzącego. Usługa OpenDNS udostępnia usługę, która może wyświetlać publiczny adres IP maszyny wirtualnej.

Za pomocą polecenia nslookup można wysłać zapytanie DNS dla nazwy myip.opendns.com do rozpoznawania nazw OpenDNS. Usługa zwraca źródłowy adres IP, który został użyty do wysłania zapytania. Po uruchomieniu następującego zapytania z maszyny wirtualnej odpowiedź jest publicznym adresem IP używanym dla tej maszyny wirtualnej:

nslookup myip.opendns.com resolver1.opendns.com

Następne kroki

  • Dowiedz się więcej o Load Balancer używanych we wdrożeniach Resource Manager.
  • Dowiedz się więcej na temat scenariuszy połączeń wychodzących dostępnych we wdrożeniach Resource Manager.