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

LUN 배치

11/20/2024 기여자

PDF

ONTAP 볼륨 내에 데이터베이스 LUN을 최적으로 배치하는 것은 주로 다양한 ONTAP 기능을 사용하는 방법에 따라 달라집니다.

볼륨

ONTAP를 처음 접하는 고객에게 혼동을 주는 한 가지 일반적인 점은 일반적으로 "볼륨"이라고 하는 FlexVol을 사용하는 것입니다.

볼륨이 LUN이 아닙니다. 이러한 용어는 클라우드 공급자를 포함한 다른 여러 공급업체 제품과 동일하게 사용됩니다. ONTAP 볼륨은 단순한 관리 컨테이너입니다. 이러한 애플리케이션은 자체적으로 데이터를 제공하지 않으며 공간을 점유하지 않습니다. 파일 또는 LUN용 컨테이너이며, 관리 효율성을 개선하고 단순화하기 위해 존재하며, 특히 규모에 맞게 사용됩니다.

볼륨 및 LUN

관련 LUN은 일반적으로 단일 볼륨에 함께 배치됩니다. 예를 들어, 10개의 LUN이 필요한 데이터베이스에서는 일반적으로 10개의 LUN이 모두 동일한 볼륨에 배치되어 있습니다.

볼륨에 대한 LUN의 1:1 비율을 사용하는 것은 볼륨당 하나의 LUN을 사용하는 것은 공식적인 모범 사례가 아닙니다.
대신, 볼륨을 워크로드 또는 데이터 세트의 컨테이너로 보아야 합니다. 볼륨당 하나의 LUN이 있거나 여러 LUN이 있을 수 있습니다. 정답은 관리 효율 요구사항에 따라 다릅니다.
불필요한 볼륨 수에 걸쳐 LUN을 분산시키면 스냅샷 작업, UI에 표시되는 개체 수가 너무 많아지고 LUN 제한에 도달하기 전에 플랫폼 볼륨 제한에 도달할 수 있는 등의 작업에 추가적인 오버헤드 및 스케줄링 문제가 발생할 수 있습니다.

볼륨, LUN 및 스냅샷

스냅샷 정책과 일정은 LUN이 아닌 볼륨에 배치됩니다. 10개의 LUN으로 구성된 데이터 세트에는 해당 LUN이 동일한 볼륨에 공존할 경우 단일 스냅샷 정책만 필요합니다.

또한 특정 데이터 세트에 대한 모든 관련 LUN을 단일 볼륨에 함께 배치하면 원자 단위 스냅샷 작업이 가능합니다. 예를 들어, 10개의 LUN에 상주하는 데이터베이스 또는 10개의 서로 다른 OS로 구성된 VMware 기반 애플리케이션 환경은 기본 LUN이 모두 단일 볼륨에 배치되어 있는 경우 일관된 단일 오브젝트로 보호할 수 있습니다. 서로 다른 볼륨에 배치되는 경우 동시에 예약된 경우에도 스냅샷이 100% 동기화될 수도 있고 그렇지 않을 수도 있습니다.

경우에 따라 복구 요구 사항으로 인해 관련 LUN 세트를 두 개의 다른 볼륨으로 분할해야 할 수도 있습니다. 예를 들어, 데이터베이스에 데이터 파일에는 LUN 4개와 로그에는 LUN 2개가 포함될 수 있습니다. 이 경우 4개의 LUN이 있는 데이터 파일 볼륨과 2개의 LUN이 포함된 로그 볼륨이 최상의 옵션이 될 수 있습니다. 그 이유는 독립적인 복구 기능입니다. 예를 들어, 데이터 파일 볼륨을 선택적으로 이전 상태로 복원할 수 있습니다. 즉, 4개의 LUN이 모두 스냅샷 상태로 되돌려지고 중요 데이터가 있는 로그 볼륨은 영향을 받지 않습니다.

볼륨, LUN 및 SnapMirror를 지원합니다

SnapMirror 정책 및 작업은 스냅샷 작업과 마찬가지로 LUN이 아닌 볼륨에 대해 수행됩니다.

단일 볼륨에서 관련 LUN을 함께 배치하면 단일 SnapMirror 관계를 생성하고 포함된 모든 데이터를 단일 업데이트로 업데이트할 수 있습니다. 스냅샷과 마찬가지로 업데이트는 원자 단위 작업이기도 합니다. SnapMirror 대상은 소스 LUN의 단일 시점 복제본을 보유하도록 보장됩니다. LUN이 여러 볼륨에 분산되어 있는 경우 복제본이 서로 정합성이 보장되거나 일치하지 않을 수 있습니다.

볼륨, LUN 및 QoS를 지원합니다

QoS를 개별 LUN에 선택적으로 적용할 수 있지만 일반적으로 볼륨 수준에서 설정하기가 더 쉽습니다. 예를 들어, 특정 ESX 서버에서 게스트가 사용하는 모든 LUN을 단일 볼륨에 배치한 다음 ONTAP 적응형 QoS 정책을 적용할 수 있습니다. 그 결과 모든 LUN에 적용되는 TB당 자체 확장 IOPS 제한이 적용됩니다.

마찬가지로, 데이터베이스에 100K IOPS가 필요하고 10개의 LUN을 사용하는 경우 각 LUN에 하나씩 10개의 개별 10K IOPS 제한을 설정하는 것보다 단일 볼륨에 단일 100K IOPS 제한을 설정하는 것이 더 쉽습니다.

다중 볼륨 레이아웃

여러 볼륨에 LUN을 분산하는 것이 도움이 되는 경우도 있습니다. 주된 이유는 컨트롤러 스트라이핑입니다. 예를 들어, HA 스토리지 시스템은 각 컨트롤러의 완전한 처리와 캐싱 잠재성이 필요한 단일 데이터베이스를 호스팅하고 있을 수 있습니다. 이 경우 일반적인 설계에서는 LUN의 절반을 컨트롤러 1의 단일 볼륨에 배치하고 나머지 절반은 컨트롤러 2의 단일 볼륨에 배치하는 것입니다.

마찬가지로, 로드 밸런싱에 컨트롤러 스트라이핑을 사용할 수도 있습니다. 10개의 LUN으로 구성된 100개의 데이터베이스를 호스팅하는 HA 시스템은 각 데이터베이스가 2개의 컨트롤러 각각에서 5개의 LUN 볼륨을 받을 수 있도록 설계될 수 있습니다. 그 결과, 추가 데이터베이스를 프로비저닝할 때 각 컨트롤러를 대칭으로 로드할 수 있습니다.

단, 이 예에서는 볼륨 대 LUN 비율에 1:1이 관련되지 않습니다. 목표는 볼륨에 관련된 LUN을 함께 배치함으로써 관리 효율성을 최적화하는 것입니다.

1:1 LUN 대 볼륨 비율이 적합한 한 가지 예는 컨테이너화입니다. 각 LUN이 실제로 단일 워크로드를 나타내므로 각 워크로드를 개별적으로 관리해야 합니다. 이 경우 1:1 비율이 최적일 수 있습니다.