Replikace DFS přes VPN: zámek není to, co dostanete

Spojení je šifrované, stále zapnuté a dost rychlé, takže sdílená složka by se měla chovat jako jedna složka na obou lokalitách. To je předpoklad, na kterém stojí většina návrhů replikace DFS, které lidi později překvapí. DFSR je multi-master a asynchronní: každá replika sleduje verze nezávisle a nic v protokolu nedrží zámek mezi servery. VPN přenáší provoz mezi nimi a nepřidává nic z koordinace, kterou tento předpoklad potřebuje. Naplánujte vzorec zápisu a kapacitní model, jinak se první skutečný konflikt stane incidentem podpory.

Mýtus: VPN udělá z replik jeden souborový systém

Tunel je transport. Dá vám povolenou cestu mezi dvěma servery a skryje skoky mezi nimi. Neříká nic o tom, kdo smí soubor upravovat, v jakém pořadí verze přicházejí ani co se stane, když se dvě úpravy střetnou.

Šifrování a dostupnost jsou vlastnosti spoje; konzistence je vlastnost replikačního jádra a vašeho pracovního postupu.

Co DFSR skutečně replikuje

Každý server si drží vlastní kopii a vlastní metadata verzí. Změny se šíří, když to spojení a plán dovolí, a jádro používá vzdálenou diferenciální kompresi, aby posílalo jen změněné části souboru. Když dvě repliky změní stejný soubor dřív, než dorazí kterákoli aktualizace, jedna verze vyhraje a druhá se odloží stranou jako konfliktní kopie. Žádný server druhou úpravu nezablokoval, protože blokování by vyžadovalo distribuovaný zámek, který DFSR neposkytuje.

Cesta v oboru názvů dělá kopie snadno dostupnými, ale nečiní je souladnými.

Staging prostor je pracovní kapacita, ne záloha

Staging je odkládací oblast, kterou replikace používá, když skládá změny. Pokyny Microsoftu k dimenzování berou souhrnnou velikost 32 největších souborů v replikované složce jako minimum, přičemž místo navíc se hodí při počáteční replikaci. Strom drobných dokumentů a složka s několika velkými archivy proto potřebují různé tvary stagingu. Když staging dojde, replikace se zastaví způsobem, který vypadá jako síťová závada. Dimenzujte ho podle dat a dál ho sledujte, jak se data mění.

Staging není záloha a šíření změn není historie verzí.

Předplnění je optimalizace, ne zkratka

U velkého existujícího stromu může podporované předplnění pomocí Robocopy snížit to, co musí při počáteční synchronizaci přejít spojem, a pokyny Microsoftu pokrývají zachování informací o souborech i práci se zamčenými nebo přeskočenými soubory. Je to optimalizace, ne slib, že cíl je už správný, takže počáteční replikace musí být i tak dokončena a ověřena. Právě vynechání tohoto ověření vede k tomu, že lokalita začne poskytovat soubory, které v replikované sadě nikdy nebyly.

Ověřte počáteční stav dřív, než na cíl začnou spoléhat uživatelé, ne až po první stížnosti.

Zvolte okno a definujte, co znamená aktuální

Plán replikace a omezení šířky pásma rozhodují o tom, kdy si partneři smějí vyměňovat data. Úzké okno po pracovní době je legitimní návrh, který přes den nechává frontu, pokud se všichni shodli, že vzdálená kopie musí být aktuální až do rána.

Napište tu větu, protože „fronta je čtyřicet minut“ je znepokojivé jen tehdy, když nikdo cíl nedefinoval.

Přijímejte s pracovním postupem, ne s jedním souborem

Testujte se soubory, které lidé opravdu používají: velký dokument, rutinní úprava, smazání a záměrná současná úprava na obou lokalitách. Potvrďte, že chování při konfliktu odpovídá tomu, co jste řekli byznysu, a že cesta obnovy ze zálohy je oddělená od replik. Pak několik týdnů sledujte objem změn, růst fronty a rezervu stagingu proti servisnímu oknu. Kapacita VPN je jeden z několika limitů a málokdy je prvním, na který narazíte.

Návrh, který dokumentuje své zpoždění a pravidla úprav, se podporuje mnohem snáz než ten, který slibuje identické kopie.