DFS репликација преко VPN-а: закључавање није оно што добијате

Веза је шифрована, стално укључена и довољно брза, па би дељена фасцикла требало да се понаша као једна фасцикла на обе локације. То је претпоставка на којој почива већина пројеката DFS репликације који људе касније изненаде. DFSR је multi-master и асинхрон: свака реплика самостално прати верзије и ништа у протоколу не држи закључавање између сервера. VPN преноси саобраћај између њих и не додаје ништа од координације коју та претпоставка тражи. Испланирајте образац писања и модел капацитета, иначе први стварни конфликт постаје инцидент за подршку.

Мит: VPN претвара реплике у један фајл систем

Тунел је транспорт. Даје вам дозвољену путању између два сервера и скрива скокове између њих. Не говори ништа о томе ко сме да уређује датотеку, којим редоследом верзије стижу ни шта се дешава када се две измене такмиче.

Шифровање и доступност су својства везе; конзистентност је својство мотора репликације и вашег радног процеса.

Шта DFSR заиста реплицира

Сваки сервер држи сопствену копију и сопствене метаподатке верзија. Промене се шире када веза и распоред то дозволе, а мотор користи удаљену диференцијалну компресију да пошаље само делове датотеке који су се променили. Када две реплике промене исту датотеку пре него што стигне било које ажурирање, једна верзија побеђује, а друга се премешта у страну као конфликтна копија. Ниједан сервер није блокирао другу измену, јер би блокирање захтевало дистрибуирано закључавање које DFSR не нуди.

Путања у простору имена чини копије лако доступним, али их не чини усклађеним.

Staging простор је радни капацитет, не резервна копија

Staging је радна површина коју репликација користи док саставља промене. Microsoftове смернице за величину узимају заједничку величину 32 највеће датотеке у реплицираној фасцикли као минимум, а додатни простор је користан током почетне репликације. Стабло ситних докумената и фасцикла са неколико великих архива зато траже различите облике staging-а. Када staging пресуши, репликација се зауставља на начин који изгледа као мрежни квар. Одредите величину из података, па наставите да пратите како се подаци мењају.

Staging није резервна копија, а ширење промена није историја верзија.

Претходно пуњење је оптимизација, не пречица

За велико постојеће стабло подржано претходно пуњење уз Robocopy може смањити оно што мора преко везе током почетне синхронизације, а Microsoftове смернице покривају чување података о датотеци и рад са закључаним или прескоченим датотекама. То је оптимизација, а не обећање да је одредиште већ исправно, па почетна репликација ипак мора бити довршена и проверена. Прескакање те провере је начин на који локација почне да служи датотеке које никада нису биле у реплицираном скупу.

Проверите почетно стање пре него што се корисници ослоне на одредиште, а не после прве жалбе.

Изаберите прозор и дефинишите шта значи актуелно

Распоред репликације и контроле пропусног опсега одређују када партнери смеју да размењују податке. Узак прозор после радног времена је легитиман дизајн који оставља заостатак током дана, под условом да су се сви сложили да удаљена копија мора бити актуелна само до јутра.

Запишите ту реченицу, јер „заостатак је четрдесет минута“ забрињава само ако нико није дефинисао циљ.

Прихватите са радним процесом, не са једном датотеком

Тестирајте са датотекама које људи заиста користе: велики документ, рутинску измену, брисање и намерну истовремену измену на обе локације. Потврдите да понашање при конфликту одговара ономе што сте рекли пословању и да је пут опоравка из резервне копије одвојен од реплика. Затим неколико недеља пратите обим промена, раст реда и резерву staging-а према сервисном прозору. VPN капацитет је једно од неколико ограничења и ретко је прво до којег дођете.

Дизајн који документује свој заостатак и правила уређивања много је лакше подржавати од оног који обећава идентичне копије.