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:
| Archive | Propietario |
|---|---|
| / 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
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()</var/www/wordpress>
En otras palabras, seguimos eliminando las hojas de bajo peso hasta que nuestro árbol se haya reducido a un número menor de hojas de peso más pesado.
Nuestro objetivo es limitar la cantidad de resultados para que los usuarios puedan centrarse en los archivos y directorios más relevantes, y también proporcionar una importancia estadística razonable para la cantidad de capacidad mostrada. Para lograr el primer objetivo, permitimos al usuario establecer un límite en el número de hojas. Para lograr el segundo, permitimos que el usuario especifique el número mínimo de muestras permitidas en una hoja.
Si configuramos el número deseado de hojas para que no sea más que 5, y el muestreo mínimo de hojas sea 3, eventualmente terminaremos con esto:
Tenga en cuenta que terminamos con un número menor de hojas (3) que el límite, con el fin de lograr el objetivo de peso mínimo de la hoja.
Esto hace un buen trabajo de señalar a un usuario donde se consume espacio. Nos encantaría saber si conoces una manera mejor.
Informes de intervalos de confianza.
Si bien las elecciones recientes han puesto en duda la legitimidad del muestreo en la mente de muchos, los sistemas de archivos tienen algunas ventajas sobre las encuestas. Primero, los bloques no mienten sobre de qué archivo forman parte. Segundo, los bloques no se niegan a decirte de qué archivo forman parte. La combinación de esos dos hechos nos permite utilizar intervalos de confianza para describir con precisión el rango de capacidad consumida por un usuario en un área determinada de un árbol de sistema de archivos. Para que esto funcione, observamos que cada nodo en el árbol para el que estamos mostrando un peso se basa en un cierto número de visitas en un cierto número de muestras. Si tienes problemas de matemáticas como yo, puedes encontrar esto para Guía de maniquíes de intervalos de confianza útil. El punto principal aquí es que no puede obtener nada 100% con el muestreo, pero puede obtener un rango en el que confía.
Cómo aplicar todos los conceptos
Construimos un script que:
- Toma muestras ponderadas por conteo de bloques.
- Mapas de muestras en propietarios de archivos
- Proyecta las muestras en árboles y refina esos árboles hasta que tengan un alcance y un significado limitados.
- Calcula los intervalos de confianza para los valores devueltos.
- Vuelca los resultados
Al ejecutar este script en mi directorio de inicio en nuestro servidor de compilación compartido, veo que tengo muchas máquinas virtuales de Windows y no muchas más:
bash-3.2 $ python capacity_by_user.py -A -Uadmin -s50000 -x10 -Cgravytrain.eng.qumulo.com -i / home / pete Total: [17.50G-17.50G] Propietario NFS_UID: pete (~ 100.0% / [17.50 G-17.50G]) \ --- \ --- \ --- inicio \ --- 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 \ --- producto ([1.52G-1.61G]) \ --- bin ([1.28G -1.36G]) \ --- user_linux64 ([549.10M-604.55M])
Una cosa más ...
Dije que íbamos a hablar de shameback. Nadie está naturalmente avergonzado de tener un terabyte de datos, ¿verdad? Por otro lado, ¿te avergonzarías de costarle a tu empresa $ 40 / mes para que mantengas una biblioteca de cada versión de Windows de 1991 a 2016? ¿Tal vez? Por lo tanto, agregamos una opción (-D) para imprimir el uso en términos de dólares por mes.
A continuación se muestra un ejemplo de salida:
Propietario NFS_UID: pete (~ 100.0% / [$ 0.75- $ 0.75] / mes) \ --- home \ --- pete \ --- pete ([$ 0.75- $ 0.75] / mes) + --- Windows 7 x64.vmwarevm ([$ 0.53- $ 0.54] / mes) | + --- Windows 7 x64-s001.vmdk ([$ 0.08- $ 0.08] / mes) | + --- Windows 7 x64-s002.vmdk ([$ 0.08- $ 0.09] / mes) | + --- Windows 7 x64-s003.vmdk ([$ 0.08- $ 0.09] / mes) | + --- Windows 7 x64-s004.vmdk ([$ 0.08- $ 0.09] / mes) | + --- Windows 7 x64-s005.vmdk ([$ 0.08- $ 0.09] / mes) | + --- Windows 7 x64-s006.vmdk ([$ 0.06- $ 0.06] / mes) | \ --- Windows 7 x64.vmem ([$ 0.04- $ 0.04] / mes) + --- qfs-657.vmwarevm ([$ 0.12- $ 0.13] / mes) | + --- qkiosk-3143-disk1.vmdk ([$ 0.08- $ 0.08] / mes) | \ --- qkiosk-3143-f195d503.vmem ([$ 0.04- $ 0.04] / mes) \ --- src.old \ --- producto ([$ 0.07- $ 0.07] / mes) \ --- bin ([$ 0.06- $ 0.06] / mes) \ --- user_linux64 ([$ 0.02- $ 0.03] / mes)
La buena noticia es que el fetiche de Windows cuesta a lo sumo centavos de Qumulo 75 por mes. Y probablemente ni siquiera eso, porque obtenemos nuestro almacenamiento prácticamente gratis!
