안녕하세요,
말씀하신 문제는 SMB 3.1.1을 사용하는 CSV(Cluster Shared Volumes) 환경의 SoFS(Scale-Out File Server)에서 초소형 파일(micro-file) 워크로드를 대량으로 처리할 때 발생하는 전형적인 메타데이터 잠금 경합(metadata lock contention) 문제입니다. 1~16KB 크기의 파일이 1,000만 개 이상 존재하는 경우, 병목 현상은 처리량(throughput)이 아니라 메타데이터 작업(열기, 닫기, 이름 변경, 삭제)에서 발생합니다. SMB 및 CSV 메타데이터 캐싱을 활성화하더라도, 4개 노드 간의 잠금 조정(lock arbitration) 과정이 CSVFS 코디네이터에 과도한 부하를 주어 심각한 지연 시간(latency)과 클러스터 전체의 중단(stall)을 초래하게 됩니다.
근본적인 원인은 CSVFS의 메타데이터 처리가 NTFS 수준에서 직렬화(serialized)되어 있어, 수백만 개의 소형 파일을 동시에 조작할 때 잠금 관리자가 확장성(scalability)을 확보하지 못하기 때문입니다. SMB 메타데이터 캐싱은 읽기 위주의 워크로드에는 도움이 되지만, 귀하의 사례처럼 생성/삭제/이름 변경 작업이 주를 이루는 경우에는 캐시가 지속적으로 무효화(invalidate)됩니다. CSV 메타데이터 캐싱 또한 읽기 메타데이터 트래픽은 줄여주지만, 쓰기 작업이 많은 메타데이터 처리 중 발생하는 잠금 경합을 완화하지는 못합니다.
이 상황에서 취할 수 있는 현실적인 방법은 다음과 같습니다.
수천만 개의 초소형 파일을 다루는 이 워크로드는 NTFS/ReFS 기반의 CSVFS + SoFS 구성에 적합하지 않습니다. Microsoft는 파일 변경이 빈번한(high-churn) 초소형 파일 자동화 워크로드에 CSVFS를 사용하지 않도록 명시적으로 권장하고 있습니다. 권장되는 설계 방식은 이러한 워크로드를 전용 파일 시스템이나 객체 스토리지 솔루션으로 분리(offload)하는 것입니다.
반드시 Windows Server 2022 SoFS를 계속 사용해야 한다면, 수백만 개의 개별 파일 대신 VHDX, 데이터베이스, 또는 아카이브 구조와 같은 더 큰 컨테이너 형식으로 파일을 통합하여 메타데이터 경합을 줄여야 합니다. 이렇게 하면 잠금 조정 부하를 획기적으로 줄일 수 있습니다.
모든 클러스터 노드에서 SMB Direct와 RDMA가 활성화되어 있는지 확인하십시오. 이는 메타데이터 잠금 경합 자체를 해결하지는 못하지만, 노드 간 메타데이터 RPC 호출의 지연 시간을 줄여줍니다.
CSVFS에는 잠금 조정을 우회할 수 있는 조정 가능한 레지스트리 키가 없습니다. 유일하게 지원되는 튜닝 방법은 워크로드에 고가용성(HA) 기능이 필요하지 않은 경우 SMB 공유의 '지속적 가용성(continuous availability)' 기능을 비활성화하여 메타데이터 오버헤드를 줄이는 것뿐입니다.
요약하자면, 이 문제는 아키텍처상의 한계입니다. CSVFS는 여러 노드에 걸쳐 초소형 파일에 대한 수십억 건의 메타데이터 작업을 처리하도록 설계되지 않았습니다. 이러한 시나리오에 대한 Microsoft의 공식 지침은 SoFS를 사용하지 않는 방식으로 워크로드 아키텍처를 재설계하는 것입니다. 현재 설계를 그대로 유지한다면, 캐싱 설정과 관계없이 계속해서 락 경합(lock contention)과 클러스터 전체의 지연(stall) 문제가 발생할 것입니다.
이번 내용이 도움이 되었기를 바랍니다. 문제에 대해 더 깊이 이해하는 데 도움이 되었다면 답변을 채택해 주시면 감사하겠습니다. 추가로 궁금한 점이 있으시면 언제든지 메시지를 남겨 주세요. 좋은 하루 보내세요!
HP.