Ja bych poprosil o custom firmware, ktery bude temi rameny hejbat proti sobe, takze disk nebude vytvaret vibrace a muze se pouzit v NASu, a taky mapovani sektoru bude rozlozeno tak, ze vice casteji budou pouzity sektory z vnejsi nez vnitrni pozice, takze se ziska rotacni disk s konstantni prenosovou rychlosti, nezavisle na adrese (ta prenosova rychlost bude prumerem vnejsi a vnitrni rychlosti).
Co myslíte tím „mapovani sektoru bude rozlozeno tak, ze vice casteji budou pouzity sektory z vnejsi nez vnitrni pozice“? Marně přemýšlím nad smyslem. Disk má nějakou kapacitu a ta je rozložená přes celou plochu ploten, takže (typicky) nižší LBA jsou vně (a tedy rychlejší) a vyšší LBA uvnitř (a tedy pomalejší) - viz klasický graf sekvenčního čtení disku (pomíjím výjimky typu remap sektoru, když se stávající vyhodnotí jako vadný). Jak to chcete jinak preferovat než použitím konkrétního bloku disku? Prostě na začátku je disk rychlejší, na konci pomalejší, proč by to mělo být jinak?
Mysleno to bylo tak, ze dve ramena se muzou chovat jako RAID-0, striping.
Pokud ale pojedou proti sobe, tj. jakoby jeden disk z RAID0 byl mapovany odzadu, tak bude prenosovka jenom 2*NejPomalejsihoDisku. Protoze jsou zde symetricky rozkladany sektory podle adrese, nehledne na rychlosti.
To co navrhuji ja, by bylo aby v extremni poloze byly (napr.) 3 sektory vne ku 1 uvnitr, tvorici stripe z raidu ktery ma 4 sektory. A uprostred ploten to bude presne 2:2 symetricky, protoze rychlosti disku jsou stejne, nezavisle na smeru kterym k nemu pristupujete.
Proste chci, aby disk byl stejne rychly v kazde adrese - DVE proti sobe se pohybujici hlavy tohle muzou zajistit, pokud budou sektory rozlozeny asymetricky. To dynamicke mapovani by slo simulovat na dvou diskretnich discich, ale tim se nezbavime vibraci - protoze to uz vyzaduje vystavovani hlav zcela synchronne.
Tak jednak NAS neni neco co ma jen 2-4 disky.. vedle stolu mam 2x24 bay uloziste.
A ze vibrace nejsou problem? No.. staci vicero aktivnich uzivatelu do uloziste a na problem mate zadelano. Vase domaci zaloha fotek vibrovat nebude.
(ono staci i jeden lokalni uzivatel.. kdyz zacnu uklizet a presouvat data mezi LVM partisnama ktere jsou nahodou na stejnem poli.. tak se to jde pretrhnout v seeku)
Nedávno jsem do 12-bay NASu přidal dva Seagate IronWolfy, a můžu říct, takovej kravál jsem nečekal. Měl jsem předtím jen WD Redy, přišlo mi to už tehdy trochu hlučný, tak jsem v recenzích těch Seagatů poznámky o hluku ignoroval. Chyba! I jen rotace ploten slyšitelně duní i z vedlejší místnosti, a seek je jak kdybych kopal do stolu :-)
Mimochodem zajímavé je, že SAS verze tohohle disku se bude tvářit jako dva LUNy (18TB bude jako dva 9TB, každý LUN bude obsluhován jednou sadou hlaviček). SATA verze bude klasicky vcelku, první půlka kapacity bude jedna sada hlav, druhá půlka druhá sada hlav a aby se ten „dvojitý“ výkon využil, musí na to myslet „obsluha“ (např. dvě partišny, každá na půlce, a dělat s oběma současně, apod.).
Já jsem si jeden čas myslel, že víceplotnový disk se fakticky vždy chová jako RAID0 - tzn. při sekvenčním čtení se „sčítají“ rychlosti ploten, že se jako se všemi pracuje paralelně a tím je to rychlejší. A ono ne. Ono se prostě jede po plotnách. Což je škoda, protože se takové řešení úplně nabízí, disk má cache, máme tu NCQ…
RAID0 z toho jde pak udělat softwarově (na SAS variantě disku snadno, když jsou to dva LUNy, na SATA variantě holt uděláte dvě partitions, jednu 0 - 50 %, druhou 50 % - 100 % a to si pak hodíte do RAID0, takhle to i zmiňuje Seagate).
Chápu, zrcadlení by mělo poskytovat jistou ochranu proti selhání jednoho z disků, ale protože se to nejen tváří jako dva disky, ale fyzicky se to i chová jako dva disky, tak by se to dalo i tak použít. Seagate k tomu píše:
…this drive can work with software RAID, but considerations need to be made
around setting up redundancy across actuators in the same drive so that you would not lose data in the rare event of a total drive failure…
Jasně, já bych to nedělal, RAID 0 se jeví jako nejsmysluplnější použití, má-li člověk nějak využít ten výkon, který to nabízí.
Pro specialni pripady bych se tomu nebranil - treba linuxovy MD umi rozdelovat pozadavky do blizsi kopie, tj. kdyz mate dva uzivatele kteri ctou jina data, tak to prakticky skonci tak, ze jednomu jdou data z jedne kopie, a druhemu z druhe kopie - a pole je tiche a rychle, protoze se neseekuje mezi nema.
Vyhoda by byla jenom v usetreni pozic, protoze mate virtualne vicero disku. Ale az osadite jakykoliv sudy pocet disku, tak ekvivalent vyrobite snadno.
Jeste je otazka zda pul-rameno nebude energeticky mene narocne - protoze ma mensi hmotnost.. takze reseni z deleneho disk bude mozna o chlup lepsi.
To by ten disk musel vypadat nějak takhle https://ctrlv.link/49bZ a to by se do normální velikosti disku asi nevešlo ;)
Mimochodem tenhle obrázek jsem „nakreslil“ před 14 lety.
"Conner produced a limited number of dual-actuator drives (internally called "Chinook") for high-throughput applications. These drives used the SCSI interface and had two independently controlled (by the embedded microprocessor) servo and read/write systems, and two complete sets of read/write heads. The drive firmware enabled it to dynamically reorder commands and assign them to a specific read/write system for optimum execution time, and perform read-write-verify and read-exclusive or-write operations twice as fast as comparable single-actuator systems. "
Moc pěkné, a na rok výroby i působivé. Zajímalo by mne, jak to v praxi fungovalo, jestli si FW byl skutečně schopen předávat úlohy mezi hlavičkami tak, aby docházelo ke znatelnému zrychlení práce HDD. A vzhledem k tehdejším cenám pevných disků, tak to tahle kráska musela stát majlant :-)
Ty brďo to je diskuze (dva LUNy, RAID0).
A já myslel že je to hlavně o zrychlení náhodného přístupu, ev. zvýšení IOPS.
Na RAID bude každý používat více samostatných disků a na ještě vyšší rychlost se použije tiering nebo čistě SSD.
Nicméně si myslím, že obecně díky složitosti se sníží životnost, tedy ne ta projektovaná, ale fyzická. Např. WD používá třikrát "zalomitelné" ramínko s hlavičkami.
A já tak děsně nerad měním disky v RAIDu.
neznám nikoho, kdo by dobrovolně chtěl šahat na RAID a něco v něm měnit. Dnes ale už daleko častěji nasazujeme SW raidy typu ceph, hdfs či podobné mesh záležitosti. Tam měni disky je naprostá lahoda, najednou člověk má pocit, že to má zase pod kontrolou, dokonce jsme už i přistoupili k výměně disků na větší na živém uložišti, to bylo v raidu a diskových polích naprosto nepředstavitelné.
dobře, asi jsem měl říct HW raid s cache a ne SW mdadm. U mdadm to je samozřejmě snadné, ale kdo ho dneska v produkcích používá? Výpadek proudu udělá dost neplechu.
Ty HW raidy jsou zase blackboxy, které fungují papírově a opravy/poruchy se řeší zaříkáváním a černou magií, je to pandořina skříňka problémů. Do toho se pak nikomu moc šahat nechce, stačí vidět, jak je obrovský problém sehnat technika k rozsypanému poli po větší havárii.
Latence klesnou na polovinu? Mozna tak prumerne v nejakem benchmarku. Latenci vetsinou vice disku nepomuze (coz tohle v jednom chassis v podstate je), pokud se tedy o IO nepere vice procesu.
Mimochodem doporucuji zkusit si nekdy ze dvou disku postavit pres mdadm RAID10 s far layoutem, a pak premyslejte jak ze to funguje, to jen tak na okraj... ;-)
Btw jedna velika vyhoda kterou maji Exos 2X18 i predesle Exos 2X14 disky je, ze prenosovka je 500MB/s pro sekvencni pristupy.
Zrejme proto, ze sada hlav ma zdvojeny / nezavisly frontend chip (ktery prepina hlavy na rameni).
Tohle mohlo byt vypichnuto rovnou ve zpravicce.. je to zajimavejsi a dulezitejsi prinos, nez nezavisly seek :)
15. 11. 2022, 10:54 editováno autorem komentáře