Быстрая отправка 4 [GB] для обработки из 100 машин?

У меня есть 100 servers в моем кластере.

В момент времени 17:35:00 все 100 servers снабжены данными (размером 1[MB]). Каждый сервер обрабатывает данные и производит вывод около 40[MB]. Время обработки для каждого сервера 5[sec].

В момент времени 17:35:05 (5[sec] later) необходимо, чтобы центральная машина считывала весь вывод из всех 100 servers (помните, что общий размер данных: 100 [машины] x 40 [МБ] ~ 4 [GB]), объединить его и произвести выход.

, что весь процесс gathering the 4[GB] data из всех 100 servers занимает как можно меньше времени. Как мне решить эту проблему?

Существуют ли какие-либо существующие инструменты (в идеале, в python, но будут рассмотрены другие решения), которые могут помочь?

Ответ 1

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

GigE обеспечивает теоретическую максимальную скорость передачи 125 МБ/с между узлами - таким образом, 4 ГБ займет ~ 30 секунд, чтобы переместить 100 40 Мбайт кусков данных в ваш центральный node из 100 обрабатывающих узлов над GigE.

Файловая система, совместно используемая всеми вашими узлами, обеспечивает альтернативу избыточному Ethernet-RAM для передачи данных RAM.

Если ваша общая файловая система работает на уровне чтения/записи на диске (скажем: множество многодисковых массивов RAID 0 или RAID 10, агрегированных в Luster F/S или некоторые из них), и использует 20 Гбит/с или 40 Гбит/с, а затем 100 узлов, каждый из которых записывает 40 МБ файл на диск, а центральный node, считывающий эти 100 файлов, может быть быстрее, чем перенос блоков размером 100 40 МБ по GigE node на node межсоединение.

Но если ваша общая файловая система представляет собой массив RAID 5 или 6, экспортированный в узлы через NFS через GigE Ethernet, это будет медленнее, чем RAM для передачи ОЗУ через GigE с помощью RPC или MPI, потому что вы должны писать и читать диски над GigE в любом случае.

Итак, были хорошие ответы и обсуждение или ваш вопрос. Но мы не знаем вашу скорость соединения node, и мы не знаем, как настроен ваш диск (общий диск или один диск на node), или есть ли у общего диска его собственное межсоединение и какая скорость то есть.

Node теперь известна скорость межсоединения. Это уже не свободная переменная.

Дисковая настройка (shared/not-shared) неизвестна, поэтому свободная переменная.

Межсоединение диска (при условии совместного использования диска) неизвестно, таким образом, другая свободная переменная.

Сколько оперативной памяти вашего центрального устройства node неизвестно (может ли он хранить 4 ГБ данных в ОЗУ?), таким образом, является свободной переменной.

Если все, включая общий диск, использует одно и то же соединение GigE, можно с уверенностью сказать, что 100 узлов, каждый из которых записывает 40 МБ файл на диск, а затем центральный node, отображающий 100 40 МБ файлов с диска, является самым медленным способом. Если ваш центральный node не может выделить 4 ГБ ОЗУ без обмена, и в этом случае вещи, вероятно, усложняются.

Если ваш общий диск отличается высокой производительностью, может случиться так, что для каждого из 100 узлов каждый будет писать файл 40 Мбайт, а для центрального node - 100 40 МБ файлов.

Ответ 2

Используйте rpyc. Он созрел и активно поддерживался.

Здесь их реклама о том, что она делает:

RPyC (IPA:/ɑɹ paɪ siː/, произносится например, -pie-see), или Remote Python Звонок, является прозрачным и симметричным библиотека python для удаленной процедуры вызовов, кластеризации и распределенных вычислений. RPyC использует объектно-проксирования, метод, который использует динамическую природу питона, преодолеть физические границы между процессами и компьютерами, поэтому управлять удаленными объектами как если бы они были локальными.

Дэвид Мерц имеет быстрый введение в RPyC на IBM developerWorks.

Ответ 3

Какая ваша настройка сети? Если ваша центральная машина подключена к кластеру с помощью одного гигабитного канала, вам потребуется не менее 30 секунд, чтобы скопировать 4GByte на него (и что при 100% эффективности и около 8 с на гигабайт, чего я никогда не видел).

Ответ 4

Можете ли вы написать свой код, используя привязку Python к MPI? MPI имеет средство для передачи данных по проводам от M узлов до N узлов, M, N >= 1.

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

Ответ 5

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

У вас есть 1meg, производящий 40 мегабайт вывода на каждом сервере - экспериментируйте с каждым сервером, сжимающим данные, которые нужно отправить. (Это сжатие может быть бесплатным, если сжатие является частью вашей файловой системы).

Задержка - она никогда не равна нулю.

Можете ли вы изменить свои алгоритмы?

Можете ли вы сделать какое-то иерархическое слияние выходов, а не один процессор, делающий все 4Gigs сразу? (Децимация во времени).

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