Windows Server’da NLB ile Network Load Balancing Kurulumu

Yazar:komut.io ekibi Windows Server Ağ Yönetimi
0 Yorum

Yıllar önce bir müşterimizin web sunucusu gece 2’de çöktüğünde, o güne kadar “NLB kurarız, yedekli çalışır, sorun olmaz” diye geçiştirdiğimiz konuyu ciddiye almak zorunda kaldım. O geceden bu yana Windows Network Load Balancing konusunda öğrendiklerimi burada toparlıyorum. NLB, Microsoft’un Windows Server’a dahil ettiği, özellikle web ve terminal hizmetleri için kullanılan, kurulumu görece kolay ama nüansları olan bir yük dengeleme çözümü. Hardware load balancer kadar güçlü değil, evet, ama lisans maliyeti sıfır ve doğru kurulursa gayet iş görüyor.

NLB Nedir, Ne Değildir?

Windows NLB, birden fazla sunucuyu tek bir sanal IP adresi altında toplayarak gelen ağ trafiğini bu sunucular arasında dağıtan bir Windows Server özelliği. Temel mantığı şu: tüm node’lar aynı sanal IP’yi “duyuruyor”, gelen paket hangi node’a gidecek karar algoritmayla belirleniyor.

Ama şunu net söyleyelim: NLB bir stateless yük dengeleyici. Veritabanı gibi durum bilgisi gerektiren servislerde kullanmayın. Klasik kullanım alanları şunlar:

  • IIS tabanlı web uygulamaları
  • Remote Desktop Services (RDS) farm yapıları
  • VPN gateway cluster’ları
  • Stateless API endpoint’leri

NLB’nin yapmadığı şeyler de var. Health check mekanizması built-in olarak yok, yani bir node kapansa trafik otomatik olarak diğerine yönlenmez, bunun için ek konfigürasyon gerekir. SQL Server, Active Directory Domain Services gibi servisler için NLB’yi sakın kullanmayın, o iş Failover Clustering’e bakıyor.

Ortam Gereksinimler ve Mimari

Basit iki node’lu bir senaryo düşünelim. İki Windows Server makinemiz var, bunların üzerine IIS kurulu ve aynı web uygulamasını servis ediyorlar. Amacımız bu iki sunucuyu NLB cluster’ına alıp tek bir IP üzerinden erişilebilir kılmak.

Her node’da olması gerekenler:

  • Minimum 2 NIC: Biri NLB trafiği için (cluster NIC), diğeri yönetim trafiği için. Tek NIC ile de çalışır ama production’da kesinlikle önermem.
  • Statik IP adresleri: Her iki NIC’te de DHCP kullanmayın.
  • Aynı Windows Server versiyonu: Karışık versiyon cluster’ları sorun çıkarır.
  • Domain üyeliği zorunlu değil: NLB için domain gerekmez, workgroup’ta da çalışır.

Örnek IP planımız şöyle olsun:

  • Node1 Cluster NIC: 192.168.10.11
  • Node2 Cluster NIC: 192.168.10.12
  • Sanal Cluster IP: 192.168.10.10
  • Yönetim NIC’leri: 192.168.20.x subnet’inde

NLB Feature Kurulumu

PowerShell ile kurmak hem hızlı hem de tekrarlanabilir. Her iki node’da aşağıdaki komutu çalıştırın:

Install-WindowsFeature NLB -IncludeManagementTools
Install-WindowsFeature RSAT-NLB

Kurulum tamamlandıktan sonra doğrulama için:

Get-WindowsFeature -Name NLB, RSAT-NLB | Select-Object Name, InstallState

GUI üzerinden gitmek isteyenler Server Manager > Add Roles and Features > Features adımında “Network Load Balancing” seçeneğini işaretleyebilir. Ama ciddiye alınan bir ortamda her şeyi script ile yapın, bir gün tekrar ihtiyacınız olacak.

Cluster Oluşturma: PowerShell ile Adım Adım

İlk node’da cluster’ı başlatıyoruz. Buradaki parametreleri iyi anlayın, sonradan değiştirmek bazen cluster’ı baştan kurmak kadar zahmetli olabiliyor.

# İlk node üzerinde çalıştırın
New-NlbCluster `
    -HostName "NODE1" `
    -ClusterName "WebFarm" `
    -InterfaceName "Ethernet" `
    -ClusterPrimaryIP "192.168.10.10" `
    -SubnetMask "255.255.255.0" `
    -OperationMode "Multicast"

OperationMode parametresi kritik. İki seçenek var:

  • Unicast: Tüm node’lar aynı MAC adresini paylaşır. Switch’te sorun yaratabilir, node’lar birbirini göremez hale gelebilir (bu yüzden ikinci NIC şart olur).
  • Multicast: Her node kendi MAC adresini korur, cluster için ayrı bir multicast MAC oluşturulur. Genellikle daha temiz çalışır ama bazı eski switch’lerde ARP problemi yaşanabilir.

Unicast modunda node’ların birbirleriyle konuşamaması meselesini yönetim NIC’i çözer. Bu yüzden iki NIC konusuna tekrar vurgu yapıyorum.

Şimdi ikinci node’u cluster’a ekleyelim:

# İkinci node üzerinde çalıştırın
Add-NlbClusterNode `
    -HostName "NODE1" `
    -NewNodeName "NODE2" `
    -NewNodeInterface "Ethernet"

Dikkat: HostName parametresi mevcut bir cluster node’unu gösteriyor, yeni node değil. Yani NODE1 üzerinden ya da uzaktan bu komutu verirken hedef cluster node’unu belirtiyorsunuz.

Cluster durumunu kontrol edin:

Get-NlbCluster
Get-NlbClusterNode

Her iki node’un da “Converged” durumunda göründüğünü görmelisiniz. “Converging” durumu geçici, bir süre bekleyin. “Stopped” görüyorsanız sorun var demektir.

Port Rules Konfigürasyonu

NLB’nin en kritik kısmı port kuralları. Default olarak tüm portlar için tek bir kural gelir (0-65535 arası), bu production için yeterli değil. Kendi kurallarınızı tanımlayın.

Mevcut kuralları silin ve sıfırdan oluşturun:

# Mevcut default kuralı sil
Get-NlbClusterPortRule | Remove-NlbClusterPortRule -Force

# HTTP için kural
Add-NlbClusterPortRule `
    -IP "192.168.10.10" `
    -StartPort 80 `
    -EndPort 80 `
    -Protocol TCP `
    -Affinity Single `
    -LoadWeight Equal

# HTTPS için kural
Add-NlbClusterPortRule `
    -IP "192.168.10.10" `
    -StartPort 443 `
    -EndPort 443 `
    -Protocol TCP `
    -Affinity Single `
    -LoadWeight Equal

Affinity parametresi çok önemli, doğru anlamak lazım:

  • None: Aynı istemciden gelen bağlantılar farklı node’lara gidebilir. Stateless uygulamalar için uygundur.
  • Single: Aynı kaynak IP, hep aynı node’a gider. Session tabanlı uygulamalar için kullanın.
  • Network: Aynı C sınıfı ağdan gelen trafik aynı node’a gider. NAT arkasındaki çok kullanıcılı ortamlar için.

Pratik deneyimden bir not: Eğer uygulamanızda session sticky gerekiyorsa ve bunu uygulama katmanında çözemediyseniz Affinity Single kurtarır sizi. Ama mümkünse sticky session’ı uygulama katmanında çözün, çok daha sağlıklı.

Cluster Yönetim IP Adresi Eklemek

Birden fazla IP ile cluster çalıştırmak istiyorsanız, örneğin hem HTTP hem de farklı bir servis için ayrı IP:

Add-NlbClusterVip `
    -IP "192.168.10.20" `
    -SubnetMask "255.255.255.0"

Sonra bu yeni IP için de port kuralı tanımlayabilirsiniz.

Node’ları Yönetmek: Drain ve Suspend

Production ortamında en sık kullanacağınız komutlar bunlar. Bir node’u bakıma almadan önce üzerindeki aktif bağlantıların yeni bağlantı almayı kesmesi ama mevcutları tamamlaması için “drain” yaparsınız.

# NODE2'yi draining moduna al (yeni bağlantı alma ama mevcutları bitir)
Stop-NlbClusterNode -HostName "NODE2" -Drain

# NODE2'yi tamamen durdur
Stop-NlbClusterNode -HostName "NODE2"

# Bakım bitti, NODE2'yi tekrar başlat
Start-NlbClusterNode -HostName "NODE2"

Cluster durumunu izlemek için:

# Anlık durum
Get-NlbClusterNode | Select-Object Name, State

# Detaylı istatistik (WMI üzerinden)
Get-WmiObject -Namespace "rootMicrosoftNLB" -Class "MicrosoftNLB_Node"

Firewall ve Ağ Konfigürasyonu

NLB’nin çalışması için Windows Firewall’da bazı izinler gerekiyor. Yönetim trafiği için:

# NLB yönetim portlarına izin ver
netsh advfirewall firewall add rule `
    name="NLB Remote Management" `
    protocol=TCP `
    dir=in `
    localport=3343 `
    action=allow

# ICMP'e izin ver (NLB node iletişimi için önemli)
netsh advfirewall firewall add rule `
    name="NLB ICMP" `
    protocol=icmpv4 `
    dir=in `
    action=allow

Switch konfigürasyonu da göz ardı edilmeyen bir konu. Multicast mod kullanıyorsanız ve switch’iniz multicast MAC için ARP proxy yapamıyorsa, switch’te statik ARP girişi eklemeniz gerekebilir. Cisco switch üzerinde örnek:

# Cisco IOS - Switch'te statik ARP girişi
arp 192.168.10.10 03bf-0a0a-000a arpa

MAC adresi format şöyle oluşuyor: Multicast modda NLB, cluster IP’sinden türetilmiş bir multicast MAC üretiyor. nlb.exe show cluster komutuyla bu MAC’i görebilirsiniz.

Gerçek Dünya Senaryosu: IIS Farm Kurulumu

Şimdi pratik bir senaryo üzerinden gidelim. İki node’lu bir IIS web farm kuracağız, her iki node’da da aynı uygulama çalışacak.

Önce her iki node’da IIS’i kurun:

Install-WindowsFeature Web-Server, Web-Asp-Net45, Web-Mgmt-Console

Uygulama havuzlarının aynı identity altında çalışmasını sağlayın. Domain ortamındaysanız bir servis hesabı kullanın:

# Her iki node'da uygulama havuzunu yapılandır
Import-Module WebAdministration

Set-ItemProperty "IIS:AppPoolsDefaultAppPool" `
    -Name processModel.userName `
    -Value "DOMAINsvc_webapp"

Set-ItemProperty "IIS:AppPoolsDefaultAppPool" `
    -Name processModel.password `
    -Value "P@ssw0rd123"

Session state meselesini çözmek için ya SQL Server session store kullanın ya da uygulamayı stateless yapın. ASP.NET uygulamalarında web.config’e şunu ekleyin:

# Web.config'de session state ayarı (SQL Server session)
# Bu XML satırını doğrudan eklemek için PowerShell
$webConfigPath = "C:inetpubwwwrootuygulamaweb.config"
$xml = [xml](Get-Content $webConfigPath)
$sessionState = $xml.configuration["system.web"].sessionState
$sessionState.mode = "SQLServer"
$sessionState.sqlConnectionString = "data source=SQLSERVER01;Initial Catalog=ASPState;uid=aspnet_user;pwd=P@ssw0rd"
$xml.Save($webConfigPath)

Monitoring ve Troubleshooting

NLB’de en sık karşılaşılan sorunlar ve çözümleri:

Convergence sorunu: Node’lar birbirini bulamıyorsa:

# Node'lar arası iletişimi test et
Test-NetConnection -ComputerName "NODE2" -Port 3343

# NLB event loglarını kontrol et
Get-WinEvent -LogName "System" | Where-Object {$_.ProviderName -eq "NLB"} | Select-Object -First 20

# NLB servisini yeniden başlat
Restart-Service -Name NLB

Cluster IP’ye erişilemiyor: ARP sorunu olabilir. Switch’teki ARP tablosunu kontrol edin. Unicast moddaysanız switch, aynı porta gelen multicast trafiği flood edebilir, bu performans sorununa yol açar.

# Cluster IP'ye ping testi
Test-NetConnection -ComputerName "192.168.10.10" -Port 80

# Hangi node cevap veriyor? (TTL değerine göre anlayabilirsiniz)
ping 192.168.10.10 -t

# NLB istatistikleri
nlb.exe query cluster:192.168.10.10

Tek node tüm trafiği alıyor: Port rule’larında yük dağılımını kontrol edin:

Get-NlbClusterPortRule | Format-List *

LoadWeight değerlerinin eşit olduğundan, Affinity ayarının ihtiyaca uygun olduğundan emin olun.

NLB’nin Sınırlamaları ve Alternatifler

Dürüst olmak gerekirse, NLB’nin ciddi sınırlamaları var:

  • Maksimum 32 node destekler (pratik olarak 8’in üzerini önermem)
  • Health check yok, ölü node’a trafik gitmeye devam eder (bu gerçekten büyük problem)
  • Layer 4 yük dengeleme, içerik tabanlı yönlendirme yapamaz
  • IPv6 desteği kısıtlı

Health check meselesini çözmek için SCOM, Nagios veya basit bir PowerShell script döngüsü kullanabilirsiniz:

# Basit health check script - Task Scheduler'a eklenebilir
$nodes = @("NODE1", "NODE2")
$clusterIP = "192.168.10.10"

foreach ($node in $nodes) {
    $testResult = Test-NetConnection -ComputerName $node -Port 80 -WarningAction SilentlyContinue
    
    if (-not $testResult.TcpTestSucceeded) {
        Write-EventLog -LogName Application -Source "NLB-HealthCheck" `
            -EventId 1001 -EntryType Warning `
            -Message "$node is not responding on port 80. Removing from cluster."
        
        # Node'u cluster'dan çıkar
        Stop-NlbClusterNode -HostName $node
        
        # Alert gönder
        Send-MailMessage -From "[email protected]" -To "[email protected]" `
            -SmtpServer "mail.sirket.com" `
            -Subject "NLB Alert: $node Down" `
            -Body "$node cluster'dan çıkarıldı. Kontrol edin."
    }
}

Bu script kaba bir çözüm ama NLB’nin olmayan health check özelliğini telafi etmek için başlangıç noktası.

Eğer daha gelişmiş ihtiyaçlarınız varsa, Windows üzerinde ARR (Application Request Routing) ile IIS tabanlı bir reverse proxy kurabilirsiniz. Ya da ortam bütçesi varsa F5, Citrix NetScaler veya HAProxy gibi dedicated çözümlere bakın.

Sonuç

NLB, ücretli alternatiflerle kıyaslandığında oldukça mütevazı bir çözüm. Ama doğru senaryo için, yani stateless web servislerinde, düşük-orta ölçekli ortamlarda, bütçenin sınırlı olduğu durumlarda gayet iş görüyor. Gece 2’deki o bakım penceresinde IIS farm’ımızı NLB ile yeniden yapılandırdık, sabah kullanıcıların haberi bile olmadı.

Önemli hatırlatmalar:

  • Mutlaka iki NIC kullanın, tek NIC kurulumu production’da sorun çıkarır
  • Multicast modunu tercih edin, switch konfigürasyonuna dikkat edin
  • Port rule’larını default bırakmayın, ihtiyaca göre özelleştirin
  • Health check için harici monitoring ekleyin, NLB bunu sizin için yapmaz
  • Session affinity gereksinimini baştan netleştirin

Her şeyi PowerShell ile script haline getirin. NLB cluster’ını sıfırdan kurmak için tek bir script dosyanızın olması, bir gece yarısı acilinde dakikalar içinde sistemi ayağa kaldırmanızı sağlar. O script dosyasını kayıt altına alın, versiyon kontrolüne ekleyin, meslektaşlarınızla paylaşın. Sistem yöneticiliğinde en değerli şey yazılı prosedür ve tekrar edilebilir süreçler.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir