Egy nagy vas, vagy több kicsi?

Virtualizáció

Sziasztok,

Szeretnék véleményt kérni arra, hogy több relatív kis gépet egy nagy, vagy több kis gépen volna-e érdemes virtualizálni.

Pontosabban, mondjuk
1db HP DL380g8, 2 fizikai CPU (sok mag) sok RAM, SAS lemezek, etc
vagy
1db ASUS twinblade
ebből van kicsi (single cpu) vagy nagy (akár dual E-series Xeon).
1db 2U házba 4db "blade"-et lehet rakni, blade-enként 3 lemezzel, ami lehet SATA v (külön vezérlővel) SAS.

mindkét esetben több mag lenne, mint amennyit elhasználnánk.
Főképp redundancia és teljesítmény miatt érdekelne a dolog. Ugye az Asus megoldás önmagában lehetne
redundáns, a HP-ból kéne mégegy...

vagy rosszul gondolom?

(paravirt lenne, valószínűleg 1 v 2 gép lenne ami több magot kapna, a többiek akár osztozhatnak a maradékon)

Köszi a tippeket :-)

  • 10882 megtekintés

( Dacr (nem ellenőrzött) | 2013. 07. 25., cs – 18:33 )

Ha redundancia, akkor az egy vasas megoldás már eleve nem teljesíti ezt a kritériumot.

( djsmiley v | 2013. 07. 25., cs – 21:22 )

s/Asus/Supermicro amire gondolsz szerintem.

Egyébként egyértelmű h. twinblade, mondjuk proxmox-al. N+1 node kell legalább ha "magas rendelkezésre állást" akarsz. Persze ha clusterelsz akkor N>=3.

Ha a Replica ficsörre gondolsz, akkor azt nem ajánlanám, ha nem MS gyártmányú SQL szerver fut a gépen. Ebben az esetben inkább alkalmazás szinten kell megoldani a redundanciát. Ha viszont a Shared-Nothing migrációra, akkor az pedig értelemszerűen azt feltételezi, hogy a költözéskor az eredeti host még működik. (Nem pedig kihúztad alóla a 220-at.) Ha meg a Scale-Out fileszerverre (ami egyébként jó lenne), azt sajnos nem tartalmazza a Hyper-V 3.

A kérdezőnek: össz-vissz két db hosttal nem tudsz normális failover clustert csinálni, a split-brain probléma miatt. Legalább 3 kell.

http://www.supermicro.com/products/nfo/Twin.cfm

Ez nem 8-12, csak 2-4-6 node.
Uresen nem veheted meg, csak akkor, ha az azt jelenti, h nincs benne CPU, RAM, HDD.

Miert, az Asus-t meg tudod venni, uresen, alaplapok nelkul, lenyegeben csak a hazat?
Annak mi ertelme van?

A 8-12 node-os termeket MicroCloud-nak hivjak:
http://www.supermicro.com/products/nfo/microcloud.cfm

tompos

Igen, az Asus-t elvileg meg lehet venni ház+1 "blade" szettben is.
Annyi értelme van, hogy 2 táppal, 2 lappal nem sokkal drágább mint 2x1U nemredundáns
vas, és IP-KVM-től kezdve minden van benne. (persze, CPU és RAM nélkül vehető ez is)

Ezzel nem azt akarom mondani,h jobb, mint a SuperMicro, de indulásból lehet, h olcsóbb.

Tobbszor elolvastam, de nem tudom ertelmezni a leveled.

Mi az a nemredundans vas? Vagy epp milyen a redundans?

> CPU es RAM nelkul veheto

Most akkor meg lehet venni 1 node-dal vagy nem? Vagy miert lenyeges ez?

> lehet, h olcsóbb

Persze, h olcsobb, mivel az Asus (gondolom) olcsobb, mint az SM, fuggetlen attol, h blade v. nem.

tompos

Szóval, az ASUS twinblade, 2 blade-el (a 4ből) nem sokkal többe fáj, mint egy barebone server amiben nincsen 2 táp. (esetleg IP KVM se)

Ebben pedig a táp redundáns, talán a hűtés is.

Tulajdonképpen jelen állításnak az lett volna a lényege, hogy a twinblade setup (akár Asus, akár SuperMicro) két blade-el nem kerül sokkal többe, mint azonos gyártótól megvásárolt 1U barebone server.
Cserébe előbbi konfigurációban van redundáns táp, és IP KVM (ill. bővítési lehetőség) utóbbiban nincs.
Azaz 2 node esetén picit drágább, 4 node esetén már olcsóbb.

> Tulajdonképpen jelen állításnak az lett volna a lényege, hogy a twinblade setup (akár Asus, akár SuperMicro) két blade-el nem kerül sokkal többe, mint azonos gyártótól megvásárolt 1U barebone server.

Igy mar erthetobb

> Cserébe előbbi konfigurációban van redundáns táp, és IP KVM (ill. bővítési lehetőség) utóbbiban nincs.

SM-nel szerintem mar talan nem is lehet IPMI nelkul gepet venni.
Viszont HDD 3 megy bele, az 1U-os 4-gyel szemben.

t

( errotan v | 2013. 07. 27., szo – 14:40 )

Ezekbe a "blade"-s szerverekbe nekem csak az nem tetszik, hogy egy darab redundáns tápon osztoznak az egységek. Ha például zárlatos lesz az egyik blade, akkor magával ránthatja a tápokat és így a többi egység nem tud menni. Gondolom ilyen ellen van mindenféle védelem és csak én vagyok ennyire paranoriás :D

( bazso | 2013. 07. 27., szo – 22:06 )

Elvonatkoztatva a fenti konfigoktól, generálisan:
Ha kevesebb nagy gépet használsz, akkor több erőforrás esik ki egy gép kiesésekor, ez vastag vas esetén akár 200 virtuális gép költöztetgetését is jelentheti. Viszont pozitívum, hogy kisebb az erőforrás fragmentáció (ugye ha van X nagyságú géped, akkor 2/5-öd X méretű virtuális gépből elfér rajta 2, és 1/5-öd erőforrás ment pocsékba. Ha 3X nagyságú géped van, akkor elfér 7 db, és ugyanúgy 1/5-öd X marad ki, ami a gép méretéhez képest nézve 1/15-öd, azaz a veszteség százalékos arányban jóval kisebb)

Személy szerint már billegek. Régen a nagyvasakat preferáltam, de a blade-ek teljesítménye is akkora lett, hogy a "nagyvas" már irreálisan nagy, így nagyon sok mindenre elég 2 node, ami meg 50% kiesést jelent egy patch vagy hw error esetén. A gépméretet én nagyjából oda lőném be, hogy minimum 3 node összejöjjön klaszterenként, de elég nagyok legyenek a node-ok az átlagos virtuális gép méretéhez képest, azaz nem is apróznám el. Ha 10 virtuális gép alatt fér el egy szerveren, akkor az nagyon kicsi, ha 100 fölött, akkor meg túl nagy (és úgyis kinyírja a performanciát a context switch függetlenül attól mekkora proc és mem van benne)

Ha szerencséd van, akkor sokszáznál sem lesz, ilyen pl a VDI, ahol azonos windows-ok esetén egyszer kerül a bináris a memóriába, és vm-enként csak a pointerrel játszik a vmware. De egy nagyon vegyes környezetben (win,lin,32/64 bit, sokféle alkalmazásprofil) esetleg megspékelve sokszálas kiszolgálókkal mint webszerver és sok kapcsolatos db szerver, ott már alacsonyabb számnál gond lesz. Megjelenik az I/O wait-ben a hálózatra várás, a sw interrupt-ra várás 0-nál nagyobb lesz,és még egy login ablakra is hosszú ideig kell várni úgy, hogy közben látszólag a cpu, mem, diszk terhelések mind 80% alatt vannak. Ugyanaz a dl580g7 bírt röhögve 200 vm-et, mint ami csuklott már 80-nál is. Az hogy neked mennyi megy,az csak és kizárólag az adott környezetre mérvadó.

Lehet ezt még ragozni. Két node esetén egyértelmű, hogy 100%-al felül kell tervezni, ennyi erőforrás (ram,i/o,cpu) a "pocsék".
Több tagú fürt esetén viszont el lehet gondolkozni rajta, összesen hány node kiesését engedem meg. Arra célzok, hogy ha egy 10 tagú clusterben 3 node kiesésére tervezek, ott akkor kb. 25%-al kell felültervezni mind a 10 vasat. A végső költség pedig megközelítheti ugyanazt a nagyságrendet, mint az első esetben.
20 tagú cluster esetén ugyanez a szám már csak ~6%. Ez már annyira kicsi, hogy gyakorlatilag nem is kell a méretezésnél figyelembe venni. YMMV