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 | Propriétaires |
|---|---|
| / 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.
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()</var/www/wordpress>
En d'autres termes, nous continuons à enlever les feuilles de faible poids jusqu'à ce que notre arbre ait été réduit à un nombre réduit de feuilles plus lourdes.
Notre objectif est de limiter le nombre de résultats afin que les utilisateurs puissent se concentrer sur les fichiers et répertoires les plus pertinents, et également pour fournir une signification statistique raisonnable pour la quantité de capacité affichée. Pour atteindre le premier objectif, nous permettons à l'utilisateur de fixer une limite au nombre de feuilles. Pour réaliser le second, nous permettons à l'utilisateur de spécifier le nombre minimum d'échantillons autorisés sur une feuille.
Si nous définissons le nombre de feuilles souhaité comme n'étant plus que 5, et que l'échantillonnage minimal des feuilles soit 3, nous finirons par avoir ceci:
Notez que nous nous retrouvons avec un plus petit nombre de feuilles (3) que la limite, afin d'atteindre l'objectif de poids minimum des feuilles.
Cela fait un très bon travail de signaler à un utilisateur où l'espace est consommé. Nous aimerions savoir si vous connaissez une meilleure façon.
Calcul des intervalles de confiance
Bien que les récentes élections aient mis en doute la légitimité de l'échantillonnage dans l'esprit de beaucoup, les systèmes de fichiers présentent certains avantages par rapport aux sondages. Tout d'abord, les blocs ne mentent pas sur le fichier dont ils font partie. Deuxièmement, les blocs ne refusent pas de vous dire à quel fichier ils appartiennent. La combinaison de ces deux faits nous permet d'utiliser intervalles de confiance pour décrire avec précision la plage de capacité consommée par un utilisateur dans une zone donnée d'une arborescence de systèmes de fichiers. Pour que cela fonctionne, nous observons que chaque nœud de l'arborescence pour laquelle nous affichons un poids est basé sur un certain nombre de résultats dans un certain nombre d'échantillons. Si vous êtes aux prises avec les mathématiques comme moi, vous trouverez peut-être cela pour guide des mannequins pour les intervalles de confiance utiles. Le point principal ici est que vous ne pouvez rien obtenir avec 100% avec un échantillonnage, mais vous pouvez obtenir une plage en laquelle vous avez confiance.
Mettre le tout ensemble
Nous avons construit un script qui:
- Prend des échantillons pondérés par nombre de blocs
- Mapper des exemples dans les propriétaires de fichiers
- Projette les échantillons dans des arbres et affine ces arbres jusqu'à ce qu'ils aient une portée et une importance limitées
- Calcule les intervalles de confiance pour les valeurs renvoyées
- Décharge les résultats
En exécutant ce script sur mon répertoire personnel sur notre serveur de build partagé, je constate que je possède beaucoup de machines virtuelles Windows et pas grand-chose d'autre:
bash-3.2 $ python capacity_by_user.py -A -Uadmin -s50000 -x10 -Cgravytrain.eng.qumulo.com -i / home / pete Total: [17.50G-17.50G] Propriétaire NFS_UID: pete (~ 100.0% / [17.50 G-17.50G]) \ --- \ --- \ --- accueil \ --- pete \ --- pete ([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 \ --- produit ([1.52G-1.61G]) \ --- bin ([1.28G -1.36G]) \ --- user_linux64 ([549.10M-604.55M])
Une dernière chose ...
J'ai dit que nous allions parler de honte. Personne n'a naturellement honte d'avoir un téraoctet de données, n'est-ce pas? D'un autre côté, auriez-vous honte de coûter à votre entreprise $ 40 / month afin de maintenir une bibliothèque de toutes les versions de Windows de 1991 à 2016? Peut être? Nous avons donc ajouté une option (-D) pour imprimer l'utilisation en termes de dollars par mois.
Un exemple de sortie est ci-dessous:
Propriétaire NFS_UID: pete (~ 100.0% / [0.75 $ - 0.75 $] / mois) \ --- home \ --- pete \ --- pete ([0.75 $ - 0.75 $] / mois) + --- Windows 7 x64.vmwarevm ([0.53 $ - 0.54 $] / mois) | + --- Windows 7 x64-s001.vmdk ([0.08 $ - 0.08 $] / mois) | + --- Windows 7 x64-s002.vmdk ([0.08 $ - 0.09 $] / mois) | + --- Windows 7 x64-s003.vmdk ([0.08 $ - 0.09 $] / mois) | + --- Windows 7 x64-s004.vmdk ([0.08 $ - 0.09 $] / mois) | + --- Windows 7 x64-s005.vmdk ([0.08 $ - 0.09 $] / mois) | + --- Windows 7 x64-s006.vmdk ([0.06 $ - 0.06 $] / mois) | \ --- Windows 7 x64.vmem ([0.04 $ - 0.04 $] / mois) + --- qfs-657.vmwarevm ([0.12 $ - 0.13 $] / mois) | + --- qkiosk-3143-disk1.vmdk ([0.08 $ - 0.08 $] / mois) | \ --- qkiosk-3143-f195d503.vmem ([0.04 $ - 0.04 $] / mois) \ --- src.old \ --- produit ([0.07 $ - 0.07 $] / mois) \ --- bin ([0.06 $- 0.06 $] / mois) \ --- user_linux64 ([0.02 $ - 0.03 $] / mois)
La bonne nouvelle est que mon fétichisme de Windows coûte tout au plus le Qumulo 75 par mois. Et peut-être même pas cela, car nous obtenons notre stockage à peu près gratuitement!
