Klasické servery, nebo Blade?

28.11.2013 00:17 | Přečteno: 3799× | plky | poslední úprava: 28.11.2013 00:17

Přichází čas na velká rozhodnutí, začíná to být zajímavé.

Klasické servery, nebo Blade?

Pomalu se připravujeme na virtualizaci desktopů. Bude se jednat o cca 120 stanic s možným dalším nárůstem. Požadavky jsou :

• Virtualizace Desktopů
• Virtualizace aplikací
• Řešení s nejlepšími latencemi a režijí na síť
• Všechny přístupy/činnosti logovat
• Dynamické přiřazování zdrojů / automatické vypínání/zapínání vm
• Čistě jen virtualizace Windows + Office + pramálo programů okolo
• Podpora ze strany tenkých klientů
• Podpora více monitorů na straně klienta + podpora tisku, usb a dalších věcí
• Výpadky se nepřipouští, takže něco, co půjde upgradovat bez výpadků

V současné době se teď dělají tři průzkumy.

1) Hypervisor

První otázky jsou, jaký hypervisor budeme používat. V současné době používáme ESXi Free, takže buď dokoupit licence, nebo přejít na XenServer (osobně preferuji), který je přecijen otevřenější. O kvm nemá zatím cenu přemýšlet, zatím není tak protlačeno do enterprise sfér z hlediska oficiální podpory sw produktů. Jednoduše řečeno, když budeme chtít na kvm něco provozovat, tak na to "něco" nedostaneme support (největší support je pro provoz na vmware, s ním počítají snad všichni, někdo pak počítá s Xenem, někdo s HyperV a hodně vzádu je kvm :-/). Tomuto bodu se ale budeme věnovat jindy.

2) Jakou virtualizaci desktopů?

Tak v současné době se nabízejí dvě řešení, které jsou na špici. Jedno je od VMWare (VMware Horizon View/ThinkApp), druhé je Citrix (XenDesktop/XenApp). Ano, také by se mi líbil RedHat a Spice, ale ten má ještě co dohánět. Mám rád otevřená řešení, ale také vím, jaké jsou naše požadavky a ty jsou značně náročné :-/. I toto však bude předmětem jiného blogu (už mám naškrábaný celkem dlouhý soupis fcí, pro, proti, co je k čemu potřeba atd.).

3) Blade?

A je to tady. Naše firma jede HP only. Co jsem si dělal průzkum, tak by 120 desktopů zvládly dva nody, které by dělaly HP DL 560 Gen8. Jsou to čtyř socket servery (8 core CPU/socket se zdá být jako dobrý nápad). Každý by měl přiměřený počet 16GiB RDIMM modulů (32GiB varinaty se nedělají v 1600MHz a také jsou neúměrně dražší). Dále by v sobě měly malé RAID1 pole pro hypervisor. Oba servery by pak měly společné pole, kde by byly VM. Přes noc by provoz utáhl jeden server, takže by nebyl problém s upgradem jednotlivých nodů. Pokud by výkon nestačil, není problém přidat další server jako třetí nod. Zde se ovšem nabízí otázka, zda nesáhnout po Blade řešení? Rád bych se zde zeptal, zda s tím někdo nemá zkušenosti a zda nepočítal, v jakých případech se již takové řešení vyplatí? Jinak pokud jde o napájení, tak to u nás v případě Blade řešení není problém. Možná by šel Blade využít k virtualizaci i pár dalších serverů (vesměs menších, nenáročných, nic, co by vyžadovalo víc, jak 2 DL 560 Gen8). Samozřejmostí je myslet i na případný další růst. Počítám však, že přes tři DL 560 Gen8 bychom se asi nedostali. Reálně se tedy nabízí otázka 3x procesorově plně osazený DL 560Gen8 vs. Blade.

Závěr

Veškerá řešení zde budu popisovat a vysvětlovat, proč jsme se tak, či onak rozhodli. Doufám, že diskuse bude přínosná a najdou se jedinci s reálnými zkušenostmi. V současné době mám za sebou půldenní konferenci o Citrixu a celkem pěknou sumu přečtených článků na netu. Taktéž mám v ruce i nějaké cenové nabídky, které se ovšem před nějakým časem vztahovaly na 20 stanic (jde to u nás rychleji kupředu, než se čekalo a je dobře, že jsme vyčkali). Rozhodně také nejde o žádnou hurá akci. V současné době jsme v bádacím režimu, poté se přepneme do režimu konzultací, poté do režimu cenových nabídek a pak se teprve uvidí.

       

Komentáře

[Chulda]

U bladu, pokud se s tím nepočítá, tak je problém spíše s chlazením. Ve staré servrovně šli blady realizovat jen s otevřeným rackem, jinak se přehřívaly a jen jeden do jednoho racku kvůli váze.

Druhá věc je, že blade by měl být taky 2x, což už je docela pálka. Nejde jen o upgrade HW, ale i firmware ("automatická" odpověď vmwaru v případě problému, který by mohl souviset s HW)

[Max]

Mno, serverovnu máme malou (ale dva racky volný), vybavenou dvěma klimatizacema (jede jen jedna na 20-21), je v přízemí, takže nějakou váhu utáhne. Pravdou je, že studenou uličku nemáme a klimačka fouká zboku na racky, které máme vzadu otevřené, protože HP fouká zepředu dozadu. Vzadu za rackama je docela teplo, před nimi je teplota normální a senzory si také nestěžují (teď koukám na jeden DL 380p Gen8 a větráky jedou na 6-35%). Troufám si tvrdit, že by s chlazením problém být neměl.
Jinak pravda, na upgrade fw jsem trochu zapomněl, to by s jedním Blade mohl být docela problém :-/. Máš nějakou story ze života?
Zdar Max

[Chulda]

Nestarám se o ně přímo já, ale kolega vedle mě a občas prskal, ale nevzpomínám si na nic fatálního. A updaty jsou docela časté. Tuším, že nakonec skončil u vmwaru od HP kvůli driverům apod. a to chvíli trvá, než je vydaj.

Že jsou 2 klimy - když jedna klekne, musí to ustát jedna samotná nebo počítat s vypnutím některých serverů, takže tím bych se nenechal moc ukonejšit

[Max]

Píši, že jede jen jedna klima. Druhá je vyplá a kdyby první zkapala, tak se zapne ta druhá. jednou za čas měníme provoz (jednu vypneme a zapneme druhou), aby byla jistota, že obě jedou ok.
Zdar Max

[SPM]

Zepředu dozadu foukají všechny zařízení, určené do racku (tedy, některé telekomunikační prvky to ne vždy mají, ale co už...). Na tom i staví ta studená ulička - klimatizace fouká do uličky, kde jsou racky čelem, zadek racků je oddělen a teplo se nasává tam odsud. V téhle kombinaci obvykle rack mívá jak přední, tak zadní dveře perforované, aby mohl vzduch procházet a nebylo potřeba jej nechávat otevřený (nicméně ve vlastní serverovně je celkem fuk, jestli tam ty dveře jsou nebo ne).

[melkors]

"ve vlastní serverovně je celkem fuk, jestli tam ty dveře jsou nebo ne"

Nevim, jak to vypada u vas, ale u nas se na salech porad neco stehuje. A neni az tak velky problem do neceho omylem vrazit - treba do tlacitka power ...

[SPM]

Máme serverovnu, ne skladiště :)) Ale upřímně, jestli tam stěhujete něco tak, že vrážíte do power tlačítka na serverech v různejch racích, tak bych se zamyslel nad tim, jestli ta serverovna stojí na správném místě...

[melkors]

Spis toho mame hodne a jak se obmenuje HW, tak ... Ceterum autem censeo, ze je lepsi mit trosku vetsi zabezpeceni, nez se dostat do pr*

[fanda42]

už 2× v životě jsem při poruše viděl, jak klima chrlí kroupy. Dost rychle tajou, potvory.

[SPM]

Tak blade vs 1U server na spotřebu a tedy i vyzářené teplo bude stejné (resp. ten blade by na tom naopak měl být lépe). Ta "potíž" je spíš v tom, že bladu lze do racku nacpat více, než 1U serverů, takže pokud to někdo narve celé a nemá na to dimenzované chlazení, tak má problém.

[drunkezz]

co sa tyka upgradov firmare u blejdov tam je jediny vopruz v tom ze ked je plne chassi a su firmware level rozhodene (tj ilo bios verzie su rozdielne per blade) tak je celkom o hubu to upgradovat, pac compatibility matrix je niekedy velmi divoky. + asi 3 sekundovy downtime na passthru moduloch v blade chassi pri fw upgrade.

V principe je to ale ok, a teraz sa to da uz vcelku pekne poautomatizovat, (scenar typu ok toto je moja nova blejda, sup s nou do chassi boot a prve co sa spravi sa vytaha firmware tam kde chces.

D.

[petr_p]

Takže čas tenkých klientů je opět zde? Zajímalo by mě, jestli jste už viděl živé nasazení, a co říkáte na zpoždění grafiky. Zvyknout se dá na vše. Ale znáte uživatele. Měl jsem pocit, že u X11 tenkých klientů lidi reptali na reakce. Přenos pixmap (RFB/VNC) tomu příliš nepomohl (obzvlášť když scrollujete ve webovém prohlížeči). Jiná řešení jsem neviděl. O Spice si iluze nedělám, protože to je RFB s automatickým přepínání do H.264 videa, když jsou změny rychlé.

[Max]

Asi takhle, máme nemálo jednoúčelových míst, kde běží čistě jen IS + tisk a tam by se to docela hodilo. Další věcí je, že toto pěkně řeší práci z domova a taktéž to řeší hw support na pobočkách, na čemž se ušetří čas. Znám firmu podobnou naší, která komplet běží na Citrixu. Reálně jsem to viděl (windows + citrix) a přijde mi to dost rychlý (prezentováno to bylo na 3G modemu a na lance by člověk neměl poznat rozdíl). Jinak tato virtualizace podle mně nešetří peníze, licence vyjdou dráž, jelikoš člověk musí mít nejen lic na windows + office, ale ještě na citrix, sql server, windows server atd. Pokud jde o hw, tak tam to také nevychází levněji (cena serverů + tenkých klinetů, které stojí kolem 7000, což je o pár tisíc míň, než stolní pc). Lze asi něco ušetřit akorát na spotřebě a na správě.
Zdar Max

[Chulda]

Tohle mám taky jen z doslechu, protože to není můj šálek kafe, ale bacha na licence. Jedna věc je, co tvrdí vmware a druhá co tvrdí microsoft - už jsme párkrát narazili na rozpor.

Např. u VDI od vmware jsou potřeba 2 licence od MS na jeden desktop a navíc obvykle nelze použít stávající (šlo hlavně u winXP).

[Max]

Ano, o licencích mi ani nemluv, co vše jsem se při zjišťování dozvěděl, humus. Jak už jsem psal, mám něco sepsáno, jen musím počkat, až si vše ještě jednou prověřím.
Zdar Max

[David Jaša]

O Spice si iluze nedělám

A zkusil sis to vůbec? Stačí pípnout...

s automatickým přepínání do H.264

mjpeg

[petr_p]

Tak jsi mě navnadil, až jsem si i přečetl dokumentaci :)

Dnes jsem si vyzkoušel Xspice a bohužel žádný zázrak se nekonal. Dokonce ani nebylo možné přeložit poslední xf86-video-qxl, protože někoho napadlo přetypovat ukazatel na uint64_t.

Pochybuji, jak někdo může oslavovat Spice na GPRS spojení. Zkoušel jsem to se 128 kb/s uplinkem. Udělal jsem 640×480 plochu, spustil maximalizovaný Firefox, v něm otevřel changelog posledního jádra a zmáčkl PageDown. 7 sekund. Těšil jsem se na proklamované kešování, tak jsem dal PageUp, a čekal jsem stejných 7 sekund.

VNC s tight kompressí Spicu natrhl prdel. Víš proč? Protože se spicec se nedostaneš pod 16bitovou hloubku a ošklivou kompresi, která je na takovýchto rychlostech nutná.

O tom, že Xspice po ukončení posledního X11 klienta má problémy ukázat drawable nového X11 klienta nebo že ukončit Xpspice lze jen signálem 9, pomlčím.

[David Jaša]

Tak jsi mě navnadil, až jsem si i přečetl dokumentaci :)

Kterou?

Dnes jsem si vyzkoušel Xspice a bohužel žádný zázrak se nekonal.

Xspice je stále poměrně experimentální a potřebuje tunit. Zkus si třeba zapnout Deferred FPS...

Pochybuji, jak někdo může oslavovat Spice na GPRS spojení.

To někdo dělá?

Těšil jsem se na proklamované kešování, tak jsem dal PageUp, a čekal jsem stejných 7 sekund.

To zní jako bug.

Protože se spicec se nedostaneš pod 16bitovou hloubku

zaprvé je spicec už dva roky mrtvý (pro F20 se už nebuildí vůbec), a zadruhé: cože? Spicec 16b barvy rozhodně uměl (a umí je i spice-gtk/remote-viewer).

O tom, že Xspice ...

holt je Xspice poměrně nové experimentální věc, na které střídavě (ne)pracují 1-2 lidé, a podle toho to i vypadá. Spice pro VMky je zcela jiné kafe.

[tuxmartin]

Pochybuji, jak někdo může oslavovat Spice na GPRS spojení.

To někdo dělá?

Jasne GPRS je blbost. V pripade GPRS bude kazdy stastny za pouzitelne SSH.

Ted me napada, jak vlastne prenasi spice obraz? Nekdo vyse psal o klasickem RFB (VNC) a pro rychle zmeny obrazu MJPEG.
Jake je to v porovnani s NX? To je vyborne na pomale linky. Jako priklad svobodne implementace jde pouzit treba X2Go, ale to zase musi bezet ve virtualizovanem OS

http://www.root.cz/clanky/nx-vzdalena-plocha-pro-sneky/
https://www.nomachine.com/

[David Jaša]

Ted me napada, jak vlastne prenasi spice obraz?

Různě. V závislosti na nastavení ovladače, rychlosti linky, změn na obrazovce a interních okolností to může být přenos 2D příkazů na klienta, přenos jednotlivých serverem vyrenderovaných obrázků (nekomprimovaný, komprimovaný bezztrátově, komprimovaný ztrátově), mjpeg stream.

Jake je to v porovnani s NX?

Spice funguje i na pomalých linkách, ale třeba oproti RDP má dolní mez použitelnosti o něco výš (to by předpokládám nějak jelo i na tom opravdovém ne-EDGE GPRS). Srovnání s NX nemám.

[petr_p]

Deferred FPS bych si bych si zapnul, kdybych mohl přeložit 0.1.1, kde je :(

Někdo tu psal o klientovi pro mobilní telefon. Tak jsem čekal, že na telefonu se používá telefonní spojení.

spicec je mrtvý? Tak jaký klient je živý? Z ideové dokumentace o architektuře to patrné není. Podívám se tedy na spice-gtk.

spicec umí --color-depth 16, ale třeba --color-depth 8 se mu nelíbí. 16bitů je pro mě moc.

[petr_p]

spicy ze spice-gtk je jen grafická omáčka. Barevnou hloubku lze nastavit jen z příkazového řádku a ta úplně stejně umí jen 16 a 32 bitů.

Výstup xtermu se v obou klientech kešuje. Narozdíl od Firefoxu, který má problém v obojím. Asi to bude souviset s rozířením, přes které Gecko/cairo kreslí.

Deferred FPS bude asi další chybějící díl, protože očividně server se snaží protlačit všechny změny, i když je nestíhá odeslat, místo toho, aby poslal konečný obrázek.

[David Jaša]

Deferred FPS bych si bych si zapnul, kdybych mohl přeložit 0.1.1, kde je :(

Jestli se stále bavíme o Xspice, tak nemusíš, ne-mu-síš. Deferred FPS bylo původně napsáno pro Xspice a uměla ho už verze použitá při F19 Spice Test Day před půl rokem.

Někdo tu psal o klientovi pro mobilní telefon. Tak jsem čekal, že na telefonu se používá telefonní spojení.

Tak zrovna v našich podmínkách se mobilní tefefony přes telefonní spojení do internetu nepřipojují. Aby taky jo, když to skoro nestačí ani na dnešní web.

Tak jaký klient je živý? ... spicy ze spice-gtk je jen grafická omáčka.

Už to tady padlo asi ve 3 příspěvcích...

16bitů je pro mě moc.

Zajímavé, za ty skoro 3 roky, co monitoruju upstreamový ML si nikdo nestěžoval na chybějící 8b barvy.

[petr_p]

Jestli se stále bavíme o Xspice, tak nemusíš, ne-mu-síš. Deferred FPS bylo původně napsáno pro Xspice a uměla ho už verze použitá při F19 Spice Test Day před půl rokem.

Nevím, co je Fedoře, ale v upstreamu je to až od 0.1.1.

Už to tady padlo asi ve 3 příspěvcích...

Fakt? Jsem si všiml jen klienta pro Android, správce virtuálních mašin a modulu do Mozilly.

[David Jaša]

Fedora u qxl holt i po vydání 0.1 pokračovala v "tradici" snapshotů, proto měla tohle už v 19. Teď by snad mohl být upstream přátelštější k distribucím a vydávat alespoň 2x ročně (jako zbytek spajsových komponent).

správce virtuálních mašin

To vypadá na provozní slepotu. virt-viewer (resp. remote-viewer) je něco jiného než virt-manager. Tedy taky je to "jen grafická omáčka" okolo spice-gtk, nicméně je zaměřená na uživatele a dostává se jí přiměřené devel i QA pozornosti.

[tuxmartin]

Zajímalo by mě, jestli jste už viděl živé nasazení, a co říkáte na zpoždění grafiky.

Ve skole mame VMware Horizon view a vykon je tragicky pomaly. Na psani ve Wordu mozna, ale staci spusit Eclipse, nebo Firefox a clovek ma chut zabijet...
Jedinou vyhodu vydim v moznosti pouzivat licencevany software doma pres "vzdalenou plochu".
Osobne si myslim, ze hlavni problem bude v chybejici 2D/3D akceleraci (protoze TeamViewer na klasicky PC chodi velmi rychle) - ale nejsem odbornik na VMware!

Me by zacala virtualizace dekstopu zajimat ve chvili, kdybch mohl pouzit Androidi PC za 700Kc (nebo s ethernetem za 1400Kc). Pak by byla velka uspora za elektrinu i za cenu PC. Na linuxovy psaci stroj a emailovy klient by to bylo luxusni.

Jenze na Android neexistuje poradny Spice/RDP/X2Go/... klient a pokud tam flashnete Linux, nemate ovladac na grafiku a 3D akcelerace se nekona. Pak krabicka vytuhne i pri hybani kurzoru po monitoru

[David Jaša]

Na psani ve Wordu mozna, ale staci spusit Eclipse, nebo Firefox a clovek ma chut zabijet...

Firefox používám přes spice poměrně často a problémy s tím nejsou. Na eclipse chodily stížnosti často, stejně tak na excel, nicméně zrovna s tím excelem se ukázalo, že s těmi samými soubory má problém scrollovat stejné verze i na holém železe...

Kapitola sama pro sebe je gnome-shell, ten když je virtualizovaný, tak tam to "s" v názvu opravdu přebývá.

Jenze na Android neexistuje poradny Spice/RDP/X2Go/...

Doporučuju zkusit aSpice a jeho varianty pro VNC a RDP (tuším bVNC a aRDP). Chvíli jsem si s tím hrál na mobilu a šlapalo to hezky, navíc na něm autor celkem aktivně pracuje.

[tuxmartin]

Firefox používám přes spice poměrně často a problémy s tím nejsou. Na eclipse chodily stížnosti často, stejně tak na excel, nicméně zrovna s tím excelem se ukázalo, že s těmi samými soubory má problém scrollovat stejné verze i na holém železe...
Doporučuju zkusit aSpice a jeho varianty pro VNC a RDP (tuším bVNC a aRDP).

Diky za tip aSpice zkusim.

Podle toho co pises a podle tve paticky predpokladam, ze mas se spice zkusenosti.
Nevis o nejakem dobrem navodu na instalci a nastaveni spice serveru? Potrebuju podporu USB po siti (flashky a tiskarny).
Ja jsem nasel jen spoustu navodu pochybne kvality. Vzdycky neco kompilovali a vysledek byl temer vzdy dost divny. Jaky treba pouzit klient pro Windows a pro Linux? Ten virt-viewer vypada divne. Ty ke stazeni na oficialnim webu spice jeste hur.
Funguje nejak USB over net na Windows i Linux klientech?

Asi pul roku zpatky jsem zkousel spice a musel jsem pouzit Fedoru. V Ubuntu hrozne prace s kompilaci a stejne to moc nejelo. Chtel jsem pouzit CentOS, ale prekvapive taky nic extra (jak to je na RHELu?).

Rad bych si na zkousku udelal spice server z Core i5, 8GB RAM. Distribuce me tolik netrapi, ale nejradi bych Ubuntu, nebo CentOS.
Jako kliety bych na testovani rad pouzil asi 2 PC s Win (1x XP a 1x 7), pak asi 1 PC s Linuxem a 2 andoidi prehravace s aSpice u televize/monitoru.

Diky za rady

[David Jaša]

Nevis o nejakem dobrem navodu na instalci a nastaveni spice serveru? Potrebuju podporu USB po siti (flashky a tiskarny).

Jak moc pracně to chceš? V oVirtovi ti stačí akorát přepnout USB v Console Options na Native, v libvirtovi se to dělá takto a v qemu spouštěném přímo z CLI takto.

Jaky treba pouzit klient pro Windows a pro Linux?

Pro linux jakýkoliv dostatečně moderní, tedy RHEL/CentOS 6.3+, Fedora 16+. Debianí svět bývá zpožděný, třeba tamní virt-viewer pěkně dlouho ignoroval existenci celého spice-gtk... Ale i tam se věci mění, po x letech třeba zvládli zabalit spice-xpi (v době, kdy už pro spouštění klientů z oVirtích portálu není potřeba).

U Windowsích klientů je to složitější, tam je potřeba buď pro každé zařízení ručně instalovat WinUSB driver, nebo si zbuildit usbclerk (který to udělá za tebe), nebo tu instalaci řešit nějak jinak (odtud). Nebo pokud to máš do firmy, tak si koupit RHEV, který má instalovatelné binárky usbclerku. Nicméně tak či tak nejedou kompozitní a isochronní zařízení (typicky webkamera nebo usb sluchátka), na linuxu tyhle věci jedou.

Ten virt-viewer vypada divne. Ty ke stazeni na oficialnim webu spice jeste hur.

Co se ti na něm nelíbí, windowsí GTK skin?

Asi pul roku zpatky jsem zkousel spice a musel jsem pouzit Fedoru. V Ubuntu hrozne prace s kompilaci a stejne to moc nejelo. Chtel jsem pouzit CentOS, ale prekvapive taky nic extra (jak to je na RHELu?).

RHEL bývá nejaktuálnější. Fedora občas zastará (třeba věci v F17 byly starší než v o měsíc mladší 6.3) a do CentOSu se to dostane až to tam zrebuildí. Debianí svět bývá pozadu, jak už jsem psal.

Rad bych si na zkousku udelal spice server z Core i5, 8GB RAM. Distribuce me tolik netrapi, ale nejradi bych Ubuntu, nebo CentOS.

HW v klidu (pokud na něm nespustíš vedle virtuálek i firefox s 50 taby a týdenním uptime ). CentOS je pro spice lepší volba, kor když má brzy vyjít 6.5.

Jako kliety bych na testovani rad pouzil asi 2 PC s Win (1x XP a 1x 7), pak asi 1 PC s Linuxem

v pohodě až na to USB u windowsích klientů.

andoidi prehravace s aSpice u televize/monitoru.

pokud to chceš na video, tak tam může být problém s výkonem: android nemá hw podporu pro mjpeg, který se ve spice používán na video (resp. rychle se měnící části obrazovky) a sw dekódování nemusí slabší CPU zvládat. Nedávno o tom psal autor aSpice na spice-devel listu.

[tuxmartin]

Doporučuju zkusit aSpice a jeho varianty pro VNC a RDP (tuším bVNC a aRDP). Chvíli jsem si s tím hrál na mobilu a šlapalo to hezky, navíc na něm autor celkem aktivně pracuje.

Existuje nejaka minimalisticka upravena distribuce, ktera by sla na klietovi nabootovat ze site (bezdiskova stanice) a mela v sobe Spice klienta?

[David Jaša]

Nevím, tohle nesleduju. Tuším jen, že něco podobného používají výrobci tenkých klientů, ale to asi veřejně dostupné nebude. Jinak udělat si vlastní spin Fedory nebo CentOSu by nemělo být nic těžkého (bootovat ze sítě to umí a různě upravených spinů je na tam spousta).

[Wex]

S bladem skoro žádné zkušenosti nemám, jenom vím, že potřebuje o něco víc IP adres než klasický server.

[R]

Pokial nemas skutocne nedostatok miesta, tak blade nepouzivaj. Usetris dvakrat - peniaze a zbytocne problemy.

[melkors]

Kupovat blady pri dvou trech serverech je blbost, sasi to neskutecne prodrazi

Pocitej s tim, ze je potreba mit minimalne jeden server v zaloze, optimalne jako hot spare. Zkalkulovat si to muzes celkem jednoduse - porovnej cenu vypadku x stanic (virtualizovanych na tom serveru) za dobu opravy a cenu serveru navic.

[snajpa]

Po vsech moznych zkusenostech s nestandardnimi form factory musim rict, ze neni nad standardni 2U stroje - at uz jde o chlazeni, rozsiritelnost nebo servisovatelnost.

[torvic]

Blade se skutečně vyplatí až od více serverů.

Co se týče těch DL560, šel bych raději na více (4?) DL360/380. Rozložíš výkon a v případě výpadku serveru ti nezmizí 50% výkonu ale jen 25%. To oceníš taky při těch aktualizacích, protože jsi schopen jeden server odstavit i v běžném provozu - takhle např. dělám aktualizace klidně už po 15. hodině, kdy provoz už není úplně na 100%, aniž by to kdokoliv vůbec poznal.

Taky bych upozornil, if servery > 2 , budeš potřebovat optický nas switch (pokud chceš - a určitě chceš (!) zdvojené napojení pole).

Automatické vypínání/zapínání serverů podle zátěže ve vmware umí až nějaká hodně vysoká licence (za tučný peníz), tak je třeba spočítat, jestli se to vyplatí.

[SPM]

DPM je dostupný "už" i v Enterprise edici... naproti tomu distributed switch, který typicky člověk na takovéhle prostředí chce, je až v enterprise plus... :-/

[Max]

Ahoj, díky za upozornění ohledně FC switche. Zatím pokukuji po HP StoreVirtual 4000 Storage. Dále bych rozhodně nechtěl mít dva nody využity na 100%. Chtěl bych rozhodně nějakou rezervu pro případ nouze. Pokud by nebyla, tak by se naladil třetí server.
Zdar Max

[drunkezz]

chod ro rackov, blejdy su dobre ked potrebujes high rack density (namiesto 20 2U v celom racku mas 32 serverov v polke racku)

tu by som povedal ze ci mviac ramky tym lepsie..kludne ozel 2 procaky a narvi tam pamate co bude treba....my bezime VDI na blejdoch sice ale my robime 400+ desktopov na tom, ...a samozrejme ozajstne pole! ziadne ataoverkoax! I/O je bottleneck !

D.

[Max]

Pokud jde o pole, tak chci dvě, aby i pole byly v HA. Zatím pokukuji po HP StoreVirtual 4000 Storage, ale jsem v začátcích, takže uvidíme.
Zdar Max

[David Jaša]

Že procáky nejsou úzké hrdlo u VDI souhlasím. Občas se divím, co zvládne utáhnout desktopové dvoujádro s 36 GB paměti. :) U I/O mi přijde, že paradoxně pomáhá thin-provisioning VMek (resp. jejich systémových disků) ze šablon, asi díky tomu, že je pak má hypervizor natažené v keši.

[xvasek]

...a samozrejme ozajstne pole! ziadne ataoverkoax! I/O je bottleneck !

Osobně si myslím, že co se týká výkonu I/O, tak je nejlepší prostě humpolácky nacpat SSD přímo na řadič toho serveru, popřípadě (lépe a dráže) na PCIe. Moc nechápu, jak může být rychlejší, když mezi ten stejný disk a sběrnici nacpu ještě řadič, kus kabelu, druhý řadič, CPU v poli, zpracuju to nějakým OS v poli, rozdělím požadavky mezi další čtyři připojené servery, pošlu požadavek na řadič k disku (který je teda v tom serveru taky) a pak zase stejnou cestou zpět. Pole svůj význam samozřejmě má (centrální správa, zálohy, dynamické přidělení prostředků, jednotná a jednoduchá politika řešení chyb), ale co se týká výkonu a zejmnéna latence, tak mi teda přijde, že je to dost velká brzda. Aspoň takovou mám já zkušenost s "cloudováním" našich serverů, které se v poslední době vyskytuje.

[SPM]

Ono je "pole" a pole. Pokud si k bladu připojím jako storagi Qnap, tak to rychlejší nejspíš nebude :)

[xvasek]

Ono ani pole bez uvozovek to moc neurychlí. Dokud se bavíme plotnových HDD, kde se v enterprise pořád drží nesmysly jako například 150GB 15k disky (které na jednu otáčku disku přečtou polovinu toho, co zvládne jednoplotnový WD Green), tak to až tak moc "nevadí". Ale pokud si vezmu SSD a začnu provozovat něco, co závisí na latenci, tak to už jde celkem i poznat na odezvách systému.

Prakticky vzato - když virtualizueme nějaké starší např. Sandy Bridge Xeony do nějaké modernější platformy (přímo ze železa do VM + pole), tak většinou považujeme za úspěch, když to jede aspoň stejně rychle, jako před upgradem.

Tím nechci říct, že by virtualizace byla špatná. Naopak mám ji opravdu rád - odpadnou skoro veškeré problémy s HW a tím, že ten který systém má debilní olvadač pro ten který řadič. Jenom mi přijde, že většina firem dnes trpí něčím jako "virtuální splepota" - zvyšování výkomu přidáním dalších CPU, paměti, rychlejších disků apod. jim funguje bezvadně, ale už vůbec nemají představu, jak rychle by to mohlo běžet přímo na primitivním železe.

[Max]

Já si myslím, že ta představa tu je, ale výhody virtualizace značně převyšují, takže pak to ani nikdo neřeší.
Zdar Max

[SPM]

Tak ono pokud je v poli jeden disk, tak výkon bude vždycky limitovaný jedním diskem. Ta výhoda toho pole přijde s tím, když je velké - v tu chvíli pole může ty data rozházet tak, aby disky byly +- stejně vytěžované, může kombinovat více typů disků a data s častějším přístupem dávat na ty rychlejší, a podobně. Jinak když se to zaplní a 150GB disk dá +- stejně IOPS jako 2TB disk, tak je potřeba vzít v úvahu i to, že po tom 2TB disku se toho ale bude chtít daleko více :)

Ta slepota je a možná to má i příčinu jinde. Ve spoustě případech mi přijde, že je už úplně nahovno udělaná ta aplikace. Ale místo toho, aby to někdo řešil, tak se tam prostě nakliká něco víc procesorů a něco víc paměti, protože u virtualizace tohleto naklikat jde a je to jednodušší. IMHO u nezprasené virtualizace poběží většina aplikací (až na nějaké specifické případy) cca stejně rychle, jako na samotném železe.

[xvasek]

Jinak když se to zaplní a 150GB disk dá +- stejně IOPS jako 2TB disk, tak je potřeba vzít v úvahu i to, že po tom 2TB disku se toho ale bude chtít daleko více :)

Tak potom si na tom 2TB WD Greenu můžu vytvořit jenom 150GB partition na vnějším okraji plotny a za zlomek ceny předhoním ten 15k SAS dokonce i v seeku.

Ale s těma zprasenýma aplikace máš samozřejmě pravdu.

[drunkezz]

tvl..tu by ta projektak praskol brozurou s rozpoctom po krku tak silno, zeby poculi prasknutie chrbtice aj v jedalni, kde by prave papali manageros svoj reznik....toto nemozes mysliiet vazne...

D.

[xvasek]

Tak jistě, když si někdo řekne o server, tak tam ty 15k disky nabídnout nechám - ale dělám to čistě kvůli tomu, že to pak bude vypadat náramě profesionálně. O poměru cena / výkon (a o absolutním výkonu samotném) si myslím svoje.

[torvic]

No, wd green jsou určitě super, ale ty enterprise 15k otáčkovky jsou skutečně někde jinde. Tady se nebavíme o spojitém datovém toku, ale o vybavovací době, když např. databáze hopsá hlavičkami z jednoho místa do druhého nebo na ten disk leze 50 uživatelů každý jinam. Proto se do pole dává více disků, a tomu důležitému parametru se říká IOPS ;)

[Max]

A proto se používajý výkonné řadiče s pár GiB cache. Rychlost se pak zvýší cca 15x.
Zdar Max

[Max]

Doufám, že je všem Grammar Nazi jasné, že to je překlep :)
Zdar Max

[xvasek]

Opravdu nejsou jinde. Ten disk je pořád disk - nastavuje, otáčí, čte / píše. Teď mi odešel jeden server se 4x72GB SCSI RAID5 - pravda jenom 10k. Hotspare je úplně sprostý entry level server s jedním CPU (hlavní má dvě) a jednoplotnovými 500GB SATA disky v zrcadle (nejsou to WD Green). A lidi si toho všimli proto, že ten systém jel znatelně rychleji. A já jsem jim to říkal, že bych ty SCSI vyhodil už dávno, že je to jak šnek.

Nejen vybavovací dobou živ je člověk, co si ten 15k nahoní ve vybavování, o to přijde při čtení. A SSD z nich dělají věc už úplně zbytečnou.

Jistě, připouštím, že se mohou vyskytnou i situace, kdy budou ty 15k rychlejší, ale při dnešních velikostech cache dost pochybuju, že to bude nějak zajímavě velká množina úkolů.

[torvic]

SCSI je už mimo, SAS je na tom líp. A - ze zkušenosti s databázema - RAID5 je velká bída, konkrétně na ty databáze.

SSD je samozřejmě jiná písnička, ale do serverů na databáze, kde se pořád něco updatuje, mám pořád interní klapku. Když na tom stojí fabrika, tak jsem konzervativní a říkám si ať si hubu nabije někdo jiný ;)

[xvasek]

Já myslím, že je to jedno. Když neodejde SSD, odejde něco jiného. Ale je fakt, že to mám zatím jenom v jednom produkčním serveru - zákazník to tak sám chtěl, já nejsem v principu proti - zálohy máme... Náš produkt na disk moc nepíše, takže z životnosti nemám strach, výkon to má pěkný, ale pořád se kolem SSD drží taková aura "pozor na to, SSD je nespolehlivé, disky jsou lepší."

[Max]

Porovnávat SCSI s novým SATA, to je vtip, ne? A ještě ke všemu i při změně pole. Říká ti třeba něco DualPort? Porovnáváš tu tintítkové sestavy a na základě toho odsuzuješ enterprise?
Dále, SAS máš většinou v 2,5" verzi, takže se ti jich vejde sakra víc do stejného prostoru. U SATA disků by jsi musel přikupovat externí pole, další prachy navíc, takže co by jsi ušetřil za hdd, to by jsi vrazil do pole a dalšího řadiče.
Dále, IOPS SAS vs SATA, tam je trojnásobný nárůst, takže pro databáze je SAS jasně lepší volbou.
Pak tu máme i životnost, kde u SAS je udávána větší hodnota MTBF.
Jako, RAID edice SATA disků bych taky někde použil a používám, ale s tvými verdikty nesouhlasím.
Proti SSD stále mluví poměr cena/životnost/a hlavně kapacita, což se mnohdy nevyplatí objetovat za jeho výkon.
Zdar Max

[xvasek]

Ty disky byly obojí 3,5", takže srovnávám podobné. Mezi SCSI Ultra 320 a SATA - tuším v tom novém serveru je 3Gbit, ale to je v této konfiguraci jedno - bych taky zásadní rozdíly nehledal. A rozhodně to nebyl upgrade z historického stroje na současný - ty servery se pořizovaly chvilku po sobě, obojí je Sandy Bridge.

Jinak co se týká samotného parametru IOPS - trochu bych se zaměřil, jak se s ním dá podvádět. Jedna věc je totiž velikost bloku a druhá je snížení skutečné doby seeku. Při formátování jenom jedné čtvrtiny disku se díky tomu IOPS zvedne klidně o 80%, takže z lenošného 7200ot/min 1TB entry level disku můžeš mít klidně výkonový ekvivalent 10000ot/min 250ky. Když si zvětším testovaný blok a budu tvrdit, že je to můj typický use-case (protože proč ne?), tak se klidně dostanu i k těm 15k SASům.

Jistě, budu mít ty racky "řídké" a budu jich potřebovat hodně, ale já se od začátku bavím o výkonu, ne o tady těch ostatních aspektech.

[Max]

Mezi SCSI Ultra 320 a SATA - tuším v tom novém serveru je 3Gbit, ale to je v této konfiguraci jedno - bych taky zásadní rozdíly nehledal

Stačí si porovnat třeba pět let starý 500GB SATA disk s novým 500GB sata diskem a budeš pozorovat docela markantní rozdíly. Porovnávat pak starce v podobě SCSI disku s novým SATA, to je opravdu pak úplně někde jinde .
Zdar Max

[xvasek]

Ty pětistovky byly soudobé SATA. Ale beru, že byly "architektonicky" mnohem novější, než ty 72GB SCSI - to byl už při prodeji nějaký dobře uleželý archívek.

[gtz]

SCSI disky byly kdysi levnější alternativou k drahým FC diskům, před nějakou dobou byly disky s FC jen v Top polích a většinou se používaly právě SCSI, kvůli dostupnosti a výdrži. Tehdejší disky byly držáky, ty dnešní no škoda mluvit.

Jak jsem psal níže osobně bych tam nacpal SAS disky na systém, databázi apod. a celý server bych připojil dual FC přes FC switch do nějakého FC/SAS (SATA) pole.

Proč vyhazovat? udělat z nich pro lidi ve firmě nějaké dočasné úložiště popř. to použít jako nějaký servřík na testy.

[xvasek]

Proč vyhazovat? udělat z nich pro lidi ve firmě nějaké dočasné úložiště popř. to použít jako nějaký servřík na testy.

No, původní server nakonec dostal FC řadič a je připojený do pole. Ale než bylo pole, tak bylo opravdu problematické to použít - pomalý IO a drahý potenciální upgrade (na rychlejší a větší SCSI disky) z toho udělaly ležák v kumbálu.

[gtz]

z toho udělaly ležák v kumbálu

Udělal bych z toho pro NAS pro IT oddělení, viditelný jen oprávněným členům skupiny administrators

[gtz]

1U servery s dostatkem paměti a nějaký menší rychlý SAS disk na systém. Servery bych připojil přes nějaký dual FC switch do nějakého FC/SAS (FC-SATA) pole s redundancí.

Cena by měla být nižší než v případě Blade (storage bys taky musel použít, FC switch taky).

Pokud Blade tak bych zkusil oslovit DELL s tím, že uvažuješ o tom a tom řešení a hlavně bych jim řekl, že máš v ruce nabídku od HP

[Ruža Becelin]

O kvm nemá zatím cenu přemýšlet, zatím není tak protlačeno do enterprise sfér z hlediska oficiální podpory sw produktů

RHEV?

[Max]

Ahoj, asi jsi to špatně pochopil. Tady jde o to, že my třeba mj. provozujeme telefonní ústředny Aastra MX-One a to běží na SLES. Oficiálně Aastra podporuje běh jen pod ESXi, když by virtuál běžel pod jiným hypervisorem, byl by problém se supportem.
Dále, někdo mi teď dokonce psal, že SLES není oficiálně podporován pod RHEV (je někde oficiální support guest os list?).
Zdar Max

[David Jaša]

RH tvrdí: 3.2, 3.3 beta; SUSE mlčí (narozdíl třeba od MS).

[Max]

Na toto jsem taktéž narazil, ale myslel jsem si, že je to vtip :-/. Ten seznam mi přijde ukrutně malý :-/.
Zdar Max

[j AM]

Blase IMHO nejde dat jen tak do racku, je treba na nej mit enclosure a myslim ze HP dela nejmensi pro 6 bladu a stoji par tisic dolaru.

Pokud jde o par serveru tak se blade nevyplati.

[SPM]

Tak enclosure nemusíš mít plný, dáš tam místo něj záslepky... nicméně pravda je, že enclosure tě taky stojí ty prachy, který pak takhle moc nevyužiješ...