아무도 물건을 버리는 것을 좋아하지 않습니다. 특히 "물건"이 파일 시스템이 가득 차게 되는 데이터인 경우에는 더욱 그렇습니다. 엔지니어링이나 사용자 실수로 인해 파일 시스템의 용량이 부족한 경우가 있지만 보통 하루 동안에 발생하는 경우가 많습니다. 관리자는 일반적으로 사용자가 하는 방식으로 데이터의 세부적인 가치를 알지 못하므로 사용자를 대신하여 데이터를 안전하게 정리할 수 없습니다. 그러나 어느 시점에서 가야 할 일이 있습니다.
능력 회복의 첫 번째 과제는 삭제할 항목 결정. 그렇게 하려면 청소할 항목을 찾기 위해 어디를 찾아야 하는지도 알아야 합니다! 각 디렉토리 구조의 최근 활동(누구인가?)에 익숙하지 않은 경우 표준 도구를 사용하여 파일 시스템을 분석해 볼 수 있습니다. 이것은 시스템에 파일이 1000만 개뿐인 경우에 효과적입니다. 하지만 그 안에 천만, 억, 심지어 XNUMX억 개의 파일이 있다면 어떻게 될까요? 단일 스레드 프로세스를 가정할 때 각 통계 호출에 밀리초가 걸린다면 XNUMX억 개의 파일을 방문하는 데 약 하루가 걸리고 XNUMXIOPS의 꾸준한 로드를 생성합니다. 따라서 귀하의 정보가 약간 오래되었을 뿐만 아니라 수신하는 데 오랜 시간이 걸리며 이는 검색의 최상위 수준에 불과합니다! 파일 시스템으로 내려가면서 헹구고 반복해야 합니다.
용량 관리를 덜 고통스럽게 만드는 방법에 대한 자세한 내용은 Qumulo 기술 개요를 다운로드하십시오.
분명히 더 나은 성능의 솔루션이 필요합니다. 예를 들어 프로세스를 다중 스레드할 수 있습니다. 1000명의 작업자가 통계 호출을 수행하고 모두 병렬로 작동하므로 하루 작업을 20시간 남짓으로 줄일 수 있습니다. 이 접근 방식의 문제는 이제 시스템에 20000 x 20000 작업자의 정상 상태 로드가 있다는 것입니다. 이는 XNUMX IOPS에 해당합니다! 이는 상당한 워크로드이며 여기서 중요한 점은 프로덕션 시스템에서 사용할 수 없는 XNUMX IOPS입니다. 용량이 어디에 있는지 실시간으로 알 수 있다는 명목으로 모든 것이 가능합니다.
스토리지 용량 관리 문제를 해결하는 방법
능력을 분석할 때 몇 가지 표준 기술이 있습니다.
1. 데이터의 전체 복사본 만들기
한 가지 기술은 해당 데이터의 전체 복사본을 백업으로 만들고 해당 메타데이터에 대해 통계 호출을 실행하는 것입니다. 이것은 프로덕션 시스템이 아닌 백업을 사용하기 때문에 끔찍한 접근 방식이 아닙니다. 백업 기준선 설정은 처리량 측면에서 비용이 많이 들지만 프로덕션 파일 시스템에서 변경 사항만 가져오는 것이 합리적인 절충안이 될 것입니다. 분석을 수행하는 소프트웨어에 가치가 있기 때문에 이 기술은 백업 계층의 비용을 증가시킨다는 점을 명심하십시오. 자신의 것을 굴린다면 이 옵션의 비용을 낮출 수 있습니다.
2. 스토리지 시스템을 보다 적극적으로 스캔하십시오.
다른 옵션은 검색에 대해 보다 적극적으로 나서 해당 기능을 스토리지 시스템에 구축하는 것입니다. 즉, 외부 시스템에서 해당 데이터를 쿼리하거나 해당 데이터를 수집하도록 요청을 발행할 수 있습니다. 이 접근 방식도 나쁘지 않습니다. 메타데이터를 수집하기 위해 로컬 작업을 실행하면 모든 통계 호출에 대한 왕복 시간이 줄어듭니다. 트리 워크 및 통계 호출이 여전히 필요하기 때문에 일부 IOPS를 사용하게 되지만 인터페이스는 SMB 또는 NFS와 같은 것보다 더 효율적입니다.
3. 스토리지 스캔을 위해 외부 타사 시스템 사용
또 다른 접근 방식은 보유한 모든 것을 스캔하고 여러 스토리지 공급업체를 포함하여 전체 스토리지 환경에서 답변을 제공하는 외부 타사 시스템을 사용하는 것입니다. 스토리지 스프롤이 많은 경우 이와 같은 도구를 사용하면 전체 그림을 파악하는 데 도움이 될 수 있으며 이는 매우 중요합니다. 이를 수행하는 많은 도구에는 일종의 데이터 관리/이동 기능도 있습니다. 스토리지 환경에 대해 학습한 내용을 사용하여 계층 또는 워크플로 단계 간에 정책 기반 데이터 이동을 설정할 수 있습니다. 이 접근 방식의 단점은 이러한 도구가 변경 사항을 찾기 위해 여전히 스캔해야 하므로 스토리지 시스템에서 메타데이터 IOPS 로드를 제거하지 않고 업데이트 측면에서 여전히 약간 뒤처지게 된다는 것입니다.
4. 기존 메타데이터 데이터베이스에 데이터 저장
마지막으로 상위 디렉토리를 정기적으로 업데이트하는 파일 및 디렉토리에 대한 검색 및 통계 호출을 없애고 해당 데이터를 이미 존재하는 메타데이터 데이터베이스에 저장할 수 있습니다. 이 접근 방식은 업데이트가 거의 실시간으로 발생할 수 있기 때문에 실제로 상당한 개선 사항입니다. 새로운 변경 사항이 있는 모든 개체가 15초마다 상위 항목에 보고하고 예를 들어 XNUMX개 수준의 디렉터리 트리가 있는 경우 루트가 가장 깊은 수준에서 추가 또는 삭제에 대해 알아내는 데 XNUMX분이 걸립니다. . 그것은 한 시간이나 하루보다 훨씬 낫습니다! 이것이 Qumulo가 실시간 분석에 사용하는 접근 방식입니다.
Qumulo 접근 방식의 또 다른 이점 즉, 스캔을 아무리 많이 하고 통계 호출을 아무리 많이 해도 "어떤 데이터가 중요한가요?"라는 가장 중요한 질문에 여전히 쉽게 대답할 수 없다는 것입니다. 모두가 자신의 데이터가 중요하다고 생각하지만 Qumulo를 사용하면 누군가가 보관해야 하는 프로젝트의 중요성에 이의를 제기할 경우 시간이 지남에 따라 분석 데이터를 사용하여 몇 달 또는 몇 년 동안 건드리지 않았음을 보여줄 수 있습니다. 이는 모호한 저장 결정에 명확성을 더해줍니다. 반대로, 이 분석 데이터를 사용하면 파일이 오래되었지만 여전히 정기적으로 사용되는 데이터 세트를 나타내는 경우가 있음을 보여줄 수도 있습니다.
스토리지 용량 관리에 대한 요약
모든 엔지니어링 작업과 마찬가지로 사용자 환경에 가장 적합한 접근 방식을 결정하는 것은 사용자와 팀의 몫입니다. 스토리지 용량에 문제가 있는 경우 다음과 같은 몇 가지 최상위 수준을 고려해야 합니다.
- 새로운 공급 업체를 두려워하지 마십시오. 시장에 새로 진입하는 업체는 더 오래되고 확고한 공급업체보다 용량 분석을 처리하는 더 현대적인 방법을 사용할 것입니다.
- 스토리지 최적화를 찾으십시오. 모든 사람이 스캔하므로 메타데이터 캐싱, 검색 정리를 위한 영리한 방법 및 로컬 스캔과 같은 최적화 기능이 있는 스토리지 시스템을 찾으십시오.
- API를 찾습니다. 긴밀한 워크플로 통합을 중요하게 생각한다면 스캔한 데이터에 프로그래밍 방식으로 액세스할 수 있어야 합니다. API는 스토리지 시스템에서 호스팅되는 데이터베이스만 쿼리할 수 있는 경우에도 가장 좋습니다. 용량 데이터를 프로덕션 관리 시스템이나 미디어 자산 관리자에 통합하고 분석 데이터를 쉽게 사용하고 조작할 수 있기를 원할 수 있습니다.
- 할당량 또는 볼륨을 사용합니다. 할당량 또는 볼륨을 사용하여 사용자 행동을 관리하고 사용자가 데이터로 스토리지를 채우지 않도록 합니다. 예를 들어 Qumluo에는 실시간으로 적용할 수 있는 디렉터리 기반 할당량이 있습니다.
