Network Load Balancing (NLB) na Windows Server — wysoka dostępność usług

Czym jest Network Load Balancing (NLB)?

Network Load Balancing (NLB) to wbudowana funkcja systemu Windows Server, która umożliwia rozłożenie ruchu sieciowego TCP/IP na kilka serwerów tworzących jeden klaster wirtualny. Klienci łączą się z jednym adresem IP klastra, a NLB automatycznie kieruje żądania do dostępnych węzłów — zapewniając wysoką dostępność (HA) i skalowalność aplikacji serwerowych.

NLB działa na warstwie 4 modelu OSI (transportowej) i obsługuje protokoły TCP oraz UDP. W odróżnieniu od sprzętowych load balancerów, nie wymaga żadnego dodatkowego sprzętu — wystarczy rola systemowa dostępna w każdej edycji Windows Server (Standard i Datacenter).

Funkcja jest dostępna w systemach od Windows Server 2003 aż do najnowszego Windows Server 2025. Obsługuje do 32 węzłów w jednym klastrze i automatycznie wykrywa awarie hostów — przenosząc ruch na sprawne serwery w ciągu około 10 sekund.

Zastosowania NLB — kiedy warto go używać?

NLB najlepiej sprawdza się w scenariuszach, gdzie aplikacja jest bezstanowa (stateless) — czyli nie przechowuje sesji użytkownika na konkretnym serwerze. Oto najczęstsze przypadki użycia:

Architektura klastra NLB — jak to działa?

Klaster NLB składa się z 2 do 32 hostów (węzłów), które współdzielą jeden lub więcej wirtualnych adresów IP (VIP). Klienci łączą się z VIP-em, a NLB na każdym hoście decyduje, czy dany pakiet powinien zostać obsłużony lokalnie, czy odrzucony.

Kluczowe elementy architektury

• Cluster IP (VIP) — wspólny adres IP, pod którym klaster jest widoczny w sieci. Wymaga wpisu DNS.
• Dedicated IP (DIP) — indywidualny adres IP każdego hosta, używany do zarządzania i komunikacji między węzłami.
• Sterownik NLB (nlb.sys) — filtr NDIS zainstalowany na karcie sieciowej, przechwytujący ruch i podejmujący decyzje o dystrybucji.
• Heartbeat — pakiety wymieniane między hostami co 1-2 sekundy, pozwalające wykryć awarię węzła.
• Convergence — proces zbieżności, podczas którego hosty negocjują podział ruchu po zmianie składu klastra.

Mechanizm działania jest prosty: każdy host w klastrze otrzymuje każdy pakiet przychodzący na VIP. Sterownik NLB na podstawie algorytmu hashowania (bazującego na adresie IP klienta i porcie) decyduje, czy dany host powinien obsłużyć ten pakiet. Dzięki temu nie ma centralnego punktu awarii — każdy host podejmuje decyzję niezależnie.

Unicast vs Multicast vs IGMP Multicast — tryby operacji

Wybór trybu operacji to jedna z najważniejszych decyzji przy konfiguracji NLB. Każdy tryb ma swoje zalety i ograniczenia:

Konfiguracja NLB krok po kroku

Poniżej przedstawiamy kompletną instrukcję konfiguracji klastra NLB na Windows Server 2022 — zarówno przez GUI (Server Manager), jak i PowerShell.

Wymagania wstępne

• Minimum 2 serwery z Windows Server (Standard lub Datacenter)
• Wszystkie hosty w tej samej podsieci
• Statyczne adresy IP na kartach sieciowych używanych przez NLB (DHCP jest automatycznie wyłączany)
• Wpis DNS dla adresu IP klastra (VIP)
• Odpowiednie licencje CAL Windows Server dla wszystkich łączących się klientów

Krok 1: Instalacja roli NLB

Metoda GUI (Server Manager):

1. Otwórz Server Manager → kliknij Add Roles and Features
2. W sekcji Features zaznacz Network Load Balancing
3. Kliknij Install — restart serwera nie jest wymagany

Metoda PowerShell (zalecana):

Install-WindowsFeature NLB -IncludeManagementTools
# Wykonaj na WSZYSTKICH serwerach, ktore beda czescia klastra

Krok 2: Tworzenie klastra NLB

Metoda GUI:

1. Otwórz Server Manager → Tools → Network Load Balancing Manager
2. Kliknij prawym na Network Load Balancing Clusters → New Cluster
3. Wpisz nazwę lub IP pierwszego hosta → kliknij Connect
4. Wybierz interfejs sieciowy → Next
5. Ustaw Priority (Unique Host ID) = 1 dla pierwszego hosta
6. Na ekranie Cluster IP kliknij Add i wpisz wirtualny adres IP klastra
7. Ustaw Full Internet Name (np. webfarm.firma.pl) i wybierz tryb operacji (Multicast)
8. Skonfiguruj Port Rules (domyślnie: 0-65535, wszystkie porty)
9. Kliknij Finish

Metoda PowerShell:

# Tworzenie nowego klastra NLB
New-NlbCluster -InterfaceName "Ethernet" -ClusterName "WebFarm" -ClusterPrimaryIP "192.168.1.100" -SubnetMask "255.255.255.0" -OperationMode "Multicast"

# Dodawanie drugiego hosta do klastra
Add-NlbClusterNode -InterfaceName "Ethernet" -NewNodeName "Server02" -NewNodeInterface "Ethernet"

# Sprawdzenie stanu klastra
Get-NlbCluster | Get-NlbClusterNode

Krok 3: Konfiguracja reguł portów (Port Rules)

Reguły portów określają, które porty i protokoły mają być równoważone. Domyślna reguła obejmuje wszystkie porty — w produkcji warto ją zawęzić:

# Usuniecie domyslnej reguly (wszystkie porty)
Get-NlbClusterPortRule | Remove-NlbClusterPortRule -Force

# Regula dla HTTP/HTTPS (porty 80 i 443)
Add-NlbClusterPortRule -StartPort 80 -EndPort 80 -Protocol "TCP" -Mode "Multiple" -Affinity "Single" -EqualLoad

Add-NlbClusterPortRule -StartPort 443 -EndPort 443 -Protocol "TCP" -Mode "Multiple" -Affinity "Single" -EqualLoad

# Blokada niechcianego portu (np. Telnet)
Add-NlbClusterPortRule -StartPort 23 -EndPort 23 -Protocol "Both" -Mode "Disabled"

Tryby filtrowania (Affinity)

NLB vs Failover Clustering — porównanie technologii HA

Windows Server oferuje dwie główne technologie wysokiej dostępności. Ich wybór zależy od typu aplikacji:

Monitorowanie i rozwiązywanie problemów

Skuteczne zarządzanie klastrem NLB wymaga monitorowania stanu węzłów i analizy logów. Oto najważniejsze narzędzia i komendy:

Sprawdzanie stanu klastra (PowerShell)

# Status wszystkich wezlow
Get-NlbClusterNode | Format-Table Name, State, StatusCode

# Szczegoly klastra
Get-NlbCluster | Format-List *

# Reguly portow
Get-NlbClusterPortRule | Format-Table StartPort, EndPort, Protocol, Mode, Affinity

# Drainstop - zatrzymanie hosta z dokoczeniem aktywnych sesji
Stop-NlbClusterNode -HostName "Server01" -Drain

# Ponowne uruchomienie hosta w klastrze
Start-NlbClusterNode -HostName "Server01"

Dziennik zdarzeń (Event Log)

NLB rejestruje wszystkie zdarzenia w Event Viewer → System log, zródło: NLB. Kluczowe zdarzenia do monitorowania:

• Event ID 16 — host dołączył do klastra (convergence zakończona)
• Event ID 17 — convergence rozpoczęta (host dodany lub usunięty)
• Event ID 20 — host został wykluczony z klastra (awaria heartbeat)
• Event ID 33 — NLB nie może przypisać adresu MAC (problem z trybem unicast)

Typowe problemy i rozwiązania

Najlepsze praktyki wdrożenia NLB

1. Używaj dedykowanej karty sieciowej — w trybie Unicast karta NLB nie służy do komunikacji między hostami. Druga karta (management NIC) to standard w produkcji.
2. Statyczne adresy IP — NLB wyłącza DHCP. Upewnij się, że wszystkie hosty mają statyczne IP przed konfiguracją.
3. Testuj failover regularnie — używaj Stop-NlbClusterNode -Drain do symulacji awarii w kontrolowany sposób.
4. Monitoruj Event Log — skonfiguruj alerty na zdarzenia ID 17 i 20 w systemie monitoringu.
5. Dokumentuj konfigurację — zapisuj VIP, tryb, reguły portów i affinity.
6. Nie mieszaj NLB z Failover Clustering na tym samym serwerze.
7. Skonfiguruj DNS Round Robin jako dodatkową warstwę — VIP w DNS + TTL 300s.
8. Aktualizuj hosty po kolei (rolling update) — Stop-NlbClusterNode -Drain, aktualizacja, Start-NlbClusterNode.

Nowoczesne alternatywy dla NLB

NLB to sprawdzona technologia, ale w 2026 roku istnieją nowoczesniejsze rozwiązania — szczególnie jeśli infrastruktura jest hybrydowa lub chmurowa:

Często zadawane pytania (FAQ)

Podsumowanie

Network Load Balancing to potężna, darmowa technologia wbudowana w Windows Server, która zapewnia wysoką dostępność i skalowalność aplikacji bezstanowych. Idealna do web farm IIS, bramek VPN, serwerów FTP i RDS Gateway — nie wymaga dodatkowego sprzętu ani oprogramowania.

Kluczowe wnioski z tego przewodnika:

• NLB = load balancing L4 dla aplikacji bezstanowych; Failover Clustering = failover dla aplikacji stanowych
• Wybierz Multicast w środowiskach wirtualnych, Unicast z dwiema kartami w fizycznych
• Affinity Single to bezpieczny domyślny — zmień na None tylko dla w pełni bezstanowych aplikacji
• Regularnie testuj failover za pomocą Stop-NlbClusterNode -Drain
• Rozważ nowoczesne alternatywy (HAProxy, Azure LB) dla scenariuszy L7 lub chmurowych