DFS replikacija per VPN: užraktas nėra tai, ką gaunate

Ryšys užšifruotas, visada įjungtas ir pakankamai greitas, todėl bendras aplankas turėtų elgtis kaip vienas aplankas abiejose vietose. Ši prielaida slypi po dauguma DFS replikacijos projektų, kurie vėliau nustebina žmones. DFSR yra kelių magistralių ir asinchroninis: kiekviena replika savarankiškai seka versijas, o protokole niekas nelaiko užrakto tarp serverių. VPN perduoda srautą tarp jų ir neprideda nieko iš tos koordinacijos, kurios reikia šiai prielaidai. Suplanuokite rašymo modelį ir talpos modelį, kitaip pirmasis tikras konfliktas taps palaikymo incidentu.

Mitas: VPN paverčia replikas viena failų sistema

Tunelis yra transportas. Jis duoda leistiną kelią tarp dviejų serverių ir paslepia tarpinius šuolius. Jis nieko nesako apie tai, kas gali redaguoti failą, kokia tvarka ateina versijos ar kas nutinka, kai dvi redakcijos varžosi.

Šifravimas ir prieinamumas yra ryšio savybės; nuoseklumas yra replikacijos variklio ir jūsų darbo eigos savybė.

Ką DFSR iš tikrųjų replikuoja

Kiekvienas serveris laiko savo kopiją ir savo versijos metaduomenis. Pakeitimai plinta, kai leidžia ryšys ir grafikas, o variklis naudoja nuotolinį diferencinį glaudinimą, kad siųstų tik pasikeitusias failo dalis. Kai dvi replikos pakeičia tą patį failą prieš atvykstant bet kuriam atnaujinimui, viena versija laimi, o kita atidedama kaip konflikto kopija. Nė vienas serveris neužblokavo antrosios redakcijos, nes blokavimui reikėtų paskirstyto užrakto, kurio DFSR nesiūlo.

Vardų erdvės kelias leidžia lengvai pasiekti kopijas, bet nepadaro jų vientisų.

Staging erdvė yra darbinė talpa, o ne atsarginė kopija

Staging yra laikina sritis, kurią replikacija naudoja rinkdama pakeitimus. Microsoft dydžio gairės ima bendrą 32 didžiausių failų dydį replikuojamame aplanke kaip minimumą, o papildoma vieta naudinga pradinės replikacijos metu. Todėl smulkių dokumentų medžiui ir aplankui su keliais dideliais archyvais reikia skirtingų staging formų. Kai staging baigiasi, replikacija sustoja taip, kad atrodo kaip tinklo gedimas. Apskaičiuokite jį iš duomenų, tada stebėkite toliau, kai duomenys keičiasi.

Staging nėra atsarginė kopija, o pakeitimų platinimas nėra versijų istorija.

Išankstinis įkėlimas yra optimizavimas, ne trumpasis kelias

Dideliam esamam medžiui palaikomas išankstinis įkėlimas su Robocopy gali sumažinti tai, ką reikia perduoti ryšiu pradinio sinchronizavimo metu, o Microsoft gairės apima failo informacijos išsaugojimą ir užrakintų ar praleistų failų tvarkymą. Tai optimizavimas, o ne pažadas, kad paskirties vieta jau teisinga, todėl pradinė replikacija vis tiek turi būti baigta ir patikrinta. Būtent šio patikrinimo praleidimas lemia, kad vieta pradeda tiekti failus, kurių niekada nebuvo replikuotame rinkinyje.

Patikrinkite pradinę būseną prieš vartotojams pradedant pasitikėti paskirties vieta, o ne po pirmojo skundo.

Pasirinkite langą ir apibrėžkite, ką reiškia aktualu

Replikacijos grafikas ir pralaidumo valdikliai nusprendžia, kada partneriai gali keistis duomenimis. Siauras langas po darbo valandų yra teisėtas sprendimas, paliekantis atsilikimą dienos metu, su sąlyga, kad visi sutiko, jog nuotolinė kopija turi būti aktuali tik iki ryto.

Užsirašykite tą sakinį, nes „atsilikimas yra keturiasdešimt minučių“ kelia nerimą tik tada, kai niekas neapibrėžė tikslo.

Priimkite su darbo eiga, o ne su vienu failu

Testuokite su failais, kuriuos žmonės iš tikrųjų naudoja: didelis dokumentas, įprasta redakcija, ištrynimas ir tyčia vienu metu atlikta redakcija abiejose vietose. Patvirtinkite, kad konflikto elgsena atitinka tai, ką pasakėte verslui, ir kad atkūrimo iš atsarginės kopijos kelias yra atskiras nuo replikų. Tada kelias savaites stebėkite pakeitimų apimtį, eilės augimą ir staging rezervą, lygindami su paslaugos langu. VPN talpa yra viena iš kelių ribų, ir ji retai būna pirmoji, kurią pasiekiate.

Projektą, kuriame dokumentuojamas jo vėlavimas ir redagavimo taisyklės, palaikyti daug lengviau nei tokį, kuris žada identiškas kopijas.