Sok-Sok-Sok adattárolás... De hogyan?

Linux-haladó

Sziasztok,

Elméleti szinten érdekelne egy téma, ami nem hagy nyugodni, főleg, hogy a neten nem találod rá leírást / megoldást. Majd megvalósítanom is meg kell, de majd csak később.

Hogyan lehet egy webszerver alá korlátlan tárhelyet varázsolni? Úgy értem a korlátlanságot, hogy a végtelenségig bővíteni a tárhelyet.

Az egyszerűség kedvéért vegyük az instagram-mot. Napi szinten felfoghatatlan mennyiségű képet és videót töltenek fel oda. De hova?

Az instát is egy webszerver szolgálja ki - tudom... nem egy, hanem sok és load balancer és társai, de ettől most tekintsünk el és a web szerver részt az egyszerűség kedvéért tekintszük 1 darabnak, függetlenül attól, hogy sok web szerver, sok load balancer és sok adatbázis cluster alkotja. Tehát webszerver.

A webszerverhez tartozik egy public mappa, docroot, ahonnan ezeket a tartalmakat ki tudja szolgálni. Hogy a fenébe csatol ide be korlátlan mennyiségű tárhelyet?

Szóval vannak NAS szerverek, amik lemez kapacitás szempontjából végesek, legyen az 24, 48...stb fiókos, de véges. Abba tesznek winyókat (hdd vagy ssd), de azok mérete is véges, plusz a háttértárak valamilyen logika szerint raid-ben vannak, tükör, csikózás, bármi. De mindentől függetlenül a NAS fiók és a bele pakolható háttértár is véges méretű. Szinten lényegtelen információként kezeljük, ezért legyen X terrabyte. Ezt az X TB-t felcsatolom a webszerver public mappájába, mondjuk nas1 mappába. Az instagram fejlesztői programozás szinten megoldják, hogy amíg a nas1-en van hely, addig minden feltöltés menjen oda. És most jön a probléma... a nas1 mounton 95% a foglaltásgi mutató. Jön a lelkes csapat... beszerzés vesz egy új nas-t és háttértárakat, a rendszergazdák összeszerelik és áram alá helyezik, konfigurálják és felcstolják a nas2 mappába... szólnak a fejlesztőknek, hogy figyelj... hogy elfogyott a hely, így mostantól a nas2 mappába töltsetek fel mindent és alakítsátok át a rendszert úgy, hogy amit eddig töltöttek fel, azt mindent a nas1 mappából szolgáljon ki a rendszer, az újakat meg már a nas2 mappában keresse, vagy a link insta.com/nas2/nezdmegkutyammilyencuki.mp4 módon keresse. Azonban a közösség nő, a feltöltések száma nő, így a nas2, nas3, nas4....stb. nas100 mappa is felcsatolásra kerül a webszerver public mappájába. De hol van a határ... mi az elméleti határ. Ha vesszük az instagram-mot, azt hogy oda napi szinten mennyi kép kerül feltöltésre, ott a nas389 2 nap alatt megtelik, tehát kell a 390. és 391 és a 392...stb. ezt így nem lehet a végtelenségig csinálni, mert nem két évre tervezték az instát, mert elfogyott a mount mappák miatt az inode a webszerver alatt. Tehát 5 év múlva is működnie kell sé tudni kell feltölteni képet.
De ha szigorúbb akarok lenni, akkor youtube... egyszer olvastam, hogy napi hány másodperc anyagot töltenek fel oda. Ííííííírdetlan mennyiségű háttértár fogy el naponta.

Hogy lehet ezt kiszolgálni? Függetlenül attól, hogy webszerver public mappa, vagy valami trükkel oldják meg, de a webszerveren, vagy még az sem feltétlenül fontos, mert lehet médai szerver is, ha videó, el kell tudja érni a fájlokat, ahhoz meg valahogy hozzá kell tudni férni. De hogy? Nem mounttolva van a háttértár egy mappába, hanem valami más módon oldják meg? De facebook képek vége is .jpg, tehát közvetlenül érem el, nem valami kép kiszolgáló scripttel, ami a megfelelő protokolon, a megfelelő fejléccel küldi, amit a böngésző, app és minden más képként értelmez, hanem a képet adja oda urlen, tehát valamiféle public mappa van, tehát nem lehet, hogy valami script gereblyézi össze a hálózatról a képet és adja oda bitfolyamként.

De akkor hogyaaaaaan? Biztos amatör kérdés és millió megoldás van erre 2023-ban, de minden olyan megoldás, ami a fejemben van, az valahol nekem valamilyen szinten korlátos, vagy inode, vagy valamilyen szinten.

Ha valaki tudja, hogy ezt hogyan lehet megoldani, akkor szívesen veszem értő és segítő szavait.

Köszönettel:
NoMan

  • 1871 megtekintés

( andrej_ v | 2023. 07. 28., p – 17:08 )

Röviden sehogy. Bővebben valamilyen elosztási koncepcióval. Igen, ha CEPH van, mint "végtelen" mögötte, az is elosztási koncepció, ha nem alkalmazás szintű, de ott is kezelni kéne, hogy ne 238972348272837 file jusson egy könyvtárra.

A határ az, hogy mennyi pénzed van rá, és ha ekkora lépték, akkor már SSD-vel kell számolni, több szempontból is.

Most hagyjuk a pénzt... mivel teljesen elméleti a kérdésem. Hova tovább, ilyen rendszer nem is sok van a világban, szóval tudom, hogy nincs ingyen, tudom, hogy a legtöbb pénzt a villany után erre pacsának el ezek a cégek, de ez most legyen az Ő gondjuk, már amennyire gond, mert azért némi aprópénzt profit gyanánt, azért elraknak ők is. Szóval tisztába vagyok vele, hogy felfoghatatlan mennyiségű pénzt őröl fel, de ez most a kérdésnek nem része. Tehát tegyük fel a pénz is annyira végtelen, mint amennyi adatot szeretnék tárolni és kiszolgálni.

Azt értem, hogy alkalmazás szintű a dolog. Viszont akkor most jön az, hogy nem egy nagy WEBSERVER van, hanem abból is sok és előttük load balacerek. Honnan tudja a load balancer, hogy honnan szolgálja ki azt a navasják képet, vagy videót?

Vagy arra gondolsz, hogy a kép linkje a következő: insta.com/node1/nas21/cukiakutyam.jpg, ahol a node1, megmondja, hogy melyik szerver csoporthoz forduljon a kérés, a nas21 egmondja, hogy a szever csoport melyik nas szerverén van és ott melyik képet kell kiszolgálni. Nyilván a nas1-en belül még ugye valamilyen alkalmazá szintű struktúrálás van, hogy ne 1 mappába legyen 47millió kép, hanem legyen mappákra osztva. De valahogy így gondoltad? És a load balancer meg tudja, hogy amikor azt kapja, hogy /node1, akkor függetlenül attól, hogy mennyire van hülyére terhelve a node1 szekció, akkor is oda irányítja a kérést?

Ennél több réteg lehet, az egyik lehetséges megoldás, hogy a (tetszőleges számú webszerveren) mondjuk a docroot/data/[a..z] az mind külön NFS mount (a pontos szerkezet ízlés kérdése), és az alkalmazás tudja, hogy mit hova pakoljon. Értelem szerűen, hogy ha akarsz egy tükröt Japánban, akkor mindent is tükröznöd kell.

A másik módszer, hogy CEPH vagy hasonló elosztott filerendszer alapon megoldod, hogy minen egyben legyen. Itt ugyanaz a problémád, hogy azért ne legyen egy könyvtárban ott a 47 millió kép.

Biztosan lesz aki az S3 jellegű objektumtárolást mondja, és ha nincs extra sebesség igényed lehet, hogy az megfelelőbb.

Egy komoly problémád mindenképp lesz, mégpedig, hogy milyen mentés készül egy ilyenről.

Ezt írtad: "Majd megvalósítanom is meg kell, de majd csak később." - hát erre lehet, hogy olyan kell, aki már csinált ilyet végtelen léptékben.

( renard | 2023. 07. 28., p – 17:09 )

Szerkesztve: 2023. 07. 28., p – 17:12

Sok-Sok-Sok adattárolás... De hogyan?

Pontosan úgy, ahogy most is történik.  Te is tárolsz adatot, az is egy adattárolás, én is tárolok adatot, az is egy adattárolás, az egész világon rengetegen tárolnak adatot, ami rengeteg adattárolás, vagyis sok-sok-sok adattárolás.

( mortein79 | 2023. 07. 28., p – 17:20 )

Szerkesztve: 2023. 07. 28., p – 17:21

A kérdésedre nem tudom a pontos választ, de egy dolgot megemlítek: az hogy a kép "vége" .jpg még egyáltalán nem jelenti hogy közvetlenül éred el. Nekem logikusabb egy olyan service, ami összeszedi a kívánt képet, és ahogy írod, megfelelő fejléccel kiköpi az adatfolyamot, és mivel a mime type is ismert semmibe nem kerül hogy az url amin eléred ne az legyen hogy "/fb.com/pic/123456/script.php?picid=3456" hanem "/fb.com/pic/123456/3456_imgtitle.jpg". Mindkettő mehet pl. img src-be, de a második közvetlenül is felhasználható mindenféle más helyen, mobilalkalmazásban, css-ben, hírlevélben meg ki tudja még hol, ahol valami buta parser jobb szereti a képnek látszó képeket.

Nevén nevezve a dolgot valami ilyesmire gondolsz?

Nginx szerverről beszélve, ahol az index.php (vagy barmimas.php) belenéz egy relációs és / vagy nem adatbázisba, ahol meg látja, hogy a hálózaton merre kéne indulni, hogy megkapja az adatfolyamot?

location ~* \.(jpg|jpeg|gif|png|bmp)$ {
    try_files $uri $uri/ /index.php$is_args$args;

    add_header        Cache-Control public;
    add_header        Cache-Control must-revalidate;
    expires           7d;
}

( joco01 v | 2023. 07. 28., p – 17:45 )

Ne hidd azt, hogy végtelen. Valamilyen szempontból nézve még az is lehet, hogy a hely szűkös, csak hétköznapi értelemben véve tűnik felfoghatatlanul soknak az a hely. A nagy tech cégeknél nagyon fontos a hatékonyság. Tehát igyekeznek úgy tervezni, hogy mindig pont elég hely legyen, ne maradjon sok diszk üresen. És nagyon sok erőforrás megy el arra, hogy a tárhelyigényt jól tudják előre becsülni. Ennek az is része, hogy olyan rengeteg merevlemezt nem annyiból tart megvenni, hogy lemegyünk a sarki boltba és betárazunk. Gondolom hónapokkal előre le kell adni a rendeléseket.

A technikai megvalósításhoz pedig nézz utána az elosztott fájlrendszereknek, meg úgy általában az elosztott rendszereknek. Itt egy érdekes cikk: https://cloud.google.com/blog/products/storage-data-transfer/a-peek-beh… .

( csizmadia_zoltan v | 2023. 07. 28., p – 17:48 )

Hello !

linux-on is van az LVM ( logical volume), amihez bővítés során felveszed a fizikai lemezegységet, majd hozzácatolod a volume-group-hoz

Amennyi a az elméleti kapacitás) PETAbyte nagyságrendű?), annyit használhatsz

Értelemszerűen az ilyan óriási/összetett rendszereknél is webszerver <-> storage I/O az egyik szűk keresztmetszet

 

CSZ

Aha, aha, aztán jönnek az ilyen meglepetések: https://www.dell.com/support/kbdoc/hu-hu/000050123/networker-ndmp-backu…

 

Lejjebb nyomtam +1-et az object storage-ra, "végtelen" kapacitásigény esetén (feltéve ha az nem egy blob, bár talán akkor is), ez jut az eszembe.

( n.balazs v | 2023. 07. 28., p – 17:57 )

Kikepzo, te vagy az? :)

Néhány kulcsszó a témában:
- SDN (software defined network)
- SDS (software defined storage)
- Nem NAS, hanem SAN, az is software defined alapon
- deduplikáció, tömörítés fájl hash alapján és/vagy blokk alapon
- tiering

Nincs 1 db public mappa. A user felé menő forgalom több forrásból "áll össze". Ezt egy elosztott rendszer csinálja. Az általad látott URL teljesen elfedi a mögöttes infrastruktúrát (cache szerverek, backend szerverek stb.).
Ne 1 szerverben gondolkodj, hanem N-ben.

( STP | 2023. 07. 29., szo – 07:17 )

Hogyan lehet egy webszerver alá korlátlan tárhelyet varázsolni?

Hókusz-pókusz, legyen a tárhely végtelen!

( bazso | 2023. 07. 29., szo – 10:08 )

SDS mint elosztott storage és sharding. Ha tudod mit akarsz tárolni, akkor arra ki lehet találni egyszerű elosztási mechanizmust (egyszerűnek kell lenni, hogy ne a számolása okozzon késést). Pl minden "a" betűs az első tárolóra, "b" a másodikra, stb. Ez alkalmazás szintű loadbalancer-ben jól kezelhető. Ezt két szintre húzva ("aa, ab") már 26x26 tároló lehet bekötve és ugye mivel 1-1 tároló is elosztott, akár 1000 körüli szerver számig kb lineárisan skálázható, így már egész kemény méretig nincs nagy varázslás. 

De pl Google módszere hogy nem halmozza a diszkeket, mert akkor egy node kiesése nagy fájdalom, olcsó kicsi szerverben 2 db lemez van, és ezekből van sok. Így a compute együtt skálázódik a storage-dzsal.

Felhasználás függő, mi az optimális alá, de manapság mindig inkább a "sok olcsó" jön be, mint a "komoly, de drága", nem véletlen szenvednek egy ideje a hagyományos vertikálisan skálázható szerver és tároló gyártók. Persze nincs ultimate mindenre is tökéletes megoldás, az elosztott esetén nagyon profi csapat kell, nagyon tesztelt automatizmusokkal, olyan korlátok modellezésével amikre nem is gondolna alapból az ember. Lásd pl: és akkor most oprendszer frissítés 2 millió szerveren. A laza 1GB fizikai átpumpálása igen finom stresszt okoz a hálózatban, miközben ugye a szolgáltatásodnak működni kell, és nem is szórhatod a pénzt hogy 2x annyi géped van, hogy az egyik fele kiszolgál, amíg a másik fele frissít. Persze mondhatod hogy nem kell 2x annyi, de akkor meg számold ki mennyi idő mire szekvenciálisan végig mész ennyi szerveren. Izgalmas terület mindenképp.

De pl Google módszere hogy nem halmozza a diszkeket, mert akkor egy node kiesése nagy fájdalom, olcsó kicsi szerverben 2 db lemez van, és ezekből van sok.

A kereső alatt ilyen volt/van.

De azóta már bőven van más szolgáltatásuk, amihez más HW-t használnak.

Erre írtam, hogy felhasználás függő, ez alól ők sem kivételek. A fix CPU/nem/disk arány ritkán optimális.

Költség optimalizált bigdata méretezésnél volt pl jó fejvakarás, hogy a 2-3 évig tartó migrációs időszakra legyen jobb (több CPU az indexeléshez és írásintenzív gyors SSD-k), vagy az azt követő évekre, amikor főleg lekérdezés van (több memória a cache miatt), vagy amikor már beállt a működés és a régi adatra kevesebb a kérés (elég lenne kevés CPU, kevés memória, és dög nagy lassú lemezek). A tiering képes SDS nagy fejfájás csökkentő tud lenni ;)

( Raynes v | 2023. 07. 29., szo – 18:25 )

Szerkesztve: 2023. 07. 29., szo – 18:54

Ahogy már írták, az elosztott rendszerek a koncepció lényege. Pont hogy nem egy webszerver szolgál ki mindent, hanem a forgalom átmegy ballancereken, amik különböző földrajzilag közeli regionális adatfarmokra küldik a kérést, és ott is több gép szolgál ki, meg elosztva, egymás között mirrorozgatva tárolják az adatot, és még az ellen is véd, ha az egyik-másik gép megfekszik, kiesik, akkor is bírja a többi, redundánsan azokon is megvan minden adat. Ha csak egy gép szolgálna ki, a nagy látogatási rohamban, főleg egy Instagram, Facebook, Google méretnél, azonnal letérdelne, abban a másodpercben, nem csak a tárhely miatt, hanem egyszerűen a hirtelen túl sok kapcsolatot nem tudná kiszolgálni, sem a webszerver, sem az adatbázis.

Ezek az elosztott rendszerek szinte a végtelenségig skálázódnak, hálózatba kapcsolt szerverek, akármennyit betehetsz, ameddig az adott adatközpont bírja árammal, hellyel, hűtéssel, nyilván nagy nemzetközi oldalaknál több adatközpont is van, nagy földrajzi területenként. Nem nehéz megcsinálni elméletben, a gyakorlatban sem olyan nagy szám szoftveresen, vannak erre kész sémák publikálva, meg tölthetők le ilyen projekthez előre beállított lemezképek, inkább csak pénzzel, erőforrással bírjad, mert ezek az adatközpontok nem olcsók, már csak az áram, netelérés része horribilis pénz, és akkor az infrastruktúra többi részét nem is néztük benne.

Kicsit úgy képzeld el, mint a RAID-et, de ez nem csak adattárolók, hanem gépek között is szét van osztva a terhelés, adattárolás. Ha van néhány géped otthon, régi laptop, asztali, SBC (RPi vagy hasonló), azokat bekapcsolhatod, bekonfigurálhatod egy hasonló rendszerben, és ki tudod próbálni ezt a koncepciót kicsiben, ilyen 2-4 géppel, nyilván saját erőforrásból tovább skálázni nem fogod tudni, de a lényegét érteni fogod. Ha nincs több géped, akkor esetleg bridge network-be kapcsolt virtuális gépek is jók erre a célra, csak legyen hozzá elég memóriád az adott gépben. Addig is a CDN-nek tudsz utána olvasni.

A torrentezés is hasonló koncepciójában, ott is több gépen van meg az adat, össze vannak kapcsolva bolyba, töltenek tőled és egymástól is, oda-vissza, a tracker meg csak közvetít, hogy rátalálj a bolyra, meg kiderítse, hogy az adott letöltött adatszelet épp kinek van meg, elossza a terhelést a seederek között.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( vasla_ | 2023. 08. 02., sze – 13:09 )

Raynes és andrej_ meg mások leírták a lényeget, de akár te is ki tudod "kicsiben" próbálni, elég 3 db  itx vagy málna pc, 32  Gb-os pc, amin vm eket futtatsz, vagy veszel 3 kisebb, olcsó  VM-et valamelyik szolgáltatónál. Egy hónapra elég rá egy  hétvégi buli ára (ha ennél komolyabb a buli: https://i.imgflip.com/15xacy.jpg :-).

CEPH -et ki tudod próbálni páldául proxmox-al. Saját k8s -sel virtruális gépeken  (microk8s stb) más volum-okkal is kíserletezhetsz (minio, mayastore, openEBS ). Google ad 1 hónap ingyenes hozzáférést GKE-hez. 

https://blog.claryel.hu

( gelei v | 2023. 08. 02., sze – 15:52 )

de ettől most tekintsünk el és a web szerver részt az egyszerűség kedvéért tekintszük 1 darabnak

Ha ezt a feladatot meg akarod oldani, akkor pont ezt a paradigmat kell eldobni, hogy van "egy" valami (amiben lehet akarhany diszk, tokmindegy), amit vertikalisan skalazol, mert az exponencialisan lesz egyre inkabb draga/bonyolult.

( vasla_ | 2023. 08. 02., sze – 16:26 )

Szerkesztve: 2023. 08. 02., sze – 16:29

Csak megerősíteni tudom gelei-t, Felállítottál egy   axiómát  ami ugyan logikusnak tűnik, de nem jó , "tekintsünk  egy darabnak az egyszerűség kedvéért " .  Itt kezdődik a hiba az kérdésedben, megoldásra várásodban.

https://blog.claryel.hu

( influencer | 2023. 08. 02., sze – 19:36 )

Úgy érzem, hogy hamarosan indul egy új magyar (nemzeti?) szolgáltatás, korlátlan tárhellyel! Lehet, hogy csak 1 szerverrel az egész mögött, ha lesz aki jól megválaszolja a kérdéseket...

Köszi az infót. Az nginx esetén a kapcsolatok száma beállítás csak azért van, hogy a hozzá nem értőket megtévessze, hogy korlátozott! :) Ha valaki adna nekem egy szervert, amiben végtelen processzor, memória, adattároló és minden egyéb erőforrás is, utána el tudnám készíteni a végtelen klienst kezelő webszervert is. Inkább ne adják ide, oda megyek, mert nincs végtelen helyem! :) Ideje lenne tájékoztatni az embereket, hogy egyszerűbb képet generálni mint feltölteni, mert napi millió számra töltik fel. Mindig tanulok itt valamit! :)

( vl v | 2023. 08. 03., cs – 00:11 )

Bocs, ez Linux kezdő, nem Linux haladó.

A webszerverhez tartozik egy public mappa, docroot, ahonnan ezeket a tartalmakat ki tudja szolgálni.

Hát, erre ne vegyél mérget.

Olyat is tudnak ám a webszerverek, hogy a beérkező kérést az URL-től függően más-más gépekre továbbítják, a választ meg visszaküldik az eredeti kérdezőnek. Google: reverse proxy

Ergó akár az egész világ összes webszerverének tartalma is lehetne egyetlen webszerver mögé bepakolva, úgy, hogy ezen egyetlen webszerveren konkrétan semmi sincs, ő csak azt tudja, hogy hová kell továbbítani a kéréseket. Te meg kívülről azt látod, hogy mennyi minden van azon a webszerveren.