Virtualizáció - megéri?

Virtualizáció

Tudom, hogy egyre divatosabb használni annyira, hogy már-már ciki, ha valaki natív futtatja az OS-t.

Kérdésem:
Megéri használni egy vason több OS-t úgy, hogy a diszkek sebessége a 10 évvel ezelőtti színvonalról máig nem lépett jelentősen előre?
(Azt gondolom, hogy már vagy 6-8 éve is a diszk volt a szűk kereszt metszett a számítástechnikában.)
Érdekelnének a tapasztalatok, diszk használat terén. (pro/kontra)

  • 10010 megtekintés

( andrej_ v | 2011. 05. 04., sze – 10:54 )

Azért egy 15k RPM-es SAS raid tömb igen izmos tempót tud hozni a 4-5-6 évvel ezelőtti állapothoz képest is. :)

Ha nagyon-nagyon IO igényes a cuccod, akkor még mindíg ott van a teljes PCI passthrough vagy a scsi passthrough ha a hipervigyor támogatja.

A tapasztalat az, hogy néhány kisebb IO igényes cuccot elég lazán lehet virtualizálni. Ahol már látványos az IO igény oda kell valami normális storage, de ezt elég könnyen be lehet lőni.

nem kell oda 15krpm SAS, vigan tudok olyan diszktombokrol, amik SATA diszkekbol vannak felepitve, es futkorasznak izmos sebesseggel.

persze en mostanaban az SSD-s raidet javaslom ilyen ala, ha annyira fontos a sebesseg, es van penz. vagy vegyesen, egy raid tomb ssdvel, egy raid tomb normal diszkekkel, es akkor megvan a flexibilitas is.

(semmibe nem kerul manapsag venni 8db 120g -s ssdt)

ez olyan, mint ha a bobcatet hasonlítanád a 16 tonnás rendes caterpillarhoz.
az egyik erre jó, a másik arra jó, és amire az egyik jó, arra a másik vagy nem igazán jó, vagy egyáltalán nem alkalmas.

a "jól bevált" sata/sas diszkek bizonyos feladatokra jóval drágábbak, bizonyos feladatokat pedig sehogy sem tudnak elvégezni. ahogy bizonyos feladatokra az ssd lesz drága/alkalmatlan.

Nem fér el ugyanakkora kapacitás ugyanakkora helyen. Ha az egyéb paraméterek adottak (mondjuk fizikailag nem fér el nagyobb kasztni, abba fizikailag nem fér több diszk), akkor van olyan szituáció, ahol egyszerűen nem tudod használni. És ez egy technológiai korlát, ami idővel vagy enyhül, vagy nem.

a "jól bevált" sata/sas diszkek bizonyos feladatokra jóval drágábbak, bizonyos feladatokat pedig sehogy sem tudnak elvégezni. ahogy bizonyos feladatokra az ssd lesz drága/alkalmatlan.

Arról szólt a thread itt, hogy az árán kívül van-e olyan paraméter, ami miatt az ssd valami konkrét feladatra alkalmatlan. Erre leírod, hogy létezik olyan feladat, amire alkalmas és hatékonyabb. ???

( egeresz | 2011. 05. 04., sze – 11:18 )

nezzunk par scenariot

Kiindulo allapot:
kell 20 szolgaltatas. Ebbol 1 nagy teljesitmeny-igenyu, 19 kis teljesitmeny-igenyu.

1) Felpakoljuk 1 vasra, 1 oprendszer ala mind a 20 szolgaltatast.
- > a legjobb teljesitmenyt ered el, de a legeslegjobban kell beallitani azt az oprendszert. Ez neha kemeny kihivas.

2) Felpakoljuk 2 vasra, vasankent 1 oprendszerrel. nagyot az egyikre, kicsit a masikra
-> legkevesebb tudas eleg hozza

3) Felpakoljuk 20 vasra, vasankent 1 oprendszerrel. Mindegyik szolgaltatast kulon.
-> legtobb penz kell hozza, es a legtobb rendszergazdai ido

4) Felpakoljuk 1 vasra, hypervisorra, valahany oprendszerre szetszorjuk a szolgaltatasokat
-> picit dragab vas kell hozza, mint az 1 esetben, de kevesebb tudas eleg.
-> tobb tudas kell, mint a 2-ben, de kevesebbe kerul a vas.
-> kevesebb ido kell hozza, mint a 3-ban, de kisebb a rendelkezesreallasa

A virtualizalas egy jo atlag, hogy azzal szivjal, amivel szeretsz.
:-)

figyuzzatok man, semely oprendszernek, semely hypervisornak nincs abszolult teljesitmenyigenye, alkalmazasnak van! Az oprendszereknek es hypervisoroknak overheadjuk van (szazalek), amit hozzatevodik a szolgaltatas igenyehez.
Az IT ipar (te, a rendszergazda) pedig nem hardvert vagy oprendszert uzemeltetsz, hanem szolgaltatast. Es a ceget igazabol nem erdekli, hogy az a szolgaltatas min fut, hanem az, hogy fut-e.

Az észrevételed jogos, természetesen nem egy servert használ az ember virtualizáláskor, hanem legalább kettőt, clusterben. Az adminisztrálás annyiból egyszerűbb, hogy a guestek egyféle gépen futnak, elég egyszer installálni egy master változatot, majd klónozni.
Mivel éles környezetben virtualizálni cluster nélkül botorság, ezzel ne is foglalkozzunk. Clusterben viszont magas rendelkezésreállást biztosíthatsz olyan környezeteknek is, amelyek erre esetleg alkalmatlanok, vagy ahol egy cluster megoldás bonyolultabb, mint a virtualizációs környezeted alatt.
Ezenkívül virtualizált környezetben könnyebben megoldható az erőforrások managementje. Időszakos terheléssel járó rendszerek csak akkor kapják meg az extra erőforrásukat, amikor erre szükségük van. Így megoldható, hogy éles és teszt környezetek olcsóbb vason fussanak, amennyiben a teszt környezetek leállíthatóak az éles csúcsrajáratása közben. Spórolhatsz az erőforrásokkal úgy is, hogy guestek különböző hostokon futnak, ám valamely host leállása esetén az alacsonyabb prioritású guesteket leállítod, így a megmaradt hostok probléma nélkül szolgálják ki a fontos guesteket.
Vannak cégek, ahol a servereket csak három évig használják, amíg a bővített garancia él, majd kivonják éles üzemből. Virtualizált környezetben ez a váltás a felhasználók számára észrevétlenül oldható meg és az üzemeltetés terhelése is alacsonyabb, hiszen az új vasat kevesebb időráfordítással állíthatod üzembe, mintha minden vackot újra fel kellene installálnod (OS, alkalmazások, felhasználók...)

Nekem is évekbe került. :-)
Az eredeti kérdéshez még annyit, hogy nem szokás egy disken virtualizálni, vállalati környezetben, hozzáértő üzemeltetés esetén természetesen. Virtuális környezetek alá érdemes valamilyen intelligens tárolót pakolni, ami az adatokat sok disken kezeli, párhuzamosan. Mondjuk clusteres környezetben ez nem kérdéses, bár két host között még JBOD-ot is meg lehet osztani, három vagy több host esetén ez már elég nehézkes vagy lehetetlen.
Természetesen minden esetben meg kell vizsgálni, hogy megéri-e egyáltalán? Pár éve még érvényes volt az a mondás, hogy adatbázist nem virtualizálunk, mivel adatbázis alatt nincs túl sok erőforrás és bármilyen virtualizáció csak lassíthatja a működését. A paravirtualizált eszközmeghajtóknak köszönhetően viszont ez az állítás egyre kevésbé igaz.

Ave, Saabi.

Általánosságban pár éve sem lehetett kijelenteni, hogy adatbázist ne futtassunk virtualizálva. Nyilván egyre kevésbé, de mindig meg kell nézni, hogy ki mit virtualizál, valamint az alatta levő infrastruktúrát is megfelelően kell méretezni (ha azt mondjuk, hogy a virtualizáció levesz 10% teljesítményt, akkor többlet teljesítménnyel ezt lehet kompenzálni annak érdekében, hogy élvezzük a virtualizáció előnyeit).

Mármint minoritás azon virtualizált adatbáziskezelők száma, amelyeknek problémát okoz a megnövekedett válaszidő a diskek felől?
Ez tökmindegy, attól még a probléma fennáll és ha az embernek épp egy ilyen rendszert kell gatyába ráznia, akkor a legkevésbé érdekli, hogy ilyenből azért nincs sok.

Ave, Saabi.

A banánhéj is akkor veszélyes, ha rálépünk, ha futunk, akkor pláne.

Az "előfordul olyan rendszer, ahol a virtualizáció miatti válaszidő növekedés elfogadhatatlan" és a "Pár éve még érvényes volt az a mondás, hogy adatbázist nem virtualizálunk" között elég nagy szakadék van.

Ekkora erővel abba is bele lehet kötni, hogy "akkor többlet teljesítménnyel ezt lehet kompenzálni", hiszen ha az úgymond maximális fizikai vas ki van hajtva csutkára (mondjuk CPU szempontból nem is nehéz: ha 8 magnál nagyobb rendszerről beszélünk), akkor 1-1 nem virtualizálható a rendszer. Ilyen ma is van, valószínűleg a jövőben is lesz, amíg nem korlátlan a VM-be konfigurálható magok száma.

De még ez esetben is meg lehet akár azt nézni, hogy némi fürtözéssel/terhelés elosztással mi a helyzet, ismét a régi klasszikust tudom idézni: http://blogs.vmware.com/performance/2008/06/scaling-real-li.html

(ha azt mondjuk, hogy a virtualizáció levesz 10% teljesítményt, akkor többlet teljesítménnyel ezt lehet kompenzálni annak érdekében, hogy élvezzük a virtualizáció előnyeit).

A virtualizáció 99%, hogy nem százalékos teljesítmény csökkenést okoz, hanem nagyjából per I/O request latency növekedést. Azt meg egy határon túl nem tudod kompenzálni, mert 0, vagy negatív idő alatt válaszoló diszkegység kellene hozzá, ami elméletben sem lehetséges.

SUM()

Azt hiszem megállapíthatjuk azt, hogy csak bizonyos számú szerver felett érdemes ezen a fajta migráción gondolkodni.
Vagyis, ha a jelenleg meglévő szerverek száma több, mint az új cluster.ben szereplő szerverek száma és összes bekerülési költségük szintén több, mint n db csúcs szerver + diszkalrendszer, akkor a választás ez utóbbira kell, hogy essen és a régi szolgáltatásokat virtualizációba migrálva lesz érdemes futtatni.

Ez egyáltalán nem ilyen egyértelmű. A képletbe az üzleti igényeket kell belefoglalni (ami vagy teljesített virtualizációs gondolkodáskor, vagy sem), az pedig praktikusan nem (csak és kizárólag) szerverek számában fejezhető ki.
Az üzleti igények vonatkozhatnak rendelkezésre állásra, rugalmasságra, tesztelési/fejlesztési lehetőségekre és még hosszan lehetne sorolni.

Nem árt persze azt sem megvizsgálni, hogy minden szolgáltatás önálló gépet igényel, vagy vannak olyan szolgáltatások, melyek egymás mellett, egyazon operációs rendszerben is képesek működni?
Ezenkívül a szerverkonszolidáció csak egy kérdés, a másik pedig hogy a jövőben mire számíthatsz? Lesz-e szükség új szolgáltatásokra és ezek ellátására új szerverekre?

Ave, Saabi.

Azért a hozzám hasonló cipőben járó emberkék védelmében: nem mondom, hogy mindent tudok. Nem mondom, hogy értek hozzá. De azt se mondanám, hogy hülye vagyok és azt is tudom, hogy lehetne jobban is. De ha a pénzügy és/vagy a főnök nem engedi a beruházást, akkor én hiába szerencsétlenkedek... Én üzemeltetem, de sz@rból várat attól még nem tok építeni!

Annyit tennék hozzá, hogyha valahol amúgy is csak egy vason futna x darab szolgáltatás, akkor "nem kötelező" két gépen virtualizálni. Ha két vason futna két szolgáltatás, akkor már jobban megfontolandó, de ha az egyik működésének előfeltétele a másik is, akkor ismét opcionális a redundáns architektúra (ami mind eszközök szempontjából drágább, mind bevezetés és üzemeltetés szempontjából).
A redundanciát a cégnek kell eldöntenie, hogy mennyit ér meg neki.

Ha van tíz, egymástól független szolgáltatásod, akkor az egyik kiesése nem feltétlen eredményezi az egész cég leállását. Ha mind a tíz szolgáltatás egy vason fut, annak a vasnak a kiesése az egész cég leállását eredményezheti, mivel az alkalmazottak nem tudnak 'Y' programmal dolgozni amíg 'X' betegeskedik.
A virtualizáció nem nagyon emlegetett mellékhatása, hogy ha nem működik, akkor sokkal nagyobb kárt okozhat, mintha nem volna. Persze jó tervezéssel ennek esélye csökkenthető, de pl. a VMWare - legjobb tudomásom szerint - nem képes sofwtare-es tükrözésre, tehát ha egy LUN kiesik a storage hibájából, az minden, azon a LUN-on futó guestet érint. És ezen nem tudsz egy második storage üzembeállításával segíteni. Ha tévednék, elnézést kérek, de én így tudom.

Ave, Saabi.

Ha a vmware nem is, mas tudhatja, nem? Amugypedig te itt most esxi-rol beszelsz? Zavaros.

Nemmellesleg nem kell feltetlenul kell zero kieseses atallasra gondolni. Hasonlo esetben nagyon sokszor az is epp eleg, ha human eroforras kezimunkaval helyrerazza a rendszer, ha szukseges a tukor beillesztesevel.

Ugyanez egy normal gep eseten jo esellyel gepek fizikai szereleset jelenti.

Vagy felreertettem vmit?

udv,

tompos

Igyekeztem végig kerülni konkrét megvalósítás megnevezését és általánosságban beszélni.
A példámban vSphere-re gondoltam.
Hogy a manuális helyreállítás mennyi idő alatt abszolválható, erősen függ a humán erőforrás képességeitől és a hiba jellegétől. Lényeg, hogy a hibaelhárítás alatt nincs _semmilyen_ szolgáltatás. Hogy ez elfogadható-e vagy sem, döntés kérdése.

Ave, Saabi.

Nem, nem az. Nem csak disk kiesés okozhatja LUN kiesését. SAN félrekonfigurálás, prezentáció félrekonfigurálás, sikertelen firmware upgrade, firmware bug... A lehetőségek tárháza korlátlan. Lényeg, hogy amíg egy storage használható, az bizony SPOF és amíg egy környezetben csak egyetlen SPOF is található, addig az a környezet nem magas rendelkezésreállású, tehát felmerülhet olyan szituáció, hogy nincs szolgáltatás.
Értem én, hogy ezek már erősen enterprise problémák, SOHO-ban ritkán merülnek fel. De a teljes képhez úgy véltem hozzátartoznak.

Ave, Saabi.

na várjunk: ha intelligens, redundáns külső diszkegységed van, az nem soho környezet, hanem enterprise, árban is (milliókról beszélünk).
ha nincs intelligens külső diszkegységed, akkor hogy van multi initiator diszked? ha nincs, akkor hogy akarsz szerver failovert? hidegtartalék és átdugod a diszkeket? vagy iscsi?

ha meg nincs szerver failovered, akkor milyen spof-ról beszélgetünk egyáltalán?

szóval persze, igazad van, a képhez hozzátartozik, és szerintem sem frankó, ha a virtualizációs környezet annyit se tud, hogy két mezei belső sata diszket összetükrözzön, de azért nem ez az igazi szempont.

Azert nem kell miliokban gondolkozni. Alapszinten kell 4 kozepszintu szerver: 2 hypervisor, 1 FreeNAS(iscsi) + 1 dev(szukseg szerint plusz szerver/backup/nas). Egy hasonlo setuppal gyakorlatilag mindent meg lehet csinalni, es ha gaz van, a dev gepbol egy reboot-al csinalsz backup nas-t, vagy 3ik hypervisort.
Ez alatt is lehet virtualizacioban gondolkozni, csak egy csomo elonyet nem fogod elvezni.

http://www.stormagic.com

A http://www.vmware.com/resources/compatibility/ oldalon keress rá a tárolókra, "Storage Virtual Appliance Only" opcióval. A többit nem ismerem/próbáltuk, nem tudom miként állnak pontosan a replikáció kérdésével.

Most jött ki nem régen w2k8r2-höz az iSCSI target, elvileg VMware alatt is használható, talán HCL-ben is benne lesz (ennek a replikációs képességeit is meg kellene nézni).

Nem drbd, hanem ugyanaz a funkcionalitás: szinkron tükrözés hálózaton keresztül.
Az a probléma, hogy a hálózati "távolsággal" arányosan a szinkron tükrözés durva latency-t tud a rendszerbe bevinni, ami egy windows fájlszervernek nem fáj, de egy oltp adatbázist nem akarsz majd rárakni.

Mellesleg, ha elolvasod a doksiját, látni fogod, hogy nem 2, hanem 3 gép kell a quorum miatt, persze ebből csak 2 az esx, a 3. a vcenter.

A StorMagic nyilván nem arra való, hogy megváltsa a világot minden szempontból, sokkal inkább arra, hogy gazdaságos osztott tárolót biztosítson (gyatrább DRDB-vel nem kevés felhasználót lehet ilyen konfigurációval kiszolgálni). Alapvetően két előnye mindenképpen van:
- tudsz VMotionözni
- működik a VMware HA
- az adataid automatikusan nem egy, hanem két helyen vannak

Azért meg lehet oldani, hogy "kellő" minőségű konzisztenciád legyen két gép esetén is: a vCentert lokális táron hagyod (nem az SvSAN által nyújtott), illetve az SvSAN-ok ne induljanak automatikusan az ESX-szel.

Ez nekem egy picit "l’art pour l’art"-nak tűnik.
Ahol van vCenterre költségvetés, ott nem hiszem el, hogy ne férne bele két olcsóbb iscsi-s appliance (bár itt a mirror kérdéses) vagy 2 rendes gép iscsi tárolóként DRDB-vel. És itt akár még a path is lehet redundáns.

Hát pedig van ilyen... Az Essentials Plus megfizethetőbb kategória (fölötte már nyilván mások a költség arányok).
Ellenben DRBD alapú tároló egyáltalán nem támogatott, ha a legkisebb tároló alapú probléma merülne fel, a VMware szépen széttárná a karját. Akkor már inkább StorMagic, vagy akármelyik más támogatott szoftveres megoldás.

Egyébként egyetértek: mindenképpen "normális" tárolót érdemes használni.

Nyilván, mindössze arra akartam utalni, hogy a virtualizációnak nemcsak nagy rendelkezésre állású (=majdnem minden redundáns) környezetben van létjogosultsága. Azaz (tetszőleges megvalósítású) osztott tároló nélkül is lehet értelme virtualizálni.

Egyébként 5-esben elvileg jön a "host based" replikáció.

ez mind igaz amit írsz, de:
enterprise környezetben ezek mind kellenek, nem csak az FT-hez:
"- mindenképpen kell közös tároló (nem buktató, csak igény)
- nyilván erőforrás igénye is van, de ez nem meglepő
- dedikált hálózat nem árt"

"- nem tudsz pillanatképet csinálni (biztonsági mentés miatt fontos lenne)" - ha vcb nem is megy, a fajlokat még bármelyik mentőszoftverrel le lehet menteni :) snapshot funkcióra meg ott a secondary vm
"- ha esetleg meglévő régebbi hardveren szeretné használni, akkor cpu kompatibilitási probléma lehet" - erre meg oda kell figyelni

btw én csak erre a mondatra válaszul írtam az FT-t: "Persze jó tervezéssel ennek esélye csökkenthető, de pl. a VMWare - legjobb tudomásom szerint - nem képes sofwtare-es tükrözésre, tehát ha egy LUN kiesik a storage hibájából, az minden, azon a LUN-on futó guestet érint."

Bár jobban belegondolva erre jó a VMware vCenter Site Recovery Manager is, és akkor a fenti hiányosságok is kiküszöbölhetőek :) Persze tudom, ehhez meg kell a tartalék vas, meg tartalék vCentert szerver, stb. De megoldható, hogy a másolati példányok másik lunon, másik storageon legyenek

"snapshot funkcióra secondary VM": ezt milyen szoftver kezeli le? (működik egyáltalán éles FT-vel?)
VM szintű mentés azért nem elhanyagolható dolog, könnyebb belőle visszaállni.

"LUN kiesik": az SRM-hez (egyelőre) kell a tároló szintű replikáció, azaz előfeltétel, hogy a LUN azért még létezzen a túloldalon. Arról nem beszélve, hogy az SRM failover nem automatikus, illetve valószínűleg nem arra van bekonfigurálva, hogy egy LUN elzakkanását kezelje le.

Ami segíteni tud (és nem is vészes pénzügyileg): virtuális gép szintű replikáció (pl. Veeam Backup & Replication), ugyanis akár teljesen független tárolóra másolódik a VM. A technológia korlátja, hogy pillanatkép szükséges, de akár folyamatosítható is.

Az SRM lényege, hogy teljes a primary site elhalása esetén is viszonylag hamar újra életképesek legyenek a szerverek a secondary siteon. Persze vannak előfeltételei, de az nem igaz, hogy ahhoz, hogy a secondary siteon elindítsak egy vm-et, ahhoz kellene hogy a túloldalon még meglegyen az eredeti LUN-ja... Ilyen esetben mi értelme lenne SRM-et használni?
Ráadásul produktív rendszerek esetében automatikusra kell állítani a replikációt, pont arra készülve, hogy a teljes primary site elpusztulhat bármikor. Az SRM failovert persze célszerű manualra állítani, hogy pár ping esetleges kiesése a két site közt ne eredményezze azt, hogy a DR siteon is elindulnak ugyanazok a szerverek, mert azt hiszi, hogy a primary lehalt :)

Nyilván nem az eredeti LUN-nak kell meglennie az elsődleges oldalon a DR oldali induláshoz, hanem a replikáltnak a DR oldalon: egy tárolóról számos okból eltűnhet egy LUN (sőt: az "eltűnésnek" is több módja lehet), így az is előfordulhat, hogy a DR oldalról is "hiányzik" már (például a tároló adminja rosszat törölt, valaki becsatolta egy Windows-ba a VMFS-t, ami újra írta a fejlécet, a változás is átment már a túloldalra,...).

A replikáció nyilván automatikus, de maga a failover nem. Tehát amíg a döntéshozó nem mondja azt, hogy failover van, addig nincs failover. Ha 24 órára van szükség döntést hozni azután, hogy felrobbant az adatközpont, akkor 24 óráig nem fut semmi a DR oldalon sem.

Az beállítható egyébként, hogy a "fő" oldalon először álljanak le a VM-ek: például árvíz van, és tuti, hogy 2 óra múlva leáll minden mert addigra úszik az épület/kifogynak a generátorok, ez esetben nem kell kézzel foglalkozni az elsődleges oldal lekapcsolásával.

A lényege valóban ez, de ennél sokkal bonyolultabb.
Valóban kell az "eredeti" lun, de az SRM storage alapú replikáción alapul, az SRM szervernek el is kell érnie a SAN-t, megfelelő privilégiumokkal bíró userrel.
IBMnél Global/Metro mirror kell a DS8k-nál, hogy működjön az egész, de ahogy Attila írta ez adminisztrátor általi lun törlésnél olyan halottnak a csók (erre van backup).
Automatikusan pedig indulhat el, nem ő dönti el, hogy failover kell-e. Nem véletlenül hoz az SRM saját role-t is a vCenterre. Ajánlott külön felhasználó az indításra.

Persze, dedikált hálózat kell managementre, de pluszban az FT loggingra is.
VCB/kliens backup vagy FT, kinek mi kell. El kell dönteni az igényeket.
Ha a lun kiesik a storage hibájából, az mindenképp baj, de nem gondolnám, hogy ez ellen hypervisor szinten kellen tenni. Nálunk például vannak olyan gépek, ahol "guest based mirror" van (pl. win alatt mirror) külön DC-ben és a vmx, vmdk(nem a flat) fileok rendszeres mentése.
SRM nem feltétlen jó erre.

Ha külön VLAN-t vagy VMkernel portot értesz dedikált hálózat alatt, akkor ok, de saját hálókártya, esetleg saját switchre nincs feltétlenül szükség (méretezés kérdése).

A "guest based mirror" természtesen jó megoldás, de a virtualizációnak pont az a lényege, hogy uniformizál számos dolgot VM szinten: meghatározod a VM-ben futó alkalmazásra vonatkozó mindenféle SLA-kat, és az előny ott jön elő, hogy minden hasonló követelményű VM igényeit azonosan tudod kielégíteni (például az FT vagy HA elég jelentősen könnyíti az adminisztrációt).

Természetesen előfordulhat, hogy VM szintű tükrözéssel/redundanciával bizonyos tervezett karbantartásokat nem lehet kiküszöbölni (például frissítés miatti OS vagy alkalmazás újraindítása), ez esetben nyilván szükséges alkalmazás szinten (is) gondoskodni a redundanciáról.

Úgyhogy én azt gondolom, hogy igen, amiről tudunk hipervizor szinten gondoskodni, arról gondoskodjunk (amíg ez nincs meg, lehet olyannal próbálkozni, hogy RAID1 VM-ben: egyik VMDK egyik tárolón, másik VMDK másik tárolón, akár működhet is legalább olyan szinten, hogy minimalizált az adatvesztés esélye, az másik kérdés, hogy pontosan mi fog történni, amikor eltűnik a LUN, főleg ha a .vmx is rajta van)

Adatközpontok közötti tükrözés esetén mindenképpen célszerű lenne arról gondoskodni, hogy az olvasás történjen csak lokálisan történjen (Linux md esetén ez paraméterezhető például?).

Egyébként az is többlet biztonságot nyújt(ana), ha adatközponton belül két különböző táron van a két VMDK (lehetőleg legalább a RAID tömb legyen különböző).

( tompos v | 2011. 05. 04., sze – 11:18 )

Ne azert virtualizalj, mert szokas, hanem akkor, ha szukseg van ra.
Ha adott a feladat, utana tudsz hozza eszkozt valasztani. Vannak virtualizacios eszkozok, amik gyakorlatilag nativan a diszk teljesitmenyet adjak vissza.

Amikor VM-eket futtatsz egymas melett, szerencses esetben a gep kihasznaltsaga noni fog, azaz a csucsok idejen megkapnak X sok eroforrast, amikor alapon futnak, az X-et pedig ugyanaz a hw adja.

Ezen kivul lehet meg elonye a virtualizacionak, pl. a konnyu koltoztethetoseg -> nem a szolgaltatast, hanem az azt kiszolgalo VM-et lesz HA.

Szoval eloszor azt kell eldontened, mi a cel.

tompos

ui.: A diszkek sebessege miert lenne a 10 evvel ezelotti szinten?

a szekvenciális olvasási sebesség nőtt, de az IOPS teljesítmény főként a diszk rpm-jével van összefüggésben, és gyakorlatilag nem nőtt.

a napokban próbáltam egy "hiperkorszerű" WD Black diszket. nem sikerült semmilyen körülmények között 140 IOPS fölé tornázni. utána megfogtam egy 10+ éves 18 gigás SCSI diszket, és lazán 180-200 IOPS-ot hozott.

nem az volt a kérdés, hogy olcsóbb lett-e, hanem hogy gyorsabb lett-e.
olcsóbb lett, gyorsabb gyakorlatilag nem nagyon.
vagy, azonos árból persze építhetsz bazi sokdiszkes RAID-et, és akkor úgy persze gyorsabb...

csak, ha megnézel egy átlag desktop pécét, egy darab diszk van benne. ha megnézel egy tipikus alap szervergépet, mondjuk 2-4 diszk van benne. akkor meg sokat érsz vele, ha létezik a szervergyártónak 24-48 diszkes SAN-ja...

Nem lesz közöttük nagyságrendi különbség.
Egy mai top 15krpm-es sas diszk alig tud többet, mint egy 8-10 évvel ezelőtti scsi verzió (kb. akkor jelentek meg a 15k-s diszkek), a különbség iops-ban szerintem 20%-on belül lesz.

A nagyságrendi különbség egy ssd meg egy forgó vinyó között van, ott iops-ban 2-3 nagyságrend simán tud lenni.

Tokmind1. Egyreszt ne a ket kulonbozo kategoriat hasonlits ossze, masreszt igen, raid-del nagysagrendeket lehet gyorsitani.

Maskor mindig clusterezes-rol van szo, hiszen anelkul nem virtualizacio virtualizacio. Most pedig 1 _db_ desktop hdd-t hasonlitasz ossze 1 _db_ top hdd-vel. Ez fair?

Masreszt pont errol van szo, meg kicsiben csinalva is, plane nagyban nezve.
Amit regen megoldottal 5x2 hdd-vel (mondjuk raid1) 5 gepben, azt most meg tudod oldani ugy, hogy lesz egy 2x5 diszkes raid10-ed es az idoben eltero terhelescsucsok miatt mindegyik kap ebbol mondjuk 2x3-at, vagy ilyesmi.

tompos

( bognarattila | 2011. 05. 04., sze – 11:19 )

Nagyon feladatfüggő, hogy minek mennyi az IOPS igénye.
Én ennyire nem gondolom gyászosnak a helyzetet, akár néhány SATA lemez is bőven elegendő teljesítményt tud nyújtani több VM számára is.
Az sem mindegy, hogy napi ügymeneti terhelést nézel vagy éjszakai mentést, utóbbi esetén majdnem mindegy, hogy az x db GB/TB adat hány VM révén jön össze.

( egeresz | 2011. 05. 04., sze – 11:20 )

a hardver budget 60%-a menjen diszkre. A tobbi cpu, memoria, halozat. Akkor lesz neked jo.
Ez a virtualizaciotol fuggetlen. A virtualizacio egy tool, egy featureset, ami nehany rendszergazdai feladatot egyszerubbe tesz, nehany korabban nem letezo feladatot meg behoz.

( THavoc v | 2011. 05. 04., sze – 11:25 )

A virtualizacio elsodleges elonye nem a sebessegnovekedes (mert az altalaban nincs is) hanem egy csomo mas: hw. jobb kihasznalasa, koltsegcsokkentes, flexibilitas novekedese, konyebb/gyorsabb management, HA/DR, etc.

Mint minden "divat" mogott, a virtualizacio mogott is vannak ervek, csak ahogy sok mas, ez sem egy altalanos mindenre jo megoldas.

"if all you have is a hammer, everything looks like a nail"

( pgyerek | 2011. 05. 04., sze – 11:26 )

Azt se feledjük, hogy virt. gépeket sokkal könnyebb "költöztetni", mert azokat már nem "érdekli" pontosan milyen vas milyen driverrel van alátéve.

Ha az árat nézzük - kevesebb - erős - vas, kisebb villanyszámla, mégis több szerepkört lehet rátolni egy fizikai gépre, amit ráadásul így karbantartani is könnyebb lehet.

Ha pedig egy virt gép megborul az nem tudja magával vinni a többit, tehát üzembiztonság szempontjából sem utolsó szempont a virtualizáció bevezetése.

Hirtelen ennyi jut eszembe de ez még közel sem teljes lista az előnyökről.

Ami a diszk teljesítmény - nyakunkon vannak az SSD-k és SSD kombó diszkek, tömbök pedig eddig is voltak...

( uid_194 | 2011. 05. 04., sze – 11:32 )

Nekem megeri, mert egy vasam van, es azon kulonbozo OS-eket szeretnek futtatni, azon okbol kifolyolag, hogy a kodomat azokon is tesztelni akarom.

Nincs az a $DEITY, hogy folyamatosan keresztul-kasul bootolgassak, plane, hogy a tesztrendszerem eleve 3+ gepet igenyel (vagy baromi nagy hackolast, amire nem vagyok kaphato). Virtualizacioval tok jol elfut egymas mellett a Debianom, egy FreeBSD meg egy OpenIndiana, tobbek kozt.

Disk sebesseg nem erdekel jelen esetben, nem az a szuk keresztmetszetem.

--
|8]

( zolpet | 2011. 05. 04., sze – 11:55 )

A legolcsóbb megoldás, hogy minden gépnek adsz egy fizikai diszket, és akkor nincs az, hogy felzabálják egymás elől a lemezt. Sosem teszteltem, de ha nem virtuális hanem fizikai diszkként teszed a VM alá, akkor szerintem közel natív sebessége kéne legyen.

1. Nem hiszem, hogy lett volna szó enterprise környezetről.
2. A hozzászólásom úgy kezdődik, hogy a legolcsóbb megoldás annak elkerülésére, hogy megegyék egymás elől a a lemezt. Ha már itt tartunk, szerinted mi a legolcsóbb megoldás erre?
3. Nyilván az optimális kialakítás függ a virtuális gépek lemezhasználatának mikéntjétől, és attól, hogy mi a cél.

1. Hat az otthoni virtualizalgatast keverni egy eles rendszerel hulyeseg de hajra. Viszont Oregonnak sajat cege van mar parszor kiemelte.
2. Te virtualiztal mar eletedben? Tudod vannak olyan szo,hogy tervezes. Ez ilyen virtualbox rules.
3. Igen na most nem a virtualis gepet igazitjuk a felhasznalashoz hanem az alkalmazast a ketto tok mas.
--
1 leszel vagy 0 élő vagy hulla!

( Helios | 2011. 05. 04., sze – 13:16 )

Akár performancia javulást is elérhetsz:
- a virtuális gép egy (vagy több) nagyobb fájlból áll, ami (ideális esetben) nincs fragmentálva. Ez kevesebb és kisebb fejmozgást eredményez.
- a futtató környezet is tud akár javulást hozni: más/több cache illetve jobb I/O policy. (Pl. találkoztam olyan SQL szerverrel, aminek VmWare környezetben javult a performanciája, pedig előtte sem gagyi HW szolgált alatta.)

schedulingolni, szep szo:)

Jobban tudja minel?
Van egy geped, azon van egy OS1, egy virtualizacios sw, majd abban egy OS2, es abban az alkalmazas. Ez jobban fut, mintha az az OS1-et es a virtualizacios sw-t kihagyod, nativan rakod az OS2-t a gepre.

Kapjon mondjuk az OS1 1 magot es 5% memoriat, a tobbit mind a VM kapja.
Azt mondod, az elso esetben gyorsabb lesz, mint az elso esetben, jol ertem? Szerinted ez igy akkor nincs elszurva?

Vagy tekintve a masik lehetoseget, azt mondja, egy file van, az defragmentalt a fragmentalt original rendszerhez kepest. Akkor nincs elszurva ott, hogy az original rendszer fragmentalt? Vagy ha (tegyuk fel) ez nem elkerulheto, akkor a VM-en belul miert nem lesz ugyanugy fragmentalt?

Nehogy mar a fika egye az ovodast.

tompos

Ezek a rendszerek egy hangyányit bonyolultabbak annál, mint hogy 5 sorban bizonyítsd azt, hogy minden esetben lassabb a VM.

Az XP pl. egy 10 éves technológia, toldozott-foldozott rendszer, aminek rohadtul nincs köze a mai hardverekhez. Egy tisztességes host oprendszer valószínűleg sokszor hatékonyabban lekezeli a hardvert, mint az XP tenné, az meg jól elvan magának a virtuálisan neki kitalált környezetben.

miert futna jobban? azokon a procikon, amik tamogatjak a hw virtualizaciot, szinte nincs koltsege.

ezt az OS1, OS2 baromsagot nem is ertem: hypervisorrol volt szo, ezt en (es senki mas sem) szokta OSnek hivni. az nem kap X% ramot, meg magot, hanem felugyel mindent.

lattal te mar kozelrol ilyen rendszert?

én a host IO cache-re gyanakszom.

Én meg egészen pontosan a write-back cache használatára tippelnék. Amivel egyébként csak 1 "apró" probléma van: az adatkonzisztencia garanciáját áldozza be az ember a sebességért, de ez ugye csak egy host crash esetén jön majd elő, az meg ritkán van, és akkor is ráfogják majd a nyuszira. Persze addig meg jön a duma, hogy mennyivel gyorsabb a virtualizált cucc... Hát persze.

( hawk | 2011. 05. 05., cs – 15:25 )

A kezdetekben:
Vala ~8 Linux + 1-2 Windows szerver. Mind más célra és teljesen más szoftver környezetben.
Kihasználtságuk alulról nyaldosta a 20%-ot. Ritka esetben persze meg voltak terhelve.
(A gépek persze nem voltak izom vasak de a fogyasztásuk így is 120-150W/gép)

Most:
2 db izmosabb vassal elvirtualizálgatjuk ezt a 8 linuxos vasat és még jópárat, ami közben jött be.
Igen a gép fogyasztása is igazodott ehhez. (200-400W terheléstől függően)

Számoljunk csak?
Régi: 10*(150-200W) = 1500-2000W
Mostani: 2*(200-300W) = 400-800W

És akkor nem beszéltünk még a clusterről meg a többi előnyről, amit ez az egész hozott.

Egyszóval szerintem NEM éri meg! :D :D :D

Es akkor mar arrol ne is beszeljunk, hogy az enterprise-ready rendszerek (vSphere) tudnak olyat hogy merik a szerverek/VM-ek kihasznaltsagat, es ha egy szint ala esik (mondjuk este munkaido utan) akkor elkezdi egyre kevesebb vasra migralni (transzparensen) a VM-eket, es a nem hasznalt vasakat kikapcsolja, majd reggel ugyanezt visszafele, terhelesfuggoen.

Bőven bejön az áramon, ehehe.

De egyébként ez csak attól függ, hogy mennyire hullámzó a terhelés. Pl. a tokiói metró/vasút beléptetőrendszere valószínűleg picit jobban meg van hajtva reggel 6-7-kor és este tízkor mint pl. hajnali háromkor, amikor csak a macskák mászkálnak az állomáson.

Ekkor az áram+légkondi vagy inkább az, hogy nem kell új vasat venni, mert ilyenkor meg ráterhelnek "ráérős" jobokat az amúgy unatkozó gépekre már jelentős megtakarítást hozhat.

De itthonra nem kéne :D

A socket szám/server majdnem mindegy, a kérdés inkább az, hogy mekkora a terhelés, amikor leesik: hány szerver erőforrás igényére nincs már szükség. Ilyen szempontból több 2 socketes szerver esetén nagyobb esély van arra, hogy legalább 1 erőforrása teljesen felszabadul.

Egyébként kis szerver számnál gazdaságosabb kevesebb socketest venni pont a redundancia miatt: ha van 2db 4 socketes szervered, akkor pont 1db 4 socketes szervered van tartaléknak (4 socket használható erőforrásod van). Ellenben 3x 2socket esetén szintén 4 socket erőforrásod van (1 esx kiesését feltételezve), de csak 2 socket van tartalékként. Jó esély van rá, hogy a 3x2 olcsóbb, mint a 2x4 (nyilván megfelelő RAM stb aránnyal).

Ha Datacenter licenc van, akkor mindegy hány Windows (Server) fut.

( PtY | 2013. 10. 20., v – 14:08 )

Ne használj lokális diket a virtualizált szerverekhez, hanem NAS-t vagy SAN-t, így a virtualhoston jelentősen csökkentheted az IO terhelést a CPU-n.
--
PtY - www.onlinedemo.hu

Lehet. Én azt látom, hogy tárolórendszerek vannak, meg szerverek. De lehet, hogy a múltban élek, és nem feltétlenül hiszem azt, hogy amit a vmware mond, az a jövő.
Sokan próbáltak már nostradamust játszani az informatikában, de az élet sokszor rájuk cáfolt, ezért inkább maradnék szkeptikus :)
--
PtY - www.onlinedemo.hu

Ez ebben a formában nem teljesen igaz!
Van jópár rendszerem ahol _normális_ (sas 10-15k rpm) lokális diskek vannak _normális_ raid kártyával, és ha hiszed ha nem, nincs vele semmi gond, pedig ráadásul drbd is van a képben.
Lehet hogy bizonyos eseteben rommá terhelődik a rendszer ha lokális diskek vannak, de ez egyáltalán nem egyértelmű tény, sőt...

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Igaz, nem akartam általánosítani, de úgy sikerült.
Sajnos azonban a brand kategóriájú cuccokban is egyre ritkábban találni rendes raid vezérlőt. Igaz, ez is csak azért van, mert minek tegyenek bele gyárilag olyan minőséget, ha az esetek nagy részében valami külső tárolóra lesz rápattintva a vas?
--
PtY - www.onlinedemo.hu

Megfontoltan kell vásárolni, gombért kapni p400-as kártyát, ami a legtöb igényt bőven kielégíti, és nem szoktak csak úgy meghalni sem.
De én azt veszem észre inkább, hogy ha a controller nomrális is, simán belerakják a jó kis wd green diskeket, onnantól kezdve meg tökmindegy.. :)
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

A disk és a kontroller általában együtt jön a brand gépekkel, bár ha az ember külön vásárol, akkor nem - ez igaz.
A disknek olyannak kell lennie, mint szoftvernek: igények alapján kell választani a megfelelőt ár/érték alapján.
Ha csak az ár számít, és az igény/érték figyelmen kívül marad, akkor meg lesz az eredménye - annak ellenére, hogy sok helyen semmi baj a green diskekkel.
--
PtY - www.onlinedemo.hu