Server - díl první - (Síťové) Filesystémy - EDIT (diskuse)

[kozzi]

Nazdar martine treba ti to pomuze: http://www.abclinuxu.cz/blog/Debian_Skystar2_mplayer/2006/9/22/151030

http://linuxgazette.net/102/piszcz.html

[Ivanhoej]

Ano prave som to chcel napisat(chystam sa vacsi test ale neni casu), s JFS mam velmi dobre skusenosti, je to minimalne tak rychle ako Reiser no spolahlivejsie (podla ludi, dost ich malo s Reiser problem pri zaplneni disku)

Pri vymene ext3, XFS za JFS je citelne rychlejsi nabeh aplikacii na desktope. Na servere vsak mam stale etx3.

[EiFFeL]

JFS taky pouzivam a nemuzu si stezovat, sice ne na serveru, ale pouze na desktopu, take predpokladam ze server bude mit zalozni zdroj energie, coz bych pote na partisnu s daty uvazoval o XFS, kde neni problem se zvetsenim/zmensenim (zvetsit lze i primo za chodu bez nutnosti odpojeni)

[al-Quaknaa]

Hmm, tak tohle jsou dobré připomínky - o JFS jsem si vždycky myslel, že je na tom jako XFS - dobrý filesystém pro databázi a spolehlivý, ale že by byl i rychlý ;) Dík za doporučení.

[tomasgn]

- mirrorovat - zalohovat - co nejvic filesystemu dat na LVM - jak systemove (/usr, /var, /tmp, /opt, /home) tak vsechny aplikacni a datove.

[al-Quaknaa]

V čem je výhoda LVM, když by se disk na serveru (v mém případě) měl rozdělit a nechat, jak je (a potom jenom nasdílet v případě přírůstku serveru)? LVM jsem používal, ale nevím, proč přidávat další vrstvu - ačkoliv to moc výkonu asi nesebere, tak minimálně další vrstva, která může selhat. A k mirrorování - myslíte ten SW RAID, který jsem uváděl? Každopádně díky za přípsěvek :)

[Jary]

Pak asi jenom v zálohování. Uděláš snapshot a v průběhu zálohování za snapshotu si systém žije svým vlastním obvyklým životem.

[deda.jabko]

raid vs. zalohy - nejsou zamenitelne kategorie... osobne doporucuji kombinaci obojiho, protoze raid snizuje riziko, ze system selze po hardwarove chybe, zalohy se zase postaraji o opravy, kdyz nejaky exot smaze cast disku (staci jedna blba tecka ve skriptu navic... vim o tom sve ;-] )

premyslet nad sdilenymi fs me pripadne v tento okamzik jako zcestne... nejdou me k sobe dve veci... reseni na bazi LAMP a k tomu snaha o pripadnou maximalni dostupnost.

otazka zni, proc budovat cluster?

+ strach z toho, ze to server nebude zvladat/bude chybet kapacita... to jde resit efektivne pomoci stavajiciho hardwaru (nacpat jedno tera mirrorovany disku do pocitace uz neni problem a rozdelit jednotlive sluzby na jednotlive servry taky neni nic extra tezkeho)

+ pozadavek na high availability... je to vubec potreba? oceni to nekdo... je to urcita komplikace, ktera muze dostupnost servru jeste vic komplikovat. pokud je to opravdu nutne... je dobre se zamyslet nad navrhem aplikace a pripadne, jeste pristoupit ke kroku jedna.

[al-Quaknaa]

Ještě k těm zálohám - doporučil byste mi vytvořit další oddíl na zálohy? Protože mít zálohy právě v tom disku, který může být onou nešťastnou náhodou smazán, přeci jenom není tak chytré, ne?

Snaha o maximalní dostupnost - to, co mě na pipni.cz vždycky tak štvalo, bylo to, že jim prostě vypadne server, neběží půl hodiny, hodinu, dvě, půl dne ... a nikoho to neštve. Ano, mají to ošetřené, takže další servery jedou v pohdoě (toho bych chtěl taky dosáhnout), ale dá se tohle dělat jenom s NFS/jak si myslíte, že j eto dělané?

Jak nacpat jedno terra mirrorovany? Další řadiče? Celkem by mě to zajímalo - do současné doby jsem se zajímal jenom desktopy, takže když jsem viděl desku, na kterou je možno připojit 6 PATA disků a 6 SATA disků, tak se mi to líbilo (teda - ne že by to někdo na té desce využil, je to jenom desktopová deska s PATA a SATA řadičem navíc ...). High avaivibility - myslíme tím spolehlivost/dostupnost serveru? No, myslím, že ta je hoděn důležitá, ne? Viz zmínku o pipni.cz ;)

Dík az reakci ;)

al-Quaknaa

[deda.jabko]

k zalohovani - zalezi proste na tom, co si muzete dovolit a jake mnozstvi dat bude potreba realne zalohovat... nekdy jsou vhodnejsi a levnejsi pasky jindy zase postaci prenos na jiny oddeleny system.

mira potrebne dostupnosti hodne zalezi na typu aplikace a s jakou zatezi pracujete. kdyz tak se rozepsite o detailech. pokud potrebujete provozovat podnikovy system, ktery ve spickach resi stovky pozadavku za minutu je dobre o necem takovem uvazovat, pokud se jedna o web server s par blogy, tak drobny vypadek nebude met takove katastroficke nasledky a je to jak jit s kladivem na komara.

[Dalibor Smolík]

Já mám extra usb 320 GB disk, kam zálohuji data. Vytvořil jsem si jednoduché skripty typu cp -ruv a zálohují se mi jen změněná data. Mám extra vytvořené adresáře pro zálohování denní, týdenní a měsíční, nejkritičtější data mám ještě zálohována extra v adresářích určených pro den v týdnu. Pokud dojde k poškození dat, ztratí se práce za jeden, nanejvýš dva dny. Databázové tabulky k tomu zálohuji každou hodinu. Dále jednou týdně nejdůležitější data vypaluji na DVD-RW a odnáším s sebou domů.

[stativ]

Taky k zálohám - zajímavý nápad je zálohovat přes cvs nebo svn. Nezálohují se potom zbytečně nezměněné soubory. Vyvolávání ze zálohy je taky poměrně luxusní když povážíte ty možnosti.

[al-Quaknaa]

Takže inkrementální zálohy? O těch jsem četl tady - nevím, jestli je opravdu svn a cvs nejlepší volba - obzvlášť když by to pro mě bylo první setkání s nimi, kromě svn/cvs/git checkout při updatu mých svn/cvs/git aplikací :D - takže ... myslíte, že je ten návod dobrý?

[tomasgn]

zalohy by mely byt prinejmensim na jinem fyzickem disku, ale nejlepe mimo server a pokud mozno v jinem miste.

LVM umozni efektivnejsi vyuziti disku, nebot se nemusi vytvaret souborove systemy s "dostatecne velkou rezervou"; stejne jednou nastane situace, kdy nekde misto doslo a jinde je ho prilis mnoho. V zacatku se vytvori souborove systemy tak aby byly vyuzity tak na 80-90% (krome /var a /tmp), zbytek disku se necha nevyuzity, a pozdeji se podle potreby zvetsi co je potreba. Navic, pokud se misto na disku vycerpa, prida se do volume grupy dalsi disk a filesystem muzeme dale zvetsovat.

[al-Quaknaa]

Umí XFS zmenšení (I třeba ne za běhu)? A dále - LVM by pro mě byla výhoda při přidání disku do stávajícího serveru, že ano? Jinak to co doporučujete, je vytvořit si /boot a potom velkou partition, z té udělat LVM volume a v tom si normálně čachrovat s LVM partitionama? Tedy nějak jako ukazuje tohle HOWTO? LVM umí tedy i RAID?

[msk]

Umí XFS zmenšení (I třeba ne za běhu)?

Nie.

[Let_Me_Be]

Na server jedine XFS. JFS je lepsi na pomalejsi disky. Ostatni filesystemy nestoji za rec.

[al-Quaknaa]

I přes pomalost XFS při práci s malými soubory? Budu tam provozovat (v několika instalacích - postupem času několika desítkách ...) redakční systém, který je sestaven z asi ~1000 php souborů, ~2kB laždý. takže nevím. XFS se mi líbí rozsahem svých možností a tím, jak funguje (cachování atp.), ale ... proč JFS ne?

al-Quaknaa

[deda.jabko]

v takovem pripade si s naprostym klidem vystacite i s ext3.

rozhodujici v tomto pripade je navrh aplikace (jestli treba cast informaci rve na disk nebo jde vse do db) a rozhodujici je co doporucuje vyrobce db za fs. (vetsinou je to stejne jedno)

nevim, pro jak moc brutalne velke texty to bude a s jakou navstevnosti se to bude potykat, ale premyslet nad nejakou distribuovanosti me prijde vcelku prehnane. v pripade pretizeni servru neni problem vzit cast systemu a prenest jej na novy hardware. ze zkusenosti, se budete muset hodne snazit, abyste zacpal 300GB disku nejakymi smysluplnymi daty.... (kdyz si to prepocitate... tak je to _28_dni_ cisteho casu filmoveho zaznamu v divxu... i kdyby se tam publikovalo jenom porno... tak to budete plnit nekolik tydnu az mesicu ;-])

rad bych tu pripomel znamy akronym KISS (keep it simple stupid) popr. cetbu The Art of Unix Programming kde je ten to pristup rozebran ve vztahu k unixovym systemum.

[al-Quaknaa]

Že si vystačím s extem neznamená, že mi dobře poslouží i XFS, ne? Jinak s tim rozšířením - každopádně nepočítám s tím, že bychom to nějak rychle naplnili, já jen .. co kdyby někdy bylo třeba rozšířit ;) A porno tam vážně nebude ... Jo, a KISS bych chtěl samozřejmě zachovat. proto jsem nejprve byl taky proti LVM, ale .. to HOWTO vypadá celkem spolehlivě.

[Let_Me_Be]

Tak jinak. Jine filesystemy nez XFS a JFS bych tam urcite nedaval. Oni totiz jsou primo delane na servery. Co ti bude vyhovovat vic, je uz tvoje vec. Oba maj velice kvalitni cachovani, takze cim vic RAM tim lip. XFS je pomale pri praci s malymi soubory (mazani/presun) pri cteni by to melo byt to same. Mrkni na testy, mozna ti reknou vic.

[CyberDragon]

XFS - na serveru jiz nikdy, nemam rad "zero" soubory. Jsem spokojeny s Ext3. :)

[al-Quaknaa]

"zero" soubory?

[CyberDragon]

http://oss.sgi.com/projects/xfs/faq.html#nulls

S tim uzce souvisi dalsi problem "write cache on", uvadeny ve FAQ. Ja si na tom dobre nabil hubu na produkcnim serveru. Rekl bych ze JFS na tom nebude o mnoho lepe. No, pokud nekdo 100% veri UPSce a kernelu a ma rad vyhledavani "#find $DATA -type f -xdev -empty", pak proti gustu... ;)

[al-Quaknaa]

Aha, takže "nespolehlivost" XFS v případě výpadku proudu ... mno, myslím, že v serverovně by tohle měli mít ošetřené, ne? Každopádně, tohle je zmíněné snad v každé diskuzi, že XFS není dobrý na normální desktop, kde se může tohel stát ... ale na server by měly být XFS a JFS použitelné dobře. každopádně, až se s něma potkám, aspoň budu vědět o co go ...

[CyberDragon]

> v serverovně by tohle měli mít ošetřené, ne?
Predpoklad, ktery muze zpusobit narust problemu geometrickou radou. :)

[msk]

nemam rad "zero" soubory. Jsem spokojeny s Ext3

Staci si kupit ups-ku :o). Ale teraz vazne. Nechapem, v com je problem. Zapis dat sa cache-uje, zapis inodov nie. Tzn. zurnal nam dopomoze k tomu, ze mame disk po vypadku napajania v konzistentnom stave, ale data nemusia byt. IMHO je to obecny princim zurnalovania vsetkych filesystemov ( pokial sa nezurnaluju aj data ). Alebo som ten XFS FAQ nepochopil?

[CyberDragon]

Jak jsem jiz poznamenal "proti gustu..."
Pokud je to pro odpovedneho admina (jeho sefa/uzivatele) prijatelne, tak proc ne.

[xxxxxxxx]

sestaven z asi ~1000 php souborů, ~2kB laždý.

IMHO se ty 2 MB načtou a pak to stejně půjde z cache. Navic ta pomalost s malymi soubory nebude zas tak strasna

[Láďa]

Souhlasím s XFS, žádný jiný filesystém nepřináší takové možnosti. Nemusíš je potřebovat teď, ale co až budeš chtít přidat třeba kvóty? XFS je podporuje nativně, do ext3 a ReiserFS byly přidány horkou jehlou a je to hrozně znát (JFS nevím). Výpadky proudu můžou být problém, pokud je server třeba v Casablance, kde to byl děs. Skvělou volbou je taky Sunovský ZFS, ale s tím si zatím kromě Solarisu a OpenSolarisu nikde neškrtneš.

[al-Quaknaa]

XFS na datový disk půjde. ZFS vypadá zajímavě co se týče funkcí, ale výkonostně (prý, žádné opravdu seriózní testy jsem nenašel) to není zas taková sláva, takže nevím. OpenSolarisu bych se zas tak moc nebál - ano, musel bych se učit něco nového, ale pokud by to vážně něco přineslo, šel bych do toho. Ale ten projekt vážně asi zas tak velký (aspoň ne hned) nebude, takže to bude linux. Dík za příspěvek :)

[Jan Kurik]

Upozornil bych, že OCFS2 a NFS mají navzájem jiný účel a jiné použití.

OCFS2 slouží k tomu, aby více serverů mohlo přistupovat ke sdíleným zařízením (devices), která jsou dostupná pro všechny servery v clusteru (např. sdílený fiber-channel storage). NFS slouží k tomu, aby server poskytoval svoje lokální diskové prostory jiným.

Pokud máte tedy nějaké externí diskové pole, tak na něj dejte OCFS2, aby v budoucnu na něj mohli přistupovat i jiné servery. Pokud máte jeden server s interníma diskama, tak použijte NFS. Jinak bohužel musím říct, že se stabilitou OCFS2 nejsem příliš spokojen. Nejvíc mne štve, že OCFS2 si posílá přes sdílené disky heartbeaty a pokud některý ze serverů ten heartbeat nestihne včas zpracovat, tak vyvolá kernel-panic. Nejčastěji to nastává když nějaký server v clusteru bootuje. To mi pak poshazuje okolní servery.

[al-Quaknaa]

Díky za zkušenost! Pokud bych měl tedy OCFS2 vyloučit (ne, nebudu mít jedno centrální úložiště), tak je lepší NFS než Coda? Coda by mi měla umožnit minimálně trošku větší výkon skrze to, že povoluje paralelní zápis, ale zůstává pravdou, že s ní bude mít méně lidí zkušenost - a hlavně to teda teď nemusím řešit :)

[deda.jabko]

nevim jestli je to ciste jen muj pocit.... ale pripadne mne, ze si situaci zbytecne komplikujete ... na bezny redakcni system/y s naprostym klidem vystacite s beznym rozdelenim pro desktop a ext3. az budete mit minimalne stovky hitu za minutu tak to bude potreba resit. a i tak to bude potreba resit v souladu s potrebami aplikace... oddelene to nema smysl.

[al-Quaknaa]

No, ale nebude pak zase příliš komplikované to řešit nějak za běhu? Navíc - samozřejmě to teď vůbec nevypadá tak, že bychom se mohli dostat na tak vysoký provoz, ale pokud si vytvořím rozložení fungující "univerzálněji", na škodu to snad být nemůže ... Každopádně díky za všechny rady.

Další díl bude nejspíš o softwarovém vybavení, takže všichni, co rozumí konfiguraci LAMPu, zabezúpečení a podobně budou vítáni :)

al-Quaknaa