SoFS 마이크로 파일 메타데이터 잠금 중단 SMB 메타데이터 캐시 CSV 메타데이터 처리 백만 개 파일 애플리케이션 빌드 메타데이터 경합 노드 전체 중단

JangJungKook 40 평판 포인트
2026-08-19T01:36:16.5566667+00:00

OS Windows Server 2022

SMB SMB 3.1.1 CSVFS 활성화

클러스터 노드 4

파일 수 10000000+

파일 크기 1KB–16KB

워크로드 자동화 빌드

메타데이터 작업 생성 열기 닫기 이름 변경 삭제

SMB 메타데이터 캐시 활성화

CSV 메타데이터 캐시 활성화

잠금 경합 심각

메타데이터 지연 높음

비즈니스용 Windows | Windows 365 Enterprise
댓글 0개 설명 없음

답변 1개

정렬 기준: 가장 유용함
  1. Harry Phan 34,045 평판 포인트 독립 자문가
    2026-08-19T04:01:16.48+00:00

    안녕하세요,

    말씀하신 문제는 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.

    이 대답이 도움이 되었나요?

    댓글 0개 설명 없음

답변

질문 작성자는 답변을 '승인됨'으로 표시하고, 중재자는 답변을 '추천됨'으로 표시할 수 있습니다. 이를 통해 사용자는 해당 답변이 작성자의 문제를 해결했다는 것을 알 수 있습니다.