Je discutais avec l'un des clients d'animation de Qumulo de l'utilisation de la capacité, et ils ont mentionné qu'ils avaient particulièrement du mal à amener les gens à supprimer des données : ils ont environ un millier d'artistes travaillant tous dans la même arborescence de système de fichiers avec des centaines de millions de fichiers ! Lorsqu'ils commencent à manquer de capacité, ils doivent appliquer une contre-pression. Mais, pour le faire efficacement, ils doivent dire aux gens quelle capacité ils consomment : il n'est pas pratique pour un millier d'utilisateurs d'explorer des centaines de millions de fichiers. Ainsi, ce client avait créé un code personnalisé qui a fonctionné pendant de nombreuses heures, accumulant des données sur l'empreinte de chaque utilisateur. C'était lent et lourd, gourmand en ressources, difficile à maintenir et fournissait des informations obsolètes. Le client nous a mis au défi de fournir quelque chose de mieux.
Comment amener les utilisateurs à supprimer des données?
Une partie douloureuse de l'administration des données est que les personnes créent des données et ne les libèrent jamais. Et cela ne fait pas de mal à tout le monde, jusqu'à ce que tout le monde soit à court d'espace et que tout le monde doive aller chercher des choses à supprimer. À quel point leur application est en train de tomber et tout le monde a oublié ce qu'ils ont créé.
Le calendrier ressemble à ceci:
Cas de réussite
- Les administrateurs de stockage savent qu'il existe plusieurs moyens d'inciter les utilisateurs à supprimer des données.
Vous pouvez couper vos utilisateurs.- Vous pourriez laisser toute votre application tomber en morceaux alors que le système de stockage s'arrête finalement. Comme il arrive souvent, de nombreux systèmes de stockage tombent en panne lorsqu'ils atteignent un taux de réussite de 100… assurez-vous de demander à votre fournisseur de stockage quelles sont ses performances et si vous êtes protégé contre les pannes de disque lorsque vous remplissez votre système de stockage.
- Vous pouvez définir des quotas, peut-être sur des utilisateurs, ou peut-être sur des répertoires. Cela fonctionne très bien, mais il brise encore les applications (les fichiers peuvent être corrompus lorsqu'une application rencontre des conditions de manque d'espace, par exemple, et cela ne résout pas le problème d'aider l'utilisateur à déterminer ce qu'il faut supprimer).
- La deuxième façon d'inciter les utilisateurs à supprimer des données consiste à les facturer (coût en dollars) ou à leur faire honte (coût de réputation). Selon les centaines d'administrateurs avec lesquels Qumulo a parlé, la honte fonctionne mieux que la facturation. Peut-être est-ce lié au phénomène par lequel les parents qui paient leurs enfants en retard à l'école maternelle sont en train de payer une amende [ce qui augmente les retards.] ) Les gens peuvent être heureux de dépenser $ 2014 de l’argent de leur entreprise, mais ils sont mécontents de voir leur collègue savoir qu’ils dépensent $ 23
- La troisième méthode consiste à aider les utilisateurs à surmonter l'étape «Je l'oublie» et à voir quelles données ils ont créées. L'idée ici est que si vous montrez rapidement à un utilisateur quelles données il a créées et où, elles peuvent prendre une décision rapide quant à savoir si elles sont toujours nécessaires.
Solutions
Malheureusement, lorsqu’il s’agit de centaines de millions de fichiers, il n’est pas possible d’envisager chacun d’entre eux pour créer un rapport. , et les données que vous obtenez sont obsolètes au moment où elles sont produites. Ce qu'il faut, c'est un moyen de calculer rapidement et à moindre coût une réponse. Les artistes 1,000 qui exécutent du's sur des milliards de fichiers 1 seraient un trillion de statistiques… ne se produiraient pas. Nous avons besoin de quelque chose de plus efficace.
Entrer dans l'échantillonnage
Ce serait vraiment pratique de échantillonner le système de fichiers pour savoir où se situe la capacité… pour choisir des blocs au hasard, voir où ils vivent et avoir une idée de la capacité. L'échantillonnage fonctionne bien lorsque vous recherchez les plus mauvais délinquants dans la consommation de certaines ressources, mais mal lorsque vous recherchez de petits contributeurs. Nous recherchons les pires délinquants, alors peut-être que l'échantillonnage peut aider.
Mais l'un des aspects les plus inquiétants des systèmes de fichiers traditionnels est qu'ils sont impossibles à échantillonner. Pour la plupart des systèmes de fichiers, nous ne pouvons pas, par exemple, prendre une centaine de blocs au hasard et savoir où ils vivent.
Il est utile d’envisager d’essayer d’implémenter l’échantillonnage en haut de l’arbre, dans le diagramme 2. Dans ce système de fichiers traditionnel, nous ne pouvons pas regarder la racine et déterminer où chercher un échantillon, car il n'y a rien à la racine pour savoir si nous devons descendre vers / home ou vers / tmp. Naïvement, nous pourrions lancer une pièce et choisir un enfant avec la même probabilité. Il est assez facile de voir, cependant, que cela échantillonnerait quelque chose dans / home 50% du temps, par rapport au% 0.01 attendu. Il n'y a tout simplement pas assez d'informations dans le système de fichiers pour échantillonner efficacement sans traiter tout l'arborescence en premier, ce qui irait à l'encontre de l'objet.
L'échantillonnage aiderait, mais les systèmes de fichiers traditionnels ne peuvent pas le faire.
Échantillonnage dans Qumulo Core
Qumulo Core maintient l'invariant selon lequel chaque répertoire suit le nombre total de blocs, de fichiers et de divers autres éléments situés en dessous. Ces totaux sont appelés des agrégats (avec des excuses de NetApp), et ces agrégats sont mis à jour de manière cohérente, mais opportune (pensez secondes 15).
Ces agrégats ont des applications utiles. Par exemple, il est trivialement facile de savoir combien de blocs sont consommés sous / home / pete dans l'exemple ci-dessus. Nous pouvons voir d'un coup d'œil que / home / pete contient des blocs 10.
Notre problème est plus compliqué, cependant, car nous voulons savoir combien de fichiers appartiennent à un utilisateur spécifique dans une zone donnée d'un arbre. Comme nous l'avons vu précédemment, nous pouvons utiliser l'échantillonnage pour résoudre ce problème.
Il est facile de voir que dans une application d'échantillonnage, on peut regarder la racine de cet arbre et décider d'écrire / home .01% du temps (sum_blocks pour / home divisé par sum_blocks pour / == .01%). Nous pouvons appliquer cette règle de manière récursive à chaque niveau et éventuellement échantillonner un seul bloc au hasard.
Qumulo Core facilite ce type d’échantillonnage avec une API pré-cuite, / v1 / files /: ref: / sample, qui prend les paramètres by-value et limit, qui contrôlent la pondération et le nombre d'échantillons à prendre, respectivement. Cette API nous permet de prélever un échantillon pondéré par sum_blocks (c.-à-d. Que / tmp est échantillonné 99.99% du temps, contre / home à 0.01%), ce qui est exactement ce dont nous avons besoin.
Que faire ensuite?
L'échantillonnage est excellent, mais pas suffisant. Il nous donne une liste de fichiers. Par exemple:
| Déposez le | Avantage pour le Propriétaire |
|---|---|
| / home / pete / test | taches |
| / tmp / bigfile | racine |
| / tmp / bigfile | racine |
| / tmp / bigfile | taches |
| / tmp / bigfile | racine |
| / tmp / bigfile | racine |
Une première approximation donne la proportion d'espace appartenant à root en tant que 83% et par pete en tant que 17%. Dans une prochaine étape, nous souhaitons décomposer les échantillons par les propriétaires, puis afficher à leur tour un arbre pour chaque propriétaire.
Affiner l'arbre
L'exemple ci-dessus est trop simpliste: il montre les mêmes fichiers en cours d'échantillonnage, car notre jeu de données est petit. Le monde réel n'est généralement pas aussi accommodant: dans les échantillons 100,000 d'un ensemble de données de centaines de millions de fichiers, nous pourrions obtenir un échantillonnage multiple du même fichier à quelques reprises seulement. En d'autres termes, si nous essayons de montrer des données aux utilisateurs, cela va être tout l'arbre feuille ou pas:
Notre objectif n'était pas de dire aux utilisateurs un tas d’anecdotes sur les fichiers sur lesquels ils ont utilisé la capacité. Au lieu de cela, il s'agit d'indiquer aux utilisateurs la zone de l'arborescence où ils peuvent avoir beaucoup de données.
Pour résoudre ce problème, nous observons que nous pouvons tailler les feuilles dans l’arbre, en déplaçant le nombre de leurs échantillons. Un exemple de fichier dans un répertoire est également un exemple du répertoire parent du fichier. En d'autres termes, nous pouvons faire la transformation suivante à plusieurs reprises:
- Choisissez la plus petite feuille échantillonnée avec l'arbre
- Élaguez-le et déplacez ses échantillons vers son parent.
Visuellement, cette transformation ressemble à ceci:
L'algorithme de base que nous utilisons pour affiner les échantillons dans quelque chose utilisable va comme suit:
while leaves > max_leaves or lightest_leaf.samples < min_samples:
prune_lightest_leaf()
In other words, we keep removing low-weight leaves until our tree has been reduced to a smaller number of heavier-weight leaves.
Our goal is to limit the number of results so users can focus on the most relevant files and directories, and also to provide reasonable statistical significance for the amount of capacity displayed. To achieve the first goal, we allow the user to set a limit on the number of leaves. To achieve the second, we allow the user to specify the minimum number of samples allowed at a leaf.
If we set the desired number of leaves to be no more than 5, and the minimum leaf sampling to be 3, eventually we’ll end up with this:
Note that we end up with a smaller number of leaves (3) than the limit, in order to accomplish the goal of minimum leaf weight.
This does a pretty good job of pointing out to a user where space is consumed. We’d love to know if you know of a better way.
Computing confidence intervals
While recent elections have cast the legitimacy of sampling into doubt in the minds of many, file systems have some advantages over polls. First, blocks don’t lie about what file they’re a part of. Second, blocks don’t refuse to tell you what file they’re a part of. The combination of those two facts allows us to use confidence intervals to accurately describe the range of capacity consumed by a user in a given area of a file system tree. For this to work we observe that each node in the tree we’re displaying a weight for is based on a certain number of hits in a certain number of samples. If you’re math-challenged like me you may find this for dummies guide to confidence intervals helpful. The main point here is that you can’t get anything 100% with sampling, but you can get a range you’re confident in.
Putting it all together
We built a script that:
- Takes samples weighted by block count
- Maps samples into file owners
- Projects the samples into trees, and refines those trees until they have constrained scope and significance
- Computes the confidence intervals for the returned values
- Dumps the results
Running this script against my home directory on our shared build server, I see I have a lot of Windows VM and not a lot else:
bash-3.2$ python capacity_by_user.py -A -Uadmin -s50000 -x10 -Cgravytrain.eng.qumulo.com -i /home/pete
Total: [17.50G-17.50G]
Owner NFS_UID:pete (~100.0%/[17.50G-17.50G])
\---
\---
\---home
\---pete
\---pete([17.50G-17.50G])
+---Windows 7 x64.vmwarevm([12.41G-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])
One more thing…
I did say that we were going to talk about shameback. No one is naturally ashamed of having a terabyte of data, right? On the other hand, would you be ashamed of costing your company $40/month so that you maintain a library of every windows release from 1991 to 2016? Maybe? So, we added an option (-D) to print out usage in terms of dollars per month.
An example output is below:
Owner NFS_UID:pete (~100.0%/[$0.75-$0.75]/month)
\---home
\---pete
\---pete([$0.75-$0.75]/month)
+---Windows 7 x64.vmwarevm([$0.53-$0.54]/month)
| +---Windows 7 x64-s001.vmdk([$0.08-$0.08]/month)
| +---Windows 7 x64-s002.vmdk([$0.08-$0.09]/month)
| +---Windows 7 x64-s003.vmdk([$0.08-$0.09]/month)
| +---Windows 7 x64-s004.vmdk([$0.08-$0.09]/month)
| +---Windows 7 x64-s005.vmdk([$0.08-$0.09]/month)
| +---Windows 7 x64-s006.vmdk([$0.06-$0.06]/month)
| \---Windows 7 x64.vmem([$0.04-$0.04]/month)
+---qfs-657.vmwarevm([$0.12-$0.13]/month)
| +---qkiosk-3143-disk1.vmdk([$0.08-$0.08]/month)
| \---qkiosk-3143-f195d503.vmem([$0.04-$0.04]/month)
\---src.old
\---product([$0.07-$0.07]/month)
\---bin([$0.06-$0.06]/month)
\---user_linux64([$0.02-$0.03]/month)
The good news is that my windows fetish is at most costing Qumulo 75 cents a month. And probably not even that, because we get our storage pretty much for free!
You can get your copy of capacity_by_user.py here!
Test drive Qumulo for free
Explore a fully functional Qumulo environment, right in your browser.
Try Demo
