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?