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

Thu Feb 9 14:00:16 CET 2012

Ahoj,

pokial nechceme riesit rozne ine platformy nez Linux, ostal by som pri
openVZ, je to zabehnute a z toho co si pisal ->
>> OpenVZ team vydava primo oficialni RHEL kernel, ktery prochazi jejich
>> labem, na ktery maji napsane svoje testy (o 1000% odladenejsi, nez
>> Debianni podani OpenVZ)

tak s tym RHEL to moze byt pre nas velka vyhra ;)


On 02/09/2012 01:43 PM, Pavel Snajdr wrote:
> 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
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20120209/6983464d/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 294 bytes
Desc: OpenPGP digital signature
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20120209/6983464d/attachment.sig>