Delame servery, jak to v enterprise nenajdete - dil I. (diskuse)

[luky]

U desktopu se da pouzivat na management Intel AMT.

[Dr. Zaba]

Nevidim nikde zmienku o UPS? Je zalohovanie napajania v rezii server housingu?

[snajpa]

Samozrejme, jinak to clovek muze mit doma ve sklepe :)

[A]

som myslel ze serverhosing je hlavne o konektivite a mesacnom trafficu, ktory v doma v pivnici (sklepe) nemas :)

[Monty]

Asi jak kdo

[Heron]

Ano, od datacentra dostanete dvě nezávislé napájecí větve, které jsou (by měly být) zálohovány UPSkou a dieslem. V každém slušné housingu vás těmito prostory rádi provedou a je to pěkná podívaná (já rád tisíce ampér). Ovšem, když se potom projdete po serverovně a kouknete se do okolních racků, tak i přes tuto ochranu je tam UPS požehnaně. Better safe then sorry.

[R]

A preto by mali mat servery redundantny zdroj, pripojeny na obe vetvy. V housingoch obcas robia nejake opravy a upravy, tak musia obcas jednu vetvu vypnut.

[SPM]

No nevim, obvykle když už, tak se ta jedna větev hodí na bypass, aby šlo manipulovat s UPSkou, ale vypnout jí úplně, to snad ne...

[xkucf03]

Taky si myslím. To by jinak museli mít jistotu, že všichni opravdu mají dva zdroje, oba jsou zapojené a nikomu zrovna jeden z těch dvou neodešel.

[R]

No u nas to oznamili dopredu a viac ich uz nic nezaujimalo...

[Käyttäjä 11133]

V každém slušné housingu vás těmito prostory rádi provedou a je to pěkná podívaná (já rád tisíce ampér).

No nevím, ale mám pocit že ve slušném hostingu to funguje přesně naopak... do restricted oblastí nepouštím lidi, kteří tam nemusí být. Je to jeden z požadavků bezpečnostní politiky každé rozumné normy pro zabezpečení datových center.

[Heron]

Jenže mě ujištění "máme to či ono", nestačí. Já to chci prostě vidět. Viděl jsem baterkárnu, viděl jsem transformátor, viděl jsem dva diesly, viděl jsem zásobníky hasiva. Samozřejmně není v mé moci skutečně prozkoumat, jak to mají zapojené, ale na rozdíl od některých datahausů to mají.

[Käyttäjä 11133]

Jenže mě ujištění "máme to či ono", nestačí.

Proto existujou normy, audity, auditoři a compliance. Samozřejmě tvrzení jsme Tier IV, je o ničem, ale prohlášení Uptime Institutu - byli jsme u návrhu toho datového centra, jeho stavby a pravidelně ho co půl roku kontrolujeme, že je opravdu ve shodě s normou Tier IV, je poměrně věrohodné. Mnohem věrohodnější, než vidět, že mají diesel, který vyzkoušeli naposledy před spuštěním produkčního provozu.

[Käyttäjä 11133]

Jinak už jen vědět, kde je zásobárna paliva pro to datacentrum je informace s kritickým dopadem na bezpečnost toho datového centra, protože v případě cíleného útoku na datové centrum to dává útočníkovi informaci o vhodném umístění nálože pro maximalizaci sekundárních explozí.

A ano, podobný útok na datové centrum jedné britské Tier 1 banky opravdu proběhl.

A dostat se do datacentra T-Systems UK, Barclays, HSBC, Lloyds, JPMC,... znamená týdny bezpečnostních prověrek. Pouštět jen tak kohokoli ke kritickým systémům, které mají vliv na dostupnost a spolehlivost celého datového centra, je bezpečnostní riziko, které by si měl každý spolehlivý operátor datových center odpustit. K čemu mi je ten 3m vysoký plot na perimetru, access control v prostorách datového centra, redundance kam se podívám, když pustím potenciálního zákazníka k hlavním rozvaděčům, kde stačí zmáčknout 2 tlačítka (FEED A, FEED B) a celé DC je ve tmě.

A nemusí se jen jednat o cílený útok, kolikrát člověk jen zakopne, nebo se omylem opře o nouzový vypínač. Znám případy jak cílených útoků, tak běžných lidských chyb, které vedly ke ztrátě dat i dostupnosti služby.

[Mrkva]

Security through obscurity? Od tebe? No teda...

[Mrkva]

Já měl pocit, že normy, audity, auditoři a compliance existují proto, aby byla práce pro pár zmrdů co si libuje v předpisech a ostatním akorát hází klacky pod nohy :)

[trekker.dk]

pravidelně ho co půl roku kontrolujeme, že je opravdu ve shodě s normou Tier IV

Jenom aby to nebylo "projdeme, jestli jsou v pořádku papíry o prováděných kontrolách"

[Jakub Lucký]

A hlavně(!) vybereme poplatek!

[Marv-CZ]

Skládačky mají jednu velkou výhodu ohledně RAIDu. Můžu si tam dát disky od různých výrobců. Zatímco v hotových sestavách jsou nejen stejné modely disku, ale i ze stejné výrobní série. A pokud je v ní nějaký problém, je vymalováno a ani RAID vás nezachrání.

[xkucf03]

+1 Jednou mi taky odešly dva disky v RAIDu skoro ve stejnou dobu (naštěstí se data ještě podařilo zachránit). Takže od té doby dávám disky od různých výrobců nebo aspoň různé modely/řady.

[Heron]

od různých výrobců

Od těch všech dvou? Je to peklo, dřív jsem měl v políčku 6 disků od 4 výrobců, dnes jsou to dva a je vůbec problém najít nějaký slušný disk.

[R]

Tiez je mi z toho smutno :( Daval som totiz do RAIDu 1 Samsung + Hitachi a ukazalo sa to ako velmi spolahlive.

[xkucf03]

jj, je to smutné, od těch dvou. Resp. někde mám kromě WD a Seagatu ještě Hitachi.

[snajpa]

Jaky jsou Hitachi disky? Myslim poruchovost, vykon a subjektivne? Jakou radu kupovat, kdyz chci 1TB 7200RPM?

[xkucf03]

Nemám příliš velký vzorek (pár kusů), takže to není moc směrodatné, ale osobní zkušenost co se týče spolehlivosti s nimi mám dobrou – přijdou mi nejlepší, na druhém místě WD a nejhorší Seagate.

[drunkezz]

Imo je tema hardwaru, tak ako ho popisujete, dost old-school. V tejto dobe vobec nema vyznam sa zaoberat len cisto hardwarom ako takym. Nedavno sme testovali u nas kvoli novym projektom najnovsi rack a blade class x86 HW (t.j Cisco UCS, HP G8, a ibm bol tusim nejaky hs20). Z hladiska HW to boli vsetko takmer identicke stroje, zostavou aj vykonom.

Rozdiel robil jednoznacne management software + dalsie ficury.

IBM toho vela nedokazal, HP bolo na tom urcite lepsie (Onboard administrator+VIrtual Connect+flexfabric), ale imo cisco bolo urcite najinovativnejsie. Napr k nodam(blejdam) sa tam pristupovalo skor logicky ako fyzicky, a nody poskytovali len HW pre to co mu management da. Inymi slovami vytvorim si profil, kde chcem minimalne 4xCPU N x Virtualny Ethernet (rychlost portu sa meni online) N x Virtualne HBA (rychlost detto) min tolko RAM a hotovo. Potom profil pripradim k nejakej volnej node, alebo to necham na management samotny. K samotnym blejdam nesli ziadne kable cize prakticky cely konnekt do chasi bol N x elektrika, N x ethernet uplink, a N x SAN uplink. VLANy VSANy sa vsetko dialo na centralnom nexuse. No proste nadhera.  ipmi je  hodne za opicami oproti tomu co dokazu enterprise class vendori.

D.

[cezz]

..len ta cena. Ale zalezi na use case. Ked si dostatocne velky cloud/vserver provider/user tak si vies tieto "naklikavacky" zabezpecit tym ze pozadovane (resp. najcastejsie pozadovane) konfiguracie mas dostupne ako triedy serverov ktore mas v DC k dispozicii. V takom pripade ti IPMI a podobne "za opicami" technologie v podstate stacia. A ano, mozes mat cudne poziadavky, ktore nie su bezne, ale potom je mozno lepsie zvolit najblizsiu vyssiu konfiguraciu a aj tak podlezies cenu HW potrebneho na dany node type s "blejdom". (a ako plus mas v niektorych parametroch rezervu) Plus teda vies softwarovou virtualizaciou rozdelit ten vykon na drobne ak je treba.

Ale ako vravim, vsetko je to o use case. Aj serverovy HW, aj desktopovy HW aj blade maju svoje miesto. Obcas sa to miesto najde celkom prekvapivo pre desktop-class HW v datacentrach (viz napr. Google)

[drunkezz]

Presne tak:)

ono v principe davam za pravdu ze desktop hardware je ok...pac co ho odlisuje od enterprise je to ze ventilatory fukaju ako besne a mozno (ozaj mozno) sa maticna testuje o trocha dlhsie....

D.

[gtz]

Však i SuperMicro dělá něco jako BLADE. Viděl jsem to v praxi a jako hodně použitelné pro menší firmy.

Nyní hodně rozhoduje cena. když tam člověk přijde s nějakým řešením např. FC hlava k tomu nějaký entry SAS to SATA, nějaký Qlogic switch apod. tak hodně firem na to nemá. Je pravda, že ceny tohoto řešení šly hodně dolů, ale když jim někdo nabídne 4U SM ve slušné konfiguraci tak jdou raději do toho řešení.

[cezz]

Celkom pekne riesenie ma aj Dell. Neviem presne kolko to stoji (a zavisi od konfiguracie), ale natlacis do 2U priestoru 4 servery (hotpluggable) spredu 12 klasickych SATA diskov (ktore si vies rozne priradit k jednotlivym strojom) a k tomu 2 zdielane zdroje. (co je podla mna dost zasadna vyhoda oproti desktop-class rieseniu - po diskoch je to IMHO najchybovejsia komponenta)

[gtz]

DELL měl vždy velice dobře udělané servery i pole. Pole většinou vypadaly jako DELL, ale ve skutečnosti to bylo přeznačené EMC. Cenově jsou zhruba stejně jako HP. Co vím tak 6620 s 2 x E5-2670 s 32GB + 1x 500 GB Sata stál minulý rok někde k 20 000€. Mně u DELLů hodně vadily ty jejich rámečky. Buď sis musel koupit redukci anebo tam narvat pouze jejich disk (většinou to býval brandovaný Seagate ES).

No já bych to řešil raději nějakým nadupaným 1U serverem, který by měl FC konektivitu. K němu bych pořídil nějaké pole FC/SATA s redundantním kontrolérem. Cenově to pak vyjde skoro stejně.

[Ruža Becelin]

Mně u DELLů hodně vadily ty jejich rámečky. Buď sis musel koupit redukci anebo tam narvat pouze jejich disk (většinou to býval brandovaný Seagate ES).

To byvalo u starsich ne? Ja mam PE2850 SCSI a 2950 SAS a ramecek je pouze zepredu a zboku. SCA je nekryty, takze se da pouzit jakykoli SCA/SAS disk. HP je na tom podobne, akorat oni maji na rameccich i velikost disku...

[Ondrej 'SanTiago' Zajicek]

S vyhodama desktopoveho hardwaru vcelku souhlasim, mam par poznamek:

- Co se tyce golden-rule" - "nejdrazsim minus jedna", tak tam bych ubral - high-end desktopovy hardware je IMHO akorat plny zbytecnosti (napr. ruzne nadstandardni radice ci tuningove featury), plne si vystacim s mid-range.

- Je opravdu remote management dulezity, nebo to je jen dusledek nevhodneho OS? Osobne bych to resil podobne jako u routeru - mit read-only system na flash (staci CF v PATA redukci, i kdyz dnes uz nove mainboardy casto PATA nemaji) s optimalizovanymi startovacimi skripty (tedy nemit tam nic, co by se mohlo rozbit) a to pouzivat jako 'hypervizor', servery pak pobezi na beznem OS v chrootu/virtualu/... z jineho disku.

- Nemate nahodou zkusenosti s consumer-grade hot-swap disk-enclosures, jako treba tohle: Chieftec SNT-2131SATA? Preci jen mit server bez hot-swap disku je dost otrava uz kvuli upgradum.

- Co se tyce profi hardware, setkal jsem se s nazorem, ze je poruchovejsi nez consumer-grade. Ono to dava i docela smysl - pokud maji vyrobci nizke marze, musi se dost snazit mit minimum reklamaci

[Sandokan]

K Chieftec SNT-2131SATA.

JJ, tuhle hračku myslím máme (možná ne přesně tento model), před nějakým časem to bylo jako část zálohovacího serveru (starý Fujitsu-Siemens P4, Centos, PCBackup) a rozhodně to přežilo použité disky. Teď je to odstavené, nahradilo se to malou krychličkou od HP, ale tehdy to účel plnilo celkem dobře.

Správně připomenuto, asi měl bych to zas oživit a použít.

Mimochodem, prima článek.

ZDAR!

[Martin Matějek]

- Je opravdu remote management dulezity, nebo to je jen dusledek nevhodneho OS? Osobne bych to resil podobne jako u routeru - mit read-only system na flash (staci CF v PATA redukci, i kdyz dnes uz nove mainboardy casto PATA nemaji) s optimalizovanymi startovacimi skripty (tedy nemit tam nic, co by se mohlo rozbit) a to pouzivat jako 'hypervizor', servery pak pobezi na beznem OS v chrootu/virtualu/... z jineho disku.

Je to o pohodlí a jistotě. Stejně jako autor zápisku si nemůžu remote management vynachválit a kdyby to šlo, tak si ho dám na servery, o které se teď starám (desktopový hardware). Pokud má člověk snadný fyzický přístup, tak to nehraje roli. Ale jestliže jsou špatně přístupné - serverovna ve sklepě kam je potřeba si dohodnout vstup předem, nebo vzdálené přes půl města nebo i víc, tak se remote management sakra hodí.

Když jsem potřeboval změnit ip adresu stroje na jinou za běhu (s přehazováním route a VLAN), případně s co nejkratším výpadkem, tak se přes remote management dá ledacos zachránit (např. když kvůli chybě v konfiguraci nestartovala síť). Nebo jsem nedávno šel přes půl města, abych ručně opravil ext3 oddíl protože systém nenastartoval a neměl jsem jistotu, že se nepokazilo ještě něco navíc (server z ničeho nic přestal reagovat na cokoliv kromě pingu a po restartu se nevzpamatoval).

[R]

A parada je remote management s emulaciou CD - potom sa da na dialku instalovat OS, pripadne robit aj zachrana pri rozbiti GRUBu. Debian netinst ISO (skoda, ze dementi zrusili businesscard) nabootuje aj cez pomalu linku a ostatne veci sa stahuju rychlo z internetu.

[Heron]

Je opravdu remote management dulezity

Je.

[Ondrej 'SanTiago' Zajicek]

Co trochu konkretnejsi odpoved - v kterych pripadech pomuze, kde by nepomohlo mou navrhovane reseni? Napada me akorat nekolik obskurnich pripadu:

- Rozbity mainboard ci CPU tak, ze CPU nebezi, ale remote management na samostatnem jednocipu funguje (nevim, zda to je realne a koneckoncu tam stejne clovek bude muset v takovem pripade zajit).

- Rozbita sitova karta (v pripade, ze remote management ma nezavisly port, nevim jak je to caste).

- Spatne nastavena sit (zde pomaha nepouzivat bezne startovaci skripty, takze pak clovek neskonci s tim, ze mu kvuli nejake banalni chybe nenabehne nic), kazdopadne tohle, predchozi pripad a par dalsich (probihajici DDoS) vcelku resi to mit v serveru nezavisly ethernet port z nezavisleho rozsahu jen pro ucely managementu.

- Moznost vzdaleneho restartu v pripade, ze se zblazni OS takovym zpusobem, ze userspace vicemene nefunguje, ale watchdog to neodchyti.

[xxx]

Poskozeny fs. Nemusi jit ani o data, staci nejaka zmrsenina v /tmp.

[Ondrej 'SanTiago' Zajicek]

Viz muj puvodni post - v pripade, kdy hypervisor (ci 'pseudohypervisor') bezi na readonly flash, je riziko poskozeni fs prakticky nulove.

[Heron]

Myslím, že odpovědi od Martina a R jsou dostatečné.

Dalším důvodem může být lidská chyba. Ať hodí kamenem ten, kdo nenapsal poweroff na jiném ssh terminálu, neshodil si na dálku síť, neučinil stroj nebootovatelným k vůli chybě v grub.conf atd. atd. V těchto případech je díky managovací kartě oprava rychlá stejně jako kdyby člověk seděl přímo fyzicky u toho počítadla.

[kyytaM]

Suhlas. Su veci, kde to kriticke nieje a su veci kde to kriticke je. Kazdopadne aj ak nema stroj nejaku formu IPMI, tak su tu este rozne ghetto style riesenia - napr KVM over IP + nejake napajanie, ktore sa da na dialku spinat (na tvrdy reset stroja).

[Heron]

nejake napajanie, ktore sa da na dialku spinat (na tvrdy reset stroja)

To bych také považoval za samozřejmost.

[Ondrej 'SanTiago' Zajicek]

Co se tyce lidske chyby tak budiz (i kdyz vzhledem k striktnimu oddeleni 'hypervisora' a bezneho serverovskeho software se to riziko dost minimaluzuje a editovat grub tam uz nedava zas tak moc smysl).

Pokud uz nekdo ma v serverovne cely rack, tak proc radsi nemit terminal server, ktery umozni management serveru pres seriovou konzoli a vzdaleny reset/poweroff, nez mit v serverech potencialni bezpecnostni diru, jakou je IPMI?

[Heron]

Co se tyce lidske chyby tak budiz (i kdyz vzhledem k striktnimu oddeleni 'hypervisora' a bezneho serverovskeho software se to riziko dost minimaluzuje a editovat grub tam uz nedava zas tak moc smysl).

Ano, ovšem ne všechny servery na sobě nesou (mohou nést) hypervizora. Na spoustě HW potřebujete mít OS.

Pokud uz nekdo ma v serverovne cely rack, tak proc radsi nemit terminal server, ktery umozni management serveru pres seriovou konzoli a vzdaleny reset/poweroff, nez mit v serverech potencialni bezpecnostni diru, jakou je IPMI?

Proč bezpečnostní díru? Na to IPMI se dostanete jedině z IPsec / OpenVPN sítě a k tomu zase potřebujete klíč. Úplně stejně na tom bude ten případný terminal server.

[Ondrej 'SanTiago' Zajicek]

Ano, ovšem ne všechny servery na sobě nesou (mohou nést) hypervizora. Na spoustě HW potřebujete mít OS.

Nejsem si jist, zda reagujes na mou puvodni otazku, ta neznela zda je dobre mit remote management na serveru z beznym OS, ale zda vhodnost remote managementu neni spis dusledek soucasnych 'nespolehlivych' OS, tedy pokud by byl system od zakladu postaven se spolehlivosti jako s jednim z primarnich cilu (vcetne napr. dusledne oddeleni 'hypervisora' a 'aplikacniho' software), pak by vyznam takoveho managementu byl podstatne mensi.

Proč bezpečnostní díru? Na to IPMI se dostanete jedině z IPsec / OpenVPN sítě a k tomu zase potřebujete klíč.

Vychazim z dvou bodu (AFAIK):

1) IPMI sam o sobe neni vyznamne zabezpeceny, zabezpecit je tedy treba primarne management port. Takove reseni je vetsinou dost problematicke. Nerikam, ze to nejde udelat dobre, ale je tam spousta mist, ktere mohou selhat. Pokud mam rack, v nem vlastni nezavisly switch jen pro management pro management porty a k tomu vlastni vyhrazeny VPN server, pak OK, v typickych aplikacich (napr. kdyz ma jen jeden server) se tam asi clovek bude spolehat na daleko vic dalsich promennych.

2) Software bezici na BMC je proprietarni, je tedy otazka, jak moc se mu vubec da duverovat.

[Radek Hladik]

Dodám ještě jednu zajímavou věc, supermicro IPMI poměrně bez problému podporuje IPv6 včetně linkových adres. Jinak řečeno, pokud máte vlastní ethernetový segment pro management, pak vám stačí znát MAC adresu BMC a mít v té síti nějaký stroj(e), na který se dá přes SSH/VPN dostat... Na straně BMC není potřeba žádná konfigurace síťování...

A je to i poměrně pohodlné, protože vám na stole "přistane" nový server, stačí mu připojit síť, napajení a bez nějakého nastavování se na server dostanete....

[pavlix]

Už dlouho říkám, že linkové adresy jsou na IPv6 to nejlepší :).

[rADOn]

Co trochu konkretnejsi odpoved - v kterych pripadech pomuze…

To je asi stejná otázka jako "co se rozbije příště". Pokud máš dopředu naplánované poruchy disků, nepotřebuješ disková pole. Pokud víš kdy bude problém se zdrojem, nepotřebuješ redundantní napájení. Et cetera… Pokud víš kdy budeš příště potřebovat židli a KVM, nepotřebuješ management karty.

Příklad ze života: Kdysi na casablance zdechla klima a celý horní patro se nažhavilo jako pec. Ne tolik aby všechno rovnou popadalo, ale dost na to aby mašiny začaly náhodně zatuhávat. Právě tehdy jsme našeho šetřivého šéfa přesvědčili že pár tisícovek na mangement kartu je lepší investice než platit lidi za to že jedou stopadesát kilometrů, zmáčknou reset a jedou zpátky. Nebo než nedejbože čekat až se pan Hampl milostivě uvolí ten čudlík zmáčknout sám. (Doma stavěné towery bez ecc pamětí určitě měly problémy podstatně větší a výrobci disků v následujících měsících taky neměli špatnej kšeft.)

[Ondrej 'SanTiago' Zajicek]

Pokud máš dopředu naplánované poruchy disků, nepotřebuješ disková pole. Pokud víš kdy bude problém se zdrojem, nepotřebuješ redundantní napájení. Et cetera… Pokud víš kdy budeš příště potřebovat židli a KVM, nepotřebuješ management karty.

No, poruchy disky ci zdroju je problem z realneho sveta, kteremu se moc vyhnout neda, takze redundance jako reseni je rozumne. Oproti tomu 'je potreba zidli a KVM' je vicemene umely softwarovy problem, ktery v prevazne vetsine pripadu by sel snadno odstranit rozumnym navrhem software (resp. zajistit, aby v takovem pripade krome KVM konzole sla pouzit i sitova konzole). Remote management (specificky tedy spis remote KVM) je proste takovy rovnak na ohybak.

Ne tolik aby všechno rovnou popadalo, ale dost na to aby mašiny začaly náhodně zatuhávat. Právě tehdy jsme našeho šetřivého šéfa přesvědčili že pár tisícovek na mangement kartu

A nestacilo by proste zapnout watchdog? Ten je dneska standardni soucasti superIO chipu, a pokud neveris internimu, lze poridit externi za par stovek.

[pavlix]

Remote management (specificky tedy spis remote KVM) je proste takovy rovnak na ohybak.

S tím souhlasím.

[rADOn]

Taky souhlasím Ale moje pointa nebyla že je potřeba nažhavit hlídacího psa, ale že se hodí být připraven na neočekávané problémy. Problémy které vyžadují wetwarový zásah budou existovat tak dlouho dokud budeme stavět počítače z baryonní hmoty. Ergo pokud nemůžu mít železo u sebe tak mě nenapadá lepší řešení než nějaký ten narovnávák.

BTW silnější povahy nechť si všimnou že nahození hw watchodga nemá žádnou souvislost s navrženým řešením. Slabší povahy by mohly míti špatné spaní z hrůzné představy že existuje něco co nejde virtualizovat :-P

[trekker.dk]

A nestacilo by proste zapnout watchdog? Ten je dneska standardni soucasti superIO chipu, a pokud neveris internimu, lze poridit externi za par stovek.

Akorát za pár stovek pořídíš i to ipmi (pokud v tom serveru už není.) S výhodou, že že se můžeš podívat, jestli na obrazovce nezůstal nějaký výpis kernel panic

[xkucf03]

Je opravdu remote management dulezity…

Případně se to dá řešit pomocí null modemu a propojení dvou serverů. Akorát ti nesmí odejít oba najednou a musíš si vystačit se sériovým portem (což se celkem dá: GRUB, GNU/Linux i některé BIOSy/Coreboot).

[Ondrej 'SanTiago' Zajicek]

To je vtipne. A s nejakym udelatkem by clovek mohl pres signalni draty v null modemu ty servery i vzajemne restartovat ci vypinat.

[XYZŽ]

Závisí na na množství serverů -- nad určité množství i zdržování se sejitím do serverovny o pět pater (aby se po sériové konzole zjistilo, že server opravdu nestartuje, protože při dvoutýdenním vypnutí před likvidací odešly paměti -- skutečný příklad hned u dvou kusů ze čtyř-uzlového clusteru -- co kdyby měly nulový modem vůči sobě :-o ) a zpět znamená nežádoucí zdržení -- a hlavně, pokud by tam externí konzole nebyla, jak by se to zjistilo? Ten počítač samozřejmě nemá monitor ani klávesnici, jen sériový port a vzdálenou konzolu ...

Uznávám, že jde asi o atypickou velikost (řádově tisíce serverů, možná deset tisíc). Zase ale těch nejneuvěřitelnějších problémů, které člověk vidí jak ze strany obsluhy na první úrovni, tak i ze strany OS (Linux z unixových docela často), doplňků do OS i aplikací, tak RM je skutečně nezbytností.

[xkucf03]

Je to samozřejmě amatérské řešení… ale v určitou chvíli za to může být člověk vděčný a svoji práci to odvede – např. můžeš mít opravený zavaděč/síť a nabootováno dříve, než bys vůbec stačil zavolat technikovi, aby ti připojil jejich KVM.

[User682]

zdravim,

pekne cteni.

>Po par letech provozu je puvodni high-end desktopovy hardware porad >nadprumerny desktop - kdo z vas ma doma quadcore Nehalem Core i7 s 24GB RAM?

Toto je velmi prakticke. Neda mi to odpovedet. Zatim je na desktopu Phenom x6 s 16GB RAM. Bohuzel jsem zjistil, ze dalsi stroj bude uz asi dual Opteron (2x16 core) a 32GB RAM. Mezikroky nemaji uz moc smysl. Az nebudu vedet, co s 50 litrama, tak do toho jdu. A taky az zjistim, ze jsem si zase dlouho nic nekoupil.....

gf

[A]

Co na tych pocitacoch robite? Ja neviem co s 1GB RAM a dvojjadrovym Atomom....

[User682]

Staci udelat nejaky vetsi build/preklad C/C++/Java.

[Heron]

Tak s tím bych si také nevěděl rady.

Odpověď je celkem jednoduchá:

$ dd if=pack-d0975dc1d1667ecd904faaf20e75a8d4b5aed293.pack of=/dev/null
8985756019 bytes (9.0 GB) copied, 40.4833 s, 222 MB/s

$ dd if=pack-d0975dc1d1667ecd904faaf20e75a8d4b5aed293.pack of=/dev/null
8985756019 bytes (9.0 GB) copied, 1.5159 s, 5.9 GB/s

32GB paměti se hodí, protože i když můžete mít SSD disk o rychlosti čtení (tohle je starej disk) i 500MB/s, tak z paměti je to pořád více než 10x rychlejší. Nejlepší použití paměti je jako IO cache.

[erino72]

Ja mam 3GB ram a casto mam problem s nedostatkom a to mam len bezne veci. Nejake IDE, prehliadac, hudbu...

[Rezza]

No asi tak - nejak moc nepoznam rozdil mezi jednojadrovym Atomem s gigem ramky a 4 jadrovym i7 s 8 gigem pameti... Alespon pro bezne pouziti, no a i ty buildy uz se na tom daji delat. Kdyz vzpomenu na davne doby :)

[Jan Grmela]

No uprimne si nedokazu uz predstavit ze bych pracoval na necim slabsim nez ekvivalentu moderniho dualcore na 1.2 GHz s mene nez 4 GB RAM. A to delam v podstate jen kancelarskou praci

Ted mam v praci 1.7 GHz i5 s 8 GB RAM a SSD a je to uz docela prijemna prace.

[Jendа]

To máš dobrý, mně Firefox, Thunderbird, OpenOffice, GIMP a možná nějaká virtualizace 2 GB zaplní, možná by zaplnily i 4.

[R]

Firefox, Thunderbird a OpenOffice zaplnia lubovolne mnozstvo pamate a na lubovolne rychlom CPU vedia byt nepouzitelne pomale.

[bada]

Zalezi na tom co delas.... na xichtoknizku takove prditko atom staci. Treba poustet virtualni masiny na tom ani nema smysl zkouset. Dalsich prikladu je spousta - namatkou treba uprava fotografii, hry, databaze, co mi tak napada.

[pavlix]

Treba poustet virtualni masiny na tom ani nema smysl zkouset.

Já jsem na něčem takovém, akorát se 3GB RAM, dělal školení, kde každý z účastníků měl k dispozici dva své vlastní virtuály.

[Milan Beneš]

Ad Supermicro hate:

jen bych rád podotknul, že servery jedeme prakticky jenom Supermicro, poměr cena výkon je opravdu fajn. Musím ale přiznat, že je jsem slyšel i názory lidí, kterým se Supermicra sypou. Z mého pozorování plyne, že dost potíží bylo se stroji typu Opteron do socketu F, tyhle starší stroje občas vytuhnou. Situace se taky hodně zlepšila od doby, kdy začalo Supermicro dělat AMD desky se síťovkama od Intelu, ty nVidie, co tam dávaly před tím, to byl mor, filcky, svrab a neštovice... všechny tyhle servery mají u nás píchnutou intelí síťovku do slotu.

Jinak FatTwin je miláček, jen mě u tak promyšlený mašiny zarazila tak podivně umístěná baterka + jumper...

[snajpa]

Jj, souhlasim. Jeste jsem slysel z doby dlouho pred tim, nez bylo vpsFree zalozene, ze se driv Supermicru nedarilo delat zdroje a odchazely. Co je na tom pravdy nevim, dneska uz to problem neni.

[PetrHL]

Diky, diky, diky. Zrovna resim neco podobneho. Mam hobby projekt, ktery ma snad potencial se rozrust. Mesicne je navstevnost neco pres 30k lidi a pres 250k shlednuti stranek. Web je napojen asi na 5GB DB. Zatim to mam na VPS s 3GB RAM, ale nestiha tam disk. S DB se intenzivne pracuje.

Premyslim o poskladani takoveho "serveru" z desktop komponent a umisteni nekam do datacentra. Mam nabidku na umisteni do male serverovny jednoho znameho, ale je to ode mne asi 150km bez moznosti nejake KVM a pod. Z toho mam strach.

Projekt dotuji z vlastniho, prispevky uzivatelu + google adsence na provoz nevydelaji ani nahodou. Proto bych uvital co nejnizsi cenu housingu. Na druhou stranu bych nerad aby dochazelo k vypadkum. Zatim se mi dari drzet velice dobrou dostupnost a restartuji jen az uz je to opravdu potreba a nejde to jinak. Uzivatele si to pochvaluji .

[User682]

zdravim,

o Vasem projektu vim a dost mozna ze znam Vaseho kolegu ok1rr.

Jen se zeptam: Kolik mate velikosti database ? Delali jste nejake optimalizace v DB ?

V podobnou navstevnosti mam zkusenost. Ale je dost mozne, ze mate podstatne vice vypoctu v DB.

gf

[PetrHL]

Dobry den,

Martina znate, vim o tom.

Adminer pise toto: velikost dat: 3 859 423 864, velikost indexu: 2 540 447 744. Delal jsem optimalizace nastaveni cache pro MySQL a take jsem menil nastaveni pri zapisu. Po commitu se nezapisuje primo na disk, ale jen cache OS, ktery se o zapis na disk postara. Do DB se skoro neustale zapisuji nejaka data. Importuji se data od uzivatelu, data z telnetu a jinych zdroju.

DB by asi sla navrhnout lepe (to asi vzdy), ale nevim jestli by se to nejak extra projevilo na vykonu. Kdyz se ohlednu zpet, asi bych nektere tabulky trochu rozdelil, ale jinak asi nic extra. DB nic moc nepocita, neni moc co, slouzi pouze jako uloziste dat. O doplneni pred ulozenim se staraji externi programky (importy dat od uzivatelu, telnet).

Petr

[User682]

Zajimava uloha. Dal jsem rec s kolegou databasistou, co umi vice nez ja okolo databasi. Napisi par veci, co by mohly pomoci:

- omezit pocet konkurencnich zapisu do DB. Zapisuju z jednoho mista. Z jedne tridy/konnektoru. Zbytek ceka ve fronte.

- zapis do docasne tabulky a pak INSERT INTO SELECT z docasne tabulky do skutecneho umisteni.

- misto dlouhych insertu kratke (zapis dotazu) nebo copy prikaz

- zapis dat pomoci specialnich datovych typu pro GIS, souradnice, body,..., pokud to database umi.

Kazdopadne dejte vedet pres muj soukromy email vedet, jak to dopadlo. Nejefektivnejsi bude nejspise prvni bod.

diky gf

[Tomáš Srnka]

- omezit pocet konkurencnich zapisu do DB. Zapisuju z jednoho mista. Z jedne tridy/konnektoru. Zbytek ceka ve fronte.

Ak pouziva InnoDB, tak toto by malo byt skoro jedno.

[PetrHL]

To omezeni zapisu z vice zdroju moc nevim jak udelat. Data do DB smeruji pernamentne ze dvou mist a to do ruznych tabulek. Obas se prida misto treti a ctvrte. Jsou to ruzne sluzby s ruznymi zdroji dat. Neco zapisuje webovy script, neco externi programy.

Ten insert do docasne tabulky by mozna sel. Pak bych na to ale pri cteni musel myslet nebo udelat podhled a pouzivat pro cteni ten. Inserty jsou kratke, zatim import z externich zdroji resim vytvorenim cache, kde ukladam zaznamy a az se jich nasklada vice, udelam StartTransaction, nasypu je tam a pak zavolam Commit. To taky hodne pomohlo.

Mne tento problem na VPS trapi uz dlouho, delal jsem kvuli tomu ruzne vylomeniny, ale uz mi dochazi napady. V DB je v ruznych tabulkach kolem 20M zaznamu. U veci, o kterych vim, ze budou potreba casto, uz mam predpripravene ve zvlastnich tabulkach. Ta data se generuji narazove pri importu dat uzivatelem.

Jestli se mi na novy stroj podari pumpnout rodinny rozpocet, bude to zase veselejsi. Tedy ta databaze a web, manzelka asi mene .

Je to vsechno nad Mysql 5.5 a InnoDB.

[User682]

Jeste jsem zapomel jednu vec, co mi hodne pomohla vykonove u par projektu, ale budete ji nejspise znat.

PreparedStatement se to jmenuje v Jave. Jinde to bude podobne.

gf

[PetrHL]

Ano, znam a pouzivam. Pri importech velkych baliku dat to dost pomaha.

[Honza Jaroš]

Řešil jsem něco podobného u Zabbixe v trochu rozsáhlejší síti, po přechodu z (omylem používaného) MyISAM na InnoDB začal chvílemi dělat disk psí kusy. Nejdřív jsem šel do jisté míry podobným směrem jako radí pan Kysilka (mezi klienty a server jsem nasadil proxy, která to pak serveru cpala jednou za pár minut dávkově), ale ve finále se ukázalo, že nejlepším řešením byl přechod na PostgreSQL, který se mi vůči disku chová mnohem ohleduplněji než MySQL. Samozřejmě je možné, že jsem měl jen někde něco špatně nastavené, nicméně moje pokusy o optimalizaci nepomohly, zatímco u Postgresu jsem prostě jen využil několika tipů od Herona a problémy zmizely. Takže můžete zkusit pouvažovat i tímto směrem, pokud je to ještě možné...

[PetrHL]

Nad tim jsem taky uvazoval. Jen mam strach jak se ty neustale inserty, pripadne delete projevi. Netusim jak casto by se spoustelo VACUUM. Aby to nebylo jeste horsi.

Tu appku jsem si psal sam, nejsou tam zadne slozite SQL dotazy, jen nejake joiny a par insert into ... on duplicate key update ... . Dale dva pohledy pouzivane pouze pro mne, aplikace je nepouziva. Mozna nejaky trigger, ale to PostreSQL umi lepe jak MySQL.

Dalsi nevyhodou pro mne je neznalost Postresu. Vim o nem jen velice malo. Sice bude dost veci spolecnych ale i tak. Musim to nejak otestovat. Vyber a sestaveni noveho stroje bude chvilku trvat, mohl bych tu appku prepsat tak, aby vyuzivala PostreSQL.

[Honza Jaroš]

Tak to vám neřeknu. Teď jsem koukal na trošku menší server u jednoho zákazníka, kde to každou hodinu odmaže kolem 73000 záznamů a přibližně stejný počet zapíše (většinou číselné hodnoty), a tam vypadá log asi takhle:

monitoring / # cat /var/log/syslog | grep -i vacuu
Feb  1 23:23:03 monitoring postgres[512]: [3-1] LOG:  autovacuum launcher shutting down
Feb  1 23:23:19 monitoring postgres[504]: [1-1] LOG:  autovacuum launcher started
Feb  2 02:28:53 monitoring postgres[504]: [2-1] LOG:  autovacuum launcher shutting down
Feb  2 02:31:10 monitoring postgres[512]: [1-1] LOG:  autovacuum launcher started
Feb  6 08:17:11 monitoring postgres[512]: [2-1] LOG:  autovacuum launcher shutting down
Feb  6 08:17:28 monitoring postgres[505]: [1-1] LOG:  autovacuum launcher started
Feb  6 08:17:42 monitoring postgres[505]: [2-1] LOG:  autovacuum launcher shutting down
Feb  6 08:17:54 monitoring postgres[497]: [1-1] LOG:  autovacuum launcher started
Feb 17 11:20:02 monitoring postgres[497]: [2-1] LOG:  autovacuum launcher shutting down
Feb 17 11:20:24 monitoring postgres[505]: [1-1] LOG:  autovacuum launcher started
Mar  5 08:20:53 monitoring postgres[505]: [2-1] LOG:  autovacuum launcher shutting down
Mar  5 08:23:33 monitoring postgres[512]: [1-1] LOG:  autovacuum launcher started
Mar  7 10:13:55 monitoring postgres[611]: [1-1] LOG:  autovacuum launcher started
Mar  9 09:00:01 monitoring postgres[611]: [2-1] LOG:  autovacuum launcher shutting down
Mar  9 09:02:10 monitoring postgres[513]: [1-1] LOG:  autovacuum launcher started
Mar  9 09:13:27 monitoring postgres[513]: [2-1] LOG:  autovacuum launcher shutting down
Mar  9 09:13:36 monitoring postgres[504]: [1-1] LOG:  autovacuum launcher started

Ale samozřejmě je otázka, nakolik je tohle srovnatelné s vaším použitím...

[Honza Jaroš]

Moment, zpět, tohle to píše při restartu. Takže informace o spouštění vacuum asi v logu nemám...

[PetrHL]

Pokud uzivatel importuje svoje data, muze dojit k tomu, ze z DB zmizi klidne 160k zaznamu a behem par minut zase pribude. Pak je ale treba chvilku klid nebo dalsi importy uz nejsou tak velke. Zalezi na tom, ktery uzivatel tam zrovna data chce nasypat.

K te navstevnosti jsem zapomnel jeste pripocitat pristupy pro programy pres XML rozhrani. Poslou si GET request a dostanou data v XML. Denne je takovych pozadavku kolem 30k o vikendech tak 50 az 60k. Rekord byl 100k pozadavku pres XML za den. Je to ale velice rychle, prakticky se jedna jen o cteni, zapis probiha pomoci insert into on duplicate key update a je velmi rychly, protoze tabulka se statistikou ma asi jen 100 zaznamu.

[Radek Hladik]

Nový postgres má zajímavou featuru: unlogged tables. Za cenu nemožnosti použít transakce a ztráty dat při nestandardním ukončením serveru, získáte vyšší rychlost a menší náročnost na disk. (viz např: http://rhaas.blogspot.cz/2010/05/global-temporary-and-unlogged-tables.html ).

Mám tabulku, kde potřebuju mít "cache" údaje, které jsou po pár minutách neaktuální. Prostě jeden zdroj tam pravidelně cpe stav a ostatní si berou aktuální stav. Začal jsem s memory table u MySQL a zatím se po pár týdnech testování zdá, že PostgreSQL s unlogged tables je nejlepší volba...

Ale pro někoho může být problém, že když db spadne, nebo jí něco killne, tak o data přijde...

[rADOn]

Říkej tomu memcache s tabulkami…

[Radek Hladik]

No hlavně i se skoro kompletním SQL...

[PetrHL]

Diky za informaci, kdybych to potreboval, vyuziju to. Data, ktera ukladam do pomocnych tabulek, maji delsi platnost. Dokud uzivatel nenaimportuje aktualnejsi data, hodnoty se z nich pouzivaji na tvorbu statistik. Je to rychlejsi a setrnejsi k serveru nez s kazdym nactenim stranky ta data znova dolovat z DB.

[sigma]

Kde v ČR kupovat Supermicro servery? Zatím jsem vždycky koukal jen na konfigurátor Abacusu, a ceny mě teda nepřesvědčily. Nebo se z nich ještě dá dohodnout rozumná sleva?

Vždycky se mi povedlo dostat na cenu nižší o 5 - 20 % za podobnou konfiguraci od HP nebo DELLu. Samozřejmě jako projektovou cenu přes obchodníka / distributora, od kterého bereme i nějaké desktopy (ne moc, řekněme v průměru 200k / rok). Na list ceny HP nebo DELLu, co mají na webu, nemá smysl koukat - dostáváme se tak o 35 až 60 % níž. Posledně jsem nově zkoušel poptat nějakého distributora HP z polska, co má i český web, a bylo to taky tak.

Např. v 11/2012 jsem kupoval od DELLu R420 - 1U, E5-2420, 24 GB RAM, HW RAID 512MB + BBU, 4 × 300 GB SAS 10k HDD, case na 8 2.5" HDD, redundantní zdroj. Cena asi 66k s DPH. Nevím, jestli by to bylo u Supermicro za X/2.

Velké rozdíly mezi výrobci bych viděl v implementaci IPMI/BMC. Můžu srovnat pár posledních generací u HP, a poslední u DELLu - ta je výrazně nejlepší. Třeba při sdílení ethernet portu pro BMC s vlastní VLAN to umí failover mezi dvěma interními eth porty, nebo je přes BMC vidět stav a konfigurace RAIDu.

[snajpa]

Napis mi na mail a hodim ti kontakt primo na naseho obchodnika z Abacusu, se kterym se vzdycky da dobre dohodnout (muj mail: snajpa @ snajpa .net)

[bibri]

V Dellu se teď hodně snaží a občas umí nabídnout i lepší cenu než Abacus - tolik mé zkušenosti za poslední půlrok...

[vencour]

Ohledně terminal serveru mam dobrou zkušenost s Digisysem ... uměj 1-32 portové.