DFS-replikering over en VPN: låsing er ikke det du får

Forbindelsen er kryptert, alltid på og rask nok, så den delte mappen bør oppføre seg som én mappe på begge lokaliteter. Det er antakelsen bak de fleste DFS-replikeringsdesignene som overrasker folk senere. DFSR er multi-master og asynkron: hver replika holder rede på versjoner uavhengig, og ingenting i protokollen holder en lås på tvers av servere. VPN-en bærer trafikken mellom dem og legger ikke til noe av koordineringen som antakelsen krever. Planlegg skrivemønsteret og kapasitetsmodellen, ellers blir den første virkelige konflikten en støttesak.

Myten: en VPN gjør replikaene til ett filsystem

En tunnel er transport. Den gir deg en tillatt vei mellom to servere og skjuler hoppene imellom. Den sier ingenting om hvem som får redigere en fil, i hvilken rekkefølge versjoner ankommer, eller hva som skjer når to redigeringer konkurrerer.

Kryptering og tilgjengelighet er egenskaper ved forbindelsen; konsistens er en egenskap ved replikeringsmotoren og ved arbeidsflyten din.

Hva DFSR faktisk replikerer

Hver server holder sin egen kopi og sine egne versjonsmetadata. Endringer spres når forbindelsen og tidsplanen tillater det, og motoren bruker fjern-differensiell komprimering for å sende bare de delene av en fil som er endret. Når to replikaer endrer samme fil før noen av oppdateringene ankommer, vinner én versjon, og den andre flyttes til side som en konfliktkopi. Ingen server blokkerte den andre redigeringen, fordi blokkering ville kreve den distribuerte låsen som DFSR ikke tilbyr.

En navneområdesti gjør kopiene enkle å nå, og den gjør dem ikke sammenhengende.

Staging-plass er arbeidskapasitet, ikke backup

Staging er arbeidsområdet replikering bruker mens den setter sammen endringer. Microsofts dimensjoneringsveiledning bruker den samlede størrelsen av de 32 største filene i den replikerte mappen som minimum, og ekstra plass er nyttig under den første replikeringen. Et tre med små dokumenter og en mappe med flere store arkiver trenger derfor forskjellige staging-former. Når staging går tom, stopper replikeringen på måter som ser ut som en nettverksfeil. Dimensjoner den ut fra dataene, og fortsett å følge med når dataene endres.

Staging er ikke en backup, og å spre endringer er ikke en versjonshistorikk.

Forhåndsfylling er en optimalisering, ikke en snarvei

For et stort eksisterende tre kan støttet forhåndsfylling med Robocopy redusere det som må over forbindelsen under den første synkroniseringen, og Microsofts veiledning dekker bevaring av filinformasjon og håndtering av låste eller overhoppede filer. Det er en optimalisering, ikke et løfte om at målet allerede er riktig, så den første replikeringen må fortsatt fullføres og verifiseres. Å hoppe over den verifiseringen er hvordan en lokalitet ender med å levere filer som aldri var i det replikerte settet.

Verifiser starttilstanden før brukerne avhenger av målet, ikke etter den første klagen.

Velg vinduet og definer hva aktuell betyr

Replikeringsplan og båndbreddekontroll bestemmer når partnerne får utveksle data. Et smalt vindu etter arbeidstid er et legitimt design som etterlater en etterslep i løpet av dagen, forutsatt at alle er enige om at fjernkopien bare må være aktuell om morgenen.

Skriv den setningen ned, fordi «etterslepet er førti minutter» er bare alarmerende hvis ingen har definert målet.

Aksepter med arbeidsflyten, ikke med én fil

Test med filene folk faktisk bruker: et stort dokument, en rutinemessig redigering, en sletting og en bevisst samtidig redigering på begge lokaliteter. Bekreft at konfliktatferden samsvarer med det du fortalte forretningen, og at gjenopprettingsveien fra backup er atskilt fra replikaene. Følg deretter med på endringsvolum, køvekst og staging-rom mot tjenestevinduet i noen uker. VPN-kapasitet er én begrensning blant flere, og det er sjelden den første du når.

Et design som dokumenterer forsinkelsen og redigeringsreglene sine, er langt lettere å støtte enn ett som lover identiske kopier.