를 클릭합니다 snapshot-only tiering-policy 액티브 파일 시스템과 공유되지 않는 블록에만 적용됩니다. 기본적으로 데이터베이스 백업의 계층화가 이루어집니다. 스냅샷이 생성되고 블록이 덮어써지면 블록이 계층화 대상이 되어 스냅샷 내에만 존재하는 블록이 됩니다. 이전 지연 시간 snapshot-only 블록은 냉각된 것으로 간주됩니다 tiering-minimum-cooling-days 볼륨 설정입니다. ONTAP 9.8의 범위는 2-183일입니다.

많은 데이터 세트의 변경률이 낮기 때문에 이 정책에서의 절약 효과가 최소화됩니다. 예를 들어 ONTAP에서 관찰되는 일반적인 데이터베이스의 변경률은 주당 5% 미만입니다. 데이터베이스 아카이브 로그는 광범위한 공간을 차지할 수 있지만 일반적으로 활성 파일 시스템에 계속 존재하므로 이 정책에 따라 계층화할 대상이 아닙니다.

를 클릭합니다 auto 계층화 정책을 통해 액티브 파일 시스템 내의 블록뿐만 아니라 스냅샷별 블록까지 계층화를 확장할 수 있습니다. 블록이 냉각된 것으로 간주되기 전의 지연은 에 의해 제어됩니다 tiering-minimum-cooling-days 볼륨 설정입니다. ONTAP 9.8의 범위는 2-183일입니다.

이 접근 방식을 사용하면 에서 제공되지 않는 계층화 옵션을 사용할 수 있습니다 snapshot-only 정책. 예를 들어, 데이터 보호 정책에서는 특정 로그 파일을 90일간 보존해야 할 수 있습니다. 냉각 기간을 3일로 설정하면 3일이 지난 로그 파일이 성능 계층에서 계층화됩니다. 이렇게 하면 성능 계층에서 상당한 공간을 확보하면서 90일 분량의 데이터를 확인하고 관리할 수 있습니다.

를 클릭합니다 none 계층화 정책을 통해 추가 블록이 스토리지 계층에서 계층화되지 않게 하고, 용량 계층에 있는 데이터는 읽을 때까지 용량 계층에 유지됩니다. 블록이 읽히면 해당 블록을 다시 가져와 성능 계층에 배치합니다.

을 사용하는 주된 이유 none 계층화 정책은 블록이 계층화되지 않도록 하는 것이지만 시간이 지남에 따라 정책을 변경하는 것이 유용할 수 있습니다. 예를 들어, 특정 데이터 세트는 용량 계층에 광범위하게 계층화되지만, 전체 성능 기능에 대한 예기치 않은 요구사항이 발생한다고 가정해 보겠습니다. 추가 계층화를 방지하고 입출력이 증가함에 따라 다시 읽히는 모든 블록이 성능 계층에 유지되는지 확인하도록 정책을 변경할 수 있습니다.

를 클릭합니다 all 계층화 정책이 을 대체합니다 backup ONTAP 9.6 기준 정책. 를 클릭합니다 backup 정책은 데이터 보호 볼륨에만 적용됩니다. 즉, SnapMirror 또는 NetApp SnapVault 대상을 의미합니다. 를 클릭합니다 all 정책은 동일하게 작동하지만 데이터 보호 볼륨으로 제한되지 않습니다.

이 정책을 사용하면 블록이 즉시 쿨 상태로 간주되어 용량 계층에 즉시 계층화할 수 있습니다.

이 정책은 장기 백업에 특히 적합합니다. HSM(Hierarchical Storage Management)의 한 형태로도 사용할 수 있습니다. 이전에는 HSM을 사용하여 파일 자체를 파일 시스템에 표시하면서 파일의 데이터 블록을 테이프로 계층화했습니다. 를 포함하는 FabricPool 볼륨 all 정책을 사용하면 로컬 스토리지 계층에서 공간을 거의 사용하지 않으면서 표시 가능하고 관리 가능한 상태로 파일을 저장할 수 있습니다.