Wysoka dostępność i równoważenie obciążenia prywatnych łączników sieciowych i aplikacji
W tym artykule wyjaśniono, jak działa dystrybucja ruchu w przypadku wdrożenia serwera proxy aplikacji. Dowiedz się, jak ruch jest dystrybuowany między użytkownikami i łącznikami, wraz z poradami dotyczącymi optymalizowania wydajności łącznika. Dowiedz się, jak ruch przepływa pomiędzy łącznikami a serwerami aplikacji zaplecza, z zaleceniami dotyczącymi równoważenia obciążenia między wieloma serwerami zaplecza.
Dystrybucja ruchu między łącznikami
Łączniki ustanawiają swoje połączenia na podstawie zasad wysokiej dostępności. Nie ma gwarancji, że ruch jest równomiernie rozkładany między łącznikami i nie ma przywiązania sesji. Jednak sposób użycia różni się, a żądania są losowo wysyłane do wystąpień usługi serwera proxy aplikacji. W rezultacie ruch jest zwykle dystrybuowany niemal równomiernie między łącznikami. Diagram i kroki ilustrują sposób nawiązywania połączeń między użytkownikami i łącznikami.
- Użytkownik na urządzeniu klienckim próbuje uzyskać dostęp do aplikacji lokalnej opublikowanej za pośrednictwem serwera proxy aplikacji.
- Żądanie przechodzi przez usługę Azure Load Balancer w celu określenia, które wystąpienie usługi serwera proxy aplikacji powinno przyjąć żądanie. W regionie dostępnych jest dziesiątki instancji przyjmujących żądania ruchu. Ta metoda pomaga równomiernie dystrybuować ruch między wystąpieniami usługi.
- Żądanie jest wysyłane do Service Bus.
- Usługa Service Bus sygnalizuje dostępny łącznik. Łącznik następnie pobiera żądanie z usługi Service Bus.
- W kroku 2 żądania przechodzą do różnych wystąpień usługi serwera proxy aplikacji, więc połączenia będą częściej wykonywane z różnymi łącznikami. W związku z tym łączniki są prawie równomiernie używane w grupie.
- Łącznik przekazuje żądanie do serwera zaplecza aplikacji. Następnie aplikacja wysyła odpowiedź z powrotem do łącznika.
- Łącznik realizuje odpowiedź, otwierając połączenie wychodzące do instancji usługi, z której pochodzi żądanie. Następnie to połączenie jest natychmiast zamknięte. Domyślnie każdy łącznik jest ograniczony do 200 współbieżnych połączeń wychodzących.
- Odpowiedź jest następnie przekazywana z wystąpienia usługi z powrotem do klienta.
- Kolejne żądania z tego samego połączenia powtórzą kroki.
Aplikacja często ma wiele zasobów i otwiera wiele połączeń w przypadku obciążenia. Każde połączenie przechodzi kroki, aby zostać przydzielone do instancji usługi. Jeśli połączenie nie jest sparowane z łącznikiem, wybierz nowy dostępny łącznik.
Najlepsze rozwiązania dotyczące wysokiej dostępności łączników
Ze względu na sposób dystrybucji ruchu między łącznikami w celu zapewnienia wysokiej dostępności należy zawsze mieć co najmniej dwa łączniki w grupie łączników. Trzy łączniki są preferowane, aby zapewnić dodatkowy bufor między łącznikami. Aby określić odpowiednią liczbę potrzebnych łączników, postępuj zgodnie z dokumentacją dotyczącą planowania pojemności.
Umieść łączniki na różnych połączeniach wychodzących, aby uniknąć pojedynczego punktu awarii. Jeśli łączniki korzystają z tego samego połączenia wychodzącego, problem sieciowy z połączeniem ma wpływ na wszystkie łączniki korzystające z niego.
Unikaj wymuszania ponownego uruchamiania łączników po nawiązaniu połączenia z aplikacjami produkcyjnymi. Może to negatywnie wpłynąć na rozkład ruchu między łącznikami. Ponowne uruchamianie łączników powoduje niedostępność większej liczby łączników i wymusza nawiązywanie połączeń z pozostałym dostępnym łącznikiem. Wynikiem jest początkowo nierównomierne użycie łączników.
Unikaj wszystkich form inspekcji inline komunikacji protokołu Transport Layer Security (TLS) między łącznikami a platformą Azure dla ruchu wychodzącego. Ten typ inspekcji liniowej powoduje pogorszenie przepływu komunikacji.
Upewnij się, że aktualizacje automatyczne są uruchomione dla łączników. Jeśli usługa aktualizatora łącznika sieci prywatnej jest uruchomiona, łączniki są aktualizowane automatycznie i odbierane najnowsze uaktualnienia. Jeśli na serwerze nie widzisz usługi Aktualizatora łączników, musisz ponownie zainstalować łącznik, aby uzyskać aktualizacje.
Przepływ ruchu między łącznikami i serwerami aplikacji zaplecza
Innym kluczowym obszarem, w którym wysoka dostępność jest czynnikiem, jest połączenie między łącznikami a serwerami zaplecza. Po opublikowaniu aplikacji za pośrednictwem serwera proxy aplikacji Microsoft Entra ruch od użytkowników do aplikacji przepływa przez trzy przeskoki:
- Użytkownik łączy się z publicznym punktem końcowym usługi proxy aplikacji Microsoft Entra na platformie Azure. Połączenie jest ustanawiane między źródłowym adresem IP klienta (publicznym) klienta i adresem IP punktu końcowego serwera proxy aplikacji.
- Łącznik sieci prywatnej ściąga żądanie HTTP klienta z usługi serwera proxy aplikacji.
- Łącznik sieci prywatnej łączy się z aplikacją docelową. Łącznik używa własnego adresu IP do nawiązywania połączenia.
X-Forwarded-For header field considerations (Zagadnienia dotyczące pola nagłówka X-Forwarded-For)
W niektórych sytuacjach (takich jak inspekcja, równoważenie obciążenia itd.), udostępnianie źródłowego adresu IP klienta zewnętrznego ze środowiskiem lokalnym jest wymagane. Aby rozwiązać ten problem, łącznik sieci prywatnej firmy Microsoft dodaje pole nagłówka X-Forwarded-For z źródłowym adresem IP klienta (publicznym) do żądania HTTP. Odpowiednie urządzenie sieciowe (moduł równoważenia obciążenia, zapora) lub serwer internetowy lub aplikacja zaplecza mogą następnie odczytywać i używać tych informacji.
Najlepsze rozwiązania dotyczące równoważenia obciążenia między wieloma serwerami aplikacji
Równoważenie obciążenia jest ważne, gdy grupa łączników przypisana do aplikacji proxy ma co najmniej dwa łączniki. Równoważenie obciążenia jest również ważne, gdy uruchamiasz aplikację internetową zaplecza na wielu serwerach.
Scenariusz 1. Aplikacja zaplecza nie wymaga trwałości sesji
Najprostszym scenariuszem jest to, że aplikacja internetowa zaplecza nie wymaga trwałości sesji (trwałość sesji). Instancja aplikacji zaplecza obsługuje żądania użytkowników w grupie serwerów. Możesz użyć modułu równoważenia obciążenia warstwy 4 i skonfigurować go bez afinity. Niektóre opcje obejmują równoważenie obciążenia sieciowego firmy Microsoft i usługę Azure Load Balancer lub moduł równoważenia obciążenia od innego dostawcy. Alternatywnie skonfiguruj strategię systemu nazw domen okrężnych (DNS).
Scenariusz 2. Aplikacja zaplecza wymaga trwałości sesji
W tym scenariuszu aplikacja internetowa zaplecza wymaga trwałości sesji (trwałość sesji) podczas uwierzytelnionej sesji. Instancja aplikacji backendowej obsługuje żądania użytkowników. Żądania te są uruchamiane na tym samym serwerze w farmie serwerów. Ten scenariusz może być bardziej skomplikowany, ponieważ klient zwykle ustanawia wiele połączeń z usługą serwera proxy aplikacji. Żądania dotyczące różnych połączeń mogą docierać do różnych łączników i serwerów w farmie. Ponieważ każdy łącznik używa własnego adresu IP do tej komunikacji, load balancer nie może zapewnić utrzymania sesji w oparciu o adres IP łączników. Nie można użyć koligacji źródłowego adresu IP. Poniżej przedstawiono kilka opcji scenariusza 2:
Opcja 1. Bazuj trwałość sesji na plikach cookie sesji ustawionych przez moduł równoważenia obciążenia. Ta opcja jest zalecana, ponieważ umożliwia równomierne rozłożenie obciążenia między serwerami zaplecza. Wymaga modułu równoważenia obciążenia warstwy 7 z tą funkcją i może obsługiwać ruch HTTP i przerywać połączenie TLS. Możesz użyć Azure Application Gateway (przyległość sesji) lub modułu równoważenia obciążenia od innego dostawcy.
Opcja 2: Oparta trwałość sesji na polu nagłówka X-Forwarded-For. Ta opcja wymaga modułu równoważenia obciążenia warstwy 7 z tą funkcją i może obsługiwać ruch HTTP i przerywać połączenie TLS.
Opcja 3. Skonfiguruj aplikację zaplecza tak, aby nie wymagała trwałości sesji.
Aby zrozumieć wymagania dotyczące równoważenia obciążenia aplikacji zaplecza, zapoznaj się z dokumentacją dostawcy oprogramowania.