vSphere Distributed Switch ile ağ yapılandırması

Standard switch (vSS) her host'ta ayrı ayrı tanımlanıyor. Üç host'ta yeni bir VLAN için port group açmak, aynı işi üç kez yapmak demek. Bir host'ta port group adını yanlış yazarsan (VM-110 yerine VM-l10) vMotion o VM'i o host'a taşıyamıyor ve bunu ancak taşıma başarısız olunca fark ediyorsun.

Distributed switch (vDS) ağ yapılandırmasını vCenter'a taşıyor. Port group'u bir kez açıyorsun, cluster'daki bütün host'larda aynı adla, aynı VLAN'la, aynı ayarlarla görünüyor.

Burada bir yanlış anlamayı düzeltmek lazım: vDS'de trafik vCenter'dan geçmiyor. vCenter sadece yapılandırmayı tutuyor ve host'lara dağıtıyor, paketleri yine her host kendisi anahtarlıyor. vCenter kapansa da VM'ler ağda kalıyor. Kapanınca kaybettiğin şey, ayarları değiştirebilmek.

vDS de DRS gibi vSphere Foundation ve VCF paketlerinde var, eskiden Enterprise Plus özelliğiydi. Daha alt bir lisansın varsa önce bunu kontrol et.

Plan

Kurmadan önce kâğıda dökmek gereken üç şey var: VLAN'lar, fiziksel port'lar ve hangi trafiğin hangi port'u tercih edeceği.

Yönetim ile vMotion'ı farklı port'lara ayırmamın sebebi şu: vMotion bir 10G hattı birkaç saniyeliğine tamamen doldurabiliyor. Yönetim trafiği aynı port'tan geçerse HA heartbeat'leri gecikip host'u izole sanmaya başlayabiliyor. Her ikisi de diğer port'u yedek olarak kullanıyor, yani bir kablo koparsa ikisi de çalışmaya devam ediyor.

Fiziksel switch tarafı

Host'a giden switch port'ları trunk olmalı ve bütün VLAN'ları taşımalı. Varsayılan teaming yöntemiyle (aşağıda) port-channel ya da LACP yapılandırma, iki port bağımsız trunk olarak kalsın. Aruba AOS-CX üzerinde:

interface 1/1/10
    description esx01-vmnic0
    no shutdown
    no routing
    vlan trunk native 1
    vlan trunk allowed 20,21,110,120
    spanning-tree port-type admin-edge

admin-edge port'un bir switch'e değil uç cihaza bağlı olduğunu söylüyor, port açıldığında spanning-tree'nin dinleme beklemesini atlıyor. ESXi host'u köprü kurmadığı için bu güvenli. Atlanırsa host yeniden başladığında port'un forwarding'e geçmesini beklerken birkaç saniye kayboluyor ve HA bunu yanlış yorumlayabiliyor.

Jumbo frame (MTU 9000) kullanacaksan yolun her noktasında açık olmalı: fiziksel switch port'ları, aradaki uplink'ler, vDS ve VMkernel adaptörü. Bir noktada eksik kalırsa küçük paketler geçiyor, büyükler sessizce düşüyor ve vMotion "bazen" başarısız oluyor. Emin değilsen MTU'yu 1500'de bırak. 10G'de vMotion için fark çoğu ortamda hissedilmiyor.

Distributed switch'i oluşturmak

vSphere Client'ta Networking görünümünde datacenter'a sağ tıklayıp Distributed Switch, New Distributed Switch:

• Ad: DSwitch-Uretim
• Sürüm: host'larının desteklediği en yeni sürüm
• Uplink sayısı: 2
• Network I/O Control: açık
• Varsayılan port group: işaretini kaldır, port group'ları kendim açacağım

Sonra switch'e sağ tıklayıp Distributed Port Group, New Distributed Port Group ile tablodaki dört port group'u aç. Her biri için VLAN türü "VLAN" ve VLAN ID. Teaming ayarı port group'un "Teaming and failover" kısmında:

• Load balancing: "Route based on originating virtual port"
• Failover order: tablodaki aktif ve yedek uplink'ler

"Route based on originating virtual port" varsayılan yöntem ve fiziksel switch'te hiçbir ayar gerektirmiyor. Her VM'in sanal port'u bir uplink'e bağlanıyor, uplink koparsa diğerine geçiyor. Tek bir VM iki port'un toplam bant genişliğini kullanamıyor, ama on VM'lik bir host'ta trafik iki port'a dağılmış oluyor. LACP daha iyi dağıtım sunuyor ama fiziksel switch'te de yapılandırma istiyor ve sorun çıktığında hata ayıklaması daha zor. Gerçek bir ihtiyaç olmadıkça ben varsayılandan şaşmıyorum.

Yönetim ağını koparmadan geçiş

Riskli kısım burası. Host'un yönetim adaptörü (vmk0) şu an vSwitch0 üzerinde. Onu vDS'e taşırken yanlış bir adım host'u vCenter'dan koparıyor.

En güvenli yol iki adımlı geçiş. Önce host'ların fiziksel port'larından sadece birini vDS'e veriyorsun. Diğeri vSwitch0'da kalıyor ve yönetim bağlantısını taşımaya devam ediyor.

vDS'e sağ tıklayıp "Add and Manage Hosts", "Add hosts", üç host'u seç. Sihirbazın adımları:

1. Fiziksel adaptörler: Her host'ta vmnic1'i Uplink2'ye ata. vmnic0'a dokunma.
2. VMkernel adaptörleri: vmk0'ı Yonetim port group'una ata.
3. VM ağı: Şimdilik atla.

İkinci adım bittiğinde vmk0 vDS üzerinde, Uplink2 (yani vmnic1) üzerinden konuşuyor. Tablodaki planda Yonetim için Uplink2 yedek, ama Uplink1'e henüz fiziksel port bağlı olmadığı için yedeğe düşüp çalışmaya devam ediyor. Host'lar vCenter'da bağlı görünüyorsa ikinci aşamaya geç: aynı sihirbazı "Manage host networking" ile tekrar aç ve bu sefer vmnic0'ı Uplink1'e ata.

Bir şey ters giderse vCenter'ın bir emniyet kemeri var: yönetim bağlantısını koparan bir değişiklikten sonra host vCenter'a ulaşamazsa değişikliği kendiliğinden geri alıyor (network rollback). Varsayılan bekleme süresi 30 saniye. Buna güvenerek çalışmak yerine iki adımlı geçişi tercih et, ama bir şey kopar da yarım dakika içinde host geri gelirse sebebi bu.

Host'lar tamamen vDS'e geçtikten sonra VM'leri taşımak için Networking görünümünde vSwitch0 üzerindeki eski port group'a sağ tıklayıp "Migrate VMs to Another Network" var. Sonra boşalan vSwitch0'ı silebilirsin.

vMotion için VMkernel adaptörü

Her host'ta Configure, Networking, VMkernel adapters, "Add Networking":

• Tür: VMkernel Network Adapter
• Port group: vMotion
• Servisler: sadece "vMotion"
• IP: 10.0.21.11, 10.0.21.12, 10.0.21.13 (gateway yok, aynı subnet)

vMotion ağının yönlendirilmesine gerek yok, host'lar aynı L2'de birbirini görüyor. Bu ağı ayrı tutmak, VM'lerin bellek içeriğini taşıyan vMotion trafiğinin başka ağlara karışmaması için de iyi. vSphere, iki taraf da destekliyorsa vMotion trafiğini varsayılan olarak şifreliyor, ama ayrı bir VLAN yine de ilk savunma hattı.

Bağlantıyı host üzerinden test etmek için SSH ile bir host'a bağlanıp:

[root@esx01:~] esxcli network ip interface ipv4 get
Name  IPv4 Address  IPv4 Netmask   IPv4 Broadcast  Address Type  Gateway  DHCP DNS
----  ------------  -------------  --------------  ------------  -------  --------
vmk0  10.0.20.11    255.255.255.0  10.0.20.255     STATIC        0.0.0.0     false
vmk1  10.0.21.11    255.255.255.0  10.0.21.255     STATIC        0.0.0.0     false

[root@esx01:~] vmkping -I vmk1 10.0.21.12

Jumbo frame açtıysan gerçek testi şu: vmkping -I vmk1 -d -s 8972 10.0.21.12. -d paketin parçalanmasını yasaklıyor, 8972 de 9000'den IP ve ICMP başlıkları çıkınca kalan boyut. Bu ping geçmiyorsa yolda MTU'su 9000 olmayan bir nokta var.

vCenter kapalıyken ağ

vDS'in tek zayıf noktası vCenter kapalıyken ortaya çıkıyor. Varsayılan port binding ("static") ile bir VM'i vDS port group'una bağlamak vCenter'ın port ayırmasını gerektiriyor. vCenter VM'inin kendisi bir sorun yüzünden ağsız kalırsa, onu Host Client'tan vDS port group'una bağlayamıyorsun.

Bunun için yönetim VLAN'ında bir de "ephemeral" binding'li port group açmanı öneririm, örneğin Yonetim-Acil. Ephemeral port'ları host kendisi oluşturuyor, vCenter'a ihtiyaç duymuyor. vCenter'ın ağı bozulursa Host Client'tan vCenter VM'inin ağ kartını bu port group'a bağlayıp vCenter'ı geri getirebiliyorsun. Normal günlerde hiç kullanılmıyor, ama bir gün kullanıldığında saatler kazandırıyor.

Yedek almayı unutma

vDS'in yapılandırması vCenter'ın veritabanında duruyor. vCenter'ı yedekten geri dönmek zorunda kalırsan vDS de geri geliyor, ama bir değişiklikten önce tek başına yedek almak istersen: switch'e sağ tıklayıp Settings, Export Configuration. Çıkan zip dosyası aynı menüdeki "Restore Configuration" ile geri yükleniyor. Büyük bir değişiklikten (uplink yeniden düzenleme, teaming değişikliği) önce bu dosyayı almak iyi bir alışkanlık.

Ağ, cluster ve vCenter hazır. Sıradaki yazıda bunların hepsini arayüze tıklamadan PowerShell ile sorgulayıp yönetmeye geçiyorum.

Sıradaki yazı: PowerCLI ile vCenter otomasyonu