VPN을 통한 DFS 복제: 잠금은 얻을 수 있는 것이 아니다

링크는 암호화되어 있고 항상 켜져 있으며 충분히 빠릅니다. 그래서 공유 폴더가 두 사이트에서 하나의 폴더처럼 동작해야 한다고 생각합니다. 나중에 사람들을 놀라게 하는 대부분의 DFS 복제 설계가 바로 이 가정 위에 서 있습니다. DFSR은 멀티 마스터이자 비동기 방식입니다. 각 복제본이 버전을 독립적으로 추적하며, 프로토콜에는 서버 간에 잠금을 유지하는 장치가 없습니다. VPN은 두 서버 사이의 트래픽을 실어 나를 뿐, 이 가정이 필요로 하는 조정 기능을 전혀 추가하지 않습니다. 쓰기 패턴과 용량 모델을 설계하세요. 그러지 않으면 첫 번째 진짜 충돌이 지원 사건이 됩니다.

신화: VPN이 복제본을 하나의 파일 시스템으로 만든다

터널은 전송 수단입니다. 두 서버 사이에 허용된 경로를 제공하고 중간 홉을 감춥니다. 누가 파일을 편집할 수 있는지, 버전이 어떤 순서로 도착하는지, 두 편집이 경쟁하면 무슨 일이 생기는지는 말해 주지 않습니다.

암호화와 가용성은 링크의 속성이고, 일관성은 복제 엔진과 작업 방식의 속성입니다.

DFSR이 실제로 복제하는 것

각 서버는 자체 복사본과 자체 버전 메타데이터를 유지합니다. 변경 사항은 연결과 일정이 허용할 때 전파되며, 엔진은 원격 차분 압축을 사용해 파일에서 변경된 부분만 보냅니다. 두 복제본이 어떤 업데이트도 도착하기 전에 같은 파일을 변경하면 한 버전이 이기고 다른 버전은 충돌 복사본으로 옆으로 밀려납니다. DFSR이 제공하지 않는 분산 잠금이 필요하기 때문에 어느 서버도 두 번째 편집을 막지 않았습니다.

네임스페이스 경로는 복사본에 쉽게 접근하게 해 주지만, 복사본을 일관되게 만들지는 않습니다.

스테이징 공간은 작업 용량이지 백업이 아니다

스테이징은 복제가 변경 사항을 모으는 동안 사용하는 임시 영역입니다. Microsoft의 크기 지침은 복제된 폴더에서 가장 큰 32개 파일의 합계 크기를 최소값으로 잡으며, 초기 복제 중에는 추가 여유가 유용합니다. 그래서 작은 문서 트리와 큰 아카이브 여러 개가 있는 폴더는 서로 다른 스테이징 형태를 필요로 합니다. 스테이징이 바닥나면 복제는 네트워크 장애처럼 보이는 방식으로 멈춥니다. 데이터에서 크기를 산정하고, 데이터가 바뀌는 동안 계속 지켜보세요.

스테이징은 백업이 아니며, 변경 사항을 전파하는 것은 버전 이력이 아닙니다.

사전 시딩은 최적화이지 지름길이 아니다

규모가 큰 기존 트리의 경우 Robocopy를 사용한 지원되는 사전 시딩은 초기 동기화 때 링크를 건너야 하는 양을 줄일 수 있으며, Microsoft의 지침은 파일 정보 보존과 잠긴 파일 또는 건너뛴 파일 처리 방법을 다룹니다. 이것은 최적화이지 대상이 이미 정확하다는 약속이 아니므로, 초기 복제는 여전히 완료되고 검증되어야 합니다. 이 검증을 건너뛰면 사이트가 복제 집합에 한 번도 들어간 적 없는 파일을 제공하게 됩니다.

사용자가 대상에 의존하기 전에 초기 상태를 검증하세요. 첫 불만이 들어온 뒤가 아닙니다.

시간대를 고르고 최신의 의미를 정의하라

복제 일정과 대역폭 제어는 파트너가 언제 데이터를 교환할 수 있는지 결정합니다. 업무 시간 이후의 좁은 시간대는 낮 동안 밀린 양을 남기는 정당한 설계입니다. 다만 원격 복사본이 아침까지만 최신이면 된다는 데 모두가 동의해야 합니다.

그 문장을 적어 두세요. 밀린 양이 사십 분이라는 말은 아무도 목표를 정의하지 않았을 때만 걱정할 일입니다.

파일 하나가 아니라 업무 흐름으로 승인하라

사람들이 실제로 쓰는 파일로 시험하세요. 큰 문서, 일상적인 편집, 삭제, 그리고 두 사이트에서 의도적으로 동시에 편집하는 경우입니다. 충돌 동작이 비즈니스에 설명한 내용과 일치하는지, 백업에서 복구하는 경로가 복제본과 별개인지 확인하세요. 그다음 몇 주 동안 변경량, 큐 증가, 스테이징 여유를 서비스 시간대와 비교해 관찰하세요. VPN 용량은 여러 한계 중 하나이며, 가장 먼저 부딪히는 한계인 경우는 드뭅니다.

지연과 편집 규칙을 문서화한 설계는 동일한 복사본을 약속하는 설계보다 지원하기가 훨씬 쉽습니다.