DFS replikācija caur VPN: bloķēšana nav tas, ko jūs iegūstat

Saite ir šifrēta, vienmēr ieslēgta un pietiekami ātra, tāpēc koplietotajai mapei abās vietās būtu jāuzvedas kā vienai mapei. Šis ir pieņēmums, uz kura balstās lielākā daļa DFS replikācijas projektu, kas vēlāk pārsteidz cilvēkus. DFSR ir multi-master un asinhrona: katra replika patstāvīgi seko versijām, un protokolā nekas netur bloķējumu starp serveriem. VPN pārnes starp tiem plūsmu un nepievieno neko no tās koordinācijas, kas šim pieņēmumam vajadzīga. Izplānojiet rakstīšanas modeli un kapacitātes modeli, citādi pirmais īstais konflikts kļūst par atbalsta incidentu.

Mīts: VPN pārvērš replikas vienā failu sistēmā

Tunelis ir transports. Tas dod atļautu ceļu starp diviem serveriem un slēpj starpposma lēcienus. Tas neko nesaka par to, kurš drīkst rediģēt failu, kādā secībā ierodas versijas vai kas notiek, kad sacenšas divas rediģēšanas.

Šifrēšana un pieejamība ir saites īpašības; konsekvence ir replikācijas dzinēja un jūsu darbplūsmas īpašība.

Ko DFSR faktiski replicē

Katrs serveris glabā savu kopiju un savus versijas metadatus. Izmaiņas izplatās, kad savienojums un grafiks to atļauj, un dzinējs izmanto attālināto diferenciālo saspiešanu, lai sūtītu tikai mainītās faila daļas. Kad divas replikas maina vienu un to pašu failu pirms jebkura atjauninājuma ierašanās, viena versija uzvar, bet otra tiek pārvietota malā kā konflikta kopija. Neviens serveris nebloķēja otro rediģēšanu, jo bloķēšanai vajadzētu izplatīto bloķējumu, ko DFSR nepiedāvā.

Nosaukumvietas ceļš padara kopijas viegli sasniedzamas, un tas nepadara tās saskaņotas.

Staging vieta ir darba kapacitāte, nevis dublējums

Staging ir pagaidu apgabals, ko replikācija izmanto, kamēr tā saliek izmaiņas. Microsoft izmēra norādījumi ņem 32 lielāko failu kopējo izmēru replicētajā mapē kā minimumu, un papildu vieta noder sākotnējās replikācijas laikā. Tāpēc sīku dokumentu kokam un mapei ar vairākiem lieliem arhīviem vajadzīgas atšķirīgas staging formas. Kad staging izbeidzas, replikācija apstājas tā, ka izskatās pēc tīkla bojājuma. Aprēķiniet to no datiem un pēc tam turpiniet vērot, kā dati mainās.

Staging nav dublējums, un izmaiņu izplatīšana nav versiju vēsture.

Iepriekšēja aizsēšana ir optimizācija, nevis īsceļš

Lielam esošam kokam atbalstīta iepriekšēja aizsēšana ar Robocopy var samazināt to, kam jāšķērso saite sākotnējās sinhronizācijas laikā, un Microsoft norādījumi aptver faila informācijas saglabāšanu un bloķētu vai izlaistu failu apstrādi. Tā ir optimizācija, nevis solījums, ka galamērķis jau ir pareizs, tāpēc sākotnējā replikācija tomēr ir jāpabeidz un jāpārbauda. Tieši šīs pārbaudes izlaišana noved pie tā, ka vietne sāk apkalpot failus, kas nekad nav bijuši replicētajā kopā.

Pārbaudiet sākotnējo stāvokli pirms lietotāji paļaujas uz galamērķi, nevis pēc pirmās sūdzības.

Izvēlieties logu un definējiet, ko nozīmē aktuāli

Replikācijas grafiks un joslas platuma ierobežojumi nosaka, kad partneri drīkst apmainīties ar datiem. Šaurs logs pēc darba laika ir likumīgs projekts, kas dienas laikā atstāj uzkrājumu, ar nosacījumu, ka visi ir vienojušies, ka attālajai kopijai jābūt aktuālai tikai līdz rītam.

Pierakstiet šo teikumu, jo „uzkrājums ir četrdesmit minūtes“ satrauc tikai tad, ja neviens nav definējis mērķi.

Pieņemiet ar darbplūsmu, nevis ar vienu failu

Pārbaudiet ar failiem, ko cilvēki faktiski izmanto: liels dokuments, rutīnas rediģēšana, dzēšana un apzināta vienlaicīga rediģēšana abās vietās. Apstipriniet, ka konflikta uzvedība atbilst tam, ko teicāt uzņēmumam, un ka atjaunošanas ceļš no dublējuma ir atsevišķi no replikām. Pēc tam dažas nedēļas vērojiet izmaiņu apjomu, rindas pieaugumu un staging rezervi pret pakalpojuma logu. VPN kapacitāte ir viens no vairākiem ierobežojumiem, un tā reti ir pirmais, ko sasniedzat.

Projektu, kas dokumentē savu aizkavēšanos un rediģēšanas noteikumus, atbalstīt ir daudz vieglāk nekā tādu, kas sola identiskas kopijas.