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?
Hozzászólások
A kritikus sebesség számszakilag mennyi? Mentés is lesz (ugyebár a RIAD nem mentés)? Kell HA? Lehet Ceph?
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.
Nade 500 kB-1MB méretű állományok esetén irtózat IOPS kell, ha 200 MB/s átlagsebességet szeretnénk elérni a felolvasásuk alatt. Vagy rosszul gondolom?
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.
Kicsit off:
veeam-ot érdemes otthoni (2-3 laptop néhány tucat Gb adata) koca-mentős megoldásnak (de free legyen!) használni?
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ó.
https://www.youtube.com/watch?v=FAy9N1vX76o
Akkor már ez: https://www.youtube.com/watch?v=C2uLSOmRx_c
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
Ez be volt baszva a videó forgatása alatt?
Esetleg felhőben?
1250$/month tárolás
2500$ a 250tb egyszeri letöltése
(gyors calc, backblaze b2)
Nem kötekedem, csak kérdezem, a fenti igények fényében ez soknak számít?
"Everything fails, all the time."
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.
É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."
Szerintem borzalmasan sok penz.
250TB-nyi adat 1MB-os file-okban, gondolom magas rendelkezesreallassal, mentve, ugy hogy kozben 200MB/s atviteli sebesseg elvart az meg borzalmasan nagy feladat.
Es eddig tartanak a nagyravagyo tervek. Innentol jon a racionalitas. Megelegszenek majd kisebb kapacitassal, alacsonyabb sebesseggel, stb.
Egesz biztosan meg 5 evre vetitve is legfeljebb kb a tizede lenne elfogadhato, ami az arat illeti, de inkabb meg kevesebb.
Fordítva nézd, képenként csak 0.00000488281 dollár! :)
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.
IOPS-ban mit tud hozni? mert 200MB/s az durván sok, pláne a maximum 1MB-osra saccolt fájlméretek esetében.
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
Ha meg nem akarsz az OS-el küzdeni:
https://www.synology.com/hu-hu/products/FS3400
Igen, van hasonló stackelhető doboznk. Viszont a synology nem jött be, így nem is szoktam ajánlani :D
Fedora 38, Thinkpad x280
Én sok helyen használom és sosem volt gondom vele. Műszaki problémád volt, vagy csak nem tetszik a képe? :D
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
Akkor téged nem szeretnek :) Nekem ezekből egyikhez se volt szerencsém, pedig van proxmox alatt iscsi ha is.
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
DellEMC PowerScale (exIsilon) scale-out NAS. Ha érdekes keress meg és tudunk róla beszélni és ajánlatot adni.
https://www.delltechnologies.com/en-us/storage/powerscale.htm
Ment PÜ! :)
Nalunk most ilyesmi van: Dell EMC Isilon H500 Hybrid NAS Storage
De mivel a felhasznaloi oldalon vagyok a vasat sem lattam. Egyelore mukodik.
Inkabb ez: https://www.delltechnologies.com/en-us/storage/powerflex.htm
Low cost: https://serverelite.hu/storages-81/hp-storageworks-245/p2000-g3-msa-24x…
Ez SFF, az életben nem pakol bele ennyi tárhelyet...
Nem is egy gépre gondoltam :)
https://www.supermicro.com/en/products/general-purpose-storage ...
36 ... 72 db diszk + RAID => 8 TB SATA esetén már megvan a tárhely a kisebbikben, de 16 TB-os diszkekkel is feltölthető.
ebbol ki fog jonni a 200MB/sec speed? es ha 1M kepekkel szamolunk akkor az >200 kapcsolat adott pillanatban. birni fog ennyi random readot?
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
1MB legyen kb 50ms/diszk, azaz 20 MB/sec/diszk -> a 200MB/sec lazán kijön. Lazán.
Viszont ha hálózaton akarja elérni a posztoló, akkor okosan kell protokollt választani, könnyen bottleneckre lehet futni.
+1
Valamint ha eldől 1 disk, akkor a spare 8-16 TB lemezre a resync mennyi idő, és addig milyen iops lesz?
RAID10 esetén ezzel nem igazán lenne gond.
60db 8TB lemez? Esetleg 42db 12T-s?!? Nem kevés darab ...
Kivéve ha a resync kellős közepén eldobná magát az a lemez is, amiről épp szinkronizál. Akkor húzhatod újra mentésből az egész 250 terás tömböcskét...
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.
Netflix-nél dolgoztál?
Nem de hasonlitott, az egyik legnagyobb japan mobilszolgaltato alvallalkozojanal voltam, mi adtuk a cegen beluli filmnezos megoldast.
sub
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.
ha nem nyul hozza, IBM Cloud Object Store - Cold Vault, azt hiszem 1$/TB/honap.
Hát a B2-t nem közelíti meg senki: http://coststorage.com/compare/
legalabb olvasnad rendesen amit irok :(
IBM cold vault: USD 0.00099 per GB/month.
b2: $0.005/GB per month
Az IBM cold vaultból egészen véletlenül nincs restore-költség? Vagy úgy gondolod, az a 2 cent/GB nem számít 200 MB/s-es forgalom mellett? :(
de van, de irta, hogy nem akar hozzanyulni, hanem csak eltarolni hosszu tavra. en ugy ertelmeztem hogy az a 200MB/s az a lerakas, amikor archival, de FIXME, ha rosszul ertettem.
igen, ezt en neztem be, jogos.
a kerdes persze h a B2 tud-e 200MB/s-et, illetve hogy otthon milyen internetet kot ami tud ennyit :)
A 200 MB/s amúgy coldnak számít egy ilyen cloud megoldásnál? :)
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.
Nekem is eszembe jutott csak egy account alol kellene elerni amit az elso public link tobbszaz felhasznalo utani rangatasakor tiltananak le a 3.14 csaba.
Mondjuk ugyanez Team drive alol lehet, hogy mukodne...
Nem tudom van-e fizetős verziója vagy ilyesmi de úgy lelőnek majd mint annak a rendje. Az unlimited storage sem unlimited igazából :)
Az csak addig unlimited, míg több hasznuk van belőle mint neked.
Letezik par darab 150TB+ Team drive amit eleg sokan rangatnak igaz azokon 400K-s file limit van...
ha nekem adnak ez a feladatot akkor en viszont pont megneznem a cephet (nem a cephfs, bar lehet azt is):
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.
A B2 Glacier áron ad warm elérést.
Igen, de attól még cephetül sok adat, és sok vas kell alá... :-)
a 250TB sok adat volt 10 eve. manapsag mar nem annyira. mi most tervezunk egy 2.5PB bovitest...
Nagyz mindig tud nagyobbat mondani...
2,5 PB nem sok adat. Tessék. :)
abszolut nem sok, igy van. 3 ev alatt a flash ara majdnem negyedelodott.
Na ja... 20 (meg egy kicsi...) éve egy adattárház projekthez volt 1TB storage odarakva... Ráadásul úgy, hogy két szállító motyója lett összerakva, és a megrendelő a tesztek után döntött, hogy melyiket kéri.
regen meg amiga is letezett es zx spectrumot is hasznaltak emberek.
megregebben a romaiak meg utakat epitettek.
hogy jon ez ide?
A "sok" az relatív. Neked a 250TiB nem sok - ennél a projektnél meg sok.
A mai vilagban nem sok. Par sorozatom meg kb 60 filmem van fent gdrive-on 5TB+...
Azok az utak még most is állnak...
Azok a Spectrumok még most is futnak...
Kár hogy az utat nem mutatja semmi, pedig jól kijött volna :(
“Any book worth banning is a book worth reading.”
" 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...
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).
Hol a redundancia?
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Sehol nem írta hogy redundanciát is szeretne!
De ha redundancia is kell, akkor 2x kell a fenti config, ZFS send/recive X időközönként.
Én valahogy nem bíznék egy ilyen feladatot egy ilyen megoldásra, de lehet hogy csak én vagyok így ezzel...
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
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
Egyszerűen azért, mert olyan verziót sem tudok elképzelni, hogy akinek kell egy ilyen rendszer, az lemondana az adatbiztonsagról.
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
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 ...
az, hogy folyamatosan Tb-ot irogatsz TB helyett (vagy TiB helyett) sokat elvesz a mondanivalodbol
Nem a kapacitás a fontos, hanem a napi használat során jelentkező problémák kezelhetősége. Nem csak papíronkénti működjön egy projekt, hanem a való életben is.
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
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ó.
tehat szerinted OK elveszteni siman 250TBot? mert ha nincs redundancia es backup, akkor elobb-utobb ez lesz.
Ahogy a bölcs öreg rendszergazda mondaná: Ami egy példányban van meg, az nincs meg.
Minimum 3 lesz az.... Ami csak 2x van meg, az sem sokkal jobb, mert ha az egyik példány elveszik, máris csak egy példányban van meg...
Pontosan. Csak nem akartam bő lére ereszteni :-)
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!
Figy, te gyakorlati tapasztalati üzemeltető, térjünk már vissza az első kérdéshez: "hol a redundancia?" :)
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Téged skippeltelek ...
Nem vagy hajlandó válaszolni, figyelmesen olvasni, nem tetszik a hangnemed ...
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
TLDR leirna vki, mi a problema a ZFS-es megoldassal elvi szinten ha mondjuk hozzatesz az ember redundanciat?
Gyors olvasgatas utan nem derult ki. Elmentetek szemelyeskedesbe mar reg, az nem erdekel.
+1 Nem értek a témához, de kiváncsi vagyok és érdekelnének a szakmai szempontok. Ezért olvasogatom a topikot, de érvek helyett csak anyázást látok.
É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.
É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.
Valamit rosszul jegyeztél meg, ilyet én soha nem mondtam.
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
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
OK, tenyleg trollkodni jottel;)
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
A kerdest provokativan raktad fel, ezen kivul amikor nem ertel celt vele, nem voltal hajlando rajta valtoztatni, konstruktiv lepeseket tenni annak erdekeben, hogy megtudd, amit szeretnel.
Igen, troll vagy, Nyilvanvaloan kotekedes celjabol irtal.
Én elengedtem!
Ebbe az „emberbe” felesleges időt/energiát invesztálni, nem lát tovább a saját szobája falánál ...
Te sem voltal sokkal konstruktivabb, epp csak egy picivel.
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
Most ettől meg kellene sértődnöm? :D
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Ja, ha ez neked ebből az egy mondatból nyilvánvaló, akkor ez inkább neked lehet probléma... :)
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
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!
Fentebb már megtettem.
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Te még saját magadnak is ellent mondasz! :D Hol írtad le???
Másold be kérlek!
"É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!
Ugyan nem engem kérdeztél, de szerintem igen.
Pontosan mit vársz ettől a beszélgetéstől amúgy? Ha nem tetszik, ahogy beszél veled, engedd el a sztorit, nem kell hatodjára is leírni, hogy bezzeg zitev névtelenül kommentel. Kit érdekel?
" Te egy igaz barom vagy! "
- :D
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
https://kep.cdn.indexvas.hu/1/0/3205/32054/320546/32054667_75572e5ea8a8…
" 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.
Azért az "évi 50TiB, de most meg akarjuk venni öt évre" nem zab (lókoszt), hanem hozzánemértő projekt inkább :-)
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
Basszus, ez komoly? Ennyibe fájt a HP Microserverem 4×8 TB diszkkel… (természetesen ZFS-sel :)
Bizalomgerjeszto, hogy el sem lehet erni a weboldalt.
Amugy az X200 az nem EOL fazisban van mar vagy nagyon kozel hozza?
DE-bol behozott hasznalt HW-vel foglalkoznak. Az lenne a fura, ha vmi uj cucc lenne ott.
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!
Még fél órája is a 369 eFt + ÁFA volt az ára. Így már sok. De nekem még mindig kérdés, hogyan jön ki a 60 darab HDD, és ez csak a egyik probléma.
De ez legyen annak a gondja aki megveszi. :)
De elirtad...
Az csak a garancia kiterjesztes ara. A motyo ennyibe kerul:
1 990 000 Ft+ÁFA, 2 527 300 Ft
Nem írta el, tegnap még tényleg annyi volt kiírva, 82%-os engedménnyel adták (volna).
Tegnap nekem be sem jott a honlap ma meg ez az ara :( Valoszinuleg vevocsalogato kamu volt vagy lehet epp ezert inkabb kilottek minthogy rossz arat mutassanak.
Nekem bejott az oldal, lattam is a jo arat, meg el is gondokoztam, csak aztan abban maradtam magammal, ogy itthonra kicsit tulzottan eros es hangos lenne. :)
amit leirtal az egy kokler hack, semmi mas, erre akartak itt neked ramutatni, csak nem akarod hallani.
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.
Áhhh, csináld akkor, mit bánom én... :)
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
mai teszt:
https://www.servethehome.com/hands-on-look-at-the-supermicro-simply-dou…
Itt a megfelelő hardver! :)
24xLFF SATA/SAS HDD + 2xSFF NVMe, dual Xeon Scalable
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.
20-24 diszkhez milyen tápegység kell?
Hagyományos HDD-hez kb 200W. Mértem fogyasztást 8W fölött nemigen evett egyik sem.
... és amikor felpörög? Az első néhány 100ms alatt van az 30W/disk is!
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
+1. Anno scsi diszkeknél volt, hogy "illett" beállítani, hogy a kontroller egyesével küldje a start parancsot a diszkeknek, amik így egymás után pörögtek fel, nem egyszerre.
kultúrált kontroller már tudja ezt SATA/SAS rendszereken is nagyon régóta (staggered spin up SSU, vagy Power-up in standby (PUIS) vagy PM2)
Pédául egy 24 diszkes Dell/HP/IBM/Supermicro/... eszközben gyárilag meglevő 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.
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? :) )
... szerintem fényképész az illető... vagy az összes létező magyarországi EU-s projekt fotodokumentációját kell tárolni.
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
Fényképész 500kB - 1MB közötti mérettel?
"ö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ó.)
6x4=24TB. vs. évi 50TB - azaz évente négy (redundancia miatt) doboz, telepakolva.Ha mindez tudja azt az IOPS-ot, amit a 200MB/s elvárt olvasási teljesítmény igényel (ez 200-400 kép/s!)
Itt elsősorban IOPS-ra kell "lőni", és tárterületre csak utána. Szerintem...
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ó.)
A 18TiB méretű diszk mekkora iops-ot sajtol ki magából? 200-400 kép/s kell, hogy kijöjjön a motyóból, ami nem triviális.
... 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.
En is beirom a tutit.
En DAS-t vennek. Mi Supermicro-t hasznalunk.
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.
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.
Olcsó gépek, 12-24 diszkel, es zfs meg mindencsoda helyett minio. Megoldja a gépek közötti szinkronizációt, konnyen lehet bele uj nodeokat felvenni.
https://docs.minio.io/docs/distributed-minio-quickstart-guide.html
---...---
TLoF
É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.
Maybe, de akkor nagyon sántít az 1 MB per kép.
Egy raw kep (kameratol fuggoen) ugy 25-50MB kozott van.
kicsi gyerek, kicsi kép :-)
Amúgy meg persze fogalmam sincs, hogy ki és milyen képekről beszél.
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.
+ JPEG, ami meg 5-10 MiB kb. Csak backupnak, mert még mindig jobb, mintha a kép sehogy sem lenne meg - a RAW sérülése esetén.
Továbbá egy átlagos PSD fájl 200-1000 MiB, ha hozzá kell nyúlni. A fotózás drága mulatság tud lenni.
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.
tippre ez vmi térfigyelőhálózat vagy vmi hasonló projekt akar lenni
No rainbow, no sugar
Oda meg videok mennének. ... esetleg +képek, amikor riasztás van
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
5 évig megőrzött fényképekkel? Hmm..
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
képet írt, nem fényképet,
Festmények?
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
lemezképek :)
"Normális ember már nem kommentel sehol." (c) Poli
500kB-1MB közötti mérettel? Képtelenség!
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Floppy lemez lehet.
300TB storage mérettel... Élénk a kép-zeleted!.. :)
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
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)
Ez kb annyira hasznos projekt lehet, mint mondjuk gyufaszálakból összeragasztgatni a parlament makettjét... :)
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
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
Hat itt mindenki beirta a tutit, akkor en meg oszinte leszek:
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
via @snq-
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
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:
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...).
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.
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.
google earth versenytárs készülődik apu garázsában :)
Hogy a fogalom nélküli találgatásba magam is beszálljak, ja, valami GIS dolog jutott az eszembe nekem is.
É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.”
Ilyen kicsi kepmerettel? Ennyi erovel nem kell kepeket kesziteni eleg egy pattern a fotoboltbol es nezegethetik azt ugyanazt fogjak latni azon is :D
lehet hogy szetvagjak :)
“Any book worth banning is a book worth reading.”
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ó.
... 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.
10 éve se volt sokkal drágább az 1TB-s lemez, kicsit stagnál az ipar, csak most nagyon sok pénzért vannak nagyon nagy lemezek, régen meg nagy pénzért csak gyorsak vagy SAS-osak voltak 3-4TB-ig.
Olcsóbb lett az, csak azóta úgy leértékelték a Ft-ot, hogy nem veszed észre.
Lásd:
https://www.tozsdeasz.hu/usd-huf-arfolyam-grafikon-10-ev-cop0/
https://www.tozsdeasz.hu/eur-huf-arfolyam-grafikon-10-ev-cop0/
En csak egyre novo grafikonokat latok.
Magyarország jobban teljesit, mint 10 eve!
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
LOL!
Főleg akkor jó, ha külföldre mész és nem USD/EUR-ban kapod a fizetésedet. Egyébként érdekes lenne kiszámolni, hogy ki járt jobban: aki mondjuk dollárra váltotta a pénzét vagy aki Magyar Államkötvénybe.