В настоящее время у меня есть системная настройка, в которой клиент отправляет мне файлы по FTP, что запускает inotify (через уведомления ядра Linux) для запуска анализа с целью выполнения действий с этими файлами. Проблема, с которой я столкнулся, заключается в том, что анализатор в настоящее время достигает емкости ввода-вывода на одном экземпляре EC2, и я хотел бы добавить дополнительные узлы для работы над разделением загрузки файла. К сожалению, клиент может загружать только по FTP. Это заставляет меня задуматься, как я могу заставить другой экземпляр, который не разделяет том EBS, на который сбрасываются файлы, работать с этим файлом.
Существует ли в настоящее время решение AWS, которое не будет трогать моего клиента, использующего FTP (кроме, возможно, смены IP-адреса, что нормально), и позволит мне иметь несколько экземпляров EC2 для доступа к файловой системе?
решение1
Конечно...
Вы можете подключать и распределять данные по нескольким томам любого типа, чтобы увеличить производительность ввода-вывода, доступную вашим приложениям Amazon EC2.
Это единственное, что я использовал, RAID-10 из томов EBS, но... но я предполагаю, что вы об этом думали.
Я думал предложить масштабировать ваш FTP-сервер, используя что-то вродеHAProxyи/или redirутилита, которая входит в комплект Ubuntu (которая может переписывать пакеты FTP, чтобы исправить некоторые присущие этому протоколу нелепости), но неудобная природа FTP с множественными соединениями может усложнить задачу, и это может оказаться не совсем тем, что вам нужно.
Так что насчет s3fs?
Прежде чем предложить это, я погуглил и нашел что-то вродеэта почта, что предполагало, что это может не сработать, но затем я понял, что автор сообщения в этом случае, похоже, имел существенное отсутствие понимания того, как на самом деле работают S3 и файловые системы, и ожидал, что inotify поймет, что что-то изменилось удаленно в S3 через внешние причины (не пересекая локальную файловую систему), что, конечно, не имеет смысла.
Но я написал код для его проверки, и s3fs действительно, похоже, правильно взаимодействует с inotify. Вы можете смонтировать bucket вместо тома EBS с вашего FTP-сервера, так что когда ваш клиент загружает файлы через FTP, они попадают прямо в bucket — и inotify перехватывает это событие, как это было бы с традиционной файловой системой, и в этот момент вы можете использовать SQS или любой другой механизм, чтобы предупредить рабочие машины о том, что есть задания, которые нужно выполнить. Затем они могут извлекать и обрабатывать файлы независимо, при этом ввод-вывод ограничивается только доступной полосой пропускания между каждой из этих машин и инфраструктурой S3.
Есть ряд вещей, для которых s3fs совершенно не подходит, например, сервер, который снова и снова обслуживает один и тот же статический контент. Для этого s3fs не является хорошим решением из-за большого количества избыточных запросов, которые, скорее всего, возникнут, и/или необходимости кэшировать данные локально (что он может, но в этом нет смысла — если вам это нужно, вы просто храните файлы локально), а задержка, связанная с их индивидуальной загрузкой по требованию при попытке обслуживания адаптивного веб-сайта, может стать проблемой... но когда каждый файлнетобращаясь к нему снова и снова, я добился положительных результатов.
Недавно я выполнил небольшой проект для клиента, который хотел хранить общедоступные загружаемые ресурсы в S3, но у них, возможно, были похожие ограничения, как у вас, — ониДействительнохотел иметь возможность загружать файлы с помощью FTP. Объединение proftpd с контейнером, смонтированным на экземпляре EC2 через s3fs, предоставило им простой «шлюз» в S3, совместимый с их существующими системами... так что я знаю, что это работает, и, только что протестировав ту же настройку с inotify, могу сказать, что у них, похоже, есть ожидаемое взаимодействие.
Используя S3 изнутри EC2 таким образом, цена хранения по сути эквивалентна EBS, и вы не будете платить за пропускную способность, если контейнер находится в том же регионе, что и ваша конечная точка — вы будете платить только за каждый PUT($5 за миллион запросов) и GET($4 за миллион запросов) (моя интерпретация таблиц цен; у меня миллионы объектов, хранящихся в S3, и у меня никогда не было сюрпризов в счетах, но не верьте мне на слово). Возможно, не будет точно 1:1 корреляции файлов и запросов, поскольку s3fs должен проделать некоторую фоновую работу, чтобы сохранить режим файла и владельца в S3 в рамках своей эмуляции псевдофайловой системы, и должен итерировать объекты для генерации списков каталогов, так что YMMV по запросам... но это кажется жизнеспособным решением.
Если вы займетесь этим с должным пониманием несоответствия между тем, что делает S3, и тем, что делает традиционная файловая система, я не вижу причин, по которым это не могло бы масштабироваться настолько бесконечно, насколько это необходимо.
Конечно, больше всего в s3fs мне нравится то, что у вас никогда не кончится место. :)
Filesystem Size Used Avail Use% Mounted on
s3fs 256T 0 256T 0% /var/xxxxxxxxxxx
решение2
Если ваш клиент может получить доступ к вашему FTP по DNS, а не по IP, то, по-видимому, самым простым решением будет разместить ELB перед несколькими экземплярами FTP, чтобы можно было масштабировать горизонтально.
Затем, если вам необходимо, чтобы все файлы, загруженные по FTP, оказались в одном месте после завершения обработки, вы можете использовать S3 или любое другое решение для постоянного хранения обработанных файлов в одном месте.
решение3
Разве вы не можете создать скрипт, который отправляет эти файлы на другой узел, когда inotify обнаруживает, что на ваш головной узел по ftp передаются новые файлы?