Actualmente tengo una configuración del sistema donde un cliente me envía archivos por FTP, lo que activa inotify (a través de notificaciones del kernel de Linux) para activar un análisis que tome medidas sobre esos archivos. El problema con el que me encuentro es que el analizador está alcanzando la capacidad de E/S en una instancia EC2 y me gustaría agregar nodos adicionales para trabajar en la división de la carga del archivo. Lamentablemente, el cliente sólo puede realizar cargas a través de FTP. Esto me deja preguntándome cómo puedo hacer que otra instancia, que no comparta el volumen de EBS en el que se colocan los archivos, funcione en ese archivo.
¿Existe actualmente una solución de AWS que mantendrá a mi cliente que usa FTP intacto (además de tal vez un cambio de IP, lo cual está bien) y me permitirá que varias instancias EC2 accedan al sistema de archivos?
Respuesta1
Por supuesto...
Puede conectar y dividir varios volúmenes de cualquier tipo para aumentar el rendimiento de E/S disponible para sus aplicaciones Amazon EC2.
Eso es algo que he usado, RAID-10 de volúmenes EBS, pero... pero supongo que has pensado en eso.
Pensé en sugerirle escalar su servidor FTP usando algo comoHAProxyy/o la redirutilidad que viene incluida con Ubuntu (que puede reescribir paquetes FTP para solucionar algunos de los absurdos inherentes a ese protocolo), pero la incómoda naturaleza de múltiples conexiones de FTP podría hacer que sea una propuesta complicada, y puede que no sea realmente lo que usted desear.
Entonces, ¿qué pasa con s3fs?
Antes de sugerir esto, busqué en Google y encontré cosas comoesta publicación, lo que sugirió que podría no funcionar, pero luego me di cuenta de que el OP en ese caso parece haber tenido una falta significativa de comprensión de cómo funcionan realmente S3 y los sistemas de archivos, y esperaba que Inotify se diera cuenta de que las cosas habían cambiado de forma remota en S3 a través de causas externas. (sin haber atravesado el sistema de archivos local) lo cual, por supuesto, no tiene sentido.
Pero escribí algo de código para probarlo y, de hecho, s3fs parece interactuar correctamente con inotify. Puede montar un depósito, en lugar de un volumen de EBS, desde su servidor FTP, de modo que cuando su cliente cargue los archivos a través de FTP, caigan directamente en el depósito, e inotify capture ese evento como lo haría con un sistema de archivos tradicional, en En ese punto, podría usar SQS o cualquier otro mecanismo para alertar a las máquinas trabajadoras de que había trabajos por realizar. Luego podrían buscar y procesar los archivos de forma independiente, con la E/S limitada únicamente por el ancho de banda disponible entre cada una de esas máquinas y la infraestructura S3.
Hay una serie de cosas para las que s3fs es completamente inadecuado, como un servidor que ofrece el mismo contenido estático una y otra vez; s3fs no es una buena solución para eso, debido a la gran cantidad de solicitudes redundantes que probablemente que ocurra y/o la necesidad de que s3fs almacene en caché las cosas localmente (lo cual puede, pero no tiene sentido; si lo necesita, entonces simplemente almacenará los archivos localmente), y la latencia involucrada en recuperarlos individualmente bajo demanda Aunque intentar ofrecer un sitio web responsivo podría ser problemático... pero cuando cada archivo esnoAl acceder una y otra vez, he obtenido resultados positivos.
Recientemente hice un pequeño proyecto para un cliente en el que querían almacenar activos descargables públicamente en S3, pero quizás tenían una restricción similar a la suya:en realidadQuería poder cargar los archivos mediante FTP. La combinación de proftpd con un depósito montado en una instancia EC2 a través de s3fs les proporcionó una "puerta de enlace" sencilla a S3 que era compatible con sus sistemas existentes... así que sé que funciona, y después de haber probado esa misma configuración con inotify simplemente Ahora puedo decirles que los dos parecen tener la interacción esperada.
Al usar S3 desde EC2 de esta manera, el precio de almacenamiento es esencialmente equivalente a EBS y no pagaría por el ancho de banda si el depósito está en la misma región que su punto final; solo pagaría por cada uno PUT($5 por millón de solicitudes) y GET($4 por millón de solicitudes) (mi interpretación de las tablas de precios; tengo millones de objetos almacenados en S3 y nunca he tenido una sorpresa en la facturación, pero no confíe en mi palabra). Posiblemente no habrá una correlación exacta de 1:1 entre archivos y solicitudes, ya que s3fs tiene que hacer algunas gestiones en segundo plano para almacenar el modo y la propiedad del archivo en S3 como parte de su emulación de pseudosistema de archivos, y tiene que iterar objetos para generar listados de directorios, por lo que YMMV en las solicitudes... pero parece una solución viable.
Siempre que lo analice con la comprensión adecuada de la falta de coincidencia de impedancia entre lo que hace S3 y lo que hace un sistema de archivos tradicional, no veo por qué esto no lo escalaría tan infinitamente como lo necesita.
Por supuesto, mi parte favorita de s3fs es que nunca te quedas sin espacio. :)
Filesystem Size Used Avail Use% Mounted on
s3fs 256T 0 256T 0% /var/xxxxxxxxxxx
Respuesta2
Si su cliente puede acceder a su ftp mediante DNS, en lugar de IP, parece que la solución más sencilla podría ser colocar un ELB delante de varias instancias de ftp, para que pueda escalar horizontalmente.
Luego, si necesita que todos los archivos ftp terminen en un solo lugar cuando haya terminado de procesar, puede usar S3 o cualquier cantidad de soluciones para almacenar de manera persistente los archivos procesados en una sola ubicación.
Respuesta3
¿No puede tener una secuencia de comandos para enviar esos archivos al otro nodo cuando inotify descubre que hay archivos nuevos que se envían por ftp a su nodo principal?