November 1st, 2009

Book

(no subject)

Мой MPI-проект принимает новые обороты. Кластер разросся, и управлять им стало совершенно невозможно. Говнорешения, сделанные на скорую руку, отслужили своё, и надо переписывать, как лучше. Да, почти всё под винду.

Сейчас у нас есть:

1) Узел для "больших ручных" задач (4 x dual core opteron, 12 TB storage, 16 GB RAM)
2) Узел для "малых ручных" задач (single core athlon, исторически первый "быстрый" узел, обгонявший целый кластер 10 x PII 450)
3) Главный узел для всех задач (quad core xeon, 8 GB ram, 2 TB storage).
4) 12 рабочих узлов для "реалтаймовых" задач (quad core xeon, 4 GB ram, 500 GB storage)
5) два вспомогательных linux-узла на rackspacecloud, используемых при всех задачах.

"Большие" задачи - 1 - 150 GB, могут быть терабайты.
"Малые" задачи - 100 B - 1 GB

Исторически самый большой когда-либо глобально анализируемый датасет - 300 ГБ. Был ограничен размером прошлого хранилища на "узле для больших ручных задач" в 1.5 тб. Получалось где-то 400 гб выходных данных, плюс столько же временных файлов внешней сортировки. Остальное занимали архивные данные, которые просто некуда было положить. Сейчас готовлюсь к терабайтам морально.

Ручные задачи - данные кладутся в папку, жмется кнопка обработки, результаты помещаются в другую папку.

Реалтаймовые задачи - всё запущено 24/7. Поллятся (S)FTP-сервера, данные выгребаются в папку, выполняется автоматическая обработка и аплоад результатов. "Большие реалтаймовые" задачи are not implemented yet, так что все реалтайм-задачи - "малые".

Обработка выглядит так:

1) Первый фильтрационный проход - из датасета извлекаются данные для глобального анализа
2) Вспомогательный этап - задействованы локальный, центральный и вспомогательные узлы. На основании глобального анализа текущего датасета с использованием информации, присланной ранее другими узлами, обновляются правила фильтрации
3) Второй фильтрационный проход - на основании обновленных правил выполняется фильтрация
4) Дедупликация - выполняется устранение дупликатов и другой глобальный анализ
Book

Обработка

Обработка выглядит так:

1) Первый фильтрационный проход - из датасета извлекаются данные для глобального анализа
2) Вспомогательный этап - задействованы локальный, центральный и вспомогательные узлы. На основании глобального анализа текущего датасета с использованием информации, присланной ранее другими узлами, обновляются правила фильтрации
3) Второй фильтрационный проход - на основании обновленных правил выполняется фильтрация
4) Дедупликация - выполняется устранение дупликатов и другой глобальный анализ

Разные этапы упираются в разные компоненты системы.

Первый фильтрационный проход - CPU
Промежуточный этап - для больших задач - CPU второго вспомогательного узла, для малых - не уменьшаемая латенси обработки одной записи в 30 сек
Второй фильтрационный проход - СPU
Дедупликация - винт и CPU
Book

Развитие кластера - часть 1

1. Исторически, все начиналось с единственного этапа фильтрации на одном ядре.

2. Были задействованы (с помощью MPI) завалявшиеся у заказчика около 10 старых на тот момент компов PII-450, скорость вырастала втрое.

3. Появился одноядерный Атлон64, который перекрывал производительность кластера. Используется и сейчас для "малых ручных" задач. Кластер был выброшен или продан retired.

4. За огромные (по сравнению с эквивалентным по скорости кластером) бабки был куплен 8-ядерный узел. Просто заказчик не верил в кластеры и старым кластером было трудно управлять. По сей день используется для "больших" ручных задач. Ничтоже сумняшеся, на 8-ядерном просто запускалось 8 одинаковых MPI-процессов вместо одного восьмипоточного. на самом деле, все не так просто - это NUMA-машина из 4-х двухъядерных узлов, каждый с собственной (но прозрачно доступной с других узлов) памятью, связанных между собой Hypertransport в кольцо, так что по-хорошему надо запускать 4 двухпоточных процесса. Один из узлов занимался кроме обработки ещё и раздачей задач остальным, сбором результатов и последующей глобальной обработкой. Затем для повышения масштабируемости были вынесены в отдельные процессы раздатчик ворк-юнитов и их сборщик-глобальный обработчик.

5. Затем заказчика утомило ручное скачивание-закачивание задач, и началась работа над реалтаймовыми задачами. Кластер его по-прежнему пугал, поэтому он закупил несколько 1U-серверов и поставил их в одну стойку с "узлом для больших ручных задач". Этот большой сервер сильно шумит, поэтому он почти всегда выключен и не используется для реалтаймовых задач.

На каждом узле для реалтаймовых задач запускались 6 MPI-процессов, занимавшихся обработкой и 1 перловый процесс для поллинга-выкачивания-закачивания, связанный с MPI-процессами через IPC (Event objects).

Был закуплен также центральный узел для реалтаймовых задач, который хранил описание правил фильтрации. Эти правила синхронизировались (копированием) с рабочими узлами при их перезапуске.

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

Развитие кластера - часть 2

6. Появились первый этап фильтрации и промежуточный этап, пока состоявший из синхронизация одного типа правил между рабочими через хитрое копирование на центральный сервер-с сервера на уровне сетевой файловой системы.

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

На центральном узле стал запускаться процесс, у которого рабочие узлы получали задания по поллингу такого-то аккаунта или обработке такого-то файла на таком-то аккаунте. Перловые процессы на рабочих узлах связывались появившемся на центральном узле перловым процессом с помощью Event::RPC.

8. Затем появилась идея глобальной обработки, потребовавшая взаимодействия всех серверов - так появились вспомогательные серверы и на центральный шедулер легла работа по взаимодействию с ними и с рабочими.

Понятно, что на каждом этапе ничего не переписывалось, так что сейчас там авгиевы конюшни и невероятное лигаси.