Ket adatkozpont osszeszinronizalasa WAN-on

Merevlemezek, vezérlők

Nem tudom jo helyre irok-e, valami olyan megoldas erdekelne, ami ket adatkozpontot osszeszinkronizal, WAN-on keresztul. (tehat legyen adattomorites, esetlegy fajloknal csak a kulonbozo biteket cserelje, mint egy snapshot eseteben, stb...)

Szoval valami komondott olyan megoldas erdekel (hardveres vagy szoftveres) amit arra talaltak ki, hogy ket tavoli adatkozpontot osszeszinkronizaljon.

  • 1972 megtekintés

( bazso | 2017. 05. 10., sze – 17:15 )

Ha üres az adatközpontod akkor pakolj ki a másikból is és máris szinkronban vannak :D

Viccet félre téve a kérdésed nem tartalmaz semmilyen adatot ami alapján választ kaphatnál.
Milyen tecnikán tárolod az adatot? Mire akarod használni a szinkront?

( AiRLAC v | 2017. 05. 10., sze – 17:44 )

Két Riverbed Steelhead, két NetApp A700s meg némi switch és kábelezés :)

(ez így kevés, több részlet kellene)
--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

Ezeknek utana neztem, jol hangzik! Foleg hogy Netapp mar van is :)

A Riverbed Steelhead megoldasat nem ismertem, hansznos info!

Tobb reszletet is irtam lenn. igazabol a storage replikacio lesz szerintem a jarhato ut, erdekelne, hogy ez teljesen gyarto specifikus, esetleg letezik valami egyseges szabvany, ami tobb, eltero gyarto eszkozen is megvalosithato?

( STP | 2017. 05. 10., sze – 18:03 )

Define adatközpont
Define összeszinkronizálni
Define adatforrás
Define szinkronizálási stratégia
Define tervezett adatmennyiség
stb, stb

( wpeople v | 2017. 05. 10., sze – 18:43 )

drbd over openvpn :-)
tömörítés van (ha nem mikrotik implementációt használ)
de (L2)VPN-en keresztül mondjuk Synology NAS-ok is sync-ben tarthatók (bár az is drbd-vel csinálja)

( Vamp | 2017. 05. 10., sze – 19:43 )

Akkor reszletesebben:

Adott egy nemet adatkozpont, Ami fol van csatolva nevezzuk "U meghajto"-kent, Network Storage-kent Citrix Xendesktopokra. Ezzel nincs is baj, ha Citrix desktopot hasznalnak a Userek, akkor az adat "marad" nemetben, de lehetoseguk van arra is, hogy vastagkliensen elerjek az U meghajtot.

Jelenleg ugye, ha pl egy nagyobb meretu fajlt fol akarnak masolni az U meghajtora, az ido... De ha lenne egy szinkronizalt adatkozpont, akkor a magyar felhasznaloknak az lenne folcsatolva, gyorsan folmenne a cucc, (persze ettol meg a nemet oldalon nem kapjak meg hamarabb az adatokat, csak a szinkron vege utan, de ez most irrelevans, a cel az, hogy a magyar user szamara a masolas csak par pillanat legyen)

A szinkronizalast ugy kepzelnem, hogy azonnali legyen, nyilvan savszel fuggvenyeben, Lehetoleg legyen valamifele tomorites is, illetve, ahogy mar irtam, valamifele olyan megoldas lenne jo, ami kepes felismerni a fajlok kozotti kulonbseget es csak ezt kuldi at.

A halozat: IPVPN, Valamint QNAP NAS-ok (jelenleg, de kesobb ez valtozhat)

Ehh megint a pongyola fogalmazasom :)

"Adatkozpont" alatt az ertem, hogy van egy data storage (egy Netapp ) Nemetorszagban (az anyavallalatnal), ezen van most az adat, amit vastagkliensel WAN-on ernek el, illetve vekonykliensel nyilvan localba.

Arra kell a megoldas, hogy mikepp lehet ugy "tukrozni" a nemet adatot magyarorszagra, hogy a magyarok a magyar storage-et, a nemetek pedig a nemetet hasznaljak, koztuk pedig ne csak fajl szintu szinkron legyen, hanem kvazi egy meghajtonak latszodjanak. (tehat ne legyen feluliras, adatvesztes, stb...)

A Dropbox nem szegi meg a fizika szabalyait mert nem osztott meghajtot ad. Nincs lockolas, nincs garancia arra hogy nem lesz conflict, hanem ha utkozes van, felteszi a kezet es rabizza a userre a problema megoldasat. Ezzel szemben Te egy olyan megosztott meghajtot szeretnel a jelek szerint, ami ugyanugy mukodik mint mondjuk egy Samba share, tehat ha szerkesztesz egy filet, az mas nem tudja, vagy akar kollaborativ szerkesztes is megy, illetve meg raadasul gyors is legyen. Ez egy nagyon komoly kulonbseg, mivel a Te esetedben az irasnak mindenhova szinkronizalni kell mielott megkapod a visszaigazolast, ami a sebesseg karara megy, illetve lehetetlenne teszi az irast ha szetszakad a ket vegpont.

--
Pásztor János
Sole Proprietor @ Opsbears | Refactor Zone

Ez esetben ne akard megoldani mert csúnya nagy adatvesztés lesz a vége. Ugyanazon user meg tudja nyitni írásra a német példányt a citrixben és a magyar példányt a vastag kliensen.
Ha szinkron a replika, lassabb lesz mint direktben a német példány.
Ha aszinkron a replika, akkor lesz egy forkolt példány a fájlból és manuális lesz a dolog mert automatán nem lehet csak verziókezelő által feloldható fájltípus esetén.

Erre a működési módra az afs elosztott fájlrendszert találták ki, de az valamiért megragadt egyetemi körökben, általános célra vannak komoly hiányosságai.

Az a baj, hogy ha itt a work driverol beszélünk, akkor mindenki össze vissza akar majd keresztbe kasul dolgozni párhuzamosan, és abból káosz lészen. Erre így sima fs nrm lesz jó szerintem, be kell tolni valamibe ami ezt kezeli, legyen az egy git vagy rgy sharepoint. Esetleg megkerdezni citrixéket...

Az pl nem megoldhato, hogy "A" helyen megnyit valaki egy fajlt, erre kvazi azt "lefoglalja" mindket helyen?

Sima network share-nel ha en megnyitok egy file-t akkor te addig nem menthetsz ra, amig nalam nyitva van. Nem lehetseges, hogy a ket storage valahogy lekommunikalja azt, hogy ez a file most meg van nyitva "vedett". Csak akkor oldodik fel mindket oldalon es lesz ujra irhato is, ha nincs nyitva sehol es a szinkron is vegbement.

Sima sharenél is kérdéses, inkább a program (pl world) oldja meg maga a lockot. Egyébként de, megoldani nyilván mindent meg lehet. Viszont kicsit gondolkodj, mi is történik. Pl megnyitok egy sima text filet, a szerkesztő felolvassa, én matatok benne lokálisan, majd nyomok egy ctrl+s-t. Honnan tudja az fs, hogy a köztes időben lockolni kell? Vagy mikor mentek dobja vissza, hogy azóta változott? Mit csinál, dob egy hibát, hogy nem lehet írni (azzal mást nem nagyon tud tenni). Mit fog ekkor csinálni a program? Többnyire feldob egy save-as ablakot.

Persze, olyat lehet, hogy amíg sync van, addig íráshibát dobálunk mindkét oldalon (a fenti nem túl fényes usability feedbackkel), aztán reménykedünk erőst, hogy barátunk nem ment egy lokális kopit, és másolja fel, ha elmúlt. (Hogy félúton mit csinál mondjuk a world auto save funkciójával, azt meg végig se nagyon akarom gondolni)

Szóval az van, hogy itt szerintem annyira sok lehetőség van, ahol a usernek érteni kell, hogy mi történik, hogy sokkal jobb, ha explicit elmegy hozzá a tranzakció kezelése valami célprogram formájában. Természetesen ha kiderül, hogy pontosan milyen fileok, meg milyen progi, akkor lehet, hogy arra pont van valami, de generikusan szerintem ez nettó önszopatás lesz, akármit is csinálsz. Tényleg az van, hogy legyen magyar share meg német share, ami csak helyben rw. (Aztán hogy ott mekkora szopás lesz az ide oda pinponggal, az más kérdés. Na ezért mondtam, hogy a fizikán kéne segíteni, hogy ugyanolyan gyorsan menjen mindenhova, különben valahol meg kell várni a syncet.

mindenkinek ott van a home-ja ahol többet dolgozik, a másik oldalon pedig read-only replika. A közös share-en pedig kompromisszum, valakinek lassú lesz akárhova is teszed.
Anno próbáltam hasonlót megoldani több telephely között időszakosan vándorló dolgozókkal, mindig az afs jött elő mint egyetlen olyan megoldás ami viszi utánad az adatot felhasználási gyakoriság alapján, de globálisan figyel a lock-okra. Ez pedig más ok miatt volt használhatatlan, így maradt a kompromisszumos megoldás.

( janoszen v | 2017. 05. 11., cs – 09:49 )

Esetleg erdemes megnezni a GlusterFS-t. Sokat kell tekergetni, foleg ha sok kis fajlod van, de tud mindenfele erdekes es izgalmas setupot tobb DC-re.

--
Pásztor János
Sole Proprietor @ Opsbears | Refactor Zone

( kisg v | 2017. 05. 11., cs – 12:35 )

Én azt javaslom neked, hogy mielőtt a technikai megoldáson kezdesz gondolkodni, kezdd el mérni nagyon részletesen, hogy melyik fájlokat ki mikor használja, és szükség van-e arra, hogy a fájlok mindkét helyről írhatóak legyenek. Gondolom a netapp tud részletes file access logokat, azokat ki kell elemezni (ha most nincsenek bekapcsolva, akkor legalább 1-2 hétig gyűljön az adat).

Ez a közös fájlshare-re dolgozunk megoldás szerintem mindenképpen problémás, különösen, ha ugyanazokat a fájlokat szerkesztik mindkét helyről. Ha ténylegesen dokumentumkezelésről van szó, akkor én inkább valamilyen dokumentumkezelő rendszeren kezdenék el gondolkodni, aminek van MultiSite megoldása ahelyett, hogy sokkal alacsonyabb szinten próbálsz replikálni és fenntartani nem hatékony / nem megbízható folyamatokat. Egy dokumentumkezelőben pl. verziózás, jogosultságok, workflowk sokkal jobban megoldhatók, mint egy file share-en, függetlenül a file share alatt futó (adott esetben nagyon drága) technológiától.

Gondolom a netapp tud részletes file access logokat

a netapp egy enterprise storage cucc: van benne (jo esetben 2+) kontroller, meg egy csomo shelf telepakolva diszkekkel. A licence-tol fuggoen tud kiajanlani a diszkeket iscsi-t (sok sikert file access logokhoz) vagy pl. nfs-en. Gyakori kombo a vmware + netapp, amely esetben az nfs konyvtarakban vmdk es hasonlo file-ok lesznek (ebben az esetben sem sanszos a file szintu loggolas), de ha emberunk mondjuk a /home konyvtarat veszi nfs-rol, akkor sem valoszinu, hogy netapp szinten lesz naplozva az egyes file-ok elerese. De ha mondjuk cifs-en eri el egy vindoze a file-okat, meg akkor sem fogadnek erre nagyobb osszeggel...

Szerintem értsd jól :)
Valahol be lehet kapcsolni a logolást, aztán - részben - ez alapján kiderül hogy valójában mekkora is a probléma. Mert simán lehet, hogy a júzerek 2%-ának okoz átlagosan heti 10 perc várakozást, ami kb. lófasz kategória ahhoz az anyagi és emberi befektetéshez képest, amibe ennek a megoldása kerülne. Értsd: még ha sikerülne is elkerülni a több helyen is felvetett buktatókat, akkor se térülne meg 100 év alatt se.

Amit leírtál itt, annyit én is értek a Netapp-hoz (ami ha jól értem nem is egy termék, hanem egy cég, aminek van csillió terméke, de most ezt hagyjuk...:) )

Viszont totál meglepne, ha a "Netapp" nem tudna CIFS-t natívan, és tényleg, a Google segített: https://www.netapp.com/us/solutions/a-z/nas-file-services.aspx

Az rémlett, hogy azt írta fentebb a kolléga, hogy a "Netapp"-ról jön a CIFS share, én balgán ezt úgy vettem, hogy tényleg onnan jön pl. a fenti megoldással. Namost ez esetben a csoda "enterspájz" storage miért is nem fog nekem file access logokat adni? Ha meg nem így van, hanem közben van még X réteg, akkor meg az van, amit xclusiv írt.

Én kérek elnézést.

Nem világosak a követelmények, de egy Microsoft DFS nem tűnik akkor nagy kalandnak, főleg ha a cég áldozni is hajlandó. Lehet, hogy egyszerűbb bevezetni, aztán kiderül, aminek ki kell derülnie, mint ki tudja meddig elemezni (ami egyrészt szintén nincs ingyen, másrészt az idő addig is megy).
Kellékek:
- két szerver (vagy virtuális gép) a két telephelyen
- 2x Windows licenc (még az is lehet, hogy van)
- 2-3 nap alatt sok mindent el lehet olvasni és be lehet konfigurálni
Nem esélytelen, hogy bármekkora is a megfeszülés, pontos követelmények nem fognak kiderülni.

Vagy lehet játszani a Linuxos elosztott fájlrendszer megoldásokkal, de ott a Samba +1 kihívás.