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

ONTAP FlexCache 핫스팟 개선 솔루션 설계

기여자 netapp-dbagwell

핫스팟을 해결하려면 병목 현상의 근본 원인, 자동 프로비저닝 FlexCache가 충분하지 않은 이유, FlexCache 솔루션을 효과적으로 설계하는 데 필요한 기술 세부 사항을 살펴봅니다. 고밀도 FlexCache 스토리지(HDFA)를 이해하고 구현하면 성능을 최적화하고 수요가 많은 작업 부하에서 병목 현상을 제거할 수 있습니다.

병목 현상 이해

다음은 이미지일반적인 단일 파일 핫 스팟팅 시나리오를 보여 줍니다. 이 볼륨은 노드당 단일 구성요소가 있는 FlexGroup이며 파일은 노드 1에 상주합니다.

모든 NAS 클라이언트의 네트워크 연결을 클러스터의 서로 다른 노드에 분산시키는 경우 핫 파일이 상주하는 볼륨 선호도를 지원하는 CPU의 병목 현상이 발생합니다. 또한 파일이 상주하는 위치가 아닌 노드에 연결된 클라이언트에서 수신되는 통화에 클러스터 네트워크 트래픽(동부-서부 트래픽)을 도입합니다. 동서부의 트래픽 오버헤드는 일반적으로 작지만 고성능 컴퓨팅 워크로드의 경우에는 비트 수가 거의 없습니다.

그림 1: FlexGroup 단일 파일 핫스팟 시나리오

그림 1: FlexGroup 단일 파일 핫스팟 시나리오

자동 프로비저닝된 FlexCache가 해답이 아닌 이유

핫스팟을 해결하려면 CPU 병목 현상을 제거하고 동서 트래픽도 제거합니다. FlexCache가 제대로 설정되어 있으면 도움이 될 수 있습니다.

다음 예에서는 FlexCache가 System Manager, BlueXP  또는 기본 CLI 인수를 사용하여 자동으로 프로비저닝됩니다. 그림 1그림 2 처음에는 같지만, 둘 다 4노드, 단일 구성 NAS 컨테이너입니다. 유일한 차이점은 그림 1의 NAS 컨테이너는 FlexGroup이고 그림 2의 NAS 컨테이너는 FlexCache입니다. 각 그림은 동일한 병목 현상을 보여 줍니다. 즉, 핫 파일에 대한 볼륨 선호도 액세스를 위한 노드 1의 CPU와 지연 시간을 유발하는 동부 서부 트래픽의 병목 현상을 보여 줍니다. 자동 프로비저닝된 FlexCache로 병목 현상이 사라지지는 않았습니다.

그림 2: 자동 프로비저닝 FlexCache 시나리오

그림 2: 자동 프로비저닝 FlexCache 시나리오

FlexCache의 해부 구조

핫스팟 교정을 위한 FlexCache를 효과적으로 설계하려면 FlexCache에 대한 몇 가지 기술 세부 사항을 이해해야 합니다.

FlexCache는 항상 스파스 FlexGroup입니다. FlexGroup는 여러 개의 FlexVol으로 구성됩니다. 이러한 FlexVol을 FlexGroup 구성요소라고 합니다. 기본 FlexGroup 레이아웃의 경우, 클러스터의 노드당 구성요소가 하나 이상 있습니다. 구성 요소는 추상화 계층 아래에 "함께 결합"되어 단일 대형 NAS 컨테이너로 클라이언트에 제공됩니다. 파일이 FlexGroup에 기록되면 수집 휴리스틱에서 파일이 저장될 구성요소를 결정합니다. 클라이언트의 NAS 연결을 포함하는 구성요소이거나 다른 노드일 수 있습니다. 모든 것이 추상화 계층 아래에서 작동하고 클라이언트에게 보이지 않기 때문에 위치는 관련이 없습니다.

FlexGroup에 대한 이해도를 FlexCache에 적용해 보겠습니다. FlexCache는 FlexGroup을 기반으로 구축되기 때문에 에 설명된 대로 클러스터의 모든 노드에 대해 단일 FlexCache가 기본적으로 제공됩니다.그림 1 대부분의 경우 이것은 매우 유용합니다. 클러스터의 모든 리소스를 활용하고 있습니다.

하지만 핫 파일을 수정하는 경우에는 단일 파일 및 동서 트래픽의 CPU와 같은 두 가지 병목 현상 때문에 이 방법이 적합하지 않습니다. 핫 파일의 모든 노드에 구성 요소가 있는 FlexCache를 생성하는 경우 해당 파일은 여전히 구성요소 중 하나에 상주합니다. 즉, 핫 파일에 대한 모든 액세스를 서비스하는 CPU가 하나 있습니다. 또한 핫 파일에 도달하는 데 필요한 동서 트래픽의 양을 제한해야 합니다.

이 솔루션은 고밀도 FlexCaches의 어레이입니다.

고밀도 FlexCache의 해부 구조

고집적 HDF(FlexCache)는 캐시된 데이터의 용량 요구 사항이 허용하는 만큼 소수의 노드에 구성 요소가 있습니다. 목표는 단일 노드에서 캐시를 활성화하는 것입니다. 용량 요구사항에 따라 그렇게 할 수 없는 경우 몇 개의 노드에만 구성요소를 사용할 수 있습니다.

예를 들어, 24노드 클러스터에는 3개의 고밀도 FlexCh가 있을 수 있습니다.

  • 노드 1에서 8까지 확장되는 경로입니다

  • 노드 9에서 16까지 확장되는 초입니다

  • 노드 17-24에 걸쳐 3분의 1을 제공합니다

이 세 개의 HDFS는 하나의 HDFA(High-Density FlexCache Array)를 구성합니다. 각 HDF 내에 파일이 균등하게 배포되면 클라이언트가 요청한 파일이 프런트엔드 NAS 접속에 로컬로 상주할 확률은 8%입니다. 각각 2개의 노드만 사용하는 12개의 HDFS를 사용하는 경우 파일이 로컬일 가능성이 50% 높습니다. HDF를 단일 노드로 축소하여 24개 노드로 만들 수 있다면 파일이 로컬임을 보증할 수 있습니다.

이 구성은 모든 동서 트래픽을 제거하며 가장 중요한 것은 핫 파일에 액세스하기 위한 24개의 CPU/볼륨 선호도를 제공합니다.