VPN 파일 공유를 위한 BranchCache: 도움이 될 때와 그렇지 않을 때

팀의 누군가가 VPN을 통한 파일 공유가 느리다고 말하면, 첫 번째 제안은 늘 캐시입니다. BranchCache를 원격 액세스 설계에 추가하기 전에 그 불만을 세 가지 형태 중 하나로 나누십시오. 변경되지 않은 콘텐츠의 반복 다운로드, 업로드, 또는 수천 개의 항목이 있는 폴더를 훑는 메타데이터 위주의 탐색입니다. BranchCache는 지원되는 콘텐츠에서 첫 번째 형태를 해결하고 나머지 둘에는 아무 쓸모가 없습니다. 이것은 우회해야 할 제약이 아니라, 배포에 일주일을 쓰기 전에 해 두어야 할 비교입니다.

같은 공유, 세 가지 다른 불만

지사 사무실에서 여덟 명이 같은 변경되지 않은 교육용 동영상을 여는 것이 이 기능이 설계된 사례입니다. 첫 검색은 WAN을 건너고, 콘텐츠는 읽는 사람 가까이에 캐시되며, 같은 변경되지 않은 파일의 이후 검색은 로컬에서 제공됩니다. 이점은 실제로 있지만 좁습니다. 같은 콘텐츠, 변경 없음, 여러 명의 읽는 사람.

가정용 회선으로 새 녹음을 업로드하는 노트북은 반대 사례입니다. 아직 존재하지 않는 파일의 이전 캐시 복사본은 없으므로 업로드는 언제나 그래왔던 제한된 경로를 따릅니다. 다운로드 캐시는 업로드를 없애지 않으며, 어느 배치 선택도 그것을 바꾸지 않습니다.

세 번째 형태는 다운로드 문제처럼 보이기 때문에 사람들을 실망시킵니다. 수만 개의 파일이 있는 디렉터리를 열고 정렬하고 메타데이터를 읽는 것은 작은 작업의 연속이며, 큰 객체의 반복 전송이 아닙니다. 파일 본문을 캐시하는 것은 열거에 아무 도움이 되지 않습니다.

분산 캐시: VPN 풀은 지사 LAN이 아니다

분산 모드에서 클라이언트 컴퓨터는 캐시된 콘텐츠를 서로 공유하며, Microsoft는 이 모드를 단일 서브넷 안에서 동작하는 것으로 문서화합니다. VPN 클라이언트 풀은 모든 주소가 연속된 것처럼 보여도 그런 의미의 서브넷이 아닙니다. 피어 검색, 클라이언트 간 도달 가능성, 캐시 데이터를 교환할 권한은 각각 별개의 질문이며, 일반적인 원격 액세스 설계는 세 가지 모두에 “아니요”라고 답합니다.

클라이언트 간 트래픽을 허용하여 풀이 지사 LAN처럼 동작하게 만들 수 있지만, 그것은 보안 결정이지 캐시 결정이 아닙니다. 대부분의 원격 액세스 설계가 클라이언트를 서로 격리하는 것은 침해된 노트북이 다른 노트북에 도달하지 못하게 하기 위해서입니다. 그 격리를 캐시 적중과 맞바꾸는 것은 피어가 이미 신뢰하는 대등 관계가 아니라면 나쁜 거래입니다.

단일 이동 사용자에게 분산 모드는 공유할 상대가 없습니다. 캐시는 그 한 클라이언트의 반복 읽기를 처리할 수 있지만, 그것은 클라이언트 측 캐시 이점이지 지사 배치의 이점이 아니며, 누군가 사무실이 빨라질 것이라고 기대하기 전에 그렇게 말해 두는 것이 좋습니다.

호스트 캐시: 배치가 도움이 되는지를 결정한다

호스트 캐시는 공유 캐시를 서버에 둔다. 서브넷을 넘어 의미가 있는 유일한 모드이며, 클라이언트끼리 통신할 수 없을 때 동작하는 유일한 모드입니다. 첫 질문은 그 서버가 어디에 있는지입니다. 호스트 캐시가 원본과 같은 제한된 링크를 넘어 접근된다면 바이트를 올겼을 뿐 문제를 올긴 것이 아닙니다.

읽는 사람 가까이에 두고, 소유자를 지정하고, 디스크는 전체 공유가 아니라 작업 집합에 맞춰 산정하십시오. Microsoft의 BranchCache 개요에는 두 모드와 클라이언트 동작이 설명되어 있으며, 사람들이 잊는 부분도 포함됩니다. 클라이언트는 캐시된 데이터를 사용하기 전에 권한 부여와 콘텐츠 정보를 위해 여전히 원본에 접속합니다.

배포는 세 역할을 함께 계획하는 것이지 확인란 하나가 아닙니다. 원본 서버가 콘텐츠의 해시를 게시하고, 호스트 캐시가 사용하도록 설정되어 검색 가능해지며, 클라이언트가 그것을 사용하도록 구성됩니다. 서버 쪽에서는 PowerShell에서 알아볼 수 있습니다.

Enable-BCHostedServer -RegisterSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode, HostedCacheServerList

클라이언트에서는 이름이 지정된 서버를 가리키거나 서비스 연결 지점을 통해 검색하도록 두십시오. 그런 다음 정책이 적용되었다고 가정하지 말고 실제로 선택된 모드를 확인하십시오.

Enable-BCHostedClient -ServerNames cache1.corp.example -UseSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode

여전히 원본에 도달하는 것

캐시는 권한 부여를 없애지 않습니다. 파일을 읽을 권한이 없는 클라이언트가 다른 사람이 캐시했다는 이유로 접근 권한을 얻지는 않으며, 원본은 여전히 권한 부여 질문에 답하고 캐시 조회를 가능하게 하는 콘텐츠 정보를 제공합니다. 원본에 도달할 수 없으면 캐시된 복사본만으로는 오프라인 공유가 되지 않습니다.

콘텐츠 변경도 이 가정을 조용히 깨뜼립니다. 다시 저장되거나 다시 인코딩되거나 백업 제품이 건드린 파일은 캐시된 해시와 더 이상 일치하지 않을 수 있으며, 다음 읽기는 원본으로 돌아갑니다. 이것은 올바른 동작이며, 작업 집합이 매시간 바뀜는 캐시가 거의 효과를 내지 못하는 이유이기도 합니다.

축출이 세 번째 한계입니다. 캐시는 유한하므로 큰 작업 집합은 오래된 콘텐츠를 밀어냅니다. 이점은 다시 읽기가 축출 전에 일어나는지에 달려 있습니다. 전체 공유에 맞춰 캐시를 산정하는 것은 기술적으로 올바른 배포에 실망하는 흐한 방식입니다.

두 번의 검색과 한 번의 업로드로 받아들인다

올바른 세 가지 흐름을 시험하고 각각이 무엇을 보여 주는지 적어 두십시오. 클라이언트에서 대표 파일을 처음 검색한 결과를 원본 링크와 사용자의 시계 양쪽에서 측정합니다. 같은 배치 그룹의 두 번째 클라이언트에서 같은 변경되지 않은 파일을 검색합니다. 새 파일의 업로드 한 번은 개선을 보여서는 안 되며, 캐시가 한 번도 하지 않은 일의 공로를 인정받지 않았음을 확인합니다.

두 번째 검색에서도 대부분의 바이트가 원본 링크를 건널다면 캐시는 사용되지 않는 것이며, 원인은 보통 잘못된 모드의 클라이언트, 원본의 해시 게시 누락, 또는 제한된 링크의 반대편에 있는 호스트 캐시입니다. 이것은 세 가지 다른 수정이며, 그중 네트워크 배치에 관한 것은 하나뿐입니다.

그런 다음 처음 불만과 같은 형태로 결론을 진술하십시오. 이 원본에서 이 읽는 사람들에게 이르는, 변경되지 않은 콘텐츠의 반복 다운로드는 이 캐시가 처리합니다. 공유의 나머지 모든 것은 그대로이며, 업로드, 폴더 열거, 그리고 여전히 자체 답이 필요한 오프라인 이야기도 포함됩니다.