Virtualizáció vállalati környezetben - Miért jó?

Linux-haladó

Sok helyen látom, hogy nagyvállalati környezetben migrálnak rengeteg fizikai vasat virtuális gépre. Arra lennék kíváncsi, hogy milyen előnyökkel jár az (nekem, mint alkalmazás üzemeltetőnek - valamint az infrastruktúra üzemeltetőnek), ha az alkalmazásaimat kiszolgáló szerverek virtuálisak?

Érdemes-e nagy erőforrású alkalmazásokat is így használni?
Valós alternatíva-e desktop környezeteket is a "szerverszobába költöztetni", azaz azokat is virtualizálni, és vékonykliensről, vagy egyéb módon használni?

  • 4361 megtekintés

( golgota | 2008. 07. 01., k – 13:23 )

Hát mondjuk DHCP,DNS, kisforgalmú mail servereket és hasonlókat célszerű virtuális gépre költöztetni.
Előnyök között említeném a snapshot-okat (persze célszerű jól archiválni őket), a virtuális gépek könnyű költöztetését, stb, stb.
Hátránya, ha monjuk egy ilyen szerver bedöglik fizikailag, akkor az azon levő szervizek halottak.
Persze mennyi időbe telik a snapshotokat ráhúzni egy másikra...

Nekünk vannak clustereink virtuális gépeken külön vasakon apache, tomcat és egyébb nyalánkságok, amiket fent is említettem.

( gorgo75 v | 2008. 07. 01., k – 13:28 )

mi rengeteget migrálunk (régi szervereket új 8 magos vas alá).
a virtuális gépeid innentől kezdve bármilyen vason futtathatók.
célszerű valamilyen HA megoldást használni, ha ez nincs akkor külső storage. Ha nem kell nagy sebesség akkor iscsi megoldással. Ha gyors kell akkor üvegen vagy scsi madzagon

így ha meghal a szervergép pillanatok alatt átteheted egy másikra.
persze ha azt is lehet, hogy van 2 egyforma szervered és a hdd teszed át.
Lehetőleg komoly vasakon érdemes futtatni amiben minimum redundáns táp van.

( gthomas | 2008. 07. 01., k – 13:29 )

1. Desktop: nálunk Windows Server-re jelentkeznek be a fejlesztők - előnye, hogy egy környezetet, egy gépet kell csak karbantartani, frissíteni. Hátránya hogy nem lehet bármit bármikor rátelepíteni, Task Manager csak egy helyen lehet nyitva...
A spec. igények (Delphi-s fejlesztői gép, MS Visual Studio-s fejlesztői környezet - ezeket nem használjuk nap mint nap) 1-1 virtuális gépre kerültek.

2. Szerver: ha a spec. alkalmazás nagy hardverigényű, akkor biztosan gyorsabb direktben futtatni, mint virtualizálva.

Viszont a gép partícionálása (IBM terminológia, nem tudom máshol hogy hívják - a processzorok, memória, diszkek szabad ide-oda rendelése virtuális gépek között) jó dolog, és nincs a virtualizációs (lassító) réteg.

( eax | 2008. 07. 01., k – 14:18 )

"milyen előnyökkel jár az (nekem, mint alkalmazás üzemeltetőnek - valamint az infrastruktúra üzemeltetőnek), ha az alkalmazásaimat kiszolgáló szerverek virtuálisak"

- eroforrasok hatekonyabb kihasznalasa (kulonosen, ha van sok idle-zo geped, pl. dns szerver)
- kevesebb vas -> kisebb energiafogyasztas, hutesi koltsegek, es vegre lesz hely a szerverteremben :)
- snapshoting (egy kenyes muveletnel ha valami rosszul sulne el, egy mozdulattal vissza tudod allitani az eredeti allapotot)
- konnyebb teszteles (2 kattintassal letrehozhatsz egy, az eredetivel megegyezo fejleszto/teszt kornyezetet)
- live migration (virtualis gepek futas kozbeni atpakolasa masik fizikai gepre, pl. tervezett hardver-karbantartas eseten jol jon)
- DRS (a terheles automatikus elosztasa a fizikai gepek kozott)
- HA (ha kihal egy fizikai gep, a vm-ek a tobbi fizikai gepen automatikusan ujraindulnak)
- disaster recovery
- backup (a virtualis gepeket lehet futas kozben, egyben backup-olni, igy sokkal gyorsabb a helyreallitas)

"Érdemes-e nagy erőforrású alkalmazásokat is így használni?"

Altalaban igen, de persze ehhez ismerni kellene a konkretumokat.

"Valós alternatíva-e desktop környezeteket is a "szerverszobába költöztetni", azaz azokat is virtualizálni, és vékonykliensről, vagy egyéb módon használni?"

Igen, errol szol pl. a vmware vdi.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Na hát az az, amire ne használd. Meg úgy általában nagy IO-t igénylő alkalmazásokra, különösen sok random művelettel.
Amúgy az én tapasztalataim alapján kb semmire se használd a virtualizált környezetet, mert akkora hulladék, hogy katasztrófa, ha valaminek baja van, lassú, egyik napról a másikra esik tizedére a teljesítmény, mindenki csak áll bambán, és passzolnak, mitől van. Szóval felejtős az egész.

BTW, oracle állásfoglalása a virtualizált környezetek támogatásával kapcsolatban annyi, hogy ha bajod van bármivel ilyen környezetben, elsőként bizonyítsd, hogy a probléma fennáll virtualizáció nélkül is. Ha sikerül reprodukálnod, akkor elkezdenek foglalkozni az üggyel. Ha nem, magadra maradtál.
És hallottam más gyártókról, hogy hasonlóan állnak a kérdéshez.

Hja, végülis mi is nagy ügyfél vagyunk, ha úgy vesszük... Már persze magyar viszonylatban. Ellenben nekünk van tapasztalatunk a témával, és sajnos a tapasztalatunk keserű. Nem állítom, hogy az egész úgy vacak, ahogy van, elképzelhető, hogy az egyes magyar beszállítók nem elég felkészültek, nem tudom.
De mivel magyar ember kérdezett magyar oldalon, gondolom itteni megoldásban gondolkozik, ergo ugyanezekre a tapasztalatokra számíthat.

Amúgy tökre kösz hogy beleszólsz, általad belülről nem ismert példát felhozva, ez tényleg biztos sokkal-sokkal többet ér, mint a saját tapasztalat... :)

Amúgy az én tapasztalataim alapján kb semmire se használd a virtualizált környezetet, mert akkora hulladék,

erre reagaltam.

ezen nincs mit belulrol ismerni, sokan megelegedessel hasznaljak. az hogy ti szoptok vele, az vagy titeket vagy a szar beszallitot (vagy mindkettot) minositi.

Próbálj meg meghajtani guest-ből egy tape libraryt. Közvetlen elérni SAN vagy SCSI eszközt.
Integrity VM alatt ez nem probléma. Mintha a Xennek se okozna ez fejtörést (de a Xenhez nem értek). Az ESX erre alkalmatlan. Cserébe van vmotion, ami meg az IVM-ből hiányzik. Semmi se tökéletes.

Ave, Saabi.

"Amúgy az én tapasztalataim alapján kb semmire se használd a virtualizált környezetet, mert akkora hulladék, hogy katasztrófa, ha valaminek baja van, lassú, egyik napról a másikra esik tizedére a teljesítmény, mindenki csak áll bambán, és passzolnak, mitől van."

Hadd tippeljek: VirtualPC? :)

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

( subchee | 2008. 07. 01., k – 14:59 )

A szerverek virtuális környezetbe való migrálása elég aktuális téma most mindenhol. Épp a minap jelent meg a Microsoft Hypervisora is Win2k8 -hoz, pont azért, mert nagy lehetőséget látnak ők is a piacban. Vállalati környezetben mi a Suse Linux + VmWare alapot használjuk, ezen vannak létrehozva virtuális gépek (azok nagy része pedig Win2k3).

A migráció több okból is megérheti:

a) ha már több régi vasat amúgy is cserélni kellene, mert az élettartamuk végéhez közelednek, olcsóbban kijön egy jól megtervezett virtuális környezet összehozása egy erős vason
b) energiatakarékosság : kevesebb áramot fogyaszt egy 8 procis, procinként 2 magos szerver, mint a teljesítményben vele egyenértékű kb. 20-30 db P3 -as szerver... és kevesebbet kell egy vas hűtésére/klimatizálásra költeni, mint mondjuk 30 -éra
c) egyszerüsített adminisztráció: ha több olyan szervered van, ami alapvetően ugyanolyan/hasonló feladatot lát el, akkor egyszer kell csak jól telepítened + bekonfigurálnod, később ebből egyszerű copy -val létre tudsz hozni egy ugyanolyan új virtuális gépet (persze fizikai gépeknél is megoldható hasonló dolog, de itt egyszerűbb)
d) meghatározhatod, mennyi erőforrást kapjanak a virtuális szervereid: adott a bazi nagy vas, amin mennek a virtuális gépek... ha egyszer az egyik virtuális szerverre új alkalmazást kell telepíteni, akkor elég hozzárendelned több erőforrást (memória, tárhely) a beállítások panelen... fizikai szervert bővíteni vagy cserélni kellene
e) nem kell kölön mentési egységet beszerezni minden fizikai szerverhez, elég egy mentési egység az egész géphez... gondolj bele, 30 db szerverhez 30 stand alone vagy beépített LTO kell, ezeknek a darabonkénti ára jelenleg kb. 600.000 Ft. Ha van egy géped, amin a virtuális szervereket futtatod, akkor csak pl. egy tape library -t kell beszerezned a mentéshez, jóval alacsonyabbak a fajlagos költségek (nem beszélve arról, hogy nem kell cserélgetni kézzel a kazikat naponta a 30 szerverben)
f) kevesebb helyet foglal el, mint sok régi bazinagy szerver külön-külön
g) több telephely adminisztrációs feladatát egy helyre lehet centralizálni (pl. fizikailag Miskolcon lévő szervereket ugyanazon cég bp -i telephelyén lévő virtuális gépre migrálva Miskolcon nem lesz szükség helyi szerveres rendszergazdára)

Hátrányok:

a) ahogy már írták, ha lehal a vas, lehal minden virtuális szerver is... de ahogy írták, van rá több megoldás is
b) egyes SW gyártók nem támogatják a termékeik virtuális környezetben való használatát (pl. Autocad Licence Server tud futni ilyen környezetben, de onnantól kezdve nincs hivatalos support a termékre)
c) magas biztonsági szintet igényelő rendszereknél nem biztos, hogy jó ötlet a virtulizáció
d) nagy hálózati forgalmat bonyolító, sok kapcsolódást igénylő alkalmazásoknál megfontolandó (pl. nagy forgalmú webszerverek), hogy minden egyes virtuális szerverhez külön hálókártyát kell beépíteni a gépbe, mert 1 db nem biztos, hogy bírja az ilyesmit kezelni

( deejayy | 2008. 07. 03., cs – 10:39 )

Akkor még a következő kérdések merültek fel bennem:

- Milyen virtualizációs megoldást válasszak, ha egy viszonylag kis költségvetésű cégnél kell ilyet bevezetni? (úgy értem, a fent felsoroltak bizony elég impresszív feature-ök, de a legalapabb VM technológiával is használhatók? Ezek supportálják a support-nélküli linuxokat (tehát nem RHEL, SLES)?)

- Vegyek komplett szervereket gyártóktól (HP, IBM, etc), vagy induljak el egy gyengébb géppel, akár PC-vel? (egyáltalán hol lehet ilyen szerverek között mazsolázni, ahol forintot is írnak a katalógusba?)

--
deejayy DOT hu

1, ha nincs penz, es raersz faragni xen. ha kell valami komolyabb, akkor vmware, de ez eleg huzos. raadasul ha tobb geped lesz, nemis tud annyit, mint a vmware.

2, en szeretem a komplett szervereket. :) de ha nincs penz, akkor valami _jol_ osszerakott gep is jo lehet a feladatra. sajnos olyan oldalt nem tudok, ahol lehetne bongeszgetni kulonbozo gyartok gepei kozott, arakkal egyutt..

*Nagyon* érdekelne, hogy mitől "húzós" a VMware (feltételezem, hogyaz "ESX"-re gondolsz)?

Több kiadása is van, ahol kisebb a költségvetés, lehet olcsóbbat is venni (nyilván kevesebb funkcionalitással), de ugyanúgy király, bővítési lehetőség adott ezt követően is.

igen, esxre gondoltam, illetve az egesz VIre.

nezzuk csak, mennyibe kerul: 995$ a foundation, de ez kb annyit tud, mind egy xen: nincs se HA, se VMotion, se DRS. szoval nem eri meg.

amiben van HA, az 2995$, ha DRS is kell, az mar 5750$.

ja, es ez support nelkul.

legalapabb supportos: VMware VirtualCenter Foundation (Up to 3 Nodes) + Gold (12x5) 1 Year Support $2,040.00

ez egy KKV -nak huzos kiadas, raadasul ez meg az a szint, amit a Xennel is meg tud csinalni.

Tudom jól az árakat, és ez miért sok? Mennyibe is kerül egy vas? (ha több kiszolgáló merül fel, akkor feltehetően nem 100e forintos alapkiszerelésekben gondolkodunk)

Ha valakinek több kiszolgálóra van szüksége, még mindig sokkal olcsóbb egy Foundationt megvenni (ESXi-ről ne is beszéljünk), mint több vasat. (+ áram fogyasztás, ups, ...)
Persze lehet azt mondani, hogy vannak ingyenes alternatívák, de itt jön az, hogy el kell dönteni: ki fogja azt támogatni, hogy fogod fejleszteni (mert például a céggel együtt az igények is nőnek). VI3 esetén ilyennel nem igazán van problémád.

Szerintem a KKV alatt nem ugyanazt a kategóriát értjük (tudom, hogy vannak cégek, akik $400-ért sem vennék meg, de közel sem kizárólag ilyen KKV-k vannak, mely kategóriába azért komolyabb cégek is beletartoznak, lásd főleg 2. K kategóriát).

Egyébként nem eladni akarom Neked: általában szeretik úgy emlegetni a VMware-t, mint valami csillagászati árú terméket (Te is többek között), holott erről azért szó sincs. (van, akinek minden drága, ami pénzbe kerül első körben)

Mondom, hogy nem vagy tisztában az árakkal :-) Ez a $8k-s aprópénz dobálózás kb olyan, mintha valakinek azt mondanád, hogy csak 15 misiért tud autót venni. (mellesleg a $8k nem stimmel)

Senki nem állította, hogy a VMware aprópénzbe kerül, de az sem igaz, hogy "húzós" lenne az ára.

Hogy néhány dolgot tisztába tegyünk: a VMware Foundationnel (vagy még olcsóbban: ESXi - ez pl. Dellnél ***$99***-ért vehető a vas mellé - ez már közelíti az aprópénz kategóriát egy normálisabb szerver árához képest mindenképpen) nem csak az a virtualizációs motort veszed meg (ami ráadásul a legmegbízhatóbb a piacon), hanem bebiztosítod a virtuális gépeid jövőjét (és jelenét...).
Miért is? Mert ha elkezdesz nőni (értsd: sok virtuális géped van), könnyen oda kerülhetsz, hogy valami normális HA megoldás kell.
Ha nem VMware-rel indítottál, könnyen ott lyukadhatsz ki, hogy mégis VMware kellene. És akkor bejön a nagy mutatvány: a sok tucat VM-et át kellene tenni VI3-ra. Szerintem ez nem egy hétvégés feladat...
Ellenben ha VMware-rel indítottál, gyakorlatilag csak egy licensz fájlt kell kicserélned. Ez megér $99 dollárt?

De térjünk vissza a $8k-ra, ami valójában $6958, listaáron (ha annyira úgy gondolod, hogy el akarok Neked adni, legyen: kérjél tőlem ajánlatot, ennél jobbat fogsz kapni).

Ha kiszámolod, hogy HA igényű környezetbe mennyit költesz vasakra (kiszolgálók, tárolórendszerek, hálózat, ...), akkor az a $6958 sem feltétlenül sok 2 CPU-nként, ráadásul most már néhány 1 CPU-s vas is támogatott (ami bizonyos szempontból felezi az árat, azaz $3479 vasanként).

És akkor még nem is jöttek szóba olyan fícsőrök, amiket mások még nem is emlegetnek (értsd: örülnek, ha összehozzák végre a hipervizort és valami menedzsmentet is fel tudnak mutatni mellé): most jelent meg például a Site Recovery Manager (na ez tényleg nem tákolt PC-s szerver kategória, de van), Stage Manager, és még jön néhány finomság a nem túl távoli jövőben.

(bocs, utólagos szerkesztés): ESXi vagy Foundation esetén nyilván nem csak a "jövőt" vásárolod meg, hanem kapsz egy megbízható, kipróbált+bevált rendszert, gazdag funkcionalitással, központi kezelőfelülettel.
Sok VM esetén gondolom akad itt-ott 1-1 Win2k is. Mennyi is a licensz díja egy Standardnak...? Ugye máris összemérhetők a költségek.

Már megbocsáss, de nem én hoztam elő a "$8k aprópénz" vonalat. Igenis értem, hogy nem mindenki hajlandó Foundationt venni, de a KKV kategóriába azért a középvállalatok is beletartoznak, ahol a Foundation akár kevés is...

Azt pedig nem írtad meg, hogy a $99-et miért találod húzósnak: ha valakinek ennyit nem ér meg, hogy normális, kiforrott, támogatott, könnyen fejleszthető rendszeren legyen, ott valószínűleg más probléma is van...

(lehet, hogy tudod a termékek licensz díját - kiindulásnak nem rossz -, de ugye mindketten tudjuk, hogy egy termék ára nem fullad ki a licensz költségekben)

Mi combos vasra CentOS 5.x-et teszünk, és a feladat függvényében Xen vagy VMware Server megy rá.
VMware Server lassabb, de könnyebb a vasak között költöztetni a (föleg a Win-es) guest-eket.

De csak kis költségvetésü céghez!!

PS: ezzel egyszer volt csak gondunk az utóbbi +2 évben. RAM hiba miatt korruptálódott néhágy guest :(
Viszont volt guest mentésünk (is). Minden hónapról :))

Vas oldalon én a Dell-t is megnézném, ráadásul a vmware sem idegen tőlük, hogy finoman fogalmazzak :-)) Szervernek, pláne több szervernek a fizikai alapját mindenképp masszívra kell tervezni/méretezni, átlagos pécével én nem kísérteném a szerencsémet, minimumnak a dupla táp, hardveres raid (olcsó a diszk, úgyhogy tükrözés+hot spare), hot swap diszkek, mindezt egy masszív ups-ről járatva. Nem szabad ugyanis elfelejteni, hogy a virtualizációs környezet döglése esetén a teljes infrastruktúra döglik, ami sokkalta kevésbé tolerálható általában, mint egy-egy szolgáltatás kiesése.

Amiért még jó a virtuális szerverek használata az a virtuális hálózati eszközök (vmware-es terminológia szerint vmnet) használatának a lehetősége, ez is költségcsökkentő tényező lehet.

( seferbt v | 2008. 07. 03., cs – 10:44 )

Valós alternatíva-e desktop környezeteket is a "szerverszobába költöztetni", azaz azokat is virtualizálni, és vékonykliensről, vagy egyéb módon használni?

Erre a HP-nak van egy hardveres megoldása, úgy hívják, hogy Blade PC, állítólag hűdejó és lehet vele a TCO-t faragni.

A blade technológia hol virtuális? Nagyon is valós, főleg ha egy c7000-es chassis ráesik a lábadra.
Az más kérdés, hogy 4+ blade server már egész jó is virtuális környezethez jelenthet alapot. De önmagában még távolról sem virtuális.

Ave, Saabi.

( foci v | 2008. 07. 03., cs – 11:31 )

egy néhány érdekes kérdés/felvetés:

- Ahogyan hallottam nem igazán tudnak 1000 Mbps kártyát virtualizálni magyarán nagy IO esetén kilőve.
- gondolom a diszk alrendszer sem egy leány álom NFS/storage/SAN esetében.
- Windows/Linux vegyes környezetben mit érdemes és mit nem virtualizálni elsősorban szolgáltatásokként jó lenne tudni.
Néhány példa:
Egy nagy multi engedi a virtualizációt, de pl. a DC ket nem engedi ilyenen futtatni.
Ők VMWare-t használnak.

Ja melyik a sok lehetőség közül?
XEN/VMWare/VirtualBox/VZ

Közigazgatásban dolgozom és mi is nagyon gondolkodunk rajta, költséghatékonyság miatt, de szeretnénk elkerülni a kísérleti nyúl szerepét.

+1, Gbic-et lehet vmware-es guestbe rakni. Diszket tervezni kell ilyen terhelés alá: az NFS tényleg felejtős f...talicska, az iSCSI lehet gyors (gyors storage, jól tervezett terhelés (swap lokális diszkeken)), de inkább költséghatékonynak mondanám, az FC-s storage meg drága, ellenben buznyák gyors is lehet. (És hogy kavarjuk a féceszt, idén várható az FC over IP...).

A DC-t nem engedik virt. környezetben futtatni... Talán mert a virtualizált környezetre nem tud az üzemeltető olyan rendelkezésre állást vállani, ami a DC-hez elengedhetetlen?

xennel simán megy a gigabit, viszont HVM rétege nem igazán jó mivel nincsen hozzá driver.Linux hoston windows guest nél valami förtelmes hálózati teljesítmény volt valami 10mbit, vmware is jó, főleg ha linux hoston kell windows :>
openvz, meg oprendszer alapú és érdemes meglesni a linux vservert :> szal van miből válogatni :D
most nézegetem használom a KVM-et ami nem tűnik rossznak.

Másik kérdés a mangement eszközök megléte, mert míg én pl minden megcsinálok parancssorból, valaki jobb szeret kattingatni :>

Core2Duo T7100, 2.5G, Ubuntu 8.04, 2.6.24

Ez nem feltétlen igaz, hogy Linux host + Windows guest = lassú hálózati kapcsolat.

Itt épp van egy érdekes példa pro és kontra egyszerre!

Adott egy Suse 10 alapú host ("host_1") + vmware, ezen van 2 db Win2k3 guest ("guest_1" és "guest_2"). "guest_1" -re/ről innen lentről az irodámból tudom másolgatni a szükséges adatokat 100 mbit/sec kapcsolatnak megfelelő sávszéllel, nem szakadozik, gyönyörűen megy. Viszont "guest_2" hálózati kapcsolata ugyanarról az irodai gépről tényleg förtelmes, kb. 1-100 kbyte/sec között ingadozik a sebesség és random időnként megszakad a kapcsolat. Gondolom rosszult konfigurálták "guest_2" -őt a vmware -ben, viszont nekem nincs jogosultságom a "host_1" -re, hogy bogarásszak a konfiggal, azt a kp -i csapat intézi... nekem csak a "guest_1" és "guest_2" virtuális gépekre van admin hozzáférésem és amikor a 2 -esen kell vmit intézni, akkor csak bosszankodni tudok... :S

(az egész szerver egyébként egy madzagon lóg a hálózaton, gigabites porttal, viszont a hálózati eszközök csak a 100 mbitet teszik lehetővé... a switch -ek átlagéletkora 15 év)

Ahogyan hallottam nem igazán tudnak 1000 Mbps kártyát virtualizálni magyarán nagy IO esetén kilőve.
Ez nem igaz. VMware ESX alatt tudsz virtuális intel e1000-est adni a gépeknek, mérésnél fogadási irányban 920MBit/s (115MB/s) küldési irányban kb 650MBit/s-et (81MB/s) produkált. De ennél többet is tud, ha a vmware toolst felteszed, akkor a vmxnet interfésszel simán megy a 930Mbit/s fel és le irányban is, csak sajnos nem minden kernelhez tudod lefordítani a toolst.

gondolom a diszk alrendszer sem egy leány álom NFS/storage/SAN esetében.
Az NFS tényleg borzasztóan lassú, az iSCSI SAN viszont elég kultúrált, kb 50-60MB/s-et tud gigabites kártyákon. Tény, hogy lokális SCSI diszkkel ennél többet lehet kihozni, de sajnos elég szűk a támogatott RAID vezérlők köre ESX alatt. Xen alatt viszont tudsz használni SATA-t is.

Egy nagy multi engedi a virtualizációt, de pl. a DC ket nem engedi ilyenen futtatni.
Ez könnyen lehet, hogy azért van, mert VirtualCenterrel managelik az ESX-eket, amiket értelemszerűen nem okos dolog virtuális gépre tenni, viszont Win2003-at és Active Directory-t igényel, emiatt a DC gépekre lehet kényelmesen elhelyezni. Erről megy a userek beléptetése meg minden, tehát gáz ha lehal, mert akkor az egész infrastruktúrájukhoz nem férnek hozzá.

XEN/VMWare/VirtualBox/VZ
Én Xen Enterprise-al és VMware ESX-el találkoztam idáig. Az ESX egy baromi háklis cucc hardverre meg egyéb supporting infrastruktúrára (tehát tervezni kell a rendszert hozzá, compatibility listát kell böngészni stb.), viszont egy valag feature-je van, ami a Xen-nek nincs.

A másik dolog, hogy az ESX feature-jeinek az értelmes kihasználásához most már eléggé elengedhetetlen, hogy VirtualCenter is legyen. Viszont az tényleg tud okos dolgokat, kapsz egy monitoring megoldást, virtuális gép template kezelő és klónozó rendszert, lehet VMotion-nel migrálni a hostok között.

A Xen hardver szempontból viszonylag igénytelenebb, bár ehhez feltétel a VT utasításkészlet a processzorban, az ESX viszont elvan nélküle is, csak a 64bites guest-ekhez igényli.
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

A termékek jelenlegi állása alapján komoly munkára gyakorlatilag csak a VMware megfelelő (azonbelül is ESX-ben célszerű gondolkodni).

Hogy alkalmas-e számotokra? Ha komoly alkalmazások vannak, szerintem belefér, hogy vesztek egy vasat (ha nincs), és azon kipróbáljátok. ESX demó üzemmódban tud futni 60 napig ingyen és bérmentve. Ha ilyen tesztre nincs keret/idő, akkor annyira talán nem is fontos a dolog, illetve nem égető a probléma :-)

Általánosságban nagyon nehéz megmondani, hogy egy alkalmazás miként fog működni virtualizáltan, vannak esetek, amikor akár jobban is. Sőt: fel is lehet mérni a kiszolgálók teljesítményét és az alapján megtervezni a virtualizációt.

"nem igazán tudnak 1000 Mbps kártyát virtualizálni magyarán nagy IO esetén kilőve": ez nem világos. Az ESX 10G-t is támogat már.

storage: nyilván előfordulhatnak problémák, de így általánosságban kijelenti, hogy "nem egy leány álom" nagyon túlzás.

Egy másik multi pont a DC-ket virtualizálta (többek között).

>A termékek jelenlegi állása alapján komoly munkára gyakorlatilag >csak a VMware megfelelő (azonbelül is ESX-ben célszerű gondolkodni).

Az emlitett multi is csak ezt engedi.

>Hogy alkalmas-e számotokra? Ha komoly alkalmazások vannak, >szerintem belefér, hogy vesztek egy vasat (ha nincs), és azon >kipróbáljátok. ESX demó üzemmódban tud futni 60 napig ingyen és >bérmentve. Ha ilyen tesztre nincs keret/idő, akkor annyira talán >nem is fontos a dolog, illetve nem égető a probléma :-)

Még nem égető, de szeretnénk stratégiát kialakítani, amely megtervezésében figyelembe kell venni ezt a lehetőséget.

>Általánosságban nagyon nehéz megmondani, hogy egy alkalmazás miként >fog működni virtualizáltan, vannak esetek, amikor akár jobban is. >Sőt: fel is lehet mérni a kiszolgálók teljesítményét és az alapján >megtervezni a virtualizációt.

pl.: MSSQL 2005 lesz majd, most 1 db blade en megy SQL2000 WIN2k3 -on

>"nem igazán tudnak 1000 Mbps kártyát virtualizálni magyarán nagy IO >esetén kilőve": ez nem világos. Az ESX 10G-t is támogat már.

Sajnos sima VMWare van csak jelenleg, azon van egy pár teszt/egy monitoring renszer, sajátgépen VirtualBox és ebben ki is merült a tapasztalat.

>storage: nyilván előfordulhatnak problémák, de így általánosságban >kijelenti, hogy "nem egy leány álom" nagyon túlzás.

Sajnos külsö cég konfigolta a meglévő storageot .... meg is látszot rajta... aztán kihivtak hozzá egy szakértőt és 10x es sebesség növekedést ért el a ficko. :)

>Egy másik multi pont a DC-ket virtualizálta (többek között).
Igen elvileg ehez nem kell olyan nagy teljesítmény szerintem sem, de a pontos infrastruktúrát sajnos ott sem ismerem.

( joachim | 2008. 07. 03., cs – 19:30 )

Xen-nel oldanám meg, gentoo alatt. Nekem bevált.

( google: "virtuális szerver + vékonykliens" )

- - - - -
And the man in the rain picked up his bag of secrets, and journeyed up the mountainside, far above the clouds, and nothing was ever heard from him again...

A Vmware saját marketing anyaga szerint:

DRS: Ez azt tudja, hogy a VM-eket úgy tologatja a gépek között, hogy optimális legyen a kihasználtság. Tehát olyat nem tudsz csinálni, hogy 1 VM _egyszerre_ több gép erőforrását használja. Ez szerintem nem volt egyértelmű.

HA: Ez azt tudja, hogy ha bedöglik a szerver a VM alatt, akkor újra tudja indítani automatikusan egy másik szerveren. Nyilván csak akkor, ha a VM shared storage-en volt. Nekem ez sem volt világos a fentiekből.

Tehát olyat a Vmware sem tud, hogy kihúzod a szervert a konnektorból (mindegyikből :) ), és a rajta futó VMek leállás nélkül futnak tovább a másik gépen, hanem lesz közben egy automatikus újraindítás.

Csak már kezdtem örülni a fenti hozzászólás alapján, hogy a Vmware már előrébb tart mint a többiek...

Ugyanezeket meg lehet csinálni Xennel + szkripteléssel (persze lehet, hogy a Vmware megbízhatóbb), illetve a XenEnterprise is tudja slideware szinten (konkrétan még nem próbáltam).

Üdv,
Gergely

( subchee | 2008. 07. 04., p – 11:59 )

Mondok egy konkrét esetet.

Egy IBM xSeries 3500 -as gépet használtunk egy virtuális környezet kialakítására. 2 db 2 magos Inten Xeon procija (2,33 GHz), 8 GB RAM -ja és beépített hot swap SCSI diszkrendszere van (~280 GB kapacitás összesen). 8 db fizikai szerver (kb. P3 kategória, főleg Compaq) lecserélésére lett tervezve, ahogy már írtam, Novell Suse 10 + vmware alapokon. Mentési egységként egy IBM System Storage TS3200 -as tape library -t használunk.

Az eddig felkerült guest -ek mindegyike Win2003. Még nincs befejezve a migráció, de már vannak előnyök:

- az eddig különálló szerverekhez különálló LTO -k tartoztak, amikben naponta kézzel kellett mentési szalagot cserélgetni (LTO 2 -es drive -okról lévén szó, már amúgy is az élettartamuk végét járták, sokszor hibásan írtak a szalagokra) --> mostmár full automatizált a mentés a TS3200 -nak köszönhetően (így a visszaállítás is jóval egyszerűbb)
- a különálló szerverekhez külön UPS is tartozott (mostmár erre nincs szükség, az egész szerverszoba kapott egy bazinagy UPS -t)
- sokszor volt olyan feladat, hogy az egyik szerverről a másikra kellett adatbázisokat (2-4 GB) másolni, ez most a virtualizált környezetben sokkal gyorsabb (annó hálózaton keresztül ment és a valódi hálózat elég lassú még házon belül is... viszont a vmware virtuális hálózatkezelése a guest -ek között szuper)

Hátrányt is tapasztaltunk:

- az erőforrások kiosztása nem lett elég jól megtervezve, ezért amikor az egyik MSSQL process kiakadt az egyik hoston (több, mint 2 GB memóriát zabált önmagában, ráadásul több instance is fut egyidőben), akkor az kihatással volt a többi guest teljesítményére is

( deejayy | 2008. 07. 04., p – 14:07 )

No, nézegettem a DELL oldalát, elég kedvező feltételekkel adnak komplett szervert ($3000) virtualizációs megoldással. Van valakinek tapasztalata, érdemes lenne ebben gondolkodni?

--
deejayy DOT hu

( saabi v | 2008. 07. 09., sze – 16:04 )

Szerintem játékra jó. Teszt szervereknek meg tanulni. Végülis jobb egy virtuális gépet kicsinálni mint a cég SAP serverét.
Aztán jó lehet még arra is, ha van egy erős vasad, amire sok feladatot rábízhatsz, de nem bízol a különböző alkalmazásokban - security szempontból - akkor a virtualizáció elég megbízhatóan választja szét ezeket.

Adatbázis servert semmiképpen nem virtualizálnék. És olyat sem, ahol a sebesség elsőrendű szempont (és mégsem adatbázis).
Bár virtualizációnak tekinthetünk egy HA cluster-t is, ahol a szolgáltatás mint virtuális server jelenik meg a hálózaton.

Ave, Saabi.

( deejayy | 2008. 07. 17., cs – 13:44 )

És az alkalmazásvirtualizációval van valakinek tapasztalata? (pl. MAV, SoftGrid?)
Milyen opensource alternatívái vannak? Ki, hol és miért használta / használná?

--
deejayy DOT hu