VmWare, OpenStack és Proxmox

Közösségi kerekasztal

Sziasztok!

Szeretnék virtualizációs környezetet létrehozni a vállalatnál ahol dolgozom.
Nektek mi a tapasztalatok melyikkel érdemes foglalkozni és miért?
Álláspontom, hogy VmWare esetén könnyű a karrier építés.
OpenStack elég elterjed cloud platform, nem mellesleg ingyenes.
Proxmox pedig egy nagyon egyszerű ugyanakkor könnyen kezelhető rendszer.

  • 11282 megtekintés

( tompos v | 2013. 10. 02., sze – 09:39 )

Az openstack-kel is konnyu a karrier epites.
Egyebkent a maganvelemenyem, h mar regen rossz, ha az az elsodleges szempont, h neked mi a jo.

tompos

Ha o valaszthat miert ne azt valasztana ami neki jo/szimpatikus/stb.
Gondolom mindenki a szamara szimpatikus rendszert valasztja ha a problema megoldhato az adott rendszereken.

Akkor egy kis "ontopic".
Szerintem a proxmox jo, a vmware-ben valo fejlodes/karrier pedig attol is fugg, hogy a ceg ahol dolgozol mennyi penzt fektet bele. Mivel a proxmox ingyenes ott ez nem kerdes, a fizetos reszei sem tul dragak gondolom a vmware-el osszehasonlitva.

OFF: Tompos, szerintem, senki nem ugyanannál a cégnél akar megöregedni ahol jelenleg dolgozik. Mindenkit hajt, hogy egy kicsit jobb legyen. Ha pedig már időt és energiát fektetek bele, akkor legyen már nekem jó. A tudásom meg közvetve jó a cégnek...

ON: Proxmox-al vannak eddig tapasztalataim, nagyon jó kis rendszer csak pár funkciója egy picit gyenge. (De határozottan fejlődik!)
OpenStack ha jól tudom a VmWare competitor akar lenni a maga kis ingyenességével.
VmWare-t az új NSX szolgáltatása miatt tartom egy nagyon jó jövőképnek.

Mind a 3-nak megvannak az előnyei és hátrányai, de nem hiszem, hogy a cég most 4-5 ezer eurókat kifizetne a licenszekre.
Innentől vagy OpenStack vagy Proxmox.

> OFF: Tompos, szerintem, senki nem ugyanannál a cégnél akar megöregedni ahol jelenleg dolgozik. Mindenkit hajt, hogy egy kicsit jobb legyen. Ha pedig már időt és energiát fektetek bele, akkor legyen már nekem jó. A tudásom meg közvetve jó a cégnek...

Persze, de mi lenne, ha esetleg szakmai szempont alapjan dontenel es nem a sajat elorehaladasod lenne a fo szempont. Amiket irsz, az alapjan vilagosan ez a helyzet: legyen jo nekem es kulon orom, ha a cegnek is az.

Mindezzel egyutt nem megbantani akarlak es nem beleszolni, csak bancsa a szememet es ezert megjegyeztem.

tompos

> Ha o valaszthat miert ne azt valasztana ami neki jo/szimpatikus/stb.
> Gondolom mindenki a szamara szimpatikus rendszert valasztja ha a problema megoldhato az adott rendszereken.

Mindenkepp a szimpatikusat fogja valasztani. A lenyeg azon van, h mitol lesz szimpatikus. Elsosorban attol, h jo a cegnek, vagy attol, h jo nekem.

tompos

Ha a problema hasonloan megoldhato barmelyik rendszeren, onnantol a szimpatia es a penztarca vastagsaga dont.
A fonokot valoszinuleg nem erdekli, hogy milyen virtualizacio van ha a rendszer megbizhatoan mukodik, valoszinubb, hogy az osszegbe fog belekotni. A srac pedig nyugodtan valassza a szimpatikusat, ha meg tudja indokolni es meg tudja vele csinalni amit kell (es persze ha kifizeti a ceg az arat, szoftware, hardware, tanfolyam).

Ha 1 fos IT reszleggel mukodik a ceg akkor ingyenes verzio lesz, ha tobben vannak akkor ugyis megbeszelik es nem egy ember dontese lesz akarmit is szeretne :)

> A srac pedig nyugodtan valassza a szimpatikusat, ha meg tudja indokolni es meg tudja vele csinalni amit kell

Igy van.
Az indokok pedig azok valtak, h jot tesz a CV-mnek. Erre horkantam fel..

Egy szo nincs a thread-ben arrol, hogy milyen kornyezetrol van szo, mit akar virtualizalni, mik a celok, mekkora a rendszer. Az elso helyen az o CV-je szerepel. Csokolom.

tompos

A jelenlegi salgópolcon tárolt PC alapú gépek kiváltása (tűzfal, DHCP, LDAP, levelező, monitorozó, naplózó, intraweb, RDP server stb.) mindemellett a lehető legmagasabb rendelkezésreállás és biztonság.
A későbbi cél pedig, hogy a vágók a videókat már RDP kapcsolattal ebben a környezetben tudják feldolgozni.

A salgo polc lenyegtelen info, viszont az OS, esetleg OS verziok nagyon is azok.

Ezen kivul lenyeges meg vmilyen rendelkezesre allasra vonatkozo informacio (ahogy masik irtak: shared storage v. nem).
Vmint pl. van egy iscsi vagy mas block storage-od, sokminden jatekban marad, de ha magad akarod osszerakni, akkor jo esellyel az esx kiesik.

Meg kell nezni, hogy mennyi eroforrasod van, mennyit kell kihozni belole, mennyibe kerul kompletten (nem egy evre, hanem 5, vagy egy jol meghatarozott idoszakra) majd utana donteni.

Szemelyes velemenyem, hogy ha egy egyszemelyes (az IT reszleg) cegrol van szo, akkor kizart, hogy akkora legyen a merete, hogy erdemes legyen openstack-et osszerakni _es_ uzemeltetni (igen, azt is kell, kulonosen, hogy egy gyorsan fejlodo rendszerrol van szo).

tompos

Most akkor "vas" vagy "node"?

Én értelmezésem szerint a "node" olyan csomópont, ami valamilyen szemszögből azonos. L3 hálózati architektúra szempontjából lehet azonos egy szerver (amin pl ESXi fut) és egy tároló, de infrastruktúra architekturális szempontból bőven van akkora különbség közöttük, hogy ne legyen értelme összemosni ezt a két fajta erőforrást. Ekkora erővel 2db switchet is bele kellene számolni az egészbe, és akkor az 3-5 már kevés lesz...

Na ugye. Azért vannak olyan piaci szereplők akik szerint pár vasból álló privát felhőhöz nem kell mindent külön vasra rakni:
http://www.pistoncloud.com/openstack-cloud-software/
https://www.nebula.com/

Piston pl. a saját megoldását 5-20 node közé méretezi. De úgy gondolom, annál a cégnél, ahol 1 fős IT van, már az 5 normálisan kiépített node beszerzése is fényévekre van az elkölthető éves IT kerettől.

Mi "Na ugye"?

Írt a srác egy konfigot, erre Te írod rá, hogy 3-5 alatt ne is gondolkozzon senki. Miért? Kettő ilyenből is simán ki lehet hozni egy rendszert, annyi, hogy tároló nélkül egy kis többlet szívási faktort bele kell számítani (ha tárolóval veszed, kicsit drágábbra jön ki, ellenben egyszerűbb/kiforrottabb a rendszer, én alapvetően ebbe az irányba mennék, de sok múlik az SLA/RTO/RPO követelményeken is).

Abban talán egyetértünk, hogy a mentésnek célszerű függetlennek lennie és felesleges ilyen konfigot alá tenni...

2 szerver + 1 tároló + 1 nas jellegű felállás biztosan van 1 rendszergazdás cégeknél, ezt nem gondolom, hanem tapasztalatból állítom.

Naugye-> az se kevesebb vas amit te írtál, backupról nem volt szó eddig. 2 szerver + 1 tároló helyett már inkább egy min. 3 compact node-ból álló megoldást érdemes használni Openstack esetében, amennyiben valami minimális failover a cél, ha nem akkor meg tökmind1, elfut a notebookomról is. SLA kérdése az egész, azt meg nem tudjuk.

Hogy ne lenne már kevesebb 2 szerver 3-5 szervernél? Mint írtam SLA kérdése, de akár tároló sem kell feltétlenül (ha tároló van, akkor nem kell HDD a szerverbe, tehát a kettő nem összehasonlítható 1-1 módon).

Egyébként hány ilyen infrastruktúrát csináltál már, amiben 3 szerverrel lezavarod az egész infrastruktúrát? Mennyi volt a költség különbség hagyományos tárolóshoz képest? Mennyi ideje futnak? Milyen szoftverrel? Milyen az SLA? Ki üzemelteti? Voltak már frissítések? A mentést mivel oldod meg?

3 szerverrel lezavarod az egész infrastruktúrát >> nem az egész infrastruktúrát, monitoring, backup értelemszerűen nincsen benne, csak a storage, computing, network része. 3 szerverest még nem csináltam az egy *elméleti minimum* amivel lehet valamilyen elfogadható szintű failovert rakni a controller szolgáltatások alá. Ez alatt is lehet építeni, pl. ahol nem mission critical a dolog, pl. fejlesztői / tesztkörnyezet. Ha ennyire érdekel a téma, érdemes elolvasni a PistonCloud, Mirantis blogokat, pl. Mirantisék több mint 40 rendszert építettek az elmúlt 2 évben, elég komoly tapasztalt összejött náluk ezen a téren.

"Ha 1 fos IT reszleggel mukodik a ceg akkor ingyenes verzio lesz" - egy másik megközelítés (tapasztalat alapján): pont azért, mert egy fős az IT, hatékony eszközre van szükség, nehogy az 1 főt az olcsó ingyenes megoldás miatt 2-re kelljen duzzasztani. Kiszámolható, hogy hány hónap alatt kopik el például egy vSphere Essentials Plus ára munkabérre és egyéb járulékokra.

Döntést akkor lehet hozni, ha minden üzleti igény be van dobva a kalapba, ez lefordítva műszaki nyelvre és különböző megvalósításokra.

+1
OpenStack-et nem ismerem, de az sem mindegy, milyen klienseket akarsz telepíteni.
Ha sok a Linux, akkor az OpenVZ nagyok könnyen és jól használható, pár mp. alatt futó rendszered van 0-ról. Proxmox-szal nagyon jól használható, van backup, HA és storage támogatás is.

VMware is jó persze, ha rá tudod venni a cégvezetést, hogy adjon sok pénzt hardverre és licencre. vSphere Hypervisor önmagában ingyenesen nem ér sokat, max. tesztkörnyezetnek.
--
PtY - www.onlinedemo.hu

A Proxmox + OpenVZ-vel nekem egy gondom van, hogy az OpenVZ konténereken belül az ACL-eket nem lehet kezelni, mivel úgy tudom a Proxmox kernelben nincs benne. Proxmoxra meg nem szívesen tennék saját fordítású kernelt.
Nekem konkrétan a Zentyal emiatt nem működik OpenVZ-s Ununtu server 12.04-en, mert a Zentyal-ban lévő Samba 4 használná az ACL-eket is.
Tehát a Zentyal megy most VM-ben.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

( _ventura_ v | 2013. 10. 02., sze – 09:49 )

Xenserver ingyen van mostmar minden featurrel egyutt. Erdemes meglesni a cloudstacket is egyszerubb felepitesu, telepitese is egyszeru.

Fedora 19, Thinkpad x61s

( mrmartin v | 2013. 10. 02., sze – 10:20 )

Openstackkel extrém könnyű a karrierépítés, ha meg tudod tanulni rendesen. Minden második héten kapok egy állásajánlatot, és a legtöbb cégnél hiány van Openstack fejlesztőkben / üzemeltetőkben. A kérdés inkább az, milyen típusú alkalmazáskörnyezetet szeretnél Openstack felett kialakítani, mert igazából akkor működik jól ez a modell, ha az üzemeltetett szoftverek is támogatják valamilyen szinten a cloud / devops elveket.

( dap | 2013. 10. 02., sze – 10:32 )

Szerintem VmWare akkor, ha a munkáltató befizet a trainingekre. A többihez fel tudod szívni a tudást bármikor, ha időd engedi, de a vmware drága hóbort.

Igen, mert a VMware Certified * minősítések feltétele a tanfolyam elvégzése (azaz nem tudsz _csak_ a vizsgára befizetni).
Ezek keresett, a szakmában aránylag jól megfizetett minősítések (feltéve ha nem csak braindumpból csinálod és értesz ez mellett pl. storagehoz is rendesen).

egy VMware alapú megoldás ott kezdődik hogy:
- (iSCSI/NFS/FC) Storage
- vCenter
- HA
- DRS
- valamilyen backup megoldás
- (esetleg SRM)

Ezekhez pedig kell némi tudás és még több gyakorlat ahhoz, hogy a valóságban is képes legyél használható rendszert építeni/üzemeltetni ezekből...

--
zrubi.hu

Szerintem ez a nyílt forrású rendszerek esetében is hasonlóan van.
Annyi különbség mindenesetre van, hogy a magvasabb információkat az utóbbi esetben nem csak egy monopol helyről lehet megszerezni.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Természetesen igazad van.

De mivel a VMeare nem nyílt platform, így a hozzá kellő tudást is (nagyrészben) csak tőlük 'veheted meg'

Tanulás, tudás, tapasztalat pedig valóban mindenhez kell - ha nem csak vaktában kattintgatni akarsz rajta. Ezt sajnos sokan elfelejtik és/vagy nem értékelik. Emiatt születik aztán a kóklertársadalom, akik azt hiszik hogy ingyen és megfelelő szintű tudás nélkül professzionális megoldásokat képesek alkotni ;)

--
zrubi.hu

Bocs, de ez így elég sznobul hangzik :-) És nagyon elrettentő...

Alapvetően jók a VMware tanfolyamok, de azért nem sok olyan hangzik el, amit dokumentáció olvasás és gyakorlás nélkül nem lehetne elsajátítani. Sőt: nagyon sok fontos dolog el sem hangzik tanfolyamon, Neked kell utána járnod...

A tanfolyamoknak inkább az az előnye, hogy gyorsabban és esetleg céltudatosabban tudsz haladni (például előkészített gyakorlatok révén). Az más kérdés, hogy a gyártó a tanfolyamok elvégzését kötelezővé teszi bizonyos esetekben, nyilván ennek is több oka van.

A tanfolyamok olyanok amilyenek véletlenül sem dicsőiteni szerettem volna őket (sőt) - de tanfolyam nélkül nem lehet VCP vizsgát tenni. Ez nekem sem tetszik de ez van.

Ha pedig a karrierépítés fontos, akkor jól jön egy-két hivatalos plecsni.

Amúgy valóban jelenleg a VMware (szinte teljes) dokumentációja szabadon elérhető. De az csak rajtuk múlik, hogy mit mennyire dokumentálnak. Sajnálatos módon a vmware esetében igen lényeges részekről egyátalán nics vagy csak nagyon felületes a dokumentáció.

--
zrubi.hu

( AiRLAC v | 2013. 10. 02., sze – 11:28 )

/grammar nazi

Gyerekek, VMware, első kettő betű nagy. Nekem meg ez "báncsa" a szemem :)

/off

A témához pedig, hogy bármelyikkel jól jársz ha értesz hozzá _nagyon_ :)

( zrubi v | 2013. 10. 02., sze – 13:01 )

Hi,

Először is meg kellene különböztetni a hypervisor-t és a rá épülő platformokat...

A VMware-nek pl: van mindegyik
ESXi - hypervisor
vCenter - cluster management

Az Openstack ezzel szemben nem hypervisor hanem egy felette lévő réteg. többek között akár VMware
is lehet alatta a hypervisor...

szvsz. ha komoly rendelkezésre állásnak kell megfelelni a végeredménynek, akkor vmware. (Storage, vCenter, HA, DRS - mert ezek nélkül az ESXi csak gyermekjáték)

Ha csak játék és tanulás a cél, akkor bármi más.
(a VMware tanúsítványokhoz ugyanis cég szinten partnernek kell lenni, és fizetős tanfolyamokat vizsgákat is el kell végezni)

--
zrubi.hu

Ugye itt megint az a kérdés, mit szeretnél felhőben üzemeltetni. Mert pl. egy modern felhő infrastruktúrára fejlesztett alkalmazás alá nem szükséges hagyományos értelemben vett HA, az alkalmazás architektúrájából adódóan egész egyszerűen hibatűrő. Az elmúlt évek téves paradigmája volt a fejlesztők részéről, azt feltételezni, hogy a vas, ahol a szoftverem fut nem áll meg. Megáll pont.

Ez egy egészen friss kapcsolódó cikk, érdemes elolvasni, még ha minden ponttal nem is lehet teljes mértékben azonosulni:
http://citizentekk.com/2013/09/27/10-mistakes-with-openstack-cloud/

Mistake #1: Failure is not an option

Az egyik 230-as zsinór kihúzását minden normálisabb vas túléli, illendően van neki két vagy több tápegysége :-P Bár láttam már olyan diszkdobozt (IBM SSA doboz), ami a tápkapcsoló (mindegyik betápot egy kapcsoló kapcsolta) hibája (a "be" állapotban rögzítő pöcök törése) miatt jól leállt - és be sem lehetett kapcsolni, mert "be" állásban nem rögzítette semmi a kapcsolót. Workaroundként a tápjaira lett direktben rádugva a betáp, miután megfelelő módon, illendően szavakba öntöttem a tervezőjének az családi- és egyéb vonatkozásait :)

Csak azért az ember jobban megbízik egy jól kitalált és bevált ha/lb megoldás mögé beillesztett app-ban, mint ha az app eleve hozza ezt magában. Nyilván, nagy gyártók esetén az ember másként áll hozzá, de ha JóskapistaSzoft hoz egy appot, ami backend nélkül nyújtja ugyanezt, hadd legyek már vele szkeptikus - még ha jó is az az app.
--
PtY - www.onlinedemo.hu

Az appnak több információja van arról, hogy adott esetben mi a legjobb failover stratégia. A hibatűrő app nem azt jelenti, hogy ne építkezne a már meglévő HA technikákra, csak azt, hogy nem épít arra, hogy azok soha nem romlanak el.

A legjobb HA rendszer az, ahol az üzemeltető és a fejlesztő együtt dolgozik. Ha külön-kölün akarják megszülni a megoldást, az többnyire rokkant lesz.

Ok, de én úgy látom, hogy evvel csak megnő a splitbrain lehetősége egy failover clusteren, mert bejön két scenario:

Backend szerint fail van, app szerint nincs.
Backend szerint minden ok, app szerint fail van.

És evvel együtt a hibakeresés is nehezedik, mert probléma esetén ki kell deríteni, hogy kinek volt igaza, amikor két masterem vagy két slave-em lett a clusteren.
--
PtY - www.onlinedemo.hu

Nem úgy értettem, hogy az app vezérli a clustert, hanem úgy, hogy ha leáll egy piszlicsáré erőforrás, akkor az alkalmazás nem akad fenn rajta, hanem tovább tud működni csökkentett módban, amit mondjuk a felhasználók 99%-a észre sem vesz. Ez a legjobb failover stratégia ha az aktuális helyzet megengedi.

Ezzel szemben a cluster nem tud olyat, hogy ha leáll egy erőforrás mert nem jött össze a failover, akkor csökkentett módban tovább fusson az alkalmazás. Ha leállt, akkor leállt, riasztja a rendszergazdát, az alkalmazással meg ki tudja mi van, jó eséllyel fejreállt.

Az átlagos cluster általában mindent egy lapra tesz, hogy sikerül a failover. Egy alkalmazás pedig bízhat abban, hogy sikerül és lehet stratégiája arra ha nem.

Egy App nem is tudhatja hogy milyen HA megoldás van alatta.
(hiszen van még közben néhány réteg: OS, virtualizáció, Cluster Management, Hypervisor)

Csúnya lenne ha egy nyamvadt applikáció megmondaná hogy mi történjen egy clusterben, amiben ö csak egy a sok száz közül...

--
zrubi.hu

Annyira birom az ilyen szuk latokoru embereket, akik leirnak olyat, hogy "ha komoly rendelkezésre állásnak kell megfelelni a végeredménynek, akkor vmware".
Ez egyertelmuen mutatja, hogy fogalmatlan vagy es nem kellene toled elfogadni tanacsot ilyen kerdesekben.

A kollega nem is igazan irta le a kerdeseben, hogy mit is szeretne elerni ezzel a rendszerrel (es ezen egy jo nagy vita alakult ki feljebb) de te megmondod neki a tutit.

Kepzeld, mi RHCS+KVM-el uzemeltetunk egy "komoly rendelkezesre allasu" tobb szaz szerveres DC-t. Eppen most fogunk atterni RHEV-re es kepzeld eppen a VMware helyett dontottunk a RHEV mellett (tobb honapos tesztelesek utan ugy, hogy a penz NEM szamit). De ettol meg nem mondom, hogy a RHEV az egyetlen, amivel meg tudnank oldani a problemankat, sot.

Bocs az offtopic miatt, de egyszeruen most fakadt ki belolem ez. Talan nem ettem eleget reggelire.

Azt hogy a témában melyikünk a fogalmatlan - nem itt kellene megbeszélni ;)

Természetesen (vagy inkább remélhetőleg) mindneki azt ajánja amihez valóban ért és/vagy van vele tapasztalata.

A KVM pedig köszönőviszonyban sincs egy type1 hypervisorral. Innentől beszélhetünk 'komolyságról' rendelkezésre állásról - vagy ami ugyancsak nem mellékes: biztonságról is.

A hozzászólásaim pedig kizárólag a saját véleményemet/tapasztalataimat tükrözik. Akinek ez nem tetszik nem veszi azokat figyelembe.

--
zrubi.hu

"Azt hogy a témában melyikünk a fogalmatlan - nem itt kellene megbeszélni ;)"
Felreertettel. Nem tudhatom, hogy mennyire vagy jartas a temakorben, (illetve te sem tudhatod, hogy en mennyire vagyok) ezert errol itt szo sincs. A fogalmatlansagodat arra ertettem, hogy nem tudsz relevans valaszt adni, mert annyira elkotelezted magad egy bizonyos iranyban (jelen esetben VMware).

"Természetesen (vagy inkább remélhetőleg) mindneki azt ajánja amihez valóban ért és/vagy van vele tapasztalata."
Egyetertunk. De te pont nem ezt csinalod ezzel a mondattal: "szvsz. ha komoly rendelkezésre állásnak kell megfelelni a végeredménynek, akkor vmware"
Ezzel eppen azt magyarazod el a szegeny tanulni vagyo embereknek, hogy CSAK a VMware tekintheto megoldasnak (raadasul ajanlod ezt megoldaskent egy olyan problemara, aminek a definialasat meg kerdezo sem gondolta at rendesen) velhetoen mert te ezt ismered, preferalod jobban.

"A KVM pedig köszönőviszonyban sincs egy type1 hypervisorral. Innentől beszélhetünk 'komolyságról' rendelkezésre állásról - vagy ami ugyancsak nem mellékes: biztonságról is."
Jaj ne, mar megint. Hatalmas, technikailag alatamasztott kijelentesek... Most meg reagalok az egyik felere ennek a kijelentesnek, de nem fogom folytatni, mert vegelathatatlan flame keveredne belole. Csak egy picit megproballak kirangatni a kodbol:
Erosen megoszlanak a velemenyek, hogy a KVM az type1 vagy type2 hypervisor. Aljon itt harom idezet:
a. http://en.wikipedia.org/wiki/Hypervisor :
"Kernel-based Virtual Machine (KVM) are implemented as a kernel modules for FreeBSD[2] and Linux respectively which, when loaded, allows its host operating system to act as a bare metal (i.e., Type 1) hypervisor.[3] However, as FreeBSD (and Linux distributions) are operating systems in their own right, one can argue that bhyve and KVM are a Type 2 hypervisors.[4]"
b. https://www.ibm.com/developerworks/community/blogs/ibmvirtualization/en…:
Myth #1: KVM is type 2 hypervisor that is hosted by the operating system, and isn’t a bare metal hypervisor. This is a persistent myth, but the truth is that KVM actually does run directly on x86 hardware.
...
On x86 hardware, KVM relies on the hardware virtualization instructions that have been in these processors for seven years. Using these instructions the hypervisor and each of its guest virtual machines run directly on the bare metal, and most of the resource translations are performed by the hardware. This fits the traditional definition of a “Type 1,” or bare metal hypervisor.
c. https://www.ibm.com/developerworks/community/blogs/ibmvirtualization/en…:
Myth #6: KVM is not secure. Of course, this is a myth. KVM has all the security features that VMware has plus some more – such as mandatory access control turned on by default.

"A hozzászólásaim pedig kizárólag a saját véleményemet/tapasztalataimat tükrözik. Akinek ez nem tetszik nem veszi azokat figyelembe."
Ez a resze a hozzaszolasodnak teljesen rendben van. En csupan arra szerettem volna felhivni a figyelmet a kezdo, a virtualizaciohoz (meg) nem erto embereknek, hogy a te velemenyed rossz, pontantlan.

mert annyira elkotelezted magad egy bizonyos iranyban (jelen esetben VMware)

Inkább csak úgy fogalmaznék, hogy jelentős tapasztalattal rendelkezem a témában - elfogultnak semmiképp sem nevezném, sőt. (úgy érzem eddigi cikkeim, és előadásaim sem vmware seggnyalásról szóltak :)

Inkább azt látom hogy sok 'szakember' azért tarjta rossznak (vagy inkább csak nem látja mennyire jó) a VMware megoldásait, mert egyszerűen nem ért hozzá olyan szinten, így közelébe sem kerül annak, hogy megtapasztalja mit tud nyújtani egy megfelelően megtervezett és megvalósított vmware cluster - szeben bármelyik másik gyártó bármelyik termékével.

Szóval bátran úgy érzem, a "szűklátókörű, és szob" véleményeimet technikai háttérrel is bármikor meg tudom támogatni...

A kezdő és tanulnivágyó kollega még maga sem tudja mit szeretne - így elég nehéz neki segíteni. De ahogy a kérdésből látom, mindegy merre indul, sok tanulnivalóval fogja szembetalálni magát ;) És a megszerzett tudás hasznos - bármelyik termékről is legyen szó.

KVM vs Type1 - ről is szívesen vitáznék... De mindegy is minek nevezzük... technikai megoldásokban semmiképp nem egy kategória az ESXi-vel.

Amivel az ESXi érdemben összehasonlítható az egyedül a Xen.
Azonban abban a pillanatban, amint nem csak a hypervisor-t nézzük, már nem nagyon marad konkurencia technikai tudásban/megoldásban.
Természetesen erre a 'tudásra' nincs mindenkinek szüksége (pénze), ezért mertem pongyolán csak "komoly rendelkezésre állásnak" hívni azt, amit egy vmware clusterből ki lehet hozni (más megoldással pedig csak közelíteni hozzá valamennyire)

Szerintem.

--
zrubi.hu

Hosszu story lesz de gondolom sokakat erdekel ezert veszem a faradsagot es leirom...
Kozel egy eve kezdodott a project, amiben korul akartunk nezni a marketen milyen egyeb lehetosegek vannak server virtualizaciora. Azzal kezdtuk, hogy egy brainstorming session alatt meghataroztuk a kovetelmenyeinket. Tobb szaz, kizarolag Red Hat linux-ot uzemeltetunk (van kulon windows-os unit, akik speciel VMware-t hasznalnak virtualizaciora).

Egyetlen elengedhetetlen kovetelmeny volt:
* atomstabil HA a nem kontainer alapu, RHEL VM-eknek, Red Hat altal supportalt kornyezetben

Ehhez parosult meg sok olyan kovetelmeny, ami a "jo volna ha lenne" kategoriaba esett (ertsd, nem zarjuk ki a termeket ha nem teljesiti):
* ne legyen olyan komponense, ami windows-t igenyel (ez egy ceges policy nalunk, hogy az osszes mission critical application linux-on fut. MC alatt ne a ceges levelezest ertsd, csak olyan app-ot amitol a ceg letezese fugg )
* DBA-k Oracle illetve Postgres DB-t supportalnak nalunk. Jo volna ha nem nekunk kellene a DB-vel foglalkozni
* Szeles (enterprise) korben hasznalt, jol kiprobalt, stabil termek, megfelelo jovokeppel es ceggel a hata mogott
* API az integraciohoz
* A jovoben lehet, hogy destop virtualizaciot is bevezetnenk, jo volna ha lenne ra lehetoseg

A projectet en kaptam mivel nekem volt a legtobb tapasztalatom virtualizacios teren. Annyi relevans rolam, hogy tobb eves VMware illetve Red Hat sys admin tapasztalatom van (nem 1-2 gepes kornyezetben) es mindket ceg termekeit nagyon szeretem.

Az elso szita utan (ami inkabb olyan feature olvasgatason, tapasztalatokon alapszik) 2 termek maradt: VMware es RHEV. Mar itt lattuk, hogy egyik sem fog minden feltetelnek megfelelni de elkezdtuk jobban altnezni a technologiak elonyeit, hatranyait.

Legend:
+ elony
++ nagy elony
- hatrany
-- nagy hatrany
* semleges megjegyzes

VMware:
++ market leader. A legnagyobbak ezt hasznaljak. Eros, nagy ceg a hata mogott.
+ iszonyat jo documentacio (talan azt mondanam, hogy a legjobb az osszes ilyen kaliberu termek kozul amivel munkam soran talalkoztam), hatalmas community
-- HW support. Mielott az Oracle megvette volna oket, Sun vasakat hasznaltunk (jelenleg IBM a befuto). Megvizsgalva (akkoriban) a VMware support matrixat ra kellett jonnunk, hogy a legujabb verzio egy darab szervert sem tamogat a 100-as nagysagrendu szerver parkunkbol. Ez nem feltetlenul jelent problemat mivel a valtas ugyis evekig tart (eleg specialis eset a mi cegunk) es a servereket 3-4-5 evente csereljuk, igy szepen lassan eltunnek a nem supportalt HW-ek a DC-bol, de azert megiscsak egy into jel. Beszelgetve a windows adminokkal azt mondtak, hogy tobbszor volt olyan problemajuk, hogy nem tudtak upgradelni, mert a vasat, akkor meg nem vagy egyaltalan nem supportalta az uj verzio.
- windowsos kliens (akkoriban). Ez nem egy hatalmas problema mert a kliens nem sok uzemeltetest igenyel, de problema. Peldaul azert, mert legtobb linuxos sysadminnak nincs windows-a nalunk. Masik apro problema ezzel, hogy van nekunk egy disaster recovery procedurank amiben azt irjuk le, hogy melyek azok a szerverek amiket muszaly visszaallitani ha leeg a DC es hogyan kell ezeket megtenni. Hirtelen megjelenne egy windows install ebben a proceduraban, amire jelenleg nem vagyunk felkeszulve. Semely szerint nem utalom a windowst, de szeretem elkerulni ha ilyen dolgokrol van szo. Ez legfokepp annak koszonheto, hogy ertek hozza annyira.
- uj ceg a support line-ba (bizony volt mar olyan problemank ahol 2 gyarto egymasra mutogatott, hogy nekik kellene megoldani a problemat. Ez igen ritka mert a legtobb gyarto direkt kapcsolatban van a masikkal es nelkulunk oldja meg a problemakat).
- ha jol emlekszem csak powershell meg egy nem teljes perl API volt hozza akkoriban (ebben lehet hogy tevedek de mar regen volt). Nalunk python a standard.
* nem nagyon volt dolgom a supportal. Ez velhetoen koszonheto a stabil termeknek, a nagyon jo documentacionak es a hatalmas community-nek (na meg annak, hogy szeretem sajat kezuleg megoldani a problemakat amig ezt a supportalt kornyezet engedi)
* oracle-re mehet

RHEV:
-- nagyon uj termek. Ellentetben a jol bevalt RH policy-val az uj feture-ok szinte azonos idoben jelenkeznek az enterprise termekben mint az upstreamben, ez kisebb stabilitasra utal.
++ iszonyat jo support. TAM supportunk van amivel messze a legjobb tapasztalatunk van. Ennek koszonhetoen kihagyjuk a level1, level2 supportot es rogton egy olyan level3-as srachoz kapcsolnak Nemet-be aki ismeri az infrastrukturankat.
+ Azonos cegtol kapjuk a supportot az OS-re illetve a virtualizaciora.
++ minden HW supportalt, amit a RHEL supportal (ez a lista joval nagyobb, mint a VMware HW support matrix)
+ Nem szukseges windows. (akkoriban csak RHEV3.0-as volt amihez kellett IE. De 3.1-tol igertek, hogy ez a dependency megszunik)
+ Csapatunk (7 fo) minden tagja rendelekezik 5+ eves RH admin tapasztalattal illetve tobb RHCE feletti certificate-kel. Aki tudja mit jelent ez, az azt is megerti, hogy sokkal biztosabb tudassal fogunk beloginolni egy RHEL hypervisorba mint egy VMware-be mert ertjuk, mi tortenik a hatterben. Ha minden kotel szakad, siman elindutjuk a VM-eket KVM-el ;)
+ A hypervisorok installalasara a mar meglevo infrastrukturat tudjuk hasznalni
++ van hozza egy REST API amivel mindent meg tudunk csinalni. (azota pedig egy python sdk is :) ) Ez nagyon fontos egy-ket kolleganak itt aki ideje nagy reszet scriptelessel/integralassal toltogeti.
* sok feture-t nem tartalmaz (vagy nem annyira jo megoldasa van ra) amit a WMware igen, de minden feature-t tartalmaz ami nekunk kell, elengedhetetlen.
* postgres

Ezeket osszevetve lathatjuk, hogy mindket termek megfelelne az elvarasoknak de valahogy megis a RHEV tartalmazza a kevesebb negativumot (tobb pozitivumot). Ezert ugy dontottunk, hogy kemeny teszteles ala vonjuk a RHEV-et, hogy megnezzuk mennyire problemas a legnagyobb negativuma (uj termek).

Ez a teszteles igazan a 3.1-es verzioval kezdodott es 2 evaluation license-t (2x3 honap) olelt fel es a legtobb idot a bug-ok javitasara varva toltottuk. Az elejen volt olyan ido, amikor azt mondtuk, hogy nem biztos, hogy eles kornyezetben hasznalnank de ez a kozepe fele megvaltozott. Osszesen 24 bug/RFE-t reportoltunk, ebbol 14 javitasra kerult (mindegyik major problem javitasra kerult 1 kivetelevel, ami jelenleg a QA-n csucsul es varhatoan a 3.3-asban lesz javitva de megfelelo workaround-ot tudtak javasolni). A maradek 10 legtobbje RFE amin meg gondolkoznak, hogy implementaljak-e vagy egy kesobbi verziora igerik az implementalasat.
Talaltunk olyan limitaciokat (pl minden szervernek kell latnia minden LUN-t egy adott logical dc-n belul) amit csunya work aroundokkal kellett megoldanunk (maradva az eredeti peldanal: kulon logikai dc mindegyik clusternek) de mindegyiket reportoltuk es javitas alatt van (maradva az eredeti peldanal: 4.0-aban mar lehet clustereknek kulon LUN egy DC-n belul).
A tesztek alatt folyamatosan upgrade-eltuk a RHEV-et illetve a clustereket es egy 5 perces problemat eltekintve (ibm java helyett openjdk install) nem utkoztunk problemaba.

Mint lathatjatok szamunkra a RHEV volt a befuto mert egyszeruen jobban illik a meglevo infrastrukturaba, tudabazisba. Szent meggyozodesem, hogy a VMware-el sem jartunk volna rosszul de a merleg nyelve nalunk nem arrefele billent.

P.S: Regebben vegeztunk performance teszteket is (a VMweare-t kulsos consultans configolta/optimalizalta, a KVM-eket mi) inkabb csak kivancsisagbol mert mindig meg voltunk elegedve a KVM (regebben Xen) teljesitmenyevel de ezeknek az eredmenyet a VMware EULA-nak (reszleges) ismereteben nem teszem kozze. De mindenkinek ajanlom ezt elevgezni, nem tart sokaig megfelelo tudas mellett. Meglepo eredmenyek szulettek.

Igazabol alap "tuning" (eleg tag fogalom) nelkul, szinte semmi ertelme nincsen tesztelni. Alap peldak:
* ESXi: ha nem installod a windowsra a vmware tools-t, akkor nagysagrendekkel kapsz roszabb teljesitmenyt onmagahoz kepest.
* KVM: ha pl qcow wagy raw image-t hasznalsz, akkor nagysagrendel kapsz roszabb teljesitmenyt IO-ban mintha direct device-t, logical volume-ot hasznalnal diszknek (RHEV ezutobbit hasznalja)
* KVM: ha nem a paravirtes drivereket hasznalod, akkor ismet nagysagrendeket veszithetsz

Stb.

* ESXi: ha nem installod a windowsra a vmware tools-t, akkor nagysagrendekkel kapsz roszabb teljesitmenyt onmagahoz kepest.

Mármint a guest-re? Mit befolyásol? A paravirt SCSI/network driverek azok, amelyekkel jobb teljesítményt értetek el, mint az LSI Logic/e1000 driverekkel?

Azért kérdeztem, mert nekem ezzel más tapasztalataim vannak. Nem tudtam különbséget mérni az egyes driverek teljesítménye között, ellenben a paravirtekkel különböző hibákba futottam bele, pl.:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cm…

Igaz, főképpen VMware 4.1-ekkel van tapasztalatom, újabbakkal nincs.

"Egy kerdes: az esx-nel mi azaz oracle-re mehet?"
DB back-end a vCenternek. A DB adminolas igy mehet a DBA-k kezebe :)

"Az utolso bekezdes eredmenyet esetleg maganban meg tudnad irni?:)"
Nem szeretnem, mert hirtel kell majd 100 magan levelet kuldenem ;)
Eleg legyen annyi, hogy sokkal kozelebb vannak egymashoz, mint azt mindket gyarto kozli. Ugye mindket gyarto azt mondja, hogy ok a gyorsabbak, ami termeszetesen a sajat tesztjeikkel igaz is ;).

Köszi a leírást, tanulságos.
A mentéseket miként oldjátok meg? A DR folyamatba bevonjátok a virtualizációt valamilyen módon?
A teljesítmény tesztek engem is érdekelnének, leginkább kiváncsiságból, metodika miatt.

Csak a teljesség kedvéért:
A VMware-nek van webszolgáltatás API-ja, nagyon jó (és elvileg teljes is), elég régóta van. (ezt még nem próbáltam: http://code.google.com/p/pysphere/)
Kellő méret/szerződés esetén VMware is rendel Hozzátok egy vagy akár több embert támogatás céljából.

"A mentéseket miként oldjátok meg?"
Arra torekszunk, hogy minden VM OS beallitas szinten "stateless" legyen. Ezt ugy erjuk el, hogy provisoning szervert es configuration managert hasznalunk (cfengine volt regebben jelenleg puppet). Ezen felul minden custom appot (sajat fejlesztes, nem resze az OS-nek) egy kulon konyvtarba installunk, ami megy a backup-ba (egyszeruseg kedveert file szinten az egesz VM benne van a backup-ban).
Ez azt jelenti, hogy barmikor ujrainstallaljuk barmelyik VM-et manual beavatkozas nelkul, ugyanilyen configgal, mint jelenleg fut kb 1 oran belul.

"A DR folyamatba bevonjátok a virtualizációt valamilyen módon?"
Igen, ez jelenleg elengedhetetlen mert a service-ek 99% virtualizalva van (a maradek nem tamogatja a virtualizaciot, amit mi hasznalunk (Oracle)).

"A VMware-nek van webszolgáltatás API-ja, nagyon jó (és elvileg teljes is), elég régóta van."
Bevallom oszinten errol nem tudtam de az is lehet, hogy ez meg nem volt supportalt amikor en a "kutatast" vegeztem. Miota van ez?

"ezt még nem próbáltam: http://code.google.com/p/pysphere/"
Probaljuk elkerulni a nem supportalt megoldasokat, persze teszunk kiveteleket. Mindenesetre jo tudni, hogy van ilyen.

"Kellő méret/szerződés esetén VMware is rendel Hozzátok egy vagy akár több embert támogatás céljából."
Errol sem tudtam de sejtettem. :)
A RH-nal ez adott volt nekunk.

DR folyamat: ha jól értem, akkor a mentések nem VM alapúak (tehát mindegy a mentés szempontjából, hogy VM-ben fut vagy sem), a DR folyamatokban miként jönnek elő a virtuális gépek, avagy miként használjátok ki, hogy VM-ek vannak? (akár olyan is lehetne, hogy DR oldalon van X darab "üres" VM, ha DR elrendelés van, akkor beléjük kell tölteni az adatot - nyilván RTO/RPO függő sok minden; vagy akár a DR oldali megfelelőbe át van rendszeresen mentve a szükséges adat függetlenül attól, hogy VM-ben fut az adott szolgáltatás vagy sem)
Akár arra gondolok tulajdonképpen, hogy VMware SRM jellegű dolog van-e, esetleg "stretched cluster" megoldás.

VMware SDK: http://www.vmware.com/support/developer/vc-sdk/index.html, itt vannak kiadások 2004 óta, bár az talán még nem webszolgáltatás alapú volt (vSphere 4.0-tól biztosan van). Ezt is tudom ajánlani: http://vijava.sourceforge.net/ (hivatalosan nem támogatott, de érdemes megnézni a PoweredBy oldalt)
Egyébként ennek is elég jó a dokumentációja + az egész rendszer meglehetősen átgondolt.

Jol erted, a mentesek nem VM alapuak. Illetve egy disaster eseten nem kizarolag a menteseket hasznaljuk fel visszaallasra (bar nem kizart, hogy bizonyos esetekben gyorsabb volna).
Nincsen DR site-unk es ennek tobb oka (fokent technikai illetve politikai) van, tehat nincs szuksegunk VMware SRM-hez hasonlo megoldasra. Mikor legutobb beszelgettem a TAM-unkkal a RHEV-rol o emlitette, hogy sokan hianyoljak ezt a RHEV-bol es azt mondta, hogy nemsokara lesz (hogy ez mit jelent idoben azt talan a HUP-on levo RHEV fejlesztok meglengethetik ;) ).
Tehat, amikor leeg majd a DC-nk meg kell varnunk, amig eloltjak a tuzet (ha mi nem porkolodunk meg) ;)

Akkor, hogy osszefoglaljuk, ezekrol a limitaciokrol beszelunk:
* A RHEV-ben nincs built-in megoldas jelenleg disaster recovery site-ra. (persze senki sem gatol meg abban, hogy magadtol osszerakj egyet: http://www.redhat.com/resourcelibrary/reference-architectures/RHEV-3-Di… )
* Nincs normalis snapshot megoldas (ez egy picit faj nekunk is, de elvileg ev vegen (mielott mi elesbe megyunk) lesz)
* Ennek koszonhetoen nincsen normalis VM alapu mentes (mi eddig is file alapu mentest csinaltunk (termeszetesen mindkettonek van elonye a masikkal szemben))

Szamunkra (es sztem sokak szamara) ezek nem "gaz" limitaciok.

Egyszerubb becopizni:
"In a live migration, the guest continues to run on the source host while its memory pages are transferred, in order, to the destination host. During migration, KVM monitors the source for any changes in pages it has already transferred, and begins to transfer these changes when all of the initial pages have been transferred. KVM also estimates transfer speed during migration, so when the remaining amount of data to transfer will take a certain configurable period of time (10ms by default), KVM suspends the original guest, transfers the remaining data, and resumes the guest on the destination host."

( zeller | 2013. 10. 02., sze – 21:15 )

Mit szeretnél? Milyen OS-eket szeretnél virtualizálni? Milyen a jelenlegi hardver? Milyen rendelkezésre állás kell, mennyire fognak változni a virtuális gépek... Sok-sok kérdésre kell -magadnak- válaszolnod, és utána elindulni valamilyen irányba. Én még a ganeti-t is megnézném egyébként :-P