저는 Qumulo의 애니메이션 고객 중 한 명과 용량 활용도에 대해 이야기하고 있었는데 사람들이 데이터를 삭제하도록 하는 데 특히 어려움을 겪는다고 언급했습니다. 약 XNUMX명의 아티스트가 모두 수억 개의 파일이 있는 동일한 파일 시스템 트리에서 작업하고 있습니다! 용량이 부족해지기 시작하면 배압을 적용해야 합니다. 그러나 이를 효과적으로 수행하려면 사람들에게 자신이 소비하는 용량을 알려야 합니다. 수천 명의 사용자가 수억 개의 파일을 크롤링하는 것은 실용적이지 않습니다. 따라서 이 고객은 모든 사용자의 발자국에 대한 데이터를 축적하면서 여러 시간 동안 실행되는 맞춤형 코드를 구축했습니다. 이는 느리고 번거롭고 리소스 집약적이며 유지 관리가 어렵고 오래된 정보를 제공했습니다. 고객이 더 나은 것을 제공하도록 요청했습니다.
사용자가 데이터를 삭제하도록 하는 방법은 무엇입니까?
데이터 관리의 고통스러운 부분은 사람들이 데이터를 생성하고 절대로 데이터를 해제하지 않는다는 것입니다. 모든 사람이 공간이 부족하고 모든 사람이 삭제할 항목을 검색해야 할 때까지 아무 것도 해치지 않습니다. 어느 시점에서 그들의 애플리케이션은 넘어지고 모든 사람들은 자신이 만든 것을 잊어버렸습니다.
타임라인은 다음과 같습니다.
모범 사례
- 스토리지 관리자는 사람들이 데이터를 삭제하도록 하는 몇 가지 방법이 있다는 것을 알고 있습니다.
사용자를 차단할 수 있습니다.- 스토리지 시스템이 마침내 중단되면서 전체 애플리케이션이 붕괴될 수 있습니다. 많은 스토리지 시스템이 100% 가득 차면 분해됩니다. 스토리지 공급업체에 성능이 어떠한지, 스토리지 시스템을 가득 채울 때 드라이브 오류로부터 보호되는지 여부에 대해 문의하십시오.
- 사용자 또는 디렉토리에 할당량을 설정할 수 있습니다. 이것은 훌륭하게 작동하지만 여전히 응용 프로그램을 손상시킵니다(예를 들어 응용 프로그램에서 공간 부족 조건이 발생하면 파일이 손상될 수 있으며 사용자가 삭제할 항목을 찾는 데 도움이 되는 문제를 해결하지 못합니다).
- 사용자가 데이터를 삭제하도록 하는 두 번째 방법은 비용을 청구하거나($ 비용) 수치심을 주는 것(명성 비용)입니다. Qumulo가 이야기한 수백 명의 관리자에 따르면 수치심은 실제로 청구하는 것보다 더 효과적입니다. 아마도 유치원에서 늦게 아이를 데리러 오는 부모에게 벌금을 부과하는 현상과 관련이 있을 수 있습니다. [실제로 지각을 증가시킵니다.]https://www.theguardian.com/commentisfree/2014/jan/23/fining-parents-unpunctual-school-pupils ) 사람들은 회사 자금의 100달러를 지출하는 데 만족할 수 있지만 동료가 100달러를 지출하고 있다는 사실을 알게 되면 불행할 수 있습니다.
- 세 번째 방법은 사용자가 "잊었습니다" 단계를 극복하고 생성한 데이터를 볼 수 있도록 돕는 것입니다. 여기서 아이디어는 사용자에게 생성한 데이터와 위치를 빠르게 표시하면 사용자가 여전히 필요한지 여부를 빠르게 결정할 수 있다는 것입니다.
솔루션
불행히도 수억 개의 파일을 처리할 때 보고서를 작성하기 위해 모든 파일을 살펴보는 것은 선택 사항이 아닙니다. 스토리지 시스템이 제공하는 성능은 엄청나며 많은 데이터를 처리하는 데 많은 시간이 걸립니다. , 그리고 당신이 얻는 데이터는 그것이 생성될 때까지 오래된 것입니다. 필요한 것은 답을 빠르고 저렴하게 계산하는 방법입니다. 1,000명의 아티스트가 1억 개의 파일에서 du's를 실행하는 것은 XNUMX조 개의 통계가 될 것입니다. 그런 일은 일어나지 않을 것입니다. 더 효율적인 것이 필요합니다.
샘플링 입력
정말 편할텐데 파일 시스템 샘플링 용량이 어디로 가는지 알아내기 위해… 무작위로 블록을 선택하고 블록이 어디에 살고 있는지 확인하고 용량이 어디로 가는지 파악합니다. 샘플링은 일부 리소스 소비에서 최악의 위반자를 찾을 때 잘 작동하지만 작은 기여자를 찾을 때는 제대로 작동하지 않습니다. 우리는 최악의 범죄자를 찾고 있으므로 샘플링이 도움이 될 수 있습니다.
그러나 기존 파일 시스템에 대한 열광적인 점 중 하나는 샘플링이 불가능하다는 것입니다. 예를 들어 대부분의 파일 시스템에서 무작위로 XNUMX개의 블록을 가져와서 어디에 있는지 알아낼 수 없습니다.
다이어그램 2에서 트리의 맨 위에서 아래로 샘플링을 구현하는 것을 고려하는 것이 도움이 됩니다. 이 전통적인 파일 시스템에서는 루트를 보고 샘플을 채취하기 위해 다음에 볼 위치를 파악할 수 없습니다. /home 또는 /tmp로 내려가야 하는지 여부를 루트에 지정합니다. 순진하게도 우리는 동전을 던지고 같은 확률로 아이를 고를 수 있습니다. 그러나 이것이 예상되는 50%에 비해 시간의 0.01%에서 /home에서 무언가를 샘플링한다는 것을 보는 것은 매우 쉽습니다. 전체 트리를 먼저 처리하지 않고 효과적으로 샘플링할 수 있는 정보가 파일 시스템에 충분하지 않습니다. 그러면 개체가 무효화됩니다.
샘플링은 도움이 될 수 있지만 기존 파일 시스템은 이를 수행할 수 없습니다.
Qumulo Core에서 샘플링
Qumulo Core는 모든 디렉토리가 그 아래에 있는 블록, 파일 및 기타 다양한 항목의 총 수를 추적한다는 불변성을 유지합니다. 이러한 합계를 집계라고 하며(NetApp에 대한 사과와 함께) 이러한 집계는 최종적으로 일관되지만 시기 적절한 방식으로(15초 정도) 업데이트됩니다.
이러한 집계에는 몇 가지 유용한 응용 프로그램이 있습니다. 예를 들어 위의 예에서 /home/pet에서 얼마나 많은 블록이 소비되었는지 알아내는 것은 아주 쉽습니다. /home/pet에 10개의 블록이 있음을 한 눈에 알 수 있습니다.
그러나 우리의 문제는 트리의 주어진 영역에서 특정 사용자가 소유한 파일의 수를 알고 싶기 때문에 더 복잡합니다. 이전에 논의한 바와 같이 샘플링을 사용하여 이 문제를 해결할 수 있습니다.
샘플링 응용 프로그램에서 이 트리의 루트를 보고 시간의 /home .01%를 샘플링하기로 결정할 수 있다는 것을 쉽게 알 수 있습니다(/home에 대한 sum_blocks를 / == .01%에 대한 sum_blocks로 나눈 값). 우리는 이 규칙을 모든 수준에서 재귀적으로 적용할 수 있으며 결국에는 무작위로 단일 블록을 샘플링할 수 있습니다.
Qumulo Core는 미리 구워진 API를 사용하여 이러한 종류의 샘플링을 쉽게 만듭니다. /v1/files/:ref:/샘플, 가중치를 부여하는 방법과 취할 샘플 수를 각각 제어하는 값과 한계에 따라 매개변수를 사용합니다. 이 API를 사용하면 sum_blocks에 의해 가중치가 부여되는 방식으로 샘플링할 수 있습니다(즉, /tmp는 시간의 99.99%로 샘플링되고 /home은 0.01%로 샘플링됨). 이것이 바로 우리가 필요로 하는 것입니다.
다음 무엇입니까?
샘플링은 훌륭하지만 그 자체로는 충분하지 않습니다. 그것은 우리에게 파일 목록을 제공합니다. 예를 들어:
| 입양 부모로서의 귀하의 적합성을 결정하기 위해 미국 이민국에 | 소유자 |
|---|---|
| /홈/피트/테스트 | 얼룩 |
| /tmp/큰 파일 | 뿌리 |
| /tmp/큰 파일 | 뿌리 |
| /tmp/큰 파일 | 얼룩 |
| /tmp/큰 파일 | 뿌리 |
| /tmp/큰 파일 | 뿌리 |
첫 번째 근사값은 루트가 소유한 공간의 비율을 83%로, 피트가 소유한 공간의 비율을 17%로 나타냅니다. 다음 단계로 소유자별로 샘플을 분류한 다음 각 소유자에 대한 트리를 차례로 표시하려고 합니다.
나무 다듬기
위의 예는 너무 단순합니다. 데이터 세트가 작기 때문에 동일한 파일이 반복적으로 샘플링되는 것을 보여줍니다. 현실 세계는 일반적으로 수용할 수 없습니다. 수억 개의 파일 데이터 세트의 100,000개 샘플에서 동일한 파일의 다중 샘플링을 몇 번만 얻을 수 있습니다. 다시 말해, 사용자에게 데이터를 표시하려고 하면 모든 리프가 되고 트리는 표시되지 않습니다.
우리의 목표는 용량을 사용한 파일에 대한 많은 일화를 사용자에게 알려주는 것이 아니었습니다. 대신 사용자에게 많은 데이터가 있을 수 있는 트리 영역에 대해 알려줍니다.
이 문제를 해결하기 위해 우리는 나무의 잎사귀를 가지치기하여 표본 수를 늘릴 수 있음을 관찰했습니다. 디렉토리에 있는 파일 샘플은 파일의 상위 디렉토리 샘플이기도 합니다. 즉, 다음과 같은 변환을 반복적으로 수행할 수 있습니다.
- 나무가 있는 가장 작은 표본 잎사귀 선택
- 트리에서 가지치기하고 샘플을 부모로 옮깁니다.
샘플을 사용 가능한 것으로 개선하는 데 사용하는 기본 알고리즘은 다음과 같습니다.
while leaves > max_leaves or lightest_leaf.samples < min_samples:
prune_lightest_leaf()</var/www/wordpress>
즉, 우리 나무가 더 적은 수의 더 무거운 잎으로 줄어들 때까지 우리는 계속해서 낮은 무게의 잎을 제거합니다.
우리의 목표는 사용자가 가장 관련성이 높은 파일 및 디렉터리에 집중할 수 있도록 결과 수를 제한하고 표시되는 용량의 양에 대해 합리적인 통계적 유의성을 제공하는 것입니다. 첫 번째 목표를 달성하기 위해 사용자가 리프 수에 제한을 설정할 수 있습니다. 두 번째를 달성하기 위해 사용자가 리프에서 허용되는 최소 샘플 수를 지정할 수 있습니다.
원하는 리프 수를 5개 이하로 설정하고 최소 리프 샘플링을 3개로 설정하면 결국 다음과 같이 됩니다.
최소 리프 무게의 목표를 달성하기 위해 제한보다 적은 수의 리프(3)로 끝납니다.
이것은 공간이 소비되는 사용자에게 지적하는 꽤 좋은 일을 합니다. 더 나은 방법을 알고 있다면 알고 싶습니다.
신뢰 구간 계산
최근의 선거로 많은 사람들이 샘플링의 정당성을 의심하게 되었지만 파일 시스템은 여론조사보다 몇 가지 이점이 있습니다. 첫째, 블록은 자신이 속한 파일에 대해 거짓말을 하지 않습니다. 둘째, 블록은 자신이 속한 파일이 무엇인지 알려주기를 거부하지 않습니다. 이 두 가지 사실을 결합하면 다음을 사용할 수 있습니다. 신뢰 구간 파일 시스템 트리의 지정된 영역에서 사용자가 소비하는 용량 범위를 정확하게 설명합니다. 이것이 작동하기 위해 우리는 가중치를 표시하는 트리의 각 노드가 특정 수의 샘플에서 특정 수의 적중을 기반으로 한다는 것을 관찰합니다. 나처럼 수학에 어려움이 있다면 이것을 찾을 수 있습니다. 유용한 신뢰 구간에 대한 더미 가이드. 여기서 중요한 점은 샘플링으로 어떤 것도 100% 얻을 수는 없지만 자신 있는 범위를 얻을 수 있다는 것입니다.
함께 모아서
다음과 같은 스크립트를 작성했습니다.
- 블록 수로 가중된 샘플을 가져옵니다.
- 샘플을 파일 소유자에 매핑
- 샘플을 나무에 투영하고 범위와 중요성이 제한될 때까지 해당 나무를 다듬습니다.
- 반환된 값에 대한 신뢰 구간을 계산합니다.
- 결과 덤프
공유 빌드 서버의 홈 디렉토리에 대해 이 스크립트를 실행하면 Windows VM이 많고 다른 것은 많지 않습니다.
bash-3.2$ python capacity_by_user.py -A -Uadmin -s50000 -x10 -Cgravytrain.eng.qumulo.com -i /home/pete 총계: [17.50G-17.50G] 소유자 NFS_UID:pete (~100.0%/[17.50 G-17.50G]) \--- \--- \---홈 \---피트 \---피트([17.50G-17.50G]) +---Windows 7 x64.vmwarevm([12.41 G-12.54G]) | +---Windows 7 x64-s001.vmdk([1.86G-1.95G]) | +---Windows 7 x64-s002.vmdk([1.92G-2.01G]) | +---Windows 7 x64-s003.vmdk([1.98G-2.08G]) | +---Windows 7 x64-s004.vmdk([1.93G-2.02G]) | +---Windows 7 x64-s005.vmdk([1.95G-2.05G]) | +---Windows 7 x64-s006.vmdk([1.33G-1.41G]) | \---Windows 7 x64.vmem([1002.22M-1.05G]) +---qfs-657.vmwarevm([2.87G-2.99G]) | +---qkiosk-3143-disk1.vmdk([1.74G-1.84G]) | \---qkiosk-3143-f195d503.vmem([978.60M-1.03G]) \---src.old \---product([1.52G-1.61G]) \---bin([1.28G] -1.36G]) \---user_linux64([549.10M-604.55M])
한가지 더 ...
나는 우리가 부끄러움에 대해 이야기할 것이라고 말했습니다. 테라바이트의 데이터를 가지고 있는 것을 부끄러워하는 사람은 없겠죠? 반면에 40년부터 1991년까지 모든 Windows 릴리스의 라이브러리를 유지하기 위해 회사에 월 $2016의 비용을 지출하는 것이 부끄럽습니까? 아마도? 그래서 월별 달러로 사용량을 출력하는 옵션(-D)을 추가했습니다.
출력 예는 다음과 같습니다.
소유자 NFS_UID:pete(~100.0%/[$0.75-$0.75]/월) \---home \---pete \---pete([$0.75-$0.75]/월) +---Windows 7 x64.vmwarevm ([$0.53-$0.54]/월) | +---Windows 7 x64-s001.vmdk([$0.08-$0.08]/월) | +---Windows 7 x64-s002.vmdk([$0.08-$0.09]/월) | +---Windows 7 x64-s003.vmdk([$0.08-$0.09]/월) | +---Windows 7 x64-s004.vmdk([$0.08-$0.09]/월) | +---Windows 7 x64-s005.vmdk([$0.08-$0.09]/월) | +---Windows 7 x64-s006.vmdk([$0.06-$0.06]/월) | \---Windows 7 x64.vmem([$0.04-$0.04]/월) +---qfs-657.vmwarevm([$0.12-$0.13]/월) | +---qkiosk-3143-disk1.vmdk([$0.08-$0.08]/월) | \---qkiosk-3143-f195d503.vmem([$0.04-$0.04]/월) \---src.old \---product([$0.07-$0.07]/월) \---bin([$0.06- $0.06]/월) \---user_linux64([$0.02-$0.03]/월)
좋은 소식은 내 창문 페티쉬가 한 달에 Qumulo로 기껏해야 75센트라는 것입니다. 그리고 아마도 그것조차 아닐 것입니다. 왜냐하면 우리는 스토리지를 거의 무료로 받기 때문입니다!
