Dotaz: SW RAID na platformě X399/1950X (odhady, zjištění, tipy)

[PetebLazar]

Pro budoucí umístění většího objemu dat (záznam z kamery buď v podobě velkých souborů .mov(ProRes), či jednotlivých souborů .dng(RAW) zvažuji možnosti stavby souborového serveru na bázi platformy X399/1(2)95(2)0X. Server by poskytoval soubory stanici určené pro editaci (SW DaVinci Resolve), případně byl schopen lokálního renderingu projektu (při využití 2x lic. Studio + PostgreSQL jako storage projektu).

Data rate zaznamenaného materiálu je v rozmezí desítek až stovek MB/s(až 600MB/s .. podle rozlišení a kvality). Cílem je z rezervou přes sít (10Gbps cross) poskytnout data do rychlosti 1GB/s. U raw záznamu může jít až o 120 souborů/sec, ale vzhledem pravděpodobnějšímu využití HighRate záznamu pro SlowMotion to bude max. 60 souborů/sekundu.

Na mé Asrock Taichi X399 se dostupný SATA řadič jeví jako device připojené dle lspci rychlostí 4x 3.0.

01:00.1 SATA controller: Advanced Micro Devices, Inc. [AMD] X399 Series Chipset SATA Controller (rev 02) (prog-if 01 [AHCI 1.0])
        Subsystem: ASMedia Technology Inc. Device 1062
...
                LnkSta: Speed 8GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
...
        Kernel driver in use: ahci
        Kernel modules: ahci

Zkusil jsem ověrit průchodnost výše uvedeného SATA subsystému tím co jsem měl k dispozici tj. 2x SATA SSD, 2x HDD (asi 5900 ot/min a 7200 ot/min). Paralelním spuštěním hdparm -t jsem předpokládám testem z rychlého okraje HDD a SSD vyzkoušel aspoň řádově IO průchodnost (na sekvenční čtení). Jak ukazuje screenshot na odkazu, dle iostatu v bylo dosaženo v určité sekundě (test je krátký) souhrné rychlosti cca 1,2GB/s. Přičemž dílčí rychlosti prakticky odpovídají samostatně spuštěným hdparm (jsou maximem použitých HDD/SSD). Vytížení CPU, pokud to čtu správně dosahuje cca 15% z jádra na 500MB/s přenosu. http://www.monitos.cz/tmp/parallel_access_SATA_device.png

Zda má smysl pole případně realizovát nad HDD či SSD může částečně vyplynout z debaty, ve prospěch HDD hovoří definovatelný výkon(úbytek se vzdáleností od okraje), lepší poměr kapacita/cena, vyšší dostupná kapacita při menším počtu členům, nutný větší počet členů na dosažení požadované rychlosti. V neprospěch SSD kromě poměru kapacita/cena, také těžce odhadnutelný trvalý výkon a jeho proměna v závislosti na zaplnění/opotřebení a u levných kapacitních SSD asi i otázka životnosti.

Zkoušel jsem realizaci mdadm (RAID6 se čtyřmi členy) nad blokovými /dev/ramX a popravdě mne vyděsil relativně malý výkon při zápisu ~700MB/s (a to šlo o operace nad RAM!). V dávné minulosti se při bootu kernelu zobrazovaly dosažitelné rychlosti pro výpočet RAIDx pro různé typy SMD instrukcí a již tehdy snad šlo o jednotky GB/s?

Pokud je řešení na bázi ZFS/Btrfs dnes výkonostně jinde než mdadm, určitě je na návrh zahrnu do testů (od diskového prostoru/filesystému nejsou vyžadovány žádné pokročilé funkce). Případná ztráta dat způsobí maximálně zklamání(poučení) a nikoli ekonomické ztráty (jde o edu/hobby projekt). Kromě funkčnosti je druhotným cílem dosažení zajímavého poměru cena/výkon(kapacita) řešení.

Je vůbec zmíněný cíl SW realizovatelný s využitím integrovaných device, nebo bude z důvodu režie/funkčnosti/výkonu vhodnější zvolit dedikovaný PCIe SAS/SATA RAID adaptér?

Odpovědi

[dustin]

Co udělá md raid6 při resynchronizaci disku, když bude pole pod stálou zápisovou zátěží? Trochu bych se bál, jak dlouho to bude trvat.

Po zkušenostech s mdadm a ZFS bych pro takový účel volije už l ZFS, ZIL SLOG na kvalitnější SSD (Intel SC36xx je celkem dostupný).

[PetebLazar]

K zapisu na pole by docházelo prakticky jen při plnění nově pořízeným materiálem. Tím by měla být také vcelku omezena fragmentace. Při případném výmazu pořízeného materiálu (např. jedné akce) vznikne volný fragment v řádu spíše stovek GB.

Výkonově kritickou službou bude čtení. Případný rendering bude nasměrován na vyhrazený NVMe (výstupní datarate v x0Mbps místo x00MB/s bude skoro 100x menší). SSD by určitě přinesly výhodu při souběhu zátěže (editing, rendering), s intenzivním čtenim ze vzdálených částí pole by asi lépe poradily (u raw záznamu tvořeného jednotlivými soubory to může narazit na tps již asi i při single zátěži).

U SSD nevím jak je to s TRIM pod mdadm/ZFS, aby nedošlo k degradaci výkonu.

[Ovocníček]

U těch SSD je asi dost nevýhoda, že prakticky všechno dneska zapisuje v režimu SLC cache a pak data sekundárně znova zapisuje do TLC. Takže pokud tam není bypass u velkých souborů/při zaplnění SLC, tak to bude haprovat - docela dost těch disků to zdá se vůbec neřeší a jso ukontinuálně schopné zapisovat do plné SLC a současně při tom z ní číst starší data a zapisoovat je jako TLC, aby se udělalo místo na nové zápisy - pro výkon asi katastrofa a pro životnost to taky nebude nejlepší.

Takže pokud SSD, tak to musí být nějaké, které při plné SLC cache přejde automaticky na nativní zápis v TLC, nebo které nepoužívá SLC ccache (snad Samsungy 970 Pro, ale jistě to nevím).

Kromě toho taky výkon zápisu v parametrech bývá uvedený pro tu SLC cache a po zaplnění je o dost nižší, u těch QLC to tuším může bý i pod 100 MB/s...

[PetebLazar]

Toto téma jsem dříve otevřel zde. http://www.abclinuxu.cz/poradna/hardware/show/444247

U velkokapacitních SSD (2TB) snad díky vyššímu paralelismu řadičů (proti těm malým) je snad šance, že se rychlost zápisu udrží nad výkonem HDD i po naplněni SLC-cache (a to i u shi.u jménem TLC a QLC). Ale měl bych u nich strach z životnosti, výrobci zmiňovaných 200 přepisů u QLC na důvěře fakt nepřidá. Výhoda rychlosti čtení (sekvenčního/náhodného) by jim snad měla zůstat.

[dustin]

Kolik těch dat bude?

[PetebLazar]

Akce se odhadem vejde do 1TB. Kapacita pole s ohledem na budget, tak jednotky TB(SSD řešení) až desítky TB(HDD řešení).

[dustin]

A hromadně se přistupuje k poslední akci, nebo podobnou měrou i ke stejným akcím předchozím?

Ptám se proto, že repasovaný server DL580 G7 se 40 jádry a 1TB DDR3 10600R od důvěryhodné firmy vyjde s dopravou na 67 tis. Kč bez DPH. Před pár týdny jsme od nich kupovali to samé s 512GB DDR3 12800R za 30 tis. komplet bez DPH, šlape perfektně. Před >dvěma lety jsme kupovali ten samý, dnes má uptime 700 dnů. Tak jsem myslel, zda by nebylo levnější/jednodušší/výkonnější dát HDD na pole + SSD na ZFS ZIL/LARC keše + hodně RAM na buffery pro read přístupy.

[PetebLazar]

Přistupovat se bude většinou k jedné (typicky poslední akci).

Repas mne popravdě ani nenapadl.

[dustin]

Tak pokud máš na to dost vaty, tak repas nepotřebuješ

[PetebLazar]

Čím dál nad tím přemýšlím, tak to vidím spíš na více, ale za to kvalitnějších NVMe SSD (typu Samsung 970 Pro 1TB).

Možná i s umístěním pracovní storage (NVMe single/RAID0/1/10 dle možností) přímo na editační stanici (pro zajištění místní rychlé odezvy), přičemž renderovací server si pro data sáhne po síti podle potřeby. Při paralelní zátěži v řádech x00MB/s by asi HDD stejně neměly šanci. Ony se nejspíš nebudou nudit ani ty NVMe SSD. Redundance pořízeného záznamu bude zajištěna ponecháním na záznamovém médiu do další akce. Archivace pak kompresí do výrazně ztrátovějšího/úspornějšího kodeku (ve vyjímečném případě exportem v bezeztrátovějším).

Na vyšší levely RAIDu je asi třeba zapomenout, dopad na výkonnost (při zápisu) by asi byl značný.

[dustin]

Tak pokud potřeby dovolují použít local storage, nemá smysl to zpomalovat/komplikovat/prodražovat daty na serveru, to je jasné.

[PetebLazar]

Větší kapacita i s ohledem na hlučnost by se snáze řešila pomocí HDD na detašovaném serveru, kde by nebyl problém s případnou hlučností. Rendering na serveru by vzhledem k značnému vytížení CPU/GPU a s tím související hlučnosti by měl smysl asi i nyní.

Umí implementace RAID1 v mdadm při čtení využít dat z libovolného členu, navýšit tak rychlost čtení?

[Nie som robot]

Citujem:

The trick is to create the RAID1 array and set the HDD(s) during creation as "write-mostly". This will cause the kernel to only do (slow) reads from the HDD if they are really needed. All other reads will go to the SSD. This option was originally added when mirroring over a slow network interface, but performs equally well to concentrate reads on an SSD.

[Nie som robot]

Ukážka 2 x 8TB Seagate (write-mostly) mdadm RAID1 + 256GB NVME v RAID1 (256GB NVME + 2 x 256GB particia na HDD):

cat /proc/mdstat:

md1 : active raid1 sdb3[2](W) sda3[1](W) nvme0n1p2[0]
      243578880 blocks super 1.2 [3/3] [UUU]
      bitmap: 2/2 pages [8KB], 65536KB chunk

hdparm -Tt /dev/md1

/dev/md1:
 Timing cached reads:   14792 MB in  2.00 seconds = 7409.85 MB/sec
 Timing buffered disk reads: 6158 MB in  3.00 seconds = 2052.24 MB/sec

[PetebLazar]

Díky. Jednoduché a zajímavé řešení. Takže zápis na takové hybridní pole je zhruba dán výkonem HDD, čtení rychlostí SSD.

Jak jsou na tom jsou vůbec spotřební SSD z pohledu "TLER,ERC,..". Když dojde k selhání např. čtení, vzdají to, nebo se to snaží zachránit dopočítáváním z EEC (minimálně do stanoveného timeoutu)?

[PetebLazar]

Konečně mi došlo proč někdy nejsem schopen o určitém SSD s jistotou říci jakou technologii xLC vlastně používá. Zatímco o SLC se již dočteme asi jen v historických záznamech, u MLC se zděšením sledujeme jejich vypařování se z nabídky a potají se hrozíme, že dnešní opovrhování nad TLC se "zítra" pod dojmem z QLC může proměnít ve vzpomínky na šťastné doby minulé.

Terminologie říká: SLC (SingleLevelCell představuje záznam jeden 1bit/cell), MLC obecně MultiLevelCell (více úrovní v buňce), TLC(3-bit/cell), QLC (4-bit/cell). Bohužel si asi většina z nás MLC logicky zobecnila s 2-bit/cell, což jak ukazuje je sice pravdou, ale ne nutně pravidlem. Například Samsung své levnější řady EVO 970 označuje za 3D V-NAND 3-bit MLC, což prodejce někdy pro zjednodušení předělá na NAND MLC.

https://www.alza.cz/samsung-970-evo-1tb-d5319058.htm?o=2

https://www.samsung.com/semiconductor/global.semi.static/Samsung_NVMe_SSD_970_EVO_Data_Sheet_Rev.1.0.pdf

Takže zatím to vypadá na pracovní storage (NVMe Samsung 970 Pro 1TB MLC 2-bit!). Půjde pouze o pracovní úložiště, takže jeho případný výpadek(chybovost) maximálně způsobí nedostupnost prostředí (případně snížení produktivity jeho náhradou za pomalejší storage). Návrh velkokapacitního prostoru (ZFS-based) nechám uzrát dle dostupných financí.

Díky všem za cenné informace a nápady.

[PetebLazar]

Tak to vypadá, že zátěž s .dng (jednotlivé snímky záznamu jsou v samostatných souborech) jako zátěž padá. BlackMagic Design právě oznámil odstranění tohoto typu záznamu z další verze firmware kamery a jeho nahrazení vlastním Blackmagic-Raw (záznam je v jednom souboru). Důvodem prý má být patentní ochrana .DNG formátu či v něm použitých technologií (nezmínili kdo uplatňuje nárok). Ten pokud si vzpomínám vyvinul Adobe se záměrem(snaze) nahrazení rozličných RAW záznamů jednotným "digitálním negativem".

[PetebLazar]

Při nejvyšší kvalitě Blackmagic-RAW(Q0 konstant quality) to v novém firmware vypadá pro 4k60 na limitní datarate někde okolo 400MB/s. To by (na vnějších stopách) asi dal i RAID0 dvou svižných 7200 3,5" HDD. Na zacatku HDDků vytvorit pracovni RAID0 partition a ze zbytku skladovaci RAID1.

SDK pro B-RAW by snad mělo být volně dostupné, tak třeba někdo vytvoří reencoding mezi různou kvalitou B-Raw. Po zpracovaní projektu z materiálu v max. kvalitě, pro archivaci materiál reencodovat do nizsi kvality(objemu) B-Raw.

[lertimir]

Ještě můžeš uvažovat o zapojení bcache. Kdy SSD ti chytí přímý datový tok a následně ho pošlou do HDD.

[PetebLazar]

Jak dlouho to v té bcache vydrží (do zapsání, nebo do nahrazení jiným obsahem)? Jde mi o to, zda v případě nasazení bcache před pomalejší cílovou HDD storage při kopírování x00GB materíálu z ext. SSD (rychlost ~550MB/s) by se z obsahu bcache profitovalo i při okamžitém čtení (zda by i u již uložených dat/souborů na cílové HDD requesty rychle ještě odpovídala bcache)?

[lertimir]

Cache nemá důvod data mazat, pokud nepřijdou nová. Pokud si pamatuji tak bcache je cache na blokovém zařízení, tedy pod filesystemem a myslím že někde v dokumentaci psali doporučení, že z vrstev má býti nejníže, přímo na hardware i pod raidem.

[lertimir]

Na RAID 5/6 je fakt třeba zapomenout. To beru jako technologii roku 1995-2000. Uvědom si, jak se vlastně se vyvíjí disproporce mezi rychlostmi a kapacitou. V roce 99 měla PATA rychlost 33-66MB/s, v roce 2000 PATA rychlost 100MB/s a v roce 2003 SATA 1 rychlost 150MB/s nicméně kapacity tehdy byly na úrovni jednotek až desítek GB viz. Takže za 20 let vzrostla kapacita HDD cca 1000 krát nicméně rychlost u HDD jen max 10 krát a u NVMe je to více proporcionálnější, ale také rychlost na 3GB/s je jen 100 násobná proti tomu roku 98 a jen 20 násobná proti SATA 1. přičemž kapacity jsou i u NVMe mnohem větši. Pak má cenu u RAIDu preferovat jen to, co efektivně nesnižuje rychlosti, což jsi napsal RAID0 pro temporární pracovní data. RAID1/10 pro standardní data.

[Max]

RAID1/10 neřeší slušnou resistenci proti výpadku více disků. Prostě možnost výpadku 1+n nebývá dostatečná. Resp. u menšího počtu disků ok (4-8), ale u většího počtu už ne. Osobně jedu v jobu ZFS, pool skládám pomocí RAID-Z2 po 8 diskách.
Pokud dotyčný bude řešit jednotky TiB, tak RAD1/10 z 1TB ssd disků bude ok. Pokud bude řešit desítky TiB, tak tam už ta cena SSD začne nepěkně narůstat a bude asi upřednostněno nasadit rotačáky. A pak je otázkou, zda se pojede v SAS, nebo SATA. Já jedu v práci SATA ZFS storage. Aktuálně modifikuji (spojuji pooly a přikupuji disky). Konečný stav bude : 4x8 hdd WD RE4/Gold 4TB v RAID-Z2. Tzn. 80 TiB storage.

Při navrhování storage je potřeba počítat s následujícími věcmi :

• zatížení pole pravidelným scrubem
• zatížení pole v případě výměny disku a tím pádem resyncem
• zatížení jednotlivých disků pravidelnými SMART kontrolami
• možnost rozšiřitelnosti kapacity do budoucna
• nároky FS jako takového, třeba ZFS má best practicles nezaplňovat pool na více jak 80% kapacity, NetApp má myslím 90%
• nezapomenout započítat režie případných snapshotů
• pokud budeme chtít online kompresy, je třeba i vhodný CPU
• nezapomenou na nároky na ram pro konkrétní typy FS
• zahrnout povolené hodnoty pro konkrétní disky, kdy např. kapacita může být ok, ale denní přepisy mohou přesahovat deklarované hodnoty výrobcem a tím pádem pak může být problém s životností a případnou reklamací

Osobně bych u malého pole (v řádu TiB) použil 1TiB SSD, nad tím ZFS alá RAID10.
V případě velkého pole bych pak použil klasické rotačáky, opět ZFS a SSD disky pro SLOG a případně cache (podle toho, jaká budou data na storage a práce s nimi).
Zdar Max
PS: už se mi stalo třeba i na NetAppu, že mi vypadly dva SSD disky s odstupem asi jedné hodiny. Na NetAppu používám RAID-DP (=RAID6/RAID-Z2)

[Max]

Jinak dodám, že se jedná o single case storage server. Na toto mám Supermicro a ti mají zajímavé řešení skříní pro různé nasazení. Já jsem nechal koupit case pro 36xSATA 3,5"
Zdar Max

[PetebLazar]

Jaký je odhadem trvalý sekvenční výkon R/W u ZFS nad osmicí takových HDD s uvedenou redundancí?

[PetebLazar]

Souhlas. Pro skladování vetších objemů dat, ale asi ješte dlouho nic lepšího než HDD mít nebudeme. Požadovanou spolehlivost možná zajistí i levné HDD kde s prostou duplikací souborů (100% redundance), cenově to vyjde skoro na stejno jako složitější řešení (na bázi dražších enterprise HDD v RAID apod).

[PetebLazar]

Jak se díváte na možnost nasazení ctyř HDD 3,5"/7200 (SATA 4 nebo 6TB), z nichž jejich první (rychlejší) polovina bude použita pro svazek RAID0 tj. kapacita 8/12TB (pro ukládání uncompresed výstupu NLE až cca 4-6Gbit/s) k ex-post encodingu. A druhá (pomalejší) polovina HDD ke konstrukci RAID6/RAIDZ2 tj. kapacita 4/6TB jako odkladiště pořízeného materiálu. Oba svazky nebudou využ́ívány současně, pořízený materiál je v době NLE umístěn na NVMe.

Jaké HDD byste pro zmíněné trvalé sekvenční zápisy/čtení doporučili? Zatím mi papírovými vlastnostmi vychází Seagate Exos 7E8, ale klidně se nechám přemluvit na levnější variantu.

Snažil jsem se navrhnout cenově přijatelnou SSD variantu, ale bezúspěšně.