A VMware ESX 3.5 és a Hyper-V összehasonlítása – 6. kör

Ezúttal a hálózati képességeket vesszük górcső alá. Ha a alcímet is lehetne adni a bejegyzések címe mellé, akkor azt írnám "Sok hűhó semmiért". A táblázat ugyan szép számmal tartalmaz tulajdonságokat (még ha a TSO és a Jumbo Frames már szerepelt is korábban), valójában azonban kevés releváns és fontos képesség van közöttük. A kötelező köröket természetesen mindenki teljesítette: már nem virtuális hubokról, hanem switchekről beszélünk. Minden gond nélkül tudunk bármelyik termék esetén privát, a hosttal közös, vagy kívülről is elérhető hálózatot definiálni. Végre nem gond a VLAN támogatás a Hyper-V számára sem – ez a VS 2005-höz képest újdonság. A virtualizációs technológia sajátossága a "tetszőleges mennyiségű" virtuális hálózati kártya születése és kimúlása – valahogy tehát kezelni kell a virtuális MAC címeket. Mindkét szoftver képes mind statikus, mind pedig dinamikus címallokációra, de menedzsment szoftver hiányában ez csak korlátozottan valósítható meg, és ebben sincs különbség. A switchek maximális száma és a switch portok száma az ESX-nél korlátozott, de ha a korlátokat összevetjük az egyidejűleg futtatható gépek számával, akkor látható, hogy ez a korlát nem korlát. Az ESX Hyper-V-vel szembeni egyetlen komoly hiányossága az iSCSI támogatásnál mutatkozik. A szülőpartíció képességei révén a Hyper-V vel gyorsabbak lehetnek az iSCSI SAN-ok.

Van aztán egy csomó olyan ESX képesség, amelyre a Hyper-V-ben beépített megoldás nincs. Ezek szinte kivétel nélkül a "port Grouping" funkcióhoz kötődnek (5-11 sor a táblázatban). Amikor először olvastam a VMware dokumentációt a Port Group funkcióról, nem értettem, mire való. Aztán amikor másodszor olvastam, azt gondoltam, ez "király" és "világmegváltó". Ripsz-ropsz WAN hálózatot lehet összeütni virtuális switchekből és lehet tesztelni a tesztelnivalót. No és mi a helyzet az éles környezetben? Mennyi értelme van pl. a virtuális switch autonegotiate képességének? Nem az a lényeg, hogy toljuk át az adatot egyik gépről a másikra, ahogy csak bírjuk? Mi értelme van a Promiscous mód detektálásának és tiltásának, ha mind a virtuális, mind pedig a fizikai világnak mi vagyunk az urai? És minek néhány tucat, extrém esetben százegynéhány gép esetén switch házirendekben gondolkodni. Nem értettem.

Aztán leesett: VM hosting! Ha SLA csoamgokat kell összeállítani, akkor a házirend alapú, technológiai korlátokat szabó megoldások elég dekoratívak. Ha védekezni kell a bérbe vevővel szemben, akkor a promiscous mód figyelése és tiltása hasznos lehet. Ha megadjuk, hogy a bérelt infrastruktúrában mekkora sávszélességgel érhető el az Internet, akkor a házirend megint segíthet. És kik lennének az infrastruktúra megújításában az élenjárók, ha nem a hosting és outsourcing cégek. Lehet, hogy már az ESX 1.0 is használták.

Arra azért senki ne vegyen mérget, hogy ezek után a Hyper-V alkalmatlan lenne a hostingra. A myhosting.com és a Hostbasket is a Hyper-V mellett döntött, pedig ez utóbbi 1200 szervert felügyel, amit mindennek lehet mondani, csak kicsinek nem. Miért is lehetséges ez? Azért, mert a fenti szofisztikált módszerek nélkül is működhet SLA, megoldható a biztonság stb. stb. Maga az ESX is hordoz magában hiányosságokat (pl. port tükrözés), ilyenkor többnyire vagy a fizikai hálózatot kell segítségül hívni, vagy ha az nem oldható meg, akkor LiveCD-s szoftverdisztribúciók úszhatnak be a képbe. Ugyanez igaz a Hyper-V esetén is. Hiányzik a sávszélesség szabályozás? Egy 128 MB-os zeroshell letöltésével – akár VHD nélküli virtuális géppel is kipipálható a feladat.

Van egy olyan képesség, amely nem a Port Grouping témakörébe tartozik és meglehetősen sok figyelmet kapott, hála a VMware kommunikációs csapatának, ez pedig a NIC Teaming. A VMware ESX-nek egy nagyon jó, a GUI-ra integrált, intuitív kezelőfelülete van hálózati kártyák együttes kezelésére, lehetővé téve ezzel a sávszélességek aggregálását és/vagy redundáns konfiguráció kialakítását. Gyakran felhozott érv a Hyper-V-vel szemben, hogy nincs benne NIC Teaming támogatás. Nos, ez így, ebben a formában nem igaz.

Tény: a Windows szerverek egyik változatában sincs NIC Teaming támogatás a Microsoft részéről. Viszont van NIC Teaming támogatás a hardver szállítók oldaláról. Tehát a HP, az IBM, a DELL meg a többiek elkészítették a maguk eszközmeghajtóit és biztosítanak NIC teaminget. A kérdés már csak az, hogy mennyire működnek ezek a meghajtók Hyper-V környezetben, tekintettel arra, hogy a szülőpartíció is virtualizált gép és a hálózati kártyák virtuális switcheket reprezentálnak. Igazság szerint a legutóbbi időkig nem volt túl fényes ez a történet. Augusztustól azonban a HP Network Configuration Utility 9.30.0.0 (Support pack 8.11) már jól működik. Hasonlóan a Broadcom eszközök is a 11.32 verziótól hozzák az elvárt teaming képességet. Mindez nem integrált a Hyper-v kezelőfelületével, de funkcionalitás tekintetében nem marad el az ESX mögött. A táblázatban ezek alapján két sorban tüntettel fel a NIC teaminget, respektálva az ESX integrált GUI fejlesztését.

Végezetül említsük meg, hogy a virtuális hálózat területén jócskán van fejlődnivaló. Senki által sem megoldott jelenleg még az IDS/IPS eszközök futtatása virtuális környezetben, nincs port mirroring, a tűzfalak kezelése homályos és fejlődő terület. A VMware több innovatív fejlesztést is bejelentett, ezek közül kettő különösen fontos. A 4-es verziótól kezdődően lehetőségünk lesz switch gyártók valódi switch operációs rendszereit, mint beépülő modulokat a virtuális környezetbe integrálni. Vagyis a virtuális gépek közé "beépíthetünk" egy virtuális CISCO kapcsolót is – annak minden előnyével együtt. Egyelőre még nem világos, hogy ennek milyen licence-költségei lesznek, de illúzióim nincsenek. A másik jelentős változás a hálózat területén a I/O virtualizáció hardveres támogatása. Itt az Intel fejlesztései lesznek meghatározók, amelyet mind a VMware mind pedig a Hyper-V támogatni fog. Ez azonban már a jövő zenéje.

Összefoglalás: a kötelező köröket mindenki tudja. Hosting környezetben az ES rendelkezik néhány vonzó képességgel. A NIC Teaming – bár mindkét megoldás támogatja, az ESX-nél jobban integrált. Az iSCSI területén a Hyper-V-nél fejlettebb. Néhány képesség mindkét termékből hiányzik – ezeket vagy ingyenes holmikkal lehet orvosolni, vagy várni kell a hypervisor következő változataira.

No.

Tulajdonság

VMware ESX 3.5

Microsoft Hyper-V

1.

Virtuális hub

Nincs

Nincs

2.

Virtuális switch

Van

Van

3.

Virtuális switchek maximális száma

127

Korlátlan

4.

Virtuális switchek maximális port száma

1016

Korlátlan

5.

Switch portok házirend alapú szabályzása (Port grouping)

Van

Nincs

6.

Változtatható port-képesség (autonegotiate)

Van

Nincs

7.

Cisci Discovery Protocol támogatás

Van

Nincs

8.

Port biztonsági házirend

Van

Nincs

9.

Promiscous mode detektálás és tiltás

Van

Nincs

10.

MAC cím változás figyelés

Van

Nincs

11.

Hálózati forgalom szabályozás (sávszélesség szabályozás)

Van

Nincs

12.

Port tükrözés

Nincs

Nincs

13.

External hálózat (külső hálózat elérése)

Van

Van

14.

Internal hálózat (A hosttal közös hálózat)

Van

Van

15.

Private hálózat (Csak virtuális gépek közötti hálózat)

Van

Van

16.

VLAN támogatás (802.1Q)

Van

Van

17.

TCP Segmentation Offload támogatás

Van

Nincs

18.

TCP Segmentation Offload támogatás iSCSI esetén

Nincs

Van

19.

Jumbo Frames támogatás

Van

Nincs

20.

Jumbo Frames támogatás iSCSI esetén

Nincs

Van

21.

NIC Teaming

Van

Van

22.

Integrált NIC Teaming

Van

Nincs

23.

Statikus MAC cím allokáció

Van

Van

24.

Dinamikus MAC cím allokáció

Van

Van

25.

MAC cím egyediségérő gondoskodó algoritmus

Van

Van

26.

Beépített DHCP szerver

Nincs

Nincs

2 Responses to A VMware ESX 3.5 és a Hyper-V összehasonlítása – 6. kör

  1. Gábor says:

    1) "Hányzik a sávszélesség szabályozás?" – hat nem tudom, szerintem innen meg egy ‘i’ is h(i)anyzik :-) .2) Szerintem nem szabad lekicsinyleni azt a tenyt, hogy a VMware a GUI tekinteteben mindig is elen jaro volt, a VMware Workstation mar akkor jobban konfigolhatonak tunt, amikor a MS megvette a Connectix-et, es elsokent kiadta a VPC-t. Erdemes lenne egy ilyen osszehasonlitas (persze ez meroben szubjektiv…), hogy a valodi lehetosegek kozul mennyi van kivezetve a kezelofeluletre, es hany miatt kell Registry-t turkalni, cmd.exe/PS-t elovenni.3) Azert en elvalasztanam azt, hogy mi az ami beepitett, es mi az, ami nem. Ha ugy tekintjuk, valoban nincs NIC teaming support a VirtualServer-ben. 3rd party gyartok termekevel mindent meg lehet oldani, de mas az, ami be van epitve, es megint mas az, ami nincsen, es ugy kell osszetenni. Ha a HP es a Broadcom megoldasa nem egyforma (en ezt valoszinusitem), akkor vannak olyan rendszerek, ahol az egyik vagy a masik jo, es maris elkezdodik a problema, hogy mi hol jo, mi miert nincs tesztelve a masik kornyezetben – az MS azert eleg sok kornyezetben tesztel, ezt valljuk be.

  2. Tamas says:

    1. Javítottam
    2. Szerintem nem kicsinyeltem le, de jelezd, ha mégis. Azt írtam "A táblázatban ezek alapján két sorban tüntettel fel a NIC teaminget, respektálva az ESX integrált GUI fejlesztését."
    3. Ez megér egy külön bejegyzést, de majd csak a cikksorozat végén. Itt és most dióhéjban annyit, hogy ez a "csata" platformok harca. A termékek nem pusztán a levegőben lógnak, hanem egy környezetbe épülnek be. A kérdés nem úgy merül fel, hogy "a Hyper-v-vel meglehet-e oldani valamit", hanem "Hyper-V-s környezetben meg lehet-e oldani valamit". Igen, a támogatás területén neked igazad van – de erről már nem ebben a válasz megjegyzésben, hanme külön szeretnék értekezni.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: