"Az SSD adottságai révén egy új, inline deduplikációs eljárást használnak, aminek köszönhetően jelentősen csökken a fölöslegesen, többszörösen tárolt adatmennyiség,"

Ha a "0" & "1"-esek redundanciáját is ki tudnák küszöbölni, akkor csak egy 2 bites tárolóra lenne szükség, ami a processzor cash-ében is elférne, ezáltal :
- teljesen elhagyható lenne az SSD
- akár 89 kg-al is csökkenne a szerver súlya,
- akár 100%-al csökkehetne az SSD működéséből adódó fogyasztás és hűtési költség
- további jelentős gyorsulás következne be az IOPS műveletekben
- a megtakarított összegből be lehetne fejezni az amd épp küszöbön álló, a számítástechnikát forradalmasító fejlesztéseit.

[/troll off]

Ezen aztán hasíthat a felnőtt tartalom.

...oktalan embert észérvekkel meggyőzni nem lehet...

Teljesen más szintű redundancia kiszűréséről van itt szó. Leegyszerűsítve arról, amikor van egy rahedli mindenféle képed, lekezded őket oda-vissza rendezgetni, válogatni, másolgatni és a végén másfélszer annyi helyet foglal a duplikálás miatt, mert egyik-másik képet több helyre is elmentetted. Aztán ugyanezt megjátssza a haverod is ugyanezekkel a képekkel a saját tárolóján. Aztán mind a ketten felpakoljátok a hálózatotokban lévő NAS-ra a saját csomagotokat. És akkor a NAS elkezd dedupliálni és kiszűri az egyformákat, ezzel megtakarít egy csomó helyet.

Szigorúan leegyszerűsítve írtam le a dolog lényegét. Vállalati szinten, sok-sok felhasználóval állítólag akár 5:1-hez is lehet a feltöltött és az effektíven hasznos, nem duplikált adatok aránya.

Resistance Is Futile. You will be assimilated!

Ez érdekes. Köszi.

Csak vártam, és vártam, és mikor nem jött semmi, tudtam, csak Tőled lehet...

"Aztán mind a ketten felpakoljátok a hálózatotokban lévő NAS-ra a saját csomagotokat. És akkor a NAS elkezd dedupliálni és kiszűri az egyformákat, ezzel megtakarít egy csomó helyet."

Annyi külöbséggel, hogy itt inline-ban történik minden, tehát a deduplikálás már az adatok SSD-re való mentése elött megtörténik. Más kérdés, hogy a deduplikálás nem mindig müxik, hisz ha kódolt (Encrypted) adatot küldünk a cuccra, akkor nagy valószínüség szerint semmit sem fog tudni deduplikálni.

"Most már ideje lefeküdni. De előtte elolvasom a NENYI-t, hogy merjek nagyokat álmodni." by Szözö

A Fujitsu is bevezette ezek szerint a btrfs-t?

Eladó: TP-Link 24-es switch, Xbox 360, Daewoo Matiz

Azert en ilyenkor huledezek egy sort, hogy hova jutottunk alig egy evtized alatt: kivaltsagosok draga jatekszerebol vallalatoknal is alkalmazhato alternative lett. A megbizhatosag es az adatsururuseg kimondottan meglepett, nem semmi hogy ebben is lelepte mar a hagyomanyos merevlemezt.

Azert arra meg kivancsi lennek, hogy mindezt hanyszoros aron merik (mert ennyi elonyt akkor szoktak hangsulyozni, ha utana nagy levegot kell venni a szamla lattan )

Az ekezetek miatt pedig mindenkitol bocs, de ezen a gepen nincs magyar klavi (es nem is lehet beallatani)

"No, I'm not immortal: I'm just not good at dying..."

"Az igazán meredek adat a berendezés[...] "

... ára

A dedupe megy hagyományos forgótányérossal is, ez így nemkicsit marketing-bullshit ízű.

Fotóim és kalandjaim a világ körül: https://www.facebook.com/fmartinphoto/

A közös használatú fájlszerver (ahol mindenkinél meglehet ugyanaz a doksi, tehát feleslegesen van sok példány belőle) és a backup fogalmát azért ne keverjük.

Fotóim és kalandjaim a világ körül: https://www.facebook.com/fmartinphoto/

Nem érted. Tegyük fel, hogy van pl. 10.000 User és mindegyiknek van egy 20 GB-os saját hálózati tárhelye a cégben. Ez ugye nem sok. Namármost 10.000 x 20 GB az majd 200 TB adat. Ha a dedup "csak" 1:2 arány, akkor az alapból a fele. (Fentebb írtam, hogy mi mennyibe kerül, szal nem keveset spórolt a cég ezzel a funkcióval.) Erröl mindenképpen lesz egy backup, de nem mindegy, hogy 200 vagy 100 TB-ot kell backupolni.
(Hozzá kell tenni, hogy manapság már a jobb backupszoftverek is imerik a dedupot.)

"Most már ideje lefeküdni. De előtte elolvasom a NENYI-t, hogy merjek nagyokat álmodni." by Szözö

Nyilván nem az ujjukból szopták ki a Fujitsunál, hogy a deduplikálással akár 5:1 tárhely megtakarítási arány is kihozható. Jaffafa esetében 10%-ot nyertek, de idézek innen akár 30:1 arányút is:

Deduplication domain: the wider the scope of the inspection and comparison process, the higher the likelihood of detecting duplicates. Local deduplication refers to the examination of redundancy at the local resource, while global deduplication refers to inspecting data across multiple sources to locate and eliminate duplicates. For example, a daily full backup of data changing at a rate of 1% or less that is retained for 30 backups has 99% of every backup duplicated. After 30 days, the ratio could reach 30:1. If, on the other hand, weekly backups were retained for a month, then the ratio would reach only 4:1.

Átlagos emberi halandó számára varázslatos dolgok vannak a "nagyipari" adattárolásban. Érdemes megnézni a pl. a storage poolokat vagy a slim/thick volume struktúrákat. Igyekszünk majd a QNAP blogban foglalkozni ezekkel a dolgokkal is.

Resistance Is Futile. You will be assimilated!

Mondok egy példát.
Ülésfejlesztés járműiparban. Van egy autó, mondjuk Ford Transit. Az összes változatában van 150 ülésvariáció. Ezekhez a csapatban van beszerző, sales, gyártásfolyamat tervező, prototípus koordinátor, FMEA koordinátor, programmanager, lead engineer, tervezőmérnök. Az összes ülésre többen vannak. A BOM Excelben van tárolva, képekkel minden alkatrészről, összeállításról. Ennyi üléshez van vagy tizenöt Excel file. Ezt módosítja gyakorlatilag mindenki, aki fenn fel lett sorolva. A file ugyan adatbázisban van, de ahhoz csak a mérnökök férnek hozzá. Ezért kell lokális másolat. E mellé vannak 3D pdf modellek minden ülésről, minden alkatrészről és részösszeállításról. Egy ülésben van vagy kétszáz ilyen. Plusz DFMEA és PFMEA exportok excelbe, PPAP, Control Plan, QOP, Cost break down, timing, Open Issues, stb. Na, szerinted mennyire jó ötlet mindent lokálisan tárolni, a helyett, hogy van egy elő dokumentum mindenből, mellette archív mappa, s ahhoz nyúl mindenki?

Honnan jön ide az adatbázis? Szerintem nagyon elbeszélünk egymás mellett. Angol példát fordítsam le, nem jött át?

A Fujitsu és hasonló kaliberű vállalatok az otthoni júzertől a Google szintű mega tárhely igénylőkig mindenféle formátummal és felhasználással foglalkoznak, van 1-2 fiókos házi NAS-uk és van temérdek rack alakpú gépük, amiben akár Skylake alapú Xeon is dolgozhat, nem beszélve az olyanokról, ahol a tároló rackek szekrényét külön szerver "hajtja meg".

Rengetegféle adatstruktúra és tárolási stratégia létezik náluk, amiknek a megismerése és a megfelelő implementálása külön szakma. Mondok egy kiragadott példát, de nem azért hogy elkezdj a részleteibe beleturkálni, hanem hogy hátha megvilágosodsz belőle, milről lehet itt szó:

Legyen az az igény, hogy egy 20 tagú fejlesztőcsapat dolgozik ugyanazokon a terveken (ezek lehetnek 3d modellek, prezentációk, nagyfelbontású képek, akármik, ez lényegtelen) heti szinten 1 TB adatot generálva. És szeretnénk biztonságban tudni a gépeki fejenként 8 TB-os merevlemezét, illetve szeretnénk, ha az éppen aktuális verziókból kb. 1 TB adat minden csoporttag által a legkisebb késleltetéssel elérhetőek legyenek.

Mezei ember úgy állna neki a dolognak, hogy hozzunk össze egy tárolót, amire rá lehet menteni mind a 20 emberke 8 TB-os merevlemezéből a három legutóbbi teljes állapotot, ergo kell 20 x 8 x 3 = 480 TB. Meg kell valami 1 TB gyors online elérés is - nyilvános vagy privát felhőben. Végig tiszta tárhelyben gondolkodunk, ahol az adatbiztonságot RAID6 tömb oldja meg.

Kicsit okosabban már csak inkrementális mentést csinálnak minden júzernél, amihez erősebb hardver kell a NAS-ban, de nem kell háromszoros tárhely, mert mentésenéként a júzereknél kb. 1 TB a frissülő adat. Így az állás 20 x 8 x 1,2 = 192 TB meg az 1 TB felhős tár.

Rákapcsolva erre még a deduplikációt rájövünk, hogy a 20 fejlesztő ugyanazon az adattömegen dolgozik, ha Pista gépe bekakál, akkor lényegében Jóska mentéséből is újra tudjuk húzni az adatait. Kis analízis, kis elemzés és hopp máris nem kell 20 külön ember, hanem mondjuk csak 5 mentése 4:1 deduplikációs arány. Ergo tárhelyben 5 x 8 x 1,2 = 48 TB. Meg a felhős 1 TB.

Következő szintként elkezdhetjük elemezni, hogy a júzerek a 8 TB-ból mennyit használnak valójában. Ha kijön, hogy átlagban csak 4 TB-ot, akkor akkor felezhető a tárhely és csinálhatunk egy olyan storage poolt, amiben minden júzerre 4 TB-tal számolnak, de ha valaki túlmegy rajta, akkor dinamikusan kap teret más júzer nem használt helyéből. Az ilyen rednszerek tudnak jelezni, amikor fogy a valódi tárhely és kvázi pillanatok műve rájuk kapcsolni még egy csomó adattárat. Ergo 5 x 4 x 1,2 = 24 TB-nál tartunk. Meg az 1 TB felhő.

Bár a példámhoz nem igazán illik, inkább valami gyors, sok lekéréses adatbázishoz passzolna, de a felhős 1 TB helyett betehetünk a saját tárolónkba 2 TB-os SSD-t. Bedobva ezt a gyors táhelyet a storage poolba használhatjuk gyorsítótárnak a júzerek inkrementális mentési folyamataihoz. Sőt, lehet nem is kell majd használni, mert csinálható úgy, hogy amikor Jóska inkrementális mentését csináljuk, akkor összehasonlítjuk az 1 TB-os felhős adatcsomaggal a munkáját, és ami azonos verziójú, azt nem ráncigáljuk át a hálózaton, hanem szépen a sokkal gyorsabb storage poolban másolgatun, akár időben eltolva olyankorra, amikor kisebb a tároló terhelése.

És még ezer apró finomítás, amihez nekem nem elég mélyek az ismereteim

[ Szerkesztve ]

Resistance Is Futile. You will be assimilated!

Maradjunk SATA volnalon és nemenjünk a gyorsabb, de jóval drágább SAS meghajtókhoz, és számoljunk RAID6 tömbbel. A korábbi példámban 480 TB-ról le tudtuk faragni az nettó tárkapacitást 24 TB-ra. A 24 TB-os tárkapacitáshoz RAID6 alapon elég nekünk 6 darab, fejenként 6 TB-os, vagy 5 darab, fejenként 8 TB-os merevlemez, amivel akkor is jók vagyunk, ha valami oknál fogva egyszerre kettő kihal.

Ha nem csúcs adatcenter, de nem is szittya mezei merevlemezben gondolkodsz, akkor a WD Red Pro széria környékén illik nézelődnöd, ott a 6 TB-os 90 000 forint körül fogható, a 8 TB-os jóval drágábbb, valami 140 000 forint. Summázva 6 x 90k = 540k forint merevlemezre.

Ennyi merevlemez alá elég egy kis/középvállalati NAS, valami a QNAP TS-653A-tól fölfelé, legalábbis én ott nézelődnék. A QNAP TS-563 már 10 Gbps-os Ethernetet is tud, a TVS-882 meg már Core i3-as, a 6 merevlemez mellé van két 2,5"-os SSD foglalata és M.2-es SSD-ket is lehet beletenni gyorsítótárnak, virtualizációhoz meg mindenhez elég erős, de talán már sok is. Az első két NAS olyan 250 000 forint körül van, a harmadik viszont már közel egymillió forint, itt már nálam jobban képben kell lenni, hogy a rendszermérnök ne költtessen el több mint félmilliót olyanra, amit nem használnak ki.

A végösszeg tehát valahol 800 000 forintnál indulna (kellhet legalább egy tartalék HDD esetleg) abban az esetben ha optimalizáltan 24 TB-ban gondolkodunk.

Ha maradnánk 480 TB-on RAID6 tömbben, akkor 82 darab 6 TB-os merevlemez kellene, de ugyanúgy csak kettő darab meghibásodását bírnánk el adatvesztés nélkül, ez sokkal kellemetlenebb mint az előző példában, nem beszélve a merevlemezek 7,4 millió forintos áráról. Ráadásul ennyi merevlemezhez már valami rack szekrény kellene. A 2U magas fiókok max 12 HDD-t szoktak megenni, azokból kellene a NAS mellé hat darab. NAS szinten megint a QNAP TS-1263U környékéről lehetne indulni, az 500 000 forint körül van, mellé 6 drab kiegészítő fiók (nem tudom, hogy kezel-e annyit) lenne még egyszer annyi.

A végösszeg tehát a korábbi példámhoz, brute force alapon 8 millió fölötti lenne, ami egy nagyságrenddel az átgondolt tervezési ár fölött van. És hasonló mértékben magasabb lenne az üzemeltetési költség is.

Most szólok, mielőtt a témában nálam sokkal jobban jártas kommentelők szétszednének, hogy ezek csak amolyan becslések, egy lehet itt-ott sarkított példa a nagyüzemi adattárolás érdekességeinek megmutatásához.

[ Szerkesztve ]

Resistance Is Futile. You will be assimilated!