Kb. 200TB adat gazdaságos tárolása

Én nem vagyok benne biztos, hogy 200TB-nyi unlisted videó nem fog szemet szúrni valami monitoring algoritmusnak, de kíváncsi lennék, mi a kísérlet vége. :)

A beker ár, természetesen ha van drive akkor olcsóbb szalagra archiválni.

Mi a szűk keresztmetszet? A hálózat? Akkor ott kell bővíteni. 2.5G már teljesen elérhető áron van, de persze 10-re is fel lehet menni. A több kisebb NAS csak akkor segít, ha mind a forrás mind a cél különbözik, ami jelen esetben nem tűnik valósnak.

Természetesen lehet teljesen redundáns rendszert is csinálni, csak győzze valaki fizetni :) Itt nem érzek olyan szintű mission critical dologokat, hogy emiatt ne érné meg az a fél nap kiesés.

Ez ugyanígy van akkor is, ha több NAS-ra szórja szét. Mint tudjuk a RAID nem backup.

Pláne. :) Ekkora léptéknél azért kiderül mennyire gondolják komolyan.

olyan szerver amibe belemegy 12LFF lemez, plusz hasonló kapacitású külső diszk-ház?
HP G8 -ból "filléres", G9-ből is Synology töredéke.

Tippre ez a project sem fog (vagy legalábbis úgy) megvalósulni, ahogyan a topik indítóban írta OP. Illetve mivel nem fog megvalósulni, tapasztalatok se lesznek megosztva 6-12 hónap múlva, mi történt a valóságban. Így felesleges bárkinek is energiát feccölnie ebben a topikban jószándékú segítségre. Mármint a kiírónak felesleges. A többiek mondjuk lehet olvasnak közte hasznosat.

Nyilván OP azért dobta be a kérdést, mert túl szeretne lépni az USB-s HDD megoldásokon, és fontosak neki az adatai.

Hogy egy klasszikust idézzek: a kokó pénzbe kerül. A repülő pénzbe kerül. A jacht, a séróm, a gyerek fogszabályzója - pénzbe kerül. Kitty sincs ingyen.

Milyen az az ilyen? Az amatőr eszközzel is lehet scannelni "leica" kisfilmet is - meg persze nagyobbat is, síkfilmet is -, meg Flextight X5-tel is, meg közöttük is van egy halom más lehetőség is.

Az meg egy örök hitvita, hogy a filmet mekkora felbontásban kell/szabad/érdemes/kötelező/hülye aki mást mond szkennelni, szóval senki ne álljon neki raw fileméretet számolni a milliméterekből.

Na, viszont lehet hogy elkapkodtam, mert ha mozifilm... Azt manapság inkább automata filmtovábbítóval és fényképezőgéppel digitalizálják. Nem őrület nagy puki, inkább csak iszonyat szűk rétegnek kell.

Na igen, ilyen nem biztos hogy sok van.

igen, es igen, rohadt draga volt a scanner... valami palyaztabol vettek, ha jol tudom kozelebb volt a 100-hoz, millioban.

Nekem gyanús, hogy ez valamilyen köztes állapotú archiv történet lenne, ahonnan relatív ritkán szednek le cuccokat. Azt írták, hogy ha kell valami, akkor SSD-re másolják, ami akár valamilyen SSD storage-et is jelenthet. A tengelyes megoldás korlátaival együtt kell élniük, ez ilyen. Több grafikus meg render studiónál láttam, vagy hallottam hogyan üzemelnek. Háttt őőőőő.... :) Persze van kivétel, de ott meg teljesen más a lépték, és szónélkül a storage felé mentek.

Ha napi használatra kell, akkor már SSD-ben kell gondolkodni, bár valszin nem 200TB méretben, ahogy írtad is. Ezt már rábízzuk a topiknyitóra. :)

Nem is az LTO-ról írtam. Azért képzeld magad elé, hogy egy grafikai/videó/CAD stúdióban LTO-znak, és néha jön a tisztogatóember, meg az LTO kezelő. Arról nem beszélve, hogy ha esetleg gubanc van, akkor nem ott fogják a türelem szobrai következő részét felvenni.

200GiB-ot kávédarálón is el lehet tárolni :-D

azt meg kiszmaolhatnad terfogatra mennyi lenne mindez... nekem kb 800 lemez polcokon beterit egy falat, szoval gondolom jo ahhoz mar valami speci tologatos szekrenyes raktar kellhet

Nem tömörítés, hanem blokkszintű redundancia. És az még ebben az esetben is várható, ha nem is annyi, mint mondjuk szöveges fájlok esetén.

Gazdaságosnak gazdaságos, de egy 16-18TB-os diszknél mennyi idő szerinted egy rebuild? Mert egy dolog biztos, hogy 3-4 év után szinte biztosan lesz halott diszk, ha olyan szériába sikerül belenyúlni, akkor hamarabb. Mivel a rebuild egy különös megterhelés, ezért teljesen reális esélyed lesz a második diszk halálra egy 3+ éves diszkes, és minimum 2-3 napos rebuild idős tömbnél. Az esélyre akkor is készülni kell, hogy ha "óhát még sosem volt ilyen, pedig eeekkooooora tömbökkel, meg eeekkoooooa diszkekkel van állandóan rebuild". Különösen akkor lesz izgalom RAID5-nél, ha esetleg az első 4-5 évben elkerült a diszk halál, és egy mégöregebb tömbnél kell 2 napot tekernie minden diszknek vadul.  Ha esetleg lesz probléma, és csak 100TB elröppen, akkor nagy szomorúság lesz, és hirtelen a RAID6 baromi olcsónak fog tűnni. Eleve arról beszélgetünk, hogy 140k nettós diszkből kell minimum 15db egy tömbbe, plusz minimum coldspare (az egyszerűség kedvéért, tehát akár ennél jóval több is lehet mindenféle konfigtól függően), és 2,1 millió (+coldspare) nettónál "spórolsz" 140k-t miközben elég vakrepülésbe fog átcsapni.

A RAID5 azért vészes, mert túl nagyok a lemezek. Egy 16-20 TB-os lemez cseréje alatt simán megáll egy másik, és akkor vége a dalnak. Ráadásul ha nem is áll meg, de diszk csere alatt nincs redundancia, szóval mehet mindig a körömrágás, hogy ugyan lefut-e vagy sem... Ez a feszkó senkinek sem hiányzik. Nem attól lesz gazdaságos, hogy egy paritás lemezt megspórolunk, pláne nem ilyen tárolási kapacitásnál.

Már 2008-ban megszületett az első cikk arról, hogy a RAID5 halott, a nagy lemezek miatt. És akkoriban 2-3 TB-os méretet értettünk a nagy lemez alatt.

Én személy szerint 2 TB-os lemezméret felett csak RAID6-ot (RaidZ2-t) használok. Ahol van hely, ott plusz hot spare, ahol nincs erre hely, ott polcon csere diszk. 2 TB alatt meg általában csak sima tükör szokott lenni, hidegtartalékkal.

Egyébként én sem a kevés óriási diszek megoldást preferálnám. Már csak amiatt sem, hogy a kapható legnagyobb lemezek általában nem a legjobban HUF/TB mutatóban. Ellenben használd diszk dobozt meg külső portos SAS vezérlőt lehet normális áron venni aklár újonnan, akár használtan, és akkor lehet több, kisebb lemezzel számolni, és valamivel rövidebb helyreállási időkkel diszk hiba esetén. Az, hogy ez mennyit fogyaszt, egy dolog. Vagy online elérhetőség lesz, vagy alacsony üzemelési költség.

Az is egy lehetőség, amit más is említett már, hogy több színtű tárolás: minden legyen kint szalagon, és egy jóval kisebb kapacitású NAS-ra töltse be egy erre készített rendszer (ami akár lehet egy Python progi plusz adatbázis...) a kért anyagokat. Sőt, ez esetben akár olyan gyors NAS is építhető, amiről akár dolgozhatnak is, ne kelljen külön SSD-re kimásolni még a szalagról visszatöltött anyagot.

Ekkor 200TiB nettóval számoljunk, ami 20TiB mérető böszmeállat lemezekkel 10 darab plusz a redundancia, erre minimum kettő paritás és legalább egy hotspare, azaz 13 darab diszk a dobozba - minimum, de kétszer 5+2+1 (raid6+hot spare) tömb sem ördögtől való - ehhez elég két darab 8 diszkes tárolótömb, ami tud raid6+hot spare felállást meg iSCSI-t, és a két iSCSI LUN-t egy szerevren összefogni LVM-mel vagy két külön ~100TiB méretű tárhelyként.

Az is jó lehet, bár ilyen felosztásban szokott előjönni az, hogy "itt elfogyott a hely, ott még van, akkor átmenetileg azt is oda..." - és örökre ott marad.

A ransomware-ek ellen én valami webes felületet csinálnék, ahol a jogosult user "kivehetné" a tárolóból a számára szükséges fájlt, ezt a háttérben az alkalmazás kimásolná egy akár SaMBa-n megosztott területre, _és_ bejelölné, hogy "feldolgozás alatt", aztán amikor a dolgozó végzett, ugyanígy jelezné, hogy visszarakható a fájl, és az alkalmazás visszamozgatná az rw területről a kliensek által direktben nem elérhető területre, az előző verziót még x ideig (esetleg) megtartva, illetve az így visszakerült megváltozott fájl a napi mentésbe is beleforogna.

Meg a munkafázisok során x óra alatt keletkező köztes fázisokat is "célszerű" elrakni, legalább addig, amíg az adott köztes állapotra bármilyen okból vissza kell lépni a feldolgozásban/utómunkában.

hat digit vilagban vagy ssd/hdd van a kameraban vagy hozza van csatolva egy kulso ssd/hdd rogzitohoz, szoval az nem hiszem hogy opcio

regen sd felbontasnal meg a dv kazettas arhivalas jo moka volt, bar az sem olcso hdd-hez viszonyitva.

és ha igen?

Van olyan, hogy nem mindenkinek van igénye arra a szintű megoldásra, arra a szintű support-ra. Meg ennél gyakrabban van olyan, hogy igény ugyan lenne rá, de nem tudja megfizetni, mert még nem annyira tőkeerős a cég, hogy megtehesse. Akkor nekik pályát kell váltani, mert ha nem tudnak profi cuccot megvenni, akkor mit keresnek azon a piacon?

Én azt gondolom, hogy ha van egy igény és azt egy szolgáltató ki tudja elégíteni, akkor a mondat végére pont került akkor is, ha az igény és/vagy a szolgáltatás nem az adott területen elérhető legprofibb.

Amennyiben növekszik az igény, akkor vagy felnő hozzá a szolgáltató, vagy másikat keres a helyére a megrendelő. Aki az általad favorizált filmes rendszereket gyártja, egészen biztosan nem ezen a szinten kezdte. Aki az Ő rendszereiket veszi, biztosan nem úgy indultak, hogy no akkor holnap indítjuk az új filmes vállalkozást és hívjuk az adott terület legprofibb informatikai szolgáltatóját, mert kevesebbel nem érjük be.

• Én elképzelhetőnek tartom, hogy lehet olcsóbb az "új" rendszer, pláne akkor, ha a drágább (mindent is tudó, kiforrott, sok megrendelő minden igényét kielégítő) rendszer nem minden szolgáltatására van szükség és azokat el lehet hagyni. De akár minden szolgáltatással sem kizárt, hogy olcsóbban is meg lehet csinálni azonos minőségben.
• A piacra betörés nem úgy van, hogy eldöntöm és betörök. Csinálok egy terméket/szolgáltatást és vagy népszerű lesz, vagy nem. Ha jól sikerül, az adott szakmai körön belül híre megy, és az új megrendelések hozzám jönnek, esetleg lesz, aki vált az addigi megoldásáról is.
• Nem feltétlen kell jobb és megbízhatóbb, ha az elérhető megoldások már jók és megbízhatók. Vagy ugyan azt adom olcsóbban és/vagy adok még valami pluszt amit a meglévőek nem tudnak de a megrendelőnek igénye van rá.
• A támogatás meg a fejlesztők száma szerintem előre nem definiálható. Az adott projekt elvárásait kell teljesíteni, nem többet nem kevesebbet. Mi van azokkal a rendszerekkel, amiket 8-17 között használnak? Arra nem kell 0-24-es támogatás. Mi van a redundanciával? Ha jól van tervezve, akkor nem kell rohanni hiba esetén. Ha meglévő "építőelemekből" rakok össze egy rendszert, akkor nem kell egy csomó klasszikus fejlesztőmérnökkel rendelkeznem, nem kötelező mindenre egyedi hardvert és szoftvert fejleszteni, ha a szolgáltatás előállítható meglévő építőelemek kombinálásával is.

2005 magaságában egy ügyfelünknél IBM Tivoli Storage Manager szoftver futtató rendszert vettek adatmentési célokra (eredeti IBM szereverrel, szalagos egységgel, mindennel ami kell hozzá). De nem kértek beüzemelést, az ajánlatot is úgy kérték, hogy saját IT tudja telepíteni, üzemeltetni. Mi más területen dolgozunk nekik, és jött az ötlet, hogy majd mi beszállunk a beüzemelésbe a helyi IT mellé. Küzdöttünk is vele vagy 3 hónapot sikertelenül. Support volt, doksi volt, segítettek is folyamatosan, a licenc ki volt fizetve, nem volt semmi kerülőút vagy spórolás (nem követelte meg a gyártó, hogy csak partner üzemelheti be). De csak nem kelt életre. Na jó, hát nem vagyunk elég okosak, sem mi sem a helyi IT-s csapat. Mikor már nagyon el voltunk keseredve mi is és az ügyfél is, akkor megkeresték a szállító céget, hogy mégis kérnék a rendszer üzembe helyezését, mert nem megy annak ellenére, hogy direkt user által üzemeltethetőt kértek. Ők további 3 hónapot dolgoztak rajta - sikertelenül. Egy bitet nem mentett le a rendszer 6 hónap intallálás során. Mindezt egy olyan "összetett" rendszeren, ami egy szem szerverből, benne a szalagos egységből és a rá telepített szoftverből állt... Sajnos nem derült ki, hogy pontosan mi hiányzott a sikerhez, mert az ügyfél megunta, és lefújta a projektet.
De a mentést meg kellett oldani, találjunk ki valamit. Erre én vettem két Intel barebone szervert, tettem rájuk FreeBSD-t, arra Bacula adatmentő rendszert. Egyik volt a fő backup, a második az "offsite" egy másik telephelyen. 10 évig üzemelt ez a megoldás, és a rá költött pénz kevesebb volt, mint a Tivoli licenc ára hardverek nélkül.

Namost ez nem az én hozzáértésemről szól, hanem arról, hogy a nagy gyártók kiforrott szuper rendszerei is support-ja sem csodaszer. Azt is emberek készítették és emberek támogatják. Így ennél az esetnél is létezhet, hogy a megrendelő számára olyan rendszert ad át a szállító, amit megelégedéssel használ annak ellenére, hogy nem a filmes iparban bevett, nagy nevű 2-3 cég szálíltotta.

Végül is, mi a francnak állt neki a Microsoft SQL szervert fejleszteni, mikor ott volt az Oracle DB. Minek kezdte el Linus Torvalds a Linux fejlesztését, mikor ott volt az SCO UNIX is meg az MS DOS is és akkoriban már a Windows is kereskedelmi termék volt. Minek álltak neki az LTO-nak, mikor már majd 10 éve elérhető volt a DLT és a Super DLT, hasonló kapacitással, minek jött a React, mikor az Angular mindent is tud? És még sorolhatnám. Ez az "inkább perkálok, és nem találom fel újra a kereket" szerintem nagyon nem releváns az informatikában...

Halál komolyan belinkeltél egy állami intézmény által konkrét megvalósításra (valószínű konkrét kivitelezővel) kiírt tendert amiben tételesen fel vannak sorolva a szállítandó eszközök? Jó, hogy nem gyári számmal tűntették fel, mit kell vinni.

Ezt egy olyan topikba, reagálásnak, ahol annyi az információ, hogy egy szolgáltató/üzemeltető megkeresést kapott valakitől 200 TB videó anyag tárolásának megoldására.

Meg maga a kiírás is érdekes... Bővítés kell, de 300 TB NVMe tárolóval... Mit bővítünk? És minek ekkora kapacitás a leggyorsabb NVMe tárolóból? Egy archiváló rendszerbe? Mennyire releváns ez bárki másnak? Egyáltalán, ez hogyan támasztja alá, hogy nagy,  filmes iparban jártas cég szállítson csak ilyesmit, mert egyébként ráfarag a megrendelő?

Azért itt nem erről lenne szó, meg előzőleg sem ez volt a probléma. A topiknyitó valszin egy büdzsé-büdzsé megoldást rakna össze, és lehet, hogy ettől is erősen felszisszen a kedves megrendelő, mert óhát aszitte ez már olcsó manapság. Ezzel szemben a rommá szupportált SDS, FC meg SAS meg SSD meg NVMe "buzzword"-okkel leszórt hipermegoldás pláne overkill lenne valszin. Bármennyire kompromisszumos, ez fedi le valszin az igényeket, és persze a korlátokra fel kell hívni a végfelhasználó figyelmét. Csak az olcsón jót gyorsan örökzöldet lehet felhozni. A termékfejlesztés nem tudom hol jött be a képbe, mert itt gyakorlatilag kivitelezés volt.

Az AWS, vagy más felhős cucc eleve nem játszik valszin. Nemcsak a tárolás milyensége lesz problémás, hanem a használt sávszél ára.

Itt ilyenről szó sincs. Én nem gondolom, hogy az AWS-nél, vagy akár a nagy magyar filmstúdióknak beszállító szakosodott cégnél okosabbnak kell lenni.

Én annyit állítok, hogy az nem igaz, hogy csak akkor lesz megoldás a problémára, ha ilyen céget kér fel a megrendelő, és minden egyéb esetben bukás vár rá.

A LaCie videó szerkesztést támogató 50 ezer dolláros tároló megoldásainál azért barátibb összegből is meg lehet oldani 200 TB videó anyag biztonságos tárolását, ha az ember hajlandó vele dolgozni egy kicsit. És nem fiókba pakolt több 10 db HDD-re gondolok, mint olcsóbb megoldás.

Mi bizonyos partnereinknek nyújtunk "felhős" e-mail szerver szerver megoldást. Proxfix-Dovecot-Roundcube. Szolgáltatásban levelezni tud, slussz. Messze-messze elmarad a legkisebb O365 csomag tudásától. De amikor az ügyfélnek ennyire van szüksége, akkor ezt adjuk, és eltesszük azt a havi 1000 Ft-ot fiókonként, ellenben az O365 legolcsóbb szolgáltatásán eltehető 100 Ft-tal, amiből az ügyfél pont ugyan ennyit használna...

Szerintem mindenkinek van helye a piacon úgy megrendelőként mint szolgáltatóként. Nem tud mindenki bármelyik szolgáltatótól vásárolni és nem tud minden szolgáltató bármilyen ügyfél igényt kielégíteni.

Konkretan a fiokban tartjak :)

Igen, ez a megoldas mar kenyelmetlen, pont azert, mert mar macera a sok disk csereberelese. De sokkal-sokkal jobb tanacsot nem tudtam adni. (Figyelembe veve az adatmennyiseget, a cserebere gyakorisagat es egyeb helyi sajatossagokat, mielott meg valaki a szivehez kapna, hogy NAS! Felho! Ket NAS! Ket felho! Szalag + tiering! meg ami meg elhangzott.)

Látom nem ment át a mondandóm lényege.

Ha a szalag azért alternatíva, mert havonta egyszer kell előásni, akkor 29 napra a HDD is elmehet standby-ba.

Ha nem ez a use case, mert a rendszernek folyamatosan kell dolgoznia, akkor viszont a szalag nem lehet alternatíva.

Igen, felvilágosítod, és az esetek többségében látod, hogy már lezárt az agya, neki mindegy, csak működjön valahogy. A kockázatot kb úgy kezeli, hogy a "f....m fog erre milliókat költeni", jólesz valami egyszerű. Ez sajnos a napi valóság. Amíg működik valahogy az adott bármilyen megoldás, addig nem is érdekli, és sok esetben abból sem tanul, ha néhány napra megáll a cége, miután egy Win10 frissítés telibeverte a szuperfontos cuccot.

Hiába mondod teljesen ájtimaszlag nélkül a dolgokat, hogy ha ő igazából azt sem érti, hogy miért kéne neki ezzel foglalkoznia, hiába mondod, hogy ember basszus, ha megáll a céged, akkor nagyon morcos leszel, esetleg megy a levesbe. Hiszen eddig még mindíg volt valahogy, valaki valahogy megoldotta, meg segített. Előttem írták, hogy X5-re, meg X6-ra meg hasonlókra elmegy a zseton, vagy simán félmila havonta autóra és még efölött ki tudja mennyi benzinre, de már egy normális backup megoldásra nem fussa. Nagyon tele van a zoknim ezekkel, meg tudom kiégett vagyok... na mind1. Ja és persze ha probléma van, akkor nagyon vad emaileket tudnak írni, meg érdekes hangnemben telefonálni.

Ohh, hát én egy cloud storage összehasonlító oldalon adtam meg az adatokat, és ott jött ki a 900 USD.

Az tény, hogy nem volt részletezve, hogy AWS Glacier Deep Archive vagy Flexible vagy Instant Retrieval. A "gyári" kalkulátor alapján az Glacier Instant Retrieval a jóval drágább 900 USD/hó.

A Depp Archive 1 USD/TB/hónap eléggé jó ár hosszú távú (archív, nem backup) tárolásra. Ellenben backup-ra nem biztos, hogy ez a jó, mert ha ehhez kell nyúlni, akkor az azt jelenti, hoghy elveszett helyben minden. Onnantól nem biztos, hogy jó lenne még 12-48 órát vármi a letöltés megkezdésére (ami 200 TB-nál szintén nem lesz meg egyhamar).

Átteszed EU-ba mindjárt nem ilyen szépek a számok.