Назад | Перейти на главную страницу

Раундробин для входящих файлов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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