DFS-i replikatsioon üle VPN-i: lukustamine ei ole see, mille saad

Link on krüpteeritud, alati sees ja piisavalt kiire, seega peaks jagatud kaust mõlemas saidis käituma ühe kaustana. See eeldus on enamiku DFS-i replikatsioonikavade taga, mis inimesi hiljem üllatavad. DFSR on mitme peamisega ja asünkroonne: iga koopia jälgib versioone iseseisvalt ja miski protokollis ei hoia lukku serverite vahel. VPN kannab nende vahel liiklust ega lisa midagi sellest koordineerimisest, mida see eeldus vajab. Planeeri kirjutamise muster ja mahumudel, muidu muutub esimene tõeline konflikt tugiintsidendiks.

Müüt: VPN muudab koopiad üheks failisüsteemiks

Tunnel on transport. See annab kahe serveri vahel lubatud tee ja peidab vahepealsed hüpped. See ei ütle midagi selle kohta, kes tohib faili muuta, mis järjekorras versioonid saabuvad või mis juhtub, kui kaks muudatust võidu jooksevad.

Krüpteerimine ja kättesaadavus on lingi omadused; järjepidevus on replikatsioonimootori ja sinu töövoo omadus.

Mida DFSR tegelikult replikeerib

Iga server hoiab oma koopiat ja oma versiooni metaandmeid. Muudatused levivad, kui ühendus ja ajakava seda lubavad, ning mootor kasutab kaugdiferentsiaalset pakkimist, et saata ainult faili muutunud osad. Kui kaks koopiat muudavad sama faili enne, kui kumbki uuendus kohale jõuab, võidab üks versioon ja teine tõstetakse kõrvale konfliktkoopiana. Ükski server ei blokeerinud teist muudatust, sest blokeerimine nõuaks hajutatud lukku, mida DFSR ei paku.

Nimeruumi tee teeb koopiad kergesti kättesaadavaks ega muuda neid sidusaks.

Staging-ruum on töömaht, mitte varukoopia

Staging on see ajutine ala, mida replikatsioon muudatuste kokkupanemisel kasutab. Microsofti suurusejuhis võtab replikeeritavas kaustas oleva 32 suurima faili kogusuuruse miinimumiks, kusjuures lisaruum on esialgse replikatsiooni ajal kasulik. Seetõttu vajavad pisidokumentide puu ja mitut suurt arhiivi hoidv kaust erinevaid staging-kujusid. Kui staging otsa saab, jääb replikatsioon seisma viisil, mis näeb välja nagu võrgurike. Mõõda see andmetest lähtudes ja jälgi edasi, kuidas andmed muutuvad.

Staging ei ole varukoopia ja muudatuste levitamine ei ole versiooniajalugu.

Eelkülvamine on optimeerimine, mitte otsetee

Suure olemasoleva puu puhul võib Robocopyga toetatud eelkülvamine vähendada seda, mis peab esialgse sünkroonimise ajal lingist üle minema, ja Microsofti juhis katab failiteabe säilitamise ning lukustatud või vahelejäetud failide käsitlemise. See on optimeerimine, mitte lubadus, et sihtkoht on juba korras, seega peab esialgne replikatsioon ikkagi lõpule jõudma ja olema kontrollitud. Just selle kontrolli vahelejätmise järel hakkab sait serveerima faile, mida replikeeritud komplektis kunagi polnud.

Kontrolli algseisundit enne, kui kasutajad sihtkohale lootma hakkavad, mitte pärast esimest kaebust.

Vali aken ja määra, mida tähendab ajakohane

Replikatsiooni ajakava ja ribalaiuse piirangud otsustavad, millal partnerid tohivad andmeid vahetada. Kitsas pärast tööaega jääv aken on legitiimne kava, mis jätab päevaks mahajäämuse, eeldusel et kõik nõustusid, et kaugkoopia peab ajakohane olema alles hommikuks.

Kirjuta see lause üles, sest „mahajäämus on nelikümmend minutit“ on murettekitav vaid siis, kui keegi pole sihti määranud.

Võta vastu töövooga, mitte ühe failiga

Testi failidega, mida inimesed tegelikult kasutavad: suur dokument, rutiinne muudatus, kustutamine ja tahtlik samaaegne muudatus mõlemas saidis. Kinnita, et konflikti käitumine vastab sellele, mida ütlesid ärile, ja et varukoopiast taastamise tee on koopiatest eraldi. Seejärel jälgi paar nädalat muudatuste mahtu, järjekorra kasvu ja staging-varu teenindusakna suhtes. VPN-i maht on üks paljudest piiridest ja harva esimene, milleni jõuad.

Kava, mis dokumenteerib oma viivituse ja muutmisreeglid, on palju lihtsam toetada kui see, mis lubab identseid koopiaid.