Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: creco 02. 01. 2013, 17:43:18
-
Pánové, měl bych na vás otázku, jak moc se zvýší výkon diskového pole v počtu zápisů a čtení pokud použiju RAID 10 z 4 disků a RAID 10 z 6 disků? Bude tam velký rozdíl?
Zasekl jsem se nad myšlenkou že stejnak jsou data stripována na všechny disky takže se RAID 10 chová jako jeden velký disk který rychle čte souvyslou stopu ale počet IOPS zůstane stejný....
Nebo to tak není?
-
RAID 10 je 1 + 0, takže u těch šesti mohou být dva RAIDy 1 ze tří disků nebo tři RAIDy 1 ze dvou disků.
RAID 0 zvyšuje čtení i zápis a RAID 1 jen čtení (dva disky mají až dvojnásobné IOPS oproti jednomu, tři mají ³⁄₂ oproti dvěma ap.). To je teorie, praxe je závislá ještě na řadiči a na konkrétních discích.
-
Nešlo by použít SSD?
Někdy se dá použít SSD k uložení vesměs dat vhodných pro čtení.
Tím se rozloží zátěž, zkrátka a jednoduše možností jak zvýšit výkon je celá řada a ne vždy to je ta první možnost.
Místo toho, aby se poli zvýšil výkon, se mu sníží zátěž, čímž se dá dospět k mnohem lepšímu výsledku.
Neříkám, že to vždycky jde.
Často je to o typu zátěže, někdy může být optimální přidat ještě jedno pole třeba jen obyčejným zrcadlem.
To je typická situace pro scénáře s převodem videa.
Databázi se oproti tomu může víc líbit na SSD, tabulky co se čtou a připisují se přesunou na úložiště ležící na SSD, pracovní tabulky se třeba vejdou jen do paměti a některé běžné se prsknou na klasický disk.
Podobná situace nastává u firemních dat, část se dá frknout na SSD, část může ležet na disku jen se zrcadlem (Home) a část nechat na nějakém lepším RAID.
Například se mi takhle povedlo rozhýbat do té doby zamrzlé pole, protože se Exchange Store hodil na jiné pole než zbytek dat.
Exchange si cvičil se schránkama o 106, původní pole jelo taky naplno, ale výkon se prakticky zdvojnásobil, jen protože se pole specializovalo.
-
Sten: to není teorie, RAID opravdu nezvyšuje IOPS. Raid zvyšuje pouze sekvenční čtení. U náhodného čtení se sice může stát, že budou požadována data z různejch disků, ale taky nemusí a pokud se čtou soubory větší než velikost jednoho raid bloku, tak na defragmentovanejch discích k nárůstu rychlosti v podstatě nedojde. Protože seeků, který jsou největší brzdou, bude úplně stejně.
Přikláněl bych se k Rumu, ve výsledku daleko větší poměr cena/výkon bude mít, když vytypuješ aplikace, co nejvíce brzdí, a přesuneš je na SSD, nebo alespoň rozhodíš na různá pole.
-
Blbost. Raid zasadne zvysuje(meni) I/O vykon. SSD je hovadina, jestlize jde o hodne zapisu, tak jako tak by musel byt v raidu - mit jen ssd bez redundance je hovadina. Ve vetsim nasazeni je lepsi mit enterprise ssd (SLC nebo MLC pro enteprise segment). V pripade toho raidu 10, kdy jde o 2 nebo 3 mirrory je narust 30%. Jestlize radic (nebo napr ZFS v pripade soft raidu) umi cist i ze dvou zrcadlenych disku v roundrobinu, vykon cteni bude v pridade 6 disku 6x vesti nez jeden disk (teoreticky) - jde samozrejme hlavne o random IO. Tearing na poli je hezka vec, ale chce to uz HW radic nebo pole - zalezi kolik penez jste ochoten investovat. V zasade jde o 75 IO na disk u 7200, 100 u 10k a cca 125 IO u 15k disku. Pocty jsou snadne, pocet disku = pocet IO co pole obslouzi - pak zalezi na konfiguraci raidu. V pripad R5 nebo R6 hodne zalezi, jestli je parita pocitana v pameti a pak zapsana, nebo tupe pocitana z jiz zapsanych dat. Zminujete raid 10, tady zkutecne ale plati, ze pocet stripu zveda vykon. Pozor na to, ze u R10 se stripe nezapisuje na cely set, ale proste se zapise stripe a jde se dal na dalsi volny stripe a tak stale dokola. Z praxe je velmi dulezite vedet, jak se bude chovat realny provoz a co od pole pozadujete. U SSD skutecne pozor na to, aby neodeslo do haje po par mesicich provozu - cist muzete jak chcete, ale prepis a nasledne mazani je VZDY po blocich nasobne vetsich nez 4kb (obvykle smazani 4kb realne prepise v disku 1MB dat na 100% jiz zapsanem disku - trim v raidu vetsinou nepomuze) - zivotnost jde rapidne dolu - proste dat ssd na web kde logujete, menite data podle navstevniku atd je cesta do (krom webu se tremi navstevniky za den)... Pro hnidopichy s tim tak trochu zkusenost mam, raidy od jednotek disku az po stovky disku na raid grupu (metaluny).... (150.000 IO/sec).
-
Sten: to není teorie, RAID opravdu nezvyšuje IOPS. Raid zvyšuje pouze sekvenční čtení. U náhodného čtení se sice může stát, že budou požadována data z různejch disků, ale taky nemusí a pokud se čtou soubory větší než velikost jednoho raid bloku, tak na defragmentovanejch discích k nárůstu rychlosti v podstatě nedojde. Protože seeků, který jsou největší brzdou, bude úplně stejně.
Přikláněl bych se k Rumu, ve výsledku daleko větší poměr cena/výkon bude mít, když vytypuješ aplikace, co nejvíce brzdí, a přesuneš je na SSD, nebo alespoň rozhodíš na různá pole.
RAID nezvyšuje IOPS, ale zvyšuje rychlost čtení? Jak by to asi dělal jinak než zvýšením IOPS, když sektory jsou pořád stejně velké?
Ty seeky jsou na tom pravděpodobnostně úplně stejně s RAIDem i bez něj, akorát když RAID může číst paralelně ze dvou disků, tak zvládne až dvakrát tolik seeků (během seekování jednoho disku může zároveň seekovat i druhý).
SSD mívají o jeden až dva řády vyšší IOPS než disky (ty nejlepší i o čtyři), RAID zvyšuje IOPS maximálně lineárně.
-
Pánové, měl bych na vás otázku, jak moc se zvýší výkon diskového pole v počtu zápisů a čtení pokud použiju RAID 10 z 4 disků a RAID 10 z 6 disků? Bude tam velký rozdíl?
Ne, nebude. Rekl bych, ze stezi neco poznas. Jestli ti jde opravdu o IOPS, pak doporucuju hybridni pole: raid1 slozen z SSD a HD (na hw-radici kterej to umoznuje, s dostatecnou cache a battery-backup, samozrejme). Primarne se pak cte/zapisuje na SSD plnou rychlosti, a v pozadi se synchronizuje HD...
-
Pánové, měl bych na vás otázku, jak moc se zvýší výkon diskového pole v počtu zápisů a čtení pokud použiju RAID 10 z 4 disků a RAID 10 z 6 disků? Bude tam velký rozdíl?
Zasekl jsem se nad myšlenkou že stejnak jsou data stripována na všechny disky takže se RAID 10 chová jako jeden velký disk který rychle čte souvyslou stopu ale počet IOPS zůstane stejný....
Nebo to tak není?
Pánové, měl bych na vás otázku, jak moc se zvýší výkon diskového pole v počtu zápisů a čtení pokud použiju RAID 10 z 4 disků a RAID 10 z 6 disků? Bude tam velký rozdíl?
Zasekl jsem se nad myšlenkou že stejnak jsou data stripována na všechny disky takže se RAID 10 chová jako jeden velký disk který rychle čte souvyslou stopu ale počet IOPS zůstane stejný....
Nebo to tak není?
Samozřejmě že to IOPS zvyšuje, ale jak konkrétně a pro jaké operace, to záleží na tom jaká úroveň RAIDu je zvolena.
Pokud se bavíme o RAID 0 (striping) tak ten dokáže v podstatě zdvojnásobit IOPS, a to bez ohledu na to zda se jedná o čtení či zápis a náhodné či sekvenční operace. Podmínkou ale je aby bloky nebyly větší než stripe size a byly dobře zarovnané (tj. aby bloky pro jednotlivé I/O operace padaly právě na jeden fyzický disk).
Obdobně u RAID 1 (mirroring), ale tam to platí v podstatě jenom pro čtení.
U kombinací jako je např. RAID 10 je to nějaká kombinace předchozích dvou odstavců. Tj. čtení může škálovat s počtem fyzických disků, zápisy s počtem RAID 1 skupin. Tj. pokud máte disky v RAID1 párech, a nad tím RAID0 mirror tak pro 4 disky se vám čtení zvýší 4x a zápis 2x, při 6 discích čtení 6x a zápis 3x.
Každopádně výše uvedené platí za předpokladu saturace toho RAID pole - buď tak že nad ním současně poběží více seekujících procesů, nebo tak že program bude nějakým způsobem používat asynchronní I/O apod. Prostě pokud použijete jeden proces který bude vždy čekat na dokončení operace a až pak udělá další, žádný rozdíl oproti jednomu disku neuvidíte (alespoň v náhodném I/O ne).
Další na čem to hodně záleží je jak ten RAID vlastně budete stavět - např. jestli jako softwarový RAID pod Linuxem, jako HW s nějakou kvalitní RAID kartou (3Ware, LSI, Areca, ...) nebo nad nějakou plečkou která často ani RAID nedělá hw ale přes ovladač.
Ale jak už tady zaznělo, pokud jde o výkon v náhodných operacích, zdaleka cenově nejefektivnější je nějaký kvalitní SSD disk. Existují i možnosti jak to spojit do hybridního pole - např. L2ARC pro ZFS apod. Ale to už je vyšší dívčí.
-
Sten, Tomáš Vondra: To bych se s dovolením hádal. :-) :-)
RAID zvyšuje především sekvenční čtení. IOPS může zvýšit, ale také nemusí. Protože bottleneck pro IOPS není samotné čtení, ale seekování disku. Sektory jsou pořád stejně velké, ale disku velmi záleží na tom, jestli chci číst sousední nebo náhodné sektory.
Např. pro mirror dvou disků je worst case situace, kdy aplikace pravidelně čte náhodná data o velikosti 2x(velikost stripe). Protože v té chvíli pro každý požadavek musí zaseekovat oba disky, což jsou řádově milisekundy. Že pak chtěná data ty disky přečtou za 1us místo 2us, protože každej disk čte jen jeden stripe a nikoli dva, jako v případě single disku, se na výkonu pole nikterak neprojeví.
-
SSD lze často použít zcela zcela běžné s minimální redundancí, jde jen o typ dat.
Pokud se jedná o firemní dokumenty typu doménové politiky, ŠABLONY, PDF atd, kdy zároveň provádím zálohování, pak mi v zásadě nejde o nic. Tím, že to hodím na SSD, se můžu zbavit řady požadavků.
U diskového pole je problém zmíněný seek, vystavování hlaviček byť vesměs optimalizované.
Pokud z pole něco číst nemusím, nemůžu ho ani zdržet.
Problém je, že 1/2 obyvatel naší země je slabá duchem ;D
S raidem si to málo adminů dokáže představit, ale zkuste si to představit na příkladu rozvozu pizza.
I když si pořídíte rychlejší auto, tak tu pizzu podstatně rychleji nerozvezete.
V lepším případě získáte +10% výkonu.
Pokud si pořídíte dvě-tři auta, tak to "hlavní" může mít třeba o 1/2 méně práce, což je zrychlení o 50%.
A přitom za stejné náklady!
-
Sten, Tomáš Vondra: To bych se s dovolením hádal. :-) :-)
RAID zvyšuje především sekvenční čtení. IOPS může zvýšit, ale také nemusí. Protože bottleneck pro IOPS není samotné čtení, ale seekování disku. Sektory jsou pořád stejně velké, ale disku velmi záleží na tom, jestli chci číst sousední nebo náhodné sektory.
Např. pro mirror dvou disků je worst case situace, kdy aplikace pravidelně čte náhodná data o velikosti 2x(velikost stripe). Protože v té chvíli pro každý požadavek musí zaseekovat oba disky, což jsou řádově milisekundy. Že pak chtěná data ty disky přečtou za 1us místo 2us, protože každej disk čte jen jeden stripe a nikoli dva, jako v případě single disku, se na výkonu pole nikterak neprojeví.
Ale já jsem hned v druhém odstavci jasně napsal že "Podmínkou ale je aby bloky nebyly větší než stripe size a byly dobře zarovnané (tj. aby bloky pro jednotlivé I/O operace padaly právě na jeden fyzický disk)."
Prostě RAID hodnotu IOPS zvyšuje ale je samozřejmě otázkou zda to aplikace dokáže využít - v podstatě pro každou konfiguraci RAID pole jde vymyslet zátěž při které pole nefunguje o nic líp než jeden disk. K tomu abychom dokázali posoudit jestli RAID pole tazateli pomůže nebo nepomůže máme málo informací.
-
SSD lze často použít zcela zcela běžné s minimální redundancí, jde jen o typ dat.
Pokud se jedná o firemní dokumenty typu doménové politiky, ŠABLONY, PDF atd, kdy zároveň provádím zálohování, pak mi v zásadě nejde o nic. Tím, že to hodím na SSD, se můžu zbavit řady požadavků.
U diskového pole je problém zmíněný seek, vystavování hlaviček byť vesměs optimalizované.
Pokud z pole něco číst nemusím, nemůžu ho ani zdržet.
To je samozřejmě pravda, i když seek je spíš problém disků než vlastního pole ...
Problém je, že 1/2 obyvatel naší země je slabá duchem ;D
S raidem si to málo adminů dokáže představit, ale zkuste si to představit na příkladu rozvozu pizza.
I když si pořídíte rychlejší auto, tak tu pizzu podstatně rychleji nerozvezete.
V lepším případě získáte +10% výkonu.
Pokud si pořídíte dvě-tři auta, tak to "hlavní" může mít třeba o 1/2 méně práce, což je zrychlení o 50%.
A přitom za stejné náklady!
No, ale to je spíš argument pro to že RAID hodnotu IOPS zvyšuje, ne? Samozřejmě pokud budu vyrábět pizzy které se mi nevejdou do jednoho auta (operace s bloky většími než chunk size) tak výkon nezvýším, atd.
-
Zalezi na RAID levelu - predpokladame-li, ze vetsina IOPs se vejde do velikosti stripe tak plati zhruba toto (zhruba proto, ze to plati pri distribuci IO pres celou velikost zarizeni, coz casto neplati):
RAID5 - pri cteni IOPs zvysuje, pri psani IOPs spise snizuje (zalezi na implementaci v sw nebo radici). V degradovanem rezimu a pri rebuildu (a to by kazdeho zajimat rozhodne melo) jde vykonnostne uplne do haje
RAID6 - plati co pro RAID5, ale hodne zalezi na radici nebo sw - ani na ne-zcela levnem radici to nemusi byt zadna vyhra.
RAID-DP a podobne - plati co pro RAID5, ale v degradovanem rezimu a pri rebuildu skoro zadny vykon nesezere - ale to jen tak neco nema
RAID1 - pri cteni IOPS vyssi, pri zapisu +- stejne (zapis hodne ovlivnuje pochopitelne i cteni, tady tim spis ze se pise vzdy na vsechny zarizeni)
RAID10 - to vsude tlacim a je to jedine co bych nasadil napriklad na databazi (pokud bych nemel RAID-DP). Je vice moznosti jak ho vytvorit (layout - far, near, pocet kopii...), ale da se zhruba rict ze zvysuje IOPs jak na cteni tak na zapis a v degradovanem rezimu nebo pri rebuildu se zpomali o zlomek toho co treba RAID5
Pokud se nejedna o extremni objem dat tak bych sahnul urcite po SSD, u vetsiho objemu ZFS + SSD na ZIL a L2ARC (SSD staci uplne mini).
-
Mám dojem, že všichni píšeme totéž, akorát z jiný strany. Já píšu, že apriory nezvyšuje, protože existují scénáře, kde se to nezvýší, vy píšete že zvyšuje, protože existují scénáře, kde se to zvýší. Tak bych se na tom shodnul, ne?
Pro tazatele z toho vyplývá, že musí zjistit charakter IO, než se rozhodne co tam dát. Schermer: Dát tam RAID samozřejmě neuškodí, ale něco to stojí, tak by měl vědět, že to nedělá jen pro dobrej pocit :-) - byť 10 samozřejmě zvedne i bezpečnost.
-
Dekuju moc za nazory ale rekneme ze se trochu rozchazeji.
Proto jeste uvedu ze se jedna o stream server na zpusob youtube. Pocet navstevniku je dene cca 50 000.
Ja osobne zvolil 4x disky s 15 000ot/s v RAID5.
Ale jaky typ RAID zvolit a jake uloziste pro maximalni IOPS.... SSD se nebranim protoze se jedna hlavne o cteni... ale zase o data uzivatelu nechci prijit a pouzivat SSD v RAID je trochu nebezpecne rekl bych protoze muzou odejit vsechny naraz.
-
Sten: to není teorie, RAID opravdu nezvyšuje IOPS. Raid zvyšuje pouze sekvenční čtení. U náhodného čtení se sice může stát, že budou požadována data z různejch disků, ale taky nemusí a pokud se čtou soubory větší než velikost jednoho raid bloku, tak na defragmentovanejch discích k nárůstu rychlosti v podstatě nedojde. Protože seeků, který jsou největší brzdou, bude úplně stejně.
Přikláněl bych se k Rumu, ve výsledku daleko větší poměr cena/výkon bude mít, když vytypuješ aplikace, co nejvíce brzdí, a přesuneš je na SSD, nebo alespoň rozhodíš na různá pole.
Nepis kraviny ... RAID IOps samo zveda ... jinak by se nedalo postavit databazovy pole ...
Je to celkem jednoduchy, jedno dvoudiskovy zrcadlo ma +- 150IOps pro zapis (zapisuje se na oba disky) a cca 300 pro cteni (ctou se ruzna data - z kazdeho disku jina). => 4 disky v R10 budou mit 300/600, 6 disku 450/900 atd. Samo jde o teoreticke optimalni hodnoty, v realu to bude trochu horsi.
-
Dekuju moc za nazory ale rekneme ze se trochu rozchazeji.
Proto jeste uvedu ze se jedna o stream server na zpusob youtube. Pocet navstevniku je dene cca 50 000.
Ja osobne zvolil 4x disky s 15 000ot/s v RAID5.
Ale jaky typ RAID zvolit a jake uloziste pro maximalni IOPS.... SSD se nebranim protoze se jedna hlavne o cteni... ale zase o data uzivatelu nechci prijit a pouzivat SSD v RAID je trochu nebezpecne rekl bych protoze muzou odejit vsechny naraz.
Uvedom si, ze R5 ti pujde dohaje v pripade rebuildu pole a to na nekolik hodin (je ulpne sumak jestli mas nebo nemas HW radic). R5/6 je obecne pole vhodny spis na ne moc vyuzivana data, vykonostni pole se stavi vpodstatne vyhradne jako R10. IOps budes mit samo nizsi nez na R10. A to jak pri zapisu tak pri cteni.
A jestli z tech 4 disku chces obslouzit 50k lidi a streamovat jim video ... tak bys spis mel zacit uvazovat o nejakym poradnym poli.
-
Mám dojem, že všichni píšeme totéž, akorát z jiný strany. Já píšu, že apriory nezvyšuje, protože existují scénáře, kde se to nezvýší, vy píšete že zvyšuje, protože existují scénáře, kde se to zvýší. Tak bych se na tom shodnul, ne?
Pro tazatele z toho vyplývá, že musí zjistit charakter IO, než se rozhodne co tam dát. Schermer: Dát tam RAID samozřejmě neuškodí, ale něco to stojí, tak by měl vědět, že to nedělá jen pro dobrej pocit :-) - byť 10 samozřejmě zvedne i bezpečnost.
Ne tak úplně. To worst case scenario je hodně teoretické, osobně neznám aplikace, co by v jediném vlákně četly náhodné části souboru po 128 KiB (standardní velikost stripe bývá 64 KiB), většinou když už čtou náhodně, tak po ½ KiB, 1 KiB nebo 4 KiB (tedy hodně pod stripe size) nebo si celý soubor namapují a pak to jádro načítá po stránkách (4 KiB). Naopak to best case scenario se týká většiny případů, kdy disk drtí několik (≥ počet disků) různých vláken paralelně, což je na serveru jedna z nejběžnějších situací.
Dekuju moc za nazory ale rekneme ze se trochu rozchazeji.
Proto jeste uvedu ze se jedna o stream server na zpusob youtube. Pocet navstevniku je dene cca 50 000.
Ja osobne zvolil 4x disky s 15 000ot/s v RAID5.
Ale jaky typ RAID zvolit a jake uloziste pro maximalni IOPS.... SSD se nebranim protoze se jedna hlavne o cteni... ale zase o data uzivatelu nechci prijit a pouzivat SSD v RAID je trochu nebezpecne rekl bych protoze muzou odejit vsechny naraz.
RAID 5 na něco takového fakt ne, to je spíše na domácí úložiště, kde je hlavní obří celkový prostor a rychlost je vedlejší.
Pokud to bude streamovat 50 000 videí denně, tak je to průměrně (každé video cca 20 až 30 minut) nějakých 1 000 videí paralelně, a pokud bych bral křivku zátěže velkých českých serverů, tak ve špičce to bude až 5 000 videí paralelně, to takové malinké pole nezvládne ani náhodou. Videa na YouTube ve standardní kvalitě mívají kolem 600 kbps, takže by to ve špičce zabralo jen pro čtení cca 3 Gbps, tak počítejte na celé pole tak 500 MBps pro čtení + jednou tolik pro zápisy (jeden 15k SAS disk dá kontinuálně kolem 150 MBps, 7200 rpm HDD polovinu, sčítání rychlostí je stejné jako u IOps).
Btw. jak to bude připojené?
-
Hmm, pro zajimavost, pri 1k soucasne bezicich videi a (pro jednoduchost) 1Mbit/video to hodi nejakych rekneme 256k IOps na 4k sektorech => 2k disku v R10. Pocitam neco blbe?
-
Mám dojem, že všichni píšeme totéž, akorát z jiný strany. Já píšu, že apriory nezvyšuje, protože existují scénáře, kde se to nezvýší, vy píšete že zvyšuje, protože existují scénáře, kde se to zvýší. Tak bych se na tom shodnul, ne?
Pro tazatele z toho vyplývá, že musí zjistit charakter IO, než se rozhodne co tam dát. Schermer: Dát tam RAID samozřejmě neuškodí, ale něco to stojí, tak by měl vědět, že to nedělá jen pro dobrej pocit :-) - byť 10 samozřejmě zvedne i bezpečnost.
Ne tak úplně. To worst case scenario je hodně teoretické, osobně neznám aplikace, co by v jediném vlákně četly náhodné části souboru po 128 KiB (standardní velikost stripe bývá 64 KiB), většinou když už čtou náhodně, tak po ½ KiB, 1 KiB nebo 4 KiB (tedy hodně pod stripe size) nebo si celý soubor namapují a pak to jádro načítá po stránkách (4 KiB). Naopak to best case scenario se týká většiny případů, kdy disk drtí několik (≥ počet disků) různých vláken paralelně, což je na serveru jedna z nejběžnějších situací.
Dekuju moc za nazory ale rekneme ze se trochu rozchazeji.
Proto jeste uvedu ze se jedna o stream server na zpusob youtube. Pocet navstevniku je dene cca 50 000.
Ja osobne zvolil 4x disky s 15 000ot/s v RAID5.
Ale jaky typ RAID zvolit a jake uloziste pro maximalni IOPS.... SSD se nebranim protoze se jedna hlavne o cteni... ale zase o data uzivatelu nechci prijit a pouzivat SSD v RAID je trochu nebezpecne rekl bych protoze muzou odejit vsechny naraz.
RAID 5 na něco takového fakt ne, to je spíše na domácí úložiště, kde je hlavní obří celkový prostor a rychlost je vedlejší.
Pokud to bude streamovat 50 000 videí denně, tak je to průměrně (každé video cca 20 až 30 minut) nějakých 1 000 videí paralelně, a pokud bych bral křivku zátěže velkých českých serverů, tak ve špičce to bude až 5 000 videí paralelně, to takové malinké pole nezvládne ani náhodou. Videa na YouTube ve standardní kvalitě mívají kolem 600 kbps, takže by to ve špičce zabralo jen pro čtení cca 3 Gbps, tak počítejte na celé pole tak 500 MBps pro čtení + jednou tolik pro zápisy (jeden 15k SAS disk dá kontinuálně kolem 150 MBps, 7200 rpm HDD polovinu, sčítání rychlostí je stejné jako u IOps).
Btw. jak to bude připojené?
Beru tvoje pripominky jako spravne. A co bys navrhoval za diskove pole pro takovou zatez?
Tedka to mam resene kompletne dvema servery. Jeden U2 8x 2TB HDD 7200ot/s. v RAID 10. A druhy server ten novy 4x 450GB 15000ot./s v RAID 5.
Do budoucna bych to videl na diskove pole na zpusob HP StorageWorks D2700 a do toho nacpat 25x 300GB 10000ot./s (nebo SSD) ale rekneme ze to neni tak uplne zadarmo a vubec nevim kolik by toho takove pole zvladlo.
Nejradsi bych jedno velke diskove pole pro vsechny servery ale vubec nevim co.
-
...
Jestli to chápu, jde hlavně o streamování videa, něco jako bys provozoval službu uloz.to.
Zkus uvážit i sofistikovanější možnosti.
Řekněme, že cca 30% provozu budou tvořit stejné položky, nestálo by za to 1x za den vyhodnotit nejvíce stahované položky a přesunout je na SSD?
Postup:
1. Spočítat počet stažení pro každou položku za dobu X a vložit to do tabulky.
2. Projíždíš tabulku toho, co je na SSD a pokud je daná položka řekněme mimo top 1000, pak jí smažeš a odstraníš si v DB flag, že je na CACHE.
3. Zjistíš uvolněné místo a podle nějakého klíče to místo obsadíš (buď tam naprdíš malé soubory, nebo prostě první co není v cache), položku z původního umístění NEMAŽEŠ!! Pouze v DB PŘIDÁŠ další náhradní odkaz (vedoucí na CACHE) a nastavíš flag.
Například:
http://www.alza.cz/intel-520-180gb-ssd-bulk-d298675.htm
Je poměrně dobré v poměru cena - výkon.
Pak můžeš postupovat analogicky, například položky málo stahované, kde počet stažení je roven mrazu, odmigruješ na nějakou lacinou herku:
http://www.alza.cz/western-digital-caviar-av-green-power-3000gb-64mb-cache-d249188.htm
(Pokud ti k souboru přistupuje cca 1 člověk za den, může takových ležet na hromadě plno a budou k dispozici možná rychleji než z toho pole!)
Výsledek?
Nejvíc vytížené věci máš na SSD,
Nezajímavé věci na které nikdo moc neleze máš na disku mimo pole.
A pole je pak vytížené dle možností!
Pokud to ve tvém případě jde, může tohle být optimální varianta!
Obecné pravidlo tvrdí, že často 20% něčeho tvoří 80% něčeho.
20% obchodníků tvoří 80% zisku.
20% souborů tvoří 80% provozu.
Jistě, nemusí to tak být vždy, je to velmi obecné a přesto velmi často platné pravidlo.
Proto tvrdím, šoupnout těch 20% někam vedle a pole bude mít o 80% méně práce!
Byť tyto věci potřebují na vymyšlení hlavu, nejedná se jen o tupé přidání výkonu dalším diskem, takže nevím, jestli to oceníš. ::)
-
Jestli na to máš, zkusil bych jako Cache použít tohle: http://www.alza.cz/ocz-revodrive-3-480gb-d252852.htm
Těch zápisů nebude až tolik, aby ses musel bát, že ti hned chcípne.
Pokud jde o videa, tak různá videa jsou tuším v permamenci vždy cca 1-4 měsíce, podle typu služby.
Takže podle toho, jak si nastavíš filtr, bys měl mít SSD obsazené tím, k čemu je hodně přístupů.
V zásadě je jedno, jestli máš na SSD věci, na které vede 40 nebo 50 přístupů, pořád jsi svému diskovému poli ušetřil 40 přístupů.
Tj. nemusíš mazat z SSD hned všechno.
Navíc tohle je pro SSD ideální scénář, kdy na něj zapíšeš něco, nějakou dobu to tam necháš a pak to smažeš.
Jen bych neobsazoval celou kapacitu SSD, ale vytvořil disk třeba o kapacitě 440GB.
Pokud bys provozoval něco jako www.zvraceny.cz, pak bych ti řekl, abys videa nahrával přímo na pole a rovnou dělal odkaz na SSD.
Videa na prvních cca 5-ti stranách budou v permanenci, pak už bude počet přístupů zřejmě klesat a klasické vyhodnocování ti řekne, co je oblíbené a co ne.
Pokud budeš dělat něco jako uloz.to, pak bych ti řekl, ať to nejprve šoupeš na pomalý disk, protože hromada kravin si prostě nezaslouží se na pole vůbec dostat a až po cca 5-ti přístupech do přesuneš na pole, teprve pak na SSD.
-
Taky uvaž kompresi, pokud tě brzdí výkon diskového systému, komprese zvýší propustnost.
To by samozřejmě víc platilo pro služby typu Uloz.to protože ISO soubory jsou často celkem slušně komprimovatelné.
Video vesměs moc komprimovatelné není, tak rozdíl nebude velký.
Další kouzlení se dá provádět s velikostí sektorů.
Je to jako když si servírku pošleš desetkrát za sebou pro štamprle piva.
Ta hloupá běhá, běhá, běhá, běhá a nestíhá obsluhovat ostatní hosty.
Chytrá ti rovnou přinese půl litr a zle se na tebe zatváří.
Podle typu "podávací aplikace", tj. toho, co ti podává data, se dá rovnou nastavit i velikost cache.
Jsem toho názoru, že pro video má smysl vytvořit souborový systém s co největšími bloky.
Velkých bloků bude nejspíš méně a nemůže tedy dojít k tak velké fragmentaci.
Mimo to se celý blok načte do paměti řadiče, takže i když si klient řekne řekněme jen o 4KB ze 64KB bloku (64KB bloky jsou doporučené pro ukládání videa) dost možná si o další blok stihne říct dříve, než se ten blok z cache uvolní a ušetříš tím řekněme řadu čtení. Pole nezatěžuje čtení, ale seek!!!
Obecně se tedy můžeš honit za IOPS jako pes za vlastním ocasem a budeš k smíchů.
Otázka by neměla znít, jak zvýšit IOPS, ale: "Jak maximalizovat propustnost, jde to jedině zvýšením IOPS?"
Někdy může znít odpověď: "Tohle nejde nijak rozdělit, zkus tam přidat disk a získáš cca 1/10 výkonu navíc (10%)."
Nebo může znít: "Tak to reorganizuj, pole bude mít o 50% méně práce (jako bys zvýšil IOPS o 100%)."
Hlavu, používejte HLAVU!
-
tak s podobnymi poziadavkami a predpokladom, kolko $$$ vygeneruje 50 000 prehranych videi denne, by som siel do krabic od oraclu a v nich nastavil trojite zrkadla. so 48 diskami na 15 000 rpm dostavas ~9 000 IOPS. k tomu nejau tu RAM (96 GB+) a l2arc na SSDcka, aby sa pre najnavstevovanejsie videa nemuselo na disky a mas hotovo.
btw na zaciatok by som povedzme 5% videi hodil na stroj, kde budu vyhradne SSD (alebo este lepsie len kopec RAM a v nej ramdisk), tam vysledovat IOPS, potom extrapolovat a podla toho dimenzovat storage s diskami.
-
to bw : trosku drahe a bezhlave riesenie. Tvoje riesenie urcite bude fungovat ale trochu overkill na to, co potrebuje. Vo finale zistis, ze sa ti to pole flaka a zbytocne si vyhodil kopu penazi za nieco, co nevyuzijes.
Kapitan RUM na to ide lepsie. Zvladne to iste ale s neporovnatelne nizsimi nakladmi. Odporucam ti ist touto cestou, ta je najlesia.
-
Kapitan RUM na to ide lepsie. Zvladne to iste ale s neporovnatelne nizsimi nakladmi. Odporucam ti ist touto cestou, ta je najlesia.
Dík!
To mě dost těší ;D
Ono se s tím dá totiž ještě víc kouzlit.
Příklad souboru, který je v permanenci, tj. dostal se jak na SSD tak zůstal na poli (na SSD je vždy jen kopie):
Zjistím, že SSD je vytížené na 100%, v takovém případě mohu některým uživatelům podávat data i z pole!
Třeba:
Připojí se mi najednou 20 000 uživatelů (je špička) a všichni se chtějí dívat na Gangnam style
http://www.youtube.com/watch?v=9bZkp7q19f0
Zbytek dalších mají rozkoukaného Hobita.
Pokud bych měl jen jedno pole, tak to půjde celé do hajzlu.
Takhle můžu například zjistit vytížení SSD (lze i z PHP) i diskového pole, zjistím, že SSD je právě v háji, ale pole na tom tak hrozně není, tak budu vracet pro nová připojení odkazy na jejich umístění v poli. Možná to není nejgeniálnější load balance, ale určitě to bude fungovat.
Podobný smysl může mít i ramdisk, pokud by mi většinu zátěže tvořilo třeba 5-10GB videí, nejspíš bych je nakopíroval na ramdisk.
Ten by měl velký smysl hlavně v případě, kdy se opravdu jedná o omezený počet kousků, které máš ohodnocené nějakým testem a máš předpoklad, že to bude stahovat tolik a tolik lidí.
Některé SSD disky mají 1GB cache, pro tvůj případ mi takové přijdou jako užitečné.
Levné SSD, které použiješ jako cache (je na nich kopie).
Při určitém typu zátěže bys mohl mít na obou SSD discích stejné video a prostě vracet cestu ke stažení/prohlížení napřeskáčku.
(Pro stejný soubor dostane klient 1 odkaz na první SSD, druhý na druhé SSD, třetí opět na první SSD....)
Cílem není rovnoměrná zátěž, protože třeba uživatelé číslo 3,5,7,9 se odpojí, ale pokud to takhle budeš praktikovat pro všechny soubory na SSD (CACHE), pak se ti stejně v celkovém průměru zátěž zprůměruje.
Jak jednou víš, kolik lidí to video bude chtít stahovat, můžeš se už spolehlivě postarat o to, aby to proběhlo v pořádku a pole ti nedoutnalo jak hlavičky cvičí.
-
Následuj RUMA: jakákoli SSD i paměťová cache (do serveru dneska nacpeš klidně 128GB RAM) Ti to zrychlí mnohem víc, než RAID.
Jinak jestli to bude pole, kde se bude velká převaha read operací, tak by stálo za to nezahazovat RAID5. Protože narozdíl od 10 má sice zoufalej zápis (což ovšem pro ukládání velkejch videí nevadí), ale při čtení může těžit z toho, že data jsou při sekvenčním čtení rozházený po všech discích ale přitom (na rozdíl od radidu 10) se nečte nic zbytečnýho. Viz např.
http://www.kendalvandyke.com/2009/02/disk-performance-hands-on-part-5-raid.html
V takovém případě ale zcela určitě dej databázi a logy na jiný pole (což je rozumný asi i tak) - na RAID5 patří pouze "readonly" operace.
-
inak k otazke IOPS na takyto server, za predpokladu idealneho rozlozenia pristup v celom dni, velkosti videa 50 MB za minutu a pouzitom bloku 64 kB (zfs ma variabilnu velkost bloku az do 1024kB, co by sa dalo v tomto pripade pekne vyuzit), dostavam IOPS (50 MB * 16 blokov na MB/60 sekund)*(86400 sekund denne/50000 pristupov) ~= 23. s rastucou velkostou bloku toto cislo dalej padne. takze vlastne cele nahananie sa za IOPS v tomto vlakne je zbytocne. budem rad, ak ma niekto opravi :)
a este by ma zaujimalo, ako presne sa da v linuxe pouzit ssd cache? bcache?
-
inak k otazke IOPS na takyto server, za predpokladu idealneho rozlozenia pristup v celom dni, velkosti videa 50 MB za minutu a pouzitom bloku 64 kB (zfs ma variabilnu velkost bloku az do 1024kB, co by sa dalo v tomto pripade pekne vyuzit), dostavam IOPS (50 MB * 16 blokov na MB/60 sekund)*(86400 sekund denne/50000 pristupov) ~= 23. s rastucou velkostou bloku toto cislo dalej padne. takze vlastne cele nahananie sa za IOPS v tomto vlakne je zbytocne. budem rad, ak ma niekto opravi :)
a este by ma zaujimalo, ako presne sa da v linuxe pouzit ssd cache? bcache?
Ten výpočet je špatně, počítáte totiž, že každé video trvá jednu sekundu. Vynásobte to nějakými 30 minutami a zjistíte ten problém :-)
-
inak k otazke IOPS na takyto server, za predpokladu idealneho rozlozenia pristup v celom dni, velkosti videa 50 MB za minutu a pouzitom bloku 64 kB (zfs ma variabilnu velkost bloku az do 1024kB, co by sa dalo v tomto pripade pekne vyuzit), dostavam IOPS (50 MB * 16 blokov na MB/60 sekund)*(86400 sekund denne/50000 pristupov) ~= 23. s rastucou velkostou bloku toto cislo dalej padne. takze vlastne cele nahananie sa za IOPS v tomto vlakne je zbytocne. budem rad, ak ma niekto opravi :)
a este by ma zaujimalo, ako presne sa da v linuxe pouzit ssd cache? bcache?
Ten výpočet je špatně, počítáte totiž, že každé video trvá jednu sekundu. Vynásobte to nějakými 30 minutami a zjistíte ten problém :-)
Oprava: počítáte, že každé video trvá jednu minutu (má 50 MB)
-
IOPS jsou Input/Output Operations Per Second, tj. vstupně výstupní operace za sekundu.
Logicky tedy disk, který musí hýbat hlavičkou, udělá tisíckrát méně IOPS než levné SSD.
http://en.wikipedia.org/wiki/IOPS
Slušné pole udělá cca 800 IOPS, levné SSD běžně 40 - 80 000 IOPS.
Takže pokud si dotyčný honí brko u IOPS, pak by měl zahodit pole a koupit si nejlevnější SSD.
Naopak disky v RAID mohou dosahovat lepších výsledků při kontinuálním čtení.
Hodně uživatelů = potřebuje hodně přístupů = potřeba hodně IOPS.
Jeden uživatel = potřebuje získávat hodně dat, třeba zpracovat jedno video na megarychlém cpu = nepotřebuje IOPS, ale propustnost.
-
inak k otazke IOPS na takyto server, za predpokladu idealneho rozlozenia pristup v celom dni, velkosti videa 50 MB za minutu a pouzitom bloku 64 kB (zfs ma variabilnu velkost bloku az do 1024kB, co by sa dalo v tomto pripade pekne vyuzit), dostavam IOPS (50 MB * 16 blokov na MB/60 sekund)*(86400 sekund denne/50000 pristupov) ~= 23. s rastucou velkostou bloku toto cislo dalej padne. takze vlastne cele nahananie sa za IOPS v tomto vlakne je zbytocne. budem rad, ak ma niekto opravi :)
a este by ma zaujimalo, ako presne sa da v linuxe pouzit ssd cache? bcache?
Ten výpočet je špatně, počítáte totiž, že každé video trvá jednu sekundu. Vynásobte to nějakými 30 minutami a zjistíte ten problém :-)
Oprava: počítáte, že každé video trvá jednu minutu (má 50 MB)
Oprava: v prvej zatvorke pocitam, kolko IOPS sa musi urobit pre video, ktoreho minuta ma 50 mega (umyselne vyrazne prestreleny bitrate pre netove videa) pri velkosti bloku 64 kB (1024/64 = 16). ak to zjednodusim a pouzijem bitrate 64 kB/s (512 kbit/s), tak na jedno video sa za 1 sekundu pri velkosti bloku 64 kB musi vykonat prave 1 IOP. cim sa dostavam na 86400/50000 IOPS, co s prstom v nose utiahne CDROMka ;) (ak su splnene vsetky ostatne podmienky). rad budem opraveny.
-
inak k otazke IOPS na takyto server, za predpokladu idealneho rozlozenia pristup v celom dni, velkosti videa 50 MB za minutu a pouzitom bloku 64 kB (zfs ma variabilnu velkost bloku az do 1024kB, co by sa dalo v tomto pripade pekne vyuzit), dostavam IOPS (50 MB * 16 blokov na MB/60 sekund)*(86400 sekund denne/50000 pristupov) ~= 23. s rastucou velkostou bloku toto cislo dalej padne. takze vlastne cele nahananie sa za IOPS v tomto vlakne je zbytocne. budem rad, ak ma niekto opravi :)
a este by ma zaujimalo, ako presne sa da v linuxe pouzit ssd cache? bcache?
Ten výpočet je špatně, počítáte totiž, že každé video trvá jednu sekundu. Vynásobte to nějakými 30 minutami a zjistíte ten problém :-)
Oprava: počítáte, že každé video trvá jednu minutu (má 50 MB)
Oprava: v prvej zatvorke pocitam, kolko IOPS sa musi urobit pre video, ktoreho minuta ma 50 mega (umyselne vyrazne prestreleny bitrate pre netove videa) pri velkosti bloku 64 kB (1024/64 = 16). ak to zjednodusim a pouzijem bitrate 64 kB/s (512 kbit/s), tak na jedno video sa za 1 sekundu pri velkosti bloku 64 kB musi vykonat prave 1 IOP. cim sa dostavam na 86400/50000 IOPS, co s prstom v nose utiahne CDROMka ;) (ak su splnene vsetky ostatne podmienky). rad budem opraveny.
Aha, tak to fakt počítáte jednosekundová videa a druhá část toho výpočtu je úplně blbě (vyjde vám to bezrozměrné, i když IOps je s⁻¹). Pokud bude videí denně 50 000, přičemž každé video má 30 minut, je to (50 000 / 86 400) (kolik videí je každou sekundu zahájeno) × 900 (30 minut na každé video) ≅ 520 paralelně přehrávaných videí. 520 videí × 1 IOps na každé video = 520 IOps. Za předpokladu, že je zátěž ideální, což zcela určitě nebude.
-
...
IOPS jsou IO za sekundu!
Je jedno, jestli máš sekundová videa nebo 30-ti minutová, pro IOPS je relevantní jen to, kolik za vteřinu potřebuješ obloužit klientů.
Za sekundu z pole dostaneš hodnoty v řádech stovek IOPS.
Jestliže datový tok jednoho videa bude rovný právě velikosti načtené jednotky(blohu dat), pak se ti kbps bude rovnat počtu IOPS a současně počtu obsloužených klientů. Všimni si tam toho "PS" to je za sekundu.
Chápeš? 800 IOPS = získá 800 bloků TŘEBA (navolíš sám) po 128 kilobajtech = obslouží 800 klientů s datovým tokem videa 1MBIT v každou chvíli.
-
...
IOPS jsou IO za sekundu!
Je jedno, jestli máš sekundová videa nebo 30-ti minutová, pro IOPS je relevantní jen to, kolik za vteřinu potřebuješ obloužit klientů.
Za sekundu z pole dostaneš hodnoty v řádech stovek IOPS.
Jestliže datový tok jednoho videa bude rovný právě velikosti načtené jednotky(blohu dat), pak se ti kbps bude rovnat počtu IOPS a současně počtu obsloužených klientů. Všimni si tam toho "PS" to je za sekundu.
Chápeš? 800 IOPS = získá 800 bloků TŘEBA (navolíš sám) po 128 kilobajtech = obslouží 800 klientů s datovým tokem videa 1MBIT v každou chvíli.
Pokud ty videa mají průměrně 30 minut, poběží jich paralelně průměrně 520. Pokud budou mít průměrně 30 sekund, poběží jich paralelně průměrně 9, takže na jejich obsloužení stačí šedesátina IOPS. Už to chápeš?
Btw. ukaž mi CD-ROMku, co zvládne 50 000 videí denně
-
Jo a doporučuju při takových výpočtech vždycky dělat rozměrovou zkoušku.
Tvůj výpočet:
IO/s × (s/den) / (video/den) = IO/video. To zřejmě nejsou IOPS
Můj výpočet:
IO/s × (video/den) / (s/den) × (s/video) = IO/s. To rozměrově jsou IOPS a můžeme se bavit tak akorát o hodnotách
-
...
IOPS jsou IO za sekundu!
Je jedno, jestli máš sekundová videa nebo 30-ti minutová, pro IOPS je relevantní jen to, kolik za vteřinu potřebuješ obloužit klientů.
Za sekundu z pole dostaneš hodnoty v řádech stovek IOPS.
Jestliže datový tok jednoho videa bude rovný právě velikosti načtené jednotky(blohu dat), pak se ti kbps bude rovnat počtu IOPS a současně počtu obsloužených klientů. Všimni si tam toho "PS" to je za sekundu.
Chápeš? 800 IOPS = získá 800 bloků TŘEBA (navolíš sám) po 128 kilobajtech = obslouží 800 klientů s datovým tokem videa 1MBIT v každou chvíli.
Hlavně tu nikoho evidentně netrápí jestli to je náhodné nebo sekvenční čtení. Když vezmu 15k disk tak ten udělá 250 seeků, tj. ~200 IOPS za vteřinu, ty s dobře udělaným NCQ/TCQ udělají >300 IOPS. Tj. pokud budu dokonale náhodně seekovat např. 4kB bloky tak udělám ~1MB/s. Jenomže ten samej disk udělá s přehledem přes 150 MB/s, což kdybych tupě přepočítával na 4kB IOPS je > 38000.
Pokud ta aplikace nebude úplně hloupě napsaná tak ta videa nebude načítat po maličkých blocích ale vždycky si načte pár MB dopředu. Navíc operační systémy dneska mají něco čemu se říká read-ahead (případně to umí i RAID řadiče), tj. na základě analýzy jednotlivých I/O requestů poznají že se vlastně daný soubor / část disku čte sekvenčně a přednačítají data. Takže s trochou snahy se výkon bude výrazně blížit tomu sekvenčnímu maximu (ale pokazit jde všechno ...).
Současně jsem tady nikde neviděl informaci o kolik dat se vlastně jedná - pokud je to srovnatelné s velikostí RAM tak se to celé nacachuje a je úplně jedno jestli jsou to spinners nebo SSD disky. A u tohohle typu dat je to většinou tak že pár položek je "hot" a ty jsou v paměti, no a drtivá většinu položek skoro nikoho nezajímá. Ty hot položky jsou ve výsledku v cache filesystému, to že se pomalé položky musí sosat z disku nikoho moc netrápí (je to malá zátěž) a systém se většinou škrtí na CPU.
-
Co to tu kurva počítáte jako dementi ??? ;D ;D
Proč prostě normálně nepoužijete RAID kalkulačku ?????
http://www.wmarow.com/strcalc/
A tady je to vysvětlené tak, že to pochopíte i vy: http://www.symantec.com/connect/articles/getting-hang-iops
A) Není možné počítat průměrnou zátěž, těžko bude stejné vytížení ve 4 ráno jako v 8 večer!
Všechny zábavní servery mají peek mimo jiné v 19:30 až 21:30, kdy se přihlašuje cca 35% uživatelů.
2Sten: Nedělej retarda, že to nechápeš.
Pokud máme přehnáno za den 50 000 videí, pak v době peeku jich bude přehráno cca 18 000!
A dál, co je to za ptákovinu video o délce 30 minu?
Videa jsou buď cca 3-5minut (klipy, písničky, zábava), cca 45 minut seriály včetně reklam, cca 120 minut filmy.
A jinak se to počítá cca takto:
Bude se nejspíš jednat o videa typu 3-5 minut, řekněme že průměr bude 4, pak tedy 4*60= 240 sekund videa.
240 sekund videa * 18 000 vidí = 4 320 000 sekund videa přehrátých za dobu 19:30-21:30, tj. za 120minut*60.
Musíme tedy přehrát 4 320 000 sekund videa za 120*60= pak 4 320 000 / 7200 = tedy musím přehrát 600 sekund vida každou vteřinu.
Tj. v peeku mám připojených cca 400 až 800 uživatelů každou vteřinu a všichni si přehrávají si video.
Abych je mohl všechny spolehlivě obsloužit, nejspíš budu potřebovat víc než 200-300 IOPS.
Hodně pořeší cache, nejspíš i bez toho, aby tomu provozovatel serveru rozuměl.
-
Současně jsem tady nikde neviděl informaci o kolik dat se vlastně jedná - pokud je to srovnatelné s velikostí RAM tak se to celé nacachuje a je úplně jedno jestli jsou to spinners nebo SSD disky. A u tohohle typu dat je to většinou tak že pár položek je "hot" a ty jsou v paměti, no a drtivá většinu položek skoro nikoho nezajímá. Ty hot položky jsou ve výsledku v cache filesystému, to že se pomalé položky musí sosat z disku nikoho moc netrápí (je to malá zátěž) a systém se většinou škrtí na CPU.
To jsem přesně psal výše.
-
Následuj RUMA: jakákoli SSD i paměťová cache (do serveru dneska nacpeš klidně 128GB RAM) Ti to zrychlí mnohem víc, než RAID.
Jinak jestli to bude pole, kde se bude velká převaha read operací, tak by stálo za to nezahazovat RAID5. Protože narozdíl od 10 má sice zoufalej zápis (což ovšem pro ukládání velkejch videí nevadí), ale při čtení může těžit z toho, že data jsou při sekvenčním čtení rozházený po všech discích ale přitom (na rozdíl od radidu 10) se nečte nic zbytečnýho. Viz např.
http://www.kendalvandyke.com/2009/02/disk-performance-hands-on-part-5-raid.html
V takovém případě ale zcela určitě dej databázi a logy na jiný pole (což je rozumný asi i tak) - na RAID5 patří pouze "readonly" operace.
Potvrzujes moji myslenku, dekuju
-
A) Není možné počítat průměrnou zátěž, těžko bude stejné vytížení ve 4 ráno jako v 8 večer!
Všechny zábavní servery mají peek mimo jiné v 19:30 až 21:30, kdy se přihlašuje cca 35% uživatelů.
2Sten: Nedělej retarda, že to nechápeš.
Samozřejmě, doporučuju se podívat před to (http://forum.root.cz/index.php?topic=5602.msg52027#msg52027), kde jsem se snažil opravit ten nesmyslný výpočet, akorát ty čísla mám trochu menší, protože jsem počítal to časové okno delší (mezi 19:00 až 22:00).
A dál, co je to za ptákovinu video o délce 30 minu?
Videa jsou buď cca 3-5minut (klipy, písničky, zábava), cca 45 minut seriály včetně reklam, cca 120 minut filmy.
Když jsem provozoval v uzavřené síti sdílené úložiště s videi (i když jsem teda měl průměr „jen“ kolem 700 videí denně), byla průměrná délka přehrávaných videí někde mezi 20 až 30 minutami, jak kdy. Samozřejmě tam byly všechny typy videí a ve špičce to většinou drtily filmy. Naopak třeba na YouTube moc seriálů ani filmů není, takže tam bude ten průměr o dost menší.
Následuj RUMA: jakákoli SSD i paměťová cache (do serveru dneska nacpeš klidně 128GB RAM) Ti to zrychlí mnohem víc, než RAID.
Jinak jestli to bude pole, kde se bude velká převaha read operací, tak by stálo za to nezahazovat RAID5. Protože narozdíl od 10 má sice zoufalej zápis (což ovšem pro ukládání velkejch videí nevadí), ale při čtení může těžit z toho, že data jsou při sekvenčním čtení rozházený po všech discích ale přitom (na rozdíl od radidu 10) se nečte nic zbytečnýho. Viz např.
http://www.kendalvandyke.com/2009/02/disk-performance-hands-on-part-5-raid.html
V takovém případě ale zcela určitě dej databázi a logy na jiný pole (což je rozumný asi i tak) - na RAID5 patří pouze "readonly" operace.
Potvrzujes moji myslenku, dekuju
Tohle ale platí pouze do doby, než začne resync pole, tam je RAID 5 v háji. Třeba Debian jej dělá z bezpečnostních důvodů (jako ochranu před silent corruption) jednou týdně a počítejte s tím, že to může trvat i celý den.
-
Když jsem provozoval v uzavřené síti sdílené úložiště s videi (i když jsem teda měl průměr „jen“ kolem 700 videí denně), byla průměrná délka přehrávaných videí někde mezi 20 až 30 minutami, jak kdy. Samozřejmě tam byly všechny typy videí a ve špičce to většinou drtily filmy. Naopak třeba na YouTube moc seriálů ani filmů není, takže tam bude ten průměr o dost menší.
Chápu, měl jsi smíšený obsah, kdy se část lidí koukala na klipy jak Hitler nadává na Klause a část se dívala na filmy, takže průměr byl cca 20 až 30 minut.
To pak chápu, ale pro tento provoz by bylo dobré sestavit korelační graf (pár kliknutí v Excelu) a říct, o co se vlastně jedná.
Pak se z toho dá postavit optimalizace.
Jinak se přikláním k tomu, že RAID 5 není žádný zázrak, ostatně POUŽIJTE NĚKDO TU RAID KALKULAČKU A SPOČÍTEJTE SI TO.
(To není na tebe Stene.)
-
Sten: No pokud bych už dělal RAID5, tak rozhodně ne softwérově na debianu. Takovýdle věci má smysl dělat na kvalitním HW řadiči, pokud možno s battery backupem. A takové pole rozhodně nebude dělat resync jednou tejdně.
Rum: K čemu "teoretická" kalkulačka, když jsou benchmarky z praxe? Jsou prostě situace, kdy RAID5 nabídne víc než raid 10. Ne nijak zásadně, ale natolik, aby mělo smysl o něm uvažovat.
-
Kapitan RUM na to ide lepsie. Zvladne to iste ale s neporovnatelne nizsimi nakladmi. Odporucam ti ist touto cestou, ta je najlesia.
Dík!
To mě dost těší ;D
Ono se s tím dá totiž ještě víc kouzlit.
Příklad souboru, který je v permanenci, tj. dostal se jak na SSD tak zůstal na poli (na SSD je vždy jen kopie):
Zjistím, že SSD je vytížené na 100%, v takovém případě mohu některým uživatelům podávat data i z pole!
Třeba:
Připojí se mi najednou 20 000 uživatelů (je špička) a všichni se chtějí dívat na Gangnam style
http://www.youtube.com/watch?v=9bZkp7q19f0
Zbytek dalších mají rozkoukaného Hobita.
Pokud bych měl jen jedno pole, tak to půjde celé do hajzlu.
Takhle můžu například zjistit vytížení SSD (lze i z PHP) i diskového pole, zjistím, že SSD je právě v háji, ale pole na tom tak hrozně není, tak budu vracet pro nová připojení odkazy na jejich umístění v poli. Možná to není nejgeniálnější load balance, ale určitě to bude fungovat.
Podobný smysl může mít i ramdisk, pokud by mi většinu zátěže tvořilo třeba 5-10GB videí, nejspíš bych je nakopíroval na ramdisk.
Ten by měl velký smysl hlavně v případě, kdy se opravdu jedná o omezený počet kousků, které máš ohodnocené nějakým testem a máš předpoklad, že to bude stahovat tolik a tolik lidí.
Některé SSD disky mají 1GB cache, pro tvůj případ mi takové přijdou jako užitečné.
Levné SSD, které použiješ jako cache (je na nich kopie).
Při určitém typu zátěže bys mohl mít na obou SSD discích stejné video a prostě vracet cestu ke stažení/prohlížení napřeskáčku.
(Pro stejný soubor dostane klient 1 odkaz na první SSD, druhý na druhé SSD, třetí opět na první SSD....)
Cílem není rovnoměrná zátěž, protože třeba uživatelé číslo 3,5,7,9 se odpojí, ale pokud to takhle budeš praktikovat pro všechny soubory na SSD (CACHE), pak se ti stejně v celkovém průměru zátěž zprůměruje.
Jak jednou víš, kolik lidí to video bude chtít stahovat, můžeš se už spolehlivě postarat o to, aby to proběhlo v pořádku a pole ti nedoutnalo jak hlavičky cvičí.
Ja bych osobne sel trochu dal a distribuoval bych ten obsah po vice uzlech, cili vytvoril bych si takovou malou cdnku.
rozvrstvil bych si soubory do 3 urovni:
50G nejnavstevovanejsich
200G nejnavstevovanejsich
zbytek
Na kazdem ze dvou serveru bych:
vytvoril (pokud mas hodne ram) 60G ramdisk
koupit 2x +200G ssd a dat do kazdeho serveru jeden
vsechna data mit na hlavnim poli.
ted na oba servery nainstalujes lighttpd/nginx/khttpd*
a udelas si 6 ruznych adres (2 servery * 3 urovne ulozist)
a ted ta kouzla, do nejake hash tabulky, kde mas umisteni pridas sloupec VIP, kde budes mit cisla 1-3, cislo 3 bude pro ty nej 2 bude pro ty hodne navstevovane a 1 pro ty ostatni. Podle toho budes na pozadi X krat denne kopirovat vse co ma VIP > 2 das na ssd a vse co ma VIP = 3 do ram disku, tim padem to nej bude na 6ti mistech, to hodne navstevovane na 4 mistech a to ostatni je jasne.
Dale si pak vytvoris pozorovanim nejakej algoritmus, kde budes urcovat kolikrat za minutu vratis uzivateli kterou url, nebo kolik vratis url z jednotlivych ulozist za jednotku casu.
Takle ziskas vlastni nekolikaurovnovou cdnku do ktere budes moci dal pridavat fyzicke servery a tim skalovat az do haleluja. Surovej vykon je fajn, ale neni nekonecnej a kdyz nebudes narazet na io disku budes narazet na propustnost, timto zpusobem muzes reagovat i na georafickou polohu zakazniku, za par let se ti to rozroste budes mit treba mega navstevnost z polska a bude pro tebe vyhodne postavit si jeden stroj treba nekde pobliz, takle na to budes pripraven. 8) 8) 8)
Dalsi vyhodou je, ze pokud dojde k necekanemu restartu, nebo odchodu ssd neztratis data.
-
To se mi moc líbí!
Rum to napsal pěkně a logicky, jako základ dobrý, ale právě ta distribuce z toho udělalá skvělé řešení!
+1 pro oba!!!