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

Thu Feb 9 13:43:07 CET 2012

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

Ahoj,

no, nevim, co s tim KVM. Jsem z nej dost zklamany.

To uz i ten Xen je lepsi... (ale ma nejistou budoucnost a mizernou
dokumentaci, navic RH upustil od podpory dom0).

Pavel Snajdr

+420 720 107 791

http://vpsfree.cz

On 02/09/2012 01:31 PM, Peter Bubelíny wrote:
> Ahoj,
> 
> Suhlas -> do buducna to vyzera super. Takze od KVM ideme definitivne
> upustit?
> 
> On 02/09/2012 12:57 AM, Pavel Snajdr 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
> 
> -- 
> S pozdravom / Best regards
> Peter Bubelíny
> PGP key: http://goo.gl/ic2Wc
> Jabber: peter.bubeliny at jabbim.sk
> 
> 
> 
> _______________________________________________
> 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/

iF0EAREIAAYFAk8zv1kACgkQdh+64ds5DaYMuwD+KUmAdACM/imMsQgcqS/abYcs
lyalWhrBd7PQ/4sJbTkA9ipbqdUbRwmUvrz4hihVg/O/c9YgrbUEub7wGn/8ECI=
=S0gK
-----END PGP SIGNATURE-----