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

Oracle 데이터베이스를 사용한 씬 프로비저닝

05/03/2024 기여자

Oracle 데이터베이스에 대한 씬 프로비저닝은 결국 실제로 사용할 수 있는 공간보다 더 많은 공간을 스토리지 시스템에 구성하게 되므로 신중한 계획이 필요합니다. 올바르게 수행하면 상당한 비용 절감 및 관리 효율성 향상을 얻을 수 있기 때문에 이러한 노력을 기울일 가치가 있습니다.

씬 프로비저닝은 다양한 형태로 제공되며 ONTAP이 엔터프라이즈 애플리케이션 환경에 제공하는 여러 기능 중 핵심이 됩니다. 또한 씬 프로비저닝은 효율성 기술과 밀접하게 관련되어 있습니다. 즉, 스토리지 시스템에서 기술적으로 있는 것보다 더 많은 논리적 데이터를 저장할 수 있다는 것입니다.

거의 모든 경우 스냅샷 사용에는 씬 프로비저닝이 수반됩니다. 예를 들어, NetApp 스토리지의 일반적인 10TB 데이터베이스에는 약 30일 스냅샷이 포함되어 있습니다. 이 방식을 통해 액티브 파일 시스템에서 약 10TB의 데이터가 표시되고 스냅샷 전용으로는 300TB가 표시됩니다. 보통 총 310TB의 스토리지가 12TB~15TB의 공간에 상주합니다. 원래 데이터의 변경사항만 저장되기 때문에 액티브 데이터베이스가 10TB를 소비하며 나머지 300TB 데이터에는 2TB~5TB의 공간만 필요합니다.

클로닝도 씬 프로비저닝의 한 예입니다. 주요 NetApp 고객은 개발에 사용하기 위해 80TB 데이터베이스의 클론 40개를 생성했습니다. 이 클론을 사용하는 40명 모두가 모든 데이터 파일의 모든 블록을 덮어쓴다면 3.2PB를 넘는 스토리지가 필요할 것입니다. 변경사항만 드라이브에 저장되기 때문 실제로 턴오버가 낮으며 총체적인 공간 요구사항은 40TB에 가깝습니다.

공간 관리

데이터 변경률이 예기치 않게 증가할 수 있기 때문에 애플리케이션 환경에서 씬 프로비저닝을 수행할 때 주의를 기울여야 합니다. 예를 들어 데이터베이스 테이블을 다시 인덱싱하거나 VMware 게스트에 대규모 패치를 적용하면 스냅샷으로 인한 공간 소비가 빠르게 증가할 수 있습니다. 백업을 잘못 배치하면 매우 짧은 시간에 많은 양의 데이터를 쓸 수 있습니다. 마지막으로, 파일 시스템에 예기치 않게 사용 가능한 공간이 부족할 경우 일부 응용 프로그램을 복구하기가 어려울 수 있습니다.

하지만 을 신중하게 구성하면 이러한 위험을 해결할 수 있습니다 volume-autogrow 및 snapshot-autodelete 정책. 그 이름이 시사하듯 이들 옵션은 사용자가 스냅샷에 의해 소비되는 공간을 자동으로 삭제하거나 추가 데이터를 수용하기 위해 볼륨을 늘리는 정책을 수립하도록 지원합니다. 다양한 옵션을 사용할 수 있으며 요구사항은 고객에 따라 다릅니다.

를 참조하십시오 "논리적 스토리지 관리 설명서" 이러한 기능에 대한 자세한 내용은

부분 예약

부분 예약은 공간 효율성과 관련하여 볼륨에서의 LUN 동작을 칭합니다. 옵션을 선택합니다 fractional-reserve 100%로 설정하면 볼륨의 모든 데이터에서 볼륨의 공간이 소진되지 않으며 모든 데이터 패턴의 턴오버가 100%가 됩니다.

예를 들어 1TB 볼륨에서 단일 250GB LUN의 데이터베이스를 가정해 보겠습니다. 스냅샷을 생성하면 어떤 이유로든 볼륨이 공간을 소진하지 않도록 보장하기 위해 즉시 볼륨에서 250GB의 공간이 추가로 예약됩니다. 데이터베이스 볼륨의 모든 바이트에 덮어쓰기를 해야 하는 경우는 거의 없기 때문에 부분 예약 사용은 일반적으로 리소스를 낭비하는 것입니다. 일어나지 않을 경우를 위해 공간을 예약할 필요는 없습니다. 그럼에도, 고객이 스토리지 시스템에서 공간 소비를 모니터링할 수 없으며 공간이 절대 소진되지 않도록 할 경우에는 스냅샷을 사용하기 위해 100% 부분 예약이 필요할 것입니다.

압축 및 중복제거

압축과 중복제거는 둘 다 씬 프로비저닝의 한 형태입니다. 예를 들어, 50TB의 데이터가 30TB까지 압축될 수 있다면 20TB가 절약될 것입니다. 압축의 이점을 얻기 위해서는 이 20TB의 일부를 다른 데이터에 사용하거나 50TB보다 적은 용량의 스토리지 시스템을 구매해야 합니다. 그 결과 스토리지 시스템에서 기술적으로 지원되는 것보다 많은 데이터를 저장할 수 있게 됩니다. 데이터 관점에서 보면 드라이브에서 30TB만 점유되어 있어도 50TB의 데이터가 있는 것입니다.

데이터 세트의 압축 가능성은 언제든 바뀔 수 있으며 이로 인해 실제 공간의 소비가 증가될 수 있습니다. 이렇게 소비가 증가하므로 모니터링과 사용 측면에서 압축을 다른 형태의 씬 프로비저닝과 마찬가지로 관리해야 합니다 volume-autogrow 및 snapshot-autodelete.

압축과 중복제거에 대한 자세한 내용은 efficiency.html 링크를 참조하십시오

압축 및 분할 예약

압축은 씬 프로비저닝의 한 형태입니다. 부분 예약은 압축 사용에 영향을 미치며, 스냅샷 생성 전에 공간을 예약한다는 점에 유의해야 합니다. 일반적으로 부분 예약은 스냅샷이 있는 경우에만 중요합니다. 스냅샷이 없는 경우 부분 예약은 중요하지 않습니다. 압축의 경우는 이와 다릅니다. 압축을 통해 볼륨에서 LUN이 생성되는 경우 ONTAP은 스냅샷을 수용하기 위해 공간을 보존합니다. 이 동작은 구성 단계에서 혼란을 줄 수 있지만 이는 예상할 수 있는 것입니다.

예를 들어, 스냅샷 없이 2.5GB까지 압축된 5GB LUN을 가지고 있는 10GB 볼륨을 생각해 보겠습니다. 두 가지 시나리오를 생각할 수 있습니다.

부분 예약 = 100, 결과: 7.5GB 활용률
부분 예약 = 0, 결과: 2.5GB 활용률

첫 번째 시나리오는 현재 데이터의 경우 2.5GB의 공간 소비와 스냅샷 사용을 예상하여 100% 소스 턴오버를 지원하기 위한 5GB의 공간이 포함됩니다. 두 번째 시나리오는 여분의 공간을 예약하지 않습니다.

혼란스러워 보이는 이 상황은 사실상 발생할 확률이 낮습니다. 압축은 씬 프로비저닝을 시사하며 LUN 환경에서 씬 프로비저닝을 수행하려면 부분 예약이 필요합니다. 압축할 수 없는 무언가로 인해 압축된 데이터를 항상 덮어쓸 수 있습니다. 즉, 압축을 위해서는 볼륨을 씬 프로비저닝해야 절약 효과를 거둘 수 있습니다.

NetApp는 * 다음과 같은 예약 구성을 권장합니다.
설정 fractional-reserve 과 함께 기본 용량 모니터링이 있는 경우 0으로 설정합니다 volume-autogrow 및 snapshot-autodelete.
설정 fractional-reserve 모니터링 기능이 없거나 어떤 상황에서도 공간을 소진하는 것이 불가능한 경우 100까지.

여유 공간 및 LVM 공간 할당

파일 시스템 환경에서 액티브 LUN 씬 프로비저닝의 효율성은 데이터가 삭제되면 시간이 지남에 따라 손실될 수 있습니다. 삭제된 데이터가 0으로 덮어 쓰이지 않는 한(도 참조 "아스크루주식회사" 또는 TRIM/UNMAP 공간 재확보와 함께 공간이 해제되면 "지워진" 데이터는 파일 시스템에서 더 많은 할당되지 않은 공백을 차지합니다. 게다가 데이터 파일이 생성 당시의 파일 최대 크기로 초기화되기 때문에 많은 데이터베이스 환경에서는 액티브 LUN의 씬 프로비저닝의 사용이 제한적입니다.

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