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

Thu Feb 9 01:15:54 CET 2012

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

To jsme probirali s dodavatelem, dobrej dotaz k veci.

Bude a nebude - pokud oba uzname (tzn dodavatel i my), ze je to tim, ze
jsme to nedodrzeli, tak od toho oni daji ruce pryc - i kdyz pochybuju ze
uplne, pomoct se budou snazit, protoze maji dobrej pristup (a protoze uz
jsem jim tam udelal nejen za vpsFree obrat, kterej se pocita).

Pavel Snajdr

+420 720 107 791

http://vpsfree.cz

On 02/09/2012 01:13 AM, Tomas Volf wrote:
> Diky za zajimave cteni :) Rozhodne tomu nerozumim natolik, abych neco
> kritizoval, tvoje vysvetleni zneji logicky :) Jedine co mne tak napada
> je "Jop, je to tak, jdeme proti doporuceni vyrobce.", jestli to nebude
> mit vliv na pripadnou reklamaci?
> 
> Ale jak rikam, nevyznam se, jenom mne to napadlo :)
> 
> Tomas
> 
> On Thu, 09 Feb 2012 00:57:09 +0100
> Pavel Snajdr <snajpa at snajpa.net> wrote:
> 
> 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.
> 
> 
> 
_______________________________________________
Community-list mailing list
Community-list at lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
>>
>>
_______________________________________________
Community-list mailing list
Community-list at lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk8zEDoACgkQdh+64ds5DaazygD/btWQVXqaQQG7HtOrm9M5ZYVV
KK/1QZ27ZunHodUE2NwA/RVoOAYsZORh1vOEGjv1sbu9TaQZXaw7SaBMyGKNOZUz
=mn+W
-----END PGP SIGNATURE-----