W tym artykule opisano najlepsze rozwiązania dotyczące bramy translatora adresów sieciowych platformy Azure. Wskazówki są oparte na pięciu filarach doskonałości architektonicznej: Optymalizacja kosztów, Doskonałość operacyjna, Wydajność wydajności, Niezawodność i Bezpieczeństwo.
Zgodnie z wymaganiami wstępnymi dotyczącymi tych wskazówek musisz mieć działającą wiedzę na temat usługi Azure NAT Gateway i poznać jej odpowiednie funkcje. Aby uzyskać więcej informacji, zobacz dokumentację usługi Azure NAT Gateway.
Optymalizacja kosztów
Konfigurowanie dostępu do rozwiązań platformy jako usługi (PaaS) za pośrednictwem usługi Azure Private Link lub punktów końcowych usługi, w tym magazynu, aby nie trzeba było używać bramy translatora adresów sieciowych. Punkty końcowe usługi Private Link i usługi nie wymagają przechodzenia przez bramę translatora adresów sieciowych w celu uzyskania dostępu do usług PaaS. Takie podejście zmniejsza koszt przetwarzania danych (GB) w porównaniu z kosztem korzystania z bramy translatora adresów sieciowych. Usługa Private Link i punkty końcowe usługi zapewniają również korzyści zabezpieczeń.
Efektywność wydajności
Każdy zasób bramy translatora adresów sieciowych zapewnia do 50 gigabitów na sekundę (Gb/s) przepływności. Wdrożenia można podzielić na wiele podsieci, a następnie przypisać bramę translatora adresów sieciowych do każdej podsieci lub grupy podsieci w celu skalowania w poziomie.
Każdy publiczny adres IP bramy translatora adresów sieciowych zawiera 64 512 portów translacji adresów sieciowych (SNAT). Do bramy translatora adresów sieciowych można przypisać maksymalnie 16 adresów IP, w tym pojedyncze standardowe publiczne adresy IP, prefiks publicznego adresu IP lub oba te adresy. Dla każdego przypisanego wychodzącego adresu IP, który przechodzi do tego samego docelowego punktu końcowego, brama translatora adresów sieciowych może obsługiwać maksymalnie 50 000 współbieżnych przepływów dla protokołu TCP (Transmission Control Protocol) i protokołu UDP (User Datagram Protocol).
Wyczerpanie translatora SNAT
Rozważ następujące wskazówki, aby zapobiec wyczerpaniu SNAT:
Zasoby bramy translatora adresów sieciowych mają domyślny limit czasu bezczynności protokołu TCP w ciągu czterech minut. Limit czasu można skonfigurować przez maksymalnie 120 minut. Jeśli zmienisz to ustawienie na wyższą wartość niż domyślna, brama translatora adresów sieciowych będzie przechowywać przepływy dłużej, co może spowodować niepotrzebne obciążenie spisu portów SNAT.
Niepodzielne żądania (jedno żądanie na połączenie) ograniczają skalę, zmniejszają wydajność i zmniejszają niezawodność. Zamiast niepodzielnych żądań można ponownie użyć połączeń HTTP lub HTTPS, aby zmniejszyć liczbę połączeń i skojarzonych portów SNAT. W przypadku ponownego użycia połączeń aplikacja może być skalowana lepiej. Wydajność aplikacji poprawia się z powodu zmniejszenia nakładu pracy, nakładu pracy i kosztów operacji kryptograficznych podczas korzystania z protokołu Transport Layer Security (TLS).
Jeśli nie buforujesz wyników rozpoznawania nazw DNS, wyszukiwania systemu nazw domen (DNS) mogą wprowadzać wiele pojedynczych przepływów na woluminie. Buforowanie DNS umożliwia zmniejszenie liczby przepływów i zmniejszenie liczby portów SNAT. DNS to system nazewnictwa mapujący nazwy domen na adresy IP dla zasobów połączonych z Internetem lub z siecią prywatną.
Przepływy UDP, takie jak wyszukiwanie DNS, używają portów SNAT podczas limitu czasu bezczynności. Czasomierz limitu czasu bezczynności protokołu UDP jest stały na cztery minuty.
Użyj pul połączeń, aby kształtować wolumin połączenia.
Aby wyczyścić przepływy, nie porzucaj dyskretnie przepływów TCP ani nie polegaj na czasomierzach TCP. Jeśli nie zezwolisz na jawne zamknięcie połączenia tcp, połączenie TCP pozostanie otwarte. Systemy pośrednie i punkty końcowe zachowują to połączenie w użyciu, co sprawia, że port SNAT jest niedostępny dla innych połączeń. Ten antywzorzec może wyzwalać błędy aplikacji i wyczerpanie SNAT.
Nie zmieniaj wartości czasomierza powiązanego z protokołem TCP na poziomie systemu operacyjnego, chyba że znasz implikacje. Jeśli punkty końcowe połączenia mają niezgodne oczekiwania, stos TCP może odzyskać sprawność, ale może negatywnie wpłynąć na wydajność aplikacji. Zazwyczaj występuje podstawowy problem z projektem, jeśli trzeba zmienić wartości czasomierza. A jeśli aplikacja bazowa ma inne antywzorzecy i zmienia wartości czasomierza, możesz również przyspieszyć wyczerpanie SNAT.
Zapoznaj się z poniższymi wskazówkami, aby zwiększyć skalę i niezawodność usługi:
Rozważ skutki zmniejszenia limitu czasu bezczynności protokołu TCP do niższej wartości. Domyślny limit czasu bezczynności przez cztery minuty może z góry zwolnić spis portów SNAT.
Rozważ asynchroniczne wzorce sondowania dla długotrwałych operacji, aby zwolnić zasoby połączenia dla innych operacji.
Rozważ użycie wartości keepalives protokołu TCP lub utrzymywania warstwy aplikacji dla długotrwałych przepływów TCP, takich jak ponowne użycie połączeń TCP, aby zapobiec przekroczeniu limitu czasu w systemach pośrednich. Należy zwiększyć limit czasu bezczynności tylko w ostateczności i może nie rozwiązać głównej przyczyny. Długi limit czasu może powodować błędy o niskiej szybkości po wygaśnięciu limitu czasu. Może również powodować opóźnienia i niepotrzebne błędy. Można włączyć elementy utrzymania tcp z jednej strony połączenia, aby zachować połączenie aktywne po obu stronach.
Rozważ użycie utrzymywania protokołu UDP dla długotrwałych przepływów UDP, aby zapobiec przekraczaniu limitu czasu w systemach pośrednich. Po włączeniu protokołu UDP zachowanie po jednej stronie połączenia pozostaje aktywne tylko po jednej stronie połączenia. Aby zachować połączenie przy życiu, należy włączyć elementy utrzymania protokołu UDP po obu stronach połączenia.
Rozważ bezpieczne wzorce ponawiania prób, aby uniknąć agresywnych ponownych prób i pęknięć podczas przejściowych awarii lub odzyskiwania po awarii. Dla antywzorcowych połączeń niepodzielnych należy utworzyć nowe połączenie TCP dla każdej operacji HTTP. Połączenia niepodzielne tracą zasoby i uniemożliwiają aplikacji skalowanie dobrze.
Aby zwiększyć szybkość transakcji i zmniejszyć koszty zasobów aplikacji, zawsze potokuj wiele operacji do tego samego połączenia. Gdy aplikacja używa szyfrowania warstwy transportu, na przykład tls, nowe przetwarzanie połączeń zwiększa koszt. Aby uzyskać więcej wzorców najlepszych rozwiązań, zobacz Wzorce projektowania chmury platformy Azure.
Doskonałość operacyjna
Bramę translatora adresów sieciowych można używać z usługą Azure Kubernetes Service (AKS), ale zarządzanie bramą translatora adresów sieciowych nie jest uwzględniane w usłudze AKS. W przypadku przypisania bramy translatora adresów sieciowych do podsieci interfejsu sieci kontenerów (CNI) włączysz zasobniki usługi AKS do ruchu wychodzącego za pośrednictwem bramy translatora adresów sieciowych.
Jeśli używasz wielu bram NAT w różnych strefach lub regionach, zachowaj możliwość zarządzania infrastrukturą adresów IP dla ruchu wychodzącego przy użyciu prefiksów publicznych adresów IP platformy Azure lub prefiksów byOIP (bring-your-own IP). Nie można przypisać rozmiaru prefiksu IP większego niż 16 adresów IP (/28 rozmiar prefiksu) do bramy translatora adresów sieciowych.
Alerty usługi Azure Monitor umożliwiają monitorowanie i zgłaszanie alertów dotyczących użycia portów SNAT, przetworzonych lub porzuconych pakietów oraz ilości przesyłanych danych. Użyj dzienników przepływu sieciowej grupy zabezpieczeń, aby monitorować przepływ ruchu wychodzącego z wystąpień maszyn wirtualnych w podsieci skonfigurowanej przez bramę translatora adresów sieciowych.
Podczas konfigurowania podsieci z bramą translatora adresów sieciowych brama translatora adresów sieciowych zastępuje wszystkie pozostałe połączenia wychodzące z publicznym Internetem dla wszystkich maszyn wirtualnych w tej podsieci. Brama translatora adresów sieciowych ma pierwszeństwo przed modułem równoważenia obciążenia, niezależnie od reguł ruchu wychodzącego. Brama ma również pierwszeństwo przed publicznymi adresami IP przypisanymi bezpośrednio do maszyn wirtualnych. Platforma Azure śledzi kierunek przepływu i uniemożliwia routing asymetryczny. Ruch przychodzący, taki jak adres IP frontonu modułu równoważenia obciążenia, jest poprawnie tłumaczony i jest tłumaczony oddzielnie od ruchu wychodzącego za pośrednictwem bramy translatora adresów sieciowych. Ta separacja umożliwia bezproblemowe współistnienie usług przychodzących i wychodzących.
Zalecamy użycie bramy translatora adresów sieciowych jako domyślnej, aby włączyć łączność wychodzącą dla sieci wirtualnych. Brama translatora adresów sieciowych zapewnia wydajność i prostotę operacyjną w porównaniu z innymi technikami łączności wychodzącej na platformie Azure. Bramy translatora adresów sieciowych przydzielają porty SNAT na żądanie i używają bardziej wydajnego algorytmu, aby zapobiec konfliktom ponownego używania portów SNAT. Nie należy polegać na domyślnym antywzorzec łączności wychodzącej dla twojego majątku. Zamiast tego jawnie zdefiniuj konfigurację przy użyciu zasobów bramy translatora adresów sieciowych.
Niezawodność
Zasoby bramy translatora adresów sieciowych są wysoce dostępne w jednej strefie dostępności i obejmują wiele domen błędów. Bramę translatora adresów sieciowych można wdrożyć w strefie bez strefy , w której platforma Azure automatycznie wybiera strefę, aby umieścić bramę translatora adresów sieciowych lub odizolować bramę translatora adresów sieciowych do określonej strefy dostępności.
Aby zapewnić izolację strefy dostępności, każda podsieć musi mieć zasoby tylko w określonej strefie. Aby zaimplementować to podejście, można wykonać następujące czynności:
- Wdróż podsieć dla każdej ze stref dostępności, w których są wdrażane maszyny wirtualne.
- Wyrównywanie strefowych maszyn wirtualnych z pasującymi bramami translatora adresów sieciowych strefowych.
- Tworzenie oddzielnych stosów strefowych.
Na poniższym diagramie maszyna wirtualna w strefie dostępności 1 znajduje się w podsieci z innymi zasobami, które znajdują się również w strefie dostępności 1. Brama translatora adresów sieciowych jest skonfigurowana w strefie dostępności 1 do obsługi tej podsieci.
Sieci wirtualne i podsieci obejmują wszystkie strefy dostępności w regionie. Nie musisz dzielić ich według stref dostępności, aby pomieścić zasoby strefowe.
Zabezpieczenia
W przypadku bramy translatora adresów sieciowych poszczególne maszyny wirtualne lub inne zasoby obliczeniowe nie potrzebują publicznych adresów IP i mogą pozostać w pełni prywatne. Zasoby bez publicznego adresu IP mogą nadal uzyskiwać dostęp do źródeł zewnętrznych poza siecią wirtualną. Możesz skojarzyć prefiks publicznego adresu IP, aby upewnić się, że używasz ciągłego zestawu adresów IP na potrzeby łączności wychodzącej. Można skonfigurować docelowe reguły zapory na podstawie tej przewidywalnej listy adresów IP.
Typowym podejściem jest zaprojektowanie scenariusza wirtualnego urządzenia sieciowego tylko dla ruchu wychodzącego (WUS) z zaporami innych niż Microsoft lub serwerami proxy. Podczas wdrażania bramy translatora adresów sieciowych w podsieci z zestawem skalowania maszyn wirtualnych urządzeń WUS te urządzenia WUS używają co najmniej jednego adresu bramy translatora adresów sieciowych na potrzeby łączności wychodzącej zamiast adresu IP modułu równoważenia obciążenia lub poszczególnych adresów IP. Aby zastosować ten scenariusz z usługą Azure Firewall, zobacz Integrowanie usługi Azure Firewall ze standardowym modułem równoważenia obciążenia platformy Azure.
Możesz użyć funkcji alertu Microsoft Defender dla Chmury do monitorowania pod kątem wszelkich podejrzanych połączeń wychodzących w bramie translatora adresów sieciowych.
Współautorzy
Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.
Główny autor:
- Ethan Haslett | Starszy architekt rozwiązań w chmurze
Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.
Następne kroki
- Microsoft Well-Architected Framework
- Samouczek: tworzenie bramy translatora adresów sieciowych przy użyciu witryny Azure Portal
- Rekomendacje do korzystania ze stref dostępności i regionów