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

Thu Feb 9 01:13:03 CET 2012

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:

> -----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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20120209/ea2a1ca9/attachment.sig>