DFS-replikáció VPN-en át: a zárolás nem az, amit kap
A telephelyi VPN szállítja a forgalmat, de nem ad hozzá fájlzárolást. Tervezze meg a konzisztenciamodellt, a staging-területet és a replikációs ablakot a kezdeti feltöltés előtt.
A kapcsolat titkosított, mindig elérhető és elég gyors, ezért a megosztott mappának mindkét telephelyen egyetlen mappaként kellene viselkednie. Ez az a feltevés, amely a legtöbb DFS-replikációs terv mögött áll, és amelyek később meglepik az embereket. A DFSR multi-master és aszinkron: minden replika önállóan követi a verziókat, és semmi a protokollban nem tart zárolást a kiszolgálók között. A VPN szállítja közöttük a forgalmat, és semmit nem ad hozzá abból a koordinációból, amire ez a feltevés támaszkodik. Tervezze meg az írási mintát és a kapacitásmodellt, különben az első valódi ütközés támogatási esetté válik.
A mítosz: a VPN egyetlen fájlrendszerré teszi a replikákat
Az alagút átvitel. Engedélyezett útvonalat ad két kiszolgáló között, és elrejti a köztes ugrásokat. Semmit nem mond arról, ki szerkeszthet fájlt, milyen sorrendben érkeznek a verziók, vagy mi történik, amikor két szerkesztés versenyez.
A titkosítás és az elérhetőség a kapcsolat tulajdonsága; a konzisztencia a replikációs motor és a munkafolyamat tulajdonsága.
Mit replikál valójában a DFSR
Minden kiszolgáló a saját másolatát és saját verzió-metaadatait tartja. A változások akkor terjednek, amikor a kapcsolat és az ütemezés engedi, a motor pedig távoli differenciáltömörítéssel csak a fájl megváltozott részeit küldi át. Ha két replika ugyanazt a fájlt módosítja, mielőtt bármelyik frissítés megérkezne, az egyik verzió nyer, a másik pedig ütközési másolatként félrekerül. Egyetlen kiszolgáló sem blokkolta a második szerkesztést, mert a blokkoláshoz arra az elosztott zárolásra lenne szükség, amelyet a DFSR nem biztosít.
A névtér-útvonal könnyen elérhetővé teszi a másolatokat, és nem teszi őket koherenssé.
A staging-terület munkakapacitás, nem biztonsági mentés
A staging az a munkaterület, amelyet a replikáció a változások összeállítása közben használ. A Microsoft méretezési útmutatója a replikált mappában lévő 32 legnagyobb fájl együttes méretét veszi minimumnak, és a kezdeti replikáció során további hely hasznos. Ezért az apró dokumentumokból álló fa és a több nagy archívumot tartalmazó mappa eltérő staging-formákat igényel. Ha a staging elfogy, a replikáció úgy áll le, hogy az hálózati hibának látszik. A méretezést az adatokból számítsa, majd figyelje tovább, ahogy az adatok változnak.
A staging nem biztonsági mentés, és a változások terjesztése nem verziótörténet.
Az előzetes feltöltés optimalizálás, nem rövidítés
Egy nagy meglévő fa esetében a Robocopyval támogatott előzetes feltöltés csökkentheti azt, aminek a kezdeti szinkronizálás során a kapcsolaton át kell mennie, és a Microsoft útmutatója kiterjed a fájlinformációk megőrzésére, valamint a zárolt vagy kihagyott fájlok kezelésére. Ez optimalizálás, nem ígéret arra, hogy a cél már helyes, ezért a kezdeti replikációnak így is végig kell futnia és ellenőrizni kell. Ennek az ellenőrzésnek a kihagyása az, ahogy egy telephely olyan fájlokat kezd kiszolgálni, amelyek soha nem voltak a replikált halmazban.
A kezdeti állapotot még az előtt ellenőrizze, hogy a felhasználók a célra támaszkodnának, nem az első panasz után.
Válassza meg az ablakot, és határozza meg, mit jelent az aktuális
A replikációs ütemezés és a sávszélesség-szabályozás dönti el, mikor cserélhetnek adatot a partnerek. A munkaidő utáni szűk ablak legitim terv, amely napközben lemaradást hagy, feltéve hogy mindenki egyetértett abban: a távoli másolatnak csak reggelre kell aktuálisnak lennie.
Írja le azt a mondatot, mert a „negyven perces a lemaradás” csak akkor aggasztó, ha senki nem határozta meg a célt.
Fogadja el a munkafolyamattal, ne egyetlen fájllal
Teszteljen azokkal a fájlokkal, amelyeket az emberek valóban használnak: nagy dokumentum, rutinszerkesztés, törlés és szándékos egyidejű szerkesztés mindkét telephelyen. Erősítse meg, hogy az ütközés viselkedése megfelel annak, amit az üzletnek mondott, és hogy a biztonsági mentésből való visszaállítás útja elkülönül a replikáktól. Ezután néhány hétig figyelje a változások mennyiségét, a sor növekedését és a staging-tartalékot a szolgáltatási ablakhoz képest. A VPN-kapacitás egy a több korlát közül, és ritkán az első, amelyet elér.
Az olyan tervet, amely dokumentálja a késleltetését és a szerkesztési szabályait, sokkal könnyebb támogatni, mint azt, amely azonos másolatokat ígér.