¿Alguna vez has tenido problemas relacionados con el tamaño de tu almacenamiento? Si usas docker en tu vida diaria, ya sea para despliegues o simplemente para pruebas, veamos como puedes reproducir estos problemas con el almacenamiento con docker.
Normalmente consideras que el almacenamiento tiene un tamaño ilimitado. Puedes tener fácilmente almacenamiento de 1TB y normalmente puedes aumentar ese almacenamiento de alguna forma. Normalmente no te tienes que preocupar de que te falte espacio en disco, pero dependiendo de a la aplicación que estés desarrollando podrías llenar el disco en algún momento.
Por ejemplo, si tienes que manejar información de un máximo de 50 usuarios, mientras tengas suficiente espacio, el tamaño que necesitas en disco se mantendrá estable. Estás seguro de que la aplicación no usará más de 5GB de espacio en el disco.
Sin embargo, si trabajas con archivos grandes, no podrás mantener el uso del disco bajo límtes normales. Un archivo grande podría usar 50GB o más, y necesitarás almacenar unos cuantos. Tu almacenamiento de 1TB podría no ser suficiente. Además, otras aplicaciones usarán espacio de disco, así que el tamaño restante podría reducirse a menos de la mitad.
Incluso más, los despliegues basados en la nube podrían imponer quotas, limitando el tamaño efectivo de tu almacenamiento a 10GB a menos que pagues por más almacenamiento.
¿Por qué necesitamos probar con un almacenamiento limitado en tamaño?
Como se ha dicho, no te puedes fiar de que tu aplicación tendrá un almacenamiento ilimitado. Podrías tener un error sobre espacio insuficiente en disco en cualquier momento. Incluso si controlas el espacio disponible, podrías necesitar hacer algo cuando te queden menos del 10% del disco.
Esto no es tan solo un problema para tu aplicación del servidor, sino también para cualquier cliente que tu aplicación pudiera tener. Por ejemplo, una aplicación móvil puede subir un fichero a tu servidor, pero tu servidor puede no tener suficiente espacio. El servidor necesita limpiar todo después de la operación fallida (metadatos que podrían quedar asumiendo que la operación tuvo éxito), y también necesita asegurarse que el cliente móvil recibe un error adecuado. Obviamente, la aplicación móvil necesita gestionar ese error.
No puedes resolver un problema si no puedes reproducirlo
Reproducir estos problemas no es fácil:
- El almacenamiento normalmente es grande, y necesitamos llenarlo de alguna forma. Necesitaríamos:
- Subir ficheros de tamaños de GB o más grandes
- Generar un gran archivo aleatorio en el disco
- Generar una gran cantidad de ficheros en el disco
- Una combinación de todo lo de arriba
- Rellenar el almacenamiento puede ser problemático si está en tu propio ordenador. Podrías tener problemas intentando probar el escenario debido a la falta de espacio en tu ordenador.
- Incluso si el servidor está en tu propio equipo, otros servicios no relacionados podrían tener problemas en ejecutarse.
Tendremos que asumir que el problema sucederá en nuestra aplicación, y que el resto del sistema se comportará adecuadamente. Por ejemplo, mientras subimos un archivo grande a través de apache o node.js, tendremos que asumir que el fichero se sube adecuadamente y alcanza nuestra aplicación; apache podría no obtener todo el fichero debido a problemas de espacio y apache podría denegar la subida, pero no nosotros.
tmpfs al rescate
El truco principal que vamos a usar es montar un sistema de ficheros tmpfs en una carpeta específica. La expectativa es que la aplicación escriba todo dentro de esa carpeta. Dependiendo de cómo la aplicación escriba en disco, podríamos necesitar diferentes puntos de montaje: uno para los logs, otro para los recursos subidos, otro para los certificados, etc. Esto es principalmente para asegurar que cada pieza que escribe en disco puede gestionar el error de una manera adecuada.
El punto principal es que tmpfs nos permite controlar el tamaño del sistema de ficheros. Podemos limitar fácilmente el sistema de ficheros a 50MB. Esto significa que la carpeta tendrá contenidos hasta alcanzar esos 50MB.
Esta aproximación tiene varias ventajas:
- No molestas a otras aplicaciones y servicios. La limitación tan sólo se aplica a esa carpeta, y sólo la conoce la aplicación. El resto de aplicaciones no deberían saber nada sobre la carpeta. Mientras tengas suficiente espacio en el ordenador, el resto de aplicaciones no se darán cuenta
- Puedes controlar el tamaño justo antes de montar tmpfs. Puedes configurar el punto de montaje para que use sólo 50MB, así que llenarlo es muy fácil.
Ten en cuenta que tmpfs almacena toda su información en la RAM y quizás en el swap. Sobredimensionar tmpfs puede causar un bloqueo en la máquina, así que deberías configurar un tamaño pequeño en relación con el tamaño de la memoria. Probablemente menos de un 10% de la memoria disponible está bien. Necesitas considerar otras aplicaciones en ejecución, la memoria que el sistema operativo está usando, y otras cosas que pudieran estar consumiendo la RAM.
Un ejemplo práctico usando docker
Veamos un ejemplo práctico usando docker y docker-compose.
Tenemos informes de errores que no se están gestionando adecuadamente. Tenemos la sospecha de que el error podría estar causando por el almacenamiento s3 cuando se queda sin espacio. Por suerte, tenemos una imagen de docker que podemos usar, así que montaremos un volumen tmpfs en el sitio adecuado.
Los contenidos relevantes del fichero «compose.yml» están debajo.
version: '3'
services:
s3server:
image: scality/s3server:latest
restart: always
ports:
- 8000:8000
environment:
- ENDPOINT=s3server
volumes:
- s3tmpdata:/usr/src/app/localData
volumes:
s3tmpdata:
driver_opts:
type: tmpfs
o: size=104857600
device: tmpfsLo que es importante es:
- El volumen «s3tmpdata» está creado con tmpfs, con un límite de 100MB
- El volumen están montado en «/usr/src/app/localData», donde los datos serán subidos de acuerdo a la documentación de la imagen.
Nota: la imagen de docker también expone «/usr/src/app/localMetadata», que almacenará metadatos. Esto no es relevante para esta prueba en particular.
¿Qué hemos conseguido ejecutando docker-compose con ese archivo de configuración? Subir un archivo a ese almacenamiento de s3 colocará algunos datos en «/usr/src/app/locaData». Cuando el servidor s3 llene los 100MB, el servidor tendrá un error de que no hay suficiente espacio. Entonces sabremos qué responde el servidor s3 y cómo podemos tratar ese error en nuestro lado.
En caso de que estuviéramos desarrollando el servidor de s3, podríamos reproducir el error de la misma forma.
Es importante notar que asumimos que el error sucederá sólo cuando el servidor escribe en el directorio «/usr/src/app/localData». No esperamos problemas escribiendo en una carpeta diferente. En caso de que quisiéramos comprobar qué pasa si no podemos escribir en la carpeta de metadata, podríamos cambiar el punto de montaje a «/usr/src/app/localMetadata»
Conclusión
No tener suficiente espacio es algo que podría suceder si no limitamos (o no podemos limitar) la cantidad de información que escribimos en disco. Montar y usar un sistema de ficheros pequeño ayuda a reproducir el problema y a manejarlo de forma adecuada gracias a gestionar el almacenamiento con docker podemos reproducir previsibles errores más fácilmente.
Si quieres saber un poco más sobre docker, puedes leer en nuestro blog:
