Virtual Swicth’ler için NIC Teaming-Failover Policy ve Load Balancing Algoritmaları

Makalede, VMware ortamında sıkça kullandığımız ve vSphere lisanslarında geçerli olan Virtual Swicth’lerde NIC Teaming&Failover Politikaları ve Yük Dengeleme (Load Balancing) algoritmalarını anlatmaya çalışacağım. Bu algoritmaların amacı, Single Point Of Failure yani Türkçe’si Tek Nokta Arızalarını tolere etmek ve fiziksel network erişiminde oluşabilecek sorunları en aza indirmektir.

Teaming ve Failover Policy :

NIC teaming, bir team’deki 2 veya daha fazla fiziksel NIC ekleyerek bir virtual switch’in network kapasitesini artırmanıza olanak tanır. Network adaptör arızası durumunda trafiğin nasıl yeniden yönlendirileceğini belirlemek için fiziksel NIC’leri yük devretme sırasına dahil edersiniz. Virtual switch’in network trafiğini bir team’deki fiziksel NIC’ler arasında nasıl dağıttığını belirlemek için ortamınızın ihtiyaçlarına ve yeteneklerine bağlı olarak load balancing algoritmalarını seçersiniz.

NIC Teaming Policy :

Switch’in network bant genişliğini artırmak ve yedeklilik sağlamak amacıyla bir virtual switch’i bir host’taki birden fazla fiziksel NIC’ye bağlamak için NIC teaming’i kullanabilirsiniz.

NIC team, trafiği üyeleri arasında dağıtabilir ve adaptör arızası veya network kesintisi durumunda pasif yük devretme sağlayabilir.

NIC teaming politikalarını vSphere Standard Switch için virtual switch veya port group düzeyinde ve vSphere Distributed Switch için port group veya port düzeyinde ayarlarsınız.

Aynı ekipteki physical switch’teki tüm port’lar aynı Layer 2 broadcast domain’de olmalıdır.

Load Balancing Policy :

Load Balancing (Yük Dengeleme) policy , network trafiğinin bir NIC ekibindeki network adaptörlerin arasında nasıl dağıtılacağını belirler.

vSphere virtual swcith yalnızca giden trafiğin yükünü dengeler. Gelen trafik, fiziksel swicth’teki load balancing (yük dengeleme) politikası tarafından kontrol edilir. Load balancing algoritmalarına aşağıda detaylı olarak değiniyor olacağız.

Network Failure Detection Policy :

Bir virtual switch’in yük devretme (failover) tespiti için kullandığı aşağıdaki yöntemlerden birini belirleyebilirsiniz.

  1. Link status only : (Yalnızca bağlantı durumu)

Yalnızca network adapter’ın sağladığı bağlantı durumuna dayanır. Çıkarılan kablolar ve fiziksel switch güç kesintileri gibi arızaları algılar. Ancak link status aşağıdaki yapılandırma hatalarını algılamaz:

  • Spaning tree tarafından engellenen veya yanlış VLAN’a yanlış yapılandırılmış Physical switch port gibi.
  • Bir fiziksel swicth’i başka bir network aygıtına (örneğin bir upstream switch ) bağlayan çekilmiş kablo.
  1. Beacon probing :
    Bir team içindeki tüm fiziksel NIC’lerde link hatası algılamak için fiziksel NIC’lerin gönderdiği Ethernet yayın çerçeveleri (broadcast frames ) veya işaret sinyallerini (beacon probe) gönderir ve dinler.

ESXi host’lar her saniye işaret paketleri (beacon packet) gönderir. İşaret araştırması (Beacon probing), ESXi host’a en yakın fiziksel swicth üzerindeki arızaları algılamak için en yararlıdır; burada arıza, host için bir link-down olayına neden olmaz.

Bir team içinde üç veya daha fazla NIC ile işaret araştırmasını (beacon probing) kullanın çünkü ESXi tek bir adaptörün arızalarını algılayabilir. Yalnızca iki NIC atanmışsa ve bunlardan biri bağlantıyı kaybederse, swicth hangi NIC’in hizmet dışı bırakılması gerektiğini belirleyemez çünkü her ikisi de (beacon )işaret almaz ve sonuç olarak tüm paketler her iki uplink’e gönderilir. Böyle bir ekipte en az üç NIC kullanılması, n-2 arızaya izin verir; burada n, belirsiz bir duruma ulaşmadan önce team’deki NIC sayısıdır.

Failback Policy :

Varsayılan olarak, bir NIC ekibinde bir failback politikası etkindir. Bir arızalı fiziksel NIC yeniden çevrimiçi duruma döndüğünde, virtual switch, yedeğe alınan NIC’in yerini alarak NIC’i tekrar etkin hale getirir.

Yük devretme sırasında ilk sırada yer alan fiziksel NIC aralıklı arızalarla karşılaşıyorsa, failback policy, kullanılan NIC’de sık sık değişiklik yapılmasına yol açabilir.

Physical switch, MAC adreslerinde sık sık değişiklik olduğunu görür ve bir adaptör çevrimiçi olduğunda, fiziksel switch port trafiği hemen kabul etmeyebilir.

Bu tür gecikmeleri en aza indirmek için fiziksel swicth’de aşağıdaki ayarları değiştirmeyi düşünebilirsiniz:

  1. ESXi host’a bağlı fiziksel NIC’lerde Spanning Tree Protocol’u (STP) devre dışı bırakın.
  2. Cisco tabanlı ağlarda, erişim arayüzleri için PortFast modunu veya trunk interface’ler için PortFast trunk mode’u etkinleştirin. Bu, fiziksel swicth port’un başlatılması sırasında yaklaşık 30 saniye tasarruf sağlayabilir.
  3. Trunk negotiation’ı devre dışı bırakın.

Notify Switches Policy :

Notify switches politikasını kullanarak ESXi host’un yük devretme olaylarını nasıl ilettiğini belirleyebilirsiniz.

Fiziksel bir NIC virtual switch’e bağlandığında veya trafik team’deki farklı bir fiziksel NIC’ye yeniden yönlendirildiğinde, virtual switch, fiziksel swicth’lerdeki arama tablolarını güncellemek için network üzerinden bildirimler gönderir.

physical switch bilgilendirme, bir failover veya vSphere vMotion ile migration oluştuğunda en düşük gecikmeyi sağlar.

Route Based on Originating Virtual Port

Virtual Swicth, vSphere Standard Switch veya vSphere Distributed Switch üzerindeki sanal makine sanal makine port ID’lerine dayalı olarak uplink’leri seçer.

Route Based on Originating VirtualPort, Standard ve Distributed Switch üzerindeki varsayılan load balancing yöntemidir.

virtual switch, bir sanal makine’nin için uplink’ini hesaplamak için, sanal makine port ID’sini ve NIC team’deki uplink’lerin sayısını kullanır.

Virtual switch bir sanal makine için bir uplink seçtikten sonra, makine aynı port üzerinde çalıştığı sürece trafiği her zaman bu sanal makine için aynı uplink üzerinden iletir. Virtual switch, uplink’ler, NIC team’e eklenmedikçe veya kaldırılmadıkça, sanal makineler için uplink’leri yalnızca bir kez hesaplar.

Bir sanal makinenin port ID’si, sanal makine aynı host üzerinde çalışırken sabitlenir. Sanal makineyi taşırsanız, kapatırsanız veya silerseniz, virtual switch üzerindeki port ID’si serbest hale gelir. Virtual switch, bu port’a trafik göndermeyi durdurur ve bu, ilişkili uplink’i için genel trafiği azaltır. Bir sanal makine açılırsa veya taşınırsa, farklı bir port’ta görünebilir ve yeni port ile ilişkili olan uplink’i kullanabilir.

Avantajları :

  • Sanal NIC’lerin sayısı team’deki fiziksel NIC’lerin sayısından fazlaysa, trafik eşit dağıtılır.
  • Virtual swicth, sanal makineler için uplink’leri yanlızca bir kez hesapladığından düşük kaynak tüketimi olur.
  • Physical switch üzerinde herhangi bir değişiklik gerekli değildir.

Dezavantajları :

  • Virtual switch, uplink’ler üzerindeki trafik yükünün farkında değildir ve trafiği daha az kullanılan uplink’lere yük dengelemez.
  • Bir sanal makinenin kullanabileceği bant genişliği, virtual machine birden fazla virtual NIC’e sahip olmadıkça, ilgili port ID ile ilişkili uplink’in hızı ile sınırlıdır.

Route Based on Source MAC Hash

Virtual switch, sanal makine MAC adresine dayalı olarak bir sanal makine için bir uplink seçer.

Virtual swicth, bir sanal makine için uplink’ini hesaplamada sanal makine MAC adresini ve NIC Team’deki uplink’lerin sayısını kullanır.

Avantajları:

  • Virtual switch her paket için bir uplink hesapladığı için , Route Based on Originating Virtual Port’a göre daha düzgün bir eşit dağılım söz konusudur.
  • MAC adresi statik olduğundan sanal makineler aynı uplink’i kullanır. Bir sanal makineyi açmak veya kapatmak, sanal makinenin kullandığı uplink’i değiştirmez.
  • Physical switch üzerinde herhangi bir değişiklik gerekli değildir.

Dezavantajları :

  • Bir sanal makinenin kullanabileceği bant genişliği, sanal makine birden fazla kaynak MAC adresi kullanmıyorsa, ilgili port ID ile ilişkili uplink’in hızı ile sınırlıdır.
  • Virtual switch , her paket için bir uplink hesapladığından Route Based on Originating Virtual Port’tan daha yüksek kaynak tüketimi vardır.
  • Virtual switch, uplink’lerin yükünün farkında değildir, bu nedenle uplink’ler aşırı yüklenebilir.

Route Based on IP Hash

Virtual switch, her paketin kaynak ve hedef IP adresine göre sanal makineler için uplink’leri seçer.

Bir sanal makine’nin uplink bağlantısını hesaplamak için virtual switch, paketteki hem kaynak hem de hedef IP adreslerinin son octet’ini alır, bunları bir XOR işlemine sokar ve ardından sonucu, NIC team’deki uplink sayısına dayalı olarak başka bir hesaplama yoluyla çalıştırır.

Herhangi bir sanal makine, kaynak ve hedef IP adresine bağlı olarak NIC team’deki herhangi bir uplink’i kullanabilir. Bu şekilde, her sanal makine team içindeki herhangi bir uplink’in bant genişliğini kullanabilir. Bir sanal makine, çok sayıda bağımsız sanal makinenin bulunduğu bir ortamda çalışıyorsa, IP hash algoritması, ekipteki NIC’ler arasındaki trafiğin eşit dağılımını sağlayabilir.

Bir sanal makine birden çok hedef IP adresiyle iletişim kurduğunda, virtual switch her bir hedef IP için farklı bir karma oluşturabilir. Bu şekilde, paketler virtual swicth’te daha yüksek potansiyel aktarımla sonuçlanan farklı uplink’ler kullanabilir.

Ancak ortamınızda az sayıda IP adresi varsa, sanal anahtar trafiği sürekli olarak team içindeki bir uplink üzerinden geçirebilir. Örneğin, bir uygulama sunucusu tarafından erişilen bir veritabanı sunucunuz varsa, sanal anahtar her zaman aynı uplink’i hesaplar, çünkü yalnızca bir kaynak-hedef çifti vardır.

IP hash load balancing’in doğru çalıştığından emin olmak için fiziksel switch üzerinde yapılandırılmış bir Etherchannel’ınız olmalıdır. Bir Etherchannel, birden çok ağ bağdaştırıcısını bir tek logical link’e bağlar. port’lar bir Etherchannel’a bağlandığında, fiziksel switch farklı port’larda aynı sanal makine MAC adresinden bir paket aldığında, switch content addressable memory (CAM) tablosunu doğru şekilde günceller.

Örneğin, fiziksel swicth , MAC adresi A’dan 01 ve 02 portlarından paketleri alırsa, switch, CAM tablosunda bir 01-A ve bir 02-A girişi yapar. Sonuç olarak, fiziksel switch gelen trafiği doğru port’lara dağıtır. Bir Etherchannel olmadan, fiziksel swicth önce MAC adresi A’dan bir paketin port 01’de alındığına dair bir kayıt yapar, ardından MAC adresinden A’dan bir paketin port 02’ye alındığına dair aynı kaydı günceller. Bu nedenle, fiziksel switch gelen trafiği yalnızca port 02 ve paketlerin hedeflerine ulaşmamasına ve karşılık gelen uplink’in aşırı yüklenmesine neden olabilir.

Sınırlamalar ve Yapılandırma Gereksinimleri :

  • ESXi host’lar, tek bir fiziksel switch veya stack switch’te IP hash teaming’i destekler.
  • ESXi host’lar , Static mode’da yalnızca 802.3ad link aggregation’ı destekler. vSphere Standard Switch’ler ile yalnızca statik bir Etherchannel kullanabilirsiniz. LACP desteklenmiyor. 802.3ad link aggregation olmadan IP hash load balancing’i etkinleştirirseniz ve bunun tersi olursa, ağ iletişimi kesintileri yaşayabilirsiniz.
  • IP hash load balancing ile ağ hatası algılama olarak “Link Status Only” kullanmanız gerekir.
  • Team’deki tüm uplink’leri Active failover list’te yarlamalısınız. Standby ve Unused listeleri boş olmalıdır.
  • Etherchannel’daki port sayısı, team’deki uplink sayısıyla aynı olmalıdır.

Avantajları :

  • Virtual switch her paket için uplink’i hesapladığı için Route Based on Originating Virtual Port ve Route Based on Source MAC Hash ile karşılaştırıldığında yükün daha eşit dağılımı söz konusudur.
  • Birden çok IP adresiyle iletişim kuran sanal makineler için potansiyel olarak daha yüksek aktarım hızı sağlar

Dezavantajları :

  • Diğer load balancing algoritmalarına kıyasla en yüksek kaynak tüketimi sağlar.
  • Virtual Swicth , uplink’lerin gerçek yükünün farkında değildir.
  • Physical network üzerinde değişiklik gerektirir.
  • Sorun gidermek işlemleri diğerlerine göre daha karmaşıktır.

Route Based on Physical NIC Load

Route Based on Physical NIC Load, virtual switch’in uplink’lerin gerçek yükünü kontrol ettiği ve aşırı yüklenmiş; uplink’lerde azaltmak için adımlar attığı Route Based on Originating Virtual Port‘u temel alır. Yalnızca vSphere Distributed Switch için kullanılabilir.

vSphere Distributed Switch, NIC team’deki port ID’lerini ve uplink’lerin sayısını alarak sanal makineler için uplink’leri hesaplar. vSphere Distributed Switch, her 30 saniyede bir uplink’leri test eder ve yükleri kullanımın yüzde 75’ini aşarsa, en yüksek I/O ‘ye sahip sanal makinenin port ID’si farklı bir uplink’e taşınır.

Avantajları :

  • Distributed switch, sanal makineler için uplink’leri yalnızca bir kez hesapladığı ve uplink’lerin kontrol edilmesinin minimum etkisi olduğu için düşük kaynak tüketimi sağlar.
  • Distributed switch , uplink’ler yükünün farkındadır ve gerekirse bunu azaltmaya özen gösterir.
  • Physical switch üzerinde herhangi bir değişiklik gerekli değildir.

Dezavantajları :

  • Sanal makineler için kullanılabilen bant genişliği, distributed switch’e bağlı uplink’lerle sınırlıdır.

Use Explicit Failover Order

Bu Policy gerçek load balancing kullanılamaz. Virtual switch, her zaman failover sırasındaki Active adapter’ler listesinde ilk sırada yer alan ve failover algılama kriterlerini geçen uplink’i kullanır. Active list’te uplink mevcut değilse, virtual switch Standby list uplink’leri kullanır.

Back to Top