Fórum Root.cz
Práce => Studium a uplatnění => Téma založeno: ABLincoln 02. 04. 2014, 15:30:24
-
nazdar nazdar,
trosku by som potreboval poradit ohladom statnicovej otazocky, resp. prikladu. Mame disk Seagate ST4000DM000 s parametrami:
MTBF(MTTF) = 750 000 hours
AFR = 0.34%
Average data transfer rate read/write = 146 MB/s
Average read seek time = 8.5ms
Average write seek time = 9.5ms
RPM = 5900
Capacity = 4TB
Vybral som si jednu z moznosti RAID 10. K vytvoreniu pola som pouzil 4 disky, co je minimalne pre RAID 10. No a uloha znie, vypocitat MTTDL a MTTR.
Vedeli by ste mi trosku pomoct?
Na nete som nasiel ze MTTR je doba potrebna k obnove poskodeneho disku, ale toto ziadny vyrobca ani neudava a nenasiel som nato ziadny vzorec.
Dakujem
-
Na nete som nasiel ze MTTR je doba potrebna k obnove poskodeneho disku, ale toto ziadny vyrobca ani neudava a nenasiel som nato ziadny vzorec.
Když jste nenašel vzorec tak nejspíš nezbývá než ho vymyslet. Co takhle MTTR spočítat pomocí těch 146 MB/s? Špatný disk se vyhodí, místo něj se do pole dá nový disk na který je třeba ze zbytku pole nakopírovat příslušná data...
-
No tiez som nad tym uvazoval. Len mi vyslo celkom vysoke cislo.
Postup:
4TB = 4194304MB
doba prekopirovania = 4194304 / 146 = 28728,11 sekund -> doba za ktoru sa to prekopiruje. To som premenil na hodiny, co mi vyslo nieco okolo 8hod a to sa mi zda celkom vela.
-
MTTR disku = kapacita / rychlost zápisu. MTTR pro RAID 10 je 0 (výpadek disku nezpůsobí výpadek pole). MTTDL je hodně složité, tady (https://www.usenix.org/legacy/event/hotstorage10/tech/full_papers/Greenan.pdf) je, jak se to počítá. Oboje jsou ale čísla akorát pro markeťáky (= naprosto k ničemu) :)
-
No tiez som nad tym uvazoval. Len mi vyslo celkom vysoke cislo.
Postup:
4TB = 4194304MB
doba prekopirovania = 4194304 / 146 = 28728,11 sekund -> doba za ktoru sa to prekopiruje. To som premenil na hodiny, co mi vyslo nieco okolo 8hod a to sa mi zda celkom vela.
Vítejte v praxi IT provozu. Ano, rebuild velkého RAID pole trvá dlouho, obzvlášť když měníte tak velký disk. U RAID 10 to ještě není tak kritické, větší sranda je to u RAID 5, protože tam v tu chvíli stačí aby odešel libovolný ze zbývajících disků (což je v tu chvíli díky jejich zvýšené zátěži ještě o trochu pravděpodobnější) a je po datech...
-
Úplně nesmyslná otázka... ::) Jednak, jak už někdo zmínil, ty marketingové hodnoty jsou na velké hnědé mazlavé, za druhé, samozřejmě záleží na tom, jestli to tam prdnu jako hotswap, event. hotspare, a na té mašině mezitím normálně poběží stávající služby, nebo holt všechno bude celou dobu down a poběží jen ta obnova, a dál pochopitelně na nastavení OS, např. u Linuxu viz
/proc/sys/dev/raid/speed_limit_max
/proc/sys/dev/raid/speed_limit_min
-
Teraz som trosku na rozpakoch. Pri RAID 10 je MTTR = 0, kedze to neovplyvni nijak chod pola alebo je nutne pri vypadku jedneho disku v RAID 10 prekopirovat 4TB dat, co by v tom pripade znamenalo tych 8hod, ako som napisal?
Ak je pripad RAID 0, tak tam sa asi o ziadnom MTTR ani neda hovorit, kedze v pripade pola RAID 0 sa pride o vsetky data?
-
těch 8 hodin je také čistá teorie, bude platit v případě prázdného nevyužívaného pole a to ještě možná, protože kontinuálně to stejně nepojede na plnou rychlost. V realu s polem které je v provozu, počítejte, že na rebild disku se použije maximálně 10-15 procent dostupného IO, ostatní IO sežerou servery a procesy využívající dané pole. čím více tím to bude horší.
v případě MDraid by Vás mohla zajímat položka /proc/sys/dev/raid/speed_limit_[min|max] kde se dá nastavit minimální a maximální rychlost syncu. Čím vyšší min, tím se disk rychleji bude syncovat, ale omezí se kapacita IO pro aplkace nebo servery.
-
Och jo, zas teoreticke sracky a prax je uplne ina. Tzn. ak uvazujeme z Average data transfer rate = 146 MB/s 15%, to je 21.9 MB/s, potom to cini skoro 54 hod na prekopirovanie. WTF!
-
No, nevěříte tomu ? Zkuste si rebuidnout pole 4x4TB R10 na kterém máte několik VM serverů přes iSCSI, popřípadě vytížené DB servery s velikým RW do pole. Pokud dáte vysokou prioritu do resync pošlete servery do kytek. Proto rebuid R5 pole není legrace pokud se jedná o veliké disky 2-4TB, může to trvat klidně 48 hodin a více. ten disk Vám neudělá 146MB/s write kontinuálně po celou dobu, navíc nejde jen o write do failnutého disku, ale také o read z těch zdravých.
-
Teraz som trosku na rozpakoch. Pri RAID 10 je MTTR = 0, kedze to neovplyvni nijak chod pola alebo je nutne pri vypadku jedneho disku v RAID 10 prekopirovat 4TB dat, co by v tom pripade znamenalo tych 8hod, ako som napisal?
Ak je pripad RAID 0, tak tam sa asi o ziadnom MTTR ani neda hovorit, kedze v pripade pola RAID 0 sa pride o vsetky data?
No, ona neexistuje žádná pevně dané definice, co MTTR znamená. Pokud vycházím z definice, že MTTR znamená, jak dlouho trvá, než je daná služba opět k dispozici (Mean Time to Recovery v původním významu), pak MTTR pro RAID 10 je 0 (pokud se tedy degradované pole nerozhodnete odstavit do skončení replikace), nicméně pro daný disk v tom poli je rovna době, než se na něj dostanou data. Pak do toho můžete i přimíchat nutnost fyzické výměny disku, pokud tam není hotspare. Anebo můžete použít definici, že MTTR znamená, jak dlouho trvá, než je dané služba opět v plném provozu (Mean Time to Repair). Pak by MTTR RAIDu bylo rovno MTTR daného disku. A ještě existují další definice: Mean Time to Respond, Mean Time to Replace, Mean Time to Resolve ap., samozřejmě do toho můžete nebo nemusíte počítat latentní dobu (od objevení chyby do její detekce) a tak dále.
U RAID 0 bráno bez vnějších vlivů nemá Mean Time to Recovery smysl. U složitějších systémů s RAID 0 se MTTR většinou počítá jako doba obnovení (Mean Time to Recover), v tomto případě většinou ze záloh. Ale jak sám vidíte, čísla to jsou dost k ničemu, když se k tomu neuvede, co vlastně znamenají a co do nich započítáváte.
-
No, nevěříte tomu ?
Len ci tomu uveri komisia, ked im poviem taketo cislo ;D
-
Len ci tomu uveri komisia, ked im poviem taketo cislo ;D
Tohle se skutečně někde dává jako státnicová otázka? Bože... (A propos, už den volba toho disku je nesmyslná, ty disky jsou pro RAID naprosto nevhodné, to pole se neustále bude sypat. Jinak to je početní cvičení tak pro ZŠ s tím, že zjištěný "výsledek" je úplně k ničemu.)
Jinak z praxe třeba nedávná migrace RAID-1 => RAID-10 (4 x 2TB) - no prostě v pátek když padla se to pustilo a v pondělí ráno bylo s velkým štěstím hotovo. ::)
-
ten disk v otazke konkr. nie je uvedeny, to som si zvolil nahodne, na skuske bude nejaky tiez zvoleny. Ja som si vybral tento, kedze pri niektorych som nevedel najst potrebne parametre :)
-
ten disk v otazke konkr. nie je uvedeny, to som si zvolil nahodne, na skuske bude nejaky tiez zvoleny.
Konečně najdu knížku, která říká: „Matematiky se mnohostranně používá ve vědě. Uvedeme vám příklad z astronomie, což je nauka o hvězdách." Otočím stránku a tam se praví: „Červené hvězdy mají teplotu čtyři tisíce stupňů, žluté hvězdy mají teplotu pět tisíc stupňů...", až sem je to v pořádku. Pokračují: „Zelené hvězdy mají teplotu sedm tisíc stupňů, modré hvězdy mají teplotu deset tisíc stupňů, fialové hvězdy mají teplotu... (nějaké velké číslo." Žádné zelené nebo fialové hvézdy neexistují, i když údaje pro ostatní jsou zhruba správné - zase potíže! A takhle vypadalo všechno: psal to někdo, kdo pořádné nevěděl, o čem mluví, takže to bylo vždycky trochu špatně! A jak dobře učit podle knížek napsaných lidmi, kteří pořádně nerozumějí tomu, o čem mluví, to nedovedu pochopit. Nevím proč, ale ty knížky byly mizerné; MIZERNÉ PO VŠECH STRÁNKÁCH!
S poslední učebnicí jsem tedy byl spokojený, byla to první knížka s příkladem na použití aritmetiky ve vědě. Byl jsem maličko
nespokojený, když jsem četl o teplotách hvězd, ale nebyl jsem zase moc nespokojený, protože to bylo víceméně správně - byl to
jen příklad chyby.Jenže pak následovala cvičení: Jan jde s otcem ven podívat se na hvězdy. Jan vidí dvě modré hvězdy a jednu červenou. Otec vidí zelenou, fialovou a dvě žluté hvězdy. Jaká je celková teplota hvězd, které Jan a otec vidí?" - a já vybuchl děsem. Proto moje žena vykládala o sopce v suterénu. Tohle je jenom jeden z přikladu: takovéhle to bylo věčně. Věčně samý nesmysl. Neexistuje absolutné žádný důvod pro sčítání teplot dvou hvězd. Nikdo to nikdy nedělá, leda možná, aby potom vypočítal průměrnou teplotu hvězd, ale ne aby zjistil celkovou teplotu všech hvězd! Bylo to příšerné! Nešlo o nic víc než o hru, jak vás přimět sčítat, a neměli ponětí o tom, co povídají. Připadal jsem si, jako když čtu věty s pár tiskovými chybami, a vtom, najednou, je celá věta vytištěna pozpátku. Takhle ta matematika vypadala. Prostě beznadějně." (Richard P. Feynman, To nemyslíte vážně, pane Feynmane!)
-
https://blogs.oracle.com/relling/entry/raid_recommendations_space_vs_mttdl: "For MTTR you need to consider the logistical repair time, which is usually the time required to identify the failed disk and physically replace it." + "if you have a multi-level RAID set, such as RAID-1+0, then you need to use both the single parity and no protection MTTDL calculations to get the MTTDL of the top-level volume."
-
Jen k tý době rebuildu (u MDraidu).
Rebuildil jsem skoro 900GB pole, komp nic jinýho nedělal. Trvalo to tři hodiny, průměrná rychlost přes 80MB/s. Průměrná rychlost čtení těch disků je kolem 110MB/s. Lze tedy tvrdit, že to šlo pravděpodobně maximální možnou rychlostí v danou chvíli (opakuju - s PCse nic jinýho nedělalo po celou dobu rebuildu).
To jen moje zkušenost.
-
Pri MTTDL som vychadzal zo vzorca:
MTTDL = (MTBF^2) / ((N) * (N - 1) * MTTR) = (750 000 ^ 2) / ((4) * (4 - 1) * 8) = 668878 rokov.
N - pocet diskov
MTTR - udal som teoreticku hodnotu co mi vysla, 8hod.
Ak sa mylim, opravte ma prosim :)
-
Chcel by som sa este spytat, mozno taku trosku "primitivnu" otazku. Nahodne nacitanie jedneho bloku v poli RAID 10 pri 4 diskoch je 4x rychlejsie alebo sa to tyka len jedneho disku, cize normalne 1x? Ak beriem do uvahy velkost bloku 4KB na disku, tak nemozno precitat tento blok 4x rychlejsie, ked sa nachadza 4KB na jednom disku. Opravte ma, ak sa mylim.
-
Pavouk106: Budte rad, ze po vas nechteli vyznacit mnozinu zelenych a cervenych hvezd, dale mnozinu zlutych a modrych, urcit jejich celkove teploty a hodnoty porovna s hodnotou mnoziny brambor z lonske urody EU.
-
Chcel by som sa este spytat, mozno taku trosku "primitivnu" otazku. Nahodne nacitanie jedneho bloku v poli RAID 10 pri 4 diskoch je 4x rychlejsie alebo sa to tyka len jedneho disku, cize normalne 1x? Ak beriem do uvahy velkost bloku 4KB na disku, tak nemozno precitat tento blok 4x rychlejsie, ked sa nachadza 4KB na jednom disku. Opravte ma, ak sa mylim.
Pokud k tomu RAIDu přistupuje jen jedno vlákno, tak při čtení jednoho bloku je rychlost stejná jako u jednoho disku, při čtení více je dvojnásobná (díky prokládání RAID 0). Pokud přistupují dvě vlákna, tak díky zrcadlení RAID 1 mohou číst obě najednou, takže je to dvojnásobně rychlé oproti jednomu vláknu (tzn. pokud čtou jeden blok, je to 2× rychlejší, pokud víc, tak 4×). Pro víc vláken to konverguje ke 4× pro oba způsoby čtení: při čtení jednoho bloku lze obsloužit až čtyři vlákna najednou, ale každé jede rychlostí jednoho disku, při čtení více bloků lze obsloužit jen dvě vlákna, ale zato při rychlosti dvou disků.
-
No, nevěříte tomu ? Zkuste si rebuidnout pole 4x4TB R10 na kterém máte několik VM serverů přes iSCSI, popřípadě vytížené DB servery s velikým RW do pole. Pokud dáte vysokou prioritu do resync pošlete servery do kytek. Proto rebuid R5 pole není legrace pokud se jedná o veliké disky 2-4TB, může to trvat klidně 48 hodin a více. ten disk Vám neudělá 146MB/s write kontinuálně po celou dobu, navíc nejde jen o write do failnutého disku, ale také o read z těch zdravých.
Takovy pole je ale ciste teoreticka srajda ... protoze v praxi by ti na nem nic nefungovalo. Databaze potrebuje predevsi IOps a ty ze 4 disku nedostanes. Jinak u R5 hodne zalezi na velikosti (poctu disku) toho R5 pole. Velmi se nedoporucuje delat vetsi nez 4-5 disku (navic s vice disky roste riziko). Prepocet 4x 1GB R5 sata trva cca 15 hodin, 5x 300GB 10k sas trva cca 5 hodin. To jsou minimalni casy kdyz se pole flaka.
Chcel by som sa este spytat, mozno taku trosku "primitivnu" otazku. Nahodne nacitanie jedneho bloku v poli RAID 10 pri 4 diskoch je 4x rychlejsie alebo sa to tyka len jedneho disku, cize normalne 1x? Ak beriem do uvahy velkost bloku 4KB na disku, tak nemozno precitat tento blok 4x rychlejsie, ked sa nachadza 4KB na jednom disku. Opravte ma, ak sa mylim.
Ani jedno ... 2x (teoreticky) a je jedno kolik mas disku. R10 = mas kazdy blok k dizpozici na dvou discich => pokud to radic umi (netusim zda tohle zvlada swraid), tak muze cist z obou zrcadlenych disku zaroven. Samozrejme zalezi i na tom, v jakym pomeru mas fyzickej blok na disku vs blok toho raidu. Pokud by to bylo 1:1 , tak k zadnymu zrychleni nedojde (bezne je blok raidu trebas 64kB => pulka se precte z jednoho a druha pulka z druhyho disku). Samo plati pro cteni prave jednoho bloku dat.
R10 v klasicky konfiguraci ma parametry pro cteni (teoreticky) = poctu disku, parametry pro zapis pak poctu stripu (tedy bezne pulka). Jde samozjreme o cteni/zapis rozlozeny na vsechny disky (coz pri bezne provozu +- plati).
-
neco se zkouset musi, jinak by ty diplomy rozdavali zadarmo kazdymu pri narozeni. co na tom, ze je to na hony daleko od praxe.
1) nespecifikovano, zda je podle pri resyncu v degradovanem rezimu v provozu
2) nespecifikovano, zda je systemove omezena rychlost resyncu
3) nespecifikovano, zda je povoleny smart a spusteni testu zrovna pri resyncu
4) nespecifikovano, zda a kolik je realokovanych bloku co zvysi pocet seeku pri resyncu mimo provoz
5) nespecifikovano, jaka je prumerna opravitelna chybovost cteni
6) nespecifikovano, kolik ma disk minimalni propustnost na rozdil od te prumerne marketingove (Fixed DTR hdparm -i) kdyz se potka smart i ecc recovery s datovym provozem.
-
7) nespecifikovano, zda maji disky stejny format bloku 512, 512e, 2048, ...
8) nespecifikovano, zda disky pouzivaji stejne hodnoty prokladani sekotru
...
-
neco se zkouset musi, jinak by ty diplomy rozdavali zadarmo kazdymu pri narozeni. co na tom, ze je to na hony daleko od praxe.
No, jde to opravdu z kopce. Marketingoví "vědátoři" v IBM (http://www.itbiz.cz/zpravicky/intel-pravdepodobnost-selhani-hp-bladesystemu-s-intel-xeonem-e5-je-nizsi-nez-ze-zasah-cloveka-bleskem) ;D
-
Dodal bych, že jakékoli tyhle výpočty jsou pro praxi nepoužitelné, real life je vždycky o řád horší než jakákoli statistika, protože musím počítat s worst case scenario. Je úplně normální, že na serveru který je jinak celkem vytížený, trvá rebuild/resync disku třeba i den dva, i když matematicky by to mělo být do desíti hodin.