NIC Teaming ile Ağ Bant Genişliği ve Yedeklilik Sağlama

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

Veri merkezinde geçirdiğim yıllar boyunca en çok hangi konuda gereksiz panik yaşandığını sorsanız, cevabım kesinlikle ağ bağlantısı kayıpları olur. Bir production sunucusunun NIC’i çöktüğünde, o an odada bulunan herkesin yüzündeki ifadeyi hatırlıyorum. Oysa bu senaryoların büyük çoğunluğu, NIC Teaming ile çoktan önlenmiş olabilirdi. Windows Server ortamlarında NIC Teaming hem bir lüks hem de bir zorunluluktur; bu yazıda bu konuyu tüm gerçekçiliğiyle ele alacağız.

NIC Teaming Nedir ve Neden Önemlidir?

NIC Teaming, birden fazla fiziksel ağ arabirim kartını (Network Interface Card) mantıksal olarak tek bir arabirim gibi davranacak şekilde birleştirme işlemidir. Windows Server dünyasında bu özellik LBFO (Load Balancing and Failover) olarak da anılır. Temel olarak iki şey elde edersiniz: bant genişliği artışı ve yedeklilik.

Ama işin özüne indiğinizde bu iki kavram birbirinden farklı öncelikleri temsil eder. Kritik bir veritabanı sunucusunda birincil hedefiniz yedeklilik olabilir; büyük dosya transfer operasyonları yapan bir depolama sunucusunda ise bant genişliği ön plana çıkar. Doğru teaming modunu seçmek bu farkı anlamakla başlar.

Windows Server 2012 ile birlikte NIC Teaming işletim sistemi düzeyinde yerleşik geldi ve artık üçüncü parti sürücülere ya da switch vendor’ına bağımlılık büyük ölçüde azaldı. Windows Server 2019 ve 2022’de ise bu altyapı daha da olgunlaştı.

Teaming Modları: Hangisi Ne Zaman?

Teaming modlarını anlamadan doğru yapılandırma yapamazsınız. Üç ana mod var ve her birinin kullanım amacı farklı.

Switch Independent Mod

Bu modda switch tarafında herhangi bir konfigürasyon gerekmez. NIC’lerinizi farklı switch’lere bile bağlayabilirsiniz. Yedeklilik açısından en sağlam seçenek budur çünkü switch seviyesinde tek nokta arızası (single point of failure) ortadan kalkar.

Gerçek hayatta şu senaryoyla karşılaştım: İki switch’e ayrılmış bir rack’te, sunucunun her iki switch’e bağlı NIC’leri switch independent modda teaming yapılmıştı. Bir switch güncellemesi sırasında diğer switch devralınca hizmet kesintisiz devam etti. Bu modun tercih edilmesinin ana sebebi budur.

Switch Dependent Modlar

Bu kategoride iki alt mod var:

  • Static Teaming (IEEE 802.3ad Static): Switch tarafında da manuel konfigürasyon gerektirir. Esnek değildir ama bazı eski switch altyapılarında tek seçenek olabilir.
  • LACP (IEEE 802.1ax / 802.3ad Dynamic): Standart protokol tabanlı çalışır. Switch ve sunucu arasında LACP negotiation yapılır. Kurumsal ortamlarda en yaygın kullanılan switch dependent moddur.

Load Balancing Algoritmaları

Mode seçiminin yanı sıra load balancing algoritması da kritik öneme sahip. Windows Server’da başlıca üç algoritma bulunur:

  • Address Hash: Kaynak ve hedef IP/MAC/Port bilgilerini hash’leyerek trafik dağıtımı yapar. Varsayılan seçenektir ve çoğu senaryo için uygundur.
  • Hyper-V Port: Sanal makinelerin bağlı olduğu sanal switch portlarına göre dağıtım yapar. Hyper-V ortamlarında bu algoritmayı kullanın.
  • Dynamic: Windows Server 2012 R2 ile gelen bu mod, flowlet ayrımı yaparak Address Hash ve Hyper-V Port’un avantajlarını birleştirir. Performans açısından genellikle en iyi sonucu verir.

PowerShell ile NIC Teaming Yapılandırması

GUI üzerinden de yapılandırma mümkün ama production ortamında tekrarlanabilirlik ve otomasyon açısından PowerShell tercih sebebidir. Üstelik Server Core kurulumlarında zaten başka seçeneğiniz yok.

Önce mevcut ağ arabirimlerini listeleyelim:

Get-NetAdapter | Where-Object {$_.Status -eq "Up"} | Select-Object Name, InterfaceDescription, LinkSpeed, MacAddress

Bu komut yalnızca aktif durumdaki NIC’leri listeler. Hangi kartların teaming için kullanılacağını belirlemek açısından başlangıç noktanız burası.

Şimdi temel bir NIC Team oluşturalım. İki NIC’i Switch Independent modda, Dynamic load balancing ile birleştiriyoruz:

New-NetLbfoTeam -Name "ProductionTeam" `
    -TeamMembers "Ethernet 1","Ethernet 2" `
    -TeamingMode SwitchIndependent `
    -LoadBalancingAlgorithm Dynamic `
    -Confirm:$false

Oluşturulan team’in durumunu kontrol etmek için:

Get-NetLbfoTeam -Name "ProductionTeam" | Select-Object Name, Status, TeamingMode, LoadBalancingAlgorithm

Get-NetLbfoTeamMember -Team "ProductionTeam" | Select-Object Name, AdministrativeMode, OperationalStatus

Team’e IP adresi atamak standart PowerShell networking cmdlet’leriyle yapılır:

$team = Get-NetAdapter -Name "ProductionTeam"
New-NetIPAddress -InterfaceIndex $team.ifIndex `
    -IPAddress "192.168.10.50" `
    -PrefixLength 24 `
    -DefaultGateway "192.168.10.1"

Set-DnsClientServerAddress -InterfaceIndex $team.ifIndex `
    -ServerAddresses ("192.168.10.10","192.168.10.11")

VLAN Yapılandırması ve Team Interface

Kurumsal ortamlarda NIC teaming’i VLAN’larla birlikte kullanmak neredeyse kaçınılmazdır. Bir team üzerinde birden fazla VLAN interface’i tanımlanabilir. Bu özellikle host-based routing veya multi-tenant ortamlar için çok işe yarar.

# Mevcut team üzerine VLAN interface ekle
Add-NetLbfoTeamNic -Team "ProductionTeam" -VlanID 100 -Name "ProductionTeam-VLAN100"
Add-NetLbfoTeamNic -Team "ProductionTeam" -VlanID 200 -Name "ProductionTeam-VLAN200"

# VLAN interface'lerini listele
Get-NetLbfoTeamNic -Team "ProductionTeam"

Her VLAN interface’ine ayrı IP adresi atanabilir ve bu interface’ler bağımsız olarak yönetilebilir. Switch tarafında ilgili portların trunk mod ve izin verilen VLAN’lar açısından doğru yapılandırıldığından emin olun.

Hyper-V Ortamında NIC Teaming

Hyper-V kullanıyorsanız, NIC teaming yaklaşımı biraz farklılaşır. İki seçeneğiniz var: host üzerinde team oluşturup bu team üzerinden sanal switch tanımlamak ya da VM içinde NIC teaming yapmak. İkinci seçenek için VM üzerinde “MAC Spoofing” aktif olmalıdır.

Hyper-V host’ta team üzerinden sanal switch oluşturma:

# Önce team oluştur
New-NetLbfoTeam -Name "HyperVTeam" `
    -TeamMembers "Ethernet 3","Ethernet 4" `
    -TeamingMode SwitchIndependent `
    -LoadBalancingAlgorithm HyperVPort `
    -Confirm:$false

# Team üzerinde Hyper-V External Switch tanımla
New-VMSwitch -Name "ExternalSwitch" `
    -NetAdapterName "HyperVTeam" `
    -AllowManagementOS $true

Hyper-V ortamında load balancing algoritması olarak HyperVPort kullanın. Address Hash’in aksine bu mod, sanal makine bazında dağıtım yaptığından VM trafiğinin bir NIC’e yığılmasının önüne geçer.

Failover Testi: Teoriden Pratiğe

Teaming yapılandırdınız, güzel. Peki gerçekten çalışıyor mu? Production’a gitmeden önce failover testini yapmanız şart. Ben her NIC teaming kurulumu sonrasında şu test prosedürünü uygularım.

Önce sürekli ping başlatın ve kayıp paket sayısını izleyin:

# Hedef sunucuya sürekli ping
ping 192.168.10.1 -t

Ayrı bir PowerShell oturumunda aktif NIC üyesini devre dışı bırakın:

# Aktif team üyesini yönetimsel olarak devre dışı bırak
Set-NetLbfoTeamMember -Name "Ethernet 1" -Team "ProductionTeam" -AdministrativeMode Standby

# Failover sonrası team durumunu kontrol et
Get-NetLbfoTeamMember -Team "ProductionTeam" | Select-Object Name, OperationalStatus, TransmitLinkSpeed

Ping tarafında bir veya iki paket kaybı normal kabul edilebilir, ama bunun üzerinde kayıp varsa yapılandırmayı gözden geçirin. Testi tamamladıktan sonra üyeyi tekrar aktife alın:

Set-NetLbfoTeamMember -Name "Ethernet 1" -Team "ProductionTeam" -AdministrativeMode Active

Fiziksel kablo çekme testini de yapmak istiyorsanız, bunu managed switch üzerinden port’u kapatarak simüle edebilirsiniz. Fiziksel kablo çekme gerçek dünyada da olabilir ve NIC’in link kaybını ne kadar sürede algılayıp failover yaptığını ölçmek önemlidir.

İzleme ve Sorun Giderme

Canlı sistemde team’in sağlığını düzenli izlemek gerekir. Şu script’i görev zamanlayıcıya ekleyerek periyodik health check yapabilirsiniz:

# NIC Team health check scripti
$teams = Get-NetLbfoTeam
foreach ($team in $teams) {
    $members = Get-NetLbfoTeamMember -Team $team.Name
    $degradedMembers = $members | Where-Object {$_.OperationalStatus -ne "Active"}
    
    if ($degradedMembers) {
        $message = "UYARI: $($team.Name) team'inde sorunlu uye tespit edildi:`n"
        $degradedMembers | ForEach-Object {
            $message += "  - $($_.Name): $($_.OperationalStatus)`n"
        }
        
        # Event Log'a yaz
        Write-EventLog -LogName Application `
            -Source "NICTeamMonitor" `
            -EventId 1001 `
            -EntryType Warning `
            -Message $message
            
        # Opsiyonel: E-posta bildirimi
        # Send-MailMessage -To "[email protected]" -Subject "NIC Team Uyarisi" -Body $message -SmtpServer "mail.firma.com"
    }
}

Event Log’a yazmadan önce kaynağı oluşturmanız gerekir:

New-EventLog -LogName Application -Source "NICTeamMonitor"

Anlık trafik istatistiklerini görmek için:

# Network adapter istatistikleri
Get-NetAdapterStatistics -Name "ProductionTeam" | Select-Object Name, ReceivedBytes, SentBytes, ReceivedUnicastPackets, SentUnicastPackets

# Saniye bazlı throughput ölçümü
while ($true) {
    $stats1 = Get-NetAdapterStatistics -Name "ProductionTeam"
    Start-Sleep -Seconds 1
    $stats2 = Get-NetAdapterStatistics -Name "ProductionTeam"
    
    $rxMbps = [math]::Round(($stats2.ReceivedBytes - $stats1.ReceivedBytes) * 8 / 1MB, 2)
    $txMbps = [math]::Round(($stats2.SentBytes - $stats1.SentBytes) * 8 / 1MB, 2)
    
    Write-Host "$(Get-Date -Format 'HH:mm:ss') | RX: $rxMbps Mbps | TX: $txMbps Mbps"
}

Yaygın Hatalar ve Kaçınılması Gerekenler

Yıllar içinde hem kendi yaptığım hem de başkasından devralıp temizlemek zorunda kaldığım bazı hatalar var. Bunları paylaşmak bu yazının en değerli kısmı olabilir.

Aynı fiziksel switch’e bağlı “yedekli” teaming: Switch independent mod seçilmiş ama iki NIC de aynı switch’e bağlı. Switch arızalanınca yedeklilik sıfır. Switch bağımsızlığı fiziksel bağlantı seviyesinde de sağlanmalı.

Hyper-V ortamında yanlış algoritma seçimi: Host üzerindeki Hyper-V trafiği için Address Hash kullanmak, tüm VM trafiğini tek bir NIC’e yığabilir. HyperVPort veya Dynamic kullanın.

Team oluşturduktan sonra IP konfigürasyonunu unutmak: NIC’lere atanmış IP adresleri team oluşturulduktan sonra kaybolur. Team interface üzerinden yeniden yapılandırmanız gerekir. Bu durum özellikle uzak bağlantıyla çalışırken RDP kopmasına neden olur; bu yüzden fiziksel konsoldan ya da IPMI/iDRAC üzerinden erişim sağlayarak işlemi yapın.

LACP modunda switch konfigürasyonunu atlamak: Switch tarafı konfigüre edilmeden LACP modunda team oluşturulursa, team “Degraded” durumda kalır. Switch engineer’ı ile koordineli çalışın.

MTU uyumsuzluğu: Jumbo frame kullanılan ortamlarda team üyelerinin MTU değerleri eşleşmeli. Aksi halde fragmentasyon sorunları yaşanır:

# Team üyelerinin MTU değerlerini kontrol et
Get-NetAdapter -Name "Ethernet 1","Ethernet 2" | Select-Object Name, MtuSize

# MTU ayarla
Set-NetAdapterAdvancedProperty -Name "Ethernet 1" -RegistryKeyword "*JumboPacket" -RegistryValue 9014
Set-NetAdapterAdvancedProperty -Name "Ethernet 2" -RegistryKeyword "*JumboPacket" -RegistryValue 9014

Windows Server 2022 ve SET (Switch Embedded Teaming)

Modern Hyper-V altyapılarında LBFO’nun yanı sıra SET (Switch Embedded Teaming) de gündemdedir. SET, Hyper-V sanal switch ile entegre çalışan ve RDMA (Remote Direct Memory Access) desteği sunan bir yaklaşımdır. LBFO ile karıştırılmamalıdır; SET yalnızca Hyper-V ortamları için tasarlanmıştır ve RDMA özelliği gerektiren SMB Direct senaryolarında tercih edilir.

# SET kullanarak Hyper-V switch oluşturma
New-VMSwitch -Name "SETSwitch" `
    -NetAdapterName "RDMA-NIC-1","RDMA-NIC-2" `
    -EnableEmbeddedTeaming $true `
    -AllowManagementOS $true

# SET üyelerini listele
Get-VMSwitchTeam -Name "SETSwitch"

Eğer depolama trafiği için SMB Direct ve RDMA kullanmıyorsanız klasik LBFO yeterlidir. Gereksiz karmaşıklığa girmeyin.

Sonuç

NIC Teaming, doğru yapılandırıldığında gerçekten hayat kurtarır. Ama “yapılandırıldım bitti” mantığıyla bırakmak olmaz. Test etmeden geçen bir teaming kurulumu, gerçek arıza anında sizi yarı yolda bırakabilir. Failover testini production öncesinde mutlaka yapın, izleme mekanizmasını kurun ve alert’lerinizi tanımlayın.

Mod seçimi konusunda ise şu pratik kurala bağlı kalıyorum: Switch bağımsızlığı önceliğinizse Switch Independent, standart kurumsal altyapılarda switch’in desteği varsa LACP, Hyper-V yoğun ortamlarda HyperVPort algoritmasıyla yine Switch Independent. Karmaşık düşünmeyin.

Son olarak, NIC Teaming’i bir kez yapıp unutmayın. Ağ ekipmanı değişimleri, switch güncellemeleri ve sunucu bakımları sonrasında team durumunu gözden geçirin. Ben her büyük değişiklik sonrasında Get-NetLbfoTeam çıktısına bakmayı alışkanlık haline getirdim. Bu basit önlem, kaç kez sessizce oluşmuş bir degraded durumu yakalamama yardımcı oldu.

Bir yanıt yazın

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