Počet pevných disků v RAID a IOPS

[Markus]

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.

[Reklama]

[bw]

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.

[Sten]

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.

[Markus]

...

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.

[Sten]

...

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ě

[Reklama]

[Sten]

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

[Tomáš Vondra]

...

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.

[PanKapitánRUM]

Co to tu kurva počítáte jako dementi  

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.

[PanKapitánRUM]

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.

[creco]

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

[Sten]

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, 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.

[PanKapitánRUM]

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.)

[Logik]

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.

[masi]

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ěší 

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.

Dalsi vyhodou je, ze pokud dojde k necekanemu restartu, nebo odchodu ssd neztratis data.

[Blabla]

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!!!