ONTAP의 디렉토리 인덱싱
ONTAP 대용량 디렉터리를 자동으로 인덱싱하므로 특정 항목 조회 시 전체 디렉터리 파일을 한 번에 읽을 필요가 없습니다. 인덱싱은 `maxdir-size`과 별개이며, 최대 디렉터리 파일 한도를 변경하지 않습니다.
디렉토리 인덱싱이 존재하는 이유
컴퓨터에서 인덱스는 모든 레코드를 순회하지 않고도 "이것은 어디에 있는가?"라는 질문에 답하는 역할을 하는 보조 구조입니다. 책의 색인이 대표적인 예입니다. 책 전체를 읽는 대신 책에서 특정 용어를 찾아 해당 페이지로 바로 이동할 수 있습니다. 데이터베이스, 검색 엔진, 파일 시스템도 같은 원리를 사용하여 데이터 규모가 커지더라도 검색 비용을 효율적으로 유지합니다. 인덱스는 데이터의 복사본이 아닙니다. 이름 등 키를 사용하여 해당 항목의 위치를 매핑하는 역할을 합니다.
디렉터리는 이름 목록입니다. 인덱스가 없으면 특정 이름을 찾으려면 목록의 상당 부분을 훑어봐야 할 수 있습니다. ONTAP의 디렉터리 인덱스는 이러한 바로가기를 파일 시스템에서 구현한 것입니다.
영구 인덱스가 없으면 이름을 찾으려면 많은 디렉토리 블록을 읽고 메모리에서 해시를 생성해야 할 수 있습니다. ONTAP 9.2부터 ONTAP는 디렉토리 파일 크기가 약 2MiB에 도달하면 보조 디렉토리 인덱스 inode를 자동으로 생성합니다.
영구 인덱스는 디렉터리 파일에서 항목의 위치를 매핑합니다. 따라서 특정 항목을 조회할 때 전체 디렉터리 파일을 메모리에 로드하는 대신 필요한 인덱스와 특정 디렉터리 블록만 읽을 수 있습니다. 인덱싱은 일반적으로 대용량 디렉터리에서 조회 중심 작업에 필요한 CPU, 메모리 및 I/O 사용량을 줄여주므로, 대용량 디렉터리 콘텐츠 처리 외에도 다른 워크로드에 더 많은 노드 리소스를 활용할 수 있습니다.
디렉토리 인덱싱을 활성화하는 데 필요한 관리자 옵션은 없으며, 기본적으로 활성화되어 있습니다. 디렉토리 파일이 약 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`은 스파스 디렉토리를 압축하지 않습니다.
