Elérkezett végre a 2009-es év első VMworld rendezvényének napja. Hála sok mindennek van szerencsém részt venni ezen a nem mindennapi eseményen. A virtualforum blog-on próbálok meg tájékoztatást adni mindenkinek az itteni történésekről. A valóságban már tegnap kezdetét vette az előadás-folyam a Partner nappal, azonban erre nem volt idén lehetőségem betekinteni.

A nap reggel 9-kor indult a rendezvény prominens előadásával: Keynote speech. A felvezetőt Mauritzio Carli adta (head of Vmware EMEA), aki lelkesen és borzasztó olasz akcentussal tett említést a különböző vmware figurákról. A válság ellenére (vagy épp ennek köszönhetően) a Vmware enterprise vonala még nagyobb penetrációt ért el a legnagyobb cégeknél. Az érdeklődés a virtualizáció és ezen belül a VMware iránt továbbra is kiemelkedő. Ezt az is mutatja, hogy a tavalyi évhez képest 200-zal több az idei résztvevők száma VMworld konferencián.

A szót Paul Maritz vette át, aki meglehetősen enerváltan és a lelkesedés minden ismérvét mellőzve beszélt a legutóbbi VMworld-ön már bejelentett vCloud koncepcióról. Néhány meghívott vendég demonstrálta, hogy jelenleg milyen stádiumban állnak a jövőben várhatóan egyre inkább elterjedő cloud computing-ot kiszolgáló rendszerek és alkalmazások.

Mr. Maritz emellett hivatalosan is bejelentette, hogy a VI következő generációja új nevet kap: vSphere. Tehát a jövőben VI helyett a vSphere lesz a helyes terminus. Arról nem esett szó, hogy az ESX vajon marad-e ESX

A keynote-ot az SAP senior vice president-je, Wolfgang Krips zárta, aki az SAP-nál elért virtualizációs eredményekről beszélt és szintén kitért a cloud computing-ban rejlő lehetőségekre. Nem szívesen lettem volna az előadó helyében, mivel az első néhány mondat elhangzása után valóságos exodus zajlott le a teremben; a közönség nagy százaléka síkitva menekült. Az előadás valóban nem vitte a pálmát, azonban halhattunk egy igen érdekes megközelítést a vCloud kapcsán. Ismert, hogy a mai légitársaságok igen nagy százaléka nem tulajdonol egyetlen repülőgépet sem. Sőt, repülőjegyet mindenki árulhat, ehhez nem kell a garázsban tartani egy-egy Boeing-et. Ehhez hasonló hullám várható az IT-ban is. Sok új cég fog felbukkanni, amelyektől nagyon gazdaságos keretek között lesz lehetőség számítási kapacitást bérelni. Az árat természetesen befolyásolni fogja a felhasznált kapacitás, időpont és időtartam hasonlatosan a mai repjegyárakhoz, amelyek függenek a turista-első osztály besorolástól és természetesen, hogy mikor is utazunk.

A Keynote után megkezdődtek az általános előadások. A szervezők igen nagy pontosággal tudták megbecsülni, hogy melyik előadásokat lehetne a legrosszabb és legkisebb terembe tenni. Ennek köszönhetően óriási sorok voltak a legérdekesebb előadásokat tartó helyiségek előtt. Sok esetben az érdeklődőket egyszerűen elküldték mivel a teremnyitás után 5 perccel már ki kellett tenni a “Megtelt” táblát. Ennek ellenére sikerült részt vennem néhány érdekes session-ön.

TP01 – NetAPP és Vmware kooperáció

Az előadás nagy érdeklődést váltott ki és szabályosan birkózni kellett a bejutásért. Egy könnyen értékelhető ippon-nal sikerült beküzdenem magamat a terembe és elfoglalni az utolsó helyek egyikét.

Az előadás elsődlegesen a NetAPP által lehetővé tett alacsony szintű storage kezelésről tett említést. Végre sikerült megértenem, hogy mi is a vStorage koncepció . Ennek elsődleges célja, hogy a különböző storage szinten is elvégezhető funkciókat -mint file másolás, snapshot készítés, stb- ne az ESX-nek kelljen elvégeznie a saját CPU-RAM-IO felhasználásával, hanem adja át ezen utasításokat a storage-nak. Belegondolva ez fantasztikus lehetőségeket lesz képes adni minden VI admin kezébe. Ez a koncepció a NetAPP oldaláról gyakorlatilag már teljes kiszolgálást élvez – a többi storage vendor-ról nem esett szó. Egy DEMO látványosan illusztrálta, hogy mit is jelent ez.  Legtöbb esetben új VM-et egy meglévő sablonból hozunk létre, amely -valljuk be -igen sokáig is eltarthat (az ESX kényetelen minden IO-t irányítani ezzel kapcsolatban). Ezt a funkciót a vStorage API-nak átadva a storage pillanatok alatt képes az új VM-eket létrehozni. (külön érdekesség, hogy a NetAPP ezt most már nem volume klónozással oldja meg, hanem valóban egy file másolással).

Másik aspektusa a vStorage-nak a storage szintű snapshot-olás. vStorage használatával már elegendő lesz a VI Client-et használnunk, hogy LUN szintű snapshot-ot készítsünk egy-egy vmfs-ről, azaz a VI admin a legtöbb storage funkciót innen már a VIC-ből is elérheti.

Utolsó példa a storage VMotion új alapokra helyezése. Mint ismeretes a mostani sVMotion implementációt teljes egészében az ESX vezérli -VM szintű snapshot, VMFS szintű másolás és snapshot konszlidáció. Ezt a funkciót a vStorage API 100 százalékban képes átvenni, így elérhető, hogy a sVMotion sokkal-sokkal gyorsabb legyen és gyakorlatilag nincs hatással sem a VM-re, sem az ESX host-ra.

TP27 – Wyse rich desktop

Az előadás elsődleges célja volt a Wyse vékony kliens néhány egyedi tulajdonságát kiemelni. A szokásos és unalomig ismert marketing szöveg után néhány valóban érdekes tényre derült fény. A Wyse által először megvalósított multimedia átirányítás -wyse TCX -(amelyet a VMware is átvett a VIEW rendszerébe) most már képes weboldalak optimlizálására is. Azaz a különböző flash animációk (videók) is lokálisan kerülnek renderelésre és nem az RDP-n keresztül jutnak el a felhasználóig. A View-ba épített MMR jelenleg csak videólejátszást tud átírányítani, a weboldalak esetén ez sajnos nem elegendő. Érdekes volt az összehasonlítás a sima RPD-t és MMR-t használó VM-ek között. Kiderült, hogy egy sima RDP-ben lejátszott videó igencsak képes lefogni az adott VM teljesítményét. Egy átlagos szerver esetében 15-20 videót lejátszó VM gyakorlatilag a vasat is lefektette. A Wyse TCX használata mellett gyakorlatilag nem jelentkezett kilengés sem CPU sem NIC IO tekintetében, ebből is látszódik ennek a funkciónak az előnye.

TA21 – VI Networking – New Features

Ebben a session-ben az új generációs VI-ban rejlő új hálózatkezelési megoldásokról hallhattunk (a vSphere megnevezés el sem hangzott ). Hát igen sok és érdekes dolognak nézünk elébe.

Distributed Switch

Ez a koncepció már ismert egy ideje: ahelyett, hogy a 15 üzemelő ESX host-unkon egyesével állítsuk be a hálózati paramétereket a Distributed Switch környezettel egyetlen helyen kell megadnunk majd ezeket a beállításokat, mindent örökölnek az ESX host-ok. Érdekes megközelítés a fizikai NIC-ek kezelése, különösen ha teaming-ről beszélünk. Szerencsére továbbra sem kell azonos fizikai hardvert használnunk, azaz nem számít hogy mondjuk  7 esx-ben intel kártya van 5-bepedign Broadcom, illetve a NIC-es száma sem limitál semmit. A Distributed Switch-ekhez virtuális adaptereket csatolunk és nem magukat a fizi
kai kártyákat. A virtuális adaptereket pedig esx-enként határozhatjuk még és ezen a szinten adjuk meg a redundanciát is. Természetesen fontos, hogy egy-egy virtuális adapter minden ESX-en létezzen…

Runtime State follow

Hasznos, új funkció lesz, hogy VMotion után a VM-et követik majd a hálózati vswitch szintű beállítások (security policy, traffic shaping, stb), valamint a VM a hálózattal kapcsolatos teljesítmény számlálóit is viszi magával (jelenleg vmotion után nullázódnak ezek az értékek és a vmotion előtti állapot elveszik).

Inbound Traffic Shaping

Jól tudjuk, hogy pillanatnyilag a VM-ek hálózati felhasználása csak a VM-et elhagyó forgalom tekintetében szabályozható. Jó hír, hogy az új megoldás már a bejövő forgalmat is képes lesz szabályozni (bár ez felvet néhány kérdést, amire nem kaptunk választ pl., hogy történik-e vmilyen cache-elése a bejövő csomagoknak, vagy egy adott buffer betelítődése után a csomagokat egyszerüen drop-olja a vmkernel?) Mindenesetre jól jöhet ez a funkció a renitens torrent-ezők ellen

Private VLANs

Az egyik legérdekesebb újdonság a privát VLAN-ok bevezetése. Nagyon röviden ezzel a megoldással elérhető, hogy a VM-ek közötti forgalmat ne csak VLAN-ok létrehozásával kontrollálhassuk, amely valljuk be nem teljesen triviális, különösen, hogy fizikai switch oldalról is bele kell nyúlni a rendszerbe. A private VLAN-okkal kizárólag ESX kell beállításokat megtenni. A VM forgalmakat szeparálni tudjuk és mindezt úgy, hogy akár a teljes infrastruktúrán átivelő közös ip subnet-et használunk! Alapvetően 3 állapotba lehet billenteni a gépeket:

-Promiscous – ezen VM-ek minden más VM-mel beszélhetnek- ideálisan ez a gateway

-Isolated – az ebben a sávban lévő VM-ek csak a gateway-jel beszélhetnek, egymással nem

-Public -az itt lévő VM-ek a gateway mellett egymással is kommunikálhatnak

PCI Passtrhu

Abszolút technikai áttörés! Mindenki ismeri az RDM koncpeciót, ahol a storage-on létrehozott LUN-okat nyers formában adhajtuk ki a VM-eknek, azaz a diszk-et nem virtualizáljuk el. Nos ez a koncepció az alapja a PCI Passtrhu-nak is, csak éppen nem nyers diszkekről beszélünk, hanem az ESX-ben lévő NIC és HBA kártyákról! Bár első ránézésre ez visszalépésnek tűnik a virtualizáció kapcsán, azonban ez végre teret nyithat olyan jelenleg megvalósíthatatlan céloknak, mint például storage rendszerek natív kezelése VM szintén, vagy éppen VCB-t használva VM-ként is tudunk majd SAN-os mentést készíteni. Sajnos elkerülhetetlen hátulutője ennek a funkciónak, hogy a PCI Passtrhu-t használó VM-eket nem lehet majd VMotion-nel költöztetni.

New VM hardver

-10 NIC/SCSI vezérlő VM-enként (jelenleg 4 a maximális szám)

-hot add/remove NIC