Azure Files 메타데이터 캐싱과 로컬 지사 캐시

VPN을 통한 느린 Azure Files 액세스에는 두 가지 변경이 제안되며, 각각 줄이는 대상이 다릅니다. 서비스 측 메타데이터 캐시는 적격 작업을 서버에 더 저렴하게 만듭니다. 로컬 지사 캐시는 바이트와 작업을 사용자에게 더 가깝게 옮깁니다. 가격표나 보도자료로 둘 중 하나를 고르면, 공유는 벤치마크에서 더 빨라지고 아침 아홉 시에는 그대로인 결과가 됩니다.

두 캐시, 두 가지 지연

두 옵션 모두 캐시라는 단어 아래 나타나며, 혼란이 시작되는 지점입니다. 둘은 네트워크의 반대편에 있습니다.

Microsoft의 SMB 성능 지침 은 적격 SSD 공유에 대한 메타데이터 캐싱과 그에 따르는 등록 단계를 설명합니다. 적격성과 기능 상태는 실제 스토리지 계정에 속하므로, 이 년 전 미리 보기 발표가 아니라 현재 페이지를 읽으십시오.

대기를 세 부분으로 나누기

느린 디렉터리 목록에는 세 가지 비용 요소가 있고, 각각 다른 해결책에 반응합니다. 요청당 서비스 처리 시간, VPN을 넘는 종속 왕복 횟수, 그리고 이동해야 하는 페이로드가 있습니다. 서비스 측 캐시는 첫 번째를 공격합니다. 서버 측에서는 아무것도 두 번째를 공격하지 않습니다.

그래서 공유가 더 나은 서비스 지표를 보여도 사용자의 파일 선택기는 여전히 팔 초 동안 멈춰 있을 수 있습니다.

각 옵션이 제자리를 얻는 곳

워크로드가 메타데이터 위주이고 적격 SSD 공유에 많은 열기, stat 호출, 디렉터리 열거가 있다면 서비스 측 캐싱이 저렴한 실험입니다. 새 인프라도, 사용자가 공유에 도달하는 방식의 변경도 필요하지 않습니다.

워크로드가 대화형이고 지연에 묶여 있다면, 문서화된 동기화 모델을 갖춘 지원되는 로컬 서버 설계가 정직한 옵션입니다. 이는 자체 운영 비용이 있는 다른 아키텍처이며 스위치가 아닙니다.

두 옵션 모두 바꾸지 않는 것

SMB 서명과 암호화는 계속 적용되며 계속 비용이 듭니다. 액세스 제어는 여전히 사용자별로 해결되므로 캐시된 복사본이 권한 부여를 단순화하지 않습니다. 사이트 간 일관성에는 여전히 정의된 모델이 필요합니다. 지사 로컬 읽기와 클라우드 측 쓰기가 무언가에 합의해야 하기 때문입니다. 그리고 오프라인 액세스는 클라이언트 설정으로 남으며 서버 기능의 부작용이 아닙니다.

서비스 기능이 WAN 왕복을 없앤다고 누군가 약속한다면, 그것이 가장 먼저 검증할 주장입니다.

사용자가 불평하는 작업에 대고 측정하십시오

합성 복사본이 아니라 정확한 작업의 시간을 재십시오. 지사 클라이언트에서 Measure-Command { Get-ChildItem \\files\projects -Recurse } 은 전후로 비교할 수 있는 숫자를 주고, Get-SmbMultichannelConnection 는 클라이언트가 하나 이상의 경로를 쓰는지 보여 줍니다. 같은 시간대의 서비스 측 지연 지표 옆에 두십시오.

공유, 클라이언트 위치, VPN 경로, 보안 정책을 일정하게 유지하십시오. 그렇지 않으면 기능이 아니라 변경 창을 측정하게 됩니다. 파일 수와 크기 분포도 기록하십시오. 작은 파일 워크로드와 대량 복사는 전혀 다른 지렛대에 반응합니다.

가질 가치가 있는 결과는 실제로 느렸던 경계에 맞춘 변경이며, 그 운영 비용과 일관성 비용이 적혀 있는 것입니다. 슬라이드의 더 큰 스토리지 IOPS 숫자는 그 결과가 아닙니다.