Dotaz: Jaký filesystem pro server?

[TriBIT]

Chtěl bych se zeptat, jaký byste mi doporučili filesystém pro server, na kterém poběží DEBIAN jako systém a další oddíly budou na DATA (webserver/files) a mySQL (databáze).

Konkrétní rozdělení:
/
/usr
/var
swap
/tmp
/home
/data (čistě datové soubory)
/mysql (zde se bude nacházet pouze databáze)

Uvažoval jsem o ReiserFS, ale nyní váhám, jestli někde nepoužít ext3... Díky za náměty a rady.

Odpovědi

[Michal Makovec]

na jakem hardware? co bude na tom serveru provozovano?

[TriBIT]

VMWARE, takže virtuální mašina, vše si mohu nastavit dle potřeby, min. počítám 2GB RAM, 64bit, pojede na tom WEBSERVER, databáze, možná mailserver - opravdu s otazníkem, FTP. Toť asi vše.

[linuxik]

Nech tam standardni ext4. Pokud to pobezi na VMware, tak je to celkem jedno. Stejne to nikdy nebude zadny rychlik, zvlaste v pripade kdyz budes mit Apache a Mysql na jednom serveru a navic virtualnim.

[TriBIT]

Nechápu, proč by to neměl být rychlík? Abychom se chápali, nechci to rozjíždět na virtuálu desktopu, ale na virtuálu v práci, kde nám i SAP servery atd. běží na VMWARE. Vymezit kapacitu paměti RAM můžu jak je libo, klidně 8GB, procesory si také můžu navýšit dle potřeby a o discích nemluvě... Prosím tedy o vysvětlení.

[Kit]

VMware běhá dobře na procesorech, které jsou na to stavěny. Proto si myslím, že s výkonem problémy nebudou.

Možná by stálo za zvážení dát Apache a MySQL na dva oddělené virtuální servery. Nemám s tím praktické zkušenosti, ale mohlo by to být zajímavé jak kvůli bezpečnosti, tak i kvůli výkonu.

[TriBIT]

Možná to tak udělám, uvidíme. Zase tam nepoběží nic moc, co by potřebovalo extra výkon. Jako webserver a redakční systém budeme používat profesionální řešení, zde poběží druhotné aplikace a weby s nízkou návštěvností a většinou na nějakým DRUPALu, Wordpressu apod... Proto myslím, že to postačí nechat na jedné mašině (apache i mysql).

Ale abych neodbíhal od tématu, nevím, jaký použít souborový systém: ext, ReiserFS,...???

[lertimir]

používal bych ext4. Reiser je už dost starý a bez rozvoje.

[pavlix]

Taky bych se reiserfs vyhnul. Člověk může na něco zapomenout, co reiser neumí a co třeba jeho zvolená distribuce používá (selinux?).

[Tomáš Bžatek]

Reiserfs hlasa podporu selinuxu, ve vanilla jadrech, dokonce se mi to podarilo i zprovoznit. Mel jsem pak ale dalsi problemy (se selinuxem), takze jsem od nej nakonec upustil.

[linuxik]

Databaze proste na virtual nepatri. Ne ze by to byla uplna tragedie a nedalo se to pouzivat, sam mam skoro vsechny mysql servery na virtualech, ale filesystem uz to nezachrani. Stare DL380 G5 s se 72GB SCSi disky v RAID1 je stale rychlesi nez virtualy na bladech pripojene po SAN k dikovemu poli.

[Sten]

Proč ne? Výkonostní rozdíl při použití virtio nad LVM není moc velký. Mě spíš přijde divný, proč všichni dávají virtuály do souborového systému, vždyť to musí strašně zpomalovat.

[pavlix]

Protože je to jednodušší. Sice jenom trochu, ale jednodušší.

[Šangala]

Hodím pod otázku, když už virtuál využívá „fyzickou LVM volume“, nastavuješ jich více nebo všechno do jednoho? Jako třeba oddělit /boot nebo logy apod?
Proč se ptám:
Mám jeden „XEN server“ kde disky jsou v souboru, a moc mi to nevyhovuje (a server se bude za nějaký čas předělávat).
Zatím jsem se nějak nedopracoval k tomu, jak by to mělo vypadat, třeba že systém nechám v souboru, kde /var apod. i oddělím, ale „datovou část“ dám na „fyzickou LVM volume“, ale přijde mi to takové celé divně pokřížené. Nebo když to dám vše na „fyzické LVM volume-y“ a oddělím jednotlivé věci (/var /boot apod.) a bude tam několik virtuálů, tak tam bude roj „LVM volume-ů“ a i sfiňa se z teho zbluje.

PS: Ad. zpomalovat: Mám odzkoušeno na běžných discích, jak XEN, tak i VMWare Workstation má výrazně rychlejší operace pokud systém pracuje s menšími soubory a s průměrným až nižším zatížením, když je filesystém v souboru a i na menší MySQL db je to OK.

[kyytaM]

Ked je VM v subore na FS, tak do hry vstupuju rozne cache FS a OS spravujuceho dany FS. Ano - pri urcitom pouzivani je to vdaka tomuto cachovaniu rychle, ale nie je to dobre pre bezpecnost dat. Pri velkom subore a VM, ktora ma agresivno IO operacie vie ist vykon velmi rychlo dole a aj o to zlozitejsie sa odhaduje, ako system bude skalovat.
Pri XENe a PVM sa celkom osvedcilo mat na Dom0 LVM a davat LV z tohoto LVM ako particie pre PVM. Cize VM si uz nerobi vlastnu parition table a particie. Cize v Dom0 sa vytvora v LVM 3 LV, naformatuju napr ext4 a pre PVM sa pridelia ako particie (napr /, /var, swap). Na urovni VM tak uz netreba nic formatovat ani riesit s FS. Dobre je ale postrazit si optimalne zarovnanie LV.

[Šangala]

Ano vnímám to tak, o té rychlosti jsem to psal jen jako reakci, že to není černo-bílé a nutně to neznamená automaticky zpomalení.
No a právě když to to nadělím třeba pro 4 mašiny, tak tam bude roj LV a bude to takové nepřehledné (ale je to právě lepší než fčul v souboru - to je naprd).

[lertimir]

Proč to dělíte na tolik oddílů? Hodně oddílů je hodně zbytků prostoru v každém oddílu. Oddělil bych jen oddíl, kde je silné riziko, že objem dat na něm může rychle růst a zaplnit oddíl, tak aby se nezaplnil kořenový oddíl.

[rADOn]

Protože oddíly slouží i k jiným věcem než jen k ochraně před vyčerpáním místa kořeni. Dokonce bych řekl že _hlavně_ k jiným věcem. Například mít na stejném oddílu velké bloky sekvenčních dat (databázi) a hodně fragmentovaná data (logy) není úplně ideální.

[Asad]

tak tak... logy zasadne do ramfs

[ukos]

LOL

[lertimir]

Souhlasím, že nějaké dělení, obzvláště na serveru, je třeba. Nicméně typicky dělení na "systém", "logy" a "uživatelé a data" se mi celkem dost osvědčuje. V dělení na filesystémy je to / /var a /home přičemž pod /home bych strčil i ty databáze a web. Pro další dělení jsou obvykle třeba speciální důvody např. /tmp /var/lock /run do tmpfs, nebo oddělení /usr pokud jej chci mít standardně připojený pouze jako read only nebo /boot je-li třeba šifrovaný root. Ale obvykle by na dělení měly být důvody a proto jsem se na ně ptal.

[Sten]

Dříve bych dal +1, ale při virtualizaci je IMO lepší dělit to na virtuály a uvnitř už to dělení nemá moc smysl.

[lertimir]

Tazatel, pokud jsem pochopil, tak u virtuálu má dělení na 7 separátních oddílů plus swap. Proto jsem se ptal, proč to tak moc dělí.

[AraxoN]

Odporúčam Ext4. Prednedávnom som robil testy všetkých FS, ktoré sú vo vanilla jadre a nemajú pri sebe príznak Experimental. Z nich Ext4 vyhral skoro vo všetkých kategóriách a v tých, ktorých nevyhral sa nenechal zahanbiť.

ReiserFS (verzia 3) je veľmi nevyvážený - niektoré operácie mu idú rýchlo, ale v niektorých bol rádovo pomalší. Napríklad spočítanie veľkosti rozsiahlej adresárovej štruktúry cez príkaz du - Ext4 za 11 sekúnd, ReiserFS tá istá štruktúra za 420 sekúnd.

Alebo benchmark dbench 64 súbežných klientov - Ext4 dal 65MB/s a max. latenciu 2 sekundy, ReiserFS pri rovnakej štruktúre záťaže 7MB/s a max. latenciu 34 sekúnd. Podľa mňa hrozné výsledky.

[Tomáš Bžatek]

Zajimave, prave reiser 3.6 mi pripada pocitove mnohonasobne rychlejsi na traverse filesystemem (system) nez ext4. Je ale mozne, ze nekdo neco doprasil v poslednich jadrech, ono se to s kazdym vydanim meni. Za tech 9 poslednich let pouzivani si jej ale nemuzu z hlediska rychlosti vynachvalit.

[Asad]

jednoznacne JFS - tromfne pri vykone a spolahlivosti vsetky ostatne - nie nadarmo ho IBM uz roky pouziva vo svojich serveroch prevadzkovanych mimo ine aj v bankach, jadrovych elektrarnach a vsade tam kde je nasadenie a reliabilita kriticka...

[AraxoN]

Příloha:

• server_6TB_fs.odt (27027 bytů)

Podľa výsledkov mojich meraní nebol ani JFS nijak extra hviezdny. Výsledky a metodiku prikladám v prílohe.

[A]

Podľa výsledkov mojich meraní

lenze rychlost zapisu, citania ci mazania nieje az tak podstatna resp. vykryje sa 10 000 a 15 000 otackovymi diskami - co je rozhodujuce je reliabilita a stabilita. A tu ma JFSka dovolim si povedat jedinecnu...

[JirkaK]

reliabilita

Měl jsi na mysli spolehlivost, že?

[A]

ano, pletu sa mi obcas anglicke slova do viet a som lenivy na to narychlo hladat ekvivalenty, tak to nechavam na citatelovi Ale vdaka.

[JirkaK]

Není zač .

[kyytaM]

JFS ma jeden problem, ktory pre niekoho mozno zavazny nie je, ale je to kazdopadne vec na zamyslenie - je okolo neho velmi mala aktivita v jadre. Na jednej strane to moze znamenat stabilitu, na druhej malu pouzivatelsku a vyvojarsku zakladnu a z toho plynuce problemy s postupnym zastaravanim, menej rozsiahlym testovanim v novsich jadrach a mensej pravdepodobnosti najdenia ochotneho JFS guru v pripade problemom s datami.

Kazdopadne zakladom je vzdy zalohovat, nech je FS akokolvek stabilny a robustny.

[Baltazar]

JFS ma jeden problem, ktory pre niekoho mozno zavazny nie je, ale je to kazdopadne vec na zamyslenie - je okolo neho velmi mala aktivita v jadre.

JFS je proste zakomponovany a netreba ho dalej vyvyjat - to co sa vyvyjat ma (a aj sa vyvyja) je jfsutils a teda sada utilit na "problemy s datami". JFS je vyvyjane od frebruara 1990 - davno pred ext2, ext3 ci ext4 ktore len dobiehaju jeho vlastnosti, spolahlivost a vykon. JFS je v prvom rade spolahlivy a zaroven rychly, 64b, vykonny (hlavne pri extremnej zatazi), odolny voci havariam - oprava 8TB pola po umyselnom vypadku prudu s JFSkom je otazkou niekolkych desiatok sekund - porovnajte si to s Ext2/3/4 ci XFS alebo Reiserom.

Na jednej strane to moze znamenat stabilitu, na druhej malu pouzivatelsku a vyvojarsku zakladnu a z toho plynuce problemy s postupnym zastaravanim, menej rozsiahlym testovanim v novsich jadrach a mensej pravdepodobnosti najdenia ochotneho JFS guru v pripade problemom s datami.

JFS filesystem je v Linuxovom jadre od verzie 2.4.18pre9-ac4 a je plne funkcny, bez nutnosti kritickych zasahov a oprav. Ina vec su uz spominane JFS utils ktore sa samozrejme vyvyjaju ale to je user space. O tom sa teraz nebavme. Nesmiernou vyhodou JFS je, ze aj pri velkej zatazi kladenej na FS nezatazuje svojou reziou CPU a preto sa hodi ako na notebook (ktoreho vykonu CPU nieje nikdy dost :) ) tak aj na velke clustre a storage servery velkych bank.

Kazdopadne zakladom je vzdy zalohovat, nech je FS akokolvek stabilny a robustny.

To je samozrejme. Otazka je kto bude musiet obnovovat castejsie

[Lol Phirae]

dalej vyvyjat - to co sa vyvyjat ma (a aj sa vyvyja) je jfsutils ... JFS je vyvyjane od frebruara 1990 ... samozrejme vyvyjaju

Fakt mi to nedá. Zkus slovník.

[Baltazar]

Co uz - ked ovladam rustinu, polstinu, cestinu, rumuncinu, madarcinu asi by som mal zamakat aj na slovencine

[Lol Phirae]

ked ovladam ... madarcinu

Taktéž hovořím plynně. Eréč piklóš neméči, huňár scépeň kámoš.

[BigWrigley]

Co XFS? Mame s nim dobre zkusenosti, ale asi bude vyhodnejsi pro velike soubory.

[Sten]

XFS funguje superrychle a bezchybně, dokud nedojde k chybě hardware (výpadek proudu, rozpad RAIDu ap.). Pak jsou data v loji.

[BigWrigley]

Jakpakto? Nechci se rouhat, ale jeste se mi to nestalo. Faktem je, nepouivame sw RAIDy a napajeni je vzdy zalohovane, servery maji dva zdroje atp.

[Sten]

XFS je jedna velká databáze a prostě to nemá ráda. Mám vyzkoušený jak výpadek proudu tak pád RAIDu. Ten výpadek proudu byl ještě celkem v pohodě, právě měněné soubory se „pouze“ z části nebo celé smazaly (i některé adresáře včetně obsahu), pád RAIDu ale znamenal ztrátu tak 10 % uložených dat a kernel panic při čtení. Teda xfs_repair ze záchranného CD ta data nakonec našel, ale bez cesty, což znamenalo 300 000 souborů v? lost+found, a to už opravdu nikdo nedá dohromady.

[Michal Kubeček]

Ono to není tak strašné, jak to někteří s oblibou líčí, ale je pravda, že riziko ztráty dat při nekorektním ukončení je vyšší než u ostatních filesystémů. Souvisí to jednak s tím, že při přerovnávání operací je XFS agresivnější, jednak s celkovou filosofií návrhu, ktará jako by stála na postulátu, že než byste po havárii měl částečně poškozený soubor (a nevěděl o tom), je lepší, když se ten soubor zlikviduje úplně.

[Sten]

Ono to není tak strašné, dokud se vám to nestane XFS je dělané na server, který má UPSku a dostatečnou redundanci. A hlavně který se zálohuje. Jak jsem pochopil, to je i součást toho postulátu: když nastane problém, raději řekneme rootovi, že má vytáhnout zálohy, než abychom riskovali, že obnovíme špatná data a způsobíme silent corruption. Což, pokud zálohy máte, je nejlepší možné řešení, protože na problém se přijde hned a ne až poté, kdy ty poškozené soubory máte i ve všech dostupných zálohách. Ale mělo by být každému, kdo jej chce nasadit, jasné, že ani xfs_repair nedokáže tuhle vlastnost obejít.

[lertimir]

Zálohování v současnosti se trochu motá v problému, že není zálohovací médium, které by mělo pomalou dostupnost a bylo cca 10 levnější na kapacitu než HDD. Doba, kdy jsem měl na SGI v 90 letech cca 200MB paměti, cca 100GB v discích, a cca 4TB v páskách, které byly na zálohy, je pryč. A mnoho majitelů/správců systémů v neprofi prostředí je líto obětovat 2-3x větší kapacitu na discích na zálohovací prostor na mediu, které by stejně tak mohly sloužit jako přímo přístupný prostor. Pravděpodobně v budoucnu se to posune SSD jako pracovní prostor a HDD jako zálohovací médium.

[Sten]

Souhlas. A proto bych raději XFS na dnešní stroje moc nenasazoval.

[Michal Kubeček]

Já jsem přece netvrdil, že ten problém neexistuje. Jenže občas máte z podobných diskusí pocit, že zatímco ostatní filesystémy jsou v pohodě a můžete s nimi počítač klidně vypínat vypínačem, u XFS vám nekorektní ukončení automaticky zlikviduje půl filesystému a navrch rozlije pivo v ledničce. Což samozřejmě není pravda - ani jedno. Je pravda, že riziko ztráty dat je u XFS o něco vyšší, ale není to tak propastný rozdíl, jak mají někteří lidé tendenci tvrdit.

XFS je dělané na server, který má UPSku a dostatečnou redundanci.

Ani UPS ani redundance vás neochrání před všemi situacemi, kdy se nestihne filesystém korektně odmountovat. Takže kdyby to s XFS bylo tak hrozné, jak se to občas líčí, nemohl by se používat ani na těch serverech…

[Tomáš Bžatek]

Ja mel zrovna tu smulu, ze mi umrel mdraid, na kterem byl xfs a mel jsem zrovna otevreny velky mbox file v modu readwrite. Nasledoval fs panic kvuli ztrate zarizeni a po recovery byla polovina souboru nuly.

Nicmene tohle je extrem, mam tusim i xfs nekde na rootu a zatim jsem nenarazil na poskozeny soubor i pres nekolik vypadku.

Pred par lety bylo velke halo kvuli podobnemu problemu v ext4 (nebo ext3?) a vsichni hromadne zacali pouzivat fsync(). Na krizovejsich datech se zacalo pouzivat rotovani souboru a atomic replace (dconf, gvfs-metadata) a vsichni ziji stastne az do dnes

[lertimir]

XFS funguje superskvěle na středních a velkých souborech. na mnoho operacích s malými soubory je to horší, obzvlášt mazání velkého množství malých souborů bývalo tragické. i když asi se to zlepšilo. Tady je nějaký bench od phoronixu Linux 2.6.39: XFS Speeds-Up, EXT4 & Btrfs Unchanged

[BigWrigley]

Ano, to souhlasim. Napr. na fs s rozbalenymi zdrojaky jadra a pod. neni xfs uplna vyhra. Jinak si myslim, ze pan neudela zasadni chybu s zadnym fs jako ext4, jfs, xfs, ev. ext3. Rozdil ve vykonu muze byt v jeho pripade tak par procent, ktere se daji dohnat jinde. Takze by mohly byt spis rozhodujici jine vlastnosti - zminena robustnost, ale treba moznost vytvoreni snapshotu.