DFS-replikering over ein VPN: låsing er ikkje det du får

Sambandet er kryptert, alltid på og raskt nok, så den delte mappa bør oppføre seg som éi mappe på begge lokalitetane. Det er føresetnaden bak dei fleste DFS-replikeringsdesigna som overraskar folk seinare. DFSR er multi-master og asynkron: kvar replika held greie på versjonar uavhengig, og ingenting i protokollen held ei lås på tvers av servarar. VPN-en ber trafikken mellom dei og legg ikkje til noko av koordineringa som føresetnaden krev. Planlegg skrivemønsteret og kapasitetsmodellen, elles blir den første verkelege konflikten ei støttesak.

Myten: eit VPN gjer replikaene til eitt filsystem

Ein tunnel er transport. Han gjev deg ein tillaten veg mellom to servarar og skjuler hoppa imellom. Han seier ingenting om kven som får redigere ei fil, i kva rekkjefølgje versjonar kjem, eller kva som skjer når to redigeringar konkurrerer.

Kryptering og tilgjenge er eigenskapar ved sambandet; konsistens er ein eigenskap ved replikeringsmotoren og ved arbeidsflyten din.

Kva DFSR faktisk replikerer

Kvar servar held si eiga kopi og sine eigne versjonsmetadata. Endringar spreier seg når sambandet og tidsplanen tillèt det, og motoren brukar fjern-differensiell komprimering for å sende berre dei delane av ei fil som er endra. Når to replikaer endrar same fila før nokon av oppdateringane kjem, vinn éin versjon, og den andre blir flytta til sida som ein konfliktkopi. Ingen servar blokkerte den andre redigeringa, fordi blokkering ville krevje den distribuerte låsa som DFSR ikkje tilbyr.

Ein namneromssti gjer kopiane enkle å nå, og han gjer dei ikkje samanhengande.

Staging-plass er arbeidskapasitet, ikkje backup

Staging er arbeidsområdet replikering brukar medan ho set saman endringar. Rettleiinga frå Microsoft for storleik brukar den samla storleiken av dei 32 største filene i den replikerte mappa som minimum, og ekstra plass er nyttig under den første replikeringa. Eit tre med små dokument og ei mappe med fleire store arkiv treng derfor ulike staging-former. Når staging går tom, stoppar replikeringa på måtar som ser ut som ein nettverksfeil. Dimensjoner henne ut frå dataa, og hald fram med å følgje med når dataa endrar seg.

Staging er ikkje ein backup, og å spreie endringar er ikkje ein versjonshistorikk.

Førehandsutfylling er ein optimalisering, ikkje ein snareveg

For eit stort eksisterande tre kan støtta førehandsutfylling med Robocopy redusere det som må over sambandet under den første synkroniseringa, og rettleiinga frå Microsoft dekkjer bevaring av filinformasjon og handtering av låste eller overhoppa filer. Det er ein optimalisering, ikkje eit løfte om at målet alt er riktig, så den første replikeringa må framleis fullførast og verifiserast. Å hoppe over den verifiseringa er korleis ein lokalitet endar med å levere filer som aldri var i det replikerte settet.

Verifiser starttilstanden før brukarane avheng av målet, ikkje etter den første klaga.

Vel vindauget og definer kva aktuell tyder

Replikeringsplan og bandbreiddestyring avgjer når partane får utveksle data. Eit smalt vindauge etter arbeidstid er eit legitimt design som lèt etter ein etterslep i løpet av dagen, føresett at alle er samde om at fjernkopien berre må vere aktuell om morgonen.

Skriv den setninga ned, fordi «etterslepet er førti minutt» er berre alarmerande om ingen har definert målet.

Aksepter med arbeidsflyten, ikkje med éi fil

Test med filene folk faktisk brukar: eit stort dokument, ei rutinemessig redigering, ei sletting og ei medviten samtidig redigering på begge lokalitetane. Stadfest at konfliktåtferda samsvarar med det du fortalde verksemda, og at gjenopprettingsvegen frå backup er skild frå replikaene. Følg deretter med på endringsvolum, køvekst og staging-plass mot tenestevindauget i nokre veker. VPN-kapasitet er éi avgrensing blant fleire, og det er sjeldan den første du når.

Eit design som dokumenterer forseinkinga og redigeringsreglane sine, er langt lettare å støtte enn eitt som lovar identiske kopiar.