수집하거나 추정하십시오:

일일 평균값 대신 최고 사용량 값을 사용하십시오. 빌드 파이프라인, 분석 작업, 마이그레이션 및 임시 스크래치 워크플로는 종종 짧은 시간 동안 가장 큰 네임스페이스를 생성한 다음 정리하지만, inode 및 디렉터리 파일에는 정리 후에도 최고 사용량 기록이 남아 있을 수 있습니다.

두 개의 별도 예측을 유지하십시오.

한 값에서 다른 값을 도출하지 마십시오. 분할된 네임스페이스(파일이 여러 디렉터리에 분산된 경우)는 큰 디렉터리를 생성하지 않고도 maxfiles 용량이 부족해질 수 있습니다. 단일 평면 디렉터리는 볼륨에 수백만 개의 사용 가능한 inode가 있더라도 maxdir-size 한계에 도달할 수 있습니다.

NTFS 또는 ACL이 많이 적용된 네임스페이스에서는 보이는 파일 개수만으로 maxfiles 크기를 계산하지 마십시오. 디렉터리, ACL inode, 명명된 스트림 및 기타 공용 오브젝트를 예측에 포함하십시오. ACL이 많이 사용되는 경우, 예측된 파일 및 디렉터리 개수의 최대 두 배를 files 보수적인 초기 추정치로 사용한 다음, 대표 데이터로 검증하십시오. ACL 공유로 인해 실제 사용량이 줄어들 수 있습니다.

"ONTAP inode 유형" 및 "Maxdir-size 및 대용량 ONTAP 디렉터리"를 참조하십시오.

일반적인 네임스페이스 레이아웃에는 세 가지 유형이 있습니다.

가능하면 애플리케이션에서 넓거나 깊은 계층 구조를 사용할 수 있는 경우, 수백만 개의 이름을 단일 디렉터리 수준에 배치하는 것을 피하십시오. 단일 디렉터리 구조는 메모리와 CPU 작업을 집중시켜 대량 GETATTR, READDIR, 검색 및 삭제 작업 중 지연 시간을 증가시킬 수 있습니다. FlexGroup 볼륨에서 대규모 단일 디렉터리는 원격 항목을 더 많이 생성하여, FlexVol에서 동일한 표시 이름 수보다 더 빨리 디렉터리 파일이 `maxdir-size`에 근접할 수 있습니다.

FlexGroup 볼륨은 일반적으로 하나의 큰 플랫 디렉터리보다는 여러 개의 작은 디렉터리로 구성하는 것이 가장 효율적입니다. 약 2MiB 미만의 디렉터리는 단순 스캔 경로를 유지합니다. ONTAP 9.2부터는 더 큰 디렉터리도 자동으로 인덱싱되어 특정 파일 검색에 도움이 됩니다. 인덱싱이 매우 큰 디렉터리를 샤딩된 계층 구조와 동일하게 만드는 것은 아닙니다. 열거, 와일드카드 스캔 및 단일 디렉터리 생성 직렬화는 여전히 적용됩니다. ONTAP은 FlexGroup 하위 디렉터리를 원격에 배치할 때 상위 디렉터리에 대한 파일 지역성을 우선시하여 해당 파일의 원격 지연 시간을 줄일 수 있습니다.

계층 구조에 걸쳐 파일을 분산시킨다는 것은 각 디렉터리에 더 적은 파일을 넣고 더 많은 디렉터리를 사용하는 것을 의미합니다.

일반적인 샤딩 키는 다음과 같습니다.

디렉터리 작업을 관리하기 쉬운 수준으로 유지할 수 있도록 충분한 수의 샤드를 선택하되, 디렉터리 수가 과도하게 많아지지 않도록 거의 비어 있는 디렉터리를 너무 많이 생성하지 마십시오. 결정론적 방식은 배치 예측 가능성을 높여 클라이언트가 모든 샤드를 스캔하지 않고도 파일을 찾을 수 있도록 합니다.

넓고 깊은 레이아웃 모두 효과적일 수 있습니다. 전체 경로 길이를 NAS 프로토콜, 클라이언트 운영 체제 및 애플리케이션의 제한 범위 내로 유지하십시오. 플랫 레이아웃이 불가피한 경우, "maxdir-size 및 현재 디렉토리 크기 보기"에 설명된 대로 가장 큰 디렉토리 파일의 현재 크기 및 maxdir-size 여유 공간을 모니터링하고 제어된 증가가 적절한지 검증하십시오.

사용 중인 inode 또는 가장 큰 디렉터리 파일의 100%를 사용하여 안정적인 운영을 계획하지 마십시오. 예상치 못한 증가, 임시 객체, 스냅샷에 보존된 메타데이터, ACL 및 스트림, 마이그레이션 중복, 백업 작업, FlexGroup 배치 불균형, 파일 이름을 변경하는 소프트웨어 변경 사항 등을 고려하여 여유 공간을 확보하십시오.

Setting `files`을 현재 최대값으로 설정하는 것은 상한선일 뿐, 마지막 inode가 사라질 때까지 실행을 허용하는 것이 아닙니다. `files-used`에 대해 해당 상한선에 도달하기 훨씬 전에 알림을 설정하십시오. `maxdir-size`의 경우, "maxdir-size를 초과하면 어떻게 됩니까?"의 약 2% 증가 지침은 상한선을 높이는 방법일 뿐, 보편적인 운영 마진을 의미하는 것이 아닙니다.

inode 파일, 디렉터리 파일, 인덱스, 스냅샷 및 집계 메타데이터를 각각 별도로 예산에 반영합니다. 할당된 공용 inode당 288바이트를 기본 inode 파일 추정치로 사용합니다. "용량 영향"를 참조하십시오. `files`를 높여도 해당 공간이 즉시 할당되지는 않습니다. 할당된 inode 파일 용량의 최대값은 영구적인 것으로 처리합니다.

최소한 다음을 테스트하십시오:

경로 길이와 기본 이름 길이는 서로 바꿔 쓸 수 없습니다. 여러 디렉터리에 걸쳐 있는 긴 경로는 프로토콜 제한 및 inode 수에 영향을 미치는 반면, 각 디렉터리는 바로 인접한 구성 요소만 저장합니다.

순차적 대역폭 테스트는 파일 수가 많을 때의 동작을 예측하지 못합니다. 다음을 포함하세요:

지연 시간 분포, CPU 사용량, 캐시 동작, 네트워크 부하 및 완료 시간을 측정합니다. 프로덕션 환경에서 스냅샷, 복제, 분석, 백업 및 보안 검사 작업이 동시에 진행되는 경우, 해당 작업 중에 테스트를 반복합니다.

초기 수집보다 더 많은 항목을 테스트하십시오:

대상 위치에서 디렉터리 인덱스를 구축하거나 전송해야 할 수 있습니다. 재구축을 방지하는 것이 복구 성능을 크게 향상시키는 경우에만 공용 인덱스 전송을 활성화하십시오. 이는 로컬 조회 성능을 향상시키지는 않습니다. "공용 디렉터리 인덱스 전송을 활성화해야 하는 시점"을 참조하십시오.

Track files-used against files and `inodefile-public-capacity`에 설명된 대로 "최대 파일, EMS 이벤트 및 ONTAP 개선 사항을 모니터링합니다.". `files-used`이(가) `files`에 도달하기 전에 알림을 받으십시오. FlexGroup 볼륨의 경우 전체 합계에 여유가 있는 것처럼 보이더라도 구성 요소 수준의 이벤트를 조사하십시오.

디렉터리 파일 크기를 측정하고 "maxdir-size 및 현재 디렉토리 크기 보기"에 설명된 대로 EMS 파일 ID를 확인합니다. 경고가 발생하기 전에 알려진 정체되거나 변경 빈도가 높은 디렉터리를 목록화합니다.

inode 경고의 경우:

디렉토리 크기 경고의 경우:

파일을 삭제하면 공용 inode가 재사용될 수 있도록 해제되지만 공용 inode 파일의 크기는 줄어들지 않습니다. 마찬가지로 디렉터리에서 이름을 삭제하면 디렉터리 슬롯을 재사용할 수 있지만 일반적으로 디렉터리 파일의 최대 크기가 줄어들지는 않습니다.

대규모 삭제는 메타데이터 사용량이 많아 일시적으로 개인용 좀비 inode 수를 증가시킬 수 있습니다. 클라이언트 측 재귀적 삭제((rm -rf)가 프로덕션 트래픽과 경쟁할 때는 속도를 제한하십시오.

ONTAP 9.8부터는 volume file async-delete`NFS 또는 SMB를 통하지 않고 클러스터에서 디렉터리를 직접 삭제하여 클라이언트 및 네트워크 충돌을 방지합니다. 이 기능은 FlexVol 및 FlexGroup 볼륨에 적용됩니다. ONTAP 경로를 스캔하고 하위 디렉터리 내용을 먼저 삭제한 후 병렬 삭제 작업을 실행합니다(기본값 5,000개의 동시 작업, 50~100,000개로 구성 가능). TR-4571 테스트에서 24,000개 항목으로 구성된 트리에서 단일 스레드 `rm -rf 방식보다 약 10배 빠른 속도를 보였습니다.

제약 조건: 볼륨은 온라인 상태이고 마운트되어 있어야 하며, 경로는 디렉터리(단일 파일이 아님)여야 하고, 비동기 삭제 작업은 한 번에 하나만 실행할 수 있습니다.

크기가 크고 데이터가 부족한 디렉터리가 여전히 문제라면, 남아 있는 항목들을 새 디렉터리로 복사하십시오. 낮춰도 maxdir-size 압축되지는 않습니다. "희소 디렉토리 및 구멍 뚫기"을 참조하십시오.

파일 수가 많은 작업은 데이터 처리량이 낮더라도 CPU, 메모리, 캐시 및 스토리지 I/O를 많이 사용합니다. 다음을 위해 여유 공간을 확보하십시오.

용량이나 처리량뿐 아니라 관찰된 메타데이터 수요를 기반으로 워크로드 균형을 조정합니다. 네트워크 및 디스크 대역폭이 충분해 보이지만 노드가 메타데이터 병목 현상을 겪을 수 있습니다.

파일 수가 많은 NAS는 종종 메타데이터 병목 현상을 겪습니다. NFS 또는 SMB 마운트는 일반적으로 하나의 데이터 LIF에 대한 하나의 TCP 연결을 사용하며, 해당 LIF는 하나의 노드에 저장됩니다. 여러 클라이언트, 스캐너 또는 백업 작업이 동일한 주소를 마운트하는 경우, 해당 노드는 클러스터의 나머지 부분이 유휴 상태일 때에도 프로토콜 처리에 CPU 자원을 소모하게 됩니다. FlexGroup는 파일 작업을 클러스터 네트워크를 통해 리디렉션할 수 있지만, 이는 클라이언트 연결을 소유한 노드의 부하를 제거하지는 않습니다.

NFS nconnect 또는 SMB 멀티채널을 지원하는 단일 클라이언트는 하나의 마운트에 추가 연결을 열 수 있습니다. 이는 해당 클라이언트에 도움이 되지만, 여러 클라이언트를 LIF 및 노드에 분산시키는 방식을 대체하는 것은 아닙니다.

최신 ONTAP 릴리스에는 디렉터리 인덱싱, inode 관리 개선, 희소 디렉터리 최적화, 디렉터리 인덱스 전송 및 기타 파일 수가 많은 환경에 대한 개선 사항이 포함됩니다. 업그레이드 결정을 내릴 때는 플랫폼 지원, 데이터 보호 호환성 및 애플리케이션 적합성을 고려해야 합니다.

파일 수가 많다는 이유만으로 특정 기능을 활성화하지 마십시오.

ONTAP 9.17.1 버전부터 새로 생성된 NAS SVM의 새 볼륨에서 파일 시스템 분석이 기본적으로 활성화될 수 있습니다. 비활성화되어 있다고 가정하지 말고 활성화 여부를 확인 `-analytics-state`하시고, 파일 수가 많은 워크로드를 처리할 때는 네임스페이스 스캔을 고려하십시오.

기록:

애플리케이션 버전, 파일 이름 형식, 보존 기간, 프로토콜 또는 데이터 보호 워크플로가 변경될 때 모델을 다시 검토하십시오.