abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 13:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 145. pražský sraz, který proběhne ve čtvrtek 26. října od 18:00 hodin v karlínském Pivovarském klubu. Najdete jej kousek od metra Florenc na adrese Křižíkova 17, Praha 8. Jedná se o poslední sraz před konferencí OpenAlt 2017, jež proběhne o víkendu 4. a 5. listopadu 2017 na FIT VUT v Brně. Běží registrace účastníků.

Ladislav Hagara | Komentářů: 0
dnes 06:00 | Zajímavý software

Byla vydána verze 0.56 open source platformy Home Assistant (GitHub) pro monitorování a řízení inteligentní domácnosti naprogramované v programovacím jazyce Python verze 3 a bežící také například na Raspberry Pi. Pro vyzkoušení je k dispozici demo [reddit].

Ladislav Hagara | Komentářů: 0
včera 16:55 | Nová verze

Byla vydána verze 1.0 klienta F-Droid určeného pro instalaci aplikací do Androidu ze softwarového repozitáře F-Droid (Wikipedie), alternativy k Google Play, nabízející pouze svobodný a otevřený software. Podrobnosti v přehledu změn [Hacker News].

Ladislav Hagara | Komentářů: 5
včera 00:55 | Nová verze

Po téměř 13 měsících vývoje od verze 0.11.0 byla vydána verze 0.12.0 hardwarově nenáročného desktopového prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklého sloučením projektů Razor-qt a LXDE. Přehled novinek v příspěvku na blogu.

Ladislav Hagara | Komentářů: 9
21.10. 12:33 | Zajímavý software

Článek ne Medium představuje nejnovější stabilní verzi 2.0 svobodné decentralizované mikroblogovací platformy a sociální sítě podobné Twitteru Mastodon (Wikipedie). Detailní přehled novinek na GitHubu [Hacker News].

Ladislav Hagara | Komentářů: 0
21.10. 06:00 | Komunita

V Praze na půdě Elektrotechnické fakulty ČVUT dnes probíhá RT-Summit 2017 – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt. Přednášky lze sledovat online na YouTube.

Ladislav Hagara | Komentářů: 0
20.10. 14:33 | Zajímavý projekt

Blender Animation Studio zveřejnilo první epizodu z připravovaného animovaného seriálu The Daily Dweebs o domácím mazlíčkovi jménem Dixey. Ke zhlédnutí také ve 3D s rozlišením 8K.

Ladislav Hagara | Komentářů: 0
20.10. 12:34 | Komunita

Aktualizovanou počítačovou hru Warhammer 40,000: Dawn of War III v ceně 39,99 eur běžící také na Linuxu lze o víkendu na Steamu hrát zdarma a případně ještě v pondělí koupit s 50% slevou. Do soboty 19:00 lze na Humble Bundle získat zdarma Steam klíč k počítačové hře Sid Meier's Civilization® III v ceně 4,99 eur běžící také ve Wine.

Ladislav Hagara | Komentářů: 0
20.10. 00:22 | Nasazení Linuxu

Společnost Samsung oznámila, že skrze dokovací stanici DeX a aplikaci Linux on Galaxy bude možno na Samsung Galaxy S8 a S8+ a Galaxy Note 8 provozovat Linux. Distribuce nebyly blíže upřesněny.

Phantom Alien | Komentářů: 19
19.10. 23:55 | Komunita

Společnost Purism na svém blogu oznámila, že její notebooky Librem jsou nově dodávány se zrušeným (neutralized and disabled) Intel Management Engine (ME). Aktualizací corebootu na již prodaných noteboocích lze Management Engine také zrušit. Více v podrobném článku.

Ladislav Hagara | Komentářů: 2
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (10%)
 (0%)
 (0%)
 (1%)
 (75%)
 (13%)
Celkem 226 hlasů
 Komentářů: 8, poslední včera 23:02
    Rozcestník

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

    18.3.2015 00:58 | Přečteno: 3760× | linux | Výběrový blog | poslední úprava: 19.3.2015 23:56

    Delší dobu si pohrávám s tím, že bych do firmy navrhl nějaký storage server na úrovni, který půjde úměrně škálovat, poběží na něm linux a půjde s ním kouzlit. Cena musí být minimální, jak jinak.

    K čemu že?

    Mno, hodil by se nějaký rychlý storage na zálohy všech VM ve firmě + jejich historie. Zároveň by sloužil i jako záloha pro file servery s historií. Do základu by to chtělo tedy kapacitu / výkon pro backup :

    Není to tak, že bychom nezálohovali, ale myslím, že je čas pokročit o stupínek výše a začít zálohovat více na úrovni a případně snížit časy obnov, které teď nejsou nic moc.


    Aktuální řešení

    Máme ve firmě různé NASy, kam dáváme zálohy. Také máme pro zálohy dvě externí pole. Jedno je MSA P2000G3 iSCSI a druhý je ještě levnější, MSA P2000G3 SAS verze. Tzn., že jsou to pole, jejichž cena je kolem 140 000,-Kč bez DPH a bez disků s tím, že SAS verze vyžaduje připojení k nějakému serveru pomocí HBA, konkrétně HP SC08e. Pole jde škálovat, ale SAS verze má drahé disky, SATA verze zase neumožňuje připojit disky větší jak 2TB (přitom SAS verze s tím problém nemá).


    Supermicro

    Ve firmě používáme HP servery, převážně řady Proliant DL380, aktuálně máme mj. několik G8 verzí. Pro kamerový server jsem protlačil do firmy Supermicro jako levné, ale serverové řešení. Musím říci, že princip supermicra se mi líbí. Prostě poskládej si svůj server, jak ti nejvíce vyhovuje. Vše je serverové železo, má to kvm, v základu celkem dobrý řadič a parádní skříně. První myšlenky tedy směřují k tomu, založit storage právě na supermicru.


    Návrh Storage

    Tím jsme na cca "117 000,-Kč bez DPH".

    Rozšíření pole do budoucna

    Kdyby do budoucna nestačila kapacita, lze server rozšířit o storage expander, např. takto :

    Zajímavé počtení :
    External SAS/SATA Disk Chassis Wiring – Part 1
    External SAS/SATA Disk Chassis Wiring – Part 2


    Jaké disky do pole dát?

    Tak samozřejmě, že kvůli ceně SATA disky. Pokud by to mělo sloužit jako odkladiště dat s velmi rychlou možností obnovy dat zpět do produkce, tak by to měly ustát klasické WD RE4 - 4TB - cca 6000,-Kč bez DPH.
    Do začátku by stačilo koupit 13x4TB disky = RAID10 = 24TB pole s jedním diskem jako spare.

    A proč zrovna WD RE4? Protože vychází z WD seznamu, který jsem rychle splácnul, nejlépe (je mimochodem docela masakroidní, tolik typů hdd, to jsem netušil) :

    OznačeníMTBFRPMCacheVelikostRozhraníMax. KapacitaFunkceZárukaUrčení
    WD Black - PDF7200643,5"SATA4TBVCT,StableTrac,NoTouch,CPT5Výkonný desktop
    WD Red - PDF1milIntelliPower16 & 642,5" & 3,5"SATA6TBTLER,RAFF,PMR,StableTrac,NASware3.0,3D Active Balance Plus3NAS 1-8
    WD Red Pro - PDF1mil7200643,5"SATA4TBTLER,RAFF,PMR,StableTrac,NASware3.0,3D Active Balance Plus5NAS 1-16
    WD AE500tis5760643,5"SATA6TBNoTouch,3D Active Balance Plus5Archivační
    WD VL - PDF1,4mil10000643,5"SATA1TBRAFF,NoTouch,PWL5Výkonné prac. stanice
    WD Purple - PDF1milIntelliPower643,5"SATA6TBTLER,ATA,AllFrame3Kamerové systémy
    WD SE - PDF1-1,2mil720064 & 1283,5"SATA6TBTLER,RAFF,NoTouch,fly height,StableTrac5Datacentra - škálovatelnost
    WD RE - PDF.1,2 - 1,4mil720032 & 64 & 1283,5"SATA & SAS6TBTLER,RAFF,NoTouch,fly height,StableTrac5Datacentra - výdrž
    WD RE+ - PDF1,2mil57601283,5"SATA6TBTLER,RAFF,NoTouch,fly height,3D Active Balance Plus,StableTrac5Datacentra - výdrž
    WD XE - PDF2mil10000 - 15000322,5" & 3,5"SAS900GBTLER,RAFF,NoTouch,fly height,StableTrac5Datacentra - výkon

    WD má někde napsáno to, jinde zase ono. Datasheety něco říkají, ale web, nebo přehled na webu zase něco jiného, viz např. : Pevné disky pro datová centra

    The difference between WD Xe, Re, Se, Purple and Velociraptor Drives solved
    WD for Desktop Comparsion
    WD Black vs. WD RE

    RE je z těchto variant určen do toho nejnáročnějšího. Dělá se dokonce i v SAS verzi, což vychází na cca 7500,-Kč bez DPH. HP SAS 4TB 3,5" stojí 12 000,-Kč bez DPH, což je celkem značný rozdíl.
    Každopádně SAS se mi zdá zbytečný, resp. bych použil SAS verzi disků v případě, že bych chtěl řešit failover v rámci řadiče (tzn. DualPort), což si myslím, že je zbytečné.

    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á a např. pro takovéto použití by to nemělo představovat problém.

    A proč WD? Mno, je to o subjektivních preferencích, takže pls. no flame.

    Dále spousta firem dospěla k názoru, že se více vyplatí ty nejlevnější disky, viz :
    NetApp Weighs In On Disks
    What Hard Drive Should I Buy?
    Google’s Disk Failure Experience
    Delame servery, jak to v enterprise nenajdete - dil II.

    Jenomže to jsou velké farmy, kde je přetěžování disků běžné a střídání jak na běžícím páse celkem normal. Nemyslím si, že by to byl náš případ a nemyslím si, že budeme ty disky tak přetěžovat, aby odcházely, proto bych šel do zlaté střední cesty, tzn. nic drahého, ale zároveň nic levného. To myslím WD RE splňuje. Navíc je celkem rozumně dostupný oproti jiným variantám. Jinak osobně mám zkušenost s HP serverem, kde byly kvalitní HP SAS 2,5" disky a server byl značně diskově vytížen a ty disky šly jeden po druhém jak na běžícím pásu. Vyplatil se nám zaplacený carepack mnohanásobně. Šlo o HP SAS 300GB 10k DP v RAID5.


    Maximální velikost jednoho pole aneb raid level

    RAID5 je ošklivý, náročný, nikomu se moc nelíbí. RAID10 je výkonný a relativně stabilní a může v něm odejít až n/2 disků a pole to ustojí. Na druhou stranu, mohou v něm odejít nevhodné dva disky a pole chcípne (pokud se pole skládá z (1+1 = RAID1) + (1+1 = RAID1) = RAID0 ). Skládat RAID10 z RAID1, které mají 3 disky, to je ukrutně drahá sranda. Myslím si, že 12ks 4TB disků v jednom poli je rozumná mez, přes kterou nejít. Tzn., že jít cestou, kde budu mít na storage více 24TiB polí (a ty pro jistotu nespojovat, nebo spojovat, ale jen v rámci btrfs). Další variantou je mít nějaký RAID10 a nějaký RAID třeba 60 (pro zálohy, které nebudou generovat IOPS a budu si jich více cenit).
    Taktéž je třeba počítat s tím, že v případě použití mdadm nevytvářet pole přes celé disky, ale vytvářet jednotně velké partition na diskách a na nich potom pole, aby se nestalo, že nový disk / jiná značka apod. bude mít menší velikost a nepřidám jej do pole.


    HW RAID vs. mdadm vs. btrfs vs. zfs

    Mám tyto možnosti :

    Mdadm mi oproti hw raidu přinese vyšší kontrolu nad celým polem + lepší přenositelnost mezi řadiči, ale třeba výměna disku pak není úplně easy jako u hw řadiče.
    FreeBSD nemá cenu řešit, protože jednak mám více zkušeností s linuxem, dále si myslím, že je na tom KVM na linuxu mnohem lépe.
    ZFS on linux - mám pochyby o podpoře a stabilitě a je nutná údržba (osobně preferuji distribuční řešení, aby do budoucna bylo méně práce, tzn., že bych nerad něco kompiloval a hlídal si víc a víc věcí, abych případným upgradem něco nepokajdil)

    Zbývá tedy čistě btrfs, nebo hw/mdadm raid+lvm+fs. Když bych chtěl snížit režije případných běžících VM, tak bych měl použít VM v rámci LVM.

    Nejlépe si mi jeví to, že budu mít RAID10 v rámci mdadm (kdyby to byl HP server, kterých máme tuny a dobrý support, tak bych nasadil HW RAID, ale přecijen toto bude trochu exot a těžko říci, jak to bude v budoucnu s řadiči), nad ním LVM. LVM si pak mohu rozkouskovat, něco pro KVM, něco pro btrfs na backupy apod. Jsem schopný oželet to, že by věděl btrfs o každém kousku hw, protože s HW RAID+LVM+FS získávám větší možnosti.


    10GBase-T ethernet

    Naše HP DL380G8 už mívají 10GBase-T síťové karty. Storage popsaný výše má taktéž 10G karty. Obě lokality (produkci vs. backup) máme v současné době propojeny 2x 1Gbit optikou Single Mode. Tato optika by měla být schopná zvládnout i 10Gbit, stačí jen použít jiné switche s jinými miniGbic moduly. Hodně levně lze najít třeba řešení od Netgearu : Netgear XS712T-100NES, 12x 10GbE RJ45, 2x shared 10GbE SFP+. Dva takové switche a povýší se kompletní síťový serverový backend na 10Gbit lajnu. Do RJ45 by byly připojený servery pomocí CAT6/7 patch kabelů (3m dlouhé) a switche by byly propojeny optikou s nějakými OEM miniGbic. Original cisco, nebo HP miniGbic pro 10G stojí kolem 75 000,-Kč bez DPH. Každopádně v práci už nyní nakupujeme 1Gbit Single Mode OEM miniGbic, protože origo stojí kolem 8000,-Kč a OEM pro HP stojí do 1000,-Kč a zatím maximální spokojenost, ani jeden problém (OEM HP miniGbic používáme jak v ProCurve 2810,2510 switchích, tak v cisco SG300 switchích), resp. jeden problém nastal jednou, kdy na multi mode optice, která má značně přešvihlou maximální délku, nerozjeli 100Mbit OEM HP miniGBIC, ale origo HP ano, s ním lajna šla. Našel jsem OEM 10G miniGbic za cca 10 000,-Kč, což zní mnohem přijatelněji, jak 75 000,- :).


    Prodávaná řešení

    EVA4400, HP StorageWorks EVA4400 by se dal zařadit jako další konkurenci (co do funkčnosti, né do pohodlnosti ovládání) k navrhnutému řešení výše. Cena tohoto pole je údajně (AG637B) 135 000,-Kč bez DPH. Jak je vidět z popisu, má toto pole 4Gb Fibre Channel (4) Ports. Nicméně v základu nic neumí, na každou blbost je potřeba si koupit licenci, viz např. : EVA 4400 Software - Enterprise Select. Z toho některé licence vyžadují i dedikovaný server.
    To samé platí o MSA P2000G3, taktéž je možné funkcionalitu rozšířit zakoupením sw licencní, viz : MSA Software - Commercial (E-LTU = elektronická licence - nedodají na papíře tak, jak je tomu u LTU).
    Tím chci říci, že koupě pole + disků ještě nedělá konečnou částku. Je třeba započítat i případnou cenu licencí. Dále je potřeba počítat i s infrastrukturou. Je pěkné, když má člověk pole s FC, ale nemá ho kam zapojit, nebo má málo optických párů mezi lokacemi apod.
    Tyto produkty mně tedy utvrzují v tom, že pro NAŠE potřeby jsou prozatím zbytečné a drahé.


    Závěr

    Když bych to měl porovnat s externím pole HP MSA P2000G3, tak jsme na tom :


    Toto je jen první nástřel/úvaha, který bych rád podrobil diskusi, nic víc. Máte tedy někdo zkušenosti s takovým nasazením, popř. s 10G sítí, popř. nějaké doporučení?


    Díky
    Zdar Max        

    Hodnocení: 89 %

            špatnédobré        

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    18.3.2015 08:47 mimi.vx | skóre: 37 | blog: Mimi.VX | Praha
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku

    podivej se na CEPH

    USE="-gnome -kde";turris
    Max avatar 18.3.2015 09:38 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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
    Měl jsem sen ... :(
    18.3.2015 10:17 mimi.vx | skóre: 37 | blog: Mimi.VX | Praha
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku

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

    USE="-gnome -kde";turris
    18.3.2015 10:47 R
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    Ako je to so zarukou a dostupnostou nahradnych dielov na servery SuperMicro?
    18.3.2015 10:56 Robertek | skóre: 5
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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 avatar 18.3.2015 11:13 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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
    Měl jsem sen ... :(
    18.3.2015 14:21 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    Mrkni na SmartOS. Ma port KVM, poradny filesystem, poradny planovac, poradny alokator pameti, s DTrace jako tresnickou na dortu.
    --- vpsFree.cz --- Virtuální servery svobodně
    18.3.2015 11:25 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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á.)
    Quando omni flunkus moritati
    18.3.2015 11:32 bibri | skóre: 33 | Olomouc
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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 avatar 18.3.2015 11:37 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    Díky, opravil jsem v článku.
    Zdar Max
    Měl jsem sen ... :(
    Max avatar 18.3.2015 12:19 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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
    Měl jsem sen ... :(
    18.3.2015 14:37 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku

    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.

    --- vpsFree.cz --- Virtuální servery svobodně
    18.3.2015 18:14 Pepa
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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.
    18.3.2015 18:49 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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".
    --- vpsFree.cz --- Virtuální servery svobodně
    pavlix avatar 18.3.2015 20:59 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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.
    19.3.2015 00:15 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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.
    Quando omni flunkus moritati
    19.3.2015 00:12 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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ě.
    Quando omni flunkus moritati
    20.3.2015 23:49 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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 :-)
    --- vpsFree.cz --- Virtuální servery svobodně
    19.3.2015 07:56 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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. :-)

    20.3.2015 20:50 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku

    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
    --- vpsFree.cz --- Virtuální servery svobodně
    20.3.2015 22:15 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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.
    Quando omni flunkus moritati
    20.3.2015 23:31 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku

    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.

    --- vpsFree.cz --- Virtuální servery svobodně
    pavlix avatar 21.3.2015 06:27 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    pro ktere to vlastne delaji - sysadminy.
    Kéž by.
    21.3.2015 11:46 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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.

    Quando omni flunkus moritati
    pavlix avatar 21.3.2015 12:11 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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í.
    21.3.2015 14:09 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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?
    Quando omni flunkus moritati
    21.3.2015 15:00 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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.
    21.3.2015 15:30 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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.
    Quando omni flunkus moritati
    pavlix avatar 21.3.2015 23:37 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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.
    22.3.2015 00:07 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    bez nejmenší šance na srovnatelnou efektivitu
    Zase tvrzení, aniž byste řekl proč...
    Quando omni flunkus moritati
    pavlix avatar 22.3.2015 00:24 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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.
    22.3.2015 05:41 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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 :-)
    --- vpsFree.cz --- Virtuální servery svobodně
    22.3.2015 10:16 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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.
    Quando omni flunkus moritati
    22.3.2015 17:48 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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).
    --- vpsFree.cz --- Virtuální servery svobodně
    23.3.2015 01:21 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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.
    Quando omni flunkus moritati
    23.3.2015 06:33 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    Nebo to jenom ukazuje, ze storage je netrivialni problem a zaslouzi si vic pristupu, nez jenom jeden. :-)
    --- vpsFree.cz --- Virtuální servery svobodně
    23.3.2015 06:36 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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 :-)
    --- vpsFree.cz --- Virtuální servery svobodně
    pavlix avatar 21.3.2015 23:32 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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?
    20.3.2015 23:18 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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ší.
    20.3.2015 23:37 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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.
    --- vpsFree.cz --- Virtuální servery svobodně
    20.3.2015 23:42 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    *vykate :-)
    --- vpsFree.cz --- Virtuální servery svobodně
    pavlix avatar 21.3.2015 06:22 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    pavlix avatar 21.3.2015 06:27 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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.
    21.3.2015 11:58 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku

    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 avatar 21.3.2015 12:16 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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ý?
    21.3.2015 13:15 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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.
    21.3.2015 14:26 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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 ...
    --- vpsFree.cz --- Virtuální servery svobodně
    21.3.2015 14:43 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku

    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.
    --- vpsFree.cz --- Virtuální servery svobodně
    21.3.2015 14:56 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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í.
    Quando omni flunkus moritati
    21.3.2015 15:13 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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.

    21.3.2015 14:16 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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 :-D
    --- vpsFree.cz --- Virtuální servery svobodně
    19.3.2015 00:28 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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.
    Quando omni flunkus moritati
    Max avatar 19.3.2015 07:11 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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
    Měl jsem sen ... :(
    19.3.2015 10:19 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    Ok, co je to ten "nominální výkon"?
    Quando omni flunkus moritati
    Max avatar 19.3.2015 10:46 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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
    Měl jsem sen ... :(
    19.3.2015 11:31 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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
    Quando omni flunkus moritati
    18.3.2015 14:23 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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.
    --- vpsFree.cz --- Virtuální servery svobodně
    20.3.2015 15:58 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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.
    --- vpsFree.cz --- Virtuální servery svobodně
    18.3.2015 12:12 kyytaM | skóre: 35 | blog: kyytaM | Bratislava
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    O enterprise SATA HDD Toshiba si neuvazoval?

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

    Stoja menej ako RE4.
    Max avatar 18.3.2015 12:21 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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
    Měl jsem sen ... :(
    Max avatar 18.3.2015 12:30 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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
    Měl jsem sen ... :(
    hw avatar 18.3.2015 15:08 hw | skóre: 22 | blog: Digital Design
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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 avatar 18.3.2015 15:48 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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
    Měl jsem sen ... :(
    hw avatar 18.3.2015 20:26 hw | skóre: 22 | blog: Digital Design
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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 avatar 18.3.2015 21:26 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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
    Měl jsem sen ... :(
    18.3.2015 21:22 R
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    Finisar svoje vyrobky dodava priamo pre Cisco a aj niektore dalsie firmy.
    Max avatar 18.3.2015 21:30 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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
    Měl jsem sen ... :(
    hw avatar 19.3.2015 07:59 hw | skóre: 22 | blog: Digital Design
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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 avatar 19.3.2015 08:52 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    Přílohy:
    Ok, jinak jsme ho nedávno rozebrali, obrázky viz příloha.
    Zdar Max
    Měl jsem sen ... :(
    Josef Kufner avatar 18.3.2015 21:00 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    Když jsem vybíral nový disk, narazil jsem na Hard Drive Reliability Update – Sep 2014. Vcelku pěkné srovnání.
    Hello world ! Segmentation fault (core dumped)
    Max avatar 18.3.2015 21:38 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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
    Měl jsem sen ... :(
    Josef Kufner avatar 18.3.2015 21:41 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    Ono hlavně HGST se docela blbě ve zdejších krajích shání.
    Hello world ! Segmentation fault (core dumped)
    19.3.2015 17:08 bibri | skóre: 33 | Olomouc
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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.
    19.3.2015 17:16 sigma
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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.
    19.3.2015 17:23 bibri | skóre: 33 | Olomouc
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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.)
    19.3.2015 17:37 sigma
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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%.
    19.3.2015 18:14 bibri | skóre: 33 | Olomouc
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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 avatar 19.3.2015 21:24 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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
    Měl jsem sen ... :(
    Max avatar 19.3.2015 22:55 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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
    Měl jsem sen ... :(
    20.3.2015 01:06 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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?
    Quando omni flunkus moritati
    20.3.2015 07:24 Pepa
    Rozbalit Rozbalit vše Re: Návrh škálovatelného Enterprise Storage za hubičku
    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).

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.