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

ONTAP의 디렉토리 인덱싱

기여자 whyistheinternetbroken

ONTAP 대용량 디렉터리를 자동으로 인덱싱하므로 특정 항목 조회 시 전체 디렉터리 파일을 한 번에 읽을 필요가 없습니다. 인덱싱은 `maxdir-size`과 별개이며, 최대 디렉터리 파일 한도를 변경하지 않습니다.

디렉토리 인덱싱이 존재하는 이유

컴퓨터에서 인덱스는 모든 레코드를 순회하지 않고도 "이것은 어디에 있는가?"라는 질문에 답하는 역할을 하는 보조 구조입니다. 책의 색인이 대표적인 예입니다. 책 전체를 읽는 대신 책에서 특정 용어를 찾아 해당 페이지로 바로 이동할 수 있습니다. 데이터베이스, 검색 엔진, 파일 시스템도 같은 원리를 사용하여 데이터 규모가 커지더라도 검색 비용을 효율적으로 유지합니다. 인덱스는 데이터의 복사본이 아닙니다. 이름 등 키를 사용하여 해당 항목의 위치를 매핑하는 역할을 합니다.

디렉터리는 이름 목록입니다. 인덱스가 없으면 특정 이름을 찾으려면 목록의 상당 부분을 훑어봐야 할 수 있습니다. ONTAP의 디렉터리 인덱스는 이러한 바로가기를 파일 시스템에서 구현한 것입니다.

영구 인덱스가 없으면 이름을 찾으려면 많은 디렉토리 블록을 읽고 메모리에서 해시를 생성해야 할 수 있습니다. ONTAP 9.2부터 ONTAP는 디렉토리 파일 크기가 약 2MiB에 도달하면 보조 디렉토리 인덱스 inode를 자동으로 생성합니다.

영구 인덱스는 디렉터리 파일에서 항목의 위치를 매핑합니다. 따라서 특정 항목을 조회할 때 전체 디렉터리 파일을 메모리에 로드하는 대신 필요한 인덱스와 특정 디렉터리 블록만 읽을 수 있습니다. 인덱싱은 일반적으로 대용량 디렉터리에서 조회 중심 작업에 필요한 CPU, 메모리 및 I/O 사용량을 줄여주므로, 대용량 디렉터리 콘텐츠 처리 외에도 다른 워크로드에 더 많은 노드 리소스를 활용할 수 있습니다.

전체 스캔으로 응답되는 2MiB 미만의 디렉토리 파일에 대한 클라이언트 이름 작업을 보여주는 흐름도

디렉토리 인덱싱을 활성화하는 데 필요한 관리자 옵션은 없으며, 기본적으로 활성화되어 있습니다. 디렉토리 파일이 약 2MiB 임계값을 초과한 후에만 디렉토리가 영구 인덱스 대상이 됩니다. 해당 조건이 충족되면 디렉토리를 임계값 이상으로 확장하는 작업, 인덱싱 스캐너 또는 LOOKUP, ACCESS, 경로 기반 open 또는 create, rename, remove 등 자격을 갖춘 프런트엔드 이름 작업에 의해 인덱스 생성이 시작될 수 있습니다. 이러한 스캐너 및 프런트엔드 트리거는 크기 임계값을 재정의하거나 더 작은 디렉토리에 대해 영구 인덱스를 생성하지 않습니다. 약 2MiB 지점은 대상 lookup이 처리되는 방식을 변경합니다. 이는 디렉토리 크기 프로토콜 지연 시간 임계값이 아닙니다. 성장하는 디렉토리가 클라이언트 및 노드 동작에 나타나는 방식은 "성능 영향"에 설명되어 있습니다.

인덱싱이 변경하지 않는 것

디렉토리 인덱스는 디렉토리 파일과 별개입니다. 디렉토리 인덱스가 존재하더라도 다음 사항은 여전히 유효합니다.

  • maxdir-size 여전히 디렉토리 파일 크기를 제한합니다.

  • 보조 인덱스는 추가 메타데이터와 inode를 사용하지만 디렉터리 크기에는 영향을 미치지 않습니다.

  • 인덱싱을 사용하면 전체 디렉터리 열거 방식보다 특정 대상을 찾는 검색 성능이 향상됩니다.

  • 와일드카드 스캔을 `READDIR`사용하더라도 전체 디렉토리 네임스페이스를 처리합니다.

  • 인덱스가 손실되거나 재구축되더라도 디렉터리 이름은 삭제되지 않습니다. ONTAP는 디렉터리 파일에서 디렉터리 이름을 재구성할 수 있습니다.

개인 및 공용 인덱스 inode에 대하여

인덱싱된 각 디렉토리에는 자체 인덱스가 있으며, 디렉토리 인덱스는 공유되지 않습니다. 따라서 볼륨은 약 2 MiB 임계값을 초과하여 커지는 모든 디렉토리에 대해 하나의 인덱스를 가질 수 있습니다. 임계값 미만의 디렉토리는 비영구 조회 경로에 유지되며, 스캐너 또는 프런트엔드 작업이 디렉토리에 액세스하는 경우에도 동반 디렉토리 인덱스 inode를 수신하지 않습니다. 대상 디렉토리의 인덱스가 `maxfiles`에 반영되는지 여부는 여기에 설명된 대로 비공개인지 또는 공개인지에 따라 달라집니다.

기본적으로 디렉터리 인덱스는 개인 inode 공간에 저장됩니다. SnapMirror 전송 시 개인 디렉터리 인덱스 inode는 제외되므로 ONTAP 활성화 또는 복원 후 필요에 따라 SnapMirror 타겟에서 인덱스를 다시 빌드합니다.

ONTAP 9.17.1 버전부터 볼륨 수준 옵션 -is-dir-index-transfer-enabled true`은 디렉터리 인덱스를 공용 inode 공간으로 이동하여 지원되는 SnapMirror 및 SnapMirror Cloud 워크플로에서 해당 인덱스를 전송할 수 있습니다. 이 옵션이 `true 활성화된 경우, 새 인덱스는 공용 inode 공간에 생성되고 스캐너가 기존 개인 인덱스를 마이그레이션합니다. 이렇게 하면 복원 후 인덱스 생성 시간을 단축할 수 있지만, 공용 인덱스는 공용 inode를 사용하므로 maxfiles 계획에 반드시 포함해야 합니다.

volume show 옵션 `-has-dir-index-public true`으로 공개 디렉토리 인덱스가 있는지 확인할 수 있습니다. 이 옵션은 수동으로 설정할 수 없으며, 공개 디렉토리 인덱스가 있는 경우에만 true로 표시됩니다.

공용 디렉터리 인덱스는 `files`에 포함되며 인덱스된 디렉터리 하나당 약 1개의 inode씩 `files-used`를 증가시킬 수 있습니다.

개인 인덱스는 공용 files 할당량을 소모하지 않습니다.

공용 디렉터리 인덱스 전송을 활성화해야 하는 시점

인덱스 전송을 활성화하면 복제 또는 복원 시 인덱스가 보존되어 파일 수가 많은 디렉터리에 대한 비용이 많이 드는 재구축을 방지할 수 있습니다. 인덱스 전송이 비활성화된 경우 SnapMirror는 개인 인덱스를 제외합니다. 활성화 또는 복원 후 ONTAP은 인덱싱 스캐너 또는 적격 프런트엔드 작업을 통해 적격 디렉터리에 대해 누락된 인덱스를 재구축할 수 있으며, 이로 인해 SnapMirror 타겟으로 페일오버 후 성능 영향이 발생할 수 있습니다. 인덱스 전송을 활성화해도 로컬 조회 성능은 향상되지 않습니다. 로컬 인덱싱은 해당 옵션이 활성화된 경우 이미 수행됩니다. false 이 기능은 SnapMirror 관계에 있는 볼륨에서만 사용하도록 설계되었습니다.

희소 디렉토리 및 구멍 뚫기

디렉토리 파일은 크기가 커졌다가 많은 파일이 삭제되면(즉, 디렉토리에서 파일이 제거되면) 빈 공간이 많아지는 현상이 발생할 수 있습니다. 디렉토리 파일 크기는 최고치를 유지한 상태로 남아 있기 때문에, a `READDIR`가 빈 블록을 탐색하는 데 상당한 CPU 및 I/O 리소스를 소모할 수 있습니다.

색인화된 디렉터리의 경우, ONTAP는 4KiB 디렉터리 블록이 완전히 비어 있게 되면 구멍을 뚫을 수 있습니다.

인덱스는 다음과 같이 구멍을 추적합니다.

  • READDIR 빈 블록은 건너뛸 수 있습니다.

  • 물리적 블록은 회수할 수 있습니다.

  • 생성된 객체는 나중에 해당 논리적 위치를 재사용할 수 있습니다.

고급 -has-optimized-sparse-directories 필드는 읽기 전용 볼륨 표시 옵션입니다. 값이 `true`이면 해당 볼륨에 최적화된 천공 형식의 디렉터리 블록이 포함되어 있음을 의미합니다.

삭제 후에도 애플리케이션 디렉토리 크기가 여전히 문제가 되는 경우, 남아 있는 항목들을 새로 생성된 디렉토리로 복사하면 디렉토리 파일 레이아웃이 더 간결해집니다. Lowering `maxdir-size`은 스파스 디렉토리를 압축하지 않습니다.

"← 이전: maxdir-size 및 현재 디렉토리 크기 보기"

"다음: maxdir-size의 영향 →"