Windows Server 2012 NIC Teaming

NIC teaming, Load Balancing/Failover (LBFO) olarak da bilinen birden fazla network adaptörünü kullanarak bant genişliği artırmayı (bandwidth aggregation) ve/veya network adaptörlerinden biri arızalandığında diğerleri üzerinden trafiği sürdürmeyi sağlar.

Bu özellik Windows Server 2012 R2 ye kadar NIC üreticilerinden temin ediliyordu.

Bu makalede aşağıdaki bölümleri ele alacağız:

NIC teaming mimarisi,
Bandwidth aggregation (load balancing olarak da bilinir) mekanizmaları,
Failover algoritmaları,
NIC özellik desteği – görev boşaltmaları (task offloads) ve daha karmaşık NIC fonksiyonları,
NIC Teaming management tool’un kullanılması ve bir örnek. (ikinci makale)

NIC teaming, server core dahil tüm Windows Server 2012 R2 versiyonlarında bulunur. NIC teaming, Windows 8.1’de kullanılamaz ancak NIC teaming ile görevlendirilen bir yada bir kaç Windows Server 2012 R2’i yönetebilmek için NIC teaming user interface ve NIC teamining Windows PowerShell Cmdlet’leri Windows 8.1 ile birlikte kullanılabilir.

Sözlük

Bu yazıda yer alan bazı terimler ve kısaltmalara aşina olmayanlar aşağıdaki sözlükten faydalanabilirler.

Terim/Kısaltma	Açıklama
LACP	Link Aggregation Control Protocol. Detay için bakınız.
NIC	Network Interface Card. Çoğunlukla Bildiğimiz erternet kart. Ethernet fiziksel bağlantısının network arayüzüdür. Windows’da, çalıştığı bazı yazılımlarda uzantı alabilir. vNIC, tNIC, vmNIC, gibi.
RSS	Receive Side Scaling. Windows’da gelen paket işleme isteğini birden çok işlemciye yayan bir özellik.
tNIC	NIC Teaming modulü tarafından sunulan bir ağ arayüzüdür. Team Interface veya Team NIC olarak da adlandırılır.
VLAN	Virtual Local Area Network. Farklı trafik grupları (kullanıcılar) için trafiği diğer trafiğe (kullanıcılara) erişemeyecek şekilde taşıyan bir yöntem. Yani bildiğimiz sanal lan. VLAN’lar, Ethernet MAC headerindaki bir alanda 0 ile 4094 arasında bir sayı ile gösterilirler. IEEE 802.1Q, frame’in ait olduğu Vlan’i belirten 12 bitlik bir alanı header’a tanımlar. 0 (0x000) ve 4095 (0xFFF) hexadecimal değerleri rezerve edilmiştir. Diğer tüm değerler, 4,094 VLAN’a kadar izin veren VLAN tanımlayıcıları olarak kullanılabilir. VLAN = 0, çerçevenin (frame) herhangi bir VLAN’a ait olmadığını ve 802.1Q üstbilgisi bulunmayan etiketsiz bir paket olduğunu gösterir.
VM	Virtual Machine (Sanal Makine)
vmNIC	Hyper-V swich tanımlanmış bir VM’de network interface olarak bulunan bir port. VM’I sanal bir swich üzerinden sanal veya fiziksel bir ağa bağlar.
VMQ	Virtual Machine Queue(s). (Sanal Makine Kuyruğu) Hyper-V swich portuna yönlendirilen tüm gelen trafiğini tek bir sırada toplayan ve bu sıranın işlenmesini belirli bir işlemciyle ilişkilendiren bir Windows özelliğidir. Bu, bir Hyper-V host’taki işlemler arasında yük dağıtımı sağlar.
vNIC	Ana makine bölümünde (host partion) network interface olarak bulunan Hyper-V swich’indeki bir port. Kısaca sanal adaptor.

Teknik Önizleme (Mimari)

Piyasadaki hemen hemen tüm NIC teaming çözümleri aşağıdaki tabloya benzer bir mimariye sahiptir:

Bir veya daha fazla fiziksel NIC, işletim sistemine bir veya daha fazla sanal bağdaştırıcı (tNICs or team interface or team NICs) sunan NIC teaming çekirdeğine bağlanır. Trafiği NIC’ler arasında dağıtmak için çeşitli algoritmalar vardır.

Birden fazla team interface oluşturmak için için tek neden, gelen trafiği mantıksal olarak VLAN’lara bölmektir. Böylece bir ana bilgisayarın farklı VLAN’lara bağlanılması sağlanır. Bir team, bir Hyper-V swich’ine bağlandığında VLAN ayarları NIC teaming software’i yerine Hyper-V swich’i üzerinde yapılmalıdır.

NIC Teaming için Konfigürasyonlar

Yukarıdaki ilk resimde sunucunun tüm Ethernet kartları (team) tek bir swiche bağlıdır. İkinci resimde ise Ethernet kartları ayrı swichlere bağlanmışlardır. Elbette bunların farkları, avantajları ve dezavantajları vardır. Basitçe açıkladığım bu modlar literatüre aşağıdaki açıklamalar ile girmişlerdir.

Switch-independent mode. (Swich bağımsız mod) (ikinci resim) : Bu konfigürasyonda swich’in team’e katılması gerekmez. Swich üzerinde herhangi bir konfigürasyona gerek yoktur. Bu modda swich’ler, ethernet kartlarının ana bilgisayarda hangi team’da olduklarını bilmediğinden ethernet kartları farklı swich’lere bağlanabilir. Bu mod, farklı swich’lere bağlanmayı mümkün kılsa da bunu gerektirmez, sadece mümkün kılar.
- Active/Active Teaming : Team’daki tüm kartların aktif olduğu durumdur. Örneğin, 1Gb/sn’lik üç ethernet kartını bu modda kullanırsanız toplam 3Gb/sn’lik bant genişliğiniz olur.
- Active/Standby Teaming: Bu modda en az iki kart bulunur, biri aktif diğeri pasiftir. Active/Passive teaming olarak da bilinir, aynı şeydir. Geniş bant yerine yedekli bir hat istendiğinde tercih edilir. Trafik, aktif olan NIC üzerinden akarken NIC üzerinde arıza oluştuğunda pasif olan NIC devreye girer ve tüm yükü alarak trafiğin sürekli ve kesintisiz akmasını sağlar. Hata toleransı ve daha düşük gecikme süresi sağlar.

Switch-dependent teaming : (Birinci resim) Bu konfigürasyonda swich team’a katılır. Yani team’daki tüm NIC’ler aynı fiziksel swich’e bağlıdır. İki farklı yönetim modu vardır:

Note:Bazı üreticilerin tüm toplama noktalarını (aggregate ports) aynı swihchten gönderdiği multi-swich’leri bulunmaktadır. Multi-swich’ler LACP işlemi için Multi-Chassis Link Aggregation Group (MC-LAG) oluşturmaktadır.

Link Aggregation Control Protocol teaming (IEEE 802.1ax, LACP): Bu mod, birden fazla ethernet kartını tek bir noktada bir araya getirerek, sankı tek bir fiziksel nokta gibi gözükmesini sağlar. Ayrıca swich üzerinde tanımlanmalı ve doğru konfigürasyon yapılmalıdır. Swich üzerinde Link Aggregation oluştururken portlar aynı vlan ve aynı bant genişliği değerlerine sahip olmalıdır. Bu protokol Cisco swich’lerde EtherCahannel olarak geçer. IEEE 802.3ax komitesinde IEEE 802.1ax olarak yayınlanmadan önce geliştirildiği için yaygın olarak IEEE 802.3ad olarak da adlandırılır. IEEE 802.1ax, ana bilgisayarla bir swich arasında bağlı olan tüm bağlantıları dinamik olarak tanımlamak/tespit etmek için Link Aggregation Control Protocol’unu (LACP) kullanarak çalışır. Bu, bir team’in otomatik olarak oluşturulmasını, team’in yalnızca tek bir noktadan (akran varlık) paketlerinin iletilmesi veya alınması yoluyla genişletilmesini ve azaltılmasını sağlar.

Windows NIC team her zaman short timer ile LACP’nin Active modunda çalışır. Zamanlayıcıyı değiştirmek veya LACP modunu değiştirmek için herhangi bir seçenek mevcut değildir. Her iki mod da birden fazla ethernet kartını tek bir kart gibi göreceği için toplu bant genişliğinin pratik sınırlarına yaklaşmaya izin verir.

Yük Dağılımı Algoritmaları (Algorithms for load distribution)

Windows Server 2012 R2’deki NIC teaming, aşağıdaki yük dağıtım algoritmalarını desteklemektedir:

Hyper-V switch port : Hyper-V ana makine (host) üzerinde team oluştururken yapılandırılır. Hyper-V swich, sanal bir NIC’ten (vNIC) gelen trafiği tek bir fiziksel NIC’e (pNIC) yönlendirir. Aşağıdaki diagramda NIC team, VM01 üzerinden gelen/giden trafiğini PNIC1 ile ilişkilendirmektedir. Aynı şekilde VM02 üzerinden gelen/giden trafğini PNIC2 ile ilişkilendirmektedir. Burada fiziksel NICler NIC team üyesidir.

(Karıştırılmaması gereken şey, yapılan iş VM başına yapılan bir birleşme değildir. Sanal NIC’lerin birlikte çalışmasıdır. Örneğin, VEM01’e ikinci bir sanal NIC eklersek, o sanal NIC için trafik NIC team tarafından herhangi bir takım üyesi ile ilişkilendirelibilr. Dinamik Sanal Makine Kuyruğu (DVMQ) sanal NIC’e yönlenen trafiği hızlandırmak ve sıraya sokmak için RSS ile birlikte çalışır. RSS hem fiziksel hem de sanal NIC ile ilişkilidir. Trafiğin yönünün her zaman aynı takım üyesi tarafından gelmesini sağlar.)

Fiziksel NIC’lerden biri başarısız olmadıkça paket trafiğinin yönü tahmin edilebilir. Sanal NIC’lere gelen trafik ilişkili fiziksel NIC’lerden akacaktır. Fiziksel NIC’lerden biri başarısız olduğunda ise VM01 ve VM02’nin tüm trafiği NIC team tarafından otomatik olarak diğer sağlam fiziksel NIC üzerinden akıtılacaktır.

Önemli olan diğer bir nokta, toplam bant genişliğidir. 2 pNIC’ten oluşan bir team’a 2X10 Gbps hat verildiğinde toplam bant genişliği 20Gbps olur fakat bu bant genişliği team’daki tüm pNIC’ler ile paylaştırılır. Dolasıyla 2 VM’li bir host’ta VM başına düşen bant genişliği 10Gbps’ı geçemez.

Fiziksel NIClerinizden daha çok sanal NIC’leriniz varsa, (Örn.20 VM ve 4 pNIC’li bir yapı) Hyper-V ortamındaysanız, Hyper-V switch port modunu kullanmanız daha uygundur.

Adress Hashing: Bu algoritma VNIC ile PNIC üyelerini ilişkilendirmez. Bunun yerine NIC ekibine gelen/giden her paket incelenir. Paketin adres (varış) bileşenlerine bakılarak (ip adresi, mac adresi, port numarası) bir hash oluşturulur. Daha sonra bu hash’e sahip paketleri kullanılabilir fiziksel adaptörlere atar. Bu mekanizma genellikle mevcut adaptörler arasında yük dengeleme amaçlı kullanılır. Bunun bir örneğini aşağıda görelim:

VM01 biri A adresine diğeri de B adresine olmak üzere iki paket gönderir. NIC team A paketini alır, adres bilgilerine bakarak (ip adres, mac adresi, port no v.s) bir hash oluşturur. Oluşturulan hash algoritmasının sonucunu pNIC ataması için kullanır ve A paketini PNIC1 üzerinden gönderir. B paketi için de aynasını yapar ve paketi daha az yoğunlukta olan PNIC2 ye yönlendirir.

Bu yöntem teorik olarak NIC team’daki tüm bant genişliğini kullanır. (Örneğin 20Gbs) Ancak bu her zaman böyle olmaz çünkü hash algoritmasının sonuçlarına bağlı olarak değişir. Yukaridaki örnekte A verisi için 10Gbs, B verisi için 10Gbs ile veri aktarılır. Sonuçta tüm bant genişliği kullanılır. Aşağıdaki örnekte bir live migration performansı görülüyor.

Host1, live migration networkunde Host2’nin tek ip adresine veri gönderir.

Live Migration, bu paketleri NIC team’a gönderir. NIC team paketi inceler. Paketlerin her biri aynı hedef (Host2) adres bilgilerine sahipdir. (Aynı mac adresi, aynı ip adresi ve tcp portu)

Hedef bilgileri ile bir hash oluşturulur ve bu hash tüm paketlerin ekibin tek bir üyesi (pNIC1) vasıtasıyla iletilmesine neden olur.

Burada Live Migration’un hızı NIC Pnıc1’in band genişliği ile sınırlıdır. (Örneğimizde 10Gbs)

Tabiki live migration sadece tek bir adaptör ile sınırlandırılamaz. Host1’in durması, Host2 ve Host3’e live migration yapmasına sebep olur. Bu durummda ortaya çıkan hash, NIC team’in Host1’deki her iki adaptörü kullanmasına neden olur ve 20Gbs’lık tüm bant genişliği kullanılır.

Adres hash’lerinin yanlış anlaşılması, A adresine gönderilen paket1’in pnic1 yoluyla gitmesi ve paket2’nin aynı adrese pnic2 ile gitmesi mümkün değildir.

Bir başka durum, eğer sadece 2 adet host’unuz varsa 2 adaptörlü bir NIC team’in sadece %50’sini görür ve kullanırsınız. Üçüncü host ekleninceye kadar LBFO’nun FO bölümünü alırsınız.

Windows Server 2012 R2 de GUI kullanarak bir NIC team oluşturursanız LB modu seçenekleri kısıtlıdır. Sadece Hyper-V host ve Adress Hash seçeneğini görürsünüz. Powershell kullanarak aşağıdaki hash opsiyonlarını da seçebilirsiniz.

TransportPorts (4-Tuple Hash): Hash oluşturmak için kaynak ve hedef UDP/TCP port bilgisi ile adres ip adresi bilgisini kullanır. Ardından hash ile eşleşen paketleri team adaptörlerinden birine atar.
IPAddresses (2-Tuple Hash): Hash oluşturmak için yalnızca kaynak ve hedef ip adresi bilgisini kullanır. Ardından hash ile eşleşen paketleri team adaptörlerinden birine atar. Eğer trafik UDP/TCP tabanlı değilse (örneğin Ipsec ile gizlenmiş paketler) bu seçeneği kullanmanız faydalıdır.
MacAddresses: Hash oluşturmak için yalnızca kaynak ve hedef MAC adreslerini kullanır. Ardından hash ile eşleşen paketleri team adaptörlerinden birine atar. Trafik IP tabanlı değilse bu seçeneği kullanabilirsiniz.

Dynamic : Bu mod, yukarıdaki iki modun her birinin en iyi özelliklerini kullanır ve bunları tek bir modda birleştirir. Yani Hyper-V swich mode ve Adress Hashing mode’larının bir karmasıdır diyebiliriz.

Giden yükler için Adress Hash’in algoritması kullanılır.
Gelen yükler için Hyper-V swich port algoritması kullanılır.

Bu modda giden yükler akışkanlık (flowlets) kavramına bağlı bir şekilde dimanik olarak dengelenir. Tıpkı biz insanlar konuşurken sözcüklerin ve cümlelerin bazı yerlerinde kopmalar olduğu gibi TCP akışları da doğal olarak kopmalara sahiptir. İki kopuş arasındaki TCP akışının bir bölümüne akış kanalı (flowlet) denir. Dinamik mod algoritması, bir akışın sınırda olduğunu tespit ettiğinde (örneğin TCP akışında yeterli uzunlukta bir kesilme meydana geldiğinde) algoritma, eğer uygunsa, akışını başka bir adaptör üyesine otomatik olarak dengeler. Algoritma, bazı durumlarda flowlet içermeyen akışları da dengeleyebilir. Bu nedenle algoritma eğer gerek görürse team’in iş yükünü dengeler.

Swich Indepentdent veya Swich Dependent mod fark etmeksizin, en iyi performans için Dynamic Mode tavsiye edilir.

Sadece iki adaptörlü, swich independent modlu ve Active/Stanby şekliyle yapılandırılmış bir NIC team’da istisna vardır. Burada Address Hash distribution, Dynamic moddan daha iyi performans sağlar.

Konfigürasyonlar ve Yük Dağılımı Arasındaki Etkileşimler

Switch Independent configuration / Address Hash distribution

En iyi performansı VM sunucularında verir. Performans olarak Switch Dependent configuration / Dynamic distribution metodunun gerisindedir. Sonuç olarak işi yükü için ilk tercih önerisi değilir.

Switch Independent configuration / Hyper-V Port distribution

VM sunucularında kullanılması uyundur. VMQ’ları maksimum kullanarak çalışır. Ancak performans olarak Swicth Independent / Dynamic metodunun gerisindedir.

Switch Independent configuration / Dynamic distribution

Bu yapılandırmada giden yük için Adress Hash Algoritmasını, gelen yükler için ise Hyper-V switch algoritmasını kullanılır. Switch Independent konfigürasyonları arasında en performanslı metotdur.

Switch Dependent configuration / Address Hash distribution

Bu yapılandırma giden yük için Adress Hash algoritmasını kullanır. Gelen yük için ise, trafiğin hangi nic’ler arasında dağıtılacağına swich karar verir. Performans olarak Swithc Dependent / Dynamic Distribution’un gerisindedir.

Switch Dependent configuration / Hyper-V Port distribution

Bu yapılandırma giden yük için Adress Hash algoritmasını kullanır. Hyper-V ortamında kullanılması tavsiye edilir. Performans olarak Switch Dependent configuration / Dynamic distribution metodunun gerisindedir. Gelen yük için ise, trafiğin hangi nic’ler arasında dağıtılacağına swich karar verir.

Switch Dependent configuration / Dynamic distribution

Bu yapılandırma giden yük için Adress Hash algoritmasını kullanır. Gelen yük için ise, trafiğin hangi nic’ler arasında dağıtılacağına swich karar verir. Yapılandırmalar arasında en performanslı metottdur diyebiliriz.

Sanal Makine (VM) içinde NIC Teaming

Bir VM içerisinde NIC teaming yapılması mümkündür. Ancak, sadece external swiche bağlı vmNIC’lere NIC teaming yapabilirsiniz. Internal veya private swichlere bağlı vmNIC’ler team içerisinde disconnected olarak gözükecektir.

VM içindesinde NIC teaming, VM’in vmNIC’ler üzerinden birden fazla Hyper-V swhichine bağlı olmasına ve her swich altındaki fiziksel NIC’in bağlantısı kesilse bile diğeri üzerinden bağlantıyı korumasına izin verir. Böylece SR-IOV trafiğinin Hyper-V swich üzerinden geçemediği durumlarda önem taşır. Ayrıca VF’leri takviye etmek için VM’lerde team oluşturulabilir.

VM’de oluşacak fail-over, diğer vmNIC’in mac aderisyle trafik göndermesine sebep olabilir. Bunu önlemek için VM ile ilişkilendirilmiş Hyper-V swichi üzerinde teaming mode aktif hale getirilmelidir. Bunun için aşağıdaki iki yolu kullanabilirsiniz:

Hyper-V managerda Vm settings ve Advanced Features tabından NIC teaming enable yapılır.

Administrator hakları ile Power Shell cmd’let’i çalıştırabilirsiniz.

Set-VMNetworkAdapter -VMName <VMname> -AllowTeaming On

Bir VM üzerinde oluşturulan teamlar, yalnızca Adress Hass distribution modlarından birini kullanarak Swich Independent yapılandırmasında çalışabilir. Ekip üyelerinin her birinin farklı bir external swich’e bağlı olduğu durum desteklenir.

Host üzerindeki Hyper-V Portlar

Host üzerinde oluşan vNIC’ler herhangi bir ekibe yerleştirilmemelidir. Ağ hatalarına neden olur.

Kısıtlamalar

Windows Server 2012 R2’deki NIC teaming aşağıdaki beş özellik ile birlikte kullanılması tavsiye edilmez.

SR-IOV, RDMA, Native host Quality of Service, TCP Chimney ve 802.1X Authentication.

SR-IOV ve RDMA da, veri doğrudan NIC’e yönlendirildiğinden team’in veriye bakması veya teamdaki başka bir yoldan yönlendirilmesi mümkün değildir.

QoS policy’leri bir native yada bir host sistem üzerinde ayarlandığında ve bu ilkeler minimum bant genişliği ilkelerini çağırdığında NIC team’in bant genişliği, mevcut bant genişliğinden daha düşük olur.

TCP Chimmney, Windows 2012 R2 teaming ile desteklenmez çünkü TCP Chimmney’in tüm ağ yükünü NIC üzerine boşaltan bir yapısı vardır.

802.1x NIC teaming ile birlikte kullanılmamalıdır. Çünkü bazı swich’ler aynı port üzerinde hem 802.1x hem de NIC teaming yapılandırmaya izin vermez.

NIC teaming ile Özellik Etkileşimleri

Feature	Comments
Datacenter bridging (DCB)	Tüm ekip üyeleri (all NICs) destekliyorsa desteklenir.
Hyper-V Network Virtualization (HNV) / NV-GRE	Hyper-V swich altına yüklendiyse desteklenir.
IPsec Task Offload (IPsecTO)	Tüm ekip üyeleri (all NICs) destekliyorsa desteklenir.
Large Send Offload (LSO)	Tüm ekip üyeleri (all NICs) destekliyorsa desteklenir.
Receive side coalescing (RSC)	Ekip üyelerinden herhangi biri destekliyorsa host üzerinde desteklenir.
Receive side scaling (RSS)	Host üzerinde desteklenir. Windows Server 2012 R2, TCP/IP RSS yığın bilgilerini doğrudan ekip üyelerine programlar.
Receive-side Checksum offloads (IPv4, IPv6, TCP)	Ekip üyelerinden herhangi biri destekliyorsa desteklenir.
Remote Direct Memory Access (RDMA)	RDMA verisi Windows Server 2012 R2 protokol yığınını bypass ettiğinden RDMA desteklenmez.
Single root I/O virtualization (SR-IOV)	SR-IOV verileri host OS yığınını bypass ettiğinden SR-IOV özelliğinin ortaya çıkmasına neden olan NIC’ler bir takıma üye iken gözükmeyeceklerdir. Ancak, VF’leri takviye etmek için VM’lerde team oluşturulabilir.
TCP Chimney Offload	Desteklenmez.
Transmit-side Checksum offloads (IPv4, IPv6, TCP)	Tüm ekip üyeleri (all NICs) destekliyorsa desteklenir.
Virtual Machine Queues (VMQ)	Hyper-V swich altına yüklendiyse desteklenir.
QoS in host/native OSs	Eğer minumum bant genişliği politikaları kullanılırsa team’daki bant genişliği minQoS’dan daha düşük olacaktır.
Virtual Machine QoS (VM-QoS)	NIC teaming tarafından kullanılan yük dağıtım algoritmarından etkilenir. En iyi sonuç için Dynmic yük dağıtım modu tavsiye edilir.
802.1X authentication	Bazı swich’ler ile uyumlu değildir. NIC teaming ile kullanılmaması tavsiye edilir.

NIC Teaming and Virtual Machine Queues (VMQs)

VMQ ve NIC teaming birlikte iyi çalışırlar. NIC team, switch configuration moduna ve load distribution moduna bağlı olarak ya adaptör üzerindeki beklemelerin/kuyrukların en az sayıda olması için VMQ kapasitesinin tamamını Hyper-V anahtarına bildirecektir (Min-ques mode) yada takımın her bir üyesinin VMQ kapasitesini Hyper-V anahtarına bildirilecektir.(Sum-of-Queues) Özetle;

Eğer team’i Switch-Independent mod ve Hyper-V yada Dynamic moda ayarlamışsanız Hyper-V swithc’e bildirilen sıraların sayısı ekip üyelerinin toplamından elde edilecek kapasite kadar olacaktır. (Sum-of-Queues)
Diğer durumlarda bildirilecek kuyruk sayısı, herhangi bir ekip üyesinin kapasitesi kadardır. (Min-ques mode)

Peki neden?

Switch independent konfigürasyonu ve Hyper-V yada Dynamic mod birlikte kullanıldığında, Hyper-V switch’ine (VM) gelen trafik daima aynı takım üyesine ulaşacaktır. Çünkü host, VM’e yönlenen trafiği hangi ekip üyesinin alacağını bilir/öngerebilir/denetleyebilir. Bu nedenle NIC team, bir ekip üyesinde hangi VMQ sırası uygulayacağına karar verebilir. Böylelikle denetleme adaptör bazına indirgenerek yapılır minimum sıra oluşturulmuş olur.
NIC teaming, herhangi bir swithc depending modunda (statik yada LCAP) ekibin bağlı olduğu anahtar gelen trafik dağıtımını kontrol eder. ancak host üzerindeki NIC teaming yazılımı, bir VM için gelen trafiğin hangi ekip üyesi tarafından alınacağını tahmin edemez/belirleyemez/denetleyemez. Böylelikle switch bir VM için olan trafiği tüm ekip üyeleri arasında dağıtır. Sonuç olarak, trafik tüm ekip arasında dağıtıldığı için NIC team VMQ için tüm ekip toplamı kadar sıra ataması ve programlaması ıyapar.
Swicth independend mod ile Adress Hashing modunu seçerseniz, gelen trafik her zaman bir ekip içindeki bir NIC üzerine gelecektir.(Birincil üyeye) Diğer ekip üyeleri gelen trafikle uğraşmadığından, birincil üye başarısız olursa gelen trafiği diğer ekip üyesi alır ve sıralar/kuyruklar (VMQ) yine NIC bazında yani adaptör bazında yapılmış olunur.

Sistemin daha performanslı çalışması için bir kaç VMW ve RSS ayarı vardır.

Her adaptörün gelişmiş özelliklerinde RssBaseProcNumber ve MaxRssProcessors değerleri bulunur.

İdeal olarak her adaptörde RssBaseProcNumber iki (2) veya daha büyük bir çift sayıya ayarlanmalıdır. Çünkü ilk çekirdek (core 0) genellikle sistem işlemesinin çoğunu yapar. Ağ işleri bu fiziksel işlemciden uzak tutulmalıdır.
Eğer Sum-of-Queues modunu kullanırsanız, takım üyelerinin (adaptörler) işlemcileri pratik olarak çakışma yapmıyacak ölçüde olmalıdır. Mesela 4 çekirdekli (mantıksal olarak 8) bir ana bilgisayarda 2x10Gb/sn’lik NIC’lerden oluşan bir ekibiniz var. İlk adaptörü Cpu-2’yi ve 4 çekirdek kullanmak için yapılandırabilirsiniz, ikinci adapdörü cpu-6’yı ve 2 çekirdek kullanmak üzere yapılandırmalısınız.
Eğer Min-Queues modunu kullanmak isterseniz takım üyeleri tarafından kullanılan işlemci setlerini aynı yapmalısınız.

Native Host Üzerinde Ekipteki NIC Sayısı

NIC teaming için en az bir NIC olması yeterlidir. Doğal olarak tek NIC’li bir takımda failover yapılamaz. Tek NIC’li takımlar, VLAN kullanılarak trafiğin ayrılması için kullanılabilir. Windows Server 2012 R2, bir takım içerisinde 32 NIC destekler.

Bir Hyper-V VM içindeki NIC Sayısı

VM’lerde iki üyeli ekipler desteklenir. Daha büyük ekipler oluşturulabilmesi mümkündür ancak desteklenmez. Her ekip üyesinin farklı bir external Hyper-V switch’ine bağlı olması ve teaming özelliğinin enable olması gerekir.

NIC Tipleri

Bir Windows Server 2012 R2 NIC teaming’de, Windows Qualification and Logo test (WHQL test)’ini geçmiş olan herhangi bir ethernet adaptörü kullanılabilir.

Ethernet dışındaki teknojileri temsil eden NIC’ler ekip oluştururken desteklenmez. (WWAN, WLAN/WiFi, Bluetooth, Infiniband, IpoIB NIC’ler)

Ana makine (host) üzerindeki vNIC’ler bir ekip içerisinde kullanılamaz.

Kernel debug network adapter (KDNIC) bir ekip içerisinde kullanılamaz.

Network boot özelliği ile kullanılan NIC’ler ekip içerisinde kullanılamaz.

Farklı Hızlara Sahip NIC’lerin Takımı

Farklı hızlarda çalışabilen NIC’ler bir arada takımlanabilir. Ancak tavsiye edilmez. Çünkü kullanılan algoritma hangisi olursa olsun trafiğin yaklaşık olarak yarısını her bir NIC’e gönderir, her bir NIC’in hızına göre ayarlayamaz. Örneğin 10Gb/sn ve 100Mb/sn lik NIC’leri bir araya getirirseniz her bir NIC’e toplam bant genişliğinin yarısı kadar trafik düşer. Eğer farklı hızlarda NIC’leri takımlayacaksanız, Active/Standby modunu kullanarak, düşük hızda olanı Standby seçmeniz önerilir.

Takım Takımları (İç İçe Takımlar)

Windows Server 2012 R2, bir takımın başka bir takım içerisinde kullanılmasına izin vermez. Ayrıca Windows Server 2012 R2 ile takımladığınız bir grubu, 3’üncü parti teaming software’leri ile de kullanmamalısınız.

MAC Adres Kullanımı ve Yönetimi

Team’in Mac Adresi

Swhitch Independend mod ile Adress Hash veya Dynamic Load Distribution konfigürasyonu ile oluşturulan bir takım, giden trafikte birincil ekip üyesinin MAC adresini kullanacaktır. Birincil ekip üyesi (primary team member) ekip oluşturulurken seçilen ilk NIC’tir. Ancak, birincil ekip üyesi her reboot işleminde, NIC disable/enable edildiğinde yada reconfiguration isteklerinde zaman zaman değişebilir. Ekibin MAC adresinin değişmesinin normalde bir sakıncası yoktur ancak bir kaç durum meydana gelebilir.

Takım içerisindeki bir NIC alınıp başka yerde kullanılırsa MAC adres çakışması oluşabilir. Bu sorunu gidermek için takım disible/enable edilmelidir. Böylelikle takımın diğer üyeleri arasından yeni bir MAC adresi seçilir.

Eğer takımda MAC adresi stabilitesi isteniyorsa, primary team interface üzerinden takımın mac adresini harhangi bir MAC adresine set edebilir.

VM’lerde MAC adres değişiklikleri desteklenmez.

İletilen Paketler Üzerinde MAC Adress Kullanımı

Switch independent mod ile adress hash/dynamic distribution konfigürasyonundan paketler tek bir kaynak üzerinden (Örneğin bir VM) aynı anda birden fazla takım üyesine dağıtılabilir. Hata durumunda source MAC adresi değişecektir. Birincil takım üyesinde bir hata oluştuğunda, yedeği olarak seçilen NIC’in MAC adresi kullanılmaya başlanır. Yalnız bu değişiklik, team’a gelen paketler için geçerli olacaktır. Giden trafik, hatadan önce kullanılan source MAC adresini kullanmaya devam edecektir. (aktarım bitene kadar)

Spesifik olarak:

Switch independent mod Adress hash distribution konfigürasyonunda,
- ARP, NS ve ICMP paketleri de dahil olmak üzere tüm special paketler primary team member üzerinden gönderilir.
- Birincil takım üyesi dışındaki NIC’ler üzerinden gönderilen trafik değiştirilen MAC adresiyle gönderilir.
- Birincil takım üyesindeki tüm trafik orjinal kaynak MAC adresiyle gönderilir. Bu MAC adresi yukarıda da açıklandığı gibi aynı zamanda team’in MAC adresidir.
Switch independent mod Hyper-V port distribution konfigürasyonunda,
- Her vmSwitch portu bir ekip üyesine duyurulmuştur.
- Her paket ekip üyesinden duyurulmuş olan porta gönderilir.
- Kaynak MAC adresi değiştirme işlemi yapılamaz.
Switch independend mod Dynamic distribution konfigürasyonunda,
- Her vmSwitch portu bir ekip üyesine duyurulmuştur.
- Tüm ARP/NS paketleri takım üyesinden duyurulmuş portlara gönderilir.
Switch dependent mod (tüm distributionlar) konfigürasyonunda,
- Kaynak MAC adresi değiştirme işlemi yapılmaz.

VLAN’ları Kullanmak

Vlan kullanırken aşağıdaki maddelere dikkat etmeniz faydalı olacaktır.

NIC teaming’i enable ettiğinizde host’un bağlı olduğu fiziksel switch’inizin portları “trunk” moda alınmalıdır. Fiziksel switch host’a olan tüm trafiği filtreleme modifikasyonu içermeden geçirmelidir.
NIC teaming’i enable ettiğinizde NIC’in gelişmiş özellikliklerinden VLAN filtlerelirini ayarlamamanız gerekir. Hyper-V switch varsa filtreleme yapabilirsiniz.

Hyper-V Host’ta Vlan’lar

Hyper-V host’a Vlanlar sadece Hyper-V Switch üzerinde yapılandırılmalıdır, NIC teaming ayarları üzerinden yapılandırılmamalıdır. Bu Vlan çarpışmasına ve iletişimin kopmasına neden olur.

Yukarıdaki örnekte bir Hyper-V host üzerinde çalışan üç adet VM görülmektedir. VM’ler hyper-v switcth’e, hyper-v switcth ise host üzerinde yapılandırılmış NIC teaming’e bağlıdırlar. Dikkat ederseniz, VLAN17 tag’i hem Hyper-V switch üzerinde hem de NIC teaming üzerinde tanımlanmıştır. VLAN17 tag’i kullanılarak host’a iletilecek bir trafik isteği NIC teaming modülü üzerinde kalır, asla VMC ye ulaşmaz. Diğer tag’ler ile işaretlenmiş tüm trafik hyper-v switch’ine ulaştırılır ancak VMC’ye ulaştırılmaz. Bu sıklıkla görülen ve yapılan bir hatadır. Bu sebeple Hyper-V host’ta Vlanlar mutlaka hyper-v swicth üzerinde yapılandırılmalıdır.

Fiziksel Network Segmentleri

NIC teaming layer 2’de çalışır. Yani takımdaki bütün NIC’ler aynı subnet’te olmalıdırlar. Bir NIC’ten diğer NIC’e olan trafiğin rotasını belirlerken layer 2 unsurları (switch’ler) kullanılmalıdır. Trafik, layer 3 (router’lar) unsurlarının olduğu yollardan geçirilmemelidir.

Sonuç : Buraya kadar aslında NIC Team mimarisi üzerinde daha fazla durdum. Şu şudur, bu budur diyerek geçmek istemedim. Başvuru kaynağı niteliğinde güzel bir makale oldu sayılır. Devamında Windows Server 2012 R2 üzerinde güzel bir örnek yapacağım.

Sevgilerimle.

Samet.