Roundrobin для входящих файлов

Куча новых файлов с уникальными именами файлов регулярно «появляется» ¹ на одном сервере. (Подобно сотням ГБ новых данных ежедневно, решение должно масштабироваться до терабайт. Каждый файл имеет размер несколько мегабайт, до нескольких десятков мегабайт.)

Есть несколько машин, которые обрабатывают эти файлы. (Десятки, если решение масштабируется до сотен.) Должна быть возможность легко добавлять и удалять новые машины.

Существуют резервные серверы хранения файлов, на которые каждый архивный файл должен быть скопирован для архивного хранения. Данные не должны быть потеряны, все входящие файлы должны быть доставлены на сервер резервного копирования.

Каждый входящий файл может быть доставлен на один компьютер для обработки и должен быть скопирован на сервер резервного хранилища.

Сервер-получатель не должен хранить файлы после того, как отправил их в путь.

Посоветуйте надежное решение для распространения файлов способом, описанным выше. Решение не должно основываться на Java. Unix-way решения предпочтительнее.

Серверы на базе Ubuntu, расположены в одном дата-центре. Все остальное можно адаптировать под требования решения.

¹ Обратите внимание, что я намеренно опускаю информацию о том, как файлы переносятся в файловую систему. Причина в том, что в настоящее время файлы отправляются третьими лицами несколькими различными устаревшими способами (как ни странно, через scp и через ØMQ). Кажется, проще разрезать межкластерный интерфейс на уровне файловой системы, но если для того или иного решения действительно потребуется какой-то определенный транспорт - устаревшие транспорты могут быть обновлены до этого.

Вот одно из решений того, что вы ищете. Ява не участвует в создании этой системы, просто доступны биты с открытым исходным кодом. Модель, представленная здесь, может работать с другими технологиями, чем те, которые я использую в качестве примера.

1. Файлы отправляются по HTTP на определенный DNS-адрес Round-Robin.
2. Затем система, отправляющая файлы, помещает задание в систему AMQP (здесь Rabbit MQ) с помощью другой пары балансировщиков нагрузки, чтобы запустить рабочий процесс обработки.
3. Балансировщики нагрузки, получающие HTTP POST, находятся перед группой серверов хранилищ объектов OpenStack Swift.
   • Каждый из балансировщиков нагрузки имеет два или более серверов хранилища объектов OpenStack Swift.
   • «Круглый Робин - это не ГА» может быть, если цели - ГА. YMMV.
   • Для дополнительной надежности IP-адреса в RRDNS могут быть отдельными кластерами LB с горячим резервированием.
4. Сервер хранилища объектов, который фактически получает POST, доставляет файл в файловую систему на основе Gluster.
   • Система Gluster должна быть как Распределенной (иначе известной), так и Реплицированной. Это позволяет ему масштабироваться до глупых плотностей.
5. Система AMQP отправляет первое задание, создающее резервную копию, на доступный обрабатывающий узел.
6. Узел обработки копирует файл из основного хранилища в резервное хранилище и при необходимости сообщает об успехе / сбое.
   • Обработка режима отказа здесь не изображена. По сути, продолжайте пытаться, пока это не сработает. И если это никогда не работает, запустите процесс исключения.
7. После завершения резервного копирования AMQP отправляет задание Обработка доступному узлу обработки.
8. Узел обработки либо извлекает файл в свою локальную файловую систему, либо обрабатывает его непосредственно из Gluster.
9. Узел обработки депонирует продукт обработки, куда бы он ни шел, и сообщает об успехе в AMQP.

Эта установка должна иметь возможность принимать файлы с предельной скоростью при наличии достаточного количества серверов. Получение суммарной скорости приема 10GbE должно быть выполнимым, если вы достаточно увеличите его. Конечно, для быстрой обработки такого большого количества данных потребуется еще больше серверов в классе вашего компьютера. Эта настройка должна масштабироваться до тысячи узлов и, возможно, за ее пределами (хотя насколько это зависит от того, что именно вы делаете со всем этим).

Глубокие инженерные проблемы будут заключаться в процессе управления рабочим процессом, скрытом в процессе AMQP. Это все программное обеспечение, и, возможно, специально созданное в соответствии с требованиями вашей системы. Но это должно быть хорошо снабжено данными!

Учитывая, что вы пояснили, что файлы будут поступать через scp, я не вижу никакой причины, по которой интерфейсный сервер вообще существует, так как транспортный механизм может быть перенаправлен на уровень 3.

Я бы поставил LVS-директора (пару) впереди, с пулом серверов обработки и политикой перенаправления циклического перебора. Это позволяет очень легко добавлять и вычитать серверы в / из пула, это повышает надежность, потому что нет никакого резервного сервера переднего плана, и это означает, что нам не нужно задавать вопрос о получении / извлечении файлов из внешний интерфейс для серверов обработки, потому что нет внешнего интерфейса.

Каждый сервер пула должен затем сделать две вещи при получении файла - сначала скопировать его в архивное хранилище, затем обработать файл и отправить его в путь.