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

Question

В моем кластере 100 servers.

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Настройка диска (общий / не общий) неизвестна, следовательно, свободная переменная.

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

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

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

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

Answer 2

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

Вот их реклама о том, что он делает:

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

David Mertzкраткое описание RPyC в IBM developerWorks.

Answer 3

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

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

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

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

МожноВы делаете какое-то иерархическое объединение выходов, а не один процессор, делающий все 4Gigs одновременно?(Сокращение по времени).

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

Answer 4

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

Answer 5

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

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