250TB kép tárolása - hogyan?

Szerverek

Sziasztok,

Ismerősi körben felmerült egy elég brutálnak tűnő igény. Szinte kizárólag képeket szeretnének tárolni (500kB - 1MB közötti mérettel) első nekifutásra minimum 50TB-ot ami évente növekszik mégegyszer ennyivel. Legalább 5 évre terveznek vele és nem szeretnének hozzányúlni ha egyszer kész ezért kapásból kéne 250-300TB storage.

Sebességnél inkább az olvasási sebesség a kritikus! Na erre kéne valami NAS vagy storage szerver + persze belevaló diszk/SSD. Költségek felső plafonját illetően nem tudok mit mondani, egyelőre csak az igény merült fel. Ha lenne több megoldási javaslat is (entry/casual/advanced) az lenne a legjobb.

Egy különálló szerveren futna egy HyperV amin virtuálizálva fut a képek elérésére használt szoftver. A storage és a szerver ami futtatja a VM-et ugyanabban a szerverteremben foglalnának helyet. Miként lenne célszerű összekötni őket (iSCSI, external SAS, stb)?

Hogyan, mivel oldanátok ezt meg?

( gyuri23 | 2020. 06. 25., cs – 11:24 )

A kritikus sebesség számszakilag mennyi? Mentés is lesz (ugyebár a RIAD nem mentés)? Kell HA? Lehet Ceph? 

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

Mondjuk minimum 200MB/s lenne az elvárt de inkább több. Mentés is lenne majd (Veeam adott, ha azzal megtudnánk oldani az már bőven jó). Ceph-et nem szeretnék - bevallom férfiasan, hogy nem értek hozzá hősködni pedig nem szeretnék.

Első körben az lenne a lényeg, hogy megtaláljuk a megfelelő eszközt amivel ezt meglehet oldani minél egyszerűbben viszont ha a jövőben lenne mondjuk HA (jelenleg nem szempont) akkor ne nagyon kelljen széttúrni az egészet.

250T-t nem biztos, hogy Veeam vagy hasonlóval akarsz menteni. Megkockáztatom, hogy ennyi adatnál eleve két példányt kéne az appnak mentenie két helyre, és ehhez képest kellene az egyikről néha valahogy menteni.

Ha Veeam, amit egyébként szeretek, akkor több storage-ben gondolkodnék, RAID6+0 vagy 5+0 alapon és lenne egy költséghatékony óriáshely, ahova ment a Veeam, de valszin oda kötelező a 10G és minimum iSCSI a storage és hoszt közé. Nagyon ki kell ezt találni, mert igen nehéz tippelgetni, hogy milyen lesz.

Simán. Az agent megy szépen standalone módon és free, igaz szeretik a regisztrációt, de ennyi. Ha van valahol állandóan menő Windows, akkor a Community Edition megy 10 backup jobig (automatizált) és egészen komoly feature-ok bennevannak. Az Agent tud integrálódni a Backup & Replication-höz, szóval egészen magával ragadó.

A kolléga 5 évre számol. Az a B2-nél csak a tárolásra:

1250$/month 5 évre 75.000$ ami kb. 24.000.000 HUF

Ha ennél drágább vasat akarsz akkor olcsó, egyébként meg nem. Persze ehhez jön még áram, üzemeltetés, a felhőnél letöltés, stb. de a nagyságrend ez.

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

Értem, viszont a felhőnél nagy előny lenne, hogy nem kell egyszerre előre kifizetni ezt a költséget és befektetni saját hardverbe.

Plusz ha nem 250TB-ről indulnak, hanem csak fokozatosan skálázódik fel az adat mennyisége addig, akkor kihasználatlanul állna a pénz a drága vasakban.

Az üzemeltetés költségei nagyrészt áthárulnak a cloud providerre, ha elavul a hardverük az 5 év alatt az szintén az ő problémájuk, jobb helyeken redundáns az adattárolás magas rendelkezésre állással, stb.

Persze ha olyan jellegű a felhasználás, hogy naponta többször fel-le mozgatnak 250 TB adatot, akkor nem érné meg a felhő.

"Everything fails, all the time."

( freeoli v | 2020. 06. 25., cs – 11:30 )

Ahogyan én csináltam hasonlót régebben oda egy redundáns unified storage kerül ami képes volt NFS-en elérhetővé így párhuzamosan lehetett írni és olvasni N szerveren.

Ha tényleg csak a tárolás a lényeg akkor egy Dell ME4 storage rendszernél nincs olcsóbb ekkora méretben, ami viszont csak block storage így mindenképpen kell egy NFS / CIFS head a block eszközre akár VM formában is.

A célodnak a tökéltes megoldása majd a FreeNAS SCALE lesz ami gluster-re épül és szerintem akár szerverenként lesz képes NFS vagy HTTPS head-et futtatni konténerben, de ez feltételezés az eddigi információk alapján.

( _ventura_ v | 2020. 06. 25., cs – 11:32 )

Hogyan, mivel oldanátok ezt meg?

Jöhet a közhely, hogy sokféleképpen.

Legegyszerűbb, fogsz egy https://www.supermicro.com/en/products/system/4U/6048/SSG-6048R-E1CR90L.cfm gépet, és beletolsz egy halom disket 90db fér bele 12T vel az már nem rossz. Persze ez 1 gép de sok tudást nem igényel, rátolsz oprendszert a tárterületet meg kiadod ahogy akarod :D

Meg vannak a bonyolultabbak, mikor a sok disk sok külső dobozban foglal helyet. Aztán, hogy lesz belőle sok tárhely az már függ a technológiától, tudástól, pénztől stb.

Fedora 38, Thinkpad x280

Hát softwares. Sok dolga nem lett volna iSCSI storage, de az se sikerült vagy 6 éve.

Volt olyan hogy a letiltott frissítés ellenére frissített és rebootolt :D Volt olyan, hogy NFS storage nak használtuk, de ugy beállt mint az uszeg. Power off/on segített viszont erre meg összeszarta magát az fs. Volt iSCSI szakadt le stb.

Mint mondtam ez évekkel ezelőtt volt. Így maradt kb játszós storage a mai napig. Így nincsen vele gond. Igaz kb semmit se csinál. 

Visszont összehasonlítva a meglévő gyári SANokkal inkább kihagyom.

Fedora 38, Thinkpad x280

Simán lehet. Mondjuk úgy vagyok vele, hogy ami mindenre jó az kb semmire se :D 

Lassan 10éve megy D-link SAN 7/24 be bekonfoltuk annó sose volt vele gond. Nekem ennyi kellett volna, de valahogy nem sikerült neki :

 

Most belépve is ilyet látok:

[Thu Jun 25 08:42:02 2020] e1000e: eth0 NIC Link is Down
[Thu Jun 25 08:42:04 2020] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[Thu Jun 25 08:42:06 2020] init: iscsi_pluginserverd main process (29476) killed by TERM signal
[Thu Jun 25 08:42:06 2020] init: iscsi_pluginengined main process (29471) killed by TERM signal
[Thu Jun 25 08:42:07 2020] init: iscsi_pluginserverd main process (29793) killed by TERM signal
[Thu Jun 25 08:42:07 2020] init: iscsi_pluginengined main process (29782) killed by TERM signal

[Thu Jun 25 09:36:48 2020] e1000e: eth0 NIC Link is Down
[Thu Jun 25 09:36:50 2020] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[Thu Jun 25 09:36:52 2020] init: iscsi_pluginserverd main process (2721) killed by TERM signal
[Thu Jun 25 09:36:52 2020] init: iscsi_pluginengined main process (2718) killed by TERM signal
[Thu Jun 25 09:36:52 2020] init: iscsi_pluginserverd main process (3066) killed by TERM signal
[Thu Jun 25 09:36:52 2020] init: iscsi_pluginengined main process (3033) killed by TERM signal

 

Mondom ezt úgy hogy 2 test hypervisor meg pár test VPS fut róla :>
 

Fedora 38, Thinkpad x280

Ha nem elég az egyszeres redundancia akkor lehet triplán tükrözni a diszkeket a RAID10-ben. Na meg nem biztos hogy muszáj az egészet egy tömbbe összefogni, ez már alkalmazás függő.

Másrészt opció több RAID6 tömb is, ha az átmeneti lassulás tolerálható. Mivel nincs pontosan specifikálva a feladat, egy rakat szkenáriót el lehet képzelni.

Ilyen meretnel mar semmifele raid nem jatszik.

Minden szervered minden diszkje onallo entitas, semmifele raid sehol, es egy kozponti storage program biztositja hogy az adataid redundansan meglegyenek tobb helyen.

Ugyanez a program vegez szabad hely es smart monitorozast, diszkhiba eseten ujabb masolat letrehozasat, API-n keresztul adat letarolast illetve meglevo adataid elereset szinten az API-n keresztul.

Kb. 6 evvel ezelotti munkahelyemen 2 petaig skalaztunk egy ilyen infrastrukturat Supermicro vasakkal, sima HDD-kkel, szepen mukodott, mivel statikus tartalmat adtunk igy CDN mogott volt az egesz, a kimeno savszelesseg kb. 1Gbit/s korul volt csucsidoben adatkozpontonkent, a CDN-nel meg 12Gbit/s.

A storage program termeszetesen hazon beluli fejlesztes volt.

Az adat betarolasa API alapu volt, a redundancia merteket te hataroztad meg a storage programban (itt volt lehetoseg geolokacio figyelembe vetelere is, volt DC-nk USA-ban, Japanban illetve az UK-ben), az adathozzaferes pedig nginx-en keresztul volt megvalositva, az url-eket a storage program API-ja biztositotta.

Volt meg elkepzeles tobbszintu storage bevezetesre (mint pl. a facebooknal) hogy legyenek kulon hdd es ssd szerverek, de vegul ez nem lett megvalositva mert egyszerubb volt hogy ha uj, nagy nezettseget varo anyag kerult fel akkor egyszeruen pre-heateltuk a CDN cache-t scriptekkel meg mielott az appokban elerheto lett volna a film.

( kubi | 2020. 06. 25., cs – 16:41 )

Nem biztos, hogy egy szervert epitenek. Az se, hogy egyaltalan epitenek ilyet. Ez mar nem az otthoni NAS kategoria.

Sporolni kell, vagy az adatok ideiglenes hianya majd jol foldhozvagja a ceget?

Maintenance, support? Ki vegzi, es mennyiert?

Vannak profi megoldasok, mint a fent emlitett Dell EMC, vagy a NextentaStor.

( NagyZ v | 2020. 06. 25., cs – 16:47 )

ha nem nyul hozza, IBM Cloud Object Store - Cold Vault, azt hiszem 1$/TB/honap.

( gee v | 2020. 06. 25., cs – 17:20 )

Google Photos szintkronizációval :-)

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

( Elbandi v | 2020. 06. 25., cs – 17:42 )

ha nekem adnak ez a feladatot akkor en viszont pont megneznem a cephet (nem a cephfs, bar lehet azt is):

  • a kepek tarolnam mint ceph object. arra van szamtalan kiszolgalo cucc.
  • a skalazodas is jol megoldott: lehet kezdeni 50T-vel, aztan ahogy no a cucc lehet ala tenni a tarhelyet, a rebalancet megoldja a ceph
  • disk halal eseten a helyreallas is jol megoldott

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Cephfs-t én kerülném, főleg ha sok metaadat lekérdezés lesz (pl. könyvtárlistázás) mert inged-gatyád kifizeted a metaadat szerverre.

Egyébként én elgondolkoznék a kérdező helyében azon, hogy vajon mennyire kellenek aktívan az adatok és nem opció-e esetleg az Amazon Glacier használata.

( zeller | 2020. 06. 25., cs – 19:44 )

" Legalább 5 évre terveznek vele és nem szeretnének hozzányúlni ha egyszer kész ezért kapásból kéne 250-300TB storage. "  - Én nem venném meg most egyből a teljes tárkapacitást, legfeljebb 2-3 évnyit, és utána új, garival/supporttal ellátott eszközökkel bővítenék. Mert most megvesz valamit, amit kvázi öt évig nem használ, és öt év után garancia/support/technológiai avulás miatt kidob... Nos, erősen szuboptimális felhasználása az anyagi erőforrásoknak, hogy finoman fogalmazzak...

( quash | 2020. 06. 25., cs – 20:41 )

Most lehet hogy kinevettek, de egy egyszerű matek:

  • 250/10 = 25

  • 24 db 10Tb-os HDD-ből durván ZFS-el kijön ~220 Tb terület!
    (azért 24, mert 24 fiókos házat/szervert lehet azért kapni)

  • ZFS Tb/1Gb RAM-ot figyelemeb véve → 256Gb RAM

  • 2x NVMe SSD SSD pl. 1Tb L2ARC-nak, csodát nem tesz, de jó ha van.
    Az éppen aktuálisan olvasott képek nagy része bent lehet cache-ben

  • lz4 compress – Mivel nem írta hogy a képek hogyan vannak tömörítve. De ~10-15%-ot tuti hoz még rajta ZFS, 250Tb/10% = 25Tb, tehát máris ennyivel több a hely. (persze ez sem igaz, mert ZFS-t nem töltjük tele)

  • Ez elfér egy „normál” 4U v. 2U házban, könnyen karbantartható, valamilyen felügyelet kell rá ha diszk megáll, akkor cserélje.

  • 10G-n simán összeköti a két gépet, és ennyi.

Ha pl. nem új, hanem 3-4 éves használt szerverben gondolkodsz, akkor ez már nem az annyira árban durva kategória.
Nem gond ha nem tud nvme SSD-t, pcie kártya és csók.
Ráadásul használtra is kaphatsz akár NBD garanciát, és megveheted akár 24hó részletre is (nem írok cégnevet, többség tudja kire gondolok).

Ezt indokold meg kérlek!, miért nem?

Az hogy 20-24 HDD van egy gépben, ebben semmi extra nincsen!, Az hogy ezek a HDD-k nem 1-2-3 TB-sek, hanem 10Tb-sek, már ebben sincsen semmi extra.
ZFS, és a hasonló fájlrendszerek erre vannak felkészítve, megfelelően választott hardverrel nincsen ezzel gond! Sem stabilitás, sem performancia.

40-50-60Tb-s ZFS alapú "storage"-okat már rendszeresen építünk, ha van elég RAM/CPU megfelelően van kiválasztva lemezvezérlő, kő 1xű az egész. Backup pedig ZFS miatt pikk-pakk megvan.

A kérdést feltevő nem írta hogy magas rendelkezésre állású, full redunsáns rendszert szeretne. Egyetlen gépet szeretne rákötni! Ha ebből indulunk ki, akkor lehet lényegesen komolyabb megoldásokban gondolkodni. De ha a kiszolgáló oldal nem redundáns, és nem erre méretezett, akkor valószínűleg "storage" oldalra sem keresnek komolyabb megoldást.

Ha redunciát akar
- akkor vagy vesz erre cél eszközt, nagyon drágán
- vagy épít valamilyen több gépes storage-ot, pl. ceph-el

Kérlek indokolod már meg! De úgy hogy a topic nyitó igényeit nézed!

Hol látsz igényt a kiszolgáló oldalon ennél "komolyabb" rendszerre? (1 db hyperv szerver ...)

Félreértések elkerülése miatt, nem azt mondom hogy ennél nincsen jobb, megbízhatóbb megoldás!
Megfelelő storage-al simán lehet ekkora kapacítás, de pl. egy IBM FlashSystem 5030 ~40Tb-vel júniusban nagyon csúnyán akciósan ~14000$ (itthoni ár!)
200-250Tb-vel ennek az ára (és másnak is) csillagászati.
És mentésed még ettől, erről sincsen, tehát arra még költhetsz.

Egy szerveres megoldás mellé, kizárt dolog hogy 10 milláért fognak storage-ot venni, és még 5-6ért backupot+ softwaret, etc ...
 

Oké, tudunk ennél kicsit konkrétabb problémákról is beszélni amik a „napi használat során” jelentkeznek?

Elég sok ZFS alapú fájlszervert, backup-ot, HV hostot raktunk már össze, jellemzően ha jól választod meg a hardvert (nem kevés a RAM, jó a controller, elég a CPU) akkor nincsen velük gond. Meglepően jól bírják az áramszünet, és a hasonló problémákat is.
Kellő mennyiségű RAM, és normális írási/olvasási sebességgel rendelkező lemezek esetén teljesen jó írási és olvasási értékek jönnek ki. Hozzáadott L2Arc az olvasáson nagyon jól tud segíteni.
Nagyobb méretnél is! Bár azt aláírom hogy 60TB-nél nagyobbat még nem építettünk, de ebben a nagyságrendben sem volt gondunk.

Kérlek most te is írd meg te mi alapján mondod azt hogy „napi használat során problémák jelentkeznek”, „csak papíron működik”.

Ne értsd félre, nem kötözködöm! De ha állítasz valamit, akkor indokoljuk már meg azt az állítást, ne csak dobálózzunk a „miért nem jó” állításokkal.

Nem én állítottam valamit, hanem te állítottad, hogy az általad javasolt megoldás megfelel a kérdező számára. Én meg azt kérdeztem erre, hogy hol a redundancia? Merthogy ezt nem nézegetni, hanem élesben használni szeretnék. Én viszont nem gondolnám, hogy az általad javasolt rendszerkiépítés önmagában alkalmas produktív környezetbe. Te valószínűleg bármikor elüzemeltetsz egy ilyen megoldast, én viszont biztosan nem.

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Vagy nem olvasol figyelmesen, vagy szándékosan kikerülöd a kérdésekre a választ!
Hol írta a kérdező azt hogy redundanciára van szüksége? Ezt a kérdést tette fel: „Na erre kéne valami NAS vagy storage szerver”. Egyetlen HyperV szervert szeretne erről üzemeltetni!

Javasolnám ha már véleményt formálsz valamiről, és visszakérdeznek akkor legyél szíves indokolni! Ne az legyen a válasz hogy te ilyet nem csinálnál.
Nem ismerjük egymás szakmai kompetenciát, tapasztalatai, gyakorlatát, de ez lekezelő stílus számomra értelmezhetetlen. Itt nem a lenne a lényeg hogy megmutasd hogy te mennyivel jobb vagy, hanem ha tényleg így van, akkor magyarázd el mivel mi a probléma!
De úgy hogy nem egy általad elképzelt rendszerre próbálod ráilleszteni, hanem a topic eredeti kérdését veszed figyelembe. Sehol nem volt arról szó hogy enterprise megoldást keres!

Ismét leírom, a kérdező NAS szintű rendszert keresett, és nem írta hogy redundaciát szeretne!
Erre miért is nem felel megy ZFS alapú szerverből épített „storage”, akár produktív környezetben?
Arról hogy ez adott esetben hogyan lesz mentve, mennyire hibatűrő nem volt szó.

Srácok!

Tök másról beszélünk!
Sehol nem írtam hogy ez atombiztos, sehol nem írtam hogy ez a tuti, elve így kezdtem: "Most lehet hogy kinevettek, de egy egyszerű matek:". Erre kaptam az a kérdést hogy "hol a redundancia?"
A kérdező egy NAS szerű megoldást keres(et)!, erre írtam egy teljesen használható megoldást!
Szó sem volt redundancia, és hasonlóakról. Rendben van hogy ez így normális üzemeltetésben nem állja meg a helyét, de az sem korrekt hogy ezért a másikat fikázzuk!

Részemről lezártam ezt az értelmetlen vitát, mert elbeszélünk egymás mellett.

Én nem tartom alkalmasnak azt a rendszert semmire, amin az adat vagy megvan, vagy nincs. Elméleti rendszerben lehet gondolkodni, de itt egy gyakorlati megvalósítást, munkára alkalmas megoldást keres a kérdező. Lehet, hogy ezt így nem írja le, nem mindenki tudja, hogy mire van szüksége, de a feladat leírásából arra lehet következtetni, hogy az adat jövőre is kelleni fog neki, ez viszont nem valósul meg azzal, amit leírtál. 

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Figy!

Mi lenne ha csak egyszer érdemben válaszolnál?
Továbbra is nagyon nagy általánosságokban beszélsz!

Üzemeltettél már ZFS-t? Volt már vele problémád? Volt már belőle adatvesztésed?
Ha jó fej lennél, akkor inkább azt írnád le hogy milyen problémába ütköztél adott esetben, ami alapján kijelented hogy nem stabil.
Mert a kijelentéseid azt feltételezik hogy szerinted ZFS nem stabil!

Én saját gyakorlati tapasztalatok alapján ajánlottam (nem elméletileg), és nem 2-3 felhasználós irodai fájlszerverekből indulok ki. Az hogy 50TB-ről vagy 250TB-ről beszélünk az csak hardver kérdése!
Igen, Az adatbiztonság pedig megint egy másik, nem kikerülhető kérdés. Erre is leírtam hogy egy mezei ZFS send/rececive-el egy másik u.i. gépre lehet pl. 15 percenként sync-elni. És máris van mentése, amit ráadásul ha snapshot-ol, akkor nem csak hardver hiba, hanem „véletlen” törlés, etc … esetén is van visszalépési lehetőség!

Azzal nincsen gondom ha megmondják, figy ez hülyeség! De ha akkor LÉCI érdemben indokolj, ne csak általánosíts!

Kösz!

Nem tetszik a hangnem? Szegény cica, de hiszen pontosan te írtál így az előbb. Ha ez nem tetszik, akkor talán először is magadban keresgélj. Egyébként pedig egy egyszerű kérdést tettem fel, de arra sem vagy hajlandó válaszolni, csak háborogsz. :)

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Figy kispajtás!

Nekem kint van publikusan nevem, elérhetőségem az adatlapomon! Legyél kedves te is ezeket kitölteni.
Ilyen stílusban/hangnemben ne beszélj velem név és arc nélkül! Nem vagy sem az óvodai játszópajtásod, sem a szomszédod!
Ha ilyen formában állást foglalsz, akkor vállald fel magad!

Figy mucika, nekem aztán édesmindegy ez a kivagyi önérzet, de hidd el, nem attól lesz releváns az info, hogy ha pl. Hekk Elek okleveles pc-kovács mondja, hanem hogy tudja a választ a "hol a redundancia?" kérdésre!  :)))

https://youtu.be/WXp1QXY81ZA

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Én ezt próbálom az arctalan úriemberből 3-4 napja kiszedni, de azon kívül hogy személyeskedik, szakmailag, érdemben még nem sikerült hozzászólnia a dologhoz.

Én sehol nem írtam hogy ez az űber tuti megoldás! Csak egy lowcost javaslat volt, és ez lett belőle. De érdemi indok nincsen, leírja a „redundacia” szót, és itt elakadt a lemez.

Mivel valószínűleg soha nem jössz ki a lakásból, ezért számodra ilyen fogalmak hogy tisztesség, becsület, értelmezhetetlenek.
Ha állítasz valamit, és a másikra ilyen jelzőket használsz, mint: „Hekk Elek okleveles pc-kovács”, akkor lehetne benned annyi tisztesség hogy ezt névvel, arccal teszed!
Nagyon szívesen felhívnálak, de akár személyesen is találkoznék veled, hogy ezeket megvitassuk, de mivel te egy arc nélküli ember vagy, ezt nem tudom megtenni.

Ha felvállalod a neved, akkor tudunk érdemben, szakmailag beszélgetni, ha továbbra is „zitev” maradsz, akkor részemről a „beszélgetést” befejeztük.

 

Mivel valószínűleg soha nem jössz ki a lakásból

Én akkor jegyeztem meg a nevét, amikor valamelyik topicban leírta, hogy ő hogyan szokott vezetni a táblák és KRESZ szabályok figyelmen kívül hagyásával arra alapozva, hogy itt így szokás. Ugyanezt adta ott is elő, izzadós erőlködést, hogy neki van igaza, aztán személyeskedést, amikor a korábbi előadás nem hatotta meg a többieket.

Ebből két dolog derül ki: 1) ki szokott mozdulni a lakásból, 2) felesleges megpróbálni megértetni vele, hogy valami máshogy van, mint ahogy elképzeli.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Azt gondolsz amit akarsz, engem ugyan nem zavar. :) egyelőre viszont te állítottál valamit, én csak egy egyszerű kérdést tettem fel, úgyhogy nem nekem kell  bizonygatnom a magam igazat, hanem neked, hogy nem beszélsz zöldségeket. Tehát akkor: "hol a redundancia?" :)))

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Miert nem ugy kerdezed, hogy elore vigye a tarsalgast?

Pl.:

"Bar nem szerepel a kiirasban, de tegyuk fel, hogy megfelelo redundancia resze a minimum elegseges megoldasnak. Azt hogy biztositanad?"

Ehhez mit szolsz?

 

Na persze a masik is magatol beirhatna, ha akarna.

Lehet cizellálni, de attól még nem lesz tartalmasabb. A kérdés így önmagában egyszerű és érthető. Nincs benne semmi sértő, nincs benne semmi olyan, amin fenn kellene akadni. Ennek ellenére sikerült... :)

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Ha neked az a trollkodás, ha a magában nagyon magabiztos, az említett feladat volumenéhez képest filléres "tutti" megoldással előrukkoló kommentelő felé egy egyszerű és indokolt kérdést felteszek, amire a  választ még mindig nem volt képes megválaszolni, akkor igen! :) (mondjuk először én is azt hittem róla, de aztán a ráfeszülésből kiderült, hogy ezt ő komolyan is gondolja.)

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Egyáltalán nem volt az, miután egy feladatra adott egy pistike pécé bété-szintű megoldást, anélkül hogy végiggondolta volna egy ilyen feladatnál, a valós üzemeltetés során felmerülő lehetséges buktatókat azzal a megoldással, amit ő személyesen javasolt és jónak tartott - és amikor egy egyszerű kérdést feltettem (amire a választ eddig a pillanatig nem sikerült megválaszolnia), csak duzzogni tud. :)

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

"Én nem tartom alkalmasnak azt a rendszert semmire, amin az adat vagy megvan, vagy nincs. Elméleti rendszerben lehet gondolkodni, de itt egy gyakorlati megvalósítást, munkára alkalmas megoldást keres a kérdező. Lehet, hogy ezt így nem írja le, nem mindenki tudja, hogy mire van szüksége, de a feladat leírásából arra lehet következtetni, hogy az adat jövőre is kelleni fog neki, ez viszont nem valósul meg azzal, amit leírtál. "

Tehát továbbra is az a kérdés: "hol a redundancia?" :)

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Feltettem egy kérdést:
„Kérlel fogalmazd meg hogy milyen szintű redundanciát várnál el a topic nyitó által felvázolt 1 node-os rendszer esetén!”

Szerinted erre ez válasz?:
"Én nem tartom alkalmasnak azt a rendszert semmire, amin az adat vagy megvan, vagy nincs. Elméleti rendszerben lehet gondolkodni, de itt egy gyakorlati megvalósítást, munkára alkalmas megoldást keres a kérdező. Lehet, hogy ezt így nem írja le, nem mindenki tudja, hogy mire van szüksége, de a feladat leírásából arra lehet következtetni, hogy az adat jövőre is kelleni fog neki, ez viszont nem valósul meg azzal, amit leírtál. "

Specifikálni sem tudod azt amin „pörögsz”.
Szakmailag és emberileg értelmezhetetlen vagy.

Én megpróbáltam veled normálisan kommunikálni, de nem lehet.

Nem veszed észre hogy ez amit csinálsz nem vezet sehova?! Mások is leírták hogy semmi értelme annak amit csinálsz.
A feltett kérdésekre nem válaszolsz, nem vállalod fel magad!

Te egy igaz barom vagy!

" egy mezei ZFS send/rececive-el egy másik u.i. gépre lehet pl. 15 percenként sync-elni. És máris van mentése, amit ráadásul ha snapshot-ol, akkor nem csak hardver hiba, hanem „véletlen” törlés, etc … esetén is van visszalépési lehetőség " - Mentése nincs, csak 15 perccel korábbi állapotról egy másolat. A snapshot más kérdés - mondjuk jó kérdés, hogy "betárolás" oldalról mennyi az időegység alatt betárolni kívánt adatmennyiség maximuma (nagyon nem mindegy, hogy az évi 50TiB 365*7*24 óra alatt egyenletesen kerül feltöltésre, vagy munkanapokon 8 óra alatt? Szintén nem mindegy, és számolni kell vele, hogy az elvárt 200MB/s (0.5-1MB-os fájlokról van szó) olvasási sebesség miatt érintett fájlok (2-400 fájl/s) elérési időpontját (atime) kell-e frissíteni/tárolni, mert ha igen, akkor annak az adminisztrálása is elég bőséggel fog változást generálni, amit szinkronizálni kell, és ami az érdemi feltöltött adatok szinkrinizálásától veszi el az időt.

Nagyon sok kérdés van a feladattal kapcsolatban,a mire választ kell kapni, hogy technológiailag az optimálishoz közelítő megoldát lehessen adni - aztán persze jöhet a költség oldali nyiszatolás, mert büdzsére is kell optimalizálni, az meg jellemzően az igények újragondolásával jár, ami magával hozhatja a korábbanjavasolt technológiák/megoldások totális elvetését is...

 

 

Én ott követtem el a "hibát", hogy olyan szintű megoldást írtam, amilyen szinten a topic nyitó (aki eltűnt! :D) megoldást keresett.
Egyetlen HV-hoz keresett "storage"-t. Ebből nekem úgy tűnt hogy ez egy low cost project, erre továbbra is azt mondom, elegendő egy ZFS alapú "storage". De nem állítom azt hogy ennél nincsen jobb megoldás!

Az adatbiztonsági kérdéseket megvitattuk, vannak! :) De ha továbbra is feltételezzük hogy low cost project, akkor bármilyen más megoldásnál is lesznek.

Abban tökéletesen igazad van hogy send/receivnek is van "költsége", főleg gyakran változót, kis méretű fájloknál. Ennek itt is lehet a buktatója.
Ha pl. storage-ban gondolkoznánk, arról is kell mentés, tehát adott esetben ott is lehet adatvesztés, X órára.

Ezért írtam ZFS-t! :) Stabil, foglalkozni nem kell vele, enni nem kér, és az ilyen játszos projektekhez tökéletes lett volna.
Csak itt mindig sikerül mindent félreértelmezni, és egyből koklerezni ... ahelyett hogy figyelmesen olvasnánk.

Amúgy itt a "projekthez" a tökéletes eszköz! :D
https://www.interbolt.eu/spd/008970/EMC-Isilon-X200-NAS-Server-2x-Intel…
354TB (nem, nem írtam el!)
359 900 Ft+ÁFA
Egy kis RAM, és kész! :D

now+5Y időtartamra levetett, már most EOL+x korban járó eszközt ajánlani... nem is tudom... :-) Ráadásul maximum 1+1 év garanciával, azaz bő másfél év múlva lehet venni valamit helyette. Ennyi üzleti adatot nulla támogatottságú hardverre bízni három(+) évig erősen a "nem vak az a ló, hanem bátor" sztorira hajaz... Még akkor is, ha duplán tárolnak mindent - mert a redundanciának egy eszközcserét kiváltó hiba esetén a csereeszköz kiválasztása/beszerzése/üzembe állítása idejére lőttek, és ez mint olyan, bőven nem lesz NBD.

levetett régi hw sem elvetendő ötlet persze, de ésszel. Egyrészt nem egyből az öt év múlva tervezett tárkapacitást kell megvenni (ez új vas esetén is egyértelmű), másrészt az eszközöket maximális garanciával kell beszerezni, és a garanciaidő lejáratához tervezni egy cserét - a ténylegesen szükséges bővítés mellé/bővítéssel együtt.

Az Isilon X200 2016.03.31 óta nem rendelhető, 2021.03.31.-én megszűnik a technikai támogatása EOSL. Érdekes a hírdetés, ha valaki ebből Isilon-t akar összerakni akkor minimum 3 darab kell, plusz kettő Infiniband switch. Az sem árt ha megvannak hozzá a szoftver licenszek. Amúgy nekem ott zavaros a hírdetés, hogy írnak benne 0GB HDD-t, meg 354TB-ot is, meg 59x 6TB-ot is. Egy X200-ban 12x 3,5" slot van. Meg még van pár buktató.

Amúgy x86 szervernek lehet egyet is használni SuperMicro a belseje.

Ott volt a smile a végén! :)
De megint rossz irányból nézitek! Valószínűleg elírták az árat, tegnap este még 360e+áfa-árt volt fent, ha kiszámolod nettó 6e ft ebben az esetben egy darab 6TB-s lemez!
Ez még használtban, 1 év garanciával is nagyon durva lett volna.

Mára már javították az árat!

Oké, tehát ZFS egy kokler hack!
Továbbra is ott tartunk hogy ti mindenféle alap nélkül koklereztek!
Mondtam én rád bármilyen negatívumot?

Nagyon pofátlan dolog a másikat lejáratni, úgy hogy érdemben nem szólsz hozzá a témához!
Leírtam vagy 5x hogy a kérdező mit kérdezett, ezt érdekes módon folyamatosan kikerülőd te is és Zitev haverod is.

Tisztában vagyok vele hogy enterprise közeghez vagy szokva! De ettől függetlenül amit leírtam az a kérdező igényeit maradéktalanul lefedi! Főleg úgy hogy a topic indító az eltűnt a fenébe, és csak nagyon nagy vonalakban specifikálta az igényeit.
Sehol nem állítottam azt amire ti kihegyezitek ezt a cicaharcot.
De rendben, álljunk bele! Vegyen a kérdező 20x ennyiért a feladatra alkalmas storage-t, és kösse rá az egyetlen HyperV host-ját.
Ez 100%-ban adatvesztés biztos ???? IBM-nél dolgozol, tudod hogyan tudnak storage-ok adott esetben elhalni! Ott is megy minden a levesbe.
Mindegyik megoldás feltételez egy backup megoldást, de erről sehol semmi szó nem esett, nem ez volt a kérdés!

Ha ismételten hozzászólsz, kérlek mellőzd a sértegetést, és olvass FIGYELMESEN!!! Ne azt mazsolázd ki az egészből ami neked tetszik!
Érdekes módon külföldi fórumokon lehet értelmesen beszélgetni ...

Kösz!

nem, a ZFS egy jo technologia, a kokler hack az, hogy ennyi adatot (amennyiben barmennyire is fontos) csak igy rabizol egy gepre.

- mi van a elromlik a HBA? alaplap? proci? ram? -> le kell allitani. persze, erre is mondhatod hogy dehat nem irtak h nem lehet111~!!!!1111

- sw update, kernel update -> ugyanaz

a syncel az a bajom hogy barmikor eltorhet; tegyuk fel nem megy a cron, mert akarmi eltorte, akkor mi lesz?

 

nekem is volt olyan fazisom kezdo storageskent amikor ilyet raktam volna ossze, es tedd szivedre a kezed: talalkoztal mar olyan projekttel ahol _utolag_ ne jottek volna be pont ezek a requirementek? "de jo lenne ha nem allna fel orat", "de jo lenne ha gyorsabb lenne", "uristen, elromlott a hw, nincs a polcom, most mi lesz?!?!?!?! HIVD A JOZSIT HATHA VAN NEKI!!!".
mert en lattam mar sok iylet. jobb megelozi a sirast, venni egy rendes storaget, aztan had szoljon.

 

fent mar irtak a Ceph-et, szerintem az egy sokkal jobb megoldas. a hatranya hogy a 250TB eleg pici neki, de mondjuk egy 6 gepes cluster 24*14TB-al mar nem rossz, lehet hwt cserelni, karbantartan, etc, es nem all meg semmi, es a bit rot sem problema.

Köszönöm!
Ilyen válaszra gondoltam! :)

Amit írtál egyetértek! csak kiszolgálás oldalon is egyetlen HV-ra bízná a kérdező a feladatot, ebből nekem annyi jött le, hogy nem szolgáltatás kritikus a feladat.
send/receivet alapvetően statusz alapján azért lehet ellenőrizni egy nagiossal pl. ha nem volt sync v. hibás a sync akkor mehet a warning.

De ha 0/24/7-re kell akkor valószínűleg tényleg storage talán a legolcsóbb megoldás. + backup :)

Neked Ceph-ben sokkal több a tapasztalatod, nálunk még csak 2 fut, de én úgy látom oda viszont erősen kell az üzemeltetői tapasztalat, ahhoz hogy performancia is legyen.

mondom, altalaban a requirementek utana derulnek ki, legkesobb az elso leallasnal... nalunk is volt nagy asztalcsapkodas mikor tavaly 1 orara elment az aram, hogy miert nincs generator ("hazi gepterem" a sajat campusunkon, nem coloc DC), es miert nincs UPS ami at tud hidalni 1 orat... 6+ racknyi GPU szerverrel, ami rackenkent huz 30kW-ot, persze. adtam projekttervet, meg leirtam mennyibe kerulne, aztan hirtelen nem volt fontos :)))

a ceph jo dolog, ha valaki az RH verziot hasznalja, ott szerintem sok minden be van tuningolva, de en meg nem teszteltem a 4.1-es RHCS-ot.

( sigellef | 2020. 06. 25., cs – 23:29 )

Ha ilyen nagy fába vágnám a fejszémet, vennék olyan alaplapot, amin jó sok SATA csatlakozó van, aztán minden csatlakozóra 20TByte-os lemezeket. Csinálnék NFS megosztásokat, minden hónapnak 1 megosztást. Így könnyű kezelni azt a szituációt, ha egy hónapban már megtelne a merevlemez. Sok fájlnál elvileg az xfs a legjobb, úgyhogy fájlrendszernek azt használnék.

Aztán építenék mégegy ugyanilyen gépet backupnak, ami mondjuk hetente bekapcsol, lefut egy script ami leszedi az új fájlokat a párjáról, azán kikapcsol. Ez a backup gép meg csak a párjával lenne összekötve (a megosztógépbe persze 2 hálókártya)

Aztán lenne egy olyan gép is, ami összesíti ezeket a megosztásokat, és innen tovább osztaná NFS-en, SMB-n helyi hállóra, (s)ftp(fs)-n, sshfs-en, weben meg osztaná kintre. ... természetesen tűzfalnak/routernek is egy linuxos gépet használnék.

Ha az adattároló/backup páros megtelik, akkor lehet építeni a következőt, kb. SATA csatlakozók számától függően 2-3 év mulva. Gondolom, egy ilyen gigatikus terv megvalósításánál nem a pénz lenne a szűk keresztmetszet.

Elvileg havonta igényelne annyi munkát, hogy a fájltárolókon mappát+exportot csinálni, az összesítőgépen meg mount pointot, és a felcsatolást. (bár, ezt se nagy kunszt automatizálni)

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

( lcseh | 2020. 06. 26., p – 05:28 )

20-24 diszkhez milyen tápegység kell?

Gondolom tetszoleges brand vagy wl gyarto 650-1200W barmi jo ami benne van.

Regen sem kajalt teljes munkaterheles mellett 10W folott 1 hdd maiak szerintem ezt lentebb adtak mar 5-8 korulre.

Amit tudok, hogy nagyon egyszeru hazi wl epites 36 diszk es egy 360W tap elvitte zokszo nelkul 5 evig.

Every single person is a fool, insane, a failure, or a bad person to at least ten people.

( end | 2020. 06. 26., p – 09:07 )

Szerkesztve: 2020. 06. 26., p – 09:17

Syno, 6 lemez x 4TB, persze mehet felfelé, akár 16TB is, bár az kicsit már drága lesz. (Lent "Not SMR"!) abból is kettő legyen, egy offline mentésre!  + RAID6! -  Soha nem bíznék ennyi képet felhőkre, a mai vírus-polgárháborúk "szántotta" időkben, csak arra számíthatsz ami közvetlenül a "hónod alatt" van. Vagy arra sem.., - de legalább az "örökösök" majd megtalálják, vihetik ha szükségessé válik..., és a képek jó eséllyel megmaradnak az utókornak, persze ha ez szükséges és kalkulált cél. (Egyébként 250 TB talán mozifilmek "kockánkénti" digitalizálásánál??? - Mert ezt a mennyiséget különben nehezen tudom elképzelni. - Esetleg CERN?  :) )

"összes létező magyarországi EU-s projekt" -  Ha esetleg ez lenne a cél, akkor talán nem kéne "home"-filozófiával hozzáállni a kérdéshez. (Mert akkor a pénz nem lehet akadály, a világ bármelyik tároló, (back-up) megoldása szóba jöhetne. - (Annál is inkább, mert az adatokat használó szervezetek működéséről, azaz létkérdésről lenne szó.)

https://www.tomshardware.com/news/western-digitals-18tb-hard-drive-brea…   --   Így már lehet merevlemezenként 200 ezerért növelni a tárolókapacitást. - Arra gondolok, hogy az IOPS-ot megelőzi a tárhelyméret, mert anélkül nem lesz szükség a gyorsaságra.  :)  És hát az éppen feldolgozandó képmennyiséget lehet tárolni lokális gépen, SSD-én. (A keresés gyorsasága, a tárolás-archiválás rendszere, szoftvere sokat segíthet a dolgon. Meg ez a feladat mindig is csak kompromisszumosan lesz megoldható.)

... az is jó kérdés, hogy miről kapja a képeket a tároló? egy eszközről? többről? Ha többről, akkor a tárolást nem volna érdemesebb több tárolón csinálni? Honnan jönnek a képek? Külső hálóról, belsőről?

Összerakni egy ilyet, aztán 5 évig hozzá se nyúlni?

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

( tompos v | 2020. 06. 26., p – 10:47 )

En is beirom a tutit.

En DAS-t vennek. Mi Supermicro-t hasznalunk.

( nagy_peter v | 2020. 06. 26., p – 12:41 )

Fontos, hogy egy helyen, egy fájlrendszeren legyen minden adat?

5 év alatt a most megvett, beüzemelt, csak üresjáratban pörgő merevlemezek már épp cserére érettek lesznek, miközben 4 évig üresen állnának. (de az áramot addig is eszik az üres lemezek, viszont mire terhelést kapnak, már rég nem lesznek garanciálisak)
Talán olcsóbb évente egy 50 terrás tárhelyet beüzemelni, pláne, hogy minden évben csökken az áruk, és növekszik a sebességük.

50 Terrás NAS meg most is már jó áron beszerezhető, sőt, lehet komolyabb vas is, amibe csak egy év múlva veszed meg a következő 50 terra tárhelyet. Utóbbiba ha elég nagy lemezeket veszel, még bővíthető is később egy hasonló dobozzal.

Nagy Péter

Ott a pont - nagyon erősen szuboptimális dolog 5x akkora tárhelyet venni most, mint amennyire egy-két éven belül szükség van. 5-6 tárolótömböt is aránylag kényelmesen lehet egy fs-ként láttatni, megfelelő frontendet elépakolva akár.

( mbael | 2020. 06. 26., p – 13:13 )

Ugy hogy elotte azert utanajarnek hogy ez egy valos igeny-e, vagy csak olyan whishful thinking mint mikor a fejlesztok egy MVP-t millios latogatottsagra terveznek.

( PDA_FAN | 2020. 06. 26., p – 15:39 )

Évente 50 TB fotó??? Értem én, hogy még kicsi a gyerek és annyira édibédi, de fel is kellene  nevelni, nem csak fotózni minden pillanatát :-)

Hát lehet, hogy egy fotóstúdió, ahová hordják talicskaszám az édibédi gyermekeket és ezért megy napi 12 órában a fotózás.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Melo vegen nalunk az osszes psd flattened(ez elegge csokkenti a meretet) Nem tudok ertelmes scenariot elkepzelni miert lenne szukseg arra, hogy random valamirol egy ev mulva pont vissza kellene mennem mondjuk a 12. Mask-ot buzergalni es azt visszaallitani mondjuk mielott meg feher a fogsora Mihalynak de Belanak meg mar igen...

Plusz psd fileokat nem kell altalaban 200MB/s -el olvasgatni elvannak vmi cold backup-ban.

Nem ástam bele  storage ténakörbe, mintha a cold storage az lenne, hogy oda ritkán kellő adat kerül, ahonnan lassú az olvasás, pl AWS glacier. A 200Mb/s így számomra nehezen értelmezhető.

A PSDnél meg lehet, flattening, nem szoktam, mert nem ipari mennyiségűt állítok elő, csak hobby.

( tomsolo | 2020. 06. 26., p – 17:19 )

tippre ez vmi térfigyelőhálózat vagy vmi hasonló projekt akar lenni

No rainbow, no sugar

Lehet ezt akarják nagyon megtolni: https://archive.org/details/3.5_Floppy_Scans_Jason_Scott_2018-11 :) A TIF-ek (5+ MiB) miatt 8 MiB per lemez, csak 39.321.600 floppy kéne hozzá; el tudom képzelni, hogy ha nem deduplikálják a meglévőket, simán összejön ennyi :)

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Parlament makettre még nem volt szükségem, az IA már jött jól, amikor egyik kedves cég a megvásárolt "Digital download" terjesztési módú szoftverről közölte, hogy eltüntette a telepítőket az oldaláról, de a low-low X USD-s havidíjért tök jól elő tudok fizetni az új előfizetéses megoldásukra :( (jó, nem ENNYIRE régi verzió volt, de pl. Win 3.1-et már szedtem le tőlük :) )

Szerk.: https://twitter.com/textfiles/status/1217567726253768711 6000 floppy/családdal számolva 6666 család kellene, és meg lenne a 250TiB :)

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

"Parlament makettre még nem volt szükségem..."

- egyrészt még lehet, nem tudhatod előre mikor lesz, másrészt pedig nem feltétlenül átfedéses a két célcsoport (bár nem zárnám ki teljesen azért...) most gondolj bele, egy ilyen gyufa-modellnek milyen macerás lehet storage-ot fenntartani... :)

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

( hrgy84 | 2020. 06. 27., szo – 23:56 )

Szerkesztve: 2020. 06. 27., szo – 23:57

Hat itt mindenki beirta a tutit, akkor en meg oszinte leszek:

  • Ez a specifikacio mindent tartalmaz, amire rank tartozik: semmit. Erre igy ebben a formaban storage-t tervezni nem csak felelotlenseg, hanem az ugyfel penzenek elherdalasa.
  • Amiket meg kell kerdezni az ugyfeltol, ha nem tudja, akkor addig kell elemezni a tervezett workflow-t, amig ki nem esnek a szamok:
    • Oke, hogy 250T adatot akar tarolni, de ezt megis hogyan, mire akarja felhasznalni?
    • Ennek mekkora reszet kell instant elerni, mekkora reszere nincs szukseg percrekeszen?
    • Mennyi az az ido, amikor az adat mar nem kell elerheto legyen a rendszer szamara egyaltalan? (cold archive)
    • Mennyi az az ido, amikor mar a business logic nem epit feltetlenul az adatra, de elerhetonek kell lennie? (hot archive)
    • A 200 MB/s olvasas az pontosan mire vonatkozik? Mit akarunk ennyire gyorsan elerni rajta, csinalni az adattal? A kepek csak ott allnak, es idonkent letolti valaki, vagy majdnem folyamatos processzalas megy rajtuk vagy mi a skorpiofullank?

En biztos, hogy tobb szinten tarolnam az adatot, nem egy-tobb darab nagy femdobozban, hanem atgondolnam a teljes use-case-t, es elkezdenem keresni, hogy honnantol nem kellenek azonnal az adatok, honanntol nem kellenek 200MB/s -el az adatok, es szepen a tierek kozott migralnek. Ma a cold storage cefet olcso, a AWS Glacier, az IBM meg minden mas felhoszolgatato szemet aron adja, cserebe rohadt lassu elerni, a letoltesnek dija van, etc, de ha nem kell percrekeszen az adat, akkor siman ki lehet tierezni ilyen helyre.

A mennyiseg alapjan tippelve a felhasznalast, a 250T adat nagy reszet az eletben nem mozgatjatok meg, ha megis, spot terhelesre kell keszulni, nem uzemszeru csucsrajaratasra.

Az, hogy a nagyfoni azt mondja, hogy "de mi van akkor, ha szembejon valaki velem a Vaci utcan es megkerdezi, hogy 5 evvel ezelott milyen szinu ruharol toltottunk fel kepet a storage-ba, legyen az is visszakeresheto" az rohadtul nem BAU igeny. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( bbking | 2020. 06. 28., v – 12:51 )

rohadtul nem értek hozzá, de nem pont itt jönne be a Hadoop? Mindig úgy gondoltam rá, hogy ezt a Google mérnökök az ilyen extraorbitális nagy adatok tárolására fejlesztették, de a tárolás mellett maradjok kereshetö és jól elérhetö az adat

( n.balazs v | 2020. 06. 28., v – 12:54 )

Nem zavar senkit se, hogy a topicnyitó csak túráztatott mindenkit? Feldobja a gumicsontot, 2-szer beleír a 139 hozzászólásba és a kollégák itt rágják a gumicsontot. Ingyencirkusz.

Csak hogy ontopic is legyek: Nekem 8-9 éve kellett megtervezni hasonló rendszert (szerkesztőségben fotók tárolására). Ennyi specifikációból nem lehet dolgozni. Ráadásul az igények sokszor eltúlzottak (250 TB helyett 100 TB, 200 MB/sec helyett 20 MB/sec stb.).
Egyáltalán a HyperV-n futó valami piaci szoftver vagy egyedi fejlesztés? Hogyan kezeli le ezt az adatmennyiséget? Sima Windows FS kell neki? Van neki adatbázisa is? Hol fut? Milyen metaadatok vannak az adatbázisban? Csak mert a képek metaadatok nélkül fabatkát se érnek - próbáld meg megkeresni azt az 1 képet, amin XY szerepel a megfelelő pozícióban az 100-200000 kép között. Csak szólok...

250 TB az 250 000 000 képet jelent (1 MB-tal számolva).

Jogos! Bocsánat, nem volt időm válaszolgatni mindenre bár naponta read-only azért jelen voltam!
Ezúton is köszönöm mindenkinek a javaslatokat! Örülök, hogy így beindult a topik sok érdekes és számomra eddig ismeretlen megoldást olvastam! Privátban fel is vettem a fonalat pár emberrel, 1 konkrét megoldási javaslat Synology vonalon már érkezett is.

Válaszolnék is röviden pár kérdésre ami közben felmerült és sikerült megtudnom:

  • Pénz nem gond, van rá forrás
  • Nem álmodozásról van szó, az igény valós
  • A 200MB/s valóban kicsit túlzás volt de a tárhely egyáltalán nem, az 50TB/év sokadik átgondolás után is valós igény.
  • Orvos-kutatás szakágba menne a vas, képalkotó diagnosztikával kapcsolatos projekt. "Vizsgálatonként" kb. 5-600MB kép kerül feldolgozásra, egyszerre sok end-user is püfölné a szoftvert napi nagyonsok órában így a ~100.000 vizsgálat/év reális
  • Ceph/ZFS nem játszik.. Ceph-fel semmi, ZFS-sel minimális tapasztalatom van (bár nem egyedül üzemeltetném) így inkább nem hősködnénk.
  • Képeknek nem kell kereshetőnek lenniük
  • DB-ben is tárol adatokat (metadata), a képek közvetlenül az FS-en lennének
  • Redundancia (RAID, akármi) természetesen fontos az adatvesztés elkerülése végett de ha van egy hosszabb áramszünet és az UPS nem bírja tovább akkor kibírják ha pár órán át nem elérhető a storage ezért failover annyira hűdenagyon nem fontos.

Orvosi képalkotás... viszont így már felbontható kisebb storage-egységekre a dolog, akár aszerint, hogy melyik osztályról küldték a beteget képalkotásra. bel, tüdő, ortopéd, stb... Mindegyik kép az adott osztályhoz tartozó storage-re menne, így akár megvalósítható, hogy egy-egy osztály saját storage-éhez akár külön csatornán csatlakozzon.

Persze, nem sok rálátásom van, de egy strukturált tár-rendszer szerintem hatékonyabb lenne, mint egy óriási nagy tárolóegység.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

A van rá forrás az jó, de... Most akkor sem szabad öt évre előre megvenni a vasat, hanem lerakni egy 5+ éves projekttervet arra, hogy évente mennyi üzemeltetési és mennyi beruházási költséggel jár a rendszer kialakítása. Mondom: ha most veszel nettó 500TB-nyi tárolókapacitást, ami alól  3-5 év múlva "kiesik" a garancia,miközben ténylegesen nem használtad a döntő hányadát, az nem jó üzlet. Mármint annak, aki veszi.  Én 50+50TiB "blokkokkal" indulnék el, akár úgy, hogy indulásként egy komolyabb, ekkora méretre skálázható storage (vezérlő plusz 50-100TB-nyi nettó tárterülethez diszkfiók), és évente a tényleges igényeknek megfelelően bővíteném.

A szoftver,a mi a képeket lerakja/visszahozza, az hogyan épül fel? Gondolom, a DB tárolja, hogy "merre" van az adott fájl a fájlrendszerben (apropo, fájlrendszer: erősen javasolt valamilyen hash-eléssel több szintes könyvtárstruktúrát összerakni - párezernél több kép ne legyen egy könyvtárban).
A betárolásnál célszerű lehet lerakni gyors elérésű tárterületre egy-két kisebbfelbontású/méretűre konvertált verziót a képekből, amiket előnézetként lehet majd használni.

A redundancia kettő szinten kell: egyrészt a tárolás (RAID-jellegű diszktömb, minden adat legalább két diszken legyen ott), másrészt a rendelkezsére állás miatt is szükséges (most lehet, hogy nem, de későbbez az igény is elő fog kerülni, hidd el...), illetve a 2. szervert lehet mentésnek is tekinteni (mert 50-250TiB adatot nem igazán fogsz tudni máshogy menteni és az erdeti tárolási helytől független, de hasonló védettségő helyen tárolni).

Apropo, védettség. Eü. adatokról van szó, tehát ha a képen szerepel bármilyen olyan infromáció, amivel adott természetes személyhez kapcsolható, akkor maguknak a képeknek az elérése, megtekintése is naplózásra kell majd, hogy kerüljön: ki,mit és mikor nézett meg (különleges adatok), erre a naplózásra is felkell készülnie a rendszernek (tárhelyben is...).

 

Redundancia (RAID, akármi) természetesen fontos az adatvesztés elkerülése végett

A RAID nem az adatvesztés elkerülése ellen jó, hanem arra, hogy ha meghal egy lemez, attól még nem hal le a szolgáltatás.

Adatvesztés elkerülése érdekében backupot kell használni. Akármilyen RAID-et építhetsz, el tud veszni az adatod, ha rossz kombinációban néhány lemez kb. egyszerre döglik meg.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Szőrszálhasogatás, de ez azért nem teljesen igaz, mert a RAID elsősorban adatvesztés elleni eszköz. Csak azért lesz tőle nagyobb a rendelkezésre állásod, mert nem veszik el az adat. Persze ettől még kell a backup, értem mire gondolsz, csak sok időm van kötözködni. :)

Nézd, azt csinálsz, amit akarsz.

Én RAID-et nem használok egyáltalán adatvesztés ellen, és egyáltalán nem gondolom, hogy _elsősorban_ adatvesztés elleni eszköz. Mivel én is azt csinálok, amit akarok, én nem használok RAID-et adatvesztés ellen.

Csak azért lesz tőle nagyobb a rendelkezésre állásod, mert nem veszik el az adat.

Azért lesz tőle nagyobb a rendelkezésre állásom, mert:
1) a rendszer nem omlik össze / bootolható marad egy hdd bekrepálása esetén
2) nem kell az elveszett adat backupból visszaállítására várni

Két, három, vagy több hdd meghalása esetén se vész el adat, mert a backupban megvan minden, viszont ezeket a helyzeteket az általam használt egyszerű RAID-5 vagy RAID-1 már nem tudja megoldani, szóval ilyenkor a gép addig nem indítható újra, amíg nincs csere hdd, és addig nem lesz teljesértékű, amíg a backupból vissza nem állította valaki a dolgokat.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

> Én RAID-et nem használok egyáltalán adatvesztés ellen

vs

> nem kell az elveszett adat backupból visszaállítására várni

:)

A fogalomzavar (és a hosszú threadet nem érdemlő mondanivalóm lényege) az, hogy adatvesztésnek nevezzük azt is, amikor csak egy (helyi) példánya veszik el az adatnak ami valamilyen módon visszanyerhető. A RAID1+ márpedig véd az adat "helyi" példányának elvesztése ellen, emiatt marad bootolható az oprendszer és ezért nem kell a backup visszaállítására várni, magyarán a rendelkezésre állás elsősorban az által javul, hogy nem veszik el az adatnak egy adott példánya.

Hát, akkor különböző módon használjuk ezeket a szavakat.

Számomra az az adatvesztés, amikor egy adat a múlté és max. szentségelni tudok.

Ha megvan másolatban akárhol, akkor nem volt adatvesztés.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

( bocs | 2020. 06. 28., v – 19:38 )

google earth versenytárs készülődik apu garázsában :)

Én is találgatni akarok :)

Mikor egyszer gyorshajtásért kaptam "csomagot", linket is kaptam, ahol 5-6 képen keresztül meg tudtam nézni, hogy sajnos igazuk van. A képeket le tudtam szedni a weboldalról. Méretük kb. 100 KB/db. (a mai napig megvannak, az eset 2012-s), a metadatokban szépen ott van minden, hol, mikor, ki volt a rendőr, milyen távolságban voltam, mennyivel mentem stb. Innen "ugorva":

Nem tudom, hogy pld. a VÉDA rendszer mozgófilmet rögzít vagy pillanatképek sorozatát. Ha utóbbit, akkor még akár ezzel kapcsolatos ügy is lehet :)

Ne kattints ide!

Hmm a GIS jól hangzik :) Én is csak azért járok már ide, hogy hátha végre kiderül :)

Az én légből kapott tippem: repülőgépről fényképezett mezőgazdasági területek, amit analizálnak, hogy milyen a vetés, aztán a képekre már nincs szükség.

“Any book worth banning is a book worth reading.”

( bennyh | 2020. 06. 29., h – 13:49 )

HEIF-ben kell tömöríteni mindent, mindjárt elég lesz 100T is, azt meg egy 8 lemezes Syno + 8 db 20TB lemezzel "költséghatékonyan" megoldható. 

( sigellef | 2020. 06. 29., h – 15:31 )

... bezzeg 10 év mulva... csak leslattyog Kókány Pistike a sarki hardverboltba, és mondja:

- Csókolom, kérek 2 darab 300 terás vinyót!

- Húha... az már kifutott, csak 600 terás a legkisebb... 1000 terás van akciósan, ha 3-at veszel, kapsz ajándékba egy házat meg egy tápot.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.