Scrie în rețea de mare viteză cu capacitate mare de stocare

Am un NAS care rulează Samba cu un pool ZFS 20T cu un vdev raid1 cu două unități de ruginie rotative. Am 16G RAM în aparat chiar acum. Spațiul de stocare este folosit pentru o arhivă de rezervă permanentă a înregistrărilor video în continuă creștere. Este scris o dată, citit o dată pentru procesare și apoi eventual restaurare de rezervă.

Arunc în mod regulat fișiere de 40 GiB pe acest NAS. Îmi voi actualiza rețeaua gigabit la 10GbE pentru a face acest proces mai puțin dureros. Cu toate acestea, bănuiesc că voi deveni limitat de viteza de scriere a unităților de bază.

Înțeleg că un ZIL și SLOG accelerează doar scrierile sincrone, așa că adăugarea unui SSD nvme ca SLOG nu mi-ar afecta cazul de utilizare, deoarece cred că Samba folosește scrieri asincrone în mod implicit.

Nu sunt sigur dacă configurarea samba pentru scrieri sincrone și adăugarea unui SLOG pe un SSD nvme ar face ceea ce am nevoie. Înțeleg că acest lucru vine cu riscul de pierdere a datelor dacă unitatea se defectează sau se întrerupe alimentarea.Acest lucru este acceptabil deoarece rețin fișierele pe mașina sursă suficient de mult pentru a fi retransferate în cazul pierderii de date pe termen scurt. Uzura SSD-ului este o preocupare, dar unitățile obișnuite au 300 TBW sau cam acolo, ceea ce este suficient pentru a umple NAS-ul meu niciodată șters de 15 ori, sau în 75 de ani la rata actuală de generare de date, sunt de acord cu asta și să cumpărați un nou SSD dacă/când SSD-ul se sparge. Acestea sunt avertismente acceptabile. În mod normal, aș încerca doar să fac un benchmark, dar în actuala lipsă de totul, aș dori să știu din timp ce trebuie să cumpăr pentru asta.

Știu că pot adăuga mai multe vdev-uri raid 1 la pool pentru a obține un pool raid 10, dar acest lucru este prea scump, șasiul midtower nu poate suporta atât de multe unități, alimentează extrem de mult piscina împreună cu unitățile existente și ar folosi mai multă energie. timpul să țină toată rugina să se învârtească.

Care sunt opțiunile mele pentru a obține viteze de scriere care depășesc 10 Gbps în acest pool zfs pentru cel puțin 40GiB de date, în afară de adăugarea mai multă rugină la pool într-un mod raid 10?

Înțeleg că acest lucru vine cu riscul de pierdere a datelor dacă unitatea se defectează sau întreruperea curentului. Acest lucru este acceptabil deoarece rețin fișierele de pe mașină sursă suficient de lungă pentru a fi retransferată în cazul datelor pe termen scurt pierderi

Dacă puteți tolera pierderea a până la 5 secunde de scrieri, puteți pur și simplu să configurați ZFS ignora sincronizarea cererilor cu comanda zfs set sync=tanc dezactivat

Forțarea tuturor scrierilor să treacă printr-un SLOG, chiar și unul foarte rapid, este nu mai rapid decât ocolirea solicitărilor de sincronizare. SLOG nu este un cache clasic de writeback, care absoarbe scrierea pentru a le demonta la nivelul mai lent. Mai degrabă, este un mijloc de a oferi persistență cu latență scăzută prin stocarea temporară a scrierii de sincronizare (și numai ei) într-un depozit rapid intermediar. După câteva secunde, aceleași scrieri vor fi transferate din memoria principală în pool-ul principal. Un SLOG nu este citit niciodată până când nu are loc o blocare (și se recuperează).

Acestea fiind spuse, cu un singur vdev oglindă bazat pe HDD, nu veți putea niciodată să saturați o legătură de 10 Gbs. Pentru a scrie constant la viteza de ~1 GB/s, aveți nevoie macar 10 HDD în raidz2 sau 12+ HDD în oglindă+striping. Sau, și mai bine, aveți nevoie de un pool complet SSD. Asta chiar înainte de a considera lucrurile ca dimensiunea recordului, comprimare, etc.

EDIT, pentru a clarifica joburile SLOG:

Pentru a minimiza latența pentru scrierile sincronizate, ZFS a folosit așa-numitul ZFS Intent Log (ZIL). Pe scurt: de fiecare dată când sosește scrierea sincronizată, ZFS le scrie imediat într-o zonă temporară de pool numită ZIL. Acest lucru permite ca scrierile să revină imediat, permițând aplicației de apelare să continue. După câteva secunde, la confirmarea tranzacției, toate înregistrările scrise în ZIL primesc răspuns la pool-ul principal. Asta face nu înseamnă că ZIL este citit la fiecare comitere; mai degrabă, datele care urmează să fie scrise provin din memoria cache principală DRAM ARC. Cu alte cuvinte, ZIL este un fel de „jurnal de înregistrare” care asigură persistența rapidă a datelor pentru datele de sincronizare care urmează să fie scrise.

Aceasta înseamnă de fapt că scrierile sincronizate sunt duplicate: sunt scrise ambii la ZIL și la piscina principală. Introduceți SLOG (dispozitiv de jurnal separat): un dispozitiv dedicat sincronizare doar scrieri - adică: eliberează pool-ul principal de traficul ZIL. Un SLOG SSD rapid este important, deoarece HDD-urile sunt foarte lente pentru scrierile de sincronizare. SLOG-ul nu este cache-ul clasic de writeback deoarece:

• absoarbe doar scrierile sincronizate, ignorând complet scrierile normale;
• reproduce numai datele care sunt deja stocate în cache în ARC.

Cele două puncte combinate înseamnă că un SLOG mare este practic irositor, deoarece are nevoie doar de 3 ori dimensiunea maximă a unei tranzacții ZFS. Cu alte cuvinte, un SLOG de 2-4 GB este suficient pentru majoritatea cazurilor, cu un SLOG mai mare util doar în anumite setări.

Un astfel de SLOG este esențial pentru a oferi o latență mai mică pentru scrierile de sincronizare aleatoare, dar, deși poate absorbi vârfuri foarte mici de scrieri de sincronizare secvențială, aceasta nu este funcția sa principală. Cu alte cuvinte, puteți vedea ZIL/SLOG ca o porțiune persistentă de ARC. Corolarul este că nu vă puteți aștepta să scrieți zeci de GB și să ascundeți viteza lentă a pool-ului principal prin SLOG, deoarece aceasta înseamnă că aveți deja zeci de GB de date murdare. în interiorul ARC bazat pe RAM.

Setare sincronizare=dezactivat instruiți ZFS să amenințe toate scrierile, chiar și cele sincronizate, așa cum scrierile asincrone normale. Acest lucru va ocoli orice date ZIL/SLOG și dacă puteți accepta o fereastră de pierdere de date de 5 secunde, aceasta este setarea mai rapidă pe care o puteți realiza vreodată - chiar și în comparație cu SLOG foarte rapid ca Optane sau RAMdrive. Lucrul frumos despre sincronizare=dezactivat este că nu dezactivează scrierea de sincronizare pentru metadatele proprii ZFS și, prin urmare, nu vă pune sistemul de fișiere în pericol. Acest lucru nu înseamnă că îl puteți folosi cu ușurință: așa cum este menționat de mai multe ori, ar trebui să fiți sigur că înțelegeți implicațiile sale (puteți pierde ultimele secunde de date nesincronizate în caz de blocare/pierdere de putere).

Pe de altă parte, un cache clasic de writeback bazat pe SSD ca lvmcache și bcache poate folosi (mai mult sau mai puțin) eficient sute de GB de memorie cache SSD pentru a masca latența/debitul pool-ului principal - mai ales pentru că sunt cache-uri cu writeback complet care nu trebuie să aibă datele lor în memoria principală (dimpotrivă, memoria principală se înroșește singur prin aceste cache-uri SSD).

Raționamentul din spatele ZFS a fost că memoria principală (mare) a sistemului este cache-ul tău real de citire/scriere, SLOG fiind un mijloc de a avea o latență mai mică pentru scrierile de sincronizare aleatoare.