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

ONTAP FlexCache write-back 지침

10/15/2026 기여자

PDF

FlexCache 쓰기 저장에는 원본과 캐시 간의 많은 복잡한 상호작용이 포함됩니다. 최적의 성능을 얻으려면 환경이 다음 지침을 따라야 합니다. 이 가이드라인은 콘텐츠 생성 당시 사용 가능한 최신 주요 ONTAP 버전(ONTAP 9.17.1)을 기반으로 합니다.

비운영 환경에서 운영 워크로드를 테스트하는 것이 가장 좋습니다. 이 지침을 벗어나는 FlexCache Write-Back을 구현할 경우 더욱 중요합니다.

다음 지침은 NetApp에서 내부적으로 잘 테스트되었습니다. 이 호텔 안에 머무시는 것이 좋습니다. 그렇지 않으면 예기치 않은 동작이 발생할 수 있습니다.

ONTAP 9.17.1P1에서는 FlexCache 쓰기 저장 기능에 대한 중요한 개선 사항이 도입되었습니다. 9.17.1P1 이후에는 원본 클러스터와 캐시 클러스터 모두에서 현재 권장되는 릴리스를 실행하는 것이 강력히 권장됩니다. 9.17.1 코드라인을 실행할 수 없는 경우, 다음으로 제안되는 릴리스는 최신 P 릴리스인 9.16.1입니다. ONTAP 9.15.1에는 FlexCache 쓰기 저장에 필요한 모든 수정 사항과 개선 사항이 포함되어 있지 않으므로 프로덕션 워크로드에는 권장되지 않습니다.
ONTAP 9.19.1 GA, 9.18.1P2, 9.17.1P3, 9.16.1P10 및 각 릴리스 제품군의 이후 P 릴리스에서는 다중 구성 요소 FlexCache 쓰기 백 캐시가 지원됩니다. 이전 ONTAP 릴리스에서는 전체 FlexCache 볼륨에 대해 단일 구성 요소를 사용해야 합니다. 이전 릴리스에서 다중 구성 요소 FlexCaches를 사용하면 캐시에서 원치 않는 데이터 제거가 발생할 수 있습니다.
100GB 미만의 파일에 대해 테스트를 실행했으며, 캐시와 원본 간의 WAN 왕복 시간이 200ms를 초과하지 않도록 했습니다. 이러한 한도를 벗어나는 작업 부하로 인해 예상치 못한 성능 특성이 나타날 수 있습니다.
SMB 대체 데이터 스트림에 쓰면 주 파일이 캐시에서 제거됩니다. 기본 파일의 모든 더티 데이터를 오리진으로 플러시해야 해당 파일에 대해 다른 작업을 수행할 수 있습니다. 대체 데이터 스트림도 오리진으로 전달됩니다.
파일 이름을 바꾸면 파일이 캐시에서 제거됩니다. 파일의 모든 더티 데이터를 오리진으로 플러시해야 해당 파일에 대해 다른 작업을 수행할 수 있습니다.
이때 write-back 지원 FlexCache 볼륨의 파일에 대해 변경하거나 설정할 수 있는 유일한 속성은 다음과 같습니다.
- 타임스탬프
- 모드 비트
- NT ACL을 선택합니다
- 소유자
- 그룹
- 크기
  
  변경되거나 설정된 다른 특성은 오리진으로 전달되어 캐시에서 파일을 제거할 수 있습니다. 캐시에서 다른 속성을 변경하거나 설정해야 할 경우, 어카운트 팀에 PVR을 개설하도록 요청하십시오.
오리진에서 생성된 스냅샷으로 인해 해당 오리진 볼륨과 연결된 모든 write-back 지원 캐시에서 미처리 더티 데이터를 모두 불러옵니다. 이렇게 하려면 많은 양의 쓰기 저장 작업이 진행 중인 경우 이러한 더티 파일을 제거하는 데 시간이 걸릴 수 있으므로 여러 번 작업을 다시 시도해야 할 수 있습니다.
쓰기를 위한 SMB 기회 잠금(Oplock)은 쓰기 백이 활성화된 FlexCache 볼륨에서 지원되지 않습니다.

라이트백 캐시는 원본 볼륨의 여유 공간이 20% 이하로 떨어지면 자동으로 쓰기 우회 모드로 전환됩니다. 이는 원본에서 공간이 부족해져 라이트백 지원 캐시에 더티 데이터가 고립되는 결과를 방지하는 데 도움이 됩니다. 원본 볼륨이 초과 프로비저닝된 경우, 논리적으로 프로비저닝된 크기가 어그리게이트의 여유 공간보다 큽니다. 20% 임계값은 원본 볼륨의 사용 가능한 공간과 어그리게이트의 사용 가능한 물리적 용량을 모두 기준으로 평가됩니다. 사용 가능한 공간이 이미 해당 임계값보다 낮을 때 percent-used 및 `capacity`는 여전히 0%를 표시할 수 있습니다.

다음 예시는 과도하게 프로비저닝된 원본 볼륨입니다. 데이터가 거의 기록되지 않지만, 애그리게이트가 전체 논리적 크기를 지원할 수 없습니다:

ORIGIN::> vol show -volume origin_volume -fields percent-used,available,size
vserver             volume           size    available percent-used
------------------- ---------------- ------- --------- ------------
origin_svm          origin_volume    19.70TB 1.33TB    0%

`percent-used`은(는) 0%이지만 사용 가능한 공간은 19.70TB 중 1.33TB이며, 이는 1.33 / 19.70, 즉 약 7%가 사용 가능함을 의미한다는 점에 유의하십시오. 이는 이미 20% 임계값 미만이므로 이 오리진의 write-back 캐시는 write-around 모드로 전환됩니다.

ORIGIN::> df -h origin_volume
Filesystem               total       used      avail   capacity  Mounted on       Vserver
/vol/origin_volume/      18TB        515MB     1363GB         0%    ---           origin_svm

2 entries were displayed.

`capacity`도 0%이고 515MB만 사용된다는 점에 유의하십시오. 사용 가능한 공간은 18TB 중 1363GB로, 파일 시스템의 약 7%입니다. 백분율 열은 저장된 데이터가 얼마나 적은지 보여줍니다. 애그리게이트가 실제로 제공할 수 있는 볼륨 크기가 얼마나 되는지는 보여주지 않습니다.

낮은 대역폭 및/또는 손실이 많은 클러스터 간 네트워크는 FlexCache 라이트백 성능에 상당한 악영향을 미칠 수 있습니다. 특정 대역폭 요구 사항은 없지만 워크로드에 따라 크게 달라지므로 캐시와 원본 간의 클러스터 간 링크 상태를 확인하는 것이 강력히 권장됩니다. 네트워크에 패킷 손실이 발생하기 쉽고 ONTAP 9.19.1 이상을 실행 중인 경우, 성능 향상을 위해 "TCP RACK" 사용을 고려해 보십시오.

ONTAP FlexCache write-back 지침

Creating your file...