Návrh škálovatelného Enterprise Storage za hubičku (diskuse)

[mimi.vx]

podivej se na CEPH

[Max]

Zajímavé, díky za tip. Udělám si tu menší souhrn do budoucna, případně pro ostatní.
Dívám se, že i Proxmox s ním oficiálně počítá : Ceph Server.

Zřejmě jsem i zmeškal nějaké akce, viz : Přednáška SUT - Open­Nebula a Ceph, prezentace viz : 20141126-Tomas_Kukral-Opennebula_a_CEPH.pdf
Zajímavé monitorovací řešení pro ceph je Calamari. K němu pak gui klient : Ceph Manager Clients, komerční app pak : Red Hat uvolňuje Inktank Ceph Enterprise 1.2, resp. Inktank.

Každopádně to vypadá, že je to řešení pro něco trochu víc rozsáhlejšího, než je prozatím v plánu.

Zdar Max

[mimi.vx]

a nebo SUSE Enterptise Storage .. https://www.suse.com/promo/ceph-enterprise-storage/

[R]

Ako je to so zarukou a dostupnostou nahradnych dielov na servery SuperMicro?

[Robertek]

Ze skusenosti k tomu mam par poznamek. Volil bycha asi mezi temito variantami:

1) mdadm + lvm + extX/XFS/...

2) FreeBSD ZFS

Co se tyce varianty 1 je ozkousena stabilni a poskytuje dobrou moznost konfigurace. Rozsirovani take neni problem. Asi k tomu neni co dodat.

Ale v dnesni dobe bych volil spise variantu 2. I s tim ze bych se FreeBSD naucil (neni to zadna veda). Take jsem se FreeBSD drive z iracionalnich duvodu branil, ale dnes na storage serveru nic jineho nepouziju. ZFS na linuxu bych na "enterprise" storage nedal. Neni to spatne, ale pochybuju ze to spolehlive ustoji velky workload. Na notebooku to pouzivam uz asi 3 roky a problemy nemam, ale na produkcni server bych to nedal. Staci se podivat jak probiha vyvoj. Btrfs bych zatim take neuvazoval, mozna za par let.

Co se tyce hw: Hodne ECC ram, dal bych min 64GB!!! Disky co pises jsou asi ok, take bych volil. Dalsi uz tolik neznam takze nehodnotim.

A to ze na FreeBSD neni KVM, to bych asi neresil, a radsi za usetrene penize koupil stroj na KVM, bez storage. Nebo pouzil nejaky co uz mas. Nekombinoval bych storage server s virtualizaci. Je sice pravda ze na FreeBSD uz funguje celkem obstojne BHYVE, ale to bych dnes pouzil tak na testovani.

[Max]

Díky za připomínky. Osobně používám btrfs na backup serveru už nyní a nenarazil jsem na žádný větší problém, kromě jednoho, kdy nešlo mazat snapshoty, ale to opravili v debian stable, nicméně i tak používám kernel z backports a nemám problémy.
Pak znám další lidi, co jej používají bez problémů + znám jednoho, co používá drbd, na něm btrfs a na něm kvm a snapshotuje jak o život a ok (ten ale používá vlastní kernel a né distribuční).
FreeBSD se nebojím, ale jde o to kvm. Nebyly by to nějak produkční VM, ale spíš backup, který vyžaduje, aby nějaká vm běžela.
Zdar Max

[snajpa]

Mrkni na SmartOS. Ma port KVM, poradny filesystem, poradny planovac, poradny alokator pameti, s DTrace jako tresnickou na dortu.

[trekker.dk]

Ta hustější verze - SuperChassis 847E16-R1K28JBOD - dá se do toho vůbec nacpat základní deska? Btw. Supermicro to 4U dodává i jako server systém (nebo jak tomu říkají) i se základní deskou, chladiči na procesory a nějakým LSI řadičem. Akorát si nejsem jistej, jestli už mají variantu s 10Gbe.

Taktéž se říká, že větší, jak 2TB disky nemá cenu v poli používat (pomalé přepočítání pole, vyšší náchylnost na chyby apod.), ale osobně si myslím, že to je věc minulá

Nedávno tady někdo linkoval článek, kde autor psal, že ani náhodou není. Něco jako RAID5 is dead, znělo to dost katastroficky, i když mojí zkušenosti to moc neodpovídalo. Nicméně u RAID10 se nic přepočítávat nemusí, takže u neaktivního pole resync znamená sekvenční čtení a sekvenční zápis. Pokud to ten druhý disk vydrží, tak ok.

Myslím si, že 12ks 4TB disků v jednom poli je rozumná mez, přes kterou nejít.

24TB pole mi přijde trochu velké - nějak mám odpor vůči velkým filesystémům. A jestli tam bude LVM, tak víc menších polí a nad nimi LVM znamená lepší kontrolu nad tím, kde co je.

ZFS on linux - mám pochyby o podpoře a stabilitě a je nutná údržba

Doporučuju posledních pár dní outage-list vpsfree. Vypadá to, že se nakonec vývojáři ZFS on Linux společně s Pavlem Šnajdrem dopracovali k nějakému řešení, ale takhle se patlat s filesystémem, to bych opravdu nechtěl. (Samozřejmě je potřeba jedním dechem dodat, že to, co ZFS nabízí, se AFAIK na Linuxu jinak sehnat nedá.)

[bibri]

Ta hustější verze - SuperChassis 847E16-R1K28JBOD - dá se do toho vůbec nacpat základní deska

Nedá, je to jen JBOD stejně jako v článku zmiňovaný 837E16-RJBOD1, jen je to novější a 4U varianta. Kabely se musí vyvést do řadiče s externími porty, který bude jinde. Ale na rozšíření kapacity je to ideální.

[Max]

Díky, opravil jsem v článku.
Zdar Max

[Max]

Zajímavá diskuse a příspěvky se zkušenostma jsou aktuálně v poradně u threadu : RAID5, ano nebo ne?
O ZFS on Linux na vpsfree vím, ostatně linkuji blog Šnajdera, proto znám plus mínus vývoj a nevěřím tedy, že když někdo říká : "to sice před 2 měsícema zlobilo, ale už je to opravený", že se neobjeví něco dalšího. Produkci vnímám tak, že když se třeba rok (na nějakém větším nasazení u více uživatelů) nenajde něco vážného, tak už je možné o tom začít částečně produkčně přemýšlet.

Jinak 24TB pole mi nepřijde tak zlé. Spíš bych to viděl jako hranici. Ono zase, když použiješ méně disků, tak si snížíš výkon pole, protože nejde tu o souček výkonů, ale o to, jaký nominální výkon je pole schopno zlvádnout (a většinou jde o IOPS, né o maximální sekvenční čtení).
Zdar Max

[snajpa]

No, vzhledem k tomu, jak to ZFS mucime, se myslim da vcelku s klidem rict, ze v momente, kdy to pojede dobre u nas, se da nasazovat kdekoliv jinde. Malo kdo tem vecem dava tak zabrat, jako my s nasi zatezi. Blizime se, ale jeste to bude boj, bohuzel. Nechal jsem vseho okolo a zacal jsem se venovat ZFS naplno, sice puvodem fakt nejsem Cckar, ale ucim se za chodu

A jako side-note si musim postezovat, ze tak zbaveny iluzi, co se tyce Linuxu, jsem jeste nebyl. Dokumentace k vnitrnostem jadra veskera zadna (ostatni unixlike systemy maji na vsechny podstatne veci man pages). Dlouhodobe neresene problemy s fragmentaci SLABu, kdy Chris Lameter navrhoval reseni uz v roce 2007, jeho patchset 15x(!!) prepsal, aby utesil stezovatele na LKML, nicmene prijato do upstreamu to nebylo. I to je z casti duvod, proc se ZFSonLinux tolik bojujeme.

Skoda, ze neexistuje zadne general-purpose distro Illumosu. Linux IMHO na server proste neni dobra volba. A to rikam jako byvaly nejvetsi nadsenec a zastance Linuxu, nez jsem se podival pod kapotu a vystrizlivel.

[Pepa]

Ad poznámka, celkem souhlasím, jen jsi nějak zapoměl na poměr cena/možnosti. Tu dokumentaci u komerčních UNIXů někdo zaplatil a to fakt tvrdě. Navíc pokud jsi narazil na problém a neplatil opět krutou maintenance, aby se ti věnoval výrobce, tak jsi to těžko sám opravil. Expertů na libovolný komerční UNIX málo a když tak opět za peníze. A po zkušenostech s AIX a Tru64 můžu říct, že tam byly taky pěkný špeky.

[snajpa]

Vsak vyvoj Linuxu je taky prevazne placena profesionalni zalezitost. Bohuzel, zamestnavatele davaji linuxovym vyvojarum prilis velky prostor, aby si delali, co chteji, jak chteji, misto aby dupali po vecech jako dokumentace, nebo nedej boze "jak tvuj kod zapada do 'grand picture' linuxoveho ekosystemu".

[pavlix]

Dobří linuxoví vývojáři jsou velmi vzácné zboží, bez ohledu na to, zda jsou dobří a svědomití nad rámec kódu. Pár jich znám a musím říct, že mám kolikrát potíže s nima vůbec mluvit, jak jim to stouplo do hlavy. Nedělá jim kolikrát problém se na původně přátelském setkání chovat tak, že mám pocit, že by mě nejradši viděli vyvážet popelnice. Neříkám, že jsou takoví všichni, jen že na to narážím víc, než bych si přál.

[trekker.dk]

No, co jsem tak po různu četl, tak je to spíš obráceně - o ten grand picture se starají ostatní vývojáři (od konkurence), zatímco zaměstnavatel zpravidla chce, aby ta která věc byla co nejdřív hotová, začleněná a mohla se dodávat.

[trekker.dk]

Dokumentace k vnitrnostem jadra veskera zadna (ostatni unixlike systemy maji na vsechny podstatne veci man pages).

Njn, to je ta slavná katedrála a bazar. Lidi, co s vnitřnostmi jádra pracují, tu dokumentaci nepotřebují, tudíž nepíšou. Lidi, kteří ji potřebují, ji neumí napsat. Krom toho se ty vnitřnosti a zejména rozhraní uvnitř jádra dost mění, takže tipuju, že i kdyby někdo nějakou dokumentaci napsal, tak se velice rychle rozjede od skutečného stavu.

Linux IMHO na server proste neni dobra volba.

Záleží na tom, co se s tím dělá. Pod kapotou to možná vypadá ošklivě, ale na druhou stranu s distribučními jádry (tj. vanilla + pár patchů) bez out-of-tree věcí to funguje docela spolehlivě.

[snajpa]

Njn, to je ta slavná katedrála a bazar.

To je dobra pointa, nenapadlo mne se na to podivat z tehle stranky. Ale napr. FreeBSD ma ty man pages taky

[Michal Kubeček]

Linux IMHO na server proste neni dobra volba.

Naštěstí je dost firem, které si myslí opak. Takže nezbývá než doufat, že to tu nečtou a váš příspěvek jim tudíž neotevře oči. :-)

[snajpa]

Akorat jsem dneska zahlidnul tweet, kterej to krasne shrnuje za mne.

zfs->btrfs
crossbow->ovs
dtrace->[several]
containers->containers
smf->systemd

pattern:
Groundbreaking -> shit clone.

https://twitter.com/FlorianHeigl1/status/578300168497459200

[trekker.dk]

Hm, ještě nedávno byl systemd zachránce před "*BORDELEM* v linuxovym svete", kterej "vytahnul tu nasi stoku "GNU/Linux" z hnicich stojatejch vod statutu quo", a dneska je to "shit clone". Lennart asi něco udělal blbě.

A co se mě týče, u filesystémů by groundbraking bylo to, kdyby se jejich vývojáři u megacool vlastností radši obtěžovali zajistit, aby potřebné informace dokázala přijmout a zpracovat bloková vrstva. Bylo by to mnohem užitečnější než (n+1). implementace RAID5 v kernelu a víc by to zapadalo i do toho "grand picture", protože by pak to samé uměly i jiné filesystémy. Jasně, mělo by to taky nevýhodu, ti vývojáři by se pak nemohli chlubit, že jejich filesystém umí fň a šč a jiné filesystémy ne.

[snajpa]

Linux se snazi featurove uz peknych par let dohnat Solaris, ale nedari se a darit se ani nemuze, protoze na to by byl potreba systemovy pristup s pohledem "zeshora", coz se proste nedeje. Navic, vetsina tech featur je okoukana z hi-level popisu z man pages nebo Sun blogu a podobne, bez toho, aby se nekdo podival dovnitr, jak to funguje. Ne jednou jsem videl na strankach nejakeho linuxoveho projektu zminku "je to jako featura ABC ze Solarisu/Illumosu", ale vubec to nebyla pravda, protoze kdo to psal, nejspis vubec Solaris/Illumos nevidel a jenom o tom nekde cetl z druhe ruky.

Navic u toho kopirovani featur jdou akorat po tech featurach, ale temer systematicky ignorujou nejakou privetivost pro ty, pro ktere to vlastne delaji - sysadminy. Napr. manipulace s BTRFS v porovnani se ZFS. Nebo uprobes/systemtap vs. DTrace.

No, a ad. rozsirovani schopnosti blokovy vrstvy - minimalne u ZFS tohle mozny proste neni. Staci na to letmy pohled do zdrojaku . Tam bylo vyslovene cilem sprsknout vsechny ty vrstvy dohromady a pekne je vzajemne provazat, krom jineho taky proto, aby se nemuseli ptat nikoho okolo a mohli storage zacit resit poradne, bez toho, aby trvalo XY let pomenit neco, co uz je pomalu jak vytesane v kameni. Jak je slozity menit neco zabehnutyho v Linuxu konkretne viz. napr. muj comment o defragmentaci Linux SLAB cache. A neni to zdaleka jenom o blokovy vrstve, to si z tech zajimavych vlastnosti ZFS zas akorat vybiras jenom cast a ignoroval bys treba Adaptive Replacement Cache se vsim dalsim, co s ni souvisi.

[pavlix]

pro ktere to vlastne delaji - sysadminy.

Kéž by.

[trekker.dk]

Napr. manipulace s BTRFS v porovnani se ZFS.

Btrfs taky není hotová věc, narozdíl od ZFS. Teda aspoň doufám, že současný stav nepovažují za hotovo.

No, a ad. rozsirovani schopnosti blokovy vrstvy - minimalne u ZFS tohle mozny proste neni. Staci na to letmy pohled do zdrojaku . Tam bylo vyslovene cilem sprsknout vsechny ty vrstvy dohromady a pekne je vzajemne provazat, krom jineho taky proto, aby se nemuseli ptat nikoho okolo a mohli storage zacit resit poradne, bez toho, aby trvalo XY let pomenit neco, co uz je pomalu jak vytesane v kameni.

No jasně, protože hrát si na vlastním písečku je jednodušší. Ok, abych nekřivdil ZFS, tak do Solarisu, pro který se to vyvíjelo, nevidím a nemůžu tudíž soudit. Že se v ZFS on Linux spousta věcí duplikuje oproti kernelu, je pravda, ale taky je to vcelku pochopitelné - kdyby to tak nechtěli, museli by (hádám) přepsat polovinu kódu, který původně pro Linux není určen.

Na druhou stranu co se btrfs týče, tak tam spousta věcí do kamene vytesaná není ani náhodou. Linux má velmi dobrou implementaci softwarového raidu, takže není potřeba cpát podporu do filesystému, stačilo vývojářům mdraid pomoci třeba s podporou discard. Určitě by pomoc neodmítli, zrovna tohle mají v roadmapě. Snapshoty umí device mapper, takže opět zbytečná duplikace - a v device mapperu je docela živý vývoj, takže taky pochybuju, že by odmítli, kdyby jim někdo chtěl pomoci s tím, aby ty snapshoty fungovaly dobře (AFAIK teď jsou pěkně pomalé, i když možná že s metadata device na SSD by to mohlo být lepší.)

A takhle by se dalo uvažovat i o dalších vlastnostech těch nových filesystémů (checksumy třeba). Neříkám, že by se do nižších vrstev dalo natlačit všechno, ale spousta věcí jo

na to by byl potreba systemovy pristup s pohledem "zeshora", coz se proste nedeje.

Ale děje, už jsem to psal. Vývojáři většinou blokují věci, které duplikují kód nebo by se špatně udržovaly. Bohužel většina z nich je na něčí výplatní pásce, takže když se náhodou víc firem shodne na jedné věci, kterou v kernelu chtějí, tak si nemohou moc vybírat a ten pohled zeshora spíš škodí. Někdo tady v téhle souvislosti nedávno zmiňoval openvswitch, který (AFAIK) v podstatě akorát zpřístupňuje síťové věci (bridge, tap device apod.) pod svým vlastním rozhraním. Tohle vůbec nemá co dělat v jádře, veškerou práci by to mohlo odvést v userspace, ale asi tady vyhrál ten "systémový přístup" firem.

[pavlix]

Linux má velmi dobrou implementaci softwarového raidu, takže není potřeba cpát podporu do filesystému, stačilo vývojářům mdraid pomoci třeba s podporou discard.

Až na to, že block device RAID a file system RAID nejsou záměnné, co do funkcionality.

kdyby jim někdo chtěl pomoci s tím, aby ty snapshoty fungovaly dobře (AFAIK teď jsou pěkně pomalé, i když možná že s metadata device na SSD by to mohlo být lepší.)

Až na to, že device snapshoty a file system snapshoty jsou po technické stránce dvě zcela odlišné technologie a nakonec taky nejsou záměnné.

A takhle by se dalo uvažovat i o dalších vlastnostech těch nových filesystémů (checksumy třeba). Neříkám, že by se do nižších vrstev dalo natlačit všechno, ale spousta věcí jo

Jenže architektura zfs i btrfs (i z toho mála, co o nich vím) je takto navržena úmyslně a právě proto, že na úrovni filesystému se dají dělat úplně jiná kouzla. Ani jeden z nich momentálně nepoužívám, takže vycházím především z toho konceptu samotného, který umožňuje prakticky libovolnou granularitu jak redundance, tak snapshotů. V případě blokového zařízení je granularita jenom jedna.

Někdo tady v téhle souvislosti nedávno zmiňoval openvswitch, který (AFAIK) v podstatě akorát zpřístupňuje síťové věci (bridge, tap device apod.) pod svým vlastním rozhraním.

To jsem klidně mohl být i já. Jako kernelový laik jsem měl od začátku podezření, že je openvswitch jeden velký omyl. Ale nechěl jsem se do toho moc pouštět, dokud jsem neslyšel stejně mluvit i kernelové vývojáře, kteří do toho vidí.

[trekker.dk]

Až na to, že block device RAID a file system RAID nejsou záměnné, co do funkcionality.

Protože?

Až na to, že device snapshoty a file system snapshoty jsou po technické stránce dvě zcela odlišné technologie

Stejná otázka: proč? Vždyť je přece jedno, jestli si filesystém pamatuje, které bloky (soubory) jsou součástí snapshotu a tak se nemají odmazat, nebo jestli si to samé pamatuje device mapper.

právě proto, že na úrovni filesystému se dají dělat úplně jiná kouzla.

Jaká a proč je nejde dělat v device mapperu nebo v mdraid?

[Michal Kubeček]

RAID na úrovni filesystému se mi taky moc nelíbí, ale u těch snapshotů smysl vidím. Problém snapshotu na úrovni blokového zařízení je v tom, že bez spolupráce s filesystémem není způsob, jak zajistit už jen to, že bude obraz filesystému (a tedy i filesystém po rollbacku) konzistentní. Snapshot na úrovni filesystému tohle zařídí snadno. Nebo třeba umožní výběr, co se má do snapshotu zahrnout a co ne.

[trekker.dk]

bez spolupráce s filesystémem není způsob, jak zajistit už jen to, že bude obraz filesystému (a tedy i filesystém po rollbacku) konzistentní.

Ale já přece neříkám, že to musí být bez spolupráce s filesystémem, ostatně pokud vím, tak když device mapper dělá snapshot na LV, na kterém je připojený filesystém, tak jako první volá freeze toho filesystému, tj. spolupráce s filesystémem je tam už teď. A taky neříkám, že filesystém by o snapshotech vůbec neměl vědět. To klidně může, ale už nemusí jejich podporu obsahovat ve vlastním kódu. A přitom by šlo i vybrat, co se má do snapshotu zahrnout a co ne - filesystému se řekne "udělej snapshot /usr", filesystém předá device mapperu instrukci "udělej snapshot těchto bloků"

Samozřejmě - navrhnout rozhraní a dohodnout se na něm s někým tak, aby jej mohli používat i jiní, je mnohem těžší, než nandat duplicitní funkcionalitu do vlastního kódu. Proto říkám, že by to bylo groundbraking - že by někdo se někdo obtěžoval udělat věci pěkně místo snadno.

[pavlix]

filesystém předá device mapperu instrukci "udělej snapshot těchto bloků"

Zde se bavíme ale na teoretické úrovni, že, a bez nejmenší šance na srovnatelnou efektivitu.

[trekker.dk]

bez nejmenší šance na srovnatelnou efektivitu

Zase tvrzení, aniž byste řekl proč...

[pavlix]

Protože používám hlavu. Rád si nechám vysvětlit raid a snapshot jen pomocí seznamu bloků v efektivitě odpovídající implementaci ve filesystému.

[snajpa]

Jak bys treba, rozumne elegantne, naimplementoval dynamickou velikost bloku, bez toho, aby ti to z dm a filesystemu udelalo totalni gulas? Uvazuj, ze je ten blok potreba nejak rozumne adresovat a pocitej s maximalni velikosti zarizeni v desitkach PB a minimalni velikost nekde u stovek MB. Jak by sis vedl - pro podobnou skalu velikosti - mapu volneho mista, abys mohl pripadne rekonstruovat jenom platna data v pripade RAIDu? IMHO to neni tak lehke, jak se na prvni pohled muze zdat. Ne, ze by to neslo, ale udelalo by to z device-mapperu vicemene object-storage, coz je presne jedna z vrstev, kterou ma ZFS v sobe, pekne provazanou s dalsimi. Pridej checksumovani tech objektu s verifikaci pomoci hash-tree a muzeme pokracovat jeste chvili dal

[trekker.dk]

IMHO to neni tak lehke, jak se na prvni pohled muze zdat.

Tak to určitě není, ale vývojářům se to zřejmě povedlo, když to ZFS má. A pokud jde alokátor bloků s dynamickou velikostí udělat ve filesystému, tak v device mapperu to přece musí jít taky. A alokace od filesytému by se pak změnila akorát z volání funkce ve vlastním kódu na volání funkce v jiném jaderném modulu.

Pridej checksumovani tech objektu s verifikaci pomoci hash-tree a muzeme pokracovat jeste chvili dal

V device mapperu přece nemusí být všechno. Checksumování si filesystém klidně může nechat u sebe, protože si dovedu představit, že různé filesystémy ho budou chtít dělat různě, nebo třeba vůbec.

[snajpa]

Jasne, ze se jim to povedlo. Meli volnou ruku a nemuseli se ohlizet na tunu kodu okolo . Kdyby melo ZFS vznikat predelavanim uz existujicich vrstev zrovna v Linuxu a pri politice, ktera okolo jadra je, nebylo by tam jeste ani ted, i kdyz vyvoj zacal uz v roce 2001. Kdyz tak nad tim premyslim, tak objektova CoW vrstva by mozna nebyla marna, ale pochybuju, ze by ji vyuzil nejaky uz existujici FS. Ale, komu by se s tim chtelo psat, kdyz muze rovnou vzit a pouzit ZFS, stejne jako to udelali v LLNL s Lustre - dnes pro Lustre existuje podporovany backend, ktery se napojuje na ZFS DMU vrstvu, tedy pridava dalsi typ datasetu, vedle ZVOL (blockdevice) a ZPL (posix layer, filesystem).

[trekker.dk]

No, ono to s tou politikou okolo jádra zase není tak špatné a dostat něco do device mapperu - zejména takhle užitečného - by IMO problém nebyl.

Ale, komu by se s tim chtelo psat, kdyz muze rovnou vzit a pouzit ZFS

No, pro začátek v Linuxu se rovnou vzít a použít ZFS nemůže, protože tam není. Že doinstaluj si sám má háčky, to jsi zjistil na vlastní kůži. Ale dobře, pro někoho, kdo ZFS věří a zároveň je ochoten používat out-of-tree patche (což třeba já moc nejsem, pokud nejsou malé nebo nezbytně nutné), fajn ZFS je volba. Pak tu máme Btrfs, které pravědpodobně spoustu věcí bude dělat podobně nebo stejně jako ZFS. To už jsou dvě implementace téhož. Jednoho krásného dne si někdo vzpomene, že v device mapperu by se ta objektová vrstva taky hodila a ejhle, máme tři implementace téhož a dokonce 4 implementace RAIDu. Přidejme k tomu Tux3, jestli ho někdy někdo dodělá a jsou tu další duplicity navíc.

To mi přijde docela praštěné. A rozhodně v rozporu s nějakou koncepčností a pohledem shora.

[snajpa]

Nebo to jenom ukazuje, ze storage je netrivialni problem a zaslouzi si vic pristupu, nez jenom jeden.

[snajpa]

Btw, nemalo storage nodu Sequoie z LLNL jede na RHEL6 + ZFS + Lustre; ty, co nejedou na RHELu, jsou taky linux, ale s novejsim jadrem. Jen tak pro zajimavost k tematu

[pavlix]

Mám za to, že už jsem na otázku odpověděl. Jak chceš dělat jakékoli funkce s menší granularitou, aniž bys viděl do struktury toho souborového systému?

[Michal Kubeček]

Papír snese všechno, elektronická média ještě víc. Bez argumentů je to jen výkřik do tmy. Názor firem, které jsou ochotny do jednotlivých řešení investovat své peníze a postavit na nich své produkty nebo je použít na svých produkčních systémech, je pro mne směrodatnější.

[snajpa]

Bez argumentů je to jen výkřik do tmy.

Vsak taky abclinuxu moc o jinem, nez o tech vykricich do tmy uz neni . Pokud se nepletu, vy (kdyz uz mi tykate) nic z toho, o cem se tu bavime (beztak uz tak dost OT) nevyvijite a nemam potrebu nejak ovlivnovat nazor uzivatele. Kdybych se o tom mel dohadovat z mistnich treba s Pavlixem, asi by to bylo o jinem.

[snajpa]

*vykate

[pavlix]

+1

[pavlix]

Kdybych se o tom mel dohadovat z mistnich treba s Pavlixem, asi by to bylo o jinem.

Teď nevím jak to myslíš. Já do kernelu běžně nesahám, kernelové zdrojáky neotevírám, pokud vyloženě nemusím, a rozhodně to nejsou ty od filesystémů. Obávám se, že jestli ti kvůli něčemu odepsal zrovna Michal, tak asi hlavně kvůli tomu, že si to bere osobně, což v mém případě nehrozí, ledaže bys do seznamu připsal nějaké síťové věci.

[Michal Kubeček]

Osobně určitě ne, nic z toho, co bylo v tom tweetu, jsem opravdu nevyvíjel (nejblíž by k tomu asi měl OVS) - koneckonců téměř všechny mé dosavadní příspěvky do jádra jsou stejně bugfixy, ne nové featury. Ale když tady snajpa systematicky předkládá svou vizi, jak je Solaris strašně super a Linux v podstatě jen sbírka nepovedených napodobenin jeho featur, a hlavně když výslovně prohlásí, že Linux není na server dobrá volba, tak jsem pocítil potřebu upozornit, že tento názor není ani zdaleka univerzální.

Když se třeba podívám, jaké OS mají certifikaci pro SGI UV platformu nebo na čem běží SAP HANA, tak tam žádné zmínky o Solarisu nevidím. A nechce se mi věřit, že by zákazníci, kteří si mohou dovolit takováhle řešení, neměli na licenci Solarisu a proto se museli spokojit s tím údajně nepoužitelným Linuxem. Samozřejmě je tu pořád možnost, že jsou to všichni blbci a snajpa jediný tomu opravdu rozumí (pardon, ještě ten, kdo psal ten tweet), ale to ať si rozhodne každý sám, jak pravděpodobná mu tahle možnost připadá…

[pavlix]

Neměl jsem ani tak namysli osobně z hlediska vývoje konkrétních vlastností, ale spíše z hlediska práce na kernelu. Jinak Linux je mainstream a vždycky se najde spousta lidí, kterým se zasteskne po něčem dneska ne tak mainstreamovém, ať už je to Solaris nebo třeba Plan9. Snajpa tomu zjevně do určité míry rozumí a udělal si svůj názor. Rozhodně takový názor neslyším prvně, takže argument absencí jeho nositelů neobstojí.

ale to ať si rozhodne každý sám, jak pravděpodobná mu tahle možnost připadá…

A můžu si s dovolením vybrat třetí možnost, tedy že svět není černobílý?

[Michal Kubeček]

To ale není třetí možnost. Já přece netvrdil, že je Solaris k ničemu nebo že se (obecně) na server nehodí. Nepopírám, že se Solaris pro určité aplikace může hodit víc, pro jiné se víc hodí Linux a pro jiné třeba i Windows. To je ten zásadní rozdíl mezi mnou a nekritickým fandou, který šmahem prohlásí, že "Linux na server prostě není dobrá volba" (a doplní zkratkou IMHO). Já bych si tohle o Solarisu říct netroufl.

[snajpa]

Tak ja si dovolim rict leccos, asi bych to byval mel rozvinout, protoze jak videt, tak se vzdycky najde nekdo, kdo mne chyti za konkretni slovo a bude to rozmazavat, dokud to jde. Z vpsFree use-case vidim, ze vetsina tech projektu, co pouzivame, nebyla na takovou 'specifickou' zatez navrzena, natoz testovana a jeste vubec, aby byla admin-friendly. Mrzi mne videt, ze Solaris na presne takove pouziti byl pripraveny uz cca. pred 8mi lety. A pritom pocet vyvojaru v Sunu je nesrovnatelny se silou vyvojarske komunity linuxoveho sveta. Presto linuxove obdoby jsou porad v plinkach, oproti Solarisu a nektere veci kvuli spatnym rozhodnutim uz ted treba ani nikdy udelat nepujdou. Duraz je spis na akademickou spravnost kodu, nez na jeho realnou pouzitelnost, natoz aby se nekdo zamyslel o par cyklu dal, nad realnym uzivatelem tech technologii. To posledni dela fakt malokdo, zas se neda kategoricky rict, ze nikdo, jasne proboha, ale ...

[snajpa]

Z hlavy mne ted napadaji treba dve veci, ktere mne docela stvou a ktere si myslim, ze uz pomalu tesane v kameni jsou a jinak nebudou:

1. BTRFS nema stromovou strukturu volumes s dedicnosti nastaveni, nedovedu si predstavit spravovat s tim tisice volumes, jako je se ZFS bezne i treba u nas - na zalohovacim poli mame 3500+ datasetu a obcas se objevi potreba nastavit neco jenom na logicke casti z nich. Dedicnost a stromova struktura potom FTW.
2. LXC je shluk ne uplne souvisejicich technologii, takze identifikovat v jadre, ze jsem zrovna v tom konkretnim kontejneru, nejde. Neexistuje neco jako ID kontejneru. Ze by linux umel kontejnery, se myslim rict poradne neda, protoze to, ze mi nahodou vyjde neco, co vypada jako kontejner, je jenom "shodou okolnosti" a je to vlastne by-product toho, ze jsem se sesel s danym procesem v XY namespacech a cgroupach.

[trekker.dk]

No, musíš uznat, že mezi "linux na server není dobrá volba" a "linux není dobrá volba tam, kde nemá potřebnou funkcionalitu" je docela rozdíl. A zrovna vpsFree je ten druhý případ, Linux potřebnou funkcionalitu (kontejnerová virtualizace a filesystém s podporou toho, co umí ZFS) nemá určitě. Takže nakonec kritizuješ Linux za to, že nefungují věci, které nejsou jeho součástí. To je pak vcelku pochopitelné, že se někdo ozve.

Duraz je spis na akademickou spravnost kodu, nez na jeho realnou pouzitelnost

Co to je použitelnost kódu? Kód buď funguje, nebo ne. A u Linuxu - opět, mainline - ten kód většinou funguje. I přes ty dlouho neřešené problémy, na které nejspíš ti, kdo nepoužívají out-of-tree kód, nikdy nenarazí.

[Michal Kubeček]

Duraz je spis na akademickou spravnost kodu, nez na jeho realnou pouzitelnost, natoz aby se nekdo zamyslel o par cyklu dal, nad realnym uzivatelem tech technologii.

Takové příklady by se určitě našly, ale rozhodně bych to tak nezevšeobecňoval. Naopak, už jsem viděl spoustu patchů zamítnutých s tím, že teoreticky by to tak sice bylo lepší, ale kvůli nějaké okrajové záležitosti se další test do fast path (nebo další položka do struct sk_buff přidávat nebude. I já už jsem do jádra posílal patch, který jsem sám považoval spíš za takový "ugly hack", ale byl nutný k vyřešení konkrétního reálného problému našeho zákazníka.

[snajpa]

Tim jsem chtel rict, ze ty pises realne veci, na ktere pak jako admin muzu nadavat, cili kdyz uz nekomu vysvetlovat neco o pristupu a o admin-friendliness, tak treba tobe. Jak mi ale letmy dotaz na Google rika, Michal prispiva k vyvoji veci taky a tak jsem se dost netrefil, mel jsem za to, ze je to jenom uzivatel, ktery ma potrebu obhajovat Linux, protoze nevidel jeste, ze se veci daji delat i jinak. Ale jak rikam, 'trosicku' jsem se netrefil

[trekker.dk]

Ono zase, když použiješ méně disků, tak si snížíš výkon pole, protože nejde tu o souček výkonů, ale o to, jaký nominální výkon je pole schopno zlvádnout

No jasně, když dám do pole míň disků, budu mít míň iops. Ale na druhou stranu zase budu mít víc polí (v součtu tedy stejně iops jako s jedním velkým) a lepší kontrolu nad tím, co pracuje s kterým polem. Jde mi o to, že se třeba nestane, že budu zrovna zálohovat dvě věci na jedno velké pole, ale ono se mi to se zápisy zrovna trefí na stejné disky, zatímco ostatní se budou flákat.

[Max]

v součtu tedy stejně iops jako s jedním velkým

Právě jsem říkal, že součet je irelevantní, důležitější je nominální výkon. Samozřejmě se to nesmí přehánět, měla by být nějaká rozumná mez, kterou jsem si stanovil na zmíněných 12 disků.

ale ono se mi to se zápisy zrovna trefí na stejné disky, zatímco ostatní se budou flákat.

To by se u pole nemělo stávat.
Zdar Max

[trekker.dk]

Ok, co je to ten "nominální výkon"?

[Max]

Sorry, né nominální, ale maximální. Je to stejné jako s virtualizací, nebo jako s ISP, kdy třeba v případě ISP spoléhají na to, že nikdy všichni uživatelé nebudou využívat lajnu na 100%, takže páteř mohou mít pomalejší, jak součet přidělených pásem. U virtualizace to samé, také máme nějaký HW a spoléháme na to, že ty VM nikdy nepoběží všechny na 100%.
Podobně je tomu u pole. Běžně se tam budou data kopírovat, poběží relativně malé diskové operace, ale také chci, aby když bude potřeba, jsem z toho pole dostal data nejrychlejším možným způsobem.
Když bych použil více RAID10 po čtyřech diskách, tak to bude docela pomalý. 20 disků je zase už moc, tam už je moc velké riziko, že se něco po. Myslím si, že 12 disků je celkem ok.
Zdar Max

[trekker.dk]

Sorry, né nominální, ale maximální.

Tak to už je něco jinýho

chci, aby když bude potřeba, jsem z toho pole dostal data nejrychlejším možným způsobem

Jo, takhle to dává smysl - víc disků, větší propustnost

[snajpa]

ZFSonLinux bych ted k nasazeni na server, kde se budou delat rsyncy, opravdu nedoporucil. Je to peklo, bojujeme s neustupnou cache metadat. Jeste to vyresene neni, ale uz se blizime.

[snajpa]

Tak minimalne problem s prerustajici meta cache na RHEL6 jadru je vyreseny. Zbyva jeste vyresit nekolik deadlocku, ale tem se da vyhnout, kdyz si clovek pohlida, aby se ta masina nedostala do uzkych s pameti.

[kyytaM]

O enterprise SATA HDD Toshiba si neuvazoval?

http://toshiba.semicon-storage.com/us/product/storage-products/enterprise-hdd.html

Stoja menej ako RE4.

[Max]

Právě že ne, proto jsem psal, že to je o subjektivních preferencích. Kdybych to měl brát papírově, tak by možná vyšlo lépe něco jiného.
Zdar Max

[Max]

Jinak teda koukám na tu toschibu, asi by mně zajímaly dle toho lehkého infa SATA řada : MG04ACA**** Series, ale když si dám hledat model číslo 4TB verze : MG04ACA400E, nebo MG04ACA400A, tak moc eshopů nenajdu. Zjevně to asi nebude v ČR nějak extra rozšířeno :-/.
Zdar Max

[hw]

Z levnějších SFP+ optických transceiverů mám dobrou zkušenost s moduly Finisar. Výborná spolehlivost a spotřeba. Používám sice 850nm 10GBASE-SR pro levná plastová multimode vlákna, navíc ne pro PC segment, ale nebál bych se ani jejich ostatních modulů pro jiné vlnové délky a single mode vlákna nebo 10GBASE-ER/LR.

[Max]

Díky za tip. Jinak jedna věc je SFP, druhá věc je kompatibilita se switchi. Musí mít deklaraci, že funguje s tím a tím (což u toho Finisaru nevidím, viz :FTLX1471D3BCL). Třeba k tomu HP, nakupujeme "SPS-7120HPE", levný, kompatibilita deklarována (a fungují i v SG300 cisco switchích).
Teď jsem našel třeba ModuleTec (Vesměs potřebujeme 10km verze) : Cisco Compatible. Poté jsem pro cisco našel "NOVATRON SFP-10G-LR OEM". Celkem zajímavé doporučení je zde : Kabely a Transceivery pro 10Gbit síť.
Pro HP jsem teď našel SFP-PLUS-LR10-HPA (JD094B OEM).
Myslím si, že trochu googlení a narazím na kompatibilní a plně dostatečné gbic pro 10G a vypadá to, že bych se mohl dostat s cenou hodně dolu.
Jinak historie mně trochu vytrestala. Je třeba se už od začátku rozhodnout pro jednu značku, jeden typ, který je odzkoušen na provozovaných switchích, protože nejen, že některé gbic nefungují v některých switchích, ale také nemusí fungovat mezi sebou (cisco ckompatibilní v ciscu + hp kompatibilní v HP a spojení se neuskuteční, docela fail). Možná je to jen problém OEM gbic, a možná, že ne.
Zdar Max

[hw]

Jinak historie mně trochu vytrestala. Je třeba se už od začátku rozhodnout pro jednu značku, jeden typ, který je odzkoušen na provozovaných switchích, protože nejen, že některé gbic nefungují v některých switchích, ale také nemusí fungovat mezi sebou (cisco ckompatibilní v ciscu + hp kompatibilní v HP a spojení se neuskuteční, docela fail). Možná je to jen problém OEM gbic, a možná, že ne.

Výslovně jsem to neuvedl, ale je dost důležité vždy používat stejné optické transceivery na obou koncích optického vlákna. To, že moduly pracují na shodné vlnové délce a stejném standardu neznamená, že budou spolupracovat.

Ještě bych se přimlouval za nemíchání pojmů (mini-)GBIC/SFP a SFP+.

[Max]

Jaký je mezi tím rozdíl? Všude na webech se to míchá křížem krážem. Všude vidím MiniGBIC/SFP. Vždy jsem myslel, že MiniGBIC (to je asi současná velikost a GBIC je taková placka doby minulé, ne?) je obecný pojem pro optický modul do switche (čímž by to mělo být obecné pojmenování pro SFP/SFP+/XFP).
SFP je dle toho, co jsem našel, určen pro rychlosti do 4.25Gbit.
SFP+ je 10Gbit a více.
XFP je jen další separátní standard pro rychlost 10Gbit.
Třeba tady je to nějak popsáno : Black Box Explains...SFP, SFP+, and XFP transceivers..
Nemělo by tedy zaměňování nějak moc vadit, ale přiznávám, že je lepší se vyjadřovat vždy přesně, pokud to jde.
Zdar Max

[R]

Finisar svoje vyrobky dodava priamo pre Cisco a aj niektore dalsie firmy.

[Max]

Mno, jasně, ale osobně netuším, jakým způsobem HP detekuje nekompatibilní SFP. Každopádně podle zkušeností to vypadá, že si nějak čte jeho PN, nebo něco podobného, protože mi v HP nikdy nejel žádný SFP, který nebyl oficiálně kompatibilní s HP. U cisca mám zkušenosti jen s řadou SG300 a ta žere jakýkoli SFP, díky bohu. Takže všude cpu HP OEM SFP moduly. Nicméně je možné, že třeba vyšší řady cisco switchů / routerů to budou také nějak kontrolovat.
Zdar Max

[hw]

Mno, jasně, ale osobně netuším, jakým způsobem HP detekuje nekompatibilní SFP.

Naprosto jednoduše. Každý SFP nebo SFP+ modul obsahuje I2C EEPROM s identifikací. Switche pouze obsahují schválený seznam podporovaných transceiverů.

[Max]

Přílohy:

• P1100130.jpg (244261 bytů)
• P1100131.jpg (273596 bytů)
• P1100135.jpg (218182 bytů)
• P1100138.jpg (114788 bytů)
• P1100139.jpg (136010 bytů)
• P1100140.jpg (162799 bytů)
• P1100141.jpg (215763 bytů)
• P1100142.jpg (87766 bytů)
• P1100145.jpg (98453 bytů)

Ok, jinak jsme ho nedávno rozebrali, obrázky viz příloha.
Zdar Max

[Josef Kufner]

Když jsem vybíral nový disk, narazil jsem na Hard Drive Reliability Update – Sep 2014. Vcelku pěkné srovnání.

[Max]

Zajímavé, ale pro mé použití tam není dostatek modelů proto, abych se rozhodl vypustit WD a přejít na HGST.
Zdar Max

[Josef Kufner]

Ono hlavně HGST se docela blbě ve zdejších krajích shání.

[bibri]

Supermicro dobrý, spousta lidí nad tím ohrnuje nos, ale obavy nejsou na místě, živostnost a spolehlivost je dobrá, cena luxusní. Pro nákup předražených "enterprise" řešení dnes v podstatě není moc důvodů - když se nebojíš. Stojí to sice práci, ale vzhledem k tomu, že si můžeš ušít řešení na míru, vyjde o dost levněji.

Šasi 847E16-R1K28LPB má dva expandery s LSI řadičem a konektory SFF8087, čili na propojení všech disků do řadiče ti stačí dva kabely. Když dáš expandery do kaskády, zaberou na řadiči jen jeden port (všechno je v manuálu). Bacha, novější řadiče už mají SFF8643 konektory, musíš mít správný kabel, např LSI00401. VELKÝ POZOR - šasi je pouze na LP karty, čili LSI 9260-16i tam fyzicky nedáš! My používáme Areca 1882i/1883i, protože mají vzhledem k LP požadavku nejlepší HW parametry (RAM, CPU).

MB X9DRE-TF+ - zkus se podívat na X10 řadu s LGA2011-3, přece jen je to novější, rychlejší a méně to žere. Typ bohužel nedoporučím, používáme 1xCPU konfigurace. Ty mají obvykle 3xPCIe, čili dají se k tomu napřímo připojit další dva JBODy do řadičů s externími porty, 2xCPU desky mívají dvakrát tolik slotů, tedy i připojení. Ty JBODy jdou i stohovat, ale dost bych se tam bál výkonu, když to ven/dovnitř poleze jedním kabelem a bude to sdílet celý vnitřek. Jedno takové řešení jsem viděl a moc se mi nelíbilo.

Taky je tu otázka výkonu CPU a RAM, pokud pojedeš na softwarovém raidu a nějakém moderním FS. Třeba pro ZFS se doporučuje 1GB RAM na 1TB dat (při deduplikaci/kompresi myslím až 5GB/1TB) a když se podíváš po netu, tak zjistíš, že k tomu asi mají důvod. Výkonově to pak podle všeho jde do kopru (zatím jsem nezkoušel, ale google mluví jasně). No a do dual-cpu SM desky nedáš víc než 1TB RAM, což tě ve výsledku začne limitovat v celkové velikosti stohovaných JBODů (nebo přijdeš o výkon). Pravda je, že u archivu to moc vadit nemusí, otázka je, co to udělá když tam budeš mít i KVM backup - to bych osobně nedělal.

POZN k failover konfiguraci - tu dokážeš udělat, ale musíš mít SAS disky, SATA to neumí. Není to ani tak drahé - disky pár stovek za kus navíc + druhá karta a konfigurace. Zkušenosti nemám, držím skladem jednu kartu navíc pro případ, kdyby někde zdechla. Sežere ti to ale PCIe slot při připojení dalšího řadiče. Kdybys chtěl ještě větší hustotu v racku, použij mastodontské 847DE16-R1K28LPB nebo 847DE16-R2K02JBOD :). Praktické zkušenosti nemám, přijde mi to už trochu přehnané :). Ale jako cold archive to může být nákladově velmi efektivní. POZOR - mám info, že při vytažení šuplíku dojde k fyzickému odpojení obou(!) disků, měl bys je tedy mít v rozdílných LUNech/volumkách!

Pro mne z toho vyplynulo, že ty JBODy raději nepoužívám - ale je to taky tím, že to nepoužívám jako cold backup, nýbrž se na tom normálně pracuje (stovky TB dat, naštěstí hlavně velké soubory). Nákup 847E16-R1K28LPB+ vnitřností není o moc dražší, každé pole se pak dá vyladit dle potřeby jinak, konektivity to má dost atd. Je to flexibilnější - v případě, že se v něčem vrtáme, což se stává dost často (nemáme to jedno úzké místo).

RAM - podle mne musíš mít do dual CPU konfigurace minimálně 4ks, přeptej se po tom!

DISKY - asspain při stavbě každého pole. Tabulka hezká, ale relevantních informací málo :). Pokusím se sepsat, co vím. Méně než 7200RPM silně nedoporučuji (vč. Intellispeed), je to k uzoufání pomalé. Jediná výhoda je nižší spotřeba - plně osazená kastle 847E16-R1K28LPB s intellispeed nám žere okolo 330W při běžném provozu, s enterprise disky je to cca 500W, tzn. ten rozdíl = rozdíl ve spotřebě 36ks disků. Jestli chceš rsyncovat, tak nezapomeň, že IOPSy pole zhruba závisí na IOPSECH disků. Taky zapomeň na MTBF - důležité je spíš URE! Záruka cca udává, jak moc výrobce těm disků věří. Cache je důležitá v případě, ale musíš ji povolit na RAID řadiči - občas bývá vypnutá! - a jestli ji chceš používat, měl bys mít UPS. Bez hot-spare ani ránu!

Iluzí o discích tě zbaví tohle čtení. Zajímavé počtení nabízí třeba i Backblaze nebo Google. Svou trochou do mlýna přispěl svého času i snajpa. Z uvedených odkazů je taky vidět, kam směřuje trend u opravdu velkých úložišť.

Přesto všechno ještě stále kupujeme enterprise disky. Řídím se URE parametrem, zárukou a doporučeným ročním workloadem (dá se dohledat v datasheetech). Moje zkušenost je taková, že prostě vydrží daleko lépe pětiletý provoz. Neznamená to, že se nekazí, to ne, ale obyčejný disk zdechne v našem provozu po dvou/třech letech a vzhledem k tomu, že nemá víc záruky, tak ho vyhodíš. Další moje zkušenost je, že ta výdrž opravdu souvisí s doporučeným workloadem - a tedy množstvím celkově zapsaných dat. Když se na disky zapisuje hodně, odchází dřív, když jen čtou, vydrží déle. Stačí se podívat na novou řadu Seagate archive, která je určena pro cold archive - jejich 8TB disky mají workload jen 180TB ročně (enteprise mají myslím 650TB ročně). Jsou prostě určeny hlavně ke čtení. Mám tu teď 36ks na zkoušku, tak uvidím - za tu cenu, pokud vydrží tři roky v archivu, tak jsou zlaté :).

Pravda je taková, že v enterprise discích nějak ten firmware upravený je a projevuje se to v praxi tak, jak jsem popsal výše. Ten disk počítá s jiným zatížením a zapojením na RAID řadič, čemuž přizpůsobuje své chování. Jestli stačí jen toto, nebo se používají i nějaké "výběrové" plotny či jiné komponenty, to fakt nevím. Možné to podle mne je, Intel CPU jsou taky všechny stejné a prodejní takt se nastavuje podle toho, jak prošly testem, že ano. Navíc dnešní klasické disky jsou už dost složitá zařízení náchylná na kdeco všechno (pěkné čteníčko). Podle mne se tím začínají blížit SSD, a u nich taky zatraceně moc záleží na vyladění/kvalitě firmwaru.

Filesystemy - zatím jsme na XFS, ZFS i BRTFS jsem prozatím nevyhodnotil jako příliš stable :). Situace ale není moc dobrá, chybí nám snapshoty - ty nad LVM jsou při velkých volumkách zoufale pomalé. Máme to XFS nějak potuněné, zvládá to co potřebujeme, ale už po očku koukáme jinam.

RAID máme hardwarový 60. Softwarový byl u nás při testech vždy pomalejší + hodně dělá jednoduchý management. Ty hardwarové zvládne ošéfovat skoro každý, o softwarové RAIDu na Linuxu už se to říci nedá.

Do budoucna zvažuju, že se pustíme cestou jako Google, Backblaze, FB a další - hodně nodů (Supermicro 5018A-AR12L+ ?), konzumní levné disky, v kombinaci s GlusterFS nebo CEPH nebo něčím takovým. Není teď čas na testy a zkoušení, snad se to časem zlepší :).

Snad ti to k něčemu bude.

[sigma]

Kde kupujete Supermicro, že se dostanete na luxusní cenu? Já když si to naklikám na abacus.cz, tak jsem vždycky o něco (někdy i hodně) výš než se dostanu u DELLu nebo HP s projektovou cenou.

[bibri]

V Asbisu, ale máme smlouvu.

Projektové ceny HP/Dell a ostatních jsou kapitola sama pro sebe - těmi se dá podstřelit skoro všechno. Otázka je, kolik pak bude stát zbytek (maitenance, náhradní díly atd.)

[sigma]

Pokud jde o běžné servery, tak kupujeme s 4 nebo 5 let NBD, potom už většinou nic neodchází, nebo je to stejně celé na odpis. Případně věci jako disky nebo zdroje jde rozumně sehnat. Maintenance - nevím co přesně myslíte, ale u serverů asi nic takového není třeba. Server beru tak, že ho koupím za nějakou cenu s nějakou zárukou, a žádný "zbytek" už tam není.

Hezký konfigurátor má https://www.thomas-krenn.com, ale když jsem si tam naklikal server odpovídající Dell 720xd co jsem kupoval nedávno, jsem na ceně vyšší asi o 70%.

[bibri]

NBD neřeším, to je šaškárna - máme sklad náhradních dílů. S unifikovanou plaformou je to docela levné a oprava bývá do hodiny hotová. Maitenance bývá zvykem u dražších polí "enterprise" výrobců. Zbytkem jsem myslel třeba disky - ty bývají na dvojnásobku ceny za TB a obvykle s menší kapacitou. Rozumně jsem je nesehnal nikdy.

A právě s kapacitou mám problém - potřebuji hlavně co nejvíc TB za co nejméně peněz (nákupních i provozních). Asi je to zřejmé z prvního postu. Když si koupím zmíněné SM se vším co potřebuji + 36ks těch archivních Seagate, dostanu při RAID60 (4x9 disků) cca 220TB na cold backup za nějakých 310k. Bral jsem to před měsícem. V tom je i 10G síť, nějaká SSDčka na cache, drahý dolar a náhradní disk do šuplíku (řadič, MB a další už náhradní skladem mám). To je myslím celkem slušné.

Pokud se to osvědčí (hlavně disky, ostatní je odzkoušené), budu koncem roku kupovat další, protože toto bude plné :). Asi tak.

[Max]

Ahoj, díky za info.
- Hlavně za tip na "SuperChassis 847DE16-R1K28LPB", rozhodně je to lepší varianta, než přes jbody. Tabulka WD je hlavně kvůli MTBF + otáčkám + záruce.
- Dual Portu u SASu jsem si také vědom, myslím, že to i v článku zmiňuji.
- ZFS s pravidlem 1GiB na 1TiB znám, s plánovanými 64GiB ram bych neměl mít problém.
- 4x ram modul na dual cpu je možná potřeba, ale jen v případě, že bych měl oba sockety obsazeny, což mít nebudu. Když bych chtěl dokoupit CPU, dokoupím i ram.
- snajpu jsem četl, ale došel jsem k závěru, že zkusím střední cestu, tzn. nekupovat nic extra drahého, ale také nic nejlevnějšího, WD RE4 by mohlo být ok.
- o vypínání řadičem cache na diskách vím, je to kvůli tomu, že řadič má svou vlastní cache, kdybych jí nechtěl použít, tak jí vypnu a použije se cache na diskách. Možná i proto, že se nepočítá s cache na diskách, se serverové disky nedělají s moc velkou cache (spoléhá se zřejmě na cache na řadiči). Stejně tak jsem obeznámen s výhodami a nevýhodami + nutností UPS apod.
- na hafo nodů s hafo desktop hdd nejsme tak velký, zatím bude stačit 24TiB pole, možná 48TiB a pak se uvidí.
- díky za upozornění na výšku karty, mám za to, že jsem si jí vybral přes menu o LP řadičích, ale koukám, že to tam má vysloveně napsáno. Každopádně už několik lidí chválilo Areca řadiče, takže díky za tip, v návrhu to přepíšu na Arecu 1883i.

Jen jedné věci nerozumím, co znamená toto? "POZOR - mám info, že při vytažení šuplíku dojde k fyzickému odpojení obou(!) disků"
Ještě jednou díky za skvělý info, které mi nějaké věci přineslo a jiné jen potvrdilo.
Zdar Max

[Max]

Tak už to chápu "72x 3.5" SAS2 / SATA3 HDDs in 36x (24 front + 12 rear) Hot-swap Drive Bays (2x HDD per bay)"

Jeden bay je tedy pro dva disky. Jsou umístěný za sebou, takže je ten bay dlouhý. Tím se docílý tak velké hustoty disků na malý plac. Nevýhodou je pak skutečně to, že vysunutím baye se odpojí dva disky. V manuálu je to pěkně popsáno a znázorněno. Zajímavé řešení. Jinak je to skutečně i vidět na pravém obrázku v linku, na stránkách supermicra, jen jsem si toho nevšiml.
Zdar Max

[trekker.dk]

Není to ani tak drahé - disky pár stovek za kus navíc + druhá karta a konfigurace. Zkušenosti nemám, držím skladem jednu kartu navíc pro případ, kdyby někde zdechla. Sežere ti to ale PCIe slot při připojení dalšího řadiče.

Jak je to pak udělané, ty řadiče se spolu domluví, nebo se do systému prezentuje jeden disk dvakrát a OS si s tím musí nějak poradit?

[Pepa]

V systému máš jeden disk dvakrát s jinou cestou. Přes multipath daemona si vytvoříš blokový device a určíš policy jak se budou cesty používat (failover,multibus).