[vpsFree.cz: community-list] Zajimave/dulezite cteni: Jak bude vypadat konfigurace nasich serveru dal, Q&A session

Thu Feb 9 11:37:58 CET 2012

Vdaka za zaujimave informacie, Z nas sa o virtualizaciu zaujimas najviac,
takze asi aj vies co bude vyhodnejsie :)

2012/2/9 Pavel Snajdr <snajpa at snajpa.net>

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


-- 
Erich Stark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20120209/28351492/attachment-0002.html>