DFS-ripetado trans VPN: ŝlosado ne estas tio, kion vi ricevas

La ligilo estas ĉifrita, ĉiam ŝaltita kaj sufiĉe rapida, do la kunhavigita dosierujo devus konduti kiel unu dosierujo ĉe ambaŭ ejoj. Tio estas la supozo malantaŭ la plej multaj DFS-ripetadaj projektoj, kiuj surprizas homojn poste. DFSR estas pluraj-majstra kaj malsinkrona: ĉiu kopio memstare spuras versiojn, kaj nenio en la protokolo tenas ŝloson trans serviloj. La VPN portas la trafikon inter ili kaj aldonas neniom el la kunordigo, kiun tiu supozo bezonas. Planu la skriban ŝablonon kaj la kapacitan modelon, alie la unua vera konflikto fariĝas subtena okazaĵo.

La mito: VPN igas la kopiojn unu dosiersistemo

Tunelo estas transporto. Ĝi donas al vi permesitan vojon inter du serviloj kaj kaŝas la saltojn intere. Ĝi diras nenion pri tio, kiu rajtas redakti dosieron, laŭ kiu ordo versioj alvenas, aŭ kio okazas, kiam du redaktoj konkuradas.

Ĉifrado kaj disponebleco estas ecoj de la ligilo; konsistenco estas eco de la ripetada motoro kaj de via laborfluo.

Kion DFSR fakte ripetas

Ĉiu servilo tenas sian propran kopion kaj siajn proprajn versiajn metadatumojn. Ŝanĝoj disvastiĝas kiam la konekto kaj la horaro permesas, kaj la motoro uzas malproksiman diferencan kunpremadon por sendi nur la partojn de dosiero, kiuj ŝanĝiĝis. Kiam du kopioj ŝanĝas la saman dosieron antaŭ ol alvenas iu ajn ĝisdatigo, unu versio venkas kaj la alia estas movita flanken kiel konflikta kopio. Neniu servilo blokis la duan redakton, ĉar blokado postulus la distribuitan ŝloson, kiun DFSR ne ofertas.

Nomspaca vojo faras la kopiojn facile atingeblaj, kaj ĝi ne faras ilin koheraj.

Stagada spaco estas labora kapacito, ne rezerva kopio

Stagado estas la provizora areo, kiun ripetado uzas dum ĝi kunmetas ŝanĝojn. La gvidlinio de Microsoft pri grandeco prenas la komunan grandecon de la 32 plej grandaj dosieroj en la ripetata dosierujo kiel minimumon, kaj plia spaco utilas dum la komenca ripetado. Arbo de etaj dokumentoj kaj dosierujo kun pluraj grandaj arkivoj do bezonas malsamajn stagadajn formojn. Kiam stagado elĉerpiĝas, ripetado haltas tiel, ke ĝi aspektas kiel reta paneo. Grandumu ĝin laŭ la datumoj, poste daŭre observu dum la datumoj ŝanĝiĝas.

Stagado ne estas rezerva kopio, kaj disvastigi ŝanĝojn ne estas versia historio.

Antaŭsemo estas optimumigo, ne fuĝvojo

Por granda ekzistanta arbo, subtenata antaŭsemo per Robocopy povas malgrandigi tion, kio devas transiri la ligilon dum la komenca sinkronigo, kaj la gvidlinio de Microsoft kovras konservadon de dosieraj informoj kaj traktadon de ŝlositaj aŭ preterlasitaj dosieroj. Ĝi estas optimumigo, ne promeso, ke la celo jam ĝustas, do la komenca ripetado ankoraŭ devas finiĝi kaj esti kontrolita. Preterlasi tiun kontrolon estas kiel ejo finas servantajn dosierojn, kiuj neniam estis en la ripetata aro.

Kontrolu la komencan staton antaŭ ol uzantoj fidas la celon, ne post la unua plendo.

Elektu la fenestron kaj difinu, kion signifas aktuala

La ripetada horaro kaj bendlarĝaj limigoj decidas, kiam la partneroj rajtas interŝanĝi datumojn. Mallarĝa fenestro post labortempo estas legitima projekto, kiu lasas postrestaĵon dum la tago, kondiĉe ke ĉiuj konsentis, ke la malproksima kopio nur devas esti aktuala matene.

Skribu tiun frazon, ĉar „la postrestaĵo estas kvardek minutoj“ maltrankviligas nur se neniu difinis la celon.

Akceptu kun la laborfluo, ne kun unu dosiero

Testu per la dosieroj, kiujn homoj vere uzas: granda dokumento, rutina redakto, forigo kaj intenca samtempa redakto ĉe ambaŭ ejoj. Konfirmu, ke la konflikta konduto kongruas kun tio, kion vi diris al la entrepreno, kaj ke la reakira vojo el rezerva kopio estas aparta de la kopioj. Poste observu ŝanĝan volumon, atendovican kreskon kaj stagadan rezervon kontraŭ la serva fenestro dum kelkaj semajnoj. VPN-kapacito estas unu limo inter pluraj, kaj ĝi malofte estas la unua, kiun vi atingas.

Projekto, kiu dokumentas sian prokraston kaj siajn redaktajn regulojn, estas multe pli facile subtenebla ol unu, kiu promesas identajn kopiojn.