Cómo hacer un test drive de Amazon Elastic File System

Muchos clientes están emocionados por Amazon EFS, ya que hace increíblemente fácil la creación y ejecución de un sistema de archivos compartidos, de larga duración, altamente disponible y escalable, en la nube. En segundos, es posible crear un sistema de archivos compatible con NFSv4 y montarlo en múltiples instancias (hasta miles) Amazon EC2 o en servidores on-premises.

Amazon EFS brinda un sistema de archivos elástico, simple y escalable para cargas de trabajo basadas en Linux y está diseñado para escalar a petabytes bajo demanda sin interrumpir aplicaciones que utilizan estos sistemas de archivos. Amazon EFS es compatible con una amplia gama de casos de uso, desde cargas de trabajo escalables con alto paralelismo que requieren el mayor rendimiento posible hasta cargas de trabajo de un solo proceso sensibles a la latencia. Casos de uso como aplicaciones lift-and-shift empresariales, análisis de big data, administración de contenido y servicio web, desarrollo y prueba de aplicaciones, flujos de trabajo de media y entretenimiento, copias de seguridad de base de datos y almacenamiento de contenedores.

Tengo el privilegio de trabajar con clientes al tiempo que evalúan, diseñan e implementan soluciones de almacenamiento para soportar distintas aplicaciones y cargas de trabajo. Un tema que veo con los clientes que son nuevos en Amazon EFS es la falta de familiaridad con las técnicas avanzadas de sistemas de archivos. Quiero compartir estas mejores prácticas con usted antes que evalúe y pruebe Amazon EFS. Esta entrada lo ayuda a aprovechar Amazon EFS al máximo.

Crear un sistema de archivos de Amazon EFS

Si todavía no lo ha hecho, cree un sistema de archivos de Amazon EFS con la Consola de Administración de AWS o la Interfaz de Línea de Comandos (CLI) de AWS. Complete los pasos 1, 2 y 3 en Introducción a Amazon Elastic File System. Después de unos minutos, debería iniciar sesión en una instancia de Amazon EC2 que tenga montado un sistema de archivos de Amazon EFS.

Test drive

Lo primero que me gusta mostrar a los clientes después que montan un sistema de archivos es el tamaño: la cantidad de bloques de 1 K disponibles. Ejecute el comando df en la línea de comandos de la instancia EC2 donde está montado el sistema de archivos de EFS. Debería retornar algo similar a lo que ve en la imagen.

Si es como yo, tendrá dificultades para convertir un valor de nueve cuatrillones (16 dígitos) en algo entendible. Por tanto, el comando df –h facilita la comprensión. A sus aplicaciones les aparece que tienen >8 EB de almacenamiento disponible, pero Amazon EFS es elástico, crece y se reduce de forma automática a medida que agrega y elimina datos, y solo paga por el almacenamiento que está usando (en este caso, cero). Ya no es necesario preocuparse por aprovisionar almacenamiento y solo paga por lo que usa.

Como es fácil comenzar a usar Amazon EFS, tal vez quiera evaluar cómo funciona Amazon EFS lo más rápido posible. Una prueba común que veo que algunos clientes usan para evaluar el rendimiento de Amazon EFS es una prueba de “contacto” para generar muchos archivos de cero bytes. He visto esto escrito en Perl, Python, Java y otros lenguajes.

Para esta entrada, utilizo un script de bash para ver qué tan rápido se pueden generar 1024 archivos. Ejecute el siguiente comando en su instancia EC2 y asegúrese de cambiar la ruta a su sistema de archivos de Amazon EFS.

¿Cuánto tardó? En mi prueba, tardó 16.808 segundos para generar 1024 archivos en Amazon EFS.

Si piensa que esto tomó demasiado tiempo para generar 1024 archivos de 0 bytes, verifique el comando para asegurarse de que sea correcto. Después de eliminar el primer conjunto de 1024 archivos de 0 bytes, ejecute el comando de nuevo. ¿Cuáles son los resultados? Prácticamente los mismos.

Si todavía cree que esto tardó demasiado para generar 1024 archivos de 0 bytes, puede compararlo con otra plataforma de almacenamiento. Modifique el comando y ejecútelo en el volumen de Amazon EBS atachado a la instancia. Ejecute el siguiente comando y asegúrese de cambiar la ruta para usar un volumen de Amazon EBS. En este ejemplo, escribo en el directorio home de ec2-user.

¿Cuánto tardó? En mi prueba, tardó 5.112 segundos para generar 1024 archivos de 0 bytes en EBS. Este es el volumen raíz, que es un volumen de EBS gp2 de 10 GB. En este ejemplo, la operación de escritura de EBS es 3,28 veces más rápida en comparación con EFS.

En casos como este, me gusta jugar con diferentes escenarios de simulación. ¿Qué pasaría si se reescribe el comando para usar varios hilos de ejecución? Esto permite generar archivos en paralelo. Introduzca GNU Parallel, que es una herramienta shell de código abierto para ejecutar operaciones seriales en paralelo. Se agregó al repositorio de Amazon Linux de modo que un comando sudo yum install parallel –y lo instala en Amazon Linux 2, después de instalar y habilitar el paquete rpm EPEL. Para obtener más información, consulte GNU Parallel.

Ejecute el siguiente comando, luego de instalar GNU Parallel y genere 1024 archivos de 0 bytes usando varios hilos de ejecución.

Reescribir el comando para usar 32 jobs (o 32 hilos de ejecución), puede generar 1024 archivos de 0 bytes en solo 8.647 segundos, que es una mejora del 94%.

¿Qué pasaría si reescribimos el comando de varios hilos de ejecución para escribir los archivos en múltiples directorios? Cada hilo de ejecución escribe en un directorio separado. Esto distribuye las operaciones de escritura a través de varios inodos.

Para aquellos que no están familiarizados con los inodos, un inodo es una estructura de datos de estilo Unix que describe objetos de un sistema de archivos, como archivos y directorios. La contención inodos se produce cuando varios hilos intentan actualizar el mismo inodo, lo cual puede ser más evidente en sistemas de archivo de red debido a las latencias de la red. Ejecute el siguiente comando para generar 1024 archivos de 0 bytes con 32 hilos de ejecución, cada hilo de ejecución debe generar 32 archivos en su propio directorio. Treinta y dos archivos en 32 directorios dan un total de 1024 archivos.

Al reescribir el comando para usar los 32 jobs (o 32 hilos de ejecución) y hacer que cada hilo de ejecución genere archivos en su propio directorio, puede generar 1024 archivos de 0 bytes en solo 0.776 segundos. Esto es 21 veces más rápido que la primera prueba de un solo directorio y un solo hilo.

Ahora, ¿qué pasaría si el mismo sistema de archivos se monta en 2, 10, 100 o 1000 instancias de Amazon EC2? ¿Cuántos archivos se pueden generar en un sistema de archivos que admite consistencia “abrir después de cerrar”, durabilidad de datos a través de múltiples servidores de almacenamiento y múltiples zonas de disponibilidad, y alta disponibilidad diseñada sin puntos únicos de falla?

Próximos pasos

Esta es solo una prueba que puede hacerse para evaluar de forma efectiva y probar Amazon EFS. Para aprender más sobre sus características de rendimiento, le recomiendo que vea el Tutorial de Amazon EFS en GitHub. El tutorial explica mucho más que la prueba que yo hice y muestra más ejemplos de los beneficios del paralelismo. También demuestra cómo el tamaño de E/S, el tipo de instancia EC2 y diferentes herramientas de transferencia de archivos tienen un impacto significativo en el rendimiento. Estas técnicas también son utilizadas por AWS DataSync para mejorar el rendimiento de la transferencia de datos desde y hacia los sistemas de archivos de Amazon EFS.

Para obtener más información sobre GNU Parallel, consulte “GNU Parallel – The Command-Line Power Tool” en la revista USENIX, febrero de 2011.

Resumen

Los sistemas de archivos de Amazon EFS se distribuyen a través de un número sin restricciones de servidores de almacenamiento, lo que permite un acceso paralelo en masa a los objetos del sistema de archivos. Este diseño distribuido evita los cuellos de botella y las limitaciones inherentes a los servidores de archivos tradicionales.

En esta prueba, pude usar estos beneficios de Amazon EFS. Reduje el tiempo que tomaba generar 1024 archivos de 0 bytes de 16.808 segundos a 0.776 segundos, que es una mejora del 2100%.

En esta entrada, demostré sólo dos recomendaciones. Puede utilizarlas para aprovechar mejor el diseño de almacenamiento de datos distribuido de Amazon EFS y lograr acceso paralelo en masa a los datos del sistema de archivos.

La primera fue acceder a Amazon EFS en paralelo con varios hilos de ejecución. La segunda fue acceder a varios directorios o inodos en paralelo con varios hilos de ejecución. Otras recomendaciones para comprender mejor y aprovechar el diseño distribuido de Amazon EFS se incluyen en el Tutorial de Amazon EFS. Espero poder escribir más entradas sobre Amazon EFS, FSx for Windows File Server y FSx for Lustre.

Darryl Osborne

Darryl es un Arquitecto de Soluciones para los servicios de archivos en Amazon Web Services (AWS). Es miembro de los equipos de servicio de Amazon EFS y Amazon FSx y es responsable de compartir la oferta de servicios de archivos nativas de AWS. Le gusta pasar tiempo al aire libre en su estado natal de Texas.