Vlákno názorů k článku Velká řešení otevřeně: základní vybavení od Rhinox - Misto saskovani s mdadm a lvm bych ja...
-
CHe (neregistrovaný)
Všetko závísí od scenára použitia. ZFS sice má zásadný benefit oproti bežnému mirroru v garantovaní integrity a samoopraviteľnosti. Nie je ale ani zďaleka "zadarmo", ak s ním chceš dosiahnuť nad rovnakou sadou rotačných diskov trochu porovnateľné IOPS charakteristiky ako by mal MDADM RAID 1 + trebárs EXT4, vyžadujte to brutálne zdroje (RAM, SSD keš) navyše. Už v bežnom setupe, bez deduplikácie. Inak si vyrobíš akurát tak spoľahlivý bottleneck, ktorý ti pri prvej trochu dlhšie trvajúcej I/O-bound záťaži úspešne zahltí mašinu.
-
CHe (neregistrovaný)
Pokiaľ sa bavíme o priepustnostiach (či už IOPS alebo BULK), relevantných pre rotačné disky resp. ich polia nad rádovo kusovými počtami fyz. diskov, je MD RAID prakticky transparentný. Výsledná charakteristika je daná prevažne charakteristikou diskov a I/O schedulingom.
Čo sa týka robustnosti (MDADM vs. hw. radiče), osobne mám skôr opačnú skúsenosť.
-
hw raid funguje jen kdyz ma poradne velkou cache (~1G) a dobrou baterku. To se hodi na raid6. Pokud chcete provozovat raid1, tak je vetsinou mdraid lepsi, protoze je tam o vrstvu min. Ta vrstva ma casto vlastni predstavu o tom, ktere operace maji byt rychle, a ktere pomale, a tato predstava se nekdy neshoduje se systemem. Potom je treba vysoka propustnost ale zaplacena zbytecne vysokou latenci na nekterych souborech. (To se mi stalo pred 7 lety s radicem Areca, bylo to na raid 6, takze mdraid jsme radeji nezkouseli).
Na takoveto "domaci serverovovani", s dvema disky per server je hw raid naprosto zbytecna investice. Staci cokoli co ma hotplug disku. -
Petr M (neregistrovaný)
No ale já vím. Mívali jsme v open space (50 lidí, průchoďák do dalších dvou kanclů) rack , normálně zamčený a nikdo z něj nikdy nic nevyškubal. To samý ve výrobě, cca 600 lidí na hale, třísměnný provoz a rack u dvěří do šaten, nikdy se nic neztratilo, nikdo nic nevypojil ani nevypnnul.
No a vzhledem k tomu, že se to celý asi nebude vznášet jenom tak v prostoru a je na to potřeba "vhodná skříň)", tak si o šifrování kvůli krádeži HDD myslím svoje.
A ještě je super, když WidloBFU ve firmě zlobí IS, restartne, nepomůže to, tak jde natvrdo resetovat server... Stroje prostě patří pod zámek a hotovo.
-
Trident (neregistrovaný)
Zrejme spatne technologicky navrzene prostory. Uz 25 let se budovy delaji s technologickym zazemim. Rozumej kazde patro ma mistnosti na technologie. A tim nemyslim jen IT, ale vzduchotechnika,EZS, rozvody topeni,vody,elektro atd. Uz budovy v realnem socialismu jako treba hotely mely naznak techto koutu pro udrzbare na patre.
Nechapu proc davas spatny navrh za vzor. Architekta bych hnal bicem.Je to jako postavit kotel v kuchyni nebo v loznici. Ano funguje to, ale to technologicke zazemi ma mit vyhrazeny prostor. Uz jen kvuli propojeni technologii,zapezpecni v jednom miste a propojeni take v jednom miste. U patrovych budov jsou to sachtove skrine, u velkych hal jsou sektorove rozvody s toutez filozofii akorat rozestavene na plose.
Mit rack v satne to musel navrhovat nejaky betonovy inzenyr strejchnuty vumlem a slivovici. -
Trident (neregistrovaný)
Dvouzdrojovy stroje jsou dneska docela bezny zelezo studentu pod stolem;) To je entry level. Navic x86 HW neni az na velmi specialni vyjimku v kategorii mission critical hw, takze tam ta redundance komponent obvykle neni na urovni nekolika motherboardu, cpu,pameti,radicu a tak dale.
-
Trident (neregistrovaný)
No mdraid je lepsi pokud mate dva identicke disky. Jenomze pokud se budem bavit pouze o urovni redundance, tak ZFS muze dobre fungovat i s ruzne rychlymi disky. Za behu si dela statistiky rychlosti a rozklada cteni/zapis dle rychlosti disku.
Hotplug disku umi kazdy levny SATA radic. Je to obsazene ve specifikaci. Pokud ne tak zkontrolovat drivery nebo reklamovat ze nesplnuje SATA specifikaci. SATA/SAS/FC/WTF=hotplug. Tecka. Na domaci serverovani uplne staci odhodit dekl a prepojit disky za behu bez suflu. Za studentskych let kdy bylo sata novinka tak spolubydla mel "manual cold spare" ze jen prehodil v kisne(pro prazaky pocitacova skrin) kabely z disku na disk.
-
j (neregistrovaný)
2lazywriter: Pata disky s tim problem nemely, problem s tim mel prevazne system/MB ... tomu disku je celkem jedno, jestli ho zapnes tak, ze sepnes zdroj, nebo tak ze do nej vrazis napajeni. Jenze nekdy pripojeni nebo odpojeni vedlo celkem spolehlive k sestreleni systemu /vytuhnuti MB. Coz ostatne plati na desktopech i se sata, byt to by to melo umet nativne ...
Druha vec je samo pomerne nevhodny mechanicky reseni, ale to se dalo osefovat suplikem.
-
Trident (neregistrovaný)
Je treba rezervovat zdroje na ZFS a rici co potrebuji. Dnes je vykon na CPU levnejsi nez vykon na storage. O RAM to pravda uz tak neplati. Stale je vsak x86 zeleza zvykem pohybovat se pouze ve stovkach GB RAM . Jinak lze ZFS premluvit tuningem aby nepouzivalo optimalizace. Nicmene otazkou je take na jakem OS a jakem zeleze. Na solarisu mam celkem dobre zkusenosti. U ZFS je i vyhoda ze pokud mas slabou storage nebo malo vlakno na disky, tak se da pomoci komprese prohnat vice dat byt s vyssi latenci.
Zalezi na use case. Napriklad na DB zatez bych spise doporucil pouzivat raw device bez filesystemu a mit tam primo vnitrni fs databaze. Tam je ZFS paradoxne vice na obtiz.
Na proti tomu kdybych delal nejaky rozsahly datovy sklad napriklad digitalizovanou knihovnu tak ZFS je prvni volba+nejaka replikace.Je treba si uvedomit, ze ZFS je navrzen puvodne jako backend filesystem pro vetsi NAS a SAN a jako konkurence veritasu. Tam se pocitalo s dedikovanym strojem na managementzpracovani a rozdilnym nastavenim.
Dalsi vyhoda ZFS je ze se spousta veci vylepsuje a zpousta veci jde v novych verzich i vypnout. A neni to zas az takovy problem protoze umi online upgrade a iopy ktere upgrade resi maji nizsi prioritu.
-
. Napriklad na DB zatez bych spise doporucil pouzivat raw device bez filesystemu a mit tam primo vnitrni fs databaze. Tam je ZFS paradoxne vice na obtiz.
Z toho většina databází už vyrostla. Navíc většina filesystémů není problém nastavit tak, aby se starali prakticky jen o alokace bloků souboru a zbytek byl více nebo méně raw. A té alokaci bloků zase napomáhají databáze tím, že alokují po velkých kusech. Výhodou takového řešení je, že se z toho dají běžnými nástroji vydolovat data v případě různých problémů. Navíc se to dá ve vypnutém stavu zmigrovat na oddíl jiné velikosti. Jádra mají dnes docela dost možností jak jim vysvětlit jaký workload od toho souboru databáze očekává. To má pak výhodu, že není potřeba extra disk na systém. (Dávat databázi jeden diskový oddíl je vzhledem k různým blokovým keším v jádře podobné jako dát jí vhodně nastavený filesytém.) -
Rhinox (neregistrovaný)
O btrfs bych ja osobne neuvazoval pro nic vic, nez muj desktop (nebo nakej testovaci servr). A v tom pripade musim byti pripravenej na to, ze mozna prijdu o vsechny data (ktere sem nezalohoval).
Ano, mate pravdu ze zfs neni na debianu dlouho, presto je to lety proverenej filesystem kteremu ja duveruju mnohem vic, nez btrfs (jehoz vyvoj jaksi zustal stat, alespon ja mam takovej dojem) nebo kombinaci mdadm+lvm+ext4. Pamet a ssd jsou dnes tak levne, ze neni zadnej problem narvat do servru kolik se tam toho vejde. Taky je to otazka osobnich skusenosti. Jak se rika, jednou skusis ZFS, a pak uz nechces nic jinyho...
