Estaba hablando con uno de los clientes de animación de Qumulo sobre la utilización de la capacidad, y mencionó que les resulta particularmente difícil lograr que las personas eliminen datos: ¡tienen aproximadamente mil artistas trabajando en el mismo árbol del sistema de archivos con cientos de millones de archivos! Cuando empiezan a quedarse sin capacidad, tienen que aplicar contrapresión. Pero, para hacerlo de manera efectiva, tienen que decirle a la gente qué capacidad están consumiendo: no es práctico para mil usuarios rastrear cientos de millones de archivos. Entonces, este cliente había creado un código personalizado que se ejecutó durante muchas horas acumulando datos sobre la huella de cada usuario. Esto era lento y engorroso, requería muchos recursos, era difícil de mantener y proporcionaba información desactualizada. El cliente nos desafió a ofrecer algo mejor.
¿Cómo consigues que los usuarios borren datos?
Una parte dolorosa de la administración de datos es que las personas crean datos y nunca los liberan. Y realmente no duele nada, hasta que todos se quedan sin espacio, y todos tienen que buscar cosas que eliminar. En qué punto se está cayendo su aplicación y todos han olvidado lo que crearon.
El tipo de línea de tiempo se parece a esto:
Mejores prácticas
- Los administradores de almacenamiento saben que hay algunas maneras de hacer que las personas eliminen datos.
Puedes cortar a tus usuarios.- Podría dejar que toda su aplicación se desmorone cuando el sistema de almacenamiento finalmente se detenga. Como sucede, muchos sistemas de almacenamiento también se deshacen cuando llegan a 100% lleno ... asegúrese de preguntarle a su proveedor de almacenamiento cómo está el rendimiento y si está protegido contra fallas en la unidad cuando llena su sistema de almacenamiento.
- Puede establecer cuotas, tal vez en usuarios, o tal vez en directorios. Esto funciona muy bien, pero todavía rompe las aplicaciones (los archivos pueden dañarse cuando una aplicación encuentra condiciones de falta de espacio, por ejemplo, y no resuelve el problema de ayudar al usuario a descubrir qué eliminar).
- La segunda forma de hacer que los usuarios eliminen datos es cobrarles (costo de $) o avergonzarlos (costo de reputación). Según los cientos de administradores con los que ha hablado Qumulo, la vergüenza en realidad funciona mejor que cargar. Tal vez esté relacionado con el fenómeno por el cual multar a los padres por recoger a sus hijos tarde en la guardería [en realidad aumenta la tardanza]. Https://www.theguardian.com/commentisfree/2014/jan/23/fining-parents-unpunctual-school-pupils ) La gente puede estar contenta gastando $ 100 del dinero de su compañía, pero no está contenta de que su compañero de trabajo sepa que está gastando $ 100
- La tercera forma es ayudar a los usuarios a superar la etapa "Lo olvido" y ayudarlos a ver qué datos han creado. La idea aquí es que si le muestra rápidamente a un usuario los datos que ha creado y dónde, puede tomar una decisión rápida sobre si aún es necesaria.
Soluciones
Desafortunadamente, cuando se trata de cientos de millones de archivos, mirar cada uno de ellos para crear un informe simplemente no es una opción ... es una tonelada de rendimiento para un sistema de almacenamiento, se necesita mucho tiempo para procesar tanta información , y los datos que obtiene están desactualizados en el momento en que se producen. Lo que se necesita es una forma rápida y económica de calcular una respuesta. Los artistas de 1,000 que ejecuten du en archivos de miles de millones de 1 serían un billón de estadísticas ... no van a suceder. Necesitamos algo más eficiente.
Entrar en muestreo
Sería muy conveniente para muestra el sistema de archivos para averiguar dónde termina la capacidad ... para elegir bloques al azar, ver dónde viven y tener una idea de hacia dónde se dirige la capacidad. El muestreo funciona bien cuando busca a los peores infractores en el consumo de algún recurso, pero mal cuando busca pequeños contribuyentes. Estamos buscando a los peores infractores, por lo que tal vez el muestreo pueda ayudar.
Pero una de las cosas enloquecedoras de los sistemas de archivos tradicionales es que son imposibles de muestrear. Para la mayoría de los sistemas de archivos, no podemos, por ejemplo, tomar cien bloques al azar y descubrir dónde viven.
Es útil considerar la posibilidad de intentar implementar el muestreo desde la parte superior de un árbol hacia abajo, en el diagrama 2. En este sistema de archivos tradicional, no podemos mirar la raíz y averiguar dónde buscar a continuación para tomar una muestra, porque no hay nada que nos diga en la raíz si debemos descender a / home o a / tmp. De manera ingenua, podríamos lanzar una moneda y elegir un niño con la misma probabilidad. Sin embargo, es bastante fácil ver que esto muestrearía algo en / home 50% del tiempo, en comparación con el 0.01% esperado. Simplemente no hay suficiente información en el sistema de archivos para muestrear de manera efectiva sin procesar primero todo el árbol, lo que anularía el objeto.
El muestreo ayudaría, pero los sistemas de archivos tradicionales no pueden hacerlo.
Muestreo en Qumulo Core
Qumulo Core mantiene la constante de que cada directorio rastrea el número total de bloques, archivos y otras cosas que viven debajo de él. Esos totales se llaman agregados (con disculpas a NetApp), y esos agregados se actualizan de una manera eventualmente consistente pero oportuna (piense en 15 segundos).
Esos agregados tienen algunas aplicaciones útiles. Por ejemplo, es trivialmente fácil averiguar cuántos bloques se consumen en / home / pete en el ejemplo anterior. Podemos ver de un vistazo que / home / pete tiene bloques 10.
Sin embargo, nuestro problema es más complicado porque queremos averiguar cuántos archivos son propiedad de un usuario específico en un área determinada de un árbol. Como vimos anteriormente, podemos usar el muestreo para resolver este problema.
Es fácil ver que en una aplicación de muestreo, podemos ver la raíz de este árbol y decidir muestrear / home .01% del tiempo (sum_blocks for / home dividido por sum_blocks para / == .01%). Podemos aplicar esta regla de forma recursiva en cada nivel y, finalmente, muestrear un solo bloque al azar.
Qumulo Core facilita este tipo de muestreo con una API precocida, / v1 / files /: ref: / sample, que toma parámetros por valor y límite, que controlan cómo ponderar, y el número de muestras a tomar, respectivamente. Esta API nos permite muestrear de una manera que está ponderada por sum_blocks (es decir, / tmp se muestrea el 99.99% del tiempo, vs. / home en 0.01%), que es exactamente lo que necesitamos.
¿Y ahora qué?
El muestreo es excelente, pero no es suficiente por sí solo. Nos da una lista de archivos. Por ejemplo:
| Declarar impuestos | PropietarioS |
|---|---|
| / home / pete / test | pete |
| / tmp / bigfile | raíz |
| / tmp / bigfile | raíz |
| / tmp / bigfile | pete |
| / tmp / bigfile | raíz |
| / tmp / bigfile | raíz |
Una primera aproximación da la proporción de espacio propiedad de la raíz como 83%, y de pete como 17%. Como paso siguiente, deseamos desglosar las muestras por propietarios y luego mostrar un árbol para cada uno de ellos a su vez.
Refinando el arbol
El ejemplo anterior es demasiado simplista: muestra los mismos archivos que se muestrean repetidamente, porque nuestro conjunto de datos es pequeño. El mundo real no suele ser tan complaciente: en las muestras 100,000 de un conjunto de datos de cientos de millones de archivos, es posible que obtengamos una muestra múltiple del mismo archivo solo unas pocas veces. En otras palabras, si intentamos mostrar datos a los usuarios, será todo hoja y ningún árbol:
Nuestro objetivo no era contar a los usuarios un montón de anécdotas sobre los archivos en los que han utilizado la capacidad. En cambio, es para informar a los usuarios sobre el área del árbol donde pueden tener una gran cantidad de datos.
Para resolver este problema, observamos que podemos podar las hojas en el árbol, moviendo sus conteos de muestras hacia arriba. Una muestra de un archivo en un directorio también es una muestra del directorio principal del archivo. En otras palabras, podemos hacer repetidamente la siguiente transformación:
- Elige la hoja más pequeña muestreada con el árbol.
- Podarlo del árbol y mover sus muestras a su padre
Visualmente, esa transformación se ve así:
El algoritmo básico que utilizamos para refinar muestras en algo utilizable es el siguiente:
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
