DFSR에서 분산 파일 잠금 이해(부족)

  • 아티클

이 문서에서는 Windows 내에서, 특히 DFSR에서 복제된 폴더 내에서 다중 호스트 분산 파일 잠금 메커니즘이 없는 것에 대해 설명합니다.

일부 배경

  • 분산 파일 잠금 – 여러 컴퓨터에 파일의 여러 복사본이 있고 쓰기 위해 파일을 하나 열면 다른 모든 복사본이 잠기는 개념을 의미합니다. 이렇게 하면 여러 사용자가 동시에 여러 서버에서 파일을 수정할 수 없습니다.
  • 분산 파일 시스템 복제 – DFSR 은 다중 마스터 상태 기반 디자인에서 작동합니다. 상태 기반 복제에서 다중 마스터 시스템의 각 서버는 로그 파일을 교환하지 않고 도착하는 복제본에 업데이트를 적용합니다(대신 버전 벡터를 사용하여 "최신 상태" 정보 유지). 초기 동기화 후 어느 서버도 임의로 신뢰할 수 없으므로 다양한 네트워크 토폴로지에서 고가용성 및 매우 유연합니다.
  • 서버 메시지 블록 - SMB는 네트워크를 통해 파일에 액세스하기 위해 Windows 사용되는 일반적인 프로토콜입니다. 간단히 말하면 리렉터레이터를 사용하여 원격 파일 시스템이 로컬 파일 시스템으로 표시되도록 하는 클라이언트 서버 프로토콜입니다. Windows 관련이 없으며 매우 일반적입니다. 잘 알려진 타사 예제는 Linux, Mac 및 기타 운영 체제가 SMB 클라이언트/서버 역할을 하고 Windows 네트워크에 참여할 수 있도록 하는 Samba입니다.

복제된 데이터 환경에서 DFSR 및 SMB가 있는 위치를 명확하게 구분하는 것이 중요합니다. SMB를 사용하면 사용자가 파일에 액세스할 수 있으며 DFSR에 대한 인식이 없습니다. 마찬가지로 DFSR(RPC 프로토콜 사용)은 서버 간에 파일을 동기화 상태로 유지하고 SMB에 대한 인식이 없습니다. 이 게시물 및 기회 잠금에 정의된 대로 분산 잠금을 혼동하지 마세요.

영국인들이 말했듯이 배 모양으로 갈 수 있는 곳은 다음과 같습니다.

사용자는 여러 서버에서 데이터를 수정할 수 있으며 각 Windows 서버는 자체의 파일 잠금에 대해서만 알고 있으므로DFSR은 다른 서버의 잠금에 대해 아무것도 알지 못하므로 사용자가 서로의 변경 내용을 덮어쓸 수 있습니다. DFSR은 "마지막 기록기 승리" 충돌 알고리즘을 사용하므로 누군가가 잃어야 하고 마지막으로 저장할 사람이 변경 내용을 유지합니다. 손실된 파일 복사본이 ConflictAndDeleted 폴더로 이동됩니다.

지금, 이것은 사람들이 믿고 싶은 것보다 훨씬 덜 일반적입니다. 일반적으로 실제 공유 파일은 로컬 환경에서 수정됩니다. 지점 또는 동일한 칸막이 행에 있습니다. 일반적으로 동일한 팀의 사용자가 작업하므로 사람들은 일반적으로 데이터를 수정하는 동료를 알고 있습니다. 일반적으로 동일한 사이트에 있으므로 공유 문서에서 작업하는 모든 사용자가 동일한 서버를 사용할 확률이 훨씬 높습니다. Windows SMB는 여기에서 상황을 처리합니다. 사용자에게 수정을 위해 잠긴 파일이 있고 동료가 파일을 편집하려고 하면 다른 사용자에게 다음과 같은 오류가 발생합니다.

Screenshot of the File In Use dialog box showing an error message that says This action can't be completed because the file is open in another program.

그리고 파일을 여는 애플리케이션이 Word 2007과 같이 매우 영리하다면 다음을 제공할 수 있습니다.

Screenshot of the File In Use dialog box showing three actions you can take when a file is locked by another user.

DFSR에는 잠긴 파일에 대한 메커니즘이 있지만 서버 자체 컨텍스트 내에만 있습니다. DFSR은 로컬 복사본에 배타적 잠금이 있는 경우 파일을 복제하거나 복제하지 않습니다. 그러나 이렇게 해서 다른 서버의 사용자가 파일을 수정할 수 없습니다.

다시 토픽으로 돌아가서 지리적으로 수정 되는 공유 데이터의 문제가 존재하며 일부 사람들에게는 매우 난해합니다. DFSR이 이 잠금을 처리하지 않고 마법의 지팡이의 물결로 모든 것을 가져가지 않는 이유를 가끔 묻습니다. 다중 마스터 복제 시스템에 대해 해결하기 위해 흥미롭고 어려운 시나리오입니다. 지금 살펴보세요.

타사 솔루션

이 문제를 해결하는 몇 가지 공급업체 솔루션이 있으며, 일반적으로 다음 방법 중 하나 이상을 처리합니다*.

  • broker 메커니즘 사용

중앙 '트래픽 경찰'을 사용하면 한 서버가 다른 모든 서버와 사용자가 잠근 파일을 인식할 수 있습니다. 아쉽게도 이는 분산 잠금 시스템에 단일 실패 지점이 있는 경우가 많다는 것을 의미합니다.

Diagram showing the use of a broker mechanism.

  • 완전히 라우팅된 네트워크에 대한 요구 사항

중앙 브로커는 파일 복제에 참여하는 모든 서버와 통신할 수 있어야 하므로 복잡한 네트워크 토폴로지 처리 기능이 제거됩니다. 링 토폴로지 및 다중 허브 및 스포크 토폴로지는 일반적으로 불가능합니다. 완전히 라우팅되지 않은 네트워크에서 일부 서버는 서로 직접 연락할 수 없거나 브로커와 직접 연락할 수 없으며 다른 서버와 통신할 수 있는 파트너와만 통신할 수 있습니다. 다중 마스터 환경에서는 괜찮지만 조정 메커니즘에서는 그렇지 않습니다.

Diagram showing the requirement for a fully routed network.

  • 서버 쌍으로 제한됨

일부 솔루션은 분산 잠금 메커니즘을 간소화하기 위해 토폴로지 쌍을 서버 쌍으로 제한합니다. 더 큰 환경의 경우 이것이 불가능할 수 있습니다.

  • 클라이언트 및 서버에서 에이전트 사용
  • 다중 마스터 복제 사용 안 함
  • MS 클러스터링을 사용하지 마세요.
  • 특수 어플라이언스 사용

* 나는 일반적으로 말을 참고! 이러한 방법 중 하나 이상을 구현하거나 구현하지 않는 솔루션이 있으므로 사망 위협을 게시하지 마세요!

심층적인 생각

이 문제에 대해 더 생각해 보면 몇 가지 근본적인 문제가 잘리기 시작합니다. 예를 들어 4개의 사이트에서 사용자가 수정할 수 있는 데이터가 있는 4개의 서버가 있고 그 중 하나에 대한 WAN 연결이 오프라인으로 전환되는 경우 어떻게 해야 하나요? 사용자는 여전히 개별 서버에 액세스할 수 있지만 허용해야 하나요? 우리는 그들이 갈등을 변경하는 것을 원하지 않지만, 우리는 확실히 그들이 계속 일하고 회사 돈을 벌기를 원합니다. 해당 시점에서 임의로 변경 내용을 차단하면 실제로 충돌이 발생하지 않더라도 사용자가 작업할 수 없습니다. 파일이 사용 중이며 다시 정사각형으로 돌아왔다는 것을 다른 서버에 알릴 수 있는 방법은 없습니다.

Diagram showing the results of a partial network outage.

그런 다음 SMB 자체와 보고 잠금의 오류 처리가 있습니다. 많은 애플리케이션을 중단하고 클라이언트가 새로운 확장 오류 메시지를 이해하지 못하기 때문에 SMB 보고서 공유 위반 방법을 실제로 변경할 수 없습니다. Word 2007과 같은 애플리케이션은 누가 파일을 잠그고 있는지 파악하기 위해 몇 가지 비밀 속임수를 수행하지만, 대부분의 애플리케이션은 사용 중인 파일이 누구인지(또는 SMB가 존재하는지) 알지 못합니다. 정말.). 따라서 사용자가 '이 파일이 사용 중'인 메시지를 받으면 특히 실행 가능하지 않습니다. 모두 지원 센터에 전화해야 하나요? 지원 센터에서 파일에 액세스하는 사용자를 확인하기 위해 모든 파일 서버에 액세스할 수 있나요? 지저분한.

고가용성을 위해 다중 마스터를 원하기 때문에 브로커 시스템은 바람직하지 않습니다. 완전히 라우팅되지 않은 네트워크를 통해서도 모든 서버에서 통신할 수 있는 모든 서버에서 실행 중인 항목이 필요할 수 있습니다. 이렇게 하려면 매우 복잡한 동기화 기술이 필요합니다. 네트워크에 약간의 오버헤드가 추가되고(많은 것은 아니지만) 사용자가 작업을 수행하지 않도록 하려면 빠르게 번개가 치는 것이 좋습니다. 파일 복제 자체를 능가해야 합니다. 실제로 복제에 실제로 연결해야 할 수도 있습니다. 또한 어떻게든 서버 크래시가 아닌 네트워크와 관련된 서버 중단을 고려해야 합니다.

Diagram showing Locking and Replication across five servers.

잠금을 더 잘 이해하고 사용자에게 유용한 정보를 제공할 수 있는 이 시나리오를 위한 특수 클라이언트 소프트웨어로 돌아갔습니다("계정에서 Susie에 전화를 걸어 해당 문서를 해제하라고 지시합니다.", "죄송합니다. 파일 잠금 토폴로지가 끊어졌으며 관리자가 수정될 때까지 이 파일을 열지 못하게 합니다.") 등). Windows 실행되는 수백만 개의 애플리케이션에서 멋지게 플레이할 수 있도록 하는 것은 확실히 흥미로울 것입니다. 지원되지 않거나 소프트웨어를 얻을 수 없는 많은 OS가 있습니다 . Windows 2000은 일반 지원에서 벗어났으며 XP는 곧 제공 될 것입니다. Linux 및 Mac 클라이언트는 이 소프트웨어가 중요하다고 판단하기 전까지는 이 소프트웨어를 갖지 않았기 때문에 고객은 공급업체가 비슷한 것을 만들었으면 좋겠습니다.

추가 정보

현재 DFSR에서 이 상황을 제어하는 가장 쉬운 방법은 DFS 네임스페이스를 사용하여 일관된 네임스페이스를 사용하여 예측 가능한 위치로 사용자를 안내하는 것입니다. DFSN 사이트 토폴로지 및 서버 링크를 올바르게 구성하면 사용자가 모두 동일한 로컬 서버를 공유하도록 강제하고 'main' 서버가 다운된 경우에만 원격 컴퓨터에 액세스할 수 있습니다. 대부분의 환경에서는 이 작업이 매우 잘 작동합니다. DFSR 대신 체크 아웃/체크 인 시스템 때문에 SharePoint 옵션입니다. BranchCache(Windows Server 2008 R2 및 Windows 7에서 제공됨)는 분기 시나리오에서 파일 읽기를 완화하기 위해 설계되었지만 결국 신뢰할 수 있는 데이터는 여전히 하나의 서버에만 저장됩니다. 여기에서 자세히 설명합니다. 그리고 다시, 그 공급 업체는 자신의 솔루션을 가지고있다.