Sok virtuális gép - mi a szűk hw keresztmetszet, mire érdemes figyelni?

Fórumok

Több virtuális gép kellene fusson folyamatosan és gördülékenyen
(1-2 XP, Debian X nélkül, Ubuntu, Win7)

Azoktól kérdezném, akik napi szinten több virtuális gépet használnak, hogy mire kell odafigyelni legjobban, mi a szűk keresztmetszet az alábbiakból és milyen sorrendben?
- háttértár (SSD, 10k rpm, vagy raid 10? Melyik a jobb?)
- memória mennyisége
- processzormagok száma
- processzor sebessége

Hozzászólások

Az OS egy dolog, minek kell futnia az OS-ben? A futó alkalmazás mit csinál? Ha bind9-et akarsz tesztelni, az merőben más, mintha mysql-t vagy abaqus-t.

Nekem LAMP-nál a memória kisebb gond, mint ahogy véltem, mondjuk egyelőre még pici a db, nincs benne 100.000 rekord se. Viszont a php5 érezhetően jobban harap fizikai gépen, virtualizáció nélkül, ám a teljes alkalmazás teljesíményén (kattintás, feldolgozás, letöltés, a böngésző rendereli a lapot) nem sokat fog vissza. Nálam a quad phenom 8G-rammal elvisz 5 gépet, amiből ált. 1 aki dolgozik, és az idő kb. 50%-ben nem pörög kettőnél több, azaz három futó gép csak vár, hogy mikor lesz dolga, és egy mirroron laknak. Amikor kihajtom az összes gépet (egyszerre 20 ember, vagy 4 szálon támad), akkor viszont cpulimites lesz a rencer, a php5 miatt.

Kolléga jól mondja.

Az adatbázisban való matatás a háttértárakat erősen használja, így idővel az lehet a szűk keresztmetszet. Raid5-nél biztosan lesznek problémák, a raid 10 már jobb, de ugye ott a fizikai méret fele használható - mindez 15000 rpm-es vinyókkal.
SSDvel kapcsolatban nincs tapasztalatom.

Memória úgy gondolom manapság már nem szabad, hogy szűk keresztmetszet legyen.

A CPU-t pedig a feladathoz kell méretezni.

PHPAdmin - Egyedi felületek készítése

Tapasztalatom szerint a disk.
Néhány hónapja használok vmware clustert, a háttértár 8 db 300 GB-os SAS RAID5-be.
10 server fut rajta (terminálok, file, mail, stb) a napi működés során nem tapasztalok szűk keresztmetszetet, de snapshot, backup készítése közben érezhetően lassabb a rendszer.
Lehet nem a legszerencsésebb választás volt a RAID5, fontolgatom a váltást....

Mi xSeries 3500 -as gépekre (Quad Core Xeon, 8GB RAM, RAID-5: 6x143GB SAS 15k rpm HDD) bíztuk a virtualizációt. Általában Windows Server 2003 guest -ek futnak rajtuk MS-SQL 2005 -el, igen nagy terhelést kiszolgálva. A szűk keresztmetszetet a RAM kiosztása jelentette a tapasztalatok szerint. 4-5 db guest részére is ki volt osztva 3-4 GB RAM (egy fizikai vason, tehát a valós 8 GB -nál több), ami az első időkben nem jelentett gondot, később azonban (ahogy egyre kihasználtabbak lettek a masinák), egyre jobban swap -pelniük kellett, belassultak. Most a guest -ek max. 2 GB -ot kapnak, így már jó. Az egyik gépen virtualizálva fut egy Suse Enterprise 10 guest is, kb. 1100 felhasználó részére fájlszerver és Novell eDirectory kiszolgáló, teljesen jó. :)

Ha valakinek a processzor/ram lenne a szűk keresztmetszet, annak ajánlom az IBM System x3950 M2 -es szerverét. Az x86os kategoria jelenlegi csúcsát. A szerver maga max kiépítésben 4 darab 4 unit-os "dobozbol" áll. Maximum kiépítésben 16 Intel® Xeon® 7400 six-core processor (16x6=96 core) és 1 TB ram. :-)

első blikkre a diszk lesz a szűk, nálunk a legtöbb esetben minden vason 4 guest fut, a redhat licenszelése miatt (így egy licensz vásárlásával 4 virt gépet lehet használni), szóval a tapasztalataim szerint a szerverek 90% erősen túl van méretezve :-)

de van olyan alkalmazásunk, aminek mindegy, hogy 1, vagy 10GB ramot kap, hogy SAN-FC diszkrendszer van alatt, akkor is fos sebességet produkál 10-20 egyidejű user nyúzása alatt, egyszerűen szar a szoftver, és balfaszok a fejlesztők :-(

valamint arra törekszünk, hogy önálló (virtuális) gépekre kerüljenek a szolgáltatások, pl: MySQL, apache, tomcat, Lotus, mail-gateway, SPAM-szűrő, file server, AD/DC/DNS, printsrv, stb

--
by Mikul@s

Csak tipp, de nekem is I/O-oldalról tűnik leginkább cinkesnek a dolog, azon belül is a diszkek teljesítménye az, amire oda kell figyelni. Ennek elkerülésére sok, relative apró diszkből csinálnék normális vezérlővel RAID10-es tömböket, és ha lehet, akkor natívan osztanám a diszket (nem diszkimage-ként).
És persze a szükséges memóriát is bele kell pakolni/hozzá kell rendelni az egyes guestekhez, hogy a swap használatára minél kevesebbet kerüljön sor.

Igen es nem.
Igen, az lett volna a kerdes, hogy miert jo, ha minden funkciot szeparalunk, es nem, amennyiben a kerdes arra vonatkozott volna, hogy virtualizacios szempontbol van-e ennek valami elonye.

Mindenesetre a valasz igy is megerkezett, de ezzel en is tisztaba voltam. Ezek szerint akkor virtualizacios szempontbol (e.g. terheleselosztas, skalazodas, etc.) nincs relevanciaja ennek.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Bare-metal hypervisort használnál (VMware), vagy valamilyen hostolt megoldást (XEN, Hyper-V)?
A kettő között elég rendes I/O teljesítménybeli különbség lehet az előbbi javára.

Nálunk jelenleg van két dom0 amiket fut az egyiken 19 másikon 17 virtuális gép, ezek nagy része linux, van 1-2 windows mindkettőn de a fizikai vas nem nagyon erőlködik.

CoreDuo L2400, 4G, Ubuntu 9.10, 2.6.31

Szinte minden felmerült már, a lényeg hogy a saját cuccodon kell best practice, másé nem jó. Általános (a mienk már jó statisztikai alapnak, két node-os esx klaszter 85 nagyon változatos guest dl580 4db quadcore 128GB ram) esetben a sorrend:
Diszk: egy lun-on ne legyen 16 guest-nél több, így is széttöredezi, olyan storage kell ami random I/O-ban extrém jó. Durvább a random terhelése mint egy elcseszett adatbázisnak.
Memória: virtuálisan kioszthatsz többet mint ami van, de ha egyszer valaki tényleg kihasználja, másodpercek alatt térdel le az egész.
Proci: ha egynél több virtuális cpu-t adsz egy gépnek, akkor az csak akkor futhat, ha annyi core egyszerre szabad. Ha sok core van, nem gond, de ha mondjuk 4 core van összesen és van egy rakás 1-2 core-os guest-ed, röhej, de a többmagosak lesznek a lassabbak, mert ritkábban jutnak procihoz.

Üdv,
BaZso