<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Ahoj, <br>
<br>
Suhlas -> do buducna to vyzera super. Takze od KVM ideme
definitivne upustit?<br>
<br>
On 02/09/2012 12:57 AM, Pavel Snajdr wrote:<br>
<blockquote type="cite">Caute,<br>
<br>
mozna bych se mohl podelit o progress, ktery jsme udelali v HW a
SW<br>
specifikaci serveru, softwarove konfiguraci a trochu vysvetlit, co
a<br>
proc a jak. Taky jsou tu dulezite informace co se tyce budoucnosti<br>
technologii @vpsFree.cz, takze si to prosim prectete.<br>
<br>
Konfigurace, co objednavame od ted - tzn. i pro Brno:<br>
<br>
System<br>
<a class="moz-txt-link-freetext" href="http://www.supermicro.com/products/system/1U/5016/SYS-5016T-MTF.cfm">http://www.supermicro.com/products/system/1U/5016/SYS-5016T-MTF.cfm</a><br>
<br>
Core i7 960 3.2 GHz (3.46 GHz turbo speed)<br>
6x 4 GB Kingston DDR3 1333 MHz<br>
4x 1TB WDC Black Edition 64MB cache<br>
1x 120 GB OCZ Revodrive 3 MAXIOPS edition<br>
<br>
Software:<br>
<br>
Scientific Linux 6<br>
(rebuild Red Hat Enterprise Linuxu)<br>
+ OpenVZ Stable kernel<br>
(novejsi revize, nez mame na Debian Squeeze)<br>
+ Flashcache z SSD nad RAID10 z disku<br>
(<a class="moz-txt-link-freetext" href="http://github.com/facebook/flashcache">http://github.com/facebook/flashcache</a>)<br>
<br>
No a nejlip vysvetlim co a jak kdyz sepisu trochu Q&A:<br>
<br>
HW Q&A<br>
<br>
Q: Proc ne Xeony a ECC pameti?<br>
A: Protoze za stejnou cenu poskytujou horsi vykon; teoreticky by
mely<br>
byt spolehlivejsi, ale praxi jsme si overili, ze to tak neni -<br>
spolehlivost je zhruba nastejno.<br>
<br>
Q: Proc Supermicro a ne vendor XYZ?<br>
A: Supermicro ma v CR dobrou dostupnost, ten hardware mame
odzkouseny,<br>
je videt, ze Supermicro jako vendor dela kvalitni praci a to
vsechno za<br>
super cenu.<br>
<br>
Q: Koukal jsem na ten system a vidim, ze pisou, ze ma povolene TDP<br>
procesoru jenom 100W, ale ta i7 ma 130W - WTF?<br>
A: Jop, je to tak, jdeme proti doporuceni vyrobce. Experimentalne
jsme<br>
si to overili na 4 kusech te same konfigurace (pro muj a Tomasuv
dalsi<br>
projekt - Relbit), tyden nam tam jel 16x CPUBurn, teplota se
drzela na<br>
hranici unosnosti, takze jsme s Abacusem (dodavatel) vykoumali, ze
ta<br>
skrin podporuje dalsi 2 ventilatory, dali jsme je tam a pomohlo
to,<br>
teplotu pri 100% vytizeni to stahlo par stupnu pod "critical"
hranici;<br>
navic z nasich munin grafu je videt, ze zridkakdy vubec
presahujeme 50%<br>
zatizeni (coz neberte jako pokyn ten CPU zacit vytezovat, co to da
-<br>
diky nizke celkove zatezi maji aplikace, ktere tam pak provozujete<br>
nizkou latenci)<br>
<br>
Q: Pred rokem a neco jste nakupovali twiny, proc je nebereme dal?<br>
A: Jsou nahovno :) Nejdriv - co jsou twiny -> dva servery v 1U.<br>
Ted vazneji - je v nich malo mista pro upgrade. Kdyz tam budu
chtit dat<br>
SSD, tak musime vyhodit silene penize za low profile PCIe SSD,
kdezto do<br>
plnych 1U muzeme v pohode dat SSD misto slotu, kde jsou ze predu<br>
vyvedena USBcka a seriovy port (Supermicro na to ma primo dil pro
montaz<br>
2.5" disku). Dalsi vec je, ze do twin chassis nesezeneme desku<br>
podporujici i7 CPU, jedine Xeony - vyhozene penize.<br>
<br>
SW Q&A<br>
<br>
Q: Kde jste nechali Debian?<br>
A: Do ted jsme jeli na Debian Squeeze, pro prechod na Red Hat
based<br>
systemy je nekolik duvodu<br>
<br>
- lepsi odladenost kernelu<br>
- OpenVZ se vyviji primarne pro RHEL -> novejsi a odladene
featury -<br>
OpenVZ team vydava primo oficialni RHEL kernel, ktery prochazi
jejich<br>
labem, na ktery maji napsane svoje testy (o 1000% odladenejsi, nez<br>
Debianni podani OpenVZ)<br>
- Flashcache je vyvijena primarne na RHEL kernelu<br>
- uz mam konecne RHCE (:D)<br>
- delal jsem v Red Hatu -- 1. ano, uz jsem odesel, 2. ne,
nevyhodili<br>
mne, 3. ne, nedelam jim reklamu, 4. vsak uz mne a muj pristup
znate (doufam)<br>
- Kickstart (Debian nic takoveho nema, takze tam neni na co
nadavat, ze<br>
by to nefungovalo :D - pro nezasvecene - feature instalatoru pro<br>
automatizaci instalace)<br>
<br>
Q: WTF je flashcache?<br>
A: Flashcache je docela zazracny modul do kernelu - pracuje na<br>
devicemapper vrstve (tzn. blokova zarizeni). Vezme 2 blokove
zarizeni,<br>
jedno z nich pouzije jako cache nad tim druhym - typicke pouziti
je vzit<br>
SSD a pouzit ho jako cache nad disky -> v nasem pripade jako
writeback<br>
cache nad RAID10.<br>
Realnym dusledkem je zvyseny vykon IO operaci, hlavne se to pozna
na<br>
databazich a pulnocnim cronu :)<br>
<br>
Q: Kde sakra mame to KVM?<br>
A: KVM je *SRACKA*. Tecka.<br>
Abych se rozepsal vic - pokud vam nejde o vykon, tak ano, KVM
muzeme<br>
realizovat. Proste v porovnani s OpenVZ je to *priserne* pomale,
je to<br>
drazsi (nizsi moznost agregace) a ma to asi tak miliardu problemu,
do<br>
kterych patri nestabilita - presne tak, i to debilni OpenVZ je
stabilnejsi.<br>
Nevim, necham si to projit hlavnou, ale rozhodne uz mne preslo
planovani<br>
megahypersuper akce pro prechod na KVM, minimalne dokud neodladi<br>
zakladni architekturalni problemy typu 2 planovace nad sebou (jak
disky,<br>
kde se to da napravit, tak CPU, kde s tim neudelam nic nez
staticky<br>
pinning virtualu k jadrum CPU, coz je reseni na ranu pesti do
hlavy).<br>
Urcite nebudeme prechazet na neco, co jsem si na 100% jistej, ze
by<br>
snizilo uroven. Skoda je, ze jsme si v zapisu schuze nechali
odhlasovat<br>
neco jineho - nechavam na kontrolni komisi, aby se k tomu
vyjadrila, ale<br>
osobne jsem z KVM opojeni docela dost vystrizlivel. Celkove jsme s<br>
Tomasem stravili uz dost hodin produkcnim hranim si s KVM (na
Relbitu),<br>
ze by se to dalo pocitat na dny. A to jak s Debianem, tak RHELem a<br>
dokonce i s Fedorou (= nejnovejsi upstream).<br>
<br>
Q: Mne se ale KVM libi, mam ho na svym domacim serveru a jede mi
super,<br>
urcite to neumis nastavit!<br>
A: Jede super, dokud je virtualu malicko. Jakmile ma dojit k
agregaci,<br>
ktera nema omezovat (tzn. ze opravdu nevyuzite prostredky muze
vyuzit<br>
ten, kdo je potrebuje) => pruser. Urcite nedoporucuju mit vic
virtualu<br>
na server, nez je tak jeden a pul nasobek poctu jader (pokud jsou
to<br>
virtualy s 1 pridelenym jadrem), pokud to ma mit nejaky vykon.
Potom se<br>
zvysujicim se poctem virtualu vykon rapidne klesa - obzvlast,
pokud se<br>
toho vykonu nedejboze dozaduje vic jak 4-5 virtualu najednou, to
je zle.<br>
Pridelit virtualu vic jak 1 vCPU a nechat na linuxu, at dynamicky<br>
planuje, ktery proces KVM na kterem procesoru bezi, to uz je uplna<br>
tragedie. Zase, dokud je virtualu malo, tak pohoda jazz, ale jak
je jich<br>
vic, tak dojde k takovym zverstvum, ze to zacne vylevat cache na
CPU<br>
(tuhle informaci mam primo od vyvojaru z Red Hatu, vedi o tom, ale<br>
reseni je v nedohlednu).<br>
<br>
<br>
<br>
Tak, a ted se ptejte, pokud jsem na neco duleziteho zapomnel.<br>
<br>
<br>
<br>
</blockquote>
<span style="white-space: pre;">>
_______________________________________________<br>
> Community-list mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:Community-list@lists.vpsfree.cz">Community-list@lists.vpsfree.cz</a><br>
> <a class="moz-txt-link-freetext" href="http://lists.vpsfree.cz/listinfo/community-list">http://lists.vpsfree.cz/listinfo/community-list</a></span><br>
<br>
-- <br>
S pozdravom / Best regards<br>
Peter Bubelíny<br>
PGP key: <a class="moz-txt-link-freetext" href="http://goo.gl/ic2Wc">http://goo.gl/ic2Wc</a><br>
Jabber: <a class="moz-txt-link-abbreviated" href="mailto:peter.bubeliny@jabbim.sk">peter.bubeliny@jabbim.sk</a><br>
<br>
</body>
</html>