Skip to main content
본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

FlexCache 쓰기 저장 사용 사례

기여자
PDF

쓰기 프로파일은 다시 쓰기 가능 FlexCache에 가장 적합합니다. 작업을 테스트하여 Write-back 또는 write-around가 최상의 성능을 제공하는지 확인해야 합니다.

참고 Write-back은 write-around를 대체하는 것이 아닙니다. 쓰기 작업이 많은 워크로드를 처리하기 위해 쓰기팅을 설계했지만 여전히 많은 워크로드에서 쓰기 작업이 더 적합합니다.

타겟 워크로드

파일 크기

파일 크기는 및 파일 호출 사이에 실행된 쓰기 수보다 덜 OPEN CLOSE 중요합니다. 작은 파일은 기본적으로 호출 수가 적기 때문에 WRITE 다시 쓰기에 적합하지 않습니다. 큰 파일은 및 호출 사이에 더 많은 쓰기를 가질 수 OPEN CLOSE 있지만, 이는 보장되지 않습니다.

쓰기 크기

클라이언트에서 쓸 때 쓰기 호출 이외의 다른 NAS 호출이 관련됩니다.

  • CREATE

  • OPEN

  • CLOSE

  • READDIR/READDIRPLUS

  • SETATTR: SETATTR , 또는 만 수정하거나 캐시에서 처리되는 호출입니다. mtime atime ctime

이러한 호출은 오리진에서 처리되어야 하며, 작업 중인 파일에 대해 Write-back 지원 캐시에 누적된 더티 데이터의 Write-Back을 트리거해야 합니다. 파일 입출력은 쓰기가 완료될 때까지 정지됩니다.

이러한 호출이 WAN을 통과해야 한다는 것을 알면 다시 쓰기에 적합한 워크로드를 식별하는 데 도움이 됩니다. 일반적으로 <write-size,above>가 발급되는 다른 호출 중 하나를 사용하지 않고 및 호출 간에 수행할 수 있는 쓰기가 많을수록 OPEN CLOSE Write-back 성능이 향상됩니다.

쓰기 후 읽기

지금까지 FlexCache에서 쓰기 후 읽기 워크로드의 성능은 좋지 않았습니다. 이는 9.15.1 이전의 write-around 동작 방식 때문이다. WRITE`파일에 대한 호출은 오리진에서 커밋되어야 하며, 후속 `READ 호출은 데이터를 다시 캐시로 가져와야 합니다. 이로 인해 두 작업 모두 WAN 페널티가 발생합니다. 따라서 FlexCache의 경우 쓰기 후 읽기 워크로드는 쓰기 방지 모드로 사용하지 않습니다. 9.15.1에 쓰기 저장 기능이 도입됨에 따라 데이터가 캐시에서 커밋되고 캐시에서 즉시 읽을 수 있으므로 WAN 페널티가 없어집니다. 워크로드에 FlexCache 볼륨에 쓰기 후 읽기 가 포함된 경우에는 write-back 모드로 작동하도록 캐시를 구성해야 합니다.

팁 쓰기 후 읽기가 작업 부하에서 중요한 부분인 경우 다시 쓰기 모드로 작동하도록 캐시를 구성해야 합니다.
쓰기 후 쓰기

파일이 캐시에 더티 데이터를 축적하면 캐시는 데이터를 원본에 비동기적으로 씁니다. 이렇게 되면 원래 위치로 다시 플러시될 때까지 계속 대기 중인 더티 데이터로 파일이 닫히는 경우가 발생합니다. 방금 닫은 파일에 대해 다른 열기 또는 쓰기가 들어오면 더티 데이터가 모두 오리진으로 플러시될 때까지 쓰기가 일시 중단됩니다.

지연 시간 고려

FlexCache가 다시 쓰기 모드로 작동하는 경우 캐시와 오리진 간에 지연 시간이 증가하므로 NAS 클라이언트에 더 유용합니다. 하지만 지연 시간이 짧은 환경에서 얻을 수 있는 이점보다 쓰기 작업의 오버헤드가 훨씬 더 중요합니다. 일부 NetApp 테스트에서는 캐시와 원본 간 지연 시간이 8ms를 약간 초과하기 시작했으며, 이 지연 시간은 워크로드에 따라 달라지므로 이점을 테스트해 보십시오.

다음 그래프는 NetApp 랩 테스트에서 Write-back에 대한 반환 지점을 보여 줍니다. x`축은 파일 크기이고 `y 축은 경과 시간입니다. 이 테스트에서는 NFSv3, 256KB 및 64ms의 WAN 지연 시간으로 마운트했습니다. rsize wsize 이 테스트는 캐시와 오리진에 대해 작은 ONTAP Select 인스턴스와 단일 스레드 쓰기 작업을 사용하여 수행되었습니다. 결과는 다를 수 있습니다.

반품 시점
중요함 클러스터 내 캐싱에는 Write-back을 사용해서는 안 됩니다. 클러스터 내 캐싱은 오리진과 캐시가 같은 클러스터에 있을 때 발생합니다.