8 Feb
2012
8 Feb
'12
11:57 p.m.
-----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-----
9 Feb
9 Feb
12:13 a.m.
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(a)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(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
12:15 a.m.
-----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(a)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(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
>
>
_______________________________________________
Community-list mailing list
Community-list(a)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-----
1:16 a.m.
New subject: Zajimave/dulezite cteni: Jak bude vypadat konfigurace nasich serveru dal, Q&A session
Díky za pěkné počtení, konečně mám trochu více jasno o aktuálním stavu a blízké
budoucnosti.
-----Original Message-----
From: community-list-bounces(a)lists.vpsfree.cz
[mailto:community-list-bounces@lists.vpsfree.cz] On Behalf Of Pavel Snajdr
Sent: Thursday, February 09, 2012 12:57 AM
To: vpsFree.cz Community list
Subject: [vpsFree.cz: community-list] Zajimave/dulezite cteni: Jak bude vypadat
konfigurace nasich serveru dal, Q&A session
-----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(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
--
This message has been scanned for viruses and dangerous content by MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
10:37 a.m.
Vdaka za zaujimave informacie, Z nas sa o virtualizaciu zaujimas najviac,
takze asi aj vies co bude vyhodnejsie :)
2012/2/9 Pavel Snajdr <snajpa(a)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
--
Erich Stark
-----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(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
12:31 p.m.
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(a)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(a)jabbim.sk
12:43 p.m.
-----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(a)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(a)jabbim.sk
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
-----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-----
1 p.m.
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:
--
S pozdravom / Best regards
Peter Bubelíny
PGP key: http://goo.gl/ic2Wc
Jabber: peter.bubeliny(a)jabbim.sk
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(a)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(a)jabbim.sk
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
14 Feb
14 Feb
2:22 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Tak jedna zmena se precijenom kona -
mluvil jsem s lidma z datacentra a s lidma od dodavatele ohledne toho
nesediciho TDP;
pro klid duse budeme stavet 2U systemy. Co se tyce mista -> ceny -
rozdil je asi 800 Kc, co pro klid na dusi rekl bych radsi dame, nez
setrit za kazdou cenu.
Takze servery mely byt v Brne uz pristi tyden, ale to asi nebudou,
pocitam ze se to zdrzi o tyden, kvuli cekani na 2U bedny.
Pavel Snajdr
+420 720 107 791
http://vpsfree.cz
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(a)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/
iF4EAREIAAYFAk86bhoACgkQdh+64ds5DaYzJgD/WAlGOoKWO8VdFDU1rdD31Hhd
O+xHV6/adt9iq4NekTMBAPJEyrEudjOAly8X0Q0iFhJ7xWlkal6rHFwOswz5r/15
=8h8W
-----END PGP SIGNATURE-----
4476
days inactive
4482
days old
community-list@lists.vpsfree.cz
8 comments
5 participants
participants (5)
-
Erich Stark -
Pavel Snajdr -
Peter Bubelíny -
Tomas Volf -
Václav Blahout