Aktív fórumtémák
Friss hozzászólások
- Szia! Nekem van élesben Xen
4 hét 4 nap - Ez viszont alátámasztja azt,
5 hét 1 nap - Ha támogatja az OS a
5 hét 1 nap - Még abba szeretném a
5 hét 1 nap - Bár 1 darab gépnél mindegy,
5 hét 2 nap - Ha egy mód van rá ne NFS-en
5 hét 2 nap - Az NFS nagyobb terhelés
5 hét 2 nap - CentOS lesz az oprendeszer
5 hét 2 nap - És mi lesz az oprendszer?
5 hét 2 nap - A kérdés nagyon jó! Ez sem
5 hét 2 nap
Szavazás
Milyen előadások érdekelnének?
Szerver virtualizáció
79%
Kliens virtualizáció
0%
Desktop virtualizáció
12%
Tárolók (storage)
6%
Vékonykliensek
3%
Mást, leírom a hozzászólásokban
0%
Összes szavazat: 34
Online felhasználók
Jelenleg 0 felhasználó és 1 vendég van a webhelyen.
XEN és a cluster
pit, 2010, június 25 - 10:18 Tag: XenÉrdemes össze clusterezni XEN en futtatott virtuális gépeket ? Van valakinek erről tapasztalata ?
- A hozzászóláshoz regisztráció és belépés szükséges
Copyright 2010 v-day.hu
Ahol eddig láttam XEN
Ahol eddig láttam XEN clustert, mindenhol drbd + heartbeat-el oldották meg a dolgot.
Ha fontos a magas rendelkezésre állás számodra, akkor nyilvánvalóan mindenképpen szükséges HA rendszert használnod.
Ellenben ugye van már jól működő supported Live Migration is a 4.0-tól ami hasznos tud lenni ha észleli időben az ember hogy halódik a host vas, és akkor gyorsan kiesésmentesen költöztet egyet.
De ugye ez nem 101% biztonságot nyújt, jól tudjuk hogy a vasak akkor szeretnek meghalni amikor nyaralunk valahol... :(
Szia! A virtualis gepeket nem
Szia!
A virtualis gepeket nem erdemes clusterezni, hanem az alattuk futo fizika kiszolgalokat. De azt viszont erdemes.
Oks akkor úgy értem hogy
Oks akkor úgy értem hogy lenne mondjuk egy vas 8 proc tételezzük fel SLES fut rajta
ezen belül létrehozni 4 db host ot és mindegyiken futna web, pop stb a fő rendszeren
ldirectord vel osztani szét a webet pop ot stb.
fő rendszer IP je kifele látszik a virt szerverek ip-je helyi csak a fő IP látszik kintről és ez osztaná szét a terhelést természetesen saját magán.
A kérdés ez hozza ki jobban a teljesítményét vagy ha nem virtualizálok alatta semmit csak 1 web fut 1 pop stb. /természetesen ha szolgáltatás kihal akkor az azonnal kiesés nem tud máshova osztani/
Természetesen ez nem igazán cluster ez csak load balancing.
ez csak elaprozza az
ez csak elaprozza az eroforrasokat. igy inkabb csak lassabb lesz a szolgaltatas, vagy nem valtozik a sebessege, de gyorsabb nem lesz. persze ez alol van kivetel, de naaagyoon ritka.
ezt inkabb ugy kellene
ezt inkabb ugy kellene megoldani, hogy az egyes szolgaltatasokat kellene kulon VM-re tenni, egy web, egy pop, stb. Igy kicsit biztonsagosabb lehet a rendszer, pl egy apache bugot kihasznalva nem lehetne egybol hozzaferni a masik VM-en futo pop kiszolgalo levleleihez.
Terheleselosztasra akkor van szukseg, hogyha az alkalmazas nem tudja a rendelkezesre allo fizikai eroforrasokat egyszerre kihasznalni. Ez ket esetben lehet igy, ha sok proci van egy fizikai kiszolgaloban es olyan szolgaltatast futtatsz, ami nem tamogatja a multiprocesszoros kornyezetet (ma mar keves ilyen van). A masik hogyha tobb fizikai kiszolgalod van, ilyenkor ertelemszeruen nem tudsz egy processzt futtatni tobb gepen.
Hogyha a terheleselosztast akarod tesztelni, akkor ez igy jo, de eles kornyezetbe inkabb ne. Nagyon bonyolult lesz a rendszer es nem kapsz nagyobb teljesitmenyt sem. Szoval keves elonnyel jar.
Akkor ha jól értelmezem a
Akkor ha jól értelmezem a hozzászólásokat, a rendelkezésreállásom növekszik, a rendszerem bonyolultsága nő, de a teljesítményem elvileg nem lesz rosszabb tőle.
hogyha számítasz szoftveres
hogyha számítasz szoftveres hibákra, vagy ha a frissítés ideje alatti szolgáltatáskiesésre gondolsz, akkor a rendelkezésreállás növekszik hogyha több VM-en osztod el a terhelést.
ezekben a rendszerekben a szűk keresztmetszed a lemez sebessége és a memórai mérete. a lemezek sebessége radikálisan tud csökkenni párhuzamos írás/olvasás során. hogyha minden vm-nek tudsz dedikálni lemezeket, akkor nem lesz teljesítménycsökkenés, de hogyha kevés számú lemezed van, akkor a lemezek sebeesége lesz a szűk keresztmetszet.
egyébként úgy van, ahogy mondod. a teljesítmény nem lesz rosszabb.
+ érdemes hosszútávon valami
+ érdemes hosszútávon valami iSCSI történetbe befektetni szerintem, ha az ember vált egy supported dologra,akkor az iscsi elengedhetetlen lesz.
hogyha a vasban van pl 8x147G
hogyha a vasban van pl 8x147G scsi, vagy sas disk, akkor meg raer. egyebkent meg kell gondolni a nagyobb teljesitmenyu kulso storage bevezeteset. ami persze draga, de ugy mar lehet ket fizikai kiszolgaloval clustert epiteni :)
az iscsi-val az a baj, hogy ha 2x1GBit-nel nagyobb sebesseget akarsz kicsikarni belole, akkor az mar tipikusan nagyon draga szokott lenni. de ha ez eleg, akkor az azert jo, mert olcso.
Ezt nem teljesen értem, miért
Ezt nem teljesen értem, miért lenne drága a 2x1GBit sebességnél nagyobb teljesítmény kicsiholása?
mert a 10Gb-es kártya meg
mert a 10Gb-es kártya meg minden hozzá horror áron van :)
Ez igaz, de ott van a
Ez igaz, de ott van a interface bonding, bár nem mindig jó megoldás. Vagy a fcoe, bár az még drágább mint a 10Gb-es kártya. ;) Szóval igazad van. Amúgy szerintem 1Gb-es iSCSI-n is elég jól elszaladnak a vm-ek, persze nem végtelen.
ami megoldás szerintem ilyen
ami megoldás szerintem ilyen helyzetben, hogy minden VM kap egy dedikált Gb-es kártyát.
Igazán extrém eset ahol 1Gb nem elég, de a storage még bírná.
az is nagyon draga. inkabb
az is nagyon draga. inkabb fel kell merni, hogy milyen workloadokat lehet egy ilyen kornyezetben futtatni, es azokat, amiknek nagyobb a disk io szukseglete a rendelkezesre allonal, azt fizikai kiszolgalon futtatni, vagy dragabb kornyezetbe mozgatni.
hogyha minden VM-hez dedikalsz egy kartyat, akkor a rugalmassagot veszited el. pl nem tudsz egy tesztkornyezetet letrehozni egyik naprol a masikra, vagy uj VM eseten hardvert kell bovitened, stb.