Vdaka za zaujimave informacie, Z nas sa o virtualizaciu zaujimas najviac, takze asi aj vies co bude vyhodnejsie :)<br><br><div class="gmail_quote">2012/2/9 Pavel Snajdr <span dir="ltr"><<a href="mailto:snajpa@snajpa.net">snajpa@snajpa.net</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
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 href="http://www.supermicro.com/products/system/1U/5016/SYS-5016T-MTF.cfm" target="_blank">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 href="http://github.com/facebook/flashcache" target="_blank">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>
- --<br>
Pavel Snajdr<br>
<br>
<a href="tel:%2B420%20720%20107%20791" value="+420720107791">+420 720 107 791</a><br>
<br>
<a href="http://vpsfree.cz" target="_blank">http://vpsfree.cz</a><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.11 (GNU/Linux)<br>
Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org/" target="_blank">http://enigmail.mozdev.org/</a><br>
<br>
iF4EAREIAAYFAk8zC9MACgkQdh+64ds5DabzVQD+JnkzI9SDv/jbt6z0WK52kyZK<br>
R3kpH4n5yRjTTLVNrcwA/jKw8YX3E5NLgHi1df1WWGAGLo7F1D5IRIcJaNoxFCUS<br>
=X3O7<br>
-----END PGP SIGNATURE-----<br>
_______________________________________________<br>
Community-list mailing list<br>
<a href="mailto:Community-list@lists.vpsfree.cz">Community-list@lists.vpsfree.cz</a><br>
<a href="http://lists.vpsfree.cz/listinfo/community-list" target="_blank">http://lists.vpsfree.cz/listinfo/community-list</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Erich Stark<br>