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

Hosszú ideje nem jelentkeztem már ezzel az összehasonlító cikkel,  de a hol-itt-piros-hol-ott-piros táblázat jól mutatja, hogy a két megoldás sok tekintetben eltér egymástól, ezért nem kevés irodalmazás és konzultáció előzte meg a megírását. Végül minden összeállt, és ez a minden nem is kevés. Igaz, akik várják a bejegyzést, azok ezt nem fogják bánni. A téma felosztható néhány további alfejezetre:

  1. A virtuális lemezek típusai és a velük végzett műveletek (undo, snapshot)
  2. A támogatott tároló rendszerek típusai és az azokon létrejövő hozzáférés-típusok
  3. Redundáns tároló-elérés
  4. A közvetlen hozzáférés témaköre.
  5. Egyebek (fájlrendszerek, LUN-okkal kapcsolatos tulajdonságok, indítás stb.)

Az egyes témafejezeteket nem jelöltem meg a táblázatban, de egy-egy üres sorral elválasztottam őket a jobb olvashatóság kedvéért. És akkor most a részletek.

A virtuális lemezekkel való zsonglőrködés mindkét rendszernél hasonló. Itt is, ott is vannak dinamikus lemezek, fix lemezek és pillanatfelvételek. Sebesség szempontjából is azonos a két cég javaslata: leggyorsabb mindig a közvetlen hozzáférés, de ezt az üzemmódot inkább csak speciális célokra, mint általános használatra ajánlják. Alig valamivel marad el a fix lemezek sebessége, a legjobb gyakorlat ilyenekkel dolgozni. Ezt követi (sebesség szempontjából) a dinamikusan növekvő lemez, ESX-nél ezt "Thin virtual disk"-nek nevezik. Végül a leglassabb a differenciális lemez, de ahogy elnéztem, ilyen ESX esetén nincs is. (Ha mégis tévedtem, javítsatok ki, és küldjétek el a linket, ahol utána olvashatok a témának.) A differenciális lemezek éles környezetben kevésbé használatosak, inkább teszteknél és bemutatóknál hasznosak: van egy csak olvasható alaplemez, többnyire sysprepelve, amelyre újabb és újabb virtuális gépeket definiálhatunk úgy, hogy mindegyik gép egy különbség lemezre dolgozik.
Itt említsük meg, hogy a virtuális gépekben dolgozó virtuális SCSI adapterek közül csak az ESX-beli képes shared-scsi üzemmódra, vagyis csak ez képes parallel-SCSI fürtök létrehozására. Ez azért fontos, mert így iSCSI target nélkül, pusztán virtuális merevlemezekkel létrehozhatunk Microsoft fürtöket. Igaz, csak két tagból állót és csak Windows Server 2003-ig bezárólag, de akkor is. A Hyper-V integrált komponensben megbúvó SCSI adapter ilyen képességgel nem felvértezett, ezért virtuális gépekből fürtöt (ún. guest clustering) csak iSCSI technológiával lehet létrehozni.

ESX-disksA támogatott interfészek a két rendszernél szintén hasonlóak, de a gyökerekből eredően itt is vannak különbségek.

Az ESX a helyi lemezek közül nem kezeli az IDE/ATA típusúakat. SAS/SATA lemez-tömböket ugyan kezel, de csak akkor, ha azok nincsenek megosztva.  Adatközpontba szánt szoftverről lévén szó ez nem tragédia, de pl. távoli telephelyeknél "olcsósított" hardvernél gondot jelenthet. Sőt, én megosztott SAS tömböket gond nélkül el tudok képzelni még egy bank adatközpontjában is – legfeljebb nem a legfontosabb funkció szalad rajta.

A másik látható történelmi előzmény az NFS. Lévén az ESX-nek Unix/Linux gyökerei vannak, jó barátságban van az ebből a világból származó szabványokkal. Az NFS egy fájl-megosztási technológia, a Windows világ SMB/CIFS techológiájával vethető össze. Szinte várható is, hogy  Hyper-V meg ez utóbbit támogatja, és lám, az alábbi ábra szépen mutatja: lehet fájlmegosztásra VHD-t rakni. Célszerű persze az SMB2 használata – tehát Windows Server 2008 alkalmazása.

Ami számomra meglepő volt a téma kapcsán, hogy a NAS eszközök száma az ESX-nél. Nem tudom, mi az oka annak, hogy egyáltalán van valamilyen korlát a számukra vonatkozóan. Nem mintha a 32 NAS eszköz olyan nagyon komolyan vehető határ, inkább a jelzés, hogy létezik ilyen korlát.

Hyper-V disks

Szintén meglepetéssel tapasztaltam, hogy a redundancia vonatkozásában tároló rendszereknél az ESX történet nem fényes. Van persze többszörös útvonal, és hiba esetén az egyik HBA munkáját gond nélkül átveszi a másik, tehát a kötelező kör, vagyis a hibatűrés letudva. A terhelés-elosztás támogatása viszont gyengére sikeredett. Ezek szerint az ESX 3.5U2 csak "experimental", vagyis próba jelleggel támogatja a "round robin"-t, a legegyszerűbb terhelés-elosztási technológiát.

A Hyper-V a témában csillog: a round robint az útvonalak részhalmazára is támogatja, de tud például  olyat, hogy egy adott IO kérést arra az útra irányítson, amelyben a legkisebb a várakozása sor. Az már csak hab a tortán, hogy az egyes storage IO utakhoz súlyokat rendelhetünk, az adaforgalom pedig ezen súlyozás arányában oszlik el. És mindezt iSCSI-re is. Három 10 Gbit/sec-es iSCSI HBA-val bődületes IO sávszélesség adódik, amit tetszőleges algoritmussal terhelhetünk egyenletesen. Ez a mutatvány nem jöhetett volna létre, ha nincs a Windows Server 2008-nak egy kiegészítő képessége (Feature), a "Multi-path IO".

Hogy a VMware maga is érzi a hiányosságot ezen a téren, azt a legjobban a "ESX Server 3 Configuration Guide" 140-ik oldalán olvasható mondatok támasztják alá: "In addition, with the software‐initiated iSCSI, you can use NIC teaming, so that
multipathing is performed through the networking layer in the VMkernel
". És teljesen igazuk van: iSCSI esetén az ESX-be épített NIC teaming nagyon jó szolgálatot tesz, mert a hibatűrés mellett jólfejlett terhelés-eloszlással is rendelkezik. A hátulütő csak annyi, hogy a hardveres iSCSI iniciátorok – tehát a HBA szerepét ellátó kártyák száma kettőnél nem lehet több.

Miután a redundáns hozzáférést jól kiveséztük, a témában egyetlen említésre érdemes szempont maradt, és ez át is vezet minket a közvetlen hozzáférés funkcióhoz. Szemben az előző körrel, itt az ES viszi a prímet. A Hyper-V-ben az MPIO nem működik, ha egy lemezhez közvetlen hozzáférést adunk a virtuális gépek számára. Ez nem szép, mondhatjuk, de én még viszonylag megbocsáthatónak tartom. Az ajánlások szerint a pass-through lemezt csak speciális célokra érdemes használatba venni, például gyorsan "megláttathatunk"’ köteteket virtuális gépekkel. Hosszú távon viszont a fix VHD a javasolt. Ha valaki betartja ezt az ajánlást, az MPIO közvetlen lemezeknél nem fog hiányozni neki.

Csakhogy nem ez az egyetlen bibi. A közvetlen hozzáférést használó gépeknél nem lehet pillanatfelvételt sem készíteni hyper-v alatt. Ha tehát valaki abba a kategóriába tartozik, ahol tényleg elengedhetetlen a pass-through lemez, ott további ujjbaharapásokra is számítani kell. Ha nincs pillanatfelvétel, nincs konzisztens online backup lehetőség sem – és ez meg backup szoftvertől független. Lássuk be, az Microsoftnak jó oka van azt ajánlani, hogy a pass-through lemezt csak megfontoltan használjuk. Az ESX ezen a területen jobban áll: kétféle közvetlen hozzáférést támogat: az egyiket "virtual compatibility mode"-nak, a másikat "physical compatibility mode"-nak nevezik. A két üzemmód közül az első lehetővé teszi a pillanatfelvétel használatát, és ha olyan alkalmazást használunk, ahol ez a technológia éles környezetben is támogatott, akkor jól is jöhet. (Az Active Directory és az Exchange éles környezetben való támogatásának egyik feltétele például a pillanatfelvétel funkció használatának elhagyása.)
A közvetlen hozzáférés vitathatatlan bajnokának mégsem nevezném az ESX-et. Egy fontos képességet ugyanis ez a termék is nélkülöz, méghozzá a helyi lemezek közvetlen hozzáférésének biztosítását. Adatközpontban, SAN-os környezetben ilyen igény ritkán jelentkezik, távoli telephelyeknél annál gyakrabban lehetnek olyan kiszolgálók, amelyek DAS-t használnak és kell nekik a pass-through. No, ahhoz jelenleg hyper-v kell.

Maradt még néhány funkció a vegyesfelvágott témakörben. Az NPIV már egy ideje elérhető technológia, még a Virtual Server 2005 is használhatta. A lényege, hogy minden virtuális gép egyedi – virtuális – WWPN-nel rendelkezik, így egy adott LUN-hoz csak egy adott virtuális gép férhet hozzá. A VMFS beköszöntével elérkezett a fürtözött file-rendszerek kora, de azzal, hogy sok virtuális gép lemezét egyetlen LUN-ra raktuk, szépen fel is rúgtuk a SAN felügyelet legjobb gyakorlatát. Az meg különösen csúnya, hogy a direkt hozzáférésű lemezeket a host HBA érheti el – a többi virtuális gép nincs kizárva az zónából. No, ezen segít az NPIV. Nüansznyi dolognak tűnik, de talán a SAN rendszergazdák értékelik, hogy a Hyper-V a Host-nak kiadott LUN-okra is tudja az NPIV-t, miközben az ESX a VMFS-re nem.

Apropó VMFS. Jelentős különbség a két gyártó megoldása között, hogy a virtuális lemezek tárolására szolgáló ESX-féle VMFS fájlrendszer egy "fürtözhető" fáljrendszer. Ez azt jelenti, hogy egyszerre egynél több (maximum 32) kiszolgáló férhet hozzá ugyanahhoz a kötethez, az elosztott fáj-zárolási mechanizmus pedig biztosítja, hogy a kötet integritása és konzisztenciája ne sérüljön. Ez a technológia azért fontos, mert alapja a Vmotion-nek, a DRS-nek, amitől olyan szép az élet a virtualizációs környezetben.
A VMFS-sel szemben ott az NTFS. A jelenlegi verziója nem fürtözött (ezért van olyan tétel a táblázatban, ami Hyper-V esetén nem értelmezhető), ugyanakkor már rég nem küzd olyan 2 TB-os korlátokkal, mint a VMFS amúgy immáron harmadik verziója.
A táblázat végét mazsolázva még egy fontos tulajdonság: mindkét termék képes SAN-ról indulni. Ha valaki ragaszkodna a blade szervereire hypervisort rakni, no neki ez kötelező igénye lesz.

Összegzés:

    • A Hyper-V által támogatott storage hardver konfigurációk típus szélesebb, mint az ESX-é.
    • Shared SCSI alapú cluster-in-a-box konfigurációt csak ESX-szel lehet további beruházás nélkül megvalósítani
    • A Windows Server 2008 MPIO komponense messze lekörözi az ESX HBA terhelés-elosztását
    • A Hyper-V-nek van csiszolnivalója a közvetlen hozzáférés témakörén
    • A VMFS ugyan fürtözött fájl-rendszer, ennek ellenére még a Windows 2000-beli NTFS méret-maximumait sem éri el
No. Tulajdonság VMware ESX 3.5 Microsoft Hyper-V
1. Dinamikusan növekvő virtuális merevlemez Igen (1) Igen
2. Állandó méretű virtuális merevlemez Igen Igen
3. Differenciális virtuális merevlemez Nem (2) Igen
4. ‘Undo’ képesség Igen Igen
5. Pillanatfelvétel (Snapshot) Igen Igen
6. Virtuális gép SCSI adapter shared SCSI üzemmódban Igen Nem
       
7. DAS támogatás (IDE/ATA) (virtuális lemezek tárolására) Nem Igen
8. DAS támogatás (SCSI) Igen Igen
9. DAS támogatás (pass-through) Nem Igen
10. SATA/SAS tömbök támogatása Igen Igen
11. SATA/SAS megosztott tömbök támogatása Nem (3) Igen
12. Fibre Channel támogatás Igen Igen
13. Hardveres iSCSI támogatás Igen Igen
14. Hardveres iSCSI Initiator maximális száma 2 Korlátlan
15. Szoftveres iSCSI támogatás Igen Igen
16. NAS támogatás Igen Igen
17. NAS over NFS Igen Nem
18. NAS over SMB/CIFS Nem Igen
19. NAS eszközök maximális száma 32 Korlátlan
       
20. Redundáns tároló elérés (MPIO) Igen Igen (lásd 28.sor!)
21. Redundáns tároló-elérés terhelés-elosztással Nem (4) Igen
22. Redundáns tároló-elérés MRU (most recently used) algoritmussal Igen Igen
23. Redundáns tároló-elérés PP (Preferred path) algoritmussal Nem Igen
24. Redundáns tároló-elérés Round-Robin with subset of path algoritmussal Nem Igen
25. Redundáns tároló-elérés "Dinamic least queue depth" algoritmussal Nem Igen
26. Redundáns tároló-elérés súlyozott útvonal algoritmussal Nem Igen
       
27. Közvetlen LUN hozzáférés Igen Igen
28. Közvetlen LUN hozzáférés redundáns storage eléréssel Igen Nem
29. Közvetlen hozzáférésű lemezek pillanatfelvétele Igen Nem
30. Közvetlen hozzáférésű lemezekkel fizikai-virtuális cluster Igen Nem
31. Közvetlen hozzáférésű lemezekkel virtuális-virtuális cluster létrehozása Igen Nem
32. Közvetlen SCSI eszköz elérése (pl. SCSI tape library) Nem Nem
       
33. N-Port ID virtualizáció (NPIV) Igen Igen
34. N-Port ID Virtualizáció nem csak közvetlen hozzáféréshez Nem Igen
35. Fürtözött file-rendszer Igen Nem
36. Metaadat frissítés SCSI-2 N.A
37. Fürtözött file-rendszerhez hozzáférő node-ok maximális mérete 32 N.A.
38. Fürtözött file-rendszerek összefűzése 32 0
39. File méret maximum 2 TB 256 TB
40. LUN-ok maximális száma 256 Korlátlan
41. LUN méret maximum (5) 2 TB 256 TB
42. Kötetméret 64 TB 256 TB
43. Hypervisor indítása SAN-ról Igen Igen

(1) – Thin vmdk
(2) – Nem találtam ilyet
(3) – Forrás: Storage / SAN Compatibility Guide For ESX Server 3.0.x – 2008. november 6.
(4) – Round robin expirimental load balance van.
(5) – Ezt a képességet egyszer már szerepeltettem, itt csupán a téma miatt tettem be újra.

További olvasmányok:
Best Practices Guide on deploying VMware ESX Server 3.5 using Emulex Virtual HBA Technology
Best Practices: SAN Deployment on Microsoft Windows Server 2008 Hyper-V using Emulex Technology
Multipath I/O Overview
Failover Clustering in the Windows Server 2008 Technical Library

Előzmények:

A VmWare ESX 3.5 és a Microsoft Hyper-V összehasonlítása – bevezetés
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 1. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 2. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 3. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 4. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 5. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 6. kör

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: