linux - ec3 - s3cmd

Qué tan estable es s3fs montar un cubo de Amazon S3 como un directorio local (2)

¿Qué tan estable es s3fs para montar un cubo de Amazon S3 como un directorio local en Linux? ¿Es recomendable / estable para entornos de producción de alta demanda?

¿Hay alguna solución mejor / similar?

Actualización: ¿Sería mejor usar EBS y montarlo a través de NFS a todas las otras AMI?

Esta es una vieja pregunta, así que compartiré mi experiencia durante el año pasado con S3FS.

Inicialmente, tenía varios errores y pérdidas de memoria (tenía un cron-job para reiniciarlo cada 2 horas) pero con la última versión 1.73 ha sido muy estable.

Lo mejor de S3FS es que tienes menos cosas de qué preocuparte y obtienes algunos beneficios de rendimiento de forma gratuita.

La mayoría de tus solicitudes S3 serán PUT (~ 5%) y GET (~ 95%). Si no necesita ningún procesamiento posterior (generación de miniaturas, por ejemplo). Si no necesita ningún procesamiento posterior, primero no debe acceder a su servidor web y cargarlo directamente a S3 (usando CORS).

Asumir que estás golpeando el servidor probablemente signifique que necesitas hacer algo de post-procesamiento en las imágenes. Con una API S3, la cargarás en el servidor y luego la subirás a S3. Si el usuario desea recortar, tendrá que volver a descargarlo desde S3, luego volver a cargarlo en el servidor, recortarlo y luego cargarlo en S3. Con S3FS y el caché local activado, esta organización se ocupa de usted y guarda la descarga de archivos desde S3.

En el almacenamiento en caché, si está almacenando en caché un disco efímero en EC2, obtiene los beneficios de rendimiento que vienen con y puede purgar su caché sin tener que preocuparse por nada. A menos que se quede sin espacio en disco, no debería tener ninguna razón para purgar su caché. Esto hace que las operaciones de desplazamiento como buscar y filtrar sean mucho más fáciles.

La única cosa que deseo que tenga fue la sincronización completa con S3 (estilo RSync). Eso lo convertiría en una versión empresarial de DropBox o Google Drive para S3, pero sin tener que lidiar con las cuotas y tarifas que vienen con él.

Hay un buen artículo sobre s3fs aquí , que después de leer recurrí a un recurso compartido de EBS.

Destaca algunas consideraciones importantes al usar s3fs, a saber, relacionadas con las limitaciones inherentes de S3:

ningún archivo puede tener más de 5GB
no puede actualizar parcialmente un archivo, por lo que al cambiar un solo byte se volverá a cargar todo el archivo.
la operación en muchos archivos pequeños es muy eficiente (cada uno es un objeto S3 separado después de todo) pero los archivos grandes son muy ineficientes
Aunque S3 admite descargas parciales / fragmentadas, s3fs no aprovecha esto, por lo que si desea leer solo un byte de un archivo de 1 GB, deberá descargar todo el GB.

Por lo tanto, depende de lo que esté almacenando si s3fs es una opción viable. Si está almacenando, por ejemplo, fotos, donde desea escribir un archivo completo o leer un archivo completo, nunca cambie un archivo de forma incremental, entonces está bien, aunque uno puede preguntar, si está haciendo esto, ¿por qué no usar S3? API directamente?

Si está hablando de datos de aplicación (por ejemplo, archivos de base de datos, archivos de registro) en los que desea realizar pequeños cambios incrementales, entonces es un no definitivo. S3 Simplemente no funciona de esa manera no puede cambiar un archivo de forma incremental.

El artículo mencionado anteriormente habla de una aplicación similar, s3backer , que s3backer los problemas de rendimiento implementando un sistema de archivos virtual sobre S3. Esto evita los problemas de rendimiento, pero tiene algunos problemas propios:

Alto riesgo de corrupción de datos, debido a las demoras en las escrituras
los tamaños de bloque demasiado pequeños (por ejemplo, el valor predeterminado de 4K) pueden agregar costos adicionales significativos (por ejemplo, $ 130 por 50 GB con bloques de almacenamiento de 4K)
los tamaños de bloque demasiado grandes pueden agregar costos significativos de transferencia de datos y almacenamiento.
el uso de la memoria puede ser prohibitivo: por defecto almacena en caché 1000 bloques.
Con el tamaño de bloque 4K predeterminado, eso no es un problema, pero la mayoría de los usuarios
probablemente querrá aumentar el tamaño del bloque.

Recurrí a EBS Mounted Drived compartido desde una instancia de EC2. Pero debe saber que, aunque es la opción más eficiente, tiene un gran problema. Un compartimiento NFS montado en EBS tiene sus propios problemas: un único punto de falla; si la máquina que comparte el volumen de EBS se cae, usted pierde el acceso en todas las máquinas que acceden al recurso compartido.

Este es un riesgo con el que pude vivir y fue la opción que elegí al final. Espero que esto ayude.