Portál AbcLinuxu, 20. dubna 2024 03:30
podivej se na CEPH
18.3.2015 09:38
Max | skóre: 72
| blog: Max_Devaine
Zřejmě jsem i zmeškal nějaké akce, viz : Přednáška SUT - OpenNebula 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
18.3.2015 11:13
Max | skóre: 72
| blog: Max_Devaine
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žbaDoporuč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á.)
18.3.2015 11:37
Max | skóre: 72
| blog: Max_Devaine
18.3.2015 12:19
Max | skóre: 72
| blog: Max_Devaine
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.
18.3.2015 20:59
pavlix | skóre: 54
| blog: pavlix
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ě.
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
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. :-)
Akorat jsem dneska zahlidnul tweet, kterej to krasne shrnuje za mne.
https://twitter.com/FlorianHeigl1/status/578300168497459200zfs->btrfs
crossbow->ovs
dtrace->[several]
containers->containers
smf->systemd
pattern:
Groundbreaking -> shit clone.
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.
21.3.2015 06:27
pavlix | skóre: 54
| blog: pavlix
pro ktere to vlastne delaji - sysadminy.Kéž by.
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 zdrojakuNo 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.
21.3.2015 12:11
pavlix | skóre: 54
| blog: 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í joJenž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í.
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é technologieStejná 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?
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.
21.3.2015 23:37
pavlix | skóre: 54
| blog: 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.
bez nejmenší šance na srovnatelnou efektivituZase tvrzení, aniž byste řekl proč...
22.3.2015 00:24
pavlix | skóre: 54
| blog: pavlix
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 dalV 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.
. 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).
Ale, komu by se s tim chtelo psat, kdyz muze rovnou vzit a pouzit ZFSNo, 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.
21.3.2015 23:32
pavlix | skóre: 54
| blog: pavlix
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.
21.3.2015 06:27
pavlix | skóre: 54
| blog: 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.
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á…
21.3.2015 12:16
pavlix | skóre: 54
| blog: pavlix
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ý?
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:
Duraz je spis na akademickou spravnost kodu, nez na jeho realnou pouzitelnostCo 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í.
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.
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ádnoutNo 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.
19.3.2015 07:11
Max | skóre: 72
| blog: Max_Devaine
19.3.2015 10:46
Max | skóre: 72
| blog: Max_Devaine
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ůsobemJo, takhle to dává smysl - víc disků, větší propustnost
18.3.2015 12:21
Max | skóre: 72
| blog: Max_Devaine
18.3.2015 12:30
Max | skóre: 72
| blog: Max_Devaine
18.3.2015 15:48
Max | skóre: 72
| blog: Max_Devaine
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+.
18.3.2015 21:26
Max | skóre: 72
| blog: Max_Devaine
18.3.2015 21:30
Max | skóre: 72
| blog: Max_Devaine
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ů.
19.3.2015 08:52
Max | skóre: 72
| blog: Max_Devaine
18.3.2015 21:00
Josef Kufner | skóre: 70
18.3.2015 21:38
Max | skóre: 72
| blog: Max_Devaine
18.3.2015 21:41
Josef Kufner | skóre: 70
19.3.2015 21:24
Max | skóre: 72
| blog: Max_Devaine
19.3.2015 22:55
Max | skóre: 72
| blog: Max_Devaine
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?
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
