MultiNIC vMotion – legyen gyors vagy egyszerű

A virtualizáció kétségtelen előnye, hogy az ily módon virtuális formában létező gépek könnyen és transzparens módon mozgathatók a virtualizációs hosztok között. Általában igen alacsony kieséssel – bár vannak olyanok, akik azt hiszik elismert talácsadóként, hogy a vMotion teljes idejére stun-ba kerül a VM, de nem tisztem nekik elmondani, hogy fogalmatlanok – akár egy teljes ESXi-t percek alatt leüríthetünk. A vMotion még 2003-ban került be az akkori úgynevezett “VMware Virtual Infrastructure 2.0” kiadásba. Persze azóta sok-sok fejlesztés ment bele:

  • VMotion in ESX 3.0 (2006):
    Lehetségessé vált azonos gyártótól, de más konkrét CPU-k közötti migráció, illetve olyan VM-ek mozgatása, amelyek több NIC-el rendelkeztek.
  • VMotion in ESX 3.5 (2007):
    64-bites VM-ek számára is opció lett a vMotion.
  • VMotion in ESX/ESXi 4.0 (2009):
    Megjelent az EVC (Enhanced VMotion Compatibility) ami végre azonos gyártótól, de különböző generációk között tette lehetővé a vMotion-t ezzel nyilván nagyon lendítve például egy újabb hardverre történő átállás komplexitásának csökkentésén. Itt jött be a Storage vMotion is.
  • VMotion in ESXi 5.0 (2011):
    Átdolgozták a vMotion lelkét, hogy kicsit gyorsabban migráljon és itt jött me a long distance vMotion lehetősége – például olyan kapcsolaton, aminek késleltetése nem éppen alacsony.
  • VMotion in ESXi 5.1 (2012):
    Támogatott lett vSphere Metro Storage Cluster (vMSC) kiépítésben is.
  • VMotion in ESXi 5.5 (2013):
    Újabb motorház alatti fejlesztés, hogy jobb teljesítménnyel és alacsonyabb hoszt oldali terheléssel mehessenek a vMotion feladatok, magas skálázódás mellett.
  • VMotion in ESXi 6.0 (2015):
    vCenter-ek közötti vMotion lehetősége itt jött be (Cross-vCenter VMotion)
  • VMotion in ESXi 6.5 and 6.7 (2016/2018):
    Újabb változások a sebességet illetően.
  • VMotion in ESXi 7.0 (2020):
    Titkosított VM-ek is támogatottak lettek.

A vMotion működéséhez nem kell sok egyéb, mint legalább egy vmkernel port, amelyen a vMotion szolgáltatás be van kapcsolva. Egy ESXi alaptelepítését követően nincs ilyen, ezt engedélyezni kell.

De jó-e ez így?

Általában nem, de elképzelhető persze olyan, hogy annyira kis rendszerről van szó és nem vonatkoznak rá olyan biztonsági szabályok és a skálázhatóság sem olyan fontos. Két pontból közelíteném meg a lehetésges opciók tárgyalását, mégpedig fizikai kábelezés és a logikai hálózat irányából.

Egy több ESXi-ből álló VMware klaszter esetén alapnak veszem, hogy minden kiszolgáló azonos módon van bekötve és adott portok felkonfigurálva. Ma már nem kevés azon rendszerek száma, ahol legalább 10Gbit-es hálózati portok használtak és emelkedik azok száma, ahol 25/40 Gbit a sávszélesség. Ha ilyen rendszerről van szó, akkor tipikusan két kábel per hoszt szokott lenni a képlet és technikailag minden forgalom ezen a két kábelen történik, csak mondjuk több VLAN-ba szortírozva.

A fenti példában a management vmkernel forgalma – a vCenter felé/től, a többi hoszt felé, a mentőrendszer felé(ha az olyan) történik ÉS a vMotion. Azonban nagyon lényeges az, hogy a vMotion igazából – ebben a példában – layer 2-t igényel a hosztok között, szóval annak mégis miért kellene gateway. Nem fordulhat olyan elő, hogy olyan hosztra történne vMotion, ami nincs azonos VLAN-ban a forrás vMotion vmkernel IP-jével. Amennyiben ez szükséges akkor méginkább érdemes a vMotion-t saját TCP/IP stack-be tenni és ott a vMotion VLAN átjáróját konfigurálni.

Előbbi esetben javasolt – többek között biztonsági, skálázhatósági és hibakeresési okok miatt – a vMotion forgalom számára egy saját VLAN használata. Ettől még fizikailag ugyanazon a kábelen bonyolódik a forgalom, de abból a hálózatból így nem lesz kijárat, mivel nem is kell – van olyan hogy kellhet.

Kell-e fizikailag másik kábel? Persze! Ha van rá lehetőség és ennek elsősorban költségek szintjén vannak igényei, akkor a több interfész persze még jobb. Minden rendszerben törekszem az egyszerűségre, szóval én szeretem ha valami nem szükségszerűtlenül a legbonyolultabb. Ha van két interfészem per szerver és mindkét fizikai kábelt aktívan szeretném használni, akkor vagy LACP-t kell csinálni – ja persze ott a static port channel is(sic) – vagy a port group-ok szintjén kell az active/standby uplink interfészekkel okosan bánni.

Az Uplink 1-en például lehet aktív a management és sok más VM-ek által is használt port group úgy, hogy a standby az Uplink 2, a vMotion vmkernel pedig lehet aktív az Uplink 2-n és csak vész esetén kerül át az Uplink 1-re. Üzemszerű működés esetén így mindkét interfészt aktívan használja a rendszer és nem vittünk bele sok komplexitást.

De lehetne ezt még jobban skálázni?

Persze hogy lehet, méghozzá egy újabb vMotion vmkernel beállításával. Sőt igazából lehet kettőnél több is, de maradjunk a realitások talaján. Ilyen esetben sem történik más az előző példát véve alapul annyi különbséggel, hogy a vMotion nem csak az egyik Uplink-et terheli aktívan, hanem mindkettőt. Egy ilyen beállítás alapja az, hogy a két vMotion vmkernel azonos VLAN-ban legyen. És pont ez az a pont, ahol a legtöbb kusza információ fellelhető és a gyártó dokumentációja nem önt tiszta vizet a pohárba. Nem állítja azt, hogy azonos VLAN-ban kell legyen, de nem írja azt sem, hogy nem lehet különbözőben. Maradok annál, hogy azonos VLAN-ban lesz a két vmkernel port.

A két Network Label mezőben a vmk1 és vmk2 esetén átható az eltérés. Ezen port group-ok beállítása így néz ki.

Eltérés csak az Active uplinks kapcsán van.

Egy biztos, minden vMotion intefész el kell érje az összes más vMotion interfészt, ezért ha két különböző VLAN-ban vannak, akkor mégis kell nekik átjáró a vMotion hálózatokon, ami pedig pont azzal megy szembe, amit korábban feltételként szabtunk, mégpedig hogy amennyire csak lehet, lokálissá tesszük a vMotion forgalmat. Itt meg arról beszélünk, hogy routing-ban találkoznának, ami könnyen lehet egy tűzfal. Nem hiszem, hogy bárki szeretné a vMotion forgalmat a tűzfalán megjáratni.

Hány vMotion fog menni egymással párhuzamosan?

A válasz keresése puszta matematika, mivel a VMware ebben az esetben – is – egy pontokon alapuló rendszert használ.

A hálózati interfészek sávszélessége adja meg a maximális kiosztható pontot per NIC:

  • 1 Gbit-es NIC esetén ez a szám 4.
  • 10GBit-es NIC esetén ez a szám 8.
  • 25Gbit-es NIC esetén ez a szám szintén 8.

Egy vMotion feladat 1 pontot kér. Egy ESXi kiszolgálónak is vannak pontjai, ami a 6.X/7.X és 8.X esetén 8. (link)

Tehát tegyük fel, hogy egy hosztot maintenance módba teszünk. Ennek van 8 pontja, szóval egy 10Gbit-es NIC-et használó vmotion vmkernel esetén elindul 8 darab vMotion. (feltételezzük hogy a vMotion céljaként adott hoszt is azonos NIC-ekkel rendelkezik és nincs folyamatban róla semmi egyéb vMotion/Storage vMotion) Ha két darab vMotion NIC-et és vmkernel-t használok, akkor is csak 8 darab párhuzamos mozgatás indul el. Ha négy NIC-et állítok be és négy vMotion vmkernelt csinálok, akkor ez a szám nem tud magasabb lenni, mivel a hosztnak 8 kredit a kapacitása.

Ha van egy 25Gbit-es interfészem, akkor szintén “csak” nyolc indul, de könnyen lehet hogy amúgy a teljes folyamat gyorsabban lemegy és végül a hoszt hamarabb kerül maintenance módba, de tegyük hozzá ez VM-ről VM-re változhat, semmi sem fix. Pont ez a lényege a nagyobb sávszélességű portoknak, nem az hogy több párhuzamos vMotion fusson, hanem egy hogy vMotion folyamat a lehető leggyorsabban befejeződjön.

A VMware állításai szerint a vSphere 7.0U1 képes kiterhelni egy 10Gbit-es vMotion interfészt, az U2 pedig egy 100Gbit-est is – ha van elég kakakó a hosztban. Ebből kiindulva lényegében teljesen mindegy mit csinálunk “csak” 8 vMotion folyamat megy majd egyszerre, de egy VM-re nézve a vMotion folyamat sokkal gyorsabban megtörténhet.

De akkor mi a tuti?

Nincs tuti….

Ha két interfésze van a hosztoknak, akkor három opció van:

  • egy vMotion vmkernel, LAG/LACP és NIOC – hogy ne terhelje ki a vMotion
  • egy vMotion vmkernel azon az uplink-en amit minden más csak standby használ
  • két vMotion vmkernel és NIOC

Itt szertem alapul venni a VMware Cloud Foundation dokumentációját és ott van pár érdekes javaslat:

“VMware Cloud Foundation do not support the use of EtherChannel configurations like LAG,LACP or VPC” Ennek inkább a VCF telepítésével összefüggő okai vannak, mivel a telepítés úgy kezdődik, hogy a management – vagy később workload – domaint alkotó hosztoknak egy standard switch-el vannak konfigurálva és a telepítési folyamat hozza létre majd a vDS-t és teszi át az uplink-et. Ezt pedig LAG/LACP mellett nem lehet automatizálni a hálózati eszközök állítgatása nélkül.

Ettől függetlenül én szeretek erre hivatkozni és jelezni, hogy még a VCF is azonos NIC-eken és vDS-en kezeli a vMotion és legalább a management forgalmat csak ő “Route based on physical NIC load” mellett. tehát még ez sem használ MultiNIC vMotion-t, miért bonyolítanánk meg egy nem VCF rendszert ezzel?