DFS-replikering över ett VPN: låsning är inte vad du får

Länken är krypterad, alltid på och snabb nog, så den delade mappen borde bete sig som en mapp på båda platserna. Det är antagandet bakom de flesta DFS-replikeringsdesigner som överraskar folk senare. DFSR är multi-master och asynkron: varje replik håller reda på versioner självständigt, och inget i protokollet håller ett lås mellan servrar. VPN:et bär trafiken mellan dem och lägger inte till något av den samordning som antagandet kräver. Planera skrivmönstret och kapacitetsmodellen, annars blir den första verkliga konflikten ett supportärende.

Myten: ett VPN gör replikerna till ett filsystem

En tunnel är transport. Den ger dig en tillåten väg mellan två servrar och döljer hoppen däremellan. Den säger ingenting om vem som får redigera en fil, i vilken ordning versioner anländer eller vad som händer när två redigeringar tävlar.

Kryptering och tillgänglighet är egenskaper hos länken; konsistens är en egenskap hos replikeringsmotorn och hos ditt arbetsflöde.

Vad DFSR faktiskt replikerar

Varje server håller sin egen kopia och sina egna versionsmetadata. Ändringar sprids när anslutningen och schemat tillåter det, och motorn använder fjärrdifferentiell komprimering för att bara skicka de delar av en fil som ändrats. När två repliker ändrar samma fil innan någon av uppdateringarna anländer vinner en version och den andra flyttas åt sidan som en konfliktkopia. Ingen server blockerade den andra redigeringen, eftersom blockering skulle kräva det distribuerade lås som DFSR inte erbjuder.

En namnrymdsväg gör kopiorna lätta att nå, och den gör dem inte sammanhängande.

Staging-utrymme är arbetskapacitet, inte backup

Staging är arbetsområdet replikeringen använder medan den sätter ihop ändringar. Microsofts dimensioneringsvägledning använder den sammanlagda storleken av de 32 största filerna i den replikerade mappen som minimum, och extra utrymme är användbart under den första replikeringen. Ett träd med små dokument och en mapp med flera stora arkiv behöver därför olika staging-former. När staging tar slut stannar replikeringen på sätt som ser ut som ett nätverksfel. Dimensionera det utifrån data och fortsätt att följa det när data ändras.

Staging är inte en backup, och att sprida ändringar är inte en versionshistorik.

Förhandsfyllning är en optimering, inte en genväg

För ett stort befintligt träd kan stödd förhandsfyllning med Robocopy minska det som måste över länken under den första synkroniseringen, och Microsofts vägledning täcker bevarande av filinformation och hantering av låsta eller överhoppade filer. Det är en optimering, inte ett löfte om att målet redan är korrekt, så den första replikeringen måste ändå slutföras och verifieras. Att hoppa över den verifieringen är hur en plats börjar leverera filer som aldrig var i den replikerade uppsättningen.

Verifiera utgångsläget innan användarna förlitar sig på målet, inte efter det första klagomålet.

Välj fönstret och definiera vad aktuell betyder

Replikeringsschema och bandbreddskontroller avgör när parterna får utbyta data. Ett smalt fönster efter arbetstid är en legitim design som lämnar en eftersläpning under dagen, förutsatt att alla har enats om att fjärrkopian bara behöver vara aktuell till morgonen.

Skriv ner den meningen, för ”eftersläpningen är fyrtio minuter” är bara alarmerande om ingen har definierat målet.

Acceptera med arbetsflödet, inte med en enda fil

Testa med de filer folk faktiskt använder: ett stort dokument, en rutinredigering, en borttagning och en avsiktlig samtidig redigering på båda platserna. Bekräfta att konfliktbeteendet stämmer med det du sa till verksamheten och att återställningsvägen från backup är skild från replikerna. Följ sedan ändringsvolymen, kötillväxten och stagingutrymmet mot servicefönstret i några veckor. VPN-kapacitet är en begränsning bland flera, och det är sällan den första du når.

En design som dokumenterar sin fördröjning och sina redigeringsregler är mycket lättare att supporta än en som lovar identiska kopior.