애플리케이션 환경에서 씬 프로비저닝을 사용할 때는 데이터 변경률이 예기치 않게 증가할 수 있으므로 주의해야 합니다. 예를 들어, 데이터베이스 테이블의 인덱싱이 다시 수행되거나 VMware 게스트에 대규모 패치가 적용되는 경우 스냅샷으로 인한 공간 사용량이 급격히 증가할 수 있습니다. 백업 파일이 잘못된 위치에 저장되면 매우 짧은 시간 안에 엄청난 양의 데이터가 손실될 수 있습니다. 마지막으로, LUN의 사용 가능한 공간이 예기치 않게 부족해지는 경우 일부 애플리케이션을 복구하기 어려울 수 있습니다.

ASA r2에서는 볼륨 자동 확장이나 스냅샷 자동 삭제와 같은 ONTAP 기능 대신 씬 프로비저닝, 사전 예방적 모니터링, *LUN 크기 조정 정책*을 통해 이러한 위험을 완화합니다. 관리자는 다음과 같이 해야 합니다.

ASA r2는 WAFL 기반 볼륨 옵션을 추상화하는 SAN 전용 아키텍처이므로 부분 예비 용량 설정을 사용하지 않습니다. 대신 공간 효율성과 덮어쓰기 방지는 LUN 수준에서 관리됩니다. 예를 들어 스토리지 장치에서 250GiB LUN을 프로비저닝한 경우 스냅샷은 사전에 동일한 양의 공간을 예약하는 대신 실제 블록 변경량을 기준으로 공간을 사용합니다. 이로써 부분준비금을 사용하는 기존 ONTAP 환경에서 흔히 발생했던 대규모 고정 예약이 필요 없어집니다.

ASA r2의 압축 및 중복 제거는 기존의 씬 프로비저닝 메커니즘이 아니라 공간 효율성 기술입니다. 이러한 기능은 중복 데이터를 제거하고 블록을 압축하여 물리적 저장 공간을 줄여주므로, 기존 저장 용량으로는 불가능했던 더 많은 논리적 데이터를 저장할 수 있습니다.

예를 들어, 50TiB 크기의 데이터셋은 30TiB로 압축되어 20TiB의 물리적 공간을 절약할 수 있습니다. 응용 프로그램 관점에서 보면, 디스크에서 30TiB만 차지하더라도 여전히 50TiB의 데이터가 있는 셈입니다.

ASA r2 환경에서 씬 프로비저닝은 삭제된 블록이 회수되지 않으면 시간이 지남에 따라 효율성이 떨어질 수 있습니다. TRIM/UNMAP 명령어를 사용하여 공간을 해제하거나 (ASMRU - 자동 공간 관리 및 복구 유틸리티를 통해) 0으로 덮어쓰지 않는 한, 삭제된 데이터는 계속해서 물리적 용량을 차지합니다. 대부분의 Oracle 데이터베이스 환경에서는 데이터 파일이 생성 시 전체 크기로 미리 할당되기 때문에 씬 프로비저닝의 이점이 제한적입니다.

LVM 구성을 신중하게 계획하면 효율성을 향상시키고 스토리지 프로비저닝 및 LUN 크기 조정 필요성을 최소화할 수 있습니다. Veritas VxVM이나 Oracle ASM과 같은 LVM을 사용하는 경우, 기본 LUN은 필요할 때만 사용되는 익스텐트로 분할됩니다. 예를 들어, 데이터 세트의 초기 크기가 2TiB이지만 시간이 지남에 따라 10TiB까지 증가할 수 있는 경우, 이 데이터 세트는 LVM 디스크 그룹으로 구성된 10TiB의 씬 프로비저닝 LUN에 배치할 수 있습니다. 생성 시에는 2TiB의 공간만 차지하며, 데이터 증가에 맞춰 익스텐트가 할당될 때만 추가 공간을 요구합니다. 이 과정은 공간을 모니터링하는 한 안전합니다.