Realtime redundáns adattárolás több telephelyen

Hálózatok egyéb

Sziasztok!

A következőre keresek valami professzinális megoldást.
Több telephelyes cég, ~10TB adattal.
Az összeköttetés jelenleg ~20MBit/s bérelt vonalon VPN-nel valósul meg.

Az probléma az, hogy sok felmappolt hálózati megosztás van a WAN/VPN linken keresztül, ami ekkora adatmennyiségnél már kezd nem okosnak
tűnni.
Pl van olyan drive, ami több ezer project folder-t (+ alattuk lévő szerkezet) tartalmaz, amit ugye mind feleslegesen le kell kérdezgetni, minden egyes olyan műveletnél, ahol ez szükséges. (a desktop-ok túlnyomó többsége Windows)
Gondoljatok csak arra, hogy pl ha egy win gépbe beraktok egy CD-t, akkor mennyiszer pörgeti fel munka során, csak hogy megnézze. Kb minden egyes file browse-olási ablaknál/műveletnél, amikor végül baromira nem is a CD-ről nyitsz meg bármit is.

Egyáltalán. ~100 fő dolgozik, párhuzamosan, nagy adatmennyiséggel WAN/VPN linken keresztül = NEM MENŐ

Olyan megoldást keresnék, ahol az adatokat a külföldi is a helyi telephelyen is tárolnánk és azok valahogy hardverből/szoftverből/tudomisén szinkronizálódnak, _de kizárólag akkor, amikor valami változik_
Nem suffni-tunning robocopy/rsync ide-oda megoldást keresek, hanem valami direkt erre a célra kitalát fizikailag több helyre telepíthető storage megoldást.

Valakinek tapasztalata ilyennel nagypályán?

  • 1943 megtekintés

( gbor | 2010. 11. 20., szo – 11:30 )

"feliratkozás" - de görcsösen hangzik magyarul :D

( _ventura_ v | 2010. 11. 20., szo – 11:33 )

AFS/OpenAFS ?

Ubuntu 10.04, Thinkpad x60s

( mrceeka v | 2010. 11. 20., szo – 12:23 )

Hello,

szerintem legkézenfekvőbb megoldás a BranchCache, ami a legkorszerűbb mód az ilyen jellegű problémák kezelésére. Mivel cache, ezért nem szükséges a tartalom replikációjával foglalkozni és nincsenek ütközési problémák sem.
Szóba jöhet DFS-R alkalmazása is és megfontolható a tárolt információk okosabb struktúrába szervezése (pl. archív folderek kialakításával). Ez utóbbi azonban a konkrét alkalmazás/felhasználási mód ismeretét és esetleges módosítását is igényelheti.

Üdv,
mrceeka

Igaz. Konkurrens írásra valóban problémákat gyártasz vele.
De ha vannak gyakran használt readonly mappáid (pl. megosztott installkit stb.), azokat leküldheted DFS-R-rel.
Egyetértek, hogy a BranchCache az, ami leginkább erre van kitalálva, de ennyi adat esetén lehet, hogy érdemes különbséget tenni adat és adat, kezelési mód és kezelési mód között.

Üdv,
mrceeka

( STP | 2010. 11. 20., szo – 14:22 )

TerminalServer

kikényszerített policy
egységes, központi mentés
olcsó kliensek.
központi frissítés

bár legalább ennyi ellenpontot is lehetne mondani :)

Valamiert ezek a terminalos megoldasok soha nem terjedtek el igazan, legalabbis a kornyezetemben nem igazan, pediga ahogy latom, a legtobb helyre eleg lenne ez. Foleg a konyvtarakat nem ertem, miert nem hasznalnak vekonyklienseket...

--
Dropbox:
https://www.getdropbox.com/referrals/NTI3NzY1ODQ5

Bár a jelen környezet komoly átdolgozását igényelheti, de valóban szóbajöhető választás.
Habár én nem Remote Desktop Servicesben gondolkodnék, hanem mérnöki alkalmazásnál inkább VDI-ban.
Ami azonban kérdés, hogy a megfelelő-e az átvihető grafikai teljesítmény illetve az adott alkalmazás felkészült-e erre.

Üdv,
mrceeka

( Mico v | 2010. 11. 20., szo – 18:37 )

"Nem suffni-tunning robocopy/rsync ide-oda megoldást keresek, hanem valami direkt erre a célra kitalát fizikailag több helyre telepíthető storage megoldást."

A "hardveres" cuccok nem jók ide, a storage replikáció ált. nem arra való, hogy több helyről dolgozzanak rajta felmountolva. NAS cuccok replikációját is inkább DR céllal találták ki és nem arra, hogy van 10 telephelyed amik összevissza replikálnak egymásra.

Gyári megoldások közül ehhez a DFS áll legközelebb. De lehet, hogy kéne tenni egy lépést hátrafelé, és eldöntnei, hogy az összes telephely a központi tárolóra/ról dolgozik, vagy alapvetően a telephely a saját adataival dolgozik, és akkor a dolog átalakul egy space management kérdéssé..