VSAN Network Gereksinimleri ve Tasarımı

vSAN, sanal makine oluşturma ve deployment işlemlerinin bir parçası olarak VMware vCenter Server içinde hızlı depolama olanağı sağlayan dağıtılmış ve paylaşılan bir depolama çözümüdür.

vSAN’ı bir Cluster ve ESXi Host’larda etkinleştirmeden önce, vSAN iletişimini taşımak için gerekli network’ü kurmanız gerekir.

VSAN network’ü, standard veya distributed switchlerle oluşturulur. Host’lar vSAN network’e erişmek için bir VMkernel adaptör kullanır.

ESXi Host’lar, en iyi network performansı için aynı subnet’te olmalıdır. VSAN 6.0 ve sonraki sürümlerinde, gerekirse aynı Layer 3 ağındaki host’larıda bağlayabilirsiniz.

vSAN hybrid konfigurasyonunda VMware, vSAN network trafiği için 1 GB, 10 GB, 25 GB, 40 GB ve 100 GB Network Interface Card’ları (NIC) destekler. Bir 1 Gb NIC kullanılıyorsa, bu NIC vSAN trafiğine tahsis edilmelidir. 10 GB veya daha yüksek bant genişliğine sahip bir NIC kullanılıyorsa, bunlar diğer network trafiği türleriyle paylaşılabilirsiniz.

vSAN all-flash konfigurasyonu yalnızca 10 GB veya daha yüksek bağlantılarla desteklenmektedir. Bunun bir nedeni, all-flash konfigurasyonunda gelişmiş performans ve daha yüksek verimlilik elde etmek için host’lar arasında daha fazla network bant genişliğinin kullanılabilmesinden kaynaklanır.

Her iki yapılandırmada, 10 GB ve daha yüksek bağlantıları vMotion, vb. gibi diğer network trafiği türleri ile paylaşılabilirler. Bir 10 GB (üstü) NIC birden fazla trafik türü arasında paylaşılıyorsa, bir trafik türünün tüm bant genişliğini sature etmesini önlemek için Network I/O Control kullanılması önerilir.

Fiziksel NIC Destek Durumu

+10Gb support

1Gb support

Comments

Hybrid Cluster

Y

Y

10Gb recommended, but 1Gb

Supported <1ms RTT

All-Flash Cluster

Y

N

All Flash requires 10Gb. 1Gb not

Supported <1ms RTT

Stretched Cluster Data to Data

Y

N

<5ms RTT, 10Gb required between

data sites

Stretched Cluster Witness to Data

Y

Y

<200ms RTT, 100Mbps

Connectivity required from

data sites to witness

2-node Data to

Data

Y

Y

10Gb required for All-Flash, 1Gb

supported for hybrid, but 10Gb

recommended

2-node Witness

to Data

Y

Y

<500ms RTT, 1.5Mbps

Bandwidth required

Farklı site’lere yerleştirilen vSAN sunucuların kabinlere Fault Domain  (rack awareness) uygulamak için hangi lisansların gerekli olduğu ve bunun vSAN stretched clustering ile nasıl karşılaştırıldığı konusunda temel olarak, aşağıdaki tablo farklı konfigurasyonlar / deployment tiplerini tanımlar ve her uygulama türü için hangi lisans sürümünün gerekli olduğunu vurgular.

Maximum number of nodes

Distance

Performance Considerations

Licensing

Witness Considerations

Sites

Stretched Cluster 15+15+W  N/A  <5ms RTT, 10Gb  Enterprise Dedicated witness host/appliance

3**

Stretched Cluster 1+1+W*  N/A  <5ms RTT, 10Gb  Standard or higher  Dedicated witness host/appliance

3**

All-Flash Fault Domains 64  N/A  Performs at LAN levels, (<1ms RTT) 10Gb bandwidth  Standard or higher  No dedicated witness. Witness Objects distributed across all fault domains 

>1**

Hybrid Fault Domains 64  N/A  Performs at LAN levels,
(<1ms RTT)  1Gb bandwidth supported but 10Gb recommended 
Standard or higher  No dedicated witness. Witness distributed across all fault domains 

>1**

vSAN, cluster’daki her host’ta belirli portlara mesajlar gönderir.

Host güvenlik duvarlarının bu portlarda trafiğe izin verdiğinden emin olmamız gerekmektedir.

vSAN Service Traffic Direction
Communicating Nodes Transport Protocol Port
vSAN Vendor Provider (vsanvp)

Incoming and outgoing

vCenter Server and ESXi TCP 8080
vSAN Clustering Service ESXi UDP 12345, 23451
vSAN Transport ESXi TCP 2233
Unicast agent ESXi UDP 12321
vSAN Management vCenter Server and ESXi TCP 443

Networking Failover ve Load Balancing

Teaming, bir vSwitch’te birden fazla Active uplink veya bir Active / Standby uplink yapılandırmasına sahip olacak şekilde yapılandırılabilir.

Temel NIC teaming için fiziksel switch katmanında Ether-channel veya Link Aggregation gibi özel bir konfigürasyon gerekli değildir.

vSAN, vSphere tarafından sağlanan temel NIC teaming ve failover policy özelliğini kullanır. vSAN load balancing için NIC teaming kullanmaz.

Bir NIC team yapılandırmayı planlıyorsanız, aşağıdaki failover yapılandırmalarını göz önünde bulundurmanız gerekmektedir.

Teaming Algorithm Failover Configuration of the Adapters in the Team
Route based on originating virtual port Active/Passive
Route based on IP hash Active/Active with static EtherChannel for the standard switch and LACP port channel for the distributed switch
Route based on physical network adapter load Active/Active

vSAN, aynı subnet’te birden fazla VMkernel adaptörünü desteklemez. Başka bir VLAN veya ayrı fiziksel kart gibi farklı subnet’lerde farklı VMkernel adaptörlerini kullanabilirsiniz.

 vSAN Network’te Unicast

VSAN 6.6 ve sonraki sürümlerde, vSAN cluster’ı destekleyen fiziksel switch’lerde multicast gerekli değildir.

VSAN’ın önceki sürümlerinde, heartbeat özelliğini etkinleştirmek ve cluster’daki host’lar arasında metadata değişimi yapmak için multicast kullanılırdı.

VSAN için basit bir unicast ağı tasarlayabilirsiniz.

Unicast’ın multiple-cluster ortamlarında kullanılması, aynı VLAN’da farklı cluster’ların vSAN trafiğini kullanılmasına izin verir çünkü vCenter Server sub-cluster ID’yi kontrol eder.

Network I/O Control Kullanarak vSAN için Bandwidth Tahsis Etme

vSAN trafiği, 10 GbE fiziksel network adaptör’lerini vSphere vMotion trafiği, vSphere HA trafiği ve sanal makine trafiği gibi diğer sistem trafiği türleriyle paylaşabilir.

VSAN için gereken bant genişliği miktarını garanti etmek için vSphere Distributed Switch’te vSphere Network I/O Control kullanılmalıdır.

vSphere Network I/O Control’de vSAN outgoing trafiği için reservation ve share yapılandırabilirsiniz.

Network I/O Control, vSAN için fiziksel adaptörde minimum bant genişliğinin mevcut olduğunu garanti edecek şekilde bir rezervasyon yapılmalıdır.

VSAN için atanan fiziksel adaptör sature olduğunda, vSAN için belirli bir bant genişliği mevcut olacak ve vSAN’ın rebuild ve synchronization işlemleri sırasında fiziksel adaptörün tüm kapasitesini tüketmesini engelleyecek şekilde ayarlanması gerekmektedir.

Örneğin,
vSAN, vSphere vMotion ve sanal makineler için trafiği işleyen 10 GbE’lik bir fiziksel adaptörde, belirli bant genişliğini ve paylaşımları yapılandırabilirsiniz.

10 GbE adaptör sature olduğunda, Network I/O Control fiziksel adaptör üzerinde vSAN’a 5 Gbps atar.

Traffic Type

Reservation ,Gbps

Share

vSAN

1

100

vSphere vMotion

0,5

70

Virtual Machine

0,5

30

Marking vSAN Traffic

Priority tagging, vSAN trafiğinin yüksek Quality of Service (QoS) taleplerine sahip olduğunu bağlı ağ cihazlarına gösteren bir mekanizmadır.

VSAN trafiğini belirli bir sınıfa atayabilir ve trafiği buna göre 0 (low priority) ile 7 (high priority) arasında Class of Service (CoS) değeriyle işaretleyebilirsiniz. Priority level ‘ı yapılandırmak için vsphere Distributed Switch’de “Traffic filtering and marking” policy özelliği kullanılmalıdır.

vSAN Trafiğini bir VLAN’da İzole Etmek

Gelişmiş güvenlik ve performans için vSAN trafiği bir VLAN’da izole edilmelidir. Bu özellik çeşitli trafik türleri arasında bir fiziksel adaptör paylaşılıyorsa mutlaka yapılmalıdır.

Jumbo Frame :

VMware vSAN, vSAN network’ündeki Jumbo Frame’leri destekler. Jumbo Frame’ler 1500 byte’tan fazla yük taşıma kapasitesine sahip ethernet frame’lerdir. Jumbo Frame’ler 9000 byte’a kadar yük taşıyabilir. CPU performansını artırmak için jumbo frame’leri vSAN ile kullanmayı planlıyorsanız, jumbo frame’lerin cluster’daki tüm network cihazlarında ve host’larda ayarlanması gerekmektedir.

Basic NIC Teaming

Failover ve Redundancy

Teaming, bir vSwitch’te çoklu Active uplink’ler veya bir Active/Standby uplink yapılandırmasına sahip olacak şekilde yapılandırılabilir. Basic NIC teaming için fiziksel switch katmanında Ether-channel veya Link Aggregation gibi özel bir konfigürasyon gerekli değildir. vSAN, vSphere tarafından sağlanan temel NIC teaming ve failover policy’i kullanır.

Not:
vSAN, (load balancing )yük dengelemesi için NIC teaming kullanmaz.

Tipik bir NIC team konfigürasyonuna ve bununla ilişkili ayarlar aşağıdaki gibidir. Ayarlar ile ilgili detaylı bilgiler aşağıdaki gibidir :

Load balancing :

Load balancing 1: Route based on originating virtual port

Active/Active veya Active/Passive konfigurasyonda “Route based on originating virtual port” normalde temel NIC teaming için kullanılan policy’dir. Bu policy etkin olduğunda, VMkernel portu yalnızca bir fiziksel NIC kullanılır.

Artıları

    • Çok düşük fiziksel switch konfigurasyonu ile en basit teaming modudur.
  • vSAN trafiği için tek bir port olduğundan sorun giderme daha kolaydır.

Eksileri

  • Tek bir VMkernel interface, tek bir fiziksel NIC’in bant genişliğinden daha fazlasını kullanamaz. Tipik vSAN ortamları bir VMkernel Adapter kullandığından, team içindeki yalnızca bir fiziksel NIC kullanılır.

Load balancing 2: Route Based on Physical NIC Load (Load Based Teaming)

Sadece vSphere Distributed Switch’te kullanılabilen Route Based on Physical NIC Load virtual switch’te uplink’lerin gerçek yükünü kontrol ettiği ve aşırı yüklenen uplink’lerde azaltmak için diğer uplinklere yük attığı bir load balancing yöntemidir.

vSphere Distributed Switch , sanal makinelerin uplink’lerini, port ID ve NIC team’deki uplink sayısını baz alarak 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 olan sanal makinenin port ID’si farklı bir uplink’e taşır.

Artıları

    • Bu algoritmanın çalışması için LACP gibi bir fiziksel switch yapılandırması gerekmemektedir.
  • Her ne kadar vSAN bir VMkernel port’a sahip olsa da, aynı uplink’lerin diğer VMkernel port’lar/network servisleri tarafından paylaşıldığında yararlı ve etkili olacaktır. vSAN, diğer rakip servislerden (örneğin, vMotion, Management) farklı bir uplink kullanarak yararlanabilir.

Eksileri

    • vSAN tipik olarak yalnızca bir VMkernel port yapılandırmasına sahip olduğundan, bu algoritmayı bir vSAN ortamında load balancing elde etmek için kullanma etkinliği sınırlıdır.
  • ESXi VMkernel belli zaman aralıklarından yükü yeniden değerlendireceği için bu küçük bir ek yüke neden olacaktır.

Setting: Network failure detection

“Link status only” varsayılan değerinde bırakılmalıdır.

Setting: Notify Switches

Default “Yes” değerinde bırakılmalıdır. Fiziksel switchler , MAC adres yönlendirme tablolarına sahiptir. Tablolar, her bir MAC adresini fiziksel bir switch portuyla ilişkilendirmek için kullanılır. Bir frame girdiğinde, switch tablodaki hedef MAC adresini arayacak ve frame’e hangi fiziksel portun gönderileceğine karar verecektir.

Bir NIC failover meydana gelirse, ESXi host’un swicthlere bir şeylerin değiştiğini bildirmesi gerekir, aksi takdirde fiziksel swicthler MAC adres tablolarında eski bilgileri aramaya devam edebilir ve frame’leri eski port’a gönderebilir.

Notify Switches
“Yes” olarak ayarlanmışsa ve bir fiziksel NIC’in fail durumunda trafik team’deki farklı bir fiziksel NIC’ye yönlendirildiğinde, virtual swicth fiziksel swicth’lerdeki arama tablolarını güncellemek için network üzerinden bildirimler gönderir.

Setting: Failback

Bu seçenek, bir hatadan çıktıktan sonra bir fiziksel adaptörün aktif göreve nasıl döndürüleceğini belirler. Bir failover olayı, bir NIC’den diğerine geçmesi için ağ trafiğini tetikler. Kaynak NIC’de bir link up durumu tespit edildiğinde, Failback “Yes” olarak ayarlanmışsa trafik otomatik olarak orijinal network adaptörüne geri dönecektir. Failback “No” olarak ayarlandığında, manuel bir geri dönüş gerekli olacaktır.

Failback “No” olarak ayarlanması bazı senaryolarda yararlı olabilir. Örneğin, fiziksel bir swicth portu bir arızadan kurtulduktan sonra, port aktif olabilir (yanar) ancak trafiği yönlendirmeye başlamak birkaç saniye sürebilir. Otomatik Failback’in Spanning Tree Protocol kullanan bazı ortamlarda sorunlara neden olduğu bilinmektedir.

Settings: Failover Order

Failover order , normal operasyon sırasında hangi uplink’lerin active olduğunu ve failover durumunda hangi uplinklerin active olduğunu belirler. VSAN network’ü için farklı desteklenen yapılandırmalar mümkündür.

Failover Order: Active / Standby Uplinks

Bir uplink’in Active ve bir uplink Standby olarak atanmış olması bir Active/Standby kurulumunu tanımlar. Bir arıza durumunda, NIC driver vSphere’e Uplink 1’de bir link down olayı olduğunu bildirir. Standby uplink daha sonra “active” hale getirilir ve trafik Uplink 2’de devam eder.

Failover Order: Active / Active Uplinks

Active/Active vSAN trafiği tarafından kullanılan virtual port’un her iki port’ü aynı anda kullanmasına izin vermemektedir.

Teaming, hem Uplink 1 hem de Uplink 2 için “Active” olarak atanacak şekilde yapılandırılmışsa, Standby Uplink’in tanıtılmasına gerek olmadığından arıza yönetimi biraz farklıdır.

Active/Active olarak ayarlama yapılmışsa , “Failback” “No” olarak ayarlanmalıdır.

Kaynak : https://storagehub.vmware.com/

https://docs.vmware.com/

Leave A Comment

Your email address will not be published. Required fields are marked (required):

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Back to Top